modelagem

Prévia do material em texto

2016
ModelageM de SiSteMaS 
eMpreSariaiS
Prof. Neli Miglioli Sabadin
Copyright © UNIASSELVI 2016
Elaboração:
Prof. Neli Miglioli Sabadin
Revisão, Diagramação e Produção:
Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri 
UNIASSELVI – Indaial.
003
S113m Sabadin; Neli Miglioli 
Modelagem de sistemas empresariais/ Neli Miglioli Sabadin: 
UNIASSELVI, 2016.
191 p. : il 
 
ISBN 978-85-7830-962-6
1. Sistemas.
I. Centro Universitário Leonardo da Vinci.
Impresso por:
III
apreSentação
Prezado (a) acadêmico (a)
Bem-vindo à disciplina de Modelagem de Sistemas Empresariais. 
Através desta disciplina verificaremos como o caminho da modelagem se 
modificou nos últimos anos, para se adequar aos constantes progressos das 
linguagens de programação, dos sistemas operacionais, dos bancos de dados, 
regras de negócio cada vez mais complexas e paradigmas da programação 
que buscam cada vez mais agilidade.
Vale lembrar que um dos assuntos mais relevantes da modelagem 
é que ela tem o objetivo de permitir o entendimento do projeto a qualquer 
pessoa da equipe, seja por parte da solicitante ou da solicitada, e em qualquer 
ponto do processo. Como já diz o ditado popular, “uma imagem vale mais 
que mil palavras”.
Conheceremos na primeira unidade os modelos de processo de 
desenvolvimento tradicionais e os modelos evolucionários. Na sequência, 
na segunda unidade, verificaremos como é realizado o levantamento dos 
requisitos e as técnicas para essa atividade, além de entendermos como 
funcionam as equipes e as fases do desenvolvimento do projeto. Para finalizar, 
conheceremos a UML, bem como seus diagramas. E complementando os 
estudos, será apresentada uma atividade para consolidar os conhecimentos 
aprendidos na disciplina de Modelagem de Sistemas Gerenciais. 
Aproveito a oportunidade para destacar a importância de desenvolver 
as autoatividades, lembrando que essas atividades NAO SÃO OPCIONAIS. 
Elas objetivam a fixação dos conceitos apresentados. Em caso de dúvida na 
realização das atividades, sugiro que você entre em contato com seu tutor 
externo ou com a tutoria da UNIASSELVI, não prosseguindo as atividades 
sem ter sanado todas as dúvidas que irão surgindo.
Bom estudo! Sucesso na sua trajetória acadêmica e profissional!
Neli Miglioli Sabadin
IV
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para 
você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novidades 
em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o 
material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um formato 
mais prático, que cabe na bolsa e facilita a leitura. 
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagramação 
no texto, aproveitando ao máximo o espaço da página, o que também contribui para diminuir 
a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, 
apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade 
de estudá-lo com versatilidade nas telas do celular, tablet ou computador. 
 
Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para 
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto 
em questão. 
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas 
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa 
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de 
Desempenho de Estudantes – ENADE. 
 
Bons estudos!
UNI
V
VI
VII
SuMário
UNIDADE 1 - INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS:
 MODELO CASCATA E INCREMENTAL E MODELOS
 EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO ........................ 1
TÓPICO 1 - MODELOS DE CICLO DE VIDA .................................................................................. 3
1 INTRODUÇÃO ..................................................................................................................................... 3
2 MODELOS DE PROCESSOS PRESCRITIVOS OU TRADICIONAIS ..................................... 4
 2.1 MODELO EM CASCATA ............................................................................................................... 4
 2.1.1 Modelo Incremental ............................................................................................................... 7
 2.1.2 Modelos de processo evolucionário .................................................................................... 9
 2.1.3 Modelo Espiral ........................................................................................................................ 9
 2.1.4 Prototipação ............................................................................................................................ 10
RESUMO DO TÓPICO 1........................................................................................................................ 12
AUTOATIVIDADE ................................................................................................................................. 13
TÓPICO 2 - INTRODUÇÃO A MODELAGEM ESTRUTURADA E
 MODELAGEM ORIENTADA A OBJETO .................................................................... 15
1 INTRODUÇÃO ..................................................................................................................................... 15
2 IMPORTÂNCIA DA MODELAGEM DE SISTEMAS .................................................................. 18
3 EVOLUÇÃO HISTÓRICA DA MODELAGEM ............................................................................. 20
 3.1 MODELAGEM ESTRUTURADA ................................................................................................. 21
 3.2 PARADIGMA DA ORIENTAÇÃO A OBJETO (OO) ................................................................. 23
RESUMO DO TÓPICO 2........................................................................................................................ 26
AUTOATIVIDADE ................................................................................................................................. 27
TÓPICO 3 - MÉTODO DE DESENVOLVIMENTO ÁGIL .............................................................. 29
1 INTRODUÇÃO ..................................................................................................................................... 29
2 PRECEITOS E PRINCÍPIOS ............................................................................................................... 31
 2.1 FATORES HUMANOS ................................................................................................................... 32
 2.2 METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO DE SOFTWARE ................................ 33
 2.2.1 Extreme Programming (programação extrema) XP .......................................................... 34
 2.2.2 Desenvolvimento de Software Adaptativo (ASD)............................................................. 35
 2.2.3 Scrum ....................................................................................................................................... 36
 2.2.4 Método de Desenvolvimento de Sistemas Dinâmicos (DSDM) ...................................... 39
 2.2.5 Crystal ...................................................................................................................................... 40
 2.2.6 Desenvolvimento Dirigido a Funcionalidades (FDD) ...................................................... 40
 2.2.7 Desenvolvimento de Software Enxuto (LSD) ....................................................................41
 2.2.8 Modelagem Ágil (AM) .......................................................................................................... 41
 2.2.9 Processo Unificado Ágil (AUP) ............................................................................................ 42
 2.2.10 Rational Unified Process (RUP) ......................................................................................... 42
LEITURA COMPLEMENTAR ............................................................................................................... 45
RESUMO DO TÓPICO 3........................................................................................................................ 59
AUTOATIVIDADE ................................................................................................................................. 61
VIII
UNIDADE 2 - ENGENHARIA DE REQUISITOS E EQUIPE DE DESENVOLVIMENTO ...... 63
TÓPICO 1 - ENGENHARIA DE REQUISITOS ................................................................................. 65
1 INTRODUÇÃO ..................................................................................................................................... 65
2 ENGENHARIA DE REQUISITOS .................................................................................................... 65
 2.1 DEFININDO OS REQUISITOS...................................................................................................... 68
 2.1.1 Requisitos Funcionais ............................................................................................................ 68
 2.1.2 Requisitos não funcionais ..................................................................................................... 69
 2.2 CRITÉRIOS PARA VALIDAÇÃO E ACEITAÇÃO DE REQUISITOS ..................................... 71
 2.3 PROBLEMAS ENCONTRADOS REFERENTES A REQUISITOS ............................................ 73
 2.4 ESPECIFICAÇÃO DE REQUISITOS ............................................................................................ 74
 2.4.1 Especificação em Linguagem Natural ................................................................................. 76
 2.4.2 Especificação Estruturada ..................................................................................................... 77
 2.4.3 Documento de requisito de software .................................................................................. 79
 2.4.4 Gerenciamento de requisitos ................................................................................................ 82
LEITURA COMPLEMENTAR ............................................................................................................... 83
RESUMO DO TÓPICO 1........................................................................................................................ 86
AUTOATIVIDADE ................................................................................................................................. 88
TÓPICO 2 - DESCOBERTA DE REQUISITOS .................................................................................. 91
1 INTRODUÇÃO ..................................................................................................................................... 91
2 TÉCNICAS DE LEVANTAMENTO .................................................................................................. 92
 2.1 ENTREVISTA ................................................................................................................................... 93
 2.1.1 Etnografia - Observação pessoal .......................................................................................... 94
 2.1.2 Questionário ............................................................................................................................ 95
 2.1.3 Brainstorming ........................................................................................................................... 96
 2.1.4 JAD (Joint Application Design) ............................................................................................... 97
RESUMO DO TÓPICO 2........................................................................................................................ 99
AUTOATIVIDADE ................................................................................................................................. 100
TÓPICO 3 - DESENVOLVIMENTO E EQUIPE DE SOFTWARE ................................................... 101
1 INTRODUÇÃO ..................................................................................................................................... 101
2 FASES DO DESENVOLVIMENTO DE SISTEMAS ...................................................................... 101
 2.1 ESTUDO DE VIABILIDADE ......................................................................................................... 102
 2.1.1 Análise...................................................................................................................................... 103
 2.1.2 Projeto ...................................................................................................................................... 104
 2.1.3 Implementação ....................................................................................................................... 105
 2.1.4 Implantação ............................................................................................................................. 105
 2.2 GERENCIAMENTO DE PROJETOS ............................................................................................ 105
 2.3 EQUIPE DE DESENVOLVIMENTO ............................................................................................. 107
 2.3.1 Gerente ..................................................................................................................................... 108
 2.3.2 Analistas .................................................................................................................................. 109
 2.3.3 Projetistas ................................................................................................................................. 110
 2.3.4 Arquitetos de software .......................................................................................................... 110
 2.3.5 Programadores ....................................................................................................................... 112
