Aula FDD CESAR Recife GAP

CESAR - GAP
DESENVOLVIMENTO 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."

• Engº Jorge Luis Bublitz
sexta-feira, 22 de abril de 2011

Agenda

• Contexto
• Metodologias
• Agilidade e Metodologias Ágeis
• Mudanças
• FDD


Contexto


O que é Desenvolvimento de
Software?

“É 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


Características

• 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


The Caos Report - 1995

Concluídos com Sucesso
16%
Falharam
31%

Concluídos com Alterações
53%

Standish Group – www.standishgroup.com


Falharam
Concluídos com Sucesso
23%
28%

49%



Falharam
24% Concluídos com Sucesso
32%

44%


Vamos Analisar
Sucesso Alterações Falharam

25,00 50,00 75,00 100,00

1994
1996
1998
2000
2002
2004
2006
2009


Funcionalidades/Funções
Utilizadas em um Sistema

Sempre
7%
Muito
13%

Nunca
45% Algumas Vezes
16%

Raramente
19%


Culpado(s)???

Clientes
Desenvolvedores
Analistas
Ferramentas

Processo

A Solução é...

• Não existe uma solução mágica e única,
mas sim um conjunto de práticas
reconhecidamente eﬁcientes.
• Desenvolvimento Incremental,
Reﬁnamento de Requisitos, BONS
PROJETISTAS...


A Solução é...

• 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 utilizada até hoje:

• 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


Metodologias


Modelo Tradicional
Levantamento
de Requisitos

Projeto

Implementação

Testes

Implantação


Modelo Tradicional

• 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, ...


Novos Tempos (??)

Menor
Tempo

Maior Menor
Qualidade Custo


Novos Problemas (?)

Escopo

Qualidade Prazo

Custo


Análise OO


Análise Orientada por Objetos

• É 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


Métodos Orientados a Objetos

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étodo Unificado

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 .


UML
• 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)


Evolução


Diagramas da UML

• Estáticos:
• Use Cases
• Classes
• Pacotes
• Dinâmicos:
• Interação
• Sequência
• Colaboração
• Estado (Statechart)
• Atividade


Caso de Uso


Classe


Seqüência


Atividade


Estado


A Decepção

• 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


Agilidade e
Metodologias Ágeis


Agilidade
• 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 - Software

“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


Metodologias Ágeis
• 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”

Manifesto para o
Desenvolvimento Ágil de Software

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


Princípios Ágeis
• Satisfação do Cliente
• Responder às Mudanças
• Entrega Freqüente
• Motivação
• Software que Funciona
• Ritmo Constante
• Simplicidade


Cuidado com o Manifesto
Radical

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


O Sucesso das Metodologias
Ágeis

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


Quem Adotou ou Está
Adotando?


Mas...

• 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


Maiores Dificuldades

• Apoio das instâncias superiores
• Gerenciamento de equipes
• Problemas técnicos
• Interação com outros departamentos
• Interação com clientes


Pessoas

Representam uma grande fonte de
problemas


Gerentes Tradicionais

• Não é assim que eu sempre fiz
• Medo de perder o controle
• O chão desabou, como agir?
• E a minha autoridade?


Arquitetos

• 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?


Programadores

• 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


Testadores
• Estão tirando o meu emprego?
• Vou ter que aprender a programar?


DBAs

• 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?


Clientes

• 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?


Coach novato

• 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.


Métodos Pseudo-Ágeis

• 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
• mas vamos usar essa ferramenta que compramos
para controlar todos os passos do desenvolvimento
para atingirmos a qualidade total
• mas precisamos fazer uma coleta de requisitos
detalhada e um planejamento completo antes de
começar a implementar, caso contrário vamos
fazer besteira.



• mas nós é quem vamos implementar o sistema,
então vamos explicar ao cliente quais são as
funcionalidades mais importantes.
• 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.
• mas infelizmente, não podemos nos dar ao luxo
de escrever testes para tudo, isso é radicalismo.


