O documento discute as dificuldades do desenvolvimento de software e as metodologias tradicionais e ágeis. Apresenta o contexto do desenvolvimento caótico de software e a necessidade de melhoria dos processos, introduzindo metodologias como waterfall e orientadas a objetos. Também discute a emergência das metodologias ágeis e seus princípios de valorizar indivíduos, software funcionando e resposta à mudança.
1. CESAR - GAP
DESENVOLVIMENTO DIRIGIDO
A FUNCIONALIDADES
"A FDD disciplina as equipes a pensarem um pouco antes
de sair fazendo e a fazer aos poucos enquanto
continuam aprendendo, demonstrando claramente o que
vão fazer e o que estão fazendo."
• Engº Jorge Luis Bublitz
sexta-feira, 22 de abril de 2011
2. Agenda
• Contexto
• Metodologias
• Agilidade e Metodologias Ágeis
• Mudanças
• FDD
sexta-feira, 22 de abril de 2011
4. O que é Desenvolvimento de
Software?
“É o ato de elaborar e implementar um
sistema computacional, isto é,
transformar a necessidade de um
utilizador ou de um mercado em um
produto de software.”
Nick Birrell
A Practical Handbook for Software
Development, 1985
sexta-feira, 22 de abril de 2011
5. Características
• Caótica
• Eterno ciclo “programar e depurar”
• Sem planejamento claramente definido
• Dificuldade em adicionar novos
recursos (funcionalidades)
• Fase de testes e depuração na
produção
• Estimativa de Tempo/Custo difícil de
ser determinada
sexta-feira, 22 de abril de 2011
6. The Caos Report - 1995
Concluídos com Sucesso
16%
Falharam
31%
Concluídos com Alterações
53%
Standish Group – www.standishgroup.com
sexta-feira, 22 de abril de 2011
7. The Caos Report - 2001
Falharam
Concluídos com Sucesso
23%
28%
Concluídos com Alterações
49%
Standish Group – www.standishgroup.com
sexta-feira, 22 de abril de 2011
8. The Caos Report - 2009
Falharam
24% Concluídos com Sucesso
32%
Concluídos com Alterações
44%
Standish Group – www.standishgroup.com
sexta-feira, 22 de abril de 2011
9. Vamos Analisar
Sucesso Alterações Falharam
25,00 50,00 75,00 100,00
1994
1996
1998
2000
2002
2004
2006
2009
Standish Group – www.standishgroup.com
sexta-feira, 22 de abril de 2011
10. Funcionalidades/Funções
Utilizadas em um Sistema
Sempre
7%
Muito
13%
Nunca
45% Algumas Vezes
16%
Raramente
19%
Standish Group – www.standishgroup.com
sexta-feira, 22 de abril de 2011
11. Culpado(s)???
Clientes
Desenvolvedores
Analistas
Ferramentas
Processo
sexta-feira, 22 de abril de 2011
12. A Solução é...
• Não existe uma solução mágica e única,
mas sim um conjunto de práticas
reconhecidamente eficientes.
• Desenvolvimento Incremental,
Refinamento de Requisitos, BONS
PROJETISTAS...
sexta-feira, 22 de abril de 2011
13. A Solução é...
• Melhorar a qualidade do software implica
na melhoria do processo pelo qual o
mesmo é produzido.
• Assumir práticas de sucesso
• Garantir que estas práticas serão
seguidas durante o desenvolvimento
• Ser fácil de seguir
• Evoluir com o aprendizado do grupo
sexta-feira, 22 de abril de 2011
14. A Solução utilizada até hoje:
• Adoção de Metodologias
• Objetivo: tornar o desenvolvimento
mais previsível e mais eficiente
• Impõe disciplinas rígidas
• Processos detalhados
• Planejamento é a ênfase
• Passam a impressão de serem uma
PANACÉIA
sexta-feira, 22 de abril de 2011
16. Modelo Tradicional
Levantamento
de Requisitos
Projeto
Implementação
Testes
Implantação
sexta-feira, 22 de abril de 2011
17. Modelo Tradicional
• Também chamado de Modelo em Cascata
(Waterfall)
• Proposto por Winston W. Royce - 1970!!!
• Orientado para documentação
• Ênfase em planejamento, horários, prazos,
orçamentos e implementação de sistemas
inteiros
• Há variantes: Incremental,
Evolucionário, ...
sexta-feira, 22 de abril de 2011
18. Novos Tempos (??)
Menor
Tempo
Maior Menor
Qualidade Custo
sexta-feira, 22 de abril de 2011
19. Novos Problemas (?)
Escopo
Qualidade Prazo
Custo
sexta-feira, 22 de abril de 2011
21. Análise Orientada por Objetos
• É um método de análise que
examina os requisitos a partir da
perspectiva das classes e objetos
encontrados no vocabulário do
domínio do problema
• Enfatiza a construção de modelos do
mundo real usando uma visão de
mundo orientada por objetos
sexta-feira, 22 de abril de 2011
22. Métodos Orientados a Objetos
Em meados dos anos 70 e início dos anos 80
(1989 a 1994) vários métodos de
modelagem orientada a objetos surgiram,
sendo que os principais foram:
• Booch (Grady Booch)
• OMT (Rumbaugh)
• OOSE (Jacobson)
• Shlaer/Mellor (Sally Shlaer e Stephen
Mellor)
• Coad/Yourdon (Peter Coad e Ed
Yourdon)
sexta-feira, 22 de abril de 2011
23. Método Unificado
Neste cenário Grady Booch e James
Rumbaugh juntaram forças através da
Rational Corporation para unificar os
métodos Booch e OMT que resultou
na versão 0.8 do Método Unificado,
lançado em outubro de 1995.
Grady Booch James Rumbaugh .
sexta-feira, 22 de abril de 2011
24. UML
• No final de 1995, Ivar Jacobson juntou-se a
equipe fundindo o método OOSE (Object-
Oriented Software Engineering)
• Booch, Rumbaugh e Jacobson estavam motivados
a criar uma linguagem unificada para modelar
sistemas complexos de qualquer tipo:
• missão crítica
• tempo real
• cliente/servidor
• Após o apoio de parceiros importantes
como Microsoft, Hewlett-Packard,
Oracle, IBM, dentre outras em janeiro
de 1997 foi lançado a UML 1.0
(Unified Modeling Language)
sexta-feira, 22 de abril de 2011
32. A Decepção
• Análise Essencial dizia O QUE fazer e
QUANDO
• Quando surge a UML, o mercado queria
uma um substituto para a Análise Essencial
• UML é uma Linguagem e não um
Processo
• Ela fornece os elementos, mas não define
QUANDO usar
• O mercado rejeitou a UML por não
compreendê-la
sexta-feira, 22 de abril de 2011
33. Agilidade e
Metodologias Ágeis
sexta-feira, 22 de abril de 2011
34. Agilidade
• a.gi.li.da.de sf (lat agilitate)
1. Qualidade do que é ágil
2. Desembaraço, ligeireza, presteza
de movimentos
3. Mobilidade, perspicácia, vivacidade
• Geralmente associa-se
AGILIDADE com Rapidez,
Flexibilidade, Leveza
sexta-feira, 22 de abril de 2011
35. Agilidade - Software
“Agilidade é a habilidade para criar e
responder às mudanças, para lucrar
num ambiente turbulento de
negócios, para equilibrar flexibilidade
e estabilidade.”
Jim Highsmith
Agile Software Development Ecosystems
2002
sexta-feira, 22 de abril de 2011
36. Metodologias Ágeis
• Antes chamadas de “Metodologias Leves”
• Tornou-se popular no ano de 2001
• 17 grandes pensadores em processo de desenvolvimento de
software
• Se encontraram para que cada um explicasse a maneira
como desenvolviam projetos de software
• E como trabalhavam para que a equipe respondesse
rapidamente às mudanças
• A partir deste encontro foi criada a
“Aliança Ágil”
• Estabelecimento dos valores do
“Manifesto Ágil”
sexta-feira, 22 de abril de 2011
37. Manifesto para o
Desenvolvimento Ágil de Software
Estamos descobrindo melhores maneiras de desenvolver
software, fazendo-o e ajudando outros a fazê-lo.
Através deste trabalho passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas.
Software que funciona mais que documentação detalhada.
Colaboração do cliente mais que negociações contratuais.
Responder às mudanças mais que seguir um plano.
Isto é, embora haja valor nos itens do lado direito, nós
valorizamos mais os do lado esquerdo.
www.agilemanifesto.org
sexta-feira, 22 de abril de 2011
38. Princípios Ágeis
• Satisfação do Cliente
• Responder às Mudanças
• Entrega Freqüente
• Motivação
• Software que Funciona
• Ritmo Constante
• Simplicidade
sexta-feira, 22 de abril de 2011
39. Cuidado com o Manifesto
Radical
O Manifesto Ágil não pode ser interpretado como
indicando que ferramentas, processo, documentos,
contratos ou planos são desprezíveis.
• Ferramentas são críticas para acelerar o
desenvolvimento e reduzir custos
• Contratos são vitais para iniciar as relações
desenvolvedor-cliente
• Documentação auxilia a comunicação
• Entretanto, os itens à esquerda são os mais
cruciais
• Sem indivíduos hábeis, software funcionando,
interações fortes com clientes e rapidez de
resposta às mudanças, a entrega do produto será
quase impossível
sexta-feira, 22 de abril de 2011
40. O Sucesso das Metodologias
Ágeis
Já é um movimento de grande sucesso
• Centenas (milhares?) de instituições
já usam
• Milhares de projetos já foram
completados
• Opinião geral dos que tentaram é
positiva
• Alguns estudos científicos começam
a aparecer
sexta-feira, 22 de abril de 2011
41. Quem Adotou ou Está
Adotando?
sexta-feira, 22 de abril de 2011
42. Mas...
• Proporcionalmente, as metodologias
tradicionais ainda dominam
• Metodologias Ágeis exigem
mudança cultural, o que não é nada
fácil
• Metodologias Ágeis foram criadas
por especialistas em
Desenvolvimento de Software
• Em geral o poder de decisão não está
nas mãos desses especialistas
sexta-feira, 22 de abril de 2011
43. Maiores Dificuldades
• Apoio das instâncias superiores
• Gerenciamento de equipes
• Problemas técnicos
• Interação com outros departamentos
• Interação com clientes
sexta-feira, 22 de abril de 2011
44. Pessoas
Representam uma grande fonte de
problemas
sexta-feira, 22 de abril de 2011
45. Gerentes Tradicionais
• Não é assim que eu sempre fiz
• Medo de perder o controle
• O chão desabou, como agir?
• E a minha autoridade?
sexta-feira, 22 de abril de 2011
46. Arquitetos
• Peões que não sabem de nada vão
mexer na minha arquitetura?
• Não quero olhar para código, isso é
coisa para programadores...
• E a minha autoridade?
sexta-feira, 22 de abril de 2011
47. Programadores
• Quebra da rotina
• Sempre fiz assim, por que
tenho que fazer diferente
agora?
• Especificação incompleta,
testes, código limpo?
• Isso não é tudo
desperdício?
• Não quero a
responsabilidade
sexta-feira, 22 de abril de 2011
48. Testadores
• Estão tirando o meu emprego?
• Vou ter que aprender a programar?
sexta-feira, 22 de abril de 2011
49. DBAs
• Onde está a especificação completa?
• Se vocês não sabem ainda o que
querem, não venham me pedir para
implementar agora coisas que vou
ter que mudar depois.
• Eu é quem modelo o Banco, vocês
apenas escrevem o código.
• Nós sempre fizemos assim e sempre
deu certo, por que mudar agora?
sexta-feira, 22 de abril de 2011
50. Clientes
• Onde estão as minhas
garantias?
• Qual é o preço final?
• Se eu pagar tudo, quero
todas as funcionalidades!
• Estou pagando para você
fazer o trabalho, por que eu
devo estar presente? Você
quer que eu faça o seu
trabalho?
sexta-feira, 22 de abril de 2011
51. Coach novato
• Eu li o livro ____
• mas não sei ainda como
começar
• Eu li o livro ____
• mas fiz tudo e não deu certo
• Eu li bastante o livro ____,
pratiquei escondido, sei como
fazer
• mas não consigo convencer o
meu gerente a experimentar.
sexta-feira, 22 de abril de 2011
52. Métodos Pseudo-Ágeis
• Métodos Ágeis é muito bom, sou a favor
• mas vamos incluir estes 113 formulários e 184
procedimentos para tornar o resultado de melhor
qualidade
• Métodos Ágeis é muito bom, sou a favor
• mas vamos usar essa ferramenta que compramos
para controlar todos os passos do desenvolvimento
para atingirmos a qualidade total
• Métodos Ágeis é muito bom, sou a favor
• mas precisamos fazer uma coleta de requisitos
detalhada e um planejamento completo antes de
começar a implementar, caso contrário vamos
fazer besteira.
sexta-feira, 22 de abril de 2011
53. Métodos Pseudo-Ágeis
• Métodos Ágeis é muito bom, sou a favor
• mas nós é quem vamos implementar o sistema,
então vamos explicar ao cliente quais são as
funcionalidades mais importantes.
• Métodos Ágeis é muito bom, sou a favor
• mas como nós estamos pagando, vamos definir
as ferramentas e as tecnologias que os
programadores irão utilizar para que eles não
façam bobagem.
• Métodos Ágeis é muito bom, sou a favor
• mas infelizmente, não podemos nos dar ao luxo
de escrever testes para tudo, isso é radicalismo.
sexta-feira, 22 de abril de 2011
54. Métodos Pseudo-Ágeis
Levantamento
de Requisitos
XP, Scrum, ...
Projeto
Implementação
Testes
Implantação
Implantação
com Testes
sexta-feira, 22 de abril de 2011
55. Mitos sobre as
Metodologias Ágeis
sexta-feira, 22 de abril de 2011
56. Programação Radical
“Extreme Programming (XP) é um processo de
desenvolvimento que possibilita a criação de
software de alta qualidade, de maneira ágil,
econômica e flexível.“ - Vinícius M. Teles
• Valores: ■ Princípios:
• Comunicação ■ Feedback rápido
• Simplicidade ■ Presumir simplicidade
• Feedback ■ Mudanças
incrementais
• Coragem ■ Abraçar mudanças
■ Trabalho de Qualidade
sexta-feira, 22 de abril de 2011
57. Principal Mito
• Agilidade = XP
• É apenas um processo ágil, centrado no
desenvolvedor
• Fatos:
• Há vários outros processos e metodologias,
como FDD, Scrum, Lean, Crystal, MSF for
Agile, ASD, DSDM, RAD, etc.
• Agilidade é mais habilidade e atitude do
que a adoção de um processo
• O Projeto C3, que deu origem à XP foi
cancelado!
sexta-feira, 22 de abril de 2011
58. Consequência #1
Documentação não é necessária!
• Fatos:
• Empresas passam por auditorias (Fiscal, SOX, ISO)
• Processos definidos precisam de um nível razoável
de documentação (CMMI, MPS.BR...)
• A documentação deve ser apropriada para o
propósito em questão (quantidade, qualidade,
profundidade, abrangência, etc.)
• Há vários níveis de interesses e necessidades na
organização, cada um com seu tipo e grau de A
documentação deve ser apropriada para o propósito
em questão (quantidade, qualidade, profundidade,
abrangência, etc.)
• Há vários níveis de interesses e necessidades na
organização, cada um com seu tipo e grau de
“documentabilidade”
sexta-feira, 22 de abril de 2011
59. Consequência #2
Modelagem?? Nem pensar!
• Fatos:
• Scott Ambler demonstrou o valor da Modelagem Ágil
• Metodologias ágeis, como a FDD, utilizam a
modelagem como vantagem e não como carga inútil
• “Uma imagem vale mais do que mil palavras” (ou,
talvez, linhas de código?)
• A geração automática de código, proporcionada por
várias ferramentas (Borland Together, ECO e
outros), é um fator para aumento de produtividade,
padronização e diminuição de defeitos
• A capacidade de entender, memorizar e comunicar é
muito maior com imagens do que com textos
apenas (alguém aí é da época dos terminais verdes,
CP/M, MS-DOS...?)
sexta-feira, 22 de abril de 2011
60. Consequência #3
Ferramentas?? Não, obrigado! Talvez as gratuitas...
• Fatos:
• Ferramentas adequadas aumentam a produtividade
• A automação ajuda a padronizar e reforçar o processo,
facilitando a adoção e institucionalização
• O problema não é tanto a ferramenta, mas principalmente
os hábitos:
sexta-feira, 22 de abril de 2011
61. Consequência #4
Os testes são os requisitos, por isso os
requisitos são desnecessários!
• Fatos:
• Existem vários tipos de requisitos: de negócio, de
usuário, funcionais, não-funcionais, infra-
estrutura, ...
• Existem vários tipos de testes: unitários, de
integração, de usabilidade, de regressão, de carga,
de stress, etc.
• Os testes são derivados dos requisitos, geralmente
os de usuário (cenários de casos de uso) e funcionais
• Há uma relação N-N entre testes e requisitos
• A rastreabilidade ajuda na sincronização entre eles
• Os testes manuais continuarão existindo (100% de
automação é 99% improvável)
sexta-feira, 22 de abril de 2011
62. Consequência #5
Agilidade é coisa nova, de 2000 prá cá...
• Fatos:
• Os valores, conceitos e práticas são antigos
(conhecidos e praticados a mais de 15 anos)
• Algumas metodologias e processos já
existiam antes de 2000:
• FDD (1997), mas várias práticas são anteriores a
1990
• Scrum (1993), mas as bases vêm de meados da
década de 1980
• RAD (década de 1980 e início de 1990)
• Agilidade, como conceito, faz parte da
natureza!
sexta-feira, 22 de abril de 2011
63. Richard Feynman: Agilista??
• Prêmio Nobel de Física em 1965
• QED - Eletrodinâmica Quântica
• Trabalhou no projeto Manhattan
(1942- 1946)
• Enquanto os mainframes não
chegavam, simulou algoritmos de
cálculos com papel, calculadoras
manuais e pessoas (um exército de
secretárias!)
• Foi capaz de depurar, descobrir
erros nos algoritmos e fazer
otimizações para acelerar os
cálculos!
• Quando as máquinas chegaram, foi
só codificar e rodar!
sexta-feira, 22 de abril de 2011
64. A “MÁ” Agilidade
• “Foco em datas na pior forma possível: ciclos
curtos, entregas rápidas, estimativas e re-
estimativas freqüentes”
• Esse foco agressivo na entrega fere a base geral
de código, porque as pessoas não dão a mão para
ajudar uns aos outros, e as tarefas “domésticas”
são negligenciadas
• Eles ficam exaustos por causa do ritmo invariante
e das horas anti-naturalmente regulares
• “São todos novos, com medo de falar, e nenhum
deles têm mesmo certeza se é a Agilidade que
está causando o problema”
• Esse pessoal Ágil é evasivo: “esquivando-se da
crítica ao abraçar qualquer coisa boa e repudiando
qualquer coisa má”
sexta-feira, 22 de abril de 2011
65. A “BOA” Agilidade
• A estrutura da organização contém
hierarquia, mas na prática ela parece
bastante “plana” (código dos gerentes)
• As pessoas evoluem os processos
quando necessário (em vez dos
processos oprimirem as pessoas)
• Grande disciplina é praticada com
relação à base de código
• A “folga” está embutida no sistema
sexta-feira, 22 de abril de 2011
66. A “BOA” Agilidade
• Permitir aos desenvolvedores explorar
outras idéias que os interessem
• Os incentivos são ligados ao valor de
negócio de cada projeto
• A organização facilita o foco na codificação
• Por exemplo, fornecendo boas
ferramentas e lanches gratuitos ☺
• As pessoas são tratadas com respeito
• As requisições são simplesmente
enfileiradas e priorizadas
sexta-feira, 22 de abril de 2011
67. Mudanças
Projetos e Processos
sexta-feira, 22 de abril de 2011
68. Porque mudar??
• Única constante do universo:
MUDANÇA
• Para melhorar
• Para motivar
• Para nos tornarmos mais eficientes
e eficazes
• Para nos tornarmos mais ágeis
sexta-feira, 22 de abril de 2011
69. Além disso...
• Para 88% dos 1.150 CEOs de todo
mundo ouvidos no início de 2009 pela
consultoria americana
Pricewaterhouse-Coopers a
competência mais importante para um
executivo atualmente é a
flexibilidade para se adaptar a
mudanças
• “E não basta ter facilidade para aceitar
o novo. O profissional deve ser um
provocador de mudanças e levar as
pessoas junto com ele”, José Aurélio
Drummond Jr., presidente da Whirlpool
sexta-feira, 22 de abril de 2011
70. O Processo de Mudança
sexta-feira, 22 de abril de 2011
71. Diferenças de Paradigmas
• Tradicional • Ágil
• Ser capaz de controlar / • Ser capaz de lidar com a
eliminar a incerteza incerteza
• Planejamento e controle de • Planejamento e controle de
progresso através do progresso através da
Caminho Crítico / EVA Corrente Crítica / Buffers
• Replanejar deve ser a • Replanejar deve ser a regra
exceção sempre
(há limites práticos)
• Controle rígido do escopo
do projeto
• Controle do escopo das
iterações
• Teorias básicas:
Gerenciamento Total da • Teorias básicas:
Qualidade Teoria do Caos
Controle Estatístico de Teoria das Restrições (TOC)
Processos Produção Enxuta (Lean)
sexta-feira, 22 de abril de 2011
72. Planejar X Plano
“Um plano não é nada...
Mas planejar é tudo!”
Dwight D. Eisenhower
34º Pres. EUA
(1953-1961)
sexta-feira, 22 de abril de 2011
73. Para que serve um Processo?
• O propósito de um processo de
desenvolvimento de software é:
• capacitar e reforçar a entrega repetível
de software que funciona...
• no prazo adequado e eficiente em
relação ao seu custo...
• fornecendo informação precisa e
significativa a todos os papéis principais,
dentro e fora de um projeto...
• com o mínimo de interrupção para os
desenvolvedores
Coad, De Luca (JMCU)
sexta-feira, 22 de abril de 2011
74. Características de um bom
Processo
• É bem delimitado
• Claramente define tarefas, que são focadas
nos resultados
• Produz progresso e informação de status
precisos
• Rapidamente torna-se uma questão de
hábito
• Ajuda a equipe a manter a qualidade e
administrar a complexidade
• Otimiza comunicação dentro e fora da
equipe
sexta-feira, 22 de abril de 2011
75. O Processo Ágil...
• Capacita a organização a responder
facilmente à mudança
• Entrega código funcionando ao mercado
mais rapidamente (do que com outros
métodos – atuais ou anteriores)
• Produz código funcionando de alta qualidade
• Aumenta a produtividade
• Aumenta a satisfação do cliente
• Fornece um ambiente de alta satisfação com
o trabalho para uma equipe bem motivada
sexta-feira, 22 de abril de 2011
76. Desenvolvimento
Dirigido a
Funcionalidades
sexta-feira, 22 de abril de 2011
77. Definição
• “FDD é uma metodologia iterativa e
incremental de gerenciamento e engenharia de
software, que combina as melhores práticas de
outras abordagens ágeis com técnicas
centradas no modelo, que podem escalar para
equipes e projetos maiores.
• É caracterizada por uma ênfase na qualidade
em todo o processo e um monitoramento de
progresso direto, preciso, intuitivo e acurado.
• Sua principal finalidade é a entrega tangível e
frequente de software funcional.”
Autor: Jorge L. Bublitz
Revisão: Adail Muniz
sexta-feira, 22 de abril de 2011
78. Onde nasceu a FDD
•1997-1998, Singapura
•Contexto: Desenvolvimento
de um grande sistema de
empréstimos para o United
Overseas Bank
•Anteriormente, após 2
anos de consultoria, 3.500
páginas de casos de (in)uso
e um modelo de objetos
com centenas de classes, foi
avaliado como impossível
sexta-feira, 22 de abril de 2011
79. Decisão x Resultado
• Decisão: Implantação das
metodologias de OOAD de Peter
Coad e de PM de Jeff De Luca
• Resultado: 2.000 Features
entregues por uma equipe de 50
pessoas, 15 meses após a
contratação da dupla
sexta-feira, 22 de abril de 2011
80. Os “Culpados”
Jeff De Luca Peter Coad
Stephen Palmer
John Mac Felsing
sexta-feira, 22 de abril de 2011
81. O Berço da FDD
Sede do United Overseas Bank David Anderson, o GUI-Man
Peter Coad e a Paul Szego e Jeff De Luca e os
Equipe de Modelagem Stephen Palmer Programadores
sexta-feira, 22 de abril de 2011
82. O que a FDD pode
proporcionar??
• Inovação Contínua
• Adaptabilidade do Produto
• Cronogramas Reduzidos de Entrega
• Adaptabilidade das Pessoas e
Processos
• Resultados Confiáveis
sexta-feira, 22 de abril de 2011
83. Principais
Características
sexta-feira, 22 de abril de 2011
84. Características da FDD
• Fornece a estrutura suficiente para equipes
maiores
• Enfatiza a produção de software de qualidade
• Entrega resultados freqüentes, tangíveis e
funcionais
• Realiza trabalho significativo desde o início,
antes de tornar-se altamente iterativa
• Fornece informação de estado e progresso de
forma simples e compreensível
• Agrada a clientes, gerentes e
desenvolvedores
sexta-feira, 22 de abril de 2011
85. O que é Feature?
• Característica ou funcionalidade
• Pequena o suficiente para ser implementada
no máximo em 2 semanas
• Oferece valor para o cliente
• Mapeia passos em uma atividade de negócio
• Pode ser um passo de um caso de uso,
podendo ser às vezes o próprio caso de uso
• Conceito muito próximo de requisito
funcional
sexta-feira, 22 de abril de 2011
86. MODELO
• <A><R><O>
• <Ação> <Resultado> <Objeto>
• Calcular o Total da Venda
sexta-feira, 22 de abril de 2011
87. Outros Exemplos
• Calcular o total do salário
• Autorizar a entrada fora do horário do expediente
do funcionário
• Assinar digitalmente o documento PDF
• Autorizar a transação com o cartão do cliente
• Calcular o desconto de uma venda
• Listar os clientes ativos da empresa
• Destacar os clientes devedores de uma filial
• Imprimir a nota fiscal de uma venda
• Validar a senha de um usuário
• Efetuar a matrícula do aluno no curso
sexta-feira, 22 de abril de 2011
88. Exercício
• Coloque as seguintes funcionalidades no
modelo sugerido (<a><r><o>):
• O usuário é validado antes de entrar no sistema
• Ao vender um produto, seu estoque é
atualizado
• A compra será paga com cartão de crédito
• O sistema notifica o cliente sobre o envio do
seu pedido
• A recepcionista escolhe o quarto do hóspede a
partir de uma lista de unidades disponíveis
• O médico verifica sua agenda para marcar a
próxima consulta do paciente
• Ao parir sua cria, a vaca deve ser registrada
como não estando mais prenha
sexta-feira, 22 de abril de 2011
89. Melhores Práticas da FDD
• Modelagem de Objetos do Domínio
• Desenvolvimento por Feature
• Posse individual de classe (código)
• Equipes de Features
• Inspeções
• Builds regulares
• Gerenciamento de configuração
• Relatório/visibilidade de resultados
sexta-feira, 22 de abril de 2011
90. 1) Modelagem de Objetos do
Domínio
• Diagramas de classes com os principais tipos de
objetos no domínio do problema e suas relações
• Auxilia na captura e esclarecimento dos requisitos
• Possibilita um entendimento comum e mais completo
sobre o domínio do problema
• O modelo de objetos do domínio
• É o mapa da estrada, que guiará a jornada
• Fornece uma estrutura abrangente na qual adicionar funcionalidade
• Ajuda a manter a integridade conceitual do sistema
• Reduz a quantidade de refactoring
• É uma forma de armazenamento e comunicação concisa,
relativamente acessível e reutilizável, para todos os envolvidos no
projeto
sexta-feira, 22 de abril de 2011
92. 2) Desenvolvimento por
Funcionalidade
• Pensamento sistêmico, processual,
visando o resultado final
• As features são o que o cliente realmente
usará
• Ele entende os termos, o valor e o progresso
• Ele pode priorizar pela importância para o negócio
• O teste é objetivo (funciona ou não funciona)
• É fácil de se determinar quando está pronta
• Garante a distribuição organizada de
responsabilidades através das classes/módulos
• É comum a várias abordagens de
desenvolvimento (funcional, estruturada,
orientada por objetos, etc.)
sexta-feira, 22 de abril de 2011
93. As Features Preenchem o
Modelo de Domínio
ClasseA
Área 1
Atividade 1.1
Feature 1.1.1
Feature 1.1.2 ClasseB
Atividade 1.2
Feature 1.2.1
Feature 1.2.2
ClasseC
Área 2
Atividade 2.1
Feature 2.1.1
Feature 2.1.2
Atividade 2.2
Feature 2.2.1
sexta-feira, 22 de abril de 2011
94. As Features Preenchem o
Modelo de Domínio
Objeto1 Objeto2 Objeto3 Objeto4
TelaA ClasseB ClasseC ClasseD
Usuário
1: feature1
1.1: operacaoC1
1.1.1: operacaoD1
1.2: operacaoA1
2: feature2
2.1: operacaoC2
2.1.1: operacaoD1
2.2: operacaoA2
sexta-feira, 22 de abril de 2011
95. 3) Posse individual de classe
(código)
• Estipula quem (pessoa ou papel) é o
responsável final pelo conteúdo de uma
classe (pedaço de código)
• O dono garante que o propósito da classe é
mantido e que as alterações são apropriadas
• Há um especialista disponível para explicar
como um trecho particular do código
funciona, especialmente para classes
complexas ou críticas para o negócio
• O dono pode implementar uma melhoria
mais rapidamente do que outro
desenvolvedor
• O dono, pessoalmente, possui algo do que
se orgulhar por ter feito bem
sexta-feira, 22 de abril de 2011
96. 4) Equipes de Features
• Formadas dinamicamente
• Única forma de desenvolver por
feature e manter a posse de código
• Sob a coordenação de um
Programador Líder
• Múltiplas mentes projetando
• Comparação entre alternativas e escolha da mais
apropriada
• Membros são os Proprietários de Classes
relevantes
• Benefício da Posse de Código
• Enfatiza o trabalho em equipe
• Ninguém termina enquanto a equipe de features não
terminar
sexta-feira, 22 de abril de 2011
97. 5) Inspeções
• Quando bem feitas, são muito úteis na melhoria
da qualidade do design e do código
• São recomendadas desde 1970 e a evidência pesa
fortemente a seu favor
• Numa experiência com 11 programas, o erro médio por 100
linhas de código caiu de 4,5 para 0,82
Taxa Média de Detecção de Defeitos
• Inspeções cortam erros em mais de 80%
• 1 hora de inspeção pode evitar 60%
60%
de 5 a 30 horas de correções
55%
45%
Teste Unitário
Teste Funcional 35% 45%
• Benefícios secundários Teste de Integração
Inspeção de Design
Inspeção de Código
24%
30%
• Transferência de conhecimento 15%
• Conformidade com padrões Técnica 0%
Jones, C.L. “A Process-Integrated Approach to Defect
Prevention”, IBM Systems Journal, 1985
sexta-feira, 22 de abril de 2011
98. Detecção Antecipada de
Defeitos
Prof. Guilherme Horta, COPPE/UFRJ, 2004
sexta-feira, 22 de abril de 2011
99. Como Conduzir Uma Inspeção
Artefato
1 Form.
Organizador
Planejamento Planejamento
Form.
2
Relato de
Inspetor Detecção
Defeitos
Form.
Ad-Hoc 3
Moderador Relato de
Técnicas de Leitura Coleção
Inspetor Defeitos
Checklists Autor Form.
Relato de
4 Defeitos
Correção
Autor Artefato
Prof. Guilherme Horta, COPPE/UFRJ, 2004 Corrigido
sexta-feira, 22 de abril de 2011
100. 6) Montagens Freqüentes
• Em intervalos regulares, compilar o sistema com
todas as features completadas até o momento
• Semanalmente, diariamente ou continuamente
• Ajuda a antecipar erros de integração
• Garante que sempre haverá alguma coisa para
mostrar ao cliente
• Oportunidades
• Geração de documentação
• Execução de scripts de auditorias e métricas
• Testes de regressão
• Notas da versão (novas features, defeitos corrigidos, etc.)
• Os resultados podem ser publicados na intranet do
projeto
sexta-feira, 22 de abril de 2011
101. 7) Gerenciamento de
Configuração
• Disciplina que suporta e controla as
evoluções e modificações em artefatos-
chave dentro do ciclo de desenvolvimento
de um software Principais
Artefatos de
Desenvolvimento
do Produto
Desenvolvimento
• Objetivos
• Facilitar o desenvolvimento de software
• Garantir a integridade dos produtos
• Controlar efetivamente as modificações Gerenciamento
• Itens de Configuração: Artefatos gerados ou
manipulados durante o ciclo de vida da
aplicação
• Arquivos, Requisitos, Documentos, Modelos,
Testes
• Processos, Contratos, Regulamentações
• Solicitações de Mudança, Defeitos, Tarefas
sexta-feira, 22 de abril de 2011
102. Tarefas Rotineiras do
Gerenciamento de Configuração
• Versionamento Gerenciamento de Processo
Definição de Workflow
• Check out/check in
Critérios de Entrada/Saída
• Histórico de revisões
• Branching & Merging Notificações
• Visões de Projeto Garantia de Segurança
Gerenciamento de Montagem
• Gestão de Mudanças Identificação de
• Acompanhamento de defeitos Dependências
• Listas de Melhoria Controle de Montagens
• Associações Gerenciamento de Liberação
• Rastreabilidade Rótulos
Estados Promocionais
• Gestão de Tarefas
Implantação
• Criação e Acompanhamento
• Ficha de tempo
sexta-feira, 22 de abril de 2011
103. 8) Relatório/Visibilidade de
Resultados
Para que o cliente e os gestores possam
direcionar o projeto corretamente é preciso
Uma figura acurada do estado atual do projeto
Saber o quão rápido a equipe adiciona
funcionalidade
O resultado geral desejado
Ter um método simples, de baixa sobrecarga,
para coletar informação de progresso de forma
acurada e confiável
Formatos de relatórios objetivos e intuitivos, para
todos os interessados no projeto
sexta-feira, 22 de abril de 2011
105. Principais Papéis
Gerente de
Desenvolvimento
Especialista
Domínio do Programador
Negócio Líder
GERENTE DE
PROJETOS
Arquiteto Proprietário
Líder de Classes
sexta-feira, 22 de abril de 2011
106. Gerente de Projeto
• Coordena as ações da equipe do projeto, controla o
progresso e reporta para a alta gerência e interessados
no projeto
• Responsável pelo gerenciamento de: escopo, tempo,
custo, qualidade, riscos, comunicação, recursos
humanos, suprimentos e integração
• Responsável por todos os assuntos administrativos do
projeto, o que inclui o gerenciamento de recursos,
orçamento, equipamentos e outros.
• Principal meta é fornecer subsídios para que nenhum
fator externo atrapalhe a produtividade da equipe do
projeto
sexta-feira, 22 de abril de 2011
107. Gerente de Desenvolvimento
• Possui habilidades técnicas e gerenciais
necessárias para coordenar as ações da equipe de
desenvolvimento, operacionalizando as decisões
tomadas pelo gerente de projeto
• Responsável por liderar o dia-a-dia do
desenvolvimento do produto.
• Por ser o responsável por resolver qualquer
conflito técnico que exista entre programadores-
chefes, precisa possuir boa experiência no
desenvolvimento de software e nas tecnologias
que estarão sendo utilizadas no projeto
sexta-feira, 22 de abril de 2011
108. Especialista no Domínio de
Negócio
• Compreende as regras e a dinâmica do domínio do problema
sendo considerado
• É o responsável por informar a equipe do projeto sobre o que
deve ser feito para que o produto do projeto seja adequado às
necessidades dos usuários
• Usa o seu conhecimento no negócio para apresentar à equipe
do projeto as necessidades para que o software possua valor
real
• Deve estar sempre disponível para fornecer aos
desenvolvedores maior detalhamento sobre determinada
funcionalidade
• É um um membro fixo da equipe e sempre esta fornecendo
feedback das entregas para todos os envolvidos.
sexta-feira, 22 de abril de 2011
109. Arquiteto Líder
• É um profissional com experiência em análise
e modelagem orientada a objetos, capaz de
liderar a equipe no desenvolvimento do
modelo que será construído para
implementar as features identificadas
• Possui habilidade para atuar como facilitador
na absorção das regras de negócio
• Será ele o responsável pela última palavra em
toda arquitetura do sistema.
sexta-feira, 22 de abril de 2011
110. Programador Líder
• Também chamado de Progranador-Chefe
• É um profissional mais experiente, que possui
reconhecimento como tal pela equipe
• Coordena o desenvolvimento das features, monta as
equipes de features e participa das definições técnicas,
além de ser também um Proprietário de Classes
• Normalmente é atribuído a ele a propriedade das classes
mais complexas do sistema
• Possui papel fundamental nas fases de absorção do
conhecimento de negócio e no planejamento das
funcionalidades.
sexta-feira, 22 de abril de 2011
111. Proprietário de Classes
• É um desenvolvedor da equipe, ao qual foram
atribuídas certas classes do modelo
• Sempre que uma feature for escolhida para
desenvolvimento e necessitar dos serviços
oferecidos por algumas das classes que estão sob
sua “custódia”, ele será escalado para participar
da equipe de features nessa iteração
• Programa, diagrama, testa e documenta as
funcionalidades a ele atribuídas pelo
Programador-chefe da equipe.
sexta-feira, 22 de abril de 2011
112. Funções de Apoio
Gerente de Guru da Engenheiro de
Versão Linguagem Desenvolvimento
Produtor de
Administrador
Testadores Ferramentas e
de Sistemas
Utilitários
Escritores
Implantadores
Técnicos
sexta-feira, 22 de abril de 2011
114. Os 5 Processos
Requisitos Concepção e Planejamento
Desenvolver Construir Planejar
Mais forma que conteúdo um Modelo a Lista de por
Abrangente Features Feature
Plano de
Desenvolvimento
Construção
Modelo de Objetos
Detalhar Construir Progresso
Mais conteúdo na forma por por
Feature Feature
Produto
Pacotes de Trabalho
Fonte: Heptagon – www.heptagon.com.br
sexta-feira, 22 de abril de 2011
115. O Porquê de Cada Processo
Desenvolver um Modelo Abrangente
Modelagem dos Processos de Negócio (BPM)
Captura de Requisitos
Análise Orientada por Objetos (OOA)
Construir a Lista de Features
Decomposição Funcional
Planejar por Feature
Plano de Desenvolvimento
Prioridade, Dependência, Distribuição de Trabalho
Detalhar por Feature
Design/Projeto OO (OOD), Estudo Detalhado
Construir por Feature
Programação OO (OOP)
Inspeção, Testes, Integração
sexta-feira, 22 de abril de 2011
116. O Contexto da FDD
Discussões Iniciais Sobre Requisitos
Obter Patrocínio da Gerência
Escolha da Linguagem de Programação
Feature-Driven Development
Planejamento Geral
Desenvolver um Modelo Abrangente Escolha da Plataforma Tecnológica
Preparação de Orçamento
Construir a Lista de Features Protótipo Técnico
Alocação de Pessoal
Planejar por Feature
Protótipo da Interface com o Usuário
Gerenciamento de Recursos
Detalhar por Feature
Limpeza de Dados
Gerenciamento de Problemas Construir por Feature
Conversão de Dados
Gerenciamento das Alterações nos Requisitos Teste do Sistema
Teste de Carga
Teste de Aceitação do Usuário
Sistema Piloto
Desenvolvimento em Fases
sexta-feira, 22 de abril de 2011
117. Principais Disciplinas
Envolvidas
Gestão Ágil de Projetos
Engenharia
de Requisitos
Concepção e Planejamento
Desenvolvimento
de Requisitos Decomposição
Análise OO Planejamento
Funcional
Gerência
de Requisitos
Construção
Gerência
de Configuração Programação
Projeto OO
e Teste OO
sexta-feira, 22 de abril de 2011
118. Análise e Desenho/Projeto
Orientados por Objetos
Análise OO
É um método de análise que examina os requisitos a
partir da perspectiva das classes e objetos
encontrados no vocabulário do domínio do problema
Enfatiza a construção de modelos do mundo real
usando uma visão de mundo orientada por objetos
Desenho/Projeto OO
É um método de projeto que abrange o processo de
decomposição orientado por objetos e uma notação
para descrever os modelos lógicos e físicos,
estáticos e dinâmicos, do sistema sendo projetado
Enfatiza a estruturação eficaz e apropriada de um
sistema complexo, sem se prender a detalhes de
implementação
sexta-feira, 22 de abril de 2011
119. Programação e Teste
Orientados por Objetos
Programação OO
É um método de implementação no qual os programas são
organizados como coleções cooperativas de objetos, cada qual
representando uma instância de alguma classe e cujas classes
são todas membros de uma hierarquia de classes unidas por
relacionamentos de herança
Enfatiza o uso de objetos, e não de algoritmos, como blocos de
construção lógica fundamentais
Teste OO
É um método de verificação do comportamento dos objetos em
tempo de execução
Enfatiza inicialmente o comportamento individual (unitário) de
cada classe de objetos, passando para o relacionamento entre
objetos, seu funcionamento como componente/serviço, e a
orquestração entre os componentes/serviços
sexta-feira, 22 de abril de 2011
120. Estabelecer o Propósito do
Projeto
Meta
Condição Condição Condição
Necessária Necessária Necessária
Objetivo Objetivo Objetivo
Intermediário Intermediário Intermediário
Objetivo Objetivo Objetivo
Intermediário Intermediário Intermediário
Objetivo Objetivo
Intermediário Intermediário
sexta-feira, 22 de abril de 2011
121. Engenharia de Requisitos
Gerenciamento & Governança de TI
Operações de TI (Produção)
IIT Management & Governance
Demanda Estratégica
Necessidades de Negócio
& Operacional
Engenharia de
ANÁLISE Requisitos
Priorização | Verificação |
Riscos | Estimação
DESCOBERTA ESPECIFICAÇÃO VALIDAÇÃO
Técnicas | Glossário | Detalhar Requisitos | Protótipo |
Revisão | Assinatura |
Fronteiras do Sistema | Modelo de Cenários de Negócio |
Baseline
Stakeholders Modelo de Casos de Uso
GERENCIAMENTO
Armazenamento | Medição & Auditoria | Ligação & Rastreamento | Relatórios | Segurança
sexta-feira, 22 de abril de 2011
122. Tipos de Requisitos
Funcionais Não-Funcionais
Requisitos
de Negócio
Documento de Visão e Escopo
Regras de
Requisitos Negócio
de Usuário
Atributos
de Qualidade
Casos de Uso
Interfaces
Requisitos Externas
de Sistema
Requisitos
Funcionais
Restrições
Especificação de
Karl Wiegers, “Software Requirements”
Requisitos de Software
sexta-feira, 22 de abril de 2011
123. 1. Desenvolver um Modelo
Abrangente
Também chamada de
“Modelagem de Objetos do
Domínio”
Preocupa-se mais com a
forma do que com o
conteúdo
Auxilia na captura e
esclarecimentos dos requisitos
Possibilita um entendimento
comum e mais completo sobre
o domínio do problema
sexta-feira, 22 de abril de 2011
124. 1. Desenvolver um Modelo
Abrangente
É uma atividade inicial de estudo, análise e
modelagem do sistema
Realizada em grupos
O modelo gerado é suficientemente
abrangente, mas não detalhado
O objetivo é ter uma definição a priori do
que será feito, para guiar a equipe durante
a fase de construção
Artefatos produzidos:
Diagramas de classes, sequência, DMA CLF PPF
atividades, estados, casos de uso
Lista preliminar de requisitos
DPF CPF
Anotações nos modelos
sexta-feira, 22 de abril de 2011
125. 1. Desenvolver um Modelo
Abrangente
Conduzir um Estudo
Formar a Equipe Dirigido Sobre o
de Modelagem Domínio de Negócio
(Gerente do Projeto) (Ger. Projeto, Especialistas)
opcional Desenvolver Modelos
Estudar Documentos em Pequenos Grupos
(Equipe de Modelagem) (Equipe de Modelagem
em pequenos grupos)
Refinar o Modelo de
Desenvolver um Objetos Completo
Modelo como Equipe (Arquiteto Líder,
(Equipe de Modelagem) Equipe de Modelagem)
Escrever Comentários
Sobre o Modelo
(Arquiteto Líder,
Programador Líder)
sexta-feira, 22 de abril de 2011
126. Arquitetura em Camadas
CO
Apresentação
O F
Negócio – Domínio do Problema
Persistência Interface com
Outros Sistemas
sexta-feira, 22 de abril de 2011
127. UML em Cores
Padrão de análise e
modelagem desenvolvido
por Peter Coad, na última
metade da década de 1990
Auxilia tanto na criação quanto na melhoria
de modelos da classes
Fácil de aprender e explicar
Propõe a utilização de 4 arquétipos
arquétipo. s.m. 1 modelo ou padrão passível de ser
reproduzido em simulacros ou objetos semelhantes; 2 idéia
que serve de base para a classificação dos objetos sensíveis; 3
Derivação: por extensão de sentido: qualquer modelo, tipo,
paradigma. (Dic. Houaiss da Língua Portuguesa).
sexta-feira, 22 de abril de 2011
128. Arquétipo: Momento-Intervalo
Representa algo que necessita ser registrado,
por razões de negócio ou até mesmo legais, que
ocorre em algum momento no tempo ou durante
um intervalo de tempo
São atividades, eventos e serviços
Um momento-intervalo também pode ter
“mi-detalhes”, ou seja, ser composto por
pequenas etapas do evento total
Exemplos:
Uma venda é algo que acontece num certo momento
Uma estada é o período de tempo que o veículo fica sob a
responsabilidade do estacionamento
Para identificar esse arquétipo usamos a cor rosa e o
estereótipo <<moment-interval>>; também usa-se a sigla MI;
para os detalhes, usamos o estereótipo <<mi-detail>>
É comum a classe estar acompanhada de um diagrama de
máquina de estados, para definir seu comportamento em tempo
de execução
sexta-feira, 22 de abril de 2011
129. Arquétipo: Pessoa-Lugar-Coisa
Representa:
Uma pessoa (física ou jurídica)
Um certo local (endereço, casa, privado ou público)
Algum objeto, geralmente concreto
São entidades que devem ser registradas no
sistema por desempenharem papéis nas
atividades (momentos-intervalos)
Uma mesma pessoa pode participar de
eventos distintos, através de papéis
diferentes
Identificamos esse arquétipo com a cor
verde e o estereótipo correspondente:
<<party>>, <<place>> ou <<thing>>
É onde geralmente aparecem os “cadastros”
e “relatórios” simples
sexta-feira, 22 de abril de 2011
130. Arquétipo: Papel
É a representação de um papel que é
desempenhado por pessoa, lugar ou coisa,
em um determinado evento do negócio
(momento-intervalo)
É mais comumente aplicado a pessoas, mas é
possível utilizá-lo com lugares e até mesmo com
coisas
Exemplo:
Um aeroporto pode desempenhar o papel de local de
origem, destino ou escala de um vôo
Uma pessoa, num hotel, pode ser recepcionista,
gerente, hóspede, vigilante, etc.
Sua cor é o amarelo e o estereótipo é
<<role>>
sexta-feira, 22 de abril de 2011
131. Arquétipo: Descrição
É como um item num catálogo, definindo as
características de uma determinada coisa,
lugar ou até mesmo pessoa (menos comum,
mas possível)
Usado para concentrar dados comuns a
diversos objetos, possibilitando perguntas de
negócio interessantes, como a quantidade
de
objetos de um determinado tipo
Aparece na cor azul (quase cinza,
dependendo da ferramenta de modelagem)
e usa-se o estereótipo <<description>>
São as famosas “referências” usadas em
combos e lookups
sexta-feira, 22 de abril de 2011
132. Domain Neutral Component
(Componente Genérico de Modelagem)
Padrão para análise
OO (Camada de
Negócio)
Mostra o
relacionamento
entre os arquétipos
Diminui a variação
no processo de
modelagem
Padroniza o
entendimento
Equipe de Negócio
Equipe de TI
sexta-feira, 22 de abril de 2011
133. UML Sem Cores
Hotel Funcionario PessoaFisica
Nome * DtAdmissao Nome
Endereco CTPS CPF
Estrelas
*
TipoQuarto Quarto Estadia Hospede
Descricao * ID DHInicio * Score
NumSolt Status DHTermino DtUltVisita
NumCasal ValorTotal
Fumante?
*
Servico
Data
Hora
Valor
sexta-feira, 22 de abril de 2011
134. UML em Cores
Hotel Funcionario PessoaFisica
Nome * DtAdmissao Nome
Endereco CTPS CPF
Estrelas
*
TipoQuarto Quarto Estadia Hospede
Descricao * ID DHInicio * Score
NumSolt Status DHTermino DtUltVisita
NumCasal ValorTotal
Fumante?
*
Servico
Data
Hora
Valor
sexta-feira, 22 de abril de 2011
135. 2. Construir a Lista de Features
Com o modelo básico criado, deve-se
agora criar uma lista de features
É uma decomposição funcional do domínio
do negócio
Categorizada em 3 níveis:
Áreas de Negócio (Grandes Conjuntos de
Features)
Atividades de Negócio (Conjuntos de Features)
Passos da Atividade de Negócio (Features)
DMA CLF PPF
Artefatos produzidos:
Lista de Features
DPF CPF
Requisitos mais detalhados
sexta-feira, 22 de abril de 2011
136. 2. Construir a Lista de Features
Formar a Equipe
de Lista de Features
(Gerente do Projeto,
Gerente de Desenvolvimento)
Construir a
Lista de Features
(Equipe de
Lista de Features)
sexta-feira, 22 de abril de 2011
137. FBS: Feature Breakdown
Structure
Sistema ou
Gerenciamento de ...
Aplicação
Área de Negócio Área de Negócio Área de Negócio
Atividade de Negócio Atividade de Negócio Atividade de Negócio
Atividade de Negócio Atividade de Negócio Atividade de Negócio
Atividade de Negócio Funcionalidade Atividade de Negócio
<Substantivo> Funcionalidade <Ação> <Resultado> <Objeto>
<VerboInfinitivo> ...
sexta-feira, 22 de abril de 2011
138. As Features preenchem o
Modelo
Área n
Atividade X
Feature 1
Classe A
Feature 2
Atividade Y
Feature 3
Feature 4
Classe B
Feature 5
...
Classe C
sexta-feira, 22 de abril de 2011
139. Processo Nº 3:
Planejar por Feature
Com a lista e o modelo, deve-se agora planejar a
ordem na qual as funcionalidades serão
implementadas, tendo como base:
a necessidade do usuário (importância, prioridade)
as dependências entre elas
a carga de trabalho da equipe de desenvolvimento
a complexidade das funcionalidades
As responsabilidades são distribuídas para a
equipe
Artefatos produzidos: DMA CLF PPF
Plano de desenvolvimento
Pacotes de trabalho
DPF CPF
Lista de classes com seus donos
sexta-feira, 22 de abril de 2011
140. Processo Nº 3:
Planejar por Feature
Formar a Equipe Determinar a Sequência
de Planejamento de Desenvolvimento
(Gerente do Projeto) (Equipe de Planejamento)
Atribuir Conjuntos de
Atribuir Classes para
Features para
os Desenvolvedores
Programadores Líderes
(Equipe de Planejamento)
(Equipe de Planejamento)
sexta-feira, 22 de abril de 2011
141. Estimativas
Regra Empírica da FDD
Cada semana de modelagem resulta em 12 semanas de construção
Pressuposto: a equipe usa UML em Cores, arquétipos e DNC
Truco (ou Poker) da Estimativa
A Escala de 5 Pontos
Nº Estimado de Classes na Complexidade Esforço
Feature da Feature (Pessoa-Dia)
1 1 0,5
2 2 1
3 3 2
4 4 4
5 5 8 (ou mais)
David Anderson, Agile Management for Software Engineering, 2003
sexta-feira, 22 de abril de 2011
142. O Plano de Desenvolvimento
Com as features devidamente estimadas, o plano de
desenvolvimento é criado a partir da capacidade de
produção
Com as features na ordem desejada, corta-se a lista em
blocos que caibam nas durações das iterações (1 ou 2
semanas)
Cuidado para não quebrar em pontos que causem problemas
Cada pacote de trabalho deve ser atribuído a um
Programador Líder
Com as “datas” de cada iteração, preencher as “datas”
planejadas de cada um dos 6 milestones (as datas
geralmente são iguais para as features da iteração)
Iteração 1 Iteração 2 Iteração 3 Iteração 4
Pacote 1 Pacote 2 Pacote 3 Pacote 4
(10) (8) (13) (15)
sexta-feira, 22 de abril de 2011
143. 4. Detalhar por Feature
Agora na fase de construção propriamente
dita, deve-se refinar o projeto (design) para
cada feature ou conjunto de features
relacionadas
A equipe de features será formada pelos
proprietários das classes envolvidas
O resultado será um pacote de trabalho, sob
a responsabilidade de um programador líder
Artefatos produzidos:
Modelos detalhados (classes e seqüência)
Esqueletos de classes com métodos
Pacote de trabalho detalhado DMA CLF PPF
Relatório de inspeção do design
Relatório de progresso atualizado
DPF CPF
sexta-feira, 22 de abril de 2011
144. 4. Detalhar por Feature
opcional
Conduzir um Estudo
Formar a Equipe
Dirigido Sobre o
de Features Domínio de Negócio
(Programador Líder) (Especialista no Domínio)
opcional opcional
Estudar Documentos Desenvolver os
de Referência Diagramas de Sequência
(Equipe de Features) (Equipe de Features)
Refinar o Modelo Escrever Prólogos de
de Objetos Classes e Métodos
(Programador Líder) (Equipe de Features)
Inspecionar o
Projeto (Design)
(Equipe de Features)
sexta-feira, 22 de abril de 2011
145. 5. Construir por Feature
Os proprietários de classes desenvolvem o
código correspondente a cada feature
Os testes de unidade e as inspeções são
realizados
O código final (aprovado) é promovido ao
build atual
O resultado são funções com valor para o
cliente (features)
Artefatos produzidos:
Código fonte testado e integrado DMA CLF PPF
Relatórios de inspeção e testes
Lista de alterações feitas/necessárias
Relatório de progresso atualizado DPF CPF
sexta-feira, 22 de abril de 2011