Gerenciamento de Projetos: Planejamento

1
ENGENHARIA DE SOFTWARE
Planejamento de Projeto de Software
gt Livro Software Engineering gt Autor Roger S.
Pressman gt Editora McGraw-Hill gt Capítulos 5 e 7
2
Planejamento de Projeto de Software

• Introdução
• Escopo do Software
• Recursos
• Estimativa de Projeto de Software
• Relacionamento entre Pessoas e Esforço
• Distribuição do Esforço
• Determinação de Cronogramas
• Rastreamento e Controle de Projeto
• Plano de Projeto de Software

3
Planejamento de Projeto de SoftwareIntrodução

• Tempo O mais valioso bem disponível a um
  engenheiro de software. Se houver tempo
  disponível suficiente
• Um problema pode ser adequado/ analisado
• Uma solução pode ser compreensiva/ projetada
• O código-fonte deve ser cuidadosamente
  implementado e
• O programa, deve ser minuciosamente testado.

4
Planejamento de Projeto de Sofware Introdução

• Um projeto é planejado e tem seu cronograma
  determinado casualmente
• Os riscos são considerados somente depois que
  eles se transformaram em problemas completos e
• As pessoas não são organizadas de uma forma que
  agilize o progresso.
• O planejamento de projetos de software obriga
  gerentes e profissionais a despender tempo para
  organizar suas ações.

5
Planejamento de Projeto de Software Introdução

• Após compreender os requisitos funcionais do
  software, restrições relativas ao sistema e
  preocupações de confiabilidade, o planejador
  aplica técnicas e ferramentas para deduzir
  estimativas de esforço e de tempo.
• Estimativas oferecem informações úteis somente se
  estiverem integradas em uma estrutura de
  planejamento mais completa.

6
Planejamento de Projeto de Software Introdução

• Objetivos do Planejamento de Projeto
• Fornecer uma estrutura que permita o gerente
  fazer estimativas de recursos, custo e
  cronograma.
• Antes de iniciarmos o planejamento de projeto,
  devemos
• responder a algumas questões sobre riscos
• desenvolver estratégia para atacar o problema
• estabelecer mecanismo para avaliar o progresso
• organizar a equipe escolhida para construir o
  software.

7
Planejamento de Projeto de SoftwareEscopo do
Software

• O escopo do software descreve função, desempenho,
  restrições, interfaces e confiabilidade
• O escopo do software é definido através da
  comunicação entre o cliente e o analista de
  sistemas.
• Exemplo de técnica de comunicação usada
• FAST (Facilitated Application Specification
  Techniques)

8
Planejamento de Projeto de SoftwareRecursos
9
Planejamento de Projeto de SoftwareEstimativa de
Projeto de Software

• Custo e esforço de software nunca serão uma
  ciência exata.
• Muitas variáveis - humana, técnica, ambiental,
  política - podem afetar o custo final de software
  e o esforço aplicado ao seu desenvolvimento.
• Entretanto, estimativa de projeto de software
  pode ser transformada de uma arte misteriosa a
  uma série de passos sistemáticos que fornecem
  estimativas com risco aceitável.

10
Planejamento de Projeto de SoftwareEstimativa de
Projeto de Software

• Para ativar custo confiável e estimativa de
  esforço, existem várias opções
• Estimativa de atraso no projeto
• Estimativa baseada em projetos similares que já
  tenham sido completados
• Uso relativamente simples de técnicas de
  decomposição para gerar custo de projeto e
  estimativas de esforço
• Uso de um ou mais modelos empíricos para
  estimativa de custo e esforço do software.

11
Planejamento de Projeto de SoftwareRelacionamento
entre Pessoas e Esforço

• Em um projeto de desenvolvimento de software
  pequeno, uma única pessoa pode analisar os
  requisitos, executar o projeto, gerar o código e
  realizar testes.
• À medida que o tamanho do projeto aumenta, mais
  pessoas devem ser envolvidas.
• Há um mito comum no qual muitos gerentes que são
  responsáveis pelo esforço de desenvolvimento
  ainda acreditam

12
Planejamento de Projeto de SoftwareRelacionamento
entre Pessoas e Esforço

• ...se nos atrasarmos, sempre poderemos
  acrescentar mais programadores e posteriormente
  sairmos do atraso do projeto....
• Acrescentar pessoas tardiamente num projeto
  muitas vezes tem um efeito desintegrador sobre o
  projeto, fazendo com que o cronograma fuja ainda
  mais do controle.

13
Planejamento de Projeto de SoftwareRelacionamento
entre Pessoas e Esforço

• As pessoas que são incluídas no sistema, e as
  pessoas que as ensinam são as mesmas que estão
  realizando o trabalho. Enquanto estão ensinando,
  nenhum trabalho é feito