LEITURA COMPLEMENTAR ............................................................................................................... 113
RESUMO DO TÓPICO 3........................................................................................................................ 116
AUTOATIVIDADE ................................................................................................................................. 117
UNIDADE 3 - REVISÃO DE CONCEITOS DA UML, DIAGRAMAS DE VISÃO
 COMPORTAMENTAL E ESTRUTURAL E UM DETALHAMENTO
 NOS CASOS DE USO ................................................................................................... 119
IX
TÓPICO 1 - UML (UNIFIED MODELING LANGUAGE) .............................................................. 121
1 INTRODUÇÃO ..................................................................................................................................... 121
2 MODELO CONCEITUAL DA UML ................................................................................................. 121
 2.1 BLOCOS DE CONSTRUÇÃO BÁSICOS DA UML .................................................................... 122
 2.1.1 Itens estruturais ..................................................................................................................... 122
 2.1.2 Itens comportamentais ..........................................................................................................124
 2.1.3 Itens de agrupamento ............................................................................................................ 125
 2.1.4 Itens anotacionais ................................................................................................................... 125
 2.2 RELACIONAMENTOS NA UML................................................................................................. 125
RESUMO DO TÓPICO 1........................................................................................................................ 127
AUTOATIVIDADE ................................................................................................................................. 128
TÓPICO 2 - DIAGRAMAS DA UML: DIAGRAMAS ESTRUTURAIS
 E COMPORTAMENTAIS ................................................................................................ 129
1 INTRODUÇÃO ..................................................................................................................................... 129
2 DIAGRAMAS ........................................................................................................................................ 129
 2.1 DIAGRAMAS ESTRUTURAIS ...................................................................................................... 131
 2.1.1 Diagrama de Objetos ............................................................................................................. 131
 2.1.2 Diagrama de Estrutura Composta ....................................................................................... 132
 2.1.3 Diagrama de Classes .............................................................................................................. 134
 2.1.4 Diagrama de Pacotes .............................................................................................................. 135
 2.2 DIAGRAMAS COMPORTAMENTAIS ........................................................................................ 136
 2.2.1 Diagramas de atividade ........................................................................................................ 136
 2.2.2 Diagramas de Caso de Uso ................................................................................................... 137
 2.2.3 Diagrama de Transição de Estados...................................................................................... 138
 2.3 DIAGRAMAS DE INTERAÇÃO ................................................................................................... 139
 2.3.1 Diagrama de Sequência ......................................................................................................... 139
 2.3.2 Diagrama de Temporização .................................................................................................. 140
 2.3.3 Diagrama de Comunicação ................................................................................................... 140
 2.3.4 Diagrama de Visão Geral de Interação ............................................................................... 141
 2.4 DIAGRAMAS DE IMPLEMENTAÇÃO ....................................................................................... 142
 2.4.1 Diagrama de Componentes .................................................................................................. 142
 2.4.2 Diagrama de Implantação ..................................................................................................... 143
RESUMO DO TÓPICO 2........................................................................................................................ 145
AUTOATIVIDADE ................................................................................................................................. 147
TÓPICO 3 - MODELO DE CASO DE USO ........................................................................................ 149
1 INTRODUÇÃO ..................................................................................................................................... 149
2 CASO DE USO ...................................................................................................................................... 150
3 ATORES .................................................................................................................................................. 150
4 FLUXO DE EVENTOS ......................................................................................................................... 151
5 RELACIONAMENTO .......................................................................................................................... 152
 5.1 RELACIONAMENTO ENTRE ATORES ...................................................................................... 152
 5.2 ATOR X CASO DE USO ................................................................................................................. 152
 5.3 INCLUSÃO E EXTENSÃO ............................................................................................................ 153
 5.4 EXTENSÃO ...................................................................................................................................... 154
6 GENERALIZAÇÃO .............................................................................................................................. 156
RESUMO DO TÓPICO 3........................................................................................................................ 158
AUTOATIVIDADE ................................................................................................................................. 159
TÓPICO 4 - DIAGRAMA DE CLASSE ............................................................................................... 161
1 INTRODUÇÃO ..................................................................................................................................... 161
X
2 DIAGRAMAS DE CLASSE ................................................................................................................ 161
LEITURA COMPLEMENTAR ............................................................................................................... 165
RESUMO DO TÓPICO 4........................................................................................................................ 174
AUTOATIVIDADE ................................................................................................................................. 175
TÓPICO 5 - DIAGRAMA DE SEQUÊNCIA ...................................................................................... 177
1 INTRODUÇÃO ..................................................................................................................................... 177
2 TIPOS DE MENSAGEM ..................................................................................................................... 177
 2.1 NOTAÇÃO DO DIAGRAMA DE SEQUÊNCIA ........................................................................ 178
LEITURA COMPLEMENTAR ............................................................................................................... 180
RESUMO DO TÓPICO 5........................................................................................................................ 188
AUTOATIVIDADE ................................................................................................................................. 189
REFERÊNCIAS ......................................................................................................................................... 190
1
UNIDADE 1
INTRODUÇÃO AOS MODELOS 
DE PROCESSO TRADICIONAIS: 
MODELO CASCATA E INCREMENTAL 
E MODELOS EVOLUCIONÁRIOS: 
MODELO ESPIRAL E PROTOTIPAÇÃO
OBJETIVOS DE APRENDIZAGEM
PLANO DE ESTUDOS
Esta unidade tem por objetivos:
• introdução aos conceitos de ciclo de vida;
• modelagem orientada e estruturada;
• conhecimento dos modelos ágeis de desenvolvimento.
Esta unidade de ensino contém trêstópicos. No final de cada um deles você 
encontrará atividades que contribuirão para a apropriação dos conteúdos.
TOPICO 1 – MODELOS DE CICLO DE VIDA
TÓPICO 2 – INTRODUÇÃO À MODELAGEM ESTRUTURADA E 
 MODELAGEM ORIENTADA A OBJETO
