1/57 Planejamento/Gerenciamento Alexandre Mota ([email protected])
Transcript of 1/57 Planejamento/Gerenciamento Alexandre Mota ([email protected])
2/57
Objetivos Evitar os erros clássicos O que é projeto? Ciclo de vida de projetos Elementos essenciais Objetivos gerais do planejamento e
gerenciamento do projeto de software
3/57
Erros Clássicos
Desenvolvimento de Software é uma atividade complicada, então
evite ...
4/57
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 Posso fazer tudo, não preciso da equipe …
5/57
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 Se você não adicionar isso, não quero
mais …
6/57
Pessoas Expectativas irreais
Vamos terminar o projeto em 6 meses … Falta de interação com o usuário
Isso é ambíguo …, mas vamos decidir sozinhos …
Crença cega Essa parte do sistema é muito simples, em
1 ou 2 dias removemos todos os erros …
7/57
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 …
8/57
Processo Planejamento insuficiente
Esse sistema é simples, não há o que planejar …
Abandono de plano sob pressão Devido ao cronograma, vamos
codificar logo depois da especificação de requisitos e não vamos testar …
9/57
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 Não precisamos registrar o tempo para tarefa
T
10/57
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 Vou codificar de qualquer jeito; ganho
tempo …
11/57
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 …
12/57
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 Vou usar ferramenta F, no lugar de G,
daí vou ganhar tempo …
13/57
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 …
14/57
Projeto: Definição PMI Um empreendimento temporário
realizado para criar um produto ou serviço único
15/57
Ciclo de Vida Delimitar início e fim de um projeto Controlar administração do projeto Estudo de viabilidade
Uma primeira fase do projeto? Define
Trabalho a ser feito X envolvidos
16/57
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 Representar precisamente o que
se pode fazer
17/57
Planejando um projeto de software Inicie com uma declaração
explícita do trabalho a ser feito e verifique se corresponde ao que o cliente espera
Em projetos médios e grandes, criam-se subprojetos menores e estima-os separadamente
Baseie suas estimativas em dados históricos de projetos semelhantes
18/57
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
19/57
Estimativa de Esforço Há várias técnicas para estimar o
esforço (tamanho) exigido no desenvolvimento de um produto de software
Uma das mais recentes é a baseada em casos de uso
20/57
Classificando Atores Ator Simples
Sistema onde há uma API bem definida para a interação
Peso 1
21/57
Classificando Atores Ator Médio
Sistema onde a interação envolve um protocolo, por exemplo TCP/IP
Peso 2
22/57
Classificando Atores Ator Complexo
Ser humano que necessita de uma GUI ou Web page
Peso 3
23/57
Classificando Casos de Uso Caso de uso simples
Se a quantidade de passos no fluxo for no máximo 3, ou
Necessitar de até 5 classes de análise Peso 5
24/57
Classificando Casos de Uso Caso de uso médio
Se a quantidade de passos no fluxo estiver entre 4 e 7 (inclusive), ou
Necessitar de 5 a 10 classes de análise
Peso 10
25/57
Classificando Casos de Uso Caso de uso complexo
Se a quantidade de passos no fluxo for maior que 7, ou
Necessitar mais de 10 classes de análise
Peso 15
26/57
Fatores Técnicos
Fator Descrição Peso
T1 Sistema Distribuído
2
T2 Tempo de resposta crítico
1
...
T13 Treinamento Especial Requerido
1
27/57
Fatores Ambientais
Fator Descrição Peso
F1 Familiar com modelo
1.5
F2 Experiência na Aplicação
0.5
...
F7 Equipe em 1/2 expediente
-1
F8 Ling. prog. -1
28/57
Calculando os UCP´s Atores (UAW) Casos de uso (UUCW)
UUCP = UAW + UUCW Fatores técnicos (TCF=0.6+0.01*TF) Fatores ambientais (EF=1.4-0.03*EF) UCP = UUCP * TCF * EF
29/57
Convertendo UCP em Horas Karner
1 UCP => 20 h Este valor deve estar entre 15 e 30h e
deve ser ajustado de acordo com histórico da empresa
Portanto, um projeto com UCP = 1.07 * 0.62 * 264 = 175.14
Demanda 175.14*20h = +/-3503h
30/57
Ferramenta para Calcular Estimativas EZEstimate
http://www.openrage.com/main/ezestimate_full.htm
31/57
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
Melhorando erros em estimativas e sua precisão
32/57
Estrutura Básica de um Plano Introdução Organização do Projeto Requisitos com Recursos (Pessoas, SW,
HW) Detalhamento das Tarefas Análise de Riscos Cronograma do Projeto
Milestones/Deliverables Atribuição de tarefas a pessoas Estimativa de tempo
Custo do Projeto
33/57
Recursos Pessoas
Ricardo, Larissa, João, Márcia e Alberto (com Especialidades)
Software JBuilder, .NET (quantidade e versões)
Hardware Laptop, PC, PDA (quantidade e
modelos)
34/57
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)
35/57
Exemplos de Tarefas Entrevistar cliente CL Reunião Projetar a GUI Gi
Criar o relatório R Atualizar o site Testar método M da classe C
36/57
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
37/57
Objetivos do Gerenciamento
Custo
Desempenho
Tempo
Objetivo:• Limite de orçamento• Prazo de entrega• Desempenho Almejado
38/57
Qualidades de Gerente Liderança Comunicação Resolver problemas Negociação Influenciar a organização Mentor Especialista técnico e em processo
39/57
Gerenciamento das Tarefas Milestones
Ponto final de uma atividade do processo de software (um marco no cronograma)
Deliverables Resultado do projeto a ser entregue
ao cliente. Usualmente entregue ao final de uma fase.
40/57
Tarefas: Duração e Dependências
Tarefa Duração (dias) DependênciasT1 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)
41/57
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
42/57
Alocação de Pessoal4/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
Jim
43/57
Tempo 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
É crucial ter folgas no caminho crítico
44/57
Acompanhamento das TarefasData Início Fim Interrup. Tarefa
20/04 08:00 15:30 30min T1
21/04 08:00 14:00 30min T2
25/04 15:00 18:00 10min T3
01/05 08:00 18:00 1hora T4
ATENÇÃO: Existe uma tabela semelhante com tempo estimado
45/57
Ferramenta para Acompanhamento
Uma vez definidas as atividades e estimativas de tempo para suas realizações
Pode-se usar a ferramenta web XPlanner para o acompanhamento (http://www.xplanner.org/)
46/57
Custo do Projeto Recursos humanos (R$/hora) Instalações (fone, luz, etc.) Reuniões (tempo, pessoas, etc.) Material de escritório/informática Etc.
47/57
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 Acompanhar os riscos durante o projeto
48/57
Processo de Gerenciamento de Riscos
Risk avoidanceand contingency
plans
Risk planning
Prioritised risklist
Risk analysis
List of potentialrisks
Riskidentification
Riskassessment
Riskmonitoring
49/57
Identificação de Riscos Riscos com Tecnologia Riscos com Pessoal Riscos Organizacionais Riscos nos Requisitos Riscos nas Estimativas
50/57
Principais Áreas de Riscos Pessoal Cronograma e Custo Funcionalidade do Sistema
Falta de entendimento da aplicação Análise de requisitos inadequada
Estabilidade dos Requisitos Cliente tenta alterar requisitos o tempo todo
Qualidade de Componentes Externos DIFICULDADE EM ANTECIPAR TUDO!!!
51/57
Análise de Riscos Avaliar a probabilidade e seriedade
de cada risco A probabilidade pode variar de
muito baixo (0-20%), baixo (20-40%), médio (40-60%), alto (60-80%) e muito alta (80-100%)
Os efeitos dos riscos podem ser catastróficos, sérios, toleráveis ou insignificantes
52/57
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 Se o risco ocorrer, o que devemos fazer?
53/57
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
54/57
Identificação de RiscosRisco Probabilida
deEfeitos
Pessoal doente Moderada Sério
Tamanho do software desconhecido
Alta Tolerável
... … …
Pessoal qualificado não disponível
Alta Catastrófico
55/57
Estratégias de Gerenciamento
Risco Estratégia
Pessoal doente
Reorganizar equipe para ter sobreposição de pessoas/trabalho
Recrutamento Alertar cliente sobre possível atraso
… …
Mudança nos requisitos
Analisar rastreamento entre requisitos para determinar impacto
56/57
Bibliografia Sommerville, I. Software
Engineering Humphrey, W. A Discipline for
Software Engineering McConnel, S. Rapid Development