Gerencimento e Qualidade de Software

Prévia do material em texto

Disciplina
Gerenciamento e Qualidade de
Software
Unidade 1
Gerenciamento e qualidade de software
Aula 1
Introdução ao gerenciamento de software
Introdução
Olá, estudante!  
Software desempenha um papel cada vez mais importante no cotidiano das pessoas, sendo
amplamente utilizado em diversas atividades, como ouvir música, assistir a �lmes e se
comunicar com os amigos. Além disso, ele impulsiona a transformação digital, tal como o uso de
inteligência arti�cial, por exemplo, o ChatGPT e o aprendizado de máquina baseado em
recomendações. 
No entanto, a complexidade do software pode representar um desa�o, pois envolve di�culdades
no entendimento e no desenvolvimento de sistemas complexos, principalmente quando há
múltiplas pessoas trabalhando ao longo de um período no mesmo sistema. 
Disciplina
Gerenciamento e Qualidade de
Software
Aluno, nesta aula, abordaremos o conceito de gerenciamento de software, discutindo sua
importância e seus objetivos. Desta forma, entenderemos como o gerenciamento de software
poderá resolver alguns desa�os associados à complexidade do desenvolvimento de software,
garantindo uma entrega bem-sucedida. 
Vamos aos estudos? 
Gerenciamento de software
O desenvolvimento de software nos remete ao código, ao teste e à entrega, mas há um fator
fundamental que percorre o software desde o seu início até sua implantação: o gerenciamento
de software. 
O gerenciamento de software abrange uma série de atividades e processos que são essenciais
para garantir o sucesso do produto, desde sua ideia inicial até a sua implantação. Logo a seguir,
temos as principais etapas do gerenciamento. 
O planejamento estratégico consiste nas estratégias claras para o desenvolvimento e a entrega
do software. No início do planejamento estratégico, é necessário avaliar as necessidades da
organização em relação ao software, entendendo os desa�os, as oportunidades e os objetivos de
negócio que o software deve atender alinhado às metas das organizações.  
Disciplina
Gerenciamento e Qualidade de
Software
Após a de�nição dos objetivos, é importante realizar uma análise de viabilidade dos projetos de
software, considerando fatores, como: recursos, custos envolvidos, prazos, riscos e retorno de
investimento. 
A análise de viabilidade auxilia na seleção dos projetos mais adequados para a inclusão de um
plano estratégico. Com base nesta análise, os projetos de software são priorizados de acordo
com sua relevância estratégica, considerando o alinhamento com os objetivos estratégicos,
baseado na urgência e na capacidade de execução. 
Também é nesta etapa que há a de�nição de planos e cronogramas, envolvendo a alocação de
pessoas e recursos e estimativa de prazos, em que se faz necessário que os planos e
cronogramas sejam revisados regularmente para garantir o processo adequado. 
É importante tratar que, no planejamento estratégico, é fundamental garantir a comunicação
e�caz entre as partes interessadas, que são: usuários �nais, equipes de desenvolvimento e alta
administração. 
A análise de requisitos abrange análises, documentações e validações de requisitos, garantindo
que os requisitos estejam claros, completos e testáveis, incluindo o entendimento das
necessidades do usuário, a priorização de requisitos e a identi�cação das funcionalidades
necessárias. 
O design e arquitetura envolve a identi�cação dos componentes, a de�nição das interfaces e a
organização lógica do software. 
Desenvolvimento e codi�cação é o processo de supervisionar o desenvolvimento e a codi�cação
do software. Isso envolve a programação, a implementação dos requisitos de�nidos, a revisão de
código e a aplicação de boas práticas de programação, assegurando que o desenvolvimento seja
conduzido de forma e�ciente, dentro dos prazos e orçamentos estabelecidos em equilíbrio com a
equipe. 
Testes e qualidade é a execução de estratégias de teste para garantir a qualidade do software e o
atendimento dos requisitos. Nesta fase, são incluídos testes unitários, testes de integração,
testes de sistema, testes de aceitação e testes de usabilidade, promovendo a adoção de boas
práticas de garantia da qualidade, como testes funcionais e não funcionais. 
Implementação e manutenção é a fase de implantação do software em um ambiente de
produção e a sua manutenção contínua, gerenciando a preparação do ambiente, que inclui a
instalação do software, a migração de dados e a con�guração de outros sistemas. 
Aluno, diante de todas as fases listadas, podemos entender o quanto o gerenciamento de
software é importante para termos um bom produto.
Desa�os do gerenciamento de software
Disciplina
Gerenciamento e Qualidade de
Software
á entendemos o que é o gerenciamento de software e suas etapas, agora vamos para os seus
desa�os. Segundo Prado (2000), o nível de sucesso das organizações na produção de um
resultado ou na criação de um produto está diretamente ligado ao nível de maturidade em que
estas empresas se encontram no que diz respeito às habilidades de condução de seus projetos,
pois, quanto maior o amadurecimento em gerenciamento de software, mais previsíveis se tornam
os resultados. 
No entanto, em relação ao software, deve-se destacar que restrições de orçamento e cronograma
são comuns. Sommerville (2011) diz que o sucesso do projeto não é garantido por um bom
gerenciamento, mas o mau gerenciamento costuma resultar em falha do projeto. O autor ainda
cita que a engenharia de software é diferente dos outros tipos de engenharia em muitas formas,
devido tornar o gerenciamento de software desa�ador. 
Disciplina
Gerenciamento e Qualidade de
Software
Figura 1 | Desa�os no gerenciamento de software.  Fonte: adaptado de Sommerville (2011, p. 414). 
Pressman e Maxim (2021, v. 9, p. 968) exempli�cam sobre um gerenciamento de software fraco
com um comentário de Meilir Page-Jones (1985): “Testemunhei, horrorizado (…) gerentes
dedicarem esforços em projetos que eram verdadeiros pesadelos, contorcendo-se em prazos
impossíveis ou entregando sistemas que ultrajavam seus usuários e continuavam a devorar um
bocado de tempo de manutenção”. 
O gerenciamento de software fraco, geralmente, se dá pela existência de ine�ciência ou
problemas signi�cativos no modo de condução e coordenação dos projetos. Alguns sinais de um
gerenciamento de software fraco podem incluir: 
Atrasos frequentes: projetos que constantemente estão atrasados em relação aos prazos
estabelecidos, indicando um equívoco no planejamento pela falta de de�nição de
prioridades ou recursos insu�cientes para �nalizar dentro do cronograma. 
Acima do orçamento: quando não há um controle adequado dos custos devido a
estimativas irreais ou à falta de monitoramento �nanceiro no projeto, pode-se estourar o
orçamento estipulado. 
Disciplina
Gerenciamento e Qualidade de
Software
Falta de comunicação e colaboração: a falta de uma comunicação clara e aberta com as
pessoas interessadas pelo produto pode gerar um mal entendimento do que é necessário
para o sistema, prejudicando o objetivo do projeto. 
Baixa qualidade do produto: o resultado de um software com muitos defeitos, erros ou bugs
indica a falta de qualidade perante uma análise falha do escopo do software, ocasionando
erros no desenvolvimento do produto.  
Falta de de�nição dos requisitos: um fator in�uenciador pela falta de comunicação são os
requisitos de software, que não se encontram claros e/ou possuem constantes mudanças,
podendo resultar em um produto �nal que não atende às expectativas dos usuários. 
Alto índice de rotatividade da equipe: uma equipe de desenvolvimento que sofre pela alta
rotatividade de seus membros pode ser resultado de problemas de liderança, falta de
motivação ou até mesmo um ambiente de trabalho não saudável. 
Para evitarmos um gerenciamento de software fraco, deve-se abordar esses problemas
especí�cos de forma proativa, implementando práticas de gerenciamento de software mais
e�cientes, como veremos a seguir.
Gerenciamento de software mais e�ciente
Disciplina
Gerenciamento e Qualidade de
Software
Um gerenciamentode software e�ciente se constrói por meio de uma combinação de elementos-
chave. Pressman e Maxim (2021) destacam que o gerenciamento e�ciente do desenvolvimento
de software se concentra nos 4 Ps: pessoas, produto, processo e projeto, não sendo de ordem
arbitrária, em que um é tão importante quanto o outro. 
 Pessoas 
A construção de um software é realizada por pessoas, e o sucesso de um projeto depende de
pessoas bem treinadas e motivadas. 
Pressman e Maxim (2021) ressaltam que o elemento humano, representado pelas pessoas
envolvidas no desenvolvimento, é essencial para o sucesso. Quando o gerenciamento de
software não reconhece a importância do esforço humano e não coloca as pessoas no centro do
processo, pode enfrentar di�culdades signi�cativas para o êxito do processo. 
É crucial reconhecer e valorizar as habilidades, o conhecimento e as contribuições individuais de
cada membro da equipe, além de fornecer um ambiente de trabalho colaborativo. Pessoas
motivadas e engajadas são fundamentais para uma entrega bem-sucedida. 
Outro fator é manter uma comunicação clara e aberta, em que os envolvidos possam se sentir
encorajados a compartilhar informações, ideias e preocupações, alinhando suas expectativas,
resolvendo problemas e mantendo os membros da equipe engajados e informados. Além de
investir no desenvolvimento pro�ssional da equipe, encorajando a colaboração entre todos. 
 Produto 
No início do planejamento estratégico, vimos que são criados a estimativa quantitativa e o
cronograma de atividades, mas, provavelmente, no início do planejamento, não temos todas as
informações sólidas, até porque realizar uma análise detalhada dos requisitos para ter as
informações �dedignas pode demorar semanas ou até mesmo meses. Mas, ainda assim, se faz
necessário um escopo estabelecido e delimitado. 
É neste escopo que serão identi�cadas as necessidades dos usuários e das partes interessadas,
capturando os requisitos e documentando-os de forma adequada para garantir uma base sólida
para o desenvolvimento. Com isso, a gerência e a equipe técnica conseguem mitigar os riscos,
de�nir alguns prazos e orçamentos, escolhendo a melhor estratégia baseada na estimativa
quantitativa. 
 Processo 
O produto se inicia pela junção de vários processos que serão os responsáveis por guiar o
trabalho da equipe de desenvolvimento. Pressman e Maxim (2021) destacam a importância de
adotar processos e�cientes, de acordo com o projeto de software a ser desenvolvido, tais como
metodologias ágeis, processos em cascata, desenvolvimento interativo, entre outros. O objetivo é
ter um processo bem de�nido e que permita uma entrega e�caz do software. 
 Projeto 
Para evitar a falha de um projeto, primeiramente, devemos entender os fatores-chave do projeto.  
Para o sucesso, Pressman e Maxim (2021) incluem: requisitos claros e fáceis de compreender;
participação ativa do usuário em toda a construção do produto; gerente com habilidades de
liderança; construção do plano do produto e cronograma com a participação dos envolvidos;
equipe habilidosa e engajada com espírito colaborativo; orçamento e cronograma realistas e
sempre monitorados; necessidade do cliente entendida e satisfeita e, por último, produto com
qualidade e escopo atingido. 
Disciplina
Gerenciamento e Qualidade de
Software
Aluno, para concluir o nosso entendimento a respeito de gerenciamento de software, este
fornece etapas estruturadas, processos bem de�nidos e necessários para garantir uma entrega
e�ciente do sistema.
Videoaula: Introdução ao gerenciamento de software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante! Durante esta aula, você entendeu o gerenciamento de software desde a sua
importância até seus objetivos atrelados à complexidade do desenvolvimento de sistemas.
Sabemos que o gerenciamento de software é um campo repleto de obstáculos e demandas
constantes, por isso, neste vídeo, você verá um compilado das principais di�culdades e desa�os
que um gestor de software pode encontrar ao atuar no mundo do software. 
Saiba mais
Disciplina
Gerenciamento e Qualidade de
Software
Para aprofundar seu conhecimento sobre gerenciamento de software, seguem dois livros com o
objetivo de você consolidar seus conhecimentos. 
 Processos de software, de Polyanna Fabris e Luis Perini: neste livro, aborda-se a modelagem de
processos de negócio, que é fundamental para entender, otimizar e aprimorar o funcionamento
das organizações. Aborda-se também sobre a engenharia de requisitos e o gerenciamento de
projetos de software.  
 Gestão de projetos de software, de Marcio Artero: neste livro, abordam-se os conceitos de
gestão de projetos de software com estratégias baseadas na governança de TI, a gestão de
escopo através dos requisitos de um software, a análise e mapeamento de riscos e a
importância da qualidade de software. 
Referências
https://biblioteca-virtual.com/detalhes/ebook/608704eb54aa8872fc616ec6
https://biblioteca-virtual.com/detalhes/ebook/6087054354aa8872fb666adc
Disciplina
Gerenciamento e Qualidade de
Software
PRADO, D. Gerenciamento de projetos nas organizações. Belo Horizonte: FDG, 2000. 
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem pro�ssional. 9. ed.
Porto Alegre: AMGM, 2021. 
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
Aula 2
Introdução à qualidade de software
Introdução
Disciplina
Gerenciamento e Qualidade de
Software
Olá, estudante!
Uma vez que interagimos com aplicativos de software, seja em sites ou em dispositivos móveis,
podemos nos deparar com situações frustrantes, que podem ser: comportamentos inesperados
do software, mensagens de erro ou até mesmo a demora demasiada no carregamento de um 
    site.
Essas experiências podem ser desagradáveis e até mesmo prejudicar a usabilidade e a e�ciência
de uma plataforma digital. Os problemas variam desde falhas de interface do usuário até
questões de desempenho e estabilidade do aplicativo. Mas, estas situações podem ser
resumidas pela falta de qualidade? Aliás, o que é a qualidade de um software?
Nesta aula, abordaremos o conceito de qualidade de software, entendendo o que é de fato,
mostrando o seu signi�cado. Exploraremos os objetivos e as métricas do gerenciamento da
qualidade de software, para medir a qualidade de um produto. Além disso, analisaremos os
principais elementos que compõem a garantia da qualidade de software.
Vamos começar?
Qualidade de software
Disciplina
Gerenciamento e Qualidade de
Software
A qualidade de um produto de software se tornou fundamental para a competitividade entre
empresas de tecnologia. Nesse cenário altamente disputado, as empresas que se destacam são
aquelas que compreendem a relevância da qualidade e se empenham continuamente para
      empregar qualidade em seus produtos (softwares) e serviços.
Além do contexto competitivo, temos sistemas complexos, nos quais a qualidade pode ser um
fator determinante para o sucesso de um software. Em alguns casos, os softwares      lidam com
situações em que milhões de reais podem estar em jogo e, até mesmo, vidas humanas.
Embora a palavra “qualidade” pareça intuitiva em seu signi�cado, à medida que nos
aprofundamos no assunto, descobrimos que a sua interpretação vai além do que inicialmente
imaginávamos.
Em produtos de software, a avaliação da qualidade é uma tarefa abstrata e bem complexa. Ao
analisarmos a qualidade de software, deparamo-nos com uma série de aspectos intangíveis que
não podem ser facilmente medidos ou quanti�cados de maneira objetiva, tais como: a e�ciência
do sistema através de suas funcionalidades; a con�abilidade do software em realizar tarefas
     sem falhas; a segurança em proteger os sistemas de ataques maliciosos e ameaças; a
usabilidade na interação do usuário ao software. Esses são alguns exemplos de qualidade que o
software deve apresentar, mas é difícil medir.Como mencionado, a avaliação do software é desa�adora, pois envolve opiniões, percepções e
interpretações individuais, sendo que cada pessoa pode ter diferentes pontos de vista sobre a
qualidade, baseando-se em sua experiência, seu conhecimento e seus valores pessoais.
A avaliação da qualidade de software é um processo subjetivo, em que a equipe de
gerenciamento de qualidade precisa usar seu julgamento para decidir se foi alcançado um nível
aceitável de qualidade. Ela precisa considerar se o software é adequado para sua �nalidade ou
não (Sommerville, 2011).
Disciplina
Gerenciamento e Qualidade de
Software
Pressman e Maxim (2021) englobam duas características à qualidade de software: qualidade do
projeto e qualidade de conformidade.
A qualidade do projeto envolve o grau de atendimento às características especi�cadas de
requisitos. Já a qualidade de conformidade foca na implementação do projeto e se o sistema
resultante atende efetivamente às necessidades e metas estabelecidas.
A qualidade de software é uma combinação de múltiplos atributos, e não depende apenas dos
requisitos do sistema, mas também da experiência do usuário e do atendimento às necessidades
especí�cas de cada contexto, requerendo um processo contínuo de testes, validações dos
usuários e aprimoramentos para assegurar que o produto atenda aos mais altos padrões de
desempenho e satisfaça as demandas dos usuários de forma efetiva.
Métricas de gerenciamento e qualidade de software
Agora que já temos uma compreensão a respeito do signi�cado de qualidade no
desenvolvimento de software, precisamos conhecer como medir a qualidade.
Primeiramente, as métricas desempenham um papel essencial na avaliação e no aprimoramento
contínuo da qualidade no software, por serem medidas quantitativas utilizadas para avaliar
diversos aspectos, visto que fornecem informações mensuráveis e objetivas da qualidade do
sistema, possibilitando ter uma visão clara sobre o produto.
Por meio das métricas, é possível obter uma compreensão mais aprofundada dos pontos fortes
dos sistemas e das áreas que necessitam de maior aprimoramento, identi�cando possíveis
Disciplina
Gerenciamento e Qualidade de
Software
problemas e riscos, permitindo que a equipe de desenvolvimento tome medidas preventivas ou
corretivas. Além disso, as métricas permitem monitorar o progresso do projeto ao longo do
tempo, identi�cando o que é crucial para garantir o cumprimento de prazos e metas
estabelecidas, evitando desvios signi�cativos.
A medição possibilita uma comparação entre diferentes projetos e/ou versões do software,
ajudando a identi�car melhores práticas e contribuindo para o aprimoramento de futuros
projetos.
Embora existam muitas medidas de qualidade de software,      a correção, a manutenibilidade, a
integridade e a usabilidade são as que mais fornecem indicadores úteis para a equipe de
desenvolvimento      (Pressman; Maxim, 2021).
Correção: mede a quantidade de defeitos encontrados em uma aplicação. Como métrica,
podemos analisar a taxa de novos defeitos, que indica quantos defeitos são encontrados
em um determinado período; a classi�cação dos defeitos, que pode ser baixa, média, alta
ou crítica; o tempo médio para corrigir os defeitos; a taxa de reincidência de defeitos,
indicando a proporção de defeitos que reaparecem após as correções; o percentual de
defeitos encontrados pelos usuários, comparados aos encontrados pela equipe de testes.
Manutenibilidade: mede a facilidade que um sistema pode ser modi�cado, atualizado ou
corrigido após sua implementação inicial. Essa métrica avalia a capacidade do software de
ser sustentado e aprimorado ao longo do tempo. Uma métrica simples é o Tempo Médio
para Alterar (MTTC), que mede o tempo necessário para analisar, projetar, implementar,
testar e liberar a funcionalidade aos usuários.
Integridade: mede a capacidade do sistema de resistir a ataques intencionais à segurança.
A integridade é de�nida com base nas métricas de ameaça (probabilidade de ataque) e
segurança (probabilidade de repelir o ataque).
Usabilidade: mede a facilidade de uso do software e a experiência do usuário em interagir
com a aplicação. Como métrica, podemos analisar a taxa de tarefas realizadas com
sucesso pelos usuários na primeira tentativa; o tempo médio que os usuários levam para
concluir as tarefas no sistema; a proporção de erros cometidos pelos usuários ao realizar
tarefas especí�cas; a satisfação do usuário ao utilizar o produto.
Portanto, as métricas são essenciais para garantir a qualidade do software e podem ser
utilizadas para direcionar ações de melhoria contínua     . 
Elementos da garantia da qualidade de software
Disciplina
Gerenciamento e Qualidade de
Software
Durante a nossa jornada sobre o gerenciamento da qualidade de software, percebemos a
importância das métricas de qualidade. É fundamental compreender que a qualidade não deve
ser uma preocupação secundária, em vez disso devemos incorporar a qualidade na concepção
do software até em sua manutenção.
A qualidade abrange todo o ciclo de desenvolvimento do software e diversos outros fatores,
como: a compreensão das necessidades do cliente, a de�nição clara dos requisitos, a análise do
processo e a adoção de boas práticas no desenvolvimento.
A garantia da qualidade de software é uma atividade essencial para assegurar que o produto
alcance os mais elevados padrões de qualidade. Integrá-la em todas as fases do
desenvolvimento é um passo crucial para alcançar o objetivo proposto do software.
Ao garantir a qualidade desde o início, conseguimos evitar retrabalho e custos extras, além de
reduzir problemas signi�cativos no produto. Isso resulta em um impacto positivo na entrega, pois
teremos um software que atende efetivamente às necessidades do cliente.
Disciplina
Gerenciamento e Qualidade de
Software
Figura 1 | Garantia da qualidade de software. Fonte: Pressman e Maxim (2021, p. 693).
De acordo com a Figura 1, os elementos da garantia de qualidade de software são:
De�nir processo: engloba o estabelecimento de um processo especí�co para a garantia da
qualidade, com diretrizes, políticas e procedimentos que serão seguidos durante todo o
ciclo de desenvolvimento.
Controle de alterações: compreende o controle e gerenciamento de todos os artefatos
produzidos durante o desenvolvimento do software, garantindo a integridade e
rastreabilidade dos itens.
Revisões e testes: inclui atividades especí�cas relacionadas à garantia e ao controle da
qualidade, tais como: revisões técnicas, estratégias de testes para identi�car e avaliar o
impacto dos defeitos encontrados, melhorando a qualidade do software.
Métodos e ferramentas: os métodos são as abordagens ou  técnicas sistematizadas que
guiam o processo de desenvolvimento. Já as ferramentas são os softwares que auxiliam
nas atividades de desenvolvimento.    
Auditorias e conformidade: avalia a e�cácia dos processos de�nida pela organização e
garante que o software esteja em conformidade com os padrões estabelecidos.
Medição e geração de relatórios: garante o uso das métricas e indicadores para medir a
qualidade do processo de desenvolvimento, identi�cando áreas de melhoria e gerando
relatórios para acompanhar o progresso e a conformidade com os objetivos estabelecidos.
Pressman e Maxim (2021) ainda citam que outros elementos também fazem parte da
preocupação da garantia da qualidade, tais como: a capacitação dos pro�ssionais da equipe e a
Disciplina
Gerenciamento e Qualidade de
Software
garantia das atividades de suporte, entre eles: manutenção, suporte on-line, documentação e
manuais de usuários.
Aluno, ao combinar estes elementos, as equipes de desenvolvimento podem estabelecer uma
cultura de qualidade sólida e garantir que o software atenda a altos padrões de qualidade.    
Videoaula: Introdução à qualidade de software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá,estudante!
Durante esta aula, você entendeu sobre o gerenciamento da qualidade de software, a importância
das métricas e a garantia da qualidade. A qualidade de software faz-se importante porque a
equipe julga e avalia o que se dará como nível de qualidade. Neste vídeo, você aprenderá sobre a
qualidade do produto e a da conformidade, duas características fundamentais para a construção
da qualidade, compreenderá a importância das métricas e verá na prática como é calculada a
métrica DRE.
Saiba Mais
Disciplina
Gerenciamento e Qualidade de
Software
Para aprofundar seu conhecimento sobre gerenciamento da qualidade, indicamos o livro a seguir:
Gestão da Qualidade, de Eliana Belo Silva: neste livro, abordam-se a história e a perspectiva
estratégica da qualidade, modelos normalizados e ferramentas para a gestão da qualidade. A
obra retrata a qualidade em um âmbito geral, não focando apenas em produtos de software.
 
Referências
https://biblioteca-virtual.com/detalhes/ebook/6087057d54aa8872fb666c5d
Disciplina
Gerenciamento e Qualidade de
Software
CAMPELO, G. B.; BUENO, C. F. S. Qualidade de Software. Recife: UFPE, [s. d.]. Disponível em:
https://www.cin.ufpe.br/~mrsj/Qualidade/Qualidade%20de%20Software.pdf. Acesso em: 2 ago.
2023.
FERREIRA, A. B. H. Novo Dicionário Aurélio da Língua Portuguesa. 2. ed. Rio de Janeiro: Nova
Fronteira, 1986.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem pro�ssional. 9. ed.
Porto Alegre: AMGM, 2021.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
Aula 3
Gerenciamento da qualidade de software
Introdução
https://www.cin.ufpe.br/~mrsj/Qualidade/Qualidade%20de%20Software.pdf
Disciplina
Gerenciamento e Qualidade de
Software
Olá, estudante!
Podemos perceber que a qualidade de software desempenha um papel fundamental no
desenvolvimento de software, garantindo que o produto atenda às necessidades dos usuários.
Essa busca pela excelência abrange um conjunto de características e propriedades que de�nem
o grau de qualidade de um software.
Priorizar a qualidade em produtos de software é crucial para prevenção de problemas e
retrabalho, garantindo a satisfação dos clientes. Nesta aula, exploraremos os diversos fatores
pelos quais a qualidade pode ser avaliada, além de analisar as estratégias e práticas que podem
ser adotadas para assegurar a qualidade em todas as etapas do desenvolvimento.
Contudo, enfrentamos um dilema comum no desenvolvimento de software: o equilíbrio entre
entregar um produto de qualidade aceitável quanto à perfeição excessiva pela qualidade. Para
superar esse desa�o, discutiremos quais as formas de encontrar esse equilíbrio.
Vamos lá?
Fatores da qualidade de software
Disciplina
Gerenciamento e Qualidade de
Software
Aluno, ao longo dos anos, a indústria de tecnologia tem reconhecido a importância de fornecer
sistemas con�áveis, e�cientes e que atendam às expectativas dos usuários. Para alcançar esses
objetivos, é essencial entender e analisar os diversos fatores que in�uenciam a qualidade de um
software.
Em 1977, McCall desenvolveu um dos primeiros modelos formais para avaliar a qualidade,
conhecido como Modelo de Fatores de Qualidade de McCall. Esse modelo propôs uma estrutura
organizada para re�etir sobre os aspectos fundamentais que in�uenciam na qualidade do
software.
Os fatores de qualidade desempenham um papel fundamental na avaliação e garantia de
qualidade do software, sendo estes os atributos e as características que determinam o grau de
excelência do produto: produtos usados para avaliar o quão bem o software atende aos
requisitos do usuário e às expectativas de qualidade.
De acordo com a Figura 1, o modelo de fatores de qualidade de McCall focou em três categorias
principais que abrangem diferentes fatores de produtos de software.
Disciplina
Gerenciamento e Qualidade de
Software
Figura 1 | Fatores da qualidade de software. Fonte: adaptada de McCall, Richards e Walters (1977).
Disciplina
Gerenciamento e Qualidade de
Software
A revisão do produto aborda a capacidade do software de ser modi�cado, atualizado e corrigido
com facilidade, sem impactar negativamente sua estrutura e funcionalidade. Inclui fatores, como:
Manutenibilidade: passar por mudanças ou evoluções de forma rápida e com baixo impacto
em sua estrutura e funcionamento.
Flexibilidade: ajustar ou adaptar facilmente a novas exigências, como: novos cenários,
requisitos ou funcionalidades adicionais.
Testabilidade: submeter a testes de forma abrangente, e�ciente e con�ável, a �m de
veri�car se ele atende aos requisitos e se funciona corretamente em diferentes cenários.
A transição do produto aborda a capacidade do software de ser adaptado e transferido para
diferentes ambientes e plataformas sem a necessidade de grandes modi�cações. Inclui fatores,
como:
Portabilidade: ser transferido em diferentes sistemas operacionais, plataformas de
hardware ou ambientes de execução. Um software portável pode ser executado em
diversos dispositivos ou ambientes sem a necessidade de modi�cações signi�cativas.
Reusabilidade: ter componentes ou módulos reutilizados para outros softwares. Um código
bem estruturado e modular facilita a reutilização de suas partes, economizando tempo e
recursos no desenvolvimento de novos sistemas.
Interoperabilidade: funciona de forma integrada com outros sistemas e aplicativos,
independentemente das plataformas ou tecnologias usadas, garantindo que dados e
serviços possam ser compartilhados e trocados de maneira e�ciente.
A operação do produto aborda a forma que o software se comporta e executa suas funções em
condições normais de uso, ou seja, quando está em pleno funcionamento pelos usuários. Inclui
fatores, como:
Correção: satisfazer as especi�cações e cumprir os objetivos visados pelo cliente.
Con�abilidade: executar as funções de maneira estável, sendo livre de defeitos, evitando
interrupções inesperadas durante o uso.
Usabilidade: fácil entendimento de uso e intuitivo, permitindo que os usuários interajam
com o sistema de forma simples e sem di�culdades.
Integridade: manter e preservar a integridade dos dados e das informações manipuladas
durante o seu funcionamento, evitando corrupção, perda ou acesso não autorizado.
E�ciência: desempenho do software em relação à velocidade e utilização de recursos,
garantindo que as tarefas sejam executadas de forma rápida e sem atrasos excessivos.
Aluno, vimos como cada fator contribui para a criação de um software mais con�ável, e�ciente e
adaptável, resultando em um produto que proporciona uma experiência positiva e satisfatória.
 
Como garantir a qualidade de software?
Disciplina
Gerenciamento e Qualidade de
Software
Caro aluno, compreender a qualidade de software é um desa�o, pois ela possui conceitos
diferentes para diferentes pessoas. Também, a qualidade é impactada por diversos fatores que
afetam seu resultado. Na Aula 2, tivemos a oportunidade de entender o signi�cado da qualidade
e explorar os seus elementos fundamentais da garantia da qualidade. Esses elementos são vitais
para assegurar que padrões e critérios de qualidade sejam devidamente alcançados. Entretanto,
o que deve ser feito para garantir a qualidade de um software?
A �m de garantir a qualidade do software, é importante compreender que a garantia da qualidade
deve estar presente em todas as etapas do desenvolvimento de software, vide exemplo na Figura
2. Seu principal objetivo é detectar problemas antes que sejam migrados para a próxima fase.
Figura 2 | Garantia da qualidade em todas as etapas de desenvolvimento. Fonte: adaptada de Bartié (2002).
De acordo com cada fase, temos as seguintes atividades e atuações da garantia da qualidade:
Disciplina
Gerenciamento e Qualidade de
Software
De�nição do modelo de negócios: nesta fase, ocorre a modelagem e a identi�cação das
necessidades do cliente, proporcionando uma compreensão do produto a ser desenvolvido,
bem como a sua viabilidade, o seu cronograma e os custos. A garantia da qualidade
assegura que as necessidades relatadas pelosclientes são claras e objetivas, além de
veri�car a existência de um planejamento que abranja a avaliação de viabilidade de
execução do projeto, o cumprimento do prazo e os custos envolvidos.
Especi�cação dos requisitos: nesta fase, são identi�cadas as características funcionais e
não funcionais para a concepção do produto. Durante esta fase, todas as necessidades que
emergiram no modelo de negócio são minuciosamente detalhadas através dos requisitos.
A garantia da qualidade deve avaliar se os requisitos coletados estão completos, claros e
sem ambiguidade. Adicionalmente, é essencial veri�car se eles foram validados pelos
clientes e se existe a rastreabilidade entre os requisitos.
Análise e modelagem: nesta fase, é de�nido um modelo de solução que abrange todos os
requisitos de�nidos na fase anterior. A garantia de qualidade avalia se todos os requisitos
foram incluídos nesta solução, bem como veri�ca a capacidade da arquitetura de�nida em
lidar e�cazmente com mudanças signi�cativas, sejam elas relacionadas ao crescimento, à
segurança, ao ambiente etc.
Implementação: já na fase de implementação, os modelos e requisitos de�nidos nas fases
anteriores são transformados em código fonte. A garantia da qualidade assegura a
legibilidade do código fonte; avalia a conformidade com o padrão de desenvolvimento da
organização; avalia as mensagens apresentadas ao usuário �nal e a existência de rotinas
de tratamento de erros em processos críticos do sistema.
Teste de software: o objetivo desta fase é identi�car falhas para buscar con�abilidade,
usabilidade e e�ciência do produto, assegurando que funcione conforme o esperado em
diferentes cenários e condições. A garantia da qualidade avalia se as estratégias, as
categorias e os casos de testes de�nidos estão sendo seguidos e executados de acordo
com o planejado para alcançar os objetivos propostos.
Disponibilização: fase em que o produto é entregue ao cliente para os usuários realizarem a
homologação das funcionalidades do sistema. A garantia de qualidade avalia a entrega do
sistema e garante o aceite por parte do cliente e as manutenções necessárias.
Através da presença e do acompanhamento em todas as fases do desenvolvimento, podemos
garantir a qualidade do software e do processo.
 
