Gerenciamento de Projetos: Planejamento - PowerPoint PPT Presentation

About This Presentation
Title:

Gerenciamento de Projetos: Planejamento

Description:

Title: Gerenciamento de Projetos: Planejamento Author: Marcos Rog rio Viana Ferreria Rocha Last modified by: Uem Created Date: 10/4/1999 8:54:48 PM – PowerPoint PPT presentation

Number of Views:103
Avg rating:3.0/5.0
Slides: 51
Provided by: Marcos196
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com