Modelos de Ciclo de Vida, Mtodos geis, Ferramentas CASE

Fernando Pedrosa fpedrosa@gmail.com

 Pressman, Roger S. Software
Engineering: A Practiotioners
Approach. Editora: McGraw-Hill.
Sommerville, Ian. Software
Engineering. Editora: Addison Wesley.

Fernando Pedrosa Lopes 2

 Disciplina de engenharia preocupada com
todos os aspectos sobre a produo de
software, incluindo:
Processos
Racionalizam o desenvolvimento de Software
Mtodos
Conhecimento tcnico; Como fazer
Ferramentas
Suporte automatizado para processos e mtodos

Desenvolver software no s programar!

Fernando Pedrosa Lopes 3

 Obter software de qualidade
Com produtividade no seu
desenvolvimento, operao e
manuteno
Dentro de custos, prazos e nveis de
qualidade controlados
Com o melhor custo-benefcio entre
Qualidade e Produtividade

Fernando Pedrosa Lopes 4

 Engenharia de Sistemas algo maior:
preocupa-se com todos os aspectos de
sistemas baseados em computador
Software
Hardware
Processos
Pessoas e outros sistemas, etc.
Engenharia de Software apenas parte
deste processo

Fernando Pedrosa Lopes 5

(TRE/BA CESPE 2010)
[61] A engenharia de software est relacionada com todos os
aspectos da produo de software, desde os estgios iniciais de
especificao do sistema at sua manuteno, depois que este
entrar em operao. A engenharia de sistemas diz respeito aos
aspectos do desenvolvimento e da evoluo de sistemas complexos,
nos quais o software desempenha um papel importante.

Fernando Pedrosa Lopes 6

(IBGE CONSULPLAN 2009)
[12] Segundo Pressman (1995), Engenharia de Software o estabelecimento e
uso de slidos princpios de engenharia para que se possa obter
economicamente um software que seja confivel e que funcione
eficientemente em mquinas reais, abrangendo um conjunto de trs elementos
fundamentais (mtodos, ferramentas e procedimentos).

Assinale a alternativa INCORRETA:

A) Mtodos de Engenharia de Software proporcionam os detalhes de como

fazer para construir o software.
B) As ferramentas proporcionam apoio automatizado ou semi-automatizado
aos mtodos.
C) Procedimentos constituem o elo de ligao dos mtodos e das ferramentas
e possibilitam o desenvolvimento racional e oportuno de software.

Fernando Pedrosa Lopes 7

D) Mtodos envolvem um amplo conjunto de tarefas que incluem:
planejamento e estimativa de projeto, anlise de requisitos de software e
sistemas, projeto de estrutura de dados, arquitetura de programa e
algoritmo de processamento, codificao, teste e manuteno.
E) Ferramentas so roteiros para o desenvolvimento de software

Fernando Pedrosa Lopes 8

 Dcada de 60: a chamada Crise do
Software
Desenvolvimento fora de controle
Iniciou como um problema de Custo e
Produtividade.
Mais importante: era um problema de
Qualidade
Dcada de 70
Programao Estruturada
Projeto Estruturado

Fernando Pedrosa Lopes 9

Fernando Pedrosa Lopes 10
 Dcada de 80
Anlise Estruturada (DFDs, Dicionrio de
Dados, Diagrama ER, de Estados, etc.)
Ferramentas CASE

Dcada de 90
Anlise e Projeto OO.
Java
UML
Processo Unificado

Fernando Pedrosa Lopes 11

 Anos 2000
Metodologias geis
Novos paradigmas: SOA, Aspectos,
Model-Driven Architecture, etc.
Cloud Computing

Fernando Pedrosa Lopes 12

Software
Programa de computador e
documentao associada
Produtos de software podem ser
desenvolvidos para um cliente
particular ou podem ser desenvolvidos
para um mercado geral
Novos softwares podem ser criados
desenvolvendo-se novos programas
ou reusando softwares existentes
Fernando Pedrosa Lopes 13
Processo
Uma srie conectada de aes, com a
inteno de satisfazer um objetivo
Define quem est fazendo o qu,
quando e como para atingir um certo
objetivo

Processo
Entrada (atividades e sub- Sada
processos)

