FDD

1° FASE- Concepção e Planejamento

2° FASE- Construção

CLP (Class, Layer, and Package):

PPF (Preliminary Planning and Feature List):

DMA (Domain Modeling Activities):

Objetivo: Criar uma visão compartilhada do domínio do problema que o sistema deve resolver, envolvendo toda a equipe.

Atividades:

Mapeamento de Conceitos: Identificação e definição de conceitos-chave e como eles se relacionam, criando um esboço inicial do modelo de domínio.

Criação de Diagramas de Domínio: Desenvolvimento de diagramas que representam visualmente os conceitos e suas relações, ajudando a visualizar o sistema de forma estruturada.

Workshops de Modelagem de Domínio: Facilitam a participação dos membros da equipe para capturar o conhecimento do domínio e identificar os principais objetos de negócio.

Objetivo: Refinar o modelo de domínio inicial em termos de classes, camadas e pacotes para preparar a base da arquitetura do sistema.

Atividades:

Identificação de Classes: Definição das principais classes que compõem o sistema, mapeando os conceitos do domínio para classes de software.

Estruturação em Camadas: Organização das classes em camadas lógicas, como camada de apresentação, camada de negócio e camada de dados, para garantir uma arquitetura modular e escalável.

Organização em Pacotes: Agrupamento das classes em pacotes, facilitando a gestão e a manutenção do código, além de promover a reutilização e a coesão.

Objetivo: Planejar preliminarmente o desenvolvimento do sistema e criar uma lista de funcionalidades que orientará o trabalho das próximas fases.

Atividades:

Criação da Lista de Funcionalidades: Detalhamento das funcionalidades do sistema, dividindo o modelo de domínio em pequenas partes que podem ser desenvolvidas e entregues iterativamente.

Priorização e Estimativa: Avaliação e priorização das funcionalidades, considerando o valor para o negócio e a complexidade técnica, além de estimar o tempo e os recursos necessários para cada uma.

Planejamento Preliminar: Estabelecimento de uma visão geral do cronograma do projeto, identificando marcos importantes e estimando o esforço necessário para as principais fases.

DPF (Detailed Planning and Feature Breakdown):

CPF (Class Ownership and Packaging):

Objetivo: Detalhar o planejamento do projeto e decompor o modelo geral em funcionalidades específicas e gerenciáveis que podem ser desenvolvidas iterativamente.

Objetivo: Definir a propriedade das classes e organizar o código em pacotes coerentes, promovendo a responsabilidade e a manutenção eficiente do sistema.

Atividades:

Especificação das Funcionalidades: Cada funcionalidade é detalhada, incluindo uma descrição clara, critérios de aceitação e dependências com outras funcionalidades. Isso garante que todas as partes interessadas compreendam o escopo e os requisitos de cada funcionalidade.

Planejamento de Iterações: As funcionalidades são organizadas em iterações, priorizando aquelas que agregam mais valor e/ou são mais críticas para o sucesso do projeto. Estima-se o esforço necessário para desenvolver cada funcionalidade, levando em conta a complexidade e os recursos disponíveis.

Elaboração Detalhada das Funcionalidades: A equipe analisa o modelo de domínio e identifica funcionalidades específicas (features) que o sistema deve oferecer. Cada funcionalidade representa uma pequena parte do comportamento do sistema que agrega valor ao usuário final.

Atividades:

Organização em Pacotes: As classes são organizadas em pacotes, de acordo com sua funcionalidade e camada lógica no sistema. Isso facilita a gestão do código, promove a coesão dentro dos pacotes e minimiza as dependências entre eles.

Definição de Interfaces e Contratos: Os desenvolvedores definem interfaces claras e contratos entre as classes e pacotes, garantindo que a integração seja suave e que os módulos possam ser desenvolvidos de forma independente.