TÓPICO 3 – METÓDO DE DESENVOLVIMENTO ÁGIL
2
3
TÓPICO 1UNIDADE 1
MODELOS DE CICLO DE VIDA
1 INTRODUÇÃO
A existência de um sistema de informação passa por um processo conhecido 
como Ciclo de Vida, com três estágios bastante conhecidos pelo analista de sistema: 
concepção, desenvolvimento e vida útil. De acordo com Silva (2014, p. 28), o nome 
de cada fase da vida de um sistema pode sofrer variações, mas, na sua essência, 
nada muda. Como vemos na definição:
Existe um encadeamento específico dessas fases, para a construção 
do sistema dá-se o nome de Ciclo de vida. O processo de software é 
o conjunto de atividades que constituem o desenvolvimento de um 
sistema computacional. Estas atividades são agrupadas em fases, como: 
• Definição de requisitos,
• Análise, projeto, 
• Desenvolvimento, 
• Teste e implantação.
Cada fase do desenvolvimento de software é definida. Além das suas 
atividades, as funções e responsabilidades de cada membro da equipe, e, como 
produto resultante, os artefatos. Como tudo que dá certo se repete, no mercado 
de software ocorre o mesmo. Repetiram-se as práticas que ofereceram resultados 
positivos. E a formalização em modelos de ciclo de vida. Em outras palavras, os 
modelos de Ciclo de Vida são o esqueleto ou as estruturas predefinidas, nas quais 
encaixamos as fases do processo. De acordo com Macêdo e Spínola (2016), a NBR 
ISO/IEC 12207:1998, o Ciclo de Vida é a “Estrutura contendo processos, atividades 
e tarefas envolvidas no desenvolvimento, operação e manutenção de um produto 
de software, abrangendo a vida do sistema desde a definição de seus requisitos, até 
o término de seu uso”. 
O modelo de Ciclo de Vida é a primeira escolha a ser feita no processo de 
software, e a partir desta escolha definir-se-á desde a maneira mais adequada para 
obter as necessidades do cliente, até quando e como o cliente receberá sua primeira 
versão operacional do sistema. Vale ressaltar que não existe um modelo ideal. O 
perfil e complexidade do empreendimento do cliente, o tempo disponível, o custo, 
a equipe, o ambiente operacional são fatores que influenciarão diretamente na 
escolha do Ciclo de Vida de software a ser adotado. Da mesma forma, também é 
difícil uma empresa adotar somente um Ciclo de Vida no processo.
Os ciclos de vida se comportam de maneira sequencial (fases seguem 
determinada ordem) e/ou incremental (divisão de escopo) e/ou iterativa 
(retroalimentação de fases) e/ou evolutiva (software é aprimorado).
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
4
Não existe uma regra, a escolha de um modelo de processo depende muito 
das características do projeto. Para escolher o modelo mais adequado é importante 
conhecer alguns modelos de Ciclo de Vida e as situações em que são aplicáveis.
2 MODELOS DE PROCESSOS PRESCRITIVOS OU 
TRADICIONAIS
Originalmente, modelos prescritivos foram propostos para trazer ordem 
ao caos existente na área de desenvolvimento de software. Segundo Pressman 
(2011, p.58), esses modelos proporcionavam uma contribuição quanto à estrutura 
utilizável no trabalho de engenharia de software e forneceram um roteiro 
razoavelmente eficaz para as equipes deste.
2.1 MODELO EM CASCATA
Também chamado de “modelo de ciclo de vida clássico”, o Modelo em 
Cascata organiza as atividades do processo de desenvolvimento de forma 
sequencial, como mostra a Figura 1. Uma característica desse modelo é que cada 
fase resulta na elaboração de um ou mais documentos, que devem ser aprovados 
antes de se iniciar a fase seguinte. Ou seja, uma fase só será iniciada após a conclusão 
daquela que a precede. Uma vez que, na prática, essas fases se sobrepõem de 
alguma forma, geralmente permite-se um retorno à fase anterior para a correção 
de erros encontrados. O resultado final, ou melhor, a entrega do sistema completo 
ocorre de uma única vez, ao final da fase de Entrega e Implantação. No Modelo em 
Cascata, todo o projeto deve ser entendido em suas fases iniciais, seguindo até o 
final com pouquíssima interação com o cliente.
TÓPICO 1 | MODELOS DE CICLO DE VIDA
5
FIGURA 1 - MODELO EM CASCATA
FONTE: Disponível em: <http://www.inf.ufes.br/~monalessa/PaginaMonalessa- NEMO/
ES_Mestrado/Artigos/ProcessoDeSoftware.pdf> Acesso em: 23 fev. 2016 
Os principais estágios do Modelo em Cascata refletem diretamente as 
atividades fundamentais do desenvolvimento, segundo Sommerville (2011, p. 20): 
1. Análise e definição de requisitos: Os serviços, restrições e metas 
do sistema são estabelecidos por meio de consulta aos usuários. Em 
seguida, são definidos em detalhes e funcionam como uma especificação 
do sistema.
2. Projeto de sistema e software: O processo de projeto de sistemas 
aloca os requisitos tanto para sistemas de hardware como para sistemas 
de software, por meio de definição de uma arquitetura geral do sistema. 
O projeto de software envolve a identificação e descrição das abstrações 
fundamentais do sistema de software e seus relacionamentos.
3. Implementação e teste unitário: Durante esse estágio, o projeto do 
software é desenvolvido como um conjunto de programas ou unidades 
de programa. O teste unitário envolve a verificação de que cada unidade 
atende à sua especificação.
4. Integração e teste de sistema: As unidades individuais do programa 
ou programas são integradas e testadas como um sistema completo, 
para assegurar que os requisitos do software tenham sido atendidos. 
Após o teste o sistema de software é entregue ao cliente.
No capítulo 2- Detalharemos os tipos de requisitos e técnicas de levantamento 
de requisitos.
ESTUDOS FU
TUROS
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
6
5. Operação e manutenção: Normalmente (embora não necessariamente), 
essa é a fase mais longa do ciclo de vida. O sistema é instalado e 
colocado em uso. A manutenção envolve a correção de erros que não 
foram descobertos em estágios iniciais do ciclo de vida, com melhora da 
implementação das unidades do sistema e ampliação de seus serviços 
em resposta às descobertas de novos requisitos.
Existe uma variação do Modelo em Cascata que é chamado de modelo V. 
Nesse modelo, procura-se enfatizar a estreita relação entre as atividades de teste 
(teste de unidade, teste de integração, teste de sistema e teste de aceitação) e as 
demais fases do processo. 
Pressman (2011) explica que à medida que a equipe de software desce em 
direção ao lado esquerdo do V, os requisitos básicos do problema são refinados em 
representações progressivamente cada vez mais detalhadas e técnicas do problema 
e de sua solução. Como mostra a Figura 2.
FIGURA 2 - MODELO V
FONTE: Adaptado de Pressman (2011, p. 60)
TÓPICO 1 | MODELOS DE CICLO DE VIDA
7
O Modelo em Cascata é o modelo mais antigo na engenharia de software, e 
nos últimos anos recebeu várias críticas, conforme relatadas por Pressman (2011, 
p. 61):
• Projetos reais raramente seguem o fluxo sequencial que o modelo 
propõe. Embora o modelo linear possa conter interações, ele o faz 
indiretamente. Como consequência, mudanças podem provocar 
confusão à medida que a equipe de projeto prossegue.
• Frequentemente, é difícil para o cliente estabelecer explicitamente 
todas as necessidades. O modelo em cascata requer isso e tem dificuldade 
para adequar a incerteza natural que existe no início de muitos projetos.
• O cliente deve ter paciência. Uma versão operacional do(s) programa(s) 
não estará disponível antes de estarmos próximo do final do projeto. 
Um erro grave, se não detectado até o programa operacional ser revisto, 
pode ser desastroso.
2.1.1 Modelo IncrementalNem todos os projetos que conseguem ter todos os requisitos são 
razoavelmente bem definidos, e devido ao tamanho do sistema a ser desenvolvido, 
isso torna impossível a adoção de um modelo sequencial, especialmente pela 
necessidade de disponibilizar uma versão para o usuário rapidamente. Para esses 
casos o Modelo Incremental é o mais indicado, como detalharemos.
Pressman (2011) diz que o Modelo Incremental combina elementos dos 
fluxos de processos lineares e paralelos. A Figura 3 ilustra esses modelos.
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
8
FIGURA 3 - MODELO INCREMENTAL
FONTE: Pressman (2011, p. 54)
O princípio fundamental desse modelo é que, seja iteração ou ciclo, uma 
versão operacional do sistema é gerada e entregue para avaliação e uso detalhado 
do cliente.
 
