RUP e metodologias ageis

Prévia do material em texto

Análise e Desenvolvimento de 
Sistemas 
Engenharia de Software 
 
O processo RUP / Métodos Ágeis 
 
2/ 
Agenda 
O processo RUP 
Desenvolvimento ágil 
Exemplo de metodologia ágil: SCRUM 
3/ 
Agenda 
O processo RUP 
Desenvolvimento ágil 
Exemplo de metodologia ágil: SCRUM 
4/ 
O processo RUP 
Definição 
–O modelo de Processo Unificado Rational (Rational Unified 
Process ou simplesmente RUP) é um modelo de processo 
moderno de software que surgiu para suportar a linguagem de 
notação UML (Unified Modeling Language); 
–A linguagem de notação UML começará a ser estudada neste 
curso, quando se iniciar os estudos sobre a técnica de Casos de 
Uso, que auxilia na descoberta e registro dos requisitos de um 
sistema; 
–O RUP é uma instância do Processo Unificado de 
Desenvolvimento de Software – é uma aplicação dele (KROLL; 
KRUCHTEN, 2003) . 
5/ 
O processo RUP 
Conceitos 
–É um modelo de processo híbrido - reúne elementos de todos 
os modelos de processos genéricos; 
–Descreve boas práticas de especificação e de projeto e 
suporta prototipagem e também desenvolvimento incremental; 
–Suporta artefatos orientados a objetos, em particular, UML; 
–Gerenciável e controlável; 
–O RUP é descrito a partir de três perspectivas: 
Perspectiva dinâmica, que mostra as fases do modelo ao 
longo do tempo; 
Perspectiva estática, que mostra as atividades do processo 
que foram adotadas; 
Perspectiva prática, que sugere boas práticas para serem 
utilizadas durante o processo. 
6/ 
O processo RUP 
Fases 
–As fases do RUP são mais relacionadas aos negócios do que a atividades do 
processo (como no modelo Cascata); 
–São quatro fases: 
Início (ou Concepção) estabelece um plano de negócios para o sistema, 
identificam-se todas as entidades externas que interagirão com o sistema e 
definem-se essas interações; 
Elaboração: entende-se o problema, elabora-se uma arquitetura do sistema, 
desenvolve-se um plano do projeto e identificam-se os principais riscos do projeto. 
Produz um modelo de requisitos do sistema; 
Construção: envolve o projeto do sistema, programação e testes. 
Desenvolvimento executado de modo integrado e em paralelo. Resulta em um 
software operacional e sua documentação associada prontos para serem 
entregues aos usuários; 
Transição: trata da passagem do sistema em desenvolvimento para os seus 
usuários finais e fazer com que o sistema funcione em um ambiente real. 
7/ 
O processo RUP 
Perspectiva dinâmica – Fases 
–Fase de Início 
Descreve um produto potencial que será transformado em um 
projeto real; 
A principal decisão a ser tomada no final desta fase: deve-se ou 
não investir tempo e dinheiro para analisar em detalhes o que 
vai ser construído; 
Entradas: ideia inicial; um sistema legado; pedido de 
desenvolvimento (RFP – Request For Proposal); produto 
anterior e uma lista de melhorias; disponibilidade de software, 
conhecimento, dinheiro; um protótipo; 
Saídas: uma descrição clara do produto (requisitos 
principais) → funcionalidade, escopo, eficiência, capacidade 
etc; critérios para avaliar o sucesso (exemplo projeção de 
vendas); avaliação inicial de riscos; estimativa de recursos para 
terminar a fase de Elaboração. 
8/ 
O processo RUP 
Perspectiva dinâmica – Fases 
–Fase de Elaboração 
Analisa-se profundamente o problema para se estabilizar a 
arquitetura. No final desta fase produz-se um plano indicando como as 
próximas duas fases serão realizadas; 
Constrói-se um protótipo, em uma ou mais iterações, dependendo do 
escopo, risco, tamanho, grau de inovação do projeto abrangendo pelo 
menos os casos de uso principais; 
Entradas: produtos e artefatos produzidos na fase anterior; um plano 
aprovado, financiador e recursos para esta fase; 
Saídas: plano detalhado do software com avaliação de riscos 
atualizada; plano de gerência; plano de equipes; plano da fase, 
indicando o número e o conteúdo de cada iteração; plano de iteração, 
detalhando a próxima iteração; ambiente de desenvolvimento e outras 
ferramentas necessárias; plano de testes. 
9/ 
O processo RUP 
Perspectiva dinâmica – Fases 
–Fase de Construção 
Esta fase é dividida em diversas iterações, evoluindo a 
arquitetura de referência até o produto final. Para cada iteração 
tem-se critérios de entrada e de saída; 
Entradas: produtos e artefatos produzidos na fase anterior. 
Neste caso, o plano de iteração da fase anterior deve ainda 
especificar: capacidades adicionais do sistema; riscos a serem 
eliminados nesta iteração; defeitos a serem consertados nesta 
iteração; 
Saídas: os mesmos produtos e artefatos da fase anterior e 
documento descrevendo a versão; casos de teste realizados 
sobre os produtos; plano de iteração, descrevendo a próxima 
iteração; critério de avaliação mensurável, para as próximas 
iterações. 
10/ 
O processo RUP 
Perspectiva dinâmica – Fases 
–Fase de Transição 
Envolve marketing, empacotamento, instalação, configuração, 
suporte, correções etc. As iterações continuam com uma ou 
mais versões: versões “beta”, versões de correção etc. Um 
aceite formal é feito pelo cliente e então todas as atividades são 
terminadas. 
Entradas: os produtos e artefatos da iteração anterior e o 
software suficientemente maduro para ser instalado/operado no 
cliente; 
Saídas: atualizações de documentos anteriores, se 
necessário; uma análise “post-mortem” do produto em relação 
aos critérios de sucesso originalmente definidos; inventário dos 
novos ativos obtidos pela organização como resultado. 
11/ 
O processo RUP 
Perspectiva dinâmica – Iterações 
–São suportadas de duas formas: 
Cada fase pode ser executada independentemente de forma 
iterativa com seus produtos obtidos de modo incremental; 
Todo o conjunto de fases também ser praticado de forma 
incremental. 
12/ 
O processo RUP 
Perspectiva Estática 
–Enfoca as atividades que ocorrem durante o processo de 
desenvolvimento; 
–Elas são denominadas de fluxos de trabalho (workflows) ou 
disciplinas; 
–Existem seis disciplinas de engenharia e três disciplinas de 
suporte: 
Disciplinas de Engenharia 
–Modelagem de Negócios; 
–Requisitos; 
–Análise e Projeto; 
–Implementação; 
–Teste; 
–Implantação. 
Disciplinas de Suporte 
–Gerenciamento da Configuração e 
Mudanças; 
–Gestão de Projetos; 
–Ambiente. 
13/ 
O processo RUP 
Perspectiva Estática 
–Existem seis disciplinas de engenharia e três disciplinas de 
suporte: 
 
 
Disciplinas de Engenharia 
–Modelagem de Negócios; 
–Requisitos; 
–Análise e Projeto; 
–Implementação; 
–Teste; 
–Implantação. 
Criar um canal de comunicação entre 
engenharia de negócios e engenharia de 
software de modo a compreender a 
estrutura e a dinâmica da empresa, seus 
problemas organizacionais atuais e 
identificar possíveis melhorias; 
Estabelecer um entendimento comum por 
clientes, usuários finais e desenvolvedores 
do que é a organização; 
Elaborar uma visão da organização na qual o 
sistema será implantado e como usar esta 
visão como uma base para descrever o 
processo, papéis e responsabilidades. 
14/ 
O processo RUP 
Perspectiva Estática 
–Existem seis disciplinas de engenharia e três disciplinas de 
suporte: 
 
