Engenharia de Software II

Prévia do material em texto

1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ENGENHARIA DE SOFTWARE II 
 
Ivone Ascar Sauáia Guimarães 
 
 
 
 
 
 
 
 
 
2 
 
 
 
 
 
 
 
 
 
 
 
 
Ivone Ascar Sauáia Guimarães 
 
Possui graduação em Tecnologia em Processamento de Dados pelo Centro Universitário 
do Maranhão (2000), especialização em Gestão em Tecnologia e Negócios em 
Telecomunicações pela Universidade Estácio de Sá (2001) e Mestrado em Educação pela 
Universidade Católica de Brasília (2011). Cursa, neste momento a graduação em Letras - 
licenciatura pelo Centro Universitário Claretiano como conclusão prevista para 2024. 
Durante o mestrado dedicou seus estudos na área de Educação à Distância como 
elemento de inclusão social, o que culminou em sua dissertação. Tem experiência docente 
superior a 15 anos, atuando nos mais diferentes cursos como Sistemas de Informação, 
Pedagogia, Radiologia, Turismo, Engenharia Ambiental, Engenharia Civil, Engenharia de 
Petróleo, Engenharia de Produção e Administração, dentre outros, nas disciplinas de 
Informática, Informática Educacional, Fundamentos de EAD, Metodologia Científica, 
Projeto de Sistemas de Informação (TCC), Administração de Sistemas de Informação e 
Interface Homem-Máquina, dentre outras. No momento presente leciona somente no 
ensino presencial. Atuou como professora universitária na Faculdade Devry São Luís de 
julho de 2015 à janeiro de 2017 e na Universidade Ceuma de Agosto de 2003 a Julho de 
2020, onde atuou como docente dos Cursos de Engenharia Civil, Engenharia de Produção 
e Sistemas de Informação, como pesquisadora do NusTI - Núcleo de Pesquisas em Sistemas 
e Tecnologia da Informação, como membro de Conselho de Curso e de Conselho 
Universitário. Recentemente, em 2022, foi instrutora junto ao Senai para o ensino médio em 
disciplina de lógica. Atualmente trabalha em seu próprio negócio de consultoria e como 
prestadora de serviços para empresas como DTCom e Faculdade Única, como 
conteudista para a EAD, e no IGTI - XP Educação, como orientadora de projeto junto ao 
MBA. 
 
 
 
 
 
 
 
 
 
3 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ENGENHARIA DE SOFTWARE II 
1ª edição 
Ipatinga – MG 
ANO 
 
 
 
 
 
 
 
 
 
4 
 
 
FACULDADE ÚNICA EDITORIAL 
 
Diretor Geral: Valdir Henrique Valério 
Diretor Executivo: William José Ferreira 
Ger. do Núcleo de Educação a Distância: Cristiane Lelis dos Santos 
Coord. Pedag. da Equipe Multidisciplinar: Gilvânia Barcelos Dias Teixeira 
Revisão Gramatical e Ortográfica: Izabel Cristina da Costa 
Revisão/Diagramação/Estruturação: Bruna Luiza Mendes Leite 
 Fernanda Cristine Barbosa 
 Guilherme Prado Salles 
 Lívia Batista Rodrigues 
Design: Bárbara Carla Amorim O. Silva 
 Élen Cristina Teixeira Oliveira 
 Maria Eliza Perboyre Campos 
 
 
 
 
 
 
© 2021, Faculdade Única. 
 
Este livro ou parte dele não podem ser reproduzidos por qualquer meio sem Autorização 
escrita do Editor. 
 
 
 
Ficha catalográfica elaborada pela bibliotecária Melina Lacerda Vaz CRB – 6/2920. 
 
 
 
 
 
NEaD – Núcleo de Educação a Distância FACULDADE ÚNICA 
Rua Salermo, 299 
Anexo 03 – Bairro Bethânia – CEP: 35164-779 – Ipatinga/MG 
Tel (31) 2109 -2300 – 0800 724 2300 
www.faculdadeunica.com.br
http://www.faculdadeunica.com.br/
 
 
 
 
 
 
 
 
 
5 
 
 
Menu de Ícones 
Com o intuito de facilitar o seu estudo e uma melhor compreensão do conteúdo 
aplicado ao longo do livro didático, você irá encontrar ícones ao lado dos textos. Eles 
são para chamar a sua atenção para determinado trecho do conteúdo, cada um 
com uma função específica, mostradas a seguir: 
 
 
 
São sugestões de links para vídeos, documentos 
científicos (artigos, monografias, dissertações e teses), 
sites ou links das Bibliotecas Virtuais (Minha Biblioteca 
e Biblioteca Pearson) relacionados com o conteúdo 
abordado. 
 
Trata-se dos conceitos, definições ou afirmações 
importantes nas quais você deve ter um maior grau 
de atenção! 
 
São exercícios de fixação do conteúdo abordado 
em cada unidade do livro. 
 
São para o esclarecimento do significado de 
determinados termos/palavras mostradas ao longo 
do livro. 
 
Este espaço é destinado para a reflexão sobre 
questões citadas em cada unidade, associando-o a 
suas ações, seja no ambiente profissional ou em seu 
cotidiano. 
 
 
 
 
 
 
 
 
 
6 
 
 
SUMÁRIO 
 
 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE ................................. 9 
1.1 DEFINIÇÃO E IMPORTÂNCIA PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
 ................................................................................................................................. 9 
1.2 MODELOS DE PROCESSOS DE SOFTWARE ........................................................... 12 
1.3 Modelo em Cascata ........................................................................................... 14 
1.4 Modelo em Espiral ............................................................................................... 15 
1.5 Modelo em Prototipação .................................................................................... 16 
1.6 Modelo em Desenvolvimento Incremental ...................................................... 18 
1.7 Modelo em Entrega Incremental ....................................................................... 19 
1.8 Modelo Orientada ao Reuso .............................................................................. 20 
FIXANDO O CONTEÚDO ...................................................................................... 23 
 ATIVIDADES RELACIONADAS AO PROCESSO DE DESENVOLVIMENTO 
DE SOFTWARE .......................................................................................... 27 
2.1 ESPECIFICAÇÃO DE SOFTWARE ........................................................................... 27 
2.2 PROJETO E IMPLEMENTAÇÃO DE SOFTWARE ...................................................... 29 
2.3 VALIDAÇÃO DE SOFTWARE ................................................................................. 30 
2.4 EVOLUÇÃO DE SOFTWARE ................................................................................... 31 
FIXANDO O CONTEÚDO ...................................................................................... 35 
METODOLOGIAS ÁGEIS .......................................................................... 40 
3.1 HISTÓRIA, CONCEITO E IMPORTÂNCIA DAS METODOLOGIAS ÁGEIS .............. 40 
3.2 VISÃO GERAL DAS METODOLOGIAS ÁGEIS DE MAIOR REPRESENTATIVIDADE 
NA TI ...................................................................................................................... 42 
3.3 VANTAGENS DE APLICAÇÃO DAS METODOLOGIAS ÁGEIS (CLIENTE X 
DESENVOLVIMENTO) ............................................................................................ 46 
3.4 MANIFESTO ÁGIL .................................................................................................. 49 
3.5 Valores e Princípios defendidos no Manifesto Ágil .......................................... 51 
FIXANDO O CONTEÚDO ...................................................................................... 54 
METODOLOGIA XP .................................................................................. 59 
4.1 HISTÓRIA, CONCEITO E IMPORTÂNCIA DA METODOLOGIA XP ........................ 59 
4.2 FINALIDADE DA METODOLOGIA XP .................................................................... 62 
4.3 VANTAGENS E RESTRIÇÕES DE APLICAÇÃO DA METODOLOGIA XP ................ 63 
4.3.1 EQUIPES E PAPÉIS NA METODOLOGIA XP ........................................................... 63 
4.3.2 MODO DE AÇÃO E ETAPAS DA METODOLOGIA XP ........................................... 64 
4.3.3 Jogo do Planejamento (Release Planning) e História de Usuário .................. 65 
4.3.4 Programação em Par (Pair Programming)e Código Coletivo ....................... 66 
4.3.5 Stand up Meeting ................................................................................................ 67 
4.3.6 Padrão de Codificação e Metáforas ................................................................ 68 
4.3.7 Refatoração (Refactoring) .................................................................................. 69 
UNIDADE 
01 
UNIDADE 
02 
UNIDADE 
03 
UNIDADE 
04 
 
 
 
 
 
 
 
 
 
7 
 
 
4.3.8 Desenvolvimento guiado por Testes (Test-Driven Development - TDD) ......... 70 
FIXANDO O CONTEÚDO ...................................................................................... 72 
METODOLOGIA SCRUM .......................................................................... 76 
5.1 HISTÓRIA, CONCEITO E IMPORTÂNCIA DA METODOLOGIA SCRUM ................ 76 
5.2 FINALIDADE DA METODOLOGIA SCRUM ............................................................ 79 
5.3 VANTAGENS E RESTRIÇÕES DE APLICAÇÃO DA METODOLOGIA SCRUM ........ 79 
5.4 EQUIPES E PAPÉIS NA METODOLOGIA SCRUM ................................................... 80 
5.5 MODO DE AÇÃO E ETAPAS DA METODOLOGIA SCRUM ................................... 82 
FIXANDO O CONTEÚDO ...................................................................................... 86 
ESTIMATIVA DE SOFTWARE ...................................................................... 90 
6.1 CONCEITO E IMPORTÂNCIA DA ESTIMATIVA DE SOFTWARE ............................. 90 
6.2 MÉTRICAS DE SOFTWARE ...................................................................................... 91 
6.3 Análise por Ponto de Função ............................................................................. 92 
6.4 Planning Poker ................................................................................................... 102 
FIXANDO O CONTEÚDO .................................................................................... 108 
RESPOSTAS DO FIXANDO O CONTEÚDO .......................................................... 112 
REFERÊNCIAS ....................................................................................................... 113 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
UNIDADE 
05 
UNIDADE 
06 
 
 
 
 
 
 
 
 
 
8 
 
 
CONFIRA NO LIVRO 
 
A Unidade I trata do que venha a ser o Processo de 
Desenvolvimento de Software, sua importância e finaliza 
apresentando os principais Modelos de Processos de Software 
conhecidos. 
A Unidade II trata especificamente do Processo de 
Desenvolvimento de Software, especificando em linhas gerais o seu 
ciclo e cada uma das etapas envolvidas. 
 
 
A Unidade III apresenta o conceito de Modelos Ágeis, histórico, 
visão geral, vantagens e finaliza apresentando o Manifesto Ágil, 
sendo ele o documento direcionador para as Metodologias Ágeis 
de desenvolvimento. 
A Unidade IV apresenta a Metodologia Ágil XP e demais elementos 
que permitem maior conhecimento acerca da ferramenta. 
 
 
 
 
 
 
A Unidade V apresenta a Metodologia Ágil Scrum e demais 
elementos que permitem maior conhecimento acerca da 
ferramenta. 
 
A Unidade VI trata de Estimativa de Software e para tal apresenta 
as métricas de Ponto de Função e Planning Poker. 
 
 
 
 
 
 
 
 
 
 
 
 
9 
 
 
 PROCESSO DE DESENVOLVIMENTO 
DE SOFTWARE 
 
 
 
 
 
 
 
 
1.1 DEFINIÇÃO E IMPORTÂNCIA PROCESSO DE DESENVOLVIMENTO DE 
SOFTWARE 
Um software não se constitui unicamente pelas linhas de código executáveis. 
Incorpora toda a documentação necessária para a sua instalação, uso e 
manutenção, incluindo a configuração imprescindível ao seu correto 
funcionamento. 
Diante deste entendimento, o Processo de Desenvolvimento de Software ou 
simplesmente Processo de Software, se refere a toda uma gama de ações 
executadas no âmbito do desenvolvimento de um produto de software, 
incorporando desde o levantamento de requisitos, escolha da linguagem, e 
alcançando inclusive, a análise de performance (SOMMERVILLE, 2011, HIRAMA, 2012; 
PETERS, 2001). 
 
 
 
Assim, no Processo de Software são estabelecidos os métodos (norteia o que 
fazer), as ferramentas (define o material a ser utilizado), e os procedimentos 
(indicando o como fazer) de modo a garantir que o produto alcance o resultado 
planejado (PRESSMAN, 2011). 
É justamente pelo desenvolvimento de um bom Processo de Software que se 
pretende alcançar a qualidade do produto desenvolvido e/ou evoluído, o que por 
sua vez requer organização e definição de ações atuantes para o alcance de 
Produto de Software: denominação dada ao software que foi desenvolvimento para o 
atendimento de demandas específicas definidas pelo cliente e pelo usuário 
(HIRAMA, 2012; PRESSMAN, 2011; PETERS, 2001). 
UNIDADE 
01 
 
 
 
 
 
 
 
 
 
 
10 
 
 
agilidade e transformação tecnológica, considerando o contexto de prazo e 
assertividade em produto (WAZLAWICK, 2013). 
Tratando destes aspectos, Wazlawick (2013) segue destacando que o prazo 
incorpora o tempo de execução do projeto, incluindo os limites e datas estabelecidos 
previamente, e a assertividade em produto se faz relacionada ao fato de o software, 
uma vez entregue ao cliente, se fazer preparado para atender as demandas que lhe 
foram solicitadas sem a incorrência de falhas ou a necessidade frequente de 
paralisação para manutenções e correções que não foram previamente definidas. 
Tal preocupação, deu-se a partir anos de 1960, quando, por falta de 
padronização no desenvolvimento, a demanda crescente de desenvolvimento, os 
custos e prazos mal definidos, o serviço descompromissado das equipes de 
tecnologia e a ausência de confiança dos clientes, fez surgir uma fase denominada 
pela expressão Crise do Software, evidenciando a necessidade de que adequações 
fossem definidas para que o processo se tornasse mais profissional (SOMMERVILLE, 
2011). 
Era destaque à época a questão referente aos defeitos de software em face 
de seu mal dimensionamento, o custo elevado e a estimativa de prazos que não 
conseguia se fazer cumprida. A isto, somava-se a complexidade do código e a total 
ausência de documentação, o que dificultava a manutenção, atrapalhando o 
processo de evolução do software e o consequente acompanhamento ao progresso 
dos equipamentos existentes (PRESSMAN, 2011). 
Além deste fato, a comunicação entre o cliente e a TI era precária ou 
inexistente, acarretando uma série de falhas no desenvolvimento pelo fato de a 
equipe de tecnologia ter dificuldade em compreender as reais necessidades a serem 
atendidas pelos softwares, levando a correções praticamente infinitas (WAZLAWICK, 
2013). 
Outro aspecto impactante era a ausência de meios avaliativos de eficácia 
que permitissem proceder com a definição de estimativas de maior precisão em 
relação ao software desenvolvido e entregue, o que efetivamente impactava na 
possibilidade de se prospectar a necessidade de treinamentos e de manutenções 
preventivas aos sistemas (SOMMERVILLE, 2011). 
Assim, a Crise do Software impulsionou o Processo de Software, e este, por sua 
vez, passou a englobar atividades fundamentais voltadas ao desenvolvimento e/ou 
evolução em um processo de software, as quais seguem apresentadas no Quadro 1. 
 
 
 
 
 
 
 
 
 
11 
 
 
 
Quadro 1: Atividades fundamentais para o desenvolvimento e/ou evolução do processo de 
software 
Especificação de 
Software 
Atividade em que se define as funcionalidades que devem ser 
atendidas pelo software e possíveis restrições que podem ser 
interpostas ao projeto 
Projeto e Implementação 
de Software 
Atividade longa que parte das especificações definidas 
anteriormente e se volta ao desenvolvimento do software 
Validação de Software 
Atividade de validação da ferramenta desenvolvida, no intuito 
de se atestar se a solução realiza o que fora solicitado pelo 
cliente 
Evolução deSoftware 
Atividade de ajuste com mudanças voltadas a garantir total 
atendimento às necessidades do cliente 
Fonte: adaptado de Sommerville (2011) 
 
Tais ações demonstram o nível de profissionalismo alcançado a partir do 
Processo de Software em oposição à ausência de definição de processos como 
acontecia anteriormente à Crise do Software. 
O Processo de Software passou a permitir efetivas melhorias em relação ao 
treinamento de usuários, padronização de desenvolvimento e possibilidade da 
experiência do usuário ser mais bem compreendida e aperfeiçoada por meio do 
sistema (WAZLAWICK, 2013). 
Neste âmbito, cabe reconhecer que quando um Processo de Software é 
especificado também são definidas descrições como as referenciadas no Quadro 2. 
 
Quadro 2: Outras especificações importantes no Processo de Software 
Produtos resultado que se deseja alcançar com o processo que se encontra em 
execução 
Papéis pessoas responsáveis e envolvidas no processo 
Condições declarações prévias ou posteriores ao processo e que merecem atenção 
Fonte: adaptado de Sommerville (2011) 
 
Cabe destacar em relação ao Quadro 2, que quando definidos os papeis 
referentes às pessoas responsáveis e envolvidas no processo tem-se um termo técnico 
comumente utilizado que é o de Stakeholders, ou seja, todos aqueles que são 
responsáveis, possuem interesses e/ou ainda são afetados pela criação de softwares 
e pela incorporação deles nas atividades de negócio (OLIVEIRA, 2018). 
No intuito de que o Processo de Software, embasado nas ações e 
especificações já apontadas, alcançasse a possibilidade de acompanhar o 
desenvolvimento e a evolução de um software, concebeu-se o entendimento 
acerca do Ciclo de Vida de Software (WAZLAWICK, 2013). 
 
 
 
 
 
 
 
 
 
12 
 
 
O Ciclo de Vida de Software, de acordo com Wazlawick (2013) incorpora em 
si as ações pertinentes a todo o período de existência de um software, incluindo a 
atualização do sistema em face das atividades do usuário sofrerem ajustes, o que, 
por conseguinte, leva a alterações evolutivas na ferramenta. 
 
 
1.2 MODELOS DE PROCESSOS DE SOFTWARE 
Um Processo de Software configura-se em um conjunto de atividades 
complexas e especializadas, de modo que o Modelo de um Processo de Software 
representa e fornece, de modo simples, informações e visibilidade acerca do 
processo em si traduzidas na forma de estruturas/esquematizações fornecedores de 
uma visão didática de como proceder com as etapas que devem se fazer efetivadas 
(SOMMERVILLE, 2011; PRESSMAN, 2011). 
Um Modelo de Processo de Software possui em seu bojo estruturas que 
demonstram as etapas atinentes ao desenvolvimento do software em si, por meio da 
organização do Ciclo de Vida de Software, no qual tem-se estruturadas as atividades 
a serem executadas, incorporando em si os conceitos listados no Quadro 3. 
 
Quadro 3: Ciclo de Vida de Software 
Requisitos Etapa voltada ao levantamento de informações atinentes ao problema 
que a ferramenta de software se destinará a resolver. Tais informações, 
ou seja, os requisitos configuram-se como condições, necessidades, 
características, funcionalidades, restrições e demais aspectos que 
carecem ser atendidos, necessitando ser devidamente documentados. 
Análise Etapa que parte do levantamento de requisitos e permite que a equipe 
de processo conheça a atividade do usuário, discuta os requisitos 
levantados e identifique melhorias que carecem de implementação. 
Abstração e 
Representação 
Etapa de elaboração de modelos mentais e conceituais voltados a 
solucionar as necessidades do cliente por meio do software. 
Os Processos de Software podem ser categorizados, conforme Sommerville (2011), como: 
a) Processo de Software dirigido a Plano: neste, o planejamento de software se faz 
definido antecipadamente, de modo que o progresso do projeto se avalia a partir da 
etapa atualizada de execução; 
b) Processo de Software Ágil: neste, o planejamento de software se faz definido 
gradualmente, e o progresso ocorre a partir do momento que as necessidades de ajuste 
em funcionalidades são sanadas. 
 
 
 
 
 
 
 
 
 
13 
 
 
Projeto Etapa de desenho do produto de software, partindo dos requisitos, ou 
seja, do que o sistema deverá executar. 
Implementação Etapa de transformação do projeto através da linguagem de 
programação escolhida, não devendo se fazer completamente 
dissociada da interação com o cliente. 
Integração Etapa em que os módulos desenvolvidos durante a implementação se 
fazem integrados para que possam trocar dados entre si. 
Testes Etapa de verificação quanto ao alcance de objetivos por parte do 
software e da possibilidade de falhas de execução ou funcionalidades 
mal dimensionadas. 
Implantação Fase em que estando o sistema finalizado, ele é disseminado pela 
organização e o desenvolvedor se mantém em atenção para a 
necessidade de ajustes em face de questões de usuário ou modelo de 
negócios. 
Manutenção Fase em que após a entrega, faz-se importante a correção de falhas, a 
melhoria de desempenho e adaptações de acordo com a necessidade 
do cliente. 
Fonte: adaptado de Pressman (2011) e Wazlawick (2013) 
 
Cabe, por último considerar a importância da documentação completa do 
Processo de Software, no qual efetivamente, através de diagramas de casos de uso 
especifica-se todo o ciclo, incluindo desde os requisitos até o planejamento de 
manutenção, garantindo que outras equipes de tecnologia possam tranquilamente 
se posicionar em prol da evolução do sistema. 
 
 
 
Em relação à fase de Implantação apresentada a partir do Quadro 3, deve-
se considerar as seguintes possibilidades descritas no Quadro 4 quando um software 
se fizer aplicado em substituição a outro que já esteja em funcionamento. 
Quadro 4: Processos de substituição de software 
Direta Assim que o sistema novo entrar em pleno funcionamento o antigo é retirado 
de operação completamente 
Paralela Os sistemas, novo e antigo, permanecem funcionando paralelamente com 
acesso e atualização à mesma base durante certo espaço de tempo 
Piloto O sistema novo refaz os processos efetivados pelo antigo com vistas a identificar 
os parâmetros de seu funcionamento e efetividade 
Parcial Parte dos sistemas se complementam e aos poucos o novo sistema vai tomando 
todo o espaço do antigo 
Fonte: adaptado de Wazlawick (2013) 
 
Diagramas de Casos de Uso são representações gráficas que demonstram visualmente as 
relações entre o sistema e o usuário e vice-versa, favorecendo a compreensão para o 
desenvolvedor das possibilidades de interação e das funcionalidades que necessitam se 
fazer implementadas (PRESSMAN, 2011). 
 
 
 
 
 
 
 
 
 
 
14 
 
 
Os conceitos apresentados apenas clarificam em relação às suas funções, e 
que não existe um único modelo para o desenvolvimento de um projeto, cabendo a 
escolha por parte da equipe de desenvolvimento embasada na filosofia de trabalho 
que emprega (PRESSMAN, 2011). 
No entanto, a possibilidade de associação entre modelos é uma realidade, de 
modo a garantir que se combine os melhores aspectos entre eles (SOMMERVILLE, 
2011). 
Deste modo, favorecendo a um melhor entendimento do que venha a ser 
estes ciclos de desenvolvimento, nos próximos tópicos desta unidade serão 
apresentados os mais conhecidos modelos de desenvolvimento em ciclo de vida. 
 
1.3 MODELO EM CASCATA 
O Modelo em Cascata é clássico, desenvolvendo-se de forma sistemática, 
encadeada e previamente planejada em sua totalidade, de modo que uma etapa 
depende diretamente da outra e a próxima somente se inicia a partir do momento 
que a anterior se encontra finalizada (SOMMERVILLE, 2011; PRESSMAN, 2011). 
A Figura 1 dispõe representação clássica do Modelo em Cascata permitindo 
melhor entendimento de suas fases. 
 
Figura 1: Representação dos estágios do Modelo em Cascata 
 
Fonte: adaptado de Sommerville (2011) e Pressman (2011)15 
 
 
Justamente pelo fato de este modelo seguir um planejamento prévio, também 
chegou a receber a denominação de Processo dirigido a Planos, no entanto, vale a 
crítica de que, mesmo em sua orientação a planos, por vezes o modelo efetiva 
levantamento de requisitos de modo superficial, não define processos padronizados 
a serem seguidos pela equipe como um todo e conta com certa dificuldade em 
rever as falhas antes da finalização de uma etapa, e até do projeto como um todo 
(SOMMERVILLE, 2011; PRESSMAN; MAXIM, 2016). 
Assim, pela não ocorrência de critérios de avaliação e controle que 
favoreçam o feedback das ações efetivadas durante a execução do projeto, tem-
se que, por vezes, o projeto consegue ser paralisado em uma dada etapa em vista 
de conseguir cumprir os critérios estabelecidos, levando à não obediências de prazos 
ajustados com o cliente e, por conseguinte, o aumento do custo final do produto 
(PRESSMAN, 2011). 
Para este modelo a documentação se faz desenvolvida a cada fase, 
permitindo que as ações sejam visíveis para a gestão, no entanto a possibilidade de 
replanejamento e mudanças durante a execução não é parte do seu escopo, 
demonstrando riscos e incapacidades de gestão latentes (PRESSMAN, 2011; 
PRESSMAN; MAXIM, 2016). 
No entanto, cabe ressaltar que, em caso de definições bem efetivadas de 
requisitos e ausência de necessidade de mudanças/ajustes ao longo do 
desenvolvimento do sistema, o modelo se aplica perfeitamente, principalmente em 
face de sua simplicidade de compreensão e uso (WAZLAWICK, 2013). 
 
1.4 MODELO EM ESPIRAL 
Neste modelo, o processo se faz representado por uma espiral, devendo se 
fazer percorrido no sentido horário, de dentro para fora, no intuito de demonstrar que 
a evolução é a tônica do conjunto de ações efetivadas (SOMMERVILLE, 2011; 
PRESSMAN, 2011). 
Os riscos referentes ao não cumprimento de prazos, à mudança de tecnologia 
e ao custo com dimensionamento mal efetivado tornam-se gerenciáveis, permitindo 
que ajustes sejam passíveis de efetivação antes da finalização do produto 
(PRESSMAN, 2011; PRESSMAN; MAXIM, 2016). 
A Figura 2 dispõe representação do Modelo em Espiral permitindo melhor 
 
 
 
 
 
 
 
 
 
16 
 
 
entendimento de suas fases. 
 
Figura 2: Representação dos estágios do Modelo em Espiral 
1º estágio 
Determinação de 
Objetivos, 
Alternativas e 
Restrições para a 
elaboração de 
plano de 
gerenciamento, de 
riscos e de 
estratégias 
 
 
2º estágio 
Avaliação de 
alternativas, 
Identificação e 
resolução de 
riscos visando a 
minimização de 
riscos através da 
análise efetivada 
3º estágio 
Desenvolvimento, 
verificação e 
validação do 
produto no nível 
seguinte, partindo 
de um protótipo 
descartável 
4º estágio 
Planejamento da 
próxima fase no 
intuito de 
favorecer o 
desenvolvimento 
contínuo da fase 
seguinte 
Fonte: adaptado de Sommerville (2011) e Pressman (2011) 
 
Conforme se observa na figura, à medida que se efetiva o desenvolvimento 
do projeto, cada fase adiciona novos requisitos, passando pelos estágios mais de 
uma vez até que o produto esteja finalizado, garantindo que os riscos sejam o fator 
de maior atenção no modelo, assim como a qualidade. 
 