Para que isso aconteça, os requisitos têm que ser levantados detalhadamente 
e há de se constatar que o sistema é modular, de modo que se possa planejar o 
desenvolvimento em incrementos. O primeiro incremento, tipicamente, contém 
funcionalidades centrais, tratando dos requisitos básicos. A cada ciclo, novas 
funcionalidades são adicionadas e as funcionalidades providas anteriormente 
podem ser modificadas para melhor satisfazer às necessidades dos clientes/
usuários. Outras características são tratadas em ciclos subsequentes. Dependendo 
do tempo estabelecido para a liberação dos incrementos, algumas atividades 
podem ser feitas para o sistema como um todo ou não. 
TÓPICO 1 | MODELOS DE CICLO DE VIDA
9
2.1.2 Modelos de processo evolucionário
Pressman (2011) afirma que o software, assim como todos os sistemas 
complexos, evolui ao longo do tempo e, conforme o desenvolvimento deste software 
avança, temos mudanças nas necessidades de negócio e de produtos, uma vez 
que mudam frequentemente. Isso torna inadequado seguirmos um planejamento 
em linha reta de determinado produto. Muitas vezes, os prazos reduzidos, a 
necessidade de atender à pressão comercial e até mesmo da concorrência e em 
outras situações como essas ou similares, faz-se necessário um modelo de processo 
que tenha sido projetado especificamente para desenvolver um produto que 
evolua ao longo do tempo. Modelos Evolucionários são caracterizados por serem 
iterativos e apresentarem características que possibilitem desenvolvermos versões 
cada vez mais completas do software. Os Processos Evolucionários se caracterizam 
por dois modelos comuns: Prototipação e Espiral.
2.1.3 Modelo Espiral
O Modelo Espiral foi originalmente proposto por Boehm em 1988. Para 
definir esse modelo de uma maneira mais simples, basta analisa-lo como um 
Modelo em Cascata, onde cada fase é precedida por uma análise de risco e sua 
execução é feita evolucionariamente (ou incrementalmente). Neste modelo de 
desenvolvimento é possível avaliar riscos de projeto, tomando-se decisões baseadas 
na experimentação de diferentes soluções. Para entendermos melhor, veja a Figura 
4.
A dimensão radial representa o custo acumulado atualizado e a dimensão 
angular representa o progresso através da espiral. Cada setor da espiral corresponde 
a uma tarefa (fase) do desenvolvimento. No modelo original foram propostas 
quatro tarefas (fases ou quadrantes) onde, por exemplo, na primeira volta pode 
gerar como resultado a especificação do produto, na espiral subsequente o 
resultado pode ser o protótipo, e nas voltas seguintes podem ser relativos a versões 
aprimoradas do sistema (PRESSMAN, 2008, p.38).
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
10
FIGURA 4 - MODELO ESPIRAL
FONTE: Pressman (2011, p. 65)
2.1.4 Prototipação
Em relação a esse paradigma, Pressman (2011) afirma que, embora possa 
ser utilizada como um modelo de processo isolado (stand-alone-process), é mais 
comumente utilizada como uma técnica passível de ser implementada no contexto 
de qualquer um dos modelos apresentados. Ele explica o funcionamento deste 
paradigma de maneira reduzida. 
Na fase de comunicação, faz-se uma reunião com os envolvidos para 
definir os objetivos gerais do software, identificar quais requisitos já são conhecidos 
e esquematizar quais áreas necessitam, obrigatoriamente, de uma definição 
mais ampla. Uma interação de prototipação é planejada rapidamente e ocorre a 
modelagem (na forma de um “projeto rápido”). 
Durante a fase de modelagem do projeto rápido: se concentra em uma 
representação daqueles aspectos do software que serão visíveis aos usuários finais, 
como, por exemplo, o layout da interface com o usuário ou formatos de exibição na 
tela. E, finalmente, a construção de um protótipo: Nesta fase é feita a construção do 
protótipo, que é empregado e avaliado, conforme vemos na Figura 5.
TÓPICO 1 | MODELOS DE CICLO DE VIDA
11
FIGURA 5 - PROTOTIPAÇÃO
FONTE: Pressman (2011, p. 63)
Sommerville (2011, p. 31) alerta que, às vezes, os desenvolvedores são 
pressionados pelos gerentes para entregar protótipos descartáveis, especialmente 
quando há atrasos na entrega da versão final do software. No entanto, isso costuma 
ser desaconselhável:
1. Pode ser impossível ajustar o protótipo para atender aos requisitos 
não funcionais, como requisitos de desempenho, proteção, robustez e 
confiabilidade, que foram ignorados durante o desenvolvimento do 
protótipo.
2. Mudanças rápidas durante o desenvolvimento inevitavelmente 
significam que o protótipo não está documentado. A única especificação 
do projeto é o código do protótipo. Para a manutenção a longo prazo, 
isso não é bom o suficiente.
3. As mudanças durante o desenvolvimento do protótipo provavelmente 
terão degradado a estrutura do sistema. O sistema será difícil e custoso 
de ser mantido.
4. Padrões de qualidade organizacional geralmente são relaxados para 
o desenvolvimento do protótipo.
12
Neste tópico, vimos:
• Um breve contato com conceitos e modelos relacionados ao processo de 
desenvolvimento de software. 
• Modelos de processos prescritivos ou tradicionais: Modelo em Cascata e Modelo 
Incremental e um resumo das fases.
• Modelos de processo evolucionário: Modelo espiral e Prototipação. 
RESUMO DO TÓPICO 1
13
1 Qual deve ser a primeira escolha a ser feita no processo de software?
2 Projetos reais raramente seguem o fluxo sequencial que o modelo propõe. 
Embora o modelo linear possa conter interações, ele o faz indiretamente. 
Como consequência, mudanças podem provocar confusão à medida que a 
equipe de projeto prossegue. Essa é uma crítica que vem sendo apresentada 
referente a qual modelo de desenvolvimento?
3 Quando se começa um projeto, nem todos conseguem ter todos os requisitos 
razoavelmente bem definidos, e devido ao tamanho do sistema a ser 
desenvolvido, isso torna impossível a adoção de qual modelo? E qual modelo 
pode ser sugerido?
4 Preencha de acordo com a definição das fases de desenvolvimento:
AUTOATIVIDADE
Normalmente (embora não necessariamente), essa é a fase mais 
longa do Ciclo de Vida. O sistema é instalado e colocado em 
uso. A manutenção envolve a correção de erros que não foram 
descobertos em estágios iniciais do Ciclo de Vida, com melhora 
da implementação das unidades do sistema e ampliação de seus 
serviços em resposta às descobertas de novos requisitos.
O processo de projeto de sistemas aloca os requisitos tanto para 
sistemas de hardware como para sistemas de software, por meio 
de definição de uma arquitetura geral do sistema. O projeto 
de software envolve a identificação e descrição das abstrações 
fundamentais do sistema de software e seus relacionamentos.
Os serviços, restrições e metas do sistema são estabelecidos por 
meio de consulta aos usuários. Em seguida, são definidos em 
detalhes e funcionam como uma especificação do sistema.
As unidades individuais do programa ou programas são 
integradas e testadas como um sistema completo, para assegurar 
que os requisitosdo software tenham sido atendidos. Após o 
teste, o sistema de software é entregue ao cliente.
Durante esse estágio, o projeto do software é desenvolvido como 
um conjunto de programas ou unidades de programa. O teste 
unitário envolve a verificação de que cada unidade atende à sua 
especificação.
14
5 Qual é o modelo ideal que se aplica à maioria dos projetos de software?
6 A definição de que, embora possa ser utilizada como um modelo de processo 
isolado (stand-alone-process), é mais comumente utilizada como uma técnica 
passível de ser implementada no contexto de qualquer um dos modelos 
apresentados, se refere a qual modelo de desenvolvimento?
15
TÓPICO 2
INTRODUÇÃO A MODELAGEM ESTRUTURADA E 
MODELAGEM ORIENTADA A OBJETO
UNIDADE 1
1 INTRODUÇÃO
Se pedissem para você desenhar ou procurar na internet um item bem 
específico: Uma cadeira com bolinhas amarela e confortável. A princípio não 
parece ser um pedido muito difícil, certo?
Mas, qual das cadeiras era a solicitada?
FIGURA 6 - CADEIRA DE BOLINHA
FONTE: Disponível em: <http://arquitetura-tamiris.blogspot.
com/2011/03/cadeira-de-bolinha-amarelinhaa.html>. Acesso em: 22 
mar. 2016.
16
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
FIGURA 7- CADEIRA DE BOLINHA
FONTE: Disponível em: <http://revistacasaejardim.globo.com/Revista/
Common/0,,ERT75860-16940,00.html>. Acesso em: 22 mar. 2016. 
Isso foi apenas uma maneira de ilustrar a dificuldade de atender aos 
requisitos. Mas se foi tão difícil para um item tão simples como uma cadeira, 
imagine para o sistema de uma empresa.
Para ajudar nessa tarefa, têm-se os modelos, que são uma visualização dos 
requisitos, bem como o desejo do cliente do que deve ser implementado. Juntos, 
eles auxiliam no entendimento do que o cliente solicitou e do que a equipe deve 
desenvolver.
O ponto mais importante do desenvolvimento de um sistema é compreender 
as necessidades e desejos do usuário e da organização e visualizar os benefícios que 
serão obtidos com esse sistema, mas se isso não for bem entendido, os requisitos 
e as atividades relacionadas ao seu desenvolvimento não terão significado algum.
O termo modelagem já sugere a criação de um modelo, a elaboração 
de um esboço do que se pretende fazer, por meio de um gráfico, um desenho, 
antes de começar a construção propriamente dita. Essa atividade abrange vários 
segmentos, pode ser uma casa, um carro, um vestido ou até mesmo um software. 
Abaixo há alguns esboços de coisas bem diferentes, mas que seguem a mesma 
linha de raciocínio. 
17
TÓPICO 2 | INTRODUÇÃO A MODELAGEM ESTRUTURADA
E MODELAGEM ORIENTADA A OBJETO
 FIGURA 8- MODELO CASA
 FONTE: Disponível em: < http://www.tudoconstrucao.com/10-modelos-