O dilema da qualidade de software
Disciplina
Gerenciamento e Qualidade de
Software
Ao longo desta jornada, exploramos os conceitos fundamentais sobre qualidade e os meios para
garantir a qualidade de software. No entanto, quão intensamente devemos direcionar o esforço e
o foco para a garantia da qualidade? O que seria um software “bom o su�ciente”?
Essas são questões do dilema da qualidade. Se for desenvolvido um software de baixa
qualidade, podemos ter uma falta de interesse do mercado; se buscarmos por um software
perfeito, devemos ter em conta os custos altos e um período longo de desenvolvimento. O dilema
da qualidade é encontrar um equilíbrio entre um produto aceitável, evitando excessos de esforço
e gasto, de forma que não comprometam o projeto.
Este dilema surge porque, ao investir em testes rigorosos, revisões extensas e práticas de
desenvolvimento de qualidade, pode-se obter um produto �nal mais estável e con�ável,
resultando em menos retrabalho, menos problemas após seu lançamento e uma reputação
positiva para a empresa. Mas, essa abordagem pode aumentar o tempo de desenvolvimento,
atrasar o lançamento do produto e aumentar os custos.
Por outro lado, optar por acelerar o processo de desenvolvimento pode permitir que o produto
chegue ao mercado mais rapidamente, o que pode ser vantajoso em um ambiente de
competição acirrada. Entretanto, pode resultar em problemas de qualidade, defeitos,
vulnerabilidades à segurança e insatisfação do cliente.
Então, o que seria um software “bom o su�ciente”?
O software “bom o su�ciente” fornece funções e características de alta qualidade desejadas
pelos usuários, mas, ao mesmo tempo, fornece outras funções e características mais obscuras
Disciplina
Gerenciamento e Qualidade de
Software
ou especializadas que contêm erros conhecidos (Pressman; Maxim, 2021).
Para Pressman e Maxim (2021), é viável a entrega de um software que não seja perfeito, mas que
atenda às necessidades do usuário e, ao mesmo tempo, ofereça alguns erros conhecidos. Com
um bom time de marketing, pode-se vender este software em sua primeira versão e melhorá-la
para a versão 2.0 com aprendizados.
Pressman e Maxim (2021) enfatizam o risco para pequenas empresas de entregar um produto
com erros, visto que se pode arruinar permanentemente a reputação da empresa, nem tendo
chances de entregar uma próxima versão. Também, temos softwares de grandes corporações,
como os de sistemas embarcados em tempo real, que envolvem risco à vida, nos quais qualquer
erro conhecido compromete drasticamente a con�abilidade.
Mas, quanto custa a qualidade? No contexto de assegurar a qualidade, certamente, haverá um
investimento �nanceiro, contudo, a ausência da qualidade também acarretará custos.
Figura 3 | Custos para corrigir erros e defeitos ao longo do ciclo de vida do software. Fonte: adaptada de Boehm e Basili
(2001).
Na Figura 3, ao exempli�car em valores, observa-se que o custo relacionado ao encontrar e
corrigir um defeito aumenta drasticamente à medida que avançamos cada vez mais nas fases do
desenvolvimento de software. Entre a fase de requisitos e codi�cação, vê-se um aumento de 1 a
10 vezes o valor do custo da correção. Na fase de testes, esse valor sobe de 15 a 70 vezes. Após
o lançamento do produto, este custo pode chegar a 1000 vezes mais caro.
Mesmo que tenha um custo para garantir a qualidade, no �nal, torna-se mais barato do que não o
ter, ou seja, o equilíbrio envolve uma análise sobre o objetivo do produto, as oportunidades do
mercado (custo e prazo) e atender às necessidades do usuário.
Videoaula: Gerenciamento da qualidade de software
Disciplina
Gerenciamento e Qualidade de
Software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante!
Durante esta aula, você entendeu sobre os atributos e as características que determinam o grau
de qualidade no software, como garantir a qualidade no software, o dilema da qualidade e os
custos que envolvem a qualidade. Neste vídeo, você aprenderá sobre como devemos aplicar a
qualidade no processo de desenvolvimento de um produto e qual o custo da qualidade.
Saiba mais
Para aprofundar seu conhecimento sobre a garantia da qualidade, indicamos o livro a seguir:
Gestão da Qualidade no Desenvolvimento de Software, de Mauro de Mesquita Spinola e Marcelo
Schneck de Paula Pessôa: neste livro, aborda-se a gestão da qualidade. No Capítulo 7, os autores
apresentam uma visão geral sobre qualidade e planejamento, controle, melhoria e garantia da
qualidade de software.
https://www.google.com.br/books/edition/Gest%C3%A3o_da_qualidade_no_desenvolvimento/PBmsDwAAQBAJ?hl=pt-BR&gbpv=1&dq=inauthor:%22Marcelo+Schneck+de+Paula+Pess%C3%B4a%22&printsec=frontcover
Disciplina
Gerenciamento e Qualidade de
Software
 
Referências
BARTIÉ, A. Garantia da Qualidade de Software. 5. ed. Rio de Janeiro: Elsevier, 2002.
BOEHM, B.; BASILI, V. R. Software Defect Reduction Top 10 List. IEEE Computer, v. 34, n. 1, 2001.
MCCALL, J.; RICHARDS, P.; WALTERS, G. Factors in Software Quality. Volume 1. Concepts and
De�nitions of Software Quality. New York: Rome Air Development Center, 1977.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem pro�ssional. 9. ed.
Porto Alegre: AMGM, 2021.
Aula 4
Introdução ao gerenciamento de projetos para qualidade de software
Introdução
Disciplina
Gerenciamento e Qualidade de
Software
Olá, estudante!
Ao longo desta unidade, exploramos a importância da gestão e garantia da qualidade. Nossos
estudos nos conduziram por uma jornada de compreensão das estratégias fundamentais de
implementação e implantação da qualidade no desenvolvimentode software, que vão desde a
identi�cação e mitigação de riscos até o estabelecimento de padrões de excelência.
Nesta aula, mergulharemos nas metodologias de gerenciamento de projetos, como as
metodologias ágeis, que permitem maior �exibilidade acerca de mudanças, e�ciência na entrega
e colaboração da equipe de desenvolvimento. Também, veremos sobre o planejamento e as
estimativas de projetos, sobre os quais o alicerce é construído; a execução dinâmica, na qual as
ideias ganham vida, e o monitoramento e controle dos projetos, garantindo resultados bem-
sucedidos.
Vamos lá?
Metodologia ágil para gerenciamento de projetos
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, modelos de processos têm por objetivo organizar e estruturar o desenvolvimento do
produto. Cada modelo, dentre os diversos disponíveis, é distinto em seu �uxo de procedimento,
delineando a maneira pela qual as atividades metodológicas, as ações e as tarefas são
estruturadas, de forma sequencial e cronológica. Esses padrões são cruciais para a resolução
dos desa�os que são identi�cados ao longo do processo de desenvolvimento de software.
Em 2001, dezessete pessoas se reuniram para discutir sobre o futuro do desenvolvimento de
software, compartilhando suas frustrações pelo enfoque das empresas em planejamento e
documentação do ciclo de desenvolvimento. Porém, as empresas esqueceram-se de fatores
importantes, então eis que surge o manifesto ágil, como podemos ver na Figura 1.
Disciplina
Gerenciamento e Qualidade de
Software
Figura 1 | Manifesto para desenvolvimento ágil de software. Fonte: Agile Manisfesto.
Mas, o que é agilidade? A agilidade abrange a rápida resposta às mudanças. Todavia, não é
somente isso. A agilidade integra as propostas do manifesto ágil, incentivando uma
comunicação mais fácil entre os membros da equipe (tanto pessoas técnicas quanto não
técnicas); enfatiza a entrega do software que realmente funcione e atenda às necessidades do
cliente; destaca a importância de trabalhar perto dos clientes para compreender suas
necessidades em evolução; reconhece que mudanças são inevitáveis e que a capacidade de se
adaptar rapidamente a elas é crucial para o sucesso do projeto.
Na metodologia ágil, temos os seguintes métodos mais utilizados no mercado, que são: Scrum e
Kanban.
Scrum: é baseado em sprints, ou seja, ciclos de produção de um projeto, com foco na
colaboração, �exibilidade e entrega contínua de valor aos clientes.
No processo do Scrum, vide Figura 2, temos o product owner, que prioriza os requisitos que
serão implementados para a próxima sprint. No planejamento, o time realiza a estimativa das
histórias priorizadas e de�ne qual será o objetivo da sprint e como será atendida, criando o sprint
backlog, que são as atividades que serão desenvolvidas até o �nal da sprint. Após isso, inicia-se
a sprint.
Sobre a duração da sprint, ocorre de duas a quatro semanas, e o time realiza o desenvolvimento
da funcionalidade. Também, temos o scrum master, que ajuda todos do time e implementa
valores, princípios e práticas do Scrum, sendo responsável por conduzir a daily. Daily é uma única
Disciplina
Gerenciamento e Qualidade de
Software
reunião diária feita para veri�car o andamento da sprint e possíveis impedimentos; caso haja
impeditivos, o scrum master é responsável por remover obstáculos.
Após a �nalização da sprint, o scrum master conduz a retrospectiva, que é uma reunião em que o
time analisa a sprint, pontuando pontos positivos e negativos e realizando questionamentos
sobre como pode melhorar; no �nal da retrospectiva, levanta alguns planos de ações para
melhoria contínua. Em paralelo com a retrospectiva, ocorre a revisão, na qual o time demonstra o
que foi desenvolvido para o product owner.
Sprint �nalizada, repete-se todo o processo a partir da reunião de planejamento.
Figura 2 | Processo do Scrum. Fonte: elaborada pela autora.
Kanban: é um quadro visual que ajuda a visualizar as demandas do time. O quadro é
dividido em colunas que representam as etapas do desenvolvimento. As etapas mais
utilizadas pelas empresas são: A fazer, em desenvolvimento e �nalizado. Claro que se pode
acrescentar mais colunas, pois a metodologia é adaptável para cada projeto. Na Figura 3, é
exibido um quadro Kanban dividido em quatro etapas, que são: A Fazer, em
desenvolvimento, em testes e
Disciplina
Gerenciamento e Qualidade de
Software
 
Figura 3 | Exemplo de quadro Kanban. Fonte: elaborada pela autora. Fonte: elaborada pela autora.
Uma das principais funções do Kanban é garantir um número máximo de itens nas colunas de
trabalho Em Andamento, limitando-o, a �m de garantir que todos tenham trabalho a fazer, mas
que ninguém esteja fazendo múltiplas tarefas. Isso quer dizer que, se foi de�nido que o limite
para um do time será quatro itens “Em Desenvolvimento”, ao ultrapassar este limite, �cará
evidente no quadro. Com isso, o foco se torna terminar os itens em andamento antes de puxar
algo novo para desenvolver.
Aluno, você pode concluir que as metodologias ágeis priorizam a colaboração no projeto, a
�exibilidade e a entrega incremental, sendo adaptáveis e e�cientes, impulsionando resultados
excepcionais no ambiente organizacional de constante mudança.
Planejamento e estimativa de projetos
Disciplina
Gerenciamento e Qualidade de
Software
As metodologias ágeis são abordagens iterativas que enfatizam a �exibilidade, a colaboração e a
entrega incremental de software. Cada iteração é um ciclo curto de desenvolvimento, durante o
qual uma parte funcional do software é planejada, desenvolvida, testada e entregue. Isso permite
que o software seja entregue em partes funcionais ao longo do tempo, em vez de esperar até que
o produto todo esteja concluído.
Entenderemos sobre o processo de planejamento e estimativa, bem como técnicas de estimativa
e o quanto podemos planejar para as próximas iterações.
Sommerville (2011) cita que, nas metodologias ágeis, há uma abordagem de planejamento em
dois estágios, sendo eles:
Disciplina
Gerenciamento e Qualidade de
Software
Planejamento de release: o objetivo principal deste estágio é de�nir uma visão de longo
prazo para o produto e determinar quais funcionalidades serão incluídas no release.
Planejamento de iteração: processo mais curto e detalhado que ocorre no início de cada
iteração, também conhecida como sprint. O planejamento de iteração é estabelecido no
backlog pelo product owner, que seleciona as histórias de usuário para serem
implementadas durante a sprint.
De acordo com a Figura 4, no início do projeto, a equipe e o cliente colaboram para identi�car as
histórias representadas por funcionalidades planejadas. O planejamento de release implica a
seleção e o re�namento das histórias de forma contínua. O planejamento de iteração envolve a
escolha das histórias para a sprint.
Na reunião de planejamento de iteração, o time realiza a quebra de histórias em tarefas,
transformando-as em pequenas atividades que são necessárias para o desenvolvimento da
funcionalidade. Por �m, cada tarefa é estimada pelo time. Essas estimativas são utilizadas para
calcular o esforço e o tempo em desenvolver as demandas da iteração por completo.
Figura 4 | Planejamento ágil. Fonte: adaptada de Sommerville (2011, p. 440).
As estimativas são calculadas da seguinte forma: as histórias são avaliadas em termos de
esforço e são atribuídos pontos de esforço, que podem variar conforme o grau de complexidade.
Algumas formas para estimar são:
Disciplina
Gerenciamento e Qualidade de
Software
Por hora: o time estima de acordo com o esforço previsto em horas de trabalho.
Story Point (pontos de história): cada história é atribuída a um número de pontos. Esses
pontos não têm um valor absoluto, mas são usados para comparar histórias entre si de
acordo com a complexidade. Exemplo: por tamanho (PP, P, M, G).
Essas formas de estimativas podem utilizar algumas técnicas, que são:
Estimativa baseada em histórico: o time usa referências históricas para estimar o esforço
em novas tarefas, ajudando a criarestimativas mais precisas e realistas.
Planning Poker: os membros da equipe discutem as histórias, fazem perguntas para
esclarecimentos e, depois, selecionam uma estimativa relativa (story point) de forma
simultânea, usando cartas com números.
Aluno, o planejamento de release ou iteração estabelece um roteiro claro para o projeto. Já as
estimativas visam prever o esforço necessário para concluir as demandas.
 
Execução, monitoramento e controle de projetos
Durante esta aula, exploramos as metodologias ágeis e vimos sobre planejamento e estimativa.
Agora, entenderemos o que é a fase de execução de um projeto e como podemos monitorar e
Disciplina
Gerenciamento e Qualidade de
Software
controlar seu andamento. Essas atividades trabalham em conjunto para garantir que os objetivos
do projeto sejam alcançados dentro do escopo de�nido, por cronograma e orçamento.
Depois da fase de levantamento de requisitos, análise e modelagem, vem a etapa da execução.
Essa fase é o momento em que o planejamento cuidadosamente elaborado começa a se
concretizar. As atividades e tarefas delineadas em reuniões de planejamento são postas em ação
pela equipe de desenvolvimento. A comunicação clara e e�caz se torna uma ferramenta vital
nesta fase, permitindo que todos os membros da equipe entendam suas responsabilidades, além
de facilitar a resolução rápida de problemas que possam surgir.
Entretanto, o progresso do projeto não pode ser considerado garantido somente pela execução
das atividades. A fase de monitoramento entra em cena para avaliar continuamente o progresso
do projeto com relação ao plano original. Dados reais são coletados e comparados aos dados
planejados, identi�cando desvios que possam surgir. Isso possibilita uma visão em tempo real
do estado do projeto, permitindo que a equipe identi�que atrasos, excessos de custos ou
problemas de qualidade antes que se tornem incontroláveis.
Utilizando, por exemplo, o Scrum, é possível monitorar o andamento do projeto pelo grá�co de
burndown, conforme a Figura 5. O grá�co representa visualmente o esforço em relação ao tempo
necessário para concluir a sprint e permite decisões mais assertivas e realistas, desde que os
dados estejam corretamente atualizados.
A precisão do grá�co facilita a comunicação com as partes interessadas para que todos saibam
o que esperar.
Conforme a Figura 5, o grá�co de burndown é construído por dois eixos, que representam:
Esforço: a quantidade de trabalho restante.
Tempo: os dias do começo até o �nal da sprint (ou projeto).
Atravessando os eixos, temos duas linhas:
Planejado: o trabalho ideal. Mostra o quanto precisa ser feito a cada dia para atingir a meta
do cronograma.
Real: o trabalho real. Mostra o ritmo de avanço que está sendo realizado pela equipe.
 
Disciplina
Gerenciamento e Qualidade de
Software
Figura 5 | Grá�co de burndown. Fonte: elaborada pela autora.
Com base nas informações coletadas durante o monitoramento, a equipe pode tomar decisões
para realinhar o projeto aos seus objetivos. Isso pode envolver readequação do cronograma,
realocação das pessoas, revisão das atividades ou até mesmo ajustes no escopo do projeto. O
controle não apenas garante que os desvios sejam tratados, mas também oferece uma
oportunidade de aprendizagem valiosa para as próximas sprints.
O monitoramento e o controle são processos iterativos, ocorrendo ao longo de toda a execução
do projeto. Isso ajuda a equipe a adaptar-se às mudanças que podem ocorrer durante o
andamento do desenvolvimento. A agilidade e a capacidade em responder aos ajustes conforme
necessário, sem comprometer o resultado.
Aluno, a execução, o monitoramento e o controle de projetos são vitais para ajudar o
gerenciamento do projeto a ser bem-sucedido. Cada fase desempenha um papel crítico para
garantir que o produto seja entregue dentro das expectativas, ajustando o percurso conforme
necessário e mitigando os riscos que possam surgir, fornecendo resultados de alta qualidade.
 
Videoaula: Introdução ao gerenciamento de projetos para qualidade de
software
Disciplina
Gerenciamento e Qualidade de
Software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante!
Durante esta aula, você entendeu sobre metodologia ágil, planejamento, estimativa, execução,
monitoramento e controle de projetos. Neste vídeo, consolidaremos os conceitos sobre
metodologia ágil, veri�cando suas vantagens, e entenderemos um pouco mais os papéis e as
atividades do Scrum.
Saiba mais
Para aprofundar seu conhecimento sobre metodologias de desenvolvimento de software,
indicamos o livro a seguir:
Métodos ágeis e melhoria de processos, de Marcelo Bellon Ferreira: neste livro, abordam-se a
gestão e o gerenciamento de projetos, bem como padrões e metodologias de desenvolvimento.
O autor menciona metodologias tradicionais de desenvolvimento e foca em metodologias ágeis,
https://plataforma.bvirtual.com.br/Acervo/Publicacao/183493
Disciplina
Gerenciamento e Qualidade de
Software
apresentando uma análise do manifesto ágil, mapeamento e melhoria de processos, trazendo a
importância da padronização e métricas.
 
