Apostila Análise de Sistemas

Prévia do material em texto

Análise de sistemas
Henrique Pontes Gonçalves de Oliveira
Dados Internacionais de Catalogação na Publicação (CIP)
(Jeane Passos de Souza - CRB 8ª/6189)
Oliveira, Henrique Pontes Gonçalves de
 Análise de sistemas / Henrique Pontes Gonçalves de Oliveira. -- 
São Paulo: Editora Senac São Paulo, 2019. (Série Universitária)
	 Bibliografia.
 e-ISBN 978-85-396-2925-1 (ePub/2019)
 e-ISBN 978-85-396-2926-8 (PDF/2019)
 1. Desenvolvimento de sistemas 2. Gestão de projetos : 
Desenvolvimento de sistemas 3. Planejamento de projetos : 
Desenvolvimento de sistemas 4. Requisitos : Engenharia 5. Lógica de 
programação I. Título. II. Série 
19-998t CDD – 003
 005.13
 BISAC COM051000
 COM051010
Índice para catálogo sistemático:
1. Desenvolvimento de sistemas 003
2. Lógica de programação 005.13
M
at
er
ia
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
ANÁLISE DE SISTEMAS
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
Henrique Pontes Gonçalves de Oliveira
Administração Regional do Senac no Estado de São Paulo
Presidente do Conselho Regional
Abram Szajman
Diretor do Departamento Regional
Luiz Francisco de A. Salgado
Superintendente Universitário e de Desenvolvimento
Luiz Carlos Dourado
M
at
er
ia
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
Editora Senac São Paulo
Conselho Editorial
Luiz Francisco de A. Salgado 
Luiz Carlos Dourado 
Darcio Sayad Maia 
Lucila Mara Sbrana Sciotti 
Jeane Passos de Souza
Gerente/Publisher
Jeane Passos de Souza (jpassos@sp.senac.br)
Coordenação Editorial/Prospecção
Luís Américo Tousi Botelho (luis.tbotelho@sp.senac.br) 
Márcia Cavalheiro Rodrigues de Almeida (mcavalhe@sp.senac.br)
Administrativo
João Almeida Santos (joao.santos@sp.senac.br) 
Comercial
Marcos Telmo da Costa (mtcosta@sp.senac.br)
Acompanhamento Pedagógico
Ana Claudia Neif Sanches Yasuraoka
Designer Educacional
Jackeline Duarte Kodaira
Revisão Técnica
Marcelo Marçula
Colaboração
Ana Paula Pigossi Papalia
Coordenação de Preparação e Revisão de Texto
Luiza Elena Luchini
Preparação de Texto
ASA Comunicação e Design
Revisão de Texto
Mariana Paixão
Projeto Gráfico
Alexandre Lemes da Silva 
Emília Correa Abreu
Capa
Antonio Carlos de Angelis
Editoração Eletrônica
Cristiane Marinho de Souza
Ilustrações
Cristiane Marinho de Souza
Imagens
iStock Photos
E-pub
Ricardo Diana
Proibida a reprodução sem autorização expressa.
Todos os direitos desta edição reservados à
Editora Senac São Paulo
Rua 24 de Maio, 208 – 3o andar 
Centro – CEP 01041-000 – São Paulo – SP
Caixa Postal 1120 – CEP 01032-970 – São Paulo – SP
Tel. (11) 2187-4450 – Fax (11) 2187-4486
E-mail: editora@sp.senac.br 
Home page: http://www.editorasenacsp.com.br
© Editora Senac São Paulo, 2019
Sumário
Capítulo 1
Desenvolvimento de sistemas, 9
1 Sistemas de software: 
definição,	10
2 Desenvolvimento de software 
como um projeto, 15
3 Paradigmas de desenvolvimento: 
estruturado e orientado a 
objeto, 18
Considerações	finais,	23
Referências, 24
Capítulo 2
Ciclo de vida de desenvolvimento 
de sistemas – análise, projeto e 
construção, 27
1 Etapas genéricas de 
desenvolvimento de sistemas, 29
2 Análise de sistemas, 31
3 Projeto de sistemas, 34
4 Construção: criação de módulos e 
banco de dados, integração, 36
Considerações	finais,	40
Referências, 42
Capítulo 3
Ciclo de vida de desenvolvimento 
de sistemas – testes, 
implantação de sistemas e tipos 
de manutenção, 43
1 Tipos de testes, 44
2 Implantação de sistemas, 50
3 Tipos de manutenção, 53
Considerações	finais,	55
Referências, 56
Capítulo 4
Planejamento e gestão de 
projetos, 57
1 Planejamento e gestão de projetos, 
58
2	 Estudo	de	viabilidade:	financeira	e	
técnica, 60
3 Dimensionamento do projeto: 
tempo e recursos, 64
4 Planos de gerenciamento: de 
riscos, de pessoas, da qualidade e 
de	configuração,	66
Considerações	finais,	71
Referências, 73
Capítulo 5
Modelos de desenvolvimento 
de sistemas, 75
1 Modelo sequencial, 76
2 Modelo iterativo, 78
3 Modelo incremental, 83
Considerações	finais,	84
Referências, 86
Capítulo 6
Metodologias de desenvolvimento 
de sistemas, 87
1 Metodologias tradicionais, 89
2 Metodologias ágeis, 91
3 Metodologias de microsserviços, 99
4 DevOps, 101
Considerações	finais,	103
Referências, 104
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
M
at
er
ia
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
Capítulo 7
Requisitos, 107
1	 Requisitos:	definições,	108
2 Requisitos funcionais, 109
3 Requisitos não funcionais, 110
4 Atributos dos requisitos, 112
5	 Documento	de	especificação	de	
requisitos, 114
Considerações	finais,	119
Referências, 120
Capítulo 8
Engenharia de requisitos, 123
1 Análise de sistemas, 124
2 Engenharia de requisitos, 126
3	 Identificação	dos	requisitos,	129
Considerações	finais,	132
Referências, 133
Capítulo 9
Ferramentas de desenvolvimento 
– diagrama de caso de uso, 135
1 Diagrama de caso de uso, 136
Considerações	finais,	148
Referências, 149
Capítulo 10
Ferramentas de desenvolvimento 
– diagrama de classes, 151
1 Diagrama de classes: conceito, 152
2 Principais elementos do diagrama 
de classes, 154
Considerações	finais,	162
Referências, 163
Capítulo 11
Ferramentas de desenvolvimento 
– diagramas de atividades e de 
sequência, 165
1 Diagrama de atividades, 166
2 Diagrama de sequência, 173
Considerações	finais,	179
Referências, 180
Capítulo 12
Lógica de programação – 
estrutura sequencial, 181
1 Representação de algoritmos, 182
2 Estrutura sequencial: 
características, 187
3 Comandos:	início	e	final	de	
programa, entrada e saída de 
dados, 188
4 Variáveis: tipos e declarações, 189
5 Comando de atribuição de 
valores, 191
6 Operadores aritméticos, 192
Considerações	finais,	193
Referências, 195
Capítulo 13
Lógica de programação – 
estrutura de decisão simples e 
aninhada, 197
1 Estrutura de decisão: 
características, 198
2 Operadores relacionais, 198
3 Comandos de decisão: simples e 
aninhada, 199
Considerações	finais,	206
Referências, 206
Capítulo 14
Lógica de programação – estrutura 
de decisão composta, 207
1 Comandos de decisão: condições 
compostas, 208
2 Operadores lógicos, 210
Considerações	finais,	212
Referências, 212
7
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
Capítulo 15
Lógica de programação – 
estrutura de repetição controlada 
por contador, 213
1 Estruturas de repetição: 
características, 214
2 Repetição controlada por 
contador, 214
Considerações	finais,	217
Referências, 218
Capítulo16
Lógica de programação 
– estrutura de repetição 
controlada pelo resultado de 
operação ou pelos dados do 
sistema, 219
1 Estruturas	enquanto/faça/fim- 
-enquanto, 220
2 Pseudocódigo, 221
3 Fluxograma, 221
4 Diagrama de Chapin, 222
5 Estruturas repita/até que, 222
6 Pseudocódigo, 223
7 Fluxograma, 223
8 Diagrama de Chapin, 224
9 Variável acumuladora, 224
10 Marcadores	ou	flag,	225
Considerações	finais,	226
Referências, 227
Sobre o autor, 229
9
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
Capítulo 1
Desenvolvimento 
de sistemas
Ao longo dos últimos 30 anos, os sistemas de software vêm exer-
cendo um papel fundamental e crítico na nossa sociedade. Atualmente, 
eles estabelecem uma dependência em empresas, indivíduos, governo, 
ou seja, em todos os organismos da sociedade moderna. O grau dessa 
dependência está atrelado às características e aos serviços oferecidos 
por sistemas computadorizados. 
10 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
Mas o que são sistemas de software? Como são produzidos? Quais 
são seus principais paradigmas de desenvolvimento? 
Neste capítulo, abordaremos uma breve história dos sistemas de 
software, seus principais conceitos, suas características, os tipos de 
software e suas aplicações. Também vamos abordar como são os pro-
jetos de desenvolvimento de software, as principais atividades e etapas, 
e faremos uma breve conceituação dessas etapas: (1) métricas, (2) es-
timativas, (3) análise de riscos, (4) planejamento e (5) controles.
Por	 fim,	 apresentaremos	 os	 conceitos	 dos	 dois	 principais	 paradig-
mas de programação de software: (1) estruturado e (2) orientado ao 
objeto, considerando seus conceitos e uma comparação básica entre 
eles, abordando suas vantagens e desvantagens e as linguagens apro-
priadas a cada um dos casos. 
1 Sistemas de software: definição
O surgimento dos primeiros sistemas de software ocorreu na déca-
da de 1950; sua evolução foi densa e rápida e, desde então, seu pro-
gresso é constante, continuando a ser a tecnologia mais importante no 
contexto mundial (PRESSMAN, 1995; PRESSMAN, 2016). 
Podemos	classificar	essa	evolução	até	os	tempos	atuais	em	cinco	
eras,	conforme	apresentado	na	figura	1.	
11Desenvolvimento de sistemas
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
Figura 1 – Cronologia da evolução do software
Primeira era1950
Orientação Batch
Distribuição limitada
Software customizado
Segunda era
Multiusuário
Tempo real
Banco de dados
Produto de software
1960
Terceira era1970
Sistemas distribuídos
“Inteligência” embutida
Hardware de baixo custo
Impacto de consumoQuarta era
PCs poderosos
Tecnologia orientada ao objeto
Sistemas especialistas
Redes neurais artificiais
Computação paralela
1980
Quinta era1990
Sistemas abertos
Software baseado em componentes
Wireless
Model Driven DevelopmentTempos atuais
Internet, intranet, groupwares
Computação em nuvem
Tecnologias móveis
Computação ubíqua e pervasiva
2010
Atuais
Fonte: adaptado de Pressman (1995), Albertin (2009), Guerra e Colombo (2009).
A	definição	de	sistemas	 de	software	apresenta	algumas	variações	
de	 acordo	 com	 diferentes	 autores,	 pesquisadores	 ou	 profissionais	 da	
área.	Vejamos	a	seguir	duas	definições:	
São programas de computadores, em suas diversas formas, e a 
documentação associada. Um programa é um conjunto de solu-
ções	algorítmicas,	codificadas	numa	linguagem	de	programação,	
executado numa máquina real. Software é um produto conceitual 
e lógico. (LEITE, 2006)
12 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
São programas de computador e documentação associada, os sis-
temas de software são abstratos e intangíveis, não são restringidos 
pelas propriedades dos materiais e nem governados pelas leis da 
física ou pelos processos de manufatura. (SOMMERVILLE, 2007)
Para	 fins	 didáticos,	 podemos	 considerar	 a	 definição	 de	 Pressman	
como a mais adequada: 
Software são instruções (programas de computador) que, quando 
executadas, produzem a função e o desempenho desejados; es-
truturas de dados que possibilitam que os programas manipulem 
adequadamente a informação; e documentos que descrevem a 
operação e o uso dos programas. (PRESSMAN, 1995)
1.1 Principais características dos sistemas de software
Para que possamos compreender melhor em que consiste um 
software, precisamos analisar suas principais características. No qua-
dro 1, observa-se uma síntese delas.
Quadro 1 – Principais características de um software
CARACTERÍSTICA DESCRIÇÃO
Invisibilidade 
O software é invisível e não 
visualizável.
• A realidade do software não é inerentemente incorporada no espaço. 
• O software não tem representação geométrica pronta, assim 
como a Terra tem mapas, os chips de silício têm diagramas e os 
computadores têm esquemas de conectividade. 
Complexidade 
Softwares são mais complexos 
para seu tamanho do que talvez 
qualquer outra construção 
humana.
• Uma ampliação de uma entidade de software não é apenas uma 
repetição dos mesmos elementos em tamanhos maiores; ampliação 
é necessariamente um aumento no número de elementos diferentes.
• Na maioria dos casos, os elementos interagem entre si de alguma 
forma não linear, e a complexidade do todo aumenta muito mais do 
que linearmente.
(cont.)
13Desenvolvimento de sistemas
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
CARACTERÍSTICA DESCRIÇÃO
Mutabilidade 
A entidade de software está 
constantemente sujeita a 
pressões por mudança.
• Em parte, isso acontece porque o software de um sistema incorpora 
suas funções. E são estas funções que, na maioria dos softwares, 
sofrem constantes pressões por mudança.
• Em parte, é porque o software pode ser mudado mais facilmente, é 
puro material de pensamento, infinitamente maleável.
• Todo o software bem-sucedido é alterado.
• As pressões por mudanças nas funções vêm principalmente de 
usuários que gostam da função básica e criam novos usos.
Conformidade 
O software deve obter 
sua identidade e estar em 
conformidade tão logo seja 
colocado em produção.
• Deve estar em conformidade porque é percebido como o mais 
adaptável. 
• Muita complexidade vem da aceitação para outras interfaces; essa 
complexidade não pode ser simplificada por qualquer redesenho do 
software sozinho.
Inalterabilidade 
O software não se desgasta no 
sentido físico.
• O software não é sensível aos problemas ambientais (ex.: poeira, 
vibrações, excesso de uso, temperatura, etc.), como são os 
hardwares.
• Os softwares se deterioram devido a suas falhas e suas correções 
e melhorias que levam a novas falhas inerentes ao seu tempo de 
utilização. Essas alterações levam a um novo ciclo de erros, ou seja, 
o software está se deteriorando devidoàs mudanças.
Reusabilidade 
O componente de um software 
deve ser projetado de forma 
que possa ser utilizado em 
programas diferentes.
• O desenvolvimento de um software, na sua maioria, é realizado 
utilizando “componentes”. 
• Esses componentes podem ser algoritmos de rotinas, sub-rotinas, 
interfaces, estrutura de banco de dados, entre outros.
• Os softwares são armazenados no que chamamos de “bibliotecas”. 
Fonte: adaptado de Brooks Jr. (1986) e Pressman (1995).
1.2 Principais atributos de um sistema de software
Um sistema de software deve ter um conjunto de atributos especí-
ficos	de	acordo	com	sua	aplicação.	Sommerville	(2007)	define	quatro	
atributos	essenciais	de	um	sistema	profissional	de	software:	(1)	manu-
tenibilidade,	(2)	confiança	e	proteção,	(3)	eficiência	e	(4)	aceitabilidade.
14 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
Quadro 2 – Principais atributos de um software
ATRIBUTOS DESCRIÇÃO
Manutenibilidade
O software deve ser escrito de forma que possa evoluir para atender às 
necessidades dos clientes. Esse é um atribulo crítico, porque a mudança de 
software é um requisito inevitável de um ambiente de negócios em mudança.
Confiança e proteção
A confiança do software inclui uma série de características como 
confiabilidade, proteção e segurança. Um software confiável não deve causar 
prejuízos físicos ou econômicos no caso de falha de sistema. Usuários 
maliciosos não devem ser capazes de acessar ou prejudicar o sistema.
Eficiência
O software não deve desperdiçar os recursos do sistema, como memória e 
ciclos do processador. Portanto, a eficiência inclui capacidade de resposta, 
tempo de processamento, uso de memória, etc.
Aceitabilidade
O software deve ser aceitável para o tipo de usuário para o qual foi projetado. 
Isso significa que deve ser compreensível, usável e compatível com outros 
sistemas usados por ele.
Fonte: adaptado de Sommerville (2007).
1.3 Principais tipos de softwares
Atribuir tipos para as aplicações de software se tornou uma tarefa 
complicada, pois conforme a complexidade do software aumenta, de-
saparecem as suas divisões em compartimentos. Pressman (2016) in-
dica os seguintes tipos de softwares e suas principais características:
a. Software de sistema.
b. Software de aplicação.
c. Software	científico	e	de	engenharia.
d. Software embarcado.
e. Software para linha de produtos.
f. Aplicações web/aplicativos móveis. 
g. Software	de	inteligência	artificial.
15Desenvolvimento de sistemas
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
PARA SABER MAIS 
Recomendamos a leitura da obra Engenharia de software: uma aborda-
gem profissional, de Roger S. Pressman, 8ª edição, páginas 6 e 7, para 
consultar as principais características sobre os principais tipos de 
software listados.
 
