FDD Apresentacao (2)

5/14/2018 FDD Apresentacao (2) - slidepdf.com

http://slidepdf.com/reader/full/fdd-apresentacao-2 1/80

Verificação, Validação e Teste deSoftware

Átila AmorimBruno do Lago John MichaelKilton CalvetLuan Pereira

Marcio Queiroga



1. INTRODUÇÃO2. FDD3. OS PROCESSO DO FDD4. ESTIMAIVAS DE PROGRESSO

5. DESENVOLVIMENTO DE UM MODELO ABRANGENTE6. CONSTRUIR A LISTA DE FUNCIONALIDADES7. PLANEJAR POR FUNCIONALIDADES8. DETALHAR POR FUNCIONALIDADES9. CONSTRUIR POR FUNCIONALIDADES10. ARQUITETURA TÉCNICA 11. TESTES EM FDD12. CONCLUSÃOREFERÊNCIAS

2



3



Falsas premissas• É possível... Prever com precisão todo o escopo do projeto...

Antecipar todos os riscos... Lidar com toda a complexidade e incerteza do

projeto... Acertar precisamente as estimativas no começo...

Fazer funcionar com o cliente ausente...

4



Requisitos poucos claros• Cliente nunca sabe tudo o que precisa• Medo de avançar

5



Gestão de mudanças• Mudanças ficam cada vez mais caras • Paralisa o projeto• Tempo e dinheiro desperdiçados

6



Desperdício e falta de foco

7



Principios Ágeis• Satisfação do cliente é prioridade• Maior valor de negócio em menos tempo• Redução de desperdício• Entrega contínuas• Feedback constantes do cliente•

Progresso medido através de softwarefuncionando

8



Um processo ágil guiado porfuncionalidades de gerenciamento edesenvolvimento de software que permite:• Resultados úteis a cada duas semanas ou menos• Blocos bem pequenos de funcionalidade valorizada

pelo cliente, chamados "Features“• Planejamento detalhado e guia para medição• Rastreabilidade e relatórios com incrível precisão• Monitoramento detalhado dentro do projeto• Fornece uma forma de saber, dentro dos primeiros

10% de um projeto, se o plano e a estimativa sãosólidos

9



A FDD é uma metodologia muitoobjetiva. Possui apenas 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)

10



Os cinco processos são bem definidos eintegrados:• DMA (Desenvolver um Modelo Abrangente) Análise Orientada por Objetos

• CLF (Construir a Lista de Funcionalidades) Decomposição Funcional

• PPF (Planejar por Funcionalidade) Planejamento Incremental

11



• DPF (Detalhar por Funcionalidade): Desenho (Projeto) Orientado por Objetos

•

CPF (Construir por Funcionalidade): Programação e Teste Orientados por Objetos

12





FDD define seis papéis – chave e deixaimplícito um número de papéisadicionais e de suporte;

Organizam um projeto de modo que asforças individuais são melhor aproveitasdentro de uma equipe.

14



É o líder administrativo do projeto,responsável por relatar o progresso;administrar o orçamento, sempre àprocura de pessoas capacitadas;gerenciando equipamentos, espaços erecursos.

15



É responsável pelo design global dosistema;

Este é um papel profundamente técnico,requerendo excelentes habilidadestécnicas e de modelagem;

16



É o responsável pelo dia-a-dia dasatividades de desenvolvimento;

Este profissional, em um papel defacilitador, deve ter boas habilidadestécnicas, além de resolver conflitosdiários buscando recursos onde os

programadores - chefe não conseguem.

17



São desenvolvedores experientes queentendem o ciclo de vida do software empouco tempo;

Programadores – Chefe combinamgrande habilidade técnica com suficientehabilidade pessoal para conduzir

pequenas equipes a produzir resultadosem poucos dias.

18



São desenvolvedores que trabalhamcomo membros de uma pequena equipede desenvolvimento sob orientação deum Programador – Chefe para projetar,codificar, testar e documentar ascaracterísticas requeridas pelo novo