Referências
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
Aula 5
Revisão da unidade
Gerenciamento e qualidade de software
Disciplina
Gerenciamento e Qualidade de
Software
Olá, aluno!
Ao longo desta unidade, embarcamos em uma jornada de descoberta no amplo campo do
gerenciamento e qualidade de software. O gerenciamento e�caz e a qualidade sólida de software
não apenas impactam o sucesso de projetos individuais, mas também in�uenciam diretamente
na reputação de uma empresa, na satisfação do cliente e na longevidade do software no
mercado competitivo.
Na primeira aula, vimos que o gerenciamento de software abrange uma série de atividades e
processos que são essenciais para o sucesso de um software que vão desde a idealização do
produto, no planejamento estratégico, passando pelo design e arquitetura, importantes para a
fase de desenvolvimento e testes, até, por �m, chegar à fase de implementação e manutenção.
No entanto, encaramos desa�os no gerenciamento devido às restrições nos orçamentos e
prazos. Quanto ao software, enfrentamos a particularidade de sua natureza intangível, o que
di�culta avaliar seu progresso. Além disso, os processos de software variam entre organizações,
e os projetos, geralmente, são únicos, limitando a transferência de lições aprendidas. No
contexto do gerenciamento de software e�ciente, é importante concentrar-se nos 4 Ps: pessoas,
produtos, processo e projeto.
Na segunda aula, pudemos entender sobre o real signi�cado da qualidade de software.
Analisamos tanto a qualidade do projeto, ligada à aderência aos requisitos especi�cados, quanto
a qualidade de conformidade, centrada na implementação do produto. Métricas emergiram como
aliadas valiosas na mensuração da qualidade, direcionando as ações de melhoria contínua. A
garantia da qualidade, por sua vez, compreende um conjunto de processos, técnicas e práticas,
destinadas a garantir que produtos e serviços alcancem os padrões e requisitos estabelecidos,
como: estabelecer um processo especí�co; controlar todas as alterações realizadas durante o
desenvolvimento do software; revisões técnicas e testes para identi�cação de defeitos; métodos
Disciplina
Gerenciamento e Qualidade de
Software
e ferramentas para guiar e auxiliar o processo de desenvolvimento; avaliar a e�cácia dos
processos de�nidos, a �m de garantir que os padrões estabelecidos estão em conformidade.
Na terceira aula, conhecemos os fatores que in�uenciam na qualidade de um software. Desde a
manutenibilidade até a e�ciência, esses elementos contribuem para a construção de softwares
con�áveis, e�cientes e adaptáveis. Reconhecemos que a qualidade permeia todo o ciclo de
desenvolvimento e prevenindo retrabalhos, reduzindo custos extras e problemas signi�cativosno
produto. O dilema da qualidade nos mostrou que um software “bom o su�ciente” é o resultado de
um equilíbrio entre o objetivo do produto, as oportunidades do mercado e atender às
necessidades do usuário.
Por �m, na quarta aula, aprofundamos a metodologia ágil, que é uma abordagem �exível de
desenvolvimento que prioriza a colaboração, a adaptação contínua e a entrega incremental de
software, permitindo respostas rápidas às mudanças e focando nas necessidades do cliente. Na
metodologia ágil, temos vários frameworks, como Scrum e Kanban. Esses frameworks são as
estruturas de trabalho que fornecem diretrizes e práticas especí�cas para sua implementação,
impulsionando resultados excepcionais no ambiente organizacional em constante mudança.
Ao encerrar esta unidade, podemos reconhecer que o gerenciamento e�caz, a busca incessante
pela qualidade e a adoção de metodologias ágeis são vitais para ajudar o sucesso de um
software. Juntos, esses elementos não só otimizam a e�ciência operacional, mas também
garantem a entrega de resultados que atendam às expectativas dos clientes e superem os
desa�os tecnológicos.
Videoaula: Revisão da unidade
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante!
Nesta unidade, aprendemos sobre o gerenciamento e qualidade de software, entendendo sobre
as métricas, os elementos para a garantia da qualidade, os fatores da qualidade, a metodologia
ágil e muito mais. Neste vídeo, reveremos os principais tópicos trabalhados nesta unidade,
revisitando os conceitos aprendidos, oferecendo uma visão geral dos temas abordados.
Estudo de caso
Disciplina
Gerenciamento e Qualidade de
Software
A TechSol (soluções tecnológicas) é uma empresa de médio porte de desenvolvimento de
software que se destaca por sua abordagem ágil, especialmente por adotar o Scrum como parte
fundamental de seus processos. Com um compromisso inabalável com a qualidade, a e�ciência
e a satisfação do cliente, a TechSol utiliza o Scrum para entregar soluções tecnológicas
inovadoras de maneira colaborativa e iterativa.
Num cenário altamente competitivo da indústria de desenvolvimento de software, a visão da
TechSol é ser reconhecida como uma referência em excelência em desenvolvimento de software,
proporcionando soluções que impulsionam a transformação digital das empresas. Sua missão é
fornecer produtos e serviços de alta qualidade, impulsionados pela inovação e pelo
compromisso com seus clientes.
Em um dos clientes mais importantes da TechSol, ocorreu uma expansão signi�cativa em seu
contrato, resultando em um aumento de 30% de sua capacidade, sendo positivo para a empresa,
pois possibilitou a formação de um novo time composto por dez membros, incluindo
desenvolvedores, um Scrum Master e um Product Owner em fase de transição de carreira, sendo
sua primeira experiência nesta função especí�ca.
Nas primeiras sprints, esperou-se um tempo de adaptação pelos novos contratados. Passados
alguns meses, os desenvolvedores e o Scrum Master estavam mostrando todo seu
conhecimento, mas durante aquela iteração todas as histórias da sprint anterior não foram
entregues, sendo arrastadas para a nova sprint.
Neste cenário, o gerente observou que a falta de conhecimento do Product Owner sobre o
produto e no processo do Scrum estava levando a de�nições inadequadas dos requisitos.
Durante o planejamento da sprint, o Product Owner lutava para explicar claramente o que era
necessário, resultando em confusão e ambiguidade para a equipe de desenvolvimento. Isso
levava a estimativas incorretas e, consequentemente, a bloqueios frequentes durante as sprints.
Disciplina
Gerenciamento e Qualidade de
Software
A inexperiência do Product Owner re�etia-se diretamente nos bloqueios durante o
desenvolvimento. O time de desenvolvimento, muitas vezes, se via paralisada, incapaz de
progredir devido à falta de informações ou aos requisitos con�itantes apresentados pelo Product
Owner. Tarefas eram iniciadas, mas �cavam incompletas, prejudicando o andamento geral da
sprint. Além disso, o time enfrentava di�culdades em ajustar suas atividades conforme os
requisitos mudavam frequentemente.
Os bloqueios persistentes nas sprints tiveram várias consequências negativas. O time de
desenvolvimento enfrentava frustração devido à incapacidade de cumprir suas
responsabilidades e de alcançar os objetivos da sprint. A inexperiência do Product Owner
também minou a con�ança do time no processo Scrum, resultando em incertezas sobre a
e�cácia da metodologia. Além disso, os atrasos na entrega das funcionalidades afetaram a
relação com o cliente e sua satisfação.
Após analisar estes pontos, o gerente teve algumas ideias para melhorar este cenário. Imagine
que você é o gerente e mapeie as possíveis soluções
______
Re�ita
Olá, estudante!
O estudo de caso ressalta a importância do Product Owner na metodologia ágil, impactando o
êxito das entregas. O Product Owner é o elo entre a equipe de desenvolvimento e as partes
interessadas, sendo essencial para traduzir as necessidades dos clientes em histórias de usuário
claras e priorizar o backlog.
Contudo, o estudo também evidencia as implicações negativas quando o Product Owner tem
di�culdades em exercer a função, resultando em mal-entendidos, retrabalho, demora nas
entregas e um software que não atende às expectativas. Sem a colaboração entre o time de
desenvolvimento e o Product Owner, temos a impossibilidade de exercer a comunicação
contínua, visando à troca de conhecimento para alinhar o desenvolvimento pelas expectativas
dos clientes e a um impacto direto na motivação da equipe.
No gerenciamento, entre os 4 Ps, podemos encontrar “Pessoas”. Gerenciar pessoas é uma base
essencial no sucesso de projetos. Já a qualidade preza por requisitos claros e que sejam
atendidos. A metodologia ágil, por sua vez, prioriza a colaboração, a comunicação e o
compartilhamento de conhecimento.
Antes de ser tomada uma iniciativa de demissão, deve-se observar como gerir as pessoas com
cuidado e consideração, reconhecendo que elas são um ativo valioso para o projeto e para a
organização como um todo.
Videoaula: Resolução do estudo de caso
Este conteúdo é um vídeo!
Disciplina
Gerenciamento e Qualidade de
Software
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
O estudo de caso apresentado traz à tona uma situação complexa em que a empresa se
encontra diante da possibilidade de demissões como resposta a desa�os identi�cados. No
entanto, antes de tomar uma decisão tão drástica, é crucial considerar uma solução holística e
abrangente que leve em conta os princípios fundamentais para gerenciar pessoas: a qualidade
do software e a metodologia ágil.
Nos 4 Ps, dentro do âmbito “Pessoas”, Pressman e Maxim (2021) dizem que é importante investir
no desenvolvimento pro�ssional da equipe, encorajando a colaboração entre todos. A
metodologia ágil reconhece a importância central das pessoas, valorizando a colaboração, a
comunicação e o desenvolvimento individual dos membros, incentivando o aprendizado contínuo
e o crescimento pessoal e pro�ssional.
Em relação ao estudo de caso, o Product Owner, pela inexperiência no cargo, cometeu uma
sequência de erros que �zeram com que o produto perdesse sua qualidade e seu time �casse
desmotivado. De acordo com a metodologia ágil, os erros devem ser tratados como
aprendizados, para não serem repetidos no futuro. Também, neste caso, deve-se criar uma
cultura de colaboração e compartilhar conhecimento, em que o Scrum Master e o time de
desenvolvimento podem ajudar o Product Owner em sua capacitação.
Neste caso, uma sugestão é criar uma reunião frequente entre o Product Owner e o Scrum
Master para discutir sobre as histórias da próxima sprint, com o intuito de não apenas assegurar
que ambos compartilhemuma compreensão comum das necessidades, mas também
proporcionar uma oportunidade para questionamentos e esclarecimentos que podem evitar mal-
entendidos futuros.
Além disso, pode-se criar uma forma visual para rastrear os bloqueios e as pendências para
manter o Product Owner informado sobre as questões que precisam ser resolvidas. Isso garante
a transparência e ajuda a evitar surpresas de última hora. Ainda, trabalham em conjunto para
criar um padrão de escrita de histórias, estabelecendo diretrizes claras que facilitam a
compreensão por parte da equipe de desenvolvimento.
Pode-se criar um checklist para determinar se uma história está pronta para entrar no sprint. Isso
estabelece critérios claros que garantem que as histórias sejam bem de�nidas e completas
antes do desenvolvimento. Incluir critérios, como a presença de critérios de aceite e a resolução
de bloqueios, destaca a importância da preparação adequada.
No geral, a abordagem colaborativa representa um passo signi�cativo em direção a um processo
ágil mais e�ciente e e�caz. Ao promover a clareza, a comunicação e a padronização, o time pode
trabalhar de maneira mais harmoniosa e focada, resultando em entregas de maior qualidade e
maior satisfação das partes interessadas. Isso re�ete a essência da metodologia ágil, que
prioriza a colaboração e a melhoria contínua para alcançar resultados excepcionais.
Resumo visual
Disciplina
Gerenciamento e Qualidade de
Software
Infográ�co | Gestão e qualidade de software. Fonte: Elaborado pelo autor.
Referências
Disciplina
Gerenciamento e Qualidade de
Software
FERREIRA, M. B. Métodos ágeis e melhoria de processos. São Paulo: Contentus, 2020.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem pro�ssional. 9. ed.
Porto Alegre: AMGM, 2021.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
,
Unidade 2
Introdução de testes de software
Aula 1
Conceito de métricas de teste de software
Introdução
Disciplina
Gerenciamento e Qualidade de
Software
Olá, estudante!  
O desenvolvimento de software desempenha um papel cada vez mais importante na era digital,
impactando quase todos os aspectos de nossas vidas. À medida que a tecnologia avança,
surgem desa�os na criação, na manutenção e de qualidade em sistemas complexos. 
Nessa busca por qualidade, as métricas de teste de software surgem como guias indispensáveis,
revelando percepções sobre e�cácia, con�abilidade, segurança e usabilidade. Nesta aula,
veremos os conceitos de erros, falhas e defeitos, entendendo como cada detalhe in�uencia a
qualidade. 
Além disso, abordaremos o conceito das revisões de software, compreendendo como as
métricas podem otimizar esse processo crítico. Esta aula é um ponto de partida essencial para o
entendimento das métricas de teste de software e das ferramentas que nos permitem quanti�car
e melhorar a qualidade do que construímos. 
Explorando a qualidade e as métricas de revisão de software
Disciplina
Gerenciamento e Qualidade de
Software
Aluno, durante o trajeto em desenvolver softwares, perceberemos que erros são resultados
inevitáveis de ações humanas. Quando um erro se manifesta como um comportamento incorreto
do software, isso é chamado de falha. A falha é o sintoma visível, mas por trás dela está o
defeito, uma imperfeição no código que causa a falha. Compreender essa relação é essencial,
pois ajuda a identi�car, corrigir e evitar defeitos, melhorando a qualidade do software.
Erro de software: no contexto do desenvolvimento de software, um erro refere-se a uma
ação humana que produz um resultado incorreto ou inesperado. Erros são inerentes à
natureza humana e podem ocorrer em qualquer fase do desenvolvimento. São o resultado
de decisões equivocadas, interpretações errôneas ou lapsos na implementação.
Defeito de software: um defeito é a raiz das falhas e ocorre quando há uma imperfeição no
código-fonte do software. É a relação entre os erros de desenvolvimento e as falhas vistas
pelo usuário. Defeitos podem surgir devido a equívocos na codi�cação. Identi�car e corrigir
defeitos é essencial para aprimorar a qualidade do software.
Falha de software: uma falha ocorre quando um componente de software não executa a
função esperada. É a diferença entre o observado e o esperado. Ela é a consequência
visível de um erro, ou seja, que não se manifesta claramente e pode ser percebida pelo
usuário �nal como um comportamento incorreto do sistema. As falhas são resultadas
tangíveis da presença de defeitos no software e podem variar em gravidade, de pequenos
incômodos a problemas críticos.
Disciplina
Gerenciamento e Qualidade de
Software
A busca pela qualidade do software nos leva ao reino das métricas de revisão. Segundo Hetzel
(1987), testes são fundamentais para o controle de um projeto, portanto, uma vez que
considerado uma fase importantíssima do processo de desenvolvimento de software, surge a
necessidade de identi�car maneiras de controlá-los de forma e�ciente.
Métricas de software são medidas quantitativas utilizadas para avaliar características do
desenvolvimento de software, permitindo análises objetivas e tomadas de decisão informadas
(Pressman; Maxim, 2014).
Algumas das métricas mais importantes incluem:
Taxa de cobertura de testes: percentual dos testes conhecidos que foram concluídos.
Taxa de detecção de defeitos: mede a e�cácia da revisão ao calcular a proporção de
defeitos encontrados em relação ao número total de defeitos presentes.
Tempo médio para resolver defeitos: avalia a e�ciência da equipe em resolver os defeitos
encontrados durante as revisões.
Taxa de falsos positivos e falsos negativos: avalia a precisão das revisões, identi�cando a
proporção de defeitos erroneamente identi�cados como verdadeiros (falsos positivos) e
defeitos reais que não foram detectados (falsos negativos).
Densidade de defeitos encontrados: quanti�ca o número de defeitos encontrados em
relação ao tamanho do artefato revisado.
Tempo médio por revisão: mede o tempo médio gasto em cada revisão.
Essas são apenas algumas das mais variadas métricas que existem atualmente nos processos
de revisão de software. No entanto, a e�cácia das métricas de revisão depende em grande parte
dos registros dessas revisões. Os registros de revisões referem-se à documentação detalhada e
organizada das atividades relacionadas às revisões. Durante esses processos formais, o
software é avaliado, buscando identi�car defeitos, sugerir melhorias e veri�car a conformidade
com os requisitos de�nidos.
Caro aluno, perante todos os conceitos apresentados anteriormente, podemos compreender o
quão importantes são as métricas e revisões para um bom desenvolvimento de software com
qualidade, visto a propensão do ser humano em cometer erros.
Métricas e revisões e�cientes
Disciplina
Gerenciamento e Qualidade de
Software
Já sabemos que o processo de desenvolvimento de software não segue uma linha de produção
limpa e fácil. Quando estamos construindo software, em meio a todas as coisas que fazemos, é
bem provável que algumas falhas aconteçam. Dessa forma, é preciso compreender como as
métricas e revisões registradas são responsáveis por garantir o sucesso durante as fases de
construção do software.
Ao fazer parte da equipe de testes em uma organização, o pro�ssional, com certeza, se deparará
com os seguintes questionamentos:
“Qual o tempo necessário para �nalizar o ciclo de testes?”.
“Qual o grau de estabilidade da funcionalidade que está sendo testada?”.
“Quantos testes serão necessários para o escopo que você está testando?”.
“Quanto já foi testado?”.
A lista de questionamentos é extensa, mas faz parte da rotina da equipe de testes. É importante
frisar que responder a esses questionamentos nem sempre é confortável para o testador. 
Existem alguns motivos:
A equipe de testes não está preparada para apresentar os dados solicitados.
A equipe de testes possui dados inadequados.
Disciplina
Gerenciamento e Qualidade de
Software
A equipe de testes não estava ciente da necessidade de levantar e registrar essas métricas.Quando não há dados registrados, geralmente um pro�ssional de testes é destacado para deixar
sua atividade e realizar a coleta dos dados e tratá-los de uma forma apresentável. Este desa�o
poderá levar muito tempo para ser �nalizado e custará o precioso tempo da equipe de testes;
isso se deve, principalmente, à falta de planejamento.
Um programa de métricas é um conjunto de passos que incluem planejar, medir, analisar os
dados, tomar decisões e implementar essas decisões.
É importante dizer que as métricas possuem algumas características que agreguem valor ao seu
uso, tais como a facilidade de ser calculada e compreendida sem ambiguidade. A métrica possui
uma capacidade de análise estatística que possibilita identi�car tendências, distribuições e
relações entre os dados.
As métricas podem ser divididas entre diretas, indiretas, orientadas a tamanho, orientadas por
função, produtividade, qualidade e técnicas (Garcia, 2015).  
Métricas diretas: chamadas também de fundamentais ou básicas, são medidas
quantitativas obtidas por meio da avaliação de atributos observáveis, tipicamente
determinada por processos de quanti�cação (exemplos: custo de projeto, tempo de
desenvolvimento e quantidade de defeitos encontrados).
Métricas indiretas: chamadas também de derivadas, são obtidas por meio da análise e
combinação de outras métricas previamente coletadas (exemplos: complexidade,
e�ciência, con�abilidade, facilidade de manutenção).
Métricas orientadas a tamanho: são indicadores diretos que mensuram as dimensões dos
artefatos de software relacionados ao processo pelo qual o software foi desenvolvido
(exemplos: esforço, custo).
Métricas orientadas por função: representam um conjunto de técnicas para mensurar o
software sob a perspectiva do usuário, estabelecendo uma visão sob a complexidade do
sistema.
Métricas de produtividade: constituem um conjunto de indicadores voltados para avaliar a
produção resultante do processo de engenharia de software (exemplos: número de casos
de uso por iteração, número de linhas de código por dia, número de histórias de usuário
concluídas por sprint).
Métricas de qualidade: são um conjunto de indicadores utilizados para avaliar a
conformidade do software com os requisitos e padrões estabelecidos pelo cliente
(exemplos: taxa de defeitos e tempo médio de correção de defeitos).
Métricas técnicas: indicadores utilizados para avaliar as características intrínsecas do
software, concentrando-se nos aspectos técnicos e estruturais do código e das soluções
implementadas (exemplos: complexidade ciclomática, índice de manutenibilidade).
Essas métricas não apenas avaliam a qualidade do processo de revisão, mas também auxiliam
na identi�cação de áreas de melhoria, como veremos a seguir.
Métricas de software na prática
Disciplina
Gerenciamento e Qualidade de
Software
Agora que entendemos a importância das métricas de software e sua in�uência na qualidade do
processo de desenvolvimento, é hora de nos aprofundarmos na aplicação dessas métricas.
Nosso objetivo é entender como essas métricas são capazes de otimizar processos e resultados
no âmbito do processo de desenvolvimento de software.
Sabemos que o levantamento de métricas é a melhor maneira de veri�car quando um processo
está sob controle e se seus objetivos são capazes de serem atingidos, principalmente se
levarmos em consideração projetos grandes e complexos. Dessa forma, somos capazes de
perceber que, para uma boa utilização das métricas de revisão de software, faz-se necessário um
planejamento estratégico sólido.
Conforme Pressman e Maxim (2014), devemos selecionar cuidadosamente as métricas que se
ajustam apropriadamente ao contexto do projeto. Cada software tem suas particularidades,
portanto, é crucial que a escolha das métricas seja      a mais      assertiva possível (Hetzel, 1987),
selecionando métricas relevantes para o sucesso do projeto.
Selecionadas as métricas, o passo seguinte é a de�nição dos objetivos tangíveis e quantitativos,
os quais servirão como pontos de referência para avaliar o progresso e o desempenho ao longo
do projeto.  Por exemplo, ao utilizar a taxa de cobertura de testes como métrica, é possível de�nir
uma meta especí�ca, como alcançar 90% de cobertura até o �nal de uma fase de
desenvolvimento pré-determinada.
O desenvolvimento de um plano detalhado para coleta e análise de dados é de extrema
importância. Essa etapa envolve determinar como, quando e por quem as métricas serão
Disciplina
Gerenciamento e Qualidade de
Software
coletadas. Para garantir a con�abilidade dos dados, a criação de um processo claro e bem
documentado é fundamental.
A seguir, realizamos a análise dos dados coletados. Essa análise deve ser realizada com
bastante atenção. É aqui que comparamos os resultados obtidos com os objetivos estipulados e
identi�camos tendências ou padrões. Se uma métrica não atingir o objetivo estabelecido,
devemos investigar as causas escondidas e implementar medidas corretivas apropriadas
(Pressman; Maxim, 2014). Por exemplo, se a taxa de detecção de defeitos estiver abaixo do
esperado, isso pode indicar que as revisões não estão sendo su�cientemente rigorosas.
Ao analisar periodicamente os resultados das métricas, podemos identi�car gargalos no
processo de desenvolvimento, reconhecer problemas recorrentes e introduzir melhorias graduais.
Caso observemos uma densidade de defeitos elevada em um módulo especí�co do software, por
exemplo, podemos optar por alocar mais recursos para revisões e testes nessa área, ou seja, as
métricas de revisão também podem desempenhar um papel fundamental na identi�cação de
áreas de melhoria contínua
A colaboração de toda a equipe de desenvolvimento é de extrema importância. Ao compartilhar
metas, métricas selecionadas e resultados obtidos, criamos um senso de responsabilidade
compartilhada pela qualidade do software. Essa abordagem colaborativa incentiva a contribuição
de cada membro da equipe na identi�cação de problemas e na proposição de soluções
(Pressman; Maxim, 2014), promovendo uma cultura de melhoria contínua.
Em síntese, a aplicação e�caz das métricas de revisão é um fator crucial para atingir um
software de qualidade. Ao selecionar métricas pertinentes, estabelecer objetivos claros, coletar e
analisar dados de maneira consistente e envolver toda a equipe, podemos aprimorar
continuamente nossos métodos de desenvolvimento, identi�car problemas precocemente e
entregar um produto de software mais con�ável e satisfatório aos usuários.
Videoaula: Conceito de métricas de teste de software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante!
Durante esta aula, você compreendeu os conceitos de erro, defeito e falha, além dos conceitos de
métricas de software e os motivos pelos quais eles são importantes. Neste vídeo,
consolidaremos esses conceitos de forma que as ideias sobre eles �quem mais claras.
Disciplina
Gerenciamento e Qualidade de
Software
Saiba mais
Para expandir seus conhecimentos sobre processos de software, bem como introduzir-se no
campo de testes de software, aconselhamos a leitura indicada a seguir, com o objetivo de
consolidar seus conhecimentos.
Processos de software, de Polyanna Fabris e Luis Perini: neste livro, os autores discorrem sobre
modelagem de processos, o que é fundamental para compreender a necessidade que se tem de
parâmetros das métricas e revisões de software. Informações sobre engenharia de requisitos e
gerenciamento de projetos também são apresentadas.
 
Referências
https://biblioteca-virtual.com/detalhes/ebook/608704eb54aa8872fc616ec6
Disciplina
Gerenciamento e Qualidade de
Software
GARCIA, L. F. Qualidade de Software. [S. l.]: [s. n.], 2015. Disponível em:
https://vdocuments.net/qualidade-de-software-aula-4-prof-dr-luis-fernando-garcia-
luisgarciaprobr-wwwgarciaprobr.html?page=12. Acesso em: 14 set. 2023.
HETZEL, W. Guia Completo ao Testede Software. Rio de Janeiro: Campus, 1987.
PRESSMAN, R.; MAXIM, B. Software Engineering: a practitioner’s approach. 8. ed. Boston:
McGraw-Hill, 2014.     
Aula 2
Introdução de teste de software
Introdução
https://vdocuments.net/qualidade-de-software-aula-4-prof-dr-luis-fernando-garcia-luisgarciaprobr-wwwgarciaprobr.html?page=12
https://vdocuments.net/qualidade-de-software-aula-4-prof-dr-luis-fernando-garcia-luisgarciaprobr-wwwgarciaprobr.html?page=12
Disciplina
Gerenciamento e Qualidade de
Software
Olá, estudante!
Já sabemos o quão importante é o desenvolvimento de software. Dessa forma, não é estranho
perceber que a qualidade é um fator crítico que permeia tudo aquilo dos quais somos
dependentes. Imagine depender de um sistema de comunicação, entretenimento ou transações
�nanceiras, e esse sistema não funcionar corretamente.
Com o intuito de atender às exigências de maior qualidade, desenvolvedores se motivaram a
criar métodos e técnicas para o software atingir padrões de qualidade exigidos. Tais exigências
não eram injusti�cadas, pois a humanidade entrou em um período em que a tecnologia afetou
signi�cativamente a vida coletiva. No que diz respeito à saúde, às �nanças, ao transporte, à
educação e à segurança, a menor falha pode ser responsável por uma catástrofe. 
É a partir desse tipo de cenário que os testes de software assumem um papel fundamental.
Nesta aula, abordaremos conceitos de qualidade e teste de software, objetivos de testar e os
principais tipos de teste.
Vamos lá?
Introdução ao teste de software
Disciplina
Gerenciamento e Qualidade de
Software
Quando a humanidade se deu conta de que o software estava integrado na maior parte da vida
cotidiana de pessoas, surgiu uma corrida pela maior qualidade de software. Qualidade não era
uma preocupação no início da era digital. Hoje, todos os desenvolvedores de software
concordam que software de alta qualidade é um objetivo importante.
De�nir qualidade de software não é uma tarefa fácil. Para Pressman e Maxim (2021), no sentido
mais geral, é uma gestão de qualidade para criar um produto útil que forneça valor mensurável
para aqueles que o produzem e para aqueles que o utilizam. Já para Sommerville (2011), a
qualidade do software é diretamente relacionada à qualidade do processo de desenvolvimento
de software. Mas, e qualidade? Segundo o dicionário, qualidade é a propriedade positiva de um
objeto ou um ser (Aulete, 2009).
A qualidade de software e os testes de software estão intrinsecamente relacionados, pois os
testes desempenham um papel fundamental na busca por qualidade no desenvolvimento de
software. Isso quer dizer que testar software é avaliar se ele está fazendo o que deveria fazer, de
acordo com os seus requisitos, e não está fazendo o que não deveria fazer (Moreira Filho; Rios,
2003).
Testar também pode ser um processo de executar um programa ou sistema com a intenção de
encontrar defeitos (teste negativo) (Myers, 1979).
Para Hetzel (1988), teste é qualquer atividade que a partir da avaliação de um atributo ou
capacidade de um programa ou sistema seja possível determinar se ele alcança os resultados
desejados. E para Pressman e Maxim (2021), é um conjunto de atividades que podem ser
planejadas com antecedência e executadas sistematicamente.
Todas essas de�nições realçam a seguinte ideia: teste de software é a veri�cação feita sobre um
sistema ou parte dele para garantir que uma determinada entrada produza sempre uma saída
esperada.
Disciplina
Gerenciamento e Qualidade de
Software
Dessa forma, compreendemos que, no âmbito do desenvolvimento de software, qualidade é
compreendida como um conjunto de condições que devem ser satisfeitas ou refere-se à medida
em que o software atende aos requisitos, sendo livre de defeitos, seguro, con�ável e que atenda
às necessidades do usuário.
Independentemente do projeto que se desenvolve, existem vários objetivos pelos quais devemos
testar software. O CTFL Syllabus (2023), em sua versão 4.0, destaca os seguintes:
Avaliar produtos de trabalho, como requisitos, histórias de usuários, projetos e código.
Detectar falhas e defeitos.
Garantir a cobertura necessária de um objeto de teste.
Reduzir o nível de risco de qualidade de software inadequado.
Veri�car se os requisitos especi�cados foram atendidos.
Veri�car se um objeto de teste está em conformidade com os requisitos contratuais, legais
e normativos.
Fornecer informações aos stakeholders para que possam tomar decisões informadas.
Criar con�ança na qualidade do objeto de teste.
Validar se o objeto de teste está completo e funciona conforme o esperado pelos
stakeholders.
Os objetivos dos testes podem variar, dependendo do contexto, o que inclui o produto de trabalho
que está sendo testado, o nível de teste, os riscos, o ciclo de vida de desenvolvimento de
software que está sendo seguido e os fatores relacionados ao contexto do negócio (CTFL
Syllabus, 2023).
Explorando os níveis de teste de software
Disciplina
Gerenciamento e Qualidade de
Software
Já sabemos os conceitos de qualidade e teste de software e compreendemos o quão importante
é garantir que o software atenda aos requisitos estabelecidos, sendo livre de defeitos e que
entregue valor aos seus desenvolvedores e usuários. Mas, quando falamos em teste de software,
imediatamente deve surgir a seguinte dúvida: quando testar?
Nesse ponto, estamos falando em níveis de teste, os quais são grupos de atividades de teste que
são organizadas e gerenciadas em conjunto. Cada nível de teste é uma instância do processo de
teste, realizado em relação ao software em um determinado estágio de desenvolvimento, desde
componentes individuais até sistemas completos (CTFL Syllabus, 2023).
Existem sete níveis de teste de software, que são realizados em momentos diferentes do ciclo de
vida do desenvolvimento de um software. Os níveis de teste são:
Teste de Unidade: veri�ca o funcionamento do menor componente do software, como sub-
rotinas, métodos e classes. É realizado pelo desenvolvedor e, geralmente, requer o uso de
estruturas de teste ou frameworks de teste de unidade.
Teste de Integração: veri�ca se a interação entre os componentes de um sistema é e�caz e
não causa con�itos. É realizado pelo desenvolvedor e envolve a integração entre um ou
mais componentes.
Teste de Sistema: veri�ca o sistema como um todo, analisando o comportamento geral e
seus recursos. É realizado por uma equipe de testes após a codi�cação completa do
sistema. É realizado para veri�car se o sistema atende aos requisitos de�nidos.
Teste de Aceitação: veri�ca o sistema como um todo, sob o ponto de vista do usuário �nal,
concentrando-se na validação dos requisitos. É realizado pelo usuário. O foco é veri�car se
o sistema está pronto para ser entregue e usado.
Disciplina
Gerenciamento e Qualidade de
Software
Teste Alfa: veri�ca o sistema de uma forma que não tenha sido planejada, sob o ponto de
vista de um seleto grupo de usuários internos. É realizado pelos usuários internos da
organização, podendo incluir testadores, desenvolvedores e outros funcionários.
Teste Beta: veri�ca o sistema de uma forma que não tenha sido planejada, sob o ponto de
vista de um grande número de usuários. É realizado por um subconjunto de usuários �nais
do sistema, que satisfaçam determinados critérios de�nidos pelo fornecedor do sistema.
Teste de Regressão: veri�ca o sistema após alterações, como correções de bugs ou
implementação de novas funcionalidades. É realizado pela equipe de testes.
Os níveis de teste são diferenciados pelos atributos que lhes convêm, para evitar que as
atividades de testes se repitam. O CTFL Syllabus (2023) destaca os seguintes:
Objeto de teste.
Objetivos do teste.
Base de teste.
Defeitos e falhas.
Abordagem e responsabilidades.
Cada um desses atributos ajuda a caracterizar e diferenciar os diferentes níveis de teste,
garantindo que cada fase de teste tenha um foco especí�co e contribua para a qualidade geral do
software. Compreender esses atributos permite que os pro�ssionais de teste planejem e
executem testesde maneira mais e�caz, atingindo os objetivos de�nidos em cada etapa do
processo de desenvolvimento de software.
Níveis de teste na prática
Disciplina
Gerenciamento e Qualidade de
Software
Agora que somos capazes de compreender a importância dos níveis de teste, no
desenvolvimento de aplicações, nosso objetivo é entender como esses níveis de testes são
executados em cada etapa do processo de desenvolvimento de software.
Os níveis de teste são agrupamentos de atividades de teste bem planejadas e executadas de
maneira organizada. Cada nível de teste representa uma fase do processo de teste. Cada nível de
teste contribui para a melhoria geral da qualidade do software, conforme de�nido pelo CTFL
Syllabus (2023).
Em um ciclo de vida de desenvolvimento, existem sete níveis distintos de teste de software, cada
um sendo executado em um momento especí�co. Segue-se a ordem:
Teste de Unidade: é a menor parte testável do sistema. Nesse nível, o foco está nas partes
mínimas do software, como funções e métodos, veri�cando se eles funcionam
individualmente. Veja a Figura 1, “Função soma”, escrita em python.
Disciplina
Gerenciamento e Qualidade de
Software
Figura 1 | Função soma. Fonte: elaborada pelo autor.
Nesse exemplo, o resultado da soma de 5 e 3 deve ser sempre 8. Este teste é muito importante
para garantir que o “alicerce” do sistema funcione conforme o esperado.
Teste de Integração: ocorre quando os componentes individuais do sistema são
combinados. Isso garante que a interação entre esses componentes não resulte em
con�itos. Este teste é uma atividade realizada pelos desenvolvedores, em que eles unem
um ou mais componentes para veri�car a integração. Veja os exemplos de integração a
seguir:
Figura 2 | Módulo formatador. Fonte: elaborada pelo autor.
Disciplina
Gerenciamento e Qualidade de
Software
Figura 3 | Módulo operações. Fonte: elaborada pelo autor.
Figura 4 | Módulo de integração. Fonte: elaborada pelo autor.
Nesses exemplos, o módulo de integração veri�ca se a função de formatação cria a saída
esperada com base no resultado da função de soma. Dessa forma, garantimos que as partes do
software interajam sem problemas, como aconteceria em uso real.
Teste de Sistema: por sua vez, avalia o sistema completo, analisando seu comportamento
geral e recursos. Uma equipe de testes executa esse nível após a codi�cação completa do
sistema. O objetivo é garantir que o sistema atenda aos requisitos de�nidos, funcionando
como uma unidade coesa.
Sobre a perspectiva do usuário �nal, temos o Teste de Aceitação. Nesse nível, os requisitos são
validados em relação à expectativa do usuário. O teste também é executado a nível de sistema e
pelo próprio usuário �nal. Ele determina se o sistema está válido, ou seja, pronto para uso.
Os testes Alfa e Beta são voltados para avaliações não planejadas do sistema. O Teste Alfa é
semelhante ao Teste de Aceitação, porém neste nível apenas um grupo seleto é incluído para
testadores e desenvolvedores, veri�cando o sistema de maneira imprevista. O objetivo é garantir
um maior nível de qualidade do produto antes de enviá-lo ao cliente, pois permite aos
desenvolvedores resolver imediatamente problemas críticos ou correções identi�cadas.
Enquanto isso, no Teste Beta, um número maior de usuários �nais avalia o sistema em condições
do mundo real, proporcionando feedback valioso. Este teste coleta a opinião dos usuários sobre
o produto e garante que o produto esteja pronto para usuários em tempo real.
Por �m, o Teste de Regressão entra em ação após modi�cações no software, como correção de
bugs ou adição de funcionalidades. É uma veri�cação para garantir que as mudanças não
Disciplina
Gerenciamento e Qualidade de
Software
impactem negativamente o sistema.
Portanto, compreender a dinâmica dos níveis de teste ajuda os pro�ssionais de teste a planejar e
executar testes de forma e�caz. Cada nível tem seu propósito único, mas todos são essenciais
para entregar um software con�ável, livre de defeitos e que atenda às necessidades dos
usuários.
Videoaula: Introdução de teste de software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante!
Nesta aula, você compreendeu os conceitos de qualidade de software, teste de software e os
níveis de teste de software, além dos motivos pelos quais eles são importantes. Neste vídeo,
consolidaremos esses conceitos de forma que as ideias sobre eles �quem mais claras.
Saiba mais
Disciplina
Gerenciamento e Qualidade de
Software
Para expandir seus conhecimentos sobre processos de software e testes de software,
aconselhamos a leitura da obra indicada a seguir, com o objetivo de consolidar seus
conhecimentos.
Processos de software, de Polyanna Fabris e Luis Perini: neste livro, os autores discorrem sobre
modelagem de processos, o que é fundamental para compreender a necessidade que se tem de
parâmetros das métricas e revisões de software. Informações sobre engenharia de requisitos e o
gerenciamento de projetos também são apresentadas.
 
