Engenharia de Software

Prévia do material em texto

Engenharia
de Software
Wagner Sanchez
W
agner Sanchez
Engenharia de Softw
are
Fundação Biblioteca Nacional
ISBN 978-65-5821-067-2
9 786558 210672
Código Logístico
I000358
Engenharia de 
Software
Wagner Sanchez
IESDE BRASIL
2021
© 2021 – IESDE BRASIL S/A. 
É proibida a reprodução, mesmo parcial, por qualquer processo, sem autorização por escrito do autor e do 
detentor dos direitos autorais.
Projeto de capa: IESDE BRASIL S/A. Imagem da capa: garagestock/shutterstock
Todos os direitos reservados.
IESDE BRASIL S/A. 
Al. Dr. Carlos de Carvalho, 1.482. CEP: 80730-200 
Batel – Curitiba – PR 
0800 708 88 88 – www.iesde.com.br
CIP-BRASIL. CATALOGAÇÃO NA PUBLICAÇÃO 
SINDICATO NACIONAL DOS EDITORES DE LIVROS, RJ
S195e
Sanchez, Wagner
Engenharia de software / Wagner Sanchez. - 1. ed. - Curitiba [PR] : 
Iesde, 2021. 
106 p. : il.
Inclui bibliografia
ISBN 978-65-5821-067-2
1. Engenharia de software. 2. Software - Desenvolvimento. 3. Progra-
mação orientada a objetos (Computação). 4. UML (Computação). I. Título.
21-74615 CDD: 005.1
CDU: 004.41
Wagner Sanchez Doutor e mestre em Engenharia Biomédica pela 
Universidade Mogi das Cruzes (UMC), especialista 
em Inteligência Artificial pela Pontifícia Universidade 
Católica de Campinas (PUC-Campinas), psicopedagogo 
pela Pontifícia Universidade Católica de São Paulo (PUC-
SP), pós-graduado em Engenharia de Software pela 
Universidade São Judas Tadeu (USJT) e bacharel em 
Análise de Sistemas pela Universidade Paulista (UNIP). 
Possui formação em Leadership & Innovation pelo 
Massachusetts Institute of Technology (MIT) e, também, 
no Entrepreneurship Program, na Babson College. 
Tem mais de 25 anos de experiência em docência 
e consultoria nas áreas de tecnologia, inovação e 
educação. É autor da primeira coleção digital cognitiva 
voltada à educação maker e ao desenvolvimento do 
pensamento computacional para alunos do Ensino 
Fundamental, além de mais de oito livros publicados 
nas áreas de inovação, gestão, tecnologia e educação. 
Atua como pró-reitor acadêmico, professor, escritor e 
pesquisador. 
Agora é possível acessar os vídeos do livro por 
meio de QR codes (códigos de barras) presentes 
no início de cada seção de capítulo.
Acesse os vídeos automaticamente, direcionando 
a câmera fotográ�ca de seu smartphone ou tablet 
para o QR code.
Em alguns dispositivos é necessário ter instalado 
um leitor de QR code, que pode ser adquirido 
gratuitamente em lojas de aplicativos.
Vídeos
em QR code!
SUMÁRIO
1 A importância da engenharia de software 9
1.1 O que é um software? 10
1.2 A evolução do hardware e software 12
1.3 A engenharia de software 22
1.4 A importância do design de software 25
2 Ciclo de vida do software 30
2.1 Ciclo de vida do software 31
2.2 Levantamento de requisitos 33
2.3 Análise e projeto 37
2.4 Implementação e testes 39
2.5 Implantação e manutenção 44
3 Orientação a objetos 51
3.1 Orientação a objetos 53
3.2 Classes e objetos 53
3.3 Abstração 56
3.4 Encapsulamento 57
3.5 Polimorfismo 60
3.6 Herança 61
4 UML – Unified Modeling Language 66
4.1 UML 66
4.2 Os diagramas da UML 68
4.3 Diagrama de atividades 68
4.4 Diagrama de classe 70
4.5 Diagrama de objetos 73
4.6 Diagrama de sequência 75
5 Diagrama de caso de uso 81
5.1 Diagrama de caso de uso 82
5.2 Cenário 83
5.3 Ator 84
5.4 Relacionamentos 85
5.5 Caso prático 87
 Resolução das atividades 101
Agora é possível acessar os vídeos do livro por 
meio de QR codes (códigos de barras) presentes 
no início de cada seção de capítulo.
Acesse os vídeos automaticamente, direcionando 
a câmera fotográ�ca de seu smartphone ou tablet 
para o QR code.
Em alguns dispositivos é necessário ter instalado 
um leitor de QR code, que pode ser adquirido 
gratuitamente em lojas de aplicativos.
Vídeos
em QR code!
Com as transformações digitais que estão ocorrendo 
nas organizações, a necessidade por desenvolvimento de 
software segue um crescente sem precedentes e sem sinais de 
desaceleração. 
As evoluções exponenciais das tecnologias estão destravando 
outras tecnologias e, por consequência, oportunidades de 
soluções computacionais corporativas nunca pensadas, sempre 
buscando alavancar diferenciais competitivos. 
A engenharia de software dá suporte para que profissionais 
de TI, usuários e gestores possam empregar seus esforços 
de maneira eficiente na construção de soluções, com mais 
assertividade e, ao mesmo tempo, com menos recursos. 
Esta obra entregará todos os recursos para os envolvidos 
no desenvolvimento de softwares, durante todas as fases de 
construção das soluções, combinando métodos, melhores 
ferramentas e técnicas, para que a garantia da qualidade seja 
alcançada com excelência. 
APRESENTAÇÃOVídeo
A importância da engenharia de software 9
1
A importância da 
engenharia de software
Com o estudo deste capítulo, você será capaz de:
• 	compreender	a	definição	de	software;	
• entender	as	características	de	sistemas	computacionais;	
• conhecer	a	evolução	do	hardware	e	do	software	ao	longo	dos	
anos	e	sua	relação	com	o	momento	atual;
• compreender	a	origem	da	engenharia	de	software;	
• reconhecer	a	importância	do	design	de	softwares.
Objetivos de aprendizagem
A	engenharia	de	software	começa	quando	há	uma	demanda	por	de-
terminado	resultado	ou	solução	para	problemas	corporativos.	De	algum	
lugar	da	equipe	de	TI,	normalmente	do	CIO,	vem	uma	solicitação	feita	ao	
desenvolvedor	para	criar	algum	tipo	de	software.
Mas	como	os	desenvolvedores	sabem	o	que	colocar	em	seu	software?		
Eles	dividem	em	necessidades	específicas	após	conduzir	entrevistas,	cole-
tar	informações,	examinar	o	portfólio	de	aplicativos	existente	e	conversar	
com	líderes	de	TI.	Em	seguida,	constroem	um	roteiro	de	como	elaborar	o	
software.	Essa	é	uma	das	partes	mais	essenciais,	pois	muito	do	“trabalho”	
é	concluído	durante	esse	estágio,	o	que	também	significa	que	quaisquer	
problemas	normalmente	ocorreram	aqui.
O	verdadeiro	ponto	de	partida	é	quando	os	desenvolvedores	come-
çam	a	escrever	código	para	o	software.	Em	muitos	casos,	essa	é	a	etapa	
mais	 longa	 do	 processo,	 pois	 o	 código	 precisa	 ser	 congruente	 com	os	
sistemas	atuais	e	a	linguagem	usada.	Infelizmente,	esses	problemas	nor-
malmente	não	são	percebidos	até	muito	mais	 tarde	no	projeto,	 logo,	o	
retrabalho	precisa	ser	concluído.
10 Engenharia de Software
Para	evitar	retrabalhos	e	desperdícios	existem	os	conceitos	de	en-
genharia	de	software,	que	busca	entregar	um	produto	de	acordo	com	
as	necessidades	do	usuário,	sendo	altamente	confiável,	eficiente	e	efi-
caz	na	sua	proposta.	Embora	a	engenharia	de	software	possa	levar	a	
produtos	que	não	cumprem	isso,	eles	quase	sempre	voltam	ao	estágio	
de	produção	(SOMMERVILLE,	2011).
Neste	capítulo	exploraremos	como	essa	engenharia	pode	otimizar	a	
produção	de	softwares,	trazendo	um	maior	valor	agregado	com	um	me-
nor	custo	de	desenvolvimento.
1.1 O que é um software? 
Vídeo Software é uma sequência de instruções escrita por um programador 
em linguagem de programação, informando a um computador como se 
comportar ou executar uma tarefa específica (ENGHOLM, 2010).
O software geralmente vem na forma de programas comerciais, 
como Microsoft Word, Excel, PowerPoint e Adobe Photoshop, jogos, sis-
temas operacionais de computador, celulares ou até mesmo malware, 
como vírus e ransomware.
Qualquer programa ou código executado em um computador é um 
exemplo de software, e qualquer coisa que façamos com um computa-
dor requer um software. Este é criado por programadores de computa-
dor, comumente chamados de desenvolvedores de softwares.
Os três principais tipos de software são: de sistema operacional, 
de aplicação e de desenvolvimento. O sistema operacional controla 
o funcionamento interno do computador e os periféricos, como mo-
nitores, impressoras e equipamentos de armazenamento de dados 
(PFLEEGER, 2007).
Sem um sistema operacional como o Windows ou o MacOS, um 
computador é apenasum conjunto de componentes de hardware inca-
pazes de executar qualquer função. 
A importância da engenharia de software 11
O sistema operacional permite que o computador execute funções 
básicas, fornecendo uma interface para que os usuários interajam com 
ele e uma plataforma na qual os aplicativos sejam executados. O sistema 
“abstrai” muitas tarefas comuns para aplicativos a fim de minimizar a re-
dundância. Por exemplo, oferece impressão como um serviço para aplica-
tivos, de modo que cada programa não precisa ter sua própria maneira de 
enviar arquivos para a impressora. 
Nesse grupo temos o firmware, um tipo de software semipermanen-
te, apresentado por muitos dispositivos e componentes, que informa 
ao dispositivo como se comportar e interagir com outros dispositivos. 
Frequentemente, pode ser atualizado, mas persiste quando não há ali-
mentação aplicada ao dispositivo. 
Os drivers de dispositivo também pertencem ao grupo dos softwares 
de sistemas operacionais. São pequenos programas que permitem a 
comunicação entre o sistema operacional e os componentes do com-
putador. Cada componente precisa de um driver para que o sistema 
saiba como usar o dispositivo. Praticamente todos os componentes de 
um computador, incluindo placa de vídeo, chip de som, teclado e mou-
se, têm seus próprios drivers. 
Para finalizar, vale ressaltar os utilitários, programas que geralmen-
te vêm com o sistema operacional ou integram-se totalmente a ele – 
como software antivírus, de limpeza de disco rígido e ferramentas de 
compactação de arquivo – para executar tarefas específicas.
Já o software de aplicação indica ao computador quais tarefes 
devem ser executadas para atender às demandas do usuário para 
determinada necessidade. Nesse grupo estão processadores de texto, 
planilhas, gerenciamento de banco de dados, inventário e programas 
de contas a pagar, folha de pagamento, controle de estoque e muitas 
outras aplicações corporativas e pessoais.
Os jogos e o software de multimídia são aplicativos populares (a câ-
mera do telefone é um aplicativo, assim como o Adobe Photoshop, usa-
do para editar gráficos e fotos). Os navegadores da web também estão 
entre os aplicativos de software mais comuns.
Por fim, o terceiro grupo são os softwares de programação. Não 
deve ser surpresa que um software seja criado com outro software. 
Os codificadores contam com várias ferramentas diferentes para criar 
programas (HIRAMA, 2011). 
12 Engenharia de Software
A seguir estão alguns exemplos de programas usados por codifica-
dores durante o desenvolvimento de software. 
Compiladores: programas que convertem o código 
escrito por humanos em forma de código de máquina 
de nível inferior que pode ser interpretado diretamen-
te pelo hardware do computador. A existência de 
compiladores torna prático criar um software extre-
mamente sofisticado. 
bs
d/
sh
ut
te
rs
to
ck
Linkers: programas que pegam a saída de um compi-
lador, geralmente muitos arquivos individuais, e com-
binam em um único arquivo executável, que pode ser 
executado por um usuário sem a necessidade de um 
ambiente de programação.
bs
d/
sh
ut
te
rs
to
ck
Depuradores: programas de computador usados para 
testar e “depurar” (localizar e remover erros) o código 
do computador.bsd
/s
hu
tte
rs
to
ck
A seguir exploraremos a evolução dos hardwares e softwares ao 
longo dos anos para compreender a importância da engenharia de 
software e as transformações que impactam atualmente as nossas vi-
das e a das empresas.
1.2 A evolução do hardware e software 
Vídeo Um engenheiro de softwares deve estar apto a trabalhar com todos 
os segmentos envolvendo a tecnologia da informação (TI), ou seja, ser 
capaz de atuar em todos os vértices da pirâmide que define um sistema 
de informação: pessoas, hardware e software.
Isso significa que esse profissional precisa entender de hardwares, ser 
capaz de especificá-los e implementá-los e fazer a sua manutenção. Tam-
bém deve desenvolver e instalar softwares e fazer a manutenção deles.
Começaremos nosso caminho rumo ao entendimento das máquinas, 
dos softwares e do comportamento humano que têm moldado e defini-
do o presente e que, certamente, continuarão a fazê-lo no futuro.
A importância da engenharia de software 13
O computador surgiu essencialmente como uma ferramenta de 
trabalho. Era utilizado por bancos, instituições financeiras, governos, 
exércitos e cientistas para a execução, em tempo hábil, de cálculos en-
volvendo uma grande quantidade de valores ou operações. Porém, na 
década de 1970, como veremos mais adiante, essas máquinas passa-
ram a ser adquiridas por pessoas não ligadas a essas áreas para, além 
do trabalho, serem usadas para diversão, aprendizagem, comunicação 
e muitas outras coisas (VELLOSO, 2014).
Há algum tempo, os computadores são muito mais do que máqui-
nas presentes em algum cômodo específico das casas ou dos escritó-
rios; eles nos acompanham na forma de um celular, monitoram nossa 
vida na forma de uma geladeira inteligente, nos levam para lugares na 
forma de um carro autônomo, nos divertem na forma de um console 
de videogame, entre muitas outras coisas.
Um bom engenheiro de software pode, entre outras atribuições, 
ser destacado para a função de programador de computadores ou 
gerenciador do parque de computadores de uma empresa. Assim, 
como podemos observar, para um profissional de TI, o computador, 
mais do que uma ferramenta de trabalho, confunde-se com a própria 
razão de sua existência.
Em função disso, começaremos com um histórico da evolução dos 
computadores. Perceberemos que determinados elementos presentes 
nas primeiras máquinas ainda fazem parte das mais atuais e, provavel-
mente, estarão presentes nas do futuro.
Embora às vezes tenhamos uma impressão contrária a isso, na 
atualidade, quase todas as pessoas, desde a infância, são capazes de 
executar operações aritméticas básicas, mas nem sempre foi assim.
Houve uma época na história que pouquíssimas pessoas tinham 
essa formação, a ponto de ela confundir-se com uma habilidade. As 
pessoas que dominavam aritmética eram aproveitadas pelo comércio, 
pelos bancos e pelas empresas. 
Com o aumento exponencial das atividades que exigiam forma-
ção matemática e o crescimento em escala inferior das pessoas que 
a tinham, inventores debruçaram-se na solução desse problema, isto 
é, desenvolver uma máquina capaz de permitir que pessoas sem for-
mação ou conhecimento executassem operações matemáticas. Assim, 
14 Engenharia de Software
surgiram as máquinas mecânicas de calcular, as quais podemos dizer 
que foram as primeiras máquinas computacionais (VELLOSO, 2014).
A primeira máquina de calcular foi desenvolvida por Blaise 
Pascal (1623-1662) – aquele mesmo do triângulo. Ele foi físico, mate-
mático e filósofo e sua máquina fazia apenas somas e subtrações. 
Ba
bi
ch
 A
