Gest�o de Projecto by ao9zW50

VIEWS: 19 PAGES: 25

									 Gestão de Projecto
              Actividades de gestão
              Planeamento de projecto
              Organização da actividades
              Escalonamento do projecto
              Gestão de risco




João Araújo – Engenharia de Software
 Gestão de Projecto

              ES profissional está sujeita a restrições de orçamento e scheduling
              Falhas ocorridas em vários sistemas estavam relacionadas a
               problemas de gestão de SW:
                •     Entrega atrasada, não confiáveis, performance pobre, custos altos
              Gestores de SW são responsáveis pelo planeamento e escalonamento
               do desenvolvimento do projecto
              Diferença entre ES e outras engenharias
                •     O producto é intangível
                •     Não há um processo padrão
                •     Projectos de SW de grande porte são frequentemente one-off




João Araújo – Engenharia de Software
     Actividades de Gestão
          Actividades
            •     Preparação de proposta
                    • objectivos e como vai ser conduzido
            •     Cálculo do orçamento do projecto
                    • recursos necessários
            •     Planeamento e escalonamento do projecto
                    • milestones e deliverables
            •     Acompanhamento e revisões do projecto
                    • formal / informal
            •     Selecção e avaliação de pessoal
                    • orçamento, disponibilidade, treino
            •     Preparação de relatórios e apresentações
                    • documentos concisos e coerentes




João Araújo – Engenharia de Software
 Pessoal
              Pode não ser possível seleccionar as pessoas
               ideais para trabalhar no projecto
                •     O orçamento pode não permitir a utilização de profissionais
                      altamente especializados
                •     Profissionais com a experiência apropriada pode não estar
                      disponível
                •     Uma organizacão pode decidir por oferecer cursos aos seus
                      empregados
              Os gestores tem que trabalhar dentro destas
               restrições especialmente quando há uma falta de
               profissionais de TI a nível mundial


João Araújo – Engenharia de Software
 Planeamento de Projecto

              O gestor deve antecipar problemas e propor soluções
              Planeamento de projecto é uma atcividade que consome considerável
               tempo de gestão
              Tipos de planeamento:
                •     qualidade: procedimentos e padrões
                •     validação: abordagem, recursos e escalonamento
                •     gestão de configuração: procedimentos e estruturas de GC
                •     manutenção: requisitos, custos e esforço
                •     desenvolvimento de staff: cursos




João Araújo – Engenharia de Software
    Planeamento de Projecto
            •     Estabelecer as restrições do projecto
            •     Inicializar os parâmetros do projecto
            •     Definir milestones e deliverables
            •     while projecto não for completado ou cancelado do
                    •   faça o escalonamento do projecto
                    •   inicie actividades de acordo com o projecto
                    •   aguarde
                    •   revise o progresso do projecto
                    •   revise estimativas dos parâmetros do projecto
                    •   actualize o escalonamento do projecto
                    •   renegocie restrições do projecto e deliverables
                    •   if surgirem problemas then
                            iniciar revisões técnicas
                    • end if
            •     end do




João Araújo – Engenharia de Software
 Planeamento de Projecto

              Estrutura do documento
                •     Introdução
                •     Organização do projecto
                •     Análise de risco
                •     Requisitos de recursos de HW e SW
                •     Work breakdown - partição do projecto em actividades e identificação de
                      milestones e deliverables
                •     Escalonamento do projecto
                •     Mecanismos de acompanhamento e relatórios




João Araújo – Engenharia de Software
        Organização das Actividades

         Milestones: final de uma actividade
         Deliverable: um resultado do fim de uma fase de projecto entregue ao
          cliente
         Milestones no processo de requisitos


                                   Actividades

 Estudo de              Análise de         Desenvolv.      Estudo de      Especificação
factibilidade           requisitos         de protótipo     desenho       de requisitos



Relatório de            Definição          Relatório de     Desenho       Especificação
factibilidade          de requisitos        avaliação     arquitectural    de requisitos

João Araújo – Engenharia de Software
                                       Milestones
 Escalonamento do projecto
              Particionar o projecto em tarefas e estimar o
               tempo e recursos necessários p/ completar cada
               tarefa
              Organizar tarefas concorrentemente para fazer o
               melhor uso da força de trabalho
              Minimizar as dependências entre as tarefas p/
               evitar atrasos
              Depende da intuição e experência dos gestores


