1 Planejamento/Gerenciamento Alexandre Mota (acm@cin.ufpe.br)

1

Planejamento/Gerenciamento

Alexandre Mota (acm@cin.ufpe.br)

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