Gerenciamento de Projeto

Transcrição

1 UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Projeto Engenharia de Software 2o. Semestre/ 2005 Slide 1

2 Gerenciamento de Projeto Organizar, planejar e elaborar cronograma em projetos de software Slide 2

3 Objetivos Mostrar as diferenças entre o gerenciamento de projetos de software e outros tipos e projetos de engenharia; Conhecer as principais tarefas dos gerentes de projeto de software; Discutir planejamento de projeto e o processo de planejamento; Mostrar como as representações gráficas de cronogramas são usadas pelos gerentes de projeto; Discutir a noção de riscos e o processo de gerenciamento de riscos. Slide 3

4 Tópicos Atividades de gerenciamento Planejamento de projeto Programação de projeto Gerenciamento de riscos Slide 4

5 Gerenciamento de projeto de software Preocupa-se com atividades envolvidas em assegurar que o software seja entregue dentro do prazo e do orçamento e que seja realizado em conformidade com os padrões requeridos. Gerenciamento de projeto é necessário porque o desenvolvimento de software está sempre sujeito a restrições de orçamento e de prazo que são estabelecidos pela organização que desenvolve o software. Slide 5

6 Diferenças para o gerenciamento de software O produto é intangível Não há processo de software padrão Grandes projetos são, freqüentemente, projetos únicos. A experiência com um tipo de projeto, em geral, não pode ser aplicada para outro tipo de projeto. Slide 6

7 Atividades de gerenciamento Elaboração de propostas Planejamento e programação de projetos Custo do projeto Monitoramento de revisões de projetos Seleção e avaliação de pessoal Elaboração de relatórios e apresentações Slide 7

8 Pontos comuns de gerenciamento Essas atividades não são exclusivas de gerenciamento de software. Muitas técnicas de gerenciamento de projeto de engenharia são aplicáveis ao gerenciamento de projeto de software. Sistemas de engenharia tecnicamente complexos tendem a apresentar os mesmos problemas dos sistemas de software. Slide 8

9 Equipe de projeto Pode não ser possível selecionar a equipe ideal para trabalhar em um projeto O orçamento do projeto pode não ser suficiente para contratar uma equipe bem-paga. Equipe com a experiência apropriada pode não estar disponível. A organização pode querer desenvolver as habilidades de seus funcionários em um projeto de software que irá iniciar. O gerente de software precisa trabalhar dentro dessas limitações quando seleciona a equipe de projeto Slide 9

10 Planejamento de projeto É a atividade de gerenciamento que mais consome tempo. É uma atividade contínua (concepção até entrega do produto). Planos devem ser revidados conforme informações se tornam disponíveis. Diferentes tipos de planos podem ser desenvolvidos para apoiar o plano de projeto principal que está preocupado com orçamento e programação. Slide 10

11 Tipos de planos de projeto Plano Plano de qualidade Plano de validação Plano de gerenciamento de configuração Plano de manutenção Plano de desenvolvimento de equipe Descrição Descreve os procedimentos para teste de qualidade que serão utilizados em um projeto Descreve a abordagem, os recursos e o método utilizados para a validação do sistema Descreve os procedimentos de gerenciamento e as estruturas a serem utilizadas. Requisitos de manutenção do sistema, os custos de manutenção e o esforço necessário. Descreve como as habilidades e a experiência dos membros da equipe de projeto serão desenvolvidas. Slide 11

12 Processo de planejamento de projeto Estabeleça as restrições do projeto Faça a avaliação inicial dos parâmetros do projeto Defina os marcos do projeto e os produtos a serem entregues While projeto não tiver terminado ou cancelado loop Faça a programação do projeto Inicie as atividades de acordo com a programação Aguarde (por um período) Examine o progresso do projeto Revise as estimativas de parâmetros do projeto Atualize a programação do projeto Reanalise as restrições do projeto e os produtos a serem entregues If surgirem problemas, then Inicie revisão técnica end if End loop Slide 12

13 Estrutura do plano de projeto Introdução Organização de projeto Análise de riscos Requisitos necessários de hardware e software Estrutura analítica Programação de projeto Mecanismos de monitoramento e de elaboração de relatórios Slide 13