le
xa
nd
er
/S
hu
tte
rs
to
ck
A Pascaline, como foi apelidada, consistia em seis engrenagens, 
cada uma com a gravação dos algarismos de 0 a 9, sendo possí-
vel somar até três parcelas por vez considerando que o total não 
ultrapassasse 999.999. Por exemplo, uma multiplicação de 30 por 10 
era feita somando 10 vezes o número 30 (VELLOSO, 2014).
Pascal recebeu do rei da França uma patente para que pudesse ven-
der a sua máquina no comércio. Ela teve uma vida útil de aproximada-
mente 200 anos (sem muitas “atualizações”); hoje um computador é 
considerado “atual” por apenas seis meses!
Com uma Pascaline, qualquer pessoa poderia executar uma soma, 
uma subtração ou mesmo uma multiplicação entre dois valores. Essa 
máquina, como não poderia deixar de ser, mostrou-se muito útil, e ou-
tros inventores dedicaram-se ao aprimoramento de seu projeto.
Depois surgiram as máquinas registradoras, mais sofisticadas que 
aquela de Pascal, pois possuíam memória para contabilizar a entrada 
de dinheiro no caixa, um grande avanço para o momento. Já imaginou 
como elas eram úteis em um comércio? 
Entre outras coisas, elas evitavam ou, pelo menos,minimizavam 
os erros no cálculo de trocos. Também contavam com uma alavan-
ca que devia ser girada para se chegar ao resultado. Na prática, o 
acionamento dessa alavanca era o equivalente ao relógio (clock) dos 
computadores atuais (PRESSMAN; MAXIM, 2016).
https://www.shutterstock.com/pt/g/suricoma
A importância da engenharia de software 15
As máquinas registradoras tornaram as operações matemáticas mui-
to mais seguras, porém ainda tinham vários pontos fracos, como a en-
trada de valores que, além de lenta, estava sujeita a erros de digitação.
Imagine, por exemplo, o caixa de um banco, ao longo do dia, ano-
tando os valores envolvidos nas transações em uma caderneta e, no 
final do dia, ao fechar o caixa, encaminhando-os para o setor de fecha-
mento geral das operações da agência. Nesse setor, novas contas são 
executadas e, mais uma vez, a entrada de valores, além de representar 
um risco, exige muito trabalho manual. Com o fechamento da agência, 
novas anotações são produzidas e, ao final de uma semana, por exem-
plo, um malote com os fechamentos da agência é encaminhado, via 
carroça, para a sede do banco, na qual, novamente, é processado, com 
todos os riscos já conhecidos.
Percebendo problemas como esse, inventores criaram os cartões 
perfurados, que podiam ser gerados pela própria máquina, ao final de 
uma operação, ou pelo caixa e que traziam informações dos valores 
envolvidos e das operações matemáticas realizadas. O caixa não preci-
sava mais anotar em uma caderneta as operações realizadas, embora, 
por algum tempo, mesmo com o cartão, isso tenha continuado.
Ao final do dia, os cartões eram colocados em outra máquina, que 
processava todas as operações da agência naquele dia, o que gerava 
novos cartões com balancetes diários da agência. Ao final de uma se-
mana, um malote com esses balancetes, na forma de cartões, era enca-
minhado, via carroça, para a sede do banco e lá era colocado em outras 
máquinas para ser processado.
Os riscos foram minimizados, pois apenas o caixa entrava com os 
valores e, depois dele, estes eram propagados diretamente nos cartões.
Devemos observar que, até esse momento da história, as má-
quinas eram destinadas apenas à realização de contas. Embora 
fundamentais, em quase todas as situações as contas eram apenas 
elementos isolados que, com muitos outros elementos, orientavam 
a tomada de decisão.
Imagine o gerenciamento de uma carteira de investimentos em 
que, a todo instante, contas são efetuadas para permitir a escolha 
da alocação dos recursos. Porém, SE determinada condição OU de-
terminado fator tornar-se relevante E determinada escolha for feita, 
16 Engenharia de Software
todas as contas devem ser refeitas para definir a parcela dos recur-
sos a serem alocados. 
Nessa situação, a análise das condições OU, E e SE depende ape-
nas de pessoas, e mais uma vez as máquinas podem nos ajudar! Foi 
para resolver situações como essa que as máquinas registradoras 
evoluíram e tornaram-se programáveis, ou seja, computadores.
Foi com o desenvolvimento da máquina analítica do matemáti-
co inglês Charles Babbage (1792-1871), a máquina de Babbage, que 
os conceitos do computador moderno começaram a ser definidos 
(VELLOSO, 2014).
Ch
ar
le
s 
Ba
bb
ag
e/
W
ik
im
ed
ia
 C
