Slide 1

UNIVERSIDADE ESTADUAL PAULISTAINSTITUTO 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 2

Gerenciamento de Projeto

● Organizar, planejar e elaborar cronograma em projetos de software

Slide 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 4

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

Slide 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 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 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 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 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 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 11

Tipos de planos de projetoPlano Descrição

Plano de qualidade Descreve os procedimentos para teste dequalidade que serão utilizados em um projeto

Plano de validação Descreve a abordagem, os recursos e ométodo utilizados para a validação dosistema

Plano degerenciamento deconfiguração

Descreve os procedimentos degerenciamento e as estruturas a seremutilizadas.

Plano demanutenção

Requisitos de manutenção do sistema, oscustos de manutenção e o esforçonecessário.

Plano dedesenvolvimento deequipe

Descreve como as habilidades e aexperiência dos membros da equipe deprojeto serão desenvolvidas.

Slide 12

Processo de planejamento de projeto

Estabeleça as restrições do projetoFaça a avaliação inicial dos parâmetros do projetoDefina os marcos do projeto e os produtos a serem entreguesWhile 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 ifEnd loop

Slide 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 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 15

Marcos no processo de requisitos

Atividades

Estudo de viabilidade

Estudo de viabilidade

Análise derequisitos

Análise derequisitos

Desenvolvimentode protótipo

Desenvolvimentode protótipo

Estudo de projeto

Estudo de projeto

Especificação de requisitos

Especificação de requisitos

Relatório deviabilidade

Relatório deviabilidade

Requisitos do usuário

Requisitos do usuário

Relatório deavaliação

Relatório deavaliação

Projeto dearquiteturaProjeto dearquitetura

Requisitos do sistema

Requisitos do sistema

Marcos

Slide 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 17

O processo de programação de projeto

Identificar atividades

Identificar atividades

Identificar dependênciasde atividades

Identificar dependênciasde atividades

Requisitos de software

Estimar recursos para atividades

Estimar recursos para atividades

Alocar pessoas às atividades

Alocar pessoas às atividades

Criar diagramas deprojeto

Criar diagramas deprojeto

Diagramas de atividadese diagramas de barra

Slide 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 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 atividadesredes de atividades mostram dependências entre atividades e o caminho crítico.

● Os diagramas de barradiagramas de barra mostram para quando está programado o início e término da atividade, bem como os responsáveis por cada atividade.

Slide 20

Duração de tarefas e dependências

Atividade Duração(dias)

Dependências

T1 8T2 15T3 15 T1 (M1)T4 10T5 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 21

Rede de atividades

���������������������������

���������������������������

���������������������������

���������������������������

���������������������������

���������������������������

���������������������������

�����������������������������������������������������

��������������������������

��������������������������

��������������������������

���������������������������

���������������������������

������������������������������������������������������

���������������������������

���������������������������

���������������������������

���������������������������

���������������������������

���������������������������

��������������������������

��������������������������

��������������������������

���������������������������

���������������������������

���������������������������

���������������������������

start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/99

8 days

14/7/99 15 days

4/8/99

15 days

25/8/99

7 days

5/9/99

10 days

19/9/99

15 days

11/8/99

25 days

10 days

20 days

5 days25/7/99

15 days

25/7/99

18/7/99

10 days

T1

M1 T3T9

M6

T11

M8

T12

���������������������������

���������������������������

���������������������������M4

Slide 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

T4T1T2

M1

T7T3

M5T8

M3M2

T6T5

M4T9

M7T10

M6T1 1

M8T12

Start

Finish

Slide 23

Alocação de pessoas4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4T8 T11

T12T1

T3T9

T2T6 T10

T7

T5

Fred

Jane

Anne

Mary

Jim

Slide 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 25

Riscos de software Risco Tipo de

RiscoDescrição

Rotatividade de pessoal Projeto O pessoal experiente deixará o projeto antes dotérmino

Mudança degerenciamento

Projeto Haverá uma mudança no gerenciamentoorganizacional, com a definição de prioridadesdiferentes.

Indisponibilidade dehardware

Projeto O hardware essencial ao projeto não será entreguedentro do prazo

Alteração no requisitos Projeto eproduto

Haverá maior número de mudanças nos requisitosdo que o previsto.

Atrasos na especificação Projeto eproduto

As especificações de interfaces essenciais nãoestavam disponíveis dentro dos prazos.

Tamanho subestimado Projeto eproduto

O tamanho do sistema foi subestimado

Baixo desempenho deferramentas CASE

Produto As ferramentas CASE que apoiam o projeto nãoapresentam 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 novastecnologias

Concorrência com oproduto

Negócios Um produto concorrente foi lançado no mercadoantes que o sistema fosse concluído.

