Aula FDD C.E.S.A.R

Jorge Luis Bublitz

Contexto Metodologias Orientação a Objetos Agilidade e Metodologias Ágeis Gestão Ágil de Projetos Mitos Mudanças FDD

“É 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 BirrellA Practical Handbook for Software

Development, 1985

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

“O limite do caos é definido como um estado natural entre ordem e caos, um amplo

compromisso entre estrutura e surpresa. O limite do caos pode ser visualizado como um

estado instável, parcialmente estruturado (...). É instável porque é constantemente atraído para

o caos ou para a ordem absoluta.”

Juan Nogueira, Surfing the Edge of Chaos: Applications to Software Engineering, 2000

Falharam

23%

Concluídos com Sucesso

28%

Completadoscom Alterações

49%

Projetos de Software

Standish Group – www.standishgroup.com

“Para aqueles que ficam imaginando por que o software da Microsoft está sempre um pouco

aquém do esperado, aqui está uma grande parte da razão: há pessoas apenas o suficiente

para implementar as características que absolutamente devem ser incluídas e só há tempo disponível para implementar cada

característica da maneira mais rápida aceitável. E há tempo e pessoas somente o

necessário para testar o produto até o ponto em que o mercado o aceitará marginalmente;

não mais.”

The 12 Simple Secrets ofMicrosoft Management

David Thielen

“Nenhum floco de neve em uma

avalanche se sente responsável por ela”

Stanislaw Lecescritor polonês

Não existe uma solução mágica e única, mas sim um conjunto de práticas reconhecidamente eficientes. Desenvolvimento Incremental, Refinamento de Requisitos

e Prototipação Rápida, BONS PROJETISTAS...

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

Adoção de Metodologias Objetivo: tornar o desenvolvimento mais

previsível e mais eficiente Impõe disciplinas rígidas Processos detalhados = Documentação Planejamento é a ênfase

Passam a impressão de serem uma PANACÉIA – cura para todos os males

Também chamado de Modelo em Cascata (Waterfall)

Proposto por Winston W. Royce em 1970 Orientado para documentação Ênfase em planejamento, horários, prazos,

orçamentos e implementação de sistemas inteiros

Há variantes: Incremental, Evolucionário, ...

Qualidade

Prazo

Custo

Escopo

É 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

Oferece uma visão “holística” do assunto sendo analisado

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)

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

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)

Estáticos: Use Cases Classes Pacotes

Dinâmicos: Interação

▪ Sequência▪ Colaboração

Estado (Statechart) Atividade

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.gi.li.da.de sf (lat agilitate)

1. Qualidade do que é ágil2. Desembaraço, ligeireza, presteza de

movimentos3. Mobilidade, perspicácia, vivacidade

Geralmente associa-se AGILIDADE com Rapidez, Flexibilidade, Leveza

“Agilidade é a habilidade para criar e responder às mudanças, para lucrar num ambiente turbulento de negócios, para equilibrar

flexibilidade e estabilidade.”

Jim HighsmithAgile Software

Development Ecosystems2002

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”

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 frequente

MotivaçãoSoftware

que Funciona

Ritmo Constante

Simplicidade

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

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

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

Apoio das instâncias superiores

Gerenciamento de equipes

Problemas técnicos

Interação com outros departamentos

Interação com clientes

Representam uma grande fonte de problemas

Não é assim que eu sempre fiz

Medo de perder o controle

O chão desabou, como agir?

E a minha autoridade?

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?

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

Estão tirando o meu emprego?

Vou ter que aprender a programar?

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?

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?

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

“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

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!

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”

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

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:

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)

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!

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!

“Foco em datas na pior forma possível: ciclos curtos, entregas rápidas, estimativas e re-estimativas frequentes”

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

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

Projetos e Processos

Única constante do universo:MUDANÇA

Para melhorar

Para motivar

Para nos tornarmos mais eficientes e eficazes

Para nos tornarmos mais ágeis

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

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

