Buscar

Apostila ENGENHARIA DE SOFTWARE unicesumar

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 182 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 6, do total de 182 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 9, do total de 182 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Prévia do material em texto

ENGENHARIA DE 
SOFTWARE
Professora Me. Márcia Cristina Dadalto Pascutti
Professora Esp. Janaína Aparecida de Freitas
Professora Esp. Talita Tonsic Gasparotti
GRADUAÇÃO
Unicesumar
C397 CENTRO UNIVERSITÁRIO DE MARINGÁ. Núcleo de Educação a 
Distância; PASCUTTI, Márcia Cristina Dadalto; FREITAS, Janaína 
Aparecida de; GASPAROTTI,Talita Tonsic. 
 
 Engenharia de Software. Márcia Cristina Dadalto Pascutti; 
Janaína Aparecida de Freitas; Talita Tonsic Gasparotti. 
 Reimpressão - 2018
 Maringá-Pr.: UniCesumar, 2016. 
 182 p.
“Graduação - EaD”.
 
 1. Engenharia. 2. Software . 3. EaD. I. Título.
 ISBN 978-85-459-0356-7
CDD - 22 ed. 005.1
CIP - NBR 12899 - AACR/2
Ficha catalográfica elaborada pelo bibliotecário 
João Vivaldo de Souza - CRB-8 - 6828
Reitor
Wilson de Matos Silva
Vice-Reitor
Wilson de Matos Silva Filho
Pró-Reitor de Administração
Wilson de Matos Silva Filho
Pró-Reitor de EAD
Willian Victor Kendrick de Matos Silva
Presidente da Mantenedora
Cláudio Ferdinandi
NEAD - Núcleo de Educação a Distância
Direção Operacional de Ensino
Kátia Coelho
Direção de Planejamento de Ensino
Fabrício Lazilha
Direção de Operações
Chrystiano Mincoff
Direção de Mercado
Hilton Pereira
Direção de Polos Próprios
James Prestes
Direção de Desenvolvimento
Dayane Almeida 
Direção de Relacionamento
Alessandra Baron
Head de Produção de Conteúdos
Rodolfo Encinas de Encarnação Pinelli
Gerência de Produção de Conteúdos
Gabriel Araújo
Supervisão do Núcleo de Produção de 
Materiais
Nádila de Almeida Toledo
Supervisão de Projetos Especiais
Daniel F. Hey
Coordenador de Conteúdo
Fabiana de Lima
Design Educacional
Yasminn Zagonel
Iconografia
Isabela Soares Silva
Projeto Gráfico
Jaime de Marchi Junior
José Jhonny Coelho
Arte Capa
Arthur Cantareli Silva
Editoração
Matheus Felipe Davi
Qualidade Textual
Hellyery Agda
Pedro Barth
Nayara Valenciano
Ilustração
Marta Sayuri Kakitani
Viver e trabalhar em uma sociedade global é um 
grande desafio para todos os cidadãos. A busca 
por tecnologia, informação, conhecimento de 
qualidade, novas habilidades para liderança e so-
lução de problemas com eficiência tornou-se uma 
questão de sobrevivência no mundo do trabalho.
Cada um de nós tem uma grande responsabilida-
de: as escolhas que fizermos por nós e pelos nos-
sos farão grande diferença no futuro.
Com essa visão, o Centro Universitário Cesumar 
assume o compromisso de democratizar o conhe-
cimento por meio de alta tecnologia e contribuir 
para o futuro dos brasileiros.
No cumprimento de sua missão – “promover a 
educação de qualidade nas diferentes áreas do 
conhecimento, formando profissionais cidadãos 
que contribuam para o desenvolvimento de uma 
sociedade justa e solidária” –, o Centro Universi-
tário Cesumar busca a integração do ensino-pes-
quisa-extensão com as demandas institucionais 
e sociais; a realização de uma prática acadêmica 
que contribua para o desenvolvimento da consci-
ência social e política e, por fim, a democratização 
do conhecimento acadêmico com a articulação e 
a integração com a sociedade.
Diante disso, o Centro Universitário Cesumar al-
meja ser reconhecido como uma instituição uni-
versitária de referência regional e nacional pela 
qualidade e compromisso do corpo docente; 
aquisição de competências institucionais para 
o desenvolvimento de linhas de pesquisa; con-
solidação da extensão universitária; qualidade 
da oferta dos ensinos presencial e a distância; 
bem-estar e satisfação da comunidade interna; 
qualidade da gestão acadêmica e administrati-
va; compromisso social de inclusão; processos de 
cooperação e parceria com o mundo do trabalho, 
como também pelo compromisso e relaciona-
mento permanente com os egressos, incentivan-
do a educação continuada.
Seja bem-vindo(a), caro(a) acadêmico(a)! Você está 
iniciando um processo de transformação, pois quando 
investimos em nossa formação, seja ela pessoal ou 
profissional, nos transformamos e, consequentemente, 
transformamos também a sociedade na qual estamos 
inseridos. De que forma o fazemos? Criando oportu-
nidades e/ou estabelecendo mudanças capazes de 
alcançar um nível de desenvolvimento compatível com 
os desafios que surgem no mundo contemporâneo. 
O Centro Universitário Cesumar mediante o Núcleo de 
Educação a Distância, o(a) acompanhará durante todo 
este processo, pois conforme Freire (1996): “Os homens 
se educam juntos, na transformação do mundo”.
Os materiais produzidos oferecem linguagem dialógica 
e encontram-se integrados à proposta pedagógica, con-
tribuindo no processo educacional, complementando 
sua formação profissional, desenvolvendo competên-
cias e habilidades, e aplicando conceitos teóricos em 
situação de realidade, de maneira a inseri-lo no mercado 
de trabalho. Ou seja, estes materiais têm como principal 
objetivo “provocar uma aproximação entre você e o 
conteúdo”, desta forma possibilita o desenvolvimento 
da autonomia em busca dos conhecimentos necessá-
rios para a sua formação pessoal e profissional.
Portanto, nossa distância nesse processo de cresci-
mento e construção do conhecimento deve ser apenas 
geográfica. Utilize os diversos recursos pedagógicos 
que o Centro Universitário Cesumar lhe possibilita. Ou 
seja, acesse regularmente o AVA – Ambiente Virtual de 
Aprendizagem, interaja nos fóruns e enquetes, assista 
às aulas ao vivo e participe das discussões. Além dis-
so, lembre-se que existe uma equipe de professores 
e tutores que se encontra disponível para sanar suas 
dúvidas e auxiliá-lo(a) em seu processo de aprendiza-
gem, possibilitando-lhe trilhar com tranquilidade e 
segurança sua trajetória acadêmica.
A
U
TO
R
A
S
Professora Me. Márcia Cristina Dadalto Pascutti
Possui graduação em Processamento de Dados pela Universidade Estadual 
de Maringá (1989) e mestrado em Ciência da Computação pela Universidade 
Federal do Rio Grande do Sul (2002). Atualmente, é professora no Instituto 
Federal do Paraná - Campus Umuarama e está cursando o doutorado na PUC-
PR. Atua, principalmente, nos seguintes temas: arquitetura de computadores, 
engenharia de software, processamento de imagens, reconhecimento de 
padrões, visão computacional.
Professora Esp. Janaína Aparecida de Freitas
Possui graduação em Informática pela Universidade Estadual de Maringá 
(2010). Especialização em MBA em Teste de Software pela Universidade 
UNICEUMAR, Brasil. (2012). Trabalhou na iniciativa privada, na área de Analise 
de Sistemas e Testes de Software. Tem experiência na área de Engenharia 
de Software com ênfase em Análise de Requisitos, Gestão de Projetos de 
Software, Métricas e Estimativas, Qualidade e Teste de Software. Atualmente 
cursando o curso Técnico em Qualidade no Senac-PR e Licenciatura em Letras 
- Português/Inglês na UniCesumar.
Professora Esp. Talita Tonsic Gasparotti
Possui formação em Análise e Desenvolvimento de Sistemas - PD, 
especialização em Gestão e Coordenação Escolar e especialista em Educação 
a Distância e as Tecnologias Educacionais
SEJA BEM-VINDO(A)!
Prezado(a) acadêmico(a), é com muito prazer que apresento a você o livro de engenha-
ria de software. A engenharia de software possui uma gama imensa de tópicos, que 
não seria possível abarcar em cinco unidades (como este livro está organizado), então 
abordei os assuntos iniciais, sem os quais não seria possível entender todo o contexto da 
disciplina. Se você gostar da disciplina e quiser se aprofundar, pode consultar os livros 
citados durante as unidades. Neles, com certeza, você aprenderá muitos outros assun-
tos e poderá ter certeza de que a engenharia de software realmente é muito importante 
quando tratamos de software, como um todo.
Este livro está organizado em cinco unidades, sendo que todas estão estreitamente re-
lacionadas. 
Na unidadeI, apresentarei alguns conceitos referentes à disciplina. Você notará, durante 
a leitura das outras unidades, que esses conceitos são utilizados com frequência.
A engenharia de software surgiu da necessidade de tornar o desenvolvimento de sof-
tware confiável, com etapas bem definidas, com custo e cronograma previsíveis, o que, 
até a época de 1968, quando o termo engenharia de software foi proposto, não aconte-
cia. Gostaria de ressaltar que software compreende, além dos programas, toda a docu-
mentação referente a ele, sendo que a engenharia de software é a disciplina que trata 
dessa documentação.
Depois, na segunda unidade, começaremos a aplicar os conceitos já estudados e mos-
trarei a você que um processo de software genérico é composto de algumas etapas bá-
sicas que farão parte de qualquer modelo de processo de software. Essas etapas básicas 
são: i) a especificação dos requisitos do software a ser desenvolvido; ii) o projeto e a im-
plementação do software; iii) a validação do software e, finalmente iv) a evolução do sof-
tware. Nesta unidade, abordarei três modelos de processo de software, mas a literatura 
traz outros modelos. Meu objetivo é mostrar alguns modelos propostos pela literatura, 
mas, ao final dessa unidade, você poderá elaborar o seu próprio modelo, colocando as 
etapas na ordem que você achar melhor para a sua empresa.
A unidade III é bastante específica, tratando apenas dos conceitos relacionados a requi-
sitos de software, já que, para o desenvolvimento de um software da forma esperada 
pelo cliente, é fundamental que todos os requisitos tenham sido claramente definidos. 
Um requisito deve estabelecer o que o sistema deve fazer, bem como as restrições sobre 
seu funcionamento e implementação, podendo ser classificado em requisito funcional e 
não funcional. Os requisitos funcionais dizem respeito aos serviços que o software deve 
fornecer, por exemplo, o cadastro dos pacientes de uma clínica odontológica, a emissão 
de um relatório de vendas. Todos esses requisitos, tanto os funcionais quanto os não 
funcionais, devem ser claramente definidos no documento de requisitos, pois é a par-
tir desse documento que o sistema será modelado, projetado, implementado, ou seja, 
todo o desenvolvimento do sistema será baseado nesse documento. Em alguns casos, 
o documento de requisitos pode servir como um contrato entre o cliente e a empresa 
desenvolvedora do software.
APRESENTAÇÃO
ENGENHARIA DE SOFTWARE
Para você ter uma ideia de como é um documento de requisitos, mostrarei o de uma 
locadora de filmes na unidade III. O exemplo é bem simples, mas contém detalhes 
suficientes para a continuidade do processo de desenvolvimento de software.
Então, de posse do documento de requisitos, começaremos a estudar a penúltima 
unidade do nosso livro, a unidade IV que trata da modelagem do sistema. Nessa 
unidade, utilizaremos os conceitos de orientação a objetos e de UML estudados na 
primeira unidade. A modelagem é a parte fundamental de todas as atividades rela-
cionadas ao processo de software, sendo que, os modelos que são construídos nessa 
etapa servem para comunicar a estrutura e o comportamento desejados do sistema, 
a fim de que possamos melhor compreender o sistema que está sendo elaborado. 
Outro ponto importante que é necessário deixar registrado, é que de nada vale uma 
documentação desatualizada, por isso, é importante utilizar uma ferramenta CASE 
para criar e manter a documentação. Representaremos estes modelos por meio de 
diagramas, utilizando a UML como notação gráfica. Na primeira unidade já explica-
mos a importância da UML e agora começaremos a utilizá-la de fato. A UML tem 
diversos diagramas, mas, em nosso material, trataremos somente do Diagrama de 
Casos de Uso e do Diagrama de Classes. A fim de auxiliar o entendimento de cada um 
deles, elaborei uma espécie de tutorial explicando a sua elaboração passo a passo. 
Isso foi feito para facilitar o seu entendimento, pois esses diagramas são os mais im-
portantes e os mais utilizados da UML, servindo de base para os demais diagramas.
E, finalmente, chegamos à última unidade do nosso material. Essa unidade é o fe-
chamento das etapas do processo de software, ou seja, tratará das etapas de pro-
jeto, implementação, teste e manutenção de software. Assim, você compreenderá 
todo o processo de software com as etapas que o englobam.
O projeto de software é onde são definidas as interfaces do sistema. É importante que o 
usuário participe ativamente deste processo, afinal, será ele quem vai passar a maior par-
te do tempo interagindo com o sistema. Depois disso, o sistema pode ser implementado, 
ou seja, é hora de transformar todo o trabalho realizado até o momento em código fonte. 
À medida que o sistema vai sendo desenvolvido, cada programa vai sendo valida-
do pelo desenvolvedor, mas isso só não basta. É muito importante que a etapa de 
validação seja cuidadosamente realizada pela equipe de desenvolvimento, pois é 
preciso assegurar que o sistema funcionará corretamente.
Depois que o sistema é colocado em funcionamento, ele precisa evoluir para conti-
nuar atendendo as necessidades dos usuários. Em todas estas etapas é importante 
a aplicação das técnicas da engenharia de software.
Assim, chegamos ao final do nosso livro. Espero, sinceramente, que sua leitura seja 
agradável e que esse conteúdo possa contribuir para seu crescimento pessoal, aca-
dêmico e profissional.
Prof.ª Márcia.
Prof.ª Janaína.
Prof.ª Talita.
APRESENTAÇÃO
SUMÁRIO
09
UNIDADE I
INTRODUÇÃO À ENGENHARIA DE SOFTWARE
15 Introdução
16 Conceitos Básicos Sobre Software 
18 História da Engenharia De Software 
22 Tipos de Aplicações de Software 
25 Software Legado 
28 Considerações Finais 
33 Referências 
34 Gabarito 
UNIDADE II
PROCESSOS DE SOFTWARE
37 Introdução
38 Processos de Software 
40 Modelos de Processo de Software 
48 Atividades Básicas do Processo de Software 
54 Considerações Finais 
60 Referências 
61 Gabarito 
SUMÁRIO
10
UNIDADE III
REQUISITOS DE SOFTWARE
65 Introdução
66 Requisitos de Software 
72 O Documento de Requisitos de Software 
78 Engenharia de Requisitos 
91 Considerações Finais 
95 Referências 
96 Gabarito 
UNIDADE IV
MODELAGEM DE SISTEMAS
101 Introdução
102 Modelagem de Sistemas 
104 Diagrama de Casos de Uso 
114 Diagrama de Classes 
131 Ferramentas Case (Computer-Aided Software Engineering) 
134 Conceitos Básicos de Orientação a Objetos 
142 Uml – Unified Modeling Languag 
144 Considerações Finais 
149 Referências 
150 Gabarito 
SUMÁRIO
11
UNIDADE V
PROJETO, IMPLEMENTAÇÃO, TESTES E MANUTENÇÃO DE SOFTWARE
157 Introdução
158 Projeto de Software 
164 Implementação de Software 
168 Teste de Software 
173 Manutenção de Software 
176 Considerações Finais 
182 Referências 
183 Gabarito 
 