om
m
on
s
O equipamento, que somente foi construído para efeitos de-
monstrativos, possuía todas as funcionalidades do computador mo-
derno, como:
 • inserção de dados com o uso dos cartões perfurados;
 • unidade de memória para que os números pudessem ser arma-
zenados e reutilizados quando necessário;
 • desenvolvimento sequencial de instruções ao hardware, proce-
dimento que atualmente conhecemos como sistema operacional.
Máquina analítica de Charles Babbage.
A importância da engenharia de software 17
Tudo isso foi descrito originalmente em 1837, mais de um século 
antes que qualquer outro equipamento do gênero tivesse sido cons-
truído com sucesso.
Finalmente chegou a eletricidade! Primeiro, ela foi introduzida nos 
computadores completamente mecânicos, aqueles com base em engre-
nagens, na forma de motores que automatizaram a alavanca de relógio.
O Z1 foi desenvolvido em 1938, na Alemanha, e foi o primeiro com-
putador binário com base em componentes mecânicos acionados por 
um motor elétrico para gerar o sinal de clock, operando com números 
em ponto flutuante e um bit de sinal. 
O programa era lido de uma fita perfurada, os dados eram introduzi-
dos por meio de um teclado numérico e os resultados eram apresentados 
por lâmpadas elétricas que ficavam acesas ou apagadas, representando 
0 e 1. Esse feito notável foi desenvolvido por Konrad Zuse (1910-1995).
Em 1939, o Z2 substituiu a unidade aritmética mecânica do Z1 
por relês eletromecânicos. O Z3, feito em 1941, possuía uma me-
mória que utilizava cerca de 1.400 relês (podendo armazenar até 
64 números), sendo 1.200 relês utilizados nas unidades de controle 
e aritmética. Somente em 1950 o Z4 foi concluído e a memória me-
cânica voltou a ser utilizada, por ser mais compacta que a memória 
eletromecânica (VELLOSO, 2014).
Em 1936, o matemático inglês Alan Turing (1912-1954) – sim, o Turing 
do filme O jogo da imitação – desenvolveu uma teoria conhecida como 
máquina universal ou máquina de Turing, que, de maneira abstrata, mo-
delava qualquer computador digital (PRESSMAN; MAXIM, 2016).
Essa teoria serviu como premissa para o desenvolvimento posterior 
da máquina capaz de quebrar os dados criptografados pela máquina 
alemã Enigma durante a Segunda Guerra Mundial.
Mais à frente, em 1943, foi desenvolvido pela Universidade da 
Pensilvânia o conhecido Eniac (electronic numerical integrator and 
computer), que tinha capacidade de 5.000 somas por segundo, um 
marco para a sua época, pois utilizava aritmética decimal. Contava 
com uma memória de 20 acumuladores com até 10 dígitos, cada um 
utilizando 10 bits para o seu armazenamento. 
18 Engenharia de Software
Eniac
Avanços científicos na área dos semicondutores e todos aqueles 
problemas dos computadores valvulados levaram ao surgimento 
dos computadores transistorizados, os quais utilizavam transis-
tores no lugar das válvulas. Isso marcou a segunda geração dos 
computadores.
Como não deveria deixar de ser, os transistores também eram 
utilizados como válvulas, cujo entendimento, em nível superficial, 
era mais fácil do que daqueles construídos com válvulas. 
Um transistor possui apenas e exatamente três pinos: a base, o 
coletor e o emissor. Quando a base não é acionada por um sinal, ou 
seja, aplicamos o nível lógico 0 (0 V), não há passagem de corrente 
do coletor para o emissor e a chave coletor-emissor está aberta. 
Quando a base é estimulada por um sinal de nível lógico 1 (5 V), 
temos a passagem de corrente e a chave está fechada.
A importância da engenharia de software 19
Os computadores dessa geração eram muito menores que os 
valvulados, não exigiam preaquecimento, consumiam menos ener-
gia, esquentavam menos, duravam mais e eram mais rápidos e 
mais confiáveis.
Foi na terceira geração de computadores que os circuitos in-
tegrados, feitos de silício, começaram a ser utilizados. Os circui-
tos integrados ficaram conhecidos como chips e eram construídos 
integrando-se muitos transistores e outros componentes. Essa 
técnica ficou conhecida como LSI (large scale integration ou inte-
gração em larga escala).
Isso possibilitou a construção de computadores menores, pois 
um único chip podia substituir várias placas; mais baratos, pois 
além do argumento anterior, os chips eram feitos em escala; e mais 
rápidos, pois dentro de um chip os componentes ficavam mais pró-
ximos e protegidos e os sinais elétricos propagam-se mais rapida-
mente entre dois componentes e ficavam mais estáveis. 
A primeira geração de circuitos integrados apenas mostrou o 
caminho. Como os chips eram novidade, as máquinas, mesmo as 
mais simples, ainda eram bastante caras, e os desenvolvedores 
não entendiam para que serviria um computador de uso pessoal e 
como essamáquina deveria parecer para ser desejada em larga es-
cala pelas pessoas. Além disso, não existiam empresas de software 
destinadas à sua produção para uso pessoal, como editores de tex-
to, jogos, agendas etc. Contudo, a quarta geração mudou isso.
Melhorias nas técnicas de integração afetaram não somente os 
processadores, mas todos os componentes presentes em um com-
putador, principalmente memórias. Desse modo, nessa época, as 
memórias dinâmicas também deram um salto em sua capacidade: 
64 kbits em 1981, 256 kbits em 1984, 1 mbit em 1984 e 4 mbits e 16 
mbits em 1987 (VELLOSO, 2014).
Um exemplo dessa geração foi o Apple I, que teve uma vida mui-
to curta, tendo sido apresentado em 1976 e substituído em 1977 
pelo Apple II.
Uma	visão	mais	lúdica	e	
profunda	dessa	geração	
de computadores e o 
surgimento	da	Microsoft	
e da Apple – empresas 
ícones	do	segmento	de	
computadores	pessoais	
–	podem	ser	vistos	pela	
ótica	do	filme	Piratas 
do Vale do Silício.	Vale	a	
pena	conferir.
Direção: Martyn Burke. EUA: 
TNT, 1999.
Filme
20 Engenharia de Software
Placa do circuito 
integrado do 
Apple I
Ac
hi
m
 B
aq
ué
/W
ik
im
ed
ia
 C
om
m
on
s
O computador apresentado pela Apple tinha como grande dife-
rencial a presença de um monitor, o que fez toda a diferença, pois 
o usuário podia editar textos, programas de gerenciamento de es-
toques e clientes, entre outras funções. Essa máquina, sim, tinha 
utilidade para muitas pessoas.
Rama & Musée Bolo/Wikimedia Commons
Percebendo o rápido crescimento da Apple com o Apple II, a IBM – 
na época a maior empresa do setor de computadores – resolveu en-
trar no segmento de computadores de uso pessoal e criou o padrão 
IBM PC, apresentado em 1981.
Apple II
https://commons.wikimedia.org/wiki/User:Rama
A importância da engenharia de software 21
IBM 5150
Bo
ffy
 b
/W
ik
im
ed
ia
 C
om
m
on
s
Para competir com a Apple, a IBM adotou a estratégia de permitir 
que outros fabricantes usassem seu padrão, fazendo com que rapida-
mente esses computadores se tornassem padrão de mercado. Além 
disso, o desenvolvimento de software e hardware para essas máquinas 
era livre de qualquer restrição, o que barateou e diversificou a oferta.
Porém, a IBM ainda usava no sistema operacional uma interfa-
ce com base em linha de comando e tinha poucos recursos de áu-
dio, um monitor de fósforo e um processador inferior. Mesmo assim, 
a empresa ganhou o mercado! Devido ao seu preço muito menor (o 
do Macintosh era exorbitante) e à sua maior penetração, o padrão 
IBM PC-AT consagrou-se mundialmente.
Enquanto isso, a Apple amargou prejuízos com o Macintosh, 
tornando-o restrito às pessoas e às empresas que se disponibilizassem 
a pagar pelo seu alto preço – quanto às pessoas, pelos motivos que já 
conhecemos, e quanto às empresas, pelos seus fantásticos atributos 
quando o assunto é imagem, é aqui que a Apple ganha a fama de ter os 
computadores preferidos de estúdios de publicidade.
Novamente, como aconteceu na quarta geração dos computado-
res, a quinta geração foi marcada por um aprimoramento nas técnicas 
de integração, fazendo com que os processadores se tornassem mais 
complexos, rápidos e baratos, porém o dispositivo chaveador conti-
nuou o mesmo, o transistor.
Como percebemos, o computador pode ser entendido como algo sem 
um inventor definido. Ele é um constante aprimoramento de ideias ante-
riores proporcionado pelo avanço científico e pelas técnicas de fabricação, 
porém que mantém, desde sua origem, a presença de uma ideia funda-
22 Engenharia de Software
mental, aquela que faz uso de chaves eletrônicas organizadas logicamen-
te, de modo a permitir a solução de problemas lógicos e aritméticos.
1.3 A engenharia de software 
Vídeo
Diante da crescente demanda por desenvolvimento de software e, 
por conseguinte, do surgimento de novos softwares e hardwares, as 
indústrias de softwares precisam engajar-se nessa onda de competi-
tividade, melhorando de maneira eficaz sua produtividade para poder 
enfrentar adequadamente essa realidade em constante evolução.
Uma particularidade inerente aos sistemas de software é a dificul-
dade de seu desenvolvimento, que evolui à medida que surgem novas 
tecnologias e cresce o tamanho do sistema.
Durante as fases de desenvolvimento do software, ao combinar 
os métodos, as melhores ferramentas para automatizar isso, as técni-
cas para a garantia da qualidade do software e os procedimentos de 
controle e gestão, é possível aplicar as boas práticas sugeridas pela 
engenharia de software.
A engenharia representa uma metodologia unida ao esforço para 
empreender resultados, os quais são provenientes de trabalhos foca-
dos em diversas áreas, nas quais há um amplo conhecimento a fim de 
propor soluções às necessidades (SOMMERVILLE, 2011).
No desenvolvimento de software, em geral, encontramos os seguin-
tes tipos de problema:
 • Os recursos destinados aos projetos tornam-se insuficientes.
 • Os custos de serviços, produtos e mão de obra são altos.
 • As soluções propostas não agradam às partes interessadas.
 • Os custos dos softwares são maiores que o custo do hardware.
 • O custo de manter um software às vezes é maior do que o desen-