Qualidade Controle Estatístico de

Processos

Á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 Caos Teoria das Restrições (TOC) Produção Enxuta (Lean)

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

Dwight D. Eisenhower34º Pres. EUA

(1953-1961)

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)

É 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

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

“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.”

Jorge L. Bublitz

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: Implantação das metodologias de OOAD de Peter Coad e de Gerência de Projetos de Jeff De Luca

Resultado: 2.000 Features entregues por uma equipe de 50 pessoas, 15 meses após a contratação da dupla

Jeff De Luca Peter Coad

Stephen Palmer John Mac Felsing

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

Inovação Contínua

Adaptabilidade do Produto

Cronogramas Reduzidos de Entrega

Adaptabilidade das Pessoas e Processos

Resultados Confiáveis

Fornece a estrutura suficiente para equipes maiores

Enfatiza a produção de software de qualidade Entrega resultados frequentes, 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í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

<ação> <resultado> <objeto>

Calcular o total da venda

ação objeto resultado

Novidade? Nunca viu algo parecido?

ENTRADA PROCESSAMENTOPROCESSAMENTO SAÍDA

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

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

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

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

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

OA

R

Área 1

Atividade 1.1Feature 1.1.1

Feature 1.1.2

Atividade 1.2Feature 1.2.1

Feature 1.2.2

Área 2Atividade 2.1

Feature 2.1.1

Feature 2.1.2

Atividade 2.2Feature 2.2.1

ClasseA

ClasseB

ClasseC

Objeto1

TelaA

Objeto2

ClasseB

Objeto3

ClasseC

Objeto4

ClasseD

Usuário

1: feature11.1: operacaoC1

1.2: operacaoA1

2.1.1: operacaoD1

2.1: operacaoC2

2.2: operacaoA2

2: feature2

1.1.1: operacaoD1

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

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

Objetivo

Demonstrar como funciona a posse coletiva

Atividades

Formar grupos de 3 a 5 pessoas

Cada grupo receberá 3 conjuntos de vogais e 2 de consoantes

Todos podem mexer em quaisquer letras

O instrutor mostrará uma palavra

Cada grupo deverá montar a palavra rapidamente sobre a mesa

O grupo que montar a palavra corretamente primeiro ganha 1 ponto

O grupo terá 1 minuto para discutir como melhorar seu desempenho

Repetir o processo para 5 palavras

Ganha o grupo que fizer mais pontos O B A

Objetivo

Demonstrar como funciona uma equipe de features

Atividades

Formar grupos de 3 a 5 pessoas

Cada grupo receberá 3 conjuntos de vogais e 2 de consoantes

Cada pessoa no grupo será dona de um conjunto de letras

Apenas o “dono” das letras poderá mexer nelas

O instrutor mostrará uma palavra

Cada grupo deverá montar a palavra rapidamente sobre a mesa

O grupo que montar a palavra corretamente primeiro ganha 1 ponto

O grupo terá 1 minuto para discutir como melhorar seu desempenho

Repetir o processo para 5 palavras

Ganha o grupo que fizer mais pontos

O B A

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 evitarde 5 a 30 horas de correções

Benefícios secundários Transferência de conhecimento

Conformidade com padrões24%

35%

45%

55%

60%

0%

10%

20%

30%

40%

50%

60%

Técnica

Taxa Média de Detecção de Defeitos

Teste Unitário

Teste Funcional

Teste de Integração

Inspeção de Design

Inspeção de Código

Jones, C.L. “A Process-Integrated Approach to Defect

Prevention”, IBM Systems Journal, 1985

Pro

f. Gu

ilhe

rme

Ho

rta, C

OP

PE

/UF

RJ, 2

00

4

1

Planejamento

2

Detecção

3

Coleção

4

Correção

Artefato

Form.

Planejamento

Form.

Relato de

Defeitos

Form.

Relato de

Defeitos

Form.

Relato de

Defeitos

