Engenharia_de_Software

Prévia do material em texto

Engenharia de Software
Créditos
Centro Universitário Senac São Paulo – Educação Superior a Distância
Diretor Regional 
Luiz Francisco de Assis Salgado
Superintendente Universitário 
e de Desenvolvimento 
Luiz Carlos Dourado
Reitor 
Sidney Zaganin Latorre
Diretor de Graduação 
Eduardo Mazzaferro Ehlers
Diretor de Pós-Graduação e Extensão 
Daniel Garcia Correa
Gerentes de Desenvolvimento 
Claudio Luiz de Souza Silva 
Luciana Bon Duarte 
Roland Anton Zottele 
Sandra Regina Mattos Abreu de Freitas
Coordenadora de Desenvolvimento 
Tecnologias Aplicadas à Educação 
Regina Helena Ribeiro
Coordenador de Operação 
Educação a Distância 
Alcir Vilela Junior
Professora Autora 
Ana Cláudia Rossi
Revisor Técnico 
Raphael Mendes de Oliveira Cobe
Técnicos de Desenvolvimento 
Ozeas Vieira Santana Filho 
Rodrigo Moura Galhardo
Coordenadoras Pedagógicas 
Ariádiny Carolina Brasileiro Silva 
Izabella Saadi Cerutti Leal Reis 
Nivia Pereira Maseri de Moraes
Equipe de Design Educacional 
Alexsandra Cristiane Santos da Silva 
Angélica Lúcia Kanô 
Cristina Yurie Takahashi 
Diogo Maxwell Santos Felizardo 
Elisangela Almeida de Souza 
Flaviana Neri 
Francisco Shoiti Tanaka 
Gizele Laranjeira de Oliveira Sepulvida 
João Francisco Correia de Souza 
Juliana Quitério Lopez Salvaia 
Jussara Cristina Cubbo 
Kamila Harumi Sakurai Simões 
Karen Helena Bueno Lanfranchi 
Katya Martinez Almeida 
Lilian Brito Santos 
Luciana Marcheze Miguel 
Luciana Saito 
Mariana Valeria Gulin Melcon 
Mônica Maria Penalber de Menezes 
Mônica Rodrigues dos Santos 
Nathália Barros de Souza Santos 
Paula Cristina Bataglia Buratini 
Renata Jessica Galdino 
Sueli Brianezi Carvalho 
Thiago Martins Navarro 
Wallace Roberto Bernardo
E
Aparecida Daniele Carvalho do Nascimento 
Gabriela Souza da Silva 
Vivian Martins Gonçalves
Coordenador Multimídia e Audiovisual 
Adriano Tanganeli
Equipe de Design Visual 
Adriana Matsuda 
Caio Souza Santos 
Camila Lazaresko Madrid 
Carlos Eduardo Toshiaki Kokubo 
Christian Ratajczyk Puig 
Danilo Dos Santos Netto 
Hugo Naoto 
Inácio de Assis Bento Nehme 
Karina de Morais Vaz Bonna 
Lucas Monachesi Rodrigues 
Marcela Corrente 
Marcio Rodrigo dos Reis 
Renan Ferreira Alves 
Renata Mendes Ribeiro 
Thalita de Cassia Mendasoli Gavetti 
Thamires Lopes de Castro 
Vandré Luiz dos Santos 
Victor Giriotas Marçon 
William Mordoch
Ana Paula Pigossi Papalia 
quipe de Qualidade 
Equipe de Design Multimídia 
Alexandre Lemes da Silva 
Cláudia Antônia Guimarães Rett 
Cristiane Marinho de Souza 
Eliane Katsumi Gushiken 
Elina Naomi Sakurabu 
Emília Correa Abreu 
Fernando Eduardo Castro da Silva 
Mayra Aoki Aniya 
Michel Iuiti Navarro Moreno 
Renan Carlos Nunes De Souza 
Rodrigo Benites Gonçalves da Silva 
Wagner Ferri
Engenharia de Software
Aula 01
Introdução à Engenharia de Software
Objetivos Específicos
• Entender a Engenharia de Software e sua importância e também, identificar
os diferentes tipos de sistemas que podem requerer diversos processos,
métodos e técnicas de Engenharia de Software.
Temas
Introdução
1 Entendendo a Engenharia de Software e sua importância
2 Diferentes aplicações da Engenharia de Software
3 Discutindo questões éticas e profissionais importantes para os engenheiros 
de software
Considerações finais
Referência
Professora
Ana Cláudia Rossi
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
3
Introdução
Olá, seja bem-vindo!
Nesta aula, apresentaremos a Engenharia de Software como área de conhecimento, e 
discutiremos a sua importância para a sociedade, as abordagens a serem utilizadas para o 
desenvolvimento de produtos de software e as questões éticas e profissionais envolvidas.
1 Entendendo a Engenharia de Software e sua importância
É muito difícil ver o mundo atual sem produtos de software. Cada vez mais as nossas 
atividades do cotidiano estão apoiadas por aplicações computacionais que, por sua vez, estão 
disponíveis para nós em diversos formatos ou dispositivos. Entendemos que esses recursos 
computacionais, na forma de aplicações, são fundamentais para a nossa qualidade de vida, 
pois agilizam e melhoram a nossa forma de viver em sociedade.
Segundo Sommerville (2011), os sistemas de software são abstratos e intangíveis. 
Não são restritos por propriedades materiais nem por leis da Física. Isso permite infinitas 
possibilidades de desenvolvimento de aplicações sem a intervenção das leis da natureza. 
Contudo, esse fato pode contribuir para ampliar a complexidade de um software, bem como 
a dificuldade de entendê-lo ou alterá-lo.
O software está presente em diversos sistemas, desde aplicações embutidas, como 
em uma televisão, até em aplicações com abrangência mundial, como o sistema de buscas 
do Google. Desenvolver essa diversidade de aplicações exige várias abordagens, técnicas, 
métodos e notações. A diversidade de abordagens nos permite encontrar o instrumental 
mais adequado para desenvolver determinado tipo de software.
É então que surge a importância da engenharia de software como área de 
conhecimento. Assim como o engenheiro civil e o médico, construir diversos tipos de 
edificações, ou executar diferentes procedimentos cirúrgicos, demanda abordagens 
apropriadas para alcançar sucesso naquilo que se faz. Desenvolver software não é diferente. 
Precisamos da Engenharia de Software para estudar e sedimentar diferentes abordagens, 
que nos levarão a produtos de qualidade.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
4
Imagine que você escreva programas como parte de um projeto maior, em 
conjunto com outros colegas. Haveria a necessidade de compartilhar 
informações sobre o sistema de software em desenvolvimento. Nesse cenário, 
poderiam surgir perguntas do tipo: como fazer determinado programa? Como 
documentar o que já foi feito? Como saber o que falta fazer? Estamos no prazo? 
As estimativas de custo estão corretas? Além disso, considere que essa equipe 
pode estar trabalhando em dois ou mais projetos de software simultaneamente. 
Como gerenciar essa complexidade garantindo produtos de qualidade para os 
futuros usuários dos sistemas?
Podemos listar estas e outras várias questões que estão diretamente atreladas ao 
desenvolvimento de produtos de software. E a Engenharia de Software busca respostas para 
todas essas questões, pois ela estuda todos os aspectos da produção de software. Desde 
a concepção de um projeto de software, passando por todo o seu ciclo de vida, até a sua 
manutenção e, posteriormente, sua desativação ou substituição por outro software mais 
moderno.
O termo engenharia é aqui aplicado, pois está diretamente ligado ao conceito de que 
o engenheiro é o profissional que faz as coisas funcionarem. Ele aplica teorias, métodos e 
ferramentas do modo mais apropriado para buscar os melhores resultados. Os engenheiros 
também têm consciência de que devem trabalhar considerando os limites financeiros e 
organizacionais das instituições que promovem a solução.
Figura 1 – Engenharia, aplicação de teorias, métodos e ferramentas
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
5
De modo complementar, quando nos referimos a todos os aspectos da produção de 
software indicamos não estarmos preocupados somente com a produção dos programas 
que serão escritos, mas também com todo o ciclo de vida desse produto de software. Por 
exemplo, com a documentação, com o ambiente onde esse software vai “rodar”, com as 
pessoas envolvidas etc.
Resumindo, a Engenharia de Software é importante porque existe uma dependência 
evidente da sociedade por produtos de software nas diversas atividades humanas, e utilizar 
seus preceitos permite entregar e manter produtos de qualidade, diminuir tempo e custos, 
além de minimizar o retrabalho daquilo que fazemos.
1.1 O processo de Software
A Engenharia de Software utiliza uma abordagem sistêmica que chamamos de processo 
de software, que compreende uma sequência de atividades que serão encadeadas para 
compor a produção de um ou maisprodutos de software. As atividades a serem utilizadas vão 
variar em função das abordagens que utilizaremos ou, ainda, dos diferentes tipos de software 
que desenvolveremos. Contudo, existem quatro atividades fundamentais para todo processo 
de software desenhado, como apresenta a figura 2.
Figura 2 – Atividades fundamentais do processo de software
Fonte: Elaborada pela autora (2014).
1.1.1 Especificação de software
A atividade de especificação deve reunir o conjunto de necessidades que o cliente do 
produto deseja. Essas necessidades são expressas em requisitos funcionais. A somatória 
desses requisitos definirá o escopo do projeto e permitirá a equipe ter um entendimento 
mais profundo sobre o que será desenvolvido para evoluir e alcançar um bom software em 
funcionamento.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
6
1.1.2 Desenvolvimento de software
O desenvolvimento pode ser entendido como a fase do projeto em que efetivamente 
construiremos o software. Escrever programas e preparar o ambiente no qual o software será 
instalado está entre as tarefas dessa atividade.
1.1.3 Validação de software
A atividade de validação deve atestar que o software produzido está em conformidade 
com a especificação produzida na primeira atividade. Fazendo uma analogia com a engenharia 
civil, seria o momento de verificar se a casa está de acordo com a planta desenhada, com as 
respectivas janelas, portas, cômodos etc. 
1.1.4 Evolução de software
A atividade de evolução pode ocorrer paralelamente a outras atividades. Se o cliente 
resolver mudar os requisitos, o produto de software será mudado também. Isso implica 
verificar e analisar os impactos ao projeto, pois haverá necessidade de esforços adicionais 
para essas mudanças.
1.2 Requisitos de qualidade de um software
Mas, o que é um bom software? 
Nem sempre aquele que atende a todas as necessidades descritas pelo cliente é um bom 
software. A qualidade não implica somente o que o software faz, devemos incluir também 
aspectos sobre como ele se apresenta ao usuário, a forma como ele é operado, o tempo de 
resposta etc. Esses aspectos são chamados de requisitos não funcionais ou de qualidade, 
que também devem ser determinados na atividade de especificação do software.
Portanto, além de atender a requisitos funcionais, um bom software também deve seguir 
critérios de qualidade, como demonstra Sommerville (2011):
• manutenibilidade: desenvolver programas que possam evoluir quando houver novas 
necessidades dos clientes; 
• confiança e proteção: garantir a segurança da aplicação, de modo que não gere 
prejuízos físicos ou econômicos;
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
7
• eficiência: primar pelo excelente uso dos recursos, como processador e memória de 
discos para obter a melhor capacidade de resposta que o produto puder alcançar;
• aceitabilidade: projetar sistemas compatíveis com os usuários finais tornando o 
software mais compreensível e intuitivo para o uso.
2 Diferentes aplicações da Engenharia de Software
Como já mencionamos anteriormente, existem tipos diferentes de sistemas de 
software a serem desenvolvidos que, por sua vez, irão requerer diferentes abordagens de 
desenvolvimento no processo de software.
As diferentes abordagens também variam em função da organização responsável pelo 
desenvolvimento e as pessoas envolvidas no processo. Não obstante, o tipo de software talvez 
seja o fator mais preponderante para a definição do processo de software a ser utilizado. O 
quadro 1 apresenta diferentes tipos de produtos de software:
Quadro 1 – Diferentes tipos de aplicação do software
Tipo de Aplicação Definição
Stand-alone
São executadas em um único local, sem a 
necessidade de conexão com a internet ou a 
outra rede.
Interativas baseadas em 
transações
Por meio de acesso via computador ou terminal, 
executam operações em um computador 
remoto.
Embutidas São sistemas que controlam e gerenciam dispositivos de hardware.
Batch (em lote) Consistem em aplicações projetadas para processar grandes conjuntos de dados.
Entretenimento Caracterizam os jogos ou outros sistemas com foco no entretenimento pessoal.
Modelagem e simulação
Desenhados para simular situações físicas ou 
reais de forma que permitam a tomada de 
decisão sobre o problema em estudo.
Coleta de dados Baseados no uso de sensores, que coletam dados de um ou mais ambientes.
Sistema de sistemas
São sistemas compostos por uma série de 
outros sistemas que somente em conjunto 
alcançam seus objetivos.
Fonte: Sommerville (2011, p. 7).
Em função do problema que queremos abordar, utilizaremos tipos de aplicação diferentes. 
Por exemplo, um jogo (game) poderia ser desenvolvido na modalidade stand-alone, porém, 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
8
se a intenção for competir com outros participantes, será necessário criar conexões com a 
internet e produzir formas de interação entre os participantes.
Por outro lado, muitas transações bancárias realizadas por correntistas hoje acontecem 
fora do banco, em aplicativos denominados home banking (na tradução do inglês seria algo 
como banco em casa). Para esse caso, precisamos de aplicativos capazes de se conectar com 
um servidor centralizado para requisitar permissões, consultar saldo da conta-corrente e 
efetuar um pagamento ou transferência bancária.
Figura 3 – Sistemas transacionais operados em diferentes equipamentos e plataformas
Observe que a complexidade de um projeto pode aumentar muito, em função dos 
requisitos definidos pelos stakeholders (traduzindo do inglês: interessados pelo projeto).
Já no caso de aplicações do tipo sistema de sistemas, temos o desafio da troca de 
dados entre aplicações heterogêneas, ou seja, que podem ter sido desenvolvidas para 
diferentes tipos de equipamentos. Nesse exemplo, utilizamos protocolos de comunicação 
para estabelecer uma forma padronizada de comunicação.
2.1 As complexidades no processo de negócios
Note que estamos apenas discutindo aqui questões técnicas que poderão surgir durante 
o processo de desenvolvimento do produto de software, também conhecido como ciclo 
de vida do produto. Mas, também existem outros pontos a se considerar sobre a área em 
que o produto de software será desenvolvido. Em outras palavras, estamos nos referindo à 
complexidade de um negócio específico ou de um processo sistêmico que será automatizado.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
9
Como exemplo, podemos citar um sistema que controla o carregamento 
de um navio. Considere que o posicionamento dos contêineres deve obedecer 
a regras como distribuição do peso no navio, limite de empilhamento e ordem 
de carga e descarga nos portos, para minimizar o manuseio dos blocos.
Portanto, podemos observar que o desenvolvimento de um produto de software 
exige profissionais capazes de enfrentar desafios técnicos sobre equipamentos, conexão, 
transmissão de dados etc., e desafios sobre a área de negócios que será melhorada com a 
implantação do novo sistema.
Figura 4 – Complexidade no caso do carregamento de contêineres
Diferentemente do estereótipo nerd que todos desenham para um profissional de 
Tecnologia da Informação, habilidades de comunicação e relacionamento interpessoal são 
importantes para ter sucesso nas etapas iniciais do processo de software, como o levantamento 
de dados e elicitação dos requisitos que farão parte do escopo do projeto. 
Mais para frente, discutiremos técnicas de levantamento e elicitação de requisitos, 
bem como questões de arquitetura de software, em que definimos como o produto será 
desenvolvido e implantado, tornando-se um sistema em produção para atender aos 
nossos usuários.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
10
3 Discutindo questões éticas e profissionais importantes 
para os engenheiros de software
Sabemos que várias pessoas escrevem programas, não necessariamente profissionaisde computação, alguns o fazem por hobby. Porém, em sua maioria, o desenvolvimento de 
software é uma atividade profissional e, para isso, exige práticas que são estudadas no âmbito 
da Engenharia de Software.
Existem muitas estatísticas que apontam o insucesso de projetos de sistemas de 
informação. Muitas vezes isso ocorre porque os profissionais envolvidos desconhecem 
algumas boas práticas da Engenharia de Software. Por esse motivo, é importante estudar o 
assunto, para tornar-se um bom profissional nessa área.
Contudo, além de ser um profissional conhecedor de práticas, métodos e técnicas 
inerentes à sua profissão, as questões éticas também são muito importantes para compor 
uma formação sólida e reconhecida no mercado.
A Engenharia de Software é desenvolvida dentro de um contexto social e, para tanto, 
deve respeitar seus protocolos. Ou seja, o profissional de Engenharia de Software deve se 
comportar de acordo com os aspectos éticos e morais da sociedade.
Mas o que isso significa? 
Estamos falando sobre manter padrões de honestidade e moralidade. Trabalhar com 
informação significa ter acesso a ela. Portanto, questões de confidencialidade devem ser 
respeitadas. No contexto empresarial, quando iniciamos uma carreira em uma nova empresa, 
os nossos contratantes apresentam códigos de conduta que devemos respeitar enquanto 
formos colaboradores dessa organização. Contudo, a responsabilidade profissional vai além 
disso e abrange aspectos como os destacados por Sommerville (2011):
• confidencialidade: respeitar o sigilo dos empregadores, independentemente de 
assinar acordos formais;
• competência: saber quais são os seus limites de capacidade de produção e não 
aceitar demandas que estão além da sua competência; 
• direitos de propriedade intelectual: estar ciente sobre legislação de patentes e 
direitos autorais; 
• preservação dos recursos: usar computadores e outros equipamentos de forma 
racional de modo a não depreciar ou danificar esses recursos. Também é necessário 
manter atenção para questões de segurança, como invasão de vírus, entre outros. 
Essas questões devem ser consideradas, pois um profissional de Engenharia de Software 
pode trabalhar nas dependências da empresa que o contratou, ou em um cliente da 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
11
empresa. Nesse caso, ele representa a empresa onde trabalha e deve se portar como tal. 
Mas, o profissional também pode trabalhar remotamente, em casa, por exemplo, utilizando 
equipamentos do contratante. Nesses exemplos, o cuidado com os aspectos de segurança 
são ainda mais presentes.
Muitas vezes você poderá participar de projetos sigilosos ou ter acesso a documentos 
confidenciais de uma empresa contratante. O cuidado com o sigilo é parte do nosso trabalho, 
manter-se como um profissional ético e íntegro traz visibilidade para a sua carreira. 
Outro aspecto envolve situações de conflito nas quais você poderá discordar das visões 
e dos objetivos de seus empregadores e enfrentar dilemas éticos. Por exemplo: você não 
concorda com alguma prática ilegal ou suspeita de que existam problemas no projeto em que 
trabalha. Como conduzir questões como essas? Demitir-se? Levar a questão para a diretoria? 
Bem, esses dilemas acontecem na maioria das profissões e fazem parte das nossas vidas. 
Acreditamos que você deve ter consciência do que é certo ou errado e manter-se na linha da 
ética e integridade. 
Para saber mais sobre questões éticas e profissionais importantes para os 
engenheiros de software, acesse a Midiateca. 
Considerações finais
Chegamos ao fim desta aula! Como você pôde perceber, a Engenharia de Software é uma 
área de conhecimento muito importante e cria condições para desenvolvermos produtos de 
software mais robustos e eficientes, de modo a melhorar a vida das pessoas que dependerão 
desses produtos.
Os profissionais que trabalham nessa área, além do domínio técnico, buscam ampliar suas 
habilidades de comunicação e relações interpessoais para entender melhor as necessidades 
dos seus clientes. Além disso, apropriam-se de técnicas, métodos e práticas para dominar 
a complexidade do seu trabalho, na produção de infinitas possibilidades de sistemas de 
informação para a nossa sociedade.
Esperamos que você tenha se motivado a conhecer mais sobre o assunto. 
Até mais!
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
12
Referência
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
Engenharia de Software
Aula 02
Processo de desenvolvimento de software: sequencial 
e evolucionário
Objetivos Específicos
• Identificar os elementos do ciclo de vida do software, entender o conceito
de processo de software e os modelos de processo de software clássicos e
suas características.
Temas
Introdução
1 Ciclo de vida e processo de software
2 Características do software
3 Modelo de processo de software
Considerações finais
Referências
Professora
Ana Cláudia Rossi
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
2
Introdução
O objetivo desta aula é conhecer os elementos envolvidos no ciclo de vida do software 
e compreender os conceitos fundamentais e os elementos do processo de dele. Além disso, 
também serão apresentados os modelos de processo de software em cascata, incremental e 
evolucionário.
Assim, ao terminar esta aula você deverá ser capaz de:
• compreender os conceitos do ciclo de vida do software, processo de software e 
modelo de processo de software, e em qual contexto cada um desses conceitos deve 
ser usado;
• conhecer as etapas fundamentais do processo de software, que são: engenharia de 
requisitos, projeto arquitetural, implementação, testes e evolução;
• compreender o impacto das mudanças de requisitos do software, como os modelos 
de processo tratam essas mudanças e como elas influenciam no custo, no cronograma 
e na qualidade do software;
• conhecer dois modelos de processo de desenvolvimento de software, e qual o 
contexto de adoção desses modelos em uma organização. Além de acompanhar 
quais são as vantagens e desvantagens de cada um.
Vamos começar com alguns conceitos fundamentais da Engenharia de Software, tais 
como ciclo de vida de um software, processo de software e modelo de processo de software.
1 Ciclo de vida e processo de software
O termo ciclo de vida é definido pela norma ISO/IEC 12.207 como a evolução de um 
sistema, produto, serviço, projeto ou outra entidade construída por seres humanos desde sua 
concepção até a descontinuação (ISO/IEC 12.207, 2011). Dessa forma, o conceito de ciclo 
de vida de software abrange o período de tempo desde a concepção até a descontinuação 
do uso do software em uma organização, ou seja, as fases de concepção, requisitos, projeto, 
implementação, testes, implantação, manutenção (ou evolução) e descontinuação do uso (ou 
retirada de operação). 
Já o conceito de modelo de ciclo de vida é definido como um framework de processo e 
atividades preocupadas com o ciclo de vida, que deve ser organizado em fases, que também 
atuam como uma referência comum para a comunicação e o entendimento do mesmo (ISO/
IEC 12.207, 2011), ou seja, o modelo de ciclo de vida do software é uma abstração do ciclo 
de vida real.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
3
É muito comum os termos ciclo de vida de software e processo de 
software serem usados de forma indistinta, entretanto, segundo Hirama (2012), 
o conceito de processo está ligado a um conjunto de atividades relacionadas 
para atingir um objetivo, enquanto que ciclo de vida, é um período entre a 
concepção e a desativação do software.
Segundo Sommerville (2011), processo de software é definido como um conjunto de 
atividades e resultados associados que produz um produto de software, que são divididos 
em quatro fases fundamentais de processo: Especificação de software: levantamento e 
especificação das funcionalidades do software e as restrições sobre suaoperação.
• Projeto e implementação de software: construção do software que atenda 
à especificação.
• Validação de software: garantia de que o software esteja de acordo com o que foi 
especificado e que o software faça o que o cliente deseja dele.
• Evolução de software: manutenção e evolução do software para atender às 
necessidades mutáveis do cliente.
A figura 1 apresenta uma esquematização genérica das fases fundamentais do processo 
de software:
Figura 1 – Esquematização das fases fundamentais do processo de software
Fonte: Elaborada pela autora (2014). 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
4
Podemos observar através da figura que nas fases de especificação e projeto, o software 
é representado de forma mais abstrata, através de textos e notações gráficas, como os 
diagramas UML (Unified Modeling Language), enquanto nas fases de teste, implementação 
e evolução a representação do software se encontra mais concreta, ou seja, já temos a 
implementação do software, que pode ser executado e ter o seu comportamento observado.
No processo de produção e evolução do software estão envolvidas várias pessoas, com 
papéis e habilidades diversas, que produzem diferentes artefatos de software e em distintos 
momentos do processo. Nesse contexto, os modelos de processo de software têm a finalidade 
de estabelecer:
• os papéis; 
• as atividades a serem executadas; 
• o que deve ser consumido e produzido em cada atividade;
• em que momento do processo de software eles acontecem.
Segundo Sommerville (2011), um modelo de processo de software é uma representação 
simplificada de um processo de software, sendo que cada modelo representa uma perspectiva 
particular de um processo, e como consequência fornece informações parciais sobre ele. Não 
existe um processo de software adequado para todas as organizações e para todos os tipos 
de software produzidos, assim, as organizações definem seus processos de software a partir 
de modelos de processo existentes na literatura, através de adaptações e adoções de práticas 
que combinem características de modelos de processos de software.
Por exemplo, podemos citar o contexto de sistemas críticos, que é 
necessário à adoção de um processo de desenvolvimento de software muito 
bem estruturado e formal, enquanto que no contexto de sistemas de negócios 
corporativos, com requisitos que se alteram de forma mais rápida é mais 
adequado à adoção de um modelo de processo menos formal e mais flexível. 
(SOMMERVILLE, 2011).
Nesse contexto, é essencial discutir as características do produto de software e entender 
os principais modelos de processo de desenvolvimento e suas características, bem como seu 
contexto de adoção.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
5
2 Características do software
Tanto na indústria como no meio acadêmico discute-se a necessidade de se 
produzir software com mais qualidade, produtividade, custos mais baixos e com maior 
interoperabilidade. A Engenharia de Software se torna uma área desafiadora por vários 
aspectos, como a necessidade de atender à demanda crescente de sistemas de informação, 
que apoiam processos de negócios vitais e essenciais em vários tipos de organizações, a 
necessidade de esses sistemas operarem em uma plataforma heterogênea de hardware e de 
software e se comunicarem com outros sistemas de diferentes fornecedores, entre outros. 
Os sistemas de software são elementos-chave no dia a dia de pessoas e organizações.
Nesse cenário, a construção ou evolução de um software tem origem na necessidade 
do negócio que, segundo Pressman (2011), podem ser:
• a correção de um defeito em um software existente; 
• a necessidade de adaptar um sistema legado devido à mudança no ambiente 
de negócio; 
• a demanda em estender funcionalidades e características de um software existente; 
• a necessidade de criar um novo produto, serviço ou sistema.
2.1 Dificuldades do desenvolvimento de sistemas de software
Brooks (1987) definiu quatro dificuldades inerentes do desenvolvimento de sistemas de 
software, que foram: complexidade, conformidade, modificabilidade e invisibilidade.
2.1.1 Complexidade
A complexidade está relacionada aos vários componentes de software e hardware que 
compõem uma solução de tecnologia de informação para automatizar os processos de negócio 
de uma organização e que, muitas vezes, também envolve a integração com sistemas legados 
e de organizações parceiras, de maior ou menor porte, em uma plataforma heterogênea.
2.1.2 Conformidade
A conformidade ainda é um desafio que também se faz presente, uma vez que o sistema 
de software pode ser tanto um novo desenvolvimento como também uma evolução de uma 
versão já existente, que pode necessitar de adaptações ou customizações para atender a 
diferentes organizações e, novamente, pode envolver a integração com outros sistemas. 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
6
2.1.3 Modificabilidade
Dentro desse contexto de necessidade de adaptações, de customizações e de evoluções, 
temos a modificabilidade, que está relacionada às pressões por mudanças e as alterações 
constantes que o software está sujeito, devido a alguns fatores, como: mudanças em estratégias 
organizacionais, novos requisitos, evolução tecnológica ou novas leis de regulamentações 
governamentais.
2.1.4 Invisibilidade
A dificuldade da invisibilidade está relacionada ao fato de que o software não é 
espacialmente representável, ou seja, não existe um diagrama ou esquema lógico que o 
descreva de forma que proporcione um fácil entendimento entre os diferentes envolvidos no 
seu processo de desenvolvimento e evolução (BROOKS, 1987). 
2.2 As representações abstratas do sistema
Para obter um entendimento do sistema são necessárias muitas representações 
abstratas, através de técnicas, métodos, documentos e ferramentas. Elas devem atender a 
diferentes visões dos envolvidos com relação ao contexto do sistema. Além desses aspectos, 
os envolvidos podem ter necessidades específicas de informação sobre o sistema e seu 
ambiente, em diferentes fases do processo de software e também possuir um conhecimento 
diverso com relação ao domínio das técnicas, dos métodos e das ferramentas de representação 
abstrata do sistema.
As dificuldades acidentais apontadas por Brooks (1987) ainda são preocupações para 
o engenheiro de software no contexto atual, além de serem muito discutidas na literatura. 
Como lidar com esses desafios é o campo de estudo da Engenharia de Software.
3 Modelo de processo de software
Nas pesquisas realizadas pelo SEI (Software Engineering Institute), para auxiliar 
organizações a desenvolver e manter a qualidade nos produtos e serviços de software, 
foram identificadas três dimensões que as organizações devem focar para a melhoria de seu 
negócio (nesse caso, construção e evolução de software): pessoas, procedimentos e métodos, 
ferramentas e equipamentos. 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
7
Figura 2 – As três dimensões críticas do processo
Fonte: CMMI (2010, p. 4).
Como foi observado na figura, o processo de software estabelece:
• quem faz: pessoas com habilidades, treinamentos e motivação;
• o que e quando: procedimentos e métodos definindo os relacionamentos entre 
tarefas e atividades;
• como: ferramentas e equipamentos.
Como foi definido anteriormente, um modelo de processo de software é uma 
representação simplificada de um processo de software, sendo que cada modelo representa 
uma perspectiva particular de um processo e como consequência fornece informações 
parciais sobre ele (SOMMERVILLE, 2011). 
Vamos estudar agora alguns modelos de processo.
3.1 Cascata
O modelo em cascata foi o primeiro modelo de processo publicado e recebeu este nome 
devido ao encadeamento entre uma fase e outra. A figura 3 apresenta as fases do modelo em 
cascata (SOMMERVILLE, 2011).
Senac São Paulo - Todos os Direitos Reservados
Engenhariade Software
8
Figura 3 – Modelo de processo em cascata
Fonte: Sommerville (2011, p. 20).
Segundo Sommerville (2011), as principais fases do modelo em cascata são:
• análise e definição de requisitos: os serviços, restrições e metas do sistema 
são especificados por meio de consultas aos usuários e demais envolvidos com o 
software e, em seguida, são definidos em detalhes. Depois, finalmente é gerada uma 
especificação do sistema;
• projeto de sistema e software: alocação dos requisitos tanto para os sistemas 
de hardware como para os sistemas de software, por meio da definição de uma 
arquitetura geral. Para isso, o projeto arquitetural envolve a identificação e descrição 
das abstrações fundamentais do sistema de software e seus relacionamentos;
• implementação e teste unitário: desenvolvimento do projeto como um conjunto 
de programas ou unidades de programas. Para garantir o funcionamento de cada 
unidade de programa é realizado o teste unitário para assegurar que as especificações 
foram atendidas;
• integração e teste de sistema: integração das unidades individuais do(s) programa(s) 
e realização de testes durante a integração, como também do sistema completo. 
Dessa forma, é assegurado que os requisitos de software tenham sido atendidos. 
Após a realização dos testes, o sistema é entregue ao cliente;
• operação e manutenção: instalação do sistema e disponibilização para uso. A fase 
de manutenção envolve a correção de erros que não foram identificados durante a 
fase de testes, como também a melhoria da implementação e a construção de novas 
funcionalidades em resposta à descoberta de novos requisitos.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
9
O modelo em cascata é caracterizado pela execução sequencial das 
fases, sendo que o resultado de cada uma é a aprovação de um ou mais 
documentos. Dessa forma, a fase seguinte não deve iniciar até que a fase 
anterior seja concluída. Entretanto, durante o projeto de software podem ser 
identificados problemas com requisitos de software e, como consequência, 
pode se observar que o processo de desenvolvimento de software não segue 
um fluxo linear e sequencial, mas envolve realimentação de uma fase para 
outra (SOMMERVILLE, 2011).
Pressman (2011) aponta algumas críticas com relação ao modelo em cascata:
• fluxo sequencial: dificilmente projetos reais seguem um fluxo sequencial de atividade 
como o modelo em cascata propõe;
• incerteza natural nas fases iniciais do processo: no início de muitos projetos de 
software existe uma incerteza natural, ou seja, muitas vezes o cliente ainda não 
consegue estabelecer todas as necessidades explicitamente;
• cliente deve ter paciência até a entrega do software: uma versão operacional do 
software será entregue após a fase de teste de sistema, ou seja, a experimentação do 
software pelo cliente acontece no momento de colocar em operação. Assim, se houver 
algum desvio de especificação de requisitos do usuário, isto pode ser desastroso.
Podemos observar que o modelo em cascata é recomendado quando os requisitos 
são bem compreendidos e com pouca possibilidade de mudança durante o processo de 
desenvolvimento do software (SOMMERVILLE, 2011; PRESSMAN, 2011).
Segundo Sommerville (2011), o modelo de desenvolvimento formal é uma variação 
importante do ciclo de vida em cascata, pois cria um modelo matemático para a especificação 
de um sistema. Esse modelo matemático é refinado através de transformações que preservam 
sua consistência, em código executável. Dessa forma, partindo-se do pressuposto de que suas 
transformações matemáticas estão corretas, você pode, portanto, usar um forte argumento 
que um programa gerado dessa forma é consistente com suas especificações. O modelo formal 
é usado apenas para desenvolvimento de sistemas críticos de segurança ou de proteção.
3.2 Modelo incremental
O modelo incremental visa à produção do software a partir da ideia de desenvolver 
uma implementação inicial de software, realizar uma avaliação dos usuários e continuar a 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
10
construção do software por meio da criação de versões intermediárias, até que um sistema 
adequado seja desenvolvido (SOMMERVILLE, 2011).
Figura 4 – Modelo incremental
Fonte: Sommerville (2011, p. 22).
Na figura 4, notamos que as atividades de especificação, desenvolvimento e validação 
são realizadas simultaneamente e intercaladas com rápido feedback entre todas as atividades. 
Assim, o modelo incremental reflete o modo como resolvemos problemas, ou seja, raramente 
desenvolvemos uma solução completa para um problema e sim um esboço inicial, que será 
dividido e construído em partes menores.
Segundo Sommerville (2011), as organizações que adotam o modelo 
incremental, têm um processo de produção de software com menor custo e 
maior facilidade em acomodar mudanças durante o desenvolvimento. Cada 
incremento ou versão do sistema incorpora alguma funcionalidade necessária 
para o cliente (os incrementos iniciais incluem funcionalidades que agregam 
mais valor ou são mais urgentes para o cliente).
As vantagens mais importantes do modelo incremental são (SOMMERVILLE, 2011):
• redução no custo de acomodar mudanças de requisitos: quantidade de análise e de 
documentação é menor do que no modelo em cascata; 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
11
• validação do cliente a cada entrega de versão: envolvimento do cliente no 
processo de produção de software a cada validação das versões entregues, através 
de feedback constante;
• entrega mais rápida de uma versão parcial do software para o cliente: entrega de 
versões parciais do sistema para uso em operação, agregando valor ao processo de 
negócio do cliente.
As desvantagens do modelo incremental são (SOMMERVILLE, 2011):
• falta de visibilidade no processo: a gerência precisa de entregas regulares para 
mensurar o progresso, se as entregas são muito rápidas não é viável a produção de 
documentos que reflitam cada versão do sistema;
• degradação da estrutura do sistema com a adição de novos incrementos: mudanças 
constantes tendem a corromper a estrutura do sistema se não for investido tempo 
em técnicas de refatoração para a melhoria do software.
3.3 Modelo evolucionário
Como discutimos anteriormente, uma característica do software é sua evolução ao 
longo do tempo, ou seja, conforme as fases do desenvolvimento do software avançam, temos 
mudanças nas necessidades de negócio e os produtos que mudam frequentemente, como 
consequência, torna-se inadequado um planejamento linear de um produto de software. 
Os modelos de processo evolucionário contemplam esse aspecto de possibilitar o 
desenvolvimento de um produto que evolua ao longo do tempo e são caracterizados por 
serem interativos e apresentarem características que possibilitem desenvolvermos versões 
cada vez mais completas do software. 
Considerações finais
O processo de software estabelece um conjunto de atividades relacionadas para atingir 
um objetivo e, nesse caso, quando falamos em processo de desenvolvimento de software o 
objetivo é a produção de um software. O processo define quem faz o que, quando e como, 
assim, quando iniciamos um projeto de software, precisamos nos apoiar em modelos de 
processo para nos guiar no que deve ser feito.
Nesta aula, conhecemos dois modelos de processo de software que têm o mesmo 
objetivo, ou seja, a produção de um software. O modelo em cascata organiza suas fases de 
forma sequencial e linear e em cada término de fase temos uma documentação intermediária 
que documenta o software produzido e fornece suporte às suas manutenções e evoluções 
futuras. Em contrapartida, apresenta algumas desvantagens, como a acomodação de 
mudanças de requisitos apenas no final do processo.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
12
Já o modelo incremental, a cada incremento produz um software que agrega valor ao 
cliente maisrapidamente e permite acomodar mudanças com mais facilidade, entretanto, a 
documentação dos artefatos das fases intermediárias não é seu ponto forte, como também 
não é a visibilidade gerencial das fases.
Cada modelo de processo tem suas características e é adequado para diferentes contextos 
de uso, razão pela qual devemos continuar aprofundando os estudos. 
Referências
BROOKS, F. P. No silver bullet - essence and accidents of software engineering. IEEE Computer, 
v. 20, n. 4, p. 10–19, 1987.
CMMI, CMMI® for Development, Version 1.3: in improving processes for developing better 
products and services. Software Engineering Institute - Carnegie Mellon University, 2010. 
Disponível em: <http://www.sei.cmu.edu/reports/10tr033.pdf>. Acesso em: 15 nov. 2014.
HIRAMA, K. Engenharia de software: qualidade e produtividade com tecnologia. Rio de Janeiro: 
Editora Campus, 2012.
ISO/IEC 12.207 - The International Organization for Standardization and the International 
Electrotechnical Commission. ISO/IEC 12207 information technology – Software life cycle 
processes, Geneve: ISO, 2008.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. Porto Alegre: Mcgraw 
Hill - Artmed, 2011.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
Engenharia de Software
Aula 03
Processos de desenvolvimento de software: prototipagem, 
modelo espiral, componentização e UP
Objetivos Específicos
• Entender outros processos de desenvolvimento de software e suas 
características.
Temas
Introdução
1 Processo de Desenvolvimento – Diferentes abordagens
2 Modelos de processo – Iterativos e evolucionários
Considerações finais
Referências
Ana Cláudia Rossi
Professora
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
2
Introdução
Nesta aula, conheceremos mais alguns modelos de processo de software que adotam as 
estratégias iterativa e incremental. Para isso, vamos conhecer suas características e exemplos 
de modelos de processo de desenvolvimento de software. É muito importante você observar 
as diferenças entre os processos que estamos estudando.
Portanto, ao terminar esta aula, você deverá ser capaz de:
• compreender os conceitos que envolvem os modelos de processos iterativos 
e evolucionários;
• conhecer o que é desenvolvimento de software baseado em componentes 
e prototipação;
• conhecer os principais modelos de processo iterativos e evolucionários;
• compreender as diferenças entre os modelos de processo;
• saber quais são as vantagens e desvantagens de cada um.
• Vamos continuar aprofundando nossos conhecimentos sobre modelos de processo 
de software.
1 Processo de Desenvolvimento – Diferentes abordagens
Segundo Pressman (2011), um processo de desenvolvimento de software tem 
quatro funções: 
• fornecer um guia de como estabelecer a ordem das atividades da equipe;
• especificar os artefatos que serão desenvolvidos e quando eles serão desenvolvidos;
• direcionar as tarefas individuais dos projetistas e da equipe como um todo;
• oferecer critérios para monitoração e medida dos produtos e das atividades 
do projeto.
Os modelos de processo podem ter seu fluxo de atividades organizado de diferentes 
maneiras, que são: linear, iterativa, incremental e paralela (PRESSMAN, 2011).
1.1 Estratégia linear
Nos modelos de processo que adotam a estratégia linear as atividades são executadas 
de forma sequencial e encadeada, uma após a outra, começando com especificação de 
requisitos e finalizando com a manutenção, como pode ser observado na figura 1.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
3
Figura 1 - Processo linear
Fonte: adaptado de Pressman (2011, p. 54).
1.2 Estratégia iterativa
Já nos modelos de processo que adotam a estratégia iterativa, uma ou mais atividades 
são repetidas antes de se prosseguir para as seguintes, como podemos observar na figura 2. 
Essa estratégia é adequada quando temos apenas uma ideia vaga do que queremos e iremos 
refinar os detalhes ao longo do desenvolvimento do software.
Figura 2 - Processo iterativo
Fonte: adaptado de Pressman (2011, p. 54).
1.3 Estratégia evolucionária
É importante observar que os modelos de processos que adotam a estratégia denominada 
evolucionária executam as atividades de forma circular e a cada volta conduzem a uma versão 
mais completa do software, como é apresentado na figura 3.
Figura 3 - Processo evolucionário
Fonte: adaptado de Pressman (2011, p. 54).
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
4
2 Modelos de processo – Iterativos e evolucionários
Dada a complexidade do software e a sua característica de evoluir ao longo do tempo, 
conforme as fases do desenvolvimento do software avançam, podem ocorrer mudanças nas 
necessidades de negócio e, como consequência, os produtos de software sofrerem alterações 
constantes. Isso faz com que a adoção de modelos de processo que utilizam a estratégia 
linear seja inadequada para lidar com mudanças de requisitos, como o modelo em cascata. 
Os modelos de processo que adotam a estratégia evolucionária contemplam esse 
aspecto de possibilitar o desenvolvimento de um produto que evolua ao longo do tempo.
Esses modelos evolucionários são caracterizados por serem iterativos e apresentarem 
características que possibilitem desenvolvermos versões cada vez mais completas do software, 
ou seja, o software evolui.
Vamos estudar alguns desses modelos de processo, que permitem tratar esses aspectos 
de incertezas e do software apresentar evolução ao longo do ciclo de vida dele para 
acomodar mudanças.
2.1 Prototipagem
Muitas vezes, o nosso cliente não tem certeza, ou tem apenas um objetivo muito 
genérico para o software, ou até mesmo, o desenvolvedor pode não estar muito seguro sobre 
a forma de interação entre os usuários e o sistema, ou com a ideia da solução proposta. 
Nesses casos, podemos fazer uso do modelo de prototipação para auxiliar no entendimento 
das necessidades do cliente e do contexto de uso do sistema.
Podemos entender um protótipo como uma versão inicial de um sistema de software, 
usado para demonstrar conceitos, experimentar opções de projeto e ajudar no entendimento 
do problema e a descobrir possíveis soluções (SOMMERVILLE, 2011). 
Através do protótipo, é possível o cliente/usuário ter uma ideia mais clara sobre o sistema 
e, até mesmo, ter uma experiência mais próxima do real das funcionalidades do sistema. 
Assim, o protótipo auxilia:
• na identificação de novas ideias para os requisitos e, assim, novos requisitos para 
o sistema;
• na busca por pontos fortes e pontos fracos do software;
• na revelação de erros e omissões nos requisitos propostos (SOMMERVILLE, 2011).
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
5
Podemos perceber a importância da prototipação no processo de desenvolvimento de 
software e, principalmente, na fase de requisitos e no projeto de interface gráfica de usuário.
A figura 4 apresenta o processo de desenvolvimento de protótipo.
Figura 4 - Processo de desenvolvimento de protótipo
Fonte: SOMMERVILLE (2011, p. 30).
É importante ressaltar que os objetivos da prototipação devem ser definidos desde o 
início do processo, que podem ser para projetar interface com o usuário, para desenvolver um 
sistema para validação dos requisitos funcionais do sistema ou, até mesmo, para desenvolver 
um sistema para demonstrar a validade técnica de uma solução (SOMMERVILLE, 2011).
Segundo Pressman (2011), tanto cliente quanto desenvolvedor devem estar de acordo 
que o protótipo é construído apenas para servir como um mecanismo de definição de requisitos 
e que depois será descartado (pelo menos em parte) e o software real será construído com 
foco na qualidade.
2.2 Modelo espiral
O modelo espiral é um modelo de processo proposto por Boehm (1988 apud 
SOMMERVILLE, 2011), que em vez de representar o processo como uma sequência de 
atividades, usou uma espiral para representar o encadeamento das atividades,como mostra 
a figura 5.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
6
Figura 5 - Modelo espiral
Fonte: Boehm (1998) apud Sommerville (2011, p. 33).
O modelo espiral é um exemplo de processo evolutivo, ou seja, o software é desenvolvido 
de forma evolutiva até que o produto final esteja cada vez mais completo, assim, a partir da 
figura 5 podemos observar que as atividades do modelo espiral evoluem no sentido horário, 
do centro para fora.
Como características do modelo espiral, podemos citar Hirama (2012) e Pressman (2011):
• integração entre as disciplinas de gerência de projetos e as disciplinas de 
engenharia (construção);
• diminuição dos riscos de desenvolvimento através da disciplina de análise de riscos, 
ou seja, até para iniciar o desenvolvimento é verificado se é gerencialmente e 
tecnicamente viável;
• envolvimento do cliente a cada iteração ou produto obtido.
O modelo espiral é dividido em quatro setores, que são (SOMMERVILLE, 2011):
• definição dos objetivos: definição dos objetivos específicos para a fase do projeto, 
tais como: restrições ao processo e ao produto, plano de gerenciamento, identificação 
de riscos de projeto e, também, pode ser elaborado um plano de alternativas em 
função dos riscos;
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
7
• avaliação e redução de riscos: é realizada a avaliação dos riscos técnicos e gerenciais 
identificados e medidas para redução dos riscos são tomadas;
• desenvolvimento e avaliação: envolvem as atividades de engenharia, construção 
e validação;
• planejamento: revisão do projeto e decisão sobre a próxima espiral, caso seja 
decidido pela continuidade, mais um incremento é realizado, para isso, planos são 
elaborados para a próxima fase.
2.3 Componentização
Durante as fases do processo de desenvolvimento de software observa-se que alguns 
artefatos de software gerados (especificações, projeto de arquitetura, código-fonte, casos 
de teste e outros) são similares, ou até mesmo iguais, a outros confeccionados em outros 
projetos. O que se percebe que uma grande quantidade de esforço, em geral, é desperdiçada. 
Esses artefatos de software desenvolvidos no contexto de outros projetos podem ser 
utilizados em novos projetos, com o intuito de diminuir o retrabalho realizado durante o 
processo de desenvolvimento de um produto de software.
A combinação de reuso de software e componentes de software é uma alternativa 
para alcançar a produtividade na elaboração de um produto de software com qualidade, 
visando custos mais baixos no processo de desenvolvimento. Como consequência, o 
processo de desenvolvimento baseado em componentes é apontado como uma abordagem 
de desenvolvimento que promove a redução do custo e do tempo de desenvolvimento de 
sistemas de software.
O componente de software é um dos principais artefatos de software que pode ser 
usado e reusado para a construção de novos sistemas. O reuso de software pode ser obtido 
por meio do desenvolvimento baseado em componentes, ou seja, um novo sistema pode ser 
construído utilizando partes (componentes), que foram criadas para compor outro sistema.
Deste modo, essa abordagem tem como premissa fundamental a construção de um 
sistema de software a partir de componentes de software já existentes. Isso contrasta com 
o processo de desenvolvimento tradicional, em que praticamente todos os elementos são 
construídos. Como qualquer processo de desenvolvimento, o processo de desenvolvimento 
de software baseado em componentes envolve uma sequência lógica de fases constituídas de 
atividades, que transformam os artefatos de entrada em artefatos de saída para construir o 
sistema desejado. Entretanto, essa abordagem difere da tradicional, pois um sistema é obtido 
através do uso de componentes de software.
Apesar de não serem iguais, os modelos de processo baseados em componentes, 
encontrados na literatura de engenharia de software, possuem um conjunto de fases em 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
8
comum, que são (PRESSMAN, 2011): análise de requisitos, aquisição do componente, 
entendimento do componente, adaptação do componente, composição do componente e 
certificação do componente.
Podemos observar que o reuso de software está implícito dentro dessa abordagem, 
uma vez que um sistema de software é construído a partir de componentes de software 
previamente construídos e, além disso, um ou mais componentes podem ter sido utilizados 
para a construção de outro sistema de software.
O processo de desenvolvimento baseado em componentes possui dois enfoques a 
serem considerados: 
• desenvolvimento de componentes de software para reuso: trata-se da construção 
de componentes de software para reuso. Para isso, são realizadas as atividades de 
construção de modelos de domínios e arquitetura, construção de novos componentes, 
ou reengenharia de componentes existentes para melhorar a sua reusabilidade;
• desenvolvimento de software com reuso de componentes: trata do uso de 
componentes de software desenvolvidos com propósito de serem reutilizados para a 
obtenção de sistemas. Suas atividades são relativas ao processo de desenvolvimento, 
incluindo a identificação e a busca de componentes reutilizáveis na base de 
reutilização, a construção de novo componente de software (se necessário) ou sua 
adaptação ou composição.
2.4 Modelo UP (Unified Process – Processo Unificado)
O processo unificado adota o desenvolvimento de software baseado em componentes, 
ou seja, prevê que o sistema de software pode ser construído através da composição de 
componentes de software interconectados através de interfaces bem definidas. Segundo 
Pressman (2011), utilizando a Unified Modeleing Language (UML) – Linguagem de 
Modelagem Unificada, o processo unificado define os componentes de software que serão 
usados para construir o sistema e as interfaces, que fornecem meios para a conexão entre 
os componentes.
O processo unificado adota o desenvolvimento iterativo e incremental e define as funções 
do sistema aplicando uma abordagem baseada em cenários denominada modelo de casos de 
uso (PRESSMAN, 2011).
O RUP é uma instância mais específica do Processo Unificado e as melhores práticas 
de processos de software incorporadas neste processo são Pressman (2011) e Sommerville 
(2011):
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
9
• desenvolvimento iterativo;
• gerência de requisitos;
• utilização de arquitetura e componentes;
• modelagem visual através da UML;
• qualidade de processo e de produto;
• gerência de configuração e versões;
• casos de uso dirigindo muitos aspectos do desenvolvimento;
• modelo de processo de desenvolvimento, que pode ser adaptado e estendido para as 
características da organização;
• necessidade de ferramentas de desenvolvimento de software para fornecer suporte 
ao processo.
A figura 6 apresenta um exemplo da estrutura do RUP, suas fases e seu núcleo do fluxo 
de trabalho.
Figura 6 - Estrutura, fases, iterações e o fluxo de trabalho da estrutura do RUP 
Fonte: Ambler (2008, p. 220).
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
10
É importante destacar que no eixo vertical, da estrutura do RUP, está a representação 
dos fluxos de trabalho do processo, consistindo basicamente de: modelagem de negócio, 
gerência de requisitos, análise e projeto, implementação, teste e distribuição. Podem existir 
outros elementos no ciclo de vida e cada elemento é apoiado por ferramentas e guias de 
processos, descrevendo cada um deles e sua aplicação.
O eixo horizontal representa o tempo e mostra como os componentes do ciclo de vida do 
processo são desdobrados através das suas fases. Essa representação descreve os aspectos 
dinâmicos do processo como ele ordena e expressa em termos de ciclos, fases, iterações e 
os pontos de verificação, sendo que, dentro de cada fase, gerentes ou projetistas podem 
dividir o trabalhoem duas ou mais iterações e cada fase termina com um ponto de verificação 
(SOMMERVILLE, 2011). 
Cada fase do processo é descrita a seguir:
• concepção: definição clara do que é o produto a ser desenvolvido; para isso, devem 
ser estabelecidos o escopo do sistema, uma visão inicial dos casos de uso principais, 
as condições limites e o critério de aceitação;
• elaboração: elaboração da especificação detalhada de mais casos de uso do produto 
e da arquitetura do sistema. Essa fase pode ser executada em uma ou mais iterações, 
dependendo do escopo, tamanho e do nível de domínio sobre o assunto do projeto;
• construção: processo de produção do produto, ou seja, implementação do software, 
integração, teste dos componentes e avaliação da versão dos produtos em relação 
aos critérios de aceitação. O resultado dessa fase é o produto que incorpora todos os 
casos de usos, definidos pelo cliente e pela gerência, para fazer parte dessa versão;
• transição: conjunto de atividades que conduzem o produto obtido ao ambiente de 
produção, compreendendo, por exemplo, manufatura, treinamento de usuário, 
suporte e correção de erros encontrados depois da entrega. 
Para mais informações sobre o processo de desenvolvimento de software, 
acesse a Midiateca. 
Considerações finais
Refletindo sobre o que estudamos até agora, podemos perceber que a mudança é 
inevitável na maioria dos projetos de software uma vez que (SOMMERVILLE, 2011):
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
11
• requisitos dos sistemas mudam em decorrência de mudanças nos processos de 
negócio devido a pressões externas e que mudam as prioridades gerenciais;
• disponibilidade de novas tecnologias e, assim, novas possibilidades de implementação 
e novos projetos;
• novas necessidades ou novos processos que precisam de automação.
Ou seja, a evolução do software ocorre quando se alteram os sistemas atuais de software 
para atender aos novos requisitos e essas mudanças são contínuas para o software continuar 
sendo útil dentro da organização.
Assim, podemos concluir que os modelos de processo de software devem ser capazes de 
lidar com a mudança e a evolução dos sistemas de software.
Referências
AMBLER, S. W. Modelagem ágil: práticas eficazes para programação extrema. Porto Alegre: 
Bookman, 2008.
HIRAMA, K. Engenharia de software: qualidade e produtividade com tecnologia. Rio de Janeiro: 
Campus, 2012.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. Porto Alegre: Mcgraw 
Hill - Artmed, 2011.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
Engenharia de Software
Aula 04
Metodologia ágil
Objetivos Específicos
• Entender os princípios e valores da metodologia ágil e as características dos 
modelos de processos ágeis. 
Temas
Introdução
1 Desenvolvimento ágil
2 Movimento ágil
3 Scrum
4 Extreme programming
Considerações finais
Referências
Ana Cláudia Rossi
Professora
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
2
Introdução
Vamos começar a nossa aula sobre metodologias ágeis!
O objetivo desta aula é conhecer o movimento ágil, sua filosofia e os principais processos 
adotados por equipes de desenvolvimento de software. Vamos observar as diferenças entre 
eles e a quebra de paradigma que temos em relação aos processos prescritivos, como o 
Modelo Cascata e o evolucionário.
Portanto, ao terminar esta aula, você deverá ser capaz de:
• compreender os conceitos que envolvem o desenvolvimento ágil;
• conhecer os principais métodos ágeis;
• compreender as diferenças entre os modelos de processo do movimento ágil e os 
modelos de processo prescritivos;
• conhecer com mais detalhes dois modelos de processo do movimento ágil, que são: 
SCRUM e XP (Extreme Programming).
Vamos começar conhecendo o manifesto ágil e o que impulsionou esse movimento.
1 Desenvolvimento ágil
No cenário atual, as empresas operam em um ambiente globalizado e muito suscetível 
a mudanças. Como sabemos, o software é parte importante deste ambiente e também é 
impactado por mudanças que vão desde a economia mundial até questões operacionais da 
empresa, em que se fazem necessários ajustes rápidos para garantir a competitividade no 
setor de atuação.
Sendo assim, considere o tempo necessário para executar todas as etapas de um 
processo de software. Neste tempo, contado desde a elicitação de requisitos até a entrega 
do produto, mudanças no ambiente podem ocorrer e gerar alterações nos requisitos 
inicialmente desenhados.
Portanto, um processo de software que planeja especificar completamente todos os 
requisitos para depois implementar e testar o sistema, não está adaptado para o cenário 
atual que descrevemos anteriormente.
Necessitamos de processos de desenvolvimento rápido, concebidos para lidar com as 
mudanças enfrentadas pelas empresas da atualidade. Sommerville (2011) indica que essas 
questões já eram conhecidas e estudadas na década de 1980, quando a IBM introduziu o 
desenvolvimento incremental. Nessa linha, as ferramentas de quarta geração também foram 
introduzidas, objetivando entregas mais rápidas.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
3
Sendo assim, para o ciclo de vida de um produto de software, podemos criar um 
processo de software específico, mais adequado para o escopo delineado e as características 
do produto que iremos desenvolver.
Por esse motivo, a engenharia de trabalha em constante empirismo, ou seja, 
experimentando novas formas de produção mais eficientes, em menor tempo, com menor 
custo e com mais qualidade. Fazer mais com menos poderia ser uma diretiva dessa área.
Mas a ideia decolou de fato no final da década de 1990, com o desenvolvimento das 
abordagens ágeis, que são:
• Desenvolvimento de Sistemas Dinâmicos (DSDM) (STAPLETON, 1997);
• Scrum (SHWABER; BEEDLE, 2001);
• Extreme Programming (BECK, 1999).
Os processos ágeis de desenvolvimento, também conhecidos como métodos ágeis, 
foram concebidos para produzir softwares úteis rapidamente. Partindo do princípio de 
que um software pode ser desenvolvido por partes, podemos então planejar uma série 
de incrementos de software (partes), cada uma atendendo uma ou mais funcionalidades 
do sistema.
Nesse raciocínio, a produção de cada incremento poderia ser submetida a um processo 
de software previamente desenhado. Se trabalharmos nesse modo de produção, as chances 
de gerar um produto desatualizado, ou não compatível com as necessidades da empresa, 
serão menores, pois, além de distribuir a atividade de especificação ao longo do projeto, a 
cada incremento, teremos uma visão mais madura do produto que estamos criando.
Podemos observar na Figura 1 que no desenvolvimento convencional, a especificação 
inicia-se somente após o fim da fase de engenharia de requisitos. O mesmo ocorre para a 
fase de projeto e implementação. Se há mudanças de requisitos o processo reinicia-se. No 
caso do desenvolvimento ágil, existe uma interação direta entre a engenharia de requisitos e 
a fase de projeto e implementação, ou seja, a especificação ocorre dentro da fase de projeto 
e implementação, a cada novo incremento de software. 
Figura 1 – Especificações no desenvolvimento convencional e desenvolvimento ágil
Fonte: Adaptada de Sommerville (2011, p. 43).
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
4
2 Movimento ágil
Em 2001, um grupo de simpatizantes do desenvolvimento ágil se reuniu para escrever o 
que ficou conhecido como manifesto ágil, que consiste em uma declaração de valores comuns 
aos processos de software denominados ágeis. O Manifesto Ágil (2001) declara que:
Estamos descobrindo melhores maneiras de desenvolver softwares, fazendo-o e 
ajudando outros a fazê-lo. Através deste trabalho valorizamos mais:
• indivíduos e interações do que processos e ferramentas; 
• software em funcionamento do que documentação abrangente; 
• colaboração com o cliente do que negociação de contratos; 
• responderàs mudanças do que seguir um plano.”
Esses princípios resultam de anos de experiência em desenvolvimento de software, 
observando problemas e experimentando alternativas ao desenvolvimento tradicional. 
2.1 Indivíduos e interações
O primeiro item diz respeito aos indivíduos e às interações. Estamos falando das 
equipes de software que devem ser mais colaborativas entre si, trocando experiências e 
compartilhando lições aprendidas a cada novo projeto.
Na prática, o cliente está preocupado com a compra de um software que funcione 
e atenda às suas necessidades. O processo de software pode vir a ser desgastante e não 
alcançar o sucesso esperado. Por esse motivo, engenheiros de software preocuparam-se em 
criar princípios que pudessem minimizar os problemas comuns em projetos de software.
2.2 Software em funcionamento
Com relação ao segundo valor, software funcionando com documentação extensa, 
segundo Cohn (2011) o movimento ágil foi mal interpretado como sendo contra a 
documentação. Ainda segundo o autor, deve existir um equilíbrio entre o que é documentado 
e o que não é documentado, mas registrado em código-fonte e testes automatizados 
(COHN, 2011). 
Assim, podemos perceber que ninguém está dizendo: “não faça documentação”, como 
muitos pregam no movimento ágil. Apenas estabelecemos graus de importância para as 
coisas. Documentação é importante e deve ser feita. Porém, o cliente espera um software. 
Esse é o produto mais importante. 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
5
Existem situações em que 40% do tempo de projeto é destinado somente 
para documentação e reduz-se o tempo de teste para atingir esta meta. Será 
que esse é o melhor cenário para produzir software?
2.3 Colaboração com o cliente
O terceiro princípio diz respeito à participação do cliente de um modo mais próximo do 
desenvolvimento. O cliente colabora mais com a equipe de desenvolvimento em um contexto 
em que as entregas são realizadas em um espaço de tempo menor, com uma versão de software 
que agrega valor ao cliente e, assim, permitindo que ele realize um feedback contínuo e 
frequente. Desta forma, os feedbacks podem gerar mudanças na versão do software e, como 
consequência, a equipe de desenvolvimento deve responder a essas mudanças. 
Podemos perceber que os contratos formalizam as relações entre cliente e desenvolvedor, 
entretanto, o grande objetivo é entregar valor ao cliente, independentemente do que está 
descrito e registrado em um contrato assinado. Desta forma, quando uma rotina não está de 
acordo com as especificações, ou quando percebemos que determinada funcionalidade foi 
especificada de forma errada, as correções são acionadas e processadas de modo 
mais rápido.
Sabemos que o custo de correção de algum item no projeto de software 
aumenta sobremaneira na medida em que as fases do projeto avançam. Por 
esse motivo, o quanto antes o erro for detectado, mais em conta será o custo 
da correção. 
2.4 Responder a mudanças
O quarto princípio fala de mudanças. Este ponto remete ao que escrevemos no início 
desta aula. Estar suscetível a mudanças, porém seguindo o plano maior que é a entrega do 
produto funcionando e com qualidade. Para isso, gerenciar mudanças em desenvolvimento 
de software é fundamental. Tudo que mudamos tem impacto no tempo e no custo. A famosa 
frase “isso é fácil, deixa que eu resolvo” não adere às boas práticas de engenharia de software. 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
6
Tudo deve ser ponderado antes de tomar a decisão. Contudo, isso não quer dizer: “melhor 
não mudar”.
Lembre-se sempre de que o cliente precisa de um produto que atenda às suas 
necessidades. Se uma mudança solicitada não for atendida, provavelmente, o produto final 
poderá não atender às necessidades.
Geralmente produtos de software representam um modelo computacional de um 
processo que era manual e foi modificado com melhorias e benefícios da computação. 
Entender esses processos e criar produtos de qualidade está entre os nossos desafios. 
Participaram do manifesto importantes personalidades da área de 
engenharia de software, como Kent Beck, Mike Beedle, Arie van Bennekum, 
Alistair Cockburn, Ward Cunningham, Jon Kern, Martin Fowler, James Grenning, 
Jim Highsmith, Andrew Hunt, Ron Jeffries, Ken Schwaber, Brian Marick, Robert 
C. Martin, Steve Mellor, Dave Thomas e Jeff Sutherland. A maioria deles tem 
livros, artigos e materiais disponíveis na web. Vale a pena pesquisar e estudar 
mais sobre o assunto. 
E, para saber mais sobre o manifesto ágil, acesse a Midiateca. 
3 Scrum
Schwaber e Sutherland (2013) definem Scrum como um framework em que as pessoas 
podem tratar e resolver problemas complexos e adaptativos, enquanto entregam de forma 
produtiva e criativa, produtos com mais valor. 
O Scrum não é um processo ou uma técnica, é um framework, ou seja, um conjunto de 
conceitos que são aplicados para resolver um problema de domínio específico. No caso, o 
problema do processo de software. A ideia básica é compor uma equipe, chamada de equipe 
Scrum, que terá papéis específicos, eventos e artefatos (documentos, ou qualquer coisa 
produzida durante o processo) e regras.
Nesse framework, os papéis específicos são:
• Equipe de Desenvolvimento – É um grupo de pessoas auto-organizável e 
multifuncional. Você não vai encontrar pessoas com papéis específicos, como 
desenvolvedor ou tester, todos trabalham multifuncionalmente. Segundo Cohn 
(2011) o tamanho de equipe ideal é de três a nove integrantes.
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
7
• Product Owner – Também denominado de dono do produto, sua responsabilidade 
é garantir que se dedique ao objetivo correto, para isso, ele redige os requisitos e 
define as prioridades (COHN, 2011). Ele gerencia o backlog do produto, que é uma 
lista de tarefas que, quando finalizada, encerra o produto.
• Scrum Master – É o responsável por garantir que o framework Scrum seja entendido 
e aplicado pela equipe Scrum e, também, atua como um facilitador para remover 
impedimentos ao progresso da equipe durante as construções de uma versão do 
software (COHN, 2011). 
Além dos papéis, temos os eventos Scrum. A Figura 2 resume o sequenciamento 
desses eventos.
Figura 2 – Fluxo do processo Scrum
Fonte: Pressman (2011, p. 96).
O backlog do produto (ou product backlog) é um artefato Scrum. Representa uma lista 
ordenada de tudo que deve ser feito no produto. Essa lista é gerenciada pelo product owner. 
Dessa lista, selecionam-se os itens que serão entregues em um incremento de software. Os 
incrementos de software são desenvolvidos em sprints.
Um sprint pode durar de duas a quatro semanas. Isso é dimensionado pela equipe 
Scrum. Durante um sprint, existem ritos que devem ser seguidos para manter o framework 
em funcionamento. São exemplos, reuniões diárias, uso do gráfico burndown, burnup ou 
similares, monitoramento do sprint e outros. 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
8
4 Extreme programming
Mais conhecido por XP, é talvez o método ágil mais utilizado. O termo XP foi cunhado 
por Beck em 2000 e se baseou em uma coletânea de práticas reconhecidamente boas, como 
o desenvolvimento iterativo (por meio de iterações ou fases), ou a programação em pares. 
Esse conjunto de práticas foi resumido em Sommerville (2011) e reproduzido no Quadro 1:
Quadro 1 – Princípios do extreme programming
Princípio ou prática Descrição
Planejamento incremental
Requisitos são gravados em cartões de história e as histórias 
incluídas em um release são determinadas pelo tempo disponível 
e prioridade. Os desenvolvedores dividem as histórias em tarefas.
Pequenos releases
Inicia-se pelo desenvolvimento de um conjunto mínimo de 
funcionalidades úteis, que fornecem valor ao negócio. Os 
próximos releases vão gradualmente adicionando novas 
funcionalidades ao primeiro release.
Projeto simples Cada projeto é executado para atender àsnecessidades atuais.
Desenvolvimento baseado 
em testes
Utiliza-se um framework inicial de testes automatizados para 
escrever os testes de uma nova funcionalidade, antes que a 
funcionalidade seja implementada.
Refatoração Todos os desenvolvedores devem refatorar continuamente para manter o código simples e de fácil manutenção.
Programação em pares Os desenvolvedores trabalham em pares, verificando o trabalho do outro e prestando apoio para um bom trabalho.
Propriedade coletiva
Os desenvolvedores trabalham em todas as áreas do sistema 
de modo a não desenvolver ilhas de expertise. Todos os 
desenvolvedores assumem a responsabilidade por todo o código.
Integração contínua
Assim que o trabalho em uma tarefa é concluído, ele é integrado 
ao sistema como um todo. Após a integração, os testes unitários 
são repetidos.
Ritmo sustentável Grandes quantidades de horas-extras não são aceitáveis, pois geram muitas vezes um trabalho de baixa qualidade.
Cliente no local É necessário um representante usuário final disponível a todo o tempo para a equipe XP. O cliente é membro da equipe. 
Fonte: Adaptado de Sommerville (2011, p. 45).
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
9
O XP apresenta uma abordagem extrema para o desenvolvimento incremental. Novas 
versões do software podem ser disponibilizadas no mesmo dia e um release é entregue ao 
cliente em períodos curtos de tempo.
Prazos não são desrespeitados. Se houver problemas na entrega do release, o cliente é 
consultado e a funcionalidade problemática pode ser retirada do release.
Aspectos como a programação em pares ou a refatoração podem ser polêmicos para 
alguns profissionais de engenharia de software, pois existem controvérsias sobre a 
produtividade quando se utilizam essas práticas. Segundo Sommerville (2011) foram 
realizados estudos sobre produtividade de programadores para avaliar a eficiência 
dessa prática.
No estudo realizado por Cockburn e Williams (2001) apud Sommerville 
(2011), usando estudantes voluntários, a conclusão do estudo foi que a 
produtividade na programação em pares foi comparável a duas pessoas que 
trabalham de forma independente. Entretanto, na pesquisa realizada por 
Arisholm et al (2007) apud Sommerville (2011) e Parrish et al (2004) apud 
Sommerville (2011), como programadores experientes, não foi possível replicar 
o resultado, e sim, perceberam uma perda significativa de produtividade em 
comparação com dois programadores trabalhando sozinhos. Ainda segundo os 
autores, apesar do benefício na qualidade, não havia compensação na perda 
de produtividade. 
Entretanto, os entusiastas do XP garantem que a programação em pares permite 
agilidade, porque muitas vezes o desenvolvedor demora muito tempo para encontrar uma 
solução de código e, quando se trabalha em pares, duas cabeças pensam melhor do que uma. 
Já a refatoração é uma prática interessante, pois quando você revê um código, pode pensar 
em estratégias mais simples para resolver o mesmo problema, além de fazer uso de padrões 
de refatoração para melhorar um código-fonte, como os propostos por Fowler (2004).
Considerações finais
Como vimos, o movimento ágil trouxe novas abordagens para o desenvolvimento de 
software, de modo a propiciar desenvolvimento mais rápido e de qualidade.
Vimos dois métodos que atualmente são expoentes no mercado de desenvolvimento 
de software: Scrum e XP. Contudo, existem outros métodos que podem ser consultados para 
estudos mais aprofundados como: 
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
10
• Feature Driven Development;
• Crystal Clear;
• Adaptive Software Development.
Ou ainda, existem experiências que misturam partes de um ou outro método ágil, 
propondo métodos híbridos. Também vamos encontrar nessa área práticas da indústria 
de manufatura que foram inseridas no contexto do desenvolvimento de software, como o 
Kanban e o Lean. 
Portanto, este é um tema muito envolvente e apresenta diversas possibilidades de 
investigação para os interessados no assunto. O mercado vem gradativamente se inserindo 
nessas práticas, sempre na expectativa de buscar melhores métodos para desenvolver 
softwares no prazo, sem ultrapassar o orçamento e com qualidade. 
Referências
BECK, K. Embracing Change with Extreme Programming. IEEE Computer, v. 32. N. 10, 1999. P. 
70-78.
COHN, M. Desenvolvimento de software com Scrum: aplicando métodos ágeis com sucesso. 
Porto Alegre: Editora Bookman, 2011.
FOWLER, M. Refatoração: aperfeiçoando projeto de código existente. Porto Alegre: Editora 
Bookman, 2004.
MANIFESTO ÁGIL. Disponível em: <http://agilemanifesto.org>. Acesso em: 06 dez. 2014.
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. Porto Alegre: Mcgraw 
Hill - Artmed, 2011.
SCHAWABER, K.; SUTHERLAND, J. The Scrum Guide. Disponível em: <http://www.scrumguides.
org/>. Acesso em: 06 dez. 2014.
SCHAWABER, K.; BEEDLE, M. Agile software development with Scrum. Englewood Cliffs, N. J.: 
Prentice Hall, 2001.
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
STAPLETON, J. DSDM: Dynamic system development method. Harlow, Reino Unido: Addison 
- Wesley, 1997.
Engenharia de Software
Aula 05
Gerência de projetos
Objetivos Específicos
• Entender as principais tarefas de um gerente de projetos no ciclo de vida 
de desenvolvimento e os fatores que influenciam o trabalho em equipe, 
comunicação, organização e composição da mesma.
Temas
1 Gerência de projetos de software
2 Planejamento de projeto
Considerações finais
Referências
Professora
Ana Cláudia Rossi
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
2
Introdução
Vamos começar a nossa aula de Gerência de Projetos!
O objetivo desta aula é conhecer a área de gerenciamento de projetos de software, suas 
principais atividades e importância para o sucesso de um projeto de software.
Portanto, ao terminar esta aula você deverá ser capaz de:
• conhecer as principais tarefas de um gerente de projeto;
• compreender o conceito de risco e ter noções de como realizar o gerenciamento 
de riscos;
• entender os fatores que influenciam a motivação das equipes de software e o impacto 
que isso tem nos projetos de software;
• entender os aspectos envolvidos no trabalho em equipe;
• conhecer algumas noções de planejamento de projeto de software.
Vamos começar discutindo o que é gerência de projetos, suas atividades e importância.
1 Gerência de projetos de software
Um dos trabalhos do engenheiro de software é participar de projetos de desenvolvimento 
de um produto de software ou de um serviço. Mas o que é um projeto?
Segundo o PMBOK (2014), projeto é um esforço temporário empreendido para criar um 
produto, serviço ou resultado exclusivo. Neste contexto, o termo temporário significa que o 
projeto tem uma duração definida. Ou seja, um projeto tem início e fim bem definidos. Ainda 
de acordo com a definição, é importante ressaltar também que o termo esforço, no contexto 
de projeto, refere-se aos recursos humanos e materiais empregados, durante o período, que 
são utilizados para o desenvolvimento do produto ou serviço e atingir o resultado. Esses 
recursos devem ser coordenados e administrados, para que os objetivos e resultados 
esperados pelo projeto sejam atingidos dentro do orçamento e no tempo previsto. 
As características de um projeto são as seguintes (PMBOK, 2014):
• objetivo: o projeto tem um objetivo definido no início e que deve ser alcançado 
ao final;
• ciclo de vida definido: o projeto tem um ciclo de vida que envolve as seguintes 
etapas: iniciação, planejamento, execução, controle e encerramento;
• complexidade: um projeto pode existir em diferentes níveis de complexidade, do 
mais simples ao mais complexo;
Senac São Paulo - Todos os Direitos Reservados
Engenharia de Software
3
• singular: produz um produto, serviço ou resultado único;
• riscos: a execução de um projeto envolve riscos que podem prejudicar o atingimento 
de