Fernando Pedrosa Lopes 14

Processo de Software
Um conjunto estruturado de
atividades para desenvolver um
sistema de software
Especificao
Projeto
Validao
Evoluo

Fernando Pedrosa Lopes 15

Fernando Pedrosa Lopes 16
 So uma representao abstrata e
simplificada do processo de
desenvolvimento software, apresentada
a partir de uma perspectiva especfica
Tipicamente contm:
Esqueleto do processo
Ordem de precedncia das atividades
Principais artefatos e produtos gerados

Fernando Pedrosa Lopes 17

 Cascata ou Clssico
Prototipagem
Mtodos formais
Espiral
Incremental

Fernando Pedrosa Lopes 18

 Modelo Clssico, teve origem na
indstria de manufatura e construo
Sua estrutura composta por vrias
etapas que so executadas de forma
sistemtica e seqencial
Na falta de uma abordagem
estruturada, foi a primeira tentativa de
formalizar uma metodologia de
desenvolvimento de software

Fernando Pedrosa Lopes 19

 Comunicao

- Iniciao do projeto
- Levantamento de Requisitos
Planejamento

- Estimativas
- Cronograma Modelagem
- Monitoramento

- Anlise
- Projeto Construo

- Codificao
Implantao
- Teste

- Entrega
- Manuteno
- Feedback

Fernando Pedrosa Lopes 20

Definio de
Requisitos

Projeto de
SW e Sistema

Codificao e
testes
unitrios

Integrao e
testes de sistema

Operao e
Manuteno

Fernando Pedrosa Lopes 21

 Minimiza o planejamento, organiza as
atividades em uma sequncia com
entregas bem definidas
Funciona bem para requisitos estveis
e bem compreendidos
O modelo pressupe que os requisitos
ficaro estveis ao longo do projeto
facilmente aplicvel em equipes
inexperientes
Porm, atrasa a reduo de riscos!
Fernando Pedrosa Lopes 22
 Atividades: requisitos projeto codificao integrao - testes

Incio da integrao
Desenvolvimento

Falha tardia
(% codificado)
Progresso de

de projeto

Data (deadline) de
entrega original

Cronograma do Projeto

Fernando Pedrosa Lopes 23

(TST - CESPE 2008)
[93] No modelo de desenvolvimento seqencial linear, a fase de
codificao a que gera erros de maior custo de correo.

(SERPRO CESPE 2008)

[63] O modelo em cascata consiste de fases e atividades que devem
ser realizadas em seqncia, de forma que uma atividade
requisito da outra.

(INMETRO - CESPE 2009)

[85] Em um processo de desenvolvimento em cascata, os testes de
software so realizados todos em um mesmo estgio, que acontece
aps a finalizao da fase de implementao.

Fernando Pedrosa Lopes 24

[86] Em uma empresa que tenha adotado um processo de
desenvolvimento de software em cascata, falhas no levantamento de
requisitos tm maior possibilidade de gerar grandes prejuzos do
que naquelas que tenham adotado desenvolvimento evolucionrio.

(SAD/PE - CESPE 2010 - adaptada)

[58] O gerente geral de projetos da empresa decidiu, junto a um
cliente, realizar algumas modificaes nos requisitos de um produto
de software que j se encontrava na fase de testes e comprometeu-
se a incluir tais requisitos na prxima liberao do produto. Essa
deciso permite inferir que o modelo de desenvolvimento de
software empregado no do tipo cascata.

Fernando Pedrosa Lopes 25

 Planejamento
Esboar escopo e requisitos
Fazer estimativas razoveis sobre
recursos, custos e prazos

Anlise e Especificao de Requisitos

Refinar requisitos e escopo
Entender o domnio do problema, com
comportamento e funcionalidades
esperados

Fernando Pedrosa Lopes 26

 Projeto
Incorporar requisitos tecnolgicos aos
requisitos essenciais do sistema
Projetar a arquitetura do sistema

Implementao
Traduzir o projeto em uma forma passvel
de execuo pela mquina
Codificao

Fernando Pedrosa Lopes 27

 Testes
Realizar diversos nveis de teste, de forma
a fazer a verificao do software.

Implantao, Operao e Manuteno