Artefato

Corrigido

Organizador

Inspetor

Moderador

Inspetor

Autor

Autor

Ad-Hoc

Técnicas de Leitura

Checklists

Prof. Guilherme Horta, COPPE/UFRJ, 2004

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

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

Principais

Artefatos de

Desenvolvimento

Desenvolvimento

do Produto

Gerenciamento

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

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

Ger. Contas de Clientes (CC) – 90%

Análise dePropostas de

Contas(23)

Nov 2005

95%

Registro deTransaçõesdas Contas

(30)

Dez 2005

82%

Aberturade NovasContas

(11)

Nov 2005

100%

PC-2 PC-2 PC-2

23-24/01/2009

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

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

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

109

Arquiteto Líder É um profissional com experiência em análise e modelagem, capaz de liderar a

equipe no desenvolvimento do modelo que será construído para implementar as features identificadas

Programador Líder É 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

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.

Sua equipe não ficar assim:

Concepção e Planejamento

Construção

Desenvolver

um Modelo

Abrangente

Planejar

por

Feature

Detalhar

por

Feature

Construir

por

FeatureMais conteúdo na forma

Mais forma que conteúdo

Modelo de Objetos

Pacotes de Trabalho

Requisitos

Produto

Plano de

Desenvolvimento

Progresso

Construir

a Lista de

Features

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

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

Gestão Ágil de Projetos

Concepção e Planejamento

Construção

Análise OO PlanejamentoDecomposição

Funcional

Projeto OOProgramação

e Teste OO

Engenharia

de Requisitos

Desenvolvimento

de Requisitos

Gerência

de Requisitos

Gerência

de Configuração

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

Meta

Condição

Necessária

Condição

Necessária

Condição

Necessária

Objetivo

Intermediário

Objetivo

Intermediário

Objetivo

Intermediário

Objetivo

Intermediário

Objetivo

Intermediário

Objetivo

Intermediário

Objetivo

Intermediário

Objetivo

Intermediário

Engenharia deRequisitos

IIT Management & Governance

Gerenciamento & Governança de TI

Demanda Estratégica & Operacional

Necessid

ades d

e N

egócio

Necessid

ades d

e N

egócio

Opera

ções d

e T

I (Pro

dução)

Opera

ções d

e T

I (Pro

dução)

ANÁLISE

Priorização | Verificação |Riscos | Estimação

DESCOBERTA

Técnicas | Glossário |Fronteiras do Sistema |

Stakeholders

ESPECIFICAÇÃO

Detalhar Requisitos | Protótipo |Modelo de Cenários de Negócio |

Modelo de Casos de Uso

VALIDAÇÃO

Revisão | Assinatura |Baseline

GERENCIAMENTO

Armazenamento | Medição & Auditoria | Ligação & Rastreamento | Relatórios | Segurança

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

23-24/01/2009 “Mapas Mentais: Enriquecendo Inteligências”, Walther Hermann & Viviani Bovo

É hora de iniciar o projeto! O instrutor e a turma decidirão sobre um

domínio de negócio a ser usado como exemplo

Descrever o propósito para o sistema Criar o mapa estratégico para o projeto Usar mapas mentais para capturar e

comunicar os principais conceitos do domínio de negócio

Também chamada de “Modelagem de Objetos do Domínio”

Preocupa-se mais com a formado 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

É 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

DMA CLF PPF

DPF CPF

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

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

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

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

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

É 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

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

Quarto

IDStatus

Hospede

ScoreDtUltVisita

Hotel

NomeEnderecoEstrelas

PessoaFisica

NomeCPF

Estadia

DHInicioDHTerminoValorTotal

*

Funcionario

DtAdmissaoCTPS

*

*

Servico

DataHoraValor

*

TipoQuarto

DescricaoNumSoltNumCasalFumante?

*

Quarto

IDStatus

Hospede

ScoreDtUltVisita

Hotel

NomeEnderecoEstrelas

