XP

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Centro de Computação e Tecnologia da 
Informação 
 
Metodologia Ágil e XP 
 
Engenharia de Software III 
 
Prof. Daniel Luis Notari 
 
Agosto - 2012 
Engenharia de Software 
• Desenvolvimento ad-hoc de software em geral 
produz resultados muito ruins 
– Especialmente em sistemas grandes 
• Desejo de criar uma engenharia para que se 
tenha controle sobre desenvolvimento de 
software 
• Engenharias tradicionais colocam grande 
ênfase em projetar antes de construir 
Visão Tradicional da 
Evolução do Software 
custo 
 
momento em que 
funcionalidade é 
adicionada 
Utopia do Software? 
• Desenvolver o produto que atenda as 
necessidades do cliente e seja entregue no 
prazo, com o custo e o nível de qualidade 
desejado. 
 
Projetos de software ainda falham 
2002
2000
1998
1996
1994
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
16%
27%
26%
28%
34%
31%
40%
28%
23%
15%
53%
33%
46%
49%
51%
Standish Group - CHAOS Research
Challenged
Failed
Suceeded
Uso de funcionalidades 
XP 2002 – Johnson, Jim – ROI, it’s your job. 
Queremos Poder Alterar Software 
• No inicio do projeto, normalmente não se sabe 
precisamente o que se quer 
• Software evolui para atender ao negócio 
– Software nunca fica “pronto” 
• Obviamente isso só é possível porque software 
é uma entidade abstrata 
Portanto… 
• Precisamos parar de tentar evitar mudanças 
– Mudanças são um aspecto intrínseco da vida do 
software 
• Precisamos de uma metodologia de 
desenvolvimento que nos permita alterar 
constantemente o código sem comprometer 
sua qualidade 
O que queremos é… 
custo 
 
momento em que 
funcionalidade é 
adicionada 
Manifesto Ágil 
1. Indivíduos e interações são mais importantes 
que processos e ferramentas 
2. Software funcionando é mais importante 
que documentação completa e detalhada 
3. Colaboração com o cliente é mais 
importante que negociação de contratos 
4. Adaptação a mudanças é mais importante 
que seguir um plano 
http://www.agilemanifesto.org/ 
Metáfora: Guiar um Carro 
– Os clientes “guiam” o conteúdo do sistema 
– O time “guia” o processo de desenvolvimento 
Métodos Ágeis 
• Métodos ágeis (AM) 
– é uma coleção de metodologias baseada na 
prática para modelagem efetiva de sistemas 
baseados em software. 
– É uma filosofia onde muitas metodologias se 
encaixam. 
• As metodologias ágeis 
– aplicam uma coleção de práticas, guiadas por 
princípios e valores que podem ser aplicados por 
profissionais de software no dia a dia. 
 
12 
13 
O que são os Modelos Ágeis? 
• Um modelo ágil é um modelo bom o suficiente, nada 
mais, o que implica que ele exibe as seguintes 
características: 
1.Ele atende seu propósito 
2.Ele é inteligível. 
3.Ele é suficientemente preciso. 
4.Ele é suficientemente consistente. 
5.Ele é suficientemente detalhado. 
6.Ele provê um valor positivo. 
7.Ele é tão simples quanto possível. 
 
14 
O que é (e não é) métodos ágeis? 
1. É uma atitude, não um processo prescritivo. 
2. É um suplemento aos métodos existentes, ele não 
é uma metodologia completa. 
3. É uma forma efetiva de se trabalhar em conjunto 
para atingir as necessidades das partes 
interessadas no projeto. 
4. É uma coisa que funciona na prática, não é teoria 
acadêmica. 
 
15 
O que é (e não é) métodos ágeis? (cont.) 
5. É para o desenvolvedor médio, mas não é um 
substituto de pessoas competentes. 
6. Não é um ataque à documentação, pelo 
contrário aconselha a criação de documentos 
que tem valor. 
7. Não é um ataque às ferramentas CASE. 
 
Pontos importantes do Movimento 
Ágil 
• Processos adaptativos 
– As mudanças são bem vindas 
– Necessidade de feedback constante 
– O aprendizado adquirido reverte na melhoria 
do produto 
• Foco nas pessoas 
• Software: o artefato mais importante 
Metodologias ágeis 
• Extreme Programming 
• Crystal Family 
• Adaptive Software Development (ASD) 
• SCRUM 
• Feature-Driven Development (FDD) 
• Dynamic System Development Method (DSDM) 
• Lean Software Development 
• Agile Modeling (AM) 
Comparando metodologias atuais 
Extreme Programming 
 