Referências
https://biblioteca-virtual.com/detalhes/ebook/608704eb54aa8872fc616ec6
Disciplina
Gerenciamento e Qualidade de
Software
AULETE, C. Minidicionário Contemporâneo da Língua Portuguesa. 2. ed. Rio de Janeiro: Lexikon,
2009.
CTFL SYLLABUS. 2023. Disponível em: https://bcr.bstqb.org.br/docs/syllabus_ct�_4.0br.pdf.
Acesso em: 14 set. 2023.
HETZEL, W. The complete guide to software testing. Massachusetts: QED, 1988.
MOREIRA FILHO, T.; RIOS, E. Projeto & Engenharia de Software: Teste de Software. Rio de Janeiro:
Alta Books, 2003.
MYERS, G. The Art of Software Testing. 2. ed. New York: Wiley, 1979.
PRESSMAN, R.; MAXIM, B. Engenharia de Software: uma abordagem pro�ssional. 9. ed. Porto
Alegre: AMGH, 2021.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Education, 2011.
Aula 3
Tipos de teste de software
Introdução
https://bcr.bstqb.org.br/docs/syllabus_ctfl_4.0br.pdf
Disciplina
Gerenciamento e Qualidade de
Software
Olá, estudante!
Adentramos uma fase em que percebemos a importância dos testes para o bom processo de
desenvolvimento de software. E quanto mais nos aprofundamos nos estudos e nas práticas de
teste de software, mais nos deparamos com circunstâncias e tipos de testes que se repetem de
tal forma que acabam servindo de referência para outras situações futuras.
Tendo como objetivo garantir que o teste de software siga sempre o melhor caminho, dentro do
processo de desenvolvimento de software, foram desenvolvidos padrões de teste de software
que ajudam as equipes de desenvolvimento e teste a garantirem a qualidade do processo sem a
necessidade de reprojetar toda a metodologia de testes a cada novo projeto.
Nesta aula, abordaremos os padrões de teste de software e como eles são importantes para o
processo de testes, além de nos aprofundarmos nos conceitos de testes para arquiteturas
cliente/servidor e testes para sistemas de tempo real.
Vamos lá?
Padrões de teste de software
Disciplina
Gerenciamento e Qualidade de
Software
Padrões estão presentes em praticamente todos os aspectos de nossas vidas, e na área de
testes de software não é diferente. Padrões são repetições reconhecíveis dentro de um conjunto
de elementos ou processos. Tanto os mecanismos de desenvolvimento quanto os de teste de
software estão cheios de padrões.
Equipes de testadores experientes realizam bons projetos de teste de software, ao passo que
novos testadores acabam �cando sobrecarregados pelas opções de testes disponíveis, tendendo
a utilizar métodos e técnicas de testes que não sejam e�cazes e bem-sucedidas.
Uma coisa que boas equipes de testes não devem fazer é resolver testar cada etapa do processo
de desenvolvimento de software do zero. Quando uma boa solução (método/modelo de teste) é
encontrada, a equipe a reutiliza repetidamente. Dessa forma, você encontrará padrões, planos de
testes, casos de teste eautomações que se repetem frequentemente. Esses padrões resolvem
situações especí�cas a depender do processo de desenvolvimento de software e permitem a
equipe de testes desenvolver seu planejamento de testes com �exibilidade.
Os padrões de teste de software são instruções e práticas criadas para auxiliar equipes de testes
a executar testes com qualidade. Alguns dos padrões mais comuns incluem:
AAA (Arrange-Act-Assert): é um padrão para organizar e formatar códigos em métodos de
testes unitários, separando-os em etapas de preparação, execução e veri�cação.
Given-When-Then: é padrão de organização de casos de teste em cenários claros, dividindo-
os em condições iniciais, ações executadas e resultados esperados.
Disciplina
Gerenciamento e Qualidade de
Software
Page Object: é um padrão de design que ajuda a reutilizar objetos de testes para facilitar a
manutenção de testes de UI automatizados.
Data-Driven Testing: é um padrão que executa scripts de testes que acessa dados de
entradas e saídas previstas a partir de arquivos de dados.
Mocking e Stubbing: é um padrão de teste em que objetos que ainda não foram criados são
simulados para isolar componentes do sistema que possuem dependências externas e/ou
fornecer respostas pré-de�nidas para chamadas de métodos.
BDD (Behavior Driven Development): é um padrão que enfatiza a colaboração entre
desenvolvedores, testadores e stakeholders que ajuda a criar cenários de teste usando
vocabulário especí�co e enxuto, minimizando di�culdades de comunicação.
TDD (Test Driven Development): é uma metodologia para desenvolvimento e escrita de
código, em que a codi�cação das funcionalidades começa a partir da escrita de testes
unitários.
Além dos padrões mencionados, é importante nos aprofundarmos na diversidade de contextos
em que o teste de software é aplicado. Ao falarmos de sistemas baseados em arquiteturas
cliente-servidor, os testes, geralmente, se concentram na comunicação entre clientes e
servidores, buscando garantir que os dados sejam entregues corretamente e que os
componentes do servidor estejam suscetíveis a lidar com várias solicitações simultâneas.
Para garantir que essas arquiteturas funcionem corretamente, uma variedade de testes pode ser
realizada, que incluem:
Testes de Comunicação e Integração.
Testes de Desempenho e Escalabilidade.
Testes de Segurança.
Testes de Integração com Bancos de Dados.
Testes de Usabilidade.
Testes de Recuperação de Falhas.
Testes de Concorrência.
Em contraste, sistemas de tempo real impõem exigências rigorosas de latência e precisão
temporal. Testar esses sistemas requer cenários especí�cos que avaliem a capacidade do
software de responder dentro de prazos quase imediatos, garantindo que a execução das tarefas
seja de�nitiva e previsível.
Padrões para arquitetura cliente-servidor
Disciplina
Gerenciamento e Qualidade de
Software
Agora que conhecemos os padrões de teste de software e sua utilidade no auxílio da execução
de testes de software, exploraremos mais a fundo os testes para arquiteturas cliente-servidor.
Disciplina
Gerenciamento e Qualidade de
Software
O modelo de rede, ou arquitetura cliente-servidor, permite que um sistema complexo seja
decomposto em componentes menores, em que cada componente é responsável por sua própria
função. Em um sistema cliente-servidor, temos, do lado cliente, um ou mais componentes
lidando com lógica de apresentação e uso de serviços fornecidos pelo lado do servidor; do lado
do servidor, temos um ou vários componentes que agem coletando e armazenando dados,
mantendo relação e fornecendo acesso aos dados processados por inúmeros clientes, ou até
mesmo outros servidores na rede.
Testar sistemas cliente-servidor pode ser um desa�o devido à sua natureza complexa, em que
cada componente é dependente e permanece em relação com outros componentes. É essencial
que haja boa colaboração entre todos os departamentos envolvidos no desenvolvimento deste
tipo de sistema, alinhando processos de teste com o desenvolvimento desde estágios iniciais,
tratando os testes como um esforço em equipe. Dessa forma, entenderemos melhor a respeito
do que é necessário testar em sistemas cliente-servidor.
Testes de Comunicação e Integração: a comunicação é um aspecto importantíssimo das
arquiteturas cliente-servidor. Os testes devem garantir que os dados sejam transmitidos
corretamente, que as solicitações dos clientes sejam tratadas de forma adequada e que as
respostas dos servidores atendam às expectativas. Logo, isso envolve testar os protocolos
de comunicação que estas arquiteturas utilizam, como HTTP, HTTPS e TCP/IP.
Testes de Desempenho e Escalabilidade: em sistemas de arquitetura cliente-servidor, a
escalabilidade é essencial para lidar com um grande número de clientes. Os testes de
desempenho veri�cam como o sistema se comporta sob carga, analisando se os
servidores são capazes de lidar com múltiplas requisições e se os tempos de resposta
dessas requisições são aceitáveis. Para esse tipo de teste, ferramentas de teste de carga,
como: Apache JMeter, são utilizadas para simular cenários de alta demanda.
Testes de Segurança: segurança é um aspecto de extrema importância em sistemas de
arquitetura cliente-servidor, pois muito comumente dados sensíveis são transmitidos. Para
identi�car e corrigir possíveis brechas na segurança, testes de penetração, ou pentest, são
executados para identi�car vulnerabilidades.
Testes de Integração com Bancos de Dados: a maioria dos sistemas cliente-servidor
interagem com bancos de dados. Testes devem ser feitos para veri�car se a integração
entre a camada do servidor e o banco de dados está sendo executada corretamente,
incluindo a capacidade de recuperação e a gravação de dados, ou seja, leitura e escrita de
informações no banco.
Testes de Usabilidade: são essenciais quando o cliente em questão possuir uma interface
para o usuário, como um aplicativo móvel ou uma página web. Esses testes têm por
objetivo garantir que a interface é intuitiva, fácil de usar e atenda às necessidades do seu
usuário.
Testes de Recuperação de Falhas: envolvem a simulação de falhas de rede, falhas de
servidor e outros cenários de erro, com o intuito de garantir que o sistema é capaz de se
recuperar adequadamente e manter a integridade dos dados.
Testes de Concorrência: envolve a simulação de um grande número de usuários acessando
o sistema ao mesmo tempo. O objetivo é identi�car problemas de concorrência, como
Disciplina
Gerenciamento e Qualidade de
Software
condições de corrida, ou seja, con�itos no acesso de recursos compartilhados do sistema
entre um ou mais usuários.
Aplicando padrões de teste de software
Tendo compreendido os conceitos de padrões de teste de software e teste de software para
sistemas de arquitetura cliente-servidor, vamos nos aprofundar na aplicação de testes para um
sistema de tempo real.
Sistemas de tempo real são quaisquer sistemas computacionais, de qualquer tipo, cujo tempo de
resposta a um determinado evento seja pré-de�nido. Isso não signi�ca, necessariamente, que
são super-rápidos, mas, sim, capazes de fornecer serviços dentro de limites temporais
estabelecidos em seu documento de requisitos.
É de nosso conhecimento os níveis de teste de software durante as etapas do processo de
desenvolvimento de software. Dessa forma, sabemos que, independentemente do tipo de
sistema que estamos testando, esses níveis devem ser respeitados para garantir que falhas no
processo de desenvolvimento sejam encontradas e tratadas.
Sigamos para a aplicação desses padrões na testagem de nosso sistema de tempo real. Para
isso, idealizaremos um sistema de monitoramento médico, projetado para permitir que médicos
e enfermeiros monitorem constantemente os sinais vitais de pacientes em hospitais em tempo
Disciplina
Gerenciamento e Qualidade de
Software
real. Este é um sistema crítico, pois fornece alertas imediatos a respeito de mudanças no estado
de saúde de pacientes, como batimentos cardíacos ou quedas de pressão.
Alguns dos testes necessários para validar, com maioríndice de qualidade possível, o sistema
proposto são:
Testes de Latência: têm o objetivo de avaliar o tempo que o sistema leva para processar
uma entrada e produzir uma saída, ou seja, medem o tempo necessário para que os dados
percorram entre o dispositivo cliente e o servidor. Estes testes devem ser executados
medindo a latência da rede em diversas condições, como diferentes cargas e tráfego ou
diferentes localizações geográ�cas dos dispositivos clientes. A latência deve estar dentro
dos limites especi�cados no documento de requisitos.
Teste de carga: têm o objetivo de avaliar como será o comportamento do sistema sob
carga máxima, ou seja, determinam se o sistema mantém desempenho aceitável quando
muitos usuários o acessam simultaneamente. Estes testes podem ser executados
utilizando ferramentas de teste de carga, em que a carga, ou seja, o número de usuários
acessando o sistema, é aumentado gradativamente até o limite especi�cado. O tempo de
resposta do sistema deve estar dentro dos limites aceitáveis para todas as instâncias de
usuários.
Teste de estresse: têm o objetivo de avaliar o momento em que o desempenho do sistema
cai, mesmo ao ponto de falhar completamente, ou seja, é um teste de carga realizado até
atingir o seu pico, em relação ao número de usuários simultâneos, por exemplo. Neste
teste, os recursos do sistema são sobrecarregados e levam o sistema para um estado de
falha.
Teste de redundância: têm o objetivo de veri�car se o sistema ou os seus componentes de
backup estão funcionando corretamente. Estes sistemas devem ser capazes de assumir as
funções do componente principal em caso de falha. Podem incluir cenários de failover,
recuperação de desastres, integridade de dados e muitos outros.
Testar sistemas de tempo real é um desa�o complexo. Mesmo diante de possíveis falhas, estes
sistemas devem ser capazes de manter sua operação contínua e con�ável. Manter os registros
dos resultados dos testes é essencial para a tomada de ações corretivas e aprimoramento
contínuo.
Videoaula: Tipos de teste de software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Disciplina
Gerenciamento e Qualidade de
Software
Olá, estudante!
Durante esta aula, você compreendeu os conceitos padrões de software, além dos tipos de teste
de software para sistemas de arquitetura cliente-servidor e sistemas de tempo real. Neste vídeo,
reforçaremos esses conceitos de forma que as ideias sobre eles �quem mais claras.
Saiba mais
Para expandir seus conhecimentos sobre processos de software e testes de software,
aconselhamos a leitura da obra indicada a seguir, com o objetivo de consolidar seus
conhecimentos.
Processos de software, de Polyanna Fabris e Luis Perini: neste livro, os autores discorrem sobre
modelagem de processos, o que é fundamental para compreender a necessidade que se tem de
parâmetros das métricas e revisões de software. Informações sobre engenharia de requisitos e o
gerenciamento de projetos também são apresentadas.
 
Referências
https://biblioteca-virtual.com/detalhes/ebook/608704eb54aa8872fc616ec6
Disciplina
Gerenciamento e Qualidade de
Software
GAMMA, E. Padrões de projeto: soluções reutilizáveis de software orientado a objetos. Porto
Alegre: Bookman, 2008.
SOMMERVILLE, I. Software Engineering. 9. ed. São Paulo: Pearson, 2011.
Aula 4
Outros tipos de teste de software
Introdução
Disciplina
Gerenciamento e Qualidade de
Software
Olá, estudante!
À medida que avançamos em nossos estudos sobre teste de software, tivemos a oportunidade
entender os conceitos de métricas de software, objetivos de se testar software, além de várias
abordagens de teste.
Para fornecer uma visão mais abrangente a respeito desse assunto, estudaremos os conceitos
de outros tipos de teste, aprofundando o conhecimento necessário para aplicar as técnicas em
projetos futuros. Perceberemos como esses conceitos se encaixam em nosso entendimento
geral de teste de software e como eles contribuem para a qualidade do software que
desenvolvemos.
Nesta aula, abordaremos os conceitos de testes estruturais (caixa branca), testes funcionais
(caixa preta) e testes de caminho base.
Vamos começar?
Testes estruturais (caixa branca) e funcionais (caixa preta)
Disciplina
Gerenciamento e Qualidade de
Software
Sabemos que os níveis de teste são executados um após o outro à medida que o
desenvolvimento do sistema �ca mais avançado, respondendo à pergunta: “Quando testar?”.
Agora, devemos responder à seguinte pergunta: “Como testar?”. Nesse momento, falamos em
técnicas de teste, as técnicas estruturais e funcionais, ou caixa branca e caixa preta.
O teste estrutural, conhecido também como teste caixa branca, é uma técnica que nos permite
olhar "dentro" do software e examinar sua estrutura interna. Este tipo de abordagem é utilizado
para identi�car falhas de programação, entender o �uxo do código e garantir que as partes
individuais do software foram escritas corretamente.
Testes estruturais podem ser executados em todos os níveis de testes, mas, geralmente, são
mais usados no nível de teste de unidade. O uso destas técnicas é recomendando logo após o
uso de técnicas baseadas em especi�cação, pois auxilia a medição da e�ciência do teste através
da análise de cobertura.
Cobertura é a extensão que uma estrutura foi exercitada por um conjunto de testes, expressa
como uma porcentagem de itens cobertos (CTFL Syllabus, 2023). É medida como o número de
instruções exercidas pelos casos de teste dividido pelo número total de instruções executáveis
no código.
Essa forma de teste é desempenhada como um teste "estático", em que o software propriamente
dito não é executado para desempenhar o teste. Com o auxílio de ferramentas de diagnóstico, é
possível analisar o código fonte, procurando erros estruturais e os pontos fracos, fornecendo
uma lista para ativar a ação corretiva a ser realizada. Esse tipo de teste é conduzido por
desenvolvedores, em vez de testadores de sistema.
As técnicas de teste caixa branca comumente usadas são Teste de Instrução e Cobertura de
Instrução e Teste de Rami�cação e Cobertura de Rami�cação.
Características comuns das técnicas baseadas em estrutura (CTFL Syllabus, 2023):
Disciplina
Gerenciamento e Qualidade de
Software
Informações sobre como o software é construído são utilizadas para derivar os casos de
testes. Por exemplo, código e modelagem.
A extensão da cobertura do código pode ser medida pelos casos de testes. Além disso, os
casos de testes podem ser derivados sistematicamente para aumentar a cobertura.
Por outro lado, o teste funcional, conhecido também como teste caixa preta, é uma técnica que
nos permite veri�car se um programa realiza suas funções conforme especi�cado nos requisitos.
Esta técnica de teste é desempenhada de forma “dinâmica”, em que o software é executado para
desempenhar o teste e avalia o comportamento de um software a partir de uma perspectiva
externa, sem a necessidade de conhecer detalhes internos da sua estrutura.
Testes caixa preta pode ser executada em quase todos os níveis de teste, sendo eles integração,
sistema, aceitação, alfa e beta. Este tipo de abordagem permite veri�car se o software atende
aos requisitos, se as funcionalidades e os recursos funcionam corretamente, além de identi�car
falhas.
As técnicas de teste caixa preta comumente usadas são:
Particionamento de equivalência.
Análise de valor de limite.
Teste de tabela de decisão.
Teste de transição de estado.
Características comuns das técnicas baseadas em especi�cação (CTFL Syllabus, 2023):
Modelos, formais ou informais, são utilizados para especi�cação de um problema a ser
resolvido, o software ou seu componente.
Os casos de testes podem ser derivados sistematicamente destes modelos.
Compreendendo caixa branca e caixa preta
Disciplina
Gerenciamento e Qualidade de
Software
Agora que já sabemos o que são testes estruturais e funcionais(caixa branca e caixa preta,
respectivamente), compreenderemos como funcionam as técnicas utilizadas em cada
abordagem.
Em testes caixa branca, temos as seguintes técnicas:
Teste de Instrução e Cobertura de Instrução:
Cada instrução do código é executada pelo menos uma vez durante a execução dos testes.
O objetivo é garantir que todas as instruções sejam testadas para veri�car se estão
funcionando conforme o esperado.
A cobertura de instrução é uma métrica usada para medir o quão bem o teste de instrução
está cobrindo o código. Ela é expressa como uma porcentagem das instruções executadas
em relação ao total de instruções no código.
A fórmula típica para calcular a cobertura de instrução é: Cobertura de Instrução (%) =
(Instruções Executadas / Total de Instruções) * 100
Teste de Rami�cação e Cobertura de Rami�cação:
O foco está nas decisões de controle de �uxo no código. Cada possível caminho ou
rami�cação dentro de estruturas condicionais, como declarações "if" e "else", deve ser
percorrido durante os testes.
Disciplina
Gerenciamento e Qualidade de
Software
A Cobertura de Rami�cação é uma métrica usada para medir o quão bem o teste de
rami�cação está cobrindo o código em termos de decisões de controle de �uxo. Ela é
expressa como uma porcentagem das bifurcações de código que foram executadas em
relação ao total de bifurcações possíveis.
A fórmula típica para calcular a cobertura de rami�cação é: Cobertura de Rami�cação (%) =
(Bifurcações Executadas / Total de Bifurcações Possíveis) * 100
Em testes caixa preta, temos as seguintes técnicas:
Particionamento de Equivalência:
Visa reduzir a redundância e a complexidade nos casos de teste.
A ideia é dividir o espaço de entrada de um sistema em grupos ou partições de
equivalência, em que cada grupo deve se comportar de maneira semelhante em relação ao
sistema.
Em vez de criar casos de teste individuais para cada valor de entrada, você cria casos de
teste que representam cada partição. Isso permite que você teste com e�ciência diferentes
cenários semelhantes, economizando tempo e recursos.
Análise de Valor de Limite:
É uma técnica que se concentra em testar os limites dos valores de entrada de um sistema.
Ela identi�ca os valores de entrada que estão próximos aos limites de uma faixa aceitável e
cria casos de teste para esses valores.
Teste de Tabelas de Decisão:
É usado para testar a implementação dos requisitos do sistema que especi�cam como
diferentes combinações de condições resultam em diferentes resultados.
Ele organiza as condições em uma tabela que lista todas as combinações possíveis de
valores das condições.
Cada combinação na tabela é testada para garantir que o sistema se comporte
corretamente em todas as situações possíveis.
Teste de Transição de Estado:
É uma técnica usada, principalmente, em sistemas que têm estados diferentes e transitam
entre esses estados durante a execução.
Ele se concentra em testar as transições entre os estados do sistema, veri�cando se as
transições ocorrem de acordo com as especi�cações e se o sistema se comporta corretamente
em cada estado
Testes de caminho base na prática
Disciplina
Gerenciamento e Qualidade de
Software
Um ponto forte fundamental que todas as técnicas de caixa branca compartilham é que toda a
implementação do software é levada em conta durante o teste, o que facilita a detecção de
defeitos mesmo quando a especi�cação do software é vaga, desatualizada ou incompleta (CTFL
Syllabus, 2023).
Agora que já sabemos o que são e como funcionam as técnicas caixa branca, exercitaremos um
pouco essas técnicas. Observe a Figura 1 a seguir.
Disciplina
Gerenciamento e Qualidade de
Software
Figura 1 | Função login. Fonte: elaborada pelo autor.
O código mostrado na Figura 1 é um exemplo de sistema de login simples. Realizaremos alguns
testes caixa branca nesse código.
Teste de Instrução e Cobertura de Instruções
A cobertura de instruções envolve a execução de testes para garantir que cada instrução no
código seja executada pelo menos uma vez. Para isso, precisaremos criar casos de teste que
acionem todas as partes do código. No código da Figura 1, temos três pontos de entrada
principais:
1. Quando o nome de usuário está correto.
2. Quando o nome de usuário está correto, mas a senha está incorreta.
3. Quando o nome de usuário está incorreto.
Criaremos os casos de teste que garantem a cobertura de todas as instruções:
Caso de teste 1: Nome de usuário e senha corretos
nome_usuario = "usuario1"
senha = "senha123"
Resultado esperado: "Login bem-sucedido!"
Caso de teste 2: Nome de usuário correto, senha incorreta
nome_usuario = "usuario1"
senha = "senha_incorreta"
Disciplina
Gerenciamento e Qualidade de
Software
Resultado esperado: "Senha incorreta."
Caso de teste 3: Nome de usuário incorreto
nome_usuario = "usuario_inexistente"
senha = "qualquer_senha"
Resultado esperado: "Nome de usuário incorreto."
Executando esses três casos de teste, garantimos a cobertura de todas as instruções do código.
Para auxiliar na identi�cação dos caminhos que devem ser testados, pode-se utilizar o critério de
McCabe, chamado complexidade ciclomática.
A complexidade ciclomática é uma técnica utilizada para criação de grafos, com a seguinte
fórmula: CC = Número de arestas – Número de nós + 2, determinando, assim, a quantidade de
casos de teste mínimo para testar os caminhos independentes do programa (Vilela, 2005).
Veja a Figura 2.
Figura 2 | Grafo de �uxo. Fonte: elaborada pelo autor.
Agora, contamos o número de nós e o número de arestas no grafo:
N = 6 (nós) A = 7 (arestas)
Podemos calcular a complexidade ciclomática (CC):
CC = 7 - 5 + 2 = 3.
Portanto, a complexidade ciclomática do código é 3. Isso signi�ca que há três caminhos
independentes através do código.
Teste de Rami�cações e Cobertura de Rami�cações:
Disciplina
Gerenciamento e Qualidade de
Software
Além da cobertura de instruções, podemos veri�car a cobertura de rami�cações, que garante que
todas as possíveis decisões no código sejam testadas. Em nosso exemplo, as principais
decisões estão relacionadas ao nome de usuário correto ou incorreto e à senha correta ou
incorreta.
Para cobertura de rami�cações, devemos adicionar mais casos de teste para cobrir as diferentes
combinações:
Caso de teste 4: Nome de usuário correto, senha correta
nome_usuario = "usuario1"
senha = "senha123"
Resultado esperado: "Login bem-sucedido!"
Caso de teste 5: Nome de usuário correto, senha incorreta
nome_usuario = "usuario1"
senha = "senha_incorreta"
Resultado esperado: "Senha incorreta."
Caso de teste 6: Nome de usuário incorreto, senha correta
nome_usuario = "usuario_inexistente"
senha = "senha123"
Resultado esperado: "Nome de usuário incorreto."
Caso de teste 7: Nome de usuário incorreto, senha incorreta
nome_usuario = "usuario_inexistente"
senha = "senha_incorreta"
Resultado esperado: "Nome de usuário incorreto."
Executando esses casos de teste, garantimos que todas as rami�cações no código sejam
testadas. Isso nos possibilita uma cobertura completa das instruções e das diferentes decisões
do código.
Videoaula: Outros tipos de teste de software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Disciplina
Gerenciamento e Qualidade de
Software
Olá, estudante!
Durante esta aula, você compreendeu os conceitos de testes estruturais e funcionais e suas
técnicas, além dos conceitos de cobertura e complexidade ciclomática.
Neste vídeo, reforçaremos esses conceitos de forma que as ideias sobre eles �quem mais
claras.
Saiba mais
Para expandir seus conhecimentos sobre processos de software e testes de software,
aconselhamos a leitura da obra indicada a seguir, com o objetivo de consolidar seus
conhecimentos.
Processos de software, de Polyanna Fabris e Luis Perini: neste livro, os autores discorrem sobre
modelagem de processos, o que é fundamental para compreender a necessidade quese tem de
parâmetros das métricas e revisões de software. Informações sobre engenharia de requisitos e o
gerenciamento de projetos também são apresentadas.
 