14 Organização de atividades As atividades em um projeto devem ser organizadas de modo a produzir saídas tangíveis para os gerentes julgar o progresso. Marcos são o ponto-final de uma atividade de processo de software. Um produto a ser entregue é o resultado do projeto entregue ao cliente. O processo com prototipação, por exemplo, permite uma definição direta de marcos de progresso. Slide 14

15 Marcos no processo de requisitos Atividades Estudo Estudo de de viabilidade viabilidade Análise Análise de de requisitos requisitos Desenvolvimento Desenvolvimento de de protótipo protótipo Estudo Estudo de de projeto projeto Especificação Especificação de de requisitos requisitos Relatório Relatório de de viabilidade viabilidade Requisitos Requisitos do do usuário usuário Relatório Relatório de de avaliação avaliação Projeto Projeto de de arquitetura arquitetura Requisitos Requisitos do do sistema sistema Marcos Slide 15

16 Programação de projeto Envolve a divisão do trabalho total de um projeto em atividades distintas e avaliação do tempo necessário para completar essas atividades. Coordenar as atividades paralelas de modo que a força de trabalho seja otimizada. Minimizar dependências entre tarefas para evitar atrasos causados por uma tarefa ter que esperar que outra seja encerrada. Depende da intuição e experiência do gerente de projeto. Slide 16

17 O processo de programação de projeto Identificar Identificar atividades atividades Requisitos de software Identificar Identificar dependências dependências de de atividades atividades Estimar Estimar recursos recursos para para atividades atividades Alocar Alocar pessoas pessoas às às atividades atividades Criar Criar diagramas diagramas de de projeto projeto Diagramas de atividades e diagramas de barra Slide 17

18 Problemas com a programação Estimar a dificuldade de problemas e o custo para desenvolver uma solução é difícil. A produtividade não é proporcional ao número de pessoas que estão trabalhando em uma tarefa. Adicionar pessoas a um projeto atrasado pode atrasá-lo ainda mais por causa do aumento de comunicação. O inesperado sempre acontece. Mantenha sempre um plano de ação. Slide 18

19 Diagramas de barras e redes de atividades Notações gráficas utilizadas para ilustrar a programação de projeto. Mostram a divisão do projeto em atividades. Atividades não devem ser muito pequenas. Devem durar pelo menos uma semana. As redes de atividades mostram dependências entre atividades e o caminho crítico. Os diagramas de barra diagramas de barra mostram para quando está programado o início e término da atividade, bem como os responsáveis por cada atividade. Slide 19

20 Duração de tarefas e dependências Atividade Duração Dependências (dias) 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) Slide 20

21 Rede de atividades 8 days 14/7/99 15 days M1 T3 15 days T9 4/7/99 start T1 15 days T2 25/7/99 M3 T7 5 days T6 20 days 4/8/99 M4 25/8/99 M6 T11 7 days 10 days T4 25/7/99 M2 10 days T5 11/8/99 M7 15 days 5/9/99 M8 18/7/99 M5 T10 10 days T12 25 days T8 19/9/99 Finish Slide 21

22 Diagrama de barras de atividades 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 T4 T1 T2 Start M1 T7 T3 M5 T8 M3 M2 T6 T5 T9 M4 M7 T10 T1 1 T12 M6 M8 Finish Slide 22

23 Alocação de pessoas 4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Fred Jane Anne Jim Mary T4 T1 T2 T3 T7 T8 T6 T5 T9 T10 T11 T12 Slide 23

24 Gerenciamento de riscos Gerenciamento de riscos se preocupa em identificar riscos e traçar planos para minimizar os efeitos sobre o projeto. Risco é a probabilidade de que alguma circunstância adversa venha a ocorrer. Riscos relacionados ao projeto afetam a programação ou os recursos do projeto Riscos relacionados ao produto afetam a qualidade ou o desempenho do software que está sendo construído. Riscos para o negócio afetam a organização que está desenvolvendo ou adquirindo o software Slide 24