Motivações do XP 
• Tornar o desenvolvimento de software 
melhor 
• Produzir software de qualidade em um 
ritmo sustentável 
• Trazer transparência, responsabilidade e 
capacidade de justificativa (accountability) 
• Abraçar as mudanças 
• Reconciliar humanidade e produtividade 
Origem do XP 
• Chrysler Comprehensive Compensation System (C3) 
• Novo sistema de folha de pagamento, unificando os sistemas 
existentes 
• Projeto orientado a objetos usando Smalltalk 
• De 1995 a 1996 – Empresa contratada inicia o projeto. Os 
resultados obtidos são ruins e o projeto entra em crise 
• Kent Beck avalia o projeto e constata seu estado crítico 
• De 1997 a 1999 – Liderado por Beck, o projeto se tornou o 
laboratório das práticas que hoje formam o XP 
Premissa extrema 
Premissa extrema 
• Com as tecnologias e práticas apropriadas é possível 
alcançar uma curva de mudanças em software mais linear 
– Orientação a objetos 
– Design simples, sem elementos extras 
– Testes automatizados 
– Prática na aplicação de refinamentos constantes ao 
design para torná-lo mais simples 
• Se isto for verdade, podemos experimentar uma maneira de 
lidar com software totalmente diferente 
Uma métafora: aprendendo a dirigir 
• Dirigir um carro, mesmo em 
uma estrada reta, implica em 
pequenos ajustes ao longo do 
tempo 
• Trânsito, imprevistos, 
mudanças de prioridades, 
podem mudar o seu caminho 
• Este é o paradigma do XP: 
Fique atento, adapte, mude 
 
Valores, princípios e práticas 
• Valores: são nossas crenças fundamentais, aquilo em que 
acreditamos no desenvolvimento de software. 
• Práticas: são atitudes, atividades concretas que fazemos no 
dia-a-dia. Garantem a aplicação dos valores. 
• Princípios: servem como guias, específicos do contexto de 
desenvolvimento, que ajudam a adaptar as práticas à 
realidade particular de cada equipe ou projeto. 
Valores Práticas 
Princípios 
Valores, princípios e práticas 
Práticas
Principios
Valores
Actividades
Valores de XP 
• Comunicação 
• Simplicidade 
• Feedback 
• Coragem 
• Respeito 
Práticas de XP 
• Inicialmente o XP definia um conjunto de 12 práticas. 
Estas práticas continuam válidas até hoje, mas foram 
remodeladas nos últimos anos 
• O conjunto atual de práticas está dividido em dois 
grupos: 
– Práticas primárias são independentes das práticas 
atuais de sua equipe. São seguras e cada uma 
delas pode gerar melhoria imediata. 
– Práticas corolárias dependem da aplicação efetiva 
das práticas primárias. É difícil aplicá-las sem ter 
domínio sobre as primárias antes. 
12 Práticas originais 
• Jogo do Planejamento 
• Releases Pequenos 
• Cliente “on-site” 
• Testes de Aceitação 
• Teste Primeiro 
(Test Driven Development) 
• Design Simples 
 
