Please enable JavaScript.

Coggle requires JavaScript to display documents.

Processos nas duas Fases do FDD - Coggle Diagram

- - - - Então as propostas são apresentadas e uma delas, ou uma junção de várias, é escolhida para ser o modelo. O modelo escolhido é incluso no modelo abrangente do produto. Este modelo abrangente é o resultado da junção de todos os modelos escolhidos para cada parte do negócio apresentada. São incluídas então notas e observações nesse modelo, e essas atividades vão se repetindo até que um modelo abrangente que cubra tudo aquilo que foi previsto nas partes de negócio para o produto seja encontrado.
  - - - 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.
  - - - 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.
- - - - 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.
  - - - 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.
- - - - Tarefa (Task) É composto por uma lista de tarefas a ser realizada a cada uma das fases;
        
        Verificação (Verification) Especifica tipos de avaliações e inspeções de projeto e códigos de “testes”;
        
        Saída (Exit) Especifica os critérios de saída, ou seja, os critérios de “pronto” da fase.
- - - - A documentação no FDD é menos formal e extensa, com foco na entrega de funcionalidades funcionais. A modelagem usa UML de forma leve para suportar essas entregas. O RUP, em contrapartida, possui documentação extensa e detalhada, cobrindo todos os aspectos do desenvolvimento. A modelagem utiliza UML extensivamente, promovendo uma compreensão detalhada e controlada do sistema.
        
        O envolvimento do cliente é alto no FDD, com feedback contínuo e entrega frequente de funcionalidades utilizáveis. No RUP, o envolvimento do cliente varia conforme a fase do projeto, sendo mais estruturado, com feedback nas revisões de iteração e marcos principais.
        
        A gestão de projetos no FDD é baseada em funcionalidades específicas, priorizadas e desenvolvidas iterativamente, sendo melhor para projetos de médio porte com equipes distribuídas. No RUP, a gestão é baseada em fases e disciplinas específicas, focando na gestão de riscos e qualidade, sendo adequado para projetos de grande porte e complexos, com uma estrutura que suporta a coordenação de grandes equipes.