Engenharia de Software Feature Driven Development

2. Engenharia de SoftwareFeatureDrivenDevelopment Allyson José Edivânia Pontes Thomas Matheus Stephany Silva

3. 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”.

4. 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.

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

6. Agentes e Atores

7. 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.

8. 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.

9. Ciclo de Vida do Projeto Requisitos Construir Listas de Features Desenvolver um modelo abrangente Planejar por Feature Construir por Feature Detalhar por Feature Produto

10. DevelopanOverall ModelDesenvolvimento de Modelo Abrangente • O cliente indica quais os requisitos que 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

11. Build byFeaturesListConstruçã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

12. PlanbyFeaturePlanejar 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

13. Design byFeatureDetalhar 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

14. Build byFeatureDesenvolver 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;

15. 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%.

16. 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.

17. 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).

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

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

20. OBRIGADO!