• Além do tempo despendido para se aprender o
  sistema, um número maior de pessoas aumenta o
  número de canais de comunicação e a complexidade
  desta ao longo de um projeto.
• novo canal de comunicação gt esforço e tempo
  adicional.

14
Planejamento de Projeto de SoftwareDistribuição
do Esforço

• Cada uma das técnicas de estimativa de projetos
  de software leva a estimativas de pessoas-mês (ou
  pessoas-ano) exigidas para se concluir o
  desenvolvimento do software.
• Essa distribuição, outrora chamada regra
  40-20-40, enfatiza as tarefas de análise e
  projeto realizadas no início do projeto e os
  testes realizados no final.

15
Planejamento de Projeto de SoftwareDistribuição
do Esforço
Atividade de testes e depuração (30 - 40)
Análise e projeto (40 - 40)
Codificação (15 - 20)
16
Planejamento de Projeto de SoftwareDistribuição
do Esforço

• Atualmente, mais de 40 de todo o esforço de
  projeto freqüentemente é recomendado para as
  tarefas de análise e projeto de grande projetos
  de desenvolvimento de software. Portanto, a regra
  40-20-40 não mais se aplica num sentido estrito.
• A distribuição de esforço ilustrada na figura
  deve ser usada somente como uma diretriz.
• As características de cada projeto devem ditar a
  distribuição do esforço.

17
Planejamento de Projeto de SoftwareDistribuição
do Esforço

• O esforço despendido em planejamento de projeto
  raramente é responsável por mais do que 2 a 3 do
  esforço total, a menos que o plano envolva
  grandes dispêndios com riscos.
• A análise de requisitos pode envolver de 10 a 25
  do esforço de projeto.
• O esforço despendido em análise ou construção de
  protótipos deve elevar-se em proporção direta com
  o tamanho e a complexidade do projeto.

18
Planejamento de Projeto de SoftwareDistribuição
do Esforço

• Uma margem de 20 a 25 do esforço normalmente é
  aplicada no projeto de software.
• O tempo gasto na revisão do projeto e na
  subseqüente iteração também deve ser considerado.
• Por causa do esforço aplicado no projeto de
  software, o código se desenvolverá com pouca
  dificuldade.
• Uma margem de 15 a 20 do esforço global pode ser
  conseguida.

19
Planejamento de Projeto de SoftwareDistribuição
do Esforço

• O teste e a subseqüente depuração podem ser
  responsáveis por uma margem de 30 a 40 do
  esforço de desenvolvimento do software.
• A condição crítica do software muitas vezes dita
  a quantidade de teste que é exigida.
• Se o software for human-rated (isto é, falha de
  software que pode resultar em perdas de vidas
  humanas), percentagens mais elevadas podem ser
  consideradas.

20
Planejamento de Projeto de Software Determinação
de Cronogramas

• A determinação de um cronograma para projetos de
  desenvolvimento de software pode ser vista a
  partir de duas perspectivas bem diferentes.
• Na primeira, uma data final para a entrega de um
  sistema baseado em computador já foi (e de
  maneira irrevogável) estabelecida. A organização
  é obrigada a distribuir o esforço dentro do
  espaço de tempo previsto.
• A segunda presume que limites cronológicos
  aproximados tenham sido discutidos, mas que a
  data final seja estabelecida pela organização de
  engenharia de software. O esforço é distribuído
  para que se possa tirar melhor proveito dos
  recursos e uma data final é definida após
  cuidadosa análise.

21
Planejamento de Projeto de Software Determinação
de Cronogramas

• A precisão na determinação de um cronograma às
  vezes pode ser bem mais importante do que a
  precisão na determinação dos custos.
• Num ambiente orientado ao produto, os custos
  adicionados podem ser absorvidos por nova
  determinação de preços ou por amortização ao
  longo de um grande número de vendas.
• Um cronograma descumprido, porém, pode reduzir o
  impacto de mercado, criar clientes insatisfeitos
  e elevar os custos internos.

22
Planejamento de Projeto de Software Determinação
de Cronogramas

• Quando abordamos a fixação de prazos para
  projetos de software, uma série de perguntas pode
  ser feita.
• Como relacionamos o tempo cronológico com o
  esforço humano?
• Quais tarefas e paralelismos podem ser esperados?
• Quais marcos de referência podem ser usados para
  mostrar o progresso?

23
Planejamento de Projeto de Software Determinação
de Cronogramas

• Como o esforço é distribuído ao longo do processo
  de engenharia de software?
• Existem métodos disponíveis de determinação de
  prazos?
• Como representaremos fisicamente o cronograma e
  como rastrearemos o progresso quando o projeto se
  iniciar?

24
Planejamento de Projeto de Software Determinação
de Cronogramas

• A determinação de um cronograma para um projeto
  de software não difere significativamente da
  fixação de prazos para qualquer esforço de
  desenvolvimento de multitarefas.