volvimento de um novo.
Consequentemente, de acordo com Hirama (2011), a engenharia de 
software foca a missão de executar os desafios de:
 • reduzir o custo;
 • seguir o cronograma de acordo com as expectativas;
 • incrementar a qualidade nos softwares;
A importância da engenharia de software 23
 • documentar de modo que qualquer parte interessada possa en-
tender (todos os detalhes devem ser escritos);
 • adaptar as alterações sugeridas e/ou necessárias no tempo e no 
custo adequados;
 • atender às necessidades do cliente;
 • dar suporte ao desenvolvimento de softwares de acordo com as 
mudanças tecnológicas.
A concepção e criação de um software é uma empreitada de extre-
ma complexidade, sendo essencial o conhecimento de todas as etapas 
que compõem essa missão. No desenvolvimento de um software é im-
portante que o roteiro da engenharia de software seja seguido elimi-
nando o desperdício de tempo e o custo e maximizando os resultados 
benéficos com qualidade.
Conforme Pressman e Maxim (2016), todo software deve ser desen-
volvido com base em um modelo de procedimentos predeterminado, de-
nominado de ciclo de vida de desenvolvimento de software. Este possui um 
conjunto de etapas que abrange métodos, procedimentos e ferramentas 
para que o produto final atenda às especificações do usuário.
Os problemas acontecem no desenvolvimento de softwares quan-
do os procedimentos ultrapassam prazos e custos, impactando negati-
vamente a qualidade percebida pelo cliente.
A demanda por uma engenharia de software originou-se do objeti-
vo de atender às necessidades dos usuários em um ambiente corpora-
tivo altamente volátil e competitivo.
Um software pode ser considerado de qualidade quando atinge 
ou supera as expectativas dos usuários, resolvendo os problemas cor-
porativos e alavancando os negócios. Um software de qualidade deve 
atender às seguintes áreas (TSUI; KARAM, 2013): 
 • Operacional: refere-se à funcionalidade em operações, como 
usabilidade, eficiência, correção de problemas, funcionalidade, 
proteção, confiabilidade e segurança.
 • Transição: significa a portabilidade entre as plataformas que o 
aplicativo precisa apresentar, ou seja, reutilização e adaptação 
são de extrema importância para um aplicativo de qualidade.
 • Manutenção: estabelece uma qualidade percebida no que se 
refere ao seu funcionamento em um ambiente de constantes 
24 Engenharia de Software
mudanças. Trata da modularidade, facilidade de manutenção, 
flexibilidade, adaptação e escalabilidade. 
O ciclo de vida de desenvolvimento é uma série de etapas na enge-
nharia de software para a elaboração do aplicativo proposto. Trata-se 
de uma sequência de procedimentos dentro do âmbito da engenharia 
de software, que possui as seguintes etapas (PRESSMAN; MAXIM, 2016):
1
Coleta de 
requisitos2
Análise	de	 
sistema
3
Codificação
4
Teste
5
Implantação
A engenharia de software tem seu início na primeira fase quando 
se observa uma solicitação do usuário para a solução de determina-
do problema. 
O requerimento é submetido a uma organização prestadora de ser-
viços e o próximo passo é feito pelos desenvolvedores, que fazem a 
diferenciação entre requisitos do usuário, do sistema e funcionais. 
O requisito é coletado por meio de entrevistas com um usuário, 
referência a um banco de dados, estudo do sistema existente etc. 
Após a coleta, a equipe analisa se o software pode ser feito para 
atender a todos os requisitos. 
A importância da engenharia de software 25
O desenvolvedor, então, decide um roteiro de seu plano, que in-
clui o estabelecimento das limitações e abrangências do software. De 
acordo com o requisito e a análise, é feito um projeto de software. A 
implementação do design de software começa com a escrita do código 
do programa em uma linguagem de programação adequada.
1.4 A importância do design de software 
Vídeo
O design de software é o processo de transformar os requisitos do 
usuário de alguma forma adequada, o que ajuda o programador na 
codificação e implementação do software. 
Durante a fase de design do software, o documento de design é pro-
duzido com base nos requisitos do cliente, portanto o objetivo dessa 
fase é transformar o documento de levantamento de requisitos no do-
cumento de design. 
Os seguintes artefatos são projetados, desenvolvidos e documenta-
dos durante a fase de design (SOMMERVILLE, 2011): 
 • Módulos diferentes necessários.
 • Controle das relações entre módulos.
 • Interface entre diferentes módulos.
 • Estrutura de dados entre diferentes módulos.
 • Algoritmos necessários para implementação entre módulos 
individuais.
Alguns objetivos são perseguidos no processo de elaboração de 
um bom design de software, tais como: 
 • Correção: ser correto, ou seja, implementar corretamente todas 
as funcionalidades do sistema.
 • Eficiência: abordar os problemas de otimização de recursos, 
tempo e custo.
 • Compreensibilidade: ser facilmente compreensível, modular e 
com todos os módulos dispostos em camadas.
 • Completude: ter todos os componentes, como estruturas de 
dados, módulos, interfaces externas etc.
 • Capacidade de manutenção: ser facilmente passível de altera-
ção sempre que uma solicitação for feita pelo cliente.
26 Engenharia de Software
O conceito de design de software significa simplesmente a ideia ou 
o princípio por trás do design. Ele descreve como deve ser planejada a 
resolução de problemas relacionados ao projeto do software, ou seja, a 
lógica ou o raciocínio que norteará o seu desenvolvimento.
O design de software permite que o engenheiro crie o modelo do 
sistema, ou o software ou o produto a ser desenvolvido ou construído. 
O conceito de design de software fornece uma estrutura ou modelo de 
suporte essencial para o desenvolvimento do software certo.
Para Engholm (2010), os seguintes pontos devem ser considerados 
no design: 
 • Abstração: ocultar dados irrelevantes, ou seja, simplesmente 
ocultar os detalhes para reduzir a complexidade e aumentar a 
eficiência ou a qualidade. Diferentes níveis de abstração são ne-
cessários e devem ser aplicados em cada etapa do processo de 
design para que qualquer erro presente possa ser removido, de 
modo a aumentar a eficiência da solução de software e refiná-la.
A solução deve ser descrita de maneira ampla, cobrindo uma 
gama de coisas diferentes em um nível superior de abstração, e 
uma descrição mais detalhada de solução de software deve ser 
fornecida no nível inferior de abstração.
 • Modularidade: subdividir o sistema. Significa simplesmente divi-
dir o sistema ou o projeto em partes menores para reduzir a sua 
complexidade. Da mesma forma, significa subdividir um sistema 
em partes menores para que elas possam ser criadas indepen-
dentemente e, em seguida, usadas em sistemas diferentes para 
executar funções distintas.
A modularidade no design tornou-se uma tendência, sendo im-
portante. Se o sistema contiver um menor número de compo-
nentes, significa que é complexo, exigindo muito esforço (custo). 
Porém, se formos capazes de dividi-lo em componentes, então, 
o custo será pequeno.
 • Arquitetura: trata-se de uma técnica para projetar a estrutura nor-
teadora de algo. A arquitetura no projeto de software é um concei-
to que envolve vários elementos e os dados da estrutura. Esses 
componentes interagem entre si e usam os dados na arquitetura.
A importância da engenharia de software 27
 • Refinamento: remove as impurezas, ou seja, refina algo para re-
mover quaisquer impurezas presentes e aumentar a qualidade. 
O conceito de refinamento de projeto de software é, na verdade, 
um processo de desenvolver ou apresentar o software ou o siste-
ma de modo detalhado. O refinamento é muito necessário para 
descobrir qualquer erro, se houver, e reduzi-lo.
 • Padrão: reaproveitamento de códigos. É uma forma ou um dese-
nho repetido várias vezes para formar um padrão. Este refere-se 
à repetição de uma solução para um problema recorrente e co-
mum dentro de certo contexto.
 • Ocultar informações: dados desnecessários não precisam 
aparecer, isto é, significa ocultar as informações para que não 
possam ser acessadas por uma parte indesejada. No projeto de 
software, a ocultação de informações é obtida projetando-se os 
módulos de modo que as informações coletadas ou contidas 
neles sejam ocultadas e não possam ser acessadas por quais-
quer outros módulos.
 • Refatorar: é reconstruir algo de tal forma que não afete o com-