Referências
https://biblioteca-virtual.com/detalhes/ebook/608704eb54aa8872fc616ec6
Disciplina
Gerenciamento e Qualidade de
Software
CTFL SYLLABUS. 2023. Disponível em: https://bcr.bstqb.org.br/docs/syllabus_ct�_4.0br.pdf.
Acesso em: 14 set. 2023.
SOMMERVILLE, I. Software Engineering. 9 ed. São Paulo: Pearson, 2011.
VILELA, P. Teste de Software: técnicas funcionais. Piracicaba: Unimep, 2005.
Aula 5
Revisão da unidade
Gerenciamento e qualidade de software
https://bcr.bstqb.org.br/docs/syllabus_ctfl_4.0br.pdf
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, durante esta unidade adentramos no universo dos testes de software, um elemento
fundamental no ciclo de desenvolvimento. O teste desempenha um papel central na garantia da
qualidade e na entrega de produtos de software con�áveis e funcionais.
A primeira aula nos proporcionou uma compreensão fundamental acerca da relação entre erros,
defeitos e falhas no desenvolvimento, bem como a importância das métricas de revisão para
avaliar e melhorar a qualidade do software. A distinção entre erro, defeito e falha é fundamental
para identi�car, corrigir e evitar problemas. Já as métricas desempenham um papel essencial no
controle de projetos, fornecendo medidas quantitativas que permitem avaliar características e
processos do desenvolvimento de software de forma objetiva, facilitando a tomada de decisões.
Durante a segunda aula fomos introduzidos ao tema do teste de software e sua relação com a
qualidade do software. Compreendemos que a qualidade é uma gestão e�caz aplicada para criar
um produto útil que atenda aos requisitos e seja livre de defeitos. Abordamos as variadas
de�nições de teste de software e reconhecemos que os testes desempenham um papel
fundamental na busca pela qualidade no desenvolvimento. Também exploramos os diferentes
níveis de teste de software e percebemos como cada nível de teste tem seus objetivos e
propósitos especí�cos.
Na terceira aula, conhecemos os padrões de teste de software e sua importância na execução de
testes de alta qualidade. Destacamos a necessidade de equipes de testes experientes usarem
padrões para criar planos de teste, casos de teste e automações de maneira e�caz, em vez de
reinventar o processo a cada vez, o que proporciona �exibilidade e e�ciência na execução dos
Disciplina
Gerenciamento e Qualidade de
Software
testes. Em seguida, examinamos os testes aplicados em sistemas cliente-servidor, destacando a
importância da colaboração entre departamentos para testar sistemas complexos. E por último
concentramos nossa atenção nos testes de sistemas de tempo real, abordando alguns dos
testes críticos necessários para validar esses sistemas
Por �m, em nossa quarta aula exploramos os conceitos de testes estruturais (caixa-branca) e
testes funcionais (caixa-preta) e suas respectivas técnicas. Ao abordarmos os testes estruturais,
percebemos como eles permitem examinar a estrutura interna do software, identi�car falhas de
programação e veri�car se as partes individuais do software foram escritas corretamente.
Entendemos como essas técnicas são úteis para testar o código em um nível mais granular,
como o teste de unidade. Também aprendemos que os testes funcionais avaliam o software com
base em seus requisitos e funcionalidades, sem necessidade de conhecer os detalhes internos
de sua implementação. Pudemos entender como essas técnicas são usadas para veri�car se o
software atende às especi�cações e se executa suas funções conforme o esperado. Além disso,
aprendemos a respeito da complexidade ciclomática, que ajuda a determinar a quantidade
mínima de casos de teste necessários para cobrir caminhos independentes no código.
Ao �nalizarmos esta unidade, �cou claro que os testes desempenham um papel insubstituível
para o gerenciamento e qualidade de software. A aplicação de técnicas de teste é essencial para
garantir a con�abilidade e a precisão do software. Compreendemos que o teste não é apenas um
processo, mas uma mentalidade que permeia todo o ciclo de vida do desenvolvimento. Ao adotar
padrões e estratégias adequadas, conseguimos não só identi�car falhas, mas também promover
um software robusto e de alta qualidade. Assim, estamos preparados para enfrentar os desa�os
e contribuir de maneira signi�cativa para a excelência na produção de software.
Videoaula: Revisão da unidade
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Estudante, nesta unidade, você compreendeu os conceitos de erro, defeito e falha, além dos
conceitos de métricas de software. Abordamos a respeito de qualidade de software, teste de
software e os níveis de teste de software, e padrões de software, além dos tipos de teste de
software para sistemas de arquitetura cliente-servidor e sistemas de tempo real. Estudamos os
testes estruturais e funcionais e suas técnicas, além da técnica de cobertura e complexidade
ciclomática e os motivos pelos quais todos esses conceitos são importantes.
Neste vídeo, vamos reforçar esses conceitos de forma que as ideias acerca deles �quem o mais
claro possível.
Disciplina
Gerenciamento e Qualidade de
Software
Estudo de caso
A E-Shop é uma empresa de médio porte no setor de comércio eletrônico que aspira se
estabelecer como líder nesse setor, oferecendo aos clientes uma plataforma con�ável e de fácil
utilização em que possam descobrir e adquirir produtos de alta qualidade com praticidade e
segurança.
A E-Shop disponibiliza uma ampla variedade de produtos, desde eletrônicos e moda até artigos
domésticos e brinquedos. A empresa construiu uma sólida base de clientes e tem o objetivo de
ampliar sua presença e impacto no mercado.
A missão da E-Shop consiste em proporcionar aos clientes uma experiência excepcional de
compras on-line, oferecendo uma seleção diversi�cada de produtos de alta qualidade, preços
competitivos e um serviço de entrega e�caz. A empresa está empenhada em fomentar a
satisfação do cliente, estabelecer relacionamentos de longo prazo e assegurar a conveniência
nas compras virtuais.
A E-Shop deseja expandir seus negócios e se tornar uma empresa de grande porte, mas
encontrou desa�os signi�cativos relacionados à qualidade do seu software e à experiência dos
clientes. Apesar do compromisso da empresa em fornecer uma experiência de compra de
excelência, os clientes têm relatado problemas frequentes durante o processo de aquisição, o
que resulta em desistências e reclamações. As análises on-line e o “boca a boca” negativo estão
impactando negativamente a reputação da E-Shop e minando a con�ança dos clientes na
plataforma. Além disso, a empresa está perdendo receita devido a carrinhos de compras que se
esvaziam subitamente, pedidos duplicados, instabilidade e erros no processamento de pedidos e
pagamentos. Ademais, a E-Shop está deixando escapar oportunidades de crescimento devido à
insatisfação dos clientes.
Disciplina
Gerenciamento e Qualidade de
Software
A E-Shop utiliza metodologias de desenvolvimento ágil, com foco em entregas rápidas e
interações frequentes com os clientes. No entanto, não há uma estratégia de teste de software
e�caz em vigor, e os testes eram frequentemente realizados de forma ad hoc (improvisada), o
que levou a problemas de qualidade e experiência do cliente.
Quando a E-Shop era uma empresa de pequeno porte, contava com um ambiente mais
controlado e uma equipe mais enxuta. Isso signi�ca que havia uma comunicação direta e mais
próxima entre os membros da equipe, e o desenvolvimento e o teste de software eram mais
gerenciáveis. A empresa tinha um controle mais e�caz sobre a qualidade do software, já que as
equipes eram menores e as mudanças eram implementadas com maior facilidade.
No entanto, à medida que a E-Shop cresceu e expandiu seusnegócios, os desa�os aumentaram.
O aumento no volume de transações e no número de clientes trouxe consigo uma maior
complexidade nos sistemas, exigindo uma escalabilidade que a empresa não havia
experimentado anteriormente. Além disso, a necessidade de incorporar novos recursos e
funcionalidades para competir no mercado de comércio eletrônico também aumentou a
complexidade do software.
Essa expansão rápida e o aumento na complexidade podem ter contribuído para problemas de
qualidade e experiência do cliente.
Após analisar a situação da E-Shop, imagine que você é o engenheiro de software responsável
pelo setor de qualidade da plataforma. O que faria para que os problemas vistos não ocorram
mais e garantir à E-Shop continuar no rumo de se tornar empresa líder no setor de comércio
eletrônico?
________
Re�ita
O estudo de caso da E-Shop oferece uma oportunidade para re�etir a respeito dos desa�os que
as empresas podem enfrentar quando a qualidade do software não está alinhada com as
expectativas dos clientes. Ao considerar as di�culdades encontradas pela E-Shop, é possível
perceber como a satisfação do cliente, a reputação da plataforma e até mesmo o crescimento da
empresa estão intrinsecamente ligados à qualidade do software. Isso nos leva a questionar
como a adoção de abordagens de teste adequadas desde o início do desenvolvimento pode
evitar problemas futuros e proporcionar uma experiência mais satisfatória para os clientes. Além
disso, o estudo de caso nos lembra que o mercado de comércio eletrônico é altamente
competitivo, e a busca pela excelência na qualidade do software é essencial para se destacar e
prosperar nesse ambiente dinâmico.
Videoaula: Resolução do estudo de caso
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
Disciplina
Gerenciamento e Qualidade de
Software
para assistir mesmo sem conexão à internet.
Estudante, o estudo de caso da E-Shop nos apresentou alguns desa�os enfrentados durante o
processo de crescimento da empresa. Para enfrentar esses desa�os e cumprir sua missão de
proporcionar uma experiência de compra excepcional aos clientes, a E-Shop pode investir em
testes de software e�cazes, incorporando técnicas de teste capazes de encontrar a raiz das
falhas em sua plataforma.
A equipe de desenvolvimento e teste da E-Shop pode realizar uma análise aprofundada do
código-fonte do sistema de compras on-line, identi�cando áreas críticas que podem estar
causando problemas, como erros lógicos e falta de validação de dados. Técnicas de teste de
caixa-branca, como testes de instrução e cobertura de instrução, são implementadas para
garantir que todas as partes do código sejam executadas corretamente. Isso ajudará a identi�car
e corrigir erros de programação que afetam a con�abilidade do sistema.
Além disso, a equipe pode realizar testes de caixa-preta para veri�car se o sistema atende aos
requisitos especi�cados. Técnicas como particionamento de equivalência e análise de valor de
limite são aplicadas para testar diferentes cenários de entrada e situações de limite, como
preenchimento de formulários, processamento de pedidos e cálculos de pagamento. Isso ajudará
a garantir que o sistema funcione conforme o esperado pelos clientes.
A E-Shop também pode conduzir testes de integração para garantir que todos os componentes
do sistema funcionem de maneira harmoniosa. O uso de testes de usabilidade é útil para avaliar
a experiência do cliente em todo o processo de compra, identi�cando problemas de design ou
usabilidade que podem afetar negativamente a satisfação do cliente.
Para garantir que o sistema possa lidar com cargas de tráfego, a equipe de testes deve realizar
testes de desempenho, simulando muitos usuários acessando o site simultaneamente. Isso
ajuda a identi�car gargalos de desempenho e garantir que o sistema funcione de maneira
e�ciente mesmo em condições de �uxo intenso.
Dada a sensibilidade dos dados de pagamento dos clientes, a E-Shop deve realizar testes de
segurança abrangentes para identi�car e corrigir vulnerabilidades que possam comprometer a
segurança das informações dos clientes.
Com a implementação dessas estratégias de teste, a E-Shop melhorará signi�cativamente a
qualidade de seu software, proporcionando uma experiência de compra on-line con�ável e
satisfatória aos clientes. 
Resumo visual
Disciplina
Gerenciamento e Qualidade de
Software
Disciplina
Gerenciamento e Qualidade de
Software
Fonte: elaborada pelo autor.
Referências
Disciplina
Gerenciamento e Qualidade de
Software
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: Uma abordagem pro�ssional. 9. ed.
Porto Alegre: AMGH, 2021.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
,
Unidade 3
Gerenciamento do processo para garantia da qualidade de software
Aula 1
Conceito de critérios para utilização de teste de software
Introdução
Disciplina
Gerenciamento e Qualidade de
Software
Boas-vindas, estudante! Nesta aula, abordaremos o conceito de critério para utilização de testes,
as práticas para testes de software e a importância da organização para testes de software.
Nesta etapa de aprendizagem, exploraremos os fundamentos de qualidade de software, e
escolheremos quais partes do software devem ser testadas. Veremos como aplicar práticas de
testes e�cazes e como organizar os processos de teste para otimizar os resultados.
Ao estudar esses tópicos, você ganhará uma compreensão mais profunda de como os critérios
para utilização de testes de software são determinados e como eles afetam a qualidade e o
desempenho do software desenvolvido.
Critérios para testes de software
Disciplina
Gerenciamento e Qualidade de
Software
Olá, estudante! Os critérios para utilização de teste de software referem-se a padrões ou
diretrizes que determinam quando e como os testes de software devem ser aplicados durante o
ciclo de desenvolvimento de software. De acordo com Pressman e Maxim (2021), para realizar
testes de forma efetiva, uma equipe de software deve aplicar técnicas de revisões formais nos
requisitos. Ao fazer isso, muitos erros serão eliminados antes do início dos testes. Esses critérios
servem para auxiliar a tomada de decisões a respeito de quando é apropriado realizar testes,
quais tipos de testes devem ser executados e qual é o melhor momento, durante o processo de
desenvolvimento, para que eles sejam aplicados.
Esses critérios podem variar dependendo da metodologia de desenvolvimento, das necessidades
de cada projeto e das características especí�cas do software. Sommerville (2011) de�ne que a
maneira como as empresas lidam com seus processos de desenvolvimento pode variar
conforme o grau de formalidade, o porte da organização e o tipo de aplicação. Com isso, �ca
claro que não existe um formato padrão para a melhoria dos processos, cabendo ao gerente de
projetos adaptar os procedimentos conforme as necessidades do projeto.
Existem vários tipos de critérios para utilização de testes, cada um com foco em diferentes
aspectos do software. Alguns dos critérios tratam de:
Riscos: testes podem ser priorizados em áreas de maior risco, nas quais falhas podem ter
impacto signi�cativo no sistema.
Complexidade: áreas mais complexas do software podem ser submetidas a testes mais
rigorosos.
Alterações: testar após alterações signi�cativas no código, como novas funcionalidades ou
correções de bugs.
Integração: testes de integração são realizados quando diferentes partes do sistema se
comunicam.
Disciplina
Gerenciamento e Qualidade de
Software
Cronograma: de�nir quando os testes devem ocorrer para que estejam alinhados com o
cronograma geral do projeto.
Requisitos críticos: áreas do software que envolvem requisitos críticos para o funcionamento
correto do sistema podem ser testadas em maior profundidade.
Feedback contínuo: testes frequentes podem ser realizados ao longo do ciclo de
desenvolvimento, com frequentes reportes ao time para garantir a qualidadeem todas as fases.
Histórico de falhas: testar áreas que historicamente apresentaram problemas ou falhas.
Uma vez que os critérios foram estabelecidos, entramos na fase das práticas de testes de
software. As práticas de teste são técnicas que empregamos para executar os testes de forma
e�caz. Elas englobam várias abordagens, como testes manuais e automatizados, testes de
unidade, integração e aceitação e testes exploratórios. Ao aplicar as técnicas corretas, podemos
identi�car falhas e problemas antes que o software seja entregue ao usuário �nal. Isso é
especialmente importante em cenários nos quais a complexidade do software exige que todas
as funcionalidades do sistema interajam sem problemas, sejam fortemente ou fracamente
acoplados.
Por �m, ter um bom planejamento para a realização dos testes afeta diretamente a qualidade do
produto, pois uma estrutura bem-organizada para os processos de teste não só facilita o trabalho
da equipe como também tem um impacto signi�cativo em cada etapa do projeto.
Explorando critérios, práticas e organização de testes
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, já entendemos que existem vários tipos de critérios para a utilização de testes, e que
diferentes situações requerem abordagens diferentes. Ao escolher os critérios certos, podemos
focar os aspectos mais críticos do software, economizando tempo e recursos. Vamos considerar
um sistema de gerenciamento de recursos humanos, que têm funcionalidades como folha de
pagamento, banco de horas, ponto eletrônico e décimo terceiro salário. Nesse contexto, o critério
de risco assume uma grande importância. A�nal, estamos lidando com o salário de pessoas, em
um ambiente complexo e altamente regulado por leis trabalhistas.
As práticas para testes de software abrangem um conjunto de métodos e técnicas que
desempenham um papel fundamental na garantia da qualidade e con�abilidade do software.
Disciplina
Gerenciamento e Qualidade de
Software
Essas práticas são desenvolvidas para testar diversos aspectos do software, desde a
funcionalidade até o desempenho e a segurança. De acordo com Pressman e Maxim (2021),
algumas das práticas essenciais para testes de software são:
Testes de unidade: focalizam o esforço de veri�cação na menor parte do software, ou seja, na
menor parte do código. Nessa prática, cada unidade individual de código é testada
separadamente para veri�car se funciona conforme o esperado. Isso ajuda a identi�car
problemas em nível mais baixo, no código, e garante que cada componente contribua para um
funcionamento correto do software.
Testes de integração: à medida que as unidades individuais de código são desenvolvidas, os
testes de integração entram em cena. Essa prática visa testar a interação entre diferentes
componentes do software. A integração é crucial para identi�car con�itos e incompatibilidades
que podem surgir quando essas partes diferentes do software são combinadas.
Testes funcionais: os testes funcionais são executados para avaliar se o software atende aos
requisitos solicitados pelos clientes. Isso envolve a execução de cenários de testes e casos de
teste que simulam um passo a passo de como o usuário utilizará a funcionalidade, garantindo
que todas elas estejam operando conforme o planejado.
Automação de testes: a automação de testes faz uso de ferramentas e scripts de códigos
envolvendo linguagens de programação para descrevê-los e executá-los de forma automatizada.
Testes de desempenho: os testes de desempenho avaliam como o software se comporta sob
diferentes cargas de trabalho.
Testes de segurança: os testes de segurança identi�cam vulnerabilidades que podem ser
exploradas por ataques maliciosos.
Ao aplicar as práticas mencionadas, estamos conduzindo avaliações de acordo com os critérios
estabelecidos, como riscos, complexidade, requisitos críticos e alterações. Contudo, para fazer
tudo isso funcionar bem, é preciso planejamento.
O planejamento é um elemento essencial para a execução e�caz das práticas de teste. Um
planejamento sólido engloba a criação de cenários de testes bem documentados até a
homologação desses testes em produção. Ao estruturar esses processos, de�nir
responsabilidades e manter ambientes de teste consistentes, a organização garante que os
testes sejam realizados de maneira e�ciente, que erros sejam minimizados e que todos os
aspectos cruciais sejam avaliados.
Aplicando estratégias de testes
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, vamos partir para a aplicação. Segundo Pressman e Maxim (2021), o mais importante
é que o software seja con�ável, e com base nessa a�rmativa escolhemos os critérios de testes
mais apropriados para cada projeto – o nível de con�ança é necessário para o software ser
utilizado, e os testes dão esse nível de con�ança devido ao fato de o projeto adotar a prevenção
de erros e corrigi-los antes que o software chegue ao usuário �nal. Por exemplo, se testarmos
uma funcionalidade de carrinho de compras de um comércio eletrônico, podemos escolher, como
prática, o Teste Funcional, e o critério Alterações seria selecionado devido à funcionalidade ser
sujeita à mudança, como adição e retirada de produto do carrinho.
Ao aplicar as práticas de teste, realizamos os testes de acordo com os critérios estabelecidos.
Se optamos por testes exploratórios, navegamos pelo software como um usuário real,
identi�cando problemas não previstos.
Vamos considerar, por exemplo, um sistema de gerenciamento de pedidos de restaurante para
mostrar como cada tipo de teste pode ser aplicado em um único cenário. Se estamos usando
testes de unidades, veri�camos no código-fonte por meio da lógica implementada via código de
adicionar pedidos em uma estrutura de dados, que pode ser uma lista. Se estamos usando testes
de integração, veri�camos se o código-fonte está adicionando o pedido em um banco de dados
conforme o esperado, uma vez que o código-fonte tem que se comunicar com o banco de dados.
As práticas de testes funcionais podem ser feitas em testes que simulam um usuário fazendo
um pedido pela própria aplicação. Já para realizar a automação de interface de usuário, podemos
Disciplina
Gerenciamento e Qualidade de
Software
utilizar o Cypress como framework de teste que usa a linguagem JavaScript para automatizar os
testes, com a �nalidade de simular o usuário interagindo com a aplicação de forma bem rápida.
Para teste de segurança podemos utilizar OWASP ZAP, uma ferramenta que veri�ca
vulnerabilidades de segurança no software. Para testes de performance podemos utilizar a
ferramenta JMeter, na qual simulamos uma carga de usuários fazendo vários pedidos ao mesmo
tempo na aplicação, e podemos observar como o software lida com esse tipo de estresse.
Dessa forma, o conjunto completo de testes cobriria todas as principais áreas do
desenvolvimento de software, contribuindo para um sistema con�ável.
Concluímos que o planejamento dos testes desempenha um papel crucial na e�cácia dos testes
de software, sem afetar a qualidade e con�abilidade do produto �nal. Quando falamos em
organização de testes de software, não estamos falando em apenas manter documentos
arrumados ou ambientes de trabalho organizados, mas também de uma abordagem estruturada
e coordenada que permeia todo o processo de desenvolvimento.
Imagine construir uma casa sem um plano sólido: os resultados seriam desastrosos. Da mesma
forma, a organização de testes de software é como o plano que guia todo o processo de
construção de um produto de alta qualidade. O plano garante que todos os passos sejam
seguidos de maneira ordenada, evitando erros e retrabalho.
Em resumo, os critérios de teste, as práticas de teste e a organização de testes são três pilares
interdependentes que sustentam a garantia de qualidade do software. Compreender e aplicar
esses elementos de maneira adequada nos permite construir um software con�ável, e�caz e que
atenda às expectativas dos usuários.
Videoaula: Conceito de critérios para utilização de teste de software
Este conteúdo é um vídeo!
Para assistireste conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante! Durante a aula, você entendeu os critérios de testes, e viu como e quando aplicar
testes durante o ciclo de desenvolvimento.
No vídeo, você verá que as práticas de teste abrangem vários tipos de testes, como unidade,
integração, automação e segurança. Para o nosso exemplo de aplicação em gerenciamento de
pedidos de restaurante, testes variados podem ser empregados, sendo vitais para a
con�abilidade. Por �m, você entenderá que critérios, práticas e organização são pilares
interligados, assegurando a qualidade do software.
Disciplina
Gerenciamento e Qualidade de
Software
Saiba mais
Para ampliar seu conhecimento a respeito dos critérios para utilização de teste de software,
indicamos o livro Gestão de projetos de software, de Marcio Artero. A obra oferece um
aprofundamento rigoroso em conceitos cruciais da gestão de projetos de software, abordando
estratégias na governança de tecnologia da informação (TI), e na gestão de escopo para
de�nição de requisitos do software, uma análise de riscos potenciais em projetos. Também
destaca a importância da qualidade de software em qualquer projeto.
 
Referências
https://biblioteca-virtual.com/detalhes/ebook/6087054354aa8872fb666adc
Disciplina
Gerenciamento e Qualidade de
Software
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre: AMGH, 2021.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
Aula 2
Gerenciamento da produção de software
Introdução
Disciplina
Gerenciamento e Qualidade de
Software
Boas-vindas, estudante! Nesta aula, abordaremos planejamento, estimativa, execução e
monitoramento no contexto de projetos de software. Nesta etapa de aprendizagem,
exploraremos as práticas fundamentais das áreas citadas: o planejamento estabelece os
objetivos, requisitos e recursos necessários para o desenvolvimento de software; as técnicas de
estimativa ajudam a avaliar o esforço e o custo do software; e a fase de execução e
monitoramento exige �exibilidade para se adaptar aos desa�os emergentes. O uso de métricas é
vital para entender o desempenho dos critérios estabelecidos, por meio de coberturas de testes e
conformidade com requisitos, o que permite a implementação de ações corretivas de forma
e�ciente. Portanto, o sucesso em projetos de software não se baseia apenas em planejamento
rigoroso, mas também em estimativas precisas e monitoramento contínuo e adaptável.
Planejamento, estimativa e execução de projetos de software
Disciplina
Gerenciamento e Qualidade de
Software
Caro estudante, o planejamento de teste é uma tarefa contínua e executada durante todo ciclo de
vida do projeto; um planejamento de excelência favorece o projeto, garantindo a sua qualidade.
Pressman e Maxim (2021) enfatizam a importância de manter o plano do projeto como um
documento útil e atualizado para a equipe. Segundo os autores, elementos como cronograma,
estimativa de custos e análise de riscos precisam ser revisados e atualizados ao longo do
desenvolvimento do projeto, para assegurar sua e�cácia e utilidade contínua.
As atividades de planejamento de testes podem ser documentadas em um plano de teste, e
incluir:
Objetivos: o que se pretende alcançar.
Requisitos: as funcionalidades e restrições do sistema.
Escopo: as limites do projeto.
Cronograma: quando cada atividade será realizada.
Orçamento: quanto vai custar.
Recursos: quais pessoas, ferramentas e materiais são necessários.
Além dessas atividades, é necessário criar estratégia de teste fornecendo uma descrição geral
do processo de teste. O CTFL Syllabus (BSTQB, 2023), em sua versão 3.1, destaca os seguintes
tipos comuns de estratégias de teste:
Analítica: é baseada em análises de dois fatores como requisitos ou riscos, para guiar o processo
em questão. Um exemplo ilustrativo dessa metodologia é o teste orientado por riscos. Nesse
Disciplina
Gerenciamento e Qualidade de
Software
cenário, a concepção e a priorização dos testes são determinadas com base na avaliação do
nível de risco associado a cada aspecto do projeto.
Baseada em modelo: o projeto dos testes é elaborado a partir de um modelo especí�co que
representa alguma funcionalidade crucial do produto. Isso pode envolver uma função particular,
um procedimento de negócios, uma estrutura interna ou mesmo um atributo não funcional, por
exemplo, con�abilidade. Modelos frequentemente utilizados nesse contexto são os modelos de
estado e os modelos de crescimento de con�abilidade.
Metódica: baseia-se na aplicação sistemática de um conjunto já estabelecido de testes ou
critérios de teste. Esses podem incluir uma classi�cação de falhas frequentes ou prováveis, uma
lista de atributos de qualidade relevantes, ou padrões estabelecidos para a aparência e o
funcionamento de aplicativos móveis ou sites da organização.
Compatível com processo: concentra-se na análise, desenvolvimento e execução de testes
guiados por normas e padrões externos. Estes podem ser estabelecidos por padrões industriais
especí�cos, documentação processual, uma base de teste identi�cada, ou qualquer outra diretriz
ou norma estabelecida pela organização.
Dirigida (ou consultivo): predominantemente guiada por conselhos, direcionamentos ou
instruções provenientes de stakeholders, peritos no domínio empresarial ou especialistas em
tecnologia. Esses consultores podem não fazer parte da equipe de teste ou mesmo da
organização como um todo.
Contra regressão: é impulsionada pela intenção de prevenir a degradação de funcionalidades já
existentes. A estratégia envolve o reaproveitamento de recursos de teste já disponíveis, como
casos de teste, além da automatização ampla de testes de regressão.
Reativa: é adaptativa, respondendo ao sistema sobre um conjunto de testes e aos
acontecimentos que surgem durante a execução do teste. Os testes são concebidos e postos em
prática, podendo ser executados imediatamente com base nas informações obtidas a partir dos
resultados de testes anteriores de outros testes. O teste exploratório é uma técnica
frequentemente utilizada em estratégias do tipo reativa.
O planejamento pode ser feito com ferramentas como Gantt Charts, JIRA ou Trello para
acompanhar o progresso do projeto.
Estimativa de testes
Disciplina
Gerenciamento e Qualidade de
Software
Caro estudante, uma vez que o planejamento do teste foi estabelecido, é necessário criar as
estimativas de teste. Existem várias técnicas que podem ser usadas para determinar o esforço
necessário e adequado para os testes. Nesta seção vamos considerar o tempo, os recursos e o
custo associados ao projeto. Estimar de forma precisa ainda é um desa�o, mas é crucial para
de�nir expectativas realistas.
De acordo com Sommerville (2011), existem dois tipos de técnicas que podem ser usadas para
estimar:
Técnicas baseadas em experiências: as estimativas de requisitos de futuros esforços se baseiam
na experiência que os especialistas frequentemente têm em projetos anteriores para fazer uma
avaliação dos esforços que serão necessários para cumprir requisitos futuros. Esse método
depende do conhecimento e domínio dos especialistas a respeito da área de aplicação do
projeto.
Modelagem algorítmica de custos: uma abordagem usada em muitas situações para estimar
custos e o esforço necessário em um projeto. Esse método se baseia em diversos fatores,
incluindo atributos do produto como tamanho, e características do processo, como a experiência
da equipe envolvida no projeto.
Em ambas as situações, é preciso fazer uma estimativa do esforço envolvido e das
características do projeto e do produto. Sommerville (2011) destaca que na fase de iniciação de
um projeto, as estimativas tendem a ter uma grande margem de erro. Isso ocorre porque a
estimativa é realizada bem no início do projeto, sendo menor a precisão. Por outro lado,
estimativas feitas tardiamente, embora possam ser mais precisas, acabam sendo menos úteispara o planejamento e execução do projeto.
Caso a estimativa inicial do esforço requerido seja de x meses, o intervalo real pode variar de
0,25x a até 4x do esforço efetivamente medido na entrega do sistema. Conforme o projeto
Disciplina
Gerenciamento e Qualidade de
Software
progride na fase de planejamento e desenvolvimento, essas estimativas tendem a se tornar cada
vez mais acuradas. Essa variação na incerteza e precisão das estimativas é ilustrada na Figura 1,
que aborda a relação entre incerteza e estimativa ao longo do projeto.
Figura 1 | Incerteza de estimativas. Fonte: Sommerville (2011, p. 442).
Estimar um projeto vai muito além de simples palpites de tempo e recursos necessários; trata-se
de um cálculo fundamentado que muitas vezes se baseia em dados históricos e expertise no
domínio. Más estimativas podem levar a atrasos signi�cativos e estouro do orçamento previsto.
Por exemplo, um projeto de grande complexidade envolvendo diversos stakeholders necessita de
relatórios mais detalhados e rigorosos em comparação a uma simples atualização de software.
No contexto do desenvolvimento ágil, métricas como relatórios de progresso de testes, resumos
de defeitos e grá�cos de burndown são incorporados em quadros de tarefas e discutidos em
reuniões stand-up diárias.
Grá�cos de burndown, frequentemente usados em metodologias ágeis como Scrum e Kanban,
são ferramentas valiosas para monitorar o avanço do projeto ao longo de períodos especí�cos,
geralmente sprints ou ciclos de trabalho. O objetivo central desses grá�cos é ilustrar o volume de
trabalho pendente em relação ao tempo restante, ajudando a equipe a avaliar se está no caminho
certo para cumprir os prazos estabelecidos.
Estimar não é adivinhar quanto tempo e recursos o projeto consumirá, mas destacar a
importância de abordagens bem-fundamentadas e o uso de ferramentas adequadas para
monitorar o progresso.
 
Disciplina
Gerenciamento e Qualidade de
Software
Execução e monitoramento de testes
Vamos discutir a execução e o monitoramento de testes, que não se trata apenas de seguir o
planejamento, mas também de ter �exibilidade e adaptabilidade para enfrentar surpresas, que
inevitavelmente acontecerão.
No desenvolvimento de software, raramente as coisas ocorrem exatamente conforme planejado,
pois sempre no meio do desenvolvimento ocorre riscos emergem, bugs aparecem e atrasos
podem ser causados por uma série de fatores. Isso exige que a equipe de qualidade seja
adaptável.
O CTFL Syllabus (2023), em sua versão 3.1, destaca que o gerenciamento de testes emprega
dados do monitoramento para oferecer, sob a forma de diretrizes gerenciais, conselhos e
intervenções requeridas para tornar os testes mais produtivos e efetivos. Veja exemplos dessas
diretrizes gerenciais:
Se um risco for mapeado e se transforma em um contratempo real, deve-se reorganizar a
ordem dos testes.
Reexaminar se um elemento de teste cumpre os requisitos de entrada ou saída.
Reajustar o calendário de testes para acomodar um atraso no fornecimento do ambiente de
testes.
Mobilizar mais recursos conforme necessário.
Além disso, o uso de painéis em tempo real e indicadores-chave de desempenho (KPIs) é
inestimável nesta fase. Eles fornecem uma visão instantânea de como a suíte de testes está
Disciplina
Gerenciamento e Qualidade de
Software
sendo desempenhada em relação aos critérios de saída, como cobertura de testes e
conformidade com requisitos.
Para exempli�car, imaginemos um projeto de um aplicativo de delivery de comida. A equipe de
qualidade utiliza painéis de controle em tempo real para monitorar KPIs. Se, na metade da sprint,
for detectado que a cobertura de teste para o sistema de pagamento do aplicativo está abaixo do
esperado, várias ações corretivas são imediatamente implementadas. Isso pode incluir uma nova
priorização de testes e a alocação de mais recursos para essa área especí�ca.
As métricas também dão uma visão quanti�cada do projeto, abordando desde a relação entre o
que foi planejado e o orçado até métricas mais especí�cas, como a densidade de defeitos e taxa
de falhas. Métricas de custo, incluindo o ROI (retorno sobre investimento), são fundamentais para
justi�car os esforços e recursos alocados na atividade de teste.
As métricas frequentemente usadas em testes compreendem:
Métricas relacionadas ao avanço do projeto, como conclusão de atividades, alocação de
recursos e intensidade do teste.
Métricas associadas ao progresso do teste, como evolução na implementação do caso de
teste, avanço na con�guração do ambiente de teste, quantidade de casos de teste
realizados/não realizados, aprovados/reprovados e duração dos testes.
Métricas para avaliar a qualidade do produto, por exemplo, disponibilidade, latência, tempo
médio de falha.
Métricas ligadas a defeitos, como número e grau de prioridade de defeitos
identi�cados/resolvidos, taxa de incidência de defeitos e percentual de detecção de falhas.
Métricas focadas em risco, como grau de risco remanescente.
Métricas de abrangência, como cobertura de exigências e cobertura do código-fonte.
Métricas �nanceiras, como custo do processo de teste e gastos globais com qualidade.
Em resumo, a execução e o monitoramento de testes são elementos centrais para o sucesso de
qualquer projeto de software. Um planejamento rigoroso, técnicas de estimativa apropriadas e
um monitoramento contínuo são a base de qualquer projeto bem-sucedido.
Videoaula: Gerenciamento da produção de software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante! Nesta aula, conhecemos as áreas de planejamento, estimativa, execução e
monitoramento em projetos de software. Neste vídeo, você verá as técnicas para estimar
Disciplina
Gerenciamento e Qualidade de
Software
esforços e custos, a importância de métricas e KPIs na fase de execução, e como manter a
�exibilidade para adaptar-se a desa�os emergentes. 
Saiba mais
Para ampliar seu conhecimento em planejamento, estimativa, execução e monitoramento em
projetos de software, indicamos o livro Engenharia de Software, de Ian Sommerville. A obra
apresenta conteúdo focando o desenvolvimento ágil de software e sistemas embarcados, e
introduz novas abordagens, como engenharia dirigida a modelos e desenvolvimento open source.
Mantendo a clareza e a didática, o livro serve como um guia abrangente para diversas aplicações
em engenharia de software.
 
Referências
https://plataforma.bvirtual.com.br/Leitor/Publicacao/2613/pdf/523?code=p7UrLiIxUKmSYVSzNcf7o6pGkEVUf+y9XcRLp6EycMdRO79CSU+tNGkBHjG6TX7LaAnqs4D9taxSu/jVVCxsEA==
Disciplina
Gerenciamento e Qualidade de
Software
BRAZILIAN SOFTWARE TESTING QUALIFICATIONS BOARD (BSTQB). Certi�ed Tester Foundation
Level Syllabus. International Software Testing Quali�cations Board, 2023. Disponível em:
https://bcr.bstqb.org.br/docs/syllabus_ct�_4.0br.pdf. Acesso em: 14 set. 2023.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre: AMGH, 2021.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
Aula 3
Processos de engenharia de software
Introdução
https://bcr.bstqb.org.br/docs/syllabus_ctfl_4.0br.pdf
Disciplina
Gerenciamento e Qualidade de
Software
Boas-vindas, estudante! Nesta aula, abordaremos os princípios e práticas fundamentais da
engenharia de software. Discutiremos os processos de desenvolvimento, como DevOps, TDD,
BDD e DDD, e exploraremos a importância da arquitetura e do design de software para a
e�ciência e qualidade do projeto. Esses temas são essenciais não apenas para atender às
necessidades dos clientes, mas também para garantir a manutenibilidade e o sucesso
sustentado do seu software a longo prazo.
Princípios que norteiam a prática
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, a prática da engenharia de software envolve diversos princípios, conceitos, métodos e
ferramentas que devem ser considerados duranteo planejamento de um software. De acordo
Pressman e Maxim (2021), alguns desses princípios são:
Princípios que orientam o processo: 1. Seja ágil em todas as abordagens, tanto no modelo
prescritivo como no ágil. 2. Mantenha o foco na qualidade do produto em cada etapa do
desenvolvimento. 3. Esteja aberto para adaptações conforme as restrições do projeto. 4. Priorize
a formação de uma equipe e�ciente e auto-organizada. 5. Estabeleça mecanismos claros para
comunicação e coordenação. 6. Implemente práticas para o gerenciamento de mudanças. 7.
Tenha planos de contingência para avaliar e mitigar riscos. 8. Produza artefatos que agreguem
valor a outros processos ou tarefas. Esses princípios servem como um quadro de referência
aplicável a qualquer metodologia de desenvolvimento de software.
Princípios que orientam a prática: 1. Divida e conquiste. 2. Compreenda o uso da abstração. 3.
Esforce-se pela consistência. 4. Concentre-se na transferência de informações. 5. Construa
software que apresente modularidade efetiva. 6. Veri�que os padrões. 7. Quando possível,
represente o problema e sua solução sob perspectivas diferentes. 8. Lembre-se de que alguém
fará a manutenção do software. Esses princípios são essenciais independentemente das
técnicas ou ferramentas usadas, pois não só guiam o desenvolvimento, mas também facilitam a
manutenção futura do software.
Princípios da comunicação: 1. Ouça. 2. Prepare-se antes de se comunicar. 3. Saiba que alguém
deve facilitar a atividade. 4. Saiba que comunicar-se pessoalmente é melhor. 5. Anote e
Disciplina
Gerenciamento e Qualidade de
Software
documente as decisões. 6. Esforce-se para conseguir colaboração. 7. Mantenha o foco e crie
módulos para a discussão. 8. Faltando clareza, desenhe. 9. (a) Uma vez de acordo, siga em
frente; (b) se não chegar a um acordo, siga em frente; (c) se uma característica ou função não
estiver clara e não puder ser elucidada no momento, siga em frente. 10. Negociação não é uma
competição nem um jogo. Funciona melhor quando as duas partes saem ganhando.
Princípios do planejamento: 1. Entenda o escopo do projeto. 2. Inclua os envolvidos na atividade
de planejamento. 3. Reconheça que o planejamento é iterativo. 4. Faça estimativas baseadas no
que conhece. 5. Considere os riscos ao de�nir o plano. 6. Seja realista. 7. Ajuste particularidades
ao de�nir o plano. 8. De�na como pretende garantir a qualidade. 9. Descreva como acomodar as
alterações. 10. Veri�que o plano com frequência e faça os ajustes necessários
Princípios da modelagem: 1. Saiba que o objetivo principal da equipe de software é construir
software, não criar modelos. 2. Seja objetivo; não crie mais modelos do que precisa. 3. Esforce-se
ao máximo para produzir o modelo mais simples possível. 4. Construa modelos que facilitem
alterações. 5. Estabeleça um propósito claro para cada modelo. 6. Adapte os modelos que
desenvolveu ao sistema à disposição. 7. Crie modelos úteis, mas esqueça a construção de
modelos perfeitos. 8. Não se torne dogmático quanto à sintaxe do modelo. Se ela consegue
transmitir o conteúdo, a representação é secundária. 9. Se os instintos dizem que um modelo não
está correto, mesmo parecendo correto no papel, provavelmente há motivos para se preocupar.
10. Obtenha feedback o quanto antes.
Princípios da construção: 1. Todos os testes devem estar alinhados com os requisitos do cliente.
2. Os testes devem ser planejados muito antes de serem iniciados. 3. O princípio de Pareto se
aplica a testes de software. 4. Os testes devem começar “no particular” e progredir para o teste
“no geral”. 5. Testes exaustivos são impossíveis. 6. Aplique a cada módulo do sistema um teste
equivalente à sua densidade de defeitos esperada. 7. Técnicas de testes estáticos podem gerar
resultados importantes. 8. Rastreie defeitos e procure padrões em falhas descobertas pelos
testes. 9. Inclua casos de teste que demonstrem que o software está se comportando
corretamente.
Princípios da disponibilização: 1. As expectativas do cliente para o software devem ser
gerenciadas. 2. Um pacote de entrega completo deve ser montado e testado. 3. É preciso
estabelecer uma estrutura de suporte antes da entrega do software. 4. Material instrucional
adequado deve ser fornecido aos usuários. 5. Software com bugs deve ser primeiramente
corrigido e, depois, entregue.
Por �m, esses princípios auxiliam na aplicação de um processo de software signi�cativo e na
execução de métodos e�cazes de engenharia de software.
Processos de testes
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, uma vez entendido os princípios e práticas da engenharia de software, é crucial
aprofundar o conhecimento dos processos de desenvolvimento de software. Ao longo dos
últimos anos, o desenvolvimento de software passou por transformações signi�cativas, e
diversas metodologias e práticas foram criadas para tornar o processo mais e�ciente e e�caz. De
acordo Pressman e Maxim (2021), alguns desses processos são:
DevOps: busca integrar as equipes de desenvolvimento (Dev) e operações (Ops) para otimizar
tanto o processo de desenvolvimento quanto a qualidade do software. Essa prática utiliza
ferramentas de automação para implementar integração contínua e entrega contínua (CI/CD),
permitindo que alterações de código sejam testadas, aprovadas e implantadas de forma rápida e
segura. O DevOps também estimula uma cultura de colaboração e comunicação aberta entre as
equipes, tornando o processo de desenvolvimento mais transparente e e�caz.
TDD (desenvolvimento orientado a testes): nesse processo, a elaboração de testes é feita antes
da escrita do código de produção. A Figura 1 ilustra a etapa em que, antes de criar o primeiro
trecho de código, a equipe de qualidade elabora um teste para avaliá-lo, tentando
intencionalmente fazer com que o código falhe. Quando o código escrito satis�zer ao teste é
realizado um novo teste para o próximo trecho de código a ser desenvolvido. Esse processo se
repete até que todos os testes executados não apresentem erros. Caso algum teste apresente
erro, o código deve ser corrigido. Esse �uxo iterativo continua até que não haja mais teste a ser
criado, signi�cando que o componente satisfaz a todos os requisitos de�nidos para ele.
Disciplina
Gerenciamento e Qualidade de
Software
Figura 1 | O �uxo de desenvolvimento controlado por teste. Fonte: Pressman e Maxim (2021, p. 885).
BDD (desenvolvimento orientado a comportamento): é uma extensão do TDD, ou seja, primeiro se
cria o teste e, em seguida, o código utiliza descrições de comportamento em linguagem natural.
Essa abordagem ajuda a garantir que todos os membros da equipe, incluindo não
desenvolvedores, possam entender e participar no desenvolvimento.
DDD (design orientado a domínio): é um conjunto de regras e práticas que ajudam a fazer com
que a parte técnica de um projeto de software se alinhe com as necessidades do negócio. Isso
signi�ca que o software pode crescer e se adaptar à medida que todos compreendem melhor o
negócio. Ele também sugere que os desenvolvedores não apenas participem de reuniões com
especialistas, mas que realmente entendam o negócio e todos os seus detalhes, olhando para
ele de diferentes perspectivas. Isso ajuda a criar um software mais e�caz e alinhado com as
metas do negócio. Todas essas práticas têm um objetivo: fazer o software melhor e tornar o
processo de desenvolvimento mais e�ciente. Elas não são coisas que você precisa escolher uma
Disciplina
Gerenciamento e Qualidade de
Software
ou outra; muitas equipes usam várias delas ao mesmo tempo. A decisão de qual usar depende
do que o projeto precisa, dos objetivos do negócio e de quem está na equipe de
desenvolvimento. O mais importante é que todas essas abordagens oferecem ferramentas e
técnicas que podem ajudar as equipes a fazerem software de alta qualidade de maneira mais
fácil.
 
