Técnicas em Projetos de Sistemas

Professor: Marinaldo

FDDFEATURE DRIVEN DEVELOPMENT

DESENVOLVIMENTO GUIADO POR FUNCIONALIDADE

•Cícero Alves•Délio Peres Barros•Hussein Mohamad•José Emerson•Marlon Ribeiro

HISTÓRICO

Criado em 1997 num grande projeto de sistema de empréstimos em Java para o

banco United Overseas Bank, em Singapura.

Problema: Após dois de consultoria, 3.500 páginas de casos de uso e um modelo de

objetos com centenas de classes, foi considerado impossível.

Decisão: União entre a experiência de análise e modelagem orientadas por objetos de

Peter Coad, e o gerencimento de projetos de Jeff De Luca.

Resultado: 15 meses depois da contratação da dupla, 2.000 features entregues por

uma equipe de 50 pessoas.

Inicialmente publicada em 1999, no capítulo 6 do livro “Java Modeling In Color With

UML”.

Em 2002, o livro “A Practical Guide To Feature Driven Development” foi publicado

com a versão completa, atualizada e comentada da metodologia.

CONCEITOS O Desenvolvimento Guiado Por Funcionalidades (FDD) é uma metodologia

ágil para o processo de engenharia de software, elaborado com foco na entrega freqüente de “software funcionando” para os clientes e na utilização de boas práticas durante o ciclo de seu desenvolvimento.

Um fato marcante é o forte favorecimento ao envolvimento de clientes (interno ou externo) ao processo de planejamento e desenvolvimento do software.

Diferentemente de outras metodologias, o FDD não é extremamente focado na programação ou no modelo, mas sim utiliza o bom senso para abstrair o melhor dos dois mundos.

Não é uma metodologia de gerenciamento de projetos de software. Apesar de, em suas práticas, existirem atividades relacionadas a esse fim. Apresenta como foco principal cobrir o processo de engenharia de software, e não do gerencimento.

CARACTERÍSTICAS Entrega resultados funcionais e tangíveis a cada duas semanas ou menos.

Pequenos blocos de funcionalidades (features) valorizados pelo cliente.

Planejamento detalhado e guiado para medição.

Rastreabilidade e relatórios precisos.

Monitoramento detalhado, com resumos em termos de negócio para o cliente.

Realiza trabalho significativo desde o início, antes de se tornar iterativa.

Fornece uma forma de saber, com 10%, se o plano e a estimativa são sólidos.

Fornece a estrutura suficiente para equipes maiores.

Enfatiza a produção de software de qualidade.

PRÁTICAS DO FDD Modelagem de objetos do domínio.

Desenvolvimento por feature (funcionalidade).

Posse individual de classe (código).

Equipes de features (papéis por áreas de negócio).

Inspeções (especificações, código, teste de unidades).

Builds regulares (geração de versões com novos features).

Gerenciamento de configuração.

Relatório/Visibilidade de resultados.

CONCEITO DE FEATURE Característica ou funcionalidade que representem algum valor para o cliente.

Um feature não deve ultrapassar o tamanho de sua iteração. Deve ser pequena o suficiente

para ser implementada no tempo médio de duas semanas.

Mapeia passos em uma atividade de negócio. Pode ser um passo de um caso de uso, ou às

vezes, pode ser o próprio caso de uso.

Conceito muito próximo ao de um requisito funcional.

É representada através do template: <ação> <resultado> <objeto>. Ex: Calcular o desconto

de uma venda. Listar os clientes ativos de uma empresa. Sendo o conjunto de funcionalidades que será entregue para o cliente ao final de uma

iteração, não deve se economizar tempo, atenção e criatividade no processo de definição das mesmas.

ESTRUTURA FASES:

Concepção & Planejamento: Pensar um pouco antes de fazer (entre 1 e 2 semanas).

Construção: Fazer de forma iterativa (geralmente em interações de 2 semanas).

PROCESSOS:

Desenvolver Um Modelo Abrangente (DMA): Análise Orientada Por Objetos.

Construir A Lista De Funcionalidades (CLF): Decomposição Funcional.

Planejar Por Funcionalidade (PPF): Planejamento Incremental.

Detalhar Por Funcionalidade (DPF): Projeto Orientado Por Objetos.

Construir Por Funcionalidade (CPF): Programação e Teste Orientado Por Objetos.

ESTRUTURA

PRINCIPAIS PAPÉIS

1.Desenvolver um Modelo

geral2. Construir uma lista de

características3. Planejar através de

característica4. Projetar através de

característica

5. Construir através de

característica

Os 5 processos do FDD

Modelo de Objeto (mais formas do que

conteúdo)

Uma lista de características categorizada

Um plano de desenvolvimento

Um pacote de projeto (seqüências)

Uma função do cliente completada

(mais conteúdo do que forma)

Descrição dos Processos de FDDCada 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)

FDD Processo #1: Desenvolver um modelo geral

• 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

FDD Processo #1- Atividades

Formar a Equipe de Modelagem

Estudo dirigido 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

• 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

FDD Processo #1:Entradas e Saídas

FDD Processo #2:Construir lista de características

• O domínio é decomposto até chegar nas características

• Características são agrupadas e categorizadas• Características são granuladas até ser

necessário menos de 2 semanas pro seu desenvolvimento

FDD Processo #2 - Atividades

Formar a Equipe da Lista de Características

Construir a lista de características

• Entrada– O processo #1 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 características)– Para cada atividade, os passos a serem realizados

(características)

FDD Processo #2:Entradas e Saídas

FDD Processo #3:Planejar através de características

• Uma data de lançamento é estabelecida para o release inicial

• A lista de características priorizadas é refinada

• O trabalho técnico é planejado e atribuído – plano de desenvolvimento

FDD Processo #3 - Atividades

Formar a Equipe de Planejamento

Determinar a Seqüência de Desenvolvimento

Atribuir Conjuntos de Características para Programadores Chefes

Atribuir Classes para Desenvolvedores

• Entrada– O processo de construir a lista de características

(processo #2) ter sido concluído com sucesso• Saídas

– 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)

FDD Processo #3: Entradas e Saídas

FDD Processo #4:Projetar através de características

• 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

FDD Processo #4 - Atividades

Formar a Equipe de Características

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

• Entrada– O processo de planejado (processo #3) ter sido concluído com

sucesso• Saídas

– Diagramas de seqüência– Projetos 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)

FDD Processo #4:Entradas e Saídas

FDD Processo #5:Construir através de características

• Características são construídas implementando todas as classes e métodos necessários

• Testes de unidades• Características são inseridas no build quando

o teste resulta em sucesso

FDD Processo #5- Atividades

Codificar

Testar Unidades Inspecionar Código

Promover à versãoatual (Build) Ponto de integração para a

funcionalidade inteira

• Entrada– O processo anterior 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

FDD Processo #5:Entradas e Saídas

• Cada característica é uma unidade planejada de trabalho que pode ser devolvida

• A soma de características entregues é igual ao status do projeto

Divulgando Resultados

Os seis marcos do FDD

Projetar pelas características Construir pelas características

Análise do domínio

Projeto Inspeção do projeto

Código Inspeção do código

Geração de build

1% 40% 3% 45% 10% 1%

Relatando resultados

Dez 2001

Porcentagem completa:

Status Completo:

Completo

Mês de conclusão

Exemplo: Conjunto de características: Fazendo avaliação de produtos – Trabalho em progresso CP-1 é o programador chefe inicial

(14) esse conjunto de características possui 14 características

Conjunto de características 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

• FDD– Fornece clareza– Eleva o controle– Facilita a comunicação – reporta resultados– Status do projeto completo é determinado pelas

características entregues – Características quebram o trabalho em entregas

menores e mais gerenciáveis– Builds regulares– É bom para os desenvolvedores, gerentes e clientes...

Conclusão