sistema de software.

19



São usuários, clientes, patrocinadores,analistas de mercado ou uma misturadestes;

Eles usam seus profundosconhecimentos de mercado paraexplicar aos desenvolvedores em vários

níveis de detalhes as tarefas que osistema deve executar.

20



Gerente de Domínio;

Guru da Linguagem;

Engenheiro de Construção;

Toolsmith;

Administrador do Sistema.

21



Testadores;Desenvolvedores;Escritores Técnicos.

22



O FDD possui 5 processos bem definidos

23



Desenvolver um Modelo Abrangente• Modelagem dos Processos de Negócio (BPM)• Análise Orientada por Objetos (OOA)

Construir a Lista de Features•

Decomposição Funcional Planejar por Feature• Plano de Desenvolvimento• Prioridade, Dependência, Distribuição de Trabalho

Detalhar por Feature•

Projeto OO (OOD), Estudo Detalhado Construir por Feature• Programação OO (OOP)• Inspeção, Testes, Integração

24



25



O modelo ETVX (Entry, Task, Validation e eXit)• 1. Especificar os critérios de entrada, claros e bem

definidos para o processo.• 2. Em seguida, liste as tarefas de cada processo e as

intitule, liste as funções do projeto que participam dessatarefa, defina se a tarefa é opcional ou obrigatória, e dêuma descrição da tarefa.

• 3. Em seguida, especifique o meio de verificação para oprocesso.

•

4. Finalmente, especificar os critérios de saída para oprocesso, isto é, como vocêsabe quando o processo está completado e quais devemser as saídas (produtos de trabalho).

26



O modelo ETVX

27



O modelo ETVX

28



FDD = - burocracia e + aproveitamentode tempo.

Não se perde tempo estimando o total de

uma tarefa pronta, e sim o total de tarefasprontas.

Utilização de um esquema de cores.

29



Monitoramento por Feature• Definindo os marcos

30



Relatório de desenvolvimento

31



Ponderando os marcos

32



Porcentagem de conclusão do projeto

33



Features concluídas por semana

34



Relatórios de alto nívelDestinados a clientes e gestoresSem necessidade de acompanhamento

individual de Feature Acompanha um grupo de features

35



Parking Lot

36



O modelo concentra-se na identificaçãodas principais classes, suasresponsabilidades importantes, e as

relações entre eles.

Realiza-se um estudo dirigido sobre o

escopo do sistema e seu contexto.

37



Após cada estudo dirigido sobre odomínio, pequenos grupos são formadospor membros do domínio do negócio

sendo estudado e por desenvolvedoresUm dos modelos propostos é

selecionado, tornando-se, assim, o

modelo para aquela área do domínio donegócio.

38



É realizada a construção de diagramasde classes UML (Unified ModelingLanguage).

Para complementar os diagramas declasse UML, são desenvolvidosdiagramas de sequencia UML

O modelo de objetos é, então,

iterativamente atualizado em seuconteúdo pelo processo nº 4 “Detalharpor Funcionalidade”.

39



40



Os especialistas no domínio do negócio,os programadores líderes e o arquitetolíder foram selecionados.

41



Avaliação Interna e Externa• Realiza-se uma auto avaliação ou uma avaliação

interna através da participação ativa dos

especialistas no domínio.• Quando necessária, uma avaliação externa pode

ser feita pedindo-se ao negócio (usuários) queconfirme ou esclareça as questões que afetam o

modelo.

42



O resultado do processo é o modelo deobjetos:• Diagramas de classes com foco na forma do modelo,

isto é, quais classes estão no domínio, como estãoconectadas umas às outras e sob quais restrições;

• Métodos e atributos identificados são colocados nasclasses;

• Diagrama(s) de sequencia e/ou de máquina de

estados se houver;• Comentários sobre o modelo para registrar o motivo

pelo qual uma forma de modelo foi escolhida e/ouquais alternativas foram consideradas.