1.5 MODELO EM PROTOTIPAÇÃO 
O protótipo, sendo uma representação visual em baixa fidelidade do produto, 
permite ao usuário/cliente conhecer a proposição das funcionalidades efetivadas 
pela equipe de desenvolvimento através da experimentação, respaldando inclusive 
a troca de informações com vistas à efetivação de melhorias para a versão final 
(SOMMERVILLE, 2011; PRESSMAN, 2011; PRESSMAN; MAXIM, 2016) 
 
 
A Baixa Fidelidade se aplica a modelos simplificados que podem ser desenvolvidos com 
materiais de fácil uso como o papel (prototipação em papel), no qual se efetiva desenhos 
de tela, por exemplo. Contudo, atualmente pode se fazer uso de softwares de 
prototipação que permitem uma relação de experimentação mais efetiva do usuário com 
a proposta que se está apresentando (PRESSMAN; MAXIM, 2016). 
 
 
 
 
 
 
 
 
 
17 
 
 
Contudo, o Modelo em Prototipação é indicado nos casos em que o cliente 
não consegue identificar claramente suas necessidades em matéria de software, 
mas participa ativamente das etapas do projeto, e assim, por meio da interação com 
o produto proposto consegue estabelecer as funcionalidades de que necessita com 
maior precisão (SOMMERVILLE, 2011). 
Seu custo que tende a ser relativamente baixo, demonstra atratividade pela 
incorporação de protótipos aos processos de desenvolvimento, uma vez que o 
levantamento de requisitos se torna mais eficiente, o feedback do cliente/usuário 
permite ajustes antes da finalização do produto e a usabilidade pode ser facilmente 
testada e ajustada (PRESSMAN, 2011). 
Assim, o modelo se aplica plenamente para o levantamento e validação de 
requisitos, como também para a avaliação de projetos e erros de interface, 
permitindo que a experiência do usuário seja o diferencial desse processo 
(WAZLAWICK, 2013). 
A Figura 3 dispõe representação de Modelo em Prototipação permitindo 
melhor entendimento de suas fases. 
 
Figura 3: Representação dos estágios do Modelo em Prototipação 
 
Fonte: adaptado de Sommerville (2011) e Pressman (2011) 
 
Com sua etapa inicial na etapa de Obtenção de Requisitos para o Plano de 
Prototipação, observa-se que em seu processo cíclico melhorias podem ser 
Obtenção de 
Requisitos para o 
Plano de 
Prototipação
Definição Geral e 
Rápida do 
Protótipo
Desenvolvimento 
do Protótipo 
executável
Avaliação do 
Protótipo pelo 
Cliente
Refinamento do 
Protótipo
Construção do 
Produto final
 
 
 
 
 
 
 
 
 
18 
 
 
incorporadas até que o protótipo alcance a possibilidade de atender às 
necessidades do cliente, permitindo que o produto alcance condições de 
efetivamente implementado em código. 
Assim, compreende-se a partir de sua atuação como um objeto de 
experimentação, que o protótipo permite a adição e teste de funcionalidades, para 
que, diante de sua viabilidade, possam efetivamente fazer parte do produto em si 
(SOMMERVILLE, 2011). 
 
1.6 MODELO EM DESENVOLVIMENTO INCREMENTAL 
No Modelo em Desenvolvimento Incremental a criação do sistema ocorre em 
versões. A cada versão ajustes são adicionados após terem passado por processo de 
avaliação efetivado por parte dos clientes/usuários (SOMMERVILLE, 2011; PRESSMAN; 
MAXIM, 2016). 
Assim, o desenvolvimento ocorre em ciclos de especificação, 
desenvolvimento e validação efetivados a cada versão, permitindo sempre que 
novas funcionalidades sejam parte da versão em atualização (PRESSMAN, 2011). 
A Figura 4 dispõe representação do Modelo em Desenvolvimento Incremental 
permitindo melhor entendimento de suas fases. 
 
Figura 4: Representação dos estágios do Modelo em Desenvolvimento Incremental 
 
Fonte: adaptado de Sommerville (2011) e Pressman (2011) 
 
Na figura, observa-se por meio do diagrama iniciado na Descrição do esboço, 
que para a passagem de uma etapa a outra ocorrem interações, e somente após o 
seu pleno atendimento são efetivados os incrementos para as etapas seguintes. 
 
 
 
 
 
 
 
 
 
19 
 
 
Complementando, a disposição composta por peças de um quebra-cabeças 
demonstra que a cada etapa uma parte do produto vai sendo adicionada até que 
ocorra a sua conclusão. 
Cabe destacar, que este modo de ação foi concebido em correção ao 
Modelo Tradicional em Cascata, no qual os ajustes somente se fariam efetivados ao 
final de todo o processo de desenvolvimento e apenas sobre os pontos de maior 
criticidade (WAZLAWICK, 2013). 
Sua indicação de uso se faz nos casos em que se necessita privilegiar a 
liberação de alguma funcionalidade do sistema ou quando os profissionais 
envolvidos carecem de melhor distribuição nas atividades a serem desenvolvidas, 
permitindo que a gestão do tempo de execução seja mais efetiva (PRESSMAN, 2011;PRESSMAN; MAXIM, 2016). 
 
1.7 MODELO EM ENTREGA INCREMENTAL 
No Modelo em Entrega Incremental o cliente aponta quais as funcionalidades 
do sistema são de maior importância. Assim, posicionando-os como de maior 
prioridade em desenvolvimento, estes são logo incrementados favorecendo a 
efetivação de entrega e aptidão para operacionalização (SOMMERVILLE, 2011) 
Como vantagem ao uso deste modelo tem-se, entre outras, a possibilidade de 
que as primeiras versões, antes do incremento final, sirvam de protótipo, favorecendo 
a experimentação do usuário/cliente e a troca de informações com a equipe de 
desenvolvimento (PRESSMAN, 2011; PRESSMAN; MAXIM, 2016). 
A Figura 5 dispõe representação dos estágios do Modelo em Entrega 
Incremental permitindo seu melhor entendimento. 
 
Figura 5: Representação dos estágios do Modelo em Entrega Incremental 
 
Fonte: Sommerville (2011, p. 31) 
 
 
 
 
 
 
 
 
 
20 
 
 
A figura demonstra que garantir a finalização do sistema e a efetivação de 
seus incrementos são preocupações do modelo, garantindo que a possibilidade de 
especificação não se efetive apenas no início do projeto. 
No entanto, vale destacar que o Modelo de Entrega Incremental não é 
indicado quando o sistema for de maior porte, o que requere a divisão de tarefas em 
equipes, e nem quando o sistema for desenvolvido para processos de maior 
criticidade e periculosidade (WAZLAWICK, 2013). 
 
1.8 MODELO ORIENTADA AO REUSO 
O Modelo Orientado ao Reuso se aplica nos casos em que o desenvolvimento 
de sistema estiver focado na integração de módulos já existentes, restando identificar 
se os componentes passíveis de integração são aptos ou não ao reuso 
(SOMMERVILLE, 2011; PRESSMAN; MAXIM, 2016). 
Basicamente, são orientados ao reuso os Serviços Web, as Coleções de 
Objetos em Frameworks de Componentes e Sistemas Stand-Alone, ou seja, que 
funcionam individualmente e isoladamente, sem interação com outros (WAZLAWICK, 
2013). 
A Figura 6 dispõe representação dos estágios do Modelo Orientado ao Reuso 
permitindo seu melhor entendimento. 
 
Figura 6: Representação dos estágios do Modelo Orientado ao Reuso 
Especificação 
de Requisitos 
Levanta-se as 
especificações 
do sistema 
Análise de 
componentes 
Busca-se 
componentes 
já existentes e 
aptos ao 
reuso 
Alteração nos 
requisitos 
Os requisitos 
são 
analisados 
com base 
nos 
componentes 
encontrados 
para serem 
modificados 
conforme a 
necessidade 
Projeto do 
sistema com 
reuso 
Procede-se 
com a 
constituição 
do 
framework 
do sistema, 
considerando 
os elementos 
de reuso 
Desenvolvimento 
e integração 
Desenvolve-se os 
componentes 
que não 
puderam ser 
reutilizados para 
proceder com a 
integração 
completa do 
sistema 
Validação de 
Sistema 
O sistema é 
validado por 
meio de sua 
disseminação 
na 
organização 
 
Fonte: adaptado de Sommerville (2011, p. 23) 
 
 
 
 
 
 
 
 
 
 
21 
 
 
Assim, diminuindo a quantitativo de software a ser desenvolvido, este modelo 
se aplica na redução de custos e do tempo de execução do projeto, contudo, a 
possibilidade de que os requisitos não se mantenham sintonizados com as 
necessidades dos usuários e com os módulos entregues no sistema é elevada, 
levando por vezes à necessidade de retrabalho e até novos desenvolvimentos de 
software desde o processo inicial (PRESSMAN, 2011, HIRAMA, 2012; PRESSMAN; MAXIM, 
2016; PETERS, 2001). 
Assim, em se tratando da manutenção de software, ou seja, da necessidade 
de ajustes após a entrega do produto em si, cabe destacar os tipos de manutenção 
existentes, os quais seguem especificadas no Quadro 5. 
 
Quadro 5: Tipos de manutenção 
Corretiva Efetivada após a entrega do produto no intuito de corrigir um erro descoberto 
em garantia de pleno funcionamento do sistema 
Adaptativa Efetivada após a entrega do produto visando estabelecer ajustes/alterações 
que garantam o uso do sistema 
Perfectiva Efetivada após a entrega do produto no intuito de melhorar o desempenho 
e/ou a manutenibilidade 
Preventiva Efetivada após a entrega do produto para o reparo de falhas antes que o 
sistema se faça afetado 
Fonte: adaptado de Wazlawick (2013) 
 
Sendo a manutenção um requisito necessário e relacionado diretamente com 
a qualidade de software (manutenibilidade), cabe que o Processo de Software 
incorpore em seu ciclo de execução esta fase, garantindo que o sistema não se torne 
obsoleto pelo simples fato de sua desatualização. 
 
 
Manutenibilidade: característica referente à facilidade de manutenção, melhoria e/ou 
adaptação de um sistema (WAZLAWICK, 2013); 
Serviços Web: metodologias que incorporam tecnologias web e que podem se fazer 
conectados em sistemas informacionais (adaptado de https://www.opensoft.pt/web-
service/); 
Coleções de Objetos em Frameworks de Componentes: grupos de aplicações que são 
aptas à conexão para interação em um sistema maior (WAZLAWICK, 2013); 
Sistemas Stand-Alone: Sistemas que funcionam sem a necessidade de interação com 
outros que atuem como auxiliares, por exemplo um editor de texto instalado no 
computador ou um software de edição de vídeos (SOMMERVILLE, 2011; PRESSMAN, 2011). 
 
 
 
 
https://www.opensoft.pt/web-service/
https://www.opensoft.pt/web-service/
 
 
 
 
 
 
 
 
 
22 
 
 
 
 
 
 
 
Se você e sua equipe de TI fossem contactados no intuito de efetivar o desenvolvimento 
de um sistema para uma empresa, considerando a importância de se manter foco no 
cliente, indisponibilidade de reajuste em prazos e orçamento limitado, qual dos modelos 
aqui estudados acha que poderia melhor se enquadrar? Reflita nos prós e contras, liste 
tudo e verifique se sua opinião pode mudar. 
 
No site DevMedia tem um artigo sob o título “Ciclos de Vida de Software” que fala destes 
modelos e de outros. Disponível em: https://bit.ly/2mpESbR. Acesso em: 02 de mar. 2023 
Assim, indico esta leitura como complemento para o seu conhecimento. 
 
https://bit.ly/2mpESbR
 
 
 
 
 
 
 
 
 
23 
 
 
 
FIXANDO O CONTEÚDO 
 
1. (TJ-PI-IDECAN – 2022) Em projetos de desenvolvimento de software uma das 
primeiras importantes decisões que se deve tomar é como gerenciar processos, 
atividades e tarefas que serão executados durante o ciclo de vida do projeto. O 
entendimento do funcionamento da interação entre a equipe de 
desenvolvimento e o cliente é fundamental para o sucesso do projeto. Para definir 
como devemos gerenciar todas essas questões, existem diversos modelos de clico 
de vida de software. Cada modelo possui especificidades e pode apresentar 
vantagens e desvantagens, a depender de características inerentes ao projeto. A 
respeito dos diferentes modelos de ciclo de vida de um software, analise as 
afirmativas abaixo e marque alternativa correta. 
I. O Modelo cascata tem como principal característica o fato das etapas serem 
executadas de forma sequencial. Isso demanda, obviamente, um grande 
planejamento como por exemplo, a definição completa de requisitos antes da 
implementação. 
II. O Modelo Incremental é uma evolução do modelo Cascata. Aqui o projeto é 
quebrado em módulos. As etapas também são executadas sequencialmente mas 
focadas apenas no módulo em desenvolvimento no momento. Dessa forma o 
processo de planejamento se torna menos desafiador pois o cliente recebe os 
diversos módulos gradualmente. 
III. No Modelo Espiral as fases do processo de desenvolvimento representam um volta 
completa na espiral. Trata-se de um modelo de grande aceitação por parte do 
cliente dada a sua simplicidade. Recomenda-se fortemente que seja aplicado 
somente em projetos de pequeno porte, uma vez que o modelo não contempla 
atividades relacionadas ao gerenciamento de riscos. 
a) Apenas as afirmativas Il e Ill estão corretas 
b) Apenas a afirmativa Ill está correta 
c) Apenas as afirmativas I e Il estão corretas 
d) Apenas a afirmativa I está corretae) Todas as afirmativas estão corretas 
 
 
 
 
 
 
 
 
 
 
24 
 
 
2. (FEPESE - CELESC - 2022) Ciclo de vida do software é o termo utilizado para definir 
o conjunto de etapas que ocorre entre a concepção de um sistema e o instante 
em que ele é descontinuado pelo desenvolvedor. Ele ajuda a orientar a equipe 
de desenvolvedores, assim como o direcionamento de recursos. Assinale a 
alternativa que contém o nome de três ciclos de vida: 
a) Incremental • Cascata • Espiral 
b) Cascata • Funcional • Avaliativo 
c) Espiral • Funcional • Exploratório 
d) Decremental • Cascata • Funcional 
e) Cascata • Incremental • Decremental 
 
3. (VUNESP - ALE SP – 2022 - adaptado) No processo de prototipação de software, um 
protótipo em papel permite apresentar: 
a) um esboço simples e rápido do software, geralmente um rascunho, para 
compreender o que é esperado do sistema. 
b) exemplos finais de como o software deve ficar quando pronto, mas sem as funções 
que ainda serão implementadas. 
c) a ideia a ser desenvolvida na forma de software, antes mesmo de esboçar 
qualquer tela a ser desenvolvida. 
d) exemplos finais de todos os leiautes e da diagramação dos elementos que serão 
parte da tela do software. 
e) o software pronto, incluindo leiautes, diagramação e todas as funcionalidades que 
são esperadas. 
 
4. (IBFC - DETRAN AM - 2022 - adaptado) Segundo Pressman (2011) este ciclo de vida 
é considerado como clássico por ter uma abordagem sequencial e sistemática 
para o desenvolvimento de software. Esse ciclo de vida é especificamente 
denominado como: 
a) modo prototipado 
b) modelo cascata 
c) processo unificado 
d) modelagem espiral 
e) modelo avaliativo 
 
https://questoes.grancursosonline.com.br/concursos/2022
https://questoes.grancursosonline.com.br/prova/detran-am-am-2022-ibfc-analista-de-sistemas-da-informacao
 
 
 
 
 
 
 
 
 
25 
 
 
5. (FAURGS - SES RS - 2022 - adaptado)Há vários modelos de processo de software, 
sendo que cada um define um fluxo de processo que invoca cada atividade do 
desenvolvimento de forma diversa. 
O modelo ___________, algumas vezes chamado ciclo de vida clássico, é um 
exemplo de processo dirigido a planos, pois deve-se planejar todas as atividades 
(estágios) do processo antes de começar a trabalhar nelas. Em princípio, o estágio 
seguinte não deve ser iniciado até que o estágio anterior seja concluído, mas, na 
prática, este processo não é um modelo linear simples, envolvendo o feedback de 
um estágio a outro. Assim, os documentos e artefatos produzidos em cada estágio 
podem ser modificados para refletirem as alterações em cada um deles. 
Seu maior problema é a divisão inflexível do projeto em estágios distintos e por isso 
deve ser usado apenas quando os requisitos são bem compreendidos e é pouco 
provável que venham a ser radicalmente alterados durante o desenvolvimento. 
Um segundo exemplo de modelo de processo de software é o modelo de 
___________________, que se baseia na construção de protótipos, uma versão 
simplificada de um sistema de software. 
Embora possa ser utilizado como um modelo de processo isolado, é comumente 
utilizado como uma técnica que auxilia os interessados a compreender melhor o 
que está para ser construído, quando os requisitos estão obscuros. 
Assinale a alternativa que completa, correta e respectivamente, as lacunas do 
texto acima. 
a) Cascata – Prototipação 
b) Espiral – Prototipação 
c) Espiral – Cascata 
d) Espiral – Desenvolvimento Baseado em Componentes 
e) Cascata – Desenvolvimento Baseado em Componentes 
 
6. Analise as afirmativas sobre o modelo de processo de software conhecido como 
“modelo em cascata". 
I. Em geral, o resultado de cada fase do processo resulta em um ou mais 
documentos aprovados. 
II. É adequado a situações com pequena probabilidade de mudanças radicais 
durante o desenvolvimento do sistema. 
III. Prevê a execução simultânea das fases de desenvolvimento. 
https://questoes.grancursosonline.com.br/prova/ses-rs-rs-2022-faurgs-analista-area-desenvolvimento-de-sistemas
 
 
 
 
 
 
 
 
 
26 
 
 
Estão CORRETAS as afirmativas: (FUNDEP – MG – 2014 - adaptado) 
a) I e II apenas. 
b) I e III apenas 
c) II e III apenas. 
d) I, II e III. 
e) Nenhuma das alternativas 
 
7. (CIAAR - FAB – 2011 - adaptado) Preencha as lacunas abaixo e, em seguida, 
assinale a alternativa correta. ______________ é um processo que capacita o 
desenvolvedor a criar um modelo do software que será implementado. Se 
abrangermos as melhores características de tal processo com as do modelo 
cascata e a __________________ como novo elemento temos uma base do modelo 
espiral. 
a) Prototipação / análise de risco 
b) Testes / manutenção 
c) Implementação / recorrência 
d) Análise / avaliação 
e) Nenhuma das alternativas 
 
8. Quando se fornece um produto, seja desenvolvendo um software, escrevendo um 
relatório ou fazendo uma viagem a negócios, segue-se costumeiramente uma 
sequência de etapas para completar um conjunto de tarefas. A respeito dos 
modelos de processo de software, assinale a alternativa correta: (CRO - RJ – 2016 
- adaptada) 
a) O modelo espiral combina uma natureza interativa com outra que incorpora 
aspectos controlados e sistemáticos. 
b) O modelo orientado ao reuso enfoca a integração dos componentes do projeto 
de software, como recursos humanos e de hardware. 
c) O modelo de entrega incremental intercala as atividades de especificação e 
validação, possuindo apenas uma versão, a final. 
d) O modelo em cascata considera as atividades fundamentais do processo, 
envolvendo especificação, desenvolvimento, validação e evolução. 
e) A prototipação é a visão final de um sistema de software, que demonstra 
conceitos e não serve para conhecer o problema do usuário. 
 
 
 
 
 
 
 
 
 
27 
 
 
 ATIVIDADES RELACIONADAS AO 
PROCESSO DE DESENVOLVIMENTO 
DE SOFTWARE 
 
 
 
2.1 ESPECIFICAÇÃO DE SOFTWARE 
A Especificação de Software tem como função compreender os serviços que 
se fazem requisitados para o sistema assim como identificar os aspectos que podem 
se posicionar como restritivos para o seu desenvolvimento (SOMMERVILLE, 2011). 
Sua ação de fundamental importância pode se posicionar como marco de 
sucesso/insucesso para o Processo de Software e, justamente em face deste aspecto, 
requer senso de responsabilidade e conhecimento para a boa efetivação dos 
processos desenvolvidos (WAZLAWICK, 2013; VAZQUEZ; SIMÕES, 2016). 
Volta-se portanto a documentar os requisitos de especificação do sistema, 
permitindo que tanto usuários quanto desenvolvedores conheçam claramente e 
detalhadamente que aspectos deverão ser cobertos pela ferramenta 
computacional em desenvolvimento (PRESSMAN, 2011). 
Sommerville (2011) e Pressman (2011) apresentam as atividades que fazem 
parte do processo de Especificação de Software e estas seguem apresentadas no 
Quadro 6. 
 
Quadro 6: Atividades efetivadas na Especificação de Software 
Estudo de 
viabilidade 
Dada a necessidade de se desenvolver um sistema, investiga-se a 
possibilidade de a ferramenta a ser proposta efetivamente atender as 
necessidades do usuário partindo do ambiente computacional de 
hardware e software existentes, da interação com os clientes/usuários, do 
orçamento disponível e do ambiente de negócio vigente na organização. 
Elicitação e 
análise de 
requisitos 
Partindo do entendimento de que a organização possui ou não um 
ambiente computacional prévio de hardware e de software, efetiva-se 
interações com os usuários/clientes a fim de identificar suas reais 
necessidades as quais impulsionam para o desenvolvimento de novos 
sistemas, permitindo inclusive a idealização de ferramentas por meio de 
modelos voltados à prototipagem. 
Especificação 
de requisitos 
Tendo estudado a viabilidade e efetivada a elicitação de requisitos, 
parte-se para o levantamento de informações efetivas e que devem ser 
registradaspor meio dos requisitos de usuário (abstrações das 
necessidades efetivas do cliente e do usuário) e requisitos de sistema 
(descrição das funcionalidades a serem implementadas pelo profissional 
de TI). 
UNIDADE 
02 
 
 
 
 
 
 
 
 
 
28 
 
 
Validação de 
requisitos 
Constata se os requisitos especificados serão efetivamente atendidos na 
ferramenta a ser desenvolvida, permitindo a correção das 
especificações. 
Fonte: adaptado de Sommerville (2011), Vazquez e Simões (2016) e Pressman (2011) 
 
 
 
 
 
 
Cabe o destaque quanto os modos de levantamento de informações junto a 
clientes/usuários na fase de Estudo de Viabilidade, de modo que estes podem se dar 
por meio de entrevista, questionário, reuniões, observações, análises documentais 
(WAZLAWICK, 2013; PRESSMAN, 2011). 
Quanto ao processo de Análise de Requisitos, naturalmente serão levantados 
Requisitos Funcionais e Não Funcionais. Em relação aos Requisitos Funcionais, tem-se 
que estes retratam as funcionalidades do software no intuito de que se planeje o 
treinamento dos usuários (exemplo: dados de cadastros de cliente, dados de 
cadastro de pedido); já os Requisitos Não Funcionais referem-se às estratégias 
utilizadas para que o sistema computacional esteja apto a resolver as problemáticas 
para as quais se fez desenvolvido (exemplo: efetivação de login e de autenticação 
de usuário) (WAZLAWICK, 2013; VAZQUEZ; SIMÕES, 2016; HIRAMA, 2012). 
Isto, se bem definido auxiliará no pleno entendimento das necessidades do 
cliente/usuário, na manutenção futura do sistema, na redução do esforço 
desempenhado para o desenvolvimento, na diminuição dos custos e tempos de 
entrega e na validação final do sistema (WAZLAWICK, 2013; PETERS, 2001). 
Em se tratando da Validação de Requisitos, é importante atentar para o papel 
do cliente/usuário neste processo, pois é justamente o seu feedback que dará ao 
desenvolvedor o entendimento quanto ao cumprimento dos requisitos funcionais e 
não funcionais levantados (PRESSMAN, 2011; VAZQUEZ; SIMÕES, 2016). 
A etapa de Especificação de Software também é denominada de Engenharia de 
Requisitos. 
Elicitação: obtenção de informações, no intuito de identificar dados para a solução de 
um problema. Disponível em: https://bit.ly/3LqHG0O. Acesso em: 10 de mar. 2023. 
Requisitos: o mesmo que condições, exigências. Disponível em: https://bit.ly/35PLLF3. 
Acesso em: 10 de mar. 2023. 
 
https://bit.ly/3LqHG0O
https://bit.ly/35PLLF3
 
 
 
 
 
 
 
 
 
29 
 
 
Contudo, cabe destacar que a Especificação de Software não é uma ação 
que se deve efetivar apenas no início do Processo de Software, sendo importante 
que durante todo o cumprimento das ações de desenvolvimento do software a 
especificação se faça presente (PRESSMAN, 2011). 
 
2.2 PROJETO E IMPLEMENTAÇÃO DE SOFTWARE 
O Projeto de Software descreve o software a ser implementado considerando 
a ideia elaborada para sua estrutura e funcionalidades, partindo da ação conjunta 
de uma equipe de projetistas que juntos estabelecem e revisam os elementos que 
deverão fazer parte do projeto em sua versão final (SOMMERVILLE, 2011). 
No Projeto de um Software não se considera informações unicamente da 
ferramenta a ser desenvolvida, pois faz-se essencial considerar todo o 
macroambiente tecnológico em que ela se fará inserida, ou seja, a Plataforma de 
Software a qual se faz composta pelo hardware, sistema operacional, base de dados 
e outros (WAZLAWICK, 2013). 
Daí se identifica a importância e relação desta fase com a de Especificação 
de Software: é justamente na etapa anterior que todas estas informações da 
Plataforma de Software serão identificadas, de modo a garantir que a ferramenta a 
ser desenvolvida se faça apta a usufruir das funcionalidades do ambiente para o qual 
ela será implementada (PRESSMAN, 2011). 
Pressman (2011) e Sommerville (2011) apresentam as atividades que fazem 
parte do Projeto de Software, e estas seguem apresentadas no Quadro 7. 
 
Quadro 7: Atividades de projeto executadas a nível do Projeto de Software 
Projeto de 
Arquitetura 
compreende a estruturação geral do sistema, considerando seus 
componentes, relacionamentos e distribuição destes 
Projeto de 
Interface 
compreende a definição de interfaces dos componentes e conexão 
entre estas interfaces 
Projeto de 
Componente 
compreende o funcionamento ou as alterações que devem ser 
efetivadas para cada componente do sistema 
Projeto de Banco 
de Dados 
compreende o projeto de estrutura de dados, sua representação e 
consequente alocação no banco de dados a ser reusado ou criado 
Fonte: adaptado de Pressman (2011) e Sommerville (2011) 
 
Sendo consequência do projeto, a Implementação de Software deve ocorrer 
intercalado ao projeto, de modo a garantir que sempre possa ser efetivada a revisão 
das ações implementadas (SOMMERVILLE, 2011). 
 
 
 
 
 
 
 
 
 
