Engenharia de Software I

Prévia do material em texto

1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ENGENHARIA DE SOFTWARE I 
 
Carlos Helmar Duarte 
 
 
 
 
 
 
 
 
 
2 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Carlos Helmar Duarte 
 
Mestre em Educação pela PUC/MG - Pontifícia Universidade Católica de Minas Gerais, 
especialista em Educação, Comunicação e Tecnologia, pela UEMG - Universidade do 
Estado de Minas Gerais. Graduado em Pedagogia pela Universidade do Estado de Minas 
Gerais e graduado em Análise e Desenvolvimento de Sistemas pela UNOPAR - Universidade 
do Norte do Paraná. Tutor à distância e presencial em cursos de graduação em Pedagogia 
e Cursos de Extensão na área de Educação e Tecnologia desde 2006. Professor 
Pesquisador e Designer Instrucional dos cursos de EAD da Universidade do Estado de Minas 
Gerais. Tem experiência na docência na área de Educação com os conteúdos de 
Matemática e Informática para o ensino Fundamental e Médio; e Educação Tecnológica 
para o ensino superior. Integrante do grupo de estudos ETCS - Educação, Tecnologia, 
Ciências e Sociedade da PUC/MG. Participou efetivamente do NECT - Núcleo de Estudos 
sobre Comunicação e Tecnologia da UEMG, de 2003 a 2007. Diretor da Divisão de Apoio 
Administrativo do Departamento de Administração de Pessoal da UFMG – Universidade 
Federal de Minas Gerais, desde 2010. 
ENGENHARIA DE SOFTWARE I 
1ª edição 
Ipatinga – MG 
2023 
 
 
 
 
 
 
 
 
 
3 
 
 
FACULDADE ÚNICA EDITORIAL 
 
Diretor Geral: Valdir Henrique Valério 
Diretor Executivo: William José Ferreira 
Ger. do Núcleo de Educação a Distância: Cristiane Lelis dos Santos 
Coord. Pedag. da Equipe Multidisciplinar: Gilvânia Barcelos Dias Teixeira 
Revisão Gramatical e Ortográfica: Izabel Cristina da Costa 
Revisão/Diagramação/Estruturação: Bruna Luiza Mendes Leite 
 Fernanda Cristine Barbosa 
 Guilherme Prado Salles 
 Lívia Batista Rodrigues 
Design: Bárbara Carla Amorim O. Silva 
 Élen Cristina Teixeira Oliveira 
 Maria Eliza Perboyre Campos 
 
 
 
 
 
 
© 2023, Faculdade Única. 
 
Este livro ou parte dele não podem ser reproduzidos por qualquer meio sem Autorização 
escrita do Editor. 
 
 
 
Ficha catalográfica elaborada pela bibliotecária Melina Lacerda Vaz CRB – 6/2920. 
 
 
 
 
 
NEaD – Núcleo de Educação a Distância FACULDADE ÚNICA 
Rua Salermo, 299 
Anexo 03 – Bairro Bethânia – CEP: 35164-779 – Ipatinga/MG 
Tel (31) 2109 -2300 – 0800 724 2300 
www.faculdadeunica.com.br
http://www.faculdadeunica.com.br/
 
 
 
 
 
 
 
 
 
4 
 
 
Menu de Ícones 
Com o intuito de facilitar o seu estudo e uma melhor compreensão do conteúdo 
aplicado ao longo do livro didático, você irá encontrar ícones ao lado dos textos. Eles 
são para chamar a sua atenção para determinado trecho do conteúdo, cada um 
com uma função específica, mostradas a seguir: 
 
 
 
São sugestões de links para vídeos, documentos 
científicos (artigos, monografias, dissertações e teses), 
sites ou links das Bibliotecas Virtuais (Minha Biblioteca 
e Biblioteca Pearson) relacionados com o conteúdo 
abordado. 
 
Trata-se dos conceitos, definições ou afirmações 
importantes nas quais você deve ter um maior grau 
de atenção! 
 
São exercícios de fixação do conteúdo abordado 
em cada unidade do livro. 
 
São para o esclarecimento do significado de 
determinados termos/palavras mostradas ao longo 
do livro. 
 
Este espaço é destinado para a reflexão sobre 
questões citadas em cada unidade, associando-o a 
suas ações, seja no ambiente profissional ou em seu 
cotidiano. 
 
 
 
 
 
 
 
 
 
5 
 
 
SUMÁRIO 
 
ENGENHARIA DE SOFTWARE: CONTEXTUALIZAÇÃO HISTÓRICA E 
CONCEITOS BÁSICOS ............................................................................... 8 
1.1 HISTÓRIA E CONCEITO DE SOFTWARE ............................................................. 8 
1.2 CONTEXTO HISTÓRICO DO SOFTWARE ............................................................ 9 
1.3 TRABALHANDO OS CONCEITOS BÁSICOS DA ENGENHARIA DE SOFTWARE
 ......................................................................................................................... 12 
1.3.1 Conceitos iniciais ................................................................................................. 12 
1.3.2 Sistemas sociotécnicos ....................................................................................... 13 
1.4 ENGENHARIA DE SOFTWARE NOS DIAS ATUAIS ............................................ 16 
FIXANDO O CONTEÚDO ................................................................................. 20 
CONCEITOS E MODELOS DE PROCESSO DE SOFTWARE ........................ 24 
2.1 MODELOS DE PROCESSOS DE SOFTWARES .................................................... 24 
2.2 CICLOS DE VIDA DE UM SOFTWARE ............................................................... 26 
2.2.1 Modelo em Cascata .......................................................................................... 27 
2.2.2 Prototipação ........................................................................................................ 28 
2.2.3 Modelo de desenvolvimento Baseado em Componentes ........................ 29 
2.2.4 Entrega Incremental ........................................................................................... 31 
2.2.5 Modelo Espiral ...................................................................................................... 32 
2.3 ATIVIDADES DE PROCESSO DE SOFTWARE .................................................... 34 
2.3.1 Especificação de software ............................................................................... 34 
2.3.2 Implementação de software ............................................................................ 35 
2.3.3 Validação de software ...................................................................................... 36 
2.3.4 Evolução (manutenção) de software ............................................................ 38 
FIXANDO O CONTEÚDO ............................................................................. 2044 
INTRODUÇÃO AO GERENCIAMENTO DE PROJETOS .............................. 46 
3.1 VISÃO GERAL E CONCEITOS DO GERENCIAMENTO DE PROJETOS ................ 46 
3.2 ATIVIDADES, PLANEJAMENTO E CRONOGRAMA DE PROJETOS DE SOFTWARES
 ............................................................................................................................ 49 
3.2.1 Visão geral das atividades de gerenciamento de projeto de software..... 50 
3.2.2 Visão geral do planejamento de gerenciamento de projeto de software
 ................................................................................................................................... 51 
3.2.3 Visão geral do cronograma de gerenciamento de projeto de software .. 53 
3.3 ANÁLISE DE RISCOS ........................................................................................... 55 
FIXANDO O CONTEÚDO .................................................................................... 59 
ENGENHARIA DE REQUISITOS ................................................................. 63 
4.1 ESTUDOS DE REQUISITOS: CONCEITOS E IMPORTÂNCIA ................................. 63 
4.1.1 Importância do estudo de requisitos ................................................................. 64 
4.1.2 Engenharia de Requisitos ..................................................................................... 65 
4.2 REQUISITOS DE UM SOFTWARE: CARACTERÍSTICAS GERAIS, REQUISITOS 
FUNCIONAIS E NÃO FUNCIONAIS .................................................................... 67 
4.2.1 Características gerais ............................................................................................ 67 
4.2.2 Requisitos Funcionais .............................................................................................68 
4.2.3 Requisitos Não funcionais ..................................................................................... 70 
4.3 ELICITAÇÃO E ANÁLISE DE REQUISITOS............................................................ 73 
4.3.1 Levantamento de requisitos ................................................................................ 74 
4.3.2 Análise de requisitos .............................................................................................. 76 
4.3.3 Documentação de requisitos .............................................................................. 78 
4.4 Validação de requisitos ................................................................................... 79 
FIXANDO O CONTEÚDO .................................................................................... 82 
UNIDADE 
01 
UNIDADE 
02 
UNIDADE 
03 
UNIDADE 
04 
 
 
 
 
 
 
 
 
 
6 
 
 
INTRODUÇÃO AO ESTUDO DE PROJETOS ORIENTADO A OBJETOS (UML - 
UNIFIED MODELING LANGUAGE) ........................................................... 86 
5.1 VISÃO GERAL DA MODELAGEM ORIENTADA A OBJETOS............................... 86 
5.2 CLASSES, ATRIBUTOS E OPERAÇÕES ................................................................. 88 
5.2.1 Classes ...................................................................................................................... 88 
5.2.2 Atributos ................................................................................................................... 89 
5.2.3 Operações .............................................................................................................. 90 
5.3 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE COM UML ...................... 93 
5.3.1 Contexto de sistema e modelos de uso ............................................................ 94 
5.3.2 Projeto de arquitetura ........................................................................................... 95 
5.3.3 Identificação dos objetos principais do sistema .............................................. 96 
5.3.4 Modelo de projetos ............................................................................................... 97 
5.3.5 Especificar interfaces de objetos ........................................................................ 97 
FIXANDO O CONTEÚDO .................................................................................... 99 
MODELAGEM BÁSICA: DIAGRAMAS UML .................................. 103 
6.1 CONCEITOS E MODELOS ................................................................................. 103 
6.2 DIAGRAMAS ESTRUTURAIS ............................................................................... 104 
6.2.1 Diagrama de Classes ......................................................................................... 105 
6.2.2 Diagrama de Objetos ........................................................................................ 107 
6.3 DIAGRAMAS COMPORTAMENTAIS ................................................................. 108 
6.3.1 Diagrama de Caso de Uso ............................................................................... 109 
6.3.2 Diagrama de Atividades ................................................................................... 112 
6.3.3 Diagramas de interação ................................................................................... 115 
FIXANDO O CONTEÚDO ............................................................................................. 118 
RESPOSTAS DO FIXANDO O CONTEÚDO .................................... 122 
REFERÊNCIAS................................................................................. 123 
 
 
 