João Araújo – Engenharia de Software
 O processo de escalonamento



  Identificar            Identificar   Estimar    Alocar      Criar
  actividades           dependências   recursos   pessoas   diagramas



Requisitos de SW




João Araújo – Engenharia de Software
 Problemas de escalonamento
              Estimar o custo de desenvolvimento de uma
               solução é duro
              Productividade não é proporcional ao nº de
               pessoas trabalhando numa tarefa
              Adicionar pessoas a um projecto atrasado torna-o
               mais atrasado por causa dos problemas de
               comunicação
              O inesperado sempre acontece, portanto sempre
               considere contingência no planeamento


João Araújo – Engenharia de Software
     Dependências e durações de tarefas
          Tarefa                   Duração (dias)   Dependencias
           T1                            8
           T2                           15
           T3                           15            T1 (M1)
           T4                           10
           T5                           10          T2, T4 (M2)
           T6                            5          T1, T2 (M3)
           T7                           20           T1 (M1)
           T8                           25           T4 (M5)
           T9                           15          T3, T6 (M4)
           T10                          15          T5, T7 (M7)
           T11                           7           T9 (M6)
           T12                          10           T11 (M8)


João Araújo – Engenharia de Software
      Rede de Actividades
                                       14/7/99        15 days
                                                                             15 days
                                         M1             T3
                    8 days                                                     T9
                      T1                              5 days       4/8/99                 25/8/99
                                     25/7/99
                                                        T6          M4                     M6
         4/7/99                        M3
           start                                      20 days                                        7 days
                       15 days
                                                 T7                                             T11
                           T2

                                     25/7/99          10 days      11/8/99                             5/9/99
          10 days
                                        M2                          M7                               M8
             T4                                         T5                      15 days
                                                                                    T10      10 days
                             18/7/99
                                                                                                      T12
                                M5
                                                         25 days
                                                             T8                                     Finish
                                                                                       19/9/99
João Araújo – Engenharia de Software
    Diagrama de barras
             4/7        11/7    18/7   25/7   1/8    8/8   15/8   22/8   29/8   5/9    12/9   19/9
                   St art
           T4
           T1
           T2
                        M1
                            T7
                            T3
                             M5
                               T8
                                    M3
                                    M2
                                     T6
                                     T5
                                                     M4
                                                T9
                                                     M7
                                                     T10
                                                                         M6
                                                                  T11
                                                                                  M8
                                                                     T12
                                                                                                Finish

João Araújo – Engenharia de Software
     Alocação de pessoas a tarefas
         4/7    11/7     18/7    25/    1/8    8/8    15/8 22/8   29/8   5/9     12/9   19/9

  Fred     T4
                            T8                                    T11
                                                                           T12
  Jane     T1
                       T3
                                              T9
  Anne     T2
                                   T6                T10

  Jim                  T7

  Mary                             T5


João Araújo – Engenharia de Software
 Gestão de risco
              A gestão de risco preocupa-se em identificar
               riscos e planear p/ minimizar seus efeitos num
               projecto
              Um risco é a probabilidade de que alguma
               circunstância adversa ocorrerá
                •     Riscos de projecto afectam o escalonamento ou recursos
                •     Riscos de produto afectam a qualidade do software a ser
                      desenvolvido
                •     Riscos de negócio afectam a organização na procura ou no
                      desenvolvimento do software



João Araújo – Engenharia de Software
 Riscos de Software
         Risco                      Tipo         Descrição
         Mudança de pessoal         Projecto     Pessoal experiente deixa o projecto
                                                 antes que esteja terminado.
         Mudança na gestão          Projecto     Há uma mudança na gestão da
                                                 organização que implica em
                                                 prioridades diferentes.
         Falta de hardware          Projecto     Hardware essencial para o projecto
                                                 não será entregue no prazo certo
         Mudança de requisitos      Projecto e   Haverá um número maior de
                                    produto      mudanças nos requisitos do que o
                                                 que foi previsto
         Atrasos na especificação   Projecto e   Especificações de interfaces
                                    produto      importantes não estão prontas nos
                                                 prazos
         Tamanho subestimado        Projecto e   O tamanho do sistema foi
                                    produto      subestimado
         Desempenho fraco de        Produto      Ferramentas CASE não tem o
         ferrameta CASE                          desempenho esperado
         Mudança na tecnologia      Negócio      A tecnologia utilizada p/ construir o
                                                 sistema é superada por uma nova
                                                 tecnologia
         Competição com outro       Negócio      Um outro produto (concorrente) é
         produto                                 lançado no mercado antes que o
                                                 sistema seja completado

