FDD: Processo 4: DPF-Detalhar por Funcionalidade

É uma atividade executada para cada funcionalidade, para produzir o pacote de projeto (design) para ela.

Certo número de funcionalidades são agendadas para desenvolvimento ao atribuí-las a um programador-líder. Ele seleciona as funcionalidades para desenvolvimento a partir de sua “caixa de entrada” de funcionalidades atribuídas. Ele pode escolher diversas funcionalidades que utilizem as mesmas classes (e portanto, desenvolvedores). Operacionalmente, com freqüência acontece o caso de “conjuntos” de funcionalidades serem agendados para desenvolvimento de uma vez pelo programador-líder. Tal conjunto é chamado de Pacote de Trabalho do Programador-Líder (PTPL).

O programador-líder, então, forma uma equipe de funcionalidades, identificando os proprietários das classes (desenvolvedores) que provavelmente serão envolvidos no desenvolvimento das funcionalidades que ele selecionou. Esta equipe produz o(s) diagrama(s) de seqüência para a(s) funcionalidade(s) atribuída(s). O programador-líder, então, refina o modelo de objetos, baseado no conteúdo do(s) diagrama(s) de seqüência. Os desenvolvedores escrevem os prefácios das classes e métodos. Realiza-se uma inspeção no projeto (design).


Critérios de Entrada


Atividades


Formar a Equipe de Funcionalidades
Responsabilidade: Programador-Líder
Obrigatória

O programador-líder identifica as classes que provavelmente serão envolvidas no projeto deste conjunto de funcionalidades e, consequentemente, atualiza o banco de dados de funcionalidades. Da lista de proprietários de classes, o programador-líder identifica os desenvolvedores necessários para formar a equipe de funcionalidades. Como parte deste passo, o programador-líder cria um novo pacote de projeto (design) para a(s) funcionalidade(s) como parte do Pacote de Trabalho.


Estudo Dirigido do Domínio
Responsabilidade: Especialista no Domínio
Opcional

O especialista no domínio apresenta uma visão geral da área do domínio para a funcionalidade a ser projetada. Essa apresentação deve também incluir informação que estiver relacionada a esta funcionalidade, mas que não seja necessariamente uma parte de sua implementação. Esta é uma atividade opcional, baseada na complexidade da funcionalidade e/ou de suas interações.


Estudar a Documentação de Referência
Responsabilidade: Equipe de Funcionalidades
Opcional

A equipe de funcionalidades estuda o(s) documento(s) de referência para a funcionalidade a ser projetada, todos os memorandos de confirmação, desenhos de telas, especificações de interface com sistemas externos e qualquer outra documentação de suporte. Esta é uma atividade opcional, baseada na complexidade da funcionalidade e/ou de suas interações.


Desenvolver o(s) Diagrama(s) de Seqüência
Responsabilidade: Equipe de Planejamento
Opcional

Desenvolver o(s) diagrama(s) de seqüência necessário(s) para a funcionalidade a ser projetada. Os arquivos do(s) diagrama(s) devem ser submetidos ao sistema de controle de versões. Quaisquer projetos (designs) alternativos, decisões de projeto, esclarecimentos de requisitos e comentários também são registrados e descritos na seção de alternativas de projeto (design) do Pacote de Projeto (Design).


Refinar o Modelo de Objetos
Responsabilidade: Programador-Líder
Obrigatória

O programador-líder cria uma área para a equipe de funcionalidades para a(s) funcionalidade(s). Esta área pode ser um diretório em um servidor de arquivos ou um diretório em seus próprios computadores, que são copiados para o servidor pelo programador-líder quando necessário, ou utiliza-se uma área de trabalho fornecida pelo sistema de controle de versões. O propósito da área da equipe de funcionalidades é para que o trabalho em andamento possa ser compartilhado e estar visível pelos membros da equipe de funcionalidades, mas invisível para o resto do projeto.

O programador-líder refina o modelo para adicionar novas classes, métodos, atributos e/ou fazer alterações aos já existentes, baseado no(s) diagrama(s) de seqüência definido(s) para a(s) funcionalidade(s). Isto resulta na atualização dos arquivos fontes da linguagem de implementação na área da equipe de funcionalidades. O programador-líder cria diagramas do modelo num formato publicável. Esses arquivos devem ser submetidos ao sistema de controle de versões e publicados na intranet do projeto.


Escrever Prefácios de Classes e Métodos
Responsabilidade: Equipe de Funcionalidades
Obrigatória

Utilizando os arquivos fontes da linguagem de implementação atualizados pela atividade “Refinar o Modelo de Objetos”, que estão na área da equipe de funcionalidades, o proprietário das classes escreve os prefácios de classe e métodos para cada item definido pela funcionalidade e pelo(s) diagrama(s) de seqüência. Isto inclui tipos de parâmetros, tipos de retorno, exceções e mensagens. Uma vez que cada desenvolvedor completou sua tarefa, o programador-líder gera a documentação da API usando e a submete para publicação na intranet do projeto.


Verificação


Inspeção do Projeto (Design)
Responsabilidade: Equipe de Funcionalidades
Obrigatória

Realiza-se uma inspeção no projeto (design) com os membros da equipe de funcionalidades ou com outros membros do projeto. A decisão de inspecionar com a equipe de funcionalidades ou com outros membros do projeto cabe ao programador-líder. Após o aceite, uma lista de tarefas é gerada para cada classe afetada, e cada membro da equipe inclui suas tarefas à sua agenda de tarefas. O programador-líder também deve combinar as alterações da área compartilhada pela equipe de funcionalidades de volta ao sistema de controle de versões.


Critérios de Saída

O resultado do processo é um Pacote de Projeto (Design) inspecionado com sucesso. O pacote de projeto consiste em:

  • Uma capa com comentários, que completa e descreve o pacote de projeto de tal forma a ser suficiente para futuros revisores;
  • Os requisitos referenciados (se houver) na forma de documentos e de todos os memorandos de confirmação relacionados, e documentação de apoio;
  • O(s) diagrama(s) de seqüência;
  • Alternativas de projeto (design) (se houver);
  • O modelo de objetos com classes, métodos e atributos novos/atualizados;
  • A saída gerada pela para os prefácios de classes e métodos, criados ou modificados por esse projeto (design);
  • Lista de tarefas e agendamentos para itens de ação nas classes afetadas para cada membro da equipe.