Please enable JavaScript.
Coggle requires JavaScript to display documents.
FDD, Processos - Coggle Diagram
FDD
ETVX
O FDD é composto por cinco etapas, e é indicado que cada iteração siga o padrão de etapas chamado de ETVX, oriundo de:
● Entrada (Entry),
● Tarefa (Task),
● Verificação (Verification) e
● Saída (Exit).
-
Saída
(Exit)
especifica os critérios de saída, definindo os produtos tangíveis
-
-
Características
● Uma feature “é uma funcionalidade com valor para o cliente que pode ser desenvolvida em duas ou menos semanas”;
● Um dos objetivos do FDD é entregar para o cliente funcionalidades com rapidez;
○ Em um período fixo de tempo, em geral, duas semanas ou menos. Exemplo:
■ Calcular o valor de uma compra;
■ Calcular itens em estoque;
■ Listar fornecedores locais.
Um projeto que segue a metodologia FDD deve ser estruturado de acordo com as seguintes premissas:
● Um único programador é responsável pela funcionalidade desenvolvida
○ ATENÇÃO: Esse é um ponto que diverge do XP!!!
○ No FDD é incentivado que UM desenvolvedor seja o único responsável pela funcionalidade que este desenvolve, já no XP, o código deve ser comunitário.
Um projeto que segue a metodologia FDD deve ser estruturado de acordo com as seguintes premissas:
● Desenvolvimento por funcionalidades;
○ Com base na lista de funcionalidades, deve-se planejar por funcionalidade, mas este planejamento deve ser incremental.
CONTEXTO
● O FDD surgiu em Singapura, entre os anos de 1997 e 1999;
○ Foi desenvolvido por Peter Coad e Jeff De Luca e publicado em 1999 no livro “Java Modeling in Color with UML”.
● Criada anteriormente ao Manifesto Ágil (o manifesto ágil ocorreu apenas em 2001) mas modificada após o manifesto;
● Apesar de ter algumas diferenças entre o FDD e o XP, é possível utilizar as melhores práticas de cada metodologia.
I. Propõe um equilíbrio entre filosofias tradicionais e ágeis;
II. É prático para o trabalho com projetos iniciais, com grandes equipes, ou projetos com codificações já existentes.
III. Lema do FDD: “Resultados frequentes e funcionais”
Em projetos maiores e que possuam tal necessidade, outros papéis podem ser incluídos no projeto, tais como:
Administrador de Sistema
Configura, gere e resolve problemas nos servidores e redes utilizados durante o desenvolvimento.
Gerente de Domínio
É o líder do domínio, resolve divergências de opinião com relação aos requisitos do sistema.
-
Guru da Linguagem
Um membro da equipe com amplo conhecimento na linguagem ou tecnologia usada no desenvolvimento do sistema.
No FDD, uma pessoa pode desempenhar mais de um papel e um papel pode ser desempenhado por mais de uma pessoa.
Papéis FDD
- Gerente de Projeto
Líder administrativo e financeiro do projeto: tem a palavra final no que se trata de escopo, cronograma e recursos do projeto.
● É quem trata das questões administrativas do projeto;
● Autonomia para decidir o que deverá ser feito;
● Prioriza toda e qualquer funcionalidade que entregue valor e consiga ser realizada durante um período de tempo pré-determinado.
É o responsável também por toda a equipe, assegurando boas condições de trabalho para aumentar o rendimento de todos os envolvidos, além de decidir o que será realizado durante a iteração definida.
- Gerente de Desenvolvimento
É o líder nas atividades diárias do desenvolvimento. É responsável por resolver qualquer tipo de conflito que venha a ocorrer dentro da equipe.
● É responsável por retirar qualquer impedimento que a equipe possua,
● Faz com que as reuniões necessárias aconteçam (principalmente com os clientes/usuários finais);
● Deve avaliar se o código realizado pelo time de desenvolvimento está nos padrões do projeto.
Caso não esteja, ele deverá apontar melhorias ou sugestões que colaborem no amadurecimento da equipe, em relação ao código e também de time.
- Proprietários de código
(programadores-chefe)
São os responsáveis pela modelagem e desenvolvimento de novas funcionalidades de um software.
● A principal atividade de um desenvolvedor/programador é a implementação das features definidas ou pelo Gerente de Projetos ou pelo Gerente de Desenvolvimento.
No FDD, o código deve ser realizado apenas por um desenvolvedor, ou seja, iniciado e terminado pelo mesmo programador.
5. Especialistas do Domínio (negócio)
Qualquer pessoa que tenha o melhor conhecimento sobre o software em particular, e pode ajudar as Equipes a entendê-lo.
● Responsabilidade de adquirir e transmitir informações a respeito do funcionamento dos requisitos do sistema.
Podem ser usuários, clientes, patrocinadores (servem como base de conhecimento dos desenvolvedores).
- Arquiteto-chefe
É responsável pela modelagem do projeto. Deve auxiliar a equipe de desenvolvedores e contribuir na construção do software.
● É responsável por questões relacionadas à definição dos componentes de software, suas propriedades externas, e seus relacionamentos com outros softwares.
Busca facilitar a organização dos componentes de um software e melhorar a flexibilidade e portabilidade do sistema, gerando mais facilidade de manutenção.
Fases
Duas Fases:No FDD, o planejamento é realizado por processos, onde o conjunto de processos se divide em duas fases:
- Concepção e Planejamento: Pensar um pouco antes de fazer (tipicamente de 1 a 2 semanas);
- Construção: Fazer de forma iterativa (tipicamente em iterações de 2 semanas).
Está sendo eficaz para projetos em que o processo de desenvolvimento é uma incógnita, cheio de mudanças.
Aqui, o projeto como um todo tem muita importância, mas o processo é separado por áreas.
Processos
-
2. Construir a Lista de Funcionalidades
➔ Nesta fase é criada uma lista de funcionalidades do sistema, descrevendo e identificando a área de domínio de cada uma delas.
◆ As funcionalidades são importantes para o processo porque cada uma é uma pequena tarefa que precisa ser implementada ao projeto.
➔ Os itens de funcionalidade não devem levar mais de duas semanas para serem concluídos e são ordenados na lista por ordem de prioridade no desenvolvimento.
➔ Por exemplo, uma lista de funcionalidades pode conter os seguintes itens: “validar a senha do usuário”, “liberar o login” e “gerar relatório de vendas”.
5. Construir por Funcionalidade
➔ Após a modelagem passar por diversos testes, o código começa a ser implementado no sistema. Dessa forma, as funcionalidades são incorporadas e já podem ser colocadas em prática.
◆ Efetivado o código, ele é escrito e essa funcionalidade é concluída.
➔ Fazem parte dessa fase a implementação das regras de negócio das classes, a inspeção do código, a condução dos testes unitários e o release da funcionalidade.
4. Detalhar por Funcionalidade
➔ Assim como na primeira fase, nessa etapa é criada uma modelagem com as funcionalidades a serem desenvolvidas.
◆ A diferença dessa modelagem é que o programador chefe a cria de acordo com uma funcionalidade específica e a divide em classes, métodos e atributos.
➔ Quando finalizada, a funcionalidade passa por testagens da equipe desenvolvedora.
3. Planejar por Funcionalidade
➔ De acordo com a lista de funcionalidades é feito o planejamento de desenvolvimento delas.
➔ Para cada funcionalidade são designados programadores-chefe que ficarão responsáveis por algumas classes ou códigos.
➔ A partir disso são formadas as equipes de planejamento e cada integrante da equipe é encarregado de uma parte do projeto.
1. Desenvolver um Modelo Abrangente
➔ O primeiro momento é de conhecer para analisar o sistema e o contexto em que ele está inserido.
◆ A partir disso são estudados os domínios do sistema e um modelo geral é desenvolvido com base nesses estudos.
➔ Criado o modelo geral, pequenas equipes são responsáveis por criar uma modelagem superficial para cada área de domínio do sistema.
◆ Cada modelo criado é revisado por outros membros do projeto, que não fazem parte da equipe que criou o modelo, a fim de escolher o melhor modelo de domínio para cada área.
➔ Assim, ao final do processo os modelos escolhidos são unificados no modelo geral do domínio do sistema e o trabalho é iniciado.