• Ferramentas e técnicas para determinação de um
  cronograma de projeto podem ser aplicadas no
  software com poucas modificações.

25
Planejamento de Projeto de Software Determinação
de CronogramasFases, passos e atividades num
projeto
26
Planejamento de Projeto de Software Determinação
de CronogramasGráfico de atividades para a
construção de uma casa
27
Planejamento de Projeto de Software Determinação
de CronogramasGráfico de atividades com durações
28
Planejamento de Projeto de Software Determinação
de Cronogramas

• O PERT - Program Evaluation and Review Technique
  (método de avaliação e revisão de programa) e o
  CPM - Critical Path Method (método do caminho
  crítico) são dois métodos de determinação de
  cronogramas que podem ser aplicados no
  desenvolvimento de software.

29
Planejamento de Projeto de Software Determinação
de Cronogramas

• Ambas as técnicas são dirigidas por informações
  já desenvolvidas em atividades de planejamento de
  projeto anterior
• estimativas de esforço
• uma decomposição de função de produto
• a seleção do modelo de processo apropriado
• a seleção de tipo de projeto e conjunto de
  tarefas.

30
Planejamento de Projeto de Software Determinação
de Cronogramas

• Independências entre tarefas pode ser definida
  usando uma rede de tarefa.
• Tarefas, algumas vezes chamadas WBS - Work
  Breakdow Structure (estrutura de divisão de
  trabalho), são definidas para o produto como um
  todo ou para funções individuais.
• Uma rede de tarefa é uma representação gráfica do
  fluxo de tarefa para um projeto.

31
Planejamento de Projeto de Software Determinação
de CronogramasCPM bar chart
32
Planejamento de Projeto de Software Determinação
de CronogramasExemplo de Work Breakdown
Structure (WBS)
33
Planejamento de Projeto de Software Determinação
de CronogramasGantt chart para o exemplo de WBS
34
Planejamento de Projeto de Software Determinação
de Cronogramas

• Tanto o PERT como o CPM proporcionam ferramentas
  quantitativas que permitem ao planejador de
  software
• determinar o caminho crítico - a cadeia de
  tarefas que determina a duração do projeto
• estabelecer as estimativas de tempo mais
  prováveis para tarefas individuais ao aplicar
  modelos estatísticos e
• calcular limites de tempo que definam uma
  janela de tempo para uma tarefa em particular.

35
Planejamento de Projeto de Software Determinação
de Cronogramas

• Cálculos de limite de tempo podem ser muito úteis
  na determinação de um cronograma para projetos de
  software.
• Deslize no projeto de uma função, por exemplo,
  pode retardar ainda mais o desenvolvimento de
  outras funções.

36
Planejamento de Projeto de Software Determinação
de Cronogramas

• Importantes limites de tempo que podem ser
  reconhecidos numa rede PERT ou CPM
• 1) o tempo mais cedo em que uma tarefa pode
  iniciar-se quando todas as tarefas precedentes
  foram completadas no tempo mais curto possível
• 2) o tempo mais tarde para o início da tarefa
  antes que o tempo de conclusão mínimo do projeto
  seja atrasado
• 3) o término mais breve - a soma do início mais
  cedo com a duração da tarefa

37
Planejamento de Projeto de Software Determinação
de Cronogramas

• 4) o término mais tardio - o momento de início
  mais tarde somado à duração da tarefa
• 5) a flutuação total - a quantidade de superávit
  de tempo ou margem de segurança permitida nas
  tarefas, determinação de prazos de forma que o
  caminho crítico da rede seja mantido dentro do
  prazo.

38
Planejamento de Projeto de Software Determinação
de Cronogramas

• Os cálculos de tempo-limite levam à determinação
  do caminho crítico e proporcionam ao gerente um
  método quantitativo para avaliar o progresso à
  medida que as tarefas são concluídas.
• O planejador deve reconhecer que o esforço de
  manutenção, ainda que não seja fácil de programar
  neste estágio, tornar-se-á, por fim, o maior
  fator de custo.

39
Planejamento de Projeto de Software Determinação
de Cronogramas

• PERT e CPM foram implementadas em uma grande
  variedade de ferramentas automatizadas que estão
  disponíveis para todos os computadores pessoais.
• Tais ferramentas são relativamente fáceis de
  serem usadas e tornam os métodos de análise
  disponíveis para todos os gerentes de projetos de
  software.

40
Planejamento de Projeto de SoftwareRastreamento
e Controle de Projeto

• Há um ditado que diz Os projetos de software
  atrasam-se em seu cronograma um dia de cada vez.
  O atraso de um dia na programação raramente será
  fatal para um projeto. Mas os dias se somam e, ao
  longo da extensão de um projeto, pequenos atrasos
  podem resultar em grandes problemas.
