PlanejamentoGerenciamento Alexandre Mota acmcin ufpe br 1 Objetivos
Planejamento/Gerenciamento Alexandre Mota (acm@cin. ufpe. br) 1
Objetivos n n n Evitar os erros clássicos Que é projeto? Ciclo de vida de projetos Elementos essenciais Objetivos gerais do planejamento e gerenciamento do projeto de software 2
Erros Clássicos Desenvolvimento de Software é uma atividade complicada. . . 3
Pessoas n Motivação incoerente n n Pessoal fraco n n Seleção apressada ao invés de conveniente … Pessoal problemático n n Esforço do pessoal e chefe de férias … Uma pessoa pode desconcentrar uma equipe … Heroísmo n Posso fazer tudo, não preciso da equipe … 4
Pessoas n Mais pessoas no final do projeto n n Escritórios barulhentos n n Em pequeno incêndio, jogue gasolina … Meu nível de concentração é excelente … Atrito entre desenvolvedores e clientes n Se você não adicionar isso, não quero mais … 5
Pessoas n Expectativas irreais n n Falta de interação com o usuário n n Vamos terminar o projeto em 6 meses … Isso é ambíguo …, mas vamos decidir sozinhos … Crença cega n Essa parte do sistema é muito simples, em 1 ou 2 dias removemos todos os erros … 6
Processo n Cronogramas altamente otimistas n n Gerenciamento de riscos insuficiente n n Ganhamos tempo na análise de requisitos e no projeto … Se o risco A se concretizar, resolvemos … Falha de contratos n Com o módulo M, a ser criado pela empresa E, vamos melhorar nosso cronograma … 7
Processo n Planejamento insuficiente n n Esse sistema é simples, não há o que planejar … Abandono de plano sob pressão n Devido ao cronograma, vamos codificar já da especificação de requisitos e não vamos testar … 8
Processo n Garantia de qualidade prejudicada n n Controle de gerenciamento insuficiente n n Só precisamos fazer os testes a partir da GUI … O que já fizemos? Não sei, mas sem problema … Sem estimativas para tarefas necessárias n Não precisamos registrar o tempo para tarefa T … 9
Processo n Planejamento para controlar depois n n Fizemos em 3 meses, o que planejamos fazer em 2, mas depois nós ganhamos tempo … Programação sem padronização n Vou codificar de qualquer jeito; ganho tempo … 10
Produto n Requisitos demais n n Desenvolvedor exagerado n n Sei que o usuário não pediu, mas vamos melhorar a performance do sistema … Sei que o sistema não precisa e que não domino a tecnologia, mas vou usar o recurso R … Desenvolvimento orientado a pesquisa n Sei que vou desenvolver funcionalidade F, estado-da-arte, mas minha estimativa é razoável … 11
Tecnologia n Síndrome da bala de prata n n Vou usar o gerador de GUIs e não terei problemas quanto ao desenvolvimento das GUIs … Estimativa otimista com novas ferramentas ou métodos n Vou usar ferramenta F, no lugar de G, daí vou ganhar tempo … 12
Tecnologia n Troca de ferramentas no meio do projeto n n Vou usar a nova versão de F, pois tem mais recursos … Falta de controle sobre o códigofonte n Vamos trabalhar em paralelo no módulo M (único arquivo), para ganharmos tempo … 13
Projeto: Definição PMI n Um empreendimento temporário realizado para criar um produto ou serviço único 14
Ciclo de Vida n n n Delimitar início e fim de um projeto Controlar administração do projeto Estudo de viabilidade n n Uma primeira fase do projeto? Define n Trabalho a ser feito X envolvidos 15
Por que Planejar? n Criar propostas que sejam n n 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 16
Planejando um projeto de software n n n 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, criamse subprojetos menores e estima-os separadamente Baseie suas estimativas com dados históricos de projetos semelhantes 17
Planejamento e Estimativa n n Registre suas estimativas para comparar com os resultados reais no final do projeto Planejamento continua durante desenvolvimento e manutenção n n Planejamento inicial não é suficiente Planejamento detalhado mais cedo possível só ocorre após a especificação de requisitos 18
Planejamento e o Processo de Software 19
Estimativa de Esforço n n 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
Classificando Atores n Ator Simples n n Sistema reusado onde há uma API bem definida para a interação Peso 1 21
Classificando Atores n Ator Médio n n Sistema reusado onde a interação envolve um protocolo, por exemplo TCP/IP Peso 2 22
Classificando Atores n Ator Complexo n n Ser humano que necessita de uma GUI ou Web page Peso 3 23
Classificando Casos de Uso n Casos de uso simples n n n Se quantidade de passos no fluxo for no máximo 3, ou Necessitar de até 5 classes de análise Peso 1 24
Classificando Casos de Uso n Casos de uso médio n n n Se quantidade de passos no fluxo estiver entre 4 e 7 (inclusive), ou Necessitar de 5 a 10 classes de análise Peso 2 25
Classificando Casos de Uso n Casos de uso complexo n n n Se quantidade de passos no fluxo for maior que 7, ou Necessitar mais de 10 classes de análise Peso 1 26
Fatores Técnicos Fator Descrição Peso T 1 Sistema Distribuído 2 Tempo de resposta 1 T 12 Acesso direto 1 T 13 Treinamento Especial Requerido 1 . . . 27
Fatores Ambientais Fator Descrição Peso F 1 Familiar com modelo Experiência na Aplicação 1. 5 Equipe 1/2 expediente Ling. prog. -1 F 2 0. 5 . . . F 7 F 8 -1 28
Calculando os UCP´s n n Atores (UAW) Casos de uso (UUCW) n n 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
Convertendo UCP em Horas n Karner n n n Portanto, um projeto com n n 1 UCP => 20 h Este valor deve estar entre 15 e 30 h e deve ser ajustado de acordo com histórico da empresa UCP = 1. 07 * 0. 62 * 264 = 175. 14 Demanda 175. 14*20 h = +/-3503 h 30
Ferramenta para Calcular n EZEstimate n http: //www. openrage. com/main/ezestima te_full. htm 31
O que é um plano? n Documento que define o trabalho que e como deve ser feito n n 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 n Melhorando erros em estimativas e sua precisão 32
Estrutura Básica de um Plano n n n Introdução Organização do Projeto Requisitos com Recursos (Pessoas, SW, HW) Detalhamento das Tarefas Análise de Riscos Cronograma do Projeto n n Milestones/Deliverables Atribuição de tarefas a pessoas Estimativa de tempo Custo do Projeto 33
Recursos n Pessoas n Ricardo, Larissa, João, Márcia e Alberto n n Software n n Especialidades JBuilder, . NET Hardware n Laptop, PC, PDA 34
Tarefas n n n 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
Exemplos de Tarefas n n n 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
Por que Gerenciar? n Para atingir objetivos e produzir resultados n n Concentrar responsabilidade e autoridade para atingir objetivos Coordenar e integrar todas as atividades para chegar aos resultados 37
Objetivos do Gerenciamento Custo Objetivo: • Limite de orçamento • Prazo de entrega • Desempenho Almejado Tempo Desempenho 38
Qualidades de Gerente n n n n Liderança Comunicação Resolver problemas Negociação Influenciar a organização Mentor Especialista técnico e em processo 39
Gerenciamento das Tarefas n Milestones n n Ponto final de uma atividade do processo de software (um marco no cronograma) Deliverables n Resultado do projeto a ser entregue ao cliente. Usualmente entregue ao final de uma fase. 40
Tarefas: Duração e Dependências Tarefa T 1 T 2 T 3 T 4 T 5 T 6 T 7 T 8 T 9 T 10 T 11 T 12 Duração (dias) 8 15 15 10 10 5 20 25 15 15 7 10 Dependências T 1 (M 1) T 2, T 4 (M 2) T 1, T 2 (M 3) T 1 (M 1) T 4 (M 5) T 3, T 6 (M 4) T 5, T 7 (M 7) T 9 (M 6) T 11 (M 8) 41
Rede de Atividades 42
Alocação de Pessoal 43
Tempo de Desenvolvimento n A partir da rede de atividades n n Determinar o caminho crítico n n n Grafo interligando tarefas com tempo 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
Acompanhamento das Tarefas Data Início Fim Interrup. Tarefa 20/04 08: 00 15: 30 30 min T 1 21/04 08: 00 14: 00 30 min T 2 25/04 15: 00 18: 00 10 min T 3 01/05 08: 00 1 hora T 4 ATENÇÃO: Existe uma tabela semelhante com tempo estimado 45
Ferramenta para Acompanhamento n n 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
Custo do Projeto n n n Recursos humanos (R$/hora) Instalações (fone, luz, etc. ) Reuniões (tempo, pessoas, etc. ) Material de escritório/informática Etc. 47
Riscos n Identificação de Riscos n n Análise de Riscos n n Avalia as conseqüências dos riscos Planejamento de Riscos n n Identificar riscos de projeto, produto e negócio Alternativas para evitar ou minimizar seus efeitos Monitoramento de Riscos n Acompanhar os riscos durante o projeto 48
Processo de Gerenciamento de Riscos 49
Identificação de Riscos n n n Riscos com Tecnologia Riscos com Pessoal Riscos Organizacionais Riscos nos Requisitos Riscos nas Estimativas 50
Principais Áreas de Riscos n n n Pessoal Cronograma e Custo Funcionalidade do Sistema n n n Estabilidade dos Requisitos n n n Falta de entendimento da aplicação Análise de requisitos inadequada Cliente tenta alterar requisitos o tempo todo Qualidade de Componentes Externos 51 DIFICULDADE EM ANTECIPAR TUDO!!!
Análise de Riscos n n n 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
Planejamento de Riscos n Para cada risco, elaborar estratégia para gerenciá-lo n Estratégias para Evitar n n Estratégias para Minimizar n n A probabilidade de ocorrência é reduzida O efeito do risco no projeto ou produto é reduzida Planos de Contingência n Se o risco ocorrer, o que devemos fazer? 53
Monitoramento de Riscos n n n 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
Identificação de Riscos Risco Probabilidade Efeitos Pessoal doente Moderada Sério Tamanho do software desconhecido. . . Alta Tolerável Pessoal qualificado não disponível Alta … … Catastrófico 55
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
Bibliografia n n n Sommerville, I. Software Engineering Humphrey, W. A Discipline for Software Engineering Mc. Connel, S. Rapid Development 57
- Slides: 57