Colocar o software em produo
Treinar pessoas
Manter o software
Gerenciar os servios

Fernando Pedrosa Lopes 28

 O objetivo trabalhar junto aos clientes
para evoluir o sistema a partir de uma
especificao inicial resumida
Entregar resultado o mais rpido possvel
Deve comear com requisitos mais bem
compreendidos
Novas funcionalidades so adicionadas
medida que o cliente as propem
Aplicvel em sistemas pequenos ou
mdios com curto tempo de vida
Fernando Pedrosa Lopes 29
Problemas
Falta de visibilidade do progresso
O sistema est sempre evoluindo, nunca
est terminado
Os sistemas acabam tornando-se
pobremente estruturados
A documentao pode ser esquecida
Os padres de qualidade podem ser
relaxados

Fernando Pedrosa Lopes 30

 Assim como na prototipagem
evolucionria, pequenas verses
prototpicas so disponibilizadas ao
clientes para avaliao
Porm, o objetivo aqui entender e
clarificar os requisitos do sistema
Deve-se comear com os requisitos
mais difceis e menos compreendidos
Ao final, descarta-se o prottipo e a
implementao do software continua
Fernando Pedrosa Lopes 31
 til para sistemas grandes e
complicados, e quando o cliente no
sabe exatamente o que quer
Prottipos descartveis podem ser
aplicados no contexto de qualquer
modelo de processo
Cascata
Espiral
Iterativo/Incremental, etc.

Fernando Pedrosa Lopes 32

Fernando Pedrosa Lopes 33
(TRE/MT - CESPE 2010 - adaptada)
[41] A metodologia de prototipagem evolutiva uma abordagem
que visualiza o desenvolvimento de concepes do sistema
conforme o andamento do projeto, por meio de prottipos visuais.

(UNIPAMPA CESPE 2009)

[73] No modelo de desenvolvimento prototipagem, um prottipo
desenvolvido para ajudar no entendimento dos requisitos do
sistema.

(TJDFT CESPE 2008)

[70] O modelo de desenvolvimento por prototipao caracterizado
pela ausncia de mtricas de controle, dada a natureza
experimental do desenvolvimento e do produto obtido.

Fernando Pedrosa Lopes 34

 Modelo baseado em tcnicas
matemticas para especificar,
desenvolver e verificar software
O software especificado usando
tcnicas formais (matemticas), e aps
a prova da especificao
transformado em cdigo
esp. 1 esp. 2 implement.

Fernando Pedrosa Lopes 35

 O prprio processo de
desenvolvimento garante que o
programa faz exatamente o que foi
especificado
possvel gerar programas corretos e
completos por construo
Tm sido aplicados apenas ao
desenvolvimento de sistemas crticos
(por questes de segurana!)

Fernando Pedrosa Lopes 36

(SERPRO CESPE 2008)
[65] Para a especificao de software e verificao de sistemas, uma
alternativa que se fundamenta na matemtica discreta e na lgica
o modelo incremental.

Fernando Pedrosa Lopes 37

 Motivao: requisitos de sistema
sempre evoluem durante o projeto
Deve-se dividir para conquistar
Duas abordagens
Desenvolvimento Incremental
Desenvolvimento Espiral

Fernando Pedrosa Lopes 38

Desenvolvimento Incremental
A idia de desenvolver e entregar o
software em incrementos, com cada
incremento entregando parte da
funcionalidade requerida
Requisitos so definidos antes do
desenvolvimento do incremento,
sendo os mais crticos priorizados

Fernando Pedrosa Lopes 39

Desenvolvimento Incremental
Um mini projeto em cascata executado
em cada iterao, progredindo at a
entrega final do produto

Fernando Pedrosa Lopes 40

 Incremental: so adicionados pedaos completos

Iterativo: esboos ou pedaos incompletos do

produto so adicionados a cada iterao

Fernando Pedrosa Lopes 41

Desenvolvimento Incremental
Vantagens
O cliente pode receber e avaliar as
entregas do produto mais cedo
Os incrementos so avaliados e os desvios
identificados, sendo possvel replanejar as
prximas iteraes de acordo
O risco geral do projeto fracassar diminui

Fernando Pedrosa Lopes 42

 Perfil do projeto