• Refatoração 
• Programação em Pares 
• Metáfora 
• Padrões de Codificação 
• Propriedade Coletiva do 
Código 
• Integração Contínua 
• Semana de 40 horas 
(Ritmo Sustentável) 
 
 
Nível do Cliente 
Nível da Equipe 
Nível do Par 
Sinergia das práticas 
Práticas corolárias 
• Envolvimento real do 
cliente 
• Entrega incremental 
• Continuidade da equipe 
• Shrinking teams 
• Análise de causa-raíz 
• Código compartilhado 
• Codifique e teste 
• Base de código única 
• Entrega diária 
• Contrato de escopo 
negociado 
• Pay-per-use
Preparando-se para o XP 
• A primeira coisa que 
deve ser feita para se 
começar um projeto XP 
é reorganizar o 
ambiente. 
• White Boards. 
• Mobília preparada para 
o trabalho em duplas. 
• Mural para colocar os 
cartões. 
Uma das mais importantes ferramentas do XP 
Jogo do planejamento 
• Pessoal de Negócio toma as decisões de negócio 
– Definir as datas 
– Escrever as histórias (escopo) 
– Priorizar o que deve ser feito 
• Pessoal Técnico toma as decisões técnicas 
– Estimar as histórias 
– Informar os riscos técnicos 
– Informar sua velocidade 
Histórias 
Um usuário pode reservar um quarto com um cartão de crédito. 
 
 
Nota: Serão aceitos VISA, MasterCard e American Express. 
Verificar Diner’s. 
• Pequenos pedaços de funcionalidades que produzem valor para os 
usuários do sistema. 
• Por simplicidade, são escritas em cartões. 
• Escritas pelo cliente ou por algum tipo de user proxy (gerentes, equipes 
de marketing, especialistas do domínio, analistas de negócio, etc). 
• Promessas de conversa futura, não especificações detalhadas 
Teste de aceitação 
• Podem ser escritos inicialmente no verso dos cartões. 
• Podem ser documentados em um editor de texto simples. 
• Existem algumas ferramentas automatizadas (FIT e FitNesse). 
• Como as histórias, são escritos pelo cliente ou por algum tipo de User 
Proxy. 
Testar com Visa, MasterCard e American Express (passar) 
Testar com Diner’s Club (falhar) 
Testar com números de cartões inválidos 
Testar com cartões expirados 
Testar com valores acima do limite do cartão 
Stand Up Meeting 
• Cada dia de trabalho “começa” 
com uma reunião, onde todos 
conversam sobre os problemas 
encontrados no dia anterior e 
definem as prioridades do dia 
que se inicia. 
• A reunião é curta, mais ou 
menos uns 15 minutos. O fato de 
ser em pé ajuda a alcançar este 
objetivo. 
• Registrar o progresso da iteração 
(quadro de acompanhamento) 
Web Designer ? 
Programação em Par 
• Duas cabeças realmente pensam 
melhor que uma. 
• Todo código de produção é escrito 
por pares de desenvolvedores. 
• Dois papéis: 
– Piloto: quem está com o teclado 
e com o mouse. Pensa focado no 
código a sua frente. 
– Navegador: o outro. Pensa mais 
estrategicamente. 
• Pressão do par favorece a 
produtividade. 
• Maior qualidade do código, mais 
correto, menos bugs. 
Desenvolvimento em XP 
• Práticas 
– Test Driven Development 
– Refatoração 
– Design simples e incremental 
– Propriedade coletiva do código 
– Integração contínua 
– Padrões de codificação 
Comentários finais sobre as práticas 
• Participação do 
cliente é 
fundamental para o 
sucesso de um 
projeto. 
 
• XP estabelece um 
ritmo de trabalho 
sustentável. 
 