30 
 
 
A experiência do projetista, sua capacidade de abstração, o uso ajustado de 
sua intuição e a aplicação de ferramentas de projeto reconhecidas e bem 
desenvolvidas para esta finalidade devem representar papel importante na etapa 
de Projeto de Software, e é justamente tais fatores que serão de impacto na 
decodificação por meio da linguagem escolhida para o projeto (PRESSMAN, 2011). 
Neste sentido, o Quadro 8 apresenta aspectos que são fundamentais para 
todo e qualquer Projeto de Software. 
 
Quadro 8: Aspectos fundamentais para o Projeto de Software 
Abstração Solução identificada em atendimento ao problema relatado pelo 
cliente/usuário, podendo se apresentar sob a forma de procedimentos, 
algoritmos e código fonte 
Abstração de 
dados 
Dados processados, agrupados, característicos e favoráveis a descrever 
um dado objeto 
Modularidade Divisão do software em partes, módulos, que podem interagir 
internamente e acoplar-se com outros externamente 
Procedimento 
de software 
Especificações definidas para que cada módulo processe os seus próprios 
dados, podendo assim alimentar os demais 
Fonte: adaptado de Pressman (2011) 
 
Não havendo um padrão que obrigatoriamente deva ser seguido por todos 
os desenvolvedores, a equipe pode adotar uma abordagem única, no entanto a 
preferência de por onde dar início ao trabalho de decodificação dependerá 
unicamente do profissional de desenvolvimento e de suas habilidades (WAZLAWICK, 
2013). 
 
2.3 VALIDAÇÃO DE SOFTWARE 
A validação de software tem o papel de verificar se o software segue as 
especificações levantadas e se isto atende as necessidades apontadas pelo 
cliente/usuário (SOMMERVILLE, 2011). 
A principal técnica utilizada para a validação é o Teste de Software, dando-
se principalmente durante e após o processo de transformação do projeto em 
código, ou seja, da implementação do sistema (WAZLAWICK, 2013). 
Contudo, relata-se que muitos erros de sistema a serem encontrados durante 
os testes podem se dar após a implementação completa, levando o retrabalho do 
desenvolvedor e ao atraso na entrega do produto (PRESSMAN, 2011). 
Pressman (2011) e Sommerville (2011) apresentam os estágios do Processo de 
 
 
 
 
 
 
 
 
 
31 
 
 
Teste de Software, e estes seguem apresentados no Quadro 9. 
 
Quadro 9: Estágios do Processo de Testes 
Testes de 
desenvolvimento 
Os testes são efetivados em componentes isoladamente pelos próprios 
desenvolvedores 
Testes de sistema Estando os componentes integrados o sistema como um todo é 
testado no intuito de se encontrar erros e possibilidades de não 
atendimento aos requisitos 
Testes de 
aceitação 
O cliente fornece dados para que se efetive testes simulados no 
sistema, podendo revelar problemas nos requisitos e no desempenho 
Fonte: adaptado de Pressman (2011), Sommerville (2011) e Vazquez e Simões (2016) 
 
Os testes de aceitação podem ser efetivados até que as falhas sejam 
completamente sanadas, neste caso, tem-se os testes alfa. Contudo pode ocorrer 
casosem que o produto de software está finalizado e passa a ser utilizado por um 
grupo de usuários no intuito de que estes relatem suas experiências através dos testes 
beta, efetivados no intuito das devidas correções até que se torne apto para a 
comercialização/distribuição em definitivo (PRESSMAN, 2011). 
 
2.4 EVOLUÇÃO DE SOFTWARE 
Os softwares envelhecem passando anteriormente por processo de 
nascimento, maturação e estabilidade, e por isso necessitam de atenção especial 
para que se mantenham funcionalmente em atividade, atendendo as demandas 
dos usuários (PRESSMAN, 2011). 
Assim, no intuito de que, neste processo evolutivo o software não venha a 
declinar e consequentemente “morrer”, faz-se primordial a implementação de ações 
de manutenção que favoreçam a constante evolução do sistema, permitindo assim 
que sejam efetivadas adequações voltadas à interação entre software e hardware, 
garantindo que se mantenham em harmonia e plena produtividade (WAZLAWICK, 
2013). 
Tornar então o software apto para a evolução, tornando melhor o desenho de 
sua estrutura é um meio de garantir a longevidade do sistema, assim como 
documentar todo o projeto, desenvolvimento e manutenções permitindo que no 
futuro outras equipes de TI também possam garantir a operacionalização e 
produtividade do ambiente computacional já existente (PRESSMAN, 2011). 
A Evolução do Software é composta por ações únicas que muito se adequam 
quando não há viabilidade no desenvolvimento de um software desde seu estágio 
 
 
 
 
 
 
 
 
 
32 
 
 
inicial, tratando-se, portanto dos ajustes necessários para que o sistema se mantenha 
em pleno atendimento às necessidades de clientes/usuários mesmo havendo a 
mudança de requisitos de hardware na infraestrutura de tecnologia da organização 
(SOMMERVILLE, 2011; VAZQUEZ; SIMÕES, 2016). 
 
 
Neste sentido, e servindo de embasamento para o desenvolvimento de modos 
diferenciados de se compreender o desenvolvimento de software a partir de 
metodologias ágeis, nos anos 70 foram lançadas as Leis de Lehman e estas seguem 
devidamente apontadas no Quadro 10. 
 
Quadro 10: Leis de Lehman acerca da Evolução de Software 
Lei da Mudança Contínua 
A manutenção do sistema o adapta para que atenda às necessidades do usuário, 
requerendo portanto interação constante, mesmo que elas se alterem de modo 
crescente, sob pena de que a produtividade e satisfação sejam afetados 
consideravelmente ao longo do tempo 
Lei da Complexidade Crescente 
Sempre que um software sofre ajustes o seu nível de complexidade tende a aumentar, 
principalmente quando tais alterações não seguirem um planejamento estruturado de 
engenharia, podendo levar à necessidade de reestruturação do sistema caso alcance o 
nível de não mais atender às necessidades, produtividade e satisfação do usuário 
Lei da Autorregulação 
Os esforços dispendidos a cada versão e no tamanho do sistema não tende a variar 
durante a vida do sistema, seguindo as diretrizes definidas pela organização solicitante da 
ferramenta 
Lei da Conservação da Estabilidade Organizacional ou Lei da Taxa Constante de 
Trabalho 
Será contínua a necessidade de evolução do sistema, contudo isto não demandará 
aumento na equipe de tecnologia sob a pena desta se tornar improdutiva 
Lei da Conservação de Familiaridade 
O incremento de ajustes na evolução de um software é constante a cada versão, sendo 
importante que a equipe de tecnologia envolvida se mantenha harmoniosa e alinhada 
aos objetivos que necessitam ser seguidos 
Lei do Crescimento Contínuo 
Um sistema não deve ser ajustado apenas a nível de correção de erros, mas também na 
adição de novas funcionalidades, aumentando assim a satisfação do usuário 
Lei da Qualidade Decrescente ou Declinante 
A evolução do sistema é parte de seu processo de uso, elevando a qualidade. Assim, a 
ausência de mudanças não é boa como se pensa, sendo importante que os ajustes 
aconteçam em prol da elevação da qualidade por meio do reajuste do sistema ao 
desenho dos processos 
Lei do Sistema de Retorno ou de Feedback 
A etapa de Evolução de Software também pode ser denominada de Manutenção de 
Software. 
 
 
 
 
 
 
 
 
 
 
33 
 
 
 
 
Faz parte do processo evolutivo de software que usuários efetivem retornos avaliativos 
tanto positivos quanto negativos, pois é justamente estas ações que favorecem os ajustes 
e a evolução do sistema evitando sua “morte” prematura 
Fonte: adaptado de Audy (2014) 
 
Assim, foi importante observar que a Evolução de Software incorpora em si o 
entendimento da necessidade de manutenção, pois sem esta ação não se faz 
possível os ajustes ao longo da vida útil do sistema. 
Contundo, as constantes alterações em software levam à possibilidade de que 
o projeto de desenvolvimento nunca consiga alcançar uma finalização, sem que ao 
menos as versões sejam efetivamente finalizadas. A este tipo de contexto denomina-
se de Beta Eterno, onde, apesar de se percorrer todas as etapas tradicionais de 
desenvolvimento, o que se faz liberado ao usuário é uma versão beta, a qual ainda 
passará por uma infinidade de adequações que em tese levariam à finalização de 
sua elaboração (ALÃO, 2018). 
Diante deste modo de pensar, a possibilidade de dispor o software a uma 
quantidade grande de usuários antes de sua finalização, funcionaria como meio de 
aceleração no desenvolvimento, contudo, conforme destaca Alão (2018), não é o 
que acontece, pois, a exemplo de gigantes da tecnologia como o Google, tem-se 
a prática como meio de distorcer o entendimento do usuário de que sendo uma 
versão beta, as falhas são perdoáveis. 
Isto coloca a necessidade de reflexões em relação aos processos praticados 
em um mundo de versões beta, principalmente se considerando as Leis de Lehman 
em relação à evolução de software. 
 
 
Sendo o desenvolvimento um processo cíclico, além de a etapa de evolução demonstrar a 
importância da manutenção para que o software não se perca em sua possibilidade de 
atender as necessidades do cliente, avalie como as Leis de Lehman deixam caracterizado 
este processo de não retrocesso para o desenvolvimento de um novo software e sim a 
melhoria constante do que já existe, caso haja possibilidade, estabelecendo uma visão 
crítica acerca do Beta Eterno. 
Tendo por base as Etapas de Desenvolvimento de Software aqui estudadas, o observe a 
figura a seguir. 
 
 
 
 
 
 
 
 
 
34 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Neste vídeo da Dheka Consultoria, denominado de Video 3 – Processos e Desenvolvimento 
de Software. Disponível em: https://bit.ly/3V4y2nQ. Acesso em: 10 de mar. 2023. 
A apresentadora adiciona conhecimentos ao estudos que já efetivamos até aqui. Vale a 
pena conferir! 
Especificação 
de Software
Projeto e 
Implementação de 
Software
Validação 
de Software
Evolução de 
Software
https://bit.ly/3V4y2nQ
 
 
 
 
 
 
 
 
 
35 
 
 
FIXANDO O CONTEÚDO 
 
1. (adaptado de CESPE - BANRISUL – 2022, CESPE – TRT – 2012, CESPE – TELEBRAS – 2022) 
Julgue os itens subsequentes quanto serem verdadeiros ou falsos e indique a 
opção que apresenta a melhor resposta para sua avaliação: 
 
I. A especificação de requisitos é frequentemente composta de vários tipos de 
documentos e não raro abrange: visão geral; glossário; modelos do sistema; lista 
de requisitos funcionais e lista de requisitos não funcionais; especificação 
detalhada de requisitos. 
II. O objetivo principal da especificação de requisitos é documentar todas as 
necessidades dos clientes e obter um aceite quanto às entregas de produto 
propostas. 
III. As atividades fundamentais relacionadas ao processo de construção de um 
software incluem a especificação, o desenvolvimento, a validação e a evolução 
do software. 
IV. No âmbito da engenharia de software, o principal produto da engenharia de 
requisitos é o documento de especificação de requisitos de software. 
a) Apenas asafirmativas Il e Ill estão corretas. 
b) Apenas a afirmativa Ill está correta. 
c) Apenas as afirmativas I e Il estão corretas. 
d) Apenas a afirmativa I está correta. 
e) Todas as afirmativas estão corretas. 
 
2. (CREFITO - MA – 2018) A Engenharia de Software é um capítulo importante de toda 
a Análise e Desenvolvimento de projetos voltados à criação de Softwares, pois ele 
traz conceitos que até hoje são utilizados, sendo algumas vezes a base da 
construção de um Sistema. Sendo assim, qual das alternativas está correta quando 
falamos em Engenharia de Software e Projetos? 
a) O foco de um Projeto de Software é a busca da perfeição, no qual o Engenheiro 
deve realizar esta tarefa sozinho, com o intuito de atender as suas necessidades. 
b) A metodologia aplicada deverá estar diretamente vinculada ao Software, onde 
teremos que atender ao individual. 
 
 
 
 
 
 
 
 
 
36 
 
 
c) A Engenharia de Software objetiva diversas soluções, onde a qualidade do 
produto deve estar evidenciada, sendo que o produto final deverá atender ao 
cliente ao qual aquele produto tenha sido solicitado. 
d) Até o momento não está comprovado que a Engenharia é eficaz e eficiente para 
criação de um Software, pois a qualidade deste depende da equipe de 
desenvolvimento. 
e) A Engenharia de projetos trabalha para montagem de projetos estipulados por um 
conjunto de atores baseados nas suas experiências individuais. 
 
3. (CCV - UFC – 2016 - adaptado) Em projeto de software, um Stakeholder representa: 
a) Um conjunto de diagramas da UML que pode ser afetado pelo futuro projeto de 
software. 
b) Uma técnica de programação em pares que pode ser afetado pelo projeto de 
software. 
c) Uma Metodologia de testes de software que pode ser afetado pelo projeto de 
software. 
d) Uma Técnica aplicada para quantizar os riscos que podem afetar o projeto de 
software. 
e) Indivíduos e organizações cujos interesses podem ser afetados pelo projeto de 
software. 
 
4. (FAURGS - BANRISUL – 2018) ___________ se preocupa com todos os aspectos do 
desenvolvimento de sistemas computacionais, incluindo engenharia 
de hardware, software e processo; e _________ é uma disciplina da engenharia 
que se preocupa com todos os aspectos da produção de software, desde os 
estágios iniciais da especificação do sistema até sua manutenção, quando o 
sistema já está sendo usado. 
Assinale a alternativa que completa, correta e respectivamente, as lacunas do 
texto acima. 
a) Engenharia de Domínio – Engenharia de Software 
b) Engenharia Reversa – Engenharia de Sistemas 
c) Engenharia de Sistemas – Engenharia de Domínio 
d) Engenharia de Sistemas – Engenharia de Software 
e) Engenharia Reversa – Engenharia de Domínio 
 
 
 
 
 
 
 
 
 
37 
 
 
 
5. (FUNDATEC – RS – 2022)O teste de software compreende um conjunto de 
ferramentas e técnicas relacionadas à verificação e validação (V&V) de um 
sistema. Em relação ao tópico de teste de software, analise as assertivas abaixo, 
assinalando V, se verdadeiras, ou F, se falsas. 
( ) O teste beta é conduzido no ambiente de usuários reais, executando tarefas reais, 
sem a monitoração e interferência próxima dos desenvolvedores. 
( ) O teste de aceitação é utilizado para verificar se um sistema de software como 
um todo é consistente com sua especificação de requisitos, geralmente 
executado pela equipe de testes sem o envolvimento do usuário. 
( ) Ao corrigir erros de um sistema, é muito fácil introduzir novos erros ou reintroduzir 
erros que ocorreram anteriormente. Nessa situação, casos de teste aprovados em 
versões prévias do software podem ser verificados novamente através de testes 
de sistema. 
( )Testes unitários em sistemas orientados a objetos normalmente realizam verificações 
de falhas em classes individuais. 
A ordem correta de preenchimento dos parênteses, de cima para baixo, é: 
a) V – F – F – V 
b) V – V – F – V 
c) V – F – V – F 
d) F – V – F – F 
e) F – F – V – V 
 
6. (FCC – CE – 2022) Uma vez que o sistema tenha sido totalmente integrado, é 
possível testá-lo para propriedades emergentes, como desempenho e 
confiabilidade. Os testes de desempenho precisam ser projetados para: 
a) projetar o sistema como uma história realista com cenários que descrevem uma 
maneira de usar o sistema. Os usuários reais do sistema devem ser capazes de se 
relacionar com cada cenário específico. 
b) assegurar maior confiabilidade do sistema em vista das respostas dos usuários que 
o testam em ambiente replicado ou em protótipos específicos criados a partir de 
blocos do sistema que se pretende testar. 
 
 
 
 
 
 
 
 
 
38 
 
 
c) projetar casos de teste em que se considera cada requisito e se deriva um conjunto 
de testes para eles a fim de demonstrar que o sistema implementou 
adequadamente seus requisitos. 
d) assegurar que o sistema possa processar a carga a que se destina. Isso 
normalmente envolve a execução de uma série de testes em que se aumenta a 
carga até que o desempenho do sistema se torne inaceitável. 
e) convencer o usuário de que uma determinada versão do sistema é boa e 
confiável o suficiente para uso além de mostrar que o sistema atende todos os 
requisitos funcionais. 
 
7. (FAURGS - SES RS - 2022) Dentro do contexto de Teste de Software, o objetivo de 
________________ é checar se o software atende a seus requisitos funcionais e não 
funcionais, enquanto o objetivo de _____________ é checar que o software atende 
às expectativas do cliente. 
Assinale a alternativa que completa, correta e respectivamente, as lacunas do 
texto acima. 
a) depuração – validação 
b) verificação – depuração 
c) teste de componente – depuração 
d) verificação – validação 
e) validação – verificação 
 
8. (FUNDATEC – 2022) Relacione a Coluna 1 à Coluna 2, associando as técnicas de 
software com suas corretas descrições. 
Coluna 1 
1. Teste alfa. 
2. Teste beta. 
3. Teste de regressão. 
Coluna 2 
( )Casos de teste realizados nos componentes isoladamente contando com a 
participação apenas dos desenvolvedores 
( )Conduzido na instalação do desenvolvedor, em um ambiente controlado por eles, 
por um grupo representativo de usuários finais. 
 
 
 
 
 
 
 
 
 
39 
 
 
( )Conduzido nas instalações de um ou mais usuários finais, geralmente sem a 
presença de desenvolvedores, em um ambiente sem o controle destes últimos. 
A ordem correta de preenchimento dos parênteses, de cima para baixo, é: 
a) 1 – 2 – 3 
b) 1 – 3 – 2 
c) 2 – 1 – 3 
d) 3 – 2 – 1 
e) 3 – 1 – 2 
 
 
 
 
 
 
 
 
 
 
 
40 
 
 
METODOLOGIAS ÁGEIS 
 
 
 
 
 
3.1 HISTÓRIA, CONCEITO E IMPORTÂNCIA DAS METODOLOGIAS ÁGEIS 
Entre os anos de 1980 e 1990 a idealização dos sistemas tinha como ponto 
primordial a aplicação das ferramentas de Engenharia de Software, denominadas 
de Ferramentas CASE, sendo esta denominação proveniente do acrônimo de 
Computer-Aided Software Engineering, ou, traduzido livremente ao português, 
Engenharia de Software auxiliada por Computador (SOMMERVILLE, 2011; HIRAMA, 
2012; PETERS, 2001). 
Tal metodologia se fazia muito bem aceita e até certo ponto eficiente para o 
desenvolvimento de sistemas de grande porte, os quais tinham por especificidade 
principal a participação de uma quantitativo elevado de Engenheiros de Software, 
localizados em áreas geograficamente distantes, e que, no entanto, possuíam um 
prazo de entrega de suas demandas de desenvolvimento bem mais amplo do que 
se verifica atualmente (PRESSMAN, 2011). 
Contudo, sendo uma abordagem de melhor aplicação a estas características, 
diante das especificidades surgidas a partir dos anos de 1990, identificou-se a 
necessidade de desenvolver novos métodos que se aplicassem a projetos de 
software de médio e pequeno porte, consequentemente com prazos mais curtos e 
maiores restrições orçamentárias (WAZLAWICK, 2013; PETERS, 2001). 
Fez-se então surgir o que se denomina de MétodosÁgeis, sendo estes modos 
de compreender o desenvolvimento de tarefas de software com foco nas pessoas 
que as desenvolvem e não nas linhas de código, pois passou-se a identificar que o 
trabalho intelectual de desenvolvimento não poderia ser executado de modo linear, 
em série e muito menos com grau elevado de previsibilidade (HIRAMA, 2012). 
Neste sentido, um Método Ágil atuaria na diminuição da burocracia 
organizacional aplicada ao desenvolvimento de software, tornando o processo em 
si mais humano, porém mais rápido, dinâmico, flexível, interativo, garantindo que o 
desenvolvimento das tarefas efetivamente conseguisse alcançar uma fase de 
UNIDADE 
03 
 
 
 
 
 
 
 
 
 
41 
 
 
finalização com maior funcionalidade e coesão, mesmo diante da necessidade de 
revisões, caso necessárias (SOMMERVILLE, 2011; PRESSMAN, 2011, HIRAMA, 2012) 
Considerando assim que o cliente/usuário nem sempre reconhece suas reais 
necessidades, o Método Ágil encontra meios de garantir que, partindo da interação 
constante dos entes interessados, ou Stakeholders, faça-se a troca de informações 
necessária à identificação dos requisitos, de modo a garantir maior assertividade no 
desenvolvimento da solução solicitada (OLIVEIRA, 2018). 
Por meio da aplicação de conceitos que incorporam o fracionamento de 
entrega do produto computacional desenvolvido de modo incremental, da auto-
organização do time de trabalho, e do uso consciente da inteligência coletiva dos 
colaboradores, os Métodos Ágeis conseguem acelerar o processo de entrega de um 
produto elaborado a partir do desenvolvimento de um dado projeto (WAZLAWICK, 
2013). 
Sob tais fatores, os Métodos Ágeis, em um geral seguem os princípios 
norteadores descritos na Figura 7. 
 
Figura 7: Princípios norteadores dos Métodos Ágeis 
 
Fonte: adaptado de Waslawick (2013) 
 
Estes princípios demonstram a preocupação com as pessoas (Stakeholders), a 
•Por meio deste envolvimento, que necessita ser íntimo, o 
cliente fornece informações quanto aos requisitos do sistema, 
avaliando sua implementação
Envolvimento do 
Cliente
•Na interação com o cliente a equipe de desenvolvimento 
identifica necessidades de implementação que se efetivam 
de modo incremental
Entrega 
Incremental
•O profissional de TI se faz reconhecido em suas 
potencialidades sendo convocado a aplicar seus 
conhecimentos no projeto, conforme metodologia própria
Pessoas, não 
processos
•Um sistema não é um ambiente estático, estará sempre em 
mudanças e por isto, tanto sua estrutura quanto a equipe 
envolvida necessitam estar aptos a tal
Aceitar as 
Mudanças
•Um sistema não necessita ser complexo pois a simplicidade 
favorece o desenvolvimento e a manutençãoManter a 
Simplicidade
 
 
 
 
 
 
 
 
 
42 
 
 
melhoria contínua e incremental e com a diminuição da complexidade do sistema e 
dos processos por ele atendidos, pois é justamente o feedback constante, coletado 
pelo meio dos processos de interação implementados que favorecem o alcance de 
tais premissas. 
Deste modo, os Métodos Ágeis atualmente rompeu as barreiras do 
desenvolvimento de sistemas e sem veem aplicados às mais variadas áreas de 
atuação e do conhecimento nas organizações, como para o desenvolvimento de 
produtos/serviços com vistas à comercialização, na 
implementação/melhoria/inovação de processos e na educação para o 
desenvolvimento de projetos inovadores, trabalhos de pesquisa e atividades 
acadêmicas (SOMMERVILLE, 2011). 
 
3.2 VISÃO GERAL DAS METODOLOGIAS ÁGEIS DE MAIOR 
REPRESENTATIVIDADE NA TI 
O tempo passou e, tanto a agilidade quanto a assertividade no 
desenvolvimento de sistemas, tornaram-se exigências marcantes para as equipes de 
TI (OLIVEIRA, 2018). 
Deste modo, as Metodologias Tradicionais de desenvolvimento, apresentadas 
no capítulo anterior, viram-se impelidas à renovação a partir do advento das 
Metodologias Ágeis, potencializando suas habilidades e garantindo que a 
modelagem, até o momento aplicada aos sistemas, pudesse se tornar mais eficiente 
(SOMMERVILLE, 2011). 
Diante deste pensamento, frameworks passaram a ser desenvolvidos em 
atendimento a esta visão de agilidade e assertividade, sendo importante aqui 
estabelecer uma visão geral daqueles que são os de maior representatividade no 
âmbito da Tecnologia da Informação a partir do Quadro 11. 
 
Quadro 11: Visão Geral das Metodologias Ágeis existentes 
FDD - FEATURE DRIVEN DEVELOPMENT 
(DESENVOLVIMENTO CONDUZIDO POR RECURSOS) 
Criador(es): Jeff de Luca e Peter Coad Criação: 1997-1998 
 
Finalidade(s): 
Para favorecer as 
interações entre 
os membros do 
projeto e para a 
Stakeholders: 
 Gerente de Projeto 
 Especialista 
 Pessoal de 
Planejamento 
Lado A (benefícios): 
 Beneficia a todos os 
Stakeholders 
 Aplicado a qualquer 
tamanho de equipe 
Lado B (restrições): 
 Não é favorável 
para pequenos 
projetos 
 
 
 
 
 
 
 
 
 
43 
 
 
implementação 
de estratégia de 
desenvolvimento 
guiado por 
funcionalidades 
 Programador-
Chefe 
 Equipe de 
Funcionalidades 
 Favorece a Qualidade 
de Software 
 Atua na entrega de 
resultados frequentes, 
tangíveis e funcionais 
para a visualização de 
progresso do Projeto 
 Custo elevado 
pelo tamanho da 
equipe envolvida 
DSDM - DYNAMIC SYSTEM DEVELOPMENT METHODOLOGY 
Criador(es): Organização sem fins lucrativos Criação: 1994 
 
Finalidade(s): 
Correção de 
falhas do Modelo 
em Cascata, 
tornando-o mais 
dinâmico 
Stakeholders: 
 Coordenador 
 Desenvolvedor 
Sênior 
 Analista 
 Programador 
 Designer 
 Testador 
 Usuários 
 Patrocinador 
 Redator técnico 
 Desenvolvedor 
 DBA 
 Configurador 
 Suporte Técnico 
Lado A (benefícios): 
 Participação ativa, 
cooperativa e 
compartilhada entre os 
Stakeholders 
 Stakeholders dotados 
de poder decisório 
 Desenvolvimento 
iterativo, incremental 
partindo de requisitos 
essenciais previamente 
fixados e com entregas 
contínuas 
 Feedback e ações 
totalmente reversíveis 
 Possibilidade de 
efetivação de Teste em 
todo o Ciclo de Vida 
Lado B (restrições): 
 Não se aplica a 
projetos em que 
o risco à vida 
humana e o 
dano crítico não 
sejam bem 
tolerados 
 Não possui 
viabilidade caso 
seja impossível a 
criação de um 
protótipo 
 Requer a 
participação 
ativa de todos 
os Stakeholders, 
incluindo o 
cliente 
ASD - ADAPTIVE SOFTWARE DEVELOPMENT 
(DESENVOLVIMENTO DE SOFTWARE ADAPTÁVEL) 
Criador(es): Sam Bayer e James Highsmith Criação: 1997 
 
Finalidade(s): 
Evolução do 
método Rapid 
Application 
Development 
(RAD) 
Stakeholders: 
 Executivo 
Responsável 
 Facilitador 
 Escriba 
 Cliente 
 Gerente do 
Projetos 
 Desenvolvedor 
Lado A (benefícios): 
 Corrige as 
metodologias 
tradicionais encurtando 
o período de 
desenvolvimento 
através da divisão de 
projeto para 
implementação e 
testes 
Lado B (restrições): 
 Não é favorável 