Tradicional
Perfil do projeto
Iterativo
Desenvolvimento
(% codificado)
Progresso de

Falha tardia
de projeto

Data (deadline) de
entrega original

Cronograma do Projeto

Fernando Pedrosa Lopes 43

Desenvolvimento em Espiral
O processo representado como uma
espiral em vez de uma seqncia de
atividades
Cada volta na espiral representa uma
fase no processo
No h fases fixas, como Especificao,
Projeto, etc.
Os loops na espiral so escolhidos
dependendo do que for necessrio

Fernando Pedrosa Lopes 44

Desenvolvimento em Espiral
Acrescenta aspectos gerenciais ao
desenvolvimento de software
Planejamento, tomada de deciso
Anlise de Riscos

Porm, complexo e requer experincia

na avaliao de riscos!

Fernando Pedrosa Lopes 45

Desenvolvimento em Espiral [Boehm]

Fernando Pedrosa Lopes 46

Desenvolvimento em Espiral [Pressman]
Planejamento
Anlise de risco
Comunicao

Eixo de
ponto de
entrada Engenharia

Avaliao
do cliente Construo
e release
Projeto de manuteno
Projeto de melhoria
Projeto de desenvolvimento de produto
Projeto de desenvolvimento de conceito

Fernando Pedrosa Lopes 47

(TST - CESPE 2008)
[94] O modelo de desenvolvimento em espiral permite repensar o
planejamento diversas vezes durante o desenrolar do projeto.

(SERPRO CESPE 2008)

[64] O modelo iterativo e o modelo em espiral possuem
caractersticas semelhantes: ambos permitem que as atividades do
processo sejam planejadas e avaliadas ao longo do ciclo de vida.

(IJSN CESPE 2010)

[56] Uma vantagem do ciclo de desenvolvimento iterativo em
relao ao ciclo clssico est na receptividade s mudanas
inerentes ao desenvolvimento de software.

Fernando Pedrosa Lopes 48

(SAD/PE - CESPE 2010 - adaptada)
[58] Imediatamente aps ter testado um prottipo evolucionrio, um
dos colegas da empresa iniciou a produo de uma lista de riscos
aos quais o projeto est sujeito. Dessa forma, a empresa no utiliza
um modelo de ciclo de vida embasado no espiral.

(SERPRO - CESPE 2010)

[69] O modelo espiral do ciclo de vida de software iterativo e
incremental, uma vez que a mesma sequncia de atividades
relacionadas produo de software realizada a cada ciclo da
espiral.

Fernando Pedrosa Lopes 49

Fernando Pedrosa Lopes 50
 Beck, Kent. Extreme Programming
Explained Embrace Change. Editora:
Addison-Wesley.
Schwaber, Ken. Scrum Guide.
Disponvel em: www.scrum.org

Fernando Pedrosa Lopes 2

 Motivao: insatisfao com os
excessos dos mtodos tradicionais,
considerados pesados
Mtodos geis buscam flexibilizar o
desenvolvimento de software
Focam no cdigo, e no no projeto
So baseados em abordagens iterativas
Tm o objetivo de entregar software
funcionando o mais rpido possvel

Fernando Pedrosa Lopes 52

Estamos evidenciando maneiras melhores de desenvolver software
fazendo-o ns mesmos e ajudando outros a faz-lo. Atravs desse
trabalho, passamos a entender que:
Indivduos e interaes so mais importantes que processos e
ferramentas.
Software funcionando mais importante do que
documentao completa e detalhada.
Colaborao com o cliente mais importante do que
negociao de contratos.
Adaptao a mudanas mais importante do que seguir o
plano inicial.
Ou seja, mesmo tendo valor os itens direita, valorizamos mais os
itens esquerda.

Fernando Pedrosa Lopes 53

Errado - Metodologia gil no o caos!

Fernando Pedrosa Lopes 54

 Mtodos geis, hoje, so considerados
uma famlia
eXtreme Programming
Scrum
FDD
Lean Software Development
Crystal Family
(...)

Fernando Pedrosa Lopes 55

Surgimento
Em meados de 1990, Kent Beck,
procurou formas mais simples e
eficientes de desenvolver Software.
Em Maro de 1996, ele iniciou um
projeto com novos conceitos que
resultaram na metodologia XP -
eXtreme Programming