portamento ou quaisquer outras características. Significa re-
construir o design para reduzir a complexidade sem afetar o 
comportamento ou as funções. 
O design de software possui três diferentes níveis que devem ser 
observados nos projetos de desenvolvimento. São eles: 
1. Projeto arquitetônico: a arquitetura de um sistema pode 
ser vista como a estrutura geral do sistema e a maneira como 
esta fornece integridade conceitual. O projeto arquitetônico 
identifica o software como um sistema com muitos componentes 
interagindo entre si. Nesse nível, os designers têm a ideia do 
domínio da solução proposta. 
2. Projeto preliminar ou de alto nível: aqui o problema é 
decomposto em um conjunto de módulos e a relação de controle 
entre os vários módulos e as interfaces entre os vários módulos 
são identificadas. O resultado desse estágio é chamado de 
arquitetura do programa. 
As técnicas de representação de design usadas nesse estágio são 
gráficas de estruturas de softwares que veremos mais à frente. 
Com	oito	edições	e	mais	de	
30	anos	no	topo	dos	livros	
mais	vendidos	e	recomen-
dados	da	engenharia	de	
software,	a	obra	Engenharia 
de software: uma aborda-
gem profissional	precisa	
estar	na	cabeceira	de	
todos os desenvolvedores, 
engenheiros,	programa-
dores	e	profissionais	de	
tecnologia.
O	livro	traz	um	leque	ri-
quíssimo	de	procedimen-
to,	roteiros,	cuidados	e	
atalhos	da	engenharia	de	
software.	Também	aborda	
aspectos	essenciais,	como	
o	trabalho	com	os	usuá-
rios	para	determinar	suas	
necessidades	de	software;	
o	roteiro	para	desenho	
de	diagramas	e	modelos	
que	ajudem	os	desenvol-
vedores	a	criar	o	código	
apropriado	para	o	sistema	
ou	aplicativo;	indicações	
de como documentar o 
sistema	ou	aplicativo	em	
detalhes	para	ajudar	os	
responsáveis	pela	manu-
tenção	futura;	os	proce-
dimentos	para	manter	o	
sistema	ou	aplicativo	com	
atualizações	e	correções	
conforme	necessário	etc.
Enfim,	por	muitos	é	
considerado	a	bíblia	da	
engenharia	de	softwares.
PRESSMAN, R. S. 8. ed. Porto Alegre: 
AMGH, 2016.
Livro
28 Engenharia de Software
3. Projeto detalhado: uma vez que o projeto de alto nível esteja 
completo, o projeto detalhado é realizado. Aqui, cada módulo é 
examinado cuidadosamente para projetar a estrutura de dados e 
algoritmos. O resultado do estágio é documentado na forma de 
um documento de especificação do módulo.CONCLUSÃO
Neste	capítulo	entendemos	a	definição	de	software	e	sistemas	compu-
tacionais	e	vimos	a	evolução	do	hardware	e	software	ao	longo	dos	anos,	
bem	como	os	principais	tipos	de	software.
Compreendemos	a	origem	da	engenharia	de	software	e	a	importân-
cia	do	design	de	softwares	atualmente	no	ecossistema	do	desenvolvi-
mento	de	aplicações.
Este	capítulo	foi	uma	ótima	introdução	aos	engenheiros	de	softwares	
que	desejam	ser	competentes	em	suas	 funções,	solucionando	proble-
mas	e	combinando	habilidades	de	pensamento	abstrato	com	uma	men-
talidade	prática.
A	partir	daqui,	estaremos	aptos	a	nos	aprofundar	em	todos	os	proce-
dimentos	da	engenharia	de	software,	que	busca	garantir	padronização,	
aumentar	qualidade	e	diminuir	prejuízos	nos	projetos	de	softwares.
ATIVIDADES
Atividade 1
Você	assumiu	a	missão	de	um	museu	altamente	relevante	nos	
Estados	Unidos	de	criar	uma	experiência	histórica	aos	visitantes:	
elaborar	uma	linha	do	tempo	com	os	principais	avanços	tecnoló-
gicos	ao	longo	da	história.	
Para	tanto,	utilize	os	marcos	trazidos	neste	capítulo,	bem	como	
outras	pesquisas,	para	criar	o	que	conhecemos	como	timeline 
da	tecnologia.	Use	a	criatividade	para	surpreender	a	todos	com	
gráficos,	imagens	e	até	animação	gráfica.	
Atividade 2
Escolha	um	aplicativo	que	você	utiliza	no	seu	dia	a	dia	e	de-
senvolva	um	documento	com	os	itens	do	design	de	software	
tratados	neste	capítulo.	Fale	como	a	abstração,	a	modularidade,	
a	arquitetura,	o	refinamento,	o	padrão,	a	ocultação	de	informa-
ções	e	a	refatoração	podem	ser	encontrados	no	aplicativo.	
A importância da engenharia de software 29
REFERÊNCIAS
ENGHOLM JR., H. Engenharia de software na prática. São Paulo: Novatec, 2010.
HIRAMA, K. Engenharia de software: qualidade e produtividade com tecnologia. Rio de 
Janeiro: Elsevier, 2011.
PFLEEGER, S. L. Engenharia de software: teoria e prática. São Paulo: Pearson Prentice 
Hall, 2007.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. 
Porto Alegre: AMGH, 2016.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson Education, 2011.
TSUI, F.; KARAM, O. Fundamentos de engenharia de software. São Paulo: LTC, 2013.
VELLOSO, F. de. C. Informática: conceitos básicos. 9. ed. Rio de Janeiro: Elsevier, 2014.
30 Engenharia de Software
2
Ciclo de vida do software
Com o estudo deste capítulo, você será capaz de:
• entender, analisar e implementar o ciclo de vida completo de 
um software;
• compreender análise, projeto, implementação, testes, implan-
tação e manutenção de sistemas;
• reconhecer a importância do levantamento de requisitos efi-
ciente para o sucesso da engenharia de software.
Objetivos de aprendizagem
Neste capítulo exploraremos o conhecido ciclo de vida de desen-
volvimento de sistemas que define as principais etapas do desenvolvi-
mento de software dentro da engenharia de software.
Existem muitas abordagens diferentes para essa atividade, e a 
maioria das equipes de desenvolvimento possuem uma metodologia 
iterativa, na qual os estágios são combinados e revisitados ao longo do 
projeto. O termo a que chamamos de ciclo de vida é usado para ilustrar 
que, eventualmente, mudanças na tecnologia ou nos requisitos de ne-
gócios tornarão um sistema obsoleto e o ciclo começará novamente – 
daí a importância de trazermos os conceitos ágeis para o nosso estudo.
O ciclo de vida de desenvolvimento de software é um processo de-
finido de desenvolvimento de softwares que, quando seguido, ajuda a 
criá-los de maneira rápida e eficiente.
Podemos comparar isso à receita que você segue para assar seu 
bolo favorito. Se o primeiro passo for combinar farinha com cacau em 
pó, você terá que seguir o processo para garantir um bolo bem assado. 
No entanto, se você misturar os ingredientes mencionados de uma vez, 
talvez não valha a pena saborear o bolo.
O mesmo se aplica para as etapas do ciclo de vida de desenvolvimen-
to de software: há um processo passo a passo definido para a criação 
Ciclo de vida do software 31
de software de qualidade. Se você perder alguma das etapas ou segui-
-las sem precisão, os esforços desse processo serão desperdiçados.
2.1 Ciclo de vida do software 
Vídeo O ciclo de vida do software (ou, em inglês, Software Development 
Life Cycle) é um processo sistemático de desenvolvimento de software 
que assegura a qualidade e as manutenções do software construído. 
O ciclo de vida na construção de softwares tem o objetivo de im-
plementar alta qualidade ao produto final, preferencialmente sur-
preendendo as expectativas do cliente. O desenvolvimento do sistema 
deve ser entregue no prazo e no custo orçados, sendo basicamente 
um plano detalhado que explora como planejar, construir e manter um 
software específico (PRESSMAN, 2016).
Cada fase do ciclo de vida do software tem seu próprio processo e 
resultados que deliberam a próxima etapa de modo cíclico com retroa-
limentação, mas sempre em parceria com os usuários para as devidas 
validações.
Apresentamos, a seguir, os motivos que impulsionam a implantação 
eficiente do ciclo de vida do desenvolvimento de softwares eficientes nas 
organizações que buscam diferenciais competitivos (PFLEEGER, 2007).
 • Fornecer subsídios para o planejamento, a codificação e a esti-
mativa de custo e tempo do projeto.
 • Entregar uma modelagem estruturada para as atividades que 
irão compor o desenvolvimento dos softwares.
 • Ser um dispositivo que propicia o acompanhamento e o monito-
ramento do projeto.
 • Dar ênfase à visibilidade de todo o planejamento estrutural do pro-
jeto para todos os envolvidos no processo de desenvolvimento.
 • Aumentar e melhorar a velocidade de desenvolvimento dos 
softwares.
 • Aprimorar as relações com o cliente.
 • Contribuir para a diminuição dos riscos relacionados ao projeto.
 • Eliminar sobrecargas no gerenciamento prático do projeto de 
software.
32 Engenharia de Software
O ciclo de vida também reduz o custo de desenvolvimento de 
software e, ao mesmo tempo, melhora a qualidade e reduz o tempo 
de produção, atingindo essas metas que aparentemente divergem, 
mas que na verdade são essenciais no desenvolvimento de softwares 
(PFLEEGER, 2007).
O ciclo segue um plano que remove as armadilhas típicas de proje-
tos de desenvolvimento de software. Esse plano começa avaliando os 
sistemas existentes, em busca de deficiências. Posteriormente, parte 
para a definição dos requisitos do novo sistema e, em seguida, ruma-se 
à criação do software por meio dos estágios de análise, planejamento, 
design, desenvolvimento, teste e implantação.
Ao prever erros com alto custo, como deixar de pedir feedback ao 
usuário final ou cliente, o ciclo de desenvolvimento eficaz pode eliminar 
retrabalho redundante e correções posteriores.
É importante, ainda, saber que há um grande foco na fase de tes-
te – com uma metodologia repetitiva, é possível garantir a qualidade 
do código a cada ciclo. Muitas organizações tendem a investir poucos 
esforços em testes, o que é um erro, pois um foco mais eficiente em 
testes pode economizar muito retrabalho, tempo e dinheiro.
O ciclo de vida tradicional e mais utilizado nas organizações é apre-
sentado na figura a seguir (IAN, 2011).
Sistema 
proposto
Figura 1
Ciclo de vida de software
Implementação e 
testes
Análise e projeto
Levantamento de 
requisitos
Implantação e 
manutenção
Fonte: Elaborada pelo autor com base em Ian, 2011.
Ciclo de vida do software 33
Em seguida, vamos explorar cada uma das etapas: levantamento 
de requisitos; análise e projeto; implementação e testes; implantação 
e manutenção.
2.2 Levantamento de requisitos 
Vídeo O levantamento de requisito é estágio inicial e essencial para um 
bem-sucedido processo de desenvolvimento de software. Esse proces-
so deve ser liderado por profissionais experientes e conhecedores do 
negócio. É a fase que dará uma visão mais clara e ampla sobre o escopo 
de todo o projeto e sobre as questões, oportunidades e diretrizes pre-
vistas que o desencadearam.
Aetapa de coleta de requisitos necessita de uma equipe capacitada 
em obter condições, dados, informações o mais detalhadas e confiá-
veis possível, contribuindo para no cumprimento do cronograma esta-
belecido (IAN, 2011).
Esta etapa se refere especificamente à prática de definir requisitos 
de software, mas na verdade todo projeto tem requisitos, desde uma 
nova plataforma de suporte ao cliente até uma cozinha remodelada. 
Em sua essência, trata-se do processo de compreensão para que o de-
senvolvedor saiba o que ele deve estar construindo e por que o está 
fazendo.
O processo geralmente envolve um conjunto de atividades, incluin-
do (SOMMERVILLE, 2011):
 • Levantamento de requisitos: obter os requisitos de negócios 
das partes interessadas e que são relevantes para compreender 
as necessidades do usuário.
 • Documentação de requisitos: codificação dessas informações 