PessoaFisica

NomeCPF

Estadia

DHInicioDHTerminoValorTotal

*

Funcionario

DtAdmissaoCTPS

*

*

Servico

DataHoraValor

*

TipoQuarto

DescricaoNumSoltNumCasalFumante?

*

Seguir o processo 1 para criar o modelo de objetos do domínio de negócio Os Especialistas no Domínio farão apresentações

sobre o negócio

A Equipe de Modelagem fará perguntas e anotações

Em pequenos grupos, desenvolver alternativas de modelos (usando os 4 arquétipos e o DNC)

Obter consenso no grande grupo sobre um modelo único

Anotar nesse modelo as razões para as decisões tomadas

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

DMA CLF PPF

DPF CPF

Formar a Equipe

de Lista de Features

(Gerente do Projeto,

Gerente de Desenvolvimento)

Construir a

Lista de Features

(Equipe de

Lista de Features)

Sistema ou

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

Atividade de NegócioFuncionalidade

Funcionalidade

Gerenciamento de ...

<Substantivo>

<VerboInfinitivo> ...

<Ação> <Resultado> <Objeto>

Classe A

Classe B

Classe C

Área n

Atividade X

Feature 1

Feature 2

Atividade Y

Feature 3

Feature 4

Feature 5

...

Seguir o processo 2 para criar a lista de features

Se necessário, consultar os Especialistas no Domínio

Geralmente são eles quem determinam as áreas de negócio e até as próprias atividades de negócio

Verificar se há redundância entre as features

Verificar se as features estão escritas de acordo com o padrão sugerido

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

DMA CLF PPF

DPF CPF

Formar a Equipe

de Planejamento

(Gerente do Projeto)

Determinar a Sequência

de Desenvolvimento

(Equipe de Planejamento)

Atribuir Conjuntos de

Features para

Programadores Líderes

(Equipe de Planejamento)

Atribuir Classes para

os Desenvolvedores

(Equipe de Planejamento)

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 da Estimativa A Escala de 5 Pontos

Nº Estimado de Classes na Feature

Complexidadeda Feature

Esforço(Pessoa-Dia)

1 1 1

2 2 2

3 3 3

4 4 5

5 5 8 (ou mais)

David Anderson, Agile Management for Software Engineering, 2003

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)

Seguir o processo 3 para criar o plano de desenvolvimento Estimar as features, de acordo com a escala de 5 pontos ou pelo Truco

da Estimativa

Consultar um representante do cliente sobre as prioridades

Determinar a dependência entre as features

Atribuir classes aos desenvolvedores

Verificar a distribuição da carga de trabalho entre os Proprietários de Classes

Determinar quantas iterações de 2 semanas serão necessárias

Criar o plano de desenvolvimento, com asdatas previstas para cada iteração

Agora na fase de construção propriamente dita, deve-se refinar o projeto (design) para cada featureou 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

DMA CLF PPF

DPF CPF

Formar a Equipe

de Features

(Programador Líder)

Conduzir um Estudo

Dirigido Sobre o

Domínio de Negócio

(Especialista no Domínio)

Estudar Documentos

de Referência

(Equipe de Features)

Desenvolver os

Diagramas de Sequência

(Equipe de Features)

Refinar o Modelo

de Objetos

(Programador Líder)

Escrever Prólogos de

Classes e Métodos

(Equipe de Features)

Inspecionar o

Projeto (Design)

(Equipe de Features)

opcional

opcional

opcional

Seguir o processo 4 para detalhar um pacote de trabalho Com o pacote de trabalho para a iteração, detalhe os requisitos

para cada feature, se necessário, consultando os Especialistas no Domínio

Para features mais complexas, desenhar um diagrama de seqüência ou de atividades

Caso algum atributo, método, relacionamento ou classe seja incluído/excluído/alterado, atualizar o modelo de objetos

Anotar as decisões tomadas no modelo Preparar o código fonte das classes (esqueleto) Realizar uma inspeção de qualidade no trabalho