Fernando Pedrosa Lopes 56

Trata-se de uma metodologia gil para
equipes pequenas e mdias desenvolvendo
software com requisitos vagos e em
constante mudana Kent Beck

Fernando Pedrosa Lopes 57

 Levar todas as boas prticas ao extremo
Se revisar cdigo bom, vamos revis-lo toda
hora (pair programming)
Se testar bom, vamos testar toda hora (testes
funcionais)
Se projetar bom, vamos fazer disso parte do
trabalho dirio de cada pessoa (refactoring)
Se integrar bom, vamos integrar a maior
quantidade de vezes possvel (integrao
contnua)
Se simplicidade bom, vamos deixar o sistema
na forma mais simples possvel (projeto simples)

Fernando Pedrosa Lopes 58

 Metfora
Uma histria que todos programadores, clientes
e gerentes podem contar acerca de como
funciona o sistema
Facilita a comunicao entre os interessados
Projeto simples
O cdigo est, a qualquer momento, na forma
mais simples que passe todos os testes
Pequenas verses
As entregas so feitas atravs de pequenos
releases (pedaos) de software funcionando
D confiana ao cliente sobre o progresso geral

Fernando Pedrosa Lopes 59

 Refatorao
O cdigo deve ser constantemente melhorado,
tornando-o mais simples e mais genrico,
removendo redundncias e duplicidades
Programao em pares
Os programadores trabalham em pares, checando
(validando) mutuamente o trabalho feito
Mesma mquina, mesmo mouse, mesmo monitor
Propriedade coletiva do cdigo
Todos so responsveis por todo o cdigo e
qualquer pessoa est autorizada a realizar
mudanas nele

Fernando Pedrosa Lopes 60

 Padro de codificao
Todo cdigo desenvolvido de acordo com um
estilo e formato consistentes (padro)
Ritmo sustentvel
Cada programador trabalha 40 horas por semana,
no mximo
Reunies em p
Reunies rpidas e dirias com a equipe, para
discutir apenas o essencial
Cliente sempre presente
O cliente, com conhecimento sobre o negcio, deve
estar disponvel em tempo integral para a equipe

Fernando Pedrosa Lopes 61

 Desenvolvimento Orientado a Testes
Uma estrutura de testes unitrios automatizada
criada e os testes so escritos antes mesmo das
funcionalidades serem implementadas
Integrao Contnua
Os diversos mdulos do software so integrados o
mais cedo possvel, para evitar problemas de
integrao no futuro
Planejamento Incremental
Requisitos so registrados como Estrias dos
Usurios e priorizados para serem includos em
uma determinada iterao

Fernando Pedrosa Lopes 62

 Comunicao
Mtodos para rapidamente construir e disseminar
conhecimento
Simplicidade
XP encoraja que voc comece, sempre, pela
soluo mais simples que funcione
Feedback
Do cliente, do sistema e da equipe
Coragem
Design simples, refatorao
Respeito
Respeito da Equipe, do Cliente, dos Usurios

Fernando Pedrosa Lopes 63

(TRE/BA - CESPE 2010)
[109] Em XP, a prtica denominada programao em pares (pair
programming) realizada por um desenvolvedor em dois
computadores, com o objetivo de aumentar a produtividade.

(SERPRO CESPE 2010)

[70] Metodologias geis como a XP enfatizam a documentao de
software no prprio cdigo, que deve ser escrito por meio de
ferramentas CASE voltadas ao desenvolvimento rpido de aplicaes

(ANAC - CESPE 2009)

[115] A tcnica conhecida como refactoring constantemente
aplicada no desenvolvimento baseado no mtodo gil
extreme programming.

Fernando Pedrosa Lopes 64

(ANAC CESPE 2009)
[116] No modelo extreme programming, os testes de software s
so realizados na etapa, final de desenvolvimento do
software e, somente nessa etapa, os programadores
trabalham, obrigatoriamente, em pares, utilizando cada um
o prprio computador.

Fernando Pedrosa Lopes 65

(BNDES CESGRANRIO 2009)
[47] Determinado projeto de software utiliza XP (eXtreme
Programming) como metodologia de desenvolvimento. A esse
respeito, INCORRETO afirmar que