em formato legível aos usuários para que eles possam confirmar 
o entendimento das necessidades.
 • Entendimento dos requisitos: etapa para que todos tenham 
certeza do entendimento dos requisitos que formarão o software.
É sempre fundamental lembrar que tudo depende do usuário! Ele 
é o personagem mais importante nesse processo. Descubra como os 
usuários desempenham suas tarefas e como desejam realizá-las de-
pois do software.
34 Engenharia de Software
1. O que os usuários precisam fazer?
2. Quais problemas precisam ser sanados?
3. Como os usuários querem resolver os problemas?
4. Quais tipos de recursos os usuários terão disponíveis?
5. Com que eficiência podemos fazer isso acontecer? 
6. Que tipo de flexibilidade pode ser necessária?
Essas são algumas perguntas que precisam ser respondidas nessa 
etapa.
A coleta de requisitos bem-sucedida é uma arte em entrevistar pes-
soas e conseguir informações. A seguir apresentamos algumas dicas 
que podem ajudar.
Estabeleça metas e objetivos do projeto desde o início
Isso pode parecer redundante: é claro que sabemos por que esta-
mos fazendo este projeto...Não é? 
Mesmo tendo-se a impressão de saber tudo, anotar e pedir aos 
stakeholders que assinem é o mais indicado.
Sem metas e objetivos claramente definidos, faltará uma estrutura 
para orientar as futuras tomadas de decisões. 
Documentar todas as atividades de obtenção de requisitos
Quando está no meio de entrevistas com as partes interessadas e 
na análise de documentação, muitas vezes o desenvolvedor pode sen-
tir que tem um grande domínio sobre as coisas. Mas, então, uma se-
mana se passa e alguns detalhes começam a ficar um pouco confusos, 
e o desenvolvedor percebe que não tem uma compreensão completa 
sobre os requisitos do seu negócio.
Parece óbvio, mas certificar-se de estar fazendo anotações detalha-
das durante as entrevistas com as partes interessadas é um passo po-
deroso para uma coleta de requisitos bem-sucedida. 
Seja transparente com a documentação de requisitos
Claro que você entende os requisitos e seus stakeholders também. 
Porém, todas as demais partes envolvidas entendem sua compreensão 
sobre os requisitos?
Após cada reunião, analise suas anotações, refine-as e, em segui-
da, compartilhe-as com a equipe do projeto, incluindo todas as partes 
interessadas. 
Ciclo de vida do software 35
Essa transparência não apenas ajuda a garantir que todos estejam 
na mesma página, mas também promove um senso de aceitação do 
projeto em todo o seu planejamento, começando com os requisitos do 
negócio. 
Fale com as partes interessadas e usuários certos
Um projeto geralmente pode ter partes interessadas “ocultas”. Faça 
perguntas de sondagem em suas reuniões iniciais para tentar desco-
brir quem são os usuários reais.
Frequentemente, essas pessoas não serão os principais tomadores 
de decisão, mas sua adesão é essencial para um projeto bem-sucedido. 
Usuários insatisfeitos que são forçados a usar um sistema que foi pro-
jetado sem as suas contribuições são um ingrediente-chave para um 
projeto fracassado.
Não faça suposições sobre os requisitos
Não presuma que compreendeu tudo, mesmo que tudo pareça 
óbvio. Um requisito aparentemente simples como “queremos um blog” 
pode mascarar todos os tipos de suposições, requisitos etc. 
1. Quais são os campos de uma postagem de blog? 
2. Como os autores são gerenciados? 
3. E quanto à marcação? 
4. Quais são as categorias? 
5. Como as postagens são exibidas? 
6. Eles estão agregados em um arquivo? 
7. Existe um feed? 
8. Quem são os autores e qual é seu nível de proficiência técnica? 
O ponto-chave está realmente nos detalhes que o desenvolvedor 
pode conseguir se fizer as perguntas certas e não acelerar o processo 
de coleta de dados. 
Confirmar, confirmar, confirmar
Isso significa “ser transparente”? No entanto, não é totalmente a 
mesma coisa. 
É ótimo apenas compartilhar suas anotações com uma parte inte-
ressada, mas muito mais valioso é fazer uma revisão rápida junto a ela 
e obter sua aprovação oficial. 
36 Engenharia de Software
O silêncio das pessoas não é um indicador de sucesso. Obtenha a con-
firmação formal das partes interessadas para só depois seguir em frente.
Pratique a escuta ativa
Conseguir que alguém se sinta ouvido é uma das melhores coisas 
que o desenvolvedor pode fazer pelo usuário. Entretanto, isso vai além 
de apenas ouvir o que eles dizem: o desenvolvedor também precisa 
ouvir o que os usuários não dizem e como eles dizem as coisas, bem 
como tentar ler sua linguagem corporal e outros indicativos de que ain-
da existem informações para serem passadas por parte dos usuários.
Isso é chamado de escuta ativa e trata-se de um componente-chave 
para o sucesso levantamento de requisitos. Não presuma que está sem-
pre entendendo a história, preste atenção às pequenas pistas que revelam 
pontos problemáticos, desejos, objetivos não declarados e suposições.
Foco nos requisitos de negócios, não nas ferramentas
Tenha cuidado ao reunir requisitos nos quais está realmente se con-
centrando e ao ouvir as necessidades dos stakeholders em vez de se pren-
der à ferramenta que está usando. Qualquer metodologia ou software 
pode ser utilizado desde que não atrapalhe a coleta de requisitos.
Lembre-se: você pode não ter entendido tudo 
Mesmo o melhor coletor de requisitos vai perder coisas, e sabe por 
quê? Porque o desenvolvedor e seus stakeholders são seres humanos, 
e seres humanos cometem erros. Mais tarde, o desenvolvedor vai pen-
sar em coisas que se esqueceu de perguntar. O stakeholder pensará 
em coisas que se esqueceu de mencionar (SOMMERVILLE, 2011).
As coisas podem mudar, as prioridades podem mudar. A boa notí-
cia é que o planejamento com antecedência poderá proporcionar uma 
construção de software interativa e eficiente durante o ciclo de vida do 
projeto; com isso, o gerenciamento contínuo de requisitos será garantido. 
Esse tempo é essencial porque os requisitos (orientados e criados 
por humanos) simplesmente não são estáticos. Dar a si mesmo tempo 
para gerenciar ativamente os requisitos ao longo de todo o projeto pode 
ajudá-lo a interromper o aumento do escopo antes de iniciá-lo e garan-
tir que sua equipe esteja sempre se concentrando no conjunto certo de 
prioridades que correspondem aos requisitos reais (IAN, 2011).
Ciclo de vida do software 37
Obviamente, há muito mais que pode ser dito sobre a arte e a ciência 
da coleta de requisitos, mas espero que esta lista tenha fornecido algumas 
ferramentas úteis para gerenciar esse processo com sucesso. Agora que já 
se sabe como definir o que está construindo vamos seguir para a próxima 
etapa do ciclo de vida do processo de desenvolvimento de software. 
2.3 Análise e projeto 
Vídeo O estágio de análise e projeto é uma etapa do desenvolvimento em 
que precisamos identificar quais são os principais aspectos do proble-
ma que se pretende resolver com o software.
Existem quatro pontos que precisamos identificar quando analisa-
mos um problema. São eles (HIRAMA, 2011):
1. Finalidade do software: muitas vezes se consegue isso com 
um texto que detalha o motivopelo qual o software está sendo 
desenvolvido.
2. Entregas: lista do que deve ser entregue ao longo do projeto. 
Esses elementos serão entregues ao cliente ou usuário final. 
3. Limites: limites definidos aos quais o software atenderá, suas 
fronteiras entre o que deve ou não ser atendido.
4. Requisitos funcionais: especifica as entradas, os processos e as 
saídas.
Esses quatro aspectos podem ser detalhados quando definimos 
entradas, processamentos e saídas esperadas. Para ficar mais claro, 
vamos a um exemplo bastante simples.
Exemplo 1
Objetivo: o software deve ser criado para permitir que um usuário 
insira dez números. Cada número deve ser validado para garantir que 
não seja inferior a 0 e nem superior a 100.
O programa deve manter um total contínuo dos números inseridos 
e produzir o total final.
Entregas: o escopo deste exemplo seria o projeto entregue, incluin-
do os aspectos: design, programa concluído, plano de teste, resultados 
de teste e relatório de avaliação. Um curto limite de tempo também 
seria definido no projeto, provavelmente menos de 30 minutos.
38 Engenharia de Software
Requisitos funcionais:
 • entradas: dez números;
 • processos: “validar dez números” e “calcular total”;
 • saídas: total digitado até o momento;
 • limites: cada número deve ser validado para garantir que não 
seja inferior a 0 e nem superior a 100. Portanto, os limites seriam 
0 e 100.
Exemplo 2
Objetivo: os proprietários de um parque temático pediram que fos-
se desenvolvido um programa para registrar o número médio de visi-
tantes em uma semana.
Para tanto, o usuário digitará o número total de visitantes para cada 
dia da semana. O programa deve, então, gerar o número médio de 
visitantes durante a semana.
Entregas: o escopo deste exemplo seria o projeto entregue, incluin-
do os aspectos: design, programa concluído, plano de teste, resultados 
de teste e relatório de avaliação. O limite de tempo desse programa 
seria relativamente curto, possivelmente algo entre 1 e 2 horas.
Requisitos funcionais:
 • entradas: total diário de pessoas;
 • processos: calcular média diária;
 • saídas: média de pessoas;
 • limites: pode ser difícil encontrar alguns limites neste exemplo. 
Nele, estamos usando dias da semana, portanto não usaríamos 
mais do que sete dias da semana. Outro limite seria que o total 
de visitantes deve ser maior que zero, pois não pode haver visi-
tantes negativos.
Na fase de análise e projeto também é necessário, geralmente, 
delinear claramente quaisquer recursos que serão necessários, por 
exemplo:
 • hardware necessário para executar o software;
 • compatibilidade de software;
 • necessidade de uma conexão com a internet durante o uso;
 • competência de TI e do grupo de usuários para a implementação 