184 CONCLUSÃO 
U
N
ID
A
D
E I
Professora Me. Márcia Cristina Dadalto Pascutti
Professora Esp. Talita Tonsic Gasparotti
INTRODUÇÃO À 
ENGENHARIA DE 
SOFTWARE
Objetivos de Aprendizagem
 ■ Entender o que é engenharia de software e qual a sua importância.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Conceitos básicos sobre Software 
 ■ História da Engenharia de Software
 ■ Tipos de Aplicações de Software
 ■ Mitos Relativos ao Software
 ■ Software Legado
INTRODUÇÃO
Caro(a) aluno(a), nesta primeira unidade, trataremos alguns conceitos relacio-
nados à engenharia de software como um todo, que serão fundamentais para o 
entendimento de todas as unidades. 
O termo engenharia de software foi proposto, inicialmente, em 1968, em 
uma conferência organizada para discutir o que era chamado de crise de sof-
tware. Essa crise foi originadaem função do hardware, que nessa época tinha seu 
poder de processamento e memória aumentados, sendo que o software deveria 
acompanhar esse avanço. E o que se notou, na época, é que o desenvolvimento 
de grandes sistemas de maneira informal, sem seguir regras ou etapas pré-defi-
nidas, não era suficiente. 
O software desenvolvido, até então, não era confiável, não era desenvolvido 
dentro do tempo e custos previstos inicialmente, seu desempenho era insatisfa-
tório e era difícil de dar manutenção. Os custos em relação ao hardware estavam 
caindo, em função de que a sua produção passou a ser em série, porém, o custo 
do software não acompanhava essa queda, muitas vezes, sendo aumentado.
A ideia inicial da engenharia de software era tornar o desenvolvimento de 
software um processo sistematizado, em que seriam aplicadas técnicas e méto-
dos necessários para controlar a complexidade inerente aos grandes sistemas 
(SOMMERVILLE, 2007, p. 4).
A engenharia de software é tão vasta que o software atual está envolvido 
intrinsecamente em nosso cotidiano, portanto é impossível ignorarmos sua 
importância. 
A engenharia de software moderna tem como objetivo elaborar metodolo-
gias baseadas na evolução, ou seja, os softwares modificam-se continuamente e 
também novos softwares são construídos a partir dos antigos.
Neste livro, abordaremos somente alguns tópicos da engenharia, pois, com 
certeza, precisaríamos de dezenas de livros como esse para esgotar esse assunto, 
portanto, gostaria de deixar claro, que aqui estudaremos somente uma pequena 
parte dessa abrangente disciplina.
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
15
©shutterstock
INTRODUÇÃO À ENGENHARIA DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E16
CONCEITOS BÁSICOS SOBRE SOFTWARE
O software é um segmento de instru-
ções que serão analisadas e processadas 
pelo computador, ele dará significado a 
elas com o objetivo de executar tarefas 
específicas, pois são os softwares que 
comandam o funcionamento de qual-
quer computador; o software é a parte 
lógica que fornece explicações para o 
hardware do computador. 
Pressman (2011 p. 32) afirma que: 
“Software de computadores continua a 
ser uma tecnologia única e mais impor-
tante no cenário mundial”.
Podemos observar outra percepção do que é o software:
Software de computador é um produto desenvolvido por profissionais 
de software que também dão suporte a ele a longo prazo e abrange pro-
gramas executáveis em computadores de diversos portes ou arquitetu-
ra, conteúdos que são apresentados quando programas são executados, 
informações descritivas em forma impressa ou virtual.  (MEDEIROS, 
2016, online).
De acordo com Sommerville (2007), o software é composto não somente pelos 
programas, mas também pela documentação associada a esses programas.
Para Pressman (2011), o software possui, pelo menos, três características 
que o diferenciam do hardware:
1. Software é desenvolvido ou passa por um processo de engenharia, não 
sendo fabricado no sentido clássico.
Apesar de existir semelhanças entre o desenvolvimento de software e a 
fabricação de hardware, essas atividades são muito diferentes. Os custos 
de software concentram-se no processo de engenharia, por causa disso 
os projetos de software não podem ser conduzidos como se fossem pro-
jetos de fabricação.
Conceitos Básicos Sobre Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
17
2. Software não se desgasta.
Normalmente, o hardware apresenta taxas de defeitos mais altas no início 
de sua vida, porém esses defeitos são corrigidos tendo assim a taxa decres-
cida, ou seja, atingindo um nível estável. Porém, com o uso, o hardware 
pode se desgastar devido à poeira, má utilização, temperaturas extremas 
e outros. Já com o software é diferente, ou seja, ele não está sujeito aos 
problemas ambientais, como o hardware. Em relação aos problemas ini-
ciais, com o software também acontece assim, pois alguns defeitos ainda 
podem passar pela etapa de validação do software.
Quando um componente de hardware se desgasta, ele normalmente é tro-
cado por um novo componente e o hardware volta a funcionar. Com o 
software, isso não acontece, não tem como simplesmente trocar o com-
ponente, pois quando um erro acontece no software, pode ser de projeto, 
de requisito mal definido, levando o software a sofrer manutenção, que 
pode ser considerada mais complexa que a do hardware.
3. Embora a indústria caminhe para a construção com base em componentes, 
a maioria dos softwares continua a ser construída de forma personali-
zada (sob encomenda).
A reutilização de componentes de hardware é parte natural do seu pro-
cesso de engenharia, já para o software é algo que apenas começou a ser 
alcançado (PRESSMAN, 2011, p. 34). Os componentes reutilizáveis de 
software são criados para que o desenvolvedor possa se concentrar nas 
partes do projeto que representam algo novo. Esses componentes encap-
sulam dados e o processamento aplicado a eles, possibilitando criar novas 
aplicações a partir de partes reutilizáveis.
“Software não se desgasta, mas ele se deteriora.” – autor desconhecido.
©shutterstock
INTRODUÇÃO À ENGENHARIA DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E18
HISTÓRIA DA ENGENHARIA DE SOFTWARE
A engenharia do software se define: “[...] o estabelecimento e o emprego de sólidos 
princípios de modo a obter software de maneira econômica, que seja confiável 
e funcione de forma eficiente em máquinas reais” (MEDEIROS, 2016, online).
A principal característica da engenharia do software são seus métodos e téc-
nicas que são utilizados para o desenvolvimento do software.
Segundo Tsui e Karam (2013), o termo engenharia do software foi mencio-
nado pela primeira vez em uma conferência da OTAN (Organização do Tratado 
do Atlântico Norte) conduzida na Alemanha em 1968.
Tendo como objetivo aplicar técnicas e utilizar ferramentas na área da com-
putação, para o desenvolvimento e a produção de software, é preciso planejar a 
curto e longo prazo a equipe que vai ser montada e a qualidade do produto e do 
seu processo, e tudo isso está presente no nosso dia a dia; as pessoas não perce-
bem, mas estamos ligados à engenharia de software no nosso cotidiano.
 Segundo Sommerville (2011), a engenharia de software é uma disciplina cujo 