25 Riscos de software Risco Tipo de Descrição Risco Rotatividade de pessoal Projeto O pessoal experiente deixará o projeto antes do término Mudança de gerenciamento Projeto Haverá uma mudança no gerenciamento organizacional, com a definição de prioridades Indisponibilidade de hardware Alteração no requisitos Atrasos na especificação Projeto Projeto e produto Projeto e produto diferentes. O hardware essencial ao projeto não será entregue dentro do prazo Haverá maior número de mudanças nos requisitos do que o previsto. As especificações de interfaces essenciais não estavam disponíveis dentro dos prazos. Tamanho subestimado Baixo desempenho de ferramentas CASE Projeto e produto Produto O tamanho do sistema foi subestimado As ferramentas CASE que apoiam o projeto não apresentam desempenho conforme o previsto. Mudanças na tecnologia Negócios A tecnologia básica sobre a qual o sistema está sendo construído foi superada por novas tecnologias Concorrência com o produto Negócios Um produto concorrente foi lançado no mercado antes que o sistema fosse concluído. Slide 25

26 O processo de gerenciamento de riscos Identificação de riscos Identificar riscos de projeto, produto e negócios Análise de riscos Avaliar as possibilidades e as conseqüências da ocorrência desses riscos. Planejamento de riscos Traçar planos para enfrentar os riscos, seja evitando-os, seja minimizando seus efeitos sobre o projeto. Monitoramento de riscos Avaliar constantemente os riscos e revisar os planos para diminuição de riscos, a medida que mais informações sobre eles se tornam disponíveis. Slide 26

27 O processo de gerenciamento de riscos Identificação Identificação de de riscos riscos Análise Análise de de riscos riscos Planejamento Planejamento de de riscos riscos Monitoramento Monitoramento de de riscos riscos Lista Lista de de riscos riscos em em potencial potencial Lista Lista de de riscos riscos priorizados priorizados Planos Planos para para evitar evitar riscos riscos e e planos planos de de contingência contingência Avaliação Avaliação de de riscos riscos Slide 27

28 Identificação de Riscos Riscos quanto à tecnologia Riscos quanto ao pessoal Riscos organizacionais Riscos quanto aos requisitos Riscos quanto à estimativa Riscos quanto à ferramentas Slide 28

29 Riscos e tipos de risco Tipos de risco Tecnologia Pessoal Organizacional Ferramentas Requisitos Estimativa Riscos possíveis O banco de dados utilizado no sistema não pode processar tantas transações por segundo, como esperado. Componentes do software que deviam ser reutilizados contem defeitos que limitam sua funcionalidade. Ë impossível treinar pessoal com a habilidade requerida. Pessoas importantes estão doentes e não disponíveis em períodos cruciais. O treinamento necessário para o pessoal não está disponível. A organização está estruturada de maneira que diferentes gerencias são responsáveis pelo projeto. Problemas financeiros organizacionais forçam reduções no orçamento do projeto. O código gerado pelas ferramentas CASE é ineficiente. As ferramentas CASE não podem ser integradas São propostas mudanças nos requisitos que exigem significativo retrabalho. Os clientes não compreendem o impacto das mudanças nos requisitos. O tempo requerido para desenvolver o software é subestimado. A taxa de solução de defeitos é subestimada. O tamanho do software é subestimado Slide 29

30 Análise de riscos Julgar sobre a probabilidade e a seriedade de cada risco identificado. A probabilidade pode ser muito baixa (<10%), baixa (10-15%), moderada(15-50%), alta(50-75%) ou muito alta (> 75%). Os efeitos dos riscos podem ser determinados como catastróficos, sérios, toleráveis ou insignificantes. Slide 30

31 Análise de riscos Risco Problemas financeiro organizacionais forçam o orçamento do projeto. É impossível recrutar pessoal com as habilidades requeridas para o projeto. Pessoas chaves estão doentes em períodos cruciais do projeto. Componentes de software que deviam ser reutilizados contém defeitos que limitam sua funcionalidade. São propostas mudanças nos requisitos, que exigem significado retrabalho. A organização está estruturada de maneira que diferentes gerências são responsáveis pelo projeto O banco de dados utilizado no sistema não pode processar tantas transações por segundo, como esperado. Probabilidade Baixa Alta Moderada Moderada Moderada Alta Moderada Efeitos Catastróficos Catastróficos Sérios Sérios Sérios Sérios Sérios Slide 31

