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):