UNIDADE 
05 
UNIDADE 
06 
 
 
 
 
 
 
 
 
 
7 
 
 
CONFIRA NO LIVRO 
 
A unidade I tem como objetivo vincular o conhecimento sobre o 
termo “Software” à sua origem e a sua aplicação, a partir de uma 
contextualização histórica do termo. Serão discutidos também 
nesta unidade os principais conceitos e o contexto nos dias atuais 
sobre a Engenharia de Software. 
A unidade II tem como objetivo discutir os principais conceitos e 
modelos de processo e os ciclos de vida de um software, (Clássico, 
prototipação, espiral, etc.). Serão abordadas também as 
atividades do processo de um software, desde a especificação até 
a sua validação. 
 
 
A unidade III aborda uma visão geral e os principais conceitos 
introdutórios sobre gerenciamento de projetos. Será discutida nessa 
unidade, além das atividades, do planejamento e do cronograma, 
a análise de riscos dos projetos em engenharia de software. 
Na unidade IV o objetivo é discutir a Engenharia de Requisitos. Serão 
abordados os principais conceitos e a importância da Engenharia 
de Requisitos e para isso serão caracterizados os requisitos 
funcionais e não funcionais de um software, além de propor uma 
discussão sobre a elicitação e análise de requisitos. 
 
 
 
 
 
 
A unidade V tem como objetivo apresentar uma visão geral da 
modelagem orientada a objetos – UML. Para isso, propõe-se discutir 
os conceitos de classe, atributos e operações, além de introduzir 
definições sobre o processo de desenvolvimento de projeto de 
software com UML. 
 
A unidade VI tem como objetivo, a partir dos conceitos 
apresentados na unidade V, definir e caracterizar os diagramas da 
modelagem básica em UML. Serão apresentados os dois grupos de 
diagramas (estrutural e comportamental) e alguns seus de 
principais subtipos. 
 
 
 
 
 
 
 
 
 
 
 
 
8 
 
 
ENGENHARIA DE SOFTWARE: 
CONTEXTUALIZAÇÃO HISTÓRICA E 
CONCEITOS BÁSICOS 
 
 
 
1.1 HISTÓRIA E CONCEITO DE SOFTWARE 
Quando as pessoas pensam no termo software, a primeira associação feita é 
com programas de computador. Tecnicamente, software pode ser definido como 
sendo um conjunto de componentes lógicos e de programas presentes em 
computadores, celulares, carros, dentre outros. Autores como Sommerville (2007), 
Pfleeger(2004), e Pressman (2011) consideram esse conceito simplista, e descrevem 
que o conceito de software se refere também a todos os dados de documentação 
do projeto e configurações associados aos sistemas, os quais são necessários para 
que o programa funcione corretamente. 
Para Pressman (2011, p. 31): 
 
Hoje, o software assume um duplo papel. Ele é um produto e, ao 
mesmo tempo, o veículo para distribuir um produto. Como produto, 
fornece o potencial computacional representado pelo hardware ou, 
de forma mais abrangente, por uma rede de computadores que 
podem ser acessados por hardware local. (...) Como veículo de 
distribuição do produto, o software atua como a base para o controle 
do computador (sistemas operacionais), a comunicação de 
informações (redes) e a criação e o controle de outros programas 
(ferramentas de software e ambientes). 
 
O software é responsável pelo produto mais importante nas relações dos seres 
humanos atualmente, a informação. Para contexto apresentado, e visando os 
objetivos iniciais dessa unidade de contextualização e caracterização do termo 
software, é importante descrever o significado de sistema. Na engenharia de 
software, sistema pode ser definido como sendo “um conjunto intencional de 
componentes inter-relacionados que funcionam juntos para atingir certo objetivo” 
(SOMMERVILLE, 2007, p.14). Para o autor essa definição de sistema abrange um vasto 
universo de sistemas, desde os mais simples aos mais complexos. 
Após as definições de software e sistema, é ilustrado na figura 1 um esquema 
que resume o sistema de software. 
UNIDADE 
01 
 
 
 
 
 
 
 
 
 
 
9 
 
 
Figura 1: Definição de sistema de Software 
 
Fonte: Adaptado de Sommerville (2007, p. 04) 
 
1.2 CONTEXTO HISTÓRICO DO SOFTWARE 
A evolução do software ocorreu, desde o seu início, de forma acelerada. O 
objetivo principal no começo não estava diretamente relacionado com a interação 
entre o usuário e a máquina.O maior investimento estava centralizado em um 
hardware que pudesse gerar processamento de dados em grande volume, deixando 
assim o desenvolvimento do software em segundo plano. 
Com o passar do tempo os conceitos sobre o uso das máquinas sofreram 
mudanças, e as necessidades dos usuários têm um papel importante nesse novo 
cenário que se configura com a evolução tecnológica. A exigência passa a ser por 
equipamentos menores e com maior eficiência no desempenho das atividades, ou 
seja, buscam-se, além do desenvolvimento do hardware, maiores investimentos na 
produção dos softwares. 
Até o começo da década de 70, o desenvolvimento estava centrado na parte 
física da máquina, dessa forma a evolução dos softwares e as modificações ainda 
não eram evidentes para os usuários. A mudança dessa concepção começa a 
ocorrer com o aparecimento dos computadores multiusuários, os quais possibilitavam 
um processamento de dados em tempo real. 
Na figura 2, é apresentado um resumo da linha do tempo sobre a evolução 
dos softwares e hardwares. 
 
 
 
 
 
 
 
 
 
 
 
 
10 
 
 
Figura 2: Evolução software/hardware 
 
Fonte: Adaptado de Stallings (2010, p.12-27). 
 
Na figura 2, a primeira geração de computadores (1940), tem como 
característica principal a utilização de válvulas e programação baseada no sistema 
binário, uma combinação que gastava a maior parte do tempo no processamento 
de dados. Foi nessa geração que houve a evolução do armazenamento de dados 
em cartões perfurados para as fitas magnéticas. 
Na segunda geração de computadores (1950), ocorre o aparecimento das 
máquinas com transistores, considerado uma revolução na época. Algumas 
características importantes dos transistores era o fato de serem mais rápidos e 
confiáveis e terem um consumo menor de energia. Nessa geração, além do alto 
custo dos equipamentos, desperdiçava-se muito tempo no processo de operação 
das maquinas, dessa forma uma das soluções que as pessoas encontraram para 
reduzir o tempo desperdiçado foi o sistema de processamento em lotes. 
 
A ideia era reunir em uma bandeja (tray) um conjunto de jobs da sala 
de submissão e então le ̂-los em uma fita magnética usando um 
computador relativamente pequeno e barato, como o IBM 1401, que 
era muito bom para ler cartões, copiar fitas e imprimir a saída, mas 
péssimo para cálculos numéricos (TANENBAUM; WOODHULL, 2008 p. 
27). 
 
 
 
 
 
 
 
 
 
11 
 
 
 
 
Na terceira geração de computadores (1958) as máquinas começam a ser 
equipadas com os circuitos integrados - os microchips, feitos de silício. Uma das 
principais evoluções nessa época foi à construção de equipamentos menores e mais 
baratos. 
De acordo com Stallings (2010, p.26) “Além da terceira geração, existe pouco 
consenso geral sobre a definição das gerações de computadores”. De acordo com 
o autor, há diversas gerações posteriores, todas com base nos avanços da tecnologia 
do circuito integrado. Um fator importante no contexto das gerações posteriores 
aconteceu em 1971, com o aparecimento do microprocessador, quando a Intel 
descobriu o chip (4004), primeiro chip que possuía todos os componentes de um 
processador. Isso possibilitou avanços, conforme afirma o autor, “no processamento 
de imagens, reconhecimento de voz, videoconferência, criação de multimídia, 
desenvolvimento em arquivos de voz e vídeo e modelagem de simulação”. (P. 29) 
A partir da década de 90, com os avanços na estrutura e composição do 
hardware, começam a surgir novas exigências das pessoas e organizações, o que 
gerou maiores desafios no desenvolvimento de softwares. O aparecimento e a 
evolução da rede mundial de computadores – Internet trouxe consigo uma nova 
maneira de se buscar e disponibilizar o dado, a informação e o conhecimento, o que 
exigiu, na época, um desenvolvimento de software voltado para a eficiência. 
Nesse contexto, há uma mudança brusca nas estratégias para o 
desenvolvimento de software, ou seja, no começo, o desenvolvedor tinha suas 
próprias técnicas, e o software era construído com base na sua experiência pessoal, 
no entanto, nos dias atuais para se garantir uma qualidade na produção de um 
software é necessário o uso de técnicas diferenciadas, um conjunto de metodologias 
e um bom trabalho em equipe. Neste momento é que surge a Engenharia de 
Software. 
 
BUSQUE POR MAIS 
Para entender mais sobre o sistema de processamento em lotes, recomenda-se a leitura 
das páginas 26 e 27 do livro, Sistemas operacionais: projeto e implementação de Andrew 
S. Tanenbaum, Albert S. Woodhull. O livro está disponível na biblioteca virtual, no link: 
https://shre.ink/HZ2Y. Acesso em: 20 jan. 2023. 
 
https://shre.ink/HZ2Y
 
 
 
 
 
 
 
 
 
12 
 
 
 
 
Na seção 1.2 serão discutidos conceitos e termos com o objetivo de elucidar 
o campo de trabalho com projetos de desenvolvimento de software associados ao 
campo da Engenharia de Software. 
 
