Aula FDD CESAR Recife GAP
-
Upload
jorge-bublitz -
Category
Documents
-
view
1.396 -
download
1
description
Transcript of Aula FDD CESAR Recife GAP
• Engº Jorge Luis Bublitz
CESAR - GAPDESENVOLVIMENTO DIRIGIDO
A FUNCIONALIDADES"A FDD disciplina as equipes a pensarem um pouco antes
de sair fazendo e a fazer aos poucos enquanto continuam aprendendo, demonstrando claramente o que
vão fazer e o que estão fazendo."
sexta-feira, 22 de abril de 2011
• Contexto
• Metodologias
• Agilidade e Metodologias Ágeis
• Mudanças
• FDD
Agenda
sexta-feira, 22 de abril de 2011
Contexto
sexta-feira, 22 de abril de 2011
“É o ato de elaborar e implementar um sistema computacional, isto é,
transformar a necessidade de um utilizador ou de um mercado em um
produto de software.”
Nick Birrell
A Practical Handbook for Software
Development, 1985
O que é Desenvolvimento de Software?
sexta-feira, 22 de abril de 2011
• Caótica• Eterno ciclo “programar e depurar”• Sem planejamento claramente definido• Dificuldade em adicionar novos
recursos (funcionalidades)• Fase de testes e depuração na
produção• Estimativa de Tempo/Custo difícil de
ser determinada
Características
sexta-feira, 22 de abril de 2011
The Caos Report - 1995
Concluídos com Sucesso16%
Concluídos com Alterações53%
Falharam31%
Standish Group – www.standishgroup.com
sexta-feira, 22 de abril de 2011
The Caos Report - 2001
Concluídos com Sucesso28%
Concluídos com Alterações49%
Falharam23%
Standish Group – www.standishgroup.com
sexta-feira, 22 de abril de 2011
The Caos Report - 2009
Concluídos com Sucesso32%
Concluídos com Alterações44%
Falharam24%
Standish Group – www.standishgroup.com
sexta-feira, 22 de abril de 2011
Vamos Analisar
25,00 50,00 75,00 100,00
19941996199820002002200420062009
Sucesso Alterações Falharam
Standish Group – www.standishgroup.com
sexta-feira, 22 de abril de 2011
Funcionalidades/Funções Utilizadas em um Sistema
Sempre7%
Muito13%
Algumas Vezes16%
Raramente19%
Nunca45%
Standish Group – www.standishgroup.com
sexta-feira, 22 de abril de 2011
Culpado(s)???
Clientes
AnalistasDesenvolvedores
Processo
Ferramentas
sexta-feira, 22 de abril de 2011
• Não existe uma solução mágica e única, mas sim um conjunto de práticas reconhecidamente eficientes.
• Desenvolvimento Incremental, Refinamento de Requisitos, BONS PROJETISTAS...
A Solução é...
sexta-feira, 22 de abril de 2011
• Melhorar a qualidade do software implica na melhoria do processo pelo qual o mesmo é produzido.
• Assumir práticas de sucesso
• Garantir que estas práticas serão seguidas durante o desenvolvimento
• Ser fácil de seguir
• Evoluir com o aprendizado do grupo
A Solução é...
sexta-feira, 22 de abril de 2011
• Adoção de Metodologias• Objetivo: tornar o desenvolvimento
mais previsível e mais eficiente• Impõe disciplinas rígidas• Processos detalhados• Planejamento é a ênfase• Passam a impressão de serem uma
PANACÉIA
A Solução utilizada até hoje:
sexta-feira, 22 de abril de 2011
Metodologias
sexta-feira, 22 de abril de 2011
Levantamento de Requisitos
Projeto
Implementação
Testes
Implantação
Modelo Tradicional
sexta-feira, 22 de abril de 2011
• Também chamado de Modelo em Cascata (Waterfall)
• Proposto por Winston W. Royce - 1970!!!• Orientado para documentação• Ênfase em planejamento, horários, prazos,
orçamentos e implementação de sistemas inteiros
• Há variantes: Incremental, Evolucionário, ...
Modelo Tradicional
sexta-feira, 22 de abril de 2011
Novos Tempos (??)
Maior Qualidade
Menor Custo
Menor Tempo
sexta-feira, 22 de abril de 2011
Novos Problemas (?)
Escopo
Qualidade Prazo
Custo
sexta-feira, 22 de abril de 2011
Análise OO
sexta-feira, 22 de abril de 2011
• É um método de análise que examina os requisitos a partir da perspectiva das classes e objetos encontrados no vocabulário do domínio do problema
• Enfatiza a construção de modelos do mundo real usando uma visão de mundo orientada por objetos
Análise Orientada por Objetos
sexta-feira, 22 de abril de 2011
Em meados dos anos 70 e início dos anos 80 (1989 a 1994) vários métodos de
modelagem orientada a objetos surgiram, sendo que os principais foram:
• Booch (Grady Booch)• OMT (Rumbaugh)• OOSE (Jacobson)• Shlaer/Mellor (Sally Shlaer e Stephen
Mellor)• Coad/Yourdon (Peter Coad e Ed
Yourdon)
Métodos Orientados a Objetos
sexta-feira, 22 de abril de 2011
Neste cenário Grady Booch e James Rumbaugh juntaram forças através da Rational Corporation para unificar os métodos Booch e OMT que resultou
na versão 0.8 do Método Unificado, lançado em outubro de 1995.
Grady Booch James Rumbaugh .
Método Unificado
sexta-feira, 22 de abril de 2011
• No final de 1995, Ivar Jacobson juntou-se a equipe fundindo o método OOSE (Object-Oriented Software Engineering)
• Booch, Rumbaugh e Jacobson estavam motivados a criar uma linguagem unificada para modelar sistemas complexos de qualquer tipo:
• missão crítica• tempo real• cliente/servidor
• Após o apoio de parceiros importantes como Microsoft, Hewlett-Packard, Oracle, IBM, dentre outras em janeiro de 1997 foi lançado a UML 1.0 (Unified Modeling Language)
UML
sexta-feira, 22 de abril de 2011
Evolução
sexta-feira, 22 de abril de 2011
• Estáticos:• Use Cases• Classes• Pacotes
• Dinâmicos:• Interação
• Sequência• Colaboração
• Estado (Statechart)• Atividade
Diagramas da UML
sexta-feira, 22 de abril de 2011
Caso de Uso
sexta-feira, 22 de abril de 2011
Classe
sexta-feira, 22 de abril de 2011
Seqüência
sexta-feira, 22 de abril de 2011
Atividade
sexta-feira, 22 de abril de 2011
Estado
sexta-feira, 22 de abril de 2011
• Análise Essencial dizia O QUE fazer e QUANDO
• Quando surge a UML, o mercado queria uma um substituto para a Análise Essencial
• UML é uma Linguagem e não um Processo
• Ela fornece os elementos, mas não define QUANDO usar
• O mercado rejeitou a UML por não compreendê-la
A Decepção
sexta-feira, 22 de abril de 2011
Agilidade e Metodologias Ágeis
sexta-feira, 22 de abril de 2011
• a.gi.li.da.de sf (lat agilitate)
1. Qualidade do que é ágil
2. Desembaraço, ligeireza, presteza de movimentos
3. Mobilidade, perspicácia, vivacidade• Geralmente associa-se
AGILIDADE com Rapidez, Flexibilidade, Leveza
Agilidade
sexta-feira, 22 de abril de 2011
“Agilidade é a habilidade para criar e responder às mudanças, para lucrar
num ambiente turbulento de negócios, para equilibrar flexibilidade
e estabilidade.”Jim Highsmith
Agile Software Development Ecosystems
2002
Agilidade - Software
sexta-feira, 22 de abril de 2011
• Antes chamadas de “Metodologias Leves”
• Tornou-se popular no ano de 2001
• 17 grandes pensadores em processo de desenvolvimento de software
• Se encontraram para que cada um explicasse a maneira como desenvolviam projetos de software
• E como trabalhavam para que a equipe respondesse rapidamente às mudanças
• A partir deste encontro foi criada a
“Aliança Ágil”
• Estabelecimento dos valores do
“Manifesto Ágil”
Metodologias Ágeis
sexta-feira, 22 de abril de 2011
Estamos descobrindo melhores maneiras de desenvolver software, fazendo-o e ajudando outros a fazê-lo.Através deste trabalho passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas.Software que funciona mais que documentação detalhada.Colaboração do cliente mais que negociações contratuais.
Responder às mudanças mais que seguir um plano.
Isto é, embora haja valor nos itens do lado direito, nós valorizamos mais os do lado esquerdo.
www.agilemanifesto.org
Manifesto para o Desenvolvimento Ágil de Software
sexta-feira, 22 de abril de 2011
Princípios Ágeis
• Satisfação do Cliente
• Responder às Mudanças
• Entrega Freqüente
• Motivação
• Software que Funciona
• Ritmo Constante
• Simplicidade
sexta-feira, 22 de abril de 2011
O Manifesto Ágil não pode ser interpretado como indicando que ferramentas, processo, documentos,
contratos ou planos são desprezíveis. • Ferramentas são críticas para acelerar o
desenvolvimento e reduzir custos• Contratos são vitais para iniciar as relações
desenvolvedor-cliente• Documentação auxilia a comunicação• Entretanto, os itens à esquerda são os mais
cruciais• Sem indivíduos hábeis, software funcionando,
interações fortes com clientes e rapidez de resposta às mudanças, a entrega do produto será quase impossível
Cuidado com o Manifesto Radical
sexta-feira, 22 de abril de 2011
Já é um movimento de grande sucesso• Centenas (milhares?) de instituições
já usam• Milhares de projetos já foram
completados• Opinião geral dos que tentaram é
positiva• Alguns estudos científicos começam
a aparecer
O Sucesso das Metodologias Ágeis
sexta-feira, 22 de abril de 2011
Quem Adotou ou Está Adotando?
sexta-feira, 22 de abril de 2011
• Proporcionalmente, as metodologias tradicionais ainda dominam
• Metodologias Ágeis exigem mudança cultural, o que não é nada fácil
• Metodologias Ágeis foram criadas por especialistas em Desenvolvimento de Software
• Em geral o poder de decisão não está nas mãos desses especialistas
Mas...
sexta-feira, 22 de abril de 2011
• Apoio das instâncias superiores
• Gerenciamento de equipes
• Problemas técnicos
• Interação com outros departamentos
• Interação com clientes
Maiores Dificuldades
sexta-feira, 22 de abril de 2011
Representam uma grande fonte de problemas
Pessoas
sexta-feira, 22 de abril de 2011
• Não é assim que eu sempre fiz• Medo de perder o controle• O chão desabou, como agir?• E a minha autoridade?
Gerentes Tradicionais
sexta-feira, 22 de abril de 2011
• Peões que não sabem de nada vão mexer na minha arquitetura?
• Não quero olhar para código, isso é coisa para programadores...
• E a minha autoridade?
Arquitetos
sexta-feira, 22 de abril de 2011
• Quebra da rotina• Sempre fiz assim, por que
tenho que fazer diferente agora?
• Especificação incompleta, testes, código limpo?
• Isso não é tudo desperdício?
• Não quero a responsabilidade
Programadores
sexta-feira, 22 de abril de 2011
• Estão tirando o meu emprego?• Vou ter que aprender a programar?
Testadores
sexta-feira, 22 de abril de 2011
• Onde está a especificação completa?• Se vocês não sabem ainda o que
querem, não venham me pedir para implementar agora coisas que vou ter que mudar depois.
• Eu é quem modelo o Banco, vocês apenas escrevem o código.
• Nós sempre fizemos assim e sempre deu certo, por que mudar agora?
DBAs
sexta-feira, 22 de abril de 2011
• Onde estão as minhas garantias?
• Qual é o preço final?• Se eu pagar tudo, quero
todas as funcionalidades!• Estou pagando para você
fazer o trabalho, por que eu devo estar presente? Você quer que eu faça o seu trabalho?
Clientes
sexta-feira, 22 de abril de 2011
• Eu li o livro ____• mas não sei ainda como
começar• Eu li o livro ____
• mas fiz tudo e não deu certo• Eu li bastante o livro ____,
pratiquei escondido, sei como fazer
• mas não consigo convencer o meu gerente a experimentar.
Coach novato
sexta-feira, 22 de abril de 2011
• Métodos Ágeis é muito bom, sou a favor• mas vamos incluir estes 113 formulários e 184
procedimentos para tornar o resultado de melhor qualidade
• Métodos Ágeis é muito bom, sou a favor• mas vamos usar essa ferramenta que compramos
para controlar todos os passos do desenvolvimento para atingirmos a qualidade total
• Métodos Ágeis é muito bom, sou a favor• mas precisamos fazer uma coleta de requisitos
detalhada e um planejamento completo antes de começar a implementar, caso contrário vamos fazer besteira.
Métodos Pseudo-Ágeis
sexta-feira, 22 de abril de 2011
• Métodos Ágeis é muito bom, sou a favor• mas nós é quem vamos implementar o sistema,
então vamos explicar ao cliente quais são as funcionalidades mais importantes.
• Métodos Ágeis é muito bom, sou a favor• mas como nós estamos pagando, vamos definir
as ferramentas e as tecnologias que os programadores irão utilizar para que eles não façam bobagem.
• Métodos Ágeis é muito bom, sou a favor• mas infelizmente, não podemos nos dar ao luxo
de escrever testes para tudo, isso é radicalismo.
Métodos Pseudo-Ágeis
sexta-feira, 22 de abril de 2011
Levantamento de Requisitos
Projeto
Implementação
Testes
Implantação
Métodos Pseudo-Ágeis
XP, Scrum, ...
Implantação com Testes
sexta-feira, 22 de abril de 2011
Mitos sobre as Metodologias Ágeis
sexta-feira, 22 de abril de 2011
“Extreme Programming (XP) é um processo de desenvolvimento que possibilita a criação de software de alta qualidade, de maneira ágil,
econômica e flexível.“ - Vinícius M. Teles
• Valores: ■ Princípios:• Comunicação ■ Feedback rápido• Simplicidade ■ Presumir simplicidade• Feedback ■ Mudanças
incrementais• Coragem ■ Abraçar mudanças
■ Trabalho de Qualidade
Programação Radical
sexta-feira, 22 de abril de 2011
• Agilidade = XP• É apenas um processo ágil, centrado no
desenvolvedor
• Fatos:• Há vários outros processos e metodologias,
como FDD, Scrum, Lean, Crystal, MSF for Agile, ASD, DSDM, RAD, etc.
• Agilidade é mais habilidade e atitude do que a adoção de um processo
• O Projeto C3, que deu origem à XP foi cancelado!
Principal Mito
sexta-feira, 22 de abril de 2011
Documentação não é necessária!• Fatos:
• Empresas passam por auditorias (Fiscal, SOX, ISO)• Processos definidos precisam de um nível razoável
de documentação (CMMI, MPS.BR...)• A documentação deve ser apropriada para o
propósito em questão (quantidade, qualidade, profundidade, abrangência, etc.)
• Há vários níveis de interesses e necessidades na organização, cada um com seu tipo e grau de A documentação deve ser apropriada para o propósito em questão (quantidade, qualidade, profundidade, abrangência, etc.)
• Há vários níveis de interesses e necessidades na organização, cada um com seu tipo e grau de “documentabilidade”
Consequência #1
sexta-feira, 22 de abril de 2011
Modelagem?? Nem pensar!• Fatos:
• Scott Ambler demonstrou o valor da Modelagem Ágil• Metodologias ágeis, como a FDD, utilizam a
modelagem como vantagem e não como carga inútil• “Uma imagem vale mais do que mil palavras” (ou,
talvez, linhas de código?)• A geração automática de código, proporcionada por
várias ferramentas (Borland Together, ECO e outros), é um fator para aumento de produtividade, padronização e diminuição de defeitos
• A capacidade de entender, memorizar e comunicar é muito maior com imagens do que com textos apenas (alguém aí é da época dos terminais verdes, CP/M, MS-DOS...?)
Consequência #2
sexta-feira, 22 de abril de 2011
Ferramentas?? Não, obrigado! Talvez as gratuitas...• Fatos:
• Ferramentas adequadas aumentam a produtividade• A automação ajuda a padronizar e reforçar o processo,
facilitando a adoção e institucionalização• O problema não é tanto a ferramenta, mas principalmente
os hábitos:
Consequência #3
sexta-feira, 22 de abril de 2011
Os testes são os requisitos, por isso os requisitos são desnecessários!
• Fatos:• Existem vários tipos de requisitos: de negócio, de
usuário, funcionais, não-funcionais, infra-estrutura, ...
• Existem vários tipos de testes: unitários, de integração, de usabilidade, de regressão, de carga, de stress, etc.
• Os testes são derivados dos requisitos, geralmente os de usuário (cenários de casos de uso) e funcionais
• Há uma relação N-N entre testes e requisitos• A rastreabilidade ajuda na sincronização entre eles
• Os testes manuais continuarão existindo (100% de automação é 99% improvável)
Consequência #4
sexta-feira, 22 de abril de 2011
Agilidade é coisa nova, de 2000 prá cá...• Fatos:
• Os valores, conceitos e práticas são antigos (conhecidos e praticados a mais de 15 anos)
• Algumas metodologias e processos já existiam antes de 2000:
• FDD (1997), mas várias práticas são anteriores a 1990
• Scrum (1993), mas as bases vêm de meados da década de 1980
• RAD (década de 1980 e início de 1990)• Agilidade, como conceito, faz parte da
natureza!
Consequência #5
sexta-feira, 22 de abril de 2011
• Prêmio Nobel de Física em 1965• QED - Eletrodinâmica Quântica
• Trabalhou no projeto Manhattan (1942- 1946)
• Enquanto os mainframes não chegavam, simulou algoritmos de cálculos com papel, calculadoras manuais e pessoas (um exército de secretárias!)
• Foi capaz de depurar, descobrir erros nos algoritmos e fazer otimizações para acelerar os cálculos!
• Quando as máquinas chegaram, foi só codificar e rodar!
Richard Feynman: Agilista??
sexta-feira, 22 de abril de 2011
• “Foco em datas na pior forma possível: ciclos curtos, entregas rápidas, estimativas e re-estimativas freqüentes”
• Esse foco agressivo na entrega fere a base geral de código, porque as pessoas não dão a mão para ajudar uns aos outros, e as tarefas “domésticas” são negligenciadas
• Eles ficam exaustos por causa do ritmo invariante e das horas anti-naturalmente regulares
• “São todos novos, com medo de falar, e nenhum deles têm mesmo certeza se é a Agilidade que está causando o problema”
• Esse pessoal Ágil é evasivo: “esquivando-se da crítica ao abraçar qualquer coisa boa e repudiando qualquer coisa má”
A “MÁ” Agilidade
sexta-feira, 22 de abril de 2011
• A estrutura da organização contém hierarquia, mas na prática ela parece bastante “plana” (código dos gerentes)
• As pessoas evoluem os processos quando necessário (em vez dos processos oprimirem as pessoas)
• Grande disciplina é praticada com relação à base de código
• A “folga” está embutida no sistema
A “BOA” Agilidade
sexta-feira, 22 de abril de 2011
• Permitir aos desenvolvedores explorar outras idéias que os interessem
• Os incentivos são ligados ao valor de negócio de cada projeto
• A organização facilita o foco na codificação• Por exemplo, fornecendo boas
ferramentas e lanches gratuitos ☺• As pessoas são tratadas com respeito• As requisições são simplesmente
enfileiradas e priorizadas
A “BOA” Agilidade
sexta-feira, 22 de abril de 2011
Projetos e Processos
Mudanças
sexta-feira, 22 de abril de 2011
• Única constante do universo:MUDANÇA
• Para melhorar• Para motivar• Para nos tornarmos mais eficientes
e eficazes• Para nos tornarmos mais ágeis
Porque mudar??
sexta-feira, 22 de abril de 2011
• Para 88% dos 1.150 CEOs de todo mundo ouvidos no início de 2009 pela consultoria americana Pricewaterhouse-Coopers a competência mais importante para um executivo atualmente é a flexibilidade para se adaptar a mudanças
• “E não basta ter facilidade para aceitar o novo. O profissional deve ser um provocador de mudanças e levar as pessoas junto com ele”, José Aurélio Drummond Jr., presidente da Whirlpool
Além disso...
sexta-feira, 22 de abril de 2011
O Processo de Mudança
sexta-feira, 22 de abril de 2011
• Tradicional
• Ser capaz de controlar / eliminar a incerteza
• Planejamento e controle de progresso através do Caminho Crítico / EVA
• Replanejar deve ser a exceção sempre
• Controle rígido do escopo do projeto
• Teorias básicas: Gerenciamento Total da QualidadeControle Estatístico de Processos
Diferenças de Paradigmas
• Ágil
• Ser capaz de lidar com a incerteza
• Planejamento e controle de progresso através da Corrente Crítica / Buffers
• Replanejar deve ser a regra (há limites práticos)
• Controle do escopo das iterações
• Teorias básicas: Teoria do CaosTeoria das Restrições (TOC)Produção Enxuta (Lean)
sexta-feira, 22 de abril de 2011
Planejar X Plano
“Um plano não é nada... Mas planejar é tudo!”
Dwight D. Eisenhower34º Pres. EUA
(1953-1961)
sexta-feira, 22 de abril de 2011
• O propósito de um processo de desenvolvimento de software é:
• capacitar e reforçar a entrega repetível de software que funciona...
• no prazo adequado e eficiente em relação ao seu custo...
• fornecendo informação precisa e significativa a todos os papéis principais, dentro e fora de um projeto...
• com o mínimo de interrupção para os desenvolvedores
Coad, De Luca (JMCU)
Para que serve um Processo?
sexta-feira, 22 de abril de 2011
• É bem delimitado• Claramente define tarefas, que são focadas
nos resultados• Produz progresso e informação de status
precisos• Rapidamente torna-se uma questão de
hábito• Ajuda a equipe a manter a qualidade e
administrar a complexidade• Otimiza comunicação dentro e fora da
equipe
Características de um bom Processo
sexta-feira, 22 de abril de 2011
• Capacita a organização a responder facilmente à mudança
• Entrega código funcionando ao mercado mais rapidamente (do que com outros métodos – atuais ou anteriores)
• Produz código funcionando de alta qualidade• Aumenta a produtividade• Aumenta a satisfação do cliente• Fornece um ambiente de alta satisfação com
o trabalho para uma equipe bem motivada
O Processo Ágil...
sexta-feira, 22 de abril de 2011
Desenvolvimento Dirigido a
Funcionalidades
sexta-feira, 22 de abril de 2011
• “FDD é uma metodologia iterativa e incremental de gerenciamento e engenharia de software, que combina as melhores práticas de outras abordagens ágeis com técnicas centradas no modelo, que podem escalar para equipes e projetos maiores.
• É caracterizada por uma ênfase na qualidade em todo o processo e um monitoramento de progresso direto, preciso, intuitivo e acurado.
• Sua principal finalidade é a entrega tangível e frequente de software funcional.”
Autor: Jorge L. Bublitz
Revisão: Adail Muniz
Definição
sexta-feira, 22 de abril de 2011
•1997-1998, Singapura•Contexto: Desenvolvimento de um grande sistema de empréstimos para o United Overseas Bank•Anteriormente, após 2 anos de consultoria, 3.500 páginas de casos de (in)uso e um modelo de objetos com centenas de classes, foi avaliado como impossível
Onde nasceu a FDD
sexta-feira, 22 de abril de 2011
• Decisão: Implantação das metodologias de OOAD de Peter Coad e de PM de Jeff De Luca
• Resultado: 2.000 Features entregues por uma equipe de 50 pessoas, 15 meses após a contratação da dupla
Decisão x Resultado
sexta-feira, 22 de abril de 2011
Jeff De Luca Peter Coad
Stephen Palmer John Mac Felsing
Os “Culpados”
sexta-feira, 22 de abril de 2011
Sede do United Overseas Bank David Anderson, o GUI-Man
Peter Coad e aEquipe de Modelagem
Paul Szego eStephen Palmer
Jeff De Luca e osProgramadores
O Berço da FDD
sexta-feira, 22 de abril de 2011
• Inovação Contínua• Adaptabilidade do Produto• Cronogramas Reduzidos de Entrega• Adaptabilidade das Pessoas e
Processos• Resultados Confiáveis
O que a FDD pode proporcionar??
sexta-feira, 22 de abril de 2011
Principais Características
sexta-feira, 22 de abril de 2011
• Fornece a estrutura suficiente para equipes maiores
• Enfatiza a produção de software de qualidade• Entrega resultados freqüentes, tangíveis e
funcionais• Realiza trabalho significativo desde o início,
antes de tornar-se altamente iterativa• Fornece informação de estado e progresso de
forma simples e compreensível• Agrada a clientes, gerentes e
desenvolvedores
Características da FDD
sexta-feira, 22 de abril de 2011
• Característica ou funcionalidade• Pequena o suficiente para ser implementada
no máximo em 2 semanas• Oferece valor para o cliente• Mapeia passos em uma atividade de negócio• Pode ser um passo de um caso de uso,
podendo ser às vezes o próprio caso de uso• Conceito muito próximo de requisito
funcional
O que é Feature?
sexta-feira, 22 de abril de 2011
MODELO
• <A><R><O>• <Ação> <Resultado> <Objeto>
• Calcular o Total da Venda
sexta-feira, 22 de abril de 2011
• Calcular o total do salário• Autorizar a entrada fora do horário do expediente
do funcionário• Assinar digitalmente o documento PDF• Autorizar a transação com o cartão do cliente• Calcular o desconto de uma venda • Listar os clientes ativos da empresa • Destacar os clientes devedores de uma filial • Imprimir a nota fiscal de uma venda • Validar a senha de um usuário • Efetuar a matrícula do aluno no curso
Outros Exemplos
sexta-feira, 22 de abril de 2011
• Coloque as seguintes funcionalidades no modelo sugerido (<a><r><o>):
• O usuário é validado antes de entrar no sistema• Ao vender um produto, seu estoque é
atualizado• A compra será paga com cartão de crédito• O sistema notifica o cliente sobre o envio do
seu pedido• A recepcionista escolhe o quarto do hóspede a
partir de uma lista de unidades disponíveis• O médico verifica sua agenda para marcar a
próxima consulta do paciente• Ao parir sua cria, a vaca deve ser registrada
como não estando mais prenha
Exercício
sexta-feira, 22 de abril de 2011
• Modelagem de Objetos do Domínio• Desenvolvimento por Feature• Posse individual de classe (código)• Equipes de Features• Inspeções• Builds regulares• Gerenciamento de configuração• Relatório/visibilidade de resultados
Melhores Práticas da FDD
sexta-feira, 22 de abril de 2011
• Diagramas de classes com os principais tipos deobjetos no domínio do problema e suas relações
• Auxilia na captura e esclarecimento dos requisitos
• Possibilita um entendimento comum e mais completosobre o domínio do problema
• O modelo de objetos do domínio• É o mapa da estrada, que guiará a jornada• Fornece uma estrutura abrangente na qual adicionar funcionalidade• Ajuda a manter a integridade conceitual do sistema• Reduz a quantidade de refactoring• É uma forma de armazenamento e comunicação concisa,
relativamente acessível e reutilizável, para todos os envolvidos no projeto
1) Modelagem de Objetos do Domínio
sexta-feira, 22 de abril de 2011
Exemplo de Modelo de Domínio
sexta-feira, 22 de abril de 2011
• Pensamento sistêmico, processual,visando o resultado final
• As features são o que o cliente realmente usará
• Ele entende os termos, o valor e o progresso• Ele pode priorizar pela importância para o negócio
• O teste é objetivo (funciona ou não funciona)• É fácil de se determinar quando está pronta• Garante a distribuição organizada de
responsabilidades através das classes/módulos• É comum a várias abordagens de
desenvolvimento (funcional, estruturada, orientada por objetos, etc.)
2) Desenvolvimento por Funcionalidade
sexta-feira, 22 de abril de 2011
Área 1 Atividade 1.1
Feature 1.1.1 Feature 1.1.2
Atividade 1.2 Feature 1.2.1 Feature 1.2.2
Área 2 Atividade 2.1 Feature 2.1.1 Feature 2.1.2
Atividade 2.2 Feature 2.2.1
ClasseA
ClasseB
ClasseC
As Features Preenchem oModelo de Domínio
sexta-feira, 22 de abril de 2011
Objeto1TelaA
Objeto2ClasseB
Objeto3ClasseC
Objeto4ClasseD
Usuário1: feature1
1.1: operacaoC1
1.2: operacaoA1
2.1.1: operacaoD12.1: operacaoC2
2.2: operacaoA2
2: feature2
1.1.1: operacaoD1
As Features Preenchem oModelo de Domínio
sexta-feira, 22 de abril de 2011
• Estipula quem (pessoa ou papel) é oresponsável final pelo conteúdo de umaclasse (pedaço de código)
• O dono garante que o propósito da classe é mantido e que as alterações são apropriadas
• Há um especialista disponível para explicar como um trecho particular do código funciona, especialmente para classes complexas ou críticas para o negócio
• O dono pode implementar uma melhoria mais rapidamente do que outro desenvolvedor
• O dono, pessoalmente, possui algo do que se orgulhar por ter feito bem
3) Posse individual de classe (código)
sexta-feira, 22 de abril de 2011
• Formadas dinamicamente• Única forma de desenvolver por
feature e manter a posse de código• Sob a coordenação de um
Programador Líder• Múltiplas mentes projetando
• Comparação entre alternativas e escolha da mais apropriada
• Membros são os Proprietários de Classes relevantes
• Benefício da Posse de Código• Enfatiza o trabalho em equipe
• Ninguém termina enquanto a equipe de features não terminar
4) Equipes de Features
sexta-feira, 22 de abril de 2011
• Quando bem feitas, são muito úteis na melhoria da qualidade do design e do código
• São recomendadas desde 1970 e a evidência pesa fortemente a seu favor
• Numa experiência com 11 programas, o erro médio por 100 linhas de código caiu de 4,5 para 0,82
• Inspeções cortam erros em mais de 80%• 1 hora de inspeção pode evitar
de 5 a 30 horas de correções
• Benefícios secundários• Transferência de conhecimento• Conformidade com padrões 0%
15%
30%
45%
60%
24%
35%
45%
55%60%
Técnica
Taxa Média de Detecção de Defeitos
Teste UnitárioTeste FuncionalTeste de IntegraçãoInspeção de DesignInspeção de Código
Jones, C.L. “A Process-Integrated Approach to Defect Prevention”, IBM Systems Journal, 1985
5) Inspeções
sexta-feira, 22 de abril de 2011
Prof. Guilherm
e Horta, C
OPPE/U
FRJ, 2004
Detecção Antecipada de Defeitos
sexta-feira, 22 de abril de 2011
1Planejamento
2Detecção
3Coleção
4Correção
Artefato
Form.Planejamento
Form.Relato deDefeitos
Form.Relato deDefeitos
Form.Relato deDefeitos
ArtefatoCorrigido
Organizador
Inspetor
ModeradorInspetor
Autor
Autor
Ad-HocTécnicas de Leitura
Checklists
Prof. Guilherme Horta, COPPE/UFRJ, 2004
Como Conduzir Uma Inspeção
sexta-feira, 22 de abril de 2011
• Em intervalos regulares, compilar o sistema comtodas as features completadas até o momento
• Semanalmente, diariamente ou continuamente
• Ajuda a antecipar erros de integração
• Garante que sempre haverá alguma coisa paramostrar ao cliente
• Oportunidades• Geração de documentação• Execução de scripts de auditorias e métricas• Testes de regressão• Notas da versão (novas features, defeitos corrigidos, etc.)
• Os resultados podem ser publicados na intranet do projeto
6) Montagens Freqüentes
sexta-feira, 22 de abril de 2011
• Disciplina que suporta e controla as evoluções e modificações em artefatos-chave dentro do ciclo de desenvolvimento de um software
• Objetivos• Facilitar o desenvolvimento de software• Garantir a integridade dos produtos• Controlar efetivamente as modificações
• Itens de Configuração: Artefatos gerados oumanipulados durante o ciclo de vida da aplicação
• Arquivos, Requisitos, Documentos, Modelos, Testes
• Processos, Contratos, Regulamentações• Solicitações de Mudança, Defeitos, Tarefas
PrincipaisArtefatos de
Desenvolvimento
Desenvolvimentodo Produto
Gerenciamento
7) Gerenciamento de Configuração
sexta-feira, 22 de abril de 2011
• Versionamento
• Check out/check in• Histórico de revisões• Branching & Merging• Visões de Projeto
• Gestão de Mudanças
• Acompanhamento de defeitos• Listas de Melhoria• Associações• Rastreabilidade
• Gestão de Tarefas
• Criação e Acompanhamento• Ficha de tempo
Gerenciamento de Processo Definição de Workflow Critérios de Entrada/Saída Notificações Garantia de Segurança
Gerenciamento de Montagem Identificação de
Dependências Controle de Montagens
Gerenciamento de Liberação Rótulos Estados Promocionais Implantação
Tarefas Rotineiras doGerenciamento de Configuração
sexta-feira, 22 de abril de 2011
Para que o cliente e os gestores possam direcionar o projeto corretamente é preciso Uma figura acurada do estado atual do projeto Saber o quão rápido a equipe adiciona
funcionalidade O resultado geral desejado
Ter um método simples, de baixa sobrecarga, para coletar informação de progresso de forma acurada e confiável
Formatos de relatórios objetivos e intuitivos, para todos os interessados no projeto
8) Relatório/Visibilidade de Resultados
sexta-feira, 22 de abril de 2011
Os Papéis
sexta-feira, 22 de abril de 2011
Principais Papéis
GERENTE DE PROJETOS
Especialista Domínio do
Negócio
Gerente de Desenvolvimento
Programador Líder
Arquiteto Líder
Proprietário de Classes
sexta-feira, 22 de abril de 2011
• Coordena as ações da equipe do projeto, controla o progresso e reporta para a alta gerência e interessados no projeto
• Responsável pelo gerenciamento de: escopo, tempo, custo, qualidade, riscos, comunicação, recursos humanos, suprimentos e integração
• Responsável por todos os assuntos administrativos do projeto, o que inclui o gerenciamento de recursos, orçamento, equipamentos e outros.
• Principal meta é fornecer subsídios para que nenhum fator externo atrapalhe a produtividade da equipe do projeto
Gerente de Projeto
sexta-feira, 22 de abril de 2011
• Possui habilidades técnicas e gerenciais necessárias para coordenar as ações da equipe de desenvolvimento, operacionalizando as decisões tomadas pelo gerente de projeto
• Responsável por liderar o dia-a-dia do desenvolvimento do produto.
• Por ser o responsável por resolver qualquer conflito técnico que exista entre programadores- chefes, precisa possuir boa experiência no desenvolvimento de software e nas tecnologias que estarão sendo utilizadas no projeto
Gerente de Desenvolvimento
sexta-feira, 22 de abril de 2011
• Compreende as regras e a dinâmica do domínio do problema sendo considerado
• É o responsável por informar a equipe do projeto sobre o que deve ser feito para que o produto do projeto seja adequado às necessidades dos usuários
• Usa o seu conhecimento no negócio para apresentar à equipe do projeto as necessidades para que o software possua valor real
• Deve estar sempre disponível para fornecer aos desenvolvedores maior detalhamento sobre determinada funcionalidade
• É um um membro fixo da equipe e sempre esta fornecendo feedback das entregas para todos os envolvidos.
Especialista no Domínio de Negócio
sexta-feira, 22 de abril de 2011
• É um profissional com experiência em análise e modelagem orientada a objetos, capaz de liderar a equipe no desenvolvimento do modelo que será construído para implementar as features identificadas
• Possui habilidade para atuar como facilitador na absorção das regras de negócio
• Será ele o responsável pela última palavra em toda arquitetura do sistema.
Arquiteto Líder
sexta-feira, 22 de abril de 2011
• Também chamado de Progranador-Chefe
• É um profissional mais experiente, que possui reconhecimento como tal pela equipe
• Coordena o desenvolvimento das features, monta as equipes de features e participa das definições técnicas, além de ser também um Proprietário de Classes
• Normalmente é atribuído a ele a propriedade das classes mais complexas do sistema
• Possui papel fundamental nas fases de absorção do conhecimento de negócio e no planejamento das funcionalidades.
Programador Líder
sexta-feira, 22 de abril de 2011
• É um desenvolvedor da equipe, ao qual foram atribuídas certas classes do modelo
• Sempre que uma feature for escolhida para desenvolvimento e necessitar dos serviços oferecidos por algumas das classes que estão sob sua “custódia”, ele será escalado para participar da equipe de features nessa iteração
• Programa, diagrama, testa e documenta as funcionalidades a ele atribuídas pelo Programador-chefe da equipe.
Proprietário de Classes
sexta-feira, 22 de abril de 2011
Gerente de Versão
Guru da Linguagem
Engenheiro de Desenvolvimento
Produtor de Ferramentas e
Utilitários
Administrador de SistemasTestadores
Implantadores Escritores Técnicos
Funções de Apoio
sexta-feira, 22 de abril de 2011
Os 5 Processos
sexta-feira, 22 de abril de 2011
Concepção e Planejamento
Construção
Desenvolverum ModeloAbrangente
PlanejarporFeature
Mais conteúdo na forma
Mais forma que conteúdo
Modelo de Objetos
Pacotes de Trabalho
Requisitos
Produto
Plano deDesenvolvimento
Progresso
Construira Lista de Features
Fonte: Heptagon – www.heptagon.com.br
Os 5 Processos
DetalharporFeature
ConstruirporFeature
sexta-feira, 22 de abril de 2011
Desenvolver um Modelo Abrangente Modelagem dos Processos de Negócio (BPM) Captura de Requisitos 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 Design/Projeto OO (OOD), Estudo Detalhado
Construir por Feature Programação OO (OOP) Inspeção, Testes, Integração
O Porquê de Cada Processo
sexta-feira, 22 de abril de 2011
Feature-Driven Development
Discussões Iniciais Sobre RequisitosObter Patrocínio da Gerência
Escolha da Linguagem de Programação
Escolha da Plataforma Tecnológica
Protótipo Técnico
Protótipo da Interface com o Usuário
Limpeza de Dados
Conversão de Dados
Teste de Carga
Sistema Piloto
Desenvolvimento em Fases
Teste de Aceitação do Usuário
Teste do SistemaGerenciamento das Alterações nos Requisitos
Gerenciamento de Problemas
Gerenciamento de Recursos
Alocação de Pessoal
Preparação de Orçamento
Planejamento Geral
Desenvolver um Modelo Abrangente
Construir a Lista de Features
Planejar por Feature
Detalhar por Feature
Construir por Feature
O Contexto da FDD
sexta-feira, 22 de abril de 2011
Gestão Ágil de Projetos
Concepção e Planejamento
Construção
Análise OO PlanejamentoDecomposição Funcional
Projeto OO Programaçãoe Teste OO
Engenhariade Requisitos
Desenvolvimento de Requisitos
Gerênciade Requisitos
Gerênciade Configuração
Principais Disciplinas Envolvidas
sexta-feira, 22 de abril de 2011
Análise OO É um método de análise que examina os requisitos a
partir da perspectiva das classes e objetos encontrados no vocabulário do domínio do problema
Enfatiza a construção de modelos do mundo real usando uma visão de mundo orientada por objetos
Desenho/Projeto OO É um método de projeto que abrange o processo de
decomposição orientado por objetos e uma notação para descrever os modelos lógicos e físicos, estáticos e dinâmicos, do sistema sendo projetado
Enfatiza a estruturação eficaz e apropriada de um sistema complexo, sem se prender a detalhes de implementação
Análise e Desenho/ProjetoOrientados por Objetos
sexta-feira, 22 de abril de 2011
Programação OO É um método de implementação no qual os programas são
organizados como coleções cooperativas de objetos, cada qual representando uma instância de alguma classe e cujas classes são todas membros de uma hierarquia de classes unidas por relacionamentos de herança
Enfatiza o uso de objetos, e não de algoritmos, como blocos de construção lógica fundamentais
Teste OO É um método de verificação do comportamento dos objetos em
tempo de execução Enfatiza inicialmente o comportamento individual (unitário) de
cada classe de objetos, passando para o relacionamento entre objetos, seu funcionamento como componente/serviço, e a orquestração entre os componentes/serviços
Programação e TesteOrientados por Objetos
sexta-feira, 22 de abril de 2011
Meta
CondiçãoNecessária
CondiçãoNecessária
CondiçãoNecessária
ObjetivoIntermediário
ObjetivoIntermediário
ObjetivoIntermediário
ObjetivoIntermediário
ObjetivoIntermediário
ObjetivoIntermediário
ObjetivoIntermediário
ObjetivoIntermediário
Estabelecer o Propósito do Projeto
sexta-feira, 22 de abril de 2011
Engenharia deRequisitos
IIT Management & GovernanceGerenciamento & Governança de TI
Demanda Estratégica & Operacional
ANÁLISE
Priorização | Verificação |Riscos | Estimação
GERENCIAMENTO
Armazenamento | Medição & Auditoria | Ligação & Rastreamento | Relatórios | Segurança
Nec
essi
dade
s de
Neg
ócio
Operações de TI (Produção)
DESCOBERTATécnicas | Glossário |
Fronteiras do Sistema |Stakeholders
ESPECIFICAÇÃODetalhar Requisitos | Protótipo |Modelo de Cenários de Negócio |
Modelo de Casos de Uso
VALIDAÇÃO
Revisão | Assinatura |Baseline
Engenharia de Requisitos
sexta-feira, 22 de abril de 2011
Karl Wiegers, “Software Requirements”
Requisitosde Negócio
Requisitosde Usuário
Requisitosde Sistema
RequisitosFuncionais
Regras deNegócio
Atributosde Qualidade
InterfacesExternas
Restrições
Documento de Visão e Escopo
Casos de Uso
Especificação deRequisitos de Software
Funcionais Não-Funcionais
Tipos de Requisitos
sexta-feira, 22 de abril de 2011
Também chamada de “Modelagem de Objetos do Domínio”
Preocupa-se mais com a forma do que com o conteúdo
Auxilia na captura e esclarecimentos dos requisitos
Possibilita um entendimento comum e mais completo sobre o domínio do problema
1. Desenvolver um Modelo Abrangente
sexta-feira, 22 de abril de 2011
É uma atividade inicial de estudo, análise e modelagem do sistema
Realizada em grupos O modelo gerado é suficientemente
abrangente, mas não detalhado O objetivo é ter uma definição a priori do
que será feito, para guiar a equipe durante a fase de construção
Artefatos produzidos: Diagramas de classes, sequência,
atividades, estados, casos de uso Lista preliminar de requisitos Anotações nos modelos
DPF CPF
1. Desenvolver um Modelo Abrangente
DMA CLF PPF
sexta-feira, 22 de abril de 2011
Formar a Equipede Modelagem
(Gerente do Projeto)
Conduzir um EstudoDirigido Sobre o
Domínio de Negócio(Ger. Projeto, Especialistas)
Estudar Documentos(Equipe de Modelagem)
Desenvolver Modelosem Pequenos Grupos(Equipe de Modelagemem pequenos grupos)
Desenvolver umModelo como Equipe
(Equipe de Modelagem)
Refinar o Modelo deObjetos Completo
(Arquiteto Líder,Equipe de Modelagem)
Escrever ComentáriosSobre o Modelo(Arquiteto Líder,
Programador Líder)
opcional
1. Desenvolver um Modelo Abrangente
sexta-feira, 22 de abril de 2011
Apresentação
Negócio – Domínio do Problema
Persistência Interface com Outros Sistemas
FOCO
Arquitetura em Camadas
sexta-feira, 22 de abril de 2011
Padrão de análise e modelagem desenvolvido por Peter Coad, na última metade da década de 1990
Auxilia tanto na criação quanto na melhoria de modelos da classes
Fácil de aprender e explicar Propõe a utilização de 4 arquétipos
arquétipo. s.m. 1 modelo ou padrão passível de ser reproduzido em simulacros ou objetos semelhantes; 2 idéia que serve de base para a classificação dos objetos sensíveis; 3 Derivação: por extensão de sentido: qualquer modelo, tipo, paradigma. (Dic. Houaiss da Língua Portuguesa).
UML em Cores
sexta-feira, 22 de abril de 2011
Representa algo que necessita ser registrado,por razões de negócio ou até mesmo legais, queocorre em algum momento no tempo ou duranteum intervalo de tempo
São atividades, eventos e serviços Um momento-intervalo também pode ter
“mi-detalhes”, ou seja, ser composto porpequenas etapas do evento total
Exemplos: Uma venda é algo que acontece num certo momento Uma estada é o período de tempo que o veículo fica sob a
responsabilidade do estacionamento Para identificar esse arquétipo usamos a cor rosa e o
estereótipo <<moment-interval>>; também usa-se a sigla MI; para os detalhes, usamos o estereótipo <<mi-detail>>
É comum a classe estar acompanhada de um diagrama de máquina de estados, para definir seu comportamento em tempo de execução
Arquétipo: Momento-Intervalo
sexta-feira, 22 de abril de 2011
Representa: Uma pessoa (física ou jurídica) Um certo local (endereço, casa, privado ou público) Algum objeto, geralmente concreto
São entidades que devem ser registradas nosistema por desempenharem papéis nas atividades (momentos-intervalos)
Uma mesma pessoa pode participar de eventos distintos, através de papéis diferentes
Identificamos esse arquétipo com a cor verde e o estereótipo correspondente: <<party>>, <<place>> ou <<thing>>
É onde geralmente aparecem os “cadastros” e “relatórios” simples
Arquétipo: Pessoa-Lugar-Coisa
sexta-feira, 22 de abril de 2011
É a representação de um papel que édesempenhado por pessoa, lugar ou coisa,em um determinado evento do negócio(momento-intervalo)
É mais comumente aplicado a pessoas, mas épossível utilizá-lo com lugares e até mesmo com coisas
Exemplo: Um aeroporto pode desempenhar o papel de local de
origem, destino ou escala de um vôo Uma pessoa, num hotel, pode ser recepcionista,
gerente, hóspede, vigilante, etc. Sua cor é o amarelo e o estereótipo é
<<role>>
Arquétipo: Papel
sexta-feira, 22 de abril de 2011
É como um item num catálogo, definindo ascaracterísticas de uma determinada coisa,lugar ou até mesmo pessoa (menos comum,mas possível)
Usado para concentrar dados comuns adiversos objetos, possibilitando perguntas denegócio interessantes, como a quantidade deobjetos de um determinado tipo
Aparece na cor azul (quase cinza, dependendo da ferramenta de modelagem) e usa-se o estereótipo <<description>>
São as famosas “referências” usadas em combos e lookups
Arquétipo: Descrição
sexta-feira, 22 de abril de 2011
Padrão para análise OO (Camada de Negócio)
Mostra o relacionamento entre os arquétipos
Diminui a variação no processo de modelagem
Padroniza o entendimento Equipe de Negócio Equipe de TI
Domain Neutral Component(Componente Genérico de Modelagem)
sexta-feira, 22 de abril de 2011
Quarto
IDStatus
Hospede
ScoreDtUltVisita
Hotel
NomeEnderecoEstrelas
PessoaFisica
Nome CPF
Estadia
DHInicioDHTerminoValorTotal
*
Funcionario
DtAdmissaoCTPS
*
*
Servico
DataHoraValor
*
TipoQuarto
DescricaoNumSoltNumCasalFumante?
*
UML Sem Cores
sexta-feira, 22 de abril de 2011
Quarto
IDStatus
Hospede
ScoreDtUltVisita
Hotel
NomeEnderecoEstrelas
PessoaFisica
Nome CPF
Estadia
DHInicioDHTerminoValorTotal
*
Funcionario
DtAdmissaoCTPS
*
*
Servico
DataHoraValor
*
TipoQuarto
DescricaoNumSoltNumCasalFumante?
*
UML em Cores
sexta-feira, 22 de abril de 2011
Com o modelo básico criado, deve-se agora criar uma lista de features
É uma decomposição funcional do domínio do negócio
Categorizada em 3 níveis: Áreas de Negócio (Grandes Conjuntos de
Features) Atividades de Negócio (Conjuntos de Features) Passos da Atividade de Negócio (Features)
Artefatos produzidos: Lista de Features Requisitos mais detalhados
DPF CPF
2. Construir a Lista de Features
PPFCLFDMA
sexta-feira, 22 de abril de 2011
Formar a Equipede Lista de Features(Gerente do Projeto,
Gerente de Desenvolvimento)
Construir aLista de Features
(Equipe deLista de Features)
2. Construir a Lista de Features
sexta-feira, 22 de abril de 2011
Sistema ouAplicação
Área de Negócio Área de Negócio Área de Negócio
Atividade de Negócio
Atividade de Negócio
Atividade de Negócio
Atividade de Negócio
Atividade de Negócio
Atividade de Negócio
Atividade de Negócio
Atividade de NegócioFuncionalidade
Funcionalidade
Gerenciamento de ...
<Substantivo><VerboInfinitivo> ...
<Ação> <Resultado> <Objeto>
FBS: Feature Breakdown Structure
sexta-feira, 22 de abril de 2011
Classe A
Classe B
Classe C
Área n
Atividade XFeature 1Feature 2
Atividade YFeature 3Feature 4Feature 5
...
As Features preenchem o Modelo
sexta-feira, 22 de abril de 2011
Com a lista e o modelo, deve-se agora planejar a ordem na qual as funcionalidades serão implementadas, tendo como base: a necessidade do usuário (importância, prioridade) as dependências entre elas a carga de trabalho da equipe de desenvolvimento a complexidade das funcionalidades
As responsabilidades são distribuídas para a equipe
Artefatos produzidos: Plano de desenvolvimento Pacotes de trabalho Lista de classes com seus donos
DPF CPF
Processo Nº 3:Planejar por Feature
DMA CLF PPF
sexta-feira, 22 de abril de 2011
Formar a Equipede Planejamento
(Gerente do Projeto)
Determinar a Sequênciade Desenvolvimento
(Equipe de Planejamento)
Atribuir Conjuntos deFeatures para
Programadores Líderes(Equipe de Planejamento)
Atribuir Classes paraos Desenvolvedores
(Equipe de Planejamento)
Processo Nº 3:Planejar por Feature
sexta-feira, 22 de abril de 2011
Regra Empírica da FDD Cada semana de modelagem resulta em 12 semanas de construção Pressuposto: a equipe usa UML em Cores, arquétipos e DNC
Truco (ou Poker) da Estimativa A Escala de 5 Pontos
Nº Estimado de Classes na Feature
Complexidadeda Feature
Esforço(Pessoa-Dia)
1 1 0,5
2 2 1
3 3 2
4 4 4
5 5 8 (ou mais)
David Anderson, Agile Management for Software Engineering, 2003
Estimativas
sexta-feira, 22 de abril de 2011
Com as features devidamente estimadas, o plano de desenvolvimento é criado a partir da capacidade de produção
Com as features na ordem desejada, corta-se a lista em blocos que caibam nas durações das iterações (1 ou 2 semanas) Cuidado para não quebrar em pontos que causem problemas
Cada pacote de trabalho deve ser atribuído a um Programador Líder
Com as “datas” de cada iteração, preencher as “datas” planejadas de cada um dos 6 milestones (as datas geralmente são iguais para as features da iteração)
Iteração 1 Iteração 2 Iteração 3 Iteração 4
Pacote 1(10)
Pacote 2(8)
Pacote 3(13)
Pacote 4(15)
O Plano de Desenvolvimento
sexta-feira, 22 de abril de 2011
Agora na fase de construção propriamente dita, deve-se refinar o projeto (design) para cada feature ou conjunto de features relacionadas
A equipe de features será formada pelos proprietários das classes envolvidas
O resultado será um pacote de trabalho, sob a responsabilidade de um programador líder
Artefatos produzidos: Modelos detalhados (classes e seqüência) Esqueletos de classes com métodos Pacote de trabalho detalhado Relatório de inspeção do design Relatório de progresso atualizado
DPF CPF
4. Detalhar por Feature
DMA CLF PPF
sexta-feira, 22 de abril de 2011
Formar a Equipede Features
(Programador Líder)
Conduzir um EstudoDirigido Sobre o
Domínio de Negócio(Especialista no Domínio)
Estudar Documentosde Referência
(Equipe de Features)
Desenvolver osDiagramas de Sequência
(Equipe de Features)
Refinar o Modelode Objetos
(Programador Líder)
Escrever Prólogos deClasses e Métodos
(Equipe de Features)
Inspecionar oProjeto (Design)
(Equipe de Features)
opcional
opcional
opcional
4. Detalhar por Feature
sexta-feira, 22 de abril de 2011
Os proprietários de classes desenvolvem o código correspondente a cada feature
Os testes de unidade e as inspeções são realizados
O código final (aprovado) é promovido ao build atual
O resultado são funções com valor para o cliente (features)
Artefatos produzidos: Código fonte testado e integrado Relatórios de inspeção e testes Lista de alterações feitas/necessárias Relatório de progresso atualizado DPF CPF
5. Construir por Feature
DMA CLF PPF
sexta-feira, 22 de abril de 2011
Implementar Classese Métodos
(Equipe de Features)
Testes Unitários(Equipe de Features)
Conduzir uma Inspeçãono Código
(Equipe de Features)
Promover para o Build(Programador Líder,Equipe de Features)
5. Construir por Feature
sexta-feira, 22 de abril de 2011
Gerenciamento do Projeto
sexta-feira, 22 de abril de 2011
No ciclo iterativo (processos 4 e 5), o progresso é medido com base em 6 marcos (milestones) bem definidos
A cada etapa cumprida, o percentual respectivo é agregado ao total de progresso da feature
Estudo Dirigido Sobre o Domínio
1%
Desenho(Projeto)
40%
Inspeção doDesenho
3%
Codificação
45%
Inspeção doCódigo10%
Promoçãoao Build
1%
Nº 4: Detalhar por Feature Nº 5: Construir por Feature
DMA CLF PPF
DPF CPF
Medindo o Progresso
sexta-feira, 22 de abril de 2011
Legenda: Atividade em andamento Requer atenção Completada Não iniciada
Id Descrição P.C. D.C.Est. Dirig.Est. Dirig. DesignDesign Insp. DesignInsp. Design Codif.Codif. Insp. Cod.Insp. Cod. BuildBuild
Id Descrição P.C. D.C.Plan. Real. Plan. Real. Plan. Real. Plan. Real. Plan. Real. Plan. Real.
12 Agendar um serviço para um carro HM AS 10/02 10/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03
13 Incluir um novo cliente na lista de clientes HM VS 01/02 01/02 04/02 04/02 05/02 05/02 07/02 07/02 08/02 08/02 09/02 09/02
14 Registrar um serviço realizado num carro AR AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03
15 Registrar uma lista de peças utilizadas num serviço AR
ASSM
10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/0315 Registrar uma lista de peças
utilizadas num serviço ARASSM
Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03Status: SM ficou doente (previsão de retorno: 01/03
16 Calcular o custo total das peças usadas num serviço HM
ASSM
10/02 10/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03
17 Enviar uma fatura para um cliente AR VS 08/03 10/03 13/03 17/03 19/03 20/03
18 Receber um pagamento por um serviço HM AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03
19 Registrar a opção de pagamento preferida por um cliente AR VS Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)Status: Não mais necessária (será feita diretamente no cadastro do cliente)
Monitorando as Features
sexta-feira, 22 de abril de 2011
NE
PendentesBacklog
Fulano
Beltrana
Sicrano
Zé
J.J.
Iniciadas Inspeção/Teste Finalizadas
N N I
N
N NE N I
N NN N
N N N
N N I
E
N
N
N
N N
N N I
Quadro de Tarefas
sexta-feira, 22 de abril de 2011
Início: Fim:
ID: Resp.:
Descrição:
Início:
Estimativa de retorno:
ID: Resp.:
Motivo:
RN12 Sic
18/06 09:15
VN: A
Fórmula de cálculo do imposto: I = ValorBruto * Aliquota
Aliquota -> parâmetro AI3Classe -> VendaTela -> pgVenda
Cartão de tarefa normal (azul)ou emergência (amarelo)
Cartão de impedimento (rosa)
Est.: 4
RN12 Sic
19/06 9:00
18/06 11:30
Classe Venda está sendo alterada
por outra tarefa
Exemplos de Kanbans
sexta-feira, 22 de abril de 2011
Mês/Ano
Porcentagem Completada:
Prazo de Entrega:Completada
Mês e Ano para entrega
Status da Atividade:
Barra de Progresso
Em andamento
Requer atenção (ex.: impedimento)
Completada
Nome daAtividade
de Negócio(nº features)
75%Ainda não iniciada
Iniciais PC
Reportando o Progresso
sexta-feira, 22 de abril de 2011
Painel de Progresso(Parking Lot)
!"#"$%&' ()*&$%&)"$+, -+"$./,***********************0,)12"+&%&*************************3&44&*%"*54,#4"66,**** 7/,*8$898&%&
:"4"$98&)"$+,*%"*;"$%&6*%"*54,%<+,6*=;5>* ?@A
($+4&%&*%"5"%8%,6
=??>
!"#$%&&'
()*+
0,$+4,2"*%"0,$+4&+,6
=B?>
,-.$%&&'
;"$%&*%"54,%<+,6
=CC>
/0#$%&&1
()*+
($D8,*%"54,%<+,6
=BE>
23.$%&&'
()*+
BFA
($+4"#&*%"54,%<+,6
=BF>
,-.$%&&'
()*4
?FA
G"2&+H48,6*%";"$%&6
=B@>
5"6$%&&1
IJAEEA ?A
:"4K*0,$+&6*%"*028"$+"6*=00>* EFA
-$L286"*%"54,1,6+&6*%"0,$+&6=C?>
/0#$%&&1
EJA
G"#86+4,*%"M4&$6&.N"6%&6*0,$+&6
=?F>
5"6$%&&1
OCA
-P"4+<4&%"*7,D&60,$+&6=BB>
/0#$%&&1
BFFA
:"4"$98&)"$+,*%"*(6+,Q<"*=:(>* E@A
R"S8$8./,*%"T$8%&%"6*%"(6+,Q<"=CU>
/0#$%&&1
BFFA
V,D8)"$+&./,%"*V"49&%,48&6
=BE>
738$%&&'
OCA
()*4
-9"8+"*%"G"Q<868.N"6%"*V,D8)"$+,
=BO>
5"6$%&&1
EIA
()*4
()*% ()*+
()*% ()*% ()*% ()*4
W86+")&0,)"498&2
=C?O>
,-.$%&&'
UJA
sexta-feira, 22 de abril de 2011
Diagrama de Fluxo Acumulado
Legenda:
Não iniciada Em andamento
Completada
Tempo (semanas)
Feat
ures
Prazo de Entrega(Lead Time)
Estoque Intermediário(Work in Progress)
Product Backlog
Controle de Produção
sexta-feira, 22 de abril de 2011
FDD eOutras Metodologias
sexta-feira, 22 de abril de 2011
Espectro de Metodologias
UP XPFDD
sexta-feira, 22 de abril de 2011
FDD x SCRUM x XP
FDD
SCRUM
XP
sexta-feira, 22 de abril de 2011
8. Incremento de Produto(pode ser liberado para uso)
6. Dia
5. Iteração(2 a 4 sem.)4. Tarefas
detalhadaspela equipe
1. Visão(RSI, marcos,
versões)
2. Lista de Espera (Backlog) de funcionalidadesdo produto, priorizada pelo Dono do Produto
3. Escopo da Corrida(Sprint)
7. Reuniões Diárias (em pé)
Concepção e Planejamento
1DMA
3PPF
2CLF
Construção
4DPF
5CPF
9. Inspeção eAdaptação
Scrum e FDD
sexta-feira, 22 de abril de 2011
FDD XP
Certo planejamento inicial Planejamento durante o desenvolvimento
Refactoring é exceção Refactoring é a norma
Programadores Líderes e Proprietários de Classes Posse coletiva do código
Design formal eInspeções de código e modelo Programação em pares
FDD e XP: Algumas Diferenças
sexta-feira, 22 de abril de 2011
Iniciação Elaboração Construção TransiçãoProcesso Unificado
FDDDMA CLF PPF
DPF CPF
XP
UP, FDD, XP:Proposta de Uso Combinado
sexta-feira, 22 de abril de 2011
OID: Inovação e Implantação OrganizacionalCAR: Análise e Prevenção de Defeitos
5 EmOtimização
4 GerenciadoQuantitativam.
3 Definido
2 Gerenciado
MelhoriaContínua do
Processo
GerênciaQuantitativa
Padronizaçãodo Processo
GerênciaBásica deProjetos
QPM: Gerenciamento Quantitativo de ProjetoOPP: Performance do Processo Organizacional
RD: Desenvolvimento de RequisitosTS: Solução Técnica
PI: Integração de ProdutosVER: VerificaçãoVAL: Validação
OPF: Foco no Processo OrganizacionalOPD: Definição do Processo Organizacional
OT: Treinamento OrganizacionalIPM: Gerência Integrada de Projeto
RSKM: Gerência de RiscosDAR: Análise e Tomada de Decisão
REQM: Gerência de RequisitosPP: Planejamento de Projeto
PMC: Monitoramento e Controle de ProjetoSAM: Gerência de Acordos com Fornecedores
MA: Medição e AnálisePPQA: Garantia da Qualidade do Processo e do
ProdutoCM: Gerência de Configuração
1 Inicial
Áreas de ProcessosNível Foco ProdutividadeQualidade
RiscoRetrabalho
FDD
Agile CMMI
sexta-feira, 22 de abril de 2011
• É um método ágil e altamente adaptativo, que produz resultados freqüentes, tangíveis e funcionais
• Oferece vantagens dos métodos prescritivos (rigorosos), pois implementa o conceito importante de planejamento, mas sem os exageros de documentação e controle
• Oferece vantagens dos métodos ágeis, onde a preocupação maior é com a produção de código, mas toma o cuidado de planejar o suficiente e controlar o andamento do projeto
• Atende às necessidades dos clientes, gerentes e desenvolvedores
Resumindo, a FDD...
sexta-feira, 22 de abril de 2011
• Geralmente a iniciativa começa nos desenvolvedores• Uma das boas contribuições da XP
• Mas se o desenvolvimento se tornar ágil e a gerência continuar tradicional, haverá desgaste
• A diferença de impedância causa perdas• Assim, a Agilidade deve ser um objetivo comum• Gerência e Desenvolvedores devem responder:
• 1) O que mudar?• 2) Para o que mudar?• 3) Como causar a mudança?
• A escolha da(s) metodologia(s) será resultado do passo 3! Não faça isso antes! • Realize projetos pilotos para experimentar (e errar!)• Adapte a metodologia às suas necessidades
Dicas para ConvencerGerentes e Desenvolvedores
sexta-feira, 22 de abril de 2011
• Adotar Gestão Ágil e FDD não é uma panacéia
• Mas é um bom começo para a melhor compreensão dos caminhos a seguir
• Agilidade e Responsabilidade não são antagônicos, mas mutuamente necessários
Só para lembrar
sexta-feira, 22 de abril de 2011
A adoção da Gestão Ágil de Projetos e FDD, como qualquer tecnologia, deve ser acompanhada de uma revisão no comportamento, nas políticas, nas métricas e nas regras da organização e das pessoas
Muitos benefícios estão por vir, mas é preciso saber plantar e cuidar para poder colher
O retorno vale muitas vezes o investimento!
Motivação é a chave para mudanças!!
Conclusão
sexta-feira, 22 de abril de 2011
Agile Alliance www.agilealliance.org
Agile Project Management Leadership www.apln.org
Agile Management www.agilemanagement.net
FDD www.featuredrivendevelopment.com www.heptagon.com.br/fdd/
Grupos de Discussão http://groups.yahoo.com/group/AgileProjectManagement http://br.groups.yahoo.com/group/Agile-Brasil http://br.groups.yahoo.com/group/GUFDD
Para saber mais
sexta-feira, 22 de abril de 2011
Literatura Recomendada
sexta-feira, 22 de abril de 2011
Adail Muniz Retamal Heptaman
Agradecimento
sexta-feira, 22 de abril de 2011
Engenheiro de Sistemas Administração de Empresas MBA em Planejamento Estratégico
Chefe da Seção de Análise e Desenvolvimento (TRE-MT) Certificação Delphi e JBuilder
Artigos publicados nas revistas Micro Sistemas (!?), Clube Delphi e MundoPM
Palestrante no 12º Congresso MT Digital - 2008 Palestrante na Conferência da Borland – Borcon Revolutions
2007 Palestrante na Conferência Mundial da CodeGear – CodeRage III
2008
Assinante do Agile Manifesto Membro da Agile Aliance
Eng. Jorge Luis Bublitz
sexta-feira, 22 de abril de 2011
"No que diz respeito ao empenho, ao compromisso, ao
esforço e à dedicação, não
existe meio termo. Ou você faz uma coisa
bem feita ou não faz."
Frase
sexta-feira, 22 de abril de 2011
Valeu !!!!!Jorge FDDMan
Email e MSN:[email protected]
Páginas:h:p://bublitz.tripod.com
h:p://jorge-‐fdd.blogspot.com
Um abraço!!!!
sexta-feira, 22 de abril de 2011