Aula 05 - Planejamento e Estimativas

Gerência de Projetos

Planejamento e Estimativas

Marcelo Marinho

Introdução

• O gerenciamento de projetos de software

começa com uma série de atividades

chamadas coletivamente de planejamento de

projetos;

• Antes de iniciar o projeto, a equipe de

software deverá fazer uma etimativa do

trabalho, dos recursos que serão necessários e

o tempo para sua conclusão;

Introdução

• Antes do projeto começar, o gerente e a equipe precisam estimar:

– O trabalho a ser feito, – Os recursos necessários,

– O tempo que vai decorrer do início ao fim.

• A partir destas estimativas, é possível estabelecer um cronograma que defina:

– as tarefas e marcos da engenharia de software, – quem é o responsável por conduzir cada tarefa, – as dependências intertarefas.

• Vale à pena planejar:

– O tempo de planejar é menor do que o tempo perdio em refazer

Introdução

Estimativas apoiam atividades de gestão de projetos e permitem

– Verificação da viabilidade do projeto;

– Elaboração de propostas técnicas e

comerciais;

– Elaboração de planos e cronogramas

detalhados;

– Acompanhamento de projetos

O “Processo” usual de Estimativas de Software

Estimativa, meta e objetivo de negócio

Risco do Projeto

Cone da Incerteza

Problemas que afetam o processo de

estimativa

• Fatores Humanos, técnicos, ambientais e políticos; • O Software é único;

• Nunca se tem o mesmo projeto ou produto de software duas vezes;

• O desenvolvimento de software é uma disciplina baseada no conhecimento que frequentemente requer inovação e experimentação;

• A tecnologia muda rapidamente;

Porque Estimar?

• Para planejar: Quando temos quarquer coisa pronta?

• Para agendar: Em qual ordem devemos fazer as coisas?

• Para contratar: Nós precisamos de mais pessoas para trabalhar?

• Para colocar preço: Quanto isso vai custar?

• Para guiar investimento: Estamos fazendo coisas que valem a pena?

Observações sobre estimativas

• Sempre que fazemos estimativas, devemos aceitar um grau de incerteza como inevitável.

– Abordagens modernas assumem que as estimativas serão revistas à medida que o projeto avança.

• A disponibilidade de informação histórica tem forte influência no risco da estimativa.

– Experiência anterior ajuda imensamente.

– Métricas de software de projetos anteriores ajudam na geração de estimativas quantitativas.

As Atividades de Estimativas

• O processo de estimativa de software envolve quatro atividades:

– Estimar o tamanho do produto a ser desenvolvido; – Estimar o esforço na execução do projeto;

– Estimar o prazo (duração) do projeto; – Estimar o custo do projeto

Estimativa do Tamanho do Software

• Significa a quantidade de trabalho a ser

executado no desenvolvimento do projeto em

uma unidade de medida;

• Cada projeto pode ser estimado de acordo com

seu tamanho físico (ex; através da especificação

de requisitos, análise,projeto e código)

• Quanto maior for o conhecimento e

detalhamento das informações sobre o projeto

melhor serão os subsídios para elaboração da

estimativa de tamanho.

Estimativa de Esfoço

• É calculado com base no processo de desenvolvimento;

• Deve ser considerado:

– Elaboração de documentos;

– Projeto do produto a ser entregue; – Implementação de protótipos;

– Revisão e testes do código;

Estimativa de Prazo

• Quantas pessoas estarão envolvidas no

projeto?

• Que atividades (WBS) serão executadas?

• Quando as atividade iniciaram e irão finalizar?

• Tanto dados históricos quanto modelos de

dados na indústria podem ser usados para

predizer o número de pessoas necessárias

para o projeto

Estimativa de Custo

• O custo é frequentemente associado a

homem-mês ou homem-hora;

• É preciso levar em consideração também:

– Custo de hardware; – Infra-estrutura

– Viagens com reuniões; – Testes nos clientes;

– Contas telefônicas (ligações de longa distância, vídeo-conferência, etc);

– Treinamentos; – Entre outros.

Um Processo “correto” de estimativas