Slide 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 27

O processo de gerenciamento de riscos

Identificaçãode riscos

Identificaçãode riscos

Análise deriscos

Análise deriscos

Planejamentode riscos

Planejamentode riscos

Monitoramentode riscos

Monitoramentode riscos

Lista de riscosem potencial

Lista de riscosem potencial

Lista de riscospriorizados

Lista de riscospriorizados

Planos para evitarriscos e planosde contingência

Planos para evitarriscos e planosde contingência

Avaliação de riscos

Avaliação de riscos

Slide 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 29

Riscos e tipos de riscoTipos de risco Riscos possíveisTecnologia O banco de dados utilizado no sistema não pode

processar tantas transações por segundo, comoesperado. Componentes do software que deviam serreutilizados contem defeitos que limitam suafuncionalidade.

Pessoal Ë impossível treinar pessoal com a habilidade requerida.Pessoas importantes estão doentes e não disponíveis emperíodos cruciais.O treinamento necessário para o pessoal não estádisponível.

Organizacional A organização está estruturada de maneira quediferentes gerencias são responsáveis pelo projeto.Problemas financeiros organizacionais forçam reduçõesno orçamento do projeto.

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

Requisitos São propostas mudanças nos requisitos que exigemsignificativo retrabalho.Os clientes não compreendem o impacto das mudançasnos requisitos.

Estimativa O tempo requerido para desenvolver o software ésubestimado. A taxa de solução de defeitos ésubestimada. O tamanho do software é subestimado

Slide 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 31

Análise de riscosRisco Proba-

bilidadeEfeitos

Problemas financeiro organizacionais forçamo orçamento do projeto.

Baixa Catastróficos

É impossível recrutar pessoal com as habilidadesrequeridas para o projeto.

Alta Catastróficos

Pessoas chaves estão doentes em períodoscruciais do projeto.

Moderada Sérios

Componentes de software que deviam serreutilizados contém defeitos que limitam suafuncionalidade.

Moderada Sérios

São propostas mudanças nos requisitos, queexigem significado retrabalho.

Moderada Sérios

A organização está estruturada de maneira quediferentes gerências são responsáveis pelo projeto

Alta Sérios

O banco de dados utilizado no sistema não podeprocessar tantas transações por segundo, comoesperado.

Moderada Sérios

Slide 32

Análise de riscosRisco Proba-

bilidadeEfeitos

O tempo requerido para desenvolver o software éSubestimado.

Alta Sérios

As ferramentas Case não podem ser integradas Alta Sérios

Os clientes não compreendem o impacto dasmudanças nos requisitos

Moderada Toleráveis

O treinamento necessário para o pessoal não estádisponível

Moderada 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 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 34

Estratégias de gerenciamento de riscos

Risco EstratégiaProblemasfinanceirosorganizacionais

Prepare um documento informativo para a alta gerência, mostrando como oprojeto presta uma contribuição muito importante para os objetivos da empresa

Problemas derecrutamento

Alerte o cliente sobre as dificuldades em potencial e a possibilidade de atrasos;investigue a compra de componentes

Componentesdefeituosos

Substitua componentes potencialmente defeituosos por componentescomprados e que tenham confiabilidade reconhecida.

Alterações nosrequisitos

Extraia informações que podem ser rastreadas, para avaliar o impacto dasmudanças nos requisitos, maximize a inclusão de informações no projeto.

Reestruturaçãoorganizacional

Prepare um documento informativo para a alta gerência, mostrando como oprojeto presta uma contribuição muito importante para os objetivos da empresa.

Desempenho dobanco de dados

Investigue a possibilidade de comprar um banco de dados com maiordesempenho.

Prazo dedesenvolvimentosubestimado

Investigue a compra de componentes e verifique o uso de um gerador deprogramas.

Slide 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 36

Fatores de risco

Tipos de risco Indicadores em potencialTecnologia Atraso na entrega de hardware ou software de apoio, muitos

problemas de tecnologias são relatados.Pessoal Pessoal pouco motivado, relacionamento insatisfatório entre

os membros da equipe, disponibilidade de trabalho.Organizacional Fofocas na empresa, falta de iniciativa por parte da gerênciaFerramentas Relutância de membros da equipe em utilizar ferramentas,

reclamações sobre ferramentas CASE, solicitações deestações de trabalho com maior capacidade.

Requisitos Muitos pedidos de modificações nos requisitos, reclamaçõesdo cliente.

Estimativa Falha no cumprimento do programa estabelecido, falha emeliminar defeitos registrados.

Slide 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 38

Pontos chave● Um marco de projetomarco 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 redes de atividadesde atividades e diagramas de barrasdiagramas 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.