Disciplinas de Engenharia 
–Modelagem de Negócios; 
–Requisitos; 
–Análise e Projeto; 
–Implementação; 
–Teste; 
–Implantação. 
Explica como elicitar requisitos das partes 
interessadas no sistema (stakeholders) e 
transformá-los em um conjunto de 
requisitos que detalham para o que o software 
deverá realizar; 
Responde a questão: “O que é para fazer?” 
15/ 
O processo RUP 
Perspectiva Estática 
–Existem seis disciplinas de engenharia e três disciplinas de 
suporte: 
Disciplinas de Engenharia 
–Modelagem de Negócios; 
–Requisitos; 
–Análise e Projeto; 
–Implementação; 
–Teste; 
–Implantação. 
Constrói um sistema que será executado em 
um ambiente de execução específico, e que 
contemplará as tarefas e funções 
especificadasnas especificações de 
requisitos (casos de uso); 
O sistema deverá cumprir todos seus 
requisitos; 
O sistema deverá ser facilmente mantido de 
mesmo quando ocorrerem mudanças nos 
requisitos funcionais; 
Responde a questão: “Como fazer?” 
16/ 
O processo RUP 
Perspectiva Estática 
–Existem seis disciplinas de engenharia e três disciplinas de 
suporte: 
Disciplinas de Engenharia 
–Modelagem de Negócios; 
–Requisitos; 
–Análise e Projeto; 
–Implementação; 
–Teste; 
–Implantação. 
Organiza o código do sistema, em termos de 
subsistemas de implementação, em 
camadas; 
Implementa classes e objetos em termos de 
componentes (arquivos-fonte, binários, 
executáveis e outros) 
Testa os componentes desenvolvidos como 
unidades; 
Integra os resultados produzidos por 
implementadores individuais (ou equipes), 
em um sistema executável; 
Sistemas são realizados através da 
aplicação de componentes. 
17/ 
O processo RUP 
Perspectiva Estática 
–Existem seis disciplinas de engenharia e três disciplinas de 
suporte: 
Disciplinas de Engenharia 
–Modelagem de Negócios; 
–Requisitos; 
–Análise e Projeto; 
–Implementação; 
–Teste; 
–Implantação. 
Verificar a interação entre objetos; 
Verifica a integração adequada de todos os 
componentes do software; 
Verifica se todos os requisitos foram 
corretamente implementados; 
Identifica e garante que os defeitos são 
descobertos antes da implantação do 
software; 
Garante que todos os defeitos são 
corrigidos, reanalisados e fechados. 
18/ 
O processo RUP 
Perspectiva Estática 
–Existem seis disciplinas de engenharia e três disciplinas de 
suporte: 
Disciplinas de Engenharia 
–Modelagem de Negócios; 
–Requisitos; 
–Análise e Projeto; 
–Implementação; 
–Teste; 
–Implantação. 
Produz produtos finais de acordo com 
releases e entrega o software para seus 
usuários; 
Diversas atividades: produção de releases, 
empacotamento do software, distribuição 
do software, instalação do software e 
prestação de ajuda e assistência aos 
usuários. 
19/ 
O processo RUP 
Perspectiva Estática 
–Existem seis disciplinas de engenharia e três disciplinas de 
suporte: 
Disciplinas de Engenharia 
–Modelagem de Negócios; 
–Requisitos; 
–Análise e Projeto; 
–Implementação; 
–Teste; 
–Implantação. 
Disciplinas de Suporte 
–Gerenciamento da Configuração 
e Mudanças; 
–Gestão de Projetos; 
–Ambiente. 
Gerenciamento de configuração: 
responsável pela estruturação sistemática dos 
produtos e suas dependências – os artefatos 
precisam estar sob controle de versão e suas 
alterações devem ser visíveis; 
Gerenciamento de solicitações de 
mudança: controlar as propostas de 
mudança e aceitá-las (ou não) nas versões; 
Gerenciamento de status e medição: às 
solicitações são atribuídas estados de 
mudança também atributos tais como a 
causa raiz, ou a natureza (como o defeito e 
melhoria) e prioridade, por exemplo. 
20/ 
O processo RUP 
Perspectiva Estática 
–Existem seis disciplinas de engenharia e três disciplinas de 
suporte: 
Disciplinas de Engenharia 
–Modelagem de Negócios; 
–Requisitos; 
–Análise e Projeto; 
–Implementação; 
–Teste; 
–Implantação. 
Disciplinas de Suporte 
–Gerenciamento da Configuração e 
Mudanças; 
–Gestão de Projetos; 
–Ambiente. 
Ocorre em dois níveis: plano de fases e 
plano de iterações; 
O plano de fases descreve todo o projeto; 
O plano de iterações é mais detalhado e 
descreve os passos iterativos a serem 
aplicados às fases individuais ou conjuntos 
de fases. 
21/ 
O processo RUP 
Perspectiva Estática 
–Existem seis disciplinas de engenharia e três disciplinas de 
suporte: 
Disciplinas de Engenharia 
–Modelagem de Negócios; 
–Requisitos; 
–Análise e Projeto; 
–Implementação; 
–Teste; 
–Implantação. 
Disciplinas de Suporte 
–Gerenciamento da Configuração e 
Mudanças; 
–Gestão de Projetos; 
–Ambiente. 
Enfoca as atividades necessárias para 
configurar o processo para um projeto. Ele 
descreve as atividades necessárias para 
desenvolver as diretrizes de apoio a um 
projeto; 
Provê os processos e as ferramentas que 
darão suporte à equipe de desenvolvimento 
para a execução do projeto. 
22/ 
O processo RUP 
Perspectiva Prática 
–É representada pelas boas práticas (best practices), comumente 
adotadas pela industria: 
1) Desenvolvimento iterativo do software; 
2) Gerenciamento de requisitos; 
3) Uso de arquitetura baseada em componentes; 
4) Modelagem visual do software; 
5) Verificação contínua da qualidade do software; 
6) Controle de mudanças do software. 
23/ 
O processo RUP 
Visão geral das perspectivas – fases e iterações 
24/ 
Agenda 
O processo RUP 
Desenvolvimento ágil 
Exemplo de metodologia ágil: SCRUM 
25/ 
Desenvolvimento ágil 
Panorama atual do desenvolvimento de sistemas 
–As empresas operam em um ambiente global, marcado por 
mudanças rápidas; 
–Elas têm que responder rapidamente às novas oportunidades 
e mercados, às alterações nas condições econômicas e ao 
surgimento de produtos e serviços concorrentes 
(SOMMERVILLE, 2011); 
–O software é parte de quase todas as operações de negócios 
– novos softwares são desenvolvidos rapidamente para tirar 
partido das novas oportunidades e responder às pressões 
competitivas; 
–Assim, o rápido desenvolvimento e a entrega são os 
requisitos mais críticos para os sistemas de software atuais. 
26/ 
Desenvolvimento ágil 
Panorama atual do desenvolvimento de sistemas 
–Assim é praticamente impossível obter um conjunto completo 
de requisitos de software estáveis; 
–Os requisitos inevitavelmente vão ser alterados pois é difícil 
prever como um novo sistema afetará práticas de trabalho, 
como ele vai interagir com outros sistemas, e que as operações 
do usuário deverão ser automatizadas; 
–Muitas vezes essas informações tornam-se mais claras apenas 
depois que o sistema tenha sido entregue e os usuários 
tenham ganhado experiência com ele; 
–Para piorar, os requisitos são susceptíveis de serem alterados 
de forma rápida e imprevisível devido a fatores externos tais 
como desatualização no momento de sua instalação no cliente. 
27/ 
Desenvolvimento ágil 
Panorama atual do desenvolvimento de sistemas 
–Processos de software que planejam e especificam 
completamente os requisitos para que, em seguida, projetem, 
construam e testem o sistema não estão orientados para o 
desenvolvimento rápido de software; 
–Desse modo, com a alteração ou a descoberta de problemas 
nos requisitos, o projeto e/ou a implementação do sistema 
deverá ser de ser reformulada e novamente testada, perdendo-
se assim um tempo substancial e incorrendo em custos 
adicionais; 
–Estes processos são genericamente denominados de 
processos “conduzidos por planos” – seu emprego é justificado 
apenas em sistemas onde é essencial uma análise completa do 
sistema, como em sistemas de segurança crítica. 
28/ 
Desenvolvimento ágil 
O manifesto ágil 
–A insatisfação com abordagens baseadas em plano para 
Engenharia de Software levou um número de desenvolvedores 
de software na década de 1990 para propor novos métodos – 
“métodos ágeis”; 
–Assim, em fevereiro de 2001, um grupo de 17 especialistas em 
processos de software, representando os principais métodos de 
desenvolvimento ágeis daquele momento, se reuniu para 
discutir suas metodologias e então como resultado disso surgiu 
o Manifesto para o Desenvolvimento Ágil; 
–Foram definidos doze princípios (FOWLER; HIGHSMITH, 2001; 
PRESSMAN, 2011). 
29/ 
Desenvolvimento ágil 
O manifesto ágil 
–Princípios 
1) Nossa maior prioridade é satisfazer o cliente por meio da entrega 
antecipada e contínua de um valioso software. 
2) As mudanças de requisitos são bem-vindas, mesmo próximas ao final do 
desenvolvimento. Processos ágeis utilizam a mudança como uma vantagem 
competitiva do cliente. 
3) Entregar software funcionando com frequência, a partir de algumas 
semanas a alguns meses, com preferência para os prazos maiscurtos. 
4) Empresários e desenvolvedores trabalham juntos diariamente durante 
todo o projeto. 
5) Construir projetos em torno de indivíduos motivados. Dê-lhes o ambiente 
e apoio que precisam e confie neles para fazer o trabalho. 
6) O método mais eficiente e eficaz de transmitir informações para e dentro 
de uma equipe de desenvolvimento é conversa cara a cara. 
30/ 
Desenvolvimento ágil 
O manifesto ágil 
–Princípios 
7) Software funcionando é a principal medida de progresso. 
8) Processos ágeis promovem o desenvolvimento sustentável. Os 
patrocinadores, desenvolvedores e usuários devem ser capazes de manter um 
ritmo constante indefinidamente. 
9) Atenção contínua a excelência técnica e bom projeto aumenta a 
agilidade. 
10) Simplicidade – a arte de maximizar a quantidade de trabalho não 
realizado – é essencial. 
11) As melhores arquiteturas, requisitos e projetos emergem de equipes 
auto-organizadas. 
12) Em intervalos regulares, a equipe reflete sobre como se tornar mais 
eficaz, então sintoniza e ajusta seu comportamento de modo adequado. 
31/ 
Desenvolvimento ágil 
Valores 
–Resumem os 12 princípios apresentados anteriormente: 
Indivíduos e interações em vez de processos e ferramentas; 
Software funcionando em vez de documentação abrangente; 
Colaboração do cliente em vez de negociação de contratos; 
Responder a mudanças em vez de seguir um plano. 
32/ 
Desenvolvimento ágil 
O que caracteriza um método ágil? 
–Adaptabilidade 
É a capacidade do processo em se adaptar face às novas 
situações e com isso acomodar as alterações que devem ser 
realizadas tanto em tecnologias quanto em requisitos, incluindo 
eventualmente alterações nos próprios métodos utilizados; 
Para que um processo seja adaptável, ele deve utilizar, de 
forma natural, a retroalimentação de informações (o 
“feedback”) obtida com os resultados da execução de uma 
atividade anterior àquela que se está executando no momento. 
Ser adaptativo é dar controle à imprevisibilidade; 
33/ 
Desenvolvimento ágil 
O que caracteriza um método ágil? 
–Iteratividade e incrementabilidade 
O software é desenvolvido em várias iterações, do seu 
planejamento à entrega final e, em cada iteração, uma parte ou 
versão do sistema é desenvolvida, testada e melhorada; 
Em cada iteração, a funcionalidade será aumentada ou 
refinada; 
O sistema cresce de modo incremental de acordo com a 
adição de novas funcionalidades com cada versão. Após cada 
iteração uma versão é entregue ao cliente de modo a obter sua 
avaliação, cujo resultado será utilizado nas próximas 
iterações. 
34/ 
Desenvolvimento ágil 
O que caracteriza um método ágil? 
–Orientado às pessoas e trabalho em equipe 
Nos métodos ágeis, as pessoas são mais importantes do que 
o processo, pois são os principais condutores do sucesso do 
projeto; 
O processo tem o papel de suportar a equipe de 
desenvolvimento para que ela possa executar seu trabalho da 
melhor maneira possível; 
As metodologias ágeis também enfatizam a comunicação 
direta (“cara a cara”) dentro das equipes e com o cliente, que 
deve se envolver diretamente com o processo de 
desenvolvimento em vez de acompanhá-lo apenas pelas 
documentações. 
35/ 
Agenda 
O processo RUP 
Desenvolvimento ágil 
Exemplo de metodologia ágil: SCRUM 
36/ 
Exemplo de metodologia ágil: SCRUM 
Origens 
–Um artigo publicado em 1986 no Japão que descrevia um 
processo de desenvolvimento de produto adaptativo, rápido e 
auto-organizado (TAKEUCHI; NONAKA, 1986); 
–Sobre o termo “scrum”: é derivado de uma estratégia no jogo 
de rugby, que reforça a ideia de trabalho em equipe, onde uma 
formação ordenada de 8 jogadores de cada o lado devem 
disputar a saída da bola após uma jogada irregular ou 
penalidade. 
37/ 
Exemplo de metodologia ágil: SCRUM 
Características da metodologia 
–SCRUM foi desenvolvido em 1993 para gerenciar o processo 
de desenvolvimento de sistemas (SCHWABER, 1995); 
–É uma abordagem empírica, inspirada na teoria de controle de 
processos industriais e reintroduz as ideias de flexibilidade, 
adaptabilidade e produtividade (SCHWABER, 1995); 
–Não define nenhuma técnica específica de desenvolvimento 
de software para as fases de implementação → concentra-se no 
comportamento dos membros da equipe de desenvolvimento para 
produzir um sistema de modo flexível em um ambiente de 
constantes alterações; 
–Principal conceito: o desenvolvimento de sistemas envolve 
muitas variáveis ambientais e técnicas (por exemplo, requisitos, 
unidades de tempo, recursos, tecnologia) e que provavelmente 
sofrerão mudanças durante a execução do processo. 
38/ 
Exemplo de metodologia ágil: SCRUM 
Fases 
–Pré-Jogo, Desenvolvimento (Jogo) e Pós-Jogo: 
De (ABRAHAMSSON et al., 2002) 
39/ 
Exemplo de metodologia ágil: SCRUM 
Fases 
–Pré-Jogo 
É uma fase cujas entradas, saídas e o processo é bem 
definido, fluxo linear e poucas iterações; 
Subfases 
–Planejamento 
Definição do sistema; 
Criação do backlog (lista de todas as funcionalidades do 
produto a serem desenvolvidas); 
Priorização dos requisitos e estimativa do esforço; 
Definição da equipe do projeto, ferramentas e outros recursos, 
avaliação e controle de riscos, treinamento e aprovação da 
gestão e financiamento; 
Em toda iteração, o backlog do produto é revisto pelas equipes 
SCRUM para a próxima iteração. 
40/ 
Exemplo de metodologia ágil: SCRUM 
Fases 
–Pré-Jogo (cont.) 
Subfases 
–Arquitetura/Projeto de Alto Nível 
Um projeto de alto nível do sistema, incluindo sua arquitetura, 
é planejado baseado no backlog atual; 
No caso de melhoria para um sistema existente, as alterações 
necessárias para implementar os itens do backlog são 
identificadas de acordo com os problemas que elas podem 
causar; 
Uma reunião de revisão do projeto é realizada para examinar as 
propostas de implementação e então decisões são tomadas 
com base nesta revisão; 
Adicionalmente, planos preliminares para o conteúdo das 
versões são preparados. 
41/ 
Exemplo de metodologia ágil: SCRUM 
Fases 
–Desenvolvimento 
É onde se encontra a parte ágil da metodologia; 
Esta fase é tratada como uma “caixa-preta” onde se espera o 
imprevisível; 
Aqui as variáveis de ambiente e técnicas definidas podem ser 
alteradas durante a execução do processo e são observadas e 
controladas por meio de diversas práticas durante períodos de 
desenvolvimento desta fase denominados sprints; 
Sprints são ciclos iterativos nos quais a funcionalidade é 
desenvolvida ou melhorada de modo a produzir novos 
incrementos; 
Cada sprint inclui as fases tradicionais de desenvolvimento 
de software. 
42/ 
Exemplo de metodologia ágil: SCRUM 
Fases 
–Desenvolvimento 
A arquitetura e o projeto do sistema evoluem durante o 
desenvolvimento de um sprint; 
Sprints são planejados para durar de uma semana a um mês; 
O processo de desenvolvimento de um sistema tipicamente 
exige de três a oito sprints antes que o sistema esteja pronto 
para ser distribuído; 
Pode haver mais do que uma equipe construindo o 
incremento. 
43/ 
Exemplo de metodologia ágil: SCRUM 
Fases 
–Pós-Jogo 
Contempla o encerramento da versão; 
Entra-se nesta fase quando um acordo é fechado a respeito em 
relação à conclusão das variáveis ambientais (por exemplo, 
requisitos); 
Neste caso nenhum item ou problema deverá figurar no 
backlog e nem se poderão inventar novos; 
O sistema está pronto para ser liberado e a preparação para 
isso é feita durante esta fase, e inclui tarefas tais como 
integração, testes do sistema e documentação. 
44/ 
Exemplo de metodologia ágil: SCRUM 
Papéis e responsabilidades 
–SCRUM Master (“mestre SCRUM”) 
É um facilitador, que organiza reuniões diárias, acompanha a 
acumulação de trabalho a ser feito, as decisões de registros, 
as medidas de progresso para evitar atrasos, e se comunica 
com os clientes e gerência; 
–Product Owner (“dono do produto”) 
É o responsávelpelo projeto, gerenciando, controlando e 
tornando visível o backlog do produto. Ele é escolhido pelo 
SCRUM Master, cliente e gerência; 
–SCRUM Team (“equipe SCRUM”) 
Decide que ações tomar e como se organizar para atingir os 
objetivos de cada sprint, estimativas, revisão do backlog e 
identificar problemas a serem removidos do projeto. 
45/ 
Exemplo de metodologia ágil: SCRUM 
Papéis e responsabilidades 
–Customer (“cliente”) 
Participa das tarefas relacionadas aos itens do backlog do 
produto no sistema em que está sendo desenvolvido ou 
melhorado; 
–Management (“gerência”) 
Toma decisões finais de acordo com os contratos, padrões e 
convenções a serem seguidas pelo projeto, participando também 
da definição dos objetivos e requisitos. 
46/ 
Exemplo de metodologia ágil: SCRUM 
Cerimônias 
–Planejamento da sprint (Sprint Planning Meeting) 
É a primeira reunião do projeto → todos devem participar; 
Duração máxima de oito horas; 
O Product Owner planeja e elabora a lista de prioridades que 
devem ser cumpridas pelo projeto: 
O Product Owner define suas prioridades, seleciona itens do 
backlog e a meta da sprint; 
A equipe define o sprint backlog → documento que contêm as 
tarefas necessárias para cumprir a meta; 
Às estórias (funcionalidades a serem desenvolvidas) são 
associadas complexidades de desenvolvimento → definidas 
pela equipe de modo simples e consensual (por exemplo, com o 
“Pôquer do Planejamento”); 
47/ 
Exemplo de metodologia ágil: SCRUM 
Cerimônias 
–Reunião diária (Daily SCRUM) 
Cada membro da equipe deve responder sobre o que já fez, o 
que pretende fazer e se há algum impedimento para a 
conclusão de suas tarefas; 
Deve ser rápida (≈15min.); 
Participam o SCRUM Master e a equipe; 
Todos os elementos da equipe devem participar; 
Normalmente após o almoço e em pé! 
48/ 
Exemplo de metodologia ágil: SCRUM 
Cerimônias 
–Revisão da sprint (Sprint Review) 
Reunião de balanço (<4h) após o término da sprint; 
A equipe deve mostrar os resultados da sprint ao Product 
Owner → somente o que está 100% pronto! 
Dinâmica 
–Um membro da equipe apresenta a meta do sprint, os itens do 
Product Backlog e os itens concluídos; 
–Os membros da equipe fazem uma demonstração funcional 
dos itens desenvolvidos. 
Participantes 
–Product Owner, SCRUM Master, equipe e convidados; 
Mudanças ou inserções serão priorizadas e incorporadas ao 
Product Backlog. 
49/ 
Exemplo de metodologia ágil: SCRUM 
Cerimônias 
–Retrospectiva da sprint (Sprint Retrospective) 
Realizada após uma revisão da sprint (<3h); 
Verifica o que houve de bom e o que pode ser melhorado em 
uma sprint; 
Aspectos: trabalho em equipe, pontos positivos e negativos, 
reflexões sobre estratégias de melhorias; 
Participam a equipe e o SCRUM Master → o SCRUM Owner 
pode participar como convidado; 
O SCRUM Master toma nota de tudo e a equipe se 
compromete a priorizar os itens apontados. 
50/ 
Exemplo de metodologia ágil: SCRUM 
Artefatos 
–Product Backlog (SBROCCO; MACEDO, 2012) 
Itens a serem desenvolvidos no projeto. 
51/ 
Exemplo de metodologia ágil: SCRUM 
Artefatos 
–Sprint Backlog (SBROCCO; MACEDO, 2012) 
Tarefas a serem desenvolvidas na sprint. 
52/ 
Exemplo de metodologia ágil: SCRUM 
Artefatos 
–Task Board (SBROCCO; MACEDO, 2012) 
Quadro de acompanhamento das sprints. 
53/ 
Exemplo de metodologia ágil: SCRUM 
Artefatos 
–Post-It (SBROCCO; MACEDO, 2012) 
Atividade a ser desenvolvida. 
54/ 
Exemplo de metodologia ágil: SCRUM 
Artefatos 
–Gráfico Burndown 
Exibe o esforço restante para concluir o trabalho. 
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/ 
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
55/ 
Referências bibliográficas 
ABRAHAMSSON, P. et al. Agile software development methods : review and analysis. Espoo [Finland]: VTT, 
2002. 
FOWLER, M.; HIGHSMITH, J. The agile manifesto. Software Development, v. 9, n. 8, p. 28–35, 2001. 
KROLL, P.; KRUCHTEN, P. The Rational Unified Process Made Easy: A Practitioner’s Guide to the RUP. 
Boston: Addison-Wesley, 2003. 
PRESSMAN, R. S. Software engineering: a practitioner’s approach. 7. ed. New York: McGraw-Hill Higher 
Education, 2010. 
SCHWABER, K. SCRUM Development Process. In: PROCEEDINGS OF THE ACM CONFERENCE ON 
OBJECT-ORIENTED PROGRAMMING–SYSTEMS, LANGUAGES AND APPLICATIONS (OOPSLA’95): 
WORKSHOP ON BUSINESS OBJECT DESIGN AND IMPLEMENTATION. 1995. 
SCHWABER, K. Agile project management with SCRUM. Redmond, Wash.: Microsoft Press, 2004. 
SBROCCO, J. H. T. DE C.; MACEDO, P. C. DE. Metodologias Ágeis: engenharia de software sob medida. 
São Paulo: Editora Érica, 2012. 
SOMMERVILLE, I. Software Engineering. 9. ed. Boston, MA: Pearson, 2011. 
TAKEUCHI, H.; NONAKA, I. The new new product development game. Harvard business review, v. 64, n. 1, p. 
137–146, 1986.