para pequenos 
projetos 
 Risco de tomada 
de decisão 
precipitada por 
conta do fator 
tempo reduzido 
SCRUM 
Criador(es): Jeff Sutherland, John Scumniolates e Jeff Mackenna Criação: Anos 90 
 
Finalidade(s): 
Foco no produto 
e no cliente por 
meio de 
Framework 
voltado para a 
gestão de 
projetos 
Stakeholders: 
 Product Owner 
 Scrum Master 
 Equipe Scrum 
 Cliente 
Lado A (benefícios): 
 Entendimento da 
dinâmica de mudança 
dos requisitos 
 Gerencia e controla o 
trabalho em si 
tornando a equipe 
autogerenciável, 
funcional e valorizada 
Lado B (restrições): 
 Não é favorável 
para projetos 
muito simples e 
nem de curto 
prazo 
 Requer a 
participação 
ativa de todos 
os Stakeholders, 
 
 
 
 
 
 
 
 
 
44 
 
 
 Age na Identificação e 
remoção de causas de 
problemas, por meio 
de processos iterativos 
e incrementais 
incluindo o 
cliente 
XP - EXTREME PROGRAMMING 
(PROGRAMAÇÃO EXTREMA) 
Criador(es):Kent Beck Criação: final da década de 1990 
 
Finalidade(s): 
Aumento da 
qualidade e 
produtividade em 
projetos de 
desenvolvimento 
de software 
Stakeholders: 
 Programador 
 Cliente 
 Testador 
 Consultor 
Lado A (benefícios): 
 Participação ativa, dos 
Stakeholders 
 Planejamento iterativo 
e de curto tempo 
 Programação 
efetivada em duplas 
 Testagem constante 
 Design simplificado 
Lado B (restrições): 
 Ambientes de 
trabalho 
exaustivo 
 Ausência de 
incentivo para a 
reutilização de 
código 
ICONIX EXPRESS 
Criador(es): Doug Rosenberg Criação: Década de 90, mas publicada na década 
seguinte 
 
Finalidade(s): 
Propiciar ao 
cliente uma visão 
real do produto 
antes de sua 
finalização 
Stakeholders: 
 Analista 
 Gerente de projeto 
 Programador Júnior 
e Sênior 
 Usuário 
 Testador 
Lado A (benefícios): 
 Dotado de 
praticidade, 
simplicidade e poucas 
documentações 
 Os requisitos são 
rastreáveis 
 Foco na comunicação, 
qualidade, evolução 
tecnológica e 
experiência de valor 
Lado B (restrições): 
 Custo elevado 
 Não é favorável 
para projetos 
muito dinâmicos 
CRYSTAL 
Criador(es): Alistair Cockburn e Jim Highsmith Criação: 2000 
 
Finalidade(s): 
Gerenciar as 
pessoas 
envolvidas no 
projeto 
respeitando as 
características e 
habilidades 
individuais e da 
equipe no todo 
Stakeholders: 
 Desenvolvedor 
 Cliente 
 Gestor de Projeto 
 Usuário 
Lado A (benefícios): 
 Aplicável a todo tipo e 
tamanho de projeto 
 Aceita os modos 
diversificados de 
trabalho das pessoas 
envolvidas 
 Compreende que os 
projetos se diferem em 
suas necessidades 
Lado B (restrições): 
 Não é favorável 
para projetos 
muito grandes 
projetos 
 Não é favorável 
para equipes de 
trabalho muito 
grandes 
 Custo elevado 
por conta do 
fator prioridade 
 Restrição ao 
ciclo de 
desenvolvimento 
KANBAN 
Criador(es): Taiichi Ohno Criação: 1953 
 
Finalidade(s): Stakeholders: 
Sem especificação 
Lado A (benefícios): Lado B (restrições): 
 
 
 
 
 
 
 
 
 
45 
 
 
Gestão visual por 
meio de cartões 
ou papéis no 
intuito do 
alinhamento de 
valores 
 Torna a relação entre 
os Stakeholders mais 
dinâmica e 
colaborativa 
 Facilita a visualização 
dos problemas e do 
planejamento diário 
 Vulnerabilidade 
por conta da 
gestão visual 
 Não lida bem 
com solicitações 
emergenciais e 
mudanças 
constantes 
OPENUP 
Criador(es): Eclipse Foundation Criação: 2006 
 
Finalidade(s): 
Focada no 
planejamento e 
na gestão de 
projetos de 
software livre 
Stakeholders: 
 Arquiteto 
 Gerente de Projeto 
 Analista 
 Testador 
 Desenvolvedor 
 Outros 
(interessados) 
Lado A (benefícios): 
 Inclui apenas o que é 
essencial para o 
desenvolvimento de 
um software 
 Não se preocupa com 
aspectos como 
contratos, equipe e 
outros 
 Reduz riscos por conta 
de seu curto ciclo de 
vida 
 Faz uso de reuniões 
regulares 
Lado B (restrições): 
 Favorável 
apenas para 
projetos de 
pequeno porte 
 Não se 
preocupa com 
aspectos como 
contratos, 
equipe, e outros 
Fonte: Adaptado de Peters (2001), Sommerville (2011) e Oliveira (2018) 
 
O quadro apresentado dispõe acerca das metodologias de maior destaque 
entre as equipes de desenvolvimento de sistemas, por sua popularidade e/ou por 
terem se adaptado melhor às necessidades dos projetos desenvolvidos. 
No entanto vale ressaltar a existência de outras metodologias ágeis que valem 
ser estudadas a fim de que os processos de gestão em projetos de software sejam 
mais dinâmicos e resolutos. 
 
 
 
 
 
Existindo outras metodologias ágeis encontrei um artigo bem interessante que vai te ajudar 
a conhecer um pouco mais sobre o assunto, podendo ser acessado por este link: 
https://bit.ly/2rttf21. Acesso em 11 mar. 2023 
Também encontrei um Podcast que trata sobre Metodologias Ágeis para empresas, no 
entanto também valer a pena assistir. Acessível a partir do link: https://bit.ly/3AL4ToF. 
Acesso em: 11 mar. 2023 
https://bit.ly/2rttf21
https://bit.ly/3AL4ToF
 
 
 
 
 
 
 
 
 
46 
 
 
 
 
3.3 VANTAGENS DE APLICAÇÃO DAS METODOLOGIAS ÁGEIS (CLIENTE X 
DESENVOLVIMENTO) 
Em sua concepção, as Metodologias Ágeis se fizeram desenvolvidas para 
atender pequenas equipes de software no intuito de garantir que, durante o processo 
de desenvolvimento, a comunicação, a troca de ideias, a análise de problemas e a 
busca de soluções pudesse se dar em ambientes de menor formalidade, maior 
interatividade, maior constância e menor índice de falhas no processo 
(SOMMERVILLE, 2011). 
Isto, pois, naquele momento, as metodologias tradicionais aplicáveis 
principalmente ao desenvolvimento de sistemas de grande porte, impactavam 
principalmente nos prazos de entrega e nos custos dos projetos, uma vez que o ciclo 
de vida praticado não contava com a possibilidade de revisões pontuais dos 
requisitos e nem de testes durante o desenvolvimento do processo, somente ao final 
(PETERS, 2001). 
Outro aspecto importante a destacar é que o tamanho dos sistemas e 
consequentemente o seu grau de complexidade variou ao longo do tempo, e à 
época do surgimento de uma mentalidade ágil para o desenvolvimento de software 
a tecnologia começava seu processo de disseminação para as pequenas e médias 
empresas requerendo meios próprios de atendimento à suas demandas 
(WAZLAWICK, 2013). 
Diante deste entendimento de mudança de mentalidade, Sommervile (2011) 
Framework: é uma espécie de estrutura ou modelo aplicável à resolução de um problema 
em específico. Disponível em: https://bit.ly/40EiTen. Acesso em: 12 de mar. 2023 
DBA: O mesmo que DataBase Administrator ou Administrador de Banco de Dados. 
Disponível em: https://bit.ly/3oMlvJy. Acesso em: 12 de mar. 2023 
Backlog: Refere-se a atividades que necessitam ser executadas em um projeto. Disponível 
em: https://bit.ly/41OSKdS. Acesso em: 12 de mar. 2023 
Software Livre: programa de licença livre, podendo ser copiado, utilizado, distribuído e 
modificado de acordo com as necessidades do usuário, requerendo apenas que as 
modificações sejam compartilhadas com a comunidade de Software Livre. Disponível em: 
https://bit.ly/40BsTon. Acesso em: 12 de mar. 2023 
https://bit.ly/40EiTen
https://bit.ly/3oMlvJy
https://bit.ly/41OSKdS
https://bit.ly/40BsTon
 
 
 
 
 
 
 
 
 
47 
 
 
aduz quanto às perspectivas de escalonamento aplicadas às Metodologias Ágeis, 
onde a Perspectiva Scaling-up, aplicando-se a equipes voltadas ao desenvolvimento 
de software de grande porte e alta complexidade, favorece os processos de 
organização em prol de que, uma vez possuindo um objetivo a ser alcançado, seja 
possível o seu efetivo alcance, considerando a parceria do usuário, seu feedback e 
as questões que tendem a incorrer reajustando os processos cotidianamente. Por 
outro lado, a Perspectiva Scaling-out, aplicando-se à grandes e já estabelecidas 
corporações voltadas ao desenvolvimento de software, permite que a organização 
reveja seus processos, compreenda uma nova cultura e torne-se cada vez mais apta 
à agilidade por meio de métodos que carregam em seu bojo esta filosofia. 
Isto pois, as Metodologias Ágeis trazem desde a sua concepção os princípios 
dispostos por meio da Figura 8. 
 
Figura 8: Princípios das Metodologias Ágeis 
 
Fonte: adaptado de Sommerville (2011) e Oliveira (2018) 
 
Isto demonstra a potencialidade de redução de ações burocráticas no 
processo de desenvolvimento de software deixando as ações mais naturais e 
dotadas de maior ambientação para a troca de experiências em face interatividade 
positiva que é incentivada ao capital intelectual existente na equipe envolvida. 
 
 
 
Assim, para o Cliente, a Metodologia Ágil apresenta como vantagens estas 
que se fazem dispostas na Figura 9. 
Pode ser que você já conheça a denominação Stakeholders, no entanto valereforçar 
que se refere a um grupo de pessoas possuidoras de determinado interesse na 
organização e que, no caso de um projeto de software, são diretamente afetadas durante 
sua execução, como o cliente, os fornecedores, os usuários, os desenvolvedores. (HIRAMA, 
2012; PETERS, 2001). 
 
 
 
 
 
 
 
 
 
 
48 
 
 
 
Figura 9: Vantagens das Metodologias Ágeis para os Clientes 
 
Fonte: adaptado de Sommerville (2011), Wazlawick (2013) e Oliveira (2018) 
 
Portanto, reduzindo boa parte dos impactos negativos gerados pelas 
metodologias tradicionais, as Metodologias Ágeis traduzem ao cliente a possibilidade 
de que os sistema incorpore em si as funcionalidades por ele solicitadas em face de 
sua demanda de negócios, permitindo que em tempo hábil a tecnologia venha a se 
fazer presente no contexto da organização. 
 
 
 
Consequentemente, as Metodologias Ágeis também favorecem ao trabalho 
dos desenvolvedores, de modo que a Figura 10 apresenta estas principais vantagens. 
 
Figura 10: Vantagens da Metodologias Ágeis para os Desenvolvedores 
 
Fonte: adaptado de Pressman (2011), Sommerville (2011) e Oliveira (2018) 
ROI (Return over Investiment): em sua tradução tem-se Retorno sobre o Investimento, e 
compreende um tipo de medida a qual permite avaliar se os investimentos efetivados por 
uma organização retornaram sob a forma de lucratividade. Disponível em: 
https://bit.ly/3LuZA2P. Acesso em: 18 de mar. 2023 
https://bit.ly/3LuZA2P
 
 
 
 
 
 
 
 
 
49 
 
 
Assim, atuando na facilitação do processo de desenvolvimento, uma vez que 
deixa de isolar o desenvolvedor do entendimento do negócio para o qual este 
desenvolve a solução, permite-se que a compreensão favoreça a identificação 
clara de possibilidades de solução melhor aplicadas e mais assertivas. 
Contudo, Sommerville (2011) destaca que a aplicação de Metodologias Ágeis 
em organizações, principalmente de grande porte, é antes de mais nada um 
processo de mudança cultural, pois considerando que muitos procedimentos já se 
encontram arraigados, necessita-se todo um reajuste do modo de vê-los, concebê-
los e de atuar sobre e com eles. 
 
3.4 MANIFESTO ÁGIL 
No início dos anos de 2000 e ainda vivenciando toda o processo de requisição 
de mudança para o modo de conceber software por conta do crescimento 
tecnológico enfrentado pela popularização das tecnologias, por conta da 
miniaturização dos componentes e pela consequente queda de seus custos, o 
paradigma do desenvolvimento por meio de metodologias tradicionais viu-se diante 
da necessidade de ser rompido, cedendo espaço para o novo, ou seja, uma visão 
ágil aplicada ao software (PRESSMAN, 2011). 
 
Figura 11: Membros do comitê de elaboração do Manifesto Ágil 
 
Fonte: O autor 
 
Assim, exatamente no ano de 2001, um grupo formado por 17 profissionais e 
 
 
 
 
 
 
 
 
 
 
50 
 
 
consultores de tecnologia (Figura 11), encontrou-se impelido a discutir estratégias que 
rompessem definitivamente com o paradigma metodológico tradicional aplicado ao 
desenvolvimento de softwares de grande porte e alta complexidade, e que se fazia 
imposto inclusive aos softwares de pequeno porte e baixa complexidade, 
acarretando problemas de entrega, custo, engajamento, entre outros (WAZLAWICK, 
2013; FERNANDES; ABREU, 2014). 
Em face destes profissionais e consultores possuírem experiência comprovada 
diante das proposições discutidas e transformadas em documento por meio do 
Manifesto Ágil, eles não consideravam que seria de maior dificuldade a 
implementação daquilo que estavam propondo e que não fugia muito ao 
tradicional, apenas adicionava elementos de gestão mais precisos, participativos e 
interativos (SUTHERLAND, 2014). 
Comparando o Quadro 11 (disposto no tópico anterior) com a Figura 11 é 
possível notar que muitos dos indivíduos que fizeram parte da concepção do 
Manifesto Ágil possuíam a expertise de elaboração de metodologias que aplicavam 
a filosofia defendida, demonstrando que não estavam trabalhando a partir de 
suposições e sim de constatações. 
Deste modo, as Metodologias Ágeis tinham como foco as diretrizes indicadas 
na Figura 12. 
 
Figura 12: Diretrizes apontadas pelo Manifesto Ágil 
Equipes Autogerenciáveis 
atuação conjunta e 
decisiva da equipe sob 
uma liderança que realiza 
o intermédio necessário 
Entregas Menores 
a diminuição nos incrementos 
de software permite que a 
entrega de funcionalidades 
possa acontecer em menor 
tempo 
 
Comunicação 
a equipe de negócio se 
mantém em constante 
contato com a de 
desenvolvimento 
Planejamento Incremental 
o planejamento se faz no 
todo, contudo as ações 
se efetivam em etapas, 
sendo estas 
contabilizadas na 
composição do plano 
total 
ABORDAGEM ÁGIL 
= 
COMUNICAÇÃO 
= 
CÓDIGO LEGÍVEL 
Uso de TDD 
(Test-Driven 
Development) 
a técnica se volta para 
constante efetivação de 
testes, evitando testes 
somente ao final do 
projeto 
 
Uso de Refatoração 
o código passa por 
processo de melhoria 
constante garantindo 
 
Preferência por Equipes 
Pequenas 
a opção por equipes pequenas 
facilita a comunicação, 
 
Integração sistêmica 
continua 
os incrementos finalizados 
são sempre habilitados ao 
todo do sistema 
https://en.wikipedia.org/wiki/Test-driven_development
https://en.wikipedia.org/wiki/Test-driven_development
 
 
 
 
 
 
 
 
 
51 
 
 
uma manutenção mais 
facilitada 
minimiza os conflitos e maximiza 
a produção 
Fonte: adaptado de Pressman (2011), Sommerville (2011) e Fernandes e Abreu (2018) 
 
Assim, na visão apresentada por meio do Manifesto Ágil a ação leva à 
agilidade dos processos de desenvolvimento onde o negócio e o cliente são a 
prioridade, demonstrando que a tecnologia posiciona-se como ferramenta auxiliar 
ao trabalho. 
Isto demonstra a especificidade que o manifesto pratica, uma vez que a 
produção de software passa a ser vista de modo direcionado e individual e não 
seguindo um paradigma industrial como definido por Lehman (AUDY, 2014) e 
apresentado aqui no Quadro 10 da unidade anterior. 
Contudo, e como já abordado anteriormente, há de se proceder com ajustes 
de cultura organizacional, pois as Metodologias Ágeis não somente preconizam 
disposições para o desenvolvimento de software, mas para todo tipo de ação que 
venha a requerer planejamento, envolvimento de pessoas, uso de capital intelectual 
e solução de problemas (PRESSMAN, 2011; SOMMERVILLE, 2011). 
 
 
 
3.5 VALORES E PRINCÍPIOS DEFENDIDOS NO MANIFESTO ÁGIL 
No intuito de romper com o paradigma de desenvolvimento de software 
utilizado na época pelas grandes empresas de software e que não se adequava nem 
a pequenas organizações e muito menos a projetos mais enxutos, como já relatado, 
um grupo de profissionais e consultores de tecnologia se reuniu e após discussões 
definiu elaborar um documento, na forma de manifesto, apresentando os pontos que 
consideravam ser essenciais para transformar e fortalecer o desenvolvimento de 
software em uma sociedade que à cada dia se tornava mais inteirada com o uso de 
tecnologias nos negócios e no cotidiano (WAZLAWICK, 2013; FERNANDES; ABREU, 
2014; SUTHERLAND, 2014). 
Refatoração: Processo aplicado à melhoria de código, sem afetar a parte visível ao 
usuário. Disponível em: https://bit.ly/3NcVcXw. Acesso em: 20 de mar. 2023 
 TDD (Test-Driven Development): possuindo como tradução Desenvolvimento Orientado a 
Testes, é uma metodologia em ciclos aplicada ao desenvolvimento de software e escrita 
de seu código. Acesso em: https://bit.ly/3LDvIBr. Acesso em: 20 de mar. 2023 
 
https://bit.ly/3NcVcXw
https://en.wikipedia.org/wiki/Test-driven_development
https://bit.ly/3LDvIBr
 
 
 
 
 
 
 
 
 
52 
 
 
Assim, o manifesto, preconizava o estabelecimento de melhorias para o 
desenvolvimento de software e o auxílio a todos os demais desenvolvedores que 
definissem optar pelos mesmo valores, estando estes dispostos na figura13. 
 
Figura 13: Valores definidos pelo Manifesto Ágil 
 
Fonte: adaptado de Audy (2014), Sommerville (2011), Waslawick (2013), Beck et al. (2001) e 
Sutherland (2014) 
 
Por conseguinte, o Manifesto Ágil estabeleceu princípios a serem seguidos, e 
estes se fazem dispostos por meio da Figura 14. 
 
Figura 14: Princípios definidos pelo Manifesto Ágil 
 
Fonte: Disponível em : https://bit.ly/3oK2uHK. Acesso em : 02 de abr. (2022) 
 
https://bit.ly/3oK2uHK
 
 
 
 
 
 
 
 
 
53 
 
 
Estes princípios demonstram que o conhecimento, a relação interpessoal, o 
gerenciamento, o contato com o cliente, entre outros, são aspectos que devem 
servir de elementos norteadores quando a agilidade for o foco de trabalho de 
equipes de desenvolvimento que optam pela excelência. 
 
 
 
 
 
Mesmo que tenhamos tratado sobre o manifesto ágil nesta unidade, vale a pena conferir 
outras informações sobre ele. Portanto, segue o link: https://bit.ly/2WcUnQa. Acesso em: 
20 de mar. 2023, da página oficial do manifesto, onde se pode encontrar na íntegra os 
valores, princípios, e outras informações referentes aos autores do documento que 
transformou o modo de conceber software na atualidade. 
 
Metodologias Ágeis atualmente são utilizadas em muita coisa. Então imagine-se 
implementando uma metodologia ágil para efetivar a elaboração do seu café, almoço 
ou jantar. Pesquise um pouco e verifique qual melhor se adaptaria a esta situação. A ideia 
aqui é compreender que efetivamente, uma ferramenta criada para a área de software, 
tem revolucionado os processos de gestão pelo mundo afora em face de sua objetividade 
e não burocracia. 
https://bit.ly/2WcUnQa
 
 
 
 
 
 
 
 
 
54 
 
 
FIXANDO O CONTEÚDO 
 
1. (BANRISUL - FAURGS – 2018) Segundo Pressman, os interessados (stakeholders) de 
um processo de software podem ser categorizados em: gerentes seniores, 
gerentes (técnicos) de projeto, programadores, clientes e usuários finais. Dentre 
essas categorias, ___________ é a que reúne aqueles que devem ter habilidades 
técnicas necessárias para desenvolver a engenharia de um produto ou aplicativo 
de software. 
Assinale a alternativa que preenche corretamente a lacuna do texto acima. 
a) gerentes seniores 
b) programadores 
c) usuários finais 
d) clientes 
e) gerentes (técnicos) de projeto 
 
2. (BANESE – 2022) Acerca dos métodos ágeis, analise as assertivas e assinale a 
alternativa que aponta a(s) correta(s). 
I. Os métodos ágeis foram desenvolvidos para serem utilizados por pequenos times 
de desenvolvedores. 
II. Empresas pequenas, que não tinham processos formais, foram os primeiros 
entusiastas dos métodos ágeis. 
III. Uma das vantagens do desenvolvimento ágil é que ele pode ser utilizado para 
qualquer tipo de desenvolvimento de software. 
a) Apenas I. 
b) Apenas II. 
c) Apenas III. 
d) Apenas I e II. 
e) Apenas II e III. 
 
3. (Câmara de Sorocaba - 2022) Sobre especificação de requisitos, analise as 
afirmações a seguir? 
I. Idealmente, os requisitos de usuário e de sistema devem ser claros, inequívocos, de 
https://www.qconcursos.com/questoes-de-concursos/institutos/banrisul
https://www.qconcursos.com/questoes-de-concursos/provas/faurgs-2018-banrisul-teste-de-software
https://questoes.grancursosonline.com.br/prova/camara-de-sorocaba-sp-2022-avanca-sp-analista-de-sistemas
 
 
 
 
 
 
 
 
 
55 
 
 
fácil compreensão, completos e consistentes. 
II. Os requisitos de usuário para um sistema devem descrever todos os requisitos de 
modo que sejam compreensíveis para usuários do sistema que não tenham 
conhecimento técnico detalhado. 
III. O documento de requisitos não deve incluir detalhes da arquitetura ou projeto do 
sistema. 
Estão corretas as afirmações: 
a) I, somente 
b) I e II, somente 
c) II e III, somente 
d) I e III, somente 
e) I, II e III 
 
4. (IFMT – 2022) Atualmente, o gerenciamento de riscos é reconhecido como uma 
das mais importantes tarefas de gerenciamento de projetos e envolve a 
identificação e a avaliação dos importantes riscos do projeto para estabelecer a 
probabilidade de que eles aconteçam e as consequências para o projeto caso 
esses riscos ocorram. Neste contexto, Sommerville (GOMMERVILLE, lan. Engenharia 
de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011) afirma que o gestor de 
projetos de software deve: 
a) Durante o processo de análise de riscos, considerar cada risco identificado e fazer 
um julgamento sobre a probabilidade e a gravidade desses riscos. É necessário 
que confie em seu próprio julgamento, na experiência advinda de projetos 
anteriores e de problemas que surgiram neles, pois não é possível fazer uma 
avaliação precisa e numérica da probabilidade e gravidade de cada risco. 
b) Impedir que haja riscos dentro de um projeto e estar preparado para as situações 
que tragam algum nível de suscetibilidade a impedimentos à conclusão de suas 
atividades ou ainda que as atrasem. 
c) Estar ciente de que não é possível pensar em ações que possam ser tomadas para 
cada um dos riscos identificados. Deve-se então procurar minimizar a interrupção 
do projeto, caso ocorra o problema que foi escolhido para ser sanado. Isso 
simplifica o processo de planejamento de contingência. 
d) O número certo de riscos a serem monitorados deve depender do projeto, no 
entanto o número de riscos escolhidos para monitoração precisa ser igual ao 
 
 
 
 
 
 
 
 
 
56 
 
 
número de riscos identificados na tarefa de análise, sob pena de inviabilizar o 
projeto com os efeitos nocivos de sua concretização. 
e) Ter a certeza da existência de riscos e a certeza da impossibilidade de tratá-los. 
Na gestão de riscos em projetos de softwares, a atividade de identificação é a 
única saída para não sofrermos os efeitos de tais incidentes e as ações de 
contenção estão limitadas à sua remediação graças à sua imprevisibilidade. 
 
5. (IFMT - IFMT – 2022) A Engenharia de Software evidencia mais do que a gestão de 
um projeto de software: ela antecipa atividades de manutenção e evolução do 
produto, indo além da capacidade de gestão da construção do produto, visando 
a sua longevidade. A respeito dos processos de evolução descritos em Sommerville 
(2011), em Engenharia de Software (9ª edição), analise as afirmativas a seguir e 
assinale a alternativa INCORRETA: 
a) As mudanças nos sistemas podem ocorrer de uma maneira informal ou formal 
dependendo da organização, mas todas as propostas de mudanças, no fim das 
contas, são acionadores de evolução: visam a correção de bugs, implementação 
de requisitos (que, por algum motivo, não foram atendidos no projeto), novos 
requisitos ou ainda novas ideias da equipe de desenvolvimento. 
b) O processo de evolução de um software inclui as atividades fundamentais de 
análise de impacto, planejamento de release, implementação da mudança e 
liberação de um sistema para os clientes. 
c) Como os processos evolutivos não são necessariamente documentados, é 
contraindicado o uso de técnicas de testes de regressão automatizados, pois 
podem gerar relatórios que não retratam a realidade, já que um novo fluxo 
informacional está sendo criado dentro do sistema. 
d) As Leis de Lehman nos indicam que a mudança é um processo contínuo e nos 
oferece uma série de parâmetros e considerações oriundas de estudos extensos 
de evolução de sistemas para que possamos nos situar acerca das implicações 
em se ter um sistema computacional saudável e útil por um longo período de 
tempo. 
e) A Reengenharia de Software se faz necessária quando o software a ser evoluído 
parte de um sistema legado que precisa se tornar mais fácil de ser mantido. 
Contudo existem limites práticos para a capacidade de melhoria por meio da 
 
 
 
 
 
 
 
 
 
57 
 
 
reengenharia, e isso pode inviabilizar o processo de melhoria, evidenciando a 
necessidade de reconstrução completa do sistema. 
 
6. (IBADE – SEA - SC – 2022 - adaptado)Scrum, Extreme Programming e OpenUp, são 
exemplos de: 
a) programação estruturada. 
b) projeto estruturado. 
c) metodologias ágeis. 
d) business intelligence. 
e) projeto conceitual. 
 