• Um dos papéis da administração é rastrear e
  controlar o projeto de software assim que ele é
  iniciado.

41
Planejamento de Projeto de SoftwareRastreamento
e Controle de Projeto

• O rastreamento (tracking) pode ser feito de
  muitas maneiras diferentes
• Realizando-se reuniões sobre a situação do
  projeto, em que cada membro da equipe relate o
  progresso e os problemas.
• Avaliando-se os resultados de todas as revisões
  realizadas ao longo do processo de engenharia de
  software.
• Determinando-se se os marcos de referência de
  projeto formais foram atingidos até a data
  programada.

42
Planejamento de Projeto de SoftwareRastreamento
e Controle de Projeto

• Comparando-se a data de início real com a data de
  início planejada para cada tarefa de projeto
  relacionada na tabela de recursos.
• Reunindo-se informalmente com profissionais para
  se obter suas avaliações subjetivas do progresso
  até o momento e os problemas que aparecem no
  horizonte.
• Todas essas técnicas de rastreamento são usadas
  por gerentes de projeto experientes.

43
Planejamento de Projeto de SoftwareRastreamento
e Controle de Projeto

• O controle é empregado por um gerente de projetos
  de software para administrar os recursos do
  projeto, enfrentar problemas e dirigir o pessoal
  do projeto.
• Se o projeto estiver no prazo e dentro do
  orçamento, as revisões indicarem progresso real e
  os marcos estiverem sendo atingidos, o controle é
  leve.
• Quando ocorrerem problemas, o gerente de projetos
  deverá exercer o controle para saná-los o mais
  rapidamente possível.
• Depois que o problema tiver sido diagnosticado,
  recursos adicionais podem ser concentrados na
  área de problema o pessoal pode novamente ser
  disposto ou a programação do projeto, redefinida.
  

44
Planejamento de Projeto de Software Processo de
Planejamento de Projeto

• 1) Estabelecer a data de início do projeto
• 2) Estabelecer a data final do projeto
• 3) Estabelecer a metodologia de projeto ou ciclo
  de vida do projeto a ser usado
• 4) Determinar o escopo do projeto em termos das
  fases da metodologia ou do ciclo de vida do
  projeto
• 5) Identificar ou selecionar os métodos de
  revisão a serem usados

45
Planejamento de Projeto de Software Processo de
Planejamento de Projeto

• 6) Identificar qualquer milestone (conclusão de
  uma atividade) predeterminado ou outras datas
  críticas que devem ser encontradas
• 7) Listar tarefas, por fase do projeto, a fim de
  que elas possam ser acompanhadas
• 8) Estimar o pessoal necessário para acompanhar
  cada tarefa
• 9) Estimar o pessoal disponível para acompanhar
  cada tarefa

46
Planejamento de Projeto de Software Processo de
Planejamento de Projeto

• 10) Determinar nível de perfil necessário para
  desempenhar cada tarefa
• 11) Determinar dependências de tarefa
• Quais tarefas podem ser feitas em paralelo
• Quais tarefas requerem estar completas para que
  outras tarefas possam iniciar
• 12) Projetar pontos de controle ou de revisão
• 13) Realizar estimativa de custo de projeto e
  análise de custo x benefício

47
Planejamento de Projeto de Software Plano de
Projeto de Software

• Cada etapa do processo de engenharia de software
  deve produzir um resultado que possa ser revisado
  e possa funcionar como uma base para os passos
  que se seguirão.
• O Plano de Projeto de Software é produzido ao
  término das tarefas de planejamento e fornece
  informações básicas sobre o custo e programação
  de recursos que serão usadas ao longo do processo
  de engenharia de software

48
Planejamento de Projeto de Software Plano de
Projeto de Software

• O Plano de Projeto de Software deve
• 1. Comunicar o escopo e os recursos à
  administração, ao pessoal técnico e ao cliente do
  software
• 2. Definir os riscos e sugerir técnicas para
  evitá-los
• 3. Definir custos e prazos para as revisões
  administrativas
• 4. Oferecer uma abordagem global ao
  desenvolvimento do software para todas as pessoas
  envolvidas no projeto
• 5. Delinear como qualidade será garantida e
  mudanças serão gerenciadas.

49
Planejamento de Projeto de Software Plano de
Projeto de Software

• O Plano de Projeto de Software não precisa ser um
  documento extenso e complexo. Seu propósito é
  ajudar a estabelecer a viabilidade do esforço de
  desenvolvimento.
• O plano concentra-se na declaração geral do o
  que e na declaração específica de quanto e
  por quanto tempo.
• As etapas subseqüentes do processo de engenharia
  de software concentrar-se-ão na definição,
  desenvolvimento e manutenção.

50
Planejamento de Projeto de Software Plano de
Projeto de Software