da solução.
Ciclo de vida do software 39
A fase de análise e projeto de software é o momento em que os ar-
quitetos e desenvolvedores elaboram especificações técnicas avança-
das de que precisam para criar o software de acordo com os requisitos. 
As partes interessadas discutirão fatores como níveis de risco, com-
posição da equipe, tecnologias aplicáveis, tempo, orçamento, limita-
ções do projeto, método e projeto arquitetônico.
Com base nas definições, desenvolve-se um documento chamado 
Documento de Especificação de Projeto que irá balizar o projeto arqui-
tetônico, os componentes, a comunicação, a representação de telas e 
os fluxos de usuário do produto. Essa etapa fornece um modelo para 
desenvolvedores e testadores e reduz as chances de falhas e atrasos 
no produto final (ENGHOLM, 2010).
Agora vamos à próxima fase!
2.4 Implementação e testes 
Vídeo A implementação ou codificação do software é o momento em que 
os desenvolvedores, de posse dos requisitos e da documentação da 
fase de análise e projeto, debruçam-se sobre a programação.
Uma linguagem é escolhida e o processo se inicia, levando em consi-
deração um padrão de programação dentro da equipe. Os padrões de 
codificação são uma série de procedimentos que podem ser definidos 
para uma linguagem de programação específica, determinando um es-
tilo de programação, os métodos e os procedimentos diferentes. 
Esses procedimentos podem ser realizados para vários aspectos do 
programa escrito nessa linguagem e podem ser considerados atributos 
essenciais do desenvolvimento de software.
Um padrão de codificação garante que todos os desenvolvedores 
que trabalham no projeto sigam certas diretrizes especificadas. O có-
digo pode ser facilmente compreendido e a consistência adequada é 
mantida (TSUI; KARAM, 2013).
A consistência tem um impacto positivo na qualidade do programa 
e deve-se mantê-la durante a codificação. Além disso, é importante cui-
dar para que as diretrizes sejam seguidas de maneira homogênea nos 
diferentes níveis do sistema e não se contradigam.
40 Engenharia de Software
A codificação deve seguir algumas premissas para que apresente 
uma fácil leitura por parte das equipes técnica e não técnica, tais como:
 • Tentar definir diferentes seções do código segmentando blocos 
de código em um parágrafo. Para tanto, é aconselhável usar 
indentação para indicar o início e o fim das estruturas de con-
trole, juntamente a uma especificação clara do local entre elas no 
qual o código está.
 • Atribuir consistência na convenção de nomenclatura das variá-
veis em todo o código. Além disso, devem ser descritos os dados 
que estão no código.
 • Nomear as funções de acordo com o que executam.
 • O código deve ser entendível mesmo depois de se retornar a ele 
após algum intervalo de tempo, sem que o programador tenha 
que olhar para cada linha do código-fonte.
 • Seguir um método específico para comentar o trabalho.
 • As funções da linguagem que são complexas ou a estrutura que é 
difícil de ser compreendida devem ser evitadas.
Com simples atitudes dos programadores, é possível evitar que os 
desenvolvedores de software gastem uma parte maior do seu tempo 
resolvendo os problemas que poderiam ter sido evitados. Implementar 
padrões de codificação ajuda a equipe a detectar os problemas anteci-
padamente ou até mesmo evitá-los completamente, o que aumenta a 
eficiência em todo o processo de software.
Após uma codificação eficiente e padronizada, parte-se para os testes. 
A implementação dos testes em software é o processo de desenvolver e 
priorizar procedimentos de teste, criando dados e, opcionalmente, prepa-
rando e escrevendo scripts de teste automatizados (TSUI; KARAM, 2013).
É de grande importância escolher os testes certos e executá-los na 
ordem certa. A importância disso cresce exponencialmente nas estra-
tégias baseadas em risco quando criamos prioridades com base na 
probabilidade de risco e problemas.
O procedimento teste é considerado uma atividade básica destinada 
a detectar e resolver problemas técnicos no código-fonte do software e 
avaliar a usabilidade geral do produto – desempenho, segurança e compa-
tibilidade. Não apenas é a parte principal da garantia de qualidade como 
também é parte integrante do processo de desenvolvimento de software.
Ciclo de vida do software 41
Um ponto importante no processo de teste é que a empresa esta-
beleça uma política de testes. Trata-se de um documento que contenha 
os princípios dos testes adotados pela empresa e os principais objeti-
vos de teste dela. Também explica como serão realizados e como uma 
empresa mede a eficácia e o sucesso dos testes (PRESSMAN, 2016).
A seguir listamos os itens essenciais de uma política de testes de 
softwares eficaz:
 • Definição do que o teste significa para a empresa.
 • Objetivos dos testes para a organização.
 • Padrões e critérios gerais para teste de software em projetos.
 • Lista de ferramentas para apoiar o processo de teste.
 • Métodos e métricas para avaliar a eficiência dos testes.
 • Maneiras de como melhorar os processos de teste.
Apoiando a política de testes se faz necessário um plano de gestão 
de qualidade, documento que define um nível aceitável de qualidade 
do produtoe descreve como o projeto alcançará esse nível. 
Não se trata de um documento obrigatório, mas ele ajudará a agen-
dar todas as tarefas necessárias para garantir que o projeto atenda às 
necessidades e expectativas do cliente. 
O principal objetivo desse plano é apoiar os gerentes de projeto e 
ajudar a organizar o processo, definindo funções, responsabilidades e 
padrões de qualidade a serem alcançados. Consequentemente, deve 
incluir os requisitos de qualidade do software e descrever como eles 
devem ser avaliados (PRESSMAN, 2016).
A seguir temos alguns tópicos essenciais para o desenvolvimento 
do plano: 
 • Objetivos de qualidade perseguida.
 • Principais entregas do projeto e processos a serem revisados 
para um nível de qualidade satisfatório.
 • Padrões de qualidade adotados.
 • Atividades de controle e garantia de qualidade.
 • Funções e responsabilidades de qualidade.
 • Ferramentas de qualidade.
 • Plano para relatar problemas de controle e garantia de qualidade.
42 Engenharia de Software
Depois do plano de qualidade, o gestor deve se debruçar sobre o 
desenvolvimento da estratégia de teste, documento de nível de pro-
duto mais específico que deriva dos requisitos de sistema, levantados 
junto aos usuários.
A estratégia de teste deve ser desenvolvida para definir as abor-
dagens de teste de software usadas para atingir os objetivos de teste. 
Uma estratégia de teste é orientada pelos requisitos de negócios do 
projeto, razão pela qual ela se confunde com as responsabilidades de 
um gerente de projeto.
Os principais componentes de uma estratégia de teste são:
 • escopo do teste;
 • objetivos de teste;
 • limitações de orçamento;
 • comunicação e relatório de status;
 • padrões industriais;
 • teste de medição e métricas;
 • relatórios e rastreamento de defeitos;
 • gerenciamento de configurações;
 • prazos;
 • cronograma de execução de teste;
 • identificação de risco.
Em um projeto pequeno, a estratégia de teste faz parte de um plano 
de teste. Porém, para um projeto maior, o gestor de projetos precisa 
criar uma estratégia de teste como um documento estático separado e 
a partir do qual cada plano de teste pode ser desenvolvido.
Um bom documento de estratégia de teste responde às seguintes 
perguntas:
 • Qual é o produto?
 • Qual(is) parte(s) deve(m) ser testada(s)?
 • Como eles devem ser testados?
 • Quando o teste deve começar?
 • Quais são os critérios de início/fim?
Por fim, é recomendado o desenvolvimento do plano de teste, docu-
mento que descreve o que testar, quando testar, como testar e quem 
Ciclo de vida do software 43
fará os testes. Ele também descreve o escopo e as atividades do teste. O 
plano de teste inclui os objetivos dos testes a serem executados e ajuda 
a controlar os riscos. É uma boa prática ter um plano de teste escrito 
por uma pessoa experiente, como um líder ou gerente de qualidade.
Um bom plano de teste deve incluir a programação de todas as ativi-
dades necessárias para controlar o tempo de teste de sua equipe. Deve 
também definir as funções de cada membro da equipe para que todos 
saibam o que é necessário. 
Não existe uma maneira universal de se criar um plano de teste por-
que ele depende dos processos, dos padrões e das ferramentas de ge-
renciamento de teste implementados na empresa. Mas aqui seguem as 
principais informações que um plano de testes de softwares deve conter. 
 • Introdução.
 • Itens de teste (o produto e suas versões).
 • Problemas de risco de software.
 • Recursos a serem testados.
 • Recursos a não serem testados.
 • Abordagem (estratégia).
 • Critérios de aprovação ou reprovação do item.
 • Critérios de suspensão.
 • Produtos (documento de plano de teste, casos de teste, ferra-
mentas, registros de erros, relatórios de problemas etc.).
 • Ambiente de teste (hardware, software, ferramentas).
 • Cronograma.
 • Necessidades de pessoal e treinamento.
 • Responsabilidades.
 • Riscos.
 • Aprovações.
