Como fazer estimativas num Projeto de Software?
Profa: Francilene Procópio Garcia O Quê se deve medir?
Alguns esquemas de medição podem chocar! Muitos dados para se coletar. Um caminho alternativo é medir o básico - quatro aspectos que fazem diferença num projeto de software:
1. O tamanho do produto - dependente do tipo de produto. O tamanho dos requisitos é o número absoluto de requisitos. Quandos e está na fase projeto representa o número de elementos projetados. O tamanho final de um produto é dado em linhas de código, subrotinas, ou classes existentes.
2. O esforço requerido para o desenovlvimento - é medido em homens/horas. O projeto deve estimar quantos homens/horas é necessário para se construir o produto.
3. A qualidade do produto - é medida em taxas de erros encontrados e solucionados. Tais erros podem ser achados em qualquer uma das fases do projeto, não apenas nas fases de teste.
4. O cronograma - descreve no tempo como as atividades planejadas serão executadas. Deve indicar quando cada atividade começa e termina.
Em geral, indica-se acompanhar essas medidas numa tabela como a que segue.
Tamanho Homens/Horas Erros Início Fim
Atividade
Estimado Real Estimado Real Achados Solucio -nados
Data Estimada
Data Real
Data Estimada
Data Real Requisitos
Planeja- mento Projeto Implemen- tação Teste Documen- tação Entrega Gerência TOTAL
1- Estimando o Tamanho do Produto a ser Desenvolvido
1. Assegure-se de que você tem clareza com relação ao problema e requisitos envolvidos.
2. Não é fácil se obter sucesso sem um processo bem definido. Como saber o que medir, monitorar o progresso, ou mesmo avaliar a qualidade dos artefatos sem um processo?
Você faz uso de algum processo p/
desenvolvimento? (2)
Você tem também um processo de medição? (4) Defina um processo
para o seu desenvolvimento.
(3)
Defina medidas para tamanho e
recursos. (5)
Você tem dados históricos? (6)
São medidas de tamanho apropriadas? (8) Identifique alguns
exemplos. (7)
Faça uma estimativa intuitiva
baseada em comparação. (9)
Aplique o mesmo método formal. (12)
Estime tempo mínimo e máximo.
(10)
Calcule intervalos nos seus prognósticos . (13)
Sim Não
Sim Não
Não Sim
Não
Sim
Estime faixas (11) Estime faixas (14)
Novo projeto ou Novos(s) requisito(s) (1)
3. Se a resposta anterior é não, procure identificar um processo simples e aplique-o. Não precisa ser um processo complexo, porém deve incluir algum planejamento e post mortem. Sugestão:
procure quebrar o seu projeto em tarefas que representem entre 10 a 25% do total. Com mais experiência e alguns dados históricos você poderá refinar e melhorar o seu processo.
4. Você necessita de algumas medidas para planejar o seu trabalho e obter dados que permitam planos melhores no futuro.
5. Se a resposta anterior é não, você necessita definir no mínimo medidas para tamanho e recursos. Ou seja, estimar tempo para o processo de desenvolvimento e tamanho do produto final.
6. Em geral, dados históricos quantitativos são importantes para se estimar melhor tamanho e esforço requerido ao projeto.
7. Ainda que sua resposta anterior seja não, você pode identificar algum projeto similar e estimar quanto tempo ele levou. Se você não mediu nenhum de seus projetos anteriores, suas estimativas para o projeto atual podem estar erradas em torno de 400 a 600% (ou mais). Dái que vale o esforço de burcar por exemplos relevantes, minimiza o erro inicial de seu planejamento.
8. Você deve satisfazer as seguintes condições antes de fazer uso de estimativas disponíveis:
• O dado de tamanho deve ser claro e explícito;
• Os dados devem ser baseados em pelo menos um histórico anterior;
• A forma de estimar o tamanho deve ser conhecida.
9. Se a resposta anterior é não, você deve conduzir uma estimativa baseada em comparação com algum outro projeto seu. Existem vários métodos para estimar tamanho: Wideband-Delphi [Boehm], Fuzzy-Logic [Putnam], Componente Padrão [Putnam], Pontos de Função [Albrecht], entre outros.
10. Estime tempos mínimo e máximo requeridos em acordo com o tipo de projeto. Lembre -se sempre pode acontecer algo imprevisível!
11. Determine uma faixa para suas estimativas. Além de um número obtido no passo 9, defina uma faixa (valores mínimos e máximos - passo 10).
12. , 13., e 14. Seguem o método PROBE para produzir as estimativas e os seus intervalos.
Método Wideband-Delphi [Boehm]
Este método sugere que vários desenvolvedores envolvidos no projeto indiquem suas estimativas individualmente. Em seguida, aplica-se o processo Delphi para se obter uma estimativa convergente.
Exemplo:
Projeto: ABC
Moderador: Fulano de Tal Data: 09.02.2001
Aqui está a faixa de estimativas obtidas na primeira coleta:
X - estimativas obtidas X* - sua estimativa X! - estimativa média
Favor, entre com a sua estimativa para a próxima coleta: ______ LOC.
Acrescente alguma explicação que justifique sua estimativa.
O processo Delphi tem como meta compartilhar diferentes visões dos desenvolvedores. Após algumas coletas, quando se alcança uma faixa considerada razoável, uma estimativa é colocada como finalista. Em projetos grandes, sugere-se a aplicação do processo de forma simultânea aos diferentes componentes do produto, ao final, combina-se as estimativas e elege-se uma estimativa final.
Método Fuzzy-Logic [Putnam]
Putnam descreve este método da seguinte forma: "os projetistas / desenvolvedores devem avaliar o produto especificado e indicar um palpite sobre seu tamanho comparando com dados históricos existentes, coletados em produtos anteriores."
Quando o grupo alcança uma massa de dados suficiente, categorias de tamanho são atribuídas, como ilustra a tabela que segue.
Faixas Tamanho - LOC Mínimo - LOC Máximo - LOC
Muito Pequeno 2000 1000 4000
Pequeno 8000 4000 16000
Médio 32000 16000 64000
Grande 128000 64000 256000
Muito Grande 512000 256000 1028000
As categorias poderão ser quebradas em mais detalhes, permitindo um acerto maior nas estimativas.
Método Componente Padrão [Putnam]
0 20 40 60 80 100
X X* X! X X
Da mesma forma que o método Fuzzy-Logic, Putnam propõe neste método o armazenamento de dados históricos ao longo do tempo. Porém, neste método os projetistas são estimulados a registrarem dados sobre tamanhos de componentes em diferentes níveis (subsistemas, módulos, e telas, por exemplo).
Também estimula-se que sejam realizadas avaliações sobre números minímos e máximos.
A estimativa obtida é multiplicada por quatro e, então, adicionada dos valores minímo e máximo.
Em seguida, divide-se o total por seis para se obter o valor mais indicado para o componente. O desvio padrão do valor final deve ser aproximadamente um sexto da diferença entre o minímo e o máximo valor obtido.
Número Estimado = [menor número admitido + 4 * (número médio estimado) + maior número admitido] / 6
A Tabela que segue ilustra alguns dos valores que Putnam usa para cálculo das estimativas.
Componente Padrão
LOC por Componente
P M G X= (P + 4 * M + G) / 6 LOC
LOC 1
Arquivos 2535 3 6 10 6,17 15633
Módulos 932 11 18 22 17,5 16310
Subsistemas 8175
Telas 818 5 9 21 10,3 8453
Relatórios 967 2 6 11 6,17 5963
Programas Interativos
1769 Programas Batch 3214
Total 46359
Método de Pontos de Função
Um dos métodos mais populares para se estimar tamanho de aplicações de software. Seu criador, Albrecht, identificou cinco funções básicas que ocorrem frequentemente e as caracterizou conforme suas complexidades.
Exemplo:
Números Chaves Tipos de Funções Pesos Total
8 Inputs 8 *4 32
12 Outputs 12 *5 60
4 Inquiries 4 *4 16
2 Logical Files 2 *10 20
1 Interfaces 1 *7 7
Total 135
2- Estimando o Esforço para o Desenvolvimento
Existem várias condutas para se estimar esforço de desenvolvimento - um componente importante para se estimar tempo e custos de projetos de software. Em geral, tais condutas fazem uso de estimativas obtidas para o tamanho do produto final, explorado no item anterior.
A figura que segue ilustra como as estimativas de tempo obtidas por diferentes condutas e também de forma intuitiva podem variar em termos de precisão.
Em geral, quanto mais se estiver nas fases iniciais do desenvolvimento (Planejamento e Elaboração), mais tende-se a estimar de forma pouco precisa. Acompanhe na tabela que segue de que forma as estimativas tendem a se tornar mais precisas e maduras.
Planejamento Elaboração Construção Transição
Fase ainda inicial Fase Inicial de projeto Fase pós-arquitetura Entradas grosseiras
Estimativas pouco fiéis Requisitos em
altíssimo nível Arquitetura ainda conceitual
Projeto melhor entendido
Estimativas mais fiéis Requisitos melhor entendidos
Arquitetura melhor entendida
Projeto bem caracterizado e detalhado Estimativas alta precisão Requisitos mais estáveis Arquitetura mais estável
Para estimarmos o tempo de desenvolvimento, com o objetivo de seguir com o cálculo de custo associados, podemos fazer uso do Modelo COCOMO na sua forma básica, por exemplo.
No modelo COCOMO, o esforço nas fases iniciais é calculado conforme ilustra as equações abaixo:
Esforço = ab * (Tamanho) * exp(bb),
Tempo_Desenvolvimento = cb * (Esforço * exp(db)) onde;
Esforço = número de homens/hora ou homens/mês Tempo_Desenvolvimento= tempo em meses cronológicos Tamanho = número de pontos de função ou KLOC estimados
ab e bb sãocoeficientes cb e db são expoentes de ajustes fornecidos na tabela abaixo.
0 4X
X/4
Planejamento Elaboraçã
o Construçã
o Transição
Superestimado
Subestimado
Tabela COCOMO Básico
Projeto de Software ab bb cb db
Orgânico - projetos simples, relativamente pequenos, requisitos não muito rígidos, com pequenas equipes experientes
2,4 1,05 2,5 0,38
Semidestacado - projeto intermediário (em tamanho e complexidade), equipes com experiência heterogênea, requisitos mistos (rígidos e não rígidos)
3 1,12 2,5 0,35
Embutido - um projeto com um conjunto rígido de restrições operacionais (hardware e software)
3,6 1,2 2,5 0,32
Observe que neste modelo básico do COCOMO, o esforço e por consequência o custo do projeto é estimado em função do tamanho do código estimado - considera-se um modelo estático. Outras formas do COCOMO levam em consideração avaliações subjetivas do produto, do hardware, do pessoal e dos atributos do projeto, além do impacto de fases que direcionam os custo (análise, projeto, por exemplo). Quem tiver interesse nas outras formas mais precisas, ver em Engenharia de Software do Roger Pressman.
Temos de fazer tudo na base da calculadora? Não. Existem boas ferramentas, conforme enumera- se a seguir:
• BYL, Gordon Group; (baseada no COCOMO)
• WICOMO, Wang Institute; (baseada no COCOMO)
• DECPlan. Digital Corporation; (baseada no COCOMO)
• SLIM, Modelo de Estimativa do Putnam; (usa programação linear e a técnica PERT)
• ESTIMACS, Rubin; (baseada em pontos de função)
• SPQR/20, Software Productivity Research (Jones) (baseado num conjunto de múltiplas perguntas e respostas).
Uma vez estimando-se o esforço do projeto, que pode ser melhor refinado a cada iteração, estaremos em condições de fazer uma estimativa de custo para o projeto, onde os componentes abaixo são determinantes:
• Esforço em Homem/mês * Custo (in cluindo impostos);
• Infra-estrutura (hardware + software + ambiente)1;
• Overhead administrativo - cerca de 20 a 30% do valor total.
3- Qualidade do produto
Para se medir qualidade de sofwtare, uma forma simples e direta é verificar a ocorrência de falhas ou erros ao longo do ciclo de desenvolvimento, registrando o momento em que foram detectados e quanto tempo foi necessário para resolv ê-los.
1 Lembrar que os valores devem ser associados ao tempo do projeto. Pro exemplo, três meses de aluguel de um PC, sala mais percentual de licenças de software.
Adicionalmente, quatro outros indicadores de qualdiade podem ser medidos, como pode ser visto na tabela que segue.
Métrica Propósito O que deve ser registrado
Mudanças sobre o tempo Planejamento de iteração, indicador de gestão da convergência de cronograma
Ordens de mudanças de código (OMC) abertas vs. OMC fechadas, organizadas por tipo, por versão/
componente/subsistema Média de quebra na
modularidade sobre mudanças sobre o tempo
Convergência, pulverização do software, indicador de qualidade
LOC retrabalhadas por mudança, organizadas por tipo, por versão/
componente/subsistema Média de retrabalho por
mudança sobre o tempo
Convergência, retrabalho no software, indicador de qualidade
Média de horas por mudança, organizadas por tipo, por versão/
componente/subsistema Taxa de defeitos sobre o
tempo (MTBF)
Cobertura/adequação de testes, robustez do uso, indicador de qualidade
Registro de falhas, horas de testes até uma falha ser detectada, por versão/ componente/subsistema
4- Cronograma
No processo de planejamento iterativo, o planejamento do conjunto de atividades no cronograma tem como meta a definição de uma sequência de resultados intermediários e das principais iterações. É importante que se entenda tal planejamento de forma evolucionária, uma vez que ajustes no conteúdo e no cronograma serão necessários ao longo do tempo.
Um roteiro genérico a ser seguido deve prever um número x de iterações em cada fase do ciclo de vida. Cada iteração é usada para se tentar uma sincronização ao longo do projeto. O tempo de cada uma delas pode variar, existem iterações que demandam um mês, uma semana, ou até dias.
Algumas técnicas para confecção do cronograma devem ser utilizadas, tais como PERT e CPM.
Ambas apresentam ferramenas quantitativas que permitem planejar: (1) o caminho crítico - uma cadeia de tarefas que totaliza a duração mínima do projeto; (2) estimativas de tempo mais prováveis para cada tarefa individual; (3) cálculo de limites de tempo que podem ajudar a definir uma "janela" de tempo para uma tarefa em particular (usam-se buffers de contigência para acontecimentos ocasionais e imprevisíveis).