Ciclo de vida de XP 
Ciclo de vida de XP 
O ritmo XP 
Extreme Programming (XP) 
• Viva a mudança!!! 
• Desenvolvimento de software é … 
– um aprendizado 
– como dirigir um carro 
• Desenvolvimento de software não é … 
– como construir uma ponte 
– aponte e atire 
Refatoração 
• Refatorar é melhorar o código sem alterar sua 
funcionalidade 
• Antes de uma mudança, você refatora o código 
para que a mudança seja simples de fazer 
• Refatoração continua possibilita manter um 
bom projeto, mesmo com mudanças 
freqüentes 
Testes Automáticos 
• Testes automáticos são parte do software 
– Se você tem somente a funcionalidade, seu software 
está incompleto 
• Testes permitem que você refatore sem medo de 
quebrar o código 
• Testes representam uma “redundância lógica” 
que você adiciona ao código 
• Escrevendo testes antes da funcionalidade, você 
clareia dúvidas sobre o que o software deve fazer 
Aspectos Importantes de XP 
• Design mais simples possível 
• Programação em pares 
• Propriedade coletiva do código 
• Cliente sempre disponível 
• Estórias do usuário 
• Planejamento do release 
O Design Mais Simples Possível 
• Designs flexíveis são uma defesa contra 
mudanças imprevistas no software 
• Porém, designs flexíveis também têm custos 
– Tempo para desenvolvimento e manutenção 
– O código fica mais complexo 
– Muita vezes a flexibilidade não é utilizada nunca 
• Como mudança é barata em XP, vamos manter o 
design mais simples possível, modificando-o 
quando for necessário suportar mais 
funcionalidade 
O Design Mais Simples Possível 
• O melhor design é aquele que: 
– Roda todos os testes 
– Não contém duplicação de funcionalidade 
– Deixa claro as decisões de design importantes 
– Tem o menor número possível de classes e métodos 
• O melhor design não é aquele: 
– Mais flexível (com mais “ganchos”) 
– Mais abstrato 
– Que resistirá ao tempo 
Programando em Pares 
• Se revisão de código é boa, vamos fazê-la o tempo todo 
• Em XP, programação é feita em pares 
• Pares mudam com relativa rapidez (em dias) 
• Programação em pares favorece comunicação e 
aprendizado 
• Mas, você precisa estabelecer um padrão de 
codificação 
• Há casos de redução no tempo de desenvolvimento 
com programação em pares 
Propriedade Coletiva do Código 
• Desenvolvimento com objetos leva a alterações 
por todo o código 
• Coordenar alterações toma tempo e gera 
resistências no “dono” do código 
• Em XP, não se coordena, simplesmente faz-se o 
que precisa ser feito 
• Mas integra-se freqüentemente 
– No máximo, uma vez por dia 
Propriedade Coletiva do Código 
• Todos são responsáveis por todo o código 
• Qualquer um que vê uma oportunidade de 
adicionar valor ao código, devo fazê-lo 
– Mantendo em vista as prioridades do cliente 
– Mantendo o design mais simples possível 
• Testes protegem a funcionalidade 
• Padrão de codificação são usados 
Cliente Sempre Disponível 
• Um cliente (usuário da aplicação) deve trabalhar 
com o time para esclarecer dúvidas, resolver 
disputas e estabelecer pequenas prioridades 
• É muito caro colocar um cliente a disposição do 
desenvolvimento? 
Estórias 
• Usuários escrevem estórias descrevendo a 
funcionalidade que querem 
• Desenvolvedores estimam o tempo necessário 
para implementar cada estória 
• Um release é um conjunto de estórias que são 
disponibilizados simultaneamente 
– As estórias mais importantes e/ou mais difíceis tem 
prioridade 
Planejamento 
• Cliente decide: 
– escopo 
– prioridade 
– composição do release 
– data do release 
 
• Programadores decidem: 
– estimativas 
– conseqüências 
– processo 
– planejamento intra-release (o 
mais arriscado primeiro) 
Releases 
• XP preconiza releases pequenos e freqüentes (a 
cada 2-3 meses) 
• As quatro dimensões do desenvolvimento de 
software são Custo, Tempo, Qualidade e Escopo 
– XP tenta manter escopo como variável livre 
Iterações 
• Releases são divididos em iterações de 2-3 
semanas 
• Uma iteração alcança algum objetivo 
(tipicamente a adição de nova funcionalidade) 
• Nada é feito que não seja imediatamente útil e 
necessário para não impactar os prazos de 
desenvolvimento 
Tarefas 
• Iterações são divididas em tarefas 
• Tarefas são a menor quantidade de trabalho que 
pode ser feita até que todos os testes voltem a 
funcionar 
• Tarefas não levam mais que um dia 
• Uma vez concluídas, tarefas são integradas 
imediatamente 
Dificuldades em XP 
• Considerar testes como parte normal do 
processo de desenvolvimento 
• Sempre fazer a coisa mais simples 
• Admitir que você não sabe 
• Colaborar 
• Vencer resistência nas pessoas 
Problemas de XP 
• Times grandes 
• Situações em que você não pode mudar 
livremente o código 
• Escrever testes para
sistemas não-
deterministicos, distribuídos ou paralelos 
 
Exercícios 
1. Das 12 práticas apresentadas, escolha duas delas uma 
como sendo a mais fácil de ser aplicada e, uma delas 
como sendo a mais difícil de ser aplicada. Justifique a sua 
resposta. 
2. O que você acha da sistema de afixar os requisitos em um 
quadro branco usando post-it? 
3. Você acha que o jogo do planejamento pode funcionar 
em um ambiente real? Cite três estratégias que podem ser 
utilizadas. 
 
Exercícios 
4. No XP, os testes de software são tão ou mais 
importantes do que o código gerado para o 
produto final. Você acredita nisto? 
5 Porque o XP prega a programação em pares? Isto 
funciona na prática 
6. O que é mesmo refatoraração de código? 
7. Você acha que é viável ter sempre o cliente 
disponível? Quais os problemas se isto não 
ocorrer durante o desenvolvimento do software? 
 