Levantamento
de Requisitos
XP, Scrum, ...
Projeto

Implementação

Testes

Implantação
Implantação
com Testes


Mitos sobre as
Metodologias Ágeis


Programação Radical

“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


Principal Mito

• 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!

Consequência #1

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 #2

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 #3
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 #4

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 #5

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!


Richard Feynman: Agilista??

• 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!


A “MÁ” Agilidade
• “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 “BOA” Agilidade

• 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

• 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

Mudanças

Projetos e Processos


Porque mudar??

• Única constante do universo:
MUDANÇA
• Para melhorar
• Para motivar
• Para nos tornarmos mais eficientes
e eficazes
• Para nos tornarmos mais ágeis


Além disso...

• 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


O Processo de Mudança


Diferenças de Paradigmas
• Tradicional • Ágil
• Ser capaz de controlar / • Ser capaz de lidar com a
eliminar a incerteza incerteza
• Planejamento e controle de • Planejamento e controle de
progresso através do progresso através da
Caminho Crítico / EVA Corrente Crítica / Buffers
• Replanejar deve ser a • Replanejar deve ser a regra
exceção sempre
(há limites práticos)
• Controle rígido do escopo
do projeto
• Controle do escopo das
iterações
• Teorias básicas:
Gerenciamento Total da • Teorias básicas:
Qualidade Teoria do Caos
Controle Estatístico de Teoria das Restrições (TOC)
Processos Produção Enxuta (Lean)


Planejar X Plano

“Um plano não é nada...
Mas planejar é tudo!”

Dwight D. Eisenhower
34º Pres. EUA
(1953-1961)


Para que serve um Processo?

• 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)


Características de um bom
Processo

• É 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


O Processo Ágil...

• 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


Desenvolvimento
Dirigido a
Funcionalidades


Definição
• “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


Onde nasceu a FDD

•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


Decisão x Resultado

• 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


Os “Culpados”

Jeff De Luca Peter Coad

Stephen Palmer
John Mac Felsing


O Berço da FDD

Sede do United Overseas Bank David Anderson, o GUI-Man

Peter Coad e a Paul Szego e Jeff De Luca e os
Equipe de Modelagem Stephen Palmer Programadores


O que a FDD pode
proporcionar??

• Inovação Contínua
• Adaptabilidade do Produto
• Cronogramas Reduzidos de Entrega
• Adaptabilidade das Pessoas e
Processos
• Resultados Confiáveis


Principais
Características


Características da FDD

• 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


O que é Feature?

• 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


MODELO

• <A><R><O>
• <Ação> <Resultado> <Objeto>

• Calcular o Total da Venda


Outros Exemplos
• 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


Exercício

• 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


Melhores Práticas da FDD

• 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


1) Modelagem de Objetos do
Domínio
• Diagramas de classes com os principais tipos de
objetos no domínio do problema e suas relações
• Auxilia na captura e esclarecimento dos requisitos
• Possibilita um entendimento comum e mais completo
sobre 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


Exemplo de Modelo de Domínio


2) Desenvolvimento por
Funcionalidade

• 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.)


As Features Preenchem o
Modelo de Domínio
ClasseA

 Área 1

 Atividade 1.1
 Feature 1.1.1
Feature 1.1.2 ClasseB

Atividade 1.2
 Feature 1.2.1
Feature 1.2.2

ClasseC
Área 2
Atividade 2.1
Feature 2.1.1
Feature 2.1.2

Atividade 2.2
Feature 2.2.1


As Features Preenchem o
Modelo de Domínio
Objeto1 Objeto2 Objeto3 Objeto4
TelaA ClasseB ClasseC ClasseD
Usuário
1: feature1
1.1: operacaoC1
1.1.1: operacaoD1

1.2: operacaoA1

2: feature2
2.1: operacaoC2
2.1.1: operacaoD1

2.2: operacaoA2


3) Posse individual de classe
(código)
• Estipula quem (pessoa ou papel) é o
responsável final pelo conteúdo de uma
classe (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


4) Equipes de Features