Arquitetura e design de software
Estudante, vamos discutir a respeito de arquitetura e design de software. Antigamente, a
arquitetura era implícita e informal, mas desde a primeiradivisão de programas em módulos ela
vem evoluindo. De acordo com Pressman e Maxim (2021), arquitetura de software é importante
para o desenvolvimento de sistemas, porque proporciona a comunicação entre todos os
envolvidos, desde decisões que impactam o projeto até o fornecimento de uma visão
compreensível da estrutura do sistema e da interação entre seus componentes.
De acordo com Sommerville (2011), existem exemplos de padrões que são muito usados e que
capturam os bons princípios de projeto de arquitetura. Eles são:
Arquitetura em camadas: organiza o software hierarquicamente, da interface do usuário ao
sistema operacional. Essa estrutura facilita o entendimento e a manutenção. A escolha desse
Disciplina
Gerenciamento e Qualidade de
Software
estilo arquitetural depende dos requisitos e limitações do projeto. A Figura 2 mostra uma
arquitetura de quatro camadas. A camada mais básica foca o suporte ao sistema, incluindo
bancos de dados e sistemas operacionais. A camada de aplicação abrange funcionalidades e
utilitários da aplicação. A terceira camada lida com a interface do usuário, autenticação e
autorização. A camada superior oferece recursos de interface com o usuário.
Figura 2 | Arquitetura em camadas. Fonte: Sommerville (2011, p. 111).
Arquitetura de repositório: centraliza dados e funções em um único armazenamento, facilitando a
manutenção e o controle de versões. Isso se torna vantajoso para aplicações baseadas em
dados, mas pode causar gargalos e tornar a distribuição desa�adora. A Figura 3 ilustra um
exemplo no qual um repositório é útil, destacando um IDE (ambiente de desenvolvimento
integrado) com várias ferramentas baseadas em modelos. Nesse contexto, o repositório atua
como um sistema de controle de versão, permitindo rastrear e reverter alterações de software.
Disciplina
Gerenciamento e Qualidade de
Software
Figura 3 | Arquitetura de repositório. Fonte: Sommerville (2011, p. 112).
Arquitetura cliente-servidor: distribui dados e processamento entre servidores e clientes
conectados por rede. É escalável e e�ciente na alocação de recursos, mas traz desa�os de
segurança e carga. É comum em sistemas web e bancos de dados. Vantagens incluem
modularidade e facilidade para expansão. A Figura 4 ilustra um exemplo de sistema cliente-
servidor multiusuário na internet para oferecer uma biblioteca de �lmes e fotos. Vários servidores
gerência desenvolveram diferentes tipos de mídia: o servidor de vídeo cuida da compressão e
descompressão de vídeos em baixa resolução, enquanto outro servidor mantém as fotos em alta
resolução.
Disciplina
Gerenciamento e Qualidade de
Software
Figura 4 | Arquitetura cliente-servidor. Fonte: Sommerville (2011, p. 114).
Arquitetura de duto e �ltro: organiza para processar dados em tempo real, em que cada etapa
transforma entradas em saídas. Os dados �uem sequencialmente ou paralelamente por meio
dessas transformações, até serem convertidos em saídas. Cada transformação é uma etapa de
processamento independente que pode operar em lotes ou de forma contínua. A Figura 5 ilustra
um exemplo de uma arquitetura de sistema em lote, usada em uma organização que emite
faturas para os seus clientes. Semanalmente os pagamentos efetuados são conciliados com as
faturas. Recibos são emitidos para os pagamentos con�rmados, e lembretes são enviados para
faturas não pagas no prazo.
Disciplina
Gerenciamento e Qualidade de
Software
Figura 5 | Arquitetura duto e �ltro. Fonte: Sommerville (2011, p. 115).
Após a fase de arquitetura vem a etapa design de software, que envolve a elaboração de
especi�cações detalhadas para cada componente ou módulo identi�cado durante a arquitetura.
Essa fase é dividida em design de alto e baixo nível, em que o primeiro estabelece a arquitetura
do software e o segundo detalha o comportamento especí�co de cada módulo. O design é
fundamental não só para orientar a construção do sistema, mas também para avaliá-lo em
relação aos seus objetivos, como con�abilidade e e�ciência. Portanto, um design bem elaborado
é importante para que o software �nal atenda às necessidades do cliente e mantenha uma alta
qualidade de código, abrangendo aspectos como legibilidade e manutenibilidade.
Contudo, tanto na arquitetura como no design de software ambas são fundamentais para o
sucesso de qualquer projeto de desenvolvimento de software, e frequentemente se sobrepõem
ou são iterativos, dependendo da metodologia de desenvolvimento adotada.
Videoaula: Processos de engenharia de software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante! Durante esta aula, você compreenderá os princípios essenciais da engenharia de
software e processos de desenvolvimento como DevOps, TDD, BDD e DDD. Discutiremos a
importância da arquitetura e do design para a qualidade e e�ciência do software, destacando sua
Disciplina
Gerenciamento e Qualidade de
Software
relevância para a manutenibilidade e sucesso a longo prazo dos projetos. Esses tópicos são
cruciais para atender às necessidades dos clientes de forma sustentável.
Saiba mais
Para ampliar seu conhecimento em princípios e práticas de engenharia de software, processos
de desenvolvimento de software (DevOps, TDD, BDD e DDD, entre outros) e arquitetura e design
de software, segue o livro Engenharia de Software de Ian Sommerville. O Capítulo 6 apresenta a
arquitetura de software, mostram o quanto a arquitetura é importante para fazer programas,
apresentando diferentes jeitos de criar arquitetura de software, com seus prós e contras, e ensina
técnicas para mostrar as ideias de forma clara. Também é mostrado dicas de como avaliar se
uma arquitetura está boa e sobre a importância de seguir padrões.
Referências
https://plataforma.bvirtual.com.br/Leitor/Publicacao/2613/pdf/523?code=p7
Disciplina
Gerenciamento e Qualidade de
Software
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre: AMGH, 2021.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
Aula 4
Normas e padrões para gerenciamento e qualidade de software
Introdução
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, boas-vindas! Nesta aula, abordaremos a qualidade em software que envolve não
apenas testes e garantia de qualidade, mas também adesão a normas como ISO/IEC 12207 e
ISO/IEC 15504. A chegada da LGPD adiciona uma camada de complexidade, exigindo proteção
de dados desde o início do desenvolvimento. Portanto, um sistema robusto que combina práticas
ágeis, conformidade com normas e regulamentações legais é essencial para alcançar excelência
e competitividade no mercado atual de desenvolvimento de software.
Critérios para testes de software
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, desde que o software se integrou em nossas vidas, surgiu a necessidade de maior
qualidade. O CTFL Syllabus (BSTQB, 2023), em sua versão 3.1, traz que muitas vezes os termos
"Garantia de Qualidade" (ou simplesmente QA) e "testes" são usados como se indicassem o
mesmo, mas são diferentes, embora relacionados. Ambos fazem parte de um conceito maior: o
gerenciamento de qualidade. Esse gerenciamento inclui todas as ações que ajudam e controlam
uma organização para manter a qualidade. Dentro disso, tanto a garantia de qualidade quanto o
controle de qualidade são partes importantes. De acordo com Pressman e Maxim (2021), o
gerenciamento de qualidade abrange uma gestão de qualidade efetiva aplicada de modo a criar
um produto útil que forneça valor signi�cativo para aqueles que o produzem e para aqueles que o
utilizam. A garantia da qualidade de software envolve diversas atividades que visam assegurar a
excelência do produto �nal, como:
Revisão de código: ou code review, é essencial para a qualidade do software. Além da detecção
de defeitos, também visa a melhorias e conformidade. Para melhores práticas, devem ser
seguidas diretrizesclaras e uma abordagem colaborativa. Estabelecer critérios de aprovação e
manter revisões frequentes também são passos importantes. A documentação dos resultados
serve como um histórico valioso para futuras análises e melhorias contínuas.
Inspeção de documentos: é uma prática rigorosa que foca principalmente a detecção de defeitos
e a avaliação da qualidade do produto de trabalho. A documentação de cada inspeção deve ser
feita por meio de checklists para guiar os revisores, que são pares ou especialistas usados para
conduzir a inspeção. A inspeção é comandada por um facilitador treinado, não pelo autor.
Disciplina
Gerenciamento e Qualidade de
Software
Documentos resultantes incluem registros de defeitos e ações necessárias. Métricas coletadas
durante o processo auxiliam na melhoria contínua do desenvolvimento de software
Gestão de con�guração e de mudanças: são práticas como controle de versões, no qual serve
para garantir a integridade e qualidade de um software ou sistema ao longo de seu ciclo de vida.
Este conjunto de práticas controla e documenta todas as alterações em código-fonte,
documentação e outros artefatos. Em equipes ágeis, a mudança não é apenas inevitável, mas
também bem-vinda. Seja uma alteração no software em desenvolvimento, na composição da
equipe ou em tecnologias emergentes, a agilidade está em saber adaptar-se e�cientemente. São
usadas ferramentas como Git para rastrear essas modi�cações, permitindo a colaboração
e�ciente entre equipes e a reversão de mudanças quando necessário. Todas essas estratégias
se integram para formar um sistema robusto de garantia da qualidade.
No gerenciamento da qualidade de software, a excelência é alcançada por meio de várias
atividades importantes. Isso inclui desde a revisão de código e inspeção de documentos, que
focam a detecção de defeitos e melhorias, até a gestão de con�guração e mudanças, essenciais
para manter a integridade do projeto ao longo do tempo. As equipes ágeis trazem uma camada
extra de adaptabilidade, tornando o software mais resistente a diversas mudanças. Todas essas
estratégias trabalham juntas para criar um sistema sólido de garantia de qualidade, assegurando
que o software entregue seja não apenas útil, mas também valioso para todos que o utilizam.
Normas e padrões de qualidade de software
Estudante, como já entendemos a garantia de qualidade, vamos estudar as normas e padrões de
qualidade de software que desempenham um papel crucial na garantia de e�cácia, segurança e
Disciplina
Gerenciamento e Qualidade de
Software
con�abilidade dos produtos de software. De acordo com Pressman e Maxim (2021), o padrão
ISO foi desenvolvido com objetivo de identi�car os atributos fundamentais de qualidade para
software. Dentre as normas internacionalmente reconhecidas, podemos destacar a ISO/IEC
12207, ISO/IEC 15504 e ISO/IEC 9126, cada uma delas com o foco em aspectos especí�cos da
qualidade do software.
ISO/IEC 12207: fornece um guia para todo o ciclo de vida de um software, do começo ao �m. Ela
ajuda empresas a �carem mais organizadas, focarem o cliente e gerenciarem melhor seus
recursos. A norma divide os processos em três tipos: Fundamentais, de Apoio e Organizacionais.
Esses processos abrangem tudo, desde o desenvolvimento até a manutenção do software,
tornando todo o trabalho mais e�ciente e alinhado. É uma ferramenta útil para evitar falhas e
garantir o sucesso de projetos de software.
ISO/IEC 15504: de�ne um conjunto de requisitos para avaliação do processo de software. A
�nalidade do padrão é auxiliar as organizações no desenvolvimento de uma avaliação objetiva da
e�cácia de um processo qualquer de software. Também conhecida como SPICE (Software
Process Improvement and Capability Determination), essa norma foca a avaliação do processo
de desenvolvimento de software. O objetivo é medir a maturidade dos processos de uma
organização e identi�car áreas para melhoria. Ao seguir esta norma, as organizações podem não
apenas melhorar seus processos internos, mas também garantir que seus produtos �nais
atendam aos padrões de qualidade desejados.
ISO/IEC 9126: esta norma foi criada para de�nir o que faz um software ter qualidade. Ele se
divide em seis atributos principais: funcionalidade, que avalia se o software faz o que promete,
considerando aspectos como segurança e adequação; con�abilidade, focada no tempo que o
software �ca disponível sem falhas; usabilidade, que olha para o quão fácil é usar o software;
e�ciência, que se preocupa com o uso inteligente de recursos do sistema; facilidade de
manutenção, que mede o quanto é simples fazer correções ou atualizações; e, por �m,
portabilidade, que é a capacidade do software de funcionar em diferentes ambientes ou
sistemas.
Em resumo, a adesão a essas normas é crucial para qualquer organização focada em alcançar a
excelência em desenvolvimento de software. Elas oferecem um roteiro estruturado para melhorar
a qualidade dos produtos e otimizar processos internos. Isso não apenas resulta em produtos
mais con�áveis, mas também potencializa a e�ciência operacional da empresa. Além disso,
empresas que seguem essas diretrizes ganham uma vantagem competitiva, pois demonstram
um compromisso sério com a qualidade e a satisfação do cliente, fatores cada vez mais
valorizados no mercado atual.
Lei Geral de Proteção de Dados (LGPD)
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, atualmente a sociedade está cada vez mais digital, o que obriga as empresas a se
adaptarem às novas regulamentações. Com isso, a Lei Geral de Proteção de Dados (LGPD), que
foi sancionada em agosto de 2018 e entrou em vigor em setembro de 2020 no Brasil, trouxe
mudanças signi�cativas no cenário de regulação de dados no país. A LGPD apresenta impactos
signi�cativos em várias áreas, inclusive na de desenvolvimento e gerenciamento de software,
pois ela estabelece regras claras para coleta, armazenamento, tratamento e compartilhamento
de dados pessoais, impondo penalidades severas para as organizações que não cumprirem a
legislação (Brasil, 2018).
Para as empresas de desenvolvimento de software, essa lei muda bastante a forma como elas
devem cuidar das informações das pessoas. Isso vale desde o momento em que o programa
está sendo feito até quando ele já está funcionando. Além de se preocupar em fazer um
programa bom e sem falhas, as empresas também têm que seguir as regras da LGPD.
Com a LGPD, a primeira coisa que muda ao fazer um programa, é que você tem que pensar em
proteger os dados das pessoas desde o começo. Não dá para deixar para pensar nisso só no
�nal. Em outras palavras, o programa tem que ser feito de modo que já venha com a segurança
dos dados como algo básico, e isso tem que ser bem testado para ter certeza de que está
funcionando. Por exemplo, medidas como criptogra�a forte para o armazenamento de dados e
protocolos seguros para a transferência de informações entre sistemas tornam-se essenciais.
Além disso, é indispensável que as empresas estabeleçam um sistema robusto de governança
de dados, integrando-o às práticas de gerenciamento de qualidade de software. Isso implica a
Disciplina
Gerenciamento e Qualidade de
Software
criação de métricas, indicadores e auditorias especí�cas para monitorar a conformidade com a
LGPD, bem como a implantação de ferramentas e processos para assegurar o tratamento
adequado dos dados pessoais.
A qualidade do software também está relacionada à experiência do usuário, e a LGPD acrescenta
uma nova camada a essa equação. Isso signi�ca que o programa precisa ser claro a respeito de
como usa os dados e permitir que as pessoas vejam, corrijam ou apaguem suas informações.
Isso é uma parte importante para saber se o programa é bom ou não.
Em caso de incidentes de segurança que resultem em vazamento de dados, a empresa deve ter
processos claros e e�cazes para lidar com a situação, minimizando os danos aos titulares dos
dados e também às suas operações. A qualidade do gerenciamento dessas situações de crise
pode inclusive impactar signi�cativamente a reputação daempresa e sua posição no mercado.
Portanto, a LGPD adiciona uma complexidade adicional ao gerenciamento e à qualidade de
software. Ignorar essa legislação não é uma opção, dadas as pesadas multas e possíveis danos
à reputação que o não cumprimento pode acarretar. Mais do que nunca, qualidade e
conformidade legal devem andar de mãos dadas no cenário atual de desenvolvimento de
software.
Videoaula: Normas e padrões para gerenciamento e qualidade de software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante! Neste vídeo, vamos abordar o tema da qualidade em desenvolvimento de
software, destacando a importância de práticas como garantia de qualidade e testes. Vamos
também explorar como normas internacionais como ISO/IEC in�uenciam essa qualidade. Além
disso, falaremos dos impactos da Lei Geral de Proteção de Dados (LGPD) no cenário atual, que
adiciona novas exigências para a proteção de dados pessoais. O objetivo é orientar
desenvolvedores e gestores a criarem softwares que sejam ao mesmo tempo e�cazes, seguros e
em conformidade com as regulamentações atuais.
Saiba mais
Disciplina
Gerenciamento e Qualidade de
Software
Para ampliar seu conhecimento acerca dos critérios para utilização de teste de software,
indicamos o livro Engenharia de Software de Ian Sommerville. O Capítulo 24 aborda a Garantia de
Qualidade, focando em técnicas como inspeção e código review, oferece exemplos, melhores
práticas e destaca a importância de manter uma cultura de qualidade na equipe, sendo um guia
útil para aprimorar a qualidade dos projetos de software.
Referências
https://biblioteca-virtual.com/detalhes/ebook/6087054354aa8872fb666adc
Disciplina
Gerenciamento e Qualidade de
Software
BRASIL. Lei nº 13.709, de 14 de agosto de 2018. Lei Geral de Proteção de Dados Pessoais
(LGPD). Diário O�cial da União, Brasília, DF, 15 ago. 2018. Disponível em:
https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm. Acesso em: 9 set.
2023.
BRAZILIAN SOFTWARE TESTING QUALIFICATIONS BOARD (BSTQB). Certi�ed Tester Foundation
Level Syllabus. International Software Testing Quali�cations Board, 2023. Disponível em:
https://bcr.bstqb.org.br/docs/syllabus_ct�_4.0br.pdf. Acesso em: 14 set. 2023.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Porto Alegre: AMGH, 2021.
Aula 5
Revisão da unidade
Gerenciamento e qualidade de software
https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm.
https://bcr.bstqb.org.br/docs/syllabus_ctfl_4.0br.pdf
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, ao longo desta unidade exploramos conceitos e práticas fundamentais relacionados à
engenharia de software. Desde os princípios que orientam o processo de desenvolvimento até as
normas de qualidade e os desa�os legais envolvendo a Lei Geral de Proteção de Dados (LGPD),
cada aula contribuiu para compreensão de como criar software de alta qualidade e atender às
demandas da sociedade digital.
Na primeira aula, concentramos nossa atenção nos princípios essenciais que guiam a
engenharia de software, que o teste de software desempenha um papel crucial na garantia da
qualidade e con�abilidade do produto �nal. É fundamental selecionar critérios de teste
apropriados, como riscos, complexidade e requisitos críticos, e aplicar práticas de teste
adequadas, como testes de unidade, integração, funcionalidade, segurança e desempenho. A
organização de testes desempenha um papel central na coordenação e execução e�caz dessas
práticas, garantindo que o software seja con�ável e atenda às expectativas dos usuários. Com
um planejamento sólido e uma abordagem estruturada, podemos evitar erros e retrabalho,
processo semelhante a construir uma casa com um plano bem de�nido. Em resumo, esses três
pilares interdependentes – critérios de teste, práticas de teste e organização de testes – são
essenciais para o sucesso do teste de software e para entregar um produto de alta qualidade.
Na segunda aula, aprofundamos nosso conhecimento a respeito dos processos de
desenvolvimento de software, explorando metodologias como DevOps, TDD (desenvolvimento
orientado a testes), BDD (desenvolvimento orientado a comportamento) e DDD (design orientado
a domínio). Cada abordagem foi analisada quanto às suas vantagens e como elas contribuem
para tornar o processo de desenvolvimento mais e�ciente e colaborativo.
A terceira aula concentrou-se na garantia de qualidade de software, um elemento vital na
engenharia de software. Discutimos práticas como revisão de código, inspeção de documentos e
gestão de con�guração e mudanças. Essas atividades são essenciais para assegurar a
Disciplina
Gerenciamento e Qualidade de
Software
excelência do produto �nal, identi�car defeitos e promover melhorias contínuas, integrando-se
perfeitamente ao processo de desenvolvimento.
Na última aula, exploramos as normas e padrões de qualidade de software, incluindo ISO/IEC
12207, ISO/IEC 15504 e ISO/IEC 9126. Essas normas desempenham um papel fundamental na
garantia da e�cácia, segurança e con�abilidade dos produtos de software. Além disso,
discutimos como a Lei Geral de Proteção de Dados (LGPD) trouxe mudanças signi�cativas na
regulamentação de dados, afetando a forma como as empresas de desenvolvimento de software
coletam, armazenam e tratam informações pessoais.
Ao encerrar esta unidade, podemos reconhecer que à medida que avançamos no estudo da
engenharia de software, torna-se evidente que a qualidade do software não é apenas uma
questão técnica, mas também abrange aspectos de colaboração, conformidade legal e
preocupações com a privacidade. Ao aplicar os princípios aprendidos e seguir as normas
relevantes, as organizações podem criar software de alta qualidade que atenda às expectativas
dos usuários e cumpra os requisitos legais em uma sociedade cada vez mais digital.
Videoaula: Revisão da unidade
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Estudante, nesta unidade exploramos conceitos e práticas fundamentais da engenharia de
software, incluindo testes, princípios, metodologias ágeis, normas de qualidade e processos de
desenvolvimento de software, e estudando metodologias como DevOps, TDD, BDD e DDD, e como
elas tornam o processo mais e�ciente e colaborativo. Abordamos também a garantia de
qualidade de software, com ênfase em práticas como revisão de código, inspeção de
documentos e gestão de con�guração e mudanças.
Neste vídeo, você vai rever os principais tópicos trabalhados nesta unidade, revisitando os
conceitos aprendidos, com uma visão geral dos temas abordados.
Estudo de caso
Disciplina
Gerenciamento e Qualidade de
Software
A Digital Information é uma organização reconhecida como referência em excelência em
desenvolvimento de software, proporcionando soluções que impulsionam a transformação
digital das empresas. Sua missão é fornecer produtos e serviços para o desenvolvimento de
software que busca constantemente aprimorar sua qualidade e garantir a conformidade com as
regulamentações, incluindo a Lei Geral de Proteção de Dados (LGPD).
Recentemente, a empresa enfrentou desa�os signi�cativos durante um projeto crítico envolvendo
o desenvolvimento de um novo sistema de gestão de clientes para uma instituição �nanceira.
Um dos principais desa�os encontrados foi a ausência de práticas de desenvolvimento orientado
(TDD): essa abordagem levou a um desenvolvimento menos e�ciente, uma vez que os testes não
eram incorporados desde o início do processo. Isso resultou na identi�cação tardia de erros e
defeitos no software, tornando mais desa�ador e dispendioso realizar correções.
Com isso ocorreu a insu�ciência de testes de unidade. Durante a fase de desenvolvimento, a
equipe de desenvolvimento deparou-secom di�culdades para realizar testes de unidade e�cazes
devido à falta de conhecimento e experiência em boas práticas de teste e com o prazo curto para
o desenvolvimento. Isso resultou em uma identi�cação tardia de erros e defeitos no software,
afetando a qualidade do projeto.
Além disso, problemas de integração surgiram ao integrar diferentes módulos do sistema. Foram
encontrados problemas de compatibilidade e con�itos de dados, o que causou atrasos
signi�cativos no cronograma do projeto. Os testes de integração não foram e�cazes na detecção
precoce desses problemas, o que levou a uma revisão e retrabalho extensos.
A conformidade com a LGPD também se mostrou um desa�o crítico. O projeto envolveu o
processamento de dados pessoais dos clientes da instituição �nanceira, exigindo conformidade
rigorosa com os requisitos legais. No entanto, a empresa enfrentou di�culdades em garantir que
Disciplina
Gerenciamento e Qualidade de
Software
todas as etapas do projeto estivessem alinhadas com os requisitos da LGPD, o que gerou
preocupações com relação à privacidade e segurança dos dados dos clientes.
Após analisar estes pontos, imagine que você é um engenheiro de software experiente. Como
faria para ajudar a Digital Information a melhorar a e�ciência do desenvolvimento e a qualidade
do software para que não ocorram esses problemas novamente?
 
______
Re�ita
 