foco é o desenvolvimento de sistemas de software de alta qualidade por um custo 
acessível. Além disso, é preciso ter em conta que “o software é abstrato e intangível, 
História da Engenharia De Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
19
e que esta engenharia é preocupada com todos os aspectos da produção de software, 
desde os estágios iniciais de especificação de um sistema até a manutenção do sis-
tema após ter sido posto em uso” (TSUI; KARAM 2013). 
Essa disciplina ou área de conhecimento surgiu em decorrência da preocupação 
em contornar a crise que estava se abatendo no software e dar a ele um tratamento 
de engenharia. Isso aconteceu em 1970, fazendo formar a engenharia do software, 
que veio para implementar sistemas mais complexos. Segundo Sommerville (2011), 
“quando falamos de engenharia de software, não se trata apenas do programa em si, 
mas de toda a documentação associada e dados deconfigurações necessários para 
fazer este programa operar corretamente”. Além disso: 
Para ser considerada como prática de engenharia profissional deve in-
cluir o código e os regulamentos que seus membros devem seguir. Por-
tanto, a engenharia do software também inclui diretivas para a aqui-
sição de conhecimento por parte de seus membros e diretivas para as 
práticas comportamentais de seus membros (TSUI; KARAM, 2013, p. 
36).
As pessoas que trabalham diretamente com a engenharia do software estão 
envolvidas e dirigem seus conhecimentos para o desenvolvimento do software, 
atentas à manutenção e adequação, bem como aos seus diferentes processos 
produtivos.
De acordo com Sommerville (2011), “a engenharia de software é uma dis-
ciplina cujo foco está em todos os aspectos da produção de software, desde os 
estágios iniciais da especificação do sistema até sua manutenção”.
Para Sommerville (2011, p. 5), a engenharia de software é importante por 
dois motivos:
1. A sociedade, cada vez mais, depende de sistemas de software avançados, 
portanto é preciso que os engenheiros de software sejam capazes de pro-
duzir sistemas confiáveis de maneira econômica e rápida.
2. A longo prazo, normalmente, é mais barato usar métodos e técnicas 
propostos pela engenharia de software, ao invés de somente escrever os 
programas como se fossem algum projeto pessoal. Para a maioria dos sis-
temas, o maior custo está na sua manutenção, ou seja, nas alterações que 
são realizadas depois que o sistema é implantado.
INTRODUÇÃO À ENGENHARIA DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E20
A PRÁTICA DA ENGENHARIA DE SOFTWARE 
De acordo com Pressman (2011, p. 43), devemos utilizar os seguintes princí-
pios e conceitos:
1. Compreender o problema: nem sempre é fácil o quanto pensamos.
Quem tem interesse na solução do problema? Quais são os interessados?
Quais recursos, dados e funções são necessários para resolver apropria-
damente o problema?
O problema pode ser compartimentalizado? É possível representar em 
problemas menores? Talvez seja mais fácil para ser compreendido.
O problema pode ser representado graficamente? É possível termos um 
modelo analítico? 
2. Planejar uma solução: realize um pequeno projeto.
Você já viu problemas similares anteriormente? Existem padrões que são 
reconhecíveis em um potencial de soluções? Existe algum software que 
implemente os dados, as funções e características necessárias?
Algum problema similar já foi resolvido? Em caso positivo, existem ele-
mentos da solução que podem ser reutilizados?
É possível definir subproblemas? Em caso positivo, existem soluções apa-
rentes e imediatas para eles?
É possível representar uma solução de maneira que conduza a uma imple-
mentação efetiva? É possível criar um modelo de projeto?
3. Executar o plano: podem surgir desvios inesperados, mas é possível 
descobrirmos caminhos melhores; se seguirmos o planejamento, conti-
nuaremos sem nos perder.
Verificar se a solução se adequa ao plano? O código fonte pode ser atri-
buído ao projeto?
Projeto e códigos foram revisados? Os componentes da solução estão pro-
vavelmente corretos?
História da Engenharia De Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
21
4. Examinar resultado para ter precisão: não podemos ter certeza de que 
uma solução seja perfeita, porém asseguramos que testes são suficientes 
para revelar um número maior de erros.
Podemos testar cada parte componente da solução? Foi implementado 
uma estratégia de testes?
Os resultados da solução se adequam aos dados, funções e característi-
cas? O software foi validado em relação às solicitações dos interessados.
PRINCÍPIOS GERAIS
De acordo com Pressman (2011), são:
1. A razão de existir: antes de especificar uma necessidade do sistema todas 
as decisões deveriam ter princípios voltados aos seus usuários, verificar 
se realmente vai haver agregação diante da necessidade.
2. KISS – (Keep it simple, ou seja, Faça de forma simples): há diversos 
fatores a ser considerados em qualquer esforço do projeto, um software 
com qualidade de fácil manutenção e menos propensos a erros.
3. Mantenha a visão: para o sucesso, é preciso mantermos uma visão clara, 
sem ela o projeto se torna ambíguo; corre-se o risco de transformar o pro-
jeto em vários recortes, comprometendo, então, a visão clara .
4. O que um produz, os outros consomem: o sistema de força industrial é 
construído e utilizado de forma isolada. Outras pessoas poderão documen-
tar, manter e usar. Sendo assim, projete e implemente ciente de que alguém 
mais deverá entender o que você está desenvolvendo, dessa forma você 
agrega mais valor ao sistema e facilita o trabalho de todas outras pessoas.
5. Esteja aberto para o futuro: jamais desenvolva projetos limitados, pois 
um software com maior tempo de vida mais tem valor.
6. Planeje com antecedência: alcançar o nível de reuso é indiscutivelmente 
a meta mais difícil de ser atingida quando se desenvolve um software, pois 
a reutilização economiza tempo e esforço.
7. Pense: é a forma mais clara e qual produz melhores resultados sempre!
©shutterstock
INTRODUÇÃO À ENGENHARIA DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E22
TIPOS DE APLICAÇÕES DE SOFTWARE
Atualmente, com o software sendo utilizado em praticamente todas as ativida-
des exercidas pelas pessoas, existe uma grande variedade de aplicações. Vamos 
ver algumas delas:
 ■ Software de sistema – de acordo com Pressman (2011, p. 34), são aqueles 