2 Desenvolvimento de software como 
um projeto
Conceitualmente,	 projeto	 significa	 um	 empreendimento,	 ou	 seja,	
é um trabalho que tem como objetivo a criação de um produto, neste 
caso, um software, envolvendo um esforço temporário e não repetitivo e 
um determinado grau de incerteza na sua realização. Esse trabalho nor-
malmente é executado por pessoas e está condicionado a prazo, custo, 
escopo e qualidade, como qualquer empreendimento. Essas atividades 
precisam ser planejadas, programadas, monitoradas e controladas. De 
acordo com Martins (2002) e Fernandes (1995), um projeto de software 
é a junção dos seguintes itens: 
Objetivos + Atividades + Prazos + Recursos envolvidos + Riscos e incertezas
No desenvolvimento de um software, a maioria das questões são 
inerentemente	 de	 qualificação.	 Nesse	 sentido,	 é	 necessário	 fazer	 as	 
seguintes perguntas: “Quais são os requisitos?”, “Qual é a técnica de pro-
gramação e teste?”. Porém, os problemas do desenvolvimento do software 
não	 são	 exclusivamente	 de	 qualificação.	 Existem	 também	 inúmeras	
questões quantitativas como: “Quanto tempo levará o desenvolvimento?”, 
“Quanto dinheiro será despendido?”, “Qual será o risco?”.
Para um gerente de projeto de desenvolvimento de software, normal-
mente as questões quantitativas são as mais preocupantes e as mais 
16 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
urgentes.	O	gerenciamento	eficaz	dos	parâmetros	quantitativos	de	um	
projeto resulta em controle (DE MARCO, 1989).
PARA PENSAR 
“Se você não pode medir, não pode gerenciar” – frase de Peter Drucker, 
considerado o pai da administração moderna. Nascido na Áustria, em 
1909, Peter Ferdinand Drucker foi escritor, professor, consultor e trouxe 
uma nova perspectiva no âmbito da gestão.
 