Exercícios 
8. Pesquise na Internet por um caso de sucesso da 
aplicação da metodologia XP. Relate como foi a 
implantação e as lições aprendidas. 
9. Pesquise na Internet por um caso de insucesso 
da aplicação da metodologia XP. Relate como foi 
a implantação e as lições aprendidas. 
10. Pesquise por ferramentas que possam ser 
utilizadas com a metodologia XP. 
 
Exercícios 
11. Para o estudo de caso da locadora de filmes, 
faça uma proposta de definição das sprints e 
releases para atender as histórias propostas. 
12. Faça uma proposta de implantação de uma 
equipe XP para atender o planejamento proposto 
no exercício anterior. 
 
ESTUDO DE CASO 
DE UM PROJETO XP 
 LOCADORA DE VÍDEOS 
CARTÃO DE VISÃO 
Locadora de vídeos 
 O sistema deverá proporcionar a locação de 
vídeos, fornecendo um controle dos filmes locados 
por cada cliente e dos pagamentos a serem 
realizados por estes clientes, de acordo com as 
notas fiscais emitidas. A identificação do cliente 
deverá ser feita através de seu nome e a senha 
por ele cadastrada. 
HISTÓRIA DE USUÁRIO 1 
1 
2 
Cadastro dos filmes 
 Permite que cada filme adquirido pela locadora 
possa ser cadastrado. Este cadastro será baseado no 
código de barras de cada filme, que representará o 
código do filme. Além do código, deverá conter o 
nome, atores principais, tipo de filme, diretor, sinopse, 
tempo de duração, censura (idade mínima), data de 
cadastramento, preço de compra do filme e o valor da 
diária. Também deverá apresentar a situação do filme 
(locado ou disponível) e o número de locações que o 
mesmo já teve. 
HISTÓRIA DE USUÁRIO 2 
2 
7 
Consulta filmes 
 Deverá permitir que os responsáveis pela 
locadora possam consultar os filmes e seus dados 
cadastrais, de acordo com as necessidades 
encontradas. 
HISTÓRIA DE USUÁRIO 2.1 
2.1 
1 
Consulta por tipo de filme 
 Permite a consulta dos filmes conforme a sua 
modalidade (aventura, comédia, etc.). 
HISTÓRIA DE USUÁRIO 2.2 
2.2 
1 
Consulta por nome do filme 
 Permite a consulta dos filmes a partir do nome 
do filme, que poderá ser completo ou parcial, 
através de palavras-chave. 
HISTÓRIA DE USUÁRIO 2.3 
2.3 
1 
Consulta por ator do filme 
 Permite a consulta através do nome de um dos 
atores principais do filme. O nome para consulta 
poderá ser completo ou parcial. 
HISTÓRIA DE USUÁRIO 2.4 
2.4 
1 
Consulta por diretor do filme 
 Permite a consulta a partir do nome do diretor 
do filme, que poderá ser digitado completo ou 
parcial. 
HISTÓRIA DE USUÁRIO 2.5 
2.5 
1 
Consulta por lançamentos 
 Permite a consulta dos filmes lançados 
(cadastrados) nos últimos sessenta dias. 
HISTÓRIA DE USUÁRIO 2.6 
2.6 
2 
Consulta pelos filmes mais locados 
 Permite a consulta através dos filmes mais 
locados num período de sessenta dias. Os quinze 
filmes que tiveram a maior quantidade de 
locações, dentre os cadastrados nos últimos 
sessenta dias, deverão ser listados numa 
seqüência, de acordo com o número de locações 
realizadas. 
HISTÓRIA DE USUÁRIO 3 
3 
3 
Cadastro de clientes 
 Permite o cadastramento dos clientes da 
locadora de vídeos. Neste cadastro deverá conter 
o nome (que servirá como código de identificação 
do cliente), endereço (rua/avenida, número, 
apartamento, bairro, CEP, telefone), CPF, RG, 
data de nascimento, saldo devedor e uma senha 
de seis números, a qual o cliente irá cadastrar. 
HISTÓRIA DE USUÁRIO 4 
4 
2 
Consulta aos clientes 
 Permite a consulta ao cadastro do cliente, 
que poderá ser realizada a partir de seu nome 
(completo ou parcial), RG ou CPF. 
 Após localizado o cadastro do cliente, 
poderão ser dados os comandos para locação 
do(s) filme(s). 
HISTÓRIA DE USUÁRIO 5 
5 
3 
Controle da locação dos vídeos 
 Após o cliente escolher os filmes, ele irá ao caixa, que irá 