Olá, estudante!
O estudo de caso da Digital Information nos oferece uma visão valiosa dos desa�os enfrentados
no desenvolvimento de software e das complexidades associadas à conformidade com
regulamentações como a LGPD. A experiência da empresa destaca a importância de vários
aspectos cruciais na engenharia de software.
Primeiramente, �cou evidente que a falta de testes de unidade adequados pode ter um impacto
signi�cativo na qualidade do projeto. A ausência de boas práticas de teste resultou na
identi�cação tardia de erros e defeitos, o que poderia ter sido evitado com a implementação de
testes de unidade e�cazes desde o início do desenvolvimento.
Além disso, os problemas de integração destacam a necessidade de testes de integração
e�cazes para evitar atrasos e retrabalho. Detectar con�itos de dados e problemas de
compatibilidade mais cedo no processo de desenvolvimento é fundamental para manter o
cronograma do projeto sob controle.
A conformidade com a LGPD é um desa�o crítico, especialmente quando se lida com dados
pessoais. Garantir que todas as etapas do projeto estejam alinhadas com os requisitos legais é
essencial para proteger a privacidade e segurança dos dados dos clientes.
Por �m, a ausência de práticas de desenvolvimento orientado a testes (TDD) demonstrou como
essa abordagem pode contribuir para um desenvolvimento mais e�ciente e identi�cação precoce
de problemas.
Como engenheiro de software experiente, você abordaria essas questões promovendo a
implementação de testes de unidade abrangentes, aprimorando os testes de integração,
assegurando a conformidade com regulamentações e incentivando a adoção de práticas de TDD.
A lição que podemos tirar deste estudo de caso é que a qualidade do software não é um
compromisso, mas uma necessidade absoluta. Ao enfrentar esses desa�os com as melhores
práticas e abordagens adequadas, as empresas podem entregar produtos de alta qualidade que
atendam às expectativas dos clientes e estejam em conformidade com as regulamentações
vigentes.
Videoaula: Resolução do estudo de caso
Este conteúdo é um vídeo!
Disciplina
Gerenciamento e Qualidade de
Software
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Estudante, o estudo de caso da empresa Digital Information nos mostrou alguns desa�os
importantes enfrentados durante um projeto crítico de desenvolvimento de software. Para
superar esses desa�os e melhorar a e�ciência do desenvolvimento e a qualidade do software, a
empresa pode seguir algumas estratégias práticas.
Primeiramente, é crucial aprimorar os testes de unidade desde o início do processo de
desenvolvimento. Isso signi�ca garantir que a equipe esteja bem treinada em boas práticas de
teste e que tenha as ferramentas certas à disposição. Para isso, deve-se investir em capacitar a
equipe. Além disso, a implementação da integração contínua (CI), que automatiza os testes, pode
acelerar a detecção de erros, economizando tempo e recursos
Outra dica valiosa é a revisão de código rigorosa e a aplicação de técnicas baseadas em
experiências. Pro�ssionais experientes podem revisar o código para identi�car problemas.
Também é fundamental destacar a implementação das práticas de desenvolvimento orientado a
testes (TDD) como um passo crucial, pois a criação dos testes antes mesmo do código de
produção permitirá a antecipação e a veri�cação de possíveis erros de forma proativa. Essa
abordagem coloca a qualidade no centro do processo de desenvolvimento, garantindo que o
código atenda aos requisitos e funcione conforme o esperado desde o início do projeto. Isso
economizará tempo e recursos, pois os problemas são identi�cados e resolvidos antes mesmo
de se tornarem obstáculos signi�cativos, contribuindo para um desenvolvimento mais e�ciente e
com menos retrabalho.
Os testes de integração também devem ser aprimorados com a execução automática durante a
integração contínua, simulações de ambiente de produção e monitoramento proativo para
identi�car problemas de compatibilidade e con�itos de dados.
Para garantir a conformidade com a LGPD, é necessário nomear uma equipe de conformidade
dedicada, realizar avaliações de impacto de privacidade e capacitar a equipe em relação aos
princípios da LGPD, possivelmente com o auxílio de ferramentas especializadas.
Em resumo, enfrentar os desa�os encontrados pela Digital Information requer compromisso com
a melhoria contínua, capacitação da equipe e implementação de melhores práticas em todos os
aspectos do desenvolvimento de software. Com essas medidas, a empresa pode melhorar sua
e�ciência de desenvolvimento e entregar produtos de alta qualidade que atendam às
expectativas dos clientes e estejam em conformidade com regulamentações como a LGPD. Para
alcançar esses objetivos, a empresa precisa investir em treinamento, ferramentas adequadas e
uma cultura organizacional focada na excelência em desenvolvimento de software. Isso não
apenas bene�ciará a Digital Information, mas também fortalecerá sua posição como líder em
transformação digital e excelência em desenvolvimento de software. Portanto, o caminho para o
sucesso é claro: compromisso com a qualidade, aprimoramento contínuo e conformidade
rigorosa com regulamentações relevantes. Com essas medidas, a Digital Information pode
enfrentar seus desa�os e alcançar novos patamares de sucesso no mercado de desenvolvimento
de software.
Disciplina
Gerenciamento e Qualidade de
Software
Resumo visual
Disciplina
Gerenciamento e Qualidade de
Software
Referências
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: Uma abordagem pro�ssional. 9. ed.
Porto Alegre: AMGH, 2021.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011.
,
Unidade 4
Modelagem, riscos, comunicação e diagramas
Aula 1
Conceito de modelagem
Introdução
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, a modelagem de software é um processo utilizado na tecnologia para representar
visualmente e de forma estruturada os diferentes aspectos de um sistema. Ela envolve a criação
de representações abstratas e detalhadas que ajudam a compreender, analisar, projetar e
comunicar os diversos componentes de um sistema.
Esta modelagem usa diversas técnicas e ferramentas para criar modelos que representam
diferentes perspectivas do sistema, como modelos de processos, modelos de dados, modelos de
comportamento, modelos de interface, modelos de arquitetura e modelos de implementação.
Nesta aula, temos como objetivo fornecer uma compreensão básica da gestão da qualidade de
software (GQS) com o conceitode modelagem de sistemas de informação. Você obterá todo o
conhecimento necessário dos principais conceitos, técnicas e práticas relacionadas a estes
temas, compreendendo a importância da qualidade de software e da modelagem na criação de
software e�cientes e con�áveis.
Conceito de modelagem de sistemas de informação
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, atualmente existem várias técnicas e ferramentas de modelagem disponíveis no
mercado, seja on-line ou standalone, para criar os mais diversos modelos possíveis,
representando as perspectivas esperadas do sistema, a depender de cada proposta e situação.
Pressman e Maxim (2021) dizem que os modelos mais utilizados para projetar sistemas são:
Modelos de processos: representam atividades, �uxos de trabalho e interações dentro de um
sistema. Podemos mencionar diagramas de �uxo de processos, diagramas de atividades e
�uxogramas como exemplos de modelos utilizados para representar processos de forma visual.
Modelos de dados: representam a estrutura e organização dos dados dentro do sistema.
Podemos mencionar o modelo de entidade relacionamento (MER), diagramas de classe e
Disciplina
Gerenciamento e Qualidade de
Software
diagramas de banco de dados como exemplos de modelos usados para representar os dados e
as suas relações.
Modelos de comportamento: representam o comportamento dinâmico do sistema ao longo do
tempo. Mencionamos como exemplos diagramas de sequência, diagramas de estado e
diagramas de colaboração, utilizados para descrever o comportamento das partes do sistema.
Modelos de interface: representam a comunicação entre os diferentes componentes do sistema
e os seus usuários, como protótipos de interface e wireframes. Esses modelos ajudam a
visualizar como os usuários deverão interagir com o sistema.
Modelos de arquitetura: representam uma estrutura global do sistema, incluindo os
componentes, todas as suas relações e dependências. Os diagramas de componente e
diagramas de pacotes são ótimos exemplos de modelos utilizados para representar a arquitetura
do sistema.
Modelos de implementação: representam os detalhes técnicos que são relacionados a
implementação do sistema, como a infraestrutura de hardware, as con�gurações de software e
as possíveis integrações com outros sistemas.
Pode-se dizer que a modelagem de sistemas de informação desempenha um papel crucial no
desenvolvimento de qualquer software, e principalmente na gestão de projetos da tecnologia da
informação (TI), pois ajudam a identi�car os requisitos, compreender toda arquitetura existente
no software e melhorar soluções desenvolvidas. Ainda possibilita uma melhor comunicação
entre os membros da equipe e os principais stakeholders, e facilita a detecção precoce de
possíveis problemas e erros de design. Diferentes metodologias, como UML (linguagem de
modelagem uni�cada) e BPMN (notação de modelagem de processos de negócio), podem ser
utilizadas para criar vários modelos, dependendo das necessidades do projeto.
Conceito de requisito
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, já que entendemos os conceitos iniciais da modelagem de sistemas de informação, e
vimos alguns modelos que são utilizados, vamos falar de requisitos. Segundo Pressman e Maxim
(2021), requisitos são as especi�cações formais e detalhadas de funcionalidades ou
características de qualidade que um sistema de software deve ter.
Pressman e Maxim (2021) ainda complementam, informando que os requisitos de software
representam as necessidades ou condições a serem satisfeitas para atender a um contrato
padrão, especi�cação ou outro documento formalmente estabelecido entre os stakeholders.
Ou seja, os requisitos são as descrições claras e documentadas das funcionalidades contendo
restrições e comportamentos esperados de um software. Estes têm o papel de formar uma base
para o desenvolvimento, para o projeto e para os testes de software, garantindo que todos os
envolvidos tenham uma compreensão comum das expectativas em relação ao produto.
Pressman e Maxim (2021) identi�cam vários tipos de requisitos no contexto de engenharia de
software. Estes tipos de requisitos manifestam diferentes aspectos relacionados ao software, e
ajudam a especi�car detalhes minuciosos que são necessários para o desenvolvimento do
produto. A seguir estão descritos os principais tipos de requisitos.
Requisitos funcionais: descrevem as funcionalidades especí�cas que o sistema deve ter, como
menu, botões, relatórios e disparos de e-mails.
Requisitos não funcionais: descrevem os atributos de qualidade que o sistema deve ter, como
desempenho, usabilidade e con�abilidade. Alguns conceitos de requisitos não funcionais são:
Requisitos de qualidade: de�nem a qualidade geral que um sistema deve ter, como
desempenho, con�abilidade, segurança e usabilidade.
Requisitos de desempenho: especi�cam metas de desempenho, como tempo de resposta,
velocidade de processamento e escalabilidade do sistema.
Disciplina
Gerenciamento e Qualidade de
Software
Requisitos de usabilidade: indicam características do sistema que afetam a facilidade de
uso e a experiência do usuário.
Requisitos de segurança: descreve os recursos e as medidas necessárias para proteger o
sistema contra ameaças e ataques maliciosos.
Requisitos de con�abilidade: estabelecem as expectativas para disponibilidade,
manutenção e capacidade do sistema de funcionar sem falhas.
Requisitos de portabilidade: de�nem a capacidade do sistema de ser executado em
diferentes ambientes e plataformas.
Requisitos de design: especi�cações mais detalhadas que descrevem como o sistema deve ser
implementado para atender aos requisitos funcionais e não funcionais.
Requisitos de desenvolvimento: são diretrizes para a equipe de desenvolvimento, como boas
práticas de desenvolvimento, frameworks e ferramentas a serem usadas para desenvolvimento
de software.
Requisitos de documentação: indicam os detalhes da documentação que deve ser produzida,
incluindo manuais do usuário, guias de instalação e documentação técnica.
Requisitos legais e regulatórios: referem-se a requisitos impostos por lei, regulamentos, normas
da indústria ou requisitos de conformidade, como a Lei Geral de Proteção de Dados (LGPD).
Todos os requisitos citados são essenciais para se de�nir e entender as expectativas do cliente
em relação ao software a ser desenvolvido. Cada tipo de requisito contribui para a construção de
um software que atenda a todos os objetivos de negócio e às necessidades dos usuários �nais.
Gestão de requisito (análise e documentação dos requisitos do software e
validação com os stakeholders)
Disciplina
Gerenciamento e Qualidade de
Software
Segundo Pressman e Maxim (2021), a gestão de requisitos é o processo de compreender,
documentar, organizar e controlar as necessidades dos stakeholders em relação ao software que
será desenvolvido. A gestão de requisitos envolve uma análise detalhada dos requisitos de
software e precisa ter uma validação contínua com os stakeholders nos artefatos que a gestão
gera para garantir que o sistema atenda às expectativas dos clientes. Pressman e Maxim (2021)
dizem que a gestão de requisitos é “Uma disciplina que de�ne o que é necessário para um
software ser desenvolvido dentro de limitações organizacionais e tecnológicas”.
Os mesmos autores também diz que a gestão de requisitos inclui várias atividades inter-
relacionadas, que são:
Elicitação de requisitos: envolve a coleta de informações das partes interessadas para entender
suas necessidades, expectativas e objetivos do sistema.
Análise de requisitos: compreende a veri�cação dos requisitos de forma mais detalhada e
consistente, identi�cando com precisão os requisitos funcionais e não funcionais do sistema.
Documentação de requisitos: consiste em registrar os requisitos de forma clara e organizada,
utilizando documentos, diagramas, modelos e outras formas de comunicação compreensíveis
para os envolvidos do projeto.
Validação de requisitos: envolve a revisão dos requisitos com os stakeholders paracon�rmar que
foram atendidos corretamente em suas necessidades.
Rastreabilidade de requisitos: acompanha a evolução dos requisitos ao longo do projeto,
assegurando que todos estejam alinhados com suas especi�cações e documentações.
Disciplina
Gerenciamento e Qualidade de
Software
A gestão de requisitos, de acordo com Pressman e Maxim (2021), ajuda a estabelecer uma base
sólida do projeto, reduzindo os riscos de trabalho, falhas e insatisfações dos usuários �nais.
Videoaula: Conceito de modelagem
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante! Ao longo do conteúdo, você pôde entender o conceito de modelagem de
sistemas  e de requisitos de software, e as melhores formas de gerenciá-los.
Fica evidente que a partir dos conceitos mencionados neste material gerenciar os requisitos
favorece o desenvolvimento e a entrega do software.
Neste vídeo, você conhecerá os principais conceitos e ideias relacionados às melhores práticas
de análise de requisitos.
Saiba mais
Disciplina
Gerenciamento e Qualidade de
Software
Com o intuito de potencializar todo o conhecimento adquirido a respeito dos conceitos de
modelagem de sistemas e gestão de requisitos, indicamos o livro Processos de Software, de
Polyanna Fabris e Luis Perini. A obra aborda de uma maneira simples e clara o tema engenharia
de requisitos de software, assim como faz vários apontamentos acerca das melhores práticas
para a modelagem de sistemas de informações que são utilizados na atualidade.
 
Referências
https://biblioteca-virtual.com/detalhes/ebook/608704eb54aa8872fc616ec6
Disciplina
Gerenciamento e Qualidade de
Software
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem pro�ssional. 9. ed.
Porto Alegre: AMGH, 2021.
Aula 2
Gestão de riscos
Introdução
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, a gestão de risco, no contexto de gerenciamento e qualidade de software, refere-se ao
processo de identi�cação, avaliação, análise e mitigação dos riscos associados ao
desenvolvimento, manutenção e operação do software. A gestão de risco busca antecipar e lidar
com situações incertas que podem impactar negativamente uma entrega bem-sucedida, visando
minimizar ameaças potenciais e aproveitar as oportunidades de melhorar consideravelmente a
qualidade, a con�abilidade e a e�cácia do software.
No contexto de gerenciamento de softwares, consideramos que os riscos podem sofrer
alterações ao longo do tempo por causa de mudanças que ocorrem no projeto. Assim, a gestão
de riscos tem como papel fundamental proporcionar uma entrega bem-sucedida, minimizando
impactos negativos em um software que já está em operação.
Nesta aula abordaremos conceitos relacionados à gestão de riscos, que é um tema para quem
busca garantir uma entrega con�ável, propondo um conjunto de operações e o acompanhamento
contínuo de sistemas.
Identi�cação e avaliação dos riscos que podem afetar o projeto
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, identi�car e avaliar os riscos no projeto ajuda a mitigar efeitos negativos dos mais
variados, complexos e abstratos do projeto. Pressman e Maxim (2021) a�rmam que a
identi�cação de riscos é o processo de reconhecer e listar possíveis eventos ou condições que
impactam negativamente o projeto de software. Os autores complementam informando que
estes eventos ou condições podem variar de atrasos no cronograma, problemas de qualidade de
software e recursos insu�cientes até a mudanças nas necessidades do cliente.
Pressman e Maxim (2021) ainda ressaltam que os principais passos envolvidos relacionados ao
gerenciamento de riscos em qualidade de software devem incluir:
Identi�cação dos riscos: neste estágio, a equipe deve localizar os riscos que poderão de alguma
forma afetar o projeto de software. Podem ser riscos técnicos, riscos de prazo e riscos
�nanceiros, entre vários outros possíveis.
Análise de riscos: assim que identi�cados, os riscos precisam ser analisados com a �nalidade de
minimizar sua ocorrência no projeto. Essa ação tem a �nalidade de priorizar os riscos de maior
impacto para o projeto.
Planejamento de respostas aos riscos: a partir da análise dos riscos, a equipe deverá criar um
planejamento de ação para lidar com os riscos encontrados, determinando estratégias para
encontrar possíveis riscos, e transferindo parte destes riscos para terceiros, ou aceitando o risco
com planos de contingência, ou seja, de maneira alternativa.
Monitoramento e controle de riscos: durante todo o ciclo de vida do projeto, todos os riscos
encontrados devem ser monitorados. Isso envolve acompanhar a evolução desses riscos,
Disciplina
Gerenciamento e Qualidade de
Software
analisando todas as possíveis estratégias de mitigação que estão sendo implementadas para
ajustar o planejamento de gestão de riscos, conforme for necessário.
Comunicação de riscos: a equipe deverá manter todas as principais partes interessadas
informadas de todos os possíveis riscos identi�cados, como também das estratégias traçadas
para lidar com eles. A comunicação transparente ajudará a evitar possíveis surpresas
desagradáveis durante todo o projeto.
Documentação de riscos: é necessário manter todos os registros detalhados dos riscos
identi�cados, desde estratégias de análise a todas as ações tomadas para lidar com os riscos
encontrados. Isso permitirá que a equipe aprenda com projetos anteriores e melhore
continuamente todos os seus processos.
Revisões e atualizações contínuas: o gerenciamento de riscos não deve ser caraterizado como
um único processo, pois ele deve ser realizado de forma contínua ao longo de todo o projeto,
com revisões regulares para avaliar a e�cácia das estratégias para gerenciar os riscos, propondo
ajustes sempre que necessário.
Caro estudante, vimos que gerenciar riscos é uma prática que visa identi�car e mitigar todas as
possíveis ameaças que podem afetar o projeto de software. Esse gerenciamento não pode
eliminar todas as possibilidades, mas pode ajudar a minimizar seus impactos negativos e
melhorar as chances de sucesso para o projeto.
Estratégias para mitigar os riscos
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, como já conseguimos identi�car os riscos que podem afetar um projeto, vamos
conhecer as estratégias para analisar e mitigar esses riscos. Para Pressman e Maxim (2021),
existem várias estratégias que servem para mitigar os riscos, e entre elas podemos mencionar:
Identi�cação de riscos: identi�ca os possíveis riscos associados ao projeto. A identi�cação pode
ser realizada com análises detalhadas do projeto, brainstorming com toda a equipe e consulta
com especialistas. Ter uma compreensão clara de todos os riscos é de fundamental importância
para gerenciar de forma satisfatória a mitigação dos riscos.
Análise de riscos: avalia cada risco que é identi�cado, analisando sua possibilidade de
ocorrência e principalmente do impacto que o projeto possa sofrer. Isso ajuda a criar uma ordem
de prioridades com maior potencial de impacto e alocar recursos para um melhor gerenciamento
de riscos.
Planejamento de mitigação: desenvolve planos especí�cos relacionados com cada risco
identi�cado. Isso pode incluir a de�nição de estratégias e a de�nição de ações de contingência
para minimizar o impacto, caso o risco se materialize.
Monitoramento contínuo: monitora constantemente os riscos e garante que todas as estratégias
de mitigação sejam implementadas conforme o planejado. Envolve uma revisão de forma regular
dos planos de mitigação.
Comunicação e�ciente: visa a uma comunicação aberta e e�caz com todos os envolvidos. Isso
inclui informar a equipe, os clientes e os stakeholders a respeito dos riscos identi�cados, as
práticas de mitigação em vigor e qualquer alteração para os planos de mitigação.
De�nição de responsabilidades: atribui responsabilidades claras na implementação das
estratégias de mitigação,com as quais cada membro da equipe deve entender sua função e ser
capaz de executá-la de maneira e�caz.
Uso de melhores práticas: utiliza experiências anteriores e melhores práticas da indústria para
orientar todas as melhores estratégias de mitigação, fazendo uso de lições aprendidas dos
projetos anteriores para evitar erros semelhantes.
Prototipagem e interação: a prototipagem é a abordagem que ajuda a mitigar riscos. Ao
desenvolver protótipos, é possível identi�car problemas e desa�os antes que eles se tornem
riscos signi�cativos ao projeto �nal.
Treinamento e capacitação: certi�ca que a equipe esteja adequadamente treinada e capacitada
para tratar com todos os riscos identi�cados. Isso pode envolver treinamento adicional e
aprimoramento de habilidades técnicas.
Aprendizado contínuo: após a conclusão do projeto, deve-se fazer uma retrospectiva para avaliar
como os riscos foram tratados e como todas as estratégias ou ações foram aplicadas. Esta
estratégia fornece informações valiosas para os projetos futuros e contribui para um ciclo de
melhoria contínua.
É importante salientar que todas essas estratégias são princípios gerais, e a aplicação delas
poderá variar de acordo com a natureza do projeto.
Implementação de gerenciamento de risco
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, Pressman e Maxim (2021) a�rmam que a implementação prática para gerenciar os
riscos de software envolve uma abordagem sistemática e contínua para avaliar, identi�car e
mitigar possíveis riscos. Logo, mencionamos alguns passos que podem ser seguidos:
Identi�cação de riscos
Contar com uma equipe multidisciplinar que inclua membros técnicos aptos para gerenciar
projetos.
Fazer sessões de brainstorming com a �nalidade em identi�car possíveis riscos em todas
as fases do ciclo de vida do software, desde requisitos até a implementação e operação.
Análise e avaliação de riscos
Avaliar cada risco que é identi�cado, tomando como base a possibilidade de ocorrência no
projeto como um todo.
Tratar com grau de prioridade os riscos com mais importância, dando mais atenção a
todos os riscos de alta gravidade e alta probabilidade.
Planejamento de mitigação
Desenvolver planos de ação especí�cos com a �nalidade de tratar todos os riscos
identi�cados, incluindo de�nição de estratégias de mitigação, planos de contingência e
Disciplina
Gerenciamento e Qualidade de
Software
alocação de recursos extras, se for necessário.
De�nir responsabilidades claras para a realização desses planos.
Implementação de medidas de controle
Integrar práticas para gerenciar riscos nas atividades cotidianas de desenvolvimento de
software.
Realizar revisões de código para identi�car vulnerabilidades e erros antes que afetem a
qualidade.
Fazer testes automatizados, incluindo testes de unidade, testes de integração e testes de
aceitação, entre outros.
Utilizar ferramentas de análise estática e dinâmica para identi�car possíveis problemas no
código e nas con�gurações.
Monitoramento contínuo
Manter uma lista atualizada de todos os riscos que foram identi�cados nas estratégias de
mitigação.
Realizar revisões regulares do processo e do status dos riscos.
Integrar o monitoramento de riscos nas reuniões regulares de acompanhamento do projeto.
Comunicação e transparência
Manter os interessados informados de todos os riscos identi�cados e as ações tomadas
para mitigá-los.
Caso ocorra o surgimento de novos riscos, ou se as estratégias precisarem ser ajustadas,
deve-se comunicar essas mudanças o mais rápido possível.
Aprendizado e melhorias
Após a conclusão do projeto, deve-se conduzir uma análise para avaliar como os riscos
foram tratados e como as estratégias funcionaram.
Deve-se também identi�car as lições aprendidas e as recomendações para melhorar a
gestão de riscos em futuros projetos de software.
Portanto, é importante lembrar que a gestão de riscos é um processo altamente interativo. À
medida que o projeto avança, novos riscos podem surgir e as condições podem mudar, exigindo
adaptações contínuas.
Videoaula: Gestão de riscos
Este conteúdo é um vídeo!
Disciplina
Gerenciamento e Qualidade de
Software
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante! Durante esta aula, foi possível entender o conceito relacionado à gestão de riscos
para um projeto de software. Apresentamos estratégias de identi�cação e avaliação de riscos e
como mitigá-los. Fica evidente que o gerenciamento de riscos é um tema repleto de obstáculos e
desa�os constantes. Neste vídeo, você entenderá de uma forma objetiva o conceito de riscos e
como identi�cá-los de uma maneira clara e precisa.
Saiba mais
Com o intuito de ampliar os conhecimentos adquiridos a respeito de gerenciamento de riscos,
indicamos o livro Gestão de Projetos de Software, de Marcio Artero. Este material disponibiliza
um conteúdo excepcional relacionado ao gerenciamento de riscos, com vários apontamentos e
exemplos práticos de aplicação.
 
Referências
https://biblioteca-virtual.com/detalhes/ebook/6087054354aa8872fb666adc
Disciplina
Gerenciamento e Qualidade de
Software
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem pro�ssional. 9. ed.
Porto Alegre: AMGH, 2021.
Aula 3
Gestão de comunicação
Introdução
Disciplina
Gerenciamento e Qualidade de
Software
A gestão de comunicação se refere a um conjunto de práticas e estratégias utilizadas para
facilitar a comunicação entre todas as partes envolvidas em um projeto de desenvolvimento de
software. Isso inclui membros da equipe de desenvolvimento, stakeholders, clientes, usuários
�nais e outros envolvidos no ciclo de vida do software. O objetivo principal da gestão de
comunicação é garantir que todas as informações relevantes sejam compartilhadas de forma
clara e oportuna, a �m de apoiar o sucesso do projeto.
Pode-se considerar ainda alguns aspectos-chave para a gestão de comunicação no contexto do
gerenciamento e qualidade de software: a identi�cação das partes interessadas, o plano de
comunicação, a comunicação interna, a comunicação externa, o gerenciamento de con�itos, a
documentação, as ferramentas de comunicação, e o feedback e melhoria contínuos.
Uma gestão e�caz da comunicação ajuda a evitar mal-entendidos, atrasos no projeto e
problemas de qualidade, contribuindo para o sucesso geral do projeto e garantindo que o produto
atenda a todas as expectativas e requisitos dos stakeholders.
Nesta aula, veremos que a gestão da comunicação é um tema crítico que abrange uma série de
atividades destinadas a garantir que a comunicação seja e�caz, transparente e adaptada às
necessidades de todas as partes envolvidas no projeto. Ao integrar uma abordagem robusta de
gestão de comunicação, as organizações podem melhorar a qualidade de seus softwares,
reduzindo os possíveis riscos e aumentando as chances de sucesso para o projeto.
Conceito e estratégias para comunicação dos principais envolvidos
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, é importante mencionar que a comunicação e�caz com os principais envolvidos em
um projeto de software é essencial para o sucesso. Os principais envolvidos geralmente incluem
a equipe de desenvolvimento, os stakeholders internos (como gerentes, líderes de equipe e
membros de equipe de qualidade) e os stakeholders externos (como clientes, usuários �nais e
outros interessados).
Segundo Pressman e Maxim (2021), a comunicação e�caz com os principais envolvidos para um
projeto de software é essencial para garantir que o software atenda às necessidades e
expectativas relevantes, com feedback e entendimento mútuos entre toda a equipe de
desenvolvimento e stakeholders. Eles ainda recomendam várias estratégias para garantir uma
comunicação e�caz com todos os principais envolvidos, que são:
Entender as necessidades do cliente:
Fazer reuniões e entrevistas para identi�car as necessidades e requisitos dos clientes.
Usar questionáriose pesquisas para coletar informações adicionais.
Documentar e validar as necessidades do cliente antes de iniciar o desenvolvimento.
Estabelecer um plano de comunicação:
Criar um plano de comunicação que descreva quem precisa ser informado, quando, e quais
informações serão compartilhadas.
De�nir canais de comunicação adequados, como reuniões, relatórios de status, e-mails etc.
Disciplina
Gerenciamento e Qualidade de
Software
Comunicar regularmente os stakeholders:
Fazer reuniões com os stakeholders para informá-los do progresso do projeto, de
atualizações e marcos alcançados.
Fornecer relatórios de status e documentação que seja clara e compreensível para o
público-alvo.
Gerenciar mudanças de requisitos:
Comunicar claramente as mudanças nos requisitos dos projetos e seu impacto no
cronograma e no escopo.
Manter um registro de todas as mudanças e obter a aprovação dos stakeholders
Solicitar e incorporar feedback:
Estar aberto a feedback dos stakeholders e implementar as melhorias sugeridas sempre
que apropriado.
Promover um ambiente em que os stakeholders se sintam confortáveis em fornecer
feedback construtivo.
Gestão de riscos de comunicação:
Identi�car possíveis riscos de comunicação, como mal-entendidos ou falta de
comunicação, e desenvolver planos de mitigação para eles.
Lidar com con�itos de interesses:
Reconhecer e lidar com con�itos de interesses entre diferentes stakeholders de maneira
justa e equitativa.
Todas estas estratégias são baseadas nas diretrizes que Pressman e Maxim (2021) que visa
promover uma comunicação e�caz e colaborativa entre a equipe de desenvolvimento de
software e os principais envolvidos, contribuindo para o sucesso do projeto e a satisfação das
partes interessadas.
Portanto, a comunicação e�caz com os principais envolvidos em um projeto de software é
fundamental para o sucesso do projeto, pois ajuda a garantir que o software seja desenvolvido de
acordo com as necessidades e expectativas dos stakeholders, reduzindo riscos, aumentando a
transparência e promovendo um ambiente de colaboração. Ela desempenha um papel crucial em
todas as fases do ciclo de vida do software, desde a concepção até a entrega, e é essencial para
assegurar que o projeto alcance os seus objetivos, cumpra os prazos e mantenha a qualidade.
Então, investir em uma comunicação e�caz é um imperativo para qualquer equipe de
desenvolvimento de software que busca o sucesso e a satisfação de seus clientes e usuários
�nais.
Disciplina
Gerenciamento e Qualidade de
Software
Conhecer as principais técnicas para comunicação dos principais envolvidos
Estudante, até este ponto foram abordadas as principais estratégias para manter uma plena
comunicação entre todos os envolvidos em um projeto de software. Vamos falar de algumas das
principais técnicas para conseguir se comunicar com os principais envolvidos em um projeto,
pois a gestão de comunicação é considerada como uma parte crucial do gerenciamento de
projetos de software. Pressman e Maxim (2021) abordam várias técnicas para facilitar a
comunicação entre os principais envolvidos em um projeto. A seguir, são mencionadas algumas
das principais técnicas:
Reuniões de status e acompanhamento: fazer reuniões periódicas para atualizar os principais
envolvidos acerca do progresso do projeto. Essas reuniões podem ocorrer semanalmente ou em
intervalos de�nidos, e são uma oportunidade para discutir problemas, obstáculos e
principalmente os próximos passos.
Relatórios de status: além das reuniões, é útil criar relatórios de status que resumam o estado
atual do projeto. Esses relatórios devem incluir informações do progresso, os marcos
alcançados, os problemas identi�cados e as ações corretivas planejadas.
Documentação do projeto: manter uma documentação clara e abrangente do projeto é essencial.
Isso inclui documentação técnica, especi�cações de requisitos, diagramas de arquitetura, planos
de teste e outros documentos relevantes. Essa documentação serve como uma fonte de
referência para todos os envolvidos.
Disciplina
Gerenciamento e Qualidade de
Software
Ferramentas de gestão de projetos: uso de ferramentas de gestão de projetos, como Microsoft
Project, Trello e Jira, para ajudar no planejamento, no acompanhamento e no gerenciamento de
tarefas. Essas ferramentas permitem que os envolvidos visualizem o progresso do projeto de
forma mais clara e organizada.
Comunicação escrita e eletrônica: utilizar e-mails, mensagens instantâneas, intranets e outras
formas de comunicação eletrônica para trocar informações de forma e�ciente. Essas
ferramentas são particularmente úteis para distribuir documentos e atualizações instantâneas.
Treinamento e comunicação: é importante garantir que os membros da equipe e os principais
envolvidos tenham as habilidades de comunicação necessárias para se expressarem de forma
clara e e�caz. Isso pode incluir treinamento em habilidades de apresentação e comunicação
escrita.
Feedback e avaliação: estabelecer um processo contínuo de feedback e avaliação para identi�car
problemas de comunicação e melhorar constantemente a e�cácia da comunicação no projeto.
Resolução de con�ito: ter procedimentos de�nidos para a resolução de con�itos e disputas entre
os envolvidos no projeto. Isso pode incluir a nomeação de um mediador ou a criação de um
comitê de resolução de con�itos.
Canais de comunicação: de�nir claramente os canais de comunicação que serão utilizados no
projeto. Isso inclui especi�car quem deve ser informado sobre o que e quando.
Comunicação interpessoal: incentivar a comunicação aberta e construtiva entre os membros da
equipe e os principais envolvidos. Isso ajuda a evitar mal-entendidos e a promover um ambiente
de trabalho saudável.
A gestão de comunicação em projetos de software é fundamental para o sucesso do projeto. As
técnicas mencionadas por Pressman e Maxim (2021) são projetadas para garantir que todas as
partes interessadas estejam alinhadas, informadas e capazes de colaborar e�cazmente durante
todas as fases do projeto.
Implementação da gestão da comunicação dos principais envolvidos
Disciplina
Gerenciamento e Qualidade de
Software
Segundo Pressman e Maxim (2021), o processo de implementação da gestão de comunicação
para um projeto de software envolve uma série de etapas e práticas para garantir uma
comunicação e�caz entre os principais envolvidos, e para estes podemos mencionar os
considerados passos-chave para a implementação em um projeto de software. Veja a seguir:
Identi�cação das partes interessadas: o primeiro passo é identi�car todas as partes interessadas
no projeto de software. Isso inclui não apenas a equipe de desenvolvimento, mas também os
clientes, usuários �nais, gerentes, patrocinadores e qualquer outra pessoa que tenha interesse no
projeto.
De�nição dos requisitos de comunicação: determine quais informações são necessárias para
cada parte interessada. Isso pode incluir relatórios de status, atualizações do projeto, problemas
identi�cados e solicitações de alterações, entre outros.
Desenvolvimento do plano de comunicação: crie um plano de comunicação detalhado que
descreva como a comunicação será gerenciada ao longo do projeto. Isso deve incluir a
frequência das comunicações, os canais de comunicação a serem usados (e-mail, reuniões,
relatórios etc.) e a quem cada tipo de comunicação será direcionado.
De�nição de responsabilidades: atribua responsabilidades claras para cada tipo de comunicação
e para cada parte interessada. Isso garantirá que cada pessoa saiba o que é esperado dela em
termos de comunicação.
Estabelecimento de ferramentas de comunicação: escolha as ferramentas de comunicação
apropriadas para o projeto. Isso pode incluir ferramentas de gerenciamento de projetos, sistemas
Disciplina
Gerenciamento e Qualidade de
Software
de e-mail, software de videoconferência etc.
Monitoramento e controle da comunicação: acompanhe regularmente a e�cácia da comunicação
no projeto. Certi�que-se de que as informações estão sendo transmitidas de maneira e�ciente e
de que as partes interessadasestão recebendo as informações de que precisam.
Avaliação contínua: faça avaliações periódicas do plano de comunicação e ajuste-o conforme
necessário. À medida que o projeto evolui, as necessidades de comunicação podem mudar.
Comunicação transparente: promova uma cultura de comunicação transparente, em que todos
os envolvidos se sintam à vontade para relatar problemas, fazer perguntas e compartilhar
informações relevantes.
Treinamento da equipe: certi�que-se de que a equipe de projeto esteja treinada e consciente da
importância da comunicação e�caz.
Resolução de con�itos: esteja preparado para lidar com con�itos de comunicação à medida que
surgirem. Ter um processo claro para resolver mal-entendidos e disputas pode ser crucial para o
sucesso do projeto.
A implementação da gestão da comunicação é fundamental para evitar mal-entendidos, atrasos
e problemas no projeto de software. Garantir que todas as partes interessadas estejam bem-
informadas e que a comunicação seja e�caz contribuirá para o sucesso do projeto.
Vimos que a gestão e�caz da comunicação em projetos de software é fundamental para evitar
problemas e garantir o sucesso. Ela não apenas envolve a transmissão de informações, mas
também a criação de um ambiente de trabalho colaborativo e e�ciente. Adaptar as práticas de
gestão da comunicação de acordo com as necessidades especí�cas do projeto e das partes
interessadas é crucial para alcançar resultados positivos.
Videoaula: Gestão de comunicação
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante! Durante esta aula, foi possível entender a gestão da comunicação em projetos de
software, um elemento fundamental para o sucesso na entrega de soluções de tecnologia. Ela se
concentra na coordenação e�caz das informações e na comunicação entre as partes envolvidas
em um projeto de software, incluindo membros da equipe, partes interessadas, clientes e
usuários �nais. Um bom gerenciamento da comunicação ajuda a evitar mal-entendidos, atrasos e
problemas de escopo, aumentando as chances de alcançar os objetivos do projeto. Isso envolve
a de�nição clara de papéis e responsabilidades de comunicação, a escolha das ferramentas
adequadas para troca de informações, a criação de planos de comunicação e a manutenção de
um �uxo contínuo de informações ao longo de todo o ciclo de vida do projeto. Em resumo, a
Disciplina
Gerenciamento e Qualidade de
Software
gestão da comunicação em projetos de software é essencial para garantir a colaboração e�caz e
a entrega bem-sucedida de produtos de software.
Neste vídeo, você conhecerá as principais técnicas de comunicação, e entenderá como ocorre a
implementação desta gestão com os principais envolvidos em um projeto de software.
Saiba mais
Com o intuito de ampliar os conhecimentos adquiridos a respeito da gestão da comunicação em
projetos de software, indicamos o livro Gestão de Projetos de Software, de Marcio Artero. Este
material disponibiliza um conteúdo extremamente rico relacionado à gestão da comunicação,
com vários apontamentos e exemplos práticos de aplicação, vários conceitos complementares a
respeito do tema em questão.
 