A gestão de projetos representa a primeira camada do processo de 
engenharia de software, ou seja, abrange todo o processo de seu desen-
volvimento. Para conduzir um projeto de software de sucesso, devemos 
conhecer o escopo do trabalho a ser feito, os riscos que podem ocorrer, 
os recursos adequados, as tarefas a serem executadas, os principais 
marcos de entrega a serem acompanhados, o esforço planejado e reali-
zado e o plano a ser cumprido (PRESSMAN, 1995). 
O gerenciamento de projeto de desenvolvimento de software com-
preende as seguintes atividades: (1) medição, (2) estimativa, (3) análise 
de riscos, (4) programação de atividades e (5) monitoramento e controle.
2.1 Medição
O processo é medido em um esforço para melhorá-lo e garantir sua 
qualidade. A medição do software é efetuada por diferentes razões, a 
saber: (1) indicar a qualidade do produto; (2) avaliar a produtividade das 
pessoas que produzem o produto; (3) avaliar os benefícios derivados de 
novos métodos e ferramentas de software; (4) formar uma linha básica 
para	estimativas;	(5)	ajudar	a	justificar	os	pedidos	de	novas	ferramentas	
ou treinamento adicional.
17Desenvolvimento de sistemas
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
2.2 Estimativa
A estimativa é um componente da atividade de planejamento do pro-
jeto. No planejamento de desenvolvimento de um software deve conter 
as principais estimativas: esforço humano exigido, duração cronológica 
do projeto e custos.
2.3 Análise de riscos
A análise de riscos refere-se ao levantamento e à administração dos 
riscos envolvidos durante todo o projeto de desenvolvimento de softwa-
re. A análise de riscos é um processo que deve ser descrito para que 
se possa agir quando o risco acontece. Deve-se atribuir a cada risco 
levantado	a	sua	identificação,	a	estratégia	de	resposta,	a	prioridade,	a	
probabilidade de sua ocorrência e seus impactos. 
2.4 Programação de atividades
A	programação	de	atividades	é	a	definição	das	tarefas	que	devem	
ser executadas ao longo do desenvolvimento do software. Devem ser 
atribuídos para cada tarefa: prazos, responsáveis, recursos e sua inter-
dependência com outras tarefas.
2.5 Monitoramento e controle
As atividades de monitoramento e controle são estabelecidas quando 
a programação do projeto se inicia. Essa atividade normalmenteé realiza-
da pelo gerente do projeto, muitas vezes por meio de ferramentas de con-
trole.	Cada	tarefa	definida	na	programação	é	monitorada	para	que	ocorra	
dentro do esperado, considerando prazo, custo, escopo e qualidade. Caso 
a tarefa não seja cumprida de acordo com sua programação, ações de-
vem ser tomadas pelo gerente do projeto, como reorganizar tarefas, redi-
recionar recursos, entre outras.
18 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
3 Paradigmas de desenvolvimento: 
estruturado e orientado a objeto
De acordo com o dicionário Michaelis da Língua Portuguesa (2014), 
o termo “paradigma” refere-se a algo que serve de exemplo ou modelo; 
padrão. Analogamente, paradigmas de desenvolvimento de software 
são padrões de resolução problemas que se relacionam a determina-
dos gêneros de programas e linguagens (TUCKER; NOONAN, 2009). 
3.1 Paradigma de desenvolvimento estruturado
Antes de 1975, a maior parte das empresas de software não utiliza-
va	nenhuma	técnica	 específica;	cada	 indivíduo	trabalhava	do	seu	pró-
prio jeito. Grandes avanços foram feitos aproximadamente entre 1975 
e 1985, com o desenvolvimento do assim chamado paradigma clássico 
ou estruturado (SCHACH, 2010). 
Para Schach (2010), no início de sua utilização, essas técnicas sur-
giram de forma intensa e promissoras, porém, com o surgimento de 
softwares	cada	vez	maiores	e	complexos,	algumas	dificuldades	come-
çaram a se manifestar, principalmente na manutenção pós-produção 
do produto de software. Outra limitação importante do paradigma estru-
turado reside no fato de que suas técnicas são orientadas a operações 
ou a atributos (dados), mas não às duas ao mesmo tempo, pois os com-
ponentes fundamentais do produto de software são as operações dos 
produtos e os atributos sobre os quais essas operações agem, ou seja, 
têm como foco principal a operação e as transformações dos dados. 
Basicamente, o paradigma de desenvolvimento estruturado é com-
posto de quatro técnicas principais: (1) análise de sistemas estruturada, 
(2)	análise	de	fluxo	de	dados,	(3)	programação	estruturada	e	(4)	testes	
estruturados. A seguir, vamos detalhar um pouco mais sobre a progra-
mação estruturada de software.
19Desenvolvimento de sistemas
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
3.1.1 Programação estruturada
A programação estruturada determina uma técnica do desenvol-
vimento estruturado de software que facilita o entendimento de pro-
gramas por meio de um número limitado de mecanismos básicos de 
verificação	 da	 execução	 de	 programas.	 Qualquer	 software,	 indepen-
dentemente de sua complexidade, de sua aplicação e da linguagem de 
programação	na	qual	será	codificado,	pode	ser	desenvolvido	por	meio	
desses mecanismos básicos.
O princípio básico de programação estruturada é que um programa é 
composto de blocos elementares de código que se interligam por meio 
de três mecanismos básicos, que são: 
(1) Sequência
(2) Seleção
(3) Iteração (repetição)
Cada uma dessas construções tem um ponto de início (o topo do 
bloco)	 e	 um	 ponto	 de	 término	 (o	 fim	 do	 bloco)	 de	 execução	 (BRAGA;	
RICARTE,	2005).	A	seguir,	confira	detalhes	sobre	as	definições	básicas	
de cada mecanismo.
 • Sequência: nesse mecanismo são implementadas as etapas de 
processamento essenciais para descrever uma funcionalidade 
específica.	 Um	 exemplo	 básico	 seria	 um	 fluxograma,	 em	 que	 é	
executada	a	“etapa	1”	e,	após	a	sua	finalização,	a	“etapa	2”	é	ini-
ciada, e assim sucessivamente.
 • Seleção:	 é	 o	 mecanismo	 em	 que	 um	 fluxo	 a	 ser	 percorrido	 de-
pende de uma escolha. Existem duas formas básicas para essa 
escolha: utilização das condicionais “se” e “senão”.
20 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
 • Iteração: é a execução de comandos de forma repetida em que, 
ao	final	de	cada	execução,	a	condição	é	reexaminada	e	enquanto	
seja considerada verdadeira a execução do programa continua.
No quadro 3, podemos observar as principais características da pro-
gramação estruturada:
Quadro 3 – Principais características da programação estruturada
PARADIGMA PRINCIPAIS VANTAGENS PRINCIPAIS DESVANTAGENS LINGUAGENS
Estruturado
• Os problemas podem 
ser desmembrados em 
vários subproblemas.
• Boa legibilidade.
• Os dados são separados das 
funções.
• Mudanças na estrutura dos 
dados acarretam alteração em 
todas as funções relacionadas.
• Gera sistemas difíceis de serem 
mantidos.
• “C”
• Basic
• Cobol
• Pascal
3.2 Paradigma de desenvolvimento orientado a objeto
O paradigma de desenvolvimento orientado a objetos considera 
igualmente importantes tanto os atributos quanto as operações. Uma 
maneira simplista de compreender um objeto é vê-lo como um artefato 
de	software	unificado	que	incorpora	tanto	os	atributos	quanto	as	opera-
ções realizadas sobre os atributos (SCHACH, 2010). 
As principais características do paradigma de desenvolvimento 
orientado a objeto são:
 • Detalhes de como os atributos de um objeto são armazenados 