de-plantas-de-casas-para-2015/>. Acesso em: 22 mar. 2016.
FIGURA 9- MODELO CARRO
FONTE: Disponível em: < http://pt.dreamstime.com/fotos-de-stock-
royalty-free-desenho-do-carro-image7844748>. Acesso em: 22 mar. 2016.
FIGURA 10- MODELO VESTIDO
FONTE: Disponível em: <http://vida-estilo.estadao.com.br/
noticias/moda,veja-quais-sao-os-vestidos-de-casamento-mais-
iconicos-de-todos-os-tempos,1786989>. Acesso em: 22 mar. 
2016.
18
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
É durante a fase de modelagem que o autor do projeto, independentemente 
do tipo, prepara um “modelo” com todos os requisitos, funcionalidade ou 
características, que o seu cliente ou usuário solicitou. Nesse modelo apresentam-se 
a estrutura e o comportamento do sistema que será desenvolvido, enxergando seu 
funcionamento. Durante essa fase é possível verificar com o usuário se o modelo 
proposto atende às suas necessidades, conforme os requisitos informados.
A criação de modelos é de suma importância para o entendimento do 
projeto como um todo.
2 IMPORTÂNCIA DA MODELAGEM DE SISTEMAS
Pode-se construir uma casa para um cachorro apenas juntando algumas 
tábuas, alguns pregos e algumas ferramentas básicas. Com um planejamento 
mínimo, em poucas horas e com um pouco de habilidade, nosso cachorro terá 
uma casa (BOOCH et al., 2000).
FIGURA 11 - CASA DE CACHORRO
FONTE: Disponível em: <http://bioretro.eco.br/lar-cao-tambem-sustentavel/>. Acesso em: 23 fev. 
2016.
Ainda segundo o autor, se o plano for construir a casa para sua família, com 
certeza uma pequena pilha de tábuas e alguns pregos não será o suficiente, pois, 
com certeza, sua família será um pouco mais exigente que o seu cachorro. Para fazer 
a sua casa, antes de sair batendo o primeiro prego é necessário que você saiba o que 
19
TÓPICO 2 | INTRODUÇÃO A MODELAGEM ESTRUTURADA
E MODELAGEM ORIENTADA A OBJETO
sua família espera, será melhor fazer um planejamento bem detalhado de como 
será essa construção. Fazer alguns desenhos e verificar todos os procedimentos 
para garantir a segurança da edificação. Durante esse detalhamento, você verá 
que é muito difícil construir uma casa sozinho, e que terá que ter uma equipe para 
auxiliar, com cada membro da equipe sabendo o que deve desempenhar. Se tudo 
correr bem e o modelo for seguido, provavelmente, ao final do projeto, sua família 
ficará satisfeita. Vale ressaltar que, para não gerar frustrações ao final do projeto, é 
muito importante definir as expectativas desde o início. 
FIGURA 12 - CASA SEM PROJETO
FONTE: Disponível em: <http://atl.clicrbs.com.br/mundoidao/2008/08/26/
casa-e-construida-de-cabeca-para-baixo/> Acesso em: 23 fev. 2016.
Agora, se você não quer construir software equivalente a uma casa, Booch 
et al. (2000) advertem que o segredo estará em criar o código correto e pensar em 
como será possível elaborar menos software. Isso faz com que o desenvolvimento 
de programa de qualidade se torne uma questão de arquitetura, processo e 
ferramentas. Para uma empresa de software ter sucesso, existem vários elementos 
que contribuem para isso, um deles é a utilização da modelagem.
Ainda segundo Booch et al. (2000, p.6) constroem-se modelos para 
compreender melhor o sistema que estamos desenvolvendo. E com ela é possível 
alcançar quatro objetivos:
• Os modelos ajudam a visualizar o sistema como ele é ou como 
desejamos que seja.
• Os modelos permitem especificar a estrutura ou o comportamento de 
um sistema.
• Os modelos proporcionam um guia para a construção do sistema.
• Os modelos documentam as decisões tomadas.
Vale ressaltar que a modelagem não se restringe apenas a grandes sistemas. 
Ainda de acordo com Booch et al. (2000), softwares pequenos, equivalentes a uma 
casa de cachorro, poderão receber os benefícios da modelagem, porém é verdade que 
quanto maior e mais complexo o sistema, maior será a importância da modelagem, 
por um motivo bem simples, que não é possível compreendê-los em sua totalidade.
20
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
3 EVOLUÇÃO HISTÓRICA DA MODELAGEM
Bezerra (2015) apresenta um breve resumo histórico da evolução das 
técnicas de desenvolvimento, para explicar como chegamos ao cenário atual.
Décadas de 1950/1960: Os sistemas eram bem simples, e o seu desenvolvimento 
era direto ao assunto, não tinha um planejamento inicial, como dizem, “ad 
hoc”. Como os sistemas eram significativamente mais simples, as técnicas de 
modelagem também: Eram usados fluxogramas e diagramas de módulos.
Década de 1970: Começaram a surgir computadores mais avançados e 
acessíveis. Houve grande ampliação do mercado computacional. Sistemas mais 
complexos começavam a surgir. Consequentemente, modelos mais robustos 
foram propostos. Os autores Larry Constantine e Edward Yourdon são grandes 
colaboradores nessas técnicas.
Década de 1980: Nessa fase os computadores se tornaram ainda mais avançados e 
mais baratos. Surge a necessidade por interfaces mais sofisticadas, o que originoua produção de sistemas de softwares mais complexos. A Análise Estruturada 
surgiu no início desse período, com os trabalhos de Edward Yourdon, Peter 
Coad, Tom De Marco, James Martin e Chris Gane.
Década de 1990: No início dessa década é o período em que surge um novo 
paradigma de modelagem, a Análise Orientada a Objetos, como resposta a 
dificuldades encontradas na aplicação da análise estruturada em algumas 
aplicações. Grandes colaboradores desse paradigma são Sally Shlaer, Stephen 
Mellor, Rebecca Wirfs-Brock, James Rumbaugh, Grady Booch e Ivar Jacobson. 
Já no fim da década, o paradigma da orientação a objetos atinge sua 
maturidade. Os conceitos de padrões de projeto, frameworks, componentes 
e qualidade começam a ganhar espaço. Surge a Linguagem de Modelagem 
Unificada UML.
Década de 2000: O reúso por meio de padrões de projetos e frameworks se 
solidifica. As denominadas metodologias ágeis começam a ganhar espaço. 
Técnicas de testes automatizados e refatoração começaram a se difundir entre os 
desenvolvedores que trabalham com orientação a objeto. Grandes nomes dessa 
fase são: Rebecca Wirfs-Brock, Martin Fowler e Eric Vans.
Como percebemos, durante a década de 90 surgiram várias propostas 
e técnicas para modelagem de sistema segundo o paradigma da orientação a 
objeto. Era comum, durante essa década, duas técnicas possuírem diferentes 
notações gráficas para modelar a mesma perspectiva de um sistema. Todas 
tinham pontos fortes e fracos em relação à notação utilizada, mas via-se a 
necessidade de uma notação que viesse a se tornar um padrão para a modelagem 
de sistemas orientados a objeto, e que fosse amplamente aceita, nas indústrias e 
na academia. 
21
TÓPICO 2 | INTRODUÇÃO A MODELAGEM ESTRUTURADA
E MODELAGEM ORIENTADA A OBJETO
FONTE: Disponível em: <https://www.passeidireto.com/arquivo/19056116/principios-de-analise-
e-projeto---eduardo-bezerra/7>. Acesso em: 11 abr. 2016.
Alguns esforços surgiram em 1996 para essa padronização, o que resultou 
na definição da UML (Unified Modeling Language), que detalharemos a seguir 
em um tópico específico, mas antes falaremos na Modelagem Estruturada e da 
Modelagem Orientada a Objetos.
3.1 MODELAGEM ESTRUTURADA
A modelagem estruturada teve seu início na década de 1970, com uma 
abordagem bem sistemática, utilizando técnicas de construção de modelos. O 
seu princípio é a divisão em módulos e submódulos. Ele é de fácil utilização, 
especialmente por ser diagrama de fácil compreensão e minimização, a lacuna 
de conhecimento, muitas vezes, existente entre os analistas e os usuários. A sua 
documentação é feita através dos diagramas de fluxo de dados (DFD), Diagrama 
de entidade-relacionamento (DER).
O Diagrama de fluxo de dados tem como objetivo representar graficamente o 
fluxo dos dados, normalmente usados para apresentar uma visão geral do sistema, 
onde podemos verificar a entrada e saída das informações e onde os dados serão 
armazenados.
Entidades Externas: São categorias lógicas de objetos ou pessoas que representam 
Origem ou destino de dados, e que acionam um sistema e/ou recebem informações. 
Podem ser pessoas, sistemas ou unidades departamentais, segundo Rezende (2005, 
p.170).
Fluxo de dados: Representa um processo de transformação de dados, é o meio por 
onde os dados e as informações trafegam, eles sempre envolvem um processo, sua 
representação é um retângulo com cantos arredondados;
Processos: Transformam fluxos de dados em uma atividade, ou seja, são as 
atividades que transformam as entradas, transportam dados de processo a 
processo, armazena os dados, e produz as saídas de um sistema.
Depósito de dados: São locais de armazenamento de dados, são arquivos físicos.
22
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
FIGURA 13- SUBSISTEMAS DE FATURAMENTO
FONTE: Rezende (1997, p. 109)
Diagrama entidade-relacionamento (DER): O principal propósito do DER 
é representar os objetos de dados e suas relações, sendo que cada entidade termina 
representada pelo menos por uma tabela de dados, e normalmente expressa por 
um depósito de dados do DFD.
Os objetos de dados são representados por retângulos rotulados e os 
relacionamentos são indicados por losangos, e as conexões entre os dados e os 
relacionamentos são estabelecidos usando-se uma série de linhas e ligações 
especiais.
23
TÓPICO 2 | INTRODUÇÃO A MODELAGEM ESTRUTURADA
E MODELAGEM ORIENTADA A OBJETO
FIGURA 14- ELEMENTOS E SÍMBOLOS DER
FIGURA 15- EXEMPLO DE DIAGRAMA DER
FONTE: Disponível em: < http://www.devmedia.com.br/artigo-sql-magazine-61-modelagem-
de-dados-para-um-sistema-de-controle-de-orcamento/11726>. Acesso em: 23 fev. 2016.
3.2 PARADIGMA DA ORIENTAÇÃO A OBJETO (OO)
Uma forma mais eficiente de pensar em modelagem e desenvolvimento de 
projetos é a Proposta Orientada a Objetos, que organiza os problemas em torno de 
situações reais, como elas realmente acontecem na prática, e isso impõe uma forma 
completamente diferente de pensar e organizar a solução, se comparado à forma 
como o pensamento estruturado apresenta esta. (BOOCH, 1994).
Inicialmente é importante definir a palavra paradigma. Pode-se dizer, 
então, que o termo “paradigma da orientação a objetos” é uma forma de abordar 
um problema. Segundo Bezerra (2015, p. 5):
24
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
Há alguns anos, Alan Kay, um dos pais do paradigma a orientação a 
objetos, formulou a chamada “analogia biológica”. Por meio dela, ele 
imaginou um sistema de software que funcionasse como um ser vivo. 
Nesse sistema, cada “célula” interagiria com outras células através do 
envio de mensagens com o propósito de realizar um objetivo comum. 
Além disso, cada célula se comportaria como uma unidade autônoma.
Ele pensou em construir um sistema de software a partir de agentes 
autônomos que interagem entre si. E estabeleceu os seguintes princípios da 
orientação a objetos Kay apud Bezerra (2005, p 6).
1. Qualquer coisa é um objeto.
2. Objetos realizam tarefas por meio da requisição de serviços a outros 
objetos.
3. Cada objeto pertence a uma determinada classe. Uma classe agrupa 
objetos similares.
4. A classe é um repositório para comportamento associado ao objeto.
5. Classes são organizadas em hierarquia.
Pode-se concluir que a Orientação a Objeto como técnica para modelagem 
de sistemas diminui a diferença semântica entre a realidade que está sendo 
modelada e os modelos construídos.
A visão contemporânea no desenvolvimento de software, segundo Booch et 
al. (2000), adota uma perspectiva orientada a objeto. Nessa visão, o principal bloco 
de construção de todos os sistemas de software é o objeto ou classe. Objeto é alguma 
coisa geralmente estruturada a partir do vocabulário do espaço ou problema ou do 
espaço da solução. E uma Classe é a descrição de um conjunto de objetos comuns. 
Todos os objetos têm uma identidade. É possível atribuir nomes ou diferenciá-los 
de alguma maneira. Um estado (costuma haver dados a eles relacionados) e um 
comportamento, que indica que você pode fazer algo com o objeto ou ele poderá 
fazer algo com outros objetos.
Entre as ideias fundamentais básicas para a tecnologia orientada a objeto 
temos: 
• Objetos.
• Classes.
• Métodos.
• Herança.
• Encapsulamento.
Objetos: Cada conceito é uma ideia ou um entendimento coletivo que 
temos do nosso mundo. Os conceitos que adquirimos nos permitem dar sentido 
sobre as coisas do nosso mundo. Essas coisas às quais nossos conceitos se aplicam 
são denominados objetos. Um objeto pode ser real ou abstrato.
• Os objetos possuem informações (contêm dados) e desempenham ações 
(possuem funcionalidade).
25
TÓPICO 2 | INTRODUÇÃO A MODELAGEM ESTRUTURADA
E MODELAGEM ORIENTADA A OBJETO
• Qualquer coisa à qual um conceito ou tipo de objeto se aplica – uma instância 
de um conceito ou tipo de objeto.• Um objeto é uma instância de uma classe.
Classe: O termo classe refere-se à implementação de software de um tipo 
de objeto. Um tipo de objeto especifica uma família de objetos sem estipular 
como o tipo e o objeto são implementados. Os tipos de objetos são especificados 
durante a análise OO. Os tipos de objetos são implementados como módulos, 
enquanto na linguagem orientada a objeto os tipos de objetos são classificados 
como classes.
• Uma classe é uma implementação de um tipo de objeto.
• Uma classe especifica uma estrutura de dados e os métodos operacionais 
permissíveis que se aplicam a cada um de seus objetos.
• Uma classe pode ter sua própria estrutura de dados e métodos, bem como 
herdá-la de sua superclasse.
Métodos: 
• Os métodos especificam a maneira pela qual os dados de um objeto são 
manipulados.
• Uma especificação dos passos pelos quais uma operação deve ser executada.
• Ele é um script de implementação de uma operação.
• Diferentes métodos podem ser usados para executar a mesma operação.
• Os métodos de um tipo de objeto referenciam somente as estruturas de dados 
desse tipo de objeto.
• A ação que um objeto ou uma classe podem desempenhar.
• Os métodos são similares às funções e procedures do universo da programação 
estruturada.
Encapsulamento: O ato de empacotar ao mesmo tempo dados e objetos 
é denominado encapsulamento. O objeto esconde seus dados de outros objetos e 
permite que os dados sejam acessados por intermédio de seus próprios métodos. 
Isso é chamado de ocultação de informações (information hiding). 
• O encapsulamento protege os dados do objeto do uso arbitrário e não 
intencional.
• O encapsulamento é o resultado (ou ato) de ocultar do usuário os detalhes da 
implementação de um objeto.
• O encapsulamento é importante porque separa a maneira como um objeto se 
comporta da maneira como ele é implementado.
FONTE: Disponível em: <http://www.macoratti.net/net_oocb.htm>. Acesso em: 11 abr. 2016.
26
RESUMO DO TÓPICO 2
Neste tópico, vimos que:
• A modelagem facilita a comunicação entre as partes envolvidas.
• A importância da modelagem de sistemas, como parte imprescindível no 
desenvolvimento dos projetos.
• A evolução histórica da modelagem, o que deu certo e o que mudou.
• As técnicas de Modelagem estruturada e o Paradigma da Orientação a Objeto 
(OO). 
27
1 “Cada conceito é uma ideia ou um entendimento coletivo que temos do 
nosso mundo. Os conceitos que adquirimos nos permitem dar sentido sobre 
as coisas do nosso mundo. Essas coisas às quais nossos conceitos se aplicam 
são denominadas objetos.” Essa definição é verdadeira ou falsa?
2 Para que serve a modelagem?
3 Quais definições apresentadas não estão corretas?
• Encapsulamento – É o agrupamento de ideias afins em uma unidade. Permite 
ao programador apresentar os detalhes da representação dos dados por trás 
de um conjunto de operações (como a interface). Reflita sobre o seguinte: 
você sabe como funciona internamente o seu micro-ondas? Mas você sabe 
como ligá-lo, programá-lo e desligá-lo. Você interage com o micro-ondas por 
meio de sua interface sem se preocupar com os detalhes da implementação: 
esse é um exemplo de encapsulamento.
• Ocultação de informações e implementações – é exatamente o uso do 
encapsulamento que restringe a visibilidade de detalhes e informações que 
ficam internas à estrutura do encapsulamento.
• Mensagens – solicitação de um objeto para que outro objeto efetue uma de suas 
operações. Os objetos não podem mandar mensagens entre si. As mensagens 
resultam na chamada de métodos que executam as ações necessárias.
• Classes – as classes são conjuntos de objetos com características semelhantes.
• Herança – o mecanismo de herança permite que uma classe seja criada a 
partir de outra classe (superclasse), e a nova classe (subclasse) herda todas as 
suas características. 
• Poliformismo – é a propriedade segundo a qual uma operação pode se 
comportar de modos diversos em classes diferentes. Sistemas orientados 
a objetos são flexíveis a mudanças, possuem estruturas bem conhecidas e 
oferecem a oportunidade de criar e implementar componentes totalmente 
reutilizáveis.
4 Quais são os objetivos atingidos utilizando modelos?
5 Quando e por que a Análise Orientada a Objetos surgiu?
6 Defina os objetivos da análise estruturada e como ela é documentada.
AUTOATIVIDADE
28
29
TÓPICO 3
MÉTODO DE DESENVOLVIMENTO ÁGIL
UNIDADE 1
1 INTRODUÇÃO
Em 2001, Kent Beck e outros 16 renomados desenvolvedores, autores e 
consultores da área de software, batizados de “Aliança dos ágeis (Agile Alliance)”, 
assinaram o Manifesto para o Desenvolvimento Ágil de Software (Agile Software 
Development Manifesto), que se inicia da seguinte maneira, segundo Pressman 
(2011, p. 81):
Desenvolvendo e ajudando outros a desenvolver software, estamos 
desvendando formas melhores de desenvolvimento. Por meio deste 
trabalho passamos a valorizar:
Indivíduos e interações acima de processos e ferramentas.
Software operacional acima de documentação completa.
Colaboração dos clientes acima de negociação comercial.
Respostas a mudanças acima de seguir um plano.
Ou seja, embora haja valor nos itens à direita, valorizaremos os da 
esquerda mais ainda.
Ainda segundo o autor, normalmente, um manifesto é associado a um 
movimento político emergente: atacando a velha guarda e sugerindo uma 
mudança revolucionária (normalmente, espera-se que para a melhor). E, de certa 
forma, é exatamente disso que o desenvolvimento ágil trata. Vale frisar que apesar 
de parecer benéfica, essa metodologia não é indicada para todos os projetos, 
produtos, pessoas e situações.
Afinal, no contexto de engenharia de software, o que é agilidade? Jacobson 
apud Pressman (2011, p. 82) responde essa pergunta:
Atualmente agilidade tornou-se a palavra da moda quando se descreve 
um moderno processo de software. Todo mundo é ágil. Uma equipe ágil 
é aquela capaz de responder apropriadamente a mudanças. Mudanças 
têm muito a ver com desenvolvimento de software. Mudanças no 
software que está sendo criado, mudanças nos membros da equipe, 
mudanças devido a novas tecnologias, mudanças de todos os tipos 
Para maiores informações, acesse: http://agilemanifesto.org/
DICAS
30
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
que poderão ter um impacto no produto que está em construção ou 
no projeto do produto. Suporte para mudanças deve ser incorporado 
em tudo o que fazemos em software, algo desenvolvido por indivíduos 
trabalhando em equipes e que as habilidades dessas pessoas, suas 
capacidades em colaborar estão no cerne do sucesso do projeto.
O Método Ágil de desenvolvimento incentiva a estruturação e as atitudes 
em equipe que tornam a comunicação mais fácil entre todos os envolvidos no 
projeto, e também enfatiza a entrega rápida do software operacional e diminui a 
importância dos artefatos intermediários. 
Importante salientar que os custos para as alterações em software aumentam 
de forma não linear conforme o projeto avança, e quando mais tarde for feita a 
alteração, mais alto será o custo. É fácil imaginar que se uma alteração for feita 
durante a fase de requisitos, no início do projeto, estes custos serão mínimos, e o 
tempo não afetará negativamente o resultado do projeto, como podemos observar 
na Figura 16.
FIGURA 16 - CUSTO DE ALTERAÇÃO
Fonte: Pressman (2011, p. 83)
31
TÓPICO 3 | MÉTODO DE DESENVOLVIMENTO ÁGIL
2 PRECEITOS E PRINCÍPIOS
Pressman (2011, p.84) ressalta que qualquer processo ágil de software é 
caracterizado de uma forma que se relacione a uma série de preceitos-chave acerca 
da maioria dos projetos de software.
1. É difícil afirmar antecipadamente quais requisitos de software irão 
persistir e quais sofrerão alterações. É igualmente difícil prever de 
que maneira as prioridades do cliente sofrerão alterações conforme o 
projeto avança.
2. Para muitos tipos de software,o projeto e a construção são 
“interconduzidos”, ou seja, ambas as atividades devem ser realizadas 
uma atrás da outra, para que modelos de projeto sejam provados 
conforme sejam criados. É difícil prever quanto de trabalho de projeto 
será necessário antes que seu desenvolvimento seja implementado para 
avaliar o projeto.
3. Análise, projeto, desenvolvimento e testes não são tão previsíveis 
quanto gostaríamos que fossem segundo o ponto de vista do 
planejamento.
Em análise a esses pontos, surge a dúvida de como é possível administrar a 
imprevisibilidade. A resposta, conforme observado, consiste na adaptabilidade de 
processos, ou seja, um processo ágil deve ser adaptável.
Para se conseguir essa agilidade, segundo Pressman (2011, p.84), o grupo 
“Aliança dos ágeis” estabeleceu 12 princípios:
1. A maior prioridade é satisfazer o cliente por meio da entrega 
adiantada e contínua de software valioso.
2. Acolha bem os pedidos de alterações, mesmo atrasados no 
desenvolvimento. Os processos ágeis se aproveitam das mudanças 
como uma vantagem competitiva na relação com o cliente.
3. Entregue o software em funcionamento frequentemente, de algumas 
semanas para alguns meses, dando preferência a intervalos mais curtos.
4. O pessoal do comercial e os desenvolvedores devem trabalhar em 
conjunto diariamente ao longo de todo o projeto.
5. Construa projetos em torno de indivíduos motivados. Dê a eles o 
ambiente e apoio necessários e confie neles para ter o trabalho feito.
6. O método mais eficiente e efetivo de transmitir informações para e 
dentro de uma equipe de desenvolvimento é uma conversa aberta, de 
forma presencial.
7. Software em funcionamento é a principal medida de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os 
proponentes, desenvolvedores e usuários devem estar capacitados para 
manter um ritmo constante indefinidamente.
9. Atenção contínua para com a excelência técnica e para com bons 
projetos aumenta a agilidade.
10. Simplicidade, a arte de maximizar o volume de trabalho não 
efetuado, é essencial.
11. As melhores arquiteturas, requisitos e projetos emergem de equipes 
que se auto-organizam.
12. A intervalos regulares, a equipe se avalia para ver como tornar-se 
mais eficiente, então sintoniza e ajusta seu comportamento de acordo.
32
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
O autor ressalta que nem todo modelo de processo ágil aplica esses 12 
princípios de maneira igual, adequando-se e priorizando um ou outro princípio. 
Entretanto, os princípios definem um espírito ágil mantido em cada um dos 
modelos de processo.
2.1 FATORES HUMANOS
Os defensores das metodologias ágeis de desenvolvimento esforçam-se 
para reforçar a importância dos “fatores humanos”. Pressman (2011) afirma que 
o desenvolvimento ágil foca talentos e habilidades de indivíduos, moldando 
o processo de acordo com as pessoas e equipes específicas. Abaixo listaremos 
algumas características ou traços-chave que uma pessoa de uma equipe ágil e a 
equipe em si devem possuir.
Competência: Abrange talentos inatos, habilidades específicas 
relacionadas a software e conhecimento generalizado do processo que a equipe 
escolheu para aplicar. Habilidade e conhecimento de processo podem e devem 
ser ensinados para todas as pessoas que sejam membros de uma equipe ágil. 
Foco comum: Embora os membros de uma equipe ágil possam realizar 
tarefas e tenham habilidades diferentes em um projeto, todos devem estar 
focados em um único objetivo: entregar um incremento de software funcionando 
ao cliente, dentro do prazo estipulado. Para atingir essa meta, a equipe também 
irá focar em adaptações contínuas (pequenas e grandes) que farão com que o 
processo se ajuste às necessidades da equipe.
Colaboração: Criar informações que ajudarão todos os envolvidos 
a compreender o trabalho da equipe e a construir informações (software para 
computadores e banco de dados relevantes) que forneçam valor de negócio para 
o cliente. Para realizar essas tarefas, os membros da equipe devem colaborar 
entre si, e com todos os demais envolvidos.
Habilidade à tomada de decisão: Ter liberdade para controlar seu 
próprio destino, ou seja, a equipe deve ter autonomia, autoridade na tomada de 
decisões. Tanto nos assuntos técnicos como de projetos. 
Habilidade de solução de problemas confusos: Os gerentes de 
software devem reconhecer que a equipe ágil terá de lidar continuamente com 
ambiguidade e que será continuamente atingida por mudanças. Em alguns casos, 
a equipe tem de aceitar o fato de que o problema que eles estão solucionando hoje 
talvez não seja o problema que necessita ser solucionado amanhã. Entretanto, 
lições aprendidas de qualquer atividade de solução de problemas podem ser 
futuramente benéficas para a equipe no projeto.
33
TÓPICO 3 | MÉTODO DE DESENVOLVIMENTO ÁGIL
Confiança mútua e respeito: Deve ser uma equipe consistente, pois 
demonstra confiança e o respeito necessário para torná-la fortemente unida. O 
todo é maior que a soma das partes.
Auto-organização: No contexto do desenvolvimento ágil, a auto-
organização implica três fatores:
1. A equipe ágil se organiza para o trabalho a ser feito;
2. A equipe organiza o processo para melhor se adequar ao seu 
ambiente local;
3. A equipe organiza o cronograma de trabalho para melhor cumprir a 
entrega do incremento de software.
FONTE: Disponível em: <https://www.passeidireto.com/arquivo/16282034/engenharia-de-
software---uma-abordagem-profissional----7-edicao/35>. Acesso em: 11 abr. 2016.
A auto-organização possui uma série de benefícios técnicos, mas o mais 
importante é o fato de servir para melhorar a colaboração e levantar o moral da 
equipe. Vale ressaltar que a equipe faz seu próprio gerenciamento, pois seleciona 
quanto trabalho acredita ser capaz de realizar dentro da iteração e se compromete 
com o trabalho. É extremamente desmotivador para o conjunto um terceiro assumir 
compromissos por ele.
2.2 METODOLOGIAS ÁGEIS DE DESENVOLVIMENTO DE 
SOFTWARE
Como foi visto até agora, as metodologias ágeis têm o objetivo de acelerar 
o desenvolvimento do software visando a melhoria contínua do processo, gerando 
benefícios como o aumento da comunicação e interação da equipe, organização 
diária para o alcance da meta definida, evitar falhas na elaboração, respostas 
rápidas às mudanças e aumento significativo da produtividade. A seguir, algumas 
metodologias de desenvolvimento ágil.
• Extreme Programming XP.
• Desenvolvimento de Software Adaptativo (ASD).
• Scrum.
• Método de Desenvolvimento de Sistemas Dinâmicos (DSDM).
• Crystal.
• Desenvolvimento Dirigido à Funcionalidade (FDD).
• Desenvolvimento de Software Enxuto (LSD).
• Modelagem Ágil (AM).
• Processo Unificado Ágil (AUP).
• Rational Unified Process (RUP).
34
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
2.2.1 Extreme Programming (programação extrema) XP
Em seu livro, Pressman (2011, p.87) define um conjunto de cinco valores 
que estabelecem as bases para todo o trabalho realizado com parte da XP, onde 
cada um deles é usado como um direcionador das atividades, ações e tarefas 
específicas da XP:
• Comunicação
• Simplicidade
• Feedback (realimentação ou retorno)
• Coragem e
• Respeito.
A Extreme Programming emprega uma abordagem orientada a objetos 
como seu paradigma de desenvolvimento preferido e envolve um conjunto de 
regras e práticas constantes no contexto de quatro atividades metodológicas, que 
são: planejamento, projeto, codificação e testes. A Figura 17 ilustra o processo e 
destaca alguns conceitos e tarefas-chave associados a cada uma das atividades 
metodológicas.
FIGURA 17 - EXTREME PROGRAMMING
FONTE: Pressman (2011, p. 88)
Segundo Sommerville (2011, p.44), em um processo XP os clientes estão 
intimamente envolvidos na especificação e priorização dos requisitos do sistema.Os requisitos não estão especificados como uma lista de funções requeridas do 
35
TÓPICO 3 | MÉTODO DE DESENVOLVIMENTO ÁGIL
sistema. Pelo contrário, o cliente do sistema é parte da equipe de desenvolvimento 
e discute cenários com outros membros da equipe. Juntos eles desenvolvem um 
“cartão de história” englobando as necessidades do cliente.
FIGURA 18 - DESENVOLVIMENTO XP
FONTE: Sommerville (2011, p.45)
2.2.2 Desenvolvimento de Software Adaptativo (ASD)
É uma técnica para a construção de software e sistemas complexos. As bases 
se concentram na colaboração humana e na auto-organização das equipes. Nesta 
técnica de desenvolvimento define-se um ciclo de vida que incorpora três fases: 
especulação, colaboração e aprendizagem.
Princípio ou prática Descrição
Planejamento 
incremental
Os requisitos são gravados em cartões de história e as histórias que 
serão incluídas em um release são determinadas pelo tempo disponível e 
sua relativa prioridade. Os desenvolvedores dividem essas histórias em 
'Tarefas'. Veja quadro 3.1 e 3.2.
Pequenos releases
Em primeiro lugar, desenvolve-se um conjunto mínimo de funcionalidades 
útil, que fornece o valor do negócio. Releases do sistema são frequentes e 
gradualmente adicionam funcionalidade ao primeiro release.
Projeto simples Cada projeto é realizado para atender às necessidades atuais e nada mais.
Desenvolvimento 
test-first
Um framework de testes iniciais automatizados é usado para escrever os 
testes para uma nova funcionalidade antes que a funcionalidade em si seja 
implementada.
Refatoração
Todos os desenvolvedores devem refatorar o códio continuamente assim 
que encontrarem melhorias de código. Isso mantém o código simples e 
manutenível.
Programação em 
pares
Os desenvolvedores trabalham em pares, verificando o trabalho dos outros 
e prestando apoio para um bom trabalho sempre.
Propriedade 
Coletiva
Os pares de desenvolvedores trabalham em todas as áreas do sistema, de 
modo que não se desenvolvam ilhas de expertise. Todos os conhecimentos 
e todos os desenvolvedores assumem responsabilidade por todo o código. 
Qualquer um pode mudar qualquer área.
Integração contínua
Assim que o trabalho em uma tarefa é concluído, ele é integrado ao sistema 
como um todo. Após essa integração, todos os testes de unidade do sistema 
devem passar.
Ritmo sustentável
Grandes quantidades de horas-extras não são consideradas aceitáveis, pois 
o resultado final, muitas vezes, é a redução da qualidade do código e da 
produtividade a médio prazo.
Cliente no local
Um representante do usuário final do sistema (o cliente) deve estar 
disponível todo o tempo à equipe de XP. Em um processo de Extreme 
Programming, o cliente é um membro da equipe de desenvolvimento e é 
responsável por levar a ela os requisitos de sistema para implementação.
36
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
FIGURA 19 - DESENVOLVIMENTO DE SOFTWARE ADAPTATIVO (ASD)
FONTE: Pressman (2011, p.94)
2.2.3 Scrum
Os princípios do Scrum são consistentes com o manifesto ágil e são usados 
para orientar as atividades de desenvolvimento dentro de um processo que 
incorpora as seguintes atividades estruturais: Requisitos, análise, projeto, evolução 
e entrega. Em cada atividade metodológica ocorrem tarefas a realizar dentro de 
um padrão de processo chamado Sprint. O fluxo geral do processo de Scrum é 
ilustrado na Figura 20.
37
TÓPICO 3 | MÉTODO DE DESENVOLVIMENTO ÁGIL
FIGURA 20 - DESENVOLVIMENTO SCRUM
FONTE: Pressman (2011, p. 96)
Segundo o guia do Scrum (2013, p. 4), ele é baseado nas teorias empíricas 
de controle de processo, ou empirismo. O empirismo garante que o conhecimento 
vem da experiência e de tomada de decisões baseadas no que é conhecido. O Scrum 
emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade 
e o controle de riscos. 
São três os pilares que apoiam a implementação de controle de processo 
empírico: transparência, inspeção e adaptação, que detalharemos a seguir:
Transparência: Aspectos significativos do processo devem estar 
visíveis aos responsáveis pelos resultados. Esta transparência requer 
aspectos definidos por um padrão comum para que os observadores 
compartilhem um mesmo entendimento do que está sendo visto.
Por exemplo:
• Uma linguagem comum referindo-se ao processo deve ser 
compartilhada por todos os participantes; e,
• Uma definição comum de “Pronto” deve ser compartilhada por 
aqueles que realizam o trabalho e por aqueles que aceitam o resultado 
do trabalho.
Inspeção: Os usuários Scrum devem, com frequência, vistoriar os 
artefatos Scrum e o desenvolvimento em direção a detectar variações. 
Esta inspeção não deve, no entanto, ser tão frequente que atrapalhe a 
própria execução das tarefas. As inspeções são mais benéficas quando 
realizadas de forma diligente por inspetores especializados no trabalho 
a se verificar.
Esse assunto merece seu estudo, acesse http://www.scrumguides.org/docs/
scrumguide/v1/Scrum-Guide-Portuguese-BR.pdf
DICAS
38
UNIDADE 1 | INTRODUÇÃO AOS MODELOS DE PROCESSO TRADICIONAIS: MODELO CASCATA
E INCREMENTAL E MODELOS EVOLUCIONÁRIOS: MODELO ESPIRAL E PROTOTIPAÇÃO
Adaptação: Se um inspetor determina que um (ou mais) aspectos de 
um processo desviou para fora dos limites aceitáveis, e que o produto 
resultado será inaceitável, o processo ou o material sendo produzido 
deve ser ajustado. O ajuste deve ser realizado o mais breve possível, 
para minimizar mais desvios.
O Scrum (2013, p.4) prescreve quatro eventos formais, contidos dentro dos 
limites da Sprint, para inspeção e adaptação, como descrito na seção Eventos do 
Scrum deste documento.
• Reunião de planejamento da Sprint
• Reunião diária
• Reunião de revisão da Sprint
• Retrospectiva da Sprint
Steffen (2011) afirma que o Scrum não é um processo ou uma técnica, 
mas um framework que, quando usado puro ou em conjunto com demais práticas 
ou processos, promove maior flexibilidade, visibilidade e produtividade, além, 
é claro, de outros benefícios que ainda serão abordados. É importante que 
fique claro que Scrum não é uma abordagem prescritiva. Não é um processo 
previsível, ele não define o que fazer em toda circunstância. É uma ferramenta, 
um framework, um conjunto de práticas que torna tudo visível. O Scrum deixa 
muitas decisões a critério da equipe, porque acredita que a equipe sabe como 
melhor resolver algum problema apresentado, assim como quais práticas ela 
está madura suficiente para adotar. Ainda segundo a autora, os envolvidos em 
um projeto podem ser divididos em dois grupos:
• Stakeholders (interessados no produto, mas não comprometidos)
• Time Scrum, que é composto do Product Owner, ScrumMaster e equipe de 
desenvolvimento (7 + ou - 2, ou seja, de 5 até 9 pessoas).
O Product Owner gerencia o product Backlog
• Representa todos os demais stakeholders (cliente, usuários, representantes de 
negócios, etc.). 
• Responsável por definir a funcionalidade do produto 
• Foco nos negócios. É responsável pelo gerenciamento do Product Backlog, 
pelo ROI e prioridades. 
• Responsável pelo aceite do produto - resultado de cada Sprint. 
• Não é um comitê, mas uma única pessoa. 
• É o único responsável pela manutenção do Backlog. 
• Não pode ser o ScrumMaster 
• Define para onde o time deve ir mas não como chegar lá, não em qual 
velocidade.
 
O ScrumMaster é quem gerencia o processo, ele é o facilitador da equipe 
e é responsável por:
• Garantir que os valores e as práticas do Scrum foram entendidos pelo time e 
estão sendo seguidos. 
39
TÓPICO 3 | MÉTODO DE DESENVOLVIMENTO ÁGIL
• Ensinar e treinar a equipe de forma que ela seja autogerenciável e multifuncional. 
• Ensinar/Garantir que o Product Owner também está desempenhando seu 
trabalho. 
• Remover impedimentos (visíveis e não visíveis) (internos e externos). 
• Motivar e manter a saúde da equipe, trabalho em equipe, comunicação, 
minimizando atritos e promovendo