Apresentação fdd
•Als PPT, PDF herunterladen•
5 gefällt mir•3,973 views
O documento descreve a metodologia de Desenvolvimento Guiado por Funcionalidades (FDD), incluindo seus conceitos, características, práticas e processos. O FDD enfatiza a entrega frequente de software funcional ao cliente através do desenvolvimento incremental por características (funcionalidades), com foco no envolvimento do cliente e na qualidade do código.
![FDD FEATURE DRIVEN DEVELOPMENT ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (16)
Ähnlich wie Apresentação fdd
Ähnlich wie Apresentação fdd (20)
Apresentação fdd
- 1. Técnicas em Projetos de Sistemas Professor: Marinaldo
- 9. ESTRUTURA
- 11. Os 5 processos do FDD 1.Desenvolver um Modelo geral 2. Construir uma lista de características 3. Planejar através de característica 4. Projetar através de característica 5. Construir através de característica Modelo de Objeto (mais formas do que conteúdo) Uma lista de características categorizada Um plano de desenvolvimento Um pacote de projeto (seqüências) Uma função do cliente completada (mais conteúdo do que forma)
- 14. FDD Processo #1- Atividades Formar a Equipe de Modelagem Estudo dirigido sobre o Domínio Estudar Documentos Desenvolver pequenos Modelos de Grupo Desenvolver um Modelo da Equipe Refinar o Modelo Geral Escrever Anotações do Modelo
- 17. FDD Processo #2 - Atividades Formar a Equipe da Lista de Características Construir a lista de características
- 20. FDD Processo #3 - Atividades Formar a Equipe de Planejamento Determinar a Seqüência de Desenvolvimento Atribuir Conjuntos de Características para Programadores Chefes Atribuir Classes para Desenvolvedores
- 23. FDD Processo #4 - Atividades Formar a Equipe de Características Estudo do Domínio Estudar Documentos de Referências Desenvolver Diagramas de Seqüência Refinar o Modelo Descrever os prefácios de classes e métodos
- 26. FDD Processo #5- Atividades Codificar Testar Unidades Inspecionar Código Promover à versão atual (Build) Ponto de integração para a funcionalidade inteira
- 29. Os seis marcos do FDD Projetar pelas características Construir pelas características Análise do domínio Projeto Inspeção do projeto Código Inspeção do código Geração de build 1% 40% 3% 45% 10% 1%
- 30. Relatando resultados Dez 2001 Porcentagem completa: Status Completo: Completo Mês de conclusão Exemplo: Conjunto de características: Fazendo avaliação de produtos – Trabalho em progresso CP-1 é o programador chefe inicial (14) esse conjunto de características possui 14 características Conjunto de características está 75% completado A conclusão é para dezembro de 2001 Status Geral: MY Barra de progresso Trabalhos em progresso Atenção (ie, atrasado) Completo Fazendo avaliação de produtos (14) 75% Não iniciado CP-1
Hinweis der Redaktion
- FDD includes 5 processes. The first 3 occur once per project the last 2 are repeated for each feature. A FDD inicia com a criação de um modelo de objetos do domínio do problema, em colaboração com os especialistas no domínio. Usando a informação vinda da atividade de modelagem e de quaisquer outras atividades de coleta de requisitos que já possam ter ocorrido, os desenvolvedores prosseguem para a criação da lista de funcionalidades. A seguir, um plano primordial é elaborado e atribui-se responsabilidades. Então, equipes pequenas e formadas dinamicamente desenvolvem as funcionalidades, realizando repetidamente iterações de projeto ( design ) e construção, que duram não mais do que duas semanas e, geralmente, são muito mais curtas.
- A FDD é composta de cinco processos. Cada um deles é descrito em não mais do que duas páginas de papel tamanho carta, frente-e-verso. Cada descrição de processo possui uma seção de entrada, com uma visão geral do processo e uma ou mais condições que precisam ser satisfeitas antes que o processo seja iniciado. A seguir, cada descrição possui uma lista de tarefas a serem realizadas, juntamente com o papel responsável no projeto para a realização da tarefa, e uma indicação se a tarefa é opcional ou obrigatória (exigida). Uma seção de verificação resume como as saídas do processo são checadas quanto à qualidade satisfatória. Finalmente, uma seção de saída lista os produtos do processo. Esta estrutura de Entrada, Tarefas, Verificação e Saída (ETVS) foi sugerida para Jeff De Luca por M. A. Rajashima, o líder de Garantia da Qualidade em Singapura, para a parte inicial do projeto.
- Realiza-se um estudo dirigido sobre o escopo do sistema e seu contexto. Então, são realizados estudos mais detalhados sobre o domínio do negócio para cada área a ser modelada. Após cada estudo dirigido sobre o domínio, pequenos grupos são formados por membros do domínio do negócio sendo estudado e por desenvolvedores, que comporão seus próprios modelos que satisfaçam o domínio em questão. Os pequenos grupos apresentam seus modelos para serem revisados por parceiros e para discussão. Um dos modelos propostos, ou uma combinação dos modelos, é selecionada por consenso, tornando-se, assim, o modelo para aquela área do domínio do negócio. Realiza-se, então, uma combinação do modelo da área do domínio dentro de um modelo abrangente, ajustando a forma do modelo se for necessário.
- A equipe de modelagem é composta de membros permanentes das áreas do domínio do negócio e de desenvolvimento, especificamente os especialistas no domínio e os programadores-chefes. É feito um rodízio com os outros integrantes do projeto através das sessões de modelagem, de modo que todo mundo tenha a chance de participar e ver o processo em ação.
- Uma equipe, geralmente composta apenas por programadores-chefes do processo nº 1, é formada para decompor funcionalmente o domínio em áreas , atividades de negócio dentro delas e passos dentro de cada atividade de negócio, formando assim a lista categorizada de funcionalidades. A categorização de mais alto nível para a lista de funcionalidades vem da divisão do domínio feita pelos especialistas do domínio no processo nº 1.
- A equipe é composta por programadores-chefes da equipe de modelagem do processo nº 1.
- O gerente de projeto, o gerente de desenvolvimento e os programadores-chefes planejam a ordem na qual as funcionalidades serão implementadas, baseada nas dependências entre elas, na carga de trabalho da equipe de desenvolvimento e também na complexidade das funcionalidades a serem implementadas. As principais atividades neste processo não são uma seqüência estrita. Como muitas atividades de planejamento, elas são consideradas em conjunto, com refinamentos feitos a partir de uma ou mais atividades e então considerando os outros novamente. Um cenário típico é levar em conta a seqüência de desenvolvimento, depois levar em conta a atribuição das atividades de negócio aos programadores-chefes e, ao fazê-lo, considerar quais das classes principais (apenas) são atribuídas a quais desenvolvedores (lembrar que o programador-chefe também é um desenvolvedor). Quando esse equilíbrio for alcançado, e a seqüência de desenvolvimento e a atribuição das atividades de negócio aos programadores-chefes estiver essencialmente completada, então a posse das classes estará completada (além das classes principais que já foram consideradas para posse).
- A equipe de planejamento é composta pelo gerente de desenvolvimento e pelos programadores-chefes.
- É uma atividade para cada funcionalidade, para produzir o pacote de projeto (design) para a funcionalidade. Certo número de funcionalidades são agendadas para desenvolvimento ao atribuí-las a um programador-chefe. 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-chefe. Tal conjunto é chamado de Pacote de Trabalho do programador-chefe. O programador-chefe, 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-chefe, 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).
- O programador-chefe 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-chefe identifica os desenvolvedores necessários para formar a equipe de funcionalidades.
- É uma atividade para cada funcionalidade, para produzir uma função com valor para o cliente (funcionalidade). Começando com o pacote de projeto (design), os proprietários de classes implementam os itens necessários para que suas classes suportem o projeto para esta funcionalidade. O código desenvolvido passa pelo teste de unidade e pela inspeção – a ordem aqui é determinada pelo programador-chefe. Após passar pela inspeção, o código é promovido à versão atual (build).
- Para patrocinadores, alta gerência e clientes