• 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


5) Inspeções
• 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
Taxa Média de Detecção de Defeitos
• Inspeções cortam erros em mais de 80%
• 1 hora de inspeção pode evitar 60%
60%
de 5 a 30 horas de correções
55%

45%
Teste Unitário
Teste Funcional 35% 45%

• Benefícios secundários Teste de Integração
Inspeção de Design
Inspeção de Código
24%
30%

• Transferência de conhecimento 15%

• Conformidade com padrões Técnica 0%

Jones, C.L. “A Process-Integrated Approach to Defect
Prevention”, IBM Systems Journal, 1985


Detecção Antecipada de
Defeitos

Prof. Guilherme Horta, COPPE/UFRJ, 2004

Como Conduzir Uma Inspeção

Artefato

1 Form.
Organizador
Planejamento Planejamento

Form.
2
Relato de
Inspetor Detecção
Defeitos

Form.
Ad-Hoc 3
Moderador Relato de
Técnicas de Leitura Coleção
Inspetor Defeitos
Checklists Autor Form.
Relato de
4 Defeitos
Correção
Autor Artefato
Prof. Guilherme Horta, COPPE/UFRJ, 2004 Corrigido


6) Montagens Freqüentes
• Em intervalos regulares, compilar o sistema com
todas as features completadas até o momento
• Semanalmente, diariamente ou continuamente
• Ajuda a antecipar erros de integração
• Garante que sempre haverá alguma coisa para
mostrar 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


7) Gerenciamento de
Configuração
• Disciplina que suporta e controla as
evoluções e modificações em artefatos-
chave dentro do ciclo de desenvolvimento
de um software Principais
Artefatos de
Desenvolvimento
do Produto
Desenvolvimento
• Objetivos
• Facilitar o desenvolvimento de software
• Garantir a integridade dos produtos
• Controlar efetivamente as modificações Gerenciamento

• Itens de Configuração: Artefatos gerados ou
manipulados durante o ciclo de vida da
aplicação
• Arquivos, Requisitos, Documentos, Modelos,
Testes
• Processos, Contratos, Regulamentações
• Solicitações de Mudança, Defeitos, Tarefas


Tarefas Rotineiras do
Gerenciamento de Configuração

• Versionamento  Gerenciamento de Processo
 Definição de Workflow
• Check out/check in
 Critérios de Entrada/Saída
• Histórico de revisões
• Branching & Merging  Notificações
• Visões de Projeto  Garantia de Segurança
 Gerenciamento de Montagem
• Gestão de Mudanças  Identificação de
• Acompanhamento de defeitos Dependências
• Listas de Melhoria  Controle de Montagens
• Associações  Gerenciamento de Liberação
• Rastreabilidade  Rótulos
 Estados Promocionais
• Gestão de Tarefas
 Implantação
• Criação e Acompanhamento
• Ficha de tempo


8) Relatório/Visibilidade de
Resultados
 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


Os Papéis


Principais Papéis

Gerente de
Desenvolvimento

Especialista
Domínio do Programador
Negócio Líder
GERENTE DE
PROJETOS

Arquiteto Proprietário
Líder de Classes


Gerente de Projeto

• 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 Desenvolvimento

• 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
conﬂito 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


Especialista no Domínio de
Negócio

• 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 ﬁxo da equipe e sempre esta fornecendo
feedback das entregas para todos os envolvidos.


Arquiteto Líder

• É um proﬁssional 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 identiﬁcadas
• 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.


Programador Líder

• Também chamado de Progranador-Chefe
• É um proﬁssional mais experiente, que possui
reconhecimento como tal pela equipe
• Coordena o desenvolvimento das features, monta as
equipes de features e participa das deﬁniçõ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.


Proprietário de Classes

• É 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.


Funções de Apoio

Gerente de Guru da Engenheiro de
Versão Linguagem Desenvolvimento

Produtor de
Administrador
Testadores Ferramentas e
de Sistemas
Utilitários

Escritores
Implantadores
Técnicos