João Araújo – Engenharia de Software
 O processo de gestão de risco
              Identificação do risco
                •     Identificar riscos de projecto, de produto e de negócio
              Analisar os riscos
                •     Avaliar a probabilidade e as consequências destes riscos
              Planeamento de riscos
                •     estabelecer planos para evitar ou minimizar os efeitos dos riscos
              Monitoração de riscos
                •     Monitorar os riscos através do projecto




João Araújo – Engenharia de Software
 O processo de gestão de risco


    Identificação                Análise        Planeamento        Monitoração
      de riscos                  de riscos        de riscos         de riscos



                              Lista de riscos     Planos de         Avaliação
    Lista de riscos
                                em ordem        contingência e       de riscos
     em potencial
                              de prioridade     p/ evitar riscos




João Araújo – Engenharia de Software
 Identificação de risco
              Riscos de tecnologia
              Riscos de pessoal
              Riscos organizacionais
              Riscos de requisitos
              Riscos de estimativa




João Araújo – Engenharia de Software
 Riscos e tipos de riscos
  Tipo de risco          Riscos possíveis

  Tecnologia             As bases de dados utilizadas no sistema não podem processar tantas
                         transações por segundo como era esperado
                         Os componentes de SW que deviam ser reutilizados contém defeitos que
                         limitam sua funcionalidade

  Pessoal                É impossível recrutar pessoal com as habilidades necessárias
                         O pessoal chave não está disponível em fases críticas
                         Treino necessário p/ o pessoal não está disponível

  Organizacional         Problemas financeiros forçam a reduções no orçamento do projecto

  Ferramentas            O código gerado por ferramentas CASE tools é ineficiente.
                         Ferramentas CASE não podem ser integradas

  Requisitos             Mudanças nos requisitos que acarretam um considerável re-desenho são
                         propostas.

  Estimativa             O tempo necessário p/ desenvolver o SW é subestimado
                         O tamanho do SW é subestimado


João Araújo – Engenharia de Software
 Análise de riscos
              Avaliar a probabilidade e a seriedade do risco
              A probabilidade pode ser muito baixa, baixa, moderada,
               alta ou muito alta
              Os efeitos do risco podem ser catastróficos, sérios,
               toleráveis ou insignificantes
              Exemplos:
                •     O pessoal chave está doente em fases críticas do prohecto
                        • Probabilidade: Moderada
                        • Efeito: Sério
                •     É impossível recrutar pessoal qualificado
                        • Probabilidade: Alta
                        • Efeito: Catastrófico




João Araújo – Engenharia de Software
 Planeamento de riscos
              Considerar cada risco e desenvolver uma estratégia p/ gerir este risco
                •     Estratégias p/ evitar o risco
                        • A probabilidade p/ o surgimento do risco será reduzida
                •     Estratégias p/ minimizar o risco
                        • O impacto do risco no projecto ou produto será reduzida
              Planos de contingência
                •     Se o risco surgir, planos de contingência devem ser utilizados
              Exemplos:
                •     Problemas de recrutamento: alertar o cliente das dificuldades e das
                      possibilidades de atrasos, investigar componentes que possam ser
                      comprados
                •     Doenças: reorganizar o time para que haja mais sobreposição de
                      trabalho




João Araújo – Engenharia de Software
 Monitoração do risco
              Avaliar cada risco identificado regularmente p/
               verificar se ele está se tornando mais ou menos
               provável
              Avaliar se os efeitos do risco mudaram
              Cada risco chave deve ser discutido nas reuniões




João Araújo – Engenharia de Software
 Factores de risco

   • Indicadores de risco de acordo com o tipo de risco

         • Tecnologia: Atrasos na entrega do HW ou no suporte do SW

         • Pessoal: Desânimo, relacionamentos pobres entre os membros da equipa

         • Organização: Fofoca organizacional, falta de acção da gestão senior

         • Ferramentas: Reclamações sobre as ferramentas CASE utilizadas

         • Requisitos: Muitos pedidos de mudanças nos requisitos

         • Estimativa: Falha em cumprir o escalonamento
João Araújo – Engenharia de Software

								
To top