7. (IBFC - EBSERH – 2022) Na Engenharia de Software existem várias metodologias de 
desenvolvimento tais como: 
(1) Metodologia Ativa 
(2) Scrum 
(3) Desenvolvimento Ágil 
(4) Modelo Cascata 
Da relação apresentada, somente são aplicadas: 
a) 1, 2 e 3 
b) 1, 2 e 4 
c) 2, 3 e 4 
d) 1, 3 e 4 
e) 1, 2, 3 e 4 podem ser aplicados 
 
8. (TJ – SC – 2021 – adaptado) Um Analista de Sistemas atua no desenvolvimento 
de software utilizando diferentes processos e metodologias cujas características 
são: 
I. Aspectos significativos do processo devem estar visíveis aos responsáveis pelos 
resultados. A transparência requer que estes aspectos tenham uma definição 
padrão comum para que os observadores compartilhem um mesmo 
entendimento do que está sendo visto. Por exemplo: uma linguagem comum 
referindo-se ao processo deve ser compartilhada por todos os participantes; e 
 
 
 
 
 
 
 
 
 
58 
 
 
aqueles que realizam o trabalho e aqueles que inspecionam o incremento 
resultado do trabalho devem compartilhar uma definição comum de Pronto. 
II. A implementação inicial do software apoia duas atividades do processo de 
engenharia de requisitos: a) levantamento de requisitos, pois os usuários podem 
realizar experiências para ver como o sistema apoia seu trabalho, podendo ter 
novas ideias para os requisitos, identificar pontos positivos e negativos 
do software e até propor novos requisitos de sistema; b) validação de requisitos, 
pois a implementação pode revelar erros e omissões nos requisitos propostos, 
levando os usuários a crerem que sua visão inicial era incorreta e incompleta e 
dando a eles oportunidade de fazerem ajustes na especificação de sistema para 
refletir sua compreensão alterada dos requisitos. 
III. O cliente está sempre participando do desenvolvimento do sistema; testes de 
unidade e de aceitação fornecem feedback sobre o sistema; oportunidades e 
problemas são identificados o mais rápido possível; os códigos são integrados e 
testados constantemente, para o caso de algum problema ser detectado, poder 
ser corrigido imediatamente. 
As características I, II, III são, respectivamente: 
a) Iconix, ASD e DSDM 
b) Scrum, OpenUp e DSDM 
c) Kanbam, OpenUp e Crystal 
d) Scrum, Prototipação e XP 
e) XP, Crystal e ASD 
 
 
 
 
 
 
 
 
 
 
 
59 
 
 
METODOLOGIA XP 
 
 
 
 
4.1 HISTÓRIA, CONCEITO E IMPORTÂNCIA DA METODOLOGIA XP 
Além de terem participado da elaboração do Manifesto Ágil (Capítulo 3), no 
início dos anos de 1990, Kent Beck, Ward Cunninghan e Ron Jeffries (Figura 15), 
partiram dos valores por ele já definidos anteriormente e criaram uma metodologia 
inovadora para projetos denominada de Extreme Programming, a qual se fez 
aplicada primeiramente em um projeto para a empresa automotiva Chrysler no ano 
de 1996 (AUDY, 2022; WILDT et al., 2015; OLIVEIRA, 2018). 
 
Figura 15: Criadores da Metodologia Extreme Programming 
 
 
Kent Beck Ward Cunninghan Ron Jeffries 
Fonte: O autor 
 
Sua redução de denominação para XP, sugerida por Kent Beck, em virtude do 
destaque das letras eXtreme Programming, leva ao entendimento de que a 
metodologia se faz indicada principalmente para projetos em que os requisitos 
podem ser modificados a qualquer momento, demonstrando seu grau de 
flexibilidade neste sentido, e requerendo o entendimento de que o trabalho é 
efetivado em um ambiente de constante mudança, podendo oscilar entre os 
extremos (SOMMERVILLE, 2011; WILDT et al., 2015; WAZLAWICK, 2013). 
Assim, atuando em equipes pequenas e médias (sendo este o principal público 
da metodologia), prima-se pela ação iterativa, disciplina, pela possibilidade do 
UNIDADE 
04 
 
 
 
 
 
 
 
 
 
60 
 
 
desenvolvimento/integração/testagem de quantidades elevadas de versões 
contando com a atuação de programadores com variados conhecimentos 
(SOMMERVILLE, 2011; WILDT et al., 2015). 
Audy (2022) destaca como valores extremos no XP os seguintes: 
a revisão, a integração, a refatoração e o teste de código que necessitam ser 
efetivados constantemente/diariamente; 
a simplicidade que deve se aplicar no código e nos padrões de uso; 
a necessidade de contar com a participação do cliente sempre e diariamente se 
for o caso; 
a necessidade da arquitetura e das iterações serem definidas/redefinidas por 
todos os indivíduos envolvidos rapidamente e sem perda de tempo; 
a importância de que o tempo de trabalho incorpore espaço para descanso, não 
ultrapassando a carga de 40h semanais. 
Neste sentido, são valores gerais defendidos pelo XP estes que seguem listados 
na Figura 16. 
 
 
 
 
 
 
 
 
 
 
61 
 
 
Figura 16: Valores gerais defendidos pelo Extreme Programming 
Fonte: adaptado de Wildt et al., 2015; Wazlawick (2013); Oliveira (2018) 
 
Isto, conforme Oliveira (2018), favoreceu o aperfeiçoamento de práticas em 
matéria de desenvolvimento de software por meio da definição dos conceitos de: 
a) Integração Contínua: prima em garantir que o código se mantenha 
executável mesmo após o processo de alteração, no intuito de que seja possível 
manter a melhoria contínua com identificação de falhas por meio de testes 
automatizados e unitários; 
b) Ambiente Informativo:prima que o local em que se desenvolve o projeto 
espelhe o nível de desenvolvimento, garantindo que todos, independentemente de 
fazerem ou não parte da equipe, consigam identificar o seu status; 
c) Folga: prima em garantir que haja no planejamento previsibilidade de 
tempo para possíveis riscos, evitando que o tempo de execução seja 
completamente comprometido e atrasos por imprevistos tornem-se uma realidade. 
Deste modo, para melhor compreender a necessidade do cliente, no XP são 
COMUNICAÇÃO
•essencial pois age na transmição e troca de informacoes/conhecimentos, além de 
incentivar o feedback.
•consegue ocorrer pessoalmente ou virtualmente, escrita ou falada, contudo a 
efetividade pode ser afetada. 
•a presencial, face a face, é mais indicada fazendo uso de quadro branco para 
rabiscar ideias. 
SIMPLICIDADE
•mantém o foco no trabalho e na agregação de valor.
•foco em implementar o que é suficiente em atendimento à necessidade do 
cliente.
•minimizar a criação de classes complexas. 
FEEDBACK
•deve ser realizado a todo momento.
•o cliente aprende com o sistema, reavalia suas necessidades e gera feedback 
para o desenvolvimento.
CORAGEM
•as características pessoais dos membros da equipe em relação ao que e quando 
devem se comunicar.
•minimiza os medos naturais, principalmente em momentos de crise.
RESPEITO
•o respeito gera sentimento de valor
•aplica-se ao time e ao cliente.
•eleva a motivacao e a lealdade entre as pessoas envolvidas no projeto
•auxilia para a construção de uma relação transparente, duradoura, colaborativa e 
de entrega de valor. 
 
 
 
 
 
 
 
 
 
62 
 
 
estabelecidos cenários que expressam a história do usuário, ou seja, os requisitos do 
sistema, permitindo que, uma vez conhecidas as tarefas que necessitam se efetivar 
na forma de requisitos de sistema, os programadores se sintam confortáveis para 
implementarem a parte de código, possibilitando em seguida a efetivação de testes 
(SOMMERVILLE, 2011; GOMES, 2021). 
Demonstra-se assim o nível de simplicidade estabelecido pela metodologia 
garantindo que a comunicação entre cliente e desenvolvedor seja facilitada. 
 
 
 
 
4.2 FINALIDADE DA METODOLOGIA XP 
A Metodologia XP se volta para a criação de software de alta qualidade e 
valor, por conta de que o desenvolvimento em si possui início, meio e finalização, ou 
seja, efetiva o ciclo completo de desenvolvimento de software (WILDT et al., 2015). 
Tem ainda como aplicação a possibilidade de que partes do projeto possam 
se fazer executados desde as fasesiniciais de sua concepção, permitindo que, de 
modo incremental e contínuo, as funcionalidades sejam adicionadas às partes e ao 
projeto como um todo (WAZLAWICK, 2013). 
Neste sentido, compreende que a concepção de software é uma atividade 
de cunho intelectual, requerendo ajustes sucessivos até que consiga alcançar sua 
versão final, e para tal, estabelece a importância da comunicação presencial entre 
membros da equipe (entre si) e clientes, ofertando a possibilidade de que melhores 
e maiores informações sejam devidamente alcançadas e incorporadas 
constantemente ao projeto (COHN, 2005). 
 
 
Status: refere-se à situação/condição/posição alcançada por algo/alguém em um dado 
momento. Disponível em: https://bit.ly/3Atq3Y8. Acesso em: 23 de mar. 2023 
 
Aprofunde-se mais nos conhecimentos acerca do XP por meio do site oficial dele. 
Disponível em: https://bit.ly/3At7Iuf Acesso em: 22 de mar. 2023, desenvolvido por Don 
Wells. Vale a pena uma visita e um maior aprofundamento neste assunto. 
https://bit.ly/3Atq3Y8
https://bit.ly/3At7Iuf
 
 
 
 
 
 
 
 
 
63 
 
 
4.3 VANTAGENS E RESTRIÇÕES DE APLICAÇÃO DA METODOLOGIA XP 
Em suas práticas modernas e ágeis o XP espelha elementos anteriormente 
descritos no Manifesto Ágil, como o desenvolvimento incremental que mantém a 
contínua atualização e simplificação do sistema/código, o envolvimento entre o 
cliente e o time de desenvolvimento, garantindo que as informações fluam com 
maior tranquilidade entre os participantes e o foco nas pessoas e não nos processos, 
por meio do modo e tempo destinado à programação, descrevendo suas vantagens 
(SOMMERVILLE, 2011; WAZLAWICK, 2013). 
No entanto, a metodologia é difícil de ser implantada em equipes onde os 
desenvolvedores já possuem uma metodologia de trabalho próprio e individualizado, 
sem espaço para e crença na aprendizagem coletiva, a troca de 
informações/conhecimentos e o trabalho em par (SOMMERVILLE, 2011). 
Isto, além de outros aspectos, requer dos membros da equipe a abertura para 
novos processos de concepção do ambiente de trabalho, onde o cliente/usuário 
não recebe o produto apenas ao final da sua elaboração, participando de todas as 
etapas de sua construção (GOMES, 2021). 
 
4.3.1 EQUIPES E PAPÉIS NA METODOLOGIA XP 
Na metodologia XP a Equipe de Trabalho se faz composta por um grupo de 
profissionais atuantes em ações/objetivos complementares, de modo que, é possível 
situações em que um membro possa tomar a incumbência de mais de um papel 
(WELDT et al, 2015; WAZLAWICK, 2013). 
Contudo, isto não deve se aplicar às ações de gerente e técnico de equipe, 
pois compreende-se a possibilidade de afetar no desempenho direto da função por 
questão de conflito de interesses (WELDT et al, 2015). 
Deste modo a equipe se divide nas seguintes funções/papéis apresentadas 
por meio do Quadro 12. 
 
Quadro 12: Funções e Papéis dos membros do time XP 
Gerente Possui papel em ação administrativa na qual estabelece a comunicação 
entre clientes, fornecedores e organização, além de acompanhar o 
planejamento do projeto que se desenvolve durante todo o trabalho, não 
se limitando a uma etapa. Agenda reuniões, efetua demonstração do 
sistema para cliente/usuário, gera relatórios/gráficos que favoreçam o 
acompanhamento do projeto, além de administrar os requisitos essenciais 
 
 
 
 
 
 
 
 
 
64 
 
 
e que compõe a infraestrutura fundamental ao trabalho da equipe, como 
equipamentos, espaços, licenças, entre outros. 
Coach Possui função técnica de orientação a todos os membros da equipe, 
agindo na manutenção da disciplina, das práticas ágeis, das cerimônias 
e no uso de algumas ferramentas. Em sua atuação, que assegura a 
execução dos processos, cabe facilitar reuniões, orientar impasses e 
manter o time engajado. 
Testador ou 
Analista de 
Teste 
Mesmo fazendo parte da equipe XP, age em conjunto com o cliente para 
escolher/desenvolver/escrever os testes aos quais o sistema será 
submetido, levantando informações importantes de correção que 
deverão ser repassadas para que a equipe de desenvolvimento as efetue. 
Redator 
Técnico 
Atua em auxílio à equipe de desenvolvimento no processo de 
documentação do sistema. 
Desenvolvedor 
ou 
Programador 
Necessita ser dotado de conhecimentos que lhe permitam atuar em 
variadas etapas de desenvolvimento do projeto de software elevando o 
nível de agilidade do time. Portanto, além de analisar, projetar, prototipar 
e codificar, é importante ainda estimar as histórias de usuário, transformá-
las em tarefas, escrever testes e código e aprimorar o design final do 
sistema. 
Cliente ou 
Dono do Ouro 
Sua ação está em definir/priorizar os elementos que compõe as histórias 
de usuário e validar o produto através da efetivação de testes. Para tal 
necessita estar próximo ao time de desenvolvimento de modo a 
estabelecer conexões, trocar informações e dirimir possíveis dúvidas. 
Cleaner Membro do time que atua em prol de um código mais limpo, simples. Para 
tal influencia a limpeza, a refatoracão, a redução da complexidade e o 
enxugamento do código. Sob esta demanda, é importante vasto 
conhecimento técnico, de arquitetura, de negócios e didático, 
permitindo o impulsionamento de suas ações e a efetiva atuação junto 
ao time. 
Tracker Sua ação está em gerar métricas que permitam acompanhar o 
desenvolvimento do time, percorrendo a história de iteração da 
aplicação e seus apontamentos. Isto favorece a que possíveis resultados 
insatisfatórios não se efetivem, permitindo-se serem modificados antes da 
finalização do projeto através da relação do tracker com o time. 
Fonte: adaptado de Weldt et al. (2015) e Wazlawick (2013) 
 
Demonstrou-se assim o grau de profissionalismo apresentado por esta 
metodologia ágil e a possibilidade de que efetivamente consiga alcançar os 
objetivos para os quais se fez dimensionada. 
 
4.3.2 MODO DE AÇÃO E ETAPAS DA METODOLOGIA XP 
A metodologia XP possui um composto de ações que a tornam única e neste 
tópico as principais serão devidamente identificadas. 
 
 
 
 
 
 
 
 
 
 
 
 
 
65 
 
 
4.3.3 Jogo do Planejamento (Release Planning) e História de Usuário 
As entregas se fazem planejadas por clientes e desenvolvedores de modo 
colaborativo, por meio da escrita de história de usuário, permitindo que a 
comunicação seja a tônica dos processos envolvendo estes membros do projeto 
(WILDT et al., 2015; WAZLAWICK, 2013). 
Assim, ao invés do cliente contar/falar a respeito das funcionalidades que o 
sistema necessita dispor, ele as escreve, uma a uma, em um cartão/papel de modo 
simplificado e objetivo (WAZLAWICK, 2013). 
A história de usuário vai se fazendo construída, respaldando a ação da equipe 
de desenvolvimento que as transforma em tarefas, as quais, por sua vez, deverão ser 
implementadas em questão de poucas horas, não ultrapassando a carga de 1 dia 
de trabalho, requerendo, por conseguinte, que o profissional se volte a esta ação, 
sem distrações em atividades paralelas, colocando toda a sua atenção e energia no 
processo em execução (WILDT et al., 2015). 
Audy (2022) destaca que as informações apresentadas por meio da história 
de usuário devem conter características de independência entre os cartões 
elaborados, a possibilidade de negociação destas características, a agregação de 
valor dos relatos, possível mensuração e testagem das informações apresentadas, 
além de conterem dados suficientes, nem a mais e nem a menos. 
Justamente no intuito de que o tempo seja melhor utilizado, pode-se solicitar 
ao cliente a priorização de histórias que possuam maior impacto para o negócio, 
favorecendo o refinamento de requisitos (SOMMERVILLE, 2011). 
Por conseguinte, à medida que as funcionalidades definidas nos cartões de 
história de usuário vão se efetivando em desenvolvimento, anotações são realizadas 
nos cantos do cartão, permitindo o controle e o acompanhamento do progresso deexecução (WAZLAWICK, 2013). 
Contudo, tal metodologia compreende que os requisitos podem sofrer 
alteração de acordo com a especificidade do negócio, empreendendo o 
desenvolvimento de novos cartões de história de usuário a serem implementados 
para uma futura entrega (SOMMERVILLE, 2011). 
Em uma periodicidade que considera o espaço de aproximadamente 2 
semanas entregas são efetivadas para o cliente, procurando-se manter sempre estes 
prazos, mesmo que ocorram intercorrências (SOMMERVILLE, 2011). 
 
 
 
 
 
 
 
 
 
66 
 
 
Contudo, uma nova versão do sistema pode acarretar a necessidade de 
execução de uma série de procedimentos, incluindo os testes antes da entrega, o 
que deverá ser negociado com cliente para futuros releases que tendem a 
ultrapassar a periodicidade de 2 semanas referida anteriormente. Isto se explica 
inclusive pelo fato de que o cliente pode, conforme a filosofia da metodologia, 
alterar todas as histórias de usuário com base no aprendizado alcançado a partir do 
desenvolvimento e experimentação do sistema WAZLAWICK, 2013). 
Isto demonstra que, neste jogo, o cliente não se coloca como oponente e sim 
como parceiro de desenvolvimento. 
 
 
 
 
4.3.4 Programação em Par (Pair Programming) e Código Coletivo 
Em um time XP os desenvolvedores são levados a trabalhar em par, de modo 
que além da efetivação do revezamento de papéis a cada 15-20 minutos, as revisões 
e sugestões sejam desenvolvidas no momento do desenvolvimento e não depois dele 
(WAZLAWICK, 2013). 
Conforme apontam Wildt et al. (2015), Wazlawick (2013) e Sommerville (2011), 
os programadores atuam no processo como piloto e copiloto de produção, 
demonstrando a divisão de papéis entre a dupla, ou seja, a construção, por ser 
colaborativa, solicita habilidades sociais e cooperativas. 
Release: refere-se ao lançamento/liberação de novas versões de software (SOMMERVILLE, 
2011; WAZLAWICK, 2013; WILDT et al., 2015). 
 
A efetivação de Histórias de Usuário se posiciona para facilitar o levantamento de 
requisitos, de modo que a responsabilidade pelas informações alcançadas passa a ser 
partilhada com o cliente/usuário. Isto auxilia pois nem sempre o desenvolvedor conhece 
a ação de negócios que aquela função para a qual deverá desenvolver em código 
executará, garantindo assim que possa compreender na prática (por meio da explicação) 
como o processo deverá se efetivar. Esta prática é adotada em muitas das metodologias 
ágeis, pois se compreende que o usuário/cliente é o maior conhecedor do seu modelo de 
negócios (SOMMERVILLE, 2011; PRESSMAN; MAXIM, 2016) 
 
 
 
 
 
 
 
 
 
67 
 
 
Tal prática beneficia a ambos, de modo que segue na Figura 17 listagem 
apontado tais benefícios. 
 
Figura 17: Benefícios da Programação em Par 
 
Fonte: adaptado de Wildt et al. (2015) e Sommerville (2011) 
 
No sentindo de romper a resistência quanto a esta sistemática de trabalho 
coletiva, Sommerville (2011) e Wildt et al. (2015) destacam que a produtividade 
alcançada por desenvolvedores atuantes em par é a mesma de programadores 
isolados, contudo, a redução de falhas no processo e o compromisso interpessoal por 
conta da parceria é que se dispunham como elementos diferenciais. 
Por conseguinte, o desenvolvimento se apresenta através de um Código 
Coletivo, pois todos os membros da equipe acabam atuando no desenvolvimento 
do software, requerendo unicamente a definição de um padrão a ser seguido 
(WAZLAWICK, 2013). 
Isto mais ainda é reflexo de uma prática firmada na colaboração e na 
comunicação, demonstrando que o conhecimento de um time não é individual e 
sim coletivo, elevando inclusive a qualidade do produto elaborado (WAZLAWICK, 
2013; WILDT et al., 2015). 
 
4.3.5 Stand up Meeting 
O Stand up Meeting refere-se às reuniões que devem se efetivar sempre no 
início do trabalho, de modo rápido, em pé, não ultrapassando o tempo de 10-15 
minutos, de modo que os membros do time utilizem o momento para comentar as 
ações efetivadas no dia anterior e a projetar as que deverão ser executadas ao 
 
 
 
 
 
 
 
 
 
68 
 
 
longo daquele dia de atividades (WAZLAWICK, 2013; WILDT et al., 2015). 
Em círculo e sentido horário/anti-horário cada membro deve relatar as ações 
já efetivadas (dia anterior) e as que deverão se desenvolver (dia em curso), 
garantindo um maior alinhamento entre os membros do time por meio da visão 
coletiva acerca das ações em execução, favorecendo ainda a troca de 
conhecimentos (WAZLAWICK, 2013; WILDT et al., 2015). 
No entanto, Wildt et al. (2015) relatam que alguns erros são comuns na 
implantação/efetivação de um Stand up Meeting, sendo os mais comuns descritos 
na Figura 18. 
 
Figura 18: Erros comuns em um Stand up Meeting 
 
Fonte: adaptado de Wildt et al. (2015) 
 
Demonstra-se assim pontos que não devem se deixar interpor à realização do 
Stand up Meeting, dada a sua importância. 
 
4.3.6 Padrão de Codificação e Metáforas 
Os desenvolvedores tendem a expressar no trabalho/código suas 
características pessoais, no entanto, como o código necessita se comunicar com 
todo o time em face de ser uma construção coletiva, a especificação de um padrão 
de codificação que espelhe estilo único de programação a ser seguido por todos é 
 
 
 
 
 
 
 
 
 
69 
 
 
uma alternativa viável para dirimir possíveis problemas de transmissão de ideias 
(WAZLAWICK, 2013). 
Neste sentido, incorpora-se o uso de metáforas favorecendo para que, em 
pontos-chave do projeto, as denominações aplicadas também sejam de fácil 
entendimento para todos (WILDT et al., 2015). 
Assim, sempre que um membro do time identificar a mudança de algum 
destes elementos, deve alertar para que seja retomada a utilização do padrão 
(SOMMERVILLE, 2011), garantindo unidade no produto desde a sua concepção até 
a finalização. 
 
4.3.7 Refatoração (Refactoring) 
Esta ação é sinônimo de melhoria contínua com implementação imediata, 
principalmente quando se fizer necessária a simplificação da escrita do 
sistema/código e/ou implementação de novidades/alterações em histórias de 
usuário o que tende a elevar a qualidade do produto final (SOMMERVILLE, 2011; 
WAZLAWICK, 2013). 
A Refatoração, portanto, mesmo não sendo uma prática definida pela 
metodologia XP, possui nela sua importância elevada, pois a melhoria do código 
favorece a manutenção, independentemente do tipo (WAZLAWICK, 2013). 
Assim, a refatoração é consequência do Código Coletivo e do Padrão de 
Codificação, uma vez que se compreende a importância de que o código 
apresente boa legibilidade, devendo se tornar uma prática regular e constante, pois 
sua correta realização economiza tempo, aumenta a qualidade, melhora o design, 
torna o código legível e reutilizável e minimiza defeitos (SOMMERVILLE, 2011; WILDT et 
al., 2015). 
 
 
 
 
A Refatoração é um dos pontos de fundamental importância da Metodologia XP, pois a 
partir dela tem-se o refinamento sucessivo do código, tornando-o cada vez mais limpo e 
simples, contando não somente com a ação constante do Cleaner, mas também do Par 
de Desenvolvimento (SOMMERVILLE, 2011; WILDT et al., 2015; WAZLAWICK, 2013). 
 
 
 
 
 
 
 
 
 
 
70 
 
 
4.3.8 Desenvolvimento guiado por Testes (Test-Driven Development - TDD) 
Configura-se como uma ação em que a busca e a correção de falhas se 
efetiva durante o processo de desenvolvimento por meio de testes que podem ser 
de (WAZLAWICK, 2013): 
a) Teste de Unidade:teste que se efetiva em um componente de software 
individualmente, podendo focar em uma classe, método ou função, no intuito de 
verificar se a implementação se deu da maneira correta; 
b) Teste de Aceitação: teste efetivado pelo cliente no intuito de validar o 
software em relação aos seus requisitos. 
Neste sentido, o Desenvolvimento guiado por Testes necessita seguir as 
seguintes regras apresentadas por meio da Figura 19. 
 
Figura 19: Regras aplicáveis ao Desenvolvimentoguiado por Testes 
 
Fonte: adaptado de Wazlawick (2013) 
 
Caracterizando deste modo o grau de exigência definido pela metodologia 
em relação ao seu processo de execução. 
 
 
 
Publicizado: tornar público, comunicar aos demais. Disponível em: https://bit.ly/3HbOqx8. 
Acesso em: 25 de mar. 2023 
 
https://bit.ly/3HbOqx8
 
 
 
 
 
 
 
 
 
71 
 
 
 
 
 
O Modelo em Cascata é o mais conhecido para o desenvolvimento de software, tendo 
sido apresentado no Capítulo 1 deste material. Volte até lá e releia as considerações 
efetivadas para que após isto possa analisar criticamente os ganhos alcançados, em 
matéria de desenvolvimento de projetos de software, a partir da Metodologia XP. Você 
vai se surpreender com a comparação! 
 
 
 
 
 
 
 
 
 
72 
 
 
FIXANDO O CONTEÚDO 
1. (CONSULPAM - Prefeitura de Irauçuba - CE – 2022 - adaptado) Dentro das 
metodologias ágeis, o processo de desenvolvimento de software especificado 
pela Programação Extrema (eXtreme Programming, XP) possui algumas 
características específicas. Uma das características do XP versa sobre as 
necessidades de melhoria no projeto, que devem ser realizadas através de um tipo 
de processo específico para este fim. Assinale a alternativa com o nome deste tipo 
de processo. 
a) Testes de Unidade 
b) Refatoração 
c) Histórias do Usuário 
d) Programação em Pares 
e) Teste de Aceitação 
 
2. (IBFC - 2022 - AFEAM - adaptado) Quanto aos conceitos fundamentais sobre XP 
(Extreme Programming), explicitados em Sommerville (2011), analise as afirmativas 
a seguir e dê valores Verdadeiro (V) ou Falso (F). 
( ) Os requisitos são expressos como cenários (chamados de histórias do usuário), que 
são implementados diretamente como uma série de tarefas. 
( ) Em um processo de XP, o cliente jamais poderá ser considerado um membro da 
equipe de desenvolvimento. 
( ) Os pares de desenvolvedores trabalham somente em suas áreas específicas, e não 
em todas as áreas do sistema. 
Assinale a alternativa que apresenta a sequência correta de cima para baixo. 
a) V - F – F 
b) V - V – F 
c) F - V – V 
d) F - F – V 
e) V – V – V 
 
