Blog

FDD (Desenvolvimento Guiado por Funcionalidades, 1997) INTRODUÇÃO O Desenvolvimento Guiado por Funcionalidades (FDD) é uma metodologia ágil para gerenciamento e desenvolvimento de software nascida em 1997 em Cingapura, a partir do Método Coad desenvolvido por Peter Coad e das técnicas de gerenciamento de projetos de Jeff de Luca. DEFINIÇAO E OBJETIVOS Trata-se de uma metodologia completa para análise, desenho p e programaçao por o iterativo e increment ten tangíveis e funcionais Desenvolve projetos simplificadas e apres OF3 gerenciamento sultados frequentes, ividades dos úteis em até duas semanas.

Dentre as principais características estão: – Blocos pequenos de funcionalidades, o que é sempre valorizado pelo cliente; – Planejamento detalhado com guias; – Apresenta relatórios precisos, facilitando o entendimento dos resultados pelo cliente; – Monitoramento detalhado do projeto, com apresentação de resumos para clientes e para gerentes; Logo no início do projeto é fornecido formas para que o cliente perceba se o software irá atender todas suas necessidades. O FDD possui um ciclo de vida curto e é indicado para sistemas ue podem mudar de requisitos rapidamente.

Por se tratar de um modelo iterativo e incremental, não possui suporte para o modelo cascata, portanto não é recomendado para sistemas com iteração. Para definição das etapas é necessário definir os critérios de entradas para cada etapa (Entry), listar as tarefas que deverão ser realizadas (Task), depois especificar os tipos de avaliações e inspeções que deverão ser realizados no projeto e no código (Verification), e por fim, especificar os critérios de saida (Exit).

As etapas do FDD são: . Desenvolver um modelo abrangente: desenvolvimento de técnicas para o entendimento do domínio de negócio em questão, tendo como resultado um modelo de objetos de alto nível que orientará a equipe no processo de construção; 2. Construir uma lista de funcionalidades: apresenta as áreas de negócio, as atividades de negócio e as funcionalidades, formando uma hierarquia de funcionalidades que representará o produto a ser construído; 3.

Planejar por funcionalidade: elabora um plano de desenvolvimento baseado na estimativa de complexidade das uncionalidades, a prioridade e o valor do negócio para o cliente; 4. Detalhar por funcionalidade: detalha os requisitos para a codificação de cada funcionalidade e inspeciona as funcionalidades para poder criar um modelo mais detalhado e códigos prontos para serem preenchidos; e 5. Construir por funcionalidade: o código é preenchido, depois testado e inspecionado para que seja apresentado o produto ao cliente com qualidade pronto para ser utilizado.

Neste processo de desenvolvimento de software os principais apéis dentro da equipe são: – Arquiteto chefe, responsável em guiar os desenvolvedores; – Programador chefe, responsável por liderar a equipe, distribuir as tarefas entre os desenvolvedores e ajuda no planejamento e na ordem das fu distribuir as tarefas entre os desenvolvedores e ajuda no planejamento e na ordem das funcionalidades a serem implementadas; – Experts em dom[nio, responsável pelas informações necessárias a respeito de área de domino, visão geral e modelagem; – Desenvolvedor, responsável por uma ou mais classes chave no esenvolvimento de cada funcionalidade, coordenado por um programador chefe (que também é desenvolvedor); – Gerente de projeto, gerencia todo o projeto e ajuda a planejar a ordem que as funcionalidades serão implementadas; e – Gerente de desenvolvimento, também ajuda a planejar a ordem que as funcionalidades serão implementadas, entre outras tarefas gerenciais.

CASOS DESENVOLVIDOS UTILIZANDO FDD – website do projeto Realise (04/2011); – Guia Esquenta U2, da empresa TAM (03/2011 – Portal do produto Nova Schin (08/2010); – Portal do Empreendedor, do SEBRAE (07/2010); #pedepraentrar, da empresa NET (1 0/2010); entre outros. PONTOS POSITIVOS – Modelagem de objetos do domínio (negócio); – Desenvolvimento por funcionalidade; – Posse individual de classe (código); – Time de funcionalidades; – Inspeções de modelo e de código; – Builds regulares; – Gerenciamento de configuração; e – Relatório / visibilidade de resultados. PONTOS NEGATIVOS – Não prevê a escolha de tecnologias e ferramentas; – Não é possível a escolha e definição da interface do usuário, testes de sistema e de carga- – Não faz o gerenciamento 3