Plano Detalhado do Projeto

 Identificar as atividades do projeto

 Estimar a duração das atividades

 Determinar os requisitos de recursos

 Construir a rede do projeto

 Analisar a rede do projeto

 Preparar a proposta do projeto

 Discutir, aprovar...

Definição da WBS

• Decomposição do projeto em partes menores de trabalho e, em seguida, as decompondo novamente até chegar a um nível de detalhe que combine com as necessidades de planejamento e programação das ações (tarefas) a serem realizadas pela equipe do projeto.

• É uma estrutura hierárquica, com a subdivisão das tarefas por blocos cada vez menores, trazendo para um estágio operacional.

Definição da WBS

OBJETIVO DO PROJETO

ETAPA 1 ETAPA 2 ETAPA 3

SUB-ETAPA 2.1 SUB-ETAPA 2.2 SUB-ETAPA 2.3

TAREFA 2.2.1 TAREFA 2.2.2 TAREFA 2.2.3 TAREFA 2.2.4

Definição da WBS

• Seis critérios para testar se WBS está bem

definida:

1. Possibilidade de medir o estado ou grau de compleição de cada atividade:

quantidade de recursos consumidos? produtos intermediários?

Definição da WBS

Definição da WBS

Definição da WBS

4. Facilidade de estimar duração e custo da atividade

Definição da WBS

Definição da WBS

6. A aplicação de um mesmo recurso em tarefas diferentes, deve ser feita de tal forma a evitar uso concorrente (conflitos de alocação de recursos)

EXEMPLO DE WBS: CONSTRUÇÃO DE UMA CASA PREPARO DO LOCAL FUNDAÇÕES ESTRUTURA INSTALAÇÕES PAREDES TETOS ACABAMENTOS

EXEMPLO DE WBS: CONSTRUÇÃO DE UMA CASA PREPARO DO LOCAL FAZER LAY-OUT FAZER A CERCA FAZER A ESCAVAÇÃO

PROJETO DE SISTEMA

DEFINIÇÃO PROJETO IMPLEMENTAÇÃO

OBJETIVO REQUISITOS ESCOLHA DA METODOLOGIA APROVAÇÃO FUNCIONAL DETALHADO PROGRAMAÇÃO INSTALAÇÃO OPERAÇÃO

Definição da WBS

• Objetivo:

– requisitos do projeto

– estabelecer objetivos

– identificar problemas principais e

necessidades

– siga a metodologia ...

Definição da WBS

• Requisitos:

– obter a documentação atual

– definir novos requisitos

– estabelecer funcionalidades

Definição da WBS

Work Breakdown Structure

• Funcional:

– identificar informações, interfaces

– especificar entradas e saídas

– especificar pontos de auditoria e

controle

– especificar estrutura de dados e seus

fluxos

Definição da WBS

• Detalhado:

– preparar fluxos do processo

– especificar programas, produtos ...

– estabelecer plano de conversão

– treinamento de operadores

– aprovação

Definição da WBS

para um projeto de sistema

• Programação:

• deveria se abrir em

– codificar e fazer testes unitários

– documentar programas

– aprovação

Definição da WBS

para um projeto de sistema

• Instalação:

– testes:

• fazer plano de testes • criar dados de teste • fazer os testes – treinamento • treinamento da operação • treinamento de usuários – implantação do sistema – aprovação

Definição da WBS

para um projeto de sistema

• Operação:

• completar análise financeira

Definição da WBS

• A abertura da WBS no seu primeiro nível é geralmente feita e acordada entre os níveis mais altos da equipe do projeto e dos clientes

• A decomposição da WBS em níveis mais baixos é feita com a participação da equipe do projeto que conhece com maior detalhe as necessidades de detalhamento e que se responsabilizará por desenvolver o projeto - a ideia é seguir a metodologia eventualmente adotada na empresa.

Estimativas de duração das atividades

• Feita com a colaboração da equipe • Usa históricos da organização

• Dispõe de métricas

• Considera o tempo produtivo das pessoas da equipe - tempo produtivo não é tempo decorrido!

• Lembre da carga de gerência, reuniões, mudanças...