3. (IADES - 2022 - ADASA) Assinale a alternativa correspondente ao processo de 
desenvolvimento de software, cujos valores centrais são comunicação, 
simplicidade, feedback, coragem e respeito. 
 
 
 
 
 
 
 
 
 
73 
 
 
 
a) Scrum 
b) TDD 
c) Modelo interativo 
d) XP 
e) Modelo incremental 
 
4. (CESPE / CEBRASPE – 2022 - adaptado) Em relação à metodologia XP e seus valores 
fundamentais, assinale a opção que apresenta aquele que permite ao cliente 
conduzir diariamente o desenvolvimento e garantir que a equipe direcione suas 
atenções àquilo que irá gerar mais valor. 
a) comunicação 
b) feedback 
c) coragem 
d) simplicidade 
e) satisfação 
 
5. (FGV - 2022 - SEFAZ-AM) A metodologia Extreme Programming (XP) define uma 
série de práticas para desenvolvimento de software. 
Assinale a opção que apresenta a prática desta metodologia que contribui para 
produção de softwares de alta qualidade. 
a) Testes de aceitação devem ser construídos por analistas especializados, sem a 
participação do cliente. 
b) Programadores devem ter autonomia para utilizar seu próprio estilo de codificação 
desde que seja inteligível. 
c) Postergar sempre que possível o merge do trabalho dos desenvolvedores em uma 
linha principal compartilhada. 
d) Programar em par/dupla num único computador para assegurar que o código 
seja sempre revisto por duas pessoas. 
e) Vedar a refatoração de códigos já testados e aprovados para evitar a introdução 
de novos erros. 
 
6. (FUNDATEC - 2022 - IPE Saúde) O processo de desenvolvimento de software 
especificado pela Programação Extrema (eXtreme Programming – XP) começa 
 
 
 
 
 
 
 
 
 
74 
 
 
com uma fase de planejamento, na qual são levantados e descritos requisitos para 
o software na forma de _____________________. O projeto e desenvolvimento dos 
requisitos busca focar nas necessidades imediatas. Necessidades de melhoria no 
projeto são realizadas através de processos de ____________. Além disso, se 
recomenda que a atividade de codificação ocorra em _______________ e seja 
guiada por _______________. 
Assinale a alternativa que preenche, correta e respectivamente, as lacunas do 
trecho acima. 
a) histórias de usuários – refatoração – quartetos – testes 
b) histórias de usuários – testes – pares – casos de uso 
c) histórias de usuários – refatoração – pares – testes 
d) modelos de domínio – refatoração – pares – testes 
e) modelos de domínio – testes – quartetos – casos de uso 
 
7. (Instituto Consulplan - 2021 - TJM-MG - adaptado) O XP (Extreme Programming), 
uma metodologia ágil de desenvolvimento, foi empregado, pela primeira vez, em 
1996, em um projeto da Chrysler, chamado de C3 (Chrysler Comprehensive 
Compensation). Considerando que são apresentados cinco principais valores, 
assinale, a seguir, dois desses valores. 
a) Revisão e Respeito 
b) Coragem e Respeito 
c) Simplicidade e Revisão 
d) Feedback e Informação 
e) Satisfação e Efetividade 
 
8. (IUDS - 2021 - IF-RJ - adaptado) Extreme Programming (XP) é um método de 
desenvolvimento ágil. 
Analise as afirmações, a seguir, acerca do desenvolvimento XP. 
I - Bom gerenciamento de projeto e um envolvimento constante do cliente são 
cruciais para o sucesso do projeto. 
II - Provê pouco suporte para o gerenciamento de projeto e o cliente está, 
constantemente, sob pressão. 
 
 
 
 
 
 
 
 
 
75 
 
 
III - É motivado por 2 elementos cruciais: comunicação efetiva entre as pessoas 
envolvidas no projeto e a divisão de responsabilidades entre pessoas da área técnica 
e o cliente. 
Estão corretas as afirmações: 
a) I e II 
b) II e III 
c) I, II e III 
d) I e III 
e) Nenhuma das alternativas 
 
 
 
 
 
 
 
 
 
 
76 
 
 
METODOLOGIA SCRUM 
 
 
 
 
 
 
 
5.1 HISTÓRIA, CONCEITO E IMPORTÂNCIA DA METODOLOGIA SCRUM 
Nas bases da Metodologia Scrum, ainda nos anos de 1896 tem-se referência 
que em um artigo relacionado à fabricação de automóveis e bens de consumo, 
Hirotaka Takeuchi e Ikujiro Nonaka tenham apontado pela primeira vez uma 
metodologia de gerenciamento de projetos voltada a equipes pequenas, auto-
organizáveis, multidisciplinares, focadas em entrega de valor e melhoria contínua, 
traços de melhoria de desempenho, demonstrando que um novo modo de 
conceber a produção em todas as suas fases já começava a se fazer pensada 
(AUDY, 2022; FERNANDES; ABREU, 2014; SABBAGH, 2022). 
No início dos anos de 1990, Peter DeGrace e Leslie Hulet Stahl associaram o 
pensamento de Hirotaka Takeuchi e Ikujiro Nonaka a uma determinada estratégia do 
jogo de rúgbi, na qual os jogadores se apoiam mutuamente diante do seu adversário, 
e que recebe a denominação de Scrum, aplicando este conceito como ideal para 
a sistemática de produção referida em 1986 (AUDY, 2022; FERNANDES; ABREU, 2014). 
Contudo, a criação oficial de uma Metodologia Ágil denominada de Scrum, 
deu-se somente no ano de 1995, através dos esforços de Ken Schwaber, Jeff 
Shuterland e Mike Beedle (Figura 20) sendo oficializado por meio da publicação de 
um artigo intitulado “Scrum and the Perfect Storm”, que traduzido livremente se 
compreende como “Scrum e a Tempestade Perfeita” demonstrando os resultados 
alcançados com sua aplicação (SABBAGH, 2022; GOMES, 2014; OLIVEIRA, 2018; 
AUDY, 2022). 
 
UNIDADE 
05 
 
 
 
 
 
 
 
 
 
77 
 
 
Figura 20: Criadores da Metodologia Scrum 
 
Ken Schwaber Jeff Shuterland Mike Beedle 
Fonte: O autor 
 
Em 2001, após a assinatura do Manifesto Ágil, os criadores da Metodologia 
Scrum lançaram suas ideias por meio do livro “Agile Software Development with 
Scrum”, publicizando em definitivo e comercialmente este modo de trabalhar 
(SABBAGH, 2022; GOMES, 2014; OLIVEIRA, 2018; AUDY, 2022; FERNANDES; ABREU, 2014). 
 
 
 
OScrum, portanto, firmou-se como um framework ágil, voltado para a entrega 
frequente de projetos de software complexos, possuindo uma abordagem iterativa, 
regular, incremental, com ciclo de vida contínuo e entregas/prazos previamente 
definidos, dotando-se de estratégias minimizadoras do risco de execução e 
finalização no que concerne à inserção/ajustes de funcionalidades em um produto 
computacional (SABBAGH, 2022; FERNANDES; ABREU, 2014, WAZLAWICK, 2013; ALFF, 
2022). 
 
 
 
Aprofunde-se mais nos conhecimentos acerca do Scrum por meio dos sites oficiais da 
metodologia. Disponível em: https://bit.ly/40DMmFb. Acesso em: 25 de mar. 2023 
Neles são sempre disponibilizadas atualizações acerca da metodologia, além de outras 
informações. Vale a pena a visita para maior aprofundamento no assunto! 
 
Framework: estrutura que serve de guia prática para a elaboração de um produto ( 
SABBAGH,2022). 
https://bit.ly/40DMmFb
 
 
 
 
 
 
 
 
 
78 
 
 
Sua versatilidade está na entrega de projetos com rapidez mesmo em casos 
de necessidade de replanejamento, na alta adaptabilidade por conta do grau de 
flexibilidade a mudanças com ajuste em entregas, e na possibilidade de 
autogerenciamento da equipe que se faz alcançada a partir do momento em que 
os membros alcançam a maturidade proveniente de suas próprias experiências 
(ALFF, 2022) 
A partir do Scrum, portanto, tem-se um conjunto de melhores práticas que são 
avaliadas regularmente, garantindo gradualmente um processo de descoberta e 
melhoria contínua em atendimento às exigências do cliente quanto ao projeto, com 
qualidade, sustentabilidade e adição de valor (SABBAGH, 2022; AUDY, 2022). 
Isto requer a definição de papéis e processos que devidamente equilibrados, 
seguidos e coordenados atende aos pilares empíricos e recorrentes que 
fundamentam o Scrum, sendo estes apresentados por meio da Figura 21. 
 
Figura 21: Pilares do Scrum 
 
Fonte: adaptado de Oliveira (2018); Fernandes e Abreu (2014) e Audy (2022) 
 
Demonstra-se assim como a sistemática de trabalho envolve os membros da 
equipe (a serem especificados mais adiante) para, tornando-os protagonistas de 
todo o processo de desenvolvimento do produto. 
 
 
 
 
 
 
Empírico: baseado na experiência, na prática. Disponível em: https://bit.ly/3NbjNM8. 
Acesso em: 28 de mar. 2023 
 
https://bit.ly/3NbjNM8
 
 
 
 
 
 
 
 
 
79 
 
 
 
5.2 FINALIDADE DA METODOLOGIA SCRUM 
Configurando-se como uma metodologia ágil, de caráter iterativo, 
incremental, aplicável ao desenvolvimento/manutenção de projetos complexos, 
tem por principal característica a possibilidade latente de realizar entregas em menor 
tempo, mesmo contando com a participação efetiva e constante do cliente em 
processo de cooperação com os membros da equipe de desenvolvimento 
(FERNANDES; ABREU, 2014; OLIVEIRA, 2018; GOMES, 2014). 
Sommerville (2011) e Fernandes e Abreu (2014) destacam que o conceito 
desta metodologia não se faz aplicável unicamente na engenharia de software em 
si, pois sua atenção se volta principalmente para a iteração, demonstrando 
aplicabilidade a outras áreas de conhecimento que requeiram sistemáticas de 
gestão voltadas a questões empíricas e ao gerenciamento de projetos em geral, nos 
quais a equipe de desenvolvimento atue de forma colaborativa. 
Aos projetos complexos tem-se aqueles que possuem atualizações constantes, 
mas que não admitem a perda de qualidade, o que em se tratando de processo 
incremental constante torna-se uma situação difícil de ser controlada (FERNANDES; 
ABREU, 2014). 
 
5.3 VANTAGENS E RESTRIÇÕES DE APLICAÇÃO DA METODOLOGIA SCRUM 
Sendo um Scrum uma das metodologias ágeis mais populares em face de sua 
adequação não somente ao âmbito do desenvolvimento de software, Sabbagh 
(2022) aponta como benefícios de seu uso a possibilidade de percepção do retorno 
de investimento por parte do cliente por conta das entregas que são de maior 
frequência, denotando ainda uma maior visibilidade quanto ao seu progresso; a 
sistemática utilizada que diminui os riscos de execução e de desperdício no projeto; 
o aumento da produtividade relacionada diretamente à melhoria na qualidade do 
produto e consequentemente um reajuste significativo na vantagem competitiva. 
Às demais organizações favorece ao maior controle e agilidade no 
desenvolvimento e gerenciamento das atividades tendo como foco o trabalho em 
equipe onde a cooperação e o compartilhamento de responsabilidades se 
posiciona como direcionador; maior motivação da equipe envolvida por conta do 
reconhecimento interpessoal e da comunicação efetiva, favorecendo a 
 
 
 
 
 
 
 
 
 
80 
 
 
produtividade e garantindo maior assertividade em relação ao que se faz solicitado 
pelo cliente; aumento na integração da equipe propiciando melhoria na qualidade 
do produto final e identificação antecipada de dificuldades a serem transpostas, 
destacando a habilidade de resposta rápida a fatores/requisitos os quais solicitam 
processos de mudança imediatos (FERNANDES; ABREU, 2014). 
Contudo, Fernandes e Abreu (2014) destacam também que a adoção do 
Scrum deve seguir critérios bem definidos em face dos desafios que se fazem 
interpostos, como o fato de que a equipe necessita possuir habilidade de trabalho 
em grupo, de os membros necessitarem de senso de autogestão, de cada membro 
somente poder fazer parte de uma equipe Scrum por vez em face das exigências de 
compromisso com o processo, de a documentação necessitar se fazer de modo 
frequente pois a cada reunião tem-se novas determinações a serem distribuídas entre 
os envolvidos. 
Conforme Oliveira (2018) destaca, no Scrum apesar de sua leveza e facilidade 
de entendimento, solicita-se a ruptura de paradigmas e padrões culturais já existentes 
em organizações que resolvem implementá-lo em seus processos, o que 
naturalmente demonstra o caráter de dificuldade de domínio que pode se fazer 
latente. 
 
5.4 EQUIPES E PAPÉIS NA METODOLOGIA SCRUM 
Na metodologia ágil Scrum, a definição de equipes e papéis não descarta a 
importância de que a responsabilidade pelo projeto é coletiva, pois, como denotado 
na estratégia do jogo de rúgbi do qual se origina o nome, os jogadores se apoiam 
mutuamente frente ao adversário (SABBAGH, 2022; OLIVEIRA, 2018; AUDY, 2022) 
Contudo, algumas funções estratégicas seguem especificadas por meio do 
Quadro 13. 
 
Quadro 13: Funções e Papéis dos membros do time Scrum 
Product Owner 
(P.O.) ou Dono 
do Produto 
 Sua função está em garantir a manutenção do contato direto, 
representando o cliente frente a equipe de desenvolvimento, 
determinando requisitos/funcionalidades que necessitam ser 
implementadas em cada etapa de ação e responsabilizando-se, 
em face de sua função estratégica como analista de negócios, 
pelas entregas posteriores e pela efetiva realização do projeto. 
 Ele ainda valida juntamente com o cliente as execuções e realiza o 
feedback para a equipe de desenvolvimento, no entanto, não 
 
 
 
 
 
 
 
 
 
81 
 
 
pode se considerar como “dono” do projeto, uma vez que sua 
construção é coletiva. 
 No intuito de que o time siga apenas uma orientação, há somente 
um indivíduo nesta função, cabendo a ele se fazer sempre 
disponível e presente para troca de ideias e esclarecimento de 
dúvidas, além de ser essencial para sua maior agilidade que possua 
conhecimentos aprofundados sobre negócios e interação pessoal, 
podendo ser, deste modo, um indivíduo da equipe contratada ou 
do contratante, contudo, desde que haja conhecimento 
comprovado também em relação à metodologia Scrum. 
Scrum Master ou 
Mestre do Scrum 
 Sua função é de liderança à equipe, garantindo que o método seja 
devidamente entendido, aplicado e seguido, o que lhe exige 
profundo conhecimento e experiência em relação ao Scrum. 
 Necessita agir como agente facilitador, moderador e orientador, 
garantindo que a equipe assumasomente compromissos dentro do 
seu limite de execução, se fazendo presente sempre for necessário. 
 Em seu papel de liderança neutra deve ser dotado de requisitos 
referentes à relação interpessoal, garantindo que atue como 
motivador e garantidor do espírito de equipe, eliminando questões 
que possam impedir o desenvolvimento do grupo. 
Scrum Team, 
Equipe Scrum ou 
Equipe de 
Desenvolvimento 
 Grupo multidisciplinar responsável em desenvolver de modo 
incremental o projeto solicitado pelo cliente atendendo ao requisito 
de construção de valor. 
 Sua composição se faz geralmente com um total de 6 a 10 pessoas. 
 Apesar de não possuir a distinção de funções internas, conta com 
os profissionais que sejam essenciais ao desenvolvimento do 
produto, agindo de modo integrado e multidisciplinar. 
 O grupo, conjuntamente deve se fazer apto a entregar uma versão 
usável do produto para o cliente ao final de cada etapa de 
execução. 
Fonte: adaptado de Oliveira (2018); Sabbagh (2022), Audy (2022), Wazlawick (2013), 
Fernandes e Abreu (2014), Alff (2022) 
 
Destaca-se, como especificado anteriormente, que a atuação dos 
profissionais que fazem, uso da metodologia Scrum é coletiva. 
O Product Owner interage com o Scrum Master e com a Scrum Team de 
acordo com a necessidade imposta, podendo repassar a estes metas a serem 
alcançadas e requisitos a cumprir por meio de um Roadmap de Produto (SABBAGH, 
2022). 
 
 
 
Conforme Sabbagh (2022), Roadmap de Produto é uma espécie de plano elaborado 
antes do início do desenvolvimento do produto, no qual se especifica a cronologia do que 
necessita ser realizado assim como as metas a serem alcançadas (Metas de Roadmap). 
 
 
 
 
 
 
 
 
 
 
 
82 
 
 
5.5 MODO DE AÇÃO E ETAPAS DA METODOLOGIA SCRUM 
Para iniciar esta explanação deve-se compreender que o Scrum possui 
artefatos e atividades que necessitam precisam ser atendidos (FERNANDES; ABREU, 
2014). 
Com a intenção de melhor compreender tais elementos cabe conceituar 
brevemente o que venha a ser uma Sprint. 
Conforme Fernandes e Abreu (2014), a Sprint se refere ao processo de 
interação dado entre os membros de uma equipe Scrum para o desenvolvimento do 
produto e que tende a acontecer com certa frequência em atividades de troca de 
ideias, reuniões, planejamento, revisão e retrospectiva do produto. 
De posse deste primeiro entendimento, e no intuito de melhor se compreender 
as etapas seguidas na metodologia, cabe por conseguinte identificar os elementos 
denominados pela ferramenta de artefatos, e dispostos aqui por meio do Quadro 14. 
 
Quadro 14: Artefatos do Scrum 
Product Backlog 
ou Backlog de 
Produto 
 Consiste em um documento essencial composto por listagem 
evolutiva, detalhada e dinâmica, sem formatação prévia, onde se 
dispõe os requisitos funcionais e não funcionais dos elementos que 
devem fazer parte da construção do produto ao longo do 
desenvolvimento do projeto. 
 Nela especifica-se ainda por ordem de posicionamento a prioridade 
de implementação dos elementos apontados, podendo ser 
reordenada a qualquer momento, o que demonstra seu processo 
de evolução à medida que o projeto vai sendo executado. 
 Ele é mantido pelo Product Owner podendo receber constantes 
atualizações por conta de melhorias até que o produto seja 
finalizado em seu ciclo de versões. 
 Contudo, a execução do que se faz nele descrito ocorre através das 
ações do Scrum Team, mediadas pelo Scrum Master. 
Sprint Backlog 
ou Backlog da 
Sprint 
 Consiste nos itens a serem criados/incrementados/ajustados, 
selecionados dentre os identificados na listagem do Product Backlog 
e que serão efetivados pelo Scrum Team em sua Sprint. 
 Desenvolve-se por meio de listas de tarefas detalhadas seguindo as 
prioridades definidas pelo Product Owner em atividades que devem 
durar de 4 a 16 horas a serem efetivadas e entregues na próxima 
Sprint. 
Incremento do 
Produto 
 Consiste na entrega do que se planejou no Product Backlog e se 
efetivou por meio da Sprint de Backlog. 
Burndown Charts 
Ou Burndown da 
Sprint 
 Demonstração gráfica do trabalho efetivamente realizado ao longo 
de um determinado espaço de tempo, destacando o progresso 
alcançado por meio do esforço conjunto, dinâmico, colaborativo, 
coeso e realizado pelo Scrum Team 
 
 
 
 
 
 
 
 
 
83 
 
 
User Story ou 
História de 
Usuário 
 Consiste na descrição detalhada, valorada, simples e concisa das 
necessidades do usuário/negócio, figurando assim como um 
requisito da listagem do Product Backlog e que auxilia no processo 
de documentação de funcionalidades. 
 Não é parte do framework Scrum, tendo uso opcional. 
 Sendo mais frequente na metodologia XP, segue as características 
apontadas em 4.5.1. 
Fonte: adaptado de Oliveira (2018); Sabbagh (2022), Audy (2022), Fernandes e Abreu (2014) 
e Wazlawick (2013) 
 
A disposição feita no Quadro 14 demonstra que o Backlog de Produto, 
contando ou não com a colaboração do User Story, fornece o direcionamento das 
ações a serem efetivadas e que se fazem transcritas por meio do Sprint Backlog. Por 
conseguinte, o Sprint Backlog gera informações de Incremento que podem ser 
acompanhados através do Burndown Charts. 
O Scrum, sendo um framework, em sua execução, incorpora também uma 
série de eventos com duração definida, ao que se denomina de Timeboxes. Estes 
favorecem para que o tempo seja utilizado com limitação e de maneira consciente, 
acarretando o não desperdício, o ritmo, a regularidade, a objetividade e a 
aplicação de metodologias que favoreçam ações de planejamento cíclicas 
(SABBAGH, 2022, AUDY, 2022; OLIVEIRA, 2018). 
Assim, no intuito de se compreender como os artefatos anteriormente listados 
se fazem alinhados com os Timeboxes em suas ações específicas e definidas pelo 
Scrum, o Quadro 15 apresenta o Eventos do Scrum. 
 
Quadro 15: Eventos do Scrum 
Sprint ou 
Iteração 
 Principal evento da metodologia ágil Scrum. 
 Refere-se ao ciclo periódico e regular de projeto, com duração 
média e acordada previamente de 2 a 4 semanas, no qual o 
produto incremental se faz desenvolvido, efetivando entrega de 
valor ao cliente. 
 Neste período o Scrum Team desenvolve, revisa, planeja e efetiva 
retrospecto das funcionalidades elencadas pela Sprint Backlog. 
 Em caso de identificação de ajustes em funcionalidades já 
existentes, sua implementação fica prospectada para a Sprint 
posterior, garantindo que a melhoria contínua posicione-se como 
um dos valores atendidos pela metodologia. 
Sprint Planning, 
Reunião de 
Sprint Planning 
ou Reunião de 
Planejamento da 
Sprint 
 Refere-se à primeira reunião de uma Sprint, voltada ao 
planejamento do que será realizado no ciclo, especificando 
inclusive o como. 
 Para tal o Product Owner apresenta os User Stories, pactuando as 
entregas, os requisitos e prazos com o Scrum Team. 
Daily Scrum, 
Daily Scrum 
 Refere-se à reunião diária, no mesmo local e horário previamente 
acordado, efetivada em pé com duração máxima de 15 minutos, e 
 
 
 
 
 
 
 
 
 
84 
 
 
Meeting, Scrum 
Diário ou 
Reunião Diária 
que conta com a presença total dos indivíduos e stakeholders que 
compõe o grupo Scrum. 
 Tem a função de gerar visibilidade e planejamento para o dia de 
trabalho que se inicia, além de permitir a avaliação de possíveis 
riscos e de tomadas de decisão não previstas e imediatas. 
 Nele, cada membro da equipe relata suas condições e reconhece 
as dos demais, identificando restrições/impedimentos que possam 
impactar na atividade a ser desenvolvida, afetando a 
sincronicidade de realização do projeto como um todo. 
Sprint Review, 
Revisão da 
Sprint, Revisão 
da Iteração ou 
Reunião de 
Revisão da Sprint 
 Ocorre ao final de uma Sprint, ou seja, no último dia do ciclo, 
permitindo que o trabalho seja entregue para as partes interessadas. 
 Por meio do feedback identifica-seo que deve ser realizado em uma 
próxima Sprint a ser inicida, ficando este retorno sob a atenção do 
Scrum Master e do Product Owner. 
 Faz-se essencial neste processo a presença do Product Owner, 
Scrum Master, Scrum Team e demais Stakeholders, de modo que se 
avalie o desempenho e se discuta possíveis problemas/dificuldades. 
 Após este evento o Scrum Master, de posse dos feedbacks, 
apresenta o conteúdo em particular ao Scrum Team. 
Sprint 
Retrospective, 
Retrospectiva da 
Sprint ou Reunião 
de Retrospectiva 
da Sprint 
 Nesta reunião o Scrum Master, juntamente com o Scrum Team, 
analisa os feedbacks recebidos, identificando pontos positivos, 
negativos, necessidades de melhoria e ações de adaptação a 
serem efetivadas. 
Fonte: adaptado de Oliveira (2018); Sabbagh (2022), Audy (2022), Fernandes e Abreu (2014) 
e Wazlawick (2013) 
 
Neste contexto, a partir dos elementos que embasam a metodologia Scrum, 
como papéis, artefatos e eventos, torna-se possível compreender o fluxo de 
execução do Scrum dado pela efetivação de suas Sprints (planejamento, diária, 
revisão e/ou retrospectiva), nas quais os artefatos são os objetos direcionadores do 
processo a ser executado pelos entes envolvidos. 
Contudo, Sommerville (2011) destaca que antes do início das Sprints efetiva-se 
a fase de planejamento geral voltada a identificação dos objetivos e elementos 
condizentes à arquitetura de software. 
Do mesmo modo, segue afirmando que ao final de todos os ciclos de 
desenvolvimento, em sua última fase, elabora-se a documentação e os manuais de 
usuário, seguida da identificação das lições que se fizeram aprendidas 
(SOMMERVILLE, 2011). 
 
 
 
 
 
 
 
 
 
 
85 
 
 
 
 
 
Analisando as duas metodologias estudadas (XP e Scrum), elas possuem mais pontos em 
comum do que divergências. No entanto, você concorda com a popularidade 
alcançada pelo Scrum? A que se deve isso? 
 
 
 
 
 
 
 
 
 
86 
 
 
FIXANDO O CONTEÚDO 
 
1. (FEPESE - 2019 – CELESC - adaptado) O Scrum é uma metodologia ágil para a 
gestão e planejamento de projetos de software. 
Analise as afirmativas abaixo com relação a este assunto. 
I. As funcionalidades a serem implementadas em um projeto são mantidas em uma 
lista que é conhecida como Product Backlog. 
II. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião 
de planejamento na qual o Product Owner prioriza os itens do Product Backlog e 
a equipe seleciona as atividades que ela será capaz de implementar durante o 
Sprint que se inicia. 
III. Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em 
uma Sprint Analysis Overview. 
Assinale a alternativa que indica todas as afirmativas corretas: 
a) É correta apenas a afirmativa I 
b) São corretas apenas as afirmativas I e II 
c) São corretas apenas as afirmativas I e III 
d) São corretas apenas as afirmativas II e III 
e) São corretas as afirmativas I, II e III 
 
2. (Instituto Consulplan - MPE MG – 2023 - adaptado) Considere o desenvolvimento 
de um projeto de um sistema para o Ministério Público junto à equipe de TI. 
Considere, ainda, utilizar a metodologia Scrum. A equipe Scrum precisa se 
organizar para executar as entregas desse sistema. NÃO faz parte da metodologia 
Scrum: 
a) A equipe (ou “time”) Scrum é interdisciplinar e se auto organiza, sendo composta 
por um product owner; um Scrum máster; e, uma pequena equipe de 
desenvolvimento (três a seis pessoas). 
b) Sua reunião diária é um evento programado de quinze minutos no início de cada 
dia de trabalho, para permitir que os membros da equipe sincronizem as suas 
atividades e se planejem para as próximas vinte e quatro horas. 
 
 
 
 
 
 
 
 
 