realizado

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

DMA CLF PPF

DPF CPF

Implementar Classes

e Métodos

(Equipe de Features)

Testes Unitários

(Equipe de Features)

Conduzir uma Inspeção

no Código

(Equipe de Features)

Promover para o Build

(Programador Líder,

Equipe de Features)

Seguir o processo 5 para construir as features Para cada feature do pacote de trabalho, siga as

instruções do diagrama de seqüência (se houver) e implemente as alterações propostas nas classes (lembre-se da posse individual de classe!)

Realize testes unitários em cada feature, relatando os resultados para a equipe

Realize uma inspeção no código gerado Se houver erros, corrigir e testar novamente Integre a porção de código trabalhado no produto

final Realize testes de integração

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

Estudo Dirigido

Sobre o Domínio

1%

Desenho

(Projeto)

40%

Inspeção do

Desenho

3%

Codificação

45%

Inspeção do

Código

10%

Promoção

ao Build

1%

Nº 4: Detalhar por Feature Nº 5: Construir por Feature

DMA CLF PPF

DPF CPF

Legenda: Atividade em andamento Requer atenção Completada Não iniciada

Id Descrição P.C. D.C.Est. Dirig. Design Insp. Design Codif. Insp. Cod. Build

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

13Incluir um novo cliente na lista de

clientesHM 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

14Registrar um serviço realizado num

carroAR AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03

15Registrar uma lista de peças

utilizadas num serviçoAR

AS

SM

10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03

