Você está na página 1de 8

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.
Atividade Tamanho Estimado Real Homens/Horas Estimado Real Erros Achados Solucio -nados Início Data Data Estimada Real Fim Data Data Estimada Real

Requisitos Planejamento Projeto Implementação Teste Documentação Entrega Gerência TOTAL

(9) Estime tempo mínimo e máximo. Como saber o que medir. 2.1. (10) Estime faixas (11) Aplique o mesmo método formal. Não é fácil se obter sucesso sem um processo bem definido. (7) São medidas de tamanho apropriadas? (8) Sim Não Faça uma estimativa intuitiva baseada em comparação. (12) Calcule intervalos nos seus prognósticos . ou mesmo avaliar a qualidade dos artefatos sem um processo? . (3) Você tem também um processo de medição? (4) Sim Não Defina medidas para tamanho e recursos. (13) Estime faixas (14) 1. (5) Você tem dados históricos? (6) Não Sim Identifique alguns exemplos. Assegure-se de que você tem clareza com relação ao problema e requisitos envolvidos.Estimando o Tamanho do Produto a ser Desenvolvido Novo projeto ou Novos(s) requisito(s) (1) Você faz uso de algum processo p/ desenvolvimento? (2) Sim Não Defina um processo para o seu desenvolvimento. monitorar o progresso.

4. Não precisa ser um processo complexo. Existem vários métodos para estimar tamanho: Wideband-Delphi [Boehm]. • Os dados devem ser baseados em pelo menos um histórico anterior. Em geral. entre outros. . Você necessita de algumas medidas para planejar o seu trabalho e obter dados que permitam planos melhores no futuro. . Componente Padrão [Putnam]. 6. suas estimativas para o projeto atual podem estar erradas em torno de 400 a 600% (ou mais). Fuzzy-Logic [Putnam]. Se a resposta anterior é não. Ou seja. porém deve incluir algum planejamento e post mortem. Pontos de Função [Albrecht]..3. estimar tempo para o processo de desenvolvimento e tamanho do produto final. Sugestão: procure quebrar o seu projeto em tarefas que representem entre 10 a 25% do total. Ainda que sua resposta anterior seja não. minimiza o erro inicial de seu planejamento. • A forma de estimar o tamanho deve ser conhecida. Além de um número obtido no passo 9. Determine uma faixa para suas estimativas. defina uma faixa (valores mínimos e máximos . 7. Dái que vale o esforço de burcar por exemplos relevantes. Se a resposta anterior é não. você deve conduzir uma estimativa baseada em comparação com algum outro projeto seu. Seguem o método PROBE para produzir as estimativas e os seus intervalos. você pode identificar algum projeto similar e estimar quanto tempo ele levou. você necessita definir no mínimo medidas para tamanho e recursos. e 14. Com mais experiência e alguns dados históricos você poderá refinar e melhorar o seu processo.passo 10). Se a resposta anterior é não. Se você não mediu nenhum de seus projetos anteriores. dados históricos quantitativos são importantes para se estimar melhor tamanho e esforço requerido ao projeto. 10. 5. 12. 13. Estime tempos mínimo e máximo requeridos em acordo com o tipo de projeto. procure identificar um processo simples e aplique-o. 9. Lembre-se sempre pode acontecer algo imprevisível! 11. 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. 8.

