Upload
internet
View
104
Download
1
Embed Size (px)
Citation preview
2
Objetivos Evitar os erros clássicos Que é projeto? Ciclo de vida de projetos Elementos essenciais Objetivos gerais do planejamento e
gerenciamento do projeto de software
3
Erros Clássicos
Desenvolvimento de Software é uma atividade complicada ...
4
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
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
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
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
Processo Planejamento insuficiente
Esse sistema é simples, não há o que planejar …
Abandono de plano sob pressão Devido ao cronograma, vamos
codificar já da especificação de requisitos e não vamos testar …
9
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
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
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,
estado-da-arte, mas minha estimativa é razoável …
12
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
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
Projeto: Definição PMI Um empreendimento temporário
realizado para criar um produto ou serviço único
15
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
Por que Planejar? Criar propostas que sejam
Econômicas e Realizadas com recursos financeiros
pré-estabelecidos E que estejam de acordo com as
necessidades requisitadas Representar precisamente o que
se pode fazer
17
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 com dados históricos de projetos semelhantes
18
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 mais cedo
possível só ocorre após a especificação de requisitos
19
Planejamento e o Processo de Software
20
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
21
Classificando Atores Ator Simples
Sistema reusado onde há uma API bem definida para a interação
Peso 1
22
Classificando Atores Ator Médio
Sistema reusado onde a interação envolve um protocolo, por exemplo TCP/IP
Peso 2
23
Classificando Atores Ator Complexo
Ser humano que necessita de uma GUI ou Web page
Peso 3
24
Classificando Casos de Uso Casos de uso simples
Se quantidade de passos no fluxo for no máximo 3, ou
Necessitar de até 5 classes de análise Peso 1
25
Classificando Casos de Uso Casos de uso médio
Se quantidade de passos no fluxo estiver entre 4 e 7 (inclusive), ou
Necessitar de 5 a 10 classes de análise
Peso 2
26
Classificando Casos de Uso Casos de uso complexo
Se quantidade de passos no fluxo for maior que 7, ou
Necessitar mais de 10 classes de análise
Peso 1
27
Fatores Técnicos
Fator Descrição Peso
T1 Sistema Distribuído
2
T2 Tempo de resposta
1
...
T12 Acesso direto 1
T13 Treinamento Especial Requerido
1
28
Fatores Ambientais
Fator Descrição Peso
F1 Familiar com modelo
1.5
F2 Experiência na Aplicação
0.5
...
F7 Equipe 1/2 expediente
-1
F8 Ling. prog. -1
29
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
30
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
31
Ferramenta para Calcular EZEstimate
http://www.openrage.com/main/ezestimate_full.htm
32
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 maior tarefa
Servir de benchmark para comparar com projetos anteriores, quando documentado apropriadamente Melhorando erros em estimativas e sua
precisão
33
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
34
Recursos Pessoas
Ricardo, Larissa, João, Márcia e Alberto
Especialidades
Software JBuilder, .NET
Hardware Laptop, PC, PDA
35
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)
36
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
37
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
38
Objetivos do Gerenciamento
Custo
Desempenho
Tempo
Objetivo:• Limite de orçamento• Prazo de entrega• Desempenho Almejado
39
Qualidades de Gerente Liderança Comunicação Resolver problemas Negociação Influenciar a organização Mentor Especialista técnico e em processo
40
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.
41
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)
42
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
43
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
44
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
45
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
46
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/)
47
Custo do Projeto Recursos humanos (R$/hora) Instalações (fone, luz, etc.) Reuniões (tempo, pessoas, etc.) Material de escritório/informática Etc.
48
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
49
Processo de Gerenciamento de Riscos
Risk avoidanceand contingency
plans
Risk planning
Prioritised risklist
Risk analysis
List of potentialrisks
Riskidentification
Riskassessment
Riskmonitoring
50
Identificação de Riscos Riscos com Tecnologia Riscos com Pessoal Riscos Organizacionais Riscos nos Requisitos Riscos nas Estimativas
51
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!!!
52
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
53
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 é reduzida
Planos de Contingência Se o risco ocorrer, o que devemos fazer?
54
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
55
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
56
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
57
Bibliografia Sommerville, I. Software
Engineering Humphrey, W. A Discipline for
Software Engineering McConnel, S. Rapid Development