a) o cliente participa ativamente e acompanha os passos dos

desenvolvedores diariamente.
b) os integrantes da equipe se renem rapidamente no incio do
dia, de preferncia em p.
c) a equipe de desenvolvimento concentra esforos naquilo que
gera maior valor para o cliente.
d) a programao em pares dispensa o desenvolvimento orientado
a testes no projeto.
e) as funcionalidades do software so descritas em histrias, da
forma mais simples possvel

Fernando Pedrosa Lopes 66

 O nome derivado de uma atividade que
acontece em um jogo de Rugby
um framework de processo dentro do
qual podem ser empregados processos e
tcnicas variadas
possvel adicionar papeis, artefatos, atividades
e cerimnias de acordo com a sua necessidade
Scrum pode ser aplicado em qualquer
contexto no qual um grupo de pessoas
trabalhe junto para atingir algum objetivo

Fernando Pedrosa Lopes 67

 As equipes se auto-organizam para
maximizar a comunicao e diminuir a
superviso
O produto evolui em uma srie de sprints
Os requisitos (funcionalidades dos clientes)
so listados em um product backlog
No h prtica de engenharia prescrita
(Scrum se adapta a todas elas)
Scrum um processo essencialmente
gerencial

Fernando Pedrosa Lopes 68

 O que voc fez ontem?
O que voc far hoje?
Reunies H algum obstculo no seu caminho?
Dirias
(Daily
Scrums)

Product 24 horas
Backlog Incremento
do produto
Sprint
Backlog 2-4 Semanas

Fernando Pedrosa Lopes 69

Product Backlog
Uma lista ordenada de tudo o que
necessrio no produto
Idealmente, cada item deve ter seu
peso (prioridade) de acordo com a
vontade do cliente
replanejado (repriorizado) no incio
de cada Sprint

Fernando Pedrosa Lopes 70

Sprint Backlog
Uma lista de tarefas que a equipe se
compromete a completar dentro de uma
determinada Sprint
Os itens so derivados a partir do
Product Backlog
So considerados
A prioridade que o cliente deu aos itens
O tempo e esforo estimados pela equipe
para completar os vrios itens

Fernando Pedrosa Lopes 71

Product Owner
Define as funcionalidades do produto

Decide as datas de lanamento e

contedo
Prioriza as funcionalidades de acordo
com o valor para a empresa
Aceita ou rejeita os resultados dos
trabalhos

Fernando Pedrosa Lopes 72

Team
Contm tipicamente entre 5 e 9 pessoas

Multi-funcional
Programadores, testadores, desenvolvedores
de interfaces, etc.
Dedicao integral
Raras Excees (ex: DBA)
Auto-organizvel (sem ttulos)
Trocas s na mudana de Sprints

Fernando Pedrosa Lopes 73

Scrum Master
Responsvel pela aplicao dos
valores e prticas Scrum
Remove obstculos, facilita resultados

Garante a plena funcionalidade e

produtividade da equipe
Escudo para interferncia externas

Fernando Pedrosa Lopes 74

Scrum Master
Obstculos a serem removidos
O meu ___ quebrou e eu preciso de um novo
Eu preciso para debugar um problema no ___
Eu preciso de ajuda para aprender ___
O cliente ___ no teve tempo de se reunir
conosco no planejamento e por isto estou
parado
O presidente da empresa pediu para eu resolver
um problema para ele em outro projeto, por um
dia ou dois

Fernando Pedrosa Lopes 75

 Planejamento da Sprint
Selecionam-se itens do Product Backlog, e as
tarefas so identificadas e estimadas
De forma colaborativa, no apenas feito pelo
Scrum Master
Reunies Dirias (Daily Scrums)
Apenas os membros da equipe, todos os dias,
em p, durante 15 minutos
Reviso do Sprint
Apresentao dos resultados obtidos
Todo o time participa, informalmente, 2
horas de preparao, no mximo, sem slides

Fernando Pedrosa Lopes 76

 Retrospectiva da Sprint
