Pmi Global 2008 Portfolio

1.572 visualizações

Publicada em

Apresentação sobre elementos característicos entre projetos para uma adequada gestão de portfólios.

Publicada em: Negócios
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.572
No SlideShare
0
A partir de incorporações
0
Número de incorporações
44
Ações
Compartilhamentos
0
Downloads
178
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Pmi Global 2008 Portfolio

  1. 1. Project Management Tools for Modern Project and Portfolio Management Vladimir Liberzon, PMP Peter Souza Mello, PMP Victoria Shavyrina, PMP (Spider Project Team) Session n# PMT01 Ferramentas de Gerenciamento de Projeto para uma Gestão Moderna de Projetos e Portfólios
  2. 2. Introdução <ul><li>Nesta apresentação iremos discutir o uso de técnicas e ferramentas que são utilizadas em gerenciamento corporativo de projetos ao redor do mundo. </li></ul><ul><li>Questões durante a apresentação são bem vindas! </li></ul>
  3. 3.
  4. 4.
  5. 5.
  6. 6.
  7. 7.
  8. 8.
  9. 9.
  10. 10.
  11. 11.
  12. 12.
  13. 13. Cálculo de Desperdício: recurso ativo x ocioso R$ 154.560 28 dias
  14. 14. Otimização de Cronograma = Redução do Desperdício R$ 138.000 25 dias
  15. 15. Economia de 11% ao tratar dados de custo adequadamente
  16. 16.
  17. 17. Múltiplas EAPs (WBS) <ul><li>Atividades sem atribuição de pacotes: </li></ul>
  18. 18. Múltiplas EAPs (WBS) <ul><li>Atividades com EAP por “entregáveis” </li></ul>
  19. 19. Múltiplas EAPs (WBS) <ul><li>Atividades com EAP por “responsabilidade” </li></ul>
  20. 20.
  21. 21.
  22. 22.
  23. 23. P a s s o s <ul><li>Identificação, seqüenciamento e estimativas sem restrições de recursos (PERT/CPM) </li></ul><ul><li>Detalhamento baseado em restrições de recursos (nivelamento por recursos // corrente crítica) </li></ul><ul><li>Identificação do caminho crítico real (task-critical-path / resource-critical-path) e folgas adequadas para atividades de projetos. </li></ul>
  24. 24. P a s s o s <ul><li>Identificação de requisitos financeiros, materiais e equipamentos para qualquer período de tempo </li></ul><ul><li>Identificação de recursos renováveis e seus tempos de aplicação </li></ul><ul><li>Análise de riscos e desenvolvimento de cronograma compatível com a parametrização dos riscos </li></ul>
  25. 25. P a s s o s <ul><li>Criação de mecanismos de medida de performance </li></ul><ul><li>“ Forecasting” de análise de performance para os parâmetros principais </li></ul><ul><li>Registro de alternativas de projeto (aceitar e respeitar o acaso) </li></ul>
  26. 26. CPM x CRR <ul><li>O método do Caminho Crítico é idêntico em todos os pacotes de gerenciamento de software e todos devem propiciar os mesmos resultados se garantidos a mesma data de início, durações e calendários (CPM) </li></ul><ul><li>Cronogramas por Restrição de Recursos (CRR) possuem diferentes mecanismos e aquele pacote que oferece o melhor resultado na otimização de um cronograma pode representar ganhos e economias aos seus usuários. </li></ul>
  27. 27. Cronogramas por Restrição de Recursos (CRR) <ul><li>O pacote Spider Project Professional explora alternativas matemáticas com restrições de materiais, recursos e finanças para cumprir diferentes objetivos de projeto: redução de custo, garantia de prazo, utilização de recursos compartilhados, estabilidade de datas e reservas, entre outros. </li></ul>
  28. 28. Cronograma sem restrições <ul><li>Para uma correta aplicação de CPM sem o detalhamento de recursos é necessário que se tenha recursos ilimitados. </li></ul><ul><li>Exemplo: O recurso R1 realiza atividades em paralelo (atividades 2 e 5) </li></ul>
  29. 29. Cronograma com restrições <ul><li>Com este mesmo cronograma baseado em restrições, a atividade 3 deixa de ser crítica e a atividade 5 passa a pertencer ao caminho crítico, denominado Caminho Crítico do Recurso ou “corrente crítica”. </li></ul>
  30. 30. CRR e Corrente Crítica <ul><li>Embora muito similar, Cronogramas por Restrição de Recursos diferem da tradicional “Corrente Crítica” por que também considera fluxo financeiro e produção de recursos renováveis e não renováveis como fatores determinante do seu resultado. </li></ul><ul><li>CRR são usados na Rússia desde os tempos da guerra fria e só se tornaram públicos na década de 90. </li></ul>
  31. 31.
  32. 32. Critérios de Sucesso em Projetos <ul><li>Tradicionalmente se estabelece com meta de projeto a sua entrega no prazo e abaixo do orçamento. </li></ul><ul><li>Projetos orientados ao negócio podem desenvolver o “foco no lucro” e não o “foco no custo” </li></ul>
  33. 33. Critérios de Sucesso em Projetos <ul><li>Trump Tower em Chicago é uma demonstração de “foco no lucro”: </li></ul><ul><ul><li>Projeto + LONGO </li></ul></ul><ul><ul><li>Projeto + CARO </li></ul></ul><ul><ul><li>Projeto + LUCRATIVO* </li></ul></ul><ul><li>* A opção é ter negócios já funcionando durante sua construção. </li></ul>http://en.wikipedia.org/wiki/Trump_International_Hotel_and_Tower_(Chicago)
  34. 34. Critérios de Sucesso em Projetos <ul><li>A análise e otimização de um cronograma em um projeto assim leva em conta os mecanismos de financiamento e também as previsões de faturamento com entregas parciais. </li></ul>http://en.wikipedia.org/wiki/Trump_International_Hotel_and_Tower_(Chicago)
  35. 35. Critérios de Sucesso em Projetos <ul><li>O caixa deste projeto é insuficiente para aproveitar os recursos disponíveis. </li></ul>
  36. 36. Critérios de Sucesso em Projetos <ul><li>A falta de dinheiro em caixa pode obrigar atrasar o projeto. </li></ul><ul><li>O lucro esperado é de USD 219.077,00 </li></ul>
  37. 37. Critérios de Sucesso em Projetos <ul><li>Um empréstimo pode garantir o cumprimento da meta inicial. </li></ul><ul><li>Sem caixa, o projeto atrasa até ter novas receitas. </li></ul>
  38. 38. Critérios de Sucesso em Projetos <ul><li>O desempenho cai de: USD 219.077,00 para USD 193.724,96 </li></ul>
  39. 39. Critérios de Sucesso em Projetos Realizar um empréstimo ou desperdiçar USD 25.000,00 ? A decisão apropriada pode pagar por todo o esforço de planejar, em especial quando consideramos o Gerenciamento de Portfólios.
  40. 40. <ul><li>Análise de Risco e Gerenciamento de Projetos por Probabilidade de Sucessos (SDPM) </li></ul>
  41. 41. Por que análise de riscos ? <ul><li>Nossa experiência em projetos demonstra que projetos baseados em cronogramas determinísticos tem baixa probabilidade de sucesso. </li></ul><ul><li>A modelagem computacional de cronogramas com a análise de riscos pode ampliar a probabilidade de sucesso. </li></ul>
  42. 42. Simulação de Riscos <ul><li>A simulação de riscos pode ser baseada em simulações de Monte Carlo ou usar três estimativas, como veremos a seguir. </li></ul>
  43. 43. Simulação de Riscos Estimativas em 3 pontos <ul><li>Dados de projeto (duração, volumes, custos, etc) são coletados com o uso de três estimativas: - otimista, pessimista e mais provável. </li></ul><ul><li>Eventos de risco são selecionados com base a “rankings” utilizados em análise qualitativa de riscos. </li></ul>
  44. 44. Simulação de Riscos Estimativas em 3 pontos <ul><li>Cenário Otimista: </li></ul><ul><ul><li>Contém eventos cuja probabilidade excede 90% </li></ul></ul><ul><li>Cenário Mais Provável: </li></ul><ul><ul><li>Contém eventos cuja probabilidade excede 50% </li></ul></ul><ul><li>Cenário Pessimista: </li></ul><ul><ul><li>Contém eventos selecionados </li></ul></ul>
  45. 45. Simulação de Riscos Estimativas em 3 pontos <ul><li>Cada cenário pode conter atividades e custos adicionais, além de empregar diferentes recursos e calendários. </li></ul><ul><li>O planejador tem como resultado três diferentes cronogramas, com custos, materiais e datas para os principais marcos de projeto. </li></ul>
  46. 46. Parâmetros desejados <ul><li>A definição das probabilidades de se alcançar diferentes resultados permite se fixar custos e datas finais desejados (metas de projeto) </li></ul>06/08 07/08 08/08 10/08 03/09 06/09 06/08 07/08 08/08 10/08 03/09 06/09
  47. 47. Probabilidade de Sucesso <ul><li>Para a meta negociada (cliente/patrocinador/equipe) temos uma probabilidade de ocorrência, que denominamos “ probabilidade de sucesso ”. </li></ul>06/08 07/08 08/08 10/08 03/09 06/09 06/08 07/08 08/08 10/08 03/09 06/09
  48. 48. Buffers/Reservas <ul><li>A diferença entre o cronograma entregue para a equipe (otimista ou provável) e a data fixada como meta estabelece o buffer do projeto . </li></ul>06/08 07/08 08/08 10/08 03/09 06/09 06/08 07/08 08/08 10/08 03/09 06/09
  49. 49. Cronograma Crítico (exemplo) <ul><li>Existem reservas de custos, materiais e tempo que são calculados não somente para o projeto como um todo, mas também temos o registro de reservas comparados ao cronograma de trabalho. </li></ul>
  50. 50. Tendências de Probabilidade de Sucesso <ul><li>A melhor forma de medir a performance de um projeto é estimar o que está acontecendo com a probabilidade de sucesso. </li></ul><ul><li>Se ela aumenta, isso significa que as reservas estão sendo gastas abaixo do planejado. </li></ul><ul><li>Se ela diminui indica que a performance não é adequada. </li></ul>
  51. 51. Tendências de Probabilidade de Sucesso
  52. 52. Tendências de Probabilidade de Sucesso <ul><li>Tendências de Probabilidade de Sucesso não refletem apenas performance de projeto (como é o caso de valor agregado) mas também por diversos elementos ao redor do projeto. </li></ul>
  53. 53. Tendências de Probabilidade de Sucesso <ul><li>Consideramos – assim – que a tendência de probabilidade de sucesso é a principal ferramenta integrada de análise de performance de projetos. </li></ul>
  54. 54. Tendências de Probabilidade de Sucesso <ul><li>Pode ser utilizada como único indicador de performance para a alta direção pois é suficiente para estimativas de performance e tomada de decisão. </li></ul>
  55. 55. Success Driven Project Management <ul><li>A aplicação do indicador de probabilidade de sucesso dá origem ao método russo S uccess D riven P roject M anagement . </li></ul>
  56. 56. Success Driven Project Management <ul><li>Informações complementares sobre SDPM podem ser encontradas em http://www.gestaoeprojetos.com </li></ul><ul><li>Destaque: 5 th Annual Conference of PMI College of Scheduling </li></ul><ul><li>– Apresentação dos princípios de SDPM por Russell Archibald (membro fundador do PMI) </li></ul><ul><li>– Detalhes por Vladimir Liberzon </li></ul>
  57. 57.
  58. 58. Ferramentas e Técnicas de GP Corporativas <ul><li>Devemos organizar dados de forma a apoiar a simulação de trabalho baseado em recursos em todo o Portfólio e com a aplicação de normas e padrões corporativos. </li></ul><ul><li>Modelos Computacionais eficientes são baseados em livros de referência e bibliotecas (fragnets), garantindo maior nível de detalhe no planejamento e execução. </li></ul>
  59. 59. Ferramentas e Técnicas de GP Corporativas <ul><li>Devemos calcular Cronogramas por Restrição de Recursos para cada projeto e o portfólio. </li></ul><ul><li>Devemos garantir a aplicação de simulações de risco em projetos. </li></ul><ul><li>Devemos selecionar critérios de sucesso que sejam compatíveis com os objetivos do negócio (pensamento no lucro e não no custo). </li></ul>
  60. 60. Ferramentas e Técnicas de GP Corporativas <ul><li>Não há projeto sem incerteza e portanto devemos definir metas de projeto com probabilidades razoáveis e um bom controle sobre reservas de contingência. </li></ul><ul><li>Projetos podem ser controlados mediante a análise da probabilidade corrente de sucesso em função das metas, de forma que se tome ações corretivas para probabilidades negativas. </li></ul>
  61. 61. Contact Information <ul><li>Name: Peter Berndt de Souza Mello, PMP </li></ul><ul><li>Email: [email_address] // [email_address] </li></ul><ul><li>Phone: +55 16 8163-3903 // 61 3244-2510 ** Ribeirão Preto ** Brasília ** </li></ul><ul><li>www.spiderproject.com.br </li></ul><ul><li>Session #: PMT01 </li></ul>
  62. 62. COMPLEMENTOS <ul><li>A versão a seguir inclui slides com explicações complementares relacionados aos mapas mentais utilizados no evento. </li></ul>
  63. 63. Project Management Tools for Modern Project and Portfolio Management Vladimir Liberzon, PMP Peter Souza Mello, PMP Victoria Shavyrina, PMP Spider Project Team Session n# PMT01
  64. 64.
  65. 65. Parte 1 <ul><li>Requisitos de Sistemas de Gerenciamento de Projetos Corporativos </li></ul>
  66. 66.
  67. 67. Requisitos de modelos computacionais para projetos e portfólios <ul><li>Deve ser baseado em padrões corporativos. (dicionários, bancos de dados e bibliotecas) </li></ul><ul><li>Deve calcular cronogramas baseados em restrições de recursos levando em consideração limitações relacionadas a recursos humanos, materiais, fluxos de caixa e dependências externas. </li></ul>
  68. 68. Requisitos de modelos computacionais para projetos e portfólios <ul><li>Deve considerar prioridades entre recursos, atividades, fases e projetos. </li></ul><ul><li>Deve simular gastos e faturamentos para permitir o gerenciamento adequado de fluxo de caixa entre projetos em um portfólio. </li></ul>
  69. 69.
  70. 70. Requisitos de modelos computacionais para projetos e portfólios <ul><li>Deve permitir o planejamento de uso de recursos com base a suas habilidades </li></ul><ul><li>Deve calcular a “corrente crítica” com base aos diversos tipos de recurso </li></ul><ul><li>Deve simular riscos e incertezas de projeto </li></ul>
  71. 71. Requisitos de modelos computacionais para projetos e portfólios <ul><li>Deve prover a alta gerencia com informações integradas que reflitam não apenas a situação atual, mas também tendências e performance do portfólio para a tomada de decisão. </li></ul><ul><li>Deve manter históricos de projeto/portfólio </li></ul>
  72. 72. Parte 2 <ul><li>Dados (informações) </li></ul>
  73. 73.
  74. 74. Organização de Dados <ul><li>Sistemas coporativos de gerenciamento de projetos tem requisitos vitais para uma implementação adequada </li></ul><ul><li>É necessário garantir que … </li></ul>
  75. 75. Requisitos de Dados <ul><li>Os custos de projetos tem uma estrutura consistente entre cada projeto (uso dos mesmos componentes de custo) </li></ul><ul><li>Contas de Custo devem ser a mesma em todos os projetos </li></ul>
  76. 76. Requisitos de Dados <ul><li>A estrutura de codificação de fases, atividades, recursos e projetos sejam utilizadas em todo o portfólio </li></ul><ul><li>Recursos compartilhados pertençam a um “pool” corporativo de recursos </li></ul>
  77. 77. Requisitos de Dados <ul><li>Recursos do mesmo tipo dividem as mesmas características (atributos comuns de peso, unidade, volumes, etc) </li></ul><ul><li>Atribuições típicas de recursos dividem as mesmas características (produtividade, custos, requisitos de materiais). </li></ul>
  78. 78. Requisitos de Dados <ul><li>Processos típicos são modelados da mesma forma entre todos os projetos </li></ul><ul><li>Estes itens e os requisitos de simulação de performance definem as estruturas de dados necessárias e algumas distinções serão vistas quando necessário. </li></ul>
  79. 79.
  80. 80. Estrutura de Dados <ul><li>Os elementos de qualquer modelo computacional de projeto são: </li></ul><ul><ul><li>Atividades de Projeto; </li></ul></ul><ul><ul><li>Dependências entre atividades; </li></ul></ul><ul><ul><li>Recursos e sua aplicação; </li></ul></ul><ul><ul><li>Calendários e Custos; </li></ul></ul><ul><ul><li>Estruturas Analíticas de: Trabalho, Recursos e Custos. </li></ul></ul>
  81. 81.
  82. 82. Dados de Atividades <ul><li>Normalmente atividades de projetos são caracterizadas por suas durações. </li></ul><ul><li>Além disso, é freqüentemente necessário se estabelecer o volume físico de trabalho correspondente a atividade. </li></ul>
  83. 83. Dados de Atividades <ul><li>Volumes de atividades podem ser medidos em metros, em toneladas, unidades, percentuais, horas planejadas ou qualquer outra unidade. </li></ul>
  84. 84. Dados de Atividades <ul><li>Diferente da duração, o volume de uma atividade não depende do recurso atribuído. </li></ul><ul><li>Uma atividade que descreva uma obra civil, um pedaço de software, um documento necessário por sua unidade de volume (m 2 , caso de uso, unidade) pode ser aplicada em um ou vários projetos. </li></ul>
  85. 85. Dados de Atividades <ul><li>A duração desta atividade é então o RESULTADO da quantidade de recursos disponíveis, o volume a ser realizado e a produtividade esperada. </li></ul>
  86. 86. Dados de Atividades <ul><li>A aplicação de VOLUMES permite definir os requerimentos de custo e materiais típicos por unidade (tijolos por m 2 ou pontos de função por caso de uso). </li></ul>
  87. 87. Dados de Atividades <ul><li>A base corporativa de dados pode então fornecer informações para cada projeto referentes ao uso de recursos típicos em função de produtividade ou índice de produção. </li></ul>
  88. 88. Dados de Dependências <ul><li>Normalmente é necessário se criar mais do que uma dependência entre tarefas (início-início & fim-fim, por exemplo). </li></ul><ul><li>Além dos “lags” positivos e negativos entre atividades, pode ser útil se criar “lags” baseados em VOLUMES (A solda entre tubos ocorre quando X tubos já foram desfilados; Os testes começam quando X casos de uso foram integrados). </li></ul>
  89. 89. Dados de Recursos <ul><li>Além de recursos individuais pode ser necessário se estabelecer as equipes/grupos e também as habilidades/papéis </li></ul><ul><li>Um “recurso-múltiplo” é um conjunto de recursos trabalhando juntos, como um time, um “carro com motorista”, um “computador com software”, etc) </li></ul>
  90. 90. Dados de Recursos <ul><li>Recursos são divididos em duas categorias: </li></ul><ul><ul><li>Renováveis (recursos humanos e equipamentos) </li></ul></ul><ul><ul><li>Consumíveis (materiais e equipamentos aplicados) </li></ul></ul><ul><li>Deve ser possível se atribuir materiais a recursos definindo seu consumo e não apenas as atividades (consumo de gasolina em um automóvel, por exemplo) </li></ul>
  91. 91. Dados de Recursos <ul><li>Se diferentes recursos podem fazer um mesmo trabalho então eles tem a mesma habilidade ou papel. </li></ul><ul><li>Recursos com a mesma habilidade são substituíveis entre si, apesar de poderem ter produtividades diferentes realizando a mesma atividade. </li></ul>
  92. 92. Dados de Recursos <ul><li>Um recurso pode ser utilizado em diferentes habilidades ou papéis. </li></ul><ul><li>Para cada papel, um recurso pode ter uma produtividade específica e consumir materiais/custos de uma forma específica. </li></ul>
  93. 93. Dados de Atribuições <ul><li>Atribuir recursos a atividades exige a noção de “equipe” – um grupo de recursos trabalhando em uma atividade juntos. </li></ul><ul><li>Uma “equipe” pode conter recursos individuais, múltiplos e habilidades/papéis. </li></ul>
  94. 94. Dados de Atribuições <ul><li>Para a definição de trabalhos parciais é necessário estabelecer tanto o percentual do recurso atribuído como sua quantidade. </li></ul><ul><ul><li>O uso de “cargas” ou “percentuais de aplicação” visto em alguns softwares não é suficiente pois para um projeto pode ser diferente ter dois recursos 50% do tempo do que ter 1 recurso 100% do tempo. </li></ul></ul>
  95. 95. Dados de Atribuições <ul><li>Um recurso útil para otimização de cronogramas é o registro de uso variável de recursos. </li></ul><ul><ul><li>Exemplo: Defini-se que o recurso X será utilizado com uma carga mínima de 40% e uma quantidade mínima de 3 unidades. Isso permite que uma atividade inicie com recursos parciais e receba novos recursos na medida em que eles estiverem disponíveis. </li></ul></ul>
  96. 96.
  97. 97. Dados de Atribuições <ul><li>Além de consumir materiais em uma atividade (processo), em alguns projetos é necessário se calcular a produção de materiais , de forma com que possam determinar o fluxo de ações para atividades subseqüentes. </li></ul>
  98. 98. Calendários <ul><li>Uma ferramenta corporativa deve conter mecanismos claros e detalhados para garantir a atribuição de calendários personalizados para: </li></ul><ul><ul><li>Atividades </li></ul></ul><ul><ul><li>Recursos </li></ul></ul><ul><ul><li>Relacionamentos (dependências) e “lags” </li></ul></ul>
  99. 99. Dados de Custos <ul><li>Normalmente não é suficiente definir custos por atividades e recursos e é necessário se conhecer todos os gastos e receitas, o que se gastará com impostos, aluguéis, equipamentos e etc. </li></ul><ul><li>Em alguns casos é necessário se conhecer taxas de retorno e câmbios de moedas </li></ul>
  100. 100. Dados de Custos <ul><li>Componentes de custo devem ser utilizados de diversas formas para garantir um gerenciamento de custos adequado </li></ul><ul><li>Deve-se expressar inclusive os desperdícios, como por exemplo o custo de equipamentos parados ou pessoal mobilizado sem atividades de projeto. </li></ul>
  101. 101.
  102. 102. Cálculo de Desperdício: recurso ativo x ocioso R$ 154.560 28 dias
  103. 103. Otimização de Cronograma = Redução do Desperdício R$ 138.000 25 dias
  104. 104. Economia de 11% ao tratar dados de custo adequadamente
  105. 105.
  106. 106. Centros de Materiais, recursos e custos <ul><li>A tomada de decisão em nível de portfólio ou mesmo no projeto necessita diversas formas de se comparar a realização x previsões. </li></ul><ul><li>Centros de custo, materiais e recursos permitem análises detalhadas de diversas faces de um mesmo projeto. </li></ul>
  107. 107. Múltiplas EAPs (WBS) <ul><li>A reorganização de atividades em diferentes Estruturas Analíticas de Projeto facilitam a identificação e detalhamento do escopo além de diferentes tipos de relatórios e mecanismos de controle. </li></ul><ul><li>Sugere-se pelo menos a construção de uma EAP baseada em entregáveis, outra em processos e uma terceira em responsáveis. </li></ul>
  108. 108. Múltiplas EAPs (WBS) <ul><li>Atividades sem atribuição de pacotes: </li></ul>
  109. 109. Múltiplas EAPs (WBS) <ul><li>Atividades com EAP por “entregáveis” </li></ul>
  110. 110. Múltiplas EAPs (WBS) <ul><li>Atividades com EAP por “responsabilidade” </li></ul>
  111. 111.
  112. 112. Arquivos de Projeto <ul><li>Um sistema de gestão de projetos deve ser capaz de permitir a análise de cenários não apenas entre um cronograma principal e uma linha de base, mas em função de múltiplas situações (medições diárias, semanais e mensais; cenários de risco; cenários de alternativas, etc) </li></ul><ul><li>Arquivos de projeto devem ser versionados. </li></ul>
  113. 113. Livros de Referência (bancos corporativos) <ul><li>Um sistema de gestão de projetos deve possuir padrões para aplicação em todo o portfólio. </li></ul><ul><li>Padrões devem incluir não somente processos e modelos, mas também estimativas (custo, prazo, recursos) de atividades típicas. </li></ul>
  114. 114.
  115. 115. Biblioteca de “Fragnets” <ul><li>Uma “fragnet” é um conjunto típico de processos que pode ser utilizado diversas vezes. </li></ul><ul><li>A criação de uma “fragnet” permite a modelagem detalhada de situações de projeto e sua reaplicação com maior segurança em novos projetos. </li></ul>
  116. 116. Biblioteca de “Fragnets” <ul><li>Em TI, as atividades habituais de levantamento de requisitos, arquitetura, desenvolvimento e testes baseados em um “caso de uso” pode ser uma “fragnet” reaplicada em um projeto com dezenas de casos de uso. </li></ul><ul><li>Pesos e ajustes finos são feitos no conjunto, aproveitando-se do ganho em produtividade na preparação do plano inicial. </li></ul>
  117. 117. Biblioteca de “Fragnets” <ul><li>Em engenharia civil, uma “fragnet” para a montagem de “um canteiro” pode conter os recursos mínimos em uma situação padrão e depois ser detalhada com base a volumes (tamanho do canteiro ou mesmo tipo de terreno). </li></ul><ul><li>Uma “fragnet” contém: </li></ul><ul><ul><li>Em situações típicas, quem faz o quê, em quanto tempo, por quanto, em que condições, por quanto e com que materiais e métodos. </li></ul></ul>
  118. 118. Continuação <ul><li>O complemento segue os slides originais. </li></ul><ul><li>Clique aqui para retornar a Parte 3 </li></ul>

×