Estimativas de duração das atividades

• Causas de Variação na Estimativa da Duração das

Atividades:

– variação de perfil técnico dos integrantes da equipe

– eventos inesperados

– eficiência no aproveitamento do tempo de trabalho

Estimativas de duração das atividades

• Seis métodos de estimar a duração das

atividades:

– similaridade com outras atividades – dados históricos

– conselho de especialistas – técnica dos três pontos

– método de pontos de função

• para projetos de sistemas

Necessidades de Recursos

– método da quantidade total - podemos estabelecer com a pessoa que vai fazer a tarefa o prazo total.

– aplicável também a casos de terceirização: uma empresa fica encarregada de fazer uma determinada tarefa em um certo prazo estabelecido de comum acordo, quando de sua contratação.

– não são controladas as horas trabalhadas diariamente, mas o resultado final associado a seu prazo contratado.

Necessidades de Recursos

• Modos de definir recursos:

– método do perfil - este método é adotado quando se tem um recurso para fazer uma tarefa e este não pode ser utilizado todo o tempo, tem de ser utilizado dentro de um calendário específico.

– assim, sua alocação dependerá da adequação entre a duração da tarefa e a disponibilidade do recurso

Necessidades de Recursos

• Tipos de recursos: – pessoas

• matrizes de perfis técnicos - um recurso com várias habilidades

• categorias de perfis técnicos - as habilidades típicas de cada tipo de recurso

– instalações

– equipamentos – dinheiro

Construção da Rede do Projeto

• Aspectos importantes na construção da rede do projeto:

– relação de ordem entre as atividades - diagrama de precedências

– tipos de dependências entre as atividades: fim-início

início-início fim-fim

Construção da Rede do Projeto

• Aspectos importantes na construção da rede do projeto:

– restrições técnicas entre atividades - uma depende da conclusão ou de um resultado da outra;

– restrições gerenciais - não há recursos disponíveis para iniciar uma atividade antes de uma certa data

– dependências entre projetos

– restrições de datas - há necessidade de ter o sistema pronto e implantado, antes do ano terminar por razões fiscais, por ex.

Construção da Rede do Projeto

• Aspectos importantes na construção da rede do projeto:

– atividades que dependem de outras, mas que podem começar ou terminar a partir de um

certo ponto da execução da outra – retardo (lag)

(recuo ou avanço)

– problemas de prazo - necessidades de comprimir a rede ou de analisar pontos de engarrafamento.

Estimativas

• Independente da varíavel de estimativa utilizada,

é recomendável estimar um intervalo de valores;

• Estima-se:

– Valor Otimista – Sopt

– Valor mais provável – Sm – Valor pessimista – Spess

• Onde:

S = (Sopt+4Sm+Spess)/6

Wideband Delphi

• Estimativa por julgamento de especialistas

– Muitas cabeças pensam melhor que uma!

Estimativas de esforço para cada atividade da lista Lista detalhada de atividades do projeto, incluindo as atividades “de suporte” Pressupostos para as estimativas

Wideband Delphi - participantes

• Moderador

– Planeja e coordena as atividades do método

– Papel de facilitador – não deve influenciar os demais

• Gerente do projeto

– Recebe os resultados do método

• 2 a 4 outros estimadores

– Especialistas no problema que será estimado – Podem ser membros da equipe do projeto

Wideband Delphi – como funciona?

Wideband Delphi

Reunião inicial

• Garante que todos os os estimadores são capazes de fazer boas estimativas

– Pode ser necéssário trocar algum deles • Discute sobre:

– o método

– a especificação do problema

– unidade que será usada para estimar – restrições do projeto

– lista inicial de atividades

– quaisquer outros pressupostos que devam ser considerados para estimar

Wideband Delphi

Preparação individual

• Cada especialista prepara sua lista de atividades e estimativas

– Pode-se partir de uma lista inicial – O WBS é uma boa pedida!

• As estimativas devem ser individuais

– Não se deixar influenciar ou pressionar!

• Quebrar atividade muito longas em atividades menores • Considerar qualquer tipo de atividade