escanear o código de barras do(s) filme(s) escolhido(s). A idade 
do cliente não poderá ser inferior à idade de censura descrita no 
cadastro do filme. O cliente não poderá estar devendo à 
locadora. 
 O cliente irá conferir o “pedido” e digitará a sua senha para a 
confirmação do mesmo. 
 O número de locações deste(s) filme(s) será acrescido em 
uma unidade no(s) seu(s) cadastro(s). 
 Será impresso o comprovante da locação, com o(s) nome(s) 
do(s) filme(s), seu(s) preço(s) e a data para devolução. 
HISTÓRIA DE USUÁRIO 6 
6 3 
Controle da devolução dos vídeos 
 Após o cadastro do cliente ser localizado, será verificado se a data 
prevista para devolução do(s) filme(s) foi respeitada. 
 Se houver atraso na entrega, o cliente deverá pagar o preço do(s) 
filme(s) atrasado(s) por cada dia atrasado na devolução. Se não, o saldo 
devedor do cliente será apresentado para que este faça o pagamento. 
 Caso o cliente não pague, será feita uma anotação no seu cadastro, 
impedindo novas locações até que o pagamento seja efetuado. 
 Caso o vídeo apresente danos, o preço de compra deste filme deverá 
ser anotado no saldo devedor do cliente, para que este pague um filme 
novo à locadora. 
 O(s) filme(s) será(ão) baixado(s) do cadastro do cliente. 
 Será impressa a nota fiscal, comprovando o pagamento efetuado e a 
devolução do(s) filme(s). 
HISTÓRIA DE USUÁRIO 7 
7 
2 
Impressão do comprovante de locação e do cupom fiscal 
 Após o cliente digitar sua senha para confirmação da locação do(s) 
vídeo(s), deverá ser impresso um comprovante da locação com duas 
vias, que deverá conter os dados da locadora (nome, endereço e 
CNPJ), a data atual, o nome do cliente, o(s) nome(s) do(s) filme(s) 
locado(s), o preço da diária do(s) filme(s) e a data prevista para 
devolução. Este comprovante deverá ter um espaço para que o cliente 
possa assinar, confirmando o recebimento dos filmes. 
 Quando o cliente fizer a devolução do(s) filme(s), deverá ser 
impresso um cupom fiscal, onde constará, além dos dados da locadora 
(nome, endereço e CNPJ), o nome do cliente, a data da devolução, 
o(s) nome(s) do(s) filme(s) devolvido(s) e o valor do pagamento 
efetuado. 
CASO DE USO 1 
Locação dos vídeos 
Este caso de uso é usado para definir os caminhos ideais para um cliente 
no cenário de uma locadora de vídeos, para a locação de filmes. 
Nome do caso de uso: Locação de vídeos. 
Ator principal: Cliente. 
Descrição breve: Este caso de uso descreve as iterações que ocorrem 
quando um cliente aluga um vídeo. 
Gatilho: O cliente escolhe o(s) filme(s) na prateleira. 
Pré-condições: 
O cliente deve
ter uma conta ativa. 
O cliente atende o requisito de idade da censura do vídeo existente no 
cadastro. 
Deverão existir filmes cadastrados na locadora. 
Fluxo dos eventos: 
1. O cliente irá escolher o(s) filme(s). 
CASO DE USO 1 [ Cont... ] 
2. O cliente irá se dirigir ao caixa, que irá identificar o cliente e localizar o 
seu cadastro. 
3. O caixa irá escanear o código de barras do(s) filme(s) e apresentar o 
pedido ao cliente. 
4. O cliente irá conferir o pedido e digitar sua senha para confirmá-lo. 
5. Será impresso o comprovante de locação que o cliente irá assinar 
após receber o(s) filme(s). 
Pós-condições: 
* O número de locações existente no cadastro do filme será acrescido em 
uma unidade. 
* O cliente leva o(s) vídeo(s) escolhido(s). 
Fluxos alternativos e exceções: 
* O cliente tem idade inferior à censura estabelecida para o filme 
escolhido. 
* A conta é inválida devido à falta de pagamento de um vídeo ou à não 
devolução do mesmo. 
CASO DE USO 2 
Devolução dos vídeos 
Este caso de uso é usado para definir os caminhos ideais para um 
cliente no cenário de uma locadora de vídeos, fazendo a devolução 
do(s) vídeo(s) locado(s). 
Nome do caso de uso: Devolução dos vídeos. 
Ator principal: Cliente. 
Descrição breve: Este caso de uso descreve as iterações que 
ocorrem quando um cliente devolve o(s) filme(s) na locadora. 
Gatilho: O cliente vai ao caixa com o(s) filme(s) que assistiu. 
Pré-condição: 
* O(s) filme(s) deverá(ão) ser entregue(s) ao caixa pelo cliente. 
Fluxo dos eventos: 
1. O cliente irá dirigir-se ao caixa e devolver o(s) filme(s). 
2. O caixa irá localizar o cadastro do cliente. 
3. O caixa irá apresentar o saldo devedor ao cliente. 
CASO DE USO 2 [ Cont... ] 
4. O cliente irá conferir o valor a pagar e efetuar o pagamento. 
5. Será impressa a nota fiscal para o cliente, comprovando o 
pagamento e a devolução do(s) filme(s). 
Pós-condições: 
* O(s) filme(s) devolvido(s) deverá(ão) ser retirado(s) do cadastro do 
cliente. 
* O saldo devedor será anotado no cadastro do cliente como uma 
restrição para novas locações, no caso do não pagamento de algum 
vídeo. 
Fluxos alternativos e exceções: 
* O cliente não efetuou o pagamento do saldo devedor. 
* O vídeo apresentou danos causados pelo cliente. 
 
