Aula FDD C.E.S.A.R.
Upcoming SlideShare
Loading in...5
×
 

Aula FDD C.E.S.A.R.

on

  • 1,126 views

Slides da aula de FDD para o curso de Pós-Graduação em Gestão Ágil de Projetos no CESAR.Edu de Recife/PE.

Slides da aula de FDD para o curso de Pós-Graduação em Gestão Ágil de Projetos no CESAR.Edu de Recife/PE.

Statistics

Views

Total Views
1,126
Views on SlideShare
1,126
Embed Views
0

Actions

Likes
0
Downloads
20
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Aula FDD C.E.S.A.R. Aula FDD C.E.S.A.R. Presentation Transcript

  • 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 umsistema 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
  •  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 umestado 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
  • Projetos de Software Falharam Completados 23% com Alterações 49% Concluídos com Sucesso 28%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 of Microsoft Management David Thielen
  • “Nenhum floco de neve em uma avalanche se senteresponsável por ela” Stanislaw Lec escritor 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, ...
  • QualidadeEscopo Prazo Custo
  •  É 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 Highsmith Agile Software Development Ecosystems 2002
  •  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
  • Satisfação do Cliente Responder Simplicidade às Mudanças Princípios RitmoConstante Ágeis Entrega frequente Software que Motivação Funciona
  • 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 Á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 exceção  Replanejar deve ser a regra sempre (há limites práticos) Controle rígido do escopo do  Controle do escopo das projeto iterações Teorias básicas:  Teorias básicas:  Gerenciamento Total da  Teoria do Caos Qualidade  Teoria das Restrições (TOC)  Controle Estatístico de  Produção Enxuta (Lean) Processos
  • “Um plano não é nada... Mas planejar é tudo!” Dwight D. Eisenhower 34º 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 CoadStephen Palmer John Mac Felsing
  • Sede do United Overseas Bank David Anderson, o GUI-Man Peter Coad e a Paul Szego e Jeff De Luca e osEquipe de Modelagem Stephen Palmer Programadores
  •  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 PROCESSAMENTO 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 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
  • A O R 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.)
  • 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 Área 2 Atividade 2.1 Feature 2.1.1 ClasseC Feature 2.1.2 Atividade 2.2 Feature 2.2.1
  • Objeto1 Objeto2 Objeto3 Objeto4 TelaA ClasseB ClasseC ClasseDUsuá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
  •  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
  •  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 O B A  Ganha o grupo que fizer mais pontos
  •  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% 60%  1 hora de inspeção pode evitar 60% 50% 55% de 5 a 30 horas de correções 40% 45% Teste Unitário Benefícios secundários 30% Teste Funcional 35% Teste de Integração  Transferência de conhecimento Inspeção de Design 20% 24% Inspeção de Código  Conformidade com padrões 10% 0% Técnica Jones, C.L. “A Process-Integrated Approach to Defect Prevention”, IBM Systems Journal, 1985
  • Prof. Guilherme Horta, COPPE/UFRJ, 2004
  • Artefato 1 Form. Planejamento PlanejamentoOrganizador Form. 2 Relato de Inspetor Detecção Defeitos Form. Ad-Hoc 3 Moderador Relato de Técnicas de Leitura Inspetor Coleção Defeitos Checklists Autor Form. Relato de 4 Defeitos Autor Correção Artefato Prof. Guilherme Horta, COPPE/UFRJ, 2004 Corrigido
  •  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
  •  Disciplina que suporta e controla as evoluções e modificações em artefatos-chave dentro do ciclo de Principais desenvolvimento de um software Artefatos de Desenvolvimento Desenvolvimento do Produto Objetivos  Facilitar o desenvolvimento de software  Garantir a integridade dos produtos Gerenciamento  Controlar efetivamente as modificações 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
  •  Versionamento  Gerenciamento de Processo  Check out/check in  Definição de Workflow  Histórico de revisões  Critérios de Entrada/Saída  Branching & Merging  Notificações  Visões de Projeto  Garantia de Segurança Gestão de Mudanças  Gerenciamento de Montagem  Acompanhamento de defeitos  Identificação de Dependências  Listas de Melhoria  Controle de Montagens  Associações  Gerenciamento de Liberação  Rastreabilidade  Rótulos Gestão de Tarefas  Estados Promocionais  Criação e Acompanhamento  Implantação  Ficha de tempo
  •  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% PC-2 PC-2 PC-2 Análise de Abertura Registro de Propostas de de Novas Transações Contas Contas das Contas (23) (11) (30) 95% 100% 82% Nov 2005 Nov 2005 Dez 2005
  •  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ários23-24/01/2009 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:
  • Requisitos Concepção e Planejamento Desenvolver Construir PlanejarMais forma que conteúdo um Modelo a Lista de por Abrangente Features Feature Plano de Desenvolvimento Modelo de Objetos Construção Detalhar Construir Progresso Mais conteúdo na forma por por Feature Feature Produto Pacotes de Trabalho
  •  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
  • Discussões Iniciais Sobre Requisitos Obter Patrocínio da Gerência Escolha da Linguagem de Programação Planejamento Geral Feature-Driven Development Desenvolver um Modelo Abrangente Escolha da Plataforma TecnológicaPreparaçã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
  • Gestão Ágil de Projetos Engenharia de Requisitos Concepção e PlanejamentoDesenvolvimento de Requisitos Decomposição Análise OO Planejamento Funcional Gerência de Requisitos Construção Gerência de Configuração Programação Projeto OO e Teste OO
  •  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 Condição CondiçãoNecessá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
  • Gerenciamento & Governança de TI IIT Management & Governance Demanda Estratégica & Operacional Operações de TI (Produção) Operações de TI (Produção)Necessidades de Negócio Engenharia de ANÁLISE Requisitos Priorização | Verificação | Riscos | Estimação DESCOBERTA ESPECIFICAÇÃO VALIDAÇÃO Técnicas | Glossário | Detalhar Requisitos | Protótipo | Revisão | Assinatura | Fronteiras do Sistema | Modelo de Cenários de Negócio | Baseline Stakeholders Modelo de Casos de Uso GERENCIAMENTO Armazenamento | Medição & Auditoria | Ligação & Rastreamento | Relatórios | Segurança
  • 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 deKarl Wiegers, “Software Requirements” Requisitos de Software
  • 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 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
  •  É 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: DMA CLF PPF  Diagramas de classes, sequência, atividades, estados, casos de uso  Lista preliminar de requisitos DPF CPF  Anotações nos modelos
  • Formar a Equipe Conduzir um Estudo de Modelagem Dirigido Sobre o (Gerente do Projeto) Domínio de Negócio (Ger. Projeto, Especialistas) opcional Desenvolver Modelos Estudar Documentos em Pequenos Grupos(Equipe de Modelagem) (Equipe de Modelagem em pequenos grupos) Desenvolver um Refinar o Modelo de Modelo como Equipe Objetos Completo(Equipe de Modelagem) (Arquiteto Líder, Equipe de Modelagem) Escrever Comentários Sobre o Modelo (Arquiteto Líder, Programador Líder)
  • 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, 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
  •  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 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
  •  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
  • Hotel Funcionario PessoaFisica Nome * DtAdmissao Nome Endereco CTPS CPF Estrelas *TipoQuarto Quarto Estadia HospedeDescricao * ID DHInicio Score *NumSolt Status DHTermino DtUltVisitaNumCasal ValorTotalFumante? * Servico Data Hora Valor
  • Hotel Funcionario PessoaFisica Nome * DtAdmissao Nome Endereco CTPS CPF Estrelas *TipoQuarto Quarto Estadia HospedeDescricao * ID DHInicio Score *NumSolt Status DHTermino DtUltVisitaNumCasal ValorTotalFumante? * Servico Data Hora Valor
  •  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: DMA CLF PPF  Lista de Features  Requisitos mais detalhados 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 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> <VerboInfinitivo> ...
  • Área n Atividade X Feature 1 Classe A Feature 2 Atividade Y Feature 3 Feature 4 Feature 5 Classe B... Classe C
  •  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 DMA CLF PPF  Pacotes de trabalho  Lista de classes com seus donos DPF CPF
  • 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 DesenvolvedoresProgramadores Líderes (Equipe de Planejamento)(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 Complexidade Esforço Classes na Feature da Feature (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 Pacote 2 Pacote 3 Pacote 4 (10) (8) (13) (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 as datas previstas para cada iteração
  •  Agora na fase de construção propriamente dita, deve-se refinar o projeto (design) para cada feature ou conjunto de features relacionadas A equipe de features será formada pelos proprietários das classes envolvidas O resultado será um pacote de trabalho, sob a responsabilidade de um programador líder Artefatos produzidos:  Modelos detalhados (classes e seqüência)  Esqueletos de classes com métodos  Pacote de trabalho detalhado DMA CLF PPF  Relatório de inspeção do design  Relatório de progresso atualizado DPF CPF
  • 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 opcionalEstudar Documentos Desenvolver os de Referência Diagramas de Sequência(Equipe de Features) (Equipe de Features) Refinar 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)
  •  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 DMA CLF PPF  Lista de alterações feitas/necessárias  Relatório de progresso atualizado DPF CPF
  • Implementar Classes Testes Unitários e Métodos (Equipe de Features) (Equipe de Features)Conduzir uma Inspeção Promover para o Build no Código (Programador Líder, (Equipe de Features) 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
  • DMA CLF PPF DPF CPF Nº 4: Detalhar por Feature Nº 5: Construir por Feature Estudo Dirigido Desenho Inspeção do Codificação Inspeção do Promoção Sobre o Domínio (Projeto) Desenho Código ao Build 1% 40% 3% 45% 10% 1% 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
  • Est. Dirig. Design Insp. Design Codif. Insp. Cod. BuildId Descrição P.C. D.C. Plan. Real. Plan. Real. Plan. Real. Plan. Real. Plan. Real. Plan. Real.12 Agendar um serviço para um carro HM AS 10/02 10/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03 Incluir um novo cliente na lista de13 HM VS 01/02 01/02 04/02 04/02 05/02 05/02 07/02 07/02 08/02 08/02 09/02 09/02 clientes Registrar um serviço realizado num14 AR AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03 carro Registrar uma lista de peças AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/0315 AR utilizadas num serviço SM Status: SM ficou doente (previsão de retorno: 01/03 Calcular o custo total das peças AS16 HM 10/02 10/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03 usadas num serviço SM17 Enviar uma fatura para um cliente AR VS 08/03 10/03 13/03 17/03 19/03 20/03 Receber um pagamento por um18 HM AS 10/02 11/02 15/02 16/02 16/02 17/02 28/02 02/03 06/03 serviço Registrar a opção de pagamento19 AR VS Status: Não mais necessária (será feita diretamente no cadastro do cliente) preferida por um cliente Legenda: Atividade em andamento Requer atenção Completada Não iniciada
  • Backlog Pendentes Iniciadas Inspeção/Teste FinalizadasFulano E N N N I N NBeltrana N N N I NSicrano N N N E N I N N E N Zé N N N N J.J. N N I N
  • ID: RN12 VN: A Est.: 4 Resp.: SicDescrição: Fórmula de cálculo do imposto: I = ValorBruto * Aliquota Aliquota -> parâmetro AI3 Cartão de impedimento (rosa) Classe -> Venda Tela -> pgVenda ID: RN12 Resp.: SicInício: 18/06 09:15 Fim: Motivo: Classe Venda está sendo alterada Cartão de tarefa normal (azul) por outra tarefa ou emergência (amarelo) Início: 18/06 11:30 Estimativa de retorno: 19/06 9:00
  • Iniciais PCStatus da Atividade: Em andamento Nome da Requer atenção (ex.: impedimento) Atividade de Negócio Completada (nº features) Ainda não iniciadaPorcentagem Completada: 75% Barra de ProgressoPrazo de Entrega: Mês/Ano Completada MA Mês e Ano para entrega
  • Gerenciamento de Vendas de Produtos (VP) – 34% PC-1 PC-1 PC-3 PC-1 PC-2 PC-1 Venda de Envio de Entrega de Entrada de Controle de Relatórios de Produtos Produtos Produtos Pedidos Contratos Vendas (22) (19) (10) (33) (13) (14) 99% 10% 30% 3% 75% SistemaComercial Nov 2005 Mar 2006 Abr 2006 Fev 2006 Abr 2006 Dez 2005 (238) 65% Ger. Contas de Clientes (CC) – 90% Gerenciamento de Estoque (GE) – 94%Abr 2006 PC-2 PC-2 PC-2 PC-3 PC-3 PC-3 Análise de Abertura Registro de Definição de Aceite de Movimentação Propostas de de Novas Transações Unidades de Requisições de Mercadorias Contas Contas das Contas Estoque de Movimento (23) (11) (30) (26) (18) (19) 95% 100% 82% 100% 97% 82% Nov 2005 Nov 2005 Dez 2005 Nov 2005 Dez 2005 Jan 2006 Legenda: Em andamento Atenção Completada Barra de Progresso Não iniciada
  • Diagrama de Fluxo Acumulado Legenda: Features Não iniciada Em andamento Estoque Intermediário Completada (Work in Progress)Prazo de Entrega Tempo (semanas) (Lead Time)
  • Escopo Execução, Monitoramento & Controle Definir oescopo da Detalhar um solução Conjunto de Features Modelar Construir um a solução Conjunto de Features Construir a Teste de Lista de Integração Features Implantar? Montar os Detalhar um Conjuntos Conjunto de Features Fechamento de Features Desenvolver Construir um o Plano de Conjunto de Features Features Teste de Planejamento e Lançamento Integração Implantar?
  • UP XP / SCRUM• Rigorosidade Quero apenas Agilidade • o Processo Suficiente• Controle • Liberdade• Equipes grandes Escalável para Equipes Pequenas,pequenas • Equipes Médias e Grandes
  • Construção 7. Reuniões 6. Dia 4 5 Diárias (em pé) DPF CPF 5. Iteração 4. Tarefas (2 a 4 sem.) 3. Escopo da Corrida detalhadas 8. Incremento de Produto pela equipe (pode ser liberado para uso) (Sprint) 1. Visão 2. Lista de Espera (Backlog) de funcionalidades(RSI, marcos, do produto, priorizada pelo Dono do Produto versões) Concepção e Planejamento 9. Inspeção e Adaptação 1 2 3 DMA CLF PPF
  • FDD XP Planejamento durante o Certo planejamento inicial desenvolvimento Refactoring é exceção Refactoring é a norma Programadores Líderes e Posse coletiva do código Proprietários de Classes Design formal e Programação em paresInspeções de código e modelo
  • Processo UnificadoIniciação Elaboração Construção Transição FDDDMA CLF PPF DPF CPF XP
  • Nível Foco Áreas de Processos Produtividade Qualidade Melhoria 5 Em OID: Inovação e Implantação Organizacional Contínua do Otimização CAR: Análise e Prevenção de Defeitos Processo 4 Gerenciado Gerência QPM: Gerenciamento Quantitativo de Projeto Quantitativam. Quantitativa OPP: Performance do Processo Organizacional RD: Desenvolvimento de Requisitos TS: Solução Técnica PI: Integração de Produtos VER: Verificação VAL: ValidaçãoFDD Padronização 3 Definido OPF: Foco no Processo Organizacional do Processo 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 Gerência PMC: Monitoramento e Controle de Projeto 2 Gerenciado Básica de SAM: Gerência de Acordos com Fornecedores Projetos MA: Medição e Análise PPQA: Garantia da Qualidade do Processo e do Produto CM: Gerência de Configuração Risco 1 Inicial Retrabalho
  •  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 em diferentes níveis do problema ou da organizaçã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
  • Concepção e Planejamento  A Gestão de Projetos pela Corrente Crítica (CCPM - Desenvolver Construir Planejar Critical Chain Project Management) é a aplicação da um Modelo a Lista de por Abrangente Features Feature Teoria das Restrições (TOC – Theory of Constraints) à gestão de projetos CF A CF B CF C Pulmão 10d 15d 13d 11d Conc. Pulm. CF D CF E CF F Integr. Testes Pulmão Projeto 10d 10d 25d 32d 17d 10d 20d 30d CF G CF H CF I Pulm. 8d 23d 19d 16d É conhecida por diminuir drasticamente a Construção duração dos projetos (em 30% a 50%, em média), com maior qualidade e com o escopo contratado Detalhar Construir por por A CCPM oferece técnicas para ajudar no Feature Feature planejamento e na execução do projeto 23-24/01/2009 173
  •  É 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 desenvolvedores23-24/01/2009 174
  •  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 necessidades23-24/01/2009 175
  • Status da Atividade: Nome da Atividade de NegócioEm andamento (nº de features)Requer atençãoCompletada 75%Não iniciada Mês/Ano
  • 200180160140120 Features100 Iniciadas80 Concluídas6040 20 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
  •  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 senha2. Chefia imediata recebe e-mail com a solicitação e ali mesmo clica em “link” para acessar o sistema, que pode autorizar ou não3. Sendo autorizada, é enviada e-mail para Chefia Superior, que também pode autorizar ou não4. Chefe da Segurança recebe e-mail informando da autorização5. 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 2ª Entrega 3ª Entrega• Autenticar usuário • Autorizar/Recusar o • Enviar e-mail a no sistema requerimento pela Chefia Imediata• Preencher o Chefia Imediata • Enviar e-mail a requerimento de • Autorizar/Recusar o Chefia Superior autorização requerimento pela • Enviar e-mail ao Chefia Superior Chefe da • Gerar listagem de Segurança requerimentos autorizados
  • • Gerência de Requisitos • Planejamento de Projeto Nível 2 – • Monitoramento e Controle de ProjetoGerenciado • Gerência de Acordos Com Fornecedores – Gerência de SubcontrataçãoFoco: Gerência • Medição e Análise Básica de • Garantia da Qualidade do Processo e do Projetos Produto • Gerência de Configuração
  • • Desenvolvimento de Requisitos • Solução Técnica Nível 3 – • Integração do Produto • Verificação Definido • Validação • Foco no Processo Organizacional Foco: • Definição do Processo OrganizacionalPadronização do • Treinamento Organizacional Processo • Gerenciamento de Risco • Análise e Tomada de Decisão • Ambiente Organizacional para Integração
  •  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 Heptamanwww.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.comhttp://jorge-fdd.blogspot.com