– Reuniões, retrabalho, treinamentos, testes, documentação, etc. – A lista pode crescer!

• Considerar que apenas 1 pessoa vai executar todas as tarefas, sequencialmente

– Não se preocupar com dependências entre tarefas

• Assumir 100% de aproveitamento das horas trabalhadas • Anotar quaisquer pressupostos considerados para estimar

Wideband Delphi

Reunião de estimativas

• Gráfico ilustrando todas as estimativas para o projeto • Anonimato é importante!

– O moderador coleta as estimativas

• Cada estimador apresenta sua lista de atividades e os pressupostos que usou para estimar

• As estimativas e listas são refeitas • As rodadas continuam até

– Estimativas convergirem – Acabar o tempo da reunião – Acabar o número de rodadas (4) – Especialistas ficarem irredutívies

Estim ativas 0 1 2 3 4 0 200 400 600 800 Esforço (h) R o d a d a Estim ativas 0 1 2 3 4 0 200 400 600 800 Esforço (h) R o d a d a Estim ativas 0 1 2 3 4 0 200 400 600 800 Esforço (h) R o d a d a

Wideband Delphi

Consolidação dos resultados

• Consolidar a lista de atividades dos especialistas – Remover atividades repetidas

– Considerar os pressupostos que foram assumidos • Consolidar as estimativas

– Média de cada atividade

– Valor mínimo como o melhor caso – Maior valor como o pior caso

– Erro:

• maior valor - média • média - valor mínimo

• Manter o espectro de estimativas de cada atividade – Descartar ou modificar atividades se necessário

Wideband Delphi

Reunião de resultados

• Todos os estimadores participam

• Consenso sobre:

– a lista de atividades consolidadas – as estimativas consolidadas

• Oportunidade para melhorar o método

• Novas atividades ainda podem ser

acrescentadas

Fornecer uma lista de atividades e estimativas que possa ser usada pelo

gerente do projeto para continuar o planejamento com razoável segurança

Pontos de casos de uso

– Baseado em algoritmo matemático

• Inspirado no modelo de Pontos de Função

• PCUNA = Pontos de Casos de Uso Não Ajustados • FCT = Fatores de Complexidade Técnica

• FA = Fatores Ambientais

Pontos de casos de uso

– Baseado na complexidade dos atores e casos de uso – “tamanho” do sistema

• FCT

– Obtido a partir do produto de 13 fatores técnicos – FCT = 0,6 + 0,01.(ProdFT)

• FA

– Obtido a partir do produto de 8 fatores ambientais – FA = 1,4 + (-0,03).(ProdFA)

• PCU = Pontos de Casos de Uso

Pontos de casos de uso

• A estimativa final considera a quantidade de

homens/hora ideal por PCU

• K = homens/hora por unidade de PCU

– Depende dos fatores ambientais

Esforço = PCU * K

Considerando Fatores Técnicos do Projeto

Fator Descrição Peso AtribuídoValor

T1 Sistema Distribuído 2 0 T2 Objetivos de Performance 1 0 T3 Eficiênca OnLine 1 * 0 T4 Complexidade de Processamento 1 0 T5 Codigo Reusável 1 0 T6 Facilidade de Instalação 0,5 0 T7 Facilidade de Uso 0,5 0 T8 Portabilidade 2 0 T9 Facilidade de Alterações 1 0 T10 Concorrência 1 0 T11 Segurança 1 0 T12 Acesso direto a terceiros 1 0 T13 Facilidades de Treinamento 1 0 FatorT 0 FCT 0,6

Considerando Fatores Ambientais

Fator Descrição Peso AtribuidoValor

F1 Familiariade da equipe com RUP 1,5 0 F2 Experiência da equipe 0,5 0 F3 Experiência da equipe em OO 1 0 F4 Capacidade dos Analistas da equipe 0,5 0 F5 Motivação 1 0 F6 Estabilidade dos Requisitos 2 0 F7 Estagiários/Meio Espediente -1 0 F8 Domínio da tecnologia e configuração do ambiente -1,5 0 FatorA 0 FA 1,4

Pontos de Caso de Uso