TESTE DE ACEITAÇÃO 1 
Cenário: a locadora recebe novos filmes. 
Operação: os filmes não estão cadastrados no 
sistema. 
Verificação: o código de barras (código) de cada 
filme será escaneado e seus dados serão 
cadastrados: nome, atores principais, tipo de filme, 
diretor, sinopse, tempo de duração, idade de 
censura, data do cadastramento, número de 
locações, situação (locado ou disponível), preço 
de compra e o valor da diária. 
TESTE DE ACEITAÇÃO 2 
Cenário: o cliente entra na locadora de vídeos. 
Operação: o cliente quer saber se a locadora 
possui determinado filme. 
Verificação: o caixa poderá consultar o filme 
através de seu nome, atores, diretor ou tipo, 
verificando a sua existência e, no caso, se o 
mesmo está locado ou disponível. 
TESTE DE ACEITAÇÃO 3 
Cenário: o cliente entra na locadora de vídeos. 
Operação: o cliente quer saber os últimos 
filmes adquiridos pela locadora. 
Verificação: o caixa irá consultar os 
lançamentos, ou seja, serão apresentados 
todos os filmes que foram cadastrados nos 
últimos sessenta dias pela locadora. 
TESTE DE ACEITAÇÃO 4 
Cenário: o cliente entra na locadora de vídeos. 
Operação: o cliente quer ver a lista dos filmes 
mais locados. 
Verificação: o caixa irá consultar os filmes 
mais locados, onde serão apresentados os 
quinze filmes que tiveram o maior número de 
locações, dentre os cadastrados nos últimos 
sessenta dias. 
TESTE DE ACEITAÇÃO 5 
Cenário: a pessoa entra na locadora de 
vídeos. 
Operação: a pessoa ainda não é cliente da 
locadora. 
Verificação: a pessoa irá apresentar seu RG, 
CPF e comprovante de residência para que o 
caixa possa fazer o seu cadastro no sistema 
da locadora, além de cadastrar uma senha de 
seis números para a locação dos filmes. 
TESTE DE ACEITAÇÃO 6 
Cenário: a pessoa entra na locadora de vídeos e 
escolhe o(s) filme(s). 
Operação: caixa quer verificar se a pessoa já é 
cliente da locadora. 
Verificação: o caixa fará a consulta ao cadastro 
da pessoa, a partir de seu nome, RG ou CPF. 
TESTE DE ACEITAÇÃO 7 
Cenário: o cliente dirige-se ao caixa com o(s) filme(s) 
escolhido(s). 
Operação: o caixa deve registrar a locação do(s) vídeo(s). 
Verificação: depois de localizar o cadastro do cliente, o caixa 
irá escanear o código de barras do(s) vídeo(s) escolhido(s). O 
cliente, após conferir o pedido, digitará sua senha confirmando a 
locação. O caixa fará a impressão do comprovante de locação, 
contendo o(s) nome(s) do(s) filme(s) locado(s), preço(s) e data 
para devolução. O comprovante deverá ser assinado pelo 
cliente. 
 Caso houver algum saldo devedor não pago pelo cliente ou a 