Referências
https://biblioteca-virtual.com/detalhes/ebook/6087054354aa8872fb666adc
Disciplina
Gerenciamento e Qualidade de
Software
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: uma abordagem pro�ssional. 9. ed.
Porto Alegre: AMGH, 2021.
Aula 4
Diagramas para Gerenciamento e Qualidade de Software
Introdução
Disciplina
Gerenciamento e Qualidade de
Software
Diagramas para gerenciamento e qualidade de software são representações grá�cas que ajudam
a visualizar, comunicar e planejar atividades relacionadas ao desenvolvimento e manutenção de
software, bem como garantir a qualidade do produto �nal.
Podemos mencionar alguns tipos de diagramas que são frequentemente utilizados para
favorecer uma maior qualidade no gerenciamento de softwares, como diagrama de Gantt,
diagrama de rede PERT, diagrama de caso de uso, diagrama de sequência, diagrama de classes,
diagrama de componentes, diagrama de implantação, diagrama de �uxo de dados, diagrama de
estado e o diagrama de transição de estados.
Para garantir a qualidade do software, esses diagramas podem ser usados em conjunto com
práticas de gerenciamento de projetos e processos de desenvolvimento, como o modelo de
maturidade de capacidade (CMMI), metodologias ágeis (Scrum, Kanban etc.), revisões de código
e testes de software, entre outros. Eles ajudam a planejar, monitorar e controlar o projeto, bem
como a assegurar que o software atenda aos padrões de qualidade estabelecidos.
Esses diagramas desempenham um papel crucial no gerenciamento de projetos de software e na
garantia de qualidade, permitindo uma melhor compreensão, planejamento e comunicação de
informações essenciais ao longo do ciclo de vida do desenvolvimento de software. Eles ajudam a
identi�car problemas precocemente, melhorar a colaboração da equipe e tomar decisões
informadas para entregar um software de alta qualidade aos usuários �nais.
Diagrama de Gantt
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, o diagrama de Gantt é uma ferramenta grá�ca usada na gestão de projetos para
representar visualmente o cronograma de tarefas e atividades planejadas ao longo do tempo. Foi
desenvolvido por Henry L. Gantt no início do século XX e tornou-se uma ferramenta padrão na
gestão de projetos.
Pressman e Maxim (2021) a�rmam que o diagrama de Gantt é uma ferramenta grá�ca que
representa o cronograma de um projeto de forma visual. Ele exibe as atividades do projeto ao
longo do tempo, permitindo que os gerentes de projeto e as equipes vejam as dependências
entre as tarefas e compreendam a ordem em que devem ser executadas. Eles ainda
complementam informando que este diagrama é composto por duas dimensões principais que
são:
Eixo horizontal: representa a linha do tempo do projeto, geralmente em dias, semanas ou meses,
dependendo da escala de tempo escolhida.
Eixo vertical: enumera as tarefas ou atividades do projeto.
Cada tarefa é representada por uma barra horizontal no grá�co. A posição dessa barra ao longo
do eixo horizontal indica quando a tarefa deve começar e quando deve ser concluída. A duração
da tarefa é representada pelo comprimento da barra.
O diagrama de Gantt é uma ferramenta valiosa para o planejamento e o acompanhamento de
projetos, permitindo que as partes interessadas vejam visualmente como as tarefas estão
relacionadas, quais são as datas de início e término esperadas e quais atividades são críticas
para o cumprimento dos prazos. É amplamente utilizado na gestão de projetos para facilitar o
planejamento, o monitoramento e a comunicação das atividades do projeto.
O diagrama de Gantt também pode incluir elementos adicionais para enriquecer a representação
do projeto:
Disciplina
Gerenciamento e Qualidade de
Software
Marcos: são pontos cruciais do projeto que representam eventos ou entregas importantes. Os
marcos são representados como pontos no grá�co e ajudam a destacar os momentos-chave no
cronograma do projeto.
Linhas de dependência: são linhas que conectam as tarefas no grá�co para mostrar as relações
de dependência entre elas. Isso ajuda a identi�car quais tarefas precisam ser concluídas antes
que outras possam começar, tornando a gestão de recursos e a programação mais e�cientes.
Recursos: além das tarefas e marcos, o diagrama de Gantt pode incluir informações a respeito
dos recursos (como pessoas, equipamentos ou materiais) alocados a cada tarefa. Isso ajuda a
garantir que os recursos certos estejam disponíveis quando necessário.
Legenda: geralmente, é fornecida uma legenda que explica a codi�cação de cores, símbolos ou
estilos usados no grá�co para representar diferentes tipos de tarefas, prioridades ou
responsáveis.
Datas de início e término realizadas: à medida que o projeto avança, as datas de inícioe término
reais podem ser adicionadas ao diagrama de Gantt para comparar o progresso real com o
planejado.
Escalas de tempo múltiplas: em projetos complexos, é comum ter escalas de tempo diferentes
em um único diagrama de Gantt. Isso permite uma visualização mais detalhada das tarefas de
curto prazo e uma visão geral das tarefas de longo prazo.
Estudante, o diagrama de Gantt é uma ferramenta �exível e poderosa que oferece uma
representação visual abrangente do cronograma de um projeto, ajudando na organização,
planejamento, execução e monitoramento de tarefas e atividades, bem como na comunicação
e�caz entre as partes interessadas do projeto. É uma peça fundamental na gestão de projetos
em uma variedade de setores e disciplinas.
 
Figura 1 | Exemplo de diagrama de Gantt. Fonte: elaborada pelo autor.
Diagrama de �uxo de dados
Disciplina
Gerenciamento e Qualidade de
Software
Estudante, como já entendemos o que é o que é o diagrama de Gantt, vamos abordar do
diagrama de �uxo de dados. Segundo Pressman e Maxim (2021), o termo diagrama de �uxo de
dados (DFD) é uma representação grá�ca usada na engenharia de software para modelar o �uxo
de informações em um sistema. Este diagrama é uma representação grá�ca que descreve o
�uxo de informações dentro de um sistema ou entre sistemas, e enfoca entrada de dados,
processamento de dados, armazenamento de dados e saída de dados em um sistema. Os DFDs
são compostos por símbolos grá�cos que representam processos, �uxo de dados,
armazenamento de dados e entidades externas, bem como setas que indicam o �uxo de dados
entre esses elementos.
Pressman e Maxim (2021) ainda complementam que os principais componentes de um DFD
incluem:
Entidades externas: representam fontes de dados ou destinos de dados externos ao sistema em
questão. Essas entidades podem ser pessoas, outros sistemas, sensores etc.
Processos: são as funções ou atividades que transformam os dados de entrada em dados de
saída. Os processos são representados por círculos ou elipses nos DFDs.
Fluxo de dados: são as setas que indicam a direção do �uxo de informações entre os
componentes do sistema. Eles representam como os dados são transmitidos de uma parte do
sistema para outra.
Armazenamento de dados: representam locais em que os dados são armazenados no sistema.
Isso pode incluir bancos de dados, arquivos ou qualquer outra forma de armazenamento de
Disciplina
Gerenciamento e Qualidade de
Software
dados.
Os DFDs são usados principalmente para entender e documentar o funcionamento de um
sistema, identi�car as interações entre os componentes e facilitar a comunicação entre
desenvolvedores, analistas e outras partes interessadas no projeto de software. Eles são
frequentemente usados como uma etapa inicial na modelagem de sistemas e podem ser
re�nados em níveis mais detalhados à medida que o projeto avança.
Pressman e Maxim (2021) falam que os DFDs podem ser divididos em níveis para representar a
complexidade do sistema de maneira hierárquica. Os principais níveis de DFDs são:
DFD de contexto (nível 0): este é o nível mais alto e descreve o sistema em sua totalidade,
mostrando suas interações com entidades externas. Geralmente, é composto por um único
processo que representa o sistema como um todo.
DFD de nível 1, nível 2 etc.: cada nível subsequente aprofunda a descrição do sistema em um
nível crescente de detalhes. Os processos do nível superior são decompostos em processos
mais detalhados, e os �uxos de dados são re�nados à medida que o modelo se aprofunda.
Segundo Pressman e Maxim (2021), podem ser mencionadas algumas importâncias
relacionadas ao uso de DFDs, que são:
Compreensão do sistema: DFDs são ferramentas poderosas para entender como um sistema
funciona. Eles ajudam a identi�car os componentes do sistema, suas interações e como os
dados �uem através deles.
Comunicação e�caz: os DFDs são úteis para comunicar ideias complexas de engenharia de
software de forma clara e concisa para as partes interessadas, incluindo clientes, gerentes e
membros da equipe de desenvolvimento.
Análise de requisitos: DFDs auxiliam na captura e na análise de requisitos do sistema, permitindo
que os desenvolvedores entendam os �uxos de informações necessários para atender às
necessidades do cliente.
Design e implementação: os DFDs podem servir como base para o projeto de sistemas, pois
ajudam a identi�car os principais componentes e �uxos de dados, orientando o desenvolvimento
de software.
Detecção de problemas: ao modelar o sistema de forma grá�ca, os DFDs podem ajudar a
identi�car possíveis problemas, gargalos ou inconsistências no design antes que o
desenvolvimento comece.
Documentação: os DFDs fornecem uma documentação visual do sistema, que pode ser usada
para referência futura, manutenção e treinamento de pessoal.
Em resumo, os diagramas de �uxo de dados são uma ferramenta valiosa na engenharia de
software para modelar sistemas, comunicar ideias, analisar requisitos, projetar sistemas e
garantir que o desenvolvimento de software seja direcionado de forma e�caz e e�ciente para
atender às necessidades dos usuários e das organizações. Eles desempenham um papel
fundamental em várias fases do ciclo de vida do desenvolvimento de software, desde a
concepção até a manutenção.
 
Disciplina
Gerenciamento e Qualidade de
Software
Figura 2 | Exemplo de diagrama de �uxo de dados. Fonte: Project Management Institute, Inc (2013, p. 101).
Diagrama de atividades
Disciplina
Gerenciamento e Qualidade de
Software
Um diagrama de atividades é um tipo de diagrama de UML (Uni�ed Modeling Language –
linguagem de modelagem uni�cada) usado para modelar o comportamento de um sistema,
processo ou �uxo de trabalho. Ele é amplamente utilizado na engenharia de software, na
engenharia de sistemas e em várias outras disciplinas para visualizar e descrever a sequência de
atividades, ações e decisões que ocorrem em um sistema ou processo. Podemos mencionar
alguns elementos-chave de um diagrama de atividades:
Atividades: são as tarefas ou ações que ocorrem no sistema ou processo. Cada atividade é
representada por um retângulo com cantos arredondados.
Fluxo de controle: linhas sólidas (setas) conectam as atividades, indicando a ordem em que as
atividades são executadas. Isso representa o �uxo de controle do sistema.
Decisões: diamantes são usados para representar pontos de decisão. Dependendo da condição,
o �uxo pode seguir caminhos diferentes a partir de um ponto de decisão.
Fusão de controle: representada por um losango com linhas de entrada e uma linha de saída, a
fusão de controle é usada para unir diferentes caminhos de �uxo de controle em um único
caminho.
Bifurcação de controle: também representada por um losango com uma linha de entrada e várias
linhas de saída, a bifurcação de controle é usada para dividir o �uxo de controle em vários
caminhos.
Disciplina
Gerenciamento e Qualidade de
Software
Nós iniciais e �nais: um círculo sólido é usado para representar o nó inicial, indicando onde o
�uxo de controle começa. Um círculo com um anel sólido é usado para representar o nó �nal,
indicando onde o �uxo de controle termina.
Partições: são usadas para dividir o diagrama de atividades em diferentes áreas ou grupos
funcionais, permitindo uma representação mais organizada de atividades em um sistema
complexo.
O objetivo principal de um diagrama de atividades é capturar visualmente o comportamento do
sistema ou processo, destacando as interações entre atividades e decisões. Ele é valioso para
comunicar o funcionamento de um sistema para stakeholders, analistas e desenvolvedores, bem
como para identi�car possíveis melhorias e otimizações em um processo existente. Diagramas
de atividades são especialmente úteis para modelar �uxos de trabalho, sistemas de software e
processos de negócios.
 
Figura 3 | Exemplo de diagrama de atividades. Fonte: elaborada pelo autor.
Videoaula: Diagramas para Gerenciamento e Qualidade de Software
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computadorou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
Disciplina
Gerenciamento e Qualidade de
Software
para assistir mesmo sem conexão à internet.
Estudante, nesta aula vimos que diagramas desempenham um papel crucial no gerenciamento e
na garantia de qualidade de software. Eles oferecem uma representação visual das várias
facetas de um projeto de software e ajudam a melhorar a comunicação, o entendimento e a
tomada de decisões ao longo do ciclo de vida do desenvolvimento de software.
Neste vídeo, você verá que os diagramas desempenham um papel essencial no gerenciamento e
na garantia de qualidade de software, auxiliando na comunicação, no planejamento, no design e
na documentação de sistemas. Eles permitem uma compreensão mais clara dos requisitos,
estrutura e comportamento do software, o que, por sua vez, leva a um desenvolvimento mais
e�ciente e a um software de maior qualidade.
Saiba mais
Com o intuito de aprofundar seu conhecimento acerca do uso de diagramas para o
gerenciamento e qualidade de software, indicamos o material a seguir, para propor uma
agregação complementar ao conteúdo abordado.
Processos de software, de Polyanna Fabris e Luis Perini, traz modelos e exemplos reais de uso
de vários tipos de diagramas que são fundamentais para entender, otimizar e aprimorar todo o
https://biblioteca-virtual.com/detalhes/ebook/608704eb54aa8872fc616ec6
Disciplina
Gerenciamento e Qualidade de
Software
funcionamento e entendimento dos processos nas organizações.
 
Referências
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: Uma abordagem pro�ssional. 9. ed.
Porto Alegre: AMGH, 2021.
PROJECT MANAGEMENT INSTITUTE, INC. Um Guia do Conhecimento em Gerenciamento de
Projetos (Guia PMBOK®). 5. ed. EUA: Project Management Institute, Inc, 2013. 
Aula 5
Revisão da unidade
Garantia de qualidade de software
Disciplina
Gerenciamento e Qualidade de
Software
Olá, estudante!
A gestão de qualidade de software em um projeto que vai produzir um aplicativo (ou um sistema,
portal, integração) permeia gestão de requisitos, gestão de riscos, e gestão da comunicação.
Vamos estudar mais essa relação tendo como base os ensinamentos de Pressman e Maxim
(2021).
Requisitos são as especi�cações formais e detalhadas de funcionalidades ou características de
qualidade que um sistema de software deve apresentar. Podem ser funcionais, não funcionais,
de design, de desenvolvimento, de documentação, legais ou regulatórios, entre outros (Figura 1).
Para se desenvolver um software é essencial entender quais requisitos serão atendidos e, para
isso, é necessário identi�car, analisar e transformar esses requisitos em componentes de
software.
Logo, para construirmos um software, transformaremos os requisitos em representações de
dados, processos, comportamentos, interfaces, arquitetura ou implementação. Essa
transformação é feita com o uso de técnicas e ferramentas de modelagem. Na prática, existem
várias representações possíveis; algumas são de uso bastante comum nos projetos, outras
podem ser aplicados conforme a necessidade e signi�cância. Os requisitos serão a base para a
construção de modelos a serem ilustrados ou representados por meio diagramas. Como
exemplo, um modelo de dados bastante utilizado é o modelo entidade-relacionamento (MER),
que descreve entidades, seus atributos e seus relacionamentos, e que pode ser representado em
diagramas de bancos de dados em seus aspectos conceituais, lógico e físico.
Disciplina
Gerenciamento e Qualidade de
Software
Figura 1 | Requisitos, modelos e a gestão de requisitos. Fonte: elaborada pela autora.
Requisitos podem ser obtidos de várias fontes e com várias pessoas. É bastante relevante para o
projeto conhecer todas as partes que podem contribuir para o sucesso do projeto – inclusive,
muitos dos requisitos podem ser obtidos em reuniões ou entrevistas com essas partes, que
podem ser o cliente, a alta gestão da empresa, o time de alta gestão do cliente, possíveis
fornecedores de recursos ou serviços, pessoas ou empresas impactadas direta ou indiretamente
pelo projeto etc.
A quantidade de pessoas (físicas ou jurídicas) que podem ser afetadas de alguma forma por um
projeto é extensa. Por essa razão, os projetos precisam também estabelecer um plano de
comunicação dentro de uma estratégia de gestão da comunicação (Figura 2). É relevante
conhecer as partes com quais se deve comunicar, a frequência da comunicação, e a melhor
forma de transmitir a mensagem, considerando os métodos disponíveis.
Disciplina
Gerenciamento e Qualidade de
Software
Figura 2 | Um olhar para a gestão da comunicação. Fonte: elaborada pela autora.
Um ponto de atenção é que ao longo do ciclo de vida de um projeto de desenvolvimento de
software alguns requisitos podem mudar ou ser removidos, e isso pode afetar o projeto
desenvolvido até então. Por isso a importância da gestão de requisitos ao longo de um projeto,
para adequadamente tratar essas mudanças que podem acontecer, e com isso, a importância da
comunicação adequada para que todas as partes compreendam os motivos dessas mudanças.
Chegamos a outro ponto importante para o projeto, que são os riscos (Figura 3). Um risco é um
evento que, se ocorrer, pode afetar de forma positiva ou negativa os objetivos do projeto. Dessa
forma, é importante identi�car esses riscos e analisá-los, e para cada um deles entender a
probabilidade de ocorrência e o grau de impacto no projeto. Assim é possível tomar uma decisão,
que pode envolver traçar algum plano de ação para mitigar um risco, e diminuir um impacto
negativo nos objetivos do projeto.
Disciplina
Gerenciamento e Qualidade de
Software
Figura 3 | Gestão de riscos. Fonte: elaborada pela autora.
Antes de concluirmos esta revisão, é importante também estar familiarizado com diagramas
amplamente usados em projetos de software. A sugestão são estes três diagramas: diagrama de
Gantt, diagrama de �uxo de dados e diagrama de atividades. O Quadro 1 fornece uma visão geral
de cada um deles.
 
Disciplina
Gerenciamento e Qualidade de
Software
Quadro 1 | Visão geral dos diagramas de Gantt, �uxo de dados e atividades. Fonte: elaborado pela autora.
Com isso, chegamos ao �nal desta aula de revisão dos temas de modelagem, comunicação,
riscos e diagramas. Estes temas ajudarão a potencializar sua atuação na garantia da qualidade
de software.
Disciplina
Gerenciamento e Qualidade de
Software
Bons estudos!
Videoaula: Revisão da unidade
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Olá, estudante!
Quando estudamos gerenciamento e qualidade de software, vários temas e conceitos se
intercalam para a criação de um produto de qualidade, do qual a equipe do projeto tenha orgulho
e com o qual o cliente esteja extremamente satisfeito.
Nesse sentido, é importante o estudo de três assuntos: a gestão de requisitos, com ênfase na
identi�cação dos requisitos, na análise e sua modelagem; a gestão de riscos, para identi�car os
riscos, avaliar a probabilidade e impacto e encontrar o melhor plano de ação para cada um deles;
e a gestão da comunicação, pois um projeto envolve pessoas, desde a equipe, o cliente e as
possíveis partes interessadas.
Vamos rever esses assuntos? Bons estudos!
Estudo de caso
Disciplina
Gerenciamento e Qualidade de
Software
Olá, estudante!
Para contextualizar a sua aprendizagem, imagine que você será o responsável por um projeto de
desenvolvimento de software para uma empresa de educação que deseja lançar uma nova
plataforma de aula on-line para uma importante instituição de ensino. Seu objetivo é garantir que
essa plataforma atenda às necessidades do cliente e seja entregue com sucesso, enquanto
minimiza riscos potenciais. Por essa razão, durante a fase inicial do projeto, você se tornou
responsável pela gestão de requisitos e identi�cação de riscos.
Descreva os passos que você seguiria para analisar e documentaros requisitos do software,
considerando as necessidades do cliente e de outras partes interessadas. Além disso, discuta
como você validaria os requisitos para garantir que eles estejam alinhados com as expectativas.
Considere que neste cenário seu cliente é um dos diretores da instituição de ensino, contudo, ele
quer que os requisitos sejam estruturados a partir da colaboração de professores, alunos e
funcionários.
Isso signi�ca que você precisará de�nir estratégias de comunicação apropriadas com cada um
dos per�s com os quais você vai conversar. Neste trabalho você começará a ter a visão de que
existem requisitos de grande aceitação entre as diversas pessoas, enquanto outros podem ser
divergentes, e então você precisará ter uma estratégia para de�nir de fato o que será construído.
Como você identi�caria os riscos que podem afetar o sucesso do projeto de desenvolvimento da
plataforma de aulas on-line? Liste pelo menos três possíveis riscos e explique como você os
avaliaria em termos de probabilidade e impacto. Além disso, discuta as estratégias que você
implementaria para mitigar esses riscos e garantir a entrega bem-sucedida do projeto.
Este estudo de caso ilustra a importância da gestão de requisitos e de riscos em projetos de
desenvolvimento de software. Como você atenderia as necessidades do cliente e das partes
interessadas ao mesmo tempo em que minimizaria os riscos potenciais?
Disciplina
Gerenciamento e Qualidade de
Software
Existem várias abordagens que podem ser usadas para se construir um software, considerando
metodologias tradicionais, iterativas, incrementais ou ágeis como algumas opções. Você pode
extrapolar como lidaria com a gestão de requisitos ou com a gestão de riscos considerando
também algumas dessas metodologias.
Perceba que o grande interesse neste estudo de caso é termos um software de qualidade e que o
produto desenvolvido atenda aos objetivos do cliente. Por essa razão, é muito importante
conhecer e aplicar os principais modelos de riscos e comunicação para a garantia da qualidade
de software, tendo como base o conjunto de requisitos que serão levantados na fase inicial do
projeto.
Pronto para resolver este estudo de caso? Vamos começar? Entender qual é a demanda do
cliente, traduzir para requisitos e com isso fazer a modelagem para o trabalho da equipe de
desenvolvimento são algumas das atividades mais relevantes para o desenvolvimento de
software e que interfere diretamente na qualidade do produto �nal produzido.
Bons estudos!
__________
Re�ita
Ao pensar em como coordenar as atividades envolvendo a gestão de requisitos e a gestão de
riscos, contemple também as seguintes questões:
Quais seriam algumas das partes interessadas neste projeto? Algumas sugestões:
professores da instituição; alunos da instituição (veteranos ou calouros?); fornecedores;
marketing; área de TI; diretores.
Como você conversaria com cada uma dessas partes? Ou seja, pensando que uma possível
parte nesse processo seja um aluno veterano, como você conversaria com ele? E se for um
aluno calouro, qual seria a abordagem? Seria igual ou diferente?
Quais riscos poderiam estar relacionados a cada uma dessas partes? Por exemplo, o
professor tem familiaridade com a tecnologia? O aluno terá condições de estudar? Qual
será a experiência?
Qual o papel da gestão da comunicação neste projeto? Perceba que existem várias partes
interessadas – ou stakeholders – e que a forma de se comunicar e interagir com cada uma
delas tende a ser diferente. Como você lidaria com essa variedade de papéis?
Videoaula: Resolução do estudo de caso
Este conteúdo é um vídeo!
Para assistir este conteúdo é necessário que você acesse o AVA pelo
computador ou pelo aplicativo. Você pode baixar os vídeos direto no aplicativo
para assistir mesmo sem conexão à internet.
Disciplina
Gerenciamento e Qualidade de
Software
Olá, estudante?
Esperamos que você tenha conseguido pensar no estudo de caso e resolvê-lo. Em um cenário
real muitas outras variáveis farão parte dessa análise, mas já temos alguns pontos
extremamente relevantes para pensarmos. Você estudará uma das possibilidades de resolução
deste estudo de caso. Procure avaliar e fazer as relações possíveis com a forma como você
próprio procurou resolver. Vamos começar?
Gestão de requisitos e modelagem
Para começar, você precisará entender com quais pessoas poderá obter informações,
envolvendo a identi�cação de requisitos funcionais, não funcionais, de design, desenvolvimento,
documentação, legais e regulatórios, entre outros. Você poderá relacionar quem são essas
pessoas e priorizar sua comunicação com elas conforme orientações do seu cliente.
Você terá como partes interessadas no projeto e com as quais você poderá conversar papéis
como: cliente ou patrocinador do projeto; diretores da instituição de ensino; professores; alunos
veteranos; alunos calouros; funcionários; fornecedores. Em algum estágio do projeto pode ser
interessante ouvir também futuros alunos ou mesmo ex-alunos. Logo, a abrangência de
possíveis interlocutores é bem extensa, e por isso a visão do cliente e patrocinador é bastante
importante para estabelecer um plano de comunicação adequado.
Note, portanto, que desde o início do projeto é necessário estabelecer um plano de comunicação,
indicando aspectos como propósito da comunicação, frequência, conteúdo e meio. Essa
sequência de interações permitirá a você ter um conjunto diversi�cado de dados para analisar,
documentar e validar. Você inclusive encontrará requisitos com os quais muitos interlocutores
concordem. Mas também encontrará várias demandas que podem ser divergentes, e você
precisará ter alguma estratégia para escolher com qual seguir.
Nesse processo de análise podem surgir os primeiros modelos de dados e de processos. De
alguma forma você precisará documentar os requisitos, seja fazendo uso de anotações em
aplicativos, em planilhas ou documentos ou mesmo usando softwares especí�cos para a
atividade. Isso vai depender dos recursos disponíveis para seu time, e da familiaridade que seu
time tem com esses recursos. Além, é claro, do que o próprio cliente entende como satisfatório.
Buscamos construir um software de qualidade, e esta qualidade pode ser afetada pelos
investimentos que o cliente tem ou está disposto a fazer, e pelas restrições de prazo, custo e
escopo do projeto.
Em algumas situações você precisará validar os requisitos antes de avançar para fases como a
codi�cação. Neste sentido, é bastante relevante elaborar modelo de interfaces e criar protótipos
para ouvir a opinião das partes interessadas para determinar o quanto se pode evoluir no projeto
ou se mais descobertas e modi�cações são necessárias.
Gestão de riscos
Outra solicitação no estudo de caso era pensar em pelo menos três riscos para analisar e traçar
alguma estratégia de mitigação. No Quadro 2 você terá três sugestões de riscos que podem se
intersectar ou complementar os que você pensou. Em uma atividade como esta, se espera que
você se tenha a percepção de que os riscos podem ser inúmeros, e a equipe de projeto deve
estar ciente e preparada para enfrentá-los. Muitas vezes algumas pessoas na equipe terão essa
responsabilidade como objetivo principal, como o gerente de projetos, o líder da equipe ou algum
outro membro do time.
Quadro 2 | Exemplos de riscos identi�cados para o estudo de caso.
Disciplina
Gerenciamento e Qualidade de
Software
Risco Probabilidade Impacto
Estratégia de
mitigação
Professores não
conseguirem gravar
as aulas.
Média Alto
Treinamento; suporte;
documentação.
Alunos não
conseguirem assistir
às aulas on-line.
Média Alto
Compatibilidade de
plataforma; testes de
usabilidade; suporte
ao aluno.
Indisponibilidade da
plataforma.
Alta Muito alto
Arquitetura de alta
disponibilidade;
backup;
monitoramento
contínuo.
Fonte: elaborado pela autora.
Considerações �nais
Com este estudo de caso esperamos que você tenha percebido a importância da gestão de
requisitos, da gestão de riscos e da gestão de comunicação. A gestão da qualidade de software
é extremamente importantepara a criação de um software, e transcende o pensar apenas no
código.
Neste estudo de caso se espera que você tenha percebido que a gestão de requisitos garante
que as expectativas do cliente e das partes interessadas sejam atendidas, que a gestão de riscos
surge como uma prática que ajuda a antecipar e mitigar possíveis impactos no projeto, e que a
gestão da comunicação ajuda na obtenção e compartilhamento das informações. Projetos de
software mais complexos requerem uma integração adequada dessas disciplinas para a criação
de um produto de qualidade.
Bons estudos!
Resumo visual
Disciplina
Gerenciamento e Qualidade de
Software
Fonte: elaborada pela autora.
Disciplina
Gerenciamento e Qualidade de
Software
Referências
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de Software: Uma abordagem pro�ssional. 9. ed.
Porto Alegre: AMGH, 2021.