Gerenciamento de projeto - UNESP: Câmpus de São José do ...ines/cursos/eng_soft/aula03.pdf ·...
Transcript of Gerenciamento de projeto - UNESP: Câmpus de São José do ...ines/cursos/eng_soft/aula03.pdf ·...
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.