PCU PCUNA *FCT*FA 0 Homem/Hora por Unidade de PCU

Estimativa em Homem/Hora 0 Tamanho da equipe 1 Estimativa para equipe em horas 0

Pontos de Função

• Ponto de função : unidade de medida do

tamanho de uma aplicação, baseada nas suas

funções, do ponto de vista do usuário.

• Funções consideradas na contagem de pontos da

aplicação:

– Entradas Externas (EE) – Saídas Externas (SE)

– Arquivos Lógicos Internos (ALI)

– Arquivos de Interface Externa (AIE) – Consultas Externas (CE)

Pontos de Função

Configuração dos Pontos de Função de uma Aplicação

– Entradas Externas (EE) – Saídas Externas (SE)

– Arquivos Lógicos Internos (ALI) – Arquivos de Interface Externa (AIE) – Consultas Externas (CE)

Fronteiras da Aplicação TRANSAÇÕES Arquivos APLICAÇÃO Transações Entrada Saída Consulta E S C Complexidade do Processamento APLICAÇÃO EXTERNA Arquivos

Pontos de Função

• Pressupostos do modelo:

– Especificações concluídas e aprovadas

– Esforço de trabalho de uma pessoa durante um mês = 130 horas

– Existência de registros históricos de produtividade por linguagem de programação, em termos de :

• Número de horas de esforço de trabalho para um ponto de função

• Número de linhas de código-fonte por um ponto de função

Pontos de Função

Roteiro

1. Identificar e enumerar as funções da aplicação.

2. Classificar cada uma das funções identificadas segundo seu nível de complexidade : simples, médio ou complexo. Um conjunto de tabelas para cada tipo de função ajuda na classificação.

3. Calcular os pontos de função brutos, somando todas as funções com os respectivos pesos.

4. Ajustar o número de pontos de função brutos pelo nível de complexidade do processamento.

Planejamento Ágil

Imagine que

Como você Estimaria Este Trabalho?

• Olhe para o monte de britas e imagine quantos

carrinhos de mão seriam necessário para

transportar toda essa brita

– Eu acredito que seja necessário uns 80 carrinhos

• Depois de 1 hora, observe quantos carrinhos você

conseguiu transportar

– Depois de 1 hora eu consegui transportar 20 carrinhos

• Então estime o tempo total de duração

– O trabalho terá duração aproximada de 4 horas

Neste Cenário

Story Points

• Ajudam o time ter um comportamento

multifuncional;

• Estimativas feitas por Story points não

depreciam;

• Estimar em story points normalmente é bem

mais rápido;

• Foco em tamanho/esfoço e não em duração

Planning Poker

Pessoal, qual a estimativa para essa história?

Outras Técnicas de Estimativas

• Modelos baseados em Proxy

– Utiliza tabelas de complexidade baseada em números de alguns componentes. Ex: telas,

classes, relatórios, tabelas de banco de dados, etc.

• Técnicas de Aprendizado de Máquina

– Redes neurais e redes neuro-fuzzy

• Técnicas estátisticas de regressão linear

Por fim… Lembre-se dos imprevistos!

• Não assumir que tudo correrá às mil maravilhas – Doenças e saídas de funcionários

– Atraso na disponibilização de recursos – Problemas com o ambiente

• Fator de erro

– Margem de segurança • Fator de produtividade

– Quem trabalha 480 minutos por dia em sua atividade fim?!

Bibliografia

– BOEHM, B., Software Enginnering Economics, Prentice Hall, 1981.

– PRESSMAN, R. Engenharia de Software. MCGRAW HILL - ARTMED, 7.ed., 2011.

– PFLEEGER, S.Engenharia de Software. PRENTICE HALL BRASIL, 2.ed.,2004.

– SOMMERVILLE, I.Engenharia de Software. PEARSON BRASIL, 9.ed., 2011.Pressman, R. Software Engineering.

– VASQUEZ, C.; SIMÕES, G.; ALBERT, R. Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software. Érica: São Paulo, 12. Ed., 2012.

Gerência de Projetos

Planejamento e Estimativas

Marcelo Marinho