Os 5 Processos


Os 5 Processos
Requisitos Concepção e Planejamento
Desenvolver Construir Planejar
Mais forma que conteúdo um Modelo a Lista de por
Abrangente Features Feature

Plano de
Desenvolvimento

Construção
Modelo de Objetos

Detalhar Construir Progresso
Mais conteúdo na forma por por
Feature Feature
Produto

Pacotes de Trabalho

Fonte: Heptagon – www.heptagon.com.br


O Porquê de Cada Processo
 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 Contexto da FDD
Discussões Iniciais Sobre Requisitos
Obter Patrocínio da Gerência

Escolha da Linguagem de Programação
Feature-Driven Development
Planejamento Geral

Desenvolver um Modelo Abrangente Escolha da Plataforma Tecnológica
Preparação de Orçamento
Construir a Lista de Features Protótipo Técnico
Alocação de Pessoal
Planejar por Feature
Protótipo da Interface com o Usuário
Gerenciamento de Recursos
Detalhar por Feature
Limpeza de Dados
Gerenciamento de Problemas Construir por Feature
Conversão de Dados
Gerenciamento das Alterações nos Requisitos Teste do Sistema

Teste de Carga
Teste de Aceitação do Usuário
Sistema Piloto

Desenvolvimento em Fases


Principais Disciplinas
Envolvidas

Gestão Ágil de Projetos
Engenharia
de Requisitos
Concepção e Planejamento
Desenvolvimento
de Requisitos Decomposição
Análise OO Planejamento
Funcional
Gerência
de Requisitos

Construção

Gerência
de Conﬁguração Programação
Projeto OO
e Teste OO


Análise e Desenho/Projeto
Orientados por Objetos

 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


Programação e Teste
Orientados por Objetos
 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


Estabelecer o Propósito do
Projeto
Meta

Condição Condição Condição
Necessária Necessária Necessária

Objetivo Objetivo Objetivo
Intermediário Intermediário Intermediário

Objetivo Objetivo Objetivo
Intermediário Intermediário Intermediário

Objetivo Objetivo
Intermediário Intermediário


Tipos de Requisitos
Funcionais Não-Funcionais
Requisitos
de Negócio

Documento de Visão e Escopo
Regras de
Requisitos Negócio
de Usuário
Atributos
de Qualidade
Casos de Uso
Interfaces
Requisitos Externas
de Sistema
Requisitos
Funcionais
Restrições

Especificação de
Karl Wiegers, “Software Requirements”
Requisitos de Software


1. Desenvolver um Modelo
Abrangente
 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


Abrangente
 É 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, DMA CLF PPF
atividades, estados, casos de uso
 Lista preliminar de requisitos
DPF CPF
 Anotações nos modelos


Abrangente

Conduzir um Estudo
Formar a Equipe Dirigido Sobre o
de Modelagem Domínio de Negócio
(Gerente do Projeto) (Ger. Projeto, Especialistas)

opcional Desenvolver Modelos
Estudar Documentos em Pequenos Grupos
(Equipe de Modelagem) (Equipe de Modelagem
em pequenos grupos)

Refinar o Modelo de
Desenvolver um Objetos Completo
Modelo como Equipe (Arquiteto Líder,
(Equipe de Modelagem) Equipe de Modelagem)

Escrever Comentários
Sobre o Modelo
(Arquiteto Líder,
Programador Líder)


Arquitetura em Camadas

CO
Apresentação

O F
Negócio – Domínio do Problema

Persistência Interface com
Outros Sistemas


UML em Cores
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).


Arquétipo: Momento-Intervalo

 Representa algo que necessita ser registrado,
por razões de negócio ou até mesmo legais, que
ocorre em algum momento no tempo ou durante
um intervalo de tempo
 São atividades, eventos e serviços
 Um momento-intervalo também pode ter
“mi-detalhes”, ou seja, ser composto por
pequenas 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: Pessoa-Lugar-Coisa

 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 no
