feature driven development (fdd) kleber silva, [email protected]@cin.ufpe.br 11/10/2005
TRANSCRIPT
![Page 2: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/2.jpg)
Agenda Introdução Motivação Melhores Práticas
Modelagem de Objeto do Domínio Desenvolvimento por Feature Class (Code) Ownership Equipes por Feature Inspeções Builds Regulares Gerência de Configuração Comunicação/Visibilidade dos Resultados
Processo Conclusão
![Page 3: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/3.jpg)
Introdução Desenvolvimento Ágil
(+) (-)
Indivíduos e Interações Processos e Ferramentas
Software Funcionando Documentação Extensa
Colaboração do Cliente Negociação de Contrato
Resposta às Mudanças Seguir um Plano
Tabela 1 – Manifesto Desenvolvimento Ágil
![Page 4: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/4.jpg)
Introdução Feature Driven Development
Criado por Jeff De Luca em 1999, baseado em 30 anos experiência na área de TI com envolvimento de Peter Coad e Steve Palmer;
Trata-se de uma compilação dos “patterns of success” percebidos;
Possui características de Desenvolvimento Ágil;
Iterações pequenas (no máximo 2 semanas)
Centrada em Design.
“We cannot predict where a chess game will go, but we
can learn patterns of play that bring success." [Highsmith 2000].
“Good habits are a wonderful thing. They allow the team
to carry out the basic steps, focusing on content
and results , rather than process steps . This is
best achieved when process steps are logical
and their worth immediately obvious to
each member.”Coad, LeFebvre, De Luca
[Coad 99]
![Page 5: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/5.jpg)
Motivação Clientes têm resultados rápidos e relatório
do status numa linguagem que eles entendem
Gerentes de projeto têm uma visão completa e exata do status do projeto
Desenvolvedores conseguem trabalhar em novas coisas em poucos dias e ficam mais envolvidos em análise, projeto e codificação
![Page 6: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/6.jpg)
Melhores Práticas Modelagem de Objeto do Domínio
Diagramas de classes dos objetos do domínio e seus relacionamentos são construídos;
O suporte aos aspectos comportamentais é dado por diagramas de seqüência em alto nível;
Ênfase não é em cima de se determinar todos os atributos;
Evita as inferências isoladas dos analistas, por se tratar de um modelo global onde todos os envolvidos participam.
![Page 7: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/7.jpg)
“Extending that analogy a bit further, a domain object
model is like the road map that guides the journey;
with it, you can reach your destination relatively
quickly and easily without too many detours or a lot
of backtracking; without it, you can very quickly end
up lost or driving around in circles, continually
reworking and refactoring the same pieces of code.”
Stephen Palmer
Modelagem De Objeto Do Domínio
Figura 1 – Modelo de Objetos Do Domínio numa Fase Inicial
![Page 8: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/8.jpg)
Desenvolvimento Por Feature
Statement of Purpose
Módulo 1
Módulo 2
Módulo 3
Módulo N
...
Req 1.1
Req 1.2
Req 2.1
Req 3.1
Req 3.2
Req 3.3
Req N.1
...
Figura 2 – Decomposição do Statement Of Purpose em Requisitos Funcionais
![Page 9: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/9.jpg)
Feature Features são os requisitos funcionais
com valor para o usuário, isto é, estão numa linguagem que o cliente ou usuário podem entender;
Os requisitos funcionais tendem a misturar funções de interface, persistência e comunicação em rede com funções de negócio;
Facilitam o acompanhamento da evolução do projeto (o quanto já foi feito) junto ao cliente.
“Once we have identified the classes in our domain object
model, we can design and implement each one in turn.
Then, once we have completed a set of classes, we integrate
them and hey, presto! We have part of our system.
Easy!...Well, it’s a nice dream!”“We can produce the most elegant
domain object model possible, but if it does not help us to
provide the system’s clients with the functionality for which
they have asked, we have failed. It would be like building
a fantastic office skyscraper but either leaving each floor
unfurnished, uncarpeted, and without staff, or furnishing it
with ornamental but impractical furniture and untrained staff.”
A Practical Guide to FDD, cap 3
![Page 10: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/10.jpg)
Feature O termo feature em FDD é muito específico. Uma feature é uma
função pequena, com valor no cliente expressa na seguinte forma: <action> <result> <object>Com as proposições apropriadas entre ação, resultado e objeto. Ex.: - Calcular o total de uma venda;
- Avaliar o desempenho de um vendedor.- Validar a senha de um usuário.
Features vs. Casos de Uso Classes com funções pesadas constantemente acessando
classes com dados pesados Alto acoplamento Baixa coesão Encapsulamento pobre
![Page 11: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/11.jpg)
Feature Exemplo
Área de Features Principal (Subject Domain Area) Gerenciamento de venda de produtos
Conjunto de Features (Business Activity) Vender para um cliente
Features Calcular o total de vendas Calcular o total de compras de um cliente Estimar o tempo de entrega de uma venda Calcular a taxa de uma venda
![Page 12: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/12.jpg)
Class (Code) Ownership Class (code) ownership num processo de
desenvolvimento denota quem é em última instância responsável pelo conteúdo de uma classe (parte de código);
Pode ser: Individual – a classe é atribuída somente a um
único dono; Coletiva – O time possui coletivamente a classe
(código).
![Page 13: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/13.jpg)
Individual Class Ownership Vantagens
Um guardião de integridade conceitual; Um expert para explicar uma parte do código; Um desenvolvedor mais rápido para implementar
essa parte de código; “É minha classe, dela me orgulho!!!”
Desvantagens Mudanças que dependem de outras classes; Perda do conhecimento por ocasião da falta do
class owner.
![Page 14: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/14.jpg)
Collective Class Ownership Vantagens
Resolve o problema da espera por outro para solução de um problema;
Desvantagens Facilmente degenera em não tem dono ou
classes governadas por uma “elite”.
![Page 15: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/15.jpg)
Equipes por Feature Como se organiza os class owners para
construir as features?
Figura 3 – Equipes por Feature
![Page 16: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/16.jpg)
Equipes por Feature Normalmente pequena: de três a seis
integrantes; Possui todo o código que necessita para
mudar sua feature; Cada membro de uma feature contribui para
o design e implementação de uma feature sob a orientação de um desenvolvedor mais experiente.
![Page 17: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/17.jpg)
Inspeções Usadas para:
Detecção de Defeitos; Transferência de Conhecimento; Aderência à Padrões de Codificação; Extrair Métricas para Melhoria do Processo.
Cuidado: Não devem ser tomadas como uma avaliação pessoal de performance.
![Page 18: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/18.jpg)
Builds Regulares Em intervalos regulares, o sistema completo é
montado; Identifica os erros de integração; Garante um sistema “up-to-date” para
demonstração ao cliente Um processo de geração de builds pode ser
melhorado para: Gerar documentação; Rodar script de métricas e de auditoria; Base para testes de regressão; Construir novo build e release notes, listando novas
features adicionadas, defeitos corrigidos, etc...
![Page 19: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/19.jpg)
Gerência de Configuração Identificação do código para todas as
features completadas; Manutenção de um histórico de mudanças
das classes.
![Page 20: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/20.jpg)
Comunicação/Visibilidade Dos Resultados Progress Reporting
Facilita o acompanhamento gerencial, através da coleta de informações confiáveis e precisas sobre o status do projeto;
Sugere um número de formatos de relatórios intuitivos e diretos para ilustrar o progresso.
Closely related to project control is the concept of
“visibility,” which refers to the ability to determine a project’s true status....If
the project team can’t answer such questions, it
doesn’t have enough visibility to control its
project.
The working software is a more accurate status report than
any paper report could ever be.
Steve McConnell [McConnell 98]
![Page 21: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/21.jpg)
KEY: Work In Progress Attention Completed Not Started
Comunicação/Visibilidade Dos Resultados
![Page 22: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/22.jpg)
Comunicação/Visibilidade Dos Resultados
![Page 23: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/23.jpg)
Dez 2001
Porcentagem completa:
Status Completo:Completo
Mês de conclusão
Exemplo: Conjunto de Features: Fazendo avaliação de produtos – Trabalho em progresso CP-1 é o programador chefe inicial
(14) esse conjunto de Features possui 14 características
Conjunto de Features/ está 75% completado
A conclusão é para dezembro de 2001
Status Geral:
MY
Barra de progresso
Trabalhos em progresso
Atenção (ie, atrasado)
Completo
Fazendoavaliação
de produtos(14)
75%Não iniciado
CP-1
Comunicação/Visibilidade Dos Resultados
![Page 24: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/24.jpg)
Product Sale Management (PS)
InvoicingSales
(33)
Dec 2001
CP-1
Setting upProduct
Agreements(13)
Dec 2001
SellingProducts
(22)
Nov 2001
CP-1
ShippingProducts
(19)
Dec 2001
CP-1
10%
DeliveringProducts
(10)
Dec 2001
CP-3
30%
MakingProduct
Assessments(14)
Dec 2001
75%99% 3%
Customer A/C Mgmt (CA)
EvaluatingAccount
Applications(23)
Oct 2001
95%
LoggingAccount
Transactions(30)
Nov 2001
82%
OpeningNew
Accounts(11)
Oct 2001
100%
Inventory Mgmt (IM)
EstablishingStorage Units
(26)
Nov 2001
100%
MovingContent
(19)
Nov 2001
82%
CP-3
AcceptingMovementRequests
(18)
Nov 2001
97%
CP-3
KEY: Work In Progress Attention Completed Progress Bar Not Started
CP-2 CP-1
CP-2 CP-2 CP-2 CP-3
Comunicação/Visibilidade Dos Resultados
![Page 25: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/25.jpg)
Comunicação/Visibilidade Dos Resultados
![Page 26: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/26.jpg)
Processo Descrição
Cada processo é descrito em não mais do que duas páginas de papel tamanho carta, frente-e-verso;
Cada descrição do processo apresenta-se de acordo com a estrutura: Entrada, Tarefas, Verificação e Saídas (ETVX).
![Page 27: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/27.jpg)
ProcessoPapéis principais
Gerente de projeto Arquiteto chefe Especialistas no domínio Gerentes de desenvolvimento Programadores chefes Proprietários de classes
![Page 28: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/28.jpg)
Processo1.Desenvolver
um Modelo Geral
2. Construir uma Lista deFeatures
3. Planejar Por
Feature4. Projetar
PorFeature
5. Construir Por Feature
Modelo de Objeto (mais formas do que conteúdo)
Uma lista de Features
categorizadaUm plano de
desenvolvimento
Um pacote de projeto
(seqüências)
Uma função do cliente
completada
(mais conteúdo do que forma)
Figura 4 – Os 5 Processos FDD
![Page 29: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/29.jpg)
Adquirir conhecimento do domínio e construir o modelo geral Estabelecimento do “propósito de negócio” do
novo sistema; Construção de um “modelo conceitual” do
sistema.
Desenvolver um Modelo Geral
![Page 30: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/30.jpg)
Formar a Equipe de Modelagem
Walkthrough sobre o Domínio
Estudar Documentos
Desenvolver pequenos Modelos de Grupo
Desenvolver um Modelo da Equipe Refinar o Modelo Geral
Escrever Anotações do Modelo
Atividades
![Page 31: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/31.jpg)
Entrada Especialistas no domínio, programadores e arquitetos
chefes são selecionados. Saídas
Modelo geral do domínio; Diagrama das classes principais com alguns métodos e
atributos identificados; Diagramas de seqüência de algumas funcionalidades mais
complexas (se houver); Comentário sobre o modelo.
Entradas e Saídas
![Page 32: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/32.jpg)
O domínio é decomposto até chegar nas Features;
Features são agrupadas e categorizadas; Features são granuladas até ser necessário
menos de 2 semanas pro seu desenvolvimento.
Construir lista de Features
![Page 33: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/33.jpg)
Formar a Equipe da Lista de Features
Construir a lista de Features
Atividades
![Page 34: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/34.jpg)
Entrada O processo de desenvolvimento do modelo geral
ter sido concluído com sucesso. Saídas
Uma lista das áreas do domínio identificadas; Para cada área, uma lista de atividades de
negócio (conjunto de Features); Para cada atividade, os passos a serem
realizados (Features).
Entradas e Saídas
![Page 35: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/35.jpg)
Uma data de lançamento é estabelecida para o release inicial;
A lista de Features priorizadas é refinada; Dependência entre funcionalidades Carga de Trabalho Complexidade ou Risco Milestones
O trabalho técnico é planejado e atribuído – plano de desenvolvimento
Planejar Por Features
![Page 36: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/36.jpg)
Formar a Equipe de Planejamento
Determinar a Seqüência de Desenvolvimento
Atribuir Conjuntos de Features para Programadores Chefes
Atribuir Classes para Desenvolvedores
Atividade
![Page 37: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/37.jpg)
Entrada O processo de construir a lista de Features ter sido
concluído com sucesso. Saídas
Áreas de Domínio com datas de término; Atividades de negócio com datas de término; Programadores-chefes atribuídos a atividades de
negócio; A lista de classes e seus donos (desenvolvedores).
Entradas e Saídas
![Page 38: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/38.jpg)
Regras e transações são identificadas O modelo da interface do usuário é
esboçado Diagramas de seqüência mais detalhados
são produzidos Especialistas são consultados para descobrir
qualquer necessidade específica adicional
Projetar Por Features
![Page 39: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/39.jpg)
Formar a Equipe Por Feature
Estudo do Domínio Estudar Documentos de Referências
Desenvolver Diagramas de Seqüência
Refinar o ModeloDescrever os prefácios de
classes e métodos
Atividades
![Page 40: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/40.jpg)
Entrada O processo de planejamento ter sido concluído com
sucesso Saídas
Diagramas de seqüência Designs alternativos (caso exista) O modelo de objeto com classes, métodos e atributos
novos ou atualizados A documentação da API do sistema Lista de tarefas (calendário/ To-Do)
Entradas e Saídas
![Page 41: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/41.jpg)
Features são construídas implementando todas as classes e métodos necessários
Testes de unidades Features são inseridas no build quando o
teste resulta em sucesso
Construir Por Feature
![Page 42: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/42.jpg)
Codificar
Testar Unidades Inspecionar Código
Promover à versãoatual (Build)
Ponto de integração para a funcionalidade inteira
Atividades
![Page 43: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/43.jpg)
Entrada O processo de construção por Feature ter sido
concluído com sucesso Saídas
Classe(s) e/ou método(s) que passaram na inspeção de código com sucesso
Classes inseridas no build A conclusão da funcionalidade do cliente
Entradas e Saídas
![Page 44: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/44.jpg)
Conclusão Requer alguma arte na alocação de
recursos; Permite um bom acompanhamento gerencial
do status das atividades; Mais leve e simples de implementar; Favorece um bom Design do sistema.
![Page 45: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/45.jpg)
Referências http://agilemanifesto.org/principles.html, Principles Behind The Agile
Manifest. Highsmith, James A. III, 2000, "Adaptive Software Development: A
Collaborative Approach to Managing Complex Systems." Dorset House Publishing
R Palmer, S. Felsing, John M. A Practical Guide to Feature-Driven Development. The Coad Series.
Coad P., Lefebyre E., De Luca, J. Java Modeling In Color With UML: Enterprise Components And Processes. Prentice Hall.
http://www.cin.ufpe.br/~processos/TAES3/slides-2004.2/FDD.ppt, Feature Driven Development. Apresentação por Manuela Xavier, 05/11/2004.
http://www.nebulon.com/fdd/, Feature Driven Development. http://www.faturedrivendevelopment.com/, The Portal For All Things
FDD. http://www.fddmanager.com/, FDD Manager – Overview. http://fddtools.sourceforge.net/, FDD Tools Project.
![Page 46: Feature Driven Development (FDD) Kleber Silva, khfts@cin.ufpe.brkhfts@cin.ufpe.br 11/10/2005](https://reader035.vdocuments.us/reader035/viewer/2022070507/570638451a28abb8238f2832/html5/thumbnails/46.jpg)
Dúvidas
???