1.3 TRABALHANDO OS CONCEITOS BÁSICOS DA ENGENHARIA DE SOFTWARE 
1.3.1 Conceitos iniciais 
Alguns conceitos iniciais referentes à elaboração e uso de softwares são 
importantes para o um melhor entendimento da área de estudo de Engenharia de 
Software. 
O conceito de engenharia no dicionário Priberam online refere-se ao 
“Conjunto de técnicas e métodos para aplicar o conhecimento técnico e científico 
na planificação, criação e manutenção de estruturas, máquinas e sistemas para 
benefício do ser humano”. A associação do conceito de engenharia e o conceito 
de software apresentado na seção 1.1 dessa unidade auxiliam em um melhor 
entendimento da definição proposta por Sommerville (2007) para o termo Engenharia 
de Software. Para o autor “A Engenharia de Software é uma disciplina de engenharia 
relacionada com todos os aspectos da produção de software, desde os estágios 
iniciais de especificação do sistema até sua manutenção, depois que este entrar em 
operação” (p.5). A Engenharia de Software está relacionada com os processos 
técnicos de desenvolvimento e gerenciamento de projeto de software, além de 
desenvolver também “ferramentas, métodos e teorias que apoiem a produção do 
software” (p.5). 
Ao longo dos tempos o processo de desenvolvimento de softwares tem 
passado por alterações significativas, uma evolução no tempo de elaboração, no 
desenvolvimento, na metodologia, nos ciclos de vidas e no custo dos projetos. 
Nesse contexto, vários fatores contribuíram para uma discussão mais 
Para saber mais sobre a história e desempenho de computadores, sugerimos a leitura da 
parte I, capítulo 2 “Evolução e desempenho do computador” (páginas 12 a 45) do livro 
“Arquitetura e organização de computadores: Projeto para o desempenho” de William 
Stallings, disponível na biblioteca virtual no endereço eletrônico https://abrir.link/FVKNj. 
Acesso em: 20 jan. 2023. 
 
https://abrir.link/FVKNj
 
 
 
 
 
 
 
 
 
13 
 
 
aprofundada sobre as atividades de desenvolvimento dos softwares nas últimas 
décadas. Esses fatores estão diretamente relacionados, primeiro, com às altas 
complexidades do sistema que surgiram com a evolução do processamento das 
imagens e sons que foram integradas aos hardwares de pequeno porte; e segundo 
com as integrações, as quais ficaram cada vez mais evidentes nos diversos tipos de 
hardwares e de sistemas operacionais, seja para o uso no computador doméstico ou 
científico. 
 
1.3.2 Sistemas sociotécnicos 
Para um melhor entendimento das definições propostas para o termo de 
engenharia de software, serão apresentadas a seguir conceitos, termos e 
características dos sistemas sociotécnicos, que além de abordagens sobre 
componentes de hardware e software, incluem também, procedimentos e 
processos. 
As discussões descritas nesse livro sobre os sistemas sociotécnicos estão 
baseadas em Sommerville (2007). Para o autor, os sistemas sociotécnicos possuem 
propriedades de comportamentos fortemente interligados, isso significaque: 
 
O funcionamento com sucesso de cada componente depende do 
funcionamento dos outros componentes. Dessa forma, o software 
poderá operar somente se o processador estiver operacional. O 
processador somente poderá realizar a computação se o sistema de 
software que define essas funções tiver sido instalado com sucesso. 
(SOMMERVILLE, 2007, p.15) 
 
Uma característica no uso de sistema sociotécnicos é o fato de que as duas 
partes, o social e o técnico, funcionam para produzir resultados positivos, desta forma, 
é necessário um trabalho em conjunto na realização das tarefas de elaboração de 
produtos físicos como resultados sociais. 
O esquema da figura 3 apresenta uma visão geral em relação aos Sistemas 
Sociotécnicos baseado nas ideias de Sommerville (2007). 
 
 
 
 
 
 
 
 
 
 
 
 
 
14 
 
 
Figura 3: Visão geral dos Sistemas Sociotécnicos 
 
Fonte: Adaptado de Sommerville (2007, p. 14-27) 
 
As associações realizadas na figura 3 mostram as interligações e propriedades 
dos sistemas sociotécnicos, desde o projeto inicial até o fechamento das atividades 
do projeto. A seguir serão detalhadas características sobre cada fase ilustrado na 
figura 3. 
As propriedades emergências podem ser classificadas como funcionais e não 
funcionais. A primeira refere-se ao trabalho de todas as partes do sistema juntos 
buscando o mesmo objetivo e a segunda “ao comportamento do sistema em seu 
ambiente operacional” (SOMMERVILLE, 2007, p. 16). As propriedades emergentes são 
difíceis de serem avaliadas, mas trazem para o projeto itens importantes na 
construção e validação das atividades. São exemplos de propriedade emergentes: 
usabilidade, confiabilidade, proteção, desempenho, volume e proteção. 
A Engenharia de Sistemas envolve discussões na elaboração das atividades 
de todo o projeto, tais como: especificação, implementação, validação, 
implantação e manutenção dos sistemas. 
 
 
 
 
 
 
 
 
 
 
15 
 
 
 
 
Figura 4: Processo de Engenharia de Sistemas 
 
Fonte: Adaptado de Sommerville (2007, p.17-23) 
 
Na parte “social” do sistema referente à “organização, pessoas e sistemas de 
computadores” as mudanças de processos e de trabalho aponta a necessidade de 
se considerar o contexto no qual estão inseridos os usuários e o ambiente 
organizacional onde será utilizado o software. Nesse ponto, é preciso um estudo do 
perfil da organização interessada na elaboração do sistema, uma coleta de dados 
sobre os processos organizacionais da empresa e dos usuários envolvidos no uso do 
software. E, por último, a partir da coleta de dados, elaborar uma proposta de acordo 
Nesse ponto é importante diferenciar a engenharia de sistema de engenharia de 
software, para Sommerville (2007, p. 6) a “engenharia de sistemas é uma disciplina mais 
antiga que a engenharia de software”. Ao longo dos anos a pessoa tem realizado a 
especificação de sistemas complexos, com a evolução da tecnologia o número de 
softwares utilizados teve um expressivo aumento na produção de sistemas, dessa forma a 
técnica de engenharia de software tem sido usada no processo de engenharia de 
sistemas. O quadro 1 da seção 1.3 apresenta mais informações em relação as 
características e diferenciações da engenharia de software e engenharia de sistemas. 
 
 
 
 
 
 
 
 
 
 
16 
 
 
com as demandas do mercado. 
Os sistemas desenvolvidos com base em softwares legado possuem hardware, 
software, processos e procedimentos baseado em tecnologias mais antigas e 
obsoletas. Os sistemas legados incluem processos de negócios, software de 
aplicação, software de apoio e hardware de sistema. São “velhas formas de fazer 
coisas que dificilmente são mudadas porque estão baseadas em software legado”. 
(SOMMERVILLE, 2007, p.25). Os responsáveis pela empresa, associados a elaboração 
de políticas e procedimentos organizacionais, na maioria dos casos não substituem 
esse tipo de sistema por acreditarem que é grande o risco de perda de dados e 
informações. 
 
 
 
Nesse capítulo foram abordados alguns importantes conceitos e contextos 
para o entendimento inicial sobre a área de Engenharia de Software. No próximo 
capítulo será apresentado a Engenharia de Software no contexto dos dias atuais, 
descrevendo sobre o trabalho, a legislação e o campo profissional do engenheiro de 
software, bem como os desafios enfrentados no mercado de trabalho. 
 
1.4 ENGENHARIA DE SOFTWARE NOS DIAS ATUAIS 
Atualmente a engenharia de software tem se apresentado como uma área 
de grande importância no início, durante e na finalização de projetos de software, 
além de atuar também na manutenção. Essa importância se deve ao fato da equipe 
realizar atividades de coleta de dados junto ao sujeito e organização, atuar no 
“Os sistemas sociotécnicos incluem hardware de computador, software e pessoas, e são 
instalados dentro de uma organização. São projetados para auxiliar a organização a 
atingir um grande objetivo” (SOMMERVILLE, 2007, p. 27). Ao pensarmos na montagem de 
um ambiente com base na estrutura de sistema sociotécnicos, imaginamos um ambiente 
com uma dimensão técnica, pessoal e organizacional. Dimensão técnica, quando nos 
referimos a equipamentos físicos e virtuais, dimensão pessoal, quando a referência é de 
pessoas de uma equipe de trabalho envolvida no projeto e dimensão organizacional, 
quando pensamos na estrutura da organização onde o projeto será aplicado. Nesse 
contexto, que elementos podemos citar da estrutura de um sistema sociotécnicos? 
 
 
 
 
 
 
 
 
 
 
17 
 
 
processamento e análise de dados a partir de estratégias bem definidas, identificar 
possíveis falhas no software e elaborar soluções para resolvê-las. 
O quadro 1, mostra uma comparação entre as grandes áreas de formação 
em relação à tecnologia atualmente, situando a Engenharia de Software no 
contexto atual. 
 
Quadro 1: Caracterização das áreas de conhecimento: Engenharia de Software, Engenharia 
de Sistema, Ciências da Computação e Ciências da Informação 
Engenharia de 
Software 
Engenharia 
de Sistemas 
Ciências da 
Computação 
Ciências da 
Informação 
Preocupa-se com os 
problemas e soluções 
da prática da 
produção de 
softwares. 
Refere-se aos aspectos 
de desenvolvimento e 
da evolução e sistemas 
complexos. 
Dedica-se as 
teorias e aos 
métodos que 
constituem a 
base de 
computadores e 
sistemas de 
softwares. 
Refere-se à análise 
da formação do 
processo desde a 
informação até a 
transformação dos 
dados em 
conhecimento. 
Tem relação direta 
com o 
empreendedorismo e 
o mercado de 
trabalho. Elaboração 
de um software a 
partir do estudo de 
problemas. 
Está relacionada com o 
desenvolvimento de 
hardware, políticas e 
de processos de 
implantação dos 
sistemas. 
Tem uma 
relação direta 
com o meio 
acadêmico e 
científico como 
um todo, devido 
a concentração 
no estudo de 
teorias. 
Está diretamente 
relacionado com a 
gestão da 
informação dentro 
de empresas. 
Fonte: Elaborado pelo autor (2023) 
 