Ocorre aps a reviso da sprint e antes da
prxima reunio de planejamento
Inspeciona como foi a ltima Sprint em
termos de:
Pessoas e Relaes
Processos e Ferramentas
Enquanto a reviso da sprint analisa o
produto, a retrospectiva analisa o
processo

Fernando Pedrosa Lopes 77

(BASA - CESPE 2010)
[78] O Scrum utilizado, como funo primria, para o
gerenciamento de projetos de desenvolvimento de software,
mas tambm tem sido usado como extreme programming e outras
metodologias de desenvolvimento. Teoricamente, o Scrum pode ser
aplicado em qualquer contexto no qual um grupo de pessoas
necessite trabalhar juntas para atingir um objetivo comum.

(SERPRO - CESPE 2010)

[54] Para que o plano do projeto de um processo seja efetivo, uma
das premissas que o product backlog esteja completo.

Fernando Pedrosa Lopes 78

(TRE/BA - CESPE 2010)
[68] Um princpio chave do Scrum o reconhecimento de que
desafios fundamentalmente empricos no podem ser resolvidos
com sucesso utilizando-se uma abordagem tradicional de controle.
O Scrum adota uma abordagem emprica, aceitando que o problema
no pode ser totalmente entendido ou definido, focando na
maximizao da habilidade da equipe de responder de forma gil
aos desafios emergentes.

[101] A metodologia Scrum facilitada por um scrum master, que

atua como um mediador entre a equipe e qualquer influncia
desestabilizadora, alm de assegurar que a equipe esteja
utilizando corretamente as prticas de Scrum, motivando e
mantendo o foco na meta da sprint.

Fernando Pedrosa Lopes 79

 Incio: Jeff de Luca e Peter Coad em 1997
projeto para um banco de Singapura
A FDD focada na entrega regular de
funcionalidades valiosas para o cliente
Tem mais estrutura do que o XP
As equipes podem variar de 10 a 250
programadores (aproximadamente)
Porm mais enxuto do que o RUP
No necessita de tanta documentao, nem
to detalhado

Fernando Pedrosa Lopes 80

Papis
Project Manager
O lder administrativo do projeto
Planeja oramento, elabora relatrios e
protege a equipe de distraes externas
Chief Architect
Responsvel pelo projeto geral do sistema
Tem a palavra tcnica final sobre o
software e sua arquitetura

Fernando Pedrosa Lopes 81

Papis
Development Manager
Lidera as atividades dirias de
desenvolvimento
Lidera a equipe de desenvolvimento
atravs de desafios tcnicos
Chief Programmers
Desenvolvedores experientes
Lideram pequenas equipes de
desenvolvedores individuais

Fernando Pedrosa Lopes 82

Papis
Class Owners
So os desenvolvedores individuais
Projetam, codificam, testam e documentam
as funcionalidades
Domain Experts
Usurios, clientes, patrocinadores, etc.
A base de conhecimento para os
desenvolvedores

Fernando Pedrosa Lopes 83

 Funcionalidades
Entendimento Quem implementar
que podem ser
do domnio e a funcionalidade?
implementadas
estabelecimento Qual a sequncia
em at 2 semanas
do escopo de implementao?

Projeto e Codificao (tarefas

de engenharia)
Fernando Pedrosa Lopes 84
(DPE/SP - FCC 2010)
[64] Na engenharia de software, um processo iterativo denominado
sprint, que segue o ciclo PDCA para entregar, num perodo de 30
dias aproximadamente, um incremento do software pronto,
caracteriza a metodologia gil

(A) SCRUM.
(B) DSDM.
(C) Crystal.
(D) FDD.
(E) XP.

Fernando Pedrosa Lopes 85

(TRF4 - FCC 2010)
[61] A Feature Driven Development (FDD) uma metodologia gil de
desenvolvimento de software, sobre a qual correto afirmar:

a) No pode ser combinada a outras tcnicas para a produo de

sistemas.
b) Possui cinco processos: Desenvolver um Modelo Abrangente,
Construir a Lista de Funcionalidades, Planejar por Funcionalidade,
Detalhar por Funcionalidade e Implementar por Funcionalidade.
c) Divide os papis em dois grupos: papis chave e papis de apoio.
Dentro de cada categoria, os papis so atribudos a um nico
participante que assume a responsabilidade pelo papel.
d) Mantm seu foco apenas na fase de modelagem.
e) Mantm seu foco apenas na fase de implementao.