43



Uma equipe é formada para decomporfuncionalmente o domínio em áreas denegócio, atividades de negócio dentro

delas e passos dentro de cada atividadede negócio.

As funcionalidades serão utilizadas paraguiar o desenvolvimento no FDD.

44



Essas funcionalidade têm como objetivomostrar o progresso através daimplementação das mesmas.

A execução das funcionalidades, ouconjunto delas, não deve exceder de

duas semanas.

45



46



Os especialistas no domínio do negócio,os programadores líderes e o arquitetolíder foram selecionados.

47



Avaliação Interna e Externa• Realiza-se uma auto avaliação ou uma avaliação

interna através da participação ativa dos

membros da equipe de modelagem.• Quando necessária, uma avaliação pode ser

feita pedindo-se aos especialistas no domínio donegócio da equipe de modelagem ou ao

negócio (usuários) que confirmem ouesclareçam as questões que afetam a lista defuncionalidades.

48



O resultado do processo é a lista defuncionalidades:• Uma lista de áreas de negócio;• Para cada área, uma lista de atividades de

negócio dentro daquela área;• Para cada passo da atividade de negócio, uma

funcionalidade que satisfaça ao passo.

49



O gerente de projeto, o gerente dedesenvolvimento e os programadoreslíderes planejam a ordem na qual as

funcionalidades serão implementadas As principais atividades neste processo

não são uma sequencia estrita.

50



51



O processo Construir a Lista deFuncionalidades foi completado.

52



Auto Avaliação• Como o planejamento é uma atividade de

equipe, realiza-se uma auto avaliação pela

participação ativa dos programadores líderes,gerente de desenvolvimento e gerente deprojeto.

53



O resultado do processo é o plano dedesenvolvimento, consistindo em:• Atividades de negócio com datas de término (mês e

ano);• Programadores-líderes atribuídos a atividades de

negócio;• Áreas com datas de término (mês e ano), derivadas

da data do último término de suas respectivasatividades de negócio;• Lista das classes e seus respectivos desenvolvedores

proprietários (a lista de proprietários de classes).

54



Atividades que visão produzir o pacotede projeto para uma funcionalidade.

Classes, Métodos e Atributos.

Programador Líder

55



Formar Equipe de Funcionalidade

Estudo Dirigido do Domínio Estudar Documentação de Referência

Desenvolver Diagramas de Seqüência

Refinar o Modelo de ObjetosEscrever os prefácios de

classes e métodos

56



Atividade Responsável CaráterFormar Equipe deFuncionalidades

Programador Líder Obrigatório

Estudo Dirigido doDomínio

Especialista doDomínio

Opcional

Estudar aDocumentação deReferência

Equipe deFuncionalidades

Opcional

Desenvolver osDiagramas deSequência

Equipe dePlanejamento

Obrigatório

Refinar o Modelo deObjetos

Programador Líder Obrigatório

Escrever Prefácios deClasses e Métodos


Obrigatório

Inspeção do Projeto Equipe deFuncionalidades Obrigatório 57



Inspeção do Projeto• Programador Líder;• Equipe de Funcionalidades;

• Lista de Tarefas;

58



Entrada• Planejamento por Funcionalidade.

Saída• Diagramas de Sequência;• Designs Alternativos;• O modelo de objeto com classes, métodos e

atributos novos ou atualizados;• Documentação de classes e métodos do design;• Lista de Tarefas.

59



Atividades que produzem uma função

com valor para o cliente implementando

as classes e métodos do design.Testes de Unidades.Equipe de Funcionalidades.

Build.

60



Implementar Classes e Métodos

Testar Unidades Inspecionar Código

Promover à versão

atual (Build)

61



Atividades Responsável Caráter

Implementar Classes eMétodos


Obrigatório

Inspecionar o Código Equipe deFuncionalidades

Obrigatório

Teste de Unidade Equipe deFuncionalidades

Obrigatório