As classificações exibidas no quadro 1, mostram que as grandes áreas de 
conhecimento de tecnologia possuem relações entre si. Dessa forma, um bom 
projeto de software precisa ter a atenção e os cuidados de todos os profissionais 
envolvidos nas equipes. 
Na engenharia de software, algumas mudanças importantes ocorreram nos 
últimos anos, principalmente em relação à responsabilidade profissional e ética junto 
ao mercado de trabalho. No ano de 2018, o órgão responsável pelas Entidades de 
Fiscalização do Exercício das Profissões Liberais/Conselho Federal de Engenharia e 
Agronomia, publicou a Resolução nº 1.100 de 24 de maio de 2018, a qual “Discrimina 
as atividades e competências profissionais do engenheiro de software e insere o 
respectivo título na Tabela de Títulos Profissionais do Sistema Confea/Crea, para efeito 
de fiscalização do exercício profissional”. O decretoestabelece no seu artigo 2º que: 
 
 
 
 
 
 
 
 
 
 
18 
 
 
compete ao engenheiro de software as atribuições previstas no art. 7° 
da Lei nº 5.194, de 1966, combinadas com as atividades 1 a 18 do art. 
5º, §1º, da Resolução nº 1.073, de 19 de abril de 2016, referentes a 
requisitos de software, sistemas e soluções de software, evolução de 
software, integração local e remota de sistemas de software. 
 
 
 
 
De acordo com os estudos da Associação Brasileira das Empresas de Software 
– ABES, publicado no relatório anual do ano de 2021, o mercado de Hardware, 
Software e Serviços no Brasil cresceram 22,9% com um investimento de cerca de R$ 
200,3 bilhões (US$ 50,7 bilhões). O mesmo estudo aponta que mais de 70% das 
empresas no Brasil estão mais voltadas para a fabricação, desenvolvimento, 
comercialização e distribuição de softwares. 
Muitos desafios e responsabilidades se apresentam nos dias atuais para o 
profissional de engenharia de software. Sommerville (2007) destaca que os principais 
são: o desafio da heterogeneidade, da entrega e da confiança. 
Para o autor no desafio da heterogeneidade é preciso que “os sistemas de 
software operem como sistemas distribuídos, através das redes, que incluem 
diferentes tipos de computadores, com diferentes tipos de sistema de apoio” 
(SOMMERVILLE, 2007, p. 10). 
No desafio da entrega, é preciso aliar o tempo com a qualidade, ou seja, o 
software, “no ambiente de negócios de hoje deve apresentar resposta ágil e mudar 
rapidamente” (SOMMERVILLE, 2007, p.10), o software de apoio precisa acompanhar 
a velocidade das mudanças. 
Para saber mais sobre as responsabilidades e ética do engenheiro de software, consulte: 
1. Lei Nº 5.194, de 24 de dezembro de 1966. Regula o exercício das profissões de 
Engenheiro, Arquiteto e Engenheiro-Agrônomo, e dá outras providências. 
Fonte: https://abrir.link/dncaO. Acesso em: 20 jan. 2023. 
2. Resolução nº 1.073, de 19 de abril de 2016. Regulamenta a atribuição de títulos, 
atividades, competências e campos de atuação profissionais aos profissionais registrados 
no Sistema Confea/Crea para efeito de fiscalização do exercício profissional no âmbito 
da Engenharia e da Agronomia. 
Fonte: Publicado no DOU – Diário Oficial da União em: 22/04/2016, Edição: 76, Seção: 1, Página: 245. 
 
https://abrir.link/dncaO
 
 
 
 
 
 
 
 
 
19 
 
 
E o desafio da confiança, nesse ponto o autor reforça que é necessário 
“desenvolver técnicas que demonstrem que o software pode ter a confiança dos 
seus usuários” (SOMMERVILLE, 2007, p.10). 
Em resumo, a unidade I, contextualizou a história e apresentou o conceito de 
software e de engenharia de software. Foi descrito também a relação da engenharia 
de software com etapas de desenvolvimento e produção de um projeto de software. 
No final da unidade foi apresentado um pouco sobre a profissionalização do 
engenheiro de software, descrevendo a legislação que regulamentou a profissão e 
desafios nos dias atuais da área de engenharia de software. 
A seguir são propostas algumas questões sobre o conteúdo da unidade 01. 
 
 
 
 
 
 
 
 
 
 
20 
 
 
FIXANDO O CONTEÚDO 
1. A engenharia de sistemas está diretamente relacionada à execução e atividades 
de todo o projeto. Sobre esse assunto analise as proposições abaixo: 
I. Definição de requisitos: indicam que o sistema já pode ser iniciado, sendo liberado 
para colocar em funcionamento. 
II. Integração do Sistema: refere-se ao grupamento dos subsistemas para a 
construção do sistema completo. 
III. Evolução do sistema: relaciona-se ao período destinado a correção de erros dos 
requisitos e projetos de novas implementações. 
IV. Projeto de sistema: nessa parte da engenharia de sistemas a funcionalidade será 
fornecida pelos componentes do sistema. 
Estão corretas: 
a) I, II, III, IV. 
b) I, III, IV. 
c) II, III, IV. 
d) II e III. 
e) III e IV. 
 
2. “Os relacionamentos complexos entre os componentes de um sistema mostram 
que o sistema é mais do que simplesmente a soma de suas partes. Ele possui 
propriedades próprias do sistema como um todo” (SOMMERVILLE, 2007, p. 16). 
São exemplos de propriedades emergentes de um sistema: 
I. Complexidade. 
II. Usabilidade. 
III. Proteção. 
IV. Contextualidade. 
V. Volume. 
Estão corretas: 
a) I, II, III, IV e V. 
b) I, III, IV e V. 
c) II, III, IV e V. 
d) II, III e V. 
e) III e V. 
 
 
 
 
 
 
 
 
 
21 
 
 
 
3. A Resolução nº 1.100 de 24 de maio de 2018 indica em seu texto que as atribuições 
do engenheiro de software estão previstas no art. 7° da Lei nº 5.194, de 1966. De 
acordo com essa informação, analise as proposições abaixo: 
I. Estudos, projetos, análises, avaliações, vistorias, perícias, pareceres E divulgação 
técnica; 
II. Contração de pessoal para composição da equipe de projeto; 
III. Fiscalização de obras e serviços técnicos; 
IV. Direção de obras e serviços técnicos; 
V. Execução de obras e serviços técnicos. 
São atribuições do engenheiro de software: 
a) I, II, III, IV e V. 
b) I, III, IV e V. 
c) II, III, IV e V. 
d) II, III e IV. 
e) III e V. 
 
4. “A engenharia de software é uma disciplina de engenharia relacionada com todos 
os aspectos da produção de software, desde os estágios iniciais de especificação do 
sistema até sua manutenção, depois que este entrar em operação” (SOMMERVILLE, 
2007, p.5). 
Sobre o conceito e a importância do processo de engenharia de software analise as 
proposições abaixo: 
I. É preciso antes de projetar qualquer informação sobre o sistema criar ações práticas 
de elaboração do software. 
II. Um ponto chave no processo de engenharia de software é entender o problema 
antes de elaborar uma solução. 
III. Um projeto bem feito terá como resultados: qualidade e facilidade de manutenção 
do software. 
IV. A engenharia de software engloba um processo, métodos de gerenciamento e 
desenvolvimento de software, bem como ferramentas. 
Estão corretas: 
a) I, II, III e IV. 
b) I e IV. 
c) III e IV. 
 
 
 
 
 
 
 
 
 
22 
 
 
d) II e III. 
e) II, III e IV. 
 
5. (FUNIVERSA - 2009 - Adaptado) Assim como a Engenharia de Software, existe 
também na área de informática a chamada Ciência da Computação e a 
Engenharia de Sistemas. Assinale a alternativa que melhor apresenta a diferença 
entre Engenharia de Software, Ciência da Computação e Engenharia de Sistemas. 
a) A Ciência da Computação tem como objetivo o desenvolvimento de teorias e 
fundamentações. A Engenharia de Software se preocupa com as práticas de 
desenvolvimento de software. Já a engenharia de sistema está relacionada com 
políticas e processos de implantação dos sistemas. 
b) A Engenharia de Software trata da criação dos sistemas de computação 
(softwares) enquanto a Ciência da Computação está ligada ao desenvolvimento 
e criação de componentes de hardware, a Engenharia de Sistemas com a 
manutenção do sistema. 
c) A Engenharia de Software e a Engenharia de Sistema tratam dos sistemas com 
base em computadores, que inclui hardware e software, e a Ciência da 
Computação trata apenas dos aspectos de desenvolvimento de sistemas. 
d) A Ciência da Computação e a Engenharia de Sistema tratam dos sistemas com 
base em computadores, que inclui hardware e software, e a Engenharia de 
Software trata apenas dos aspectos de desenvolvimento de sistemas. 
e) A Ciência da Computação destina-se ao estudo e solução para problemas 
genéricos das áreas de rede e banco de dados e a Engenharia de Software e a 
Engenharia de Sistema restringem-se ao desenvolvimento de sistemas. 
 
6. Observe os trechos abaixo: 
“Toda a programação era feita em linguagem de máquina pura, frequentemente 
interligando fios através de painéis de conectores para controlar as funções básicas 
da máquina” (TANENBAUM e WOODHULL, 2008). 
O texto refere-se à: 
a) A primeira geração de computadores 
b) A geração de computadores dos circuitos integrados 
c)A geração de computadores que enfatizam o processamento em tempo real 
d) A quarta geração de computadores 
https://www.qconcursos.com/questoes-de-concursos/provas/funiversa-2009-iphan-analista-tecnologia-da-informacao
 
 
 
 
 
 
 
 
 
23 
 
 
e) A geração de computadores dos sistemas operacionais avançados. 
 
7. Sobre o conceito de software, analise as proposições abaixo: 
I. Os arquivos de configuração mostram no projeto como configurar o sistema 
planejado; 
II. A documentação do sistema refere-se às descrições da estrutura do sistema; 
III. Softwares disponíveis na web são fontes de coletas de informações pelos usuários; 
IV. Um projeto de software pode ser definido apenas como sendo programas de 
computadores. 
Estão corretas: 
a) I, II, III. 
b) I e III. 
c) II, III, IV. 
d) II e III. 
e) III e IV. 
 