sistema 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: Papel
 É 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: Descrição
 É como um item num catálogo, definindo as
características de uma determinada coisa,
lugar ou até mesmo pessoa (menos comum,
mas possível)
 Usado para concentrar dados comuns a
diversos objetos, possibilitando perguntas de
negócio interessantes, como a quantidade
de
objetos 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


Domain Neutral Component
(Componente Genérico de Modelagem)

 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


UML Sem Cores
Hotel Funcionario PessoaFisica

Nome * DtAdmissao Nome
Endereco CTPS CPF
Estrelas

*
TipoQuarto Quarto Estadia Hospede

Descricao * ID DHInicio * Score
NumSolt Status DHTermino DtUltVisita
NumCasal ValorTotal
Fumante?

*
Servico

Data
Hora
Valor


UML em Cores
Hotel Funcionario PessoaFisica

Nome * DtAdmissao Nome
Endereco CTPS CPF
Estrelas

*
TipoQuarto Quarto Estadia Hospede

Descricao * ID DHInicio * Score
NumSolt Status DHTermino DtUltVisita
NumCasal ValorTotal
Fumante?

*
Servico

Data
Hora
Valor


2. Construir a Lista de Features

 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)
DMA CLF PPF
 Lista de Features
DPF CPF
 Requisitos mais detalhados

2. Construir a Lista de Features

Formar a Equipe
de Lista de Features
(Gerente do Projeto,
Gerente de Desenvolvimento)

Construir a
Lista de Features
(Equipe de
Lista de Features)


FBS: Feature Breakdown
Structure
Sistema ou
Gerenciamento de ...
Aplicaçã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 Funcionalidade Atividade de Negócio

<Substantivo> Funcionalidade <Ação> <Resultado> <Objeto>
<VerboInﬁnitivo> ...


As Features preenchem o
Modelo
Área n
Atividade X
Feature 1
Classe A
Feature 2
Atividade Y
Feature 3
Feature 4
Classe B
Feature 5
...

Classe C


Processo Nº 3:
 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: DMA CLF PPF
 Plano de desenvolvimento
 Pacotes de trabalho
DPF CPF
 Lista de classes com seus donos


Processo Nº 3:

Formar a Equipe Determinar a Sequência
de Planejamento de Desenvolvimento
(Gerente do Projeto) (Equipe de Planejamento)

Atribuir Conjuntos de
Atribuir Classes para
Features para
os Desenvolvedores
Programadores Líderes
(Equipe de Planejamento)
(Equipe de Planejamento)


Estimativas
 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 Complexidade Esforço
Feature da Feature (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


O Plano de Desenvolvimento
 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 Pacote 2 Pacote 3 Pacote 4
(10) (8) (13) (15)


4. Detalhar por Feature
 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
 Modelos detalhados (classes e seqüência)
 Esqueletos de classes com métodos
 Pacote de trabalho detalhado DMA CLF PPF
 Relatório de inspeção do design
 Relatório de progresso atualizado
DPF CPF


4. Detalhar por Feature
opcional
Conduzir um Estudo
Formar a Equipe
Dirigido Sobre o
de Features Domínio de Negócio
(Programador Líder) (Especialista no Domínio)

opcional opcional
Estudar Documentos Desenvolver os
de Referência Diagramas de Sequência
(Equipe de Features) (Equipe de Features)

Reﬁnar o Modelo Escrever Prólogos de
de Objetos Classes e Métodos
(Programador Líder) (Equipe de Features)

Inspecionar o
Projeto (Design)
(Equipe de Features)


5. Construir por Feature

 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)
 Código fonte testado e integrado DMA CLF PPF
 Relatórios de inspeção e testes
 Lista de alterações feitas/necessárias
 Relatório de progresso atualizado DPF CPF


Aula FDD CESAR Recife GAP

Recommandé

Recommandé

Contenu connexe

Similaire à Aula FDD CESAR Recife GAP

Similaire à Aula FDD CESAR Recife GAP (16)

Aula FDD CESAR Recife GAP