Please enable JavaScript.

Coggle requires JavaScript to display documents.

FDD - Coggle Diagram

- - - - CLF (Construir a Lista de Funcionalidades): Também se trata de um processo executado apenas no inicio do projeto. E formado por um time para a lista de funcionalidades, que normalmente é composto pelos programadores-chefes que participaram do processo anterior e é construída uma lista de funcionalidades. Utilizando as partes do produto que foram identiﬁcadas no processo anterior, chamadas aqui de áreas de negócio, o grupo deve identiﬁcar às atividades dessas áreas e a partir dessas atividades, as funcionalidades que as constituem.
        
        PPF (Planejar por Funcionalidade): Também sendo um processo abrangente, é executado somente uma vez no inicio do projeto. Durante esse processo é formado o time de planejamento. Esse time faz a sequência do desenvolvimento do projeto se baseando em suas dependências, na equipe de desenvolvimento, na carga horária e na complexidade das funcionalidades. Depois são atribuídas aos programadores-chefes responsabilidades sobre um conjunto de atividades de negócio, que serão responsáveis por toda as funcionalidades que a compõe. Então são atribuídos ”donos”, programadores, as classes, que serão responsáveis pela manutenção delas. Assim, as classes são distribuídas com base na experiência de cada programador.
  - - - DPF (Detalhar por Funcionalidade): Esse processo, e o processo seguinte, são executados uma vez para cada funcionalidade. Agora, formam-se as equipes de funcionalidades, onde o programador-chefe chama os ”donos” de cada classe para participar da equipe. Dependendo do quão complexa seja a funcionalidade, o programador chefe pode convocar um especialista de negócio para que este conduza um novo Domain Walkthrough (Estudo dirigido sobre o domínio) para a equipe, para não ﬁcar dúvidas a respeito daquela funcionalidade em si. Ainda dependendo do quão claro ﬁcou para o time sua função, pode ser reservado um tempo para ser estudada a documentação de negócio e as anotações relacionadas àquela funcionalidade. E feito então um diagrama de sequência relacionado àquela funcionalidade e é reﬁnado o modelo abrangente, já incluindo métodos e atributos nas classes envolvidas nela. Com essas informações, cada programador cria os prólogos de suas classes, com cabeçalhos de métodos com tipagem de parâmetros, atributos e outros, não fazendo nenhuma implementação ainda. Então, o programador-chefe dessa funcionalidade convida outro membro da equipe para avaliar o desenvolvimento de sua classe durante o processo.
        
        CPF (Construir por Funcionalidade): Este processo também será executado uma vez para cada funcionalidade, como o anterior. São implementadas as classes e métodos de acordo com a visão abrangente e o detalhamento realizado nos processos anteriores. Então, cada desenvolvedor convida um membro de outra equipe para avaliar aquilo que foi desenvolvido em sua classe durante este processo. E após isso os desenvolvedores ficam responsáveis por testar suas classes e métodos e assegurar que as necessidades do negocio sejam alcançadas. E com as classes testadas e funcionando, pode ser então feito o build.
- - - - XP usa ciclos de desenvolvimento muito curtos (geralmente de 1 a 2 semanas), com entregas frequentes de pequenas melhorias ou novas funcionalidades.
        
        XP tem uma estrutura de equipe menos formal, com papéis como Desenvolvedores, Clientes (ou Representantes do Cliente), e Testadores, promovendo a colaboração entre todos os membros.
  - - - FDD usa iterações curtas, mas seu foco é entregar funcionalidades completas e significativas a cada iteração.
        
        FDD define papéis específicos como o Arquiteto-Chefe, o Gerente de Projeto, e o Dono da Lista de Funcionalidades.
- - - - RUP exige uma extensa documentação e segue uma abordagem muito estruturada. Inclui uma série de disciplinas e atividades detalhadas.
        
        RUP divide o processo de desenvolvimento em quatro fases: Iniciação, Elaboração, Construção e Transição. Cada fase tem objetivos específicos e culmina em marcos importantes.
        
        RUP faz uso extensivo de UML (Unified Modeling Language) para a modelagem e documentação dos requisitos, design e arquitetura do sistema.
        
        RUP define claramente papéis e responsabilidades para todos os membros da equipe, incluindo analistas, desenvolvedores, testadores e gerentes de projeto.
  - - - FDD é menos formal em termos de documentação comparado ao RUP. A ênfase está na entrega rápida de funcionalidades.
        
        FDD utiliza iterações curtas para entregar funcionalidades incrementais, mantendo um foco constante no progresso visível e tangível.
        
        Inclui uma fase inicial de modelagem do domínio para identificar e priorizar as funcionalidades a serem desenvolvidas.
        
        FDD define papéis específicos, como Arquiteto-Chefe, Gerente de Projeto e Dono da Lista de Funcionalidades.