Your SlideShare is downloading. ×
0
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Apresentação fdd
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Apresentação fdd

2,176

Published on

metodologia ageo

metodologia ageo

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,176
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
115
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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
  • Transcript

    • 1. Técnicas em Projetos de Sistemas Professor: Marinaldo
    • 2. FDD FEATURE DRIVEN DEVELOPMENT <ul><li>DESENVOLVIMENTO GUIADO POR FUNCIONALIDADE </li></ul><ul><li>Cícero Alves </li></ul><ul><li>Délio Peres Barros </li></ul><ul><li>Hussein Mohamad </li></ul><ul><li>José Emerson </li></ul><ul><li>Marlon Ribeiro </li></ul>
    • 3. HISTÓRICO <ul><li>Criado em 1997 num grande projeto de sistema de empréstimos em Java para o banco United Overseas Bank , em Singapura. </li></ul><ul><li>Problema: Após dois de consultoria, 3.500 páginas de casos de uso e um modelo de objetos com centenas de classes , foi considerado impossível . </li></ul><ul><li>Decisão: União entre a experiência de análise e modelagem orientadas por objetos de Peter Coad , e o gerencimento de projetos de Jeff De Luca . </li></ul><ul><li>Resultado: 15 meses depois da contratação da dupla, 2.000 features entregues por uma equipe de 50 pessoas . </li></ul><ul><li>Inicialmente publicada em 1999, no capítulo 6 do livro “Java Modeling In Color With UML” . </li></ul><ul><li>Em 2002, o livro “A Practical Guide To Feature Driven Development” foi publicado com a versão completa, atualizada e comentada da metodologia. </li></ul>
    • 4. CONCEITOS <ul><li>O Desenvolvimento Guiado Por Funcionalidades (FDD) é uma metodologia ágil para o processo de engenharia de software, elaborado com foco na entrega freqüente de “software funcionando” para os clientes e na utilização de boas práticas durante o ciclo de seu desenvolvimento. </li></ul><ul><li>Um fato marcante é o forte favorecimento ao envolvimento de clientes (interno ou externo) ao processo de planejamento e desenvolvimento do software . </li></ul><ul><li>Diferentemente de outras metodologias, o FDD não é extremamente focado na programação ou no modelo , mas sim utiliza o bom senso para abstrair o melhor dos dois mundos. </li></ul><ul><li>Não é uma metodologia de gerenciamento de projetos de software. Apesar de, em suas práticas, existirem atividades relacionadas a esse fim. Apresenta como foco principal cobrir o processo de engenharia de software , e não do gerencimento. </li></ul>
    • 5. CARACTERÍSTICAS <ul><li>Entrega resultados funcionais e tangíveis a cada duas semanas ou menos. </li></ul><ul><li>Pequenos blocos de funcionalidades (features) valorizados pelo cliente . </li></ul><ul><li>Planejamento detalhado e guiado para medição. </li></ul><ul><li>Rastreabilidade e relatórios precisos. </li></ul><ul><li>Monitoramento detalhado, com resumos em termos de negócio para o cliente. </li></ul><ul><li>Realiza trabalho significativo desde o início, antes de se tornar iterativa . </li></ul><ul><li>Fornece uma forma de saber, com 10%, se o plano e a estimativa são sólidos . </li></ul><ul><li>Fornece a estrutura suficiente para equipes maiores . </li></ul><ul><li>Enfatiza a produção de software de qualidade . </li></ul>
    • 6. PRÁTICAS DO FDD <ul><li>Modelagem de objetos do domínio . </li></ul><ul><li>Desenvolvimento por feature (funcionalidade). </li></ul><ul><li>Posse individual de classe (código). </li></ul><ul><li>Equipes de features (papéis por áreas de negócio ). </li></ul><ul><li>Inspeções (especificações, código, teste de unidades ). </li></ul><ul><li>Builds regulares ( geração de versões com novos features). </li></ul><ul><li>Gerenciamento de configuração . </li></ul><ul><li>Relatório /Visibilidade de resultados. </li></ul>
    • 7. CONCEITO DE FEATURE <ul><li>Característica ou funcionalidade que representem algum valor para o cliente . </li></ul><ul><li>Um feature não deve ultrapassar o tamanho de sua iteração. Deve ser pequena o suficiente para ser implementada no tempo médio de duas semanas . </li></ul><ul><li>Mapeia passos em uma atividade de negócio . Pode ser um passo de um caso de uso, ou às vezes, pode ser o próprio caso de uso . </li></ul><ul><li>Conceito muito próximo ao de um requisito funcional . </li></ul><ul><li>É representada através do template: <ação> <resultado> <objeto>. Ex: Calcular o desconto de uma venda . Listar os clientes ativos de uma empresa . </li></ul><ul><li>Sendo o conjunto de funcionalidades que será entregue para o cliente ao final de uma iteração, não deve se economizar tempo, atenção e criatividade no processo de definição das mesmas. </li></ul>
    • 8. ESTRUTURA <ul><li>FASES: </li></ul><ul><ul><li>Concepção & Planejamento: Pensar um pouco antes de fazer (entre 1 e 2 semanas). </li></ul></ul><ul><ul><li>Construção: Fazer de forma iterativa (geralmente em interações de 2 semanas). </li></ul></ul><ul><li>PROCESSOS: </li></ul><ul><ul><li>Desenvolver Um Modelo Abrangente (DMA): Análise Orientada Por Objetos. </li></ul></ul><ul><ul><li>Construir A Lista De Funcionalidades (CLF): Decomposição Funcional. </li></ul></ul><ul><ul><li>Planejar Por Funcionalidade (PPF): Planejamento Incremental. </li></ul></ul><ul><ul><li>Detalhar Por Funcionalidade (DPF): Projeto Orientado Por Objetos. </li></ul></ul><ul><ul><li>Construir Por Funcionalidade (CPF): Programação e Teste Orientado Por Objetos. </li></ul></ul>
    • 9. ESTRUTURA
    • 10. PRINCIPAIS PAPÉIS
    • 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)
    • 12. Descrição dos Processos de FDD <ul><li>Cada processo é descrito em não mais do que duas páginas de papel tamanho carta, frente-e-verso </li></ul><ul><li>Cada descrição do processo apresenta-se de acordo com a estrutura: Entrada, Tarefas, Verificação e Saídas (ETVX) </li></ul>
    • 13. FDD Processo #1: Desenvolver um modelo geral <ul><li>Adquirir conhecimento do domínio e construir o modelo geral </li></ul><ul><ul><li>Estabelecimento do “propósito de negócio” do novo sistema </li></ul></ul><ul><ul><li>Construção de um “modelo conceitual” do sistema </li></ul></ul>
    • 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
    • 15. <ul><li>Entrada </li></ul><ul><ul><li>Especialistas no domínio, programadores e arquitetos chefes são selecionados </li></ul></ul><ul><li>Saídas </li></ul><ul><ul><li>Modelo geral do domínio </li></ul></ul><ul><ul><li>Diagrama das classes principais com alguns métodos e atributos identificados </li></ul></ul><ul><ul><li>Diagramas de seqüência de algumas funcionalidades mais complexas (se houver) </li></ul></ul><ul><ul><li>Comentário sobre o modelo </li></ul></ul>FDD Processo #1: Entradas e Saídas
    • 16. FDD Processo #2: Construir lista de características <ul><li>O domínio é decomposto até chegar nas características </li></ul><ul><li>Características são agrupadas e categorizadas </li></ul><ul><li>Características são granuladas até ser necessário menos de 2 semanas pro seu desenvolvimento </li></ul>
    • 17. FDD Processo #2 - Atividades Formar a Equipe da Lista de Características Construir a lista de características
    • 18. <ul><li>Entrada </li></ul><ul><ul><li>O processo #1 ter sido concluído com sucesso </li></ul></ul><ul><li>Saídas </li></ul><ul><ul><li>Uma lista das áreas do domínio identificadas </li></ul></ul><ul><ul><li>Para cada área, uma lista de atividades de negócio (conjunto de características) </li></ul></ul><ul><ul><li>Para cada atividade, os passos a serem realizados (características) </li></ul></ul>FDD Processo #2: Entradas e Saídas
    • 19. FDD Processo #3: Planejar através de características <ul><li>Uma data de lançamento é estabelecida para o release inicial </li></ul><ul><li>A lista de características priorizadas é refinada </li></ul><ul><li>O trabalho técnico é planejado e atribuído – plano de desenvolvimento </li></ul>
    • 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
    • 21. <ul><li>Entrada </li></ul><ul><ul><li>O processo de construir a lista de características (processo #2) ter sido concluído com sucesso </li></ul></ul><ul><li>Saídas </li></ul><ul><ul><li>Atividades de negócio com datas de término </li></ul></ul><ul><ul><li>Programadores-chefes atribuídos a atividades de negócio </li></ul></ul><ul><ul><li>A lista de classes e seus donos (desenvolvedores) </li></ul></ul>FDD Processo #3: Entradas e Saídas
    • 22. FDD Processo #4: Projetar através de características <ul><li>Regras e transações são identificadas </li></ul><ul><li>O modelo da interface do usuário é esboçado </li></ul><ul><li>Diagramas de seqüência mais detalhados são produzidos </li></ul><ul><li>Especialistas são consultados para descobrir qualquer necessidade específica adicional </li></ul>
    • 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
    • 24. <ul><li>Entrada </li></ul><ul><ul><li>O processo de planejado (processo #3) ter sido concluído com sucesso </li></ul></ul><ul><li>Saídas </li></ul><ul><ul><li>Diagramas de seqüência </li></ul></ul><ul><ul><li>Projetos alternativos (caso exista) </li></ul></ul><ul><ul><li>O modelo de objeto com classes, métodos e atributos novos ou atualizados </li></ul></ul><ul><ul><li>A documentação da API do sistema </li></ul></ul><ul><ul><li>Lista de tarefas (calendário/ To-Do) </li></ul></ul>FDD Processo #4: Entradas e Saídas
    • 25. FDD Processo #5: Construir através de características <ul><li>Características são construídas implementando todas as classes e métodos necessários </li></ul><ul><li>Testes de unidades </li></ul><ul><li>Características são inseridas no build quando o teste resulta em sucesso </li></ul>
    • 26. FDD Processo #5- Atividades Codificar Testar Unidades Inspecionar Código Promover à versão atual (Build) Ponto de integração para a funcionalidade inteira
    • 27. <ul><li>Entrada </li></ul><ul><ul><li>O processo anterior ter sido concluído com sucesso </li></ul></ul><ul><li>Saídas </li></ul><ul><ul><li>Classe(s) e/ou método(s) que passaram na inspeção de código com sucesso </li></ul></ul><ul><ul><li>Classes inseridas no build </li></ul></ul><ul><ul><li>A conclusão da funcionalidade do cliente </li></ul></ul>FDD Processo #5: Entradas e Saídas
    • 28. <ul><li>Cada característica é uma unidade planejada de trabalho que pode ser devolvida </li></ul><ul><li>A soma de características entregues é igual ao status do projeto </li></ul>Divulgando Resultados
    • 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
    • 31. <ul><li>FDD </li></ul><ul><ul><li>Fornece clareza </li></ul></ul><ul><ul><li>Eleva o controle </li></ul></ul><ul><ul><li>Facilita a comunicação – reporta resultados </li></ul></ul><ul><ul><li>Status do projeto completo é determinado pelas características entregues </li></ul></ul><ul><ul><li>Características quebram o trabalho em entregas menores e mais gerenciáveis </li></ul></ul><ul><ul><li>Builds regulares </li></ul></ul><ul><ul><li>É bom para os desenvolvedores, gerentes e clientes... </li></ul></ul>Conclusão

    ×