Fernando Pedrosa Lopes 86

(TJ/PE - FCC 2007)
[36] Considere:
I. Desenvolvimento de um modelo geral.
II. Construo da lista de funcionalidades.
III. Plano de liberaes com base nas funcionalidades a implementar.
IV. Projetar com base nas funcionalidades.
V. Implementar com base nas funcionalidades.

So fases de projetos que seguem o processo projetado por Peter

Coad, Erich Lefebvre e Jeff De Luca chamado de

(A) MDA
(B) XP
(C) FDD
(D) RUP
(E) MVC

Fernando Pedrosa Lopes 87

Fernando Pedrosa Lopes 88
 Antes da dcada de 90 casa de
ferreiro, espeto de pau
Hoje em dia as ferramentas CASE
ainda no so to variadas nem
fornecem tudo aquilo que os
desenvolvedores queriam, mas so
um aparato essencial para o
engenheiro de software

Fernando Pedrosa Lopes 89

 O que so?
So ferramentas que auxiliam o
engenheiro de SW em cada atividade
associada ao desenvolvimento de SW
Quem usa?
Gerentes de projeto e engenheiros de SW
Por que so importantes?
Reduzem o esforo necessrio para
produzir artefatos e alcanar metas
Aumentam a qualidade do software

Fernando Pedrosa Lopes 90

 Quais so os passos?
Ferramentas CASE so usadas em
conjunto com o modelo de processo
adotado. Se for escolhida uma ferramenta
completa, pode passar por quase todos os
passos do desenvolvimento de SW

Fernando Pedrosa Lopes 91

 Como so usadas?
Como complemento s boas prticas de
Engenharia de Software. Ferramentas
CASE no substituem uma metodologia de
desenvolvimento de software slida

Um tolo com ferramentas, ainda apenas

um tolo

Fernando Pedrosa Lopes 92

 Horizontais
So utilizados durante todo o processo de
desenvolvimento de software
Verticais
So especficas para uma disciplina de software
Por funes [Pressman]
Processos de negcio, Planejamento de
projeto, Anlise de Riscos, Rastreamento
de Requisitos, IDEs, Gerenciamento de
BDs, Anlise Esttica, Anlise Dinmica, ...

Fernando Pedrosa Lopes 93

 Como no h um padro para categorizar
ferramentas CASE, a seguinte proposta foi
feita:
Front-end ou Upper CASE
apiam as etapas iniciais da criao dos
sistemas: as fases de planejamento, anlise e
projeto da aplicao
Back-end ou Lower CASE
do apoio parte fsica, i.e, cdigo, testes e
manuteno
I-CASE ou Integrated CASE
cobrem todo o ciclo de vida, do incio ao fim

Fernando Pedrosa Lopes 94

(TRT5 - CESPE 2009)
[76] As ferramentas CASE podem ser verticais ou horizontais. As
primeiras oferecem servios utilizados durante todo o processo de
software, enquanto as segundas so utilizadas em fases especficas
do processo de software.
(TJ/CE - CESPE 2008)
[53] Uma ferramenta CASE pode ser utilizada durante todo o projeto
de um software ou apenas em fases especficas do projeto.
(MDS - CESPE 2009)
[118] Uma ferramenta CASE (computer-aided software/system
engineering) integrada, tambm chamada de I-CASE,permite a
transferncia de informao, como modelos, programas e
documentos, de uma ferramenta para outra. Entretanto, uma I-CASE
no permite a mudana de um estgio do processo de engenharia
de software para outro.

Fernando Pedrosa Lopes 95

 [0] 61 C, 12 E
[1] 93 E, 63 C, 85 E, 86 C, 58 C
[2] 41 C, 73 C, 70 E
[3] 65 E
[4] 94 C, 64 C, 56 C, 58 E, 69 E
[5] 109 E, 70 E, 115 C, 116 E, 47 D
[6] 78 C, 54 E, 68 C, 101 C
[7] 64 A, 61 B, 36 C
[8] 76 E, 53 C, 118 E

Fernando Pedrosa Lopes 96

Fernando Pedrosa Lopes 97