idade do cliente for inferior à censura do filme, a locação não 
poderá ser efetuada. 
TESTE DE ACEITAÇÃO 8 
Cenário: o cliente assina o comprovante, 
confirmando a locação do(s) vídeo(s). 
Operação: o número de locações no cadastro 
do vídeo deverá ser alterado. 
Verificação: após a assinatura do cliente, 
confirmando a locação do vídeo, a variável 
“número de locações” existente no cadastro do 
vídeo deverá ser acrescida em uma unidade 
para facilitar a consulta dos filmes mais 
locados. 
TESTE DE ACEITAÇÃO 9 
Cenário: o cliente entra na locadora de vídeos 
para devolver o(s) vídeo(s) locado(s). 
Operação: o caixa deverá registrar a devolução 
do(s) vídeo(s). 
Verificação: o caixa irá consultar o cadastro do 
cliente, registrando a devolução do(s) vídeo(s). O 
cliente deverá fazer o pagamento da diária do(s) 
vídeo(s). Após o pagamento ser efetuado deverá 
ser impresso um cupom fiscal, comprovando a 
devolução e o pagamento da locação do(s) 
vídeo(s). 
TESTE DE ACEITAÇÃO 10 
Cenário: a data de devolução do vídeo difere da data 
prevista para devolução. 
Operação: o caixa deverá cobrar a multa pelo atraso 
na devolução. 
Verificação: durante o registro de devolução feito pelo 
caixa, será verificado que a data de devolução difere 
da data prevista na locação. O cliente deverá pagar o 
número de diárias correspondente ao atraso na 
entrega. 
 Após o pagamento ser efetuado deverá ser impresso 
um cupom fiscal, comprovando a devolução e o 
pagamento da locação do(s) vídeo(s). 
TESTE DE ACEITAÇÃO 11 
Cenário: o vídeo devolvido pelo cliente está 
danificado. 
Operação: o cliente deverá cobrar do cliente o 
preço correspondente à compra deste filme. 
Verificação: o caixa irá consultar o preço de 
compra do vídeo existente no cadastro do mesmo, 
e cobrar este valor do cliente. 
 Caso o cliente não pague, este valor deverá ser 
registrado no cadastro do cliente, como saldo 
devedor do cliente. 
TESTE DE ACEITAÇÃO 12 
Cenário: o cliente não paga o valor da locação 
do(s) vídeo(s). 
Operação: o caixa deverá registrar a falta de 
pagamento no cadastro do cliente. 
Verificação: o caixa irá acessar o cadastro do 
cliente e registrar o valor não pago como saldo 
devedor do cliente, impossibilitando novas 
locações até que o pagamento seja efetuado. O 
mesmo ocorrerá se o cliente danificar um vídeo e 
não pagar o valor correspondente à compra deste 
filme. 
CRONOGRAMA 
Atividade Data 
Inicial 
Data 
Final 
Duração Custo 
(R$) 
1 Cadastro de 
filmes 
01/01 05/01 1 40,00 
2 Consulta filmes 08/01 22/01 2,5 100,00
2.1 Consulta por tipo 
de filme 
08/01 09/01 0,25 10,00 
2.2 Consulta por 
nome do filme 
09/01 11/01 0,5 20,00 
2.3 Consulta por ator 
do filme 
11/01 12/01 0,25 10,00 
CRONOGRAMA [ Cont... ] 
2.4 Consulta por 
diretor do filme 
15/01 17/01 0,5 20,00 
2.5 Consulta por 
lançamentos 
17/01 19/01 0,5 20,00 
 
2.6 
Consulta pelos 
filmes mais 
locados 
19/01 22/01 0,5 20,00 
3 Cadastro de 
clientes 
22/01 26/01 1 40,00 
4 Consulta aos 
clientes 
29/01 31/01 0,5 20,00 
 
5 
Controle da 
locação dos 
vídeos 
31/01 20/02 3 120,00 
CRONOGRAMA [ Cont... ] 
 
6 
Controle da 
devolução dos 
vídeos 
20/02 13/03 3 120,00 
 
7 
Impressão do 
comprovante de 
locação e do 
cupom fisca 
13/03 20/03 1 40,00 
TOTAL 14,5 580,00