02.LOC 4000 16000 64000 256000 1028000 As categorias poderão ser quebradas em mais detalhes. Em seguida. Após algumas coletas. categorias de tamanho são atribuídas. entre com a sua estimativa para a próxima coleta: ______ LOC. ao final. O processo Delphi tem como meta compartilhar diferentes visões dos desenvolvedores. Em projetos grandes. uma estimativa é colocada como finalista.sua estimativa X! . combina-se as estimativas e elege-se uma estimativa final. Método Componente Padrão [Putnam] . Faixas Muito Pequeno Pequeno Médio Grande Muito Grande Tamanho . Exemplo: Projeto: ABC Moderador: Fulano de Tal Data: 09. Acrescente alguma explicação que justifique sua estimativa. aplica-se o processo Delphi para se obter uma estimativa convergente.estimativa média Favor." Quando o grupo alcança uma massa de dados suficiente.2001 Aqui está a faixa de estimativas obtidas na primeira coleta: X 0 20 X* 40 X! 60 X 80 X 100 X .Método Wideband-Delphi [Boehm] Este método sugere que vários desenvolvedores envolvidos no projeto indiquem suas estimativas individualmente. como ilustra a tabela que segue.estimativas obtidas X* .LOC 1000 4000 16000 64000 256000 Máximo . permitindo um acerto maior nas estimativas. sugere-se a aplicação do p rocesso de forma simultânea aos diferentes componentes do produto. 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 se alcança uma faixa considerada razoável.LOC 2000 8000 32000 128000 512000 Mínimo .

Albrecht. Também estimula-se que sejam realizadas avaliações sobre números minímos e máximos. 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. divide-se o total por seis para se obter o valor mais indicado para o componente. Exemplo: Números Chaves 8 12 4 2 1 Tipos de Funções Inputs Outputs Inquiries Logical Files Interfaces Total Pesos 8 *4 12 *5 4 *4 2 *10 1 *7 Total 32 60 16 20 7 135 .Da mesma forma que o método Fuzzy-Logic. e telas. Seu criador. então. A estimativa obtida é multiplicada por quatro e. neste método os projetistas são estimulados a registrarem dados sobre tamanhos de componentes em diferentes níveis (subsistemas.17 15633 16310 8453 5963 Método de Pontos de Função Um dos métodos mais populares para se estimar tamanho de aplicações de software. adicionada dos valores minímo e máximo.5 10.3 6. identificou cinco funções básicas que ocorrem frequentemente e as caracterizou conforme suas complexidades. Porém. por exemplo). Em seguida. módulos.17 17. Componente Padrão LOC Arquivos Módulos Subsistemas Telas Relatórios Programas Interativos Programas Batch Total LOC por Componente 1 2535 932 8175 818 967 1769 3214 46359 P M G X= (P + 4 * M + G) / 6 LOC 3 11 5 2 6 18 9 6 10 22 21 11 6. Putnam propõe neste método o armazenamento de dados históricos ao longo do tempo. 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.

quanto mais se estiver nas fases iniciais do desenvolvimento (Planejamento e Elaboração). o esforço nas fases iniciais é calculado conforme ilustra as equações abaixo: Esforço = ab * (Tamanho) * exp(bb). Em geral. por exemplo. Planejamento Fase ainda inicial Entradas grosseiras Estimativas pouco fiéis Requisitos em altíssimo nível Arquitetura ainda conceitual Elaboração Fase Inicial de projeto Projeto melhor entendido Estimativas mais fiéis Requisitos melhor entendidos Arquitetura melhor entendida Construção Transição Fase pós-arquitetura Projeto bem caracterizado e detalhado Estimativas alta precisão Requisitos mais estáveis Arquitetura mais estável Para estimarmos o tempo de desenvolvimento. 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ão coeficientes cb e db são expoentes de ajustes fornecidos na tabela abaixo. .Estimando o Esforço para o Desenvolvimento Existem várias condutas para se estimar esforço de desenvolvimento . podemos fazer uso do Modelo COCOMO na sua forma básica. Acompanhe na tabela que segue de que forma as estimativas tendem a se tornar mais precisas e maduras.2. Tempo_Desenvolvimento = cb * (Esforço * exp(db)) onde. explorado no item anterior. No modelo COCOMO. tais condutas fazem uso de estimativas obtidas para o tamanho do produto final.um componente importante para se estimar tempo e custos de projetos de software. 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. com o objetivo de seguir com o cálculo de custo associados. 4X Superestimado 0 Planejamento Elaboraçã o Construçã o Transição Subestimado X/4 Em geral. mais tende-se a estimar de forma pouco precisa.