87 
 
 
c) A revisão do sprint ocorre no final do sprint, quando a equipe de desenvolvimento 
decidiu que o incremento está completo. Em geral, a revisão do sprint é limitada 
a uma reunião de quatro horas para um sprint de quatro semanas. 
d) Toda equipe (ou “time”) Scrum participa da reunião diária. São realizadas três 
perguntas-chave, que são respondidas por todos os membros da equipe: “o que 
você realizou desde a última reunião de equipe?”; “Quais obstáculos está 
encontrando?”; e, “O que planeja realizar até a próxima reunião da equipe?” 
e) Ao final de um Sprint, a equipe realiza um Sprint Planning Meeting, ou seja, uma 
reunião de planejamento na qual o Product Owner prioriza os itens da Sprint 
Backlog e a equipe seleciona as atividades que ela será capaz de implementar 
durante o Sprint que se inicia. 
 
3. (FGV - SEFAZ MG - 2023) Em uma equipe ágil, um dos papéis mais importantes é o 
do responsável por planejar o desenvolvimento do produto, escolhendo e 
priorizando os itens do backlog e garantindo que o máximo de valor seja entregue 
a cada sprint. Assinale a opção que indica o nome correto desse membro do time. 
a) Scrum Master 
b) Stakeholder 
c) Gerente de Projetos 
d) Product Owner 
e) Desenvolvedor 
 
4. (FGV - CGE-SC - 2023) No Scrum, o principal objetivo da reunião de Retrospectiva 
da Sprint é: 
a) revisar e atualizar o backlog do produto. 
b) avaliar o progresso feito durante a sprint. 
c) planejar a próxima sprint. 
d) identificar e planejar melhorias para a próxima sprint. 
e) revisar e atualizar o backlog da sprint. 
 
 
 
 
 
 
 
 
 
88 
 
 
5. (CESPE/CEBRASPE - APEX Brasil – 2022 - adaptado)No Scrum, a cerimônia que 
define o início do ciclo de uma sprint e que auxilia na definição da sprint backlog 
é chamada de: 
a) sprint backlog 
b) sprint retrospective 
c) sprint planning 
d) daily scrum 
e) sprint burndown 
 
6. (FUNDATEC - SUSEPE - 2022) Os rincípios do Scrum são consistentes com o manifesto 
ágil e são usados para orientar as atividades de desenvolvimento dentro de um 
processo dividido em iterações geralmente de 30 dias chamadas de _____________. 
O ______________ compõe uma lista com prioridades dos requisitos ou 
funcionalidades do projeto desejadas pelo cliente. Reuniões diárias, tipicamente 
de 15 minutos, são realizados pela equipe e conduzidas pelo _______________. 
Assinale a alternativa que preenche, correta e respectivamente, as lacunas do 
trecho acima. 
a) sprints – product backlog – Scrum master 
b) sprints – sprint backlog – Scrum master 
c) sprints – product backlog – gerente de produto 
d) refatoração – product backlog – Scrum máster 
e) refatoração – sprint backlog – gerente de produto 
 
7. (VUNESP - ALE SP - 2022) O método de desenvolvimento de software denominado 
Scrum possui diversas características peculiares ao método, em particular sua 
equipe de desenvolvimento, da qual faz parte o elemento denominado Product 
Owner, sobre o qual é correto afirmar: 
a) é o único responsável por gerenciar o backlog do software em desenvolvimento. 
b) exerce a mesma função do Scrum Master. 
c) não há essa figura do Product Owner em projetos de pequeno porte. 
d) não tem qualquer interação com o Scrum Master. 
 
 
 
 
 
 
 
 
 
89 
 
 
e) normalmente, essa figura é composta por uma equipe de três ou mais pessoas. 
 
8. (CESPE/CEBRASPE - SEFAZ SE - 2022) De acordo com a metodologia Scrum, a 
reunião em que são apresentados os pontos positivos e negativos da sprint é a: 
a) sprint planning 
b) retrospective 
c) daily 
d) backlog refinement 
e) sprint review 
 
 
 
 
 
 
 
 
 
90 
 
 
ESTIMATIVA DE SOFTWARE 
 
 
 
6.1 CONCEITO E IMPORTÂNCIA DA ESTIMATIVA DE SOFTWARE 
O termo estimativa, conforme o Dicio (2023), refere-se ao cálculo efetivado no 
intuito de se avaliar algo/alguém, tendo por base evidências que permitam melhor 
conhecer e quantificar estatísticas acerca do ser/objetivo avaliado. 
Aliado a este entendimento, Wazlawick (2013) destaca que, dificilmente uma 
atividade profissional, seja ela qualquer, não possua suas próprias maneiras de 
estimar o esforço aplicado para obtenção de um dado resultado, favorecendoassim, para que no âmbito gerencial se alcance um maior controle das ações 
desempenhadas assim como da qualidade alcançada em relação ao elemento 
produzido. 
Neste intento de estimar, tem-se o entendimento de medição, que segundo 
Vazquez et al. (2018) e Wazlawick (2013), refere-se ao processo direto de atribuir 
números no intuito de quantificação das características atribuídas a um determinado 
elemento, necessitando-se assim, identificar que atributos são estes de tamanha 
relevância a ponto de despertar o interesse para sua mensuração. 
Por conseguinte, a métrica se refere à quantificação indireta, e nela tem-se o 
cálculo aplicado sobre a medição, destacando qual o critério que se fará avaliado, 
ou seja, a característica que será medida e que já fora anteriormente identificada 
como de destaque/relevância (WAZLAWICK, 2013). 
Assim, o resultado alcançado a partir da aplicação de uma medição tem o 
intuito de permitir que as pessoas envolvidas no desenvolvimento de um dado projeto 
compreendam como os elementos envolvidos podem afetar cliente e usuário, 
viabilizando o conhecimento e a correção dos problemas rapidamente e sem que 
consigam acarretar maiores impactos (VAZQUEZ ET AL., 2018). 
Diante destes entendimentos, Sommerville (2011) destaca que, em se tratando 
da medição de software, tem-se a possibilidade de, por meio dela e dos elementos 
característicos do processo de mensuração, identificar questões referentes à 
UNIDADE 
06 
 
 
 
 
 
 
 
 
 
91 
 
 
qualidade do software desenvolvido, documentação e/ou qualidade dos processos 
que permeiam as tarefas desempenhadas. 
O objetivo da Medição de Software, conforme Sommerville (2011) e Pressman 
e Maxim (2016) está em identificar os parâmetros de relevância permitindo que 
periodicamente estes possam ser revistos no intuito de se identificar o nível de 
qualidade do software ou ainda elementos que necessitam de maior atenção em se 
tratando da efetivação de melhorias. 
 
 
 
6.2 MÉTRICAS DE SOFTWARE 
Em se tratando especificamente de Métricas de Software, vale destacar que 
o termo se refere ao processo de medir algo em relação a um dado atributo que seja 
de relevância para o software (PRESSMAN; MAXIM, 2016). 
Neste contexto a categorização de medidas para a construção de software 
pode se fazer atribuída em nível de medidas de produto, projeto e recurso, como 
segue melhor identificado no Quadro 16. 
 
Quadro 16: Medidas de Software 
Medidas de 
Produto 
Refere-se a caraterísticas como tamanho, estrutura e qualidade. 
Medidas de 
Projeto 
Refere-se ao desempenho de um software podendo ser calculado por 
porcentagem 
Medidas de 
Recursos 
Refere-se aos recursos e materiais aplicados no desenvolvimento do projeto 
de software 
Medidas de 
Processo 
Refere-se à coleta de informações que permite identificar os pontos fortes, 
fracos, deficiências, e avaliação após implementação/mudança em 
software 
Fonte: adaptado de Wazlawick (2013) 
 
Em referência à Qualidade de Software, tem-se o entendimento de que se refira a um 
grupo de características que um software necessita atender, principalmente em se 
tratando do atendimento das necessidades do cliente/usuário. Assim, um software de 
qualidade não apenas incorpora em si questões de custo/benefício, mas também de 
produtividade, de competitividade, de atendimento a requisitos de norma, de 
possibilidade de adequação/readequação a outros processos, de melhoria contínua, e 
demais questões que demonstram atendimento à expectativas de quem dele faz uso 
(PRESSMAN; MAXIM, 2016; WAZLAWICK, 2013; SOMMERVILLE, 2011). 
 
 
 
 
 
 
 
 
 
 
92 
 
 
É justamente a partir destas medidas que são especificadas as métricas a 
serem atribuídas para a medição de software, de modo a garantir que dúvidas a 
respeito do projeto de software possam efetivamente ser respondidas. 
Por conseguinte, as métricas de software podem ser categorizadas conforme 
se verifica no Quadro 17. 
 
Quadro 17: Métricas de Software 
Métricas de 
Controle ou 
Métricas de 
Projeto 
Embasa o gerenciamento de processos de software, especificando meios de 
avaliação do seu andamento, riscos, problemáticas, fluxo de tarefas e 
habilidades da equipe, sendo coletadas durante toda a efetivação do 
projeto a fim de permitir o estabelecimento de indicadores de melhoria a 
longo prazo. 
Métricas de 
Previsão ou 
Métricas de 
Produto 
Embasam a previsão e medição dos atributos internos de um software, 
ajudando a estimar o esforço dispendido para o desenvolvimento e 
alterações do sistema em face de seu grau de complexidade, seu tamanho, 
riscos e tecnologia aplicada. 
Fonte: adaptado de Sommerville (2011) e Pressman e Maxim (2016 
 
Demonstra-se assim que as métricas ultrapassam a visão da simples efetivação 
de controle, permitindo que variáveis importantes sejam consideradas no projeto de 
desenvolvimento do software (PRESSMAN; MAXIM, 2016). 
Reconhece-se, portanto, o papel das métricas em permitir que o 
desenvolvimento de software seja constantemente aperfeiçoado, uma vez que as 
informações alcançados embasam a tomada de decisão da gestão e da equipe 
desenvolvedora, favorecendo o processo de planejamento (PRESSMAN, 2011; 
WAZLAWICK, 2013). 
A estimativa de software não se efetiva de modo aleatório, podendo fazer uso 
de técnicas já estabelecidas que passaram por todo um processo de análise e testes 
até se tornarem referência, garantindo que o planejamento forneça efetivamente a 
direção que deve se fazer ser seguida pelos envolvidos (PRESSMAN; MAXIM, 2016). 
Neste âmbito, segue a apresentação de ferramentas passíveis de utilização 
visando as efetivação de estimativas de software: a Análise de Pontos de Função e 
o Planning Poker. 
 
6.3 ANÁLISE POR PONTO DE FUNÇÃO 
A Análise por Ponto de Função (APF) ou Function Point Analysis (FPA) configura-
se como técnica voltada à medição das funcionalidades, dimensionamento e 
 
 
 
 
 
 
 
 
 
93 
 
 
complexidade de um software por meio de processos aplicados ao tamanho do 
projeto, contundo, tendo por parâmetro o ponto de visão do usuário (PRESSMAN; 
MAXIM, 2016; VAZQUEZ et al., 2018). 
Como os métodos de medição identificam e quantificam as qualidades 
existentes em um produto, em se tratando de Pontos de Função, tem-se um processo 
que mede os requisitos funcionais atribuíveis ao usuário em um software (histórias de 
usuário), ou seja, os requisitos de negócio, sem estabelecer atenção ao aspecto 
tecnológico, de plataforma e/ou linguagem, focando exclusivamente na ação 
direta da ferramenta desenvolvida (VAZQUEZ et al., 2018). 
 
 
 
Deste modo, aos Pontos de Função, sendo os requisitos que passarão por 
medição, efetiva-se a atribuição de valores numéricos, os quais processados 
posteriormente, permitem identificar o esforço dispendido durante o 
desenvolvimento do software, pois em se tratando deste aspecto, amplia-se o 
entendimento considerando esforço, prazo, custo e demais parâmetros, o que pode 
em projetos de software respaldar as conclusões acerca do seu tamanho e 
complexidade (WAZLAWICK, 2013; VAZQUEZ et al., 2018). 
 
 
 
Nesta base, destaca-se os seguintes elementos dispostos na Figura 22 como 
objetivos atribuíveis à Análise por Pontos de Função. 
Como já especificado, considera-se como requisitos funcionais aqueles que expressam as 
ações do software ao ser aplicado na atividade do usuário, de modo que, caracterizam 
elementos aplicados ao processo de negócios da organização, podendo se fazer 
relacionados à transferência e armazenagem de dados (WAZLAWICK, 2013). 
 
Considera-se por vezes que a complexidade de software se faz diretamente relacionada 
ao tamanho, à quantidade de código desenvolvido, que pode levar a excessos de 
funções e até repetições desnecessárias. A isto, a Metodologia XP combate por meio da 
prática constante de Refatoração, como meio de diminuição da complexidadeatravés 
da simplificação do código, retirando excessos cometidos pelo desenvolvedor 
(PRESSMAN, 2011; SOMMERVILLE, 2011). 
 
 
 
 
 
 
 
 
 
 
94 
 
 
 
Figura 22: Objetivos da Análise por Ponto de Função 
 
Fonte: adaptado de Vazquez et al. (2018) 
 
Efetivando-se a Análise por Pontos de Função em atributos do sistema, aos 
quais compreende-se que sejam os requisitos, o resultado alcançado pelo processo 
também pode se voltar a intenções que não estejam elencadas na Figura 22, 
cabendo ainda para outros intentos como os apontados por meio da Figura 23. 
 
Figura 23: Outros Objetivos atribuíveis à Análise por Ponto de Função 
 
Fonte: adaptado de Wazlawick (2013) 
 
Para tal, o processo que envolve a Análise por Pontos de Função necessita 
seguir os parâmetros dispostos pela Figura 24. 
 
Figura 24: Parâmetros ideais para a Análise por Pontos de Função 
 
Fonte: adaptado de Vazquez et al. (2018) 
medir a funcionalidade 
solicitada pelo usuário
medir a funcionalidade 
efetivamente recebida 
pelo usuário
medir o desempenho 
do software 
independente da 
tecnologia de 
desenvolvimento
medir a manutenção 
do software 
independente da 
tecnologia de 
desenvolvimento
Melhoria em produto
• após a efetivação de uma manutenção contabiliza-se as funcionalidades adicionadas, alteradas e 
excluídas
Contagem em aplicação
• aplicada na contabilização de pontos de aplicações existentes
Simplicidade
•pela necessidade do envolvido humano e manual no processo de análise de métricas, a 
simplicidade é essencial, de modo que o esforço seja minimizado, não onerando o projeto
Consistência
•pela possibilidade de haver mais de uma pessoa envolvida na análise, há de se identificar 
sistemáticas que garantam resultados semelhantes entre os avaliadores, denotando a 
qualidade da medição por meio de uma melhor e igualitária compreensão dos requisitos
Capacitação
•o medidor necessita possuir conhecimentos suficientes que o dotem para a ação que 
pretende efetivar sob o risco de que o processo se faça permeado de erros em face da 
ausência de uma formação consistente para tal
 
 
 
 
 
 
 
 
 
95 
 
 
A Contagem de Pontos de Função, visando sua posterior análise, efetiva-se de 
modo simplificado por meio da sistemática disposta na Figura 25. 
 
Figura 25: Sistemática simplificada de contagem de Pontos de Função 
 
Fonte: adaptado de Wazlawick (2013) e Pressman e Maxim (2016) 
 
Neste contexto, em se tratando dos elementos destacados na sistemática 
simplificada presente por meio da Figura 26, tem-se de modo mais abrangente um 
detalhamento de ações apresentado através do Quadro 18. 
 
Quadro 18: Ampliação da efetivação de Sistemática de Contagem de Pontos de Função 
AÇÕES PROCESSOS ESPECIFICAÇÃO 
Determinar 
Tipo de 
Contagem 
 Projeto  Melhoria  Aplicação 
Método  Estimado  Detalhado 
Identificar 
Escopo e 
Fronteira da 
Aplicação 
 Limite entre sistema e usuário 
 Limite entre sistema e outras aplicações 
 Visão do Usuário 
 Função de Negócio 
 Independência de Tecnologia 
 Manutenção 
Contar 
Funções de 
Dados 
 Arquivos Lógicos Internos (ALI) 
 Arquivos de Interface Externa (AIE) 
Funções de 
Transação 
 Entrada 
Externa (EE) 
 Consulta 
Externa (CE) 
 Saída 
Externa (SE) 
Ajustar Fator de Ajuste 
 Atualização Online 
 Complexidade de Processamento 
 Comunicação de Dados 
 Configuração Altamente Utilizada 
AjustarContarIdentificarDeterminar
Tipo de 
Contagem e 
Método
Escopo e 
Fronteira da 
aplicação
Funções de 
Dados
Funções de 
Transações
Pontos à ajustar 
e ajustados
Fator de Ajuste
 
 
 
 
 
 
 
 
 
96 
 
 
Pontos a ajustar 
 Eficiência de Usuário Final 
 Entrada de Dados Online 
 Facilidade de Instalação 
 Facilidade de Mudanças 
 Facilidade de Operação 
 Múltiplas Localidades 
 Performance 
 Processamento Distribuído 
 Reutilização 
 Taxa de Transações 
Pontos ajustados 
Fonte: adaptado de Wazlawick (2013) e Pressman e Maxim (2016) 
 
Considerando a figura 25 e o Quadro 18, e compreendendo que a dimensão 
dos requisitos funcionais do usuário recebe a denominação de tamanho funcional e 
que uma aplicação seja um conjunto composto de dados e procedimentos que 
sofreram automatização fornecendo suporte ao processo de negócio de acordo 
com a ação do usuário (VAZQUEZ et al., 2018) os Tipos de Contagem passíveis de 
efetivação na Análise por Pontos de Função, seguem explicitados por meio da Figura 
26. 
 
Figura 26: Tipos de Contagem em Análise por Pontos de Função 
 
Fonte: adaptado de Vazquez et al. (2018) 
 
Em se tratando do aspecto referente à Fronteira da Aplicação, tem-se a 
identificação dos limites entre o software e o mundo em que ele se faz inserido, 
seguindo os critérios de ponto de vista do usuário, a separação de funções atribuídas 
aos negócios, e, em caso de projetos de melhoria, os aspectos já definidos devem 
ser reanalisados com intuito de verificar se existe a necessidade de adaptação 
Contagem de um projeto de desenvolvimento
•permite, por meio da identificação do tamanho funcional do sistema, medir se as
funcionalidades ofertadas ao usuário no projeto inicial permitem-se ser migradas em caso
de ajustes futuros na ferramenta, pois é comum que, à medida que um sistema vai sendo
utilizado os requisitos se tornam mais fáceis de compreensão permitindo que
funcionalidades adicionais sejam identificadas durante o projeto, impactando no seu
tamanho original.
Contagem de um projeto de melhoria
•permite medir as funções adicionadas, modificadas, excluídas e/ou convertidas do sistema
pelo projeto.
Contagem de uma aplicação
•permite medir a funcionalidade fornecida aos usuários por meio de uma aplicação
instalada, de modo a se identificar uma medida atualizada da funcionalidade que o usuário
está fazendo utilização, tendo por parâmetro os dados coletados ao final do projeto em
comparação com cada processo de melhoria.
 
 
 
 
 
 
 
 
 
97 
 
 
(VAZQUEZ et al., 2018). 
Neste sentido, tem-se como aspectos facilitadores para a identificação das 
fronteiras de uma aplicação estes que se fazem citados na Figura 27. 
 
Figura 27: Aspectos que facilitam a identificação das Fronteiras de uma Aplicação 
 
Fonte: adaptado de Vazquez et al. (2018) 
 
Referindo-se ao Escopo, tem-se a identificação de quais as funcionalidades a 
serem contadas por meio da sistemática escolhida, podendo incorporar todas as 
existentes, apenas aquelas que são utilizadas pelo usuário, ou ainda algumas em 
específico (VAZQUEZ et al., 2018). 
Tem-se, deste modo, a identificação de quantos sistemas serão quantificados, 
definindo claramente onde começam e terminam (WAZLAWICK, 2013). 
Por conseguinte, define-se o Tipo de Método, podendo, conforme Pressman e 
Maxim (2016) ser: 
a) Estimado: Calcula os Pontos de Função de acordo com regras 
internacionalmente definidas no intuito de estimar as Funções de Dados 
(preferencialmente de complexidade baixa) e as Funções de Transação 
(preferencialmente de complexidade média); 
b) Detalhado: Efetiva a quantificação dos Pontos de Função com regras 
internacionalmente definidas no intuito de estimar as Funções de Dados e de 
Transação de acordo com as especificidades do caso. 
Em relação à contagem/medição das Funções de Dados e de Transação, 
identificar a natureza dos dados configura-se como o primeiro passo do processo, 
pois é justamente a partir dele que se reconhece as reais necessidades do usuário 
em relação ao negócio, assim como as funcionalidades previstas pelos usuários 
(VAZQUEZ et al., 2018; PRESSMAN; MAXIM, 2016; WAZLAWICK, 2013), sendo tais ações 
melhor especificadas por meio do Quadro 19. 
Identificar pela 
documentação de 
fluxo do sistema os 
elementos 
internos/externos
Verificar como se 
efetiva a manutenção 
dos dados
Identificar as áreas 
funcionais por meio 
das entidades e 
processos do sistema
Verificar se, por meio 
de outras métricas,os 
resultados alcançados 
em medição são os 
mesmos
Reconhecer como 
ocorre o processo de 
gestão da aplicação
Identificar a existência 
no sistema de ordens 
de serviço 
Comparar o 
organograma da 
empresa com a 
estrutura de área e de 
sistemas
 
 
 
 
 
 
 
 
 
98 
 
 
Quadro 19: Especificações acerca de Funções de Dados e Funções de Transação 
DADOS FUNÇÕES ARQUIVOS 
Estáticos 
dados 
estruturados na 
forma de 
arquivos 
internos/externos 
Funções 
de Dados 
Arquivo 
Lógico 
Interno (ALI) 
Grupo lógico de dados ou informações 
reconhecidos pelo usuário e que servem 
para efetivações de controle 
Arquivo de 
Interface 
Externa (AIE) 
Grupo lógico de dados ou informações 
reconhecidos pelo usuário e que se fazem 
mantidos fora da aplicação 
Dinâmicos 
dados de 
transação na 
forma de 
entradas, saídas 
e consultas 
Funções 
de 
Transação 
Entradas 
Externas (EE) 
Dados informados pelo usuário que 
alimentam o sistema alterando seu estado 
interno 
Saídas 
Externas (SE) 
Dados que saem sob requisição ou não de 
cliente/sistema, apresentando 
quantificações em relação a algum 
parâmetro previamente definido 
Consultas 
Externas (CE) 
Dados que saem sob requisição ou não de 
cliente/sistema, do mesmo modo em que 
se fazem armazenados 
Fonte: adaptado de Wazlawick (2013) e Pressman e Maxim (2016) 
 
Por conseguinte, após a identificação das funções a serem contadas, é 
requerida a identificação de seu fator de Complexidade, devendo este seguir os 
parâmetros dispostos por meio do Quadro 20. 
 
Quadro 20: Tipos de Função conforme fatores de Complexidade 
TIPO DE 
FUNÇÃO 
COMPLEXIDADE 
PESOS 
Baixa Média Alta 
Entradas 
Externas (EE) 
3 4 6 
A
rq
u
iv
o
s 
R
e
fe
re
n
c
i
a
d
o
s 
Tipos de Dados 
 <5 5-15 >15 
<2 Baixa Baixa Média 
2 Baixa Média Alta 
>2 Média Alta Alta 
 
Saídas 
Externas (SE) 
4 5 7 
 
A
rq
u
iv
o
s 
R
e
fe
re
n
c
ia
d
o
s 
Tipos de Dados 
 <6 6-19 >19 
<
2 
Baixa Baixa Médi
a 
2-
3 
Baixa Médi
a 
Alta 
>
3 
Médi
a 
Alta Alta 
Consultas 
Externas 
(CE) 
3 4 6 
Arquivo 
Lógico 
Interno (ALI) 
7 10 15 
A
rq
u
iv
o
s 
R
e
fe
re
n
c
ia
d
o
s 
Tipos de Dados 
 <20 20-50 >50 
<1 Baixa Baixa Média 
2-
5 
Baixa Média Alta 
>5 Média Alta Alta 
 
Arquivo de 
Interface 
Externa (AIE) 
5 7 10 
Fonte: adaptado de Wazlawick (2013) e Pressman e Maxim (2016) 
 
Conforme os parâmetros apresentados no Quadro 20 referentes aos fatores de 
 
 
 
 
 
 
 
 
 
99 
 
 
complexidade concernentes às funções de dado e transação, os pontos alcançados 
devem ser somados a fim de que se identifique o Tamanho Funcional da aplicação 
(WAZLAWICK, 2013). 
Isto se efetiva identificando-se os tipos de registro da Função de Dados e a 
quantidade de campos da Função de Transação, de modo que com a atribuição 
dos pesos de complexidade apresentados tem-se a quantificação dos Pontos de 
Função a Ajustar (PRESSMAN; MAXIM, 2016). 
Para sua efetivação é necessária a identificação do Fator de Ajuste, e em 
relação a ele aplica-se o fator de influência de 0 a 5 a cada um dos 14 níveis que são 
avaliados, conforme já se fez apresentado no Quadro 18, contudo recebendo outro 
e mais específico destaque aqui, por meio do Quadro 21. 
 
Quadro 21: Níveis, Características e Fatores de Influência 
NÍVEL CARACTERÍSTICA FATOR DE 
INFLUÊNCIA 
01 Comunicação de Dados Grau de comunicação 
requerida 
0 (sem 
influência) 
a 
5 (grande 
influência) 
02 Processamento Distribuído Grau de processamento 
distribuído 
03 Performance Criticidade da Performance 
04 Configuração Altamente 
Utilizada 
Equipamento existente 
Nível de Uso 
05 Taxa de Transações Volume de transações 
06 Entrada de Dados Online Existência de entradas online 
07 Eficiência de Usuário Final Aumento na eficiência do 
usuário 
08 Atualização Online Atualização de arquivos online 
09 Complexidade de 
Processamento 
Grau de complexidade do 
processamento interno 
10 Reutilização Código reutilizável 
11 Facilidade de Instalação Sistema fácil de instalar 
12 Facilidade de Operação Sistema fácil de operar 
13 Múltiplas Localidades Instalações e organizações 
múltiplas 
14 Facilidade de Mudanças Aplicação fácil de ser 
modificada 
Fonte: adaptado de Wazlawick (2013) e Pressman e Maxim (2016) 
 
O Fator de Ajuste uma vez definido favorece para a efetivação de 
quantificação dos Pontos de Função a Ajustar e dos Pontos de Função Ajustados 
(PRESSMAN; MAXIM, 2016). 
Assim, de posse das informações de um software, como os que se encontram 
dispostos em Diagramas de Caso de Uso, Diagramas de Entidade-Relacionamento, 
 
 
 
 
 
 
 
 
 
