UNIVERSIDADE ESTADUAL PAULISTA
INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS
DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA
Gerenciamento de Projetos
Engenharia de Software 2o. Semestre/ 2006
Slide 2
Gerenciamento de Projeto
Organizar, planejar e elaborar cronograma em projetos de software
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
Slide 4
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
desenvolve o software.
Slide 6
Diferenças entre o gerenciamento de software e outras áreas da Eng.
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.
Atividades de gerenciamento
Elaboração de propostas
Planejamento e programação de projetos
Custo do projeto
Monitoramento e 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.
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.
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, os custos 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.
Slide 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 de progresso 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
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.
Para estabelecer marcos, o processo de software deve ser dividido em atividades básicas, com saídas
associadas.
Atividades e Marcos envolvidos na
especificação de requisitos com o uso da prototipação
Atividades
Estudo de viabilidade Estudo de
viabilidade Análise de requisitos Análise de
requisitos Desenvolvimento de 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 de avaliação Relatório de
avaliação Projeto de arquitetura Projeto de
arquitetura Requisitos do sistema Requisitos
do sistema
Marcos
Slide 16
Programação de projeto
dividir o trabalho total de um projeto em
atividades distintas e avaliar o 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.
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
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.
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 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.
Slide 20
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
T10 T5 M7
T7
T4 M2
M5 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 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 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
T4 T1
T2
M1 T7T3
M5 T8
M3 M2 T6 T5
M4 T9
M7 T10
M6 T1 1
M8 T12
Start
Finish
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 T4
T8 T11
T12 T1
T3
T9 T2
T6 T10
T7 Fred
Jane
Anne
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
Riscos de software
Risco Tipo de
Risco
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
Slide 26
O processo de gerenciamento de riscos
Identificação de riscos Identificação
de riscos Análise de
riscos Análise de
riscos Planejamento
de riscos Planejamento
de riscos Monitoramento
de riscos Monitoramento
de riscos
Lista de riscos em potencial Lista de riscos
em potencial Lista de riscos priorizados 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
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 28
Identificação de Riscos
Riscos quanto à tecnologia
Riscos quanto ao pessoal
Riscos organizacionais
Riscos quanto aos requisitos
Riscos quanto à estimativa
Riscos quanto à ferramentas
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 gerências 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 é
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-25%), moderada(25-50%), alta(50- 75%) ou muito alta (> 75%).
Os efeitos dos riscos podem ser determinados como catastróficos, sérios, toleráveis ou
insignificantes.
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
Slide 32
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.
Moderada Insignificantes
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égia
Problemas financeiros organizacionais
Prepare 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 componentes comprados e que tenham confiabilidade reconhecida.
Alterações nos
requisitos 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.
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 maior desempenho.
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.
Slide 36
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 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 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.