um projeto com um conjunto rígido de restrições operacionais (hardware e software) ab 2. sala mais percentual de licenças de software. requisitos mistos (rígidos e não rígidos) Embutido . Temos de fazer tudo na base da calculadora? Não.5 0. (baseada em pontos de função) • SPQR/20.6 1. o esforço e por consequência o custo do projeto é estimado em função do tamanho do código estimado . Gordon Group. 3. • Infra-estrutura (hardware + software + ambiente)1. Outras formas do COCOMO levam em consideração avaliações subjetivas do produto. Lembrar que os valores devem ser associados ao tempo do projeto. (baseada no COCOMO) • DECPlan. relativamente pequenos. uma forma simples e direta é verificar a ocorrência de falhas ou erros ao longo do ciclo de desenvolvimento. estaremos em condições de fazer uma estimativa de custo para o projeto. Pro exemplo. • Overhead administrativo .5 0. (usa programação linear e a técnica PERT) • ESTIMACS.35 3. Existem boas ferramentas.projeto intermediário (em tamanho e complexidade).12 2. Modelo de Estimativa do Putnam. conforme enumerase a seguir: • BYL.38 3 1.considera-se um modelo estático. registrando o momento em que foram detectados e quanto tempo foi necessário para resolv ê-los.cerca de 20 a 30% do valor total. com pequenas equipes experientes Semidestacado . onde os componentes abaixo são determinantes: • Esforço em Homem/mês * Custo (in cluindo impostos).2 2. Quem tiver interesse nas outras formas mais precisas. requisitos não muito rígidos.Qualidade do produto Para se medir qualidade de sofwtare. além do impacto de fases que direcionam os custo (análise. por exemplo). ver em Engenharia de Software do Roger Pressman.05 cb 2.Tabela COCOMO Básico Projeto de Software Orgânico . Rubin. do hardware.projetos simples. Uma vez estimando-se o esforço do projeto. que pode ser melhor refinado a cada iteração. 1 . três meses de aluguel de um PC.32 Observe que neste modelo básico do COCOMO. equipes com experiência heterogênea. Wang Institute. Digital Corporation. do pessoal e dos atributos do projeto. projeto.5 db 0.4 bb 1. (baseada no COCOMO) • SLIM. (baseada no COCOMO) • WICOMO. Software Productivity Research (Jones) (baseado num conjunto de múltiplas perguntas e respostas).

por versão/ componente/subsistema Registro de falhas. O tempo de cada uma delas pode variar. Um roteiro genérico a ser seguido deve prever um número x de iterações em cada fase do ciclo de vida.uma cadeia de tarefas que totaliza a duração mínima do projeto. indicador de qualidade Convergência. Métrica Mudanças sobre o tempo Propósito Planejamento de iteração. Algumas técnicas para confecção do cronograma devem ser utilizadas. organizadas por tipo.Cronograma No processo de planejamento iterativo. pulverização do software. como pode ser visto na tabela que segue. organizadas por tipo. por versão/ componente/subsistema LOC retrabalhadas por mudança. (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). existem iterações que demandam um mês. uma vez que ajustes no conteúdo e no cronograma serão necessários ao longo do tempo. É importante que se entenda tal planejamento de forma evolucionária. indicador de qualidade Cobertura/adequação de testes. (2) estimativas de tempo mais prováveis para cada tarefa individual. indicador de gestão da convergência de cronograma O que deve ser registrado Ordens de mudanças de código (OMC) abertas vs.Adicionalmente. por versão/ componente/subsistema Média de horas por mudança. tais como PERT e CPM. indicador de qualidade 4. horas de testes até uma falha ser detectada. organizadas por tipo. robustez do uso. uma semana. por versão/ componente/subsistema Média de quebra na modularidade sobre mudanças sobre o tempo Média de retrabalho por mudança sobre o tempo Taxa de defeitos sobre o tempo (MTBF) Convergência. ou até dias. Cada iteração é usada para se tentar uma sincronização ao longo do projeto. . Ambas apresentam ferramenas quantitativas que permitem planejar: (1) o caminho crítico . quatro outros indicadores de qualdiade podem ser medidos. retrabalho no software. OMC fechadas. 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.