32 Análise de riscos Risco O tempo requerido para desenvolver o software é Subestimado. Probabilidade Alta Sérios As ferramentas Case não podem ser integradas Alta Sérios Efeitos Os clientes não compreendem o impacto das mudanças nos requisitos O treinamento necessário para o pessoal não está disponível Moderada Moderada Toleráveis Toleráveis A taxa de solução de defeitos é subestimada. Moderada Toleráveis O tamanho do software é subestimado. Alta Toleráveis O código gerado pelas ferramentas CASE é ineficiente. Moderada Insignificantes Slide 32

33 Planejamento de riscos Considera cada um dos riscos mais importantes e define estratégias para gerencia-lo. Estratégias preventivas Reduzem a probabilidade de o risco surgir Estratégias de minimização Diminuem o impacto do risco Planos de contingência Se o risco acontecer, existe uma estratégia pronta para lidar com o caso Slide 33

34 Estratégias de gerenciamento de riscos Risco Problemas financeiros organizacionais Problemas de recrutamento Componentes defeituosos Alterações nos requisitos Reestruturação organizacional Desempenho do banco de dados Prazo de desenvolvimento subestimado Estratégia Prepare um documento informativo para a alta gerência, mostrando como o projeto presta uma contribuição muito importante para os objetivos da empresa Alerte o cliente sobre as dificuldades em potencial e a possibilidade de atrasos; investigue a compra de componentes Substitua componentes potencialmente defeituosos por componentes comprados e que tenham confiabilidade reconhecida. Extraia informações que podem ser rastreadas, para avaliar o impacto das mudanças nos requisitos, maximize a inclusão de informações no projeto. Prepare um documento informativo para a alta gerência, mostrando como o projeto presta uma contribuição muito importante para os objetivos da empresa. Investigue a possibilidade de comprar um banco de dados com maior desempenho. Investigue a compra de componentes e verifique o uso de um gerador de programas. Slide 34

35 Monitoramento de riscos Avaliar regularmente cada um dos riscos identificados, a fim de decidir se esse risco está se tornando mais ou menos provável. Avaliar também se os efeitos desses riscos se modificaram. O monitoramento de riscos deve ser um processo contínuo. Cada um dos riscos principais deve ser considerado separadamente e discutido em uma reunião. Slide 35

36 Fatores de risco Tipos de risco Tecnologia Pessoal Organizacional Ferramentas Requisitos Estimativa Indicadores em potencial Atraso na entrega de hardware ou software de apoio, muitos problemas de tecnologias são relatados. Pessoal pouco motivado, relacionamento insatisfatório entre os membros da equipe, disponibilidade de trabalho. Fofocas na empresa, falta de iniciativa por parte da gerência Relutância de membros da equipe em utilizar ferramentas, reclamações sobre ferramentas CASE, solicitações de estações de trabalho com maior capacidade. Muitos pedidos de modificações nos requisitos, reclamações do cliente. Falha no cumprimento do programa estabelecido, falha em eliminar defeitos registrados. Slide 36

37 Pontos chave Um bom gerenciamento de projeto é essencial para o sucesso do projeto. A natureza intangível do software causa problemas para o gerenciamento. Atividades importantes de gerentes de software: planejamento, estimativa e programação. O planejamento e a estimativa são processos iterativos que continuam ao longo do projeto. Slide 37

38 Pontos chave Um marco de projeto é o resultado previsto de uma atividade em que algum relatório formal de progresso deve ser apresentado à gerência. A programação de projeto envolve a criação de várias representações gráficas, incluindo redes de atividades e diagramas de barras. Os principais riscos de projeto devem ser identificados, avaliados e monitorados, de forma a elaborar planos preventivos, gerenciamento de riscos, ou planos para administrar os riscos. Slide 38