Status: SM ficou doente (previsão de retorno: 01/03

16Calcular o custo total das peças

usadas num serviçoHM

AS

SM10/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

18Receber um pagamento por um

serviçoHM AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03

19Registrar a opção de pagamento

preferida por um clienteAR VS Status: Não mais necessária (será feita diretamente no cadastro do cliente)

NNEE

PendentesBacklog

Fulano

Beltrana

Sicrano

Zé

J.J.

Iniciadas Inspeção/Teste Finalizadas

NN NN II

NN

NN NNEE NN II

NN NNNN NN

NN NN NN

NN NN II

EE

NN

NN

NN

NN NN

NN NN II

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 alteradapor outra tarefa

Mês/Ano

Porcentagem Completada:

Prazo de Entrega:

Completada

Mês e Ano para entrega

Status da Atividade:

MA

Barra de Progresso

Em andamento

Requer atenção (ex.: impedimento)

Completada

Nome da

Atividade

de Negócio

(nº features)

75%

Ainda não iniciada

Iniciais PC

Legenda: Em andamento Atenção Completada Barra de Progresso Não iniciada

Gerenciamento de Vendas de Produtos (VP) – 34%

Entrada dePedidos

(33)

Fev 2006

PC-1

Controle deContratos

(13)

Abr 2006

Venda deProdutos

(22)

Nov 2005

PC-1

Envio deProdutos

(19)

Mar 2006

PC-1

10%

Entrega deProdutos

(10)

Abr 2006

PC-3

30%

Relatórios deVendas

(14)

Dez 2005

75%99% 3%

Ger. Contas de Clientes (CC) – 90%

Análise dePropostas de

Contas(23)

Nov 2005

95%

Registro deTransaçõesdas Contas

(30)

Dez 2005

82%

Aberturade NovasContas

(11)

Nov 2005

100%

Gerenciamento de Estoque (GE) – 94%

Definição deUnidades de

Estoque(26)

Nov 2005

100%

Movimentaçãode Mercadorias

(19)

Jan 2006

82%

PC-3

Aceite deRequisições

de Movimento(18)

Dez 2005

97%

PC-3

PC-2 PC-1

PC-2 PC-2 PC-2 PC-3

SistemaComercial

(238)

Abr 2006

65%

Diagrama de Fluxo Acumulado

Legenda:

Não iniciada

Em andamento

Completada

Tempo (semanas)

Fe

atu

res

Prazo de Entrega

(Lead Time)

Estoque Intermediário

(Work in Progress)

Fecham

ento

Execução, Monitoramento & Controle

Planejamento e Lançamento

Escopo

Definir o

escopo da

solução

Modelar

a solução

Construir a

Lista de

Features

Montar os

Conjuntos

de Features

Desenvolver

o Plano de

Features

Detalhar um

Conjunto de

Features

Construir um

Conjunto de

Features

Teste de

Integração

Implantar?Detalhar um

Conjunto de

Features

Construir um

Conjunto de

Features

Teste de

Integração

Implantar?

UP

• Rigorosidade

• Controle

• Equipes grandes

XP / SCRUM

• Agilidade

• Liberdade

• Equipes pequenas

Quero apenas oProcesso Suficiente

Escalável para Equipes Pequenas, Médias e Grandes

8. Incremento de Produto(pode ser liberado para uso)

6. Dia

5. Iteração

(2 a 4 sem.)4. Tarefas

detalhadas

pela equipe

1. Visão(RSI, marcos,

versões)

2. Lista de Espera (Backlog) de funcionalidades

do produto, priorizada pelo Dono do Produto

3. Escopo da Corrida

(Sprint)

7. Reuniões

Diárias (em pé)

Concepção e Planejamento

1

DMA

3

PPF

2

CLF

Construção

4

DPF

5

CPF

9. Inspeção e

Adaptação

FDD XP

Certo planejamento inicialPlanejamento 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

Iniciação Elaboração Construção Transição

Processo UnificadoProcesso Unificado

FDDDMA CLF PPF

DPF CPF

XP

OID: Inovação e Implantação Organizacional

CAR: 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 Projeto

OPP: Performance do Processo Organizacional

RD: Desenvolvimento de Requisitos

TS: Solução Técnica

PI: Integração de Produtos

VER: Verificação

VAL: Validação

OPF: Foco no Processo Organizacional

OPD: Definição do Processo Organizacional

OT: Treinamento Organizacional

IPM: Gerência Integrada de Projeto

RSKM: Gerência de Riscos

DAR: Análise e Tomada de Decisão

REQM: Gerência de Requisitos

PP: Planejamento de Projeto

PMC: Monitoramento e Controle de Projeto

SAM: Gerência de Acordos com Fornecedores

MA: Medição e Análise

PPQA: Garantia da Qualidade do Processo e do Produto

CM: Gerência de Configuração

1 Inicial

Áreas de ProcessosNível Foco Produtividade

Qualidade

Risco

Retrabalho

FD

D

A FDD é um meta-processo, que pode ser adaptado e aplicado a diversos níveis e necessidades de desenvolvimento

Podemos usá-la para desenvolver aspectos diferentes do produto: Infra-estrutura (frameworks, persistência, bibliotecas,

componentes, ...) Interface com o usuário Integração com outros sistemas

O segredo é definir, para cada aspecto, quem é o cliente e derivar as features a partir desta perspectiva

Podemos também aplicar a FDD emdiferentes níveis do problema ou daorganização Processos de Negócio Planejamento Estratégico e Tático dos Sistemas Entendimento dos relacionamentos entre produtores e

consumidores de informação A analogia com um fractal é devida à reaplicação da

FDD em determinada etapa de outra aplicação da FDD

Nos Estados Unidos, Mac Felsing está aplicando esse conceito, com o nome de “Enterprise FDD”, para conseguir escalabilidade e uniformidade de comunicação

A Gestão de Projetos pela Corrente Crítica (CCPM -Critical Chain Project Management) é a aplicação da Teoria das Restrições (TOC – Theory of Constraints) à gestão de projetos

23-24/01/2009 173

CF A

10d

CF B

15d

CF C

13d

Pulmão

11d

CF D

25d

CF E

32d

CF F

17d

CF G

8d

CF H

23d

CF I

19d

Pulm.

16d

Integr.

10d

Testes

20d

Pulmão Projeto

30d

Pulm.

10d

Conc.

10d

Concepção e Planejamento

Desenvolver

um Modelo

Abrangente

Planejar

por

Feature

Construir

a Lista de

Features

Construção

Detalhar

por

Feature

Construir

por

Feature

É conhecida por diminuir drasticamente a duração dos projetos (em 30% a 50%, em média), com maior qualidade e com o escopo contratado

A CCPM oferece técnicas para ajudar no planejamento e na execução do projeto

23-24/01/2009

É 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

174

23-24/01/2009 175

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

Status da Atividade:

Em andamentoRequer atençãoCompletadaNão iniciada

Nome da Atividade

de Negócio

(nº de features)

75%

Mês/Ano

0

20

40

60

80

100

120

140

160

180

200

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Features

Iniciadas

Concluídas

Autorização para Entrada fora do Horário do Expediente

Como funciona hoje:1. Servidor preenche Requerimento2. Chefia imediata autoriza3. Chefia Superior (Secretário, Assessor, Diretor,

...) Autoriza4. Encaminha requerimento a Seção de

Segurança5. Encaminha Requerimentos Autorizados a

guarita

1. Servidor preenche requerimento em uma página da Intranet, acessada através de senha

2. Chefia imediata recebe e-mail com a solicitação e ali mesmo clica em “link” para acessar o sistema, que pode autorizar ou não

3. Sendo autorizada, é enviada e-mail para Chefia Superior, que também pode autorizar ou não

4. Chefe da Segurança recebe e-mail informando da autorização

5. O sistema gera uma página automaticamente a cada dia com os requerimentos autorizados

Autenticar usuário no sistema Preencher o requerimento de autorização Enviar e-mail a Chefia Imediata Autorizar/Recusar o requerimento pela Chefia

Imediata Enviar e-mail a Chefia Superior Autorizar/Recusar o requerimento pela Chefia

Superior Enviar e-mail ao Chefe da Segurança Gerar listagem de requerimentos autorizados

1ª Entrega

• Autenticar usuário no sistema

• Preencher o requerimento de autorização

2ª Entrega

• Autorizar/Recusar o requerimento pela Chefia Imediata

• Autorizar/Recusar o requerimento pela Chefia Superior

• Gerar listagem de requerimentos autorizados

3ª Entrega

• Enviar e-mail a Chefia Imediata

• Enviar e-mail a Chefia Superior

• Enviar e-mail ao Chefe da Segurança

• Gerência de Requisitos

• Planejamento de Projeto

• Monitoramento e Controle de Projeto

• Gerência de Acordos Com Fornecedores –Gerência de Subcontratação

• Medição e Análise

• Garantia da Qualidade do Processo e do Produto

• Gerência de Configuração

Nível 2 –Gerenciado

Foco: Gerência Básica de Projetos

• Desenvolvimento de Requisitos

• Solução Técnica

• Integração do Produto

• Verificação

• Validação

• Foco no Processo Organizacional

• Definição do Processo Organizacional

• Treinamento Organizacional

• Gerenciamento de Risco

• Análise e Tomada de Decisão

• Ambiente Organizacional para Integração

Nível 3 –Definido

Foco: Padronização do

Processo

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

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

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

Principal divulgador da FDD no Brasil

Adail Muniz Retamal Heptaman

www.heptagon.com.br

Jorge Luis Bublitz

Formado em Administração de Empresas MBA em Planejamento Estratégico Pós-Graduação em Engenharia de Sistemas

Chefe da Seção de Análise e Desenvolvimento (TRE-MT) Certificação Delphi e JBuilder Artigos publicados nas revistas Micro Sistemas (!?) e Clube Delphi

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

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

Valeu !!!!!

Jorge FDDMan

Email e MSN:bublitz@hotmail.com

Páginas:http://bublitz.tripod.com

http://jorge-fdd.blogspot.com