Promover a Versão Atual(Build)

Programador Líder,Equipe deFuncionalidades

Obrigatório

62



Inspeção do Código.

Teste de Unidade.

63



Entradas• Processo Detalhar por Funcionalidade

completado.

Saídas• Classes e Métodos inspecionados;• Classes promovidas à versão atual (Build);• Término de uma Funcionalidade.

64



Conjunto de Produtos de Software ouComponentes usados na implementaçãode um Sistema.

Estratégias e Padrões que traduzem umaanalise de alto nível para obterresultados eficientes.

Flexibilidade – Definida a qualquermomento antes da fase de construção.

65



Testes dentro dos processos• Atividade secundária• Não implica em sua inexistência

Ênfase na produção de código de altaqualidade

Entrega frequente de partes tangíveis

Auxílio no processo de testes

66



Teste de UnidadeTeste de IntegraçãoTeste de SistemaTeste de Aceitação

67



Unidade é a menor parte de umprograma que é passível de teste• Métodos de classes

As atividades de teste são realizadas,normalmente, por desenvolvedores• Melhoria nos custos

Complementado pelas inspeções noprojeto e no código

68



Funcionalidades são sequências deinterações entre objetos• Teste de Funcionalidades

Comunicação de teste informal• Baixa sobrecarga de documentos• Formalizada quando necessário Equipe de projeto muito grande

Equipe de projeto separada geograficamenteOcorre com frequência no processo deconstrução

69



Teste formal, realizada por uma equipeespecializada

Elaboração de Casos de Teste• A partir dos requisitos e lista de funcionalidades

Feito em conjunto com a equipe dedesenvolvimento

70



Satisfação do cliente• Garantir que o sistema cumpre as exigências

Alguns casos de teste elaborados na

presença do cliente

71



Processo de encontrar e relatar falhasFalhas são encontradas quando testes

não obtém resultados esperados• Necessidade de modificação para corrigir

Atividades:• Procurar falhas•

Relatar falhas• Diagnosticar falhas• Reparar defeitos

72



73



74



Organização dos casos de teste é umaatividade crítica

Características-chave consideradas no

processo de teste• Definição do ambiente• Repetição• Registro de valores de entrada, resultados e saídas• Rastreamento por recursos e requisitos• Testes automatizados• Rastreamento por defeitos

75



Atribuição de gravidade das falhas• Baixa, Média e Elevada

Os níveis de gravidade devem ser

compreendidos por toda equipe

76



Atividade mais complexa que a correçãode defeitos

Quando os relatórios de falhas

aumentam, é necessário concentraresforço em diagnosticar defeitos

77



Para defeitos simples, é solicitado que oproprietário da classe se responsabilizepela correção

Para defeitos mais complexos, pode sernecessária a inspeção no projeto dafuncionalidade pela equipe responsável

78



FDD é um método ágil e altamente adaptativo, queproduz resultados frequentes, tangíveis e funcionais.

Oferece vantagens em relação aos métodosprescritivos, pois implementa o conceito deplanejamento sem exageros na documentação.

Oferece vantagens em relação aos métodosextremamente ágeis, pois planeja e controla oprojeto de maneira satisfatória.

É orientado às necessidades dos clientes, gerentes edesenvolvedores

A atividade de teste mesmo não sendo atividadeprincipal, acontece com frequência ao longo de cadaprocesso.

79



ANDERSON, David J. Agile Management forSoftware Engineering. 1 ed, Prentice Hall, 2003.

COAD, Peter. DE LUCA, Jeff. LEFEBVRE, Eric. JavaModeling In color With UML. 1 ed, Prentice Hall,1999.

PALMER, Stephen R. FELSING, John M. A PraticalGuide to Feature-Driven Development. 1 ed,

Prentice Hall, 2002.SOMMERVILLE, Ian. Engenharia de software, 8ªedição. São Paulo: Pearson Addison-Wesley, 2007

Documents

FDD Apresentacao (2)