8. (IPSEM– 2010) A evolução dos computadores foi caracterizada por avanços 
tecnológicos que marcaram cada geração. Sobre os avanços tecnológicos e suas 
respectivas gerações, é correto afirmar que: 
a) Na primeira geração a tecnologia dos circuitos integrados permitiu a substituição 
de centenas de componentes por uma única pastilha de silício. 
b) Na segunda geração nasceu o conceito de família de computadores compatíveis 
que permitiu a migração de sistemas para computadores mais potentes. 
c) Na terceira geração, os computadores eram baseados no uso de relés e válvulas 
permitindo a miniaturização. 
d) Na primeira geração a forma dominante de armazenamento secundário foi 
implementado através de fitas magnéticas que permitiam uma maior capacidade 
e velocidade. 
e) Na terceira geração apareceram os discos magnéticos para o armazenamento 
de dados possibilitando uma maior velocidade já que permitia acesso direto aos 
arquivos. 
 
 
 
 
 
 
 
 
 
 
 
 
24 
 
 
CONCEITOS E MODELOS DE 
PROCESSO DE SOFTWARE 
 
 
 
2.1 MODELOS DE PROCESSOS DE SOFTWARES 
 
Vimos na unidade I, conceitos, caracterização e uma contextualização do 
termo software, e de engenharia de software. Na unidade II, serão abordadas as 
relações da engenharia de software e as fases na construção do projeto de software. 
Essas fases consistem na apresentação de modelos de processos, do ciclo de vida e 
de atividades de processos software. 
O termo processo é definido por Pfleeger (2004 p.36), como sendo um 
“conjunto de tarefas ordenadas (...) uma série de etapas que envolvem atividades, 
restrições e recursos para alcançar a saída desejada”. 
A figura 6 ilustra algumas características de um processo segundo Pfleeger 
(2004). 
Figura 6: Características de um processo 
 
Fonte: Adaptado de Pfleeger (2004, p. 36-37). 
 
 
UNIDADE 
02 
 
 
 
 
 
 
 
 
 
25 
 
 
Em relação aos processos de software, para Sommerville (2007, p. 42), “os 
processos de software são complexos e, como todos os processos intelectuais e 
criativos, dependem de julgamento humano”. Apesar das muitas tentativas do uso 
de ferramentas para a automatização dos processos de software, os resultados são 
bastante limitados, isso por causa dos fatores relacionados à decisão nos projetos, ou 
seja, o uso do julgamento e da criatividade. 
Pressman (2011, p. 40) descreve que no contexto da engenharia de software, 
podemos dizer que o processo de desenvolvimento de software não é um processo 
fixo, rígido, estático, “ao contrário, é uma abordagem adaptável que possibilita às 
pessoas (a equipe de software) realizar o trabalho de selecionar e escolher o conjunto 
apropriado de ações e tarefas”. 
Existem vários tipos de processos de software, desta forma, um bom 
entendimento sobre o funcionamento desses processos auxilia na elaboração dos 
projetos. Existem algumas atividades que são comuns aos diversos tipos de processo, 
assim, é importante entende-las para uma melhor escolha do tipo que será 
selecionado para executar o projeto. Isso porque, confirma afirma Pfleeger (2004), 
“A estrutura do processo orienta nossas ações, permitindo-nos examinar, entender, 
controlar e aprimorar as atividades que compõem” (p.37), ou seja, é fundamental 
que o processo esteja alinhado a metodologia proposta no projeto de software. A 
figura 7 ilustra as atividades comuns no processo de software. 
 
 
 
 
 
 
 
 
 
 
26 
 
 
Figura 7: Atividades fundamentais e comuns no processo de software 
 
Fonte: Adaptado de Sommerville (2007, p.43) 
 
A figura 7 permite concluir que seja qual for o processo escolhido para compor 
o projeto de software, é necessário um processo que contenha a especificação, 
implementação, validação e evolução (manutenção) do projeto de software. As 
seções 2.2 e 2.3 dessa unidade descrevem conceitos e caracterizam os 
processos/ciclos de vida de um software. 
 
 
 
2.2 CICLOS DE VIDA DE UM SOFTWARE 
O ciclo de vida de um software é citado na literatura com diferentes 
denominações, dependendo da abordagem do autor. 
Nessa seção do livro serão abordados modelos de processo de software 
conforme o quadro 2, conforme pressupostos de Sommerville (2007). 
 
Para saber mais sobre o processo de software sugerimos a leitura do capítulo 4 do livro 
Engenharia de Software do autor Ian Sommerville (2007), páginas 42-49. O livro está 
disponível na Biblioteca Virtual: https://abrir.link/slcpS. Acesso em: 20 jan. 2023. 
 
https://abrir.link/slcpS
 
 
 
 
 
 
 
 
 
27 
 
 
Quadro 2: Modelos de Processos de Software 
Modelo em 
Cascata 
Prototipação Engenharia de 
Software 
Baseada em 
Componentes 
Entrega 
Incremental 
Desenvolvimento 
Espiral 
Especificação, 
desenvolvimento, 
validação e 
evolução (Fases 
de processos 
separados). 
Tem o 
objetivo de 
mostrar ao 
usuário, antes 
da entrega 
do produto 
final, um 
protótipo do 
sistema. 
Essa abordagem 
é baseada na 
existência de um 
número 
significativo de 
componentes 
reusáveis. 
A especificação, 
o projeto e a 
implementação 
de software são 
divididos em uma 
série de 
incrementos 
desenvolvidos 
um de cada vez. 
O 
desenvolvimento 
do sistema evolui 
em espiral para 
fora a partir de 
um esboço inicial 
até o sistema 
final. 
 
RUP – Ration 
Unified Process 
Modelo híbrido de processo. Traz elementos de todos os modelos de 
processo indicados nas colunas 1 a 5 desse quadro. 
Fonte: Adaptado de Sommerville (2007). 
 
 
 
A seguir serão descritos com mais detalhes os modelos de processo de 
software apresentados no quadro 2. 
 
2.2.1 Modelo em Cascata 
No modelo em Cascata, também conhecido como ciclo de vida clássico, na 
medida em que se executa o projeto, as informações são trocadas entre as fases e 
os problemas identificados são discutidos durante as fases do projeto. 
A figura 8 ilustra o modelo em cascata, observe que o modelo tem a 
característica de não linearidade. 
 
Uma organização de posse das ferramentas tecnológicas de processo disponíveis pode 
construir um modelo automatizado das tarefas, atividades e da metodologia de 
processos. Ao analisarmos as informações do quadro 2, podemos afirmar que existe um 
modelo único de processo para a elaboração desses projetos? 
 
 
 
 
 
 
 
 
 
28 
 
 
Figura 8: Modelo de processo de software em Cascata 
 
Fonte: Adaptado de Pressman (2011, p. 60). 
 
Dentre as vantagens desse tipo de modelo podemos citar a produção de 
documentos em cada fase e seu uso em outros modelos de projeto. A Desvantagem 
refere-se à inflexibilidade das fases do projeto, ou seja, há resistência no projeto em 
relação a mudanças de requisitos do usuário, dessa forma os requisitos precisam estar 
bem definidos no projeto. 
 
2.2.2 Prototipação 
O modelo de prototipação apresenta inicialmente um produto ao usuário em 
forma de protótipo, e somente depois da aprovação do cliente, o desenvolvimento 
do software é iniciado. O usuário terá acesso ao protótipo, por meio de um sistema 
já existente (sem todas as funcionalidades) oupor meio de aparências das janelas, 
consultas, relatórios, sem funcionalidade, ou através do uso do papel, onde é 
realizado um rascunho das interações com o sistema que será planejado. 
A figura 9 ilustra o modelo processo de prototipação. 
 
 
 
 
 
 
 
 
 
 
29 
 
 
Figura 9: O modelo da prototipação 
 
Fonte: Adaptado de Pfleeger (2004. p. 43). 
 
O processo de prototipação pode ser usado como modelo principal no 
desenvolvimento do software. Algumas práticas indicam que seu uso é mais comum 
como técnica implantada junto com os outros processos de software. De acordo 
com Pressman (2011) “quando os requisitos estão obscuros, o paradigma da 
prototipação auxilia os interessados a compreender melhor o que está para ser 
construído”. O autor completa: 
 
O projeto rápido leva à construção de um protótipo, que é 
empregado e avaliado pelos envolvidos, que fornecerão um retorno 
(feedback), que servirá para aprimorar os requisitos. A iteração ocorre 
conforme se ajusta o protótipo às necessidades de vários interessados 
e, ao mesmo tempo, possibilita a melhor compreensão das 
necessidades que devem ser atendidas (PRESSMAN, 2011, p. 64). 
 
É importante nesse processo considerar o fator relacionado à ansiedade do 
cliente, pois ao ter contato com o protótipo são geradas expectativas, o que pode 
influenciar na entrega final do produto. 
 
2.2.3 Modelo de desenvolvimento Baseado em Componentes 
A característica principal desse processo é o reuso de softwares. A definição 
de reuso no dicionário Priberam (2008), refere-se ao “ato ou efeito de reusar”, e a 
 
 
 
 
 
 
 
 
 
30 
 
 
palavra reusar, significa, “utilizar novamente”. Dessa forma podemos dizer que o 
processo de Engenharia de Software Baseado em componentes utiliza-se de vários 
softwares para a elaboração de outro software. Esse modelo de processo, “depende 
de uma grande base de componentes de softwares reusáveis e algum framework de 
integração desses componentes”. (SOMMERVILLE, 2007, p. 46) 
De acordo com Pressman (2011, p. 69) o modelo baseado em componentes 
possui as seguintes etapas no seu desenvolvimento: 
 
1. Produtos baseados em componentes disponíveis são pesquisados e 
avaliados para o campo de aplicação em questão. 2. Itens de 
integração de componentes são considerados. 3. Uma arquitetura de 
software é projetada para acomodar os componentes. 4. Os 
componentes são integrados na arquitetura. 5. Testes completos são 
realizados para assegurar funcionalidade adequada. 
 
A figura 11 ilustra as etapas e atividades do modelo de processo baseado em 
componentes. 
 
Figura 11: Processo de desenvolvimento de Engenharia de Software Baseada em 
Componentes 
 