100 
 
 
Diagramas de Classe e/ou História do Usuário, tem-se a possibilidade de identificar as 
funcionalidades de uma aplicação no intuito de alimentar uma planilha voltada à 
quantificação para efetivação de Análise Pontos de Função (VAZQUEZ et al., 2018), 
conforme exemplificação que segue na Figura 28. 
 
Figura 28: Modelo de Planilha para Contagem de Pontos de Função 
NOME DA 
FUNÇÃO 
TIPO DA 
FUNÇÃO 
QUANTIDADE DE 
TIPO DE DADO 
QUANTIDADE DE ARQUIVOS 
REFERENCIADOS/ QUANTIDADE DE 
TIPOS DE REGISTRO 
COMPLEXIDADE PONTOS DE 
FUNÇÃO 
ORIGEM DA 
INFORMAÇÃO 
 
 
TOTAL DE PONTOS DE FUNÇÃO 
Fonte: adaptado de Wazlawick (2013) e Vazquez et al. (2018) 
 
Seguindo o modelo definido na Figura 28, o Nome da Função depende das 
especificações apresentadas no material de origem da informação; o Tipo de 
Função, segue como Funções de Dados e Funções de Transação, com o 
detalhamento de seus arquivos conforme se verificou no Quadro 19; a Quantidade 
de Tipo de Dado, a Quantidade de Arquivos Referenciados e a Quantidade do Tipo 
de Registro são consequências da identificação do Tipo de Função, especificando 
as respectivas quantificações; a Complexidade relaciona os elementos 
anteriormente identificados, passando pela conversão apresentada por meio do 
Quadro 20; os Pontos de Função também seguem o disposto no Quadro 20, 
identificando-se a relação entre o Tipo de Função, Quantidade de Tipo de Dado, a 
Quantidade de Arquivos Referenciados onde o peso encontrado identifica o valor a 
ser atribuído; e a Origem da Informação especifica de onde as informações listadas 
foram alcançadas. Ao final, o somatório de Pontos de Função permitirá estimar o 
esforço gasto no desenvolvimento do software favorecendo possíveis correções em 
processos (VAZQUEZ et al., 2018). 
Assim, tem-se como exemplo este: 
Funcionalidade de Registro de Ponto 
Ator: Funcionário 
História do Usuário Funcionário 
O Funcionário insere os dados de presença (entrada/saída) em um sistema de 
ponto. 
Quando chega ao local trabalho o Funcionário deve registrar sua presença no 
sistema, fazendo o mesmo na saída. 
Fluxo de Ações do Ator Funcionário 
 
 
 
 
 
 
 
 
 
101 
 
 
Funcionário realiza login no sistema 
Funcionário registra entrada/saída 
Considerando a data e o horário atuais o sistema armazena a informação 
Funcionário realiza logoff no sistema 
Fluxo de Ações de Processamento e Armazenagem do Sistema 
Sistema identifica matrícula e senha do Funcionário no momento do login 
Efetiva leitura interna para identificar data e hora atualizada, armazenando 
informação 
Recebe pedido de registro de entrada/saída 
Armazena registro 
Sistema processa logoff do Funcionário 
As 12h, 18h e 00h o sistema atualiza as tabelas de armazenagem identificando 
registros de entrada e de saída e alimentando relatórios de acesso para 
funcionários e gerentes 
 
Figura 29: Exemplificação de uso da Figura 28 
NOME DA 
FUNÇÃO 
TIPO DA 
FUNÇÃO 
QUANTIDADE 
DE TIPO DE 
DADO 
QUANTIDADE DE ARQUIVOS 
REFERENCIADOS / QUANTIDADE 
DE TIPOS DE REGISTRO 
COMPLEXIDADE PONTOS DE 
FUNÇÃO 
ORIGEM DA INFORMAÇÃO 
Funcionário ALI 4 1 Baixa 7 História do Usuário e Fluxo de 
Ações 
Login SE 4 1 Baixa 4 Históriado Usuário e Fluxo de 
Ações 
Registro de 
Ponto 
SE 3 1 Baixa 3 História do Usuário e Fluxo de 
Ações 
TOTAL DE PONTOS DE FUNÇÃO 14 
Fonte: O autor 
 
Contudo, se efetivando o Fator de Influência da Complexidade de alguma 
destas funções caso tivessem figurado como altas, seria necessário fazer uso das 
informações do Quadro 21 a fim de identificar prioridades em virtude de fatores de 
impacto. 
 
 
 
 
 
 
 
 
 
 
 
102 
 
 
 
 
 
 
 
6.4 PLANNING POKER 
O Planning Poker é uma técnica aplicável também à estimativa de 
complexidade, considerando o tamanho de projetos que incorporam metodologias 
ágeis e as histórias de usuário como elementos base para o levantamento de 
requisitos (COHN, 2005; GOMES, 2014). 
Contudo, sua aplicação em conjunto com a Metodologia Scrum, apesar de 
bastante afinada, não se faz obrigatória, dependendo de definições estabelecidas 
no planejamento do projeto, os quais se efetivam por meio da gestão (GOMES, 2014; 
SABBAGH, 2022). 
Se aplica muito bem a equipes ágeis por seu dinamismo, requerendo apenas 
dedicação de tempo para execução, o que se faz compensado pelo retorno 
alcançado no processo (AUDY, 2022). 
Tendo sido criado por James Greening (Figuras 11 e 30), um dos profissionais 
que participou da elaboração do Manifesto Ágil (temática tratada no item 3.4 deste 
material), esta técnica é constantemente associada à Metodologia Scrum, além do 
fato de realizar estimativas considerando as histórias de usuário e a 
Diagrama de Caso de Uso: representação gráfica que permite visualizar e compreender 
a relação entre os atores e os variados elementos de um sistema (VAZQUEZ; SIMÕES, 2016). 
Diagrama de Entidade-Relacionamento: representação gráfica que permite visualizar 
como as entidades de um sistema se relacionam entre si (HIRAMA, 2012). 
Diagrama de Classe: representação gráfica que permite a visualização dos objetos que 
compõem um sistema (SOMMERVILLE, 2011). 
 História do Usuário: descrição das necessidades do usuário sob a sua visão, facilitando o 
entendimento do desenvolvedor quanto as funcionalidades que necessitam se fazer 
dispostas em um sistema (OLIVEIRA, 2018; SABBAGH, 2022; AUDY, 2022; FERNANDES; ABREU, 
2014; WAZLAWICK, 2013). 
 
 
Neste vídeo: https://bit.ly/3V8driD. A Fatto Consultoria de Sistemas realizou Webinar, no 
qual efetivou a Análise de Pontos de Função de um App do Google. Indico assistir para 
compreender na prática o que aqui explicamos de modo teórico. Bom estudo! 
https://bit.ly/3V8driD
 
 
 
 
 
 
 
 
 
103 
 
 
conversação/dialogação efetiva entre os membros da equipe de desenvolvimento 
e análise, garantindo o alcance de um consenso de ideias entre todos (GOMES, 
2014). 
 
Figura 30: James Greening 
 
Fonte: O autor 
 
Deste modo, em sua efetivação, o Planning Poker tende a alcançar de modo 
interativo, combinado e prático, os elementos que se fazem citados na Figura 31. 
 
Figura 31: Elementos alcançados a partir do Planning Poker 
 
 
Fonte: adaptado de Cohn (2005) 
 
O Planning Poker age no sentido de pertencimento dos indivíduos envolvidos, 
no aprendizado coletivo e contínuo, na importância dos variados tipos de 
conhecimento e especialidades de pessoas que perfazem o corpo do time, e no 
papel do consenso para se alcançar o melhor resultado possível (AUDY, 2022). 
Por meio da aplicação e do uso de um jogo de cartas, os indivíduos que 
perfazem a equipe de desenvolvimento posicionam-se, considerando a sua visão de 
complexidade em relação ao sistema, tendo por parâmetro os fatores tempo e 
esforço, os quais servem como elementos-base para que se alcance um consenso a 
respeito do assunto em voga (COHN, 2005). 
Cada integrante da equipe, portanto, fazendo uso do baralho específico para 
 
 
 
 
 
 
 
 
 
104 
 
 
a metodologia, expressa pontuações a respeito da história do usuário ao mesmo 
tempo, fazendo-se uso de sistemática, aplicável à comunicação estabelecida entre 
eles, que permita a implementação de rodadas de jogo e o alcance de ideia única 
entre os entes envolvidos (GOMES, 2014). 
O baralho a ser utilizado se faz baseado na sequência de Fibonacci, com 
cartas pontuadas de 0 a 20, podendo possuir ainda mais 3 cartas adicionais, o que 
caracteriza uma curva crescente de incerteza, visto que o valor de uma carta 
seguinte é sempre o somatório de duas anteriores (COHN, 2005; GOMES, 2014; AUDY, 
2022), conforme se apresenta na Figura 32. 
 
Figura 32: Cartas do Planning Poker 
 
Fonte: Adaptado de Cohn (2005), Gomes (2014), Audy (2020) e Sabbagh (2022) 
 
Certas cartas possuem como significado os seguintes (COHN, 2005; AUDY, 
2022): 
a) carta de valor zero: significa a finalização de análise da história ou ainda que a 
complexidade seja tão baixa que não necessita ser estimada podendo ser 
resolvida rapidamente; 
b) carta com o símbolo de infinito (∞): significa que o elemento analisado está 
muito grande, necessitando ser dividido em partes menores; 
c) a carta com o ponto de interrogação (?): pode ser utilizada sempre que o 
jogador não se sentir em condição de estabelecer opinião a respeito da estimativa 
que se faz analisada; 
d) carta contendo a “figura da xícara de café”: o pedido de pausa é comum pois 
sendo um processo que requer dedicação de tempo, por vezes necessita de várias 
rodadas até o alcance de consenso, acarretando inclusive a exaustão dos 
participantes. 
As regras do Planning Poker seguem descritas na Figura 33. 
 
 
 
 
 
 
 
 
 
 
105 
 
 
Figura 33: Regras do Planning Poker 
 
Fonte: Adaptado de Audy (2022) 
 
Audy (2022) e Gomes (2014) seguem destacando que uma história de usuário 
com muitas funcionalidades tende a apresentar pontuação elevada em face da 
incerteza elevada presente em sua estimativa, o que explica a necessidade de sua 
divisão em histórias menores, permitindo que o time de desenvolvimento lide melhor 
com a incerteza e a complexidade. 
A estimativa deve considerar uma variável definida pela equipe, podendo ser 
tempo, dias, pontos, entre outros elementos passíveis de mensuração ao menos 
aproximada, permitindo que se identifique o tempo/esforço a ser gasto para a 
conclusão das histórias que se fizerem analisadas, o que por sua vez auxilia o 
entendimento, por parte do cliente, do cronograma de execução e das etapas de 
entrega elencadas (GOMES, 2014). 
Os resultados alcançados por meio das estimativas definidas devem ser 
considerados estabelecendo-se processos de comparação anteriores e posteriores 
a intervenções, o que demonstra a possibilidade de que a sistemática seja 
executada novamente mesmo depois de a complexidade ser resolvida no projeto 
(AUDY, 2022). 
Gomes (2014) refere-se ainda ao fato de que estimativas tendem a ser 
complexas e imprecisas, principalmente, em face do nível de maturidade da equipe 
envolvida e da tecnologia aplicada ao projeto, demonstrando que, com o passar do 
tempo e o aumento da experiência dos indivíduos envolvidos, torna-se natural o 
alcance de maior produtividade e celeridade na execução, demonstrando que a 
 
 
 
 
 
 
 
 
 
106 
 
 
complexidade, definida inicialmente pode se fazer minimizada à medida que a 
equipe ganha experiência em execução. 
Fazendo uso das regras dispostas na Figura 33 e do material apresentado na 
Figura 32, tem-se a seguir a sistemática de efetivação da estimativa por meio desta 
ferramenta disposta no Quadro 22. 
 
Quadro 22: Sistemática aplicada à estimativa pelo Planning Poker 
1 O Líder do Projeto, partindo da história do usuário, divide-a em partes e relata a todos 
os indivíduos da equipe envolvida (não deve possuir mais de 10 membros) um item a 
ser estimado (uma interação de usuário), solicitando que pontuem o nível de esforço a 
ser aplicado para o desenvolvimento da tarefa; 
2 Os membros da equipe discutem entre si em relação ao esforço e o tempo de 
execução, considerando todas as açõesque envolvam a efetivação da tarefa, tiram 
dúvidas a respeito do item e cada um escolhe uma carta que reflita o nível de trabalho 
necessário para a efetivação de seu desenvolvimento, sem revelar antecipadamente 
o valor de sua escolha; 
3 Assim que todos tiverem escolhido suas cartas, ao mesmo tempo devem expor suas 
escolhas, demonstrando que cada pessoa possui uma visão individualizada a respeito 
de uma determinada ação, evitando-se que as respostas possam ser influenciadas; 
4 Todos avaliam os resultados alcançados, identificando convergências e divergências; 
5 Os indivíduos que pontuaram com maior e menor estimativas, conversam entre si diante 
de todos apresentando suas ideias e as justificando, permitindo aos demais momentos 
de reflexão a respeito de fatores que de repente não se fizeram analisados em suas 
escolhas, podendo inclusive alterar a opinião anteriormente definida; 
6 Efetiva-se novas rodadas de estimativa até que o consenso entre todos seja 
alcançado, estabelecendo-se como fator de complexidade o número de maior 
ocorrência ou a média delas caso não haja consenso; 
7 Findada a análise de um item da história de usuário, passa-se a outro até que todos se 
façam analisados. 
Fonte: adaptado de Cohn (2005), Gomes (2014) e Sabbagh (2022) 
 
O indivíduo que atua liderando o processo, não pode estimar, possuindo papel 
apenas de gerenciar as ações que serão tomadas pela equipe como um todo 
(COHN, 2005). 
Vale destacar a crítica de Cohn (2005) e Audy (2022), na qual, considerando 
que a equipe possua experiências diferenciadas a percepção por vezes seja 
distorcida, pois, em sua composição múltipla e na necessidade de interação exigida, 
pessoas com personalidades mais fortes ou maior habilidade de fala tendem a se 
sobressair no processo, podendo inclusive influenciar as análises dos demais, o que 
requer do Líder uma atuação de mediação que pode ser dificultada. 
No entanto, desde que os membros da equipe se façam envolvidos e que o 
padrão de estimativa seja efetivamente definido, Gomes (2014) ressalta que os 
retornos alcançados tendem a se fazer de grande valia e elevada qualidade. 
 
 
 
 
 
 
 
 
 
107 
 
 
 
 
 
 
 
 
 
 
Neste vídeo: https://bit.ly/3Nf02mW. O André Gomes apresenta de modo simples e prático 
os assuntos aqui apresentados, principalmente associando ao Scrum. 
Neste outro vídeo: https://bit.ly/3n48BpX. O Marcos Santos apresenta na prática a 
aplicação do Planning Poker na avaliação de um projeto. 
Indico assistir aos dois para compreender melhor o que aqui explicamos teoricamente. 
Bom estudo! 
 
Tais métricas apresentadas podem ser aplicadas a outras ações que não seja a estimativa 
de software? 
 Se sim, requerem algum tipo de adaptação? Se não, por qual razão? 
https://bit.ly/3Nf02mW
https://bit.ly/3n48BpX
 
 
 
 
 
 
 
 
 
108 
 
 
FIXANDO O CONTEÚDO 
 
1. (FGV - TCE ES - 2023) O SiCONTA será um sistema de apoio à contabilidade 
tributária. No SiCONTA, há funcionalidades para incluir, alterar, excluir e consultar 
tributos. Para cada tributo é possível incluir, alterar, excluir e consultar alíquotas, ou 
seja, a alíquota só pode existir se estiver associada a um tributo. Com base na 
Análise de Pontos de Função, a contagem do projeto de desenvolvimento do 
SiCONTA deverá considerar: 
a) três Entradas Externas (EE) e uma Consulta Externa (CE); 
b) seis Entradas Externas (EE) e duas Consultas Externas (CE); 
c) três Entradas Externas (EE) e duas Consultas Externas (CE); 
d) seis Entradas Externas (EE) e dois Arquivos Lógicos Internos (ALI); 
e) três Entradas Externas (EE) e dois Arquivos Lógicos Internos (ALI). 
 
2. (FCC - TCE GO – 2022)Na métrica de análise de pontos por função, a identificação 
das funções de dados ALI e AIE: 
a) Representam funcionalidades fornecidas ao usuário a fim de atender às suas 
necessidades de persistência de dados internos e externos à aplicação. 
b) São classificadas como entradas externas, saídas externas e consultas de interesse 
do usuário. 
c) Representam os requisitos funcionais e não funcionais da aplicação, sejam ou não 
de interesse direto do usuário. 
d) São classificadas como entradas externas, saídas externas e consultas de interesse 
ou não do usuário. 
e) São as funcionalidades somente de entrada, de interesse do usuário ou quaisquer 
requisitos não funcionais que não necessitem ser persistidos. 
 
3. (IBFC - EBSERH - 2022)A análise por pontos de função (APF) tem como principal 
objetivo medir a funcionalidade do sistema tendo como base a visão do usuário, 
de acordo com características abaixo: 
(1)Utiliza-se de estimativas. 
 
 
 
 
 
 
 
 
 
109 
 
 
(2)É independente da tecnologia utilizada. 
(3)Baseia-se na visão do usuário. 
(4)Somente permite o seu cálculo de forma manual. 
Assinale a alternativa correta. 
a) Somente são aplicados o 1, 2 e 3 
b) Somente são aplicados o 1, 2 e 4 
c) Somente são aplicados o 2, 3 e 4 
d) Somente são aplicados o 1, 3 e 4 
e) 1, 2, 3 e 4 podem ser aplicados 
 
4. (Instituto AOCP - BANESE - 2022) Coletar métricas de software é importante para a 
estimativa de prazos, custos e qualidade do sistema projetado. Sendo assim, 
quando se trata da métrica de Pontos de Função, uma das contagens de tipo de 
dados diz respeito ao grupo lógico de dados e persistentes dentro da fronteira de 
outra aplicação, embora requerido ou referenciado pela aplicação que está 
sendo contada. Essa contagem refere-se a: 
a) arquivo lógico interno 
b) tipo de dados 
c) tipo de referências 
d) arquivo de interface externa 
e) casos de uso internos 
 
5. (IADES – BRB - 2021)No contexto das metodologias ágeis, o planning poker é uma: 
a) técnica para realizar estimativas de esforço de tarefas por meio do consenso entre 
o time. 
b) cerimônia para discutir e estipular as metas de entrega da próxima sprint. 
c) atividade lúdica realizada no decorrer das pausas das cerimônias para integrar o 
time. 
d) técnica para escrever casos de uso em cartões, estruturando seus requisitos do 
ponto de vista do usuário. 
e) ferramenta para registrar as lições aprendidas ao longo da sprint. 
 
 
 
 
 
 
 
 
 
 
110 
 
 
6. (adaptado de UFRN – 2018) Uma ferramenta que pode ser usada na gestão de 
projetos é a planning poker. Sobre essa ferramenta, analise as afirmativas abaixo: 
I. É uma técnica que privilegia a opinião do "jogador" ganhador em detrimento da 
opinião dos demais. 
II. O "jogo" é composto por cartas com números que representam esforço estimado. 
III. O "jogo" possui 356 cartas. 
IV. Há uma forte interação entre os "jogadores" e product owners, que discutem 
questões do projeto antes de realizarem suas jogadas. 
Estão corretas as afirmativas: 
a) II e IV 
b) I e III 
c) I e II 
d) III e IV 
e) I e IV 
 
7. (CESPE – TRE BA - 2017) A reunião de planejamento da sprint do Scrum é o evento 
em que: 
a) é definida a equipe scrum e são cancelados os itens da sprint anterior que não 
tenham sido entregues e os que tenham sido entregues, mas tenham sido 
rejeitados pelo usuário. 
b) são escritas as histórias dos usuários por meio do planning poker. 
c) é definida a meta da sprint e são selecionados os itens do product backlog que 
comporão a sprint. 
d) é decidido pelo PO (product owner) se haverá o cancelamento ou não 
da sprint em curso. 
e) participam exclusivamente o PO (product owner) e o SM (scrum master), que, por 
meio do planning poker, priorizaram os itens do backlog. 
 
8. (CESPE/CEBRASPE - TCE PR -2016) Acerca de Scrum, assinale a opção correta. 
 
 
 
 
 
 
 
 
 
111 
 
 
a) Em uma equipe Scrum, o conhecimento prático acerca do Scrum master é mais 
importante que o conhecimento teórico a seu respeito, ainda que esse 
conhecimento seja confirmado por certificações. 
b) Os requisitos para o desenvolvimento de um novo software são coletados dos 
usuários desse software e podem ser conflitantes entre si,situação que deve ser 
regularizada durante a etapa de construção. 
c) Todos os integrantes de uma equipe Scrum devem se revezar no papel de product 
owner, com o objetivo de tornar mais colaborativo o desenvolvimento do software. 
d) A técnica de planning poker é utilizada para mensurar o tamanho de um requisito, 
auxiliando o product owner a determinar se esse requisito será implementado no 
software para compor o backlog do produto. 
e) Os stakeholders, indivíduos e grupos interessados no processo e no software, fazem 
parte da equipe Scrum. 
 
 
 
 
 
 
 
 
 
 
 
112 
 
 
RESPOSTAS DO FIXANDO O CONTEÚDO 
 
UNIDADE 01 
 
 
 
UNIDADE 02 
 
QUESTÃO 1 C QUESTÃO 1 E 
QUESTÃO 2 A QUESTÃO 2 C 
QUESTÃO 3 B QUESTÃO 3 E 
QUESTÃO 4 B QUESTÃO 4 D 
QUESTÃO 5 A QUESTÃO 5 A 
QUESTÃO 6 A QUESTÃO 6 D 
QUESTÃO 7 A QUESTÃO 7 D 
QUESTÃO 8 D QUESTÃO 8 E 
 
 
UNIDADE 03 
 
 
 
 
UNIDADE 04 
 
QUESTÃO 1 B QUESTÃO 1 B 
QUESTÃO 2 D QUESTÃO 2 A 
QUESTÃO 3 E QUESTÃO 3 D 
QUESTÃO 4 A QUESTÃO 4 B 
QUESTÃO 5 C QUESTÃO 5 D 
QUESTÃO 6 C QUESTÃO 6 C 
QUESTÃO 7 C QUESTÃO 7 B 
QUESTÃO 8 D QUESTÃO 8 D 
 
 
UNIDADE 05 
 
 
 
UNIDADE 06 
 
QUESTÃO 1 B QUESTÃO 1 A 
QUESTÃO 2 C QUESTÃO 2 A 
QUESTÃO 3 D QUESTÃO 3 A 
QUESTÃO 4 D QUESTÃO 4 D 
QUESTÃO 5 C QUESTÃO 5 A 
QUESTÃO 6 A QUESTÃO 6 A 
QUESTÃO 7 A QUESTÃO 7 C 
QUESTÃO 8 B QUESTÃO 8 A 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
113 
 
 
REFERÊNCIAS 
 
ALÃO, Rui. Estratégias de design para contextos complexos. In: CONGRESSO 
PESQUISA & DESENVOLVIMENTO EM DESIGN, 13., Joinville, 5-8 nov. 2018. Anais [...]. 
Santa Catarina: Univille, 2018. [não paginado]. 
ALFF, Francilvio Roberto. O mínimo que você precisa saber: as quatro cerimônias do 
Scrum. Dois Vizinhos: edição do autor, 2022. 
AUDY, Jorge Horácio. As 8 leis de Lehman foram o Manifesto do século XX. Baguete, 
17 abr. 2014. Disponível em: https://www.baguete.com.br/colunas/jorge-horacio-
audy/17/04/2014/as-8-leis-de-lehman-foram-o-manifesto-do-seculo-xx. Acesso em: 
03 fev. 2023. 
AUDY, Jorge. Scrum 360. Um guia completo e prático de agilidade. São Paulo: Casa 
do Código, 2022 
BECK, Kent; BEEDLE, Mike; VAN BENNEKUM, Arie; COCKBURN, Alistair; CUNNINGHAM, 
Ward; FOWLER, Martin; GRENNING, James, HIGHSMITH, Jim; HUNT, Andrew; JEFFRIES, 
Ron; KERN, Jon; MARICK, Brian; MARTIN, Robert C.; MELLOR, Steve; SCHWABER, Ken; 
SUTHERLAND, Jeff; THOMAS, Dave. Manifesto para Desenvolvimento Ágil de Software. 
2001. Disponível em: https://agilemanifesto.org/iso/ptbr/manifesto.html. Acesso em 
09 fev. 2023. 
COHN, M. Agile Estimating and Planning. [s. l.]: Prentice Hall, 2005. 
DICIO. Dicionário Online de Português. Estimativa. 2023. Disponível em: 
https://www.dicio.com.br/estimativa/. Acesso em: 27 fev. 2023. 
FERNANDES, Aguinaldo Aragon; ABREU, Vladimir Ferraz. Implantando a Governança 
de TI: as estratégia à gestão de processos de serviços. 4. ed. Rio de Janeiro: Brasport, 
2014. 
GOMES, André Farias. Agile: desenvolvimento de software com entregas frequentes 
e foco no valor de negócio. São Paulo: Casa do Código, 2021. 
HIRAMA, Kechi. Engenharia de Software: qualidade e produtividade com tecnologia. 
Rio de Janeiro: Elsevier, 2012. 
OLIVEIRA, Bruno Souza de. Métodos Ágeis e Gestão de Serviços de TI. Rio de Janeiro: 
Brasport, 2018. 
PETERS, James F., Engenharia de Software: Teoria e Prática. Rio de Janeiro: Campus, 
2001. 
PRESSMAN, Roger S. Engenharia de Software. 7. ed. São Paulo: Pearson Prentice Hall, 
2011. 
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de Software: uma abordagem 
profissional. 8. ed. Porto Alegre: AMGH, 2016. 
https://www.dicio.com.br/estimativa/
 
 
 
 
 
 
 
 
 
114 
 
 
SABBAGH, Rafael. Scrum: gestão ágil para projetos de sucesso. São Paulo: Casa do 
Código, 2022 
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson, 2011. 
SUTHERLAND, Jeff. A arte de fazer o dobro do trabalho na metade do tempo. São 
Paulo, Leya, 2014. 
VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira. Engenharia de Requisitos: 
software orientado ao negócio. São Paulo: Brasport, 2016. 
VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira; ALBERT, Renato Machado. 
Análise de Pontos de Função: medição, estimativa e gerenciamento de projetos de 
software. 13 ed. São Paulo: Érica:Saraiva, 2018. 
WAZLAWICK, R. S. Engenharia de software: conceitos e práticas. Rio de Janeiro: 
Elsiever, 2013. 
WILDT, Daniel; MOURA, Dionatan; LACERDA, Guilherme ; HELM, Rafael. eXtreme 
Programming: práticas para o dia a dia no desenvolvimento ágil de software. São 
Paulo: Casa do Código, 2015.