programas desenvolvidos para atender a outros programas, por exemplo, 
editores de texto, compiladores e sistemas operacionais.
 ■ Software de aplicação – são programas desenvolvidos para solucionar uma 
necessidade específica de negócio, processando dados comerciais ou técnicos 
de forma que ajude nas operações comerciais ou tomadas de decisão pelos 
administraExdores da empresa. Um exemplo é o software ERP (Enterprise 
Resource Planning) sendo este um software que visa a integração de todos 
os dados e processos de uma organização em um sistema único.
 ■ Software científico/de engenharia – são aplicações que vão da astronomia 
à vulcanologia, da biologia molecular à fabricação automatizada, normal-
mente utilizando algoritmos para processamento numérico pesado.
 ■ Software embutido – controla ou gerencia dispositivos 
de hardware, como celular, painel do micro-ondas, con-
trole do sistema de freios de um veículo.
 ■ Software de inteligência artificial – utiliza algoritmos 
não numéricos para solucionar problemas complexos que 
não poderiam ser solucionados pela computação ou análise 
direta, por exemplo, sistemas especialistas, robótica, redes neu-
rais artificiais.
MITOS RELATIVOS AO SOFTWARE
Mitos de software são caracterizados como uma série de “falsas verdades”, pois 
apresentam uma sensação intuitiva, distorcendo a verdadeira face do processo 
de engenharia. Atualmente, profissionais com muita experiência na engenha-
ria de software reconhecem os mitos e as atitudes enganosas que representam. 
Tipos de Aplicações de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
23
Podemos observar alguns exemplos a seguir de acordo com Presmann (2011, 
p. 46-47).
1. Mitos de Gerenciamento: 
Mito: temos um livro com padrões e procedimentos para desenvolver 
software.
Realidade: o livro pode existir, mas ele é usado? Os praticantes sabem queele existe? O livro reflete a prática moderna da engenharia de software? É 
adaptável, está alinhado para melhorar o tempo de entrega, mantendo o 
foco na qualidade? Em muitos casos, a resposta para essas perguntas é “não”.
Mito: se o cronograma atrasar, poderemos acrescentar mais programa-
dores e ficarmos em dia?
Realidade: o desenvolvimento de software não é um processo mecânico 
como os das fábricas. Nas palavras de Brooks[Bro95]: “acrescentar pes-
soas num projeto de software atrasado o tornará mais atrasado ainda”. 
O que ocorre com a chegada de novas pessoas em um projeto, as que já 
estavam terão de gastar tempo situando os recém-chegados, reduzindo 
consequentemente o tempo destinado ao desenvolvimento produtivo. 
Para que sejam inseridas novas pessoas esta ação deverá ser de forma 
planejada e coordenada.
Mito: posso terceirizar o projeto de software e simplesmente relaxar e dei-
xar a essa empresa realizá-lo.
Realidade: caso essa organização não saiba gerenciar e controlar projetos 
de software, provavelmente irá se deparar com dificuldades.
2. Mitos de Clientes: 
É importante sabermos que os clientes solicitantes do software podem ser pes-
soas comuns, ou seja, não necessariamente é preciso conhecimento específico 
na área computacional, porém, é necessário saber da sua regra de negócio.
Mito: definição geral é suficiente para começar a escrever os programas.
Realidade: nem sempre será possível uma definição ampla e estável dos 
requisitos. Estes são obtidos somente por meio da comunicação entre 
cliente e desenvolvedor, sendo assim nem sempre é possível. 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E24
3. Mitos de profissionais da área:
Tem residido por mais de 50 anos de cultura de programação. Modos e 
atitudes antigos dificilmente são esquecidos.
Mito: uma vez feito programa e colocado em uso, nosso trabalho está 
terminado?
Realidade: uma vez que alguém já disse que “o quanto antes se começa a 
codificar, mais tempo levará para termina-lo”.
Mito: até que um programa entre em funcionamento, não há maneira de 
avaliar sua qualidade.
Realidade: um dos mecanismos de garantia da qualidade de software mais 
eficaz pode ser aplicado desde a concepção de um projeto.
Mito: o único produto passível de entrega é o programa em funcionamento.
Realidade: um programa funcionando é somente uma parte de uma con-
figuração de software que inclui muitos elementos. 
Mito: a engenharia de software nos fará criar documentação volumosa 
e desnecessária.
Realidade: a engenharia de software não trata de criação de documentos, 
mais sim da criação de um produto de qualidade.
Ter ciência das realidades dos profissionais que trabalham com software é 
o primeiro passo para buscar soluções práticas na engenharia de software. 
Por isso, muitos profissionais de software reconhecem com facilidade om 
mitos que acabamos de descrever.
“Se o processo estiver correto, os resultados falarão por si mesmos.” 
Takashi Osada
Software Legado
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
25
SOFTWARE LEGADO
Denominam-se aos softwares antigos os que são foco de contínua atenção e pre-
ocupação desde os anos 1960. Dayani-Fard e seus colegas [Day99] descrevem 
software legado da seguinte forma:
Sistemas de software legado... Foram desenvolvidos há décadas atrás e 
tem sido continuamente modificado para se adequar a mudanças dos 
requisitos de negócio e a plataformas computacionais. A proliferação de 
tais sistemas está causando dores de cabeça para grandes organizações 
que consideram dispendiosos de manter e arriscado de evoluir. 
Liu e seus colegas [Liu98] observaram que “muitos sistemas legados permane-
cem dando suporte para funções de negócios vitais e são ‘indispensáveis’ para 
o mesmo”. 
Softwares legados, por sua vez, podem apresentar projetos não expansí-
veis, código intrincado, documentação inexistente ou escassa, testes que nunca 
foram arquivados. E que, mesmo assim, esses softwares possuem funções vitais 
de negócios e são indispensáveis para ele. Surge-nos, então, a pergunta, o que 
devemos fazer? Nada, isso mesmo, nada, até que o software legado se submeta 
a modificações significativas. 
Vale lembrarmos que, caso o software legado atenda às necessidades de seus 
usuários, possibilitando confiança e vitalidade, não precisa ser “consertados”. 
Entretanto, esses sistemas evoluem com o passar do tempo, por uma ou mais 
das seguintes razões (Pressman 2011): 
 ■ O software deve ser adaptado para atender às necessidades de novos 
ambientes ou de novas tecnologias computacionais.
 ■ O software deve ser aperfeiçoado para implementar novos requisitos de 
negócio.
 ■ O software deve ser expandido para torná-lo interoperável com outros 
bancos de dados ou softwares mais modernos.
 ■ O software deve ser rearquitetado para torná-lo viável dentro de um 