não são conhecidos externamente ao objeto. 
 • A manutenção pós-produção é mais rápida e fácil, pois é efetuada 
por objetos. A chance de aparecerem erros de regressão é muito 
reduzida.
21Desenvolvimento de sistemas
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
 • O desenvolvimento também é bem facilitado devido ao objetivo 
ter uma equivalência com um produto físico. Essa característica 
de um objeto e seu equivalente no “mundo real” deriva na produ-
ção de softwares de melhor qualidade.
 • Os objetos projetados são unidades independentes, pois tanto os 
atributos como suas operações são incluídos no mesmo objeto. 
Se todas as operações realizadas nos atributos de um objeto fo-
rem incluídas nesse mesmo objeto, então ele pode ser considera-
do uma entidade conceitualmente independente. 
 • O paradigma orientado ao objeto reduz o nível de complexidade 
de um produto de software, pois produz unidade menores e inde-
pendentes;	consequentemente,	simplifica	o	desenvolvimento	e	a	
manutenção.
 • A reutilização é um ponto forte no uso do paradigma orientado a 
objeto. Como os objetos são entidades independentes, eles po-
dem ser utilizados em novos produtos de software.
A seguir, vamos detalhar um pouco mais sobre a programação orien-
tada a objeto de software.
3.2.1 Programação orientada a objeto
A programação orientada a objeto (POO) fornece um modelo no 
qual um programa é uma coleção de objetos que interagem entre si, 
passando mensagens que transformam seu estado. Nesse sentido, a 
passagem de mensagens permite que objetos de dados se tornem ati-
vos. Essa característica ajuda a distinguir melhor a POO das demais. A 
classificação	de	objetos,	a	herança	e	a	passagem	de	mensagens	são	
componentes fundamentais da POO (TUCKER; NOONAN, 2009). 
22 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
ação
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
O paradigma orientado a objeto é fundamentado em quatro pilares 
principais: (1) abstração, (2) encapsulamento, (4) herança e (5) polimor-
fismo.	 Esses	 quatro	 pilares	 são	 essenciais	 no	 entendimento	 de	 qual-
quer linguagem orientada a objetos.
No quadro 4, podemos observar as principais características da pro-
gramação orientada a objetos.
Quadro 4 – Principais características da programação orientada a objetivos
PARADIGMA PRINCIPAIS VANTAGENS PRINCIPAIS DESVANTAGENS LINGUAGENS
Orientado a 
objetos – POO
• Alteração de um módulo 
não incorre na modificação 
de outros módulos.
• Quanto mais um módulo 
for independente, maior a 
chance de reutilização em 
outra aplicação.
• Bem estabelecido.
• Flexível e eficiente.
• Exige formas de pensar 
relativamente complexas, 
de difícil compreensão se 
comparado ao estruturado.
• Pode possuir baixo 
desempenho se comparado 
a códigos estruturados 
similares.
• Smalltalk
• Python
• Ruby
• C++ 
• Object Pascal
• Java
• C#
• Oberon
• Ada
• Eiffel
• Simula 
• NET
3.3 Comparativo entre os paradigmas estruturado e 
orientado a objetos
Uma	 diferença	 significativa	 entre	 os	 dois	 paradigmas	 de	 desenvolvi-
mento está no ciclo de vida de desenvolvimento. No projeto estruturado, 
o processo passa uma única vez por cada etapa (salvo a necessidade de 
manutenção), de forma única para todo o produto, tornando a transição 
entre cada etapa mais trabalhosa. No ciclo de vida do projeto orientado 
por objetos, o processo passa por todas as etapas de cada objeto a ser de-
senvolvido, sendo mais suave a transição entre as etapas, tornando mais 
ágil o desenvolvimento do produto. No próximo capítulo, será estudado, de 
forma mais detalhada, o ciclo de desenvolvimento de um sistema. 
23Desenvolvimento de sistemas
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
De	 qualquer	 forma,	 os	 paradigmas	 não	 devem	 ser	 classificados	
como “melhor” ou “pior”, “certo” ou “errado”. Cada paradigma determina 
uma forma particular de abordar os problemas e de formular respecti-
vas soluções, possibilitando a escolha do paradigma mais adequado 
para analisar e resolver cada problema. Ambos os paradigmas têm 
suas vantagens e desvantagens. 
Considerações finais
Neste capítulo, vimos que um sistema de software é um produto 
complexo e sua evolução, desde seu surgimento até os dias atuais, foi 
relativamente	rápida.	Sua	definição	pode	ser	apresentada	de	várias	for-
mas,	da	mais	simples	à	mais	complexa,	dependendo	da	sua	finalidade,	
do	 tipo	 e	 da	 quantidade	 de	 componentes	 utilizados.	 Verificamos	 que	
existe uma grande quantidade de tipos de sistemas de software, de di-
fícil categorização, a qual depende de sua aplicabilidade e seu objetivo, 
que vão desde softwares básicos para simples operações a sistemas 
complexos de engenharia, sistemas gerenciais e funcionais a sistemas 
de	inteligência	artificial.	Devido	ao	software	ser	um	produto	não	físico,	
suas principais características se baseiam em propriedades de difícil 
tangibilidade. Um software de alta qualidade tem que garantir pelo me-
nos quatro atributos: (1) facilidade na sua manutenção, (2) segurança, 
(3)	eficiência	e	(4)	aceitação	pelo	usuário/cliente.			
O gerenciamento de um projeto de desenvolvimento de software é 
uma atividade complexa e composta de cinco etapas principais: (1) de-
finição	de	métricas	de	controle,	(2)	estimativas	das	atividades,	(3)	análi-
se dos possíveis riscos conhecidos e desconhecidos, (4) planejamento 
das atividades e plano de respostas aos riscos mapeados e (5) contro-
le e monitoramento de todas as tarefas para que sejam realizadas de 
acordo com o planejamento, as atividades e as respostas aos riscos. 
24 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
Vimos também que o desenvolvimento de um software pode ser 
concebido, principalmente, por meio de dois paradigmas: (1) o modelo 
estruturado e (2) o orientado a objeto. Ambos os paradigmas apresen-
tam vantagens e desvantagens, sendo possível inferir que um paradig-
ma não seja “melhor” que o outro. O melhor paradigma é aquele que se 
adapte à linguagem de programação utilizada, ao conhecimento do pro-
gramador	e,	principalmente,	à	finalidade	do	software	a	ser	desenvolvido.	
Referências
ALBERTIN, Alberto L. Administração de informática: funções e fatores críticos 
de sucesso. 6. ed. São Paulo: Atlas, 2009.
BRAGA, Denise B.; RICARTE, Ivan L. M. Letramento e tecnologia. Projeto 
Linguagem e letramento. CEFIEL/IEL/Unicamp: Campinas, 2005.
BROOKS JR., Frederick P. No silver bullet: essence and accidents in software 
engineering. IEEE Computer, 1987.
DEMARCO, Tom. Controle de projetos de software: gerenciamento, avaliação, 
estimativa. Rio de Janeiro: Campus, 1989.
FERNANDES, Aguinaldo A. Gerência de software através de métricas: garan-
tindo a qualidade do projeto, processo e produto. São Paulo: Atlas, 1995.
GUERRA, Ana C.; COLOMBO, Regina M. T. Tecnologia da Informação: qualidade 
de produto de software. Brasília: PBQP Software, 2009.
JÉZÉQUEL, J.-M.; MEYER, B. Design by contract: the lessons of Ariane. 
Computer, v. 30, n. 1, p. 129-130, 1997.
LEITE, Jair C. Engenharia de software: ciclos de vida. Universidade do Rio 
Grande do Norte, 2006.
MARTINS, José Carlos Cordeiro. Gestão de projetos de desenvolvimento de 
software: PMI-UML. Rio de Janeiro: Brasport, 2002.
MICHAELIS Dicionário prático da língua portuguesa. 2. ed. São Paulo: 
Melhoramentos, 2014. 
25Desenvolvimento de sistemas
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
MONTEALEGRE, Ramiro; KEIL, Mark. De-escalating information technology pro-
jects: lessons from the Denver International Airport. Mis Quarterly, p. 417-447, 
2000.
PRESSMAN, S. Roger. Engenharia de software. 3. ed. São Paulo: McGraw-Hill, 
1995.
______. Engenharia de software:	 uma	 abordagem	 profissional.	 8.	 ed.	 Rio	 de	
Janeiro: McGraw-Hill, 2016.
SCHACH, Stephen R. Engenharia de software: os paradigmas clássico e orien-
tado a objetos. 7. ed. Porto Alegre: AMGH Editora, 2010.
SOMMERVILLE, Ian. Engenharia de software. 8. ed. São Paulo: Pearson 
Addison-Wesley, 2007.
TUCKER, Allen; NOONAN, Robert. Linguagens de programação: princípios e pa-
radigmas. 2. ed. Rio de Janeiro: McGraw-Hill, 2009.
27
Capítulo 2
Ciclo de vida de 
desenvolvimento 
de sistemas – 
análise, projeto e 
construção
 O estudo do ciclo de desenvolvimento de sistemas surgiu em 
meados dos anos de 1960. Trata-se de um modelo sequencial de eta-
pas dispostas em degraus, também conhecido como “modelo cascata” 
de desenvolvimento de software. Genericamente, esse ciclo é compos-
to de seis etapas principais – (1) análise, (2) projeto de sistemas, (3) 
construção, (4) testes, (5) implantação e (6) manutenção – e cada uma 
delas é composta de várias atividades. 
Cada etapa produz um produto ou insumo que é a entrada da eta-
pa seguinte, a qual se inicia com a finalização da anterior. Em qualquer 
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educaçãoa Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
28 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
etapa do processo, pode-se voltar a alguma etapa anterior, conforme 
necessário, lembrando da necessidade de refazer as etapas seguintes 
até o ponto da pertinência de retrocesso.
Cada etapa cumpre um objetivo no processo de desenvolvimento de 
um software. Nasce, basicamente, na análise da necessidade, seguindo 
pela definição do projeto, sua construção ou codificação, na realização 
dos testes e finaliza-se com a implantação e manutenção do produto.
 Neste capítulo, vamos apresentar, de forma genérica, as seis prin-
cipais etapas e abordar, com mais detalhes, as três primeiras etapas 
desse ciclo: (1) análise, (2) projeto e (3) construção, destacando seus 
objetivos e suas principais características.
A etapa da análise consiste em dois grupos de atividades principais: 
(1) a análise de sistemas ou engenharia de sistemas e (2) a análise de 
requisitos. Na análise de sistemas, basicamente, é efetuada a identifica-
ção da melhor solução para atender à necessidade do cliente por meio 
de diversos estudos, viabilidade técnica e econômica, atribuição de fun-
ções aos componentes do sistema (principalmente hardware, software, 
base de dados e pessoas) e o estabelecimento de restrições de custos 
e prazo (PRESSMAN, 1995). Já análise de requisitos será estudada com 
mais profundidade nos capítulos 7 e 8.
Na etapa de projeto, inicia-se a parte técnica do desenvolvimento da 
aplicação, que consiste na elaboração da especificação técnica do sis-
tema, composta, principalmente, de definições da estrutura de dados, 
de procedimentos de processamento, de arquitetura de software e de 
interfaces. 
Concluída a etapa do projeto, é gerado um documento de especifica-
ção, que é a entrada para o início da construção do sistema. Na etapa de 
construção, são tratados os conceitos de criação dos módulos do siste-
ma e banco de dados e o processo de integração de seus componentes, 
explorando seus principais tipos, suas características e sua usabilidade.
29Ciclo de vida de desenvolvimento de sistemas – análise, projeto e construção
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
1 Etapas genéricas de desenvolvimento de 
sistemas
Conforme mencionado, o ciclo de vida de desenvolvimento de 
software contém seis etapas principais, que são: (1) análise, (2) projeto 
de sistemas, (3) construção, (4) testes, (5) implantação e (6) manuten-
ção, as quais estão contidas em um ciclo de vida tradicional ou clássico, 
também conhecido como “modelo cascata”. Vale ressaltar que, de acor-
do com a necessidade, pode-se voltar a qualquer etapa, cumprindo as 
etapas subsequentes novamente e, por esse motivo, utiliza-se o termo 
“ciclo”. Para Pressman (2010), esse modelo propõe um tratamento se-
quencial e ordenado para o desenvolvimento de um software.
O modelo cascata surgiu em meados dos anos 1960, consolidando-
-se nos anos 1970, e é considerado um grande avanço nas atividades 
de desenvolvimento de um software. Os programas se tornaram mais 
claros, escritos mais rapidamente e mais fáceis de modificar (TENÓRIO; 
VALLE, 2013). Na figura 1, é apresentado o modelo de ciclo de vida clás-
sico ou “modelo cascata”.
Figura 1 – Modelo de ciclo de vida clássico
Análise
Projeto
Construção
Testes
Implantação
Manutenção
Fonte: adaptado de Pressman (2010), Audy e Prikladnicki (2007).
30 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
1.1 Análise
A etapa de análise é constituída, basicamente, de duas grandes ati-
vidades: (1) a análise de engenharia de sistemas ou, simplesmente, 
análise de sistemas, e (2) a análise de requisitos de software (que será 
estudada nos capítulos 7 e 8). 
A análise de sistemas abrange todos os elementos do sistema e não 
apenas no software, principalmente no levantamento das necessidades 
do cliente, no estudo de viabilidade técnica e econômica do desenvolvi-
mento, nas propostas de alternativas para a solução e nas atribuições 
de funções aos componentes do sistema.
1.2 Projeto
O projeto de software é um processo composto de várias atividades 
e é a primeira etapa do núcleo técnico no processo de desenvolvimento 
do software. Nessa etapa, são elaboradas as especificações da solução 
proposta e definida na etapa de análise. 
1.3 Construção
A etapa de construção inicia-se após a conclusão da etapa de proje-
to. Na etapa de construção, são executadas as atividades de programa-
ção, criação de módulos, banco de dados, integração de componentes, 
codificação, entre outras especificações definidas na etapa do projeto. 
A codificação é o processo que transforma o programa escrito em uma 
determinada linguagem em uma forma legível de entendimento pelo 
hardware, conhecida como “linguagem de máquina”.
31Ciclo de vida de desenvolvimento de sistemas – análise, projeto e construção
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
1.4 Teste
O processo de realização de testes concentra-se nos aspectos ló-
gicos internos do software, garantindo que todas as instruções recebi-
das tenham sido testadas de acordo com os resultados esperados. A 
realização dos testes também visa buscar defeitos de função, lógica, 
implementação, como também sua relação com outros componentes 
da solução. Normalmente, os testes devem ser realizados em ambiente 
exclusivo similar ao de produção.
1.5 Implantação
A implantação é a etapa em que o software é instalado no hardware 
em ambiente de produção e disponibilizado para o cliente solicitante e 
seus usuários. Nessa etapa, são realizadas todas as conexões (inter-
faces) com outros sistemas, hardwares, base de dados, conforme as 
especificações; também são realizadas importações ou migrações de 
dados, quando necessário.
1.6 Manutenção
A manutenção é a atividade realizada após a implantação do softwa-
re em produção. As atividades de manutenção decorrem sob demanda 
em consequência de erros e falhas não detectados na fase de testes, 
especificações interpretadas de forma incorreta, novas funcionalidades, 
entre outras necessidades de alterações. 
2 Análise de sistemas
A análise de sistemas é a atividade que compõe a maior parte das 
atividades de entendimento do problema até a sua respectiva solução. 
32 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
Nessa etapa, é estabelecida a solução mais viável para atender às ne-
cessidades da solução. São identificadas as necessidades funcionais eos requisitos técnicos para todos os componentes do sistema. Essa vi-
são de sistemas é essencial quando o sistema deve fazer interface com 
outros elementos, como hardware, pessoas e banco de dados. 
Segundo Pressman (1995), os principais objetos da etapa de análise 
de sistemas são: 
1. a identificação da necessidade do sistema;
2. a avaliação da concepção do sistema quanto à sua realização; 
3. a realização da análise da viabilidade econômica e técnica; 
4. a atribuição das funções ao hardware, ao software, às pessoas, ao 
banco de dados e aos demais elementos do sistema; e, por fim, 
5. o estabelecimento das restrições de prazo e de custo.
2.1 Identificação da necessidade do sistema
Identificar a necessidade do sistema é o primeiro passo do processo 
de análise de sistemas. Nessa etapa é que o analista ou engenheiro 
de software se reúne com o cliente solicitante do produto. Esse cliente 
pode ser formado por gerentes do cliente, usuários finais, fornecedores, 
ou seja, todos os principais envolvidos e impactados pelo novo sistema.
Nessa etapa, deve-se definir, primeiramente, as informações gerais 
do sistema: quais informações serão produzidas e devem ser forneci-
das, quais funções deverão ter o sistema, o desempenho esperado, en-
tre outras. Essa atividade não é trivial como parece e, portanto, deve 
ser efetuada com muita cautela e exaustivamente por meio de várias 
“rodadas” de conversas. O principal problema encontrado nessa fase 
é a comunicação, ou seja, o entendimento entre o analista e o cliente.
33Ciclo de vida de desenvolvimento de sistemas – análise, projeto e construção
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
2.2 Avaliação da concepção do sistema quanto à sua 
viabilidade
Nesta etapa, são efetuados os estudos de viabilidade econômica, 
técnica, legal e a análise de alternativas. Na viabilidade econômica, é 
avaliado o custo do desenvolvimento comparado aos benefícios ge-
rados pelo novo sistema. Na viabilidade técnica, é verificado se o am-
biente tecnológico da organização (hardware, software e pessoas) está 
preparado para receber o novo produto, e, na viabilidade legal, deve ser 
feita uma investigação, principalmente sobre restrições legislativas e 
contratuais. Nessa etapa, também deve ser realizada uma avaliação so-
bre alternativas para o desenvolvimento do software, levando em consi-
deração as inviabilidades identificadas para a solução inicial. 
2.2.1 Análise da viabilidade econômica
A análise econômica é basicamente a realização do estudo da via-
bilidade econômica do produto. Trata-se de um estudo de custo x be-
nefício, ou seja, efetuar o levantamento dos custos diretos e indiretos 
para o desenvolvimento e confrontá-los com todos os benefícios que 
o sistema proporcionará. Esse resultado deve ser avaliado pela orga-
nização, levando em consideração seu planejamento estratégico. Esse 
estudo também não é trivial, pois existem muitos critérios que variam 
de acordo com o sistema solicitado e seus benefícios, muitas vezes, 
são intangíveis, sendo necessária uma avaliação subjetiva. 
2.2.2 Análise da viabilidade técnica
Na análise da viabilidade técnica, devem ser levantadas as tecno-
logias, os recursos necessários, as metodologias, os processos e os 
algoritmos que serão utilizados, deve ser efetuada a análise de riscos 
relacionados e avaliada o quanto essas questões tecnológicas impac-
tam no custo final do desenvolvimento do sistema. 
34 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
2.3 Atribuição das funções ao hardware, ao software, às 
pessoas, ao banco de dados e aos demais elementos do 
sistema
Nessa etapa, são atribuídas as funções a cada elemento do sistema, 
principalmente ao hardware, ao software, às pessoas, ao banco de da-
dos e a outros componentes associados, com suas características de 
desempenho e interface exigidas.
2.4 Restrições de prazo e de custo
No projeto de desenvolvimento de software devem ser estabelecidas 
algumas restrições, dentre elas, as mais importantes são as de prazo 
e custo. Essas restrições servem para fixar uma meta de desenvolvi-
mento; são estabelecidas de acordo com o planejamento estratégico 
da organização e são consideradas métricas e estimativas no gerencia-
mento do projeto.
3 Projeto de sistemas
Uma boa definição para projeto de sistemas surgiu nos anos 1950, 
porém segue uma definição clara, objetiva e muito atual: “[...] o processo 
de se aplicar várias técnicas e princípios ao propósito de se definir um 
dispositivo, um processo ou um sistema com detalhes suficientes para 
permitir sua realização física” (TAYLOR, 1959). 
A etapa do projeto é a primeira da fase técnico-central do processo 
de desenvolvimento de software e suas atividades iniciam tão logo a 
etapa de análise de sistema é finalizada. A importância da fase de proje-
to está diretamente relacionada à qualidade do sistema. 
35Ciclo de vida de desenvolvimento de sistemas – análise, projeto e construção
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
Essa etapa concentra a especificação de quatro atributos: 
1. Estrutura de dados
2. Procedimentos
3. Arquitetura de software
4. Definição de interfaces
No quadro 1, há a descrição dos elementos que compõem o projeto 
de software.
Quadro 1 – Elementos que compõem o projeto de software
ATRIBUTO DEFINIÇÃO E CARACTERÍSTICAS
Estrutura de dados
Representação do 
relacionamento lógico 
entre elementos de dados 
individuais. 
Em conjunto com a estrutura de programa, é essencial para a definição da 
arquitetura de software.
Impacta diretamente o projeto procedimental final.
Estabelece organização, métodos de acesso, grau de associatividade e 
alternativas do processamento dos dados.
Existem vários métodos para a organização de dados, porém é importante 
compreender os métodos clássicos e os conceitos fundamentais das 
hierarquias de informação. 
Procedimentos
Hierarquia de controle 
relacionada à sequência de 
processamentos.
Tem como objetivo descrever em detalhes a operação de cada elemento 
do software individualmente.
Focaliza nos detalhes do processamento de cada módulo 
individualmente.
Especifica processamento, sequência de eventos, pontos de decisão, 
operações repetitivas e organização de dados.
Sua representação é disposta em camadas.
Arquitetura de software
É a estrutura ou a organização 
de componentes de programa
Define como esses componentes interagem e a estrutura de dados que 
são utilizadas por esses componentes.
Indica as duas características mais importantes do software: (1) a 
estrutura hierárquica dos componentes procedimentais e (2) a estrutura 
de dados.
Resulta de um processo de divisão em partições que relaciona 
componentes do software a questões levantadas na análise de requisitos.
(cont.)
36 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
ATRIBUTO DEFINIÇÃO E CARACTERÍSTICAS
Interfaces
Representa o fluxo de 
informaçãoque entram e saem 
de um sistema.
Define como são transmitidos os dados entre os componentes definidos 
na arquitetura.
No projeto de interface, temos três tipos essenciais de interface:
interface com o usuário,
interfaces externas para outros sistemas ou dispositivos,
interfaces internas entre vários componentes do sistema.
Fonte: adaptado de Pressman (2010) e Pressman (2016).
Após a conclusão da etapa do projeto, deve ser elaborado um do-
cumento de especificação do projeto. Não existe um padrão para a re-
dação desse documento, pois isso depende da metodologia utilizada. 
Porém todas as definições sobre o projeto devem estar contidas nesse 
documento, detalhadamente, de forma a ser possível iniciar a etapa de 
construção do sistema.
4 Construção: criação de módulos e banco 
de dados, integração
4.1 Modularidade 
A concepção da modularidade na construção de software é utilizada 
desde a década de 1960 como uma solução aos softwares “monolíti-
cos”, os quais apresentavam dificuldades de compreensão e em suas 
atividades de manutenção. 
Na criação de módulos, o software é segmentado em componentes 
nomeados e direcionados, que são integrados para atender aos requi-
sitos estabelecidos. São considerados três tipos de módulos dentro da 
estrutura de um programa, conforme descritos no quadro 2.
37Ciclo de vida de desenvolvimento de sistemas – análise, projeto e construção
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
Quadro 2 – Tipos de módulo
TIPO DE MÓDULO DESCRIÇÃO
Módulo sequencial
O módulo sequencial é consultado e executado 
sem interrupção pelos aplicativos.
Módulo incremental
O módulo incremental pode ser interrompido antes da sua conclusão e 
retomado no ponto de sua interrupção.
Módulo paralelo
O módulo paralelo é executado simultaneamente com outros módulos em 
ambientes com multiprocessadores.
Fonte: adaptado de Pressman (2010).
A modularidade dispõe de resultados positivos em curto prazo, pois, 
ao segregar um problema maior em problemas menores, as respecti-
vas soluções serão identificadas com um esforço relativamente menor. 
Porém, quanto maior o número de módulos criados no desenvolvimen-
to do sistema, maior será a quantidade de interfaces entre os módulos 
a serem desenvolvidas. 
4.2 Banco de dados 
Genericamente, podemos descrever um banco de dados como um 
conjunto de dados que se relacionam. Para que esses dados sejam ar-
mazenados, organizados, acessados ou manipulados, são necessários 
programas que processam essas atividades. Esses programas são co-
nhecidos como sistemas de gerenciamento de banco de dados (SGBD). 
Segundo Silberschatz, Sundarshan e Korth (2016, p. 1), “um sistema 
de banco de dados é uma coleção de dados inter-relacionados e um 
conjunto de programas que permitem aos usuários acessar e modificar 
esses dados”.
Na figura 2, podemos observar a representação de um sistema de 
banco de dados.
38 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
Figura 2 – Sistema de banco de dados
Programas softwares
Usuário
Sistemas de gerenciamento 
de banco de dados
Banco de dados
Os sistemas de banco de dados são armazenados em hardwares, 
que podem ser desde equipamentos de pequeno porte, como pendri-
ves, computadores de mão, entre outros, até máquinas de grande porte, 
denominadas mainframes. 
Os objetivos principais de um sistema de banco de dados são: for-
necer aos usuários uma visão dos dados transformados para uma utili-
zação prática e amigável, ou seja, não apresentar os dados como estão 
gravados no banco de dados e, também, tornar os dados independentes 
das aplicações em que são utilizados, mantendo a independência na 
sua forma de armazenamento e nas estratégias de acesso. 
Com relação aos tipos de banco de dados, podemos destacar quatro 
modelos principais: (1) relacional, (2) entidade/relacionamento, (3) ba-
seado em objetos e (4) semiestruturado. No quadro 3 estão descritas 
suas principais características.
39Ciclo de vida de desenvolvimento de sistemas – análise, projeto e construção
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
Quadro 3 – Principais modelos de banco de dados
MODELO CARACTERÍSTICAS
Relacional
Trata-se do modelo de dados 
mais utilizado.
Utiliza uma coleção de tabelas para representar os dados e suas 
relações, cada tabela possui colunas, cada uma com um nome único. 
O modelo relacional é um exemplo de modelo baseado em registros. 
Cada tipo de registro define um número fixo de campos ou atributos. 
Vale lembrar que registros são as linhas de dados formados por vários 
campos. Por exemplo, imagine uma tabela com os seguintes campos: 
“nome”; “cidade”; “estado”. O 1o registro poderia ser a linha: Renato; 
Santos; São Paulo; o 2º registro, Douglas, Bauru, São Paulo. E assim 
sucessivamente.
Entidade/relacionamento (ER)
O modelo ER foi desenvolvido 
para facilitar o projeto de banco 
de dados.
O modelo de dados ER utiliza 3 elementos básicos: entidades, 
relacionamento e atributos. 
Entidades: é uma “coisa” ou “objeto” baseado no mundo real que é 
distinguível de todos os outros objetos. Por exemplo, cada pessoa em 
uma empresa pode ser uma entidade.
Relacionamentos: é uma associação entre várias entidades.
Atributos: são propriedades descritivas de um conjunto de entidades.
Baseado em objetos
O modelo combina 
características do modelo de 
dados orientado a objetos e do 
modelo relacional.
Como a programação orientada a objetos tornou-se a metodologia 
dominante, isso levou ao desenvolvimento de um modelo de dados 
também orientado a objetos, que pode ser visto como uma extensão do 
modelo ER com noções de encapsulamento e identidade do objeto. 
Semiestruturado
Os dados são armazenados de 
forma não estruturada.
Permite a especificação dos dados, em que itens de dados individuais 
do mesmo tipo podem ter diferentes conjuntos de atributos. 
Isso é o oposto dos modelos de dados mencionados anteriormente, em 
que todos os itens de dados de determinado tipo precisam ter o mesmo 
conjunto de atributos.
Fonte: adaptado de Silberschatz et al. (2016).
Os modelos de banco de dados são definidos de acordo com a apli-
cação a ser construída e suas características, como paradigma de de-
senvolvimento, quantidade de informações, estratégia de acesso, tec-
nologia utilizada, entre outras.
40 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
4.3 Integração 
A integração é uma atividade do processo de desenvolvimento do 
software que tem como objetivo agrupar os componentes do sistema 
que foram desenvolvidos separadamente, compondo um único siste-
ma. Também pode ser a integração de um novo software desenvolvido 
com um outro sistema já existente. São como um “quebra-cabeça”, em 
que todas as peças se juntam uma com as outras, formando uma peça 
única, ou seja, um único produto. A integração pode ser efetuada por 
meio de duas maneiras: a integração simultânea e a incremental. Naintegração simultânea, todos os componentes são agrupados em uma 
única vez; na incremental, os componentes são integrados um por vez. 
Do ponto de vista técnico e funcional, a integração incremental é a 
melhor estratégia por três motivos principais: (1) não há necessidade de 
todos os componentes do sistema estarem prontos para que seja efe-
tuada a integração, (2) otimiza a realização dos testes e (3) facilita a lo-
calização de erros, já que os componentes são integrados um a um. Na 
integração simultânea, a ocorrência de riscos é bastante alta e possui 
muitas desvantagens que são o inverso das vantagens da integração 
incremental. A abordagem simultânea é utilizada, basicamente, para o 
desenvolvimento de sistemas de pequeno porte.
Considerações finais
Neste capítulo, vimos que no processo de desenvolvimento de um 
software é indicado que se cumpra algumas etapas essenciais para a 
entrega de um produto de qualidade. O conjunto dessas etapas é co-
nhecido como ciclo de vida de desenvolvimento de sistemas e essas 
etapas são genericamente conhecidas como: análise, projeto, constru-
ção, testes, implantação e manutenção. Também estudamos com mais 
detalhes as três primeiras etapas.
41Ciclo de vida de desenvolvimento de sistemas – análise, projeto e construção
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
Na etapa da análise, se realiza, basicamente, estudo para a concep-
ção do produto final, levantamento das necessidades, viabilidade, veri-
ficação das opções de solução, identificação de processos e métodos. 
Em síntese, a etapa da análise consiste em identificar o melhor caminho 
para a criação da aplicação.
A realização da etapa do projeto consiste em elaborar a especifi-
cação técnica de como a solução identificada será construída. Talvez 
seja a etapa mais importante de todo o ciclo de desenvolvimento. Não 
devemos poupar tempo e esforço nessa fase, pois sua realização de 
forma completa e detalhada resultará na entrega de um produto com a 
qualidade desejada.
Na sequência, é realizada a construção da solução definida e espe-
cificada. Nessa etapa, são criados, principalmente, os módulos de de-
senvolvimento, o banco de dados e a realização da integração. Vimos 
que o conceito de modularidade tem como objetivo principal dividir em 
componentes o desenvolvimento do sistema, facilitando a identificação 
de problemas. Porém, quanto mais módulos criados, maior a necessi-
dade do desenvolvimento de interfaces. A modularidade é um conceito 
que deve ser utilizado com cautela e moderação. 
O banco de dados é um dos principais componentes de um sistema; 
é nele que ficam armazenados todos os dados e informações neces-
sárias para a utilização do sistema. Associada ao banco de dados, se 
faz necessária a utilização de um sistema que executará as funções de 
manipulação dos dados, o qual chamamos de sistema de gerenciamen-
to de banco de dados, conhecido pela sigla SGBD. Por último, vimos a 
atividade de integração que consiste na realização da união de todos os 
componentes desenvolvidos, gerando um único sistema que também 
pode ser a integração de um novo componente a um sistema já existen-
te. O processo de integração é uma atividade de alta complexidade, de-
vido, principalmente, à grande variedade de tecnologias compreendidas 
na concepção dos diversos componentes.
42 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
Cada etapa produz um insumo que é a entrada para a realização 
das atividades da etapa seguinte. Se cada etapa for realizada da me-
lhor forma possível, a etapa seguinte será realizada com mais facilida-
de e qualidade, e assim sucessivamente, garantindo um produto final 
de sucesso.
Referências
AUDY, Jorge L. N.; PRIKLADNICKI, Rafael.  Desenvolvimento distribuído de 
software. Rio de Janeiro: Elsevier, 2007.
PRESSMAN, S. Roger. Engenharia de software. 3. ed. São Paulo: McGraw-Hill, 
1995.
_____. Engenharia de software. 6. ed. São Paulo: McGraw-Hill, 2006.
_____. Engenharia de software: uma abordagem profissional. 8. ed. São Paulo: 
McGraw-Hill, 2016.
SILBERSCHATZ, Abraham; SUNDARSHAN, S.; KORTH, Henry F. Sistema de ban-
co de dados. 6. ed. Rio de Janeiro: Elsevier Brasil, 2016.
TAYLOR, E. S. An interim report on engineering design. Massachusetts Institute 
of Technology, 1959.
TENORIO, Fernando G.; VALLE, Rogerio. Fábrica de software. São Paulo: FGV, 
2013.
43
Capítulo 3
Ciclo de vida de 
desenvolvimento de 
sistemas – testes, 
implantação de 
sistemas e tipos de 
manutenção
Dando continuidade ao capítulo anterior, no qual estudamos, generi-
camente, o ciclo de vida clássico de desenvolvimento de software e suas 
três primeiras etapas – (1) análise, (2) projeto e (3) construção –, neste 
capítulo, vamos estudar mais detalhadamente as três últimas etapas 
do ciclo de desenvolvimento – (4) testes, (5) implantação e (6) manu-
tenção –, assim como seus principais tipos, objetivos e características.
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
44 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
Na etapa de testes, são realizados diversos tipos de verificação, com o 
objetivo de minimizar ao máximo falhas de codificação, processamento, de-
sempenho, entre outros, bem como investigar se suas funcionalidades es-
tão de acordo com as necessidades levantadas e acordadas com o cliente.
Ao final da etapa de testes, inicia-se a fase de implantação, considera-
da a mais crítica de todo o ciclo, pois é nessa fase que o software desen-
volvido é colocado em produção no ambiente do cliente e dos usuários, 
o que pode paralisar todos os processos funcionais do cliente, causando 
vários danos. Nessa fase, são realizadas diversas atividades inter-rela-
cionadas, mobilizando diversas pessoas das áreas técnicas e funcionais, 
bem como outros indivíduos envolvidos na solução proposta.
Intuitivamente, podemos pensar que, após o software ser colocado 
em produção, finaliza-se o ciclo de desenvolvimento, mas não: todo sof-
tware, após ser colocado em produção, quase que imediatamente inicia 
a etapa de manutenção, em que são efetuadas correções ou melhorias 
em decorrência de falhas técnicas ou funcionais que não foram identifi-
cadas na fase de testes. Também é nessa fase que são implementadas 
novas funcionalidades solicitadas pelo cliente, bem como adaptações 
necessárias em decorrência de alterações nos ambientes técnicos ou 
do cliente.
1 Tipos de testes
Depois que o software é construído, passamos para a etapa se-
guinte do ciclo de vida de desenvolvimento de sistemas, que é testar 
o que foi construído.
Os principais objetivos da etapa de testes são descobrir erros funcio-
nais e de codificação, bem como garantir que os requisitos solicitados 
estejam funcionando corretamente. Para Pressman (2006), a etapa de 
testes é um conjunto de atividades que são planejadas com antecedên-
cia e realizadas sistematicamente, o que deve ser suficientemente fle-
xível parapossibilitar uma abordagem de teste sob medida e de acordo 
45Ciclo de vida de desenvolvimento de sistemas – testes, implantação de sistemas e tipos de manutenção
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
com a complexidade do software construído. A melhor estratégia para a 
execução dos testes é realizá-los a partir do menor componente possí-
vel, expandindo até o seu maior nível, ou seja, de dentro para fora, seme-
lhantemente ao formato espiral, conforme ilustrado na figura 1. 
Figura 1 – Modelo espiral de testes
Teste de validação
Teste de sistemas
Teste de integração
Teste de unidade
Código
Projetos
Requisitos
Engenharia de sistemas
Fonte: adaptado de Pressman (2006, p. 291).
Os principais tipos de testes são:
1. Teste de unidade
2. Testes de integração:
a. Testes de integração descendente 
b. Testes de integração ascendente
c. Testes de regressão
d. Teste “fumaça”
e. Teste de validação
3. Testes de sistema:
a. Testes de recuperação
46 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
b. Testes de segurança
c. Testes de esforço
d. Testes de desempenho
e. Testes de usabilidade
f. Testes de disponibilidade
1.1 Testes de unidade
O teste de unidade ou testes unitários relacionam-se ao nível mais 
baixo na escala de testes e são executados nos menores componentes 
do código desenvolvido, tendo como objetivo garantir que eles estejam 
de acordo com as especificações, considerando suas características e 
sua funcionalidade. Os testes unitários analisam o funcionamento de 
um componente do sistema que possa ser testado separadamente. 
Normalmente, e, na sua maioria, os testes unitários são realizados pe-
los desenvolvedores (RIOS; MOREIRA, 2006).
Os principais objetivos dos testes unitários são detectar erros rela-
cionados a falhas de lógica, estrutura de dados erradas ou simplesmen-
te erros de programação, por exemplo, erro de sintaxe. Para a realização 
dos testes unitários, não é necessário que o sistema esteja finalizado, 
pois os componentes do software são testados separadamente. A im-
portância dos testes unitários na estratégia de testes como um todo 
está no fato de evitar que possíveis erros surjam em uma fase mais 
avançada da construção software, eliminando, assim, retrabalhos que 
possam consumir mais recursos.
1.2 Testes de integração
Os testes de integração são realizados com o objetivo de verificar se 
os componentes testados separadamente (testes unitários) funcionam 
sem erros juntos, ou seja, são realizados para garantir que as interfaces 
47Ciclo de vida de desenvolvimento de sistemas – testes, implantação de sistemas e tipos de manutenção
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
entre os componentes funcionem corretamente, bem como o proces-
samento dos dados, conforme as especificações. Segundo Pressman 
(2016, p. 297), o teste de integração é 
[...] uma técnica sistemática para construir a arquitetura do softwa-
re enquanto, ao mesmo tempo, conduz testes para descobrir erros 
associados às interfaces, sendo seu objetivo, a partir de compo-
nentes testados no nível de unidade, construir uma estrutura de 
programa determinada pelo projeto.
Podemos classificar os testes de integração em quatro subtipos 
principais (RIOS; MOREIRA, 2006; PRESSMAN, 2006):
a. Integração ascendente: são testes executados agrupando os 
componentes de forma ascendente, de baixo para cima, iniciando 
pela estrutura mais inferior do programa até chegar ao módulo de 
controle principal. É bastante utilizado para o desenvolvimento de 
sistemas de grande porte, pois cada equipe de desenvolvimento 
é responsável pela construção de um subsistema.
b. Integração descendente: é o contrário do subtipo anterior, tratan-
do-se de uma estratégia incremental. A vantagem dessa estra-
tégia é que alguns resultados podem ser demonstrados anteci-
padamente antes da construção de componentes de níveis mais 
baixos. Um problema que pode surgir nesse tipo de teste é a ne-
cessidade da construção de um componente de nível mais baixo 
para que seja testado componentes de níveis superiores.
c. Regressão: os testes de regressão são realizados a cada com-
ponente acrescentado no sistema, para garantir que essa adição 
não modifique o que já foi testado com sucesso, pois novos com-
ponentes agregam novas interfaces, fluxo de dados, controles, 
etc., e essas alterações podem causar efeitos colaterais no sub-
conjunto que já foi testado.
48 Análise de sistemas Ma
te
ria
l p
ar
a 
us
o 
ex
cl
us
ivo
 d
