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
Gerenciamento de Projeto
● Organizar, planejar e elaborar cronograma
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
Tópicos
● Atividades de gerenciamento ● Planejamento de projeto
● Programação de projeto ● Gerenciamento de riscos
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
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,
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
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
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.
Tipos de planos de projeto
Plano Descrição
Plano de qualidade Descreve os procedimentos para teste de
qualidade que serão utilizados em um projeto Plano de validação Descreve a abordagem, os recursos e o
método utilizados para a validação do sistema
Plano de
gerenciamento de configuração
Descreve os procedimentos de
gerenciamento e as estruturas a serem utilizadas.
Plano de
manutenção Requisitos de manutenção do sistema, oscustos de manutenção e o esforço necessário.
Plano de
desenvolvimento de equipe
Descreve como as habilidades e a
experiência dos membros da equipe de projeto serão desenvolvidas.
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
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
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
Marcos no processo de
requisitos
Atividades Estudo de viabilidade Estudo deviabilidade Análise derequisitos Análise de
requisitos Desenvolvimentode protótipo Desenvolvimento
de protótipo Estudo de projeto Estudo de
projeto Especificação de requisitos Especificação
de requisitos
Relatório de viabilidade
Relatório de
viabilidade Requisitos do usuário Requisitos
do usuário Relatório deavaliação Relatório de
avaliação arquiteturaProjeto de Projeto de
arquitetura Requisitos do sistema Requisitos
do sistema
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
Slide 17
O processo de programação
de projeto
Identificar atividades Identificar atividades Identificar dependências de atividades Identificar dependências de atividades Requisitos de software Estimar recursos para atividades Estimar recursos para atividades Alocar pessoas às atividades Alocar pessoas às atividades Criar diagramas de projeto Criar diagramas de projeto Diagramas de atividades e diagramas de barraProblemas 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
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 redes de atividades
entre atividades e o caminho crítico.
● Os diagramas de barra mostram para quando diagramas de barra
está programado o início e término da atividade, bem como os responsáveis por cada atividade.
Duração de tarefas e
dependências
Atividade Duração (dias) Dependências 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)Rede de atividades
start T2 M3 T6 Finish T10 M7 T5 T7 M2 T4 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 days 25/7/99 15 days 25/7/99 18/7/99 10 days T1 M1 T3 T9 M6 T11 M8 T12 M4Diagrama 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 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T1 1 M8 T12 Start FinishAlocaçã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 T4 T8 T11 T12 T1 T3 T9 T2 T6 T10 T7 T5 Fred Jane Anne Mary JimGerenciamento 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
Riscos de software
Risco Tipo deRisco
Descrição
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 diferentes.
Indisponibilidade de hardware
Projeto O hardware essencial ao projeto não será entregue dentro do prazo
Alteração no requisitos Projeto e produto
Haverá maior número de mudanças nos requisitos do que o previsto.
Atrasos na especificação Projeto e produto
As especificações de interfaces essenciais não estavam disponíveis dentro dos prazos.
Tamanho subestimado Projeto e produto
O tamanho do sistema foi subestimado
Baixo desempenho de ferramentas CASE
Produto 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.
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.
O processo de gerenciamento
de riscos
Identificação de riscos
Identificação
de riscos Análise deriscos Análise de
riscos Planejamentode riscos Planejamento
de riscos Monitoramentode riscos Monitoramento
de riscos
Lista de riscos em potencial
Lista de riscos
em potencial Lista de riscospriorizados Lista de riscos
priorizados
Planos para evitar riscos e planos de contingência
Planos para evitar riscos e planos de contingência Avaliação de riscos Avaliação de riscos
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 risco
Tipos de risco Riscos possíveis
Tecnologia 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.
Pessoal Ë 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.
Organizacional 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.
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 exigem significativo retrabalho.
Os clientes não compreendem o impacto das mudanças nos requisitos.
Estimativa O tempo requerido para desenvolver o software é subestimado. A taxa de solução de defeitos é
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 (> alta(50-75%).
● Os efeitos dos riscos podem ser determinados
como catastróficos, sérios, toleráveis ou insignificantes.
Slide 31
Análise de riscos
Risco
Proba-bilidade
Efeitos
Problemas financeiro organizacionais forçam o orçamento do projeto.
Baixa Catastróficos É impossível recrutar pessoal com as habilidades
requeridas para o projeto.
Alta Catastróficos Pessoas chaves estão doentes em períodos
cruciais do projeto.
Moderada Sérios Componentes de software que deviam ser
reutilizados contém defeitos que limitam sua funcionalidade.
Moderada Sérios
São propostas mudanças nos requisitos, que exigem significado retrabalho.
Moderada Sérios A organização está estruturada de maneira que
diferentes gerências são responsáveis pelo projeto
Alta Sérios O banco de dados utilizado no sistema não pode
processar tantas transações por segundo, como esperado.
Análise de riscos
Risco
Proba-bilidade
Efeitos
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 das
mudanç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.
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
Estratégias de gerenciamento
de riscos
Risco Estratégia Problemas financeiros organizacionaisPrepare um documento informativo para a alta gerência, mostrando como o projeto presta uma contribuição muito importante para os objetivos da empresa Problemas de
recrutamento
Alerte o cliente sobre as dificuldades em potencial e a possibilidade de atrasos; investigue a compra de componentes
Componentes
defeituosos Substitua componentes potencialmente defeituosos por componentescomprados e que tenham confiabilidade reconhecida. Alterações nos
requisitos 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ção
organizacional
Prepare um documento informativo para a alta gerência, mostrando como o projeto presta uma contribuição muito importante para os objetivos da empresa. Desempenho do
banco de dados Investigue a possibilidade de comprar um banco de dados com maiordesempenho. Prazo de
desenvolvimento subestimado
Investigue a compra de componentes e verifique o uso de um gerador de programas.
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.
Fatores de risco
Tipos de risco Indicadores em potencial
Tecnologia 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ência Ferramentas Relutância de membros da equipe em utilizar ferramentas,
reclamações sobre ferramentas CASE, solicitações de estações de trabalho com maior capacidade.
Requisitos Muitos pedidos de modificações nos requisitos, reclamações do cliente.
Estimativa Falha no cumprimento do programa estabelecido, falha em eliminar defeitos registrados.
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
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 atividades
de 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.