Atribuição de Propriedade de Classes: Cada classe identificada durante a modelagem de domínio é atribuída a um desenvolvedor específico ou a uma pequena equipe. O proprietário da classe é responsável por sua implementação, manutenção e qualidade. Isso incentiva a responsabilidade individual e o conhecimento aprofundado do código.

Padrão ETVX

RUP

FDD

Vantagens e Desvantagens do FDD

Vantagens

Desvantagens

O padrão ETVX (Entry, Task, Verification, Exit) é um modelo usado para descrever processos de forma clara e estruturada. Ele define quatro componentes principais:

Entry (Entrada): Condições ou critérios que devem ser atendidos antes de iniciar a tarefa. Define os insumos necessários e o estado inicial do processo.

Task (Tarefa): Conjunto de atividades e operações que compõem o processo. Descreve as etapas específicas e como elas devem ser executadas.

Verification (Verificação): Métodos e critérios para verificar se as tarefas foram realizadas corretamente e se os resultados atendem aos requisitos estabelecidos.

Exit (Saída): Condições que devem ser atendidas para considerar a tarefa concluída. Define os resultados esperados e o estado final do processo.

Clareza e Estrutura: O foco em funcionalidades bem definidas ajuda a manter clareza e estrutura no desenvolvimento.

Entrega Contínua de Valor: Funcionalidades são entregues regularmente, proporcionando valor contínuo ao cliente.

Responsabilidade: Papéis bem definidos promovem responsabilidade e especialização.

Qualidade do Código: A ênfase na modelagem inicial e na propriedade das classes melhora a qualidade e a manutenção do código.

Planejamento Detalhado: O planejamento detalhado ajuda a prever problemas e gerenciar riscos antecipadamente.

Complexidade Inicial: A modelagem e o planejamento detalhados iniciais podem ser complexos e demorados.

Rigidez: Pode ser menos flexível em comparação com outras metodologias ágeis que se adaptam rapidamente a mudanças de requisitos.

Dependência de Especialistas: Requer especialistas em modelagem de domínio e arquitetos experientes.

Foco em Funcionalidades: Pode deixar de lado outras prioridades, como melhoria contínua e inovação técnica, se não for equilibrado adequadamente.

Tamanho da Equipe: Pode ser menos eficiente para equipes muito pequenas ou projetos menores devido à estrutura e papéis definidos.

XP

Processo Iterativo: Dividido em quatro fases principais (Iniciação, Elaboração, Construção e Transição).

Modelagem Extensiva: Enfase significativa em modelagem e documentação.

Flexibilidade de Papéis: Define papéis, mas é flexível em sua aplicação dependendo do projeto.

Disciplines: Abrange várias disciplinas, incluindo análise de negócios, design, implementação, teste e gerenciamento de configuração.

Ferramentas de Suporte: Comumente associado a ferramentas de modelagem UML e desenvolvimento baseadas em produtos Rational.

Foco em Práticas Ágeis: Prioriza práticas ágeis como programação em pares e TDD (Desenvolvimento Orientado por Testes).

Iterações Curtas: Iterações de desenvolvimento geralmente duram de 1 a 2 semanas.

Feedback Contínuo: Enfatiza o feedback constante do cliente e a adaptação rápida.

Equipe Autogerenciada: Incentiva a auto-organização e colaboração intensa da equipe.

Valores e Princípios: Baseado em valores como comunicação, simplicidade, feedback, coragem e respeito.

Foco em Funcionalidades: Prioriza o desenvolvimento de funcionalidades específicas e bem definidas.

Modelagem de Domínio: Inicia com uma modelagem abrangente do domínio.

Planejamento Detalhado: Cada funcionalidade é detalhadamente planejada antes do desenvolvimento.

Papéis Definidos: Possui papéis específicos, como Chief Architect e Feature Owner.

Processo Estruturado: Segue um processo de cinco fases (desenvolver modelo geral, construir lista de funcionalidades, planejamento por funcionalidade, design por funcionalidade, construção por funcionalidade).