Fonte: Adaptado de Sommerville, (2007, p. 46) 
 
A redução de custos e riscos é uma das vantagens desse modelo, isso porque 
reduz a quantidade de software a ser produzido. A desvantagem é que o 
desenvolvimento baseado em uma entrega mais rápida compromete a descrição 
dos requisitos, e consequentemente a possibilidade da entrega de um software que 
não atenda às necessidades reais dos usuários. 
 
 
 
 
 
 
 
 
 
 
31 
 
 
2.2.4 Entrega Incremental 
Nos projetos de construção de softwares de grande porte há muitas pressões 
internas para a mudança de requisitos, dessa forma, são necessárias alterações na 
forma de gerenciamento. “A essência dos processos iterativos é que a especificação 
é desenvolvida conjuntamente com o software”. No modelo incremental, “A 
especificação, o projeto e a implementação de software são divididos em uma série 
de incrementos desenvolvidos um de cada vez (...) o cliente identifica, em linhas 
gerais, os serviços a serem fornecidos pelo sistema” SOMMERVILLE, 2007, p.47). 
A Entrega Incremental combina as vantagens dos modelos evolucionárias e 
modelo em cascata, conforme ilustra a figura 12. 
 
Figura 12: Entrega Incremental – Processo de Software 
 
Fonte: Adaptado de Sommerville, (2007, P. 46) 
 
Observe na figura 12 que a partir do desenvolvimento do incremento do 
sistema, há uma forte iteração entre as atividades e fases do processo. No final ao 
validar um incremento, há um loop e a atividade se reinicia no desenvolvimento de 
outro incremento. 
A seguir, no quadro 3 são apresentados as vantagens e desvantagens da 
Entrega Incremental. 
 
Quadro 3: Vantagens e desvantagens da entrega incremental 
Vantagens 
 
Desvantagens 
 Os clientes não precisam esperar até a 
entrega do sistema inteiro. 
 Os clientes podem utilizar os 
incrementos iniciais como protótipos e 
utiliza-lo como experiência para os 
 Os incrementos devem ser relativamente 
pequenos e cada um deve entregar uma 
funcionalidade do sistema. 
 Dificuldade no mapeamento dos requisitos 
dos clientes em incrementos de tamanho 
 
 
 
 
 
 
 
 
 
32 
 
 
outros incrementos. 
 Existe um risco menor de falha geral do 
projeto, principalmente nas partes mais 
importantes do sistema. 
 
adequado. 
 A maior parte dos sistemas requer um 
conjunto de recursos básicos usados por 
diferentes partes do sistema. 
 Dificuldades na identificação dos recursos 
comuns exigidos por todos os incrementos. 
Fonte: Adaptado de Sommerville (2007, p. 48). 
 
2.2.5 Modelo Espiral 
No modelo espiral “o desenvolvimento do sistema evolui em espiral para fora 
a partir de um esboço inicial até o sistema final” (SOMMERVILLE, 2007, p. 47). O 
desenvolvimento Espiral apresenta quatro atividades importantes: planejamento, 
análise de riscos, engenharia e avaliação do cliente. 
De forma resumida, conforme Sommerville (2007), no planejamento ocorrem 
discussões importantes, tais como a determinação dos objetivos, alternativas e 
restrições. Na análise de riscos ocorre a identificação e resolução dos riscos. Na 
engenharia há o desenvolvimento do produto. E por último, na avaliação do cliente, 
é realizada uma avalição dos resultados da engenharia. 
Um dos pontos principais do modelo espiral e o que diferencia esse modelo 
dos demais modelos é a questão da análise do risco, ou seja, “o que pode dar 
errado”. Na figura 13, podemos observar a relevância dada a atividade de análise 
de riscos se comparado com as outras atividades do modelo. 
 
 
 
 
 
 
 
 
 
 
33 
 
 
Figura 13: Modelo em espiral do processo de software 
 
Fonte: Adaptado Pfleeger (2004, p.47). 
 
As vantagens do modelo espiral são significativas quando comparadas com 
os outros modelos de software. Uma dessas vantagens é que, as interações iniciais 
possuem um baixo custo, e são as que resolvem o maior número de problemas, 
devido à análise de riscos do modelo. A desvantagem é a exigência do modelo em 
relação à competência da avaliação de riscos para que o projeto tenha bons 
resultados; outro problema e o fato do modelo não fornecer indicação da 
quantidade de trabalho em cada ciclo, o que acarreta um aumento de problemas 
para gerência do projeto. 
 
 
 
 
O Rational Unified Process – RUP, idealizado durante o início dos anos 1990, por James 
Rumbaugh, Grady Booch e Ivar Jacobson é um bom exemplo de modelo híbrido de 
processo, ele traz elementos dos modelos iterativos, em cascata, baseado em 
componentes, evolucionário e a prototipação, a partir de uma perspectiva dinâmica, 
(mostra as fases do modelo) estática (Mostra as atividades realizadas) e prática (sugere 
boas práticas a serem realizadas). 
 
 
 
 
 
 
 
 
 
 
34 
 
 
 
 
2.3 ATIVIDADES DE PROCESSO DE SOFTWARE 
É importante ressaltar inicialmente que as atividades do processo de software, 
conforme descreve Sommerville (2007, p. 49), “são organizadas de modo diferente 
nos diversos processos de desenvolvimento”. São relatadas no quadro 5 um resumo 
das quatros atividades básicas do processo de software, segundo o autor. 
 
Quadro 5: Atividades de processo de software 
Atividades Descrição 
Especificação de software Processo para compreender e definir quaisserviços são 
necessários e identificar as restrições de operação e de 
desenvolvimento do sistema. 
Projeto e implementação 
de software 
Processo de conversão de uma especificação de sistema em 
um sistema executável. 
Validação de software O Objetivo é mostrar que um sistema está em conformidade 
com sua especificação e que atende às expectativas do 
cliente que está adquirindo o sistema. 
Evolução do software Mudanças podem ser feitas no software a qualquer instante, 
durante ou após o desenvolvimento do sistema. 
Fonte: Adaptado de Sommerville (2007) 
 
A seguir são descritos com mais detalhes as atividades de processo de 
software ilustradas no quadro 5. 
 
2.3.1 Especificação de software 
O processo de especificação de software é também denominado Engenharia 
de Requisitos. Na unidade 4, trataremos mais específico sobre os processos que 
envolvem os requisitos de um sistema. No geral, de acordo com Pressman (2011, 
p.129) uma: 
especificação de requisitos de software (software requirements specifi 
cation, SrS) é um documento criado quando uma descrição 
detalhada de todos os aspectos do software a ser construído deve ser 
especificada antes de o projeto começar. 
 
Para entender um pouco mais sobre o RUP, leia as páginas 54 a 56 do livro Engenharia de 
software do autor Ian Sommerville. O livro está disponível na biblioteca virtual: 
https://abrir.link/slcpS. Acesso em: 20 jan. 2023. 
 
https://abrir.link/slcpS
 
 
 
 
 
 
 
 
 
35 
 
 
O produto final, portanto, do processo de especificação de software é 
denominado documento de requisito e aborda o conteúdo sobre a especificação 
do sistema. O modelo está ilustrado na figura 14. 
 
Figura 14: Modelo de especificação de requisitos de software 
 
Fonte: Pressman (2011, p.129) 
 
As quatro principais fases da especificação de um software são: estudo de 
viabilidade, elicitação e análise de requisitos, especificação de requisitos e a 
validação de requisitos. Todas essas fases serão descritas com mais detalhes na 
unidade 4 desse livro. 
 
2.3.2 Implementação de software 
O objetivo da atividade que envolve o projeto e a sua implementação é a 
transformação da teoria (projeto do sistema) em prática (sistema executável). A 
figura 14 ilustra com detalhamento o processo de implementação de um projeto de 
software. 
 
 
 
 
 
 
 
 
 
 
36 
 
 
Figura 14: Processo de especificação de um software 
 
Fonte: Adaptado de Sommerville, (2007, p. 47). 
 
A figura 14 mostra as relações das atividades e produtos dos projetos, na 
atividade de elaboração do projeto e implementação de software. “A saída de 
cada atividade de projeto é uma especificação para o próximo estágio. [...] Os 
resultados finais do processo são especificações precisas de algoritmo e estruturas de 
dados a serem implementados” (SOMMERVILLE, 2007, p. 51). 
 
2.3.3 Validação de software 
O processo de validação de um software está diretamente relacionado com 
as verificações do sistema e a conformidade com as solicitações feitas pelo cliente 
que realizou a contratação. A ideia básica da validação do software é a partir da 
localização do erro, elaborar e aplicar o projeto de reparo desse erro, visando o 
acerto dos problemas encontrados. 
Nesse sentido são realizados três estágios de testes: teste no componente, teste 
no sistema e o teste na aceitação, conforme ilustrado na figura 15. 
 
 
 
 
 
 
 
 
 
 
37 
 
 
Figura 15: Processo de Validação de Software 
 
Fonte: Adaptado de Sommerville (2007, p. 52-53) 
 
A Figura 15 ilustra as fases de teste no processo de software. Acompanhando 
o fluxo da seta, primeiramente testam-se os componentes individuais, na sequência 
a integração dos componentes e por último é realizado, uma simulação, um teste 
com dados fornecidos pelo cliente. Observe que caso haja uma necessidade de se 
retornar a uma fase de teste isso é possível, ou seja, se o projeto encontra-se na fase 
de teste do sistema e há demanda para se testar novamente um componente, o 
processo poderá ser realizado. 
Complementando as informações da figura 15, a figura 16 mostra o fluxo para 
reparo do erro em um sistema de software. 
 
Figura 16: Fluxo para reparo do erro no processo de software (Debugging) 
 
Fonte: Adaptado de Sommerville (2007, p.52-53) 
 
