Engenharia de Software Feature Driven Development Allyson Jos

Engenharia de Software Feature Driven Development Allyson José Edivânia Pontes Thomas Matheus Stephany Silva

Metodologias Ágeis • Foi criada durante os anos 90 como reação contra os métodos de desenvolvimento “pesados”, tipificados pelo modelo em cascata. • Denominadas como métodos de desenvolvimento “leves”.

Como surgiu o FDD • Concebido originalmente por Jeff de Luca, o FDD surgiu em Singapura, entre os anos de 1997 e 1999 com base no método Coad (Criado por Peter Coad – 1980/1990) e nos processos interativos e lean já utilizados por Jeff de Luca.

FDD • É uma metodologia ágil para o processo de engenharia de software. • Busca o desenvolvimento por funcionalidade, ou seja, por um requisito funcional do sistema.

Agentes e Atores

Análise do risco de utilização de Métodos Ágeis e Preditivos • Métodos ágeis: ØPouca crítica à implementação ØEquipe de desenvolvimento constituída por elementos experientes ØGrandes mudanças nos requisitos ØEquipe de desenvolvimento constituída por poucos elementos ØCultura que prospera na falta de organização.

Análise do risco de utilização de Métodos Ágeis e Preditivos • Métodos preditivos: ØMuita crítica à implementação ØEquipe de desenvolvimento constituída por elementos inexperientes ØPoucas mudanças nos requisitos ØEquipe de desenvolvimento constituída por muitos elementos ØCultura que exige ordem e organização.

Ciclo de Vida do Projeto Requisit os Desenvo lver um modelo abrange nte Detalh ar por Feature Constr uir Listas de Featur es Constr uir por Feature Planeja r por Feature Produto

Develop an Overall Model Desenvolvimento de Modelo Abrangente • O cliente indica quais os requisitos quer ver cumpridos no sistema • Cabe à equipe de desenvolvimento: analisar e verificar os requisitos dados pelo cliente; Sugerir novos requisitos; E colocar todas questões que possam ainda não terem sido respondidas, ou que tenham sido esquecidas • A equipe de desenvolvimento dividem-se em pequenos grupos para desenvolver seus modelos • Os resultados são adicionados a um modelo comum, um modelo abrangente

Build by Features List Construção de Lista de Funcionalidades • Identifica todas as funcionalidades e agrupa-as por ordem hierárquica • Critérios de divisão: áreas e classes • Entra a provisória lista de funcionalidades • Sai uma detalhada lista de funcionalidades

Plan by Feature Planejar por Funcionalidade • Desenho por funcionalidade e Construção por funcionalidade • Sequência e conjunto inicia de datas • A cada chefe de programação é fornecida uma lista de funcionalidades a serem desenvolvidas. • Revisão e aprovação do desenvolvedor e chefe de design. • Previsão de término do projeto

Design by Feature Detalhar por Funcionalidade • Desempenho da estrutura para cada funcionalidade. • Análise do processo • Identificação das classes envolvidas • Dependendo da complexidade da funcionalidade, o programador chefe poderá consultar os especialistas da área • O programador consulta o diagrama sequencial • A equipe de programadores toma nota daquilo que é relevante

Build by Feature Desenvolver por Funcionalidade • Implementar classes e métodos; • Inspecionar código: o desenvolvedor “convida” outro para verificar seu código; • Testes unitários, realizados pelo próprio desenvolvedor; • Promover a build, se a classe estiver testada e inspecionada;

Percentual de tempo gasto em cada funcionalidade • Levantamento do domínio da aplicação = 1%; • Projeto = 40%; • Inspeção do projeto = 3%; • Desenvolvimento = 45%; • Inspeção do código = 10%; • Integração = 1%.

Afinal, por que usar FDD? • Planejamento e modelo na medida certa. Sem exageros, mas também sem ausência; • Os processos favorecem a aproximação de especialistas, gerentes e desenvolvedores; • Permite realizar entregas frequentes ao cliente; • A inspeção de código e de design permite obter qualidade no produto final.

Vantagens • Por cada feature ser pequena, coletar os requisitos se torna mais fácil, pois estes podem ser melhor descritos, e durante a revisão, se torna mais fácil encontrar ambiguações e erros. • Features podem ser organizadas de forma hierárquica; • Menor custo humano, dado que cada feature pode ser desenvolvida de maneira independente, e ser lançada em média a cada 2 semanas. • Como cada feature é algo reduzido, inspecionar erros em seu design ou em seu código é uma tarefa mais fácil (menor custo de tempo).

Desvantagens • Questionamento sobre efetividade/aplicabilidade do FDD. • Não existe um consenso do tamanho que cada feature deve ter. • Manutenção.

Referências • http: //www. slideshare. net/ruancarvalho/featuredrivendevelopment-viso-geral • http: //paginas. fe. up. pt/~aaguiar/es/artigos%20 finais/es_final _22. pdf • http: //www. devmedia. com. br/introducao-ao-fdd-featuredriven-development/27971

OBRIGADO!