Qualidade de Software
Gerenciamento de Projetos
Marcelo Marinho
Conteúdo
• Erros clássicos de planejamento e
gerenciamento
• O que é projeto?
• Ciclo de vida de projetos
• Elementos essenciais
• Objetivos gerais do planejamento e
Erros Clássicos
• Desenvolvimento de Software é uma
atividade complicada, então evite
Pessoas
• Motivação incoerente
– Esforço do pessoal e chefe de férias …
• Pessoal fraco
– Seleção apressada ao invés de conveniente …
• Pessoal problemático
– Uma pessoa pode desconcentrar uma equipe …
• Heroísmo
Pessoas
• Mais pessoas no final do projeto
– Em pequeno incêndio, jogue gasolina …
• Escritórios barulhentos
– Meu nível de concentração é excelente …
• Atrito entre desenvolvedores e clientes
Pessoas
• Expectativas irreais
– Vamos terminar o projeto em 6 meses …
• Falta de interação com o usuário
– Isso é ambíguo …, então vamos decidir sozinhos.
• Crença cega
– Essa parte do sistema é muito simples, em 1 ou 2 dias removemos todos os erros …
Processo
• Cronogramas altamente otimistas
– Ganhamos tempo na análise de requisitos e no projeto …
• Gerenciamento de riscos insuficiente
– Se o risco A se concretizar, resolvemos …
• Falha de contratos
– Com o módulo M, a ser criado pela empresa E, vamos melhorar nosso cronograma …
Processo
• Planejamento insuficiente
– Esse sistema é simples, não há o que planejar …
• Abandono de plano sob pressão
– Devido ao cronograma apertado, vamos codificar logo depois da especificação de requisitos e não vamos testar …
Processo
• Garantia de qualidade prejudicada
– Só precisamos fazer os testes a partir da GUI
• Controle de gerenciamento insuficiente
– O que já fizemos? Não sei, mas sem problema …
• Sem estimativas para tarefas necessárias
Processo
• Planejamento para controlar depois
– Fizemos em 3 meses, o que planejamos fazer em 2, mas depois nós ganhamos tempo …
• Programação sem padronização
Produto
• Requisitos demais
– Sei que o usuário não pediu, mas vamos melhorar a performance do sistema …
• Desenvolvedor exagerado
– Sei que o sistema não precisa e que não domino a tecnologia, mas vou usar o recurso R …
• Desenvolvimento orientado a pesquisa
– Sei que vou desenvolver funcionalidade F, que é estado-da-arte, mas minha estimativa é razoável …
Tecnologia
• Síndrome da bala de prata
– Vou usar o gerador de GUIs e não terei problemas quanto ao desenvolvimento das GUIs …
• Estimativa otimista com novas ferramentas ou
métodos
Tecnologia
• Troca de ferramentas no meio do projeto
– Vou usar a nova versão de F, pois tem mais recursos …
• Falta de controle sobre o código-fonte
– Vamos trabalhar em paralelo no módulo M (único arquivo) para ganharmos tempo …
Projeto: Definição PMI
• Um esfoço temporário realizado para criar um produto ou serviço único
• Características dos projetos:
– Prazo limitado;
– Recursos limitados e definidos a priori;
– Data estipulada para conclusão;
– Resultado diferente do que é produzido na rotina
da organização;
Gerenciamento de Projetos de
Software
• Está relacionado às atividades envolvidas em assegurar que o software será entregue:
– Dentro do prazo definido no cronograma;
– De acordo com os requisitos das organizações que desenvolvem e adquirem o software.
• Gerenciamento de projeto é necessário porque o desenvolvimento de software está sempre sujeito a restrições de orçamento e de cronograma
Distinções de Gerenciamento de
Software
• O produto é intangível;
• O produto é flexível;
• A engenharia de software não é reconhecida
como uma disciplina da engenharia, nem possui o
mesmo status da engenharia mecânica, elétrica,
etc.
• O processo de desenvolvimento de software não
é padronizado;
Atividades de Gerenciamento
• Elaboração de proposta.
• Planejamento
e
desenvolvimento
de
cronograma do projeto.
• Estimativa de custo do projeto.
• Monitoração e revisões de projeto.
Ciclo de Vida
• Delimita início e fim de um projeto
• Controla administração do projeto
• Define
Por que Planejar?
• Criar propostas que sejam
– Econômicamente viáveis e
– Realizadas com recursos financeiros pré-estabelecidos
• E que estejam de acordo com as necessidades
requisitadas
Planejamento de Projetos
• É, provavelmente, a atividade de gerenciamento
de projeto que toma mais tempo.
• É uma atividade contínua que vai do conceito
inicial até a entrega do sistema.
• Os planos são regularmente revisados, à medida
que informações novas se tornam disponíveis.
• Vários tipos diferentes de plano podem ser
desenvolvidos para apoiar o plano principal
– Este último é particularmente focado no cronograma
e no orçamento do projeto
“Processo” de Planejamento de Projeto
• Isso é apenas uma idéia geral. Na prática, as coisas são mais complicadas
Planejamento e Estimativa
• Registre suas estimativas para comparar com os
resultados reais no final do projeto
• Planejamento continua durante desenvolvimento e
manutenção
– Planejamento inicial não é suficiente
– Planejamento detalhado só ocorre após a especificação de requisitos
Estimativa de Esforço
• Há várias técnicas para estimar o esforço (tamanho) exigido no desenvolvimento de um produto de software
O que é um plano?
• Documento que define o trabalho que e como deve ser
feito
– Com uma estimativa de tempo e recursos exigidos, e um contexto para gerenciamento de controle e revisão, para cada marco
– Servir de benchmark para comparar com projetos anteriores, quando documentado apropriadamente
O plano do Projeto
• O plano de projeto estabelece:
– Os recursos disponíveis para o projeto; – A estrutura analítica de trabalho;
– Atividades (incluindo tempo necessário) – Recursos
– Alocação de recursos a atividades – Ordenação das atividades
Estrutura Básica de um Plano
• Introdução
• Organização de projeto
• Análise de riscos
• Requisitos de recursos de hardware e de
software
• Estrutura analítica
• Cronograma de projeto
• Mecanismos de monitoramento e elaboração de
relatórios
Organização de Atividades
• Em um projeto, as atividades devem ser organizadas para produzir saídas tangíveis
• Marcos são o ponto final de uma atividade de processo • Produtos a serem entregues são resultados do projetos
– Disponibilizados para os clientes.
• O processo cascata permite a definição direta dos marcos de progresso.
Desenvolvimento do Cronograma do
projeto
• Dividir o projeto em tarefas e estimar tempo e
recursos necessários para completar cada tarefa.
• Organizar tarefas simultâneas para fazer uso
otimizado da força de trabalho.
• Minimizar as dependências de tarefas para evitar
atrasos causados pelo fato de uma tarefa ter de
aguardar a finalização de outra.
• É dependente da intuição e experiência dos
gerentes de projeto.
Processo de desenvolvimento
de
Problemas de desenvolvimento de
cronograma
• É difícil estimar dificuldades e problemas
– Logo, é difícil estimar o tempo total de uma atividade
• A produtividade não é proporcional ao número de pessoas que trabalham em uma tarefa.
• A inclusão de pessoas em um projeto atrasado o atrasa ainda mais devido aos overheads de comunicação.
• O inesperado sempre ocorre. Deve-se sempre considerar a contingência no planejamento.
Recursos
• Pessoas
– Ricardo, Larissa, João, Márcia e Alberto (com
Especialidades)
• Software
– JBuilder, .NET (quantidade e versões)
• Hardware
Tarefas
• Dividir para conquistar
• Normalmente atribuída a uma pessoa
• Estimativa de tempo/esforço precisa
• Pode-se associar especialidade(s)
necessária(s) para sua realização
• Podem gerar (parte de) resultado desejável
(milestone)
Exemplos de Tarefas
• Entrevistar cliente CL
• Fazer uma Reunião
• Projetar a GUI G
i• Criar o relatório R
• Atualizar o site
Por que Gerenciar?
• Para atingir objetivos e produzir resultados
– Concentrar responsabilidade e autoridade para
atingir objetivos
– Coordenar e integrar todas as atividades para
chegar aos resultados
Objetivos do Gerenciamento
Custo Desempenho Tempo Objetivo: • Limite de orçamento • Prazo de entrega • Desempenho AlmejadoQualidades de Gerente
• Liderança
• Comunicação
• Resolver problemas
• Negociação
• Influenciar a organização
• Mentor
Diagramas de barras e redes de
atividades
• São notações gráficas usadas para ilustrar o cronograma de projeto.
• Mostram a quebra do projeto em tarefas que não devem ser muito pequenas. Elas devem levar aproximadamente uma ou duas semanas.
– Depende da duração do projeto
• Redes de atividades mostram as dependências entre as tarefas e o caminho crítico.
• Os diagramas de barras mostram o cronograma em contraste com tempo do calendário.
Tarefas: Duração e Dependências
T arefa D u r a ção ( di a s) D e p e n d ê n c ia s T 1 8 T 2 1 5 T 3 1 5 T 1 ( M 1 ) T 4 1 0 T 5 1 0 T 2 , T 4 ( M 2 ) T 6 5 T 1 , T 2 ( M 3 ) T 7 2 0 T 1 ( M 1 ) T 8 2 5 T 4 ( M 5 ) T 9 1 5 T 3 , T 6 ( M 4 ) T 1 0 1 5 T 5 , T 7 ( M 7 ) T 1 1 7 T 9 ( M 6 ) T 1 2 1 0 T 1 1 ( M 8)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 M4Alocação de Pessoal
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 JimTempo de Desenvolvimento
• A partir da rede de atividades
– Grafo interligando tarefas com tempo • Determinar o caminho crítico
– O caminho que leva mais tempo para concluir
• Gerente deve dar especial atenção às tarefas contidas no caminho crítico
Acompanhamento das Tarefas
Data Início Fim Interrup. Tarefa
20/0
4
08:00 15:30 30min
T1
21/04 08:00 14:00 30min
T2
25/0
4
15:00 18:00 10min
T3
01/05 08:00 18:00 1hora
T4
Ferramenta para Acompanhamento
• Uma vez definidas as atividades e estimativas
de tempo para suas realizações, pode-se usar
uma ferramentas para o acompanhamento
(ex: a ferramenta web XPlanner
Custo do Projeto
• Recursos humanos (R$/hora) • Instalações (fone, luz, etc.)
• Reuniões (tempo, pessoas, etc.) • Material de escritório/informática • Etc.
Riscos
• Identificação de Riscos
– Identificar riscos de projeto, produto e negócio
• Análise de Riscos
– Avalia as conseqüências dos riscos
• Planejamento de Riscos
– Alternativas para evitar ou minimizar seus efeitos
• Monitoramento de Riscos
O processo de gerenciamento de
riscos
• Identificação de riscos
– Identifica os riscos de projeto, de produto e de negócio;
• Análise de riscos
– Avalia a probabilidade e as conseqüências desses riscos;
• Planejamento de riscos
– Elabora planos para evitar ou minimizar os efeitos do riscos;
• Monitoração de riscos
Identificação de Riscos
• Riscos com Tecnologia
• Riscos com Pessoal
• Riscos Organizacionais
• Riscos nos Requisitos
Análise de riscos
• Avaliar a probabilidade e a seriedade de cada risco.
• A probabilidade pode ser muito baixa, baixa, média, alta e muito alta.
• Os efeitos de risco poderiam ser catastróficos, sérios, toleráveis ou insignificantes.
Planejamento de Riscos
• Para cada risco, elaborar estratégia para gerenciá-lo
– Estratégias para Evitar
• A probabilidade de ocorrência é reduzida
– Estratégias para Minimizar
• O efeito do risco no projeto ou produto é reduzido
– Planos de Contingência
Monitoramento de Riscos
• Avaliar cada risco periodicamente para determinar se
está mais ou menos provável de ocorrer
• Avaliar os efeitos pois podem mudar
• Cada risco crítico deve ser discutido em reuniões
gerenciais de progresso do projeto
Monitoração de riscos
• Avaliar, regularmente, cada um dos riscos identificados para decidir se está ou não se tornando menos ou mais provável. • Avaliar também se os efeitos do risco mudaram.
• Cada risco-chave deve ser discutido nas reuniões de gerenciamento de progresso.