Na figura 16 observa-se que após a detecção do erro (processo de 
debugging), inicia-se o processo de verificação do erro e em seguida os 
procedimentos para o reparo. No final uma reavaliação do programa é realizada 
finalizando o processo. 
 
 
 
 
 
 
 
 
 
 
38 
 
 
2.3.4 Evolução (manutenção) de software 
Evolução significa transformar algo ao longo de um determinado período. 
Historicamente as preocupações com o processo de manutenção de um software 
sempre ficaram em um plano inferior, a preocupação sempre está centrada no 
desenvolvimento do sistema. Para Sommerville (2007, p. 54) apesar de historicamente 
da manutenção de um software ser considerada menos desafiador do que o 
desenvolvimento é preciso: 
considerar o desenvolvimento e a manutenção de forma contínua. 
Em vez de dois processos separados, é mais realista pensar na 
engenharia de software como um processo evolutivo, no qual o 
software e continuamente alterado ao longo de sua vida, em 
respostas a mudanças de requisitos e as necessidades do cliente. 
 
 
 
 
 
 
 
 
 
 
 
39 
 
 
 
 
Por meio do estudo da unidade 2, foi possível perceber conceitos e relações 
importantes do termo processo e dos modelos propostos de processos de software. 
Foi possível também estudar os ciclos de vida de software e entender o 
funcionamento de cada ciclo no contexto do desenvolvimento dos projetos de 
software. Vimos, também, as quatro principais atividades do processo de software, 
seus fundamentos e conceitos. Na unidade 3, estudaremos de forma introdutória o 
gerenciamento de projetos. 
 
Manutenção de software 
As alterações feitas no software podem ser simples mudanças para correção de erros de 
codificação, até mudanças mais extensas para correção de erros de projeto, ou 
melhorias significativas para corrigir erros de especificação ou acomodar novos requisitos. 
As mudanças são implementadas por meio da modificação de componentes do sistema 
existente e, quando necessário, por meio da adição de novos componentes 
(SOMMERVILLE, 2007, p. 327). 
Gráfico 1: Distribuição de esforço de manutenção 
Gráfico 2: Custo de desenvolvimento e manutenção 
 
Fonte: Sommerville (2007, p.327) 
 
Analisando os dados dos gráficos 1 e 2 podemos retirar algumas conclusões sobre o 
processo de desenvolvimento e manutenção do projeto de software. Dessa forma, ao 
separarmos de um projeto de software a etapa da manutenção da etapa do 
desenvolvimento, qual o maior risco que podemos correr? O prejuízo será maior ou menor? 
É mais fácil trabalhar com o erro no decorrer do processo ou entregar o produto e esperar 
que os erros se acumulem para resolver todos de uma só vez? 
 
 
 
 
 
 
 
 
 
 
40 
 
 
 
 
 
 
 
 
A engenharia de software auxiliada por computador – CASE (Computer-Aided Sofware 
Enginnering) refere-se aos softwares utilizados para dar apoio às atividades do projeto de 
software, a partir da automação de algumas atividades referente ao processo. 
Para saber mais sobre ferramenta CASE, sugerimos a leitura do título: “Engenharia de 
software auxiliada por computador” páginas 56 e 57 do livro engenharia de software de 
Ian Sommerville. O livro está disponível na biblioteca virtual: https://abrir.link/slcpS. Acesso 
em: 20 jan. 2023. 
 
https://abrir.link/slcpS
 
 
 
 
 
 
 
 
 
41 
 
 
FIXANDO O CONTEÚDO 
 
1. Analise as proposições abaixo referentes às características de um processo: 
I. Restrições e controles só podem ser aplicados a uma atividade do processo; 
II. Os processos possuem um conjunto de diretrizes que explicam os objetivos detodas 
as atividades; 
III. Cada atividade do processo tem critérios de entrada e saída, de modo que seja 
possível saber quando o processo começa e termina; 
IV. Nos processos é importante atribuir critérios de entrada e saída para cada 
atividade, o objetivo é saber quando um processo começa e termina. 
Estão corretos: 
a) I, II, III e IV. 
b) I, II e III. 
c) II, III e IV. 
d) II e IV. 
e) III e IV. 
 
2. Observe a imagem e analise as proposições: 
 
Fonte: Pressman, (2011, p. 60) 
 
I. Em 5, as atividades principais desenvolvidas e a entrega do produto e a 
realização dos feedbacks. 
II. Em 3, o objetivo é realizar a previsão das atividades a partir da elaboração do 
cronograma e realizar o acompanhamento das atividades. 
III. O modelo de processo de software apresentado na figura é o modelo em 
prototipação, considerado o paradigma mais antigo da engenharia de 
software. 
IV. Na fase 1 da figura o objetivo é que sejam definidos todas as necessidades, 
um ponto criticado atualmente no modelo, tendo em vista que é difícil para o 
cliente estabelecer explicitamente todas as necessidades. 
V. O modelo apresentado na figura sugere uma abordagem sequencial e 
 
 
 
 
 
 
 
 
 
42 
 
 
sistemática para o desenvolvimento de software. 
Estão corretas: 
a) I, IV e V. 
b) I, II, III e V. 
c) I, III, IV e V. 
d) II, IV e V. 
e) II, III e IV. 
 
3. (IFMS-2016) O Modelo de Processo de Software em Espiral (Boehm) é caracterizado 
por não representar o processo de software como uma sequência de atividades com 
algum retorno entre uma atividade e outra, mas sim, como uma espiral. Cada loop, 
na espiral, representa uma fase do processo de software que é dividido em quatro 
setores. Cronologicamente, os setores estão organizados como: 
a) análise de negócio; avaliação e redução de riscos; desenvolvimento e validação; 
planejamento. 
b) planejamento; definição de objetivos; avaliação e redução de riscos; 
desenvolvimento e validação. 
c) definição de objetivos; avaliação e redução de riscos; desenvolvimento e 
validação; planejamento da próxima fase. 
d) planejamento; análise de negócio; avaliação e redução de riscos; 
desenvolvimento e validação. 
e) planejamento; análise de negócio; definição de objetivos; desenvolvimento. 
 
4. Em relação ao ciclo de vida de um software, associe as duas colunas a seguir: 
I. Modelo Espiral 
 
(A) Sugere uma abordagem sequencial e sistemática para o 
desenvolvimento de software, começando com o 
levantamento de necessidades por parte do cliente. 
II. Modelo em Cascata (B) Cada loop representa uma fase de processo do software. 
III. Engenharia baseada 
em componentes 
(C) O cliente define uma série de objetivos gerais para o 
software, mas não identifica, detalhadamente, os requisitos 
para funções e recursos. 
IV.Entrega incremental (D) Baseia-se em componentes reusáveis. 
V. Prototipação (E) Intercala atividades de especificação, desenvolvimento e 
validação. 
 
A sequência CORRETA é: 
a) I-E, II-A, III-C, IV-B, V-D. 
b) I-B, II-A, III-E, IV-C, V-D. 
 
 
 
 
 
 
 
 
 
43 
 
 
c) I-B, II-A, III-D, IV-E, V-C. 
d) I-E, II-B, III-D, IV-B, V-C. 
e) I-A, II-B, III-E, IV-D, V-C. 
 
5. As proposições abaixo se referem às atividades de processo de software. Analise-
as para responder a questão: 
I. O documento de requisito é considerado o documento que inicia as atividades 
de especificação de software. 
II. Na atividade de implementação de software, a discussão entre o que foi escrito 
no projeto e o que está sendo aplicado é uma das principais características. 
III. No processo de validação de um software, antes de reparar o erro, a equipe 
realiza o teste de componentes, integração e simulação. 
Está (ão) correta (s): 
a) I, II e III. 
b) I e II. 
c) Somente II. 
d) Somente III. 
e) II e III. 
 
6. Observe o trecho: “Trabalhos posteriores propuseram métodos para a tradução de 
fluxos de dados ou da estrutura de dados em uma definição de projeto. Abordagens 
de projeto mais recentes propuseram uma abordagem orientada a objetos para a 
derivação do projeto. Atualmente, a ênfase em projeto de software tem sido na 
arquitetura de software e nos padrões de projeto que podem ser utilizados para 
implementar arquiteturas de software e níveis de abstração de projeto mais baixos”. 
(PRESSMAN, 2011, p. 211) 
 
O trecho acima se refere à atividade do projeto de software: 
 
a) Evolução de software. 
b) RPU. 
c) Validação de software. 
d) Projeto de implementação de software. 
e) Análise de requisitos. 
 
 
 
 
 
 
 
 
 
44 
 
 
 
7. Observe o recorte da imagem: 
 
Fonte: (Pfleeger, 2004, P. 89) 
 
A etapa anterior a “Codificação” e posterior “Teste do sistema” são: 
 
a) Projeto do programa e Teste de Aceitação 
b) Projeto de programa e Operação e Manutenção 
c) Projeto de Sistema e Teste de Aceitação 
d) Projeto de Sistema e Manutenção 
e) Definição de Requisitos e Manutenção 
 
8. “Originalmente proposto por Barry Boehm [Boe88], o modelo espiral é um modelo 
de processo de software evolucionário que acopla a natureza iterativa da 
prototipação com os aspectos sistemáticos e controlados da modelo cascata” 
(PRESSMAN, 2011, p. 65). 
Sobre o modelo espiral analise as proposições abaixo: 
 
I. Um dos principais pontos do modelo espiral, é que o modelo parte do princípio que 
a forma de desenvolvimento do software precisa ser completamente determinada 
de antemão. 
II. Um dos ciclos no modelo espiral refere-se a avaliar alternativas com relação aos 
objetivos e restrições, e identificar as principais fontes de riscos. 
III. No modelo espiral, a estratégia para se descobrir os problemas é a prototipação, 
que é vista como um meio de redução de riscos. 
IV. Na etapa de planejamento da próxima fase, configura-se uma atividade 
preventiva, tendo em vista que o projeto poderá ser abortado se apresentar um alto 
fator de risco. 
 
 
 
 
 
 
 
 
 
45 
 
 
Estão corretas: 
a) I, II e IV. 
b) I, II e III. 
c) I e IV. 
d) II, III e IV. 
e) II, III e IV. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
46 
 
 
INTRODUÇÃO AO 
GERENCIAMENTO DE PROJETOS 
 
 
 
 
3.1 VISÃO GERAL E CONCEITOS DO GERENCIAMENTO DE PROJETOS 
De acordo com o guia PMBOK - Guide to the Project Management Body of 
Knowledge ou Guia para o Conjunto de Conhecimentos de Gerenciamento de 
Projetos (2017, p.4), podemos definir projeto como sendo: “um esforço temporário 
empreendido para criar um produto, serviço ou resultado único. Projetos são 
realizados para cumprir objetivos através da produção de entregas”. Conforme 
consta no guia é possível à produção de uma ou mais entregas de: 
 
um produto único que pode ser um componente de outro item, um 
aprimoramento ou correção de um item ou um novo item final (...) um 
serviço único ou uma capacidade de realizar um serviço (...) um 
resultado único, como um produto ou documento; (...) e uma 
combinação única de um ou mais produtos, serviços ou resultados. 
(p.4) 
 
 
A definição e a caracterização do termo projeto têm como objetivo ajudar na 
elucidação do contexto de um estudo inicial sobre o gerenciamento de projetos. A 
figura 17 apresenta algumas características importantes sobre projetos. 
 
UNIDADE 
03 
 
 
 
 
 
 
 
 
 
47 
 
 
Figura 17: Contexto de iniciação do projeto 
 
Fonte: Adaptado de Guia PMBOK (2017, p. 08) 
 
Em relação ao gerenciamento de projetos, o guia PMBOK (2017, p. 10) define 
como sendo “a aplicação de conhecimentos, habilidades, ferramentas e técnicas 
às atividades do projeto a fim de cumprir os seus requisitos”. 
O gerenciamento de um projeto pode ser considerado como bom ou ruim, 
dependendo de vários fatores, seja eles internos ou externos. Para ajudar na 
compreensão desses fatores, é descrito no quadro 6, uma visão geral de 
características de gerenciamento de projetosconsiderados eficazes e mal 
gerenciados ou a ausência do gerenciamento. 
 
Quadro 6: Visão geral sobre a concepção de projetos 
Gerenciamento de projetos eficazes Projetos mal gerenciados ou ausência de 
gerenciamento 
 Cumprirem os objetivos do negócio; 
 Satisfazerem as expectativas das partes 
interessadas; 
 Serem mais previsíveis; 
 Aumentarem suas chances de sucesso; 
 Entregarem os produtos certos no 
momento certo; 
 Resolverem problemas e questões; 
 Responderem a riscos em tempo hábil; 
 Otimizarem o uso dos recursos 
organizacionais; 
 Identificarem, recuperarem ou 
 Prazos perdidos; 
 Estouros de orçamento; 
 Má qualidade; 
 Retrabalho; 
 Expansão descontrolada do projeto; 
 Perda de reputação para a organização; 
 Partes interessadas insatisfeitas; e 
 Incapacidade de alcançar os objetivos 
para os quais o projeto foi empreendido 
 
 
 
 
 
 
 
 
 
48 
 
 
Gerenciamento de projetos eficazes Projetos mal gerenciados ou ausência de 
gerenciamento 
eliminarem projetos com problemas; 
 Gerenciarem restrições 
 Equilibrarem a influência de restrições do 
projeto e 
 Gerenciarem melhor as mudanças 
Fonte: Guia PMBOK, (2017, p. 10). 
 
 
 
De um modo geral o gerenciamento de projetos é agrupado em cinco 
grandes grupos de processos: iniciação, planejamento, execução, monitoramento e 
controle e encerramento (PMBOK, 2017, p.21) 
 A iniciação é responsável pela definição e autorização de todo ou fase do 
projeto, 
 No planejamento trabalha-se com a definição e ações necessárias para 
viabilização dos objetivos. 
 Na execução realiza-se a integração das pessoas e recursos envolvidos para 
o plano de gerenciamento do projeto, além de concluir o trabalho definido 
no plano de gerenciamento do projeto com o objetivo de satisfazer os 
requisitos do projeto. 
 O grupo de monitoramento e controle é responsável pela medição constante 
do processo, com o objetivo de identificar as variações em relação ao plano 
de gerenciamento do projeto para o início das mudanças correspondentes. 
 No encerramento é formalizada a aceitação do produto, serviço ou resultado. 
Outro ponto do gerenciamento de projetos refere-se à equipe de trabalho, ou 
seja, o gerenciamento das partes interessadas dos projetos. A figura 18 apresenta um 
breve resumo das fases que envolvem esse gerenciamento. 
 
Para saber um pouco mais sobre as concepções de projetos e sistemas, sugerimos a 
leitura da unidade I, “Aqui começa o projeto”, do livro: “Gestão de projetos” do autor 
Fabio Câmara Araújo de Carvalho, páginas 1 a 18. O livro está disponível na biblioteca 
virtual: https://abrir.link/AYI52. Acesso em: 20 jan. 2023. 
 
https://abrir.link/AYI52
 
 
 
 
 
 
 
 
 
49 
 
 
Figura 18: Os processos de gerenciamento das partes interessadas do projeto são: 
 
Fonte: Adaptada do guia PMBOK (2017, p. 503). 
 
O gerenciamento das partes interessadas do projeto, em geral pode ser 
resumida de acordo com o guia PMBOK, (2017): 
 
inclui os processos exigidos para identificar todas as pessoas, grupos 
ou organizações que podem impactar ou serem impactados pelo 
projeto, analisar as expectativas das partes interessadas, seu impacto 
no projeto e desenvolver estratégias de gerenciamento apropriadas 
para o engajamento eficaz das partes interessadas nas decisões e na 
execução do projeto. (p.503) 
 
O conceito abordado nessa seção teve como objetivo descrever uma visão 
geral do termo projeto e do gerenciamento de projeto. No próximo capítulo será 
abordada uma visão geral das etapas específicas do gerenciamento de projeto de 
software. 
 
3.2 ATIVIDADES, PLANEJAMENTO E CRONOGRAMA DE PROJETOS DE 
SOFTWARES 
O gerenciamento de projetos de software é “parte essencial da engenharia 
de software” (SOMMERVILLE 2007, p.61). Como foi abordado no item 3.1 desse livro, 
 
 
 
 
 
 
 
 
 
50 
 
 
um mau gerenciamento de projeto, pode resultar em falha grave nos projetos. Dessa 
forma, é importante que a seleção da pessoa responsável pelo controle e 
coordenação desse tipo de projeto seja realizada com responsabilidade e critério. 
No gerenciamento de projetos de software, os profissionais responsáveis pelo 
desenvolvimento de planos e cronograma dos projetos são os gerentes de software. 
Além dessa função, eles também “supervisionam o trabalho para assegurar que ele 
esteja sendo realizado dentro dos padrões exigidos e monitoram o progresso para 
verificar se o desenvolvimento está no prazo e dentro do orçamento” SOMMERVILLE 
(2007, p.61). 
 
3.2.1 Visão geral das atividades de gerenciamento de projeto de software 
As atividades de um projeto, em geral, estão diretamente relacionadas ao 
“processo de identificação e documentação das ações específicas a serem 
realizadas para produzir as entregas do projeto” (PMBOK, 2017, p. 183). Uma 
atividade de gerenciamento de projeto de software está associada a “parte do 
projeto que acontece ao longo de determinado período” (PFLEEGER 2004, p.64). 
A figura 19 ilustra a proposta de atividades em um projeto de gerenciamento 
de software. 
 
 
 
 
 
 
 
 
 
 
51 
 
 
Figura 19: Esboço das atividades de gerenciamento de software 
 
Fonte: Adaptado de Sommerville (2007, p. 62-63) 
 
3.2.2 Visão geral do planejamento de gerenciamento de projeto de software 
Conforme já citado no item 3.1 desse livro, o planejamento, de uma forma 
geral, trabalha visando a realização dos objetivos do projeto. Nos projetos de 
gerenciamento de software, para que os objetivos sejam alcançados são necessários 
planos de ações. O quadro 7, exibe informações, sobre os planos de ações de um 
planejamento de projeto de software. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
52 
 
 
Quadro 7: Tipos de planos de ação 
Plano Descrição 
Plano de qualidade 
Descreve os procedimentos e os padrões de 
qualidade usados no projeto. 
Plano de validação 
Descreve a abordagem, os recursos e o 
cronograma usado para a validação do sistema. 
Plano de gerenciamento de 
configuração 
Descreve os procedimentos e a estrutura de 
gerenciamento de configuração a serem usados. 
Plano de manutenção 
Prevê os requisitos de manutenção do sistema, os 
cultos de manutenção e o esforço necessário. 
Plano de desenvolvimento de 
pessoal 
Descreve como as habilidades e a experiência dos 
membros da equipe de projeto será desenvolvida. 
Fonte: Sommerville (2007, p. 64). 
 
Em um planejamento de projeto de software, as ações devem ser elaboradas 
e acompanhadas pelo gerente do projeto. Na figura 20, é possível identificar as 
ações referentes ao planejamento de projeto de software. Note, na figura, que há 
um “loop” ao término da ação final, caso haja um novo problema, o processo é 
reiniciado. 
Figura 20: Ações do planejamento de projeto de software 
 
Fonte: Sommerville (2007, p.64) 
 
 
 
 
 
 
 
 
 
 
53 
 
 
Um conceito importante e que tem relação direta com as atividades é o termo 
“marco”. Diferente de atividade, o marco, pode ser definido como sendo “um ponto 
final reconhecível de uma atividade do processo e software” SOMMERVILLE (2007, p. 
65). Para Pfleeger (2004), na relação entre marco e atividade, pode-se afirmar que 
“uma atividade tem um começo e um fim, ao passo que o marco é o fim de uma 
atividade – um momento específico no tempo”. 
A figura 21 ilustra o conceito e as relações entre atividade e marco no 
planejamento de projeto de software, observe na figura a descrição do marco e sua 
finalização em uma atividade. 
Figura 21: Atividade e marcos no processo de requisitos 
 
Fonte: Adaptada de Sommerville, (2007, p.65). 
 
3.2.3 Visão geral do cronograma de gerenciamento de projeto de software 
Cronograma de projeto de software “é uma atividade que distribui o esforço 
estimado por toda a duração planejada do projeto alocando esse esforço para 
tarefas específicas de engenharia de software” PRESSMAN (2011, p.