Todos esses itens são necessários para que se possa estabelecer 
um plano de testes que seja objetivo, evitar repetições e desperdícios 
e, principalmente, aprovar o software de acordo com as necessidades 
dos usuários e sem anomalias operacionais 
Por último, é importante que o plano de testes seja compartilhado 
com todas as partes interessadas, pois ele fornecerá informações so-
bre os processos de teste e, consequentemente, de qualidade.
2.5 Implantação e manutenção 
Vídeo Após meses ou anos de trabalho, você finalmente desenvolveu o 
software ou parte dele pode ser implementado. Que alívio!
Infelizmente, no entanto, normalmente não temos a “casa livre”, ou 
seja, existem softwares antigos rodando, usuários acostumados com o 
padrão antigo – enfim, uma série de desafios a serem superados.
A implementação de qualquer tipo de nova tecnologia no local de 
trabalho, incluindo esse novo software, pode ser uma mudança que 
ocorre com muito estresse.
As pessoas geralmente resistem a qualquer mudança que afete seu 
status quo, ou seja, o estado atual das coisas. E pedir para que as pes-
soas aprendam uma nova ferramenta certamente parecerá uma inter-
rupção indesejável.
O importante é passar a confiança de que a implementação trará 
benefícios para a empresa, para todos individualmente, bem como de 
que ninguém será desligado, se for possível afirmar isso.
Todos os impactados precisam estar de “braços abertos” para o 
novo software!
Apresentamos cinco dicas essenciais para essa missão 
(SOMMERVILLE, 2011):
1. Encontre seus campeões
Se você puder aproveitar o entusiasmo dos colaboradores empol-
gados com o novo para dar impulso em torno desse novo software, 
essa empolgação pode ajudar a convencer o restante dos funcionários 
a utilizá-lo.
Encontre pessoas que se sintam naturalmente à vontade com 
os conceitos do novo software e incentive-as a defendê-
-lo. Você pode considerar as pessoas da equipe pi-
loto que ajudaram a avaliar a ferramenta ou as 
pessoas que usarão o software com maior 
frequência. Ver o entusiasmo 
desses campeões ajudará a con-
verter as pessoas mais céticas 
ou hesitantes.
Pu
re
So
lu
tio
n/
Sh
ut
te
rs
to
ck
4444 Engenharia de softwareEngenharia de software
2. Crie um entendimento compartilhado
Se os funcionários não encontrarem um motivo convincente para 
usar o novo software, é possível que a empresa receba taxas de adoção 
baixas. Portanto, ajude os colaboradores campeões a entender exata-
mente o que é a ferramenta, o que ela faz e por que foi desenvolvida. 
Envolva as pessoas desde o início do processo de implementação e in-
centive as perguntas apresentando transparência nas respostas.
3. Realizar eventos de treinamento
Os eventos de treinamento podem ser uma forma eficaz de treinar 
os funcionários em um novo software. Use esses eventos para estimu-
lar o diálogo e responder a perguntas, reforçar os benefícios da ferra-
menta e demonstrar sua aplicação prática diária no fluxo de trabalho 
da equipe.
É importante encontrar maneiras criativas de incorporar o novo 
software à rotina off-line ou à rotina com o software antigo com a 
maior frequência possível.
4. Mova conteúdos importantes para o novo software
Uma maneira de aumentar a adoção é tornar as informações im-
portantes de que os funcionários precisam acessíveis apenas por meio 
da nova ferramenta. Na verdade, definir um prazo rígido de migração 
para o novo software pode ser a única maneira de fazer com que os 
retardatários se convertam.
Mas tome cuidado! Essa é uma etapa ousada que corre o risco de 
frustrar os funcionários, especialmente se implementada muito cedo. 
Para ajudar nesse processo, comunique e enfatize as razões para a 
adoção do novo software de maneira eficaz, ressaltando como a nova 
ferramenta beneficiará a todos.
Pu
re
So
lu
tio
n/
Sh
ut
te
rs
to
ck
Ciclo de vida do softwareCiclo de vida do software 4545
46 Engenharia de Software
5. Considere a opção do uso de recompensas
Recompensas podem ser uma forma eficaz de incentivar um deter-
minadocomportamento, mas isso depende da cultura e da filosofia da 
organização. É importante notar que as “cenouras” e os “por-
retes” tendem a falhar quando aplicamos essas metodolo-
gias em pessoas pensadoras e criativas, podendo até ser 
prejudiciais.
A verdadeira motivação é impulsionada por um senso 
de propósito e busca de domínio, razão pela qual transmitir 
o valor do software é tão importante. Dito isso, pequenas 
recompensas voltadas a incentivar a participação podem 
ser bastante eficazes quando relacionadas a tarefas menos 
criativas, como controle de tempo.
Finalmente chegamos à última etapa do ciclo de desenvolvi-
mento de software: a manutenção. Para essa etapa, é essencial que o 
gestor desenvolva um plano de manutenção.
Um plano de manutenção é um documento que define o trabalho 
realizado para manter ativos operacionais. O conteúdo do documento 
ajuda a facilitar o uso contínuo de um ativo com desempenho ideal. 
Sua instalação pode evitar avarias significativas ou renovações impre-
vistas se você seguir as diretrizes fornecidas aqui.
A ideia por trás do planejamento de manutenção é garantir que se 
possa manter as condições de funcionamento adequadas dos equipa-
mentos. Embora um plano comum faça esse trabalho, qualquer ins-
talação requer um programa eficaz para que se aproveitem todos os 
benefícios da política de manutenção.
O principal objetivo da manutenção de software é modificar e atua-
lizar o seu aplicativo após a entrega para corrigir falhas e melhorar o 
desempenho dele.
As principais necessidades de manutenção em softwares são exigi-
das para: 
 • corrigir as falhas;
 • melhorar o design;
 • implementar melhorias;
 • incluir interface com outros sistemas.
Pu
re
So
lu
tio
n/
Sh
ut
te
rs
to
ck
Ciclo de vida do software 47
Dentro dessas necessidades, vale ressaltar os tipos de manutenção 
que precisam ser contemplados no plano de manutenção (HIRAMA, 
2011):
Manutenção corretiva
A manutenção corretiva de um software pode ser essencial para 
corrigir alguns erros observados enquanto o sistema está em uso ou 
para aprimorar o desempenho do sistema.
Para exemplificar, suponha que você acabou de lançar o software 
na noite passada, mas recebe a informação de que os usuários não 
conseguem fazer o login com suas credenciais do Facebook. Você con-
tata seu desenvolvedor e descobre que o código de autenticação que 
se comunica com o Facebook tem um pequeno defeito e precisa ser 
atualizado para restaurar a funcionalidade de login.
A manutenção corretiva, também conhecida como manutenção rea-
tiva, emprega esforços na correção de problemas encontrados após a 
entrega do software.
Manutenção adaptativa
Abrange alterações, atualizações e incrementos em função das ne-
cessidades dos usuários que estão em locais em que o produto seja 
executado em novas plataformas, sistemas operacionais e hardwares.
Para exemplificar esse tipo de manutenção, vamos supor que os 
usuários têm feito login com sucesso no sistema há vários dias e as 
coisas estão indo muito bem, mas você descobre que o problema está 
de volta e os usuários não podem mais acessar suas contas. 
Após várias horas de investigação por seu desenvolvedor, você des-
cobre que o Facebook mudou a maneira como você autentica com sua 
API, portanto seu site precisa ser atualizado para oferecer suporte ao 
novo método. 
Seu desenvolvedor passa mais algumas horas atualizando o site 
para suportar o novo método de autenticação do Facebook e tudo vol-
ta ao normal.
Esse problema requer manutenção adaptativa, que é a modificação 
de um produto de software realizada após sua entrega para manter um 
produto de software utilizável em um ambiente alterado ou em mutação.
48 Engenharia de Software
Manutenção para aumento de qualidade
Um software necessita de manutenção de qualidade para entregar 
aos usuários novas experiências, para que ele possa levar encantamen-
to e uma aproximação ainda maior com seu público-alvo.
Seguindo exemplo anterior, o Facebook encerrou suas alterações e 
parou de comprometer o seu site, mas você começa a receber alguns 
comentários de seus usuários depois de mais alguns dias. 
Acontece que, em vez de o usuário ser enviado para o perfil após 
o login, faz mais sentido ver o painel de atividades recentes. Um pedi-
do razoável; você trabalha com seu desenvolvedor e, após uma rápida 
atualização do sistema, os usuários agora são recebidos com as últimas 
ações do produto para que possam estar sempre atualizados.
A manutenção do software em busca de qualidade, que normal-
mente resulta do feedback do usuário, é de extrema importância, pois 
busca atender especificamente às solicitações de quem o utiliza.
O objetivo é garantir que seus usuários fiquem satisfeitos com a 
experiência e continuem usando seu produto como resultado do valor 
agregado com que a manutenção perfectiva contribui. 
Novos recursos e aprimoramentos para recursos existentes não são 
considerados manutenção perfeita. Se o painel de atividades recentes 
não existisse, ele seria um novo recurso em vez de uma manutenção 
perfeita.
Manutenção preventiva
A manutenção preventiva atua para evitar futuros problemas e insa-
tisfações dos usuários. Seu grande objetivo é antecipar o acontecimen-
to de anomalias futuras que trarão prejuízos ao software.
Continuando com o nosso exemplo, temos que, com as mudanças 
em seu sistema (estamos falando muito hipoteticamente aqui), você 
atrai um grande interesse de sua base de usuários e precisa se prepa-
rar para um evento de alto tráfego nos próximos dias. 
Você não tem certeza se o seu servidor pode suportar esse tipo de 
carga, mas sabe que, se o site cair com tanta atenção, você terá muitos 
usuários irritados que podem abandonar o seu produto. 
Assim, você incumbe seu desenvolvedor de proteção contra esse 
desastre, e ele passa um tempo considerável atualizando o ambiente 
de hospedagem para que este seja mais escalonável. 
Ciclo de vida do software 49
Quando muito tráfego atinge um servidor, suas atualizações garan-
tem que novos servidores fiquem on-line automaticamente para lidar 
com o tráfego extra. Não fazia sentido configurar essa infraestrutura 
de escalonamento automático durante o desenvolvimento, mas, agora 
que você precisa dela, é fundamental para o sucesso do seu produto.
Esse esforço é classificado como manutenção preventiva ou modifi-
cação de um produto de software após a entrega para detectar e corrigir 
possíveis falhas no produto de software antes que elas entrem em vigor.
Quanto mais complexo for o software, provavelmente mais manu-
tenção será necessário para garantir o uso contínuo. As perguntas ób-
vias são “por quê” e “quanto”. Isso varia e é um pouco complicado, pois 
cada produto de software é diferente. 
É possível minimizar os custos de manutenção por meio de planeja-
mento e execução inteligentes, mas também pode-se acabar pagando 
mais para manter o produto do que para desenvolvê-lo se o gestor não 
tomar cuidado.
Existem muitos fatores de custo de manutenção de software: ela 
não se trata apenas de consertar bugs; envolve qualquer esforço para 
manter as coisas funcionando da maneira que seus usuários esperam 
que funcione – e, na maioria das vezes, isso significa outra coisa do que 
simplesmente corrigir defeitos em seu código.
Com esta etapa, concluímos o ciclo de desenvolvimento de softwa-
re, processo altamente importante dentro da engenharia de softwa-
re que busca trazer práticas, ferramentas e metodologias eficazes na 
construção, entrega e manutenção dos softwares.
O livro Não me faça 
pensar, de Steve Krug, 
explica que os humanos 
que usam software ou 
sites tendem a aceitar 
a primeira solução que 
lhes é apresentada. Esse 
ponto essencial deve ser 
aproveitado por enge-
nheiros de softwares que 
querem se diferenciar no 
mercado.
O livro se concentra na 
simplicidade, na objeti-
vidade e no bom senso, 
sendo considerado por 
muitos essencial para 
qualquer engenheiro de 
software. A obra ajuda 
os desenvolvedores a