e 
al
un
o 
m
at
ric
ul
ad
o 
em
 c
ur
so
 d
e 
Ed
uc
aç
ão
 a
 D
is
tâ
nc
ia
 d
a 
Re
de
 S
en
ac
 E
AD
, d
a 
di
sc
ip
lin
a 
co
rre
sp
on
de
nt
e.
 P
ro
ib
id
a 
a 
re
pr
od
uç
ão
 e
 o
 c
om
pa
rti
lh
am
en
to
 d
ig
ita
l, s
ob
 a
s 
pe
na
s 
da
 L
ei
. ©
 E
di
to
ra
 S
en
ac
 S
ão
 P
au
lo
.
d. Teste “fumaça”: é uma estratégia utilizada quando um software é 
desenvolvido em um prazo crítico. É uma espécie de marca-pas-
so, em que os testes são realizados em uma frequência estabe-
lecida, exemplo: de 15 em 15 minutos é realizado um teste. O ob-
jetivo do teste “fumaça” é proporcionar uma avaliação constante 
pela equipe de desenvolvimento.
1.3 Teste de validação
O teste de validação inicia ao término dos testes de integração. 
Nesse tipo de teste, são avaliados os requisitos do sistema, ou seja, o 
teste é avaliado de acordo com as especificações solicitadas pelo clien-
te, suas funcionalidades. Basicamente, é a aceitação, pelo cliente, do 
sistema desenvolvido. 
Normalmente, são utilizados dois processos nesse tipo de teste: (1) 
o teste realizado no ambiente do desenvolvedor executado pelo cliente 
final, em que o desenvolvedor registra as ocorrências, chamado de “tes-
te alfa”, e (2) o teste realizado no ambiente do usuário e realizado pelo 
cliente, no qual o cliente registra as ocorrências e encaminha para o 
desenvolvedor providenciar os ajustes, chamado de “teste beta”.
1.4 Testes de sistemas
Os testes de sistemas são considerados o último estágio da etapa 
de testes. Consistem na realização de testes do software relacionando-
-se com os outros elementos (hardware, rede, dados, indivíduos, etc.) 
para verificar se o software está adequado para ser utilizado no seu am-
biente final. Durante os testes de sistemas, são efetuados testes com 
diferentes finalidades. Os testes mais importantes que compõe os tes-
tes de sistemas são:
49Ciclo de vida de desenvolvimento de sistemas – testes, implantação de sistemas e tipos de manutenção
M
aterial para uso exclusivo de aluno m
atriculado em
 curso de Educação a Distância da Rede Senac EAD, da disciplina correspondente. Proibida a reprodução e o com
partilham
ento digital, sob as penas da Lei. ©
 Editora Senac São Paulo.
a. Testes de recuperação: é basicamente um teste de resiliência. 
Trata-se da avaliação do quanto o software é capaz de se recupe-
rar na ocorrência de falhas. O teste de recuperação é executado por 
meio da exposição do software a uma série de falhas de funciona-
mento e o quanto demora para voltar a funcionar corretamente. 
b. Testes de segurança: verifica se os mecanismos de segurança 
projetados para o software vão funcionar satisfatoriamente, de-
fendendo o software contra invasões indesejáveis por