ambiente de rede.
INTRODUÇÃO À ENGENHARIA DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E26
O objetivo da engenharia de software moderna é de “elaborar metodologias 
baseadas na evolução”, ou seja, os softwares modificam-se continuamente e que 
novos softwares são construídos a partir dos antigos... [Day99].
INTRODUÇÃO À QUALIDADE DE SOFTWARE
Para que o software possa ser funcional e prático, é preciso qualidade na pro-
dução e na manutenção. A qualidade em software se refere às características 
dos produtos que atendam requisitos de funcionalidade. Esses requisitos estão 
ligados, diretamente, com a área de utilização do programa. Para cada requi-
sito, temos um campo de abrangência, uma especificidade. Esses requisitos são: 
funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade, por-
tabilidade, estabilidade. 
Esses requisitos fazem parte da qualidade do software de forma que cada 
produto, cada programa, possa atender às necessidades tecnológicas, 
econômicas, sociais, intelectuais e práticas do setor ao qual se 
destinam, observando as especificidades de cada área onde o produto é 
utilizado. Assim deve se levar em consideração a utilização do produto. 
Em áreas econômicas certos requisitos serão mais necessários do que 
na área educacional, onde os requisitos de um programa atendem 
as necessidades daquele público em particular. (VASCONCELOS, 
ROUILLER, MACHADO, MEDEIROS, 2006).
Ao observar essas especificidades, o software responde aos anseios de um mer-
cado em particular. Sem deixar de levar em consideração o que cada um precisa. 
Áreas de lazer precisam de certos requisitos, áreas educacionais outros, áreas 
sociais outros. O programa atende às necessidades de cada setor, sem perder a 
sua qualidade.
Software Legado
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
27
A qualidade se torna uma parte importante em todo o processo de pro-
dução de um software, em que se leva em consideração não apenas aspectos 
tecnológicos, econômicos ou sociais, mas a praticidade do mesmo, as funções 
que desempenha, a facilidade de uso, a capacidade de ser reciclado, manuten-
ção, entre outros. A qualidade visa apresentar um produto completo que atenda 
a todas as necessidades do setor a qual se destina. 
O que é engenharia reversa?
O nome “engenharia reversa” define muito bem o conceito do que ela faz. 
Trata-se do estudo de um objeto, seja um processador, um monitor, um pro-
grama ou até mesmo um simples relógio, desmontando-o e analisando suas 
peças,seus componentes, seus comandos e seu comportamento (no caso 
de programas). Isso é feito para descobrir como ele foi fabricado, como ele 
poderia ser melhorado e que outras funções ele poderia realizar.
Fonte: Hautsch (online).1
INTRODUÇÃO À ENGENHARIA DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IU N I D A D E28
CONSIDERAÇÕES FINAIS
Nesta primeira unidade, foram apresentados alguns conceitos básicos sobre enge-
nharia de software que serão utilizados no decorrer de todo o livro, por isso, é 
muito importante que esses conceitos fiquem bem claros para você.
A engenharia de software foi proposta para tentar levar a precisão da enge-
nharia para o desenvolvimento de software, pois até aquela época, desenvolver 
um software era algo que não podia ser mensurado, nem em relação ao tempo, 
nem em relação ao custo, levando-se, normalmente, muito mais tempo do que 
o previsto. E o que acontecia era que não se tinha uma regra, uma sequência de 
atividades para o desenvolvimento. Você vai ver, na próxima unidade que, para 
tentar solucionar esse problema, os estudiosos da engenharia de software pro-
puseram vários modelos de processos de software, sendo que a empresa pode 
escolher o que melhor se adequa a ela. Isso tem ajudado muito o desenvolvimento 
de software. Você vai perceber isso durante o estudo das próximas unidades.
Outro conceito importante que foi tratado nesta primeira unidade é o con-
ceito de software. Algumas pessoas que conheço acham que desenvolver software 
é simplemesmente sentar em frente ao computador e escrever as linhas de código. 
Você percebeu que sim, isso faz parte do software, mas que desenvolver software 
é muito mais abrangente, pois o software envolve, além dos programas, a docu-
mentação, as pessoas, os procedimentos envolvidos. A engenharia de software 
trata de todos esses aspectos, mas em nosso livro trataremos mais especifica-
mente da modelagem de um software, desde o levantamento dos requisitos até 
a elaboração de vários diagramas. Não trataremos da implementação propria-
mente dita, pois isso você verá em outras disciplinas do curso. A implementação 
é muito importante, por isso, você terá disciplinas dedicadas a essa tarefa.
Essa primeira unidade foi somente um aperitivo. Agora vamos passar a estu-
dar assuntos específicos da disciplina e você vai perceber que a engenharia de 
software é muito importante para o desenvolvimento de um software.
29 
1. Segundo Pressman, assinale quais alternativas diferenciam o software do 
hardware?
I. Software não é fabricado no sentido clássico.
II. Software se desgasta.
III. Software possui componentes reutilizáveis.
IV. Software não possui segmento de instruções.
V. Software é a parte lógica.
São verdadeiras:
a. Somente I e II.
b. Somente I, III e V.
c. Somente I, III e V.
d. Todas estão corretas.
2. Quando falamos de engenharia de software, não se trata apenas do 
______________ em si, mas de toda a _____________ associada e dados de con-
figurações necessários para fazer este programa operar corretamente.
3. Quais são os tipos de aplicações de software?
30 
DESENVOLVIMENTO ÁGIL DE SOFTWARE
Kend Beck (2001) e outros dezesseis renomados que trabalhavam na área de desen-
volvimento, consultoria, do sistema de software assinaram o “Manifesto para o desen-
volvimento ágil de Software”. O objetivo era sanar fraquezas que fossem perceptíveis 
na engenharia de software, para que esse método funcionasse era necessário observar 
alguns itens: a satisfação do cliente, a maneira como se acolhe os pedidos de alterações, 
dar preferência a intervalos mais curtos de entrega, trabalhar em conjunto, motivação 
constante tanto para elaborar o projeto como da equipe que irá realizá-lo, sempre ter 
uma conversa aberta com a equipe, o software sempre deve estar em funcionamento, 
ter sempre um ritmo constante, atenção contínua, simplicidade, auto organização da 
equipe, avaliação da equipe em tempos regulares. Segundo Pressman (2011, p. 86) o 
desenvolvimento ágil foca talentos e habilidades de indivíduos, moldando o processo 
de acordo com as pessoas e as equipes específicas. 
Quando falamos de desenvolvimento ágil da engenharia do software, nos deparamos 
com inúmeras definições, pois as suas práticas variam muito, mas os princípios são 
iguais, a entrega rápida do projeto, a agilidade da equipe, e a constante participação di-
reta do cliente com seus fornecedores, que são os engenheiros de software, estes têm o 
enfoque no software em si, e não em sua concepção e documentação. Segundo Steffen 
(2016, p. 1): 
Ágil é uma nova forma de gestão e desenvolvimento de Software que 
usa uma abordagem de planejamento e execução iterativa e incremental 
voltado para processos empíricos (complexos, caóticos ou com muita 
incerteza, têm mudanças ao longo do processo, não são repetitivos e 
são imprevisíveis) que divide o problema em produtos menores e que 
visa entregar software funcionando regularmente, visa a aproximação 
e maior colaboração do time de desenvolvimento com os experts de 
negócios, comunicação face-to-face, redução dos riscos associados às 
incertezas dos projetos, abraçar e responder as mudanças de forma mais 
rápida e natural e é claro a satisfação final dos clientes por meio da ado-
ção de práticas de gestão e de engenharia de software com foco nos 
valores e princípios doLean e do agile, resumindo, seu principal objetivo 
é entregar o produto que o cliente realmente deseja e que será útil e 
com qualidade.
Podemos notar que a engenharia ágil de software tem como prioridade melhorar a sua 
produtividade, tendo como foco a contínua comunicação com seu cliente, o que muda 
na sua estrutura, mas só um pouco, essa engenharia planeja apenas o que será feito, 
com todos os detalhes, se acaso acontecer de ter algum erro, esse pode ser corrigido 
rapidamente, não deixando a equipe se desmotivar.
31 
Nos dias de hoje, as empresas operam em um ambiente global, com mu-
danças rápidas. Assim precisam responder a novas oportunidades e no-
vos mercados, a mudanças nas condições econômicas e ao surgimento 
de produtos e serviços concorrentes. Softwares fazem parte de quase 
todas as operações de negócios, assim novos softwares são desenvolvi-
dos rapidamente para obterem proveito de novas oportunidades e res-
ponder às pressões competitivas (SOMMERVILLE. p. 39). 
O método ágil não é fechado em si, tendo várias vertentes ou campos de atuação, como:
A Extreme Programming (XP) é uma metodologia de desenvolvimento de software, nas-
cida nos Estados Unidos no final da década de 90. Destaca-se, em diversos países, por 
auxiliar o desenvolvimento de sistemas de melhor qualidade, que são produzidos em 
menos tempo e de forma mais econômica que o habitual. Os objetivos são alcançados 
por meio de um pequeno conjunto de valores, princípios e práticas, que diferem subs-
tancialmente da forma tradicional de se desenvolver software. Propondo que somente 
a documentação estritamente necessária seja gerada, com o código e os testes de uni-
dade servindo como documentação.
Scrum é uma metodologia de desenvolvimento que surgiu no início dos anos 90, seu 
nome foi originado a partir de uma atividade durante a partida de rugby.
Incorpora atividades estruturais, sendo elas: requisitos, análise, projeto, evolução e en-
trega. Para cada atividade metodológica, é utilizado padrões de processo:
Registro pendente de trabalhos (Backlog): lista de requisitos e prioridades ou funciona-
lidades que fornecem valor comercial aos clientes.
Urgências (sprints): consiste em realizar ajustes dentro de prazo pré-estabelecido. 
Alterações: permitem que membros trabalhem em curto prazo, porém estáveis.
Reuniões: são realizadas diariamente pela equipe com duração máxima de 15 minutos.
Demos: demonstração ao cliente das funcionalidadesimplementadas, lembrando que 
esta poderá não ter todas as funcionalidades.
Por meio desses métodos a engenharia de software pode aplicar em seus projetos, 
sendo eles não muito complexos, de maior rapidez, pois os ciclos são mais curtos, o 
planejamento é mais funcional, tolerância a mudanças, maior proximidade da equipe 
com seu cliente e vice versa e o foco geral no ambiente de trabalho e de seus colabora-
dores.
MATERIAL COMPLEMENTAR
Fundamentos de Engenharia de Software
Frank Tsui e Orlando Karam
Editora: LTC
Sinopse: Em sua segunda edição, Fundamentos da Engenharia 
de Software consiste em uma introdução abrangente de temas e 
metodologias essenciais sobre o desenvolvimento de software. Ideal 
para estudantes universitários e para profi ssionais experientes à 
procura de uma nova carreira no setor de tecnologia da informação 
– ou áreas afi ns –, esta obra apresenta o ciclo de vida completo de 
um sistema de software – da concepção até a liberação e o suporte 
ao usuário. 
Fundamentos da Engenharia de Software constitui um texto 
excepcional para aqueles que estão ingressando no estimulante 
mundo do desenvolvimento de software.
REFERÊNCIAS
33
MEDEIROS, H. Princípios da engenharia de software. Disponível em: <http://
www.devmedia.com.br/principios-da-engenharia-de-software/29630>. Acesso em 
11 de fev. de 2016.
PRESSMAN, R. S. Engenharia de software. Uma abordagem profissional. 7. Ed. Por-
to Alegre: AMGH, 2011.
SOMMERVILLE, I. Engenharia de software. 9. Ed. São Paulo: Pearson Prentice Hall, 
2011. 
STEFFEN, J. B. O que são essas tais de metodologias ágeis? Disponível em: <ht-
tps://www.ibm.com/developerworks/community/blogs/rationalbrasil/entry/
mas_o_que_s_c3_a3o_essas_tais_de_metodologias__c3_a1geis?lang=en>. Aces-
so em 11 de fev. de 2016.
TSUI, F. ; KARAM, O. Fundamentos de engenharia de software. 2. Ed. Rio de Janei-
ro: LTC, 2013.
VASCONCELOS, A. M. L. de; ROUILLER, A. C.; MACHADO, C. Â. F.; MEDEIROS, T. M. 
M. de. Introdução à engenharia de software e à qualidade de software. Lavras: 
UFLA/FAEPE, 2006. Disponível em: <http://www.cin.ufpe.br/~if720/downloads/
Mod.01.MPS_Engenharia&QualidadeSoftware_V.28.09.06.pdf>. Acesso em 11 de 
fev. de 2016.
GABARITO
1. – C
2. - Programa, Documentação
3. –
• Software de sistema: programas desenvolvidos para atender a outros pro-
gramas.
• Software de aplicação: programas desenvolvidos para solucionar uma ne-
cessidade específica de negócio.
• Software científico/de engenharia: são aplicações que vão da astronomia à 
fabricação automatizada.
• Software embutido: controla ou gerencia dispositivos de hardware.
• Software de inteligência artificial: solucionar problemas complexos que 
não poderiam ser solucionados pela computação ou análise. 
U
N
ID
A
D
E II
Professora Me. Márcia Cristina Dadalto Pascutti
PROCESSOS DE SOFTWARE
Objetivos de Aprendizagem
 ■ Compreender os conceitos de processo de software e modelos de 
processo de software.
 ■ Mostrar as atividades básicas do processo de software.
 ■ Mostrar três modelos de processo de software.
Plano de Estudo
A seguir, apresentam-se os tópicos que você estudará nesta unidade:
 ■ Processos de Software
 ■ Modelos de Processo de Software
 ■ Atividades Básicas do Processo de Software
INTRODUÇÃO
Caro(a) aluno(a), na primeira unidade, você aprendeu alguns conceitos bási-
cos relacionados à Engenharia de Software. A partir de agora, você começará a 
estudar assuntos mais específicos da disciplina e você verá que seu estudo ficará 
cada vez mais interessante. 
Nos últimos tempos, o desenvolvimento de software é uma das áreas da tec-
nologia que mais cresceu, e com esse crescimento vieram, também, problemas 
que vão desde o não cumprimento dos prazos estabelecidos para o seu desen-
volvimento até a falta de qualidade do software desenvolvido. 
Um software não pode ser desenvolvido de qualquer jeito, sem seguir cri-
térios, sem que se saiba qual o próximo passo a ser dado. Por isso, os conceitos 
relacionados à engenharia de software devem ser utilizados. Hoje em dia, a 
empresa precisa definir qual o seu processo de software.
Nesta unidade, você aprenderá o que é um processo de software e conhe-
cerá alguns modelos de processo que já existem em nossa literatura e que são 
utilizados por muitas empresas. Esses modelos são: modelo em cascata, desen-
volvimento incremental e engenharia de software baseada em componentes. É 
importante, porém, ressaltar que não é preciso seguir um desses modelos que já 
estão prontos, ou seja, a empresa que vai desenvolver software pode criar o seu 
próprio modelo. É imprescindível que esse modelo seja seguido.
Existem algumas atividades básicas que fazem parte de um processo de sof-
tware. Estudaremos cada uma dessas atividades: especificação de software, projeto 
e implementação de software, validação de software e evolução de software. Você 
perceberá que os modelos de processo de software apresentados nesta unidade 
possuem todas essas atividades, e que, às vezes, a atividade possui um nome 
diferente, mas com o mesmo significado. Você verá também que uma atividade 
pode se desdobrar em várias etapas ou subatividades.
Introdução
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
37
©shutterstock
PROCESSOS DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E38
PROCESSOS DE SOFTWARE
Para que um software seja produzido, são necessárias diversas etapas, compostas 
por uma série de tarefas em cada uma delas. A esse conjunto de etapas dá-se o 
nome de processo de software. Essas etapas podem envolver o desenvolvimento 
de software a partir do zero em uma determinada linguagem de programação 
(por exemplo, o Java ou C) ou, então, a ampliação e a modificação de sistemas 
já em utilização pelos usuários.
Segundo Sommerville (2011), existem muitos processos de software diferen-
tes, porém todos devem incluir quatro atividades fundamentais para a engenharia 
de software:
1. Especificação de software: é necessário que o cliente defina as 
funcionalidades do software que será desenvolvido, bem como defina 
todas as suas restrições operacionais.
2. Projeto e implementação de software: o software deve ser confeccio-
nado seguindo as especificações definidas anteriormente.
Processos de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
39
3. Validação de software: o software precisa ser validado para garantir que 
ele faz o que o cliente deseja, ou seja, que ele atenda às especificações de 
funcionalidade.
4. Evolução de software: as funcionalidades definidas pelo cliente durante 
o desenvolvimento do software podem mudar e o software precisa evo-
luir para atender a essas mudanças.
Vamos estudar detalhadamente cada uma das atividades mencionadas acima 
durante a nossa disciplina, inclusive utilizando ferramentas automatizadas (fer-
ramentas CASE) para nos auxiliar na elaboração dos diversos documentos que 
serão necessários.
Conforme Sommerville (2011, p. 19), “os processos de software são comple-
xos e, como todos os processos intelectuais e criativos, dependem de pessoas para 
tomar decisões e fazer julgamentos. Não existe um processo ideal, a maioria das 
organizações desenvolve os próprios processos de desenvolvimento de software”.
O que acontece é que nem sempre as empresas aproveitam as boas técnicas 
da engenharia de software em seu desenvolvimento de software. E, normal-
mente, o software não atende aos requisitosdo usuário, acaba demorando mais 
tempo para ser desenvolvido do que o previsto, aumentando assim, o valor do 
custo do software.
As atividades mencionadas por Sommerville podem ser organizadas pelas 
empresas da forma como ela achar melhor, porém, é importante ressaltar que 
todas essas atividades são de extrema importância e o processo de software ado-
tado pela empresa não deve deixar de considerar nenhuma das etapas.
É importante ressaltar que mesmo as empresas que possuem um processo 
de software bem definido e documentado, para determinados softwares que ela 
desenvolve, pode ser utilizado outro processo de software, ou seja, dependendo 
do software a ser desenvolvido, pode ser utilizado um determinado processo de 
software. Na próxima seção, veremos alguns modelos de processo de software e 
veremos também que é possível a empresa adotar um processo de software pró-
prio, que atenda suas necessidades.
PROCESSOS DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E40
MODELOS DE PROCESSO DE SOFTWARE
Como foi discutido anteriormente, um processo de software é composto por um 
conjunto de etapas que são necessárias para que seja produzido. Sommerville 
(2007) afirma que um modelo de processo de software é uma representação abs-
trata, simplificada de um processo de software. Os modelos de processo incluem 
as atividades que fazem parte do processo de software (você está lembrado das 
atividades descritas no item anterior?), os artefatos de software que devem ser 
produzidos em cada uma das atividades (documentos) e também os papéis das 
pessoas envolvidas na engenharia de software. Além disso, cada modelo de pro-
cesso representa um processo a partir de uma perspectiva particular, de uma 
maneira que proporciona apenas informações parciais sobre o processo.
Na literatura, existem diversos modelos de processo de software. Aqui, irei 
mostrar somente três desses modelos e, em seguida, mostrarei as atividades básicas 
que estão presentes em, praticamente, todos os modelos de processos de software. 
Os modelos de processo que mostrarei foram retirados de Sommerville 
(2011, p.20) e são:
1. Modelo em Cascata: esse modelo considera as atividades de especifi-
cação, desenvolvimento, validação e evolução, que são fundamentais ao 
processo e as representa como fases separadas, como a especificação de 
requisitos, o projeto de software, a implementação, os testes e assim por 
diante (SOMMERVILLE, 2011).
2. Desenvolvimento Incremental. esse modelo intercala as atividades de 
especificação, desenvolvimento e validação. Um sistema inicial é rapida-
mente desenvolvido a partir de especificações abstratas, que são refinadas 
com informações do cliente, para produzir um sistema que satisfaça suas 
necessidades, produzindo várias versões do software (SOMMERVILLE, 
2011).
3. Engenharia de Software Orientada a Reuso: esse modelo parte do prin-
cípio de que existem muitos componentes que podem ser reutilizáveis. 
O processo de desenvolvimento do sistema se concentra em combi-
nar vários desses componentes em um sistema, em vez de proceder ao 
desenvolvimento a partir do zero, com o objetivo de reduzir o tempo de 
desenvolvimento (SOMMERVILLE, 2011).
©shutterstock
Modelos de Processo de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
41
O MODELO EM CASCATA
O modelo cascata ou ciclo de vida clássico, 
considerado o paradigma mais antigo da 
engenharia de software, sugere uma abor-
dagem sequencial e sistemática para o 
desenvolvimento de software, começando 
com a definição dos requisitos por parte do 
cliente, avançando pelas atividades de projeto 
e implementação de software, testes, implan-
tação, culminando no suporte contínuo do 
software concluído. 
Segundo Sommerville (2007, p. 44), os 
principais estágios do modelo em cascata demonstram as atividades fundamen-
tais do desenvolvimento:
1. Análise e definição de requisitos: as funções, as restrições e os objeti-
vos do sistema são estabelecidos por meio da consulta aos usuários do 
sistema. Em seguida, são definidos em detalhes e servem como uma espe-
cificação do sistema.
2. Projeto de sistemas e de software: o processo de projeto de sistemas 
agrupa os requisitos em sistemas de hardware ou de software. Ele esta-
belece uma arquitetura do sistema geral. O projeto de software envolve 
a identificação e a descrição das abstrações fundamentais do sistema de 
software e suas relações.
3. Implementação e teste de unidades: durante esse estágio, o projeto de 
software é compreendido como um conjunto de programas ou unida-
des de programa. O teste de unidades envolve verificar que cada unidade 
atenda a sua especificação.
4. Integração e teste de sistemas: as unidades de programa ou programas 
individuais são integrados e testados como um sistema completo a fim de 
garantir que os requisitos de software foram atendidos. Depois dos tes-
tes, o sistema de software é entregue ao cliente.
PROCESSOS DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E42
5. Operação e manutenção: normalmente (embora não necessariamente), 
esta é a fase mais longa do ciclo de vida. O sistema é instalado e colo-
cado em operação. A manutenção envolve corrigir erros que não foram 
descobertos em estágios anteriores do ciclo de vida, melhorando a imple-
mentação das unidades de sistema e aumentando as funções desse sistema 
à medida que novos requisitos são descobertos.
Um estágio somente pode ser iniciado depois que o estágio anterior tenha sido 
concluído. Porém, Sommerville (2011, p. 21) afirma que na prática esses está-
gios acabam se sobrepondo, alimentando uns aos outros de informações. Por 
exemplo, durante o projeto, os problemas com os requisitos são identificados. 
O que acontece é que um processo de software não é um modelo linear simples, 
sequencial, mas envolve iterações entre as fases. Os artefatos de software que são 
produzidos em cada uma dessas fases podem ser modificados para refletirem 
todas as alterações realizadas em cada um deles.
Pressman (2011) aponta alguns problemas que podem ser encontrados 
quando o modelo cascata é aplicado:
1. Os projetos que acontecem nas empresas dificilmente seguem o fluxo 
sequencial proposto pelo modelo. Alguma iteração sempre ocorre e traz 
problemas na aplicação do paradigma.
2. Na maioria das vezes, o cliente não consegue definir claramente todas as 
suas necessidades e o modelo cascata requer essa definição no início das 
atividades. Portanto, esse modelo tem dificuldade em acomodar a incer-
teza natural que existe no começo de muitos projetos.
3. Uma versão operacional do sistema somente estará disponível no final do 
projeto, ou seja, o cliente não terá nenhum contato com o sistema durante 
o seu desenvolvimento. Isso leva a crer que se algum erro grave não for 
detectado durante o desenvolvimento, o sistema não atenderá de forma 
plena as necessidades do cliente.
Segundo Sommerville (2011) e Pressman (2011), o modelo em cascata deve 
ser utilizado somente quando os requisitos são fixos e tenham pouca probabi-
lidade de serem alterados durante o desenvolvimento do sistema e o trabalho 
deve ser realizado até sua finalização de forma linear. Sommerville (2011, p.21) 
Modelos de Processo de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
43
ainda afirma que “o modelo cascata reflete o tipo de processo usado em outros 
projetos de engenharia. Como é mais fácil usar um modelode gerenciamento 
comum para todo o projeto, processos de software baseados no modelo em cas-
cata ainda são comumente utilizados”.
DESENVOLVIMENTO INCREMENTAL
O desenvolvimento incremental, segundo Sommerville (2011, p. 21), tem como 
base a ideia de desenvolver uma implementação inicial, baseada em uma reunião 
com os envolvidos para definir os objetivos gerais do software, mostrar para o 
usuário e fazer seu refinamento por meio de várias versões, até que um sistema 
adequado tenha sido desenvolvido. 
Figura 1– Atividades concorrentes
Especi�cações
Versão �nal
Versão inicial
Atividades concorrentes
Validação
DesenvolvimentoDescrição 
do esboço
Versões 
intermediárias
Fonte: Sommerville (2011, p.22).
Assim, as atividades de especificação, desenvolvimento e validação são reali-
zadas concorrentemente com um rápido feedback entre todas as atividades. A 
cada nova versão, o sistema incorpora novos requisitos definidos pelo cliente.
PROCESSOS DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E44
Para Pressman (2011, p. 63), inicialmente, é necessário desenvolver um pro-
jeto rápido que deve se concentrar em uma representação daqueles aspectos do 
software que serão visíveis aos usuários finais, como, o layout da interface com 
o usuário.
O desenvolvimento incremental apresenta algumas vantagens importantes em 
relação ao modelo em cascata. Sommerville (2011, p. 22) aponta três vantagens: 
(1) se o cliente mudar seus requisitos, o custo será reduzido, pois a quantidade de 
análise e documentação a ser refeita é menor do que no modelo em cascata; (2) 
é mais fácil obter um retorno dos clientes sobre o desenvolvimento que foi feito, 
pois os clientes vão acompanhando o desenvolvimento do software à medida 
que novas versões são apresentadas a eles; (3) os clientes podem começar a uti-
lizar o software logo que as versões iniciais forem disponibilizadas, o que não 
acontece com o modelo cascata.
Entretanto, a partir de uma perspectiva de engenharia e de gerenciamento, 
existem alguns problemas:
1. O processo não é visível: os gerentes necessitam que o desenvolvimento 
seja regular, para que possam medir o progresso. Se os sistemas são desen-
volvidos rapidamente, não é viável produzir documentos que reflitam 
cada versão do sistema.
2. Os sistemas frequentemente são mal estruturados: a mudança constante 
tende a corromper a estrutura do software. Incorporar modificações no 
software torna-se cada vez mais difícil e oneroso.
3. Podem ser exigidas ferramentas e técnicas especiais: elas possibilitam 
rápido desenvolvimento, mas podem ser incompatíveis com outras ferra-
mentas ou técnicas, e relativamente poucas pessoas podem ter a habilitação 
necessária para utilizá-las.
Para sistemas pequenos (com menos de 100 mil linhas de código) ou para sis-
temas de porte médio (com até 500 mil linhas de código), com tempo de vida 
razoavelmente curto, a abordagem incremental de desenvolvimento talvez seja a 
melhor opção. Contudo, para sistemas de grande porte, de longo tempo de vida, 
nos quais várias equipes desenvolvem diferentes partes do sistema, os problemas 
de se utilizar o desenvolvimento incremental se tornam particularmente graves. 
Modelos de Processo de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
45
Para esses sistemas, é recomendado um processo misto, que incorpore as melho-
res características do modelo de desenvolvimento em cascata e do incremental, 
ou ainda algum outro modelo disponível na literatura.
Na literatura referente a modelos de processo de software pode-se encontrar 
a prototipação como um exemplo de abordagem incremental.
ENGENHARIA DE SOFTWARE ORIENTADA A REUSO
Na maioria dos projetos de software, ocorre algum reuso de software, pois, 
normalmente, a equipe que trabalha no projeto conhece projetos ou códigos 
análogos ao que está sendo desenvolvido. Ela busca esses códigos, faz as modi-
ficações conforme a necessidade do cliente e os incorporam em seus sistemas. 
Independentemente do processo de software que está sendo utilizado, pode ocor-
rer esse reuso informal.
Porém, nos últimos anos, uma abordagem para desenvolvimento de software, 
com foco no reuso de software existente tem emergido e se tornado cada vez 
mais utilizada. A abordagem orientada a reuso conta com um grande número 
de componentes de software reutilizáveis, que podem ser acessados, e com um 
framework de integração para esses componentes. Às vezes, esses componen-
tes são sistemas propriamente ditos (sistemas COTS – commercial off-the-shelf 
- sistemas comerciais de prateleira), que podem ser utilizados para proporcionar 
funcionalidade específica, como formatação de textos, cálculo numérico, entre 
outros (SOMMERVILLE, 2011, p. 23).
“Em todo processo há um cliente, pois, sem cliente, um processo deixa de 
ter sentido.”
(V. Daniel Hunt)
PROCESSOS DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E46
O modelo genérico de processo baseado em reuso é mostrado na figura 2 
(SOMMERVILLE, 2007, p.46). Note que, embora as etapas de especificação de 
requisitos e de validação sejam comparáveis com outros processos, as etapas 
intermediárias em um processo orientado a reuso são diferentes. 
Figura 2: Modelo genérico de processo baseado em reuso
Especi�cação de 
resquisitos
Análise de 
componentes
Modi�cação de 
requisitos
Projeto de sistema 
com reuso
Desenvolvimento e 
integração
Validação de 
sistema
Fonte: adaptado de Sommerville (2007).
Conforme Sommerville (2011, p.23), essas etapas são:
1. Análise de componentes: considerando a especificação de requisitos, é feita 
uma busca de componentes para implementar essa especificação. Pode ser 
que não sejam encontrados componentes que atendam a toda especificação de 
requisitos, ou seja, pode fornecer somente parte da funcionalidade requerida.
2. Modificação de requisitos: no decorrer dessa etapa, os requisitos são 
analisados, levando-se em consideração as informações sobre os com-
ponentes que foram encontrados na etapa anterior. Se for possível, os 
requisitos são, então, modificados para refletir os componentes disponí-
veis. Quando isso não for possível, ou seja, quando as modificações forem 
impossíveis, a etapa de análise de componentes deverá ser refeita, a fim 
de procurar outras soluções.
Modelos de Processo de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
47
3. Projeto do sistema com reuso: durante essa etapa, o framework do sis-
tema é projetado ou então alguma infraestrutura existente é reutilizada. 
Os projetistas levam em consideração os componentes que são reusados 
e organizam o framework para tratar desse aspecto. Se os componentes 
reusáveis não estiverem disponíveis, pode ser necessário que um novo 
software deva ser projetado.
4. Desenvolvimento e integração: nessa etapa, o software que não puder ser 
comprado deverá ser desenvolvido, e os componentes e sistemas COTS 
serão integrados, a fim de criar um novo sistema. A integração de siste-
mas, nessa abordagem, pode ser parte do processo de desenvolvimento, 
em vez de uma atividade separada.
Deve-se tomar muito cuidado ao utilizar essa abordagem, pois não se tem como 
evitar as alterações nos requisitos dos usuários e isso pode acabar levando ao 
desenvolvimento de um sistema que não atenda as suas reais necessidades. Há 
também o fato de que o controle da evolução do sistema fique comprometido,pois as novas versões dos componentes reusáveis não estão sob o controle da 
organização que as está utilizando.
De qualquer forma, a abordagem baseada em reuso tem a vantagem de pro-
piciar a entrega mais rápida do software, pois reduz sensivelmente a quantidade 
de software que a empresa deve desenvolver, reduzindo, consequentemente, os 
custos de desenvolvimento, bem como os seus riscos.
©shutterstock
PROCESSOS DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E48
ATIVIDADES BÁSICAS DO PROCESSO DE SOFTWARE
Caro(a) aluno(a), estudando os modelos de processo de software apresentados 
anteriormente, é possível notar que algumas atividades estão presentes em todos 
eles, somente, às vezes, essas atividades estão organizadas de forma diferente, 
dependendo do processo de software que está sendo considerado. Sommerville 
(2011, p. 24) afirma que no modelo cascata essas atividades são organizadas de 
forma sequencial, ao passo que no desenvolvimento incremental são intercala-
das. A forma como essas atividades serão realizadas 
depende do tipo de software, das pessoas e da orga-
nização envolvida.
São quatro as atividades básicas do processo de 
software: a especificação, o projeto e a implemen-
tação, a validação e a evolução. E a partir de agora, 
iremos detalhar, de forma genérica, sem conside-
rar um processo de software em específico, cada 
uma dessas atividades.
Modelos de Processos de Engenharia de Software
O artigo de Lessa e Lessa Jr. trata sobre a Engenharia de software e como 
surgiram os problemas para corrigir com relação ao desenvolvimento de 
projetos de software, a partir desse surgimento modelos de processos e 
guia de desenvolvimentos foram criados para otimização do processo de 
desenvolvimento do software. O artigo também mostrará alguns modelos 
de processos e um guia chamando de SWEBOK, que foi criado por membros 
da comunidade científica devido ao vasto material que envolve a área. Vale 
a pena a leitura. 
Fonte: Lessa e Lessa Jr. (online)2
Atividades Básicas do Processo de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
49
ESPECIFICAÇÃO DE SOFTWARE
A especificação de software, ou engenharia de requisitos, é a primeira atividade 
básica de um processo de software e tem como objetivo definir quais funções 
são requeridas pelo sistema e identificar as restrições sobre a operação e o desen-
volvimento desse sistema. Essa atividade é muito importante e crítica, pois se a 
definição dos requisitos não for bem realizada, com certeza problemas posterio-
res no projeto e na implementação do sistema irão acontecer.
Segundo Sommerville (2011, p.24), “o processo de engenharia de requisitos 
tem como objetivo produzir um documento de requisitos acordados que espe-
cifica um sistema que satisfaz os requisitos dos stakeholders”. 
O processo de engenharia de requisitos é composto por quatro fases, con-
forme descreve Sommerville (2007, p. 50). A unidade seguinte tratará com mais 
detalhes sobre esse assunto.
1. Estudo de viabilidade: uma avaliação é realizada para verificar se as 
necessidades dos usuários, que foram identificadas, podem ser atendi-
das utilizando as atuais tecnologias de software e hardware, disponíveis 
na empresa. Esse estudo deve indicar se o sistema proposto será viá-
vel, do ponto de vista comercial, e também, se poderá ser desenvolvido 
considerando restrições orçamentárias, caso existam. Um estudo de 
viabilidade não deve ser caro e demorado, pois é a partir do seu resul-
tado que a decisão de prosseguir com uma análise mais detalhada deve 
ser tomada.
2. Levantamento e análise de requisitos: nesta fase é necessário levantar os 
requisitos do sistema pela observação de sistemas já existentes, pela con-
versa com usuários e compradores em potencial, pela análise de tarefas e 
assim por diante. Essa fase pode envolver o desenvolvimento de um ou 
mais diferentes modelos e protótipos de sistema. Isso pode ajudar a equipe 
de desenvolvimento a compreender melhor o sistema a ser especificado.
PROCESSOS DE SOFTWARE
Reprodução proibida. A
rt. 184 do Código Penal e Lei 9.610 de 19 de fevereiro de 1998.
IIU N I D A D E50
3. Especificação de requisitos: é a atividade de traduzir as informações cole-
tadas durante a fase anterior em um documento que defina um conjunto 
de requisitos. Tanto os requisitos dos usuários quanto os requisitos de sis-
tema podem ser incluídos nesse documento. De acordo com Sommerville 
(2011, p. 24), os requisitos dos usuários são declarações abstratas dos 
requisitos do sistema tanto para o cliente quanto para os usuários finais 
do sistema; os requisitos do sistema são descrições mais detalhadas das 
funcionalidades a serem fornecidas. Na próxima unidade, trataremos com 
mais detalhes sobre requisitos.
4. Validação de requisitos: essa atividade verifica os requisitos quanto à sua 
pertinência, consistência e integralidade. Durante o processo de valida-
ção, os requisitos que apresentarem problemas devem ser corrigidos, para 
que a documentação de requisitos fique correta.
As atividades de análise, definição e especificação de requisitos são intercaladas, 
ou seja, elas não são realizadas seguindo uma sequência rigorosa, pois, com cer-
teza, novos requisitos surgem ao longo do processo.
PROJETO E IMPLEMENTAÇÃO DE SOFTWARE
Segundo Sommerville (2011, p. 25), “O estágio de implementação do desenvol-
vimento de software é o processo de conversão de uma especificação do sistema 
em um sistema executável”. Essa etapa sempre envolve processos de projeto e 
programação de software, porém, se uma abordagem incremental de desenvolvi-
mento for utilizada, poderá também envolver o aperfeiçoamento da especificação 
de software, em que os requisitos foram definidos.
Para Pressman (2011, p. 206), o projeto de software cria uma representação 
ou modelo do software, fornecendo detalhes sobre a arquitetura do software, as 
estruturas de dados, interfaces e componentes fundamentais para implementar 
o sistema. O projeto de software é aplicado independentemente do modelo de 
processo de software que está sendo utilizado, ou seja, se estiver sendo utilizado 
o modelo em cascata ou a abordagem incremental.
Atividades Básicas do Processo de Software
Re
pr
od
uç
ão
 p
ro
ib
id
a.
 A
rt
. 1
84
 d
o 
Có
di
go
 P
en
al
 e
 L
ei
 9
.6
10
 d
e 
19
 d
e 
fe
ve
re
iro
 d
e 
19
98
.
51
O início do projeto ocorre assim que os requisitos tiverem sido analisados e 
modelados, ou seja, assim que a modelagem do sistema tiver sido realizada. Com 
base no documento de requisitos, o engenheiro de software, na fase de modelagem 
do sistema, deverá elaborar os diagramas da UML – Unified Modeling Language 
(por exemplo, o Diagrama de Caso de Uso e o Diagrama de Classes). Na fase 
de projeto do sistema, o engenheiro de software deverá: i) definir o Diagrama 
Geral do Sistema; ii) elaborar as Interfaces com o Usuário (telas e relatórios) e 
iii) desenvolver um conjunto de especificações de casos de uso, sendo que, essas 
especificações devem conter detalhes suficientes para permitir a codificação. 
Geralmente, durante o projeto, o analista de sistemas terá que definir cada com-
ponente do sistema ao nível de detalhamento que se fizer necessário para a sua 
implementação em uma determinada linguagem de programação.
A programação, normalmente começa como era de se esperar, quando ter-
mina a atividade de projeto. A programação, ou fase de implementação de um 
projeto típico, envolve a escrita de instruções em Java, C++, C# ou em alguma 
outra linguagem de programação para implementar o que

Outros materiais

Materiais relacionados

Perguntas relacionadas

Materiais recentes

Perguntas Recentes