Como fazer estimativas num Projeto de Software?

Profa: Francilene Procpio Garcia O Qu se deve medir? Alguns esquemas de medio podem chocar! Muitos dados para se coletar. Um caminho alternativo medir o bsico - quatro aspectos que fazem diferena num projeto de software: 1. O tamanho do produto - dependente do tipo de produto. O tamanho dos requisitos o nmero absoluto de requisitos. Quandos e est na fase projeto representa o nmero de elementos projetados. O tamanho final de um produto dado em linhas de cdigo, subrotinas, ou classes existentes. 2. O esforo requerido para o desenovlvimento - medido em homens/horas. O projeto deve estimar quantos homens/horas necessrio 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, no apenas nas fases de teste. 4. O cronograma - descreve no tempo como as atividades planejadas sero executadas. Deve indicar quando cada atividade comea 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 Incio Data Data Estimada Real Fim Data Data Estimada Real

Requisitos Planejamento Projeto Implementao Teste Documentao Entrega Gerncia TOTAL

1- 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 No Defina um processo para o seu desenvolvimento. (3)

Voc tem tambm um processo de medio? (4)

Sim

No Defina medidas para tamanho e recursos. (5)

Voc tem dados histricos? (6)

No

Sim

Identifique alguns exemplos. (7)

So medidas de tamanho apropriadas? (8)

Sim

No

Faa uma estimativa intuitiva baseada em comparao. (9) Estime tempo mnimo e mximo. (10) Estime faixas (11)

Aplique o mesmo mtodo formal. (12)

Calcule intervalos nos seus prognsticos . (13) Estime faixas (14)

1. Assegure-se de que voc tem clareza com relao ao problema e requisitos envolvidos. 2. No fcil 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?

3. Se a resposta anterior no, procure identificar um processo simples e aplique-o. No precisa ser um processo complexo, porm deve incluir algum planejamento e post mortem. Sugesto: procure quebrar o seu projeto em tarefas que representem entre 10 a 25% do total. Com mais experincia e alguns dados histricos 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 no, voc necessita definir no mnimo medidas para tamanho e recursos. Ou seja, estimar tempo para o processo de desenvolvimento e tamanho do produto final. 6. Em geral, dados histricos quantitativos so importantes para se estimar melhor tamanho e esforo requerido ao projeto. 7. Ainda que sua resposta anterior seja no, voc pode identificar algum projeto similar e estimar quanto tempo ele levou. Se voc no mediu nenhum de seus projetos anteriores, suas estimativas para o projeto atual podem estar erradas em torno de 400 a 600% (ou mais). Di que vale o esforo de burcar por exemplos relevantes, minimiza o erro inicial de seu planejamento. 8. Voc deve satisfazer as seguintes condies antes de fazer uso de estimativas disponveis: O dado de tamanho deve ser claro e explcito; Os dados devem ser baseados em pelo menos um histrico anterior; A forma de estimar o tamanho deve ser conhecida. 9. Se a resposta anterior no, voc deve conduzir uma estimativa baseada em comparao com algum outro projeto seu. Existem vrios mtodos para estimar tamanho: Wideband-Delphi [Boehm], Fuzzy-Logic [Putnam], Componente Padro [Putnam], Pontos de Funo [Albrecht], entre outros. 10. Estime tempos mnimo e mximo requeridos em acordo com o tipo de projeto. Lembre-se sempre pode acontecer algo imprevisvel! 11. Determine uma faixa para suas estimativas. Alm de um nmero obtido no passo 9, defina uma faixa (valores mnimos e mximos - passo 10). 12. , 13., e 14. Seguem o mtodo PROBE para produzir as estimativas e os seus intervalos.

Mtodo Wideband-Delphi [Boehm] Este mtodo sugere que vrios 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 0 20 X* 40 X! 60 X 80 X 100

X - estimativas obtidas X* - sua estimativa X! - estimativa mdia Favor, entre com a sua estimativa para a prxima coleta: ______ LOC. Acrescente alguma explicao que justifique sua estimativa. O processo Delphi tem como meta compartilhar diferentes vises dos desenvolvedores. Aps algumas coletas, quando se alcana uma faixa considerada razovel, uma estimativa colocada como finalista. Em projetos grandes, sugere-se a aplicao do p rocesso de forma simultnea aos diferentes componentes do produto, ao final, combina-se as estimativas e elege-se uma estimativa final. Mtodo Fuzzy-Logic [Putnam] Putnam descreve este mtodo da seguinte forma: "os projetistas / desenvolvedores devem avaliar o produto especificado e indicar um palpite sobre seu tamanho comparando com dados histricos existentes, coletados em produtos anteriores." Quando o grupo alcana uma massa de dados suficiente, categorias de tamanho so atribudas, como ilustra a tabela que segue. Faixas Muito Pequeno Pequeno Mdio Grande Muito Grande Tamanho - LOC 2000 8000 32000 128000 512000 Mnimo - LOC 1000 4000 16000 64000 256000 Mximo - LOC 4000 16000 64000 256000 1028000

As categorias podero ser quebradas em mais detalhes, permitindo um acerto maior nas estimativas.

Mtodo Componente Padro [Putnam]

Da mesma forma que o mtodo Fuzzy-Logic, Putnam prope neste mtodo o armazenamento de dados histricos ao longo do tempo. Porm, neste mtodo os projetistas so estimulados a registrarem dados sobre tamanhos de componentes em diferentes nveis (subsistemas, mdulos, e telas, por exemplo). Tambm estimula-se que sejam realizadas avaliaes sobre nmeros minmos e mximos. A estimativa obtida multiplicada por quatro e, ento, adicionada dos valores minmo e mximo. Em seguida, divide-se o total por seis para se obter o valor mais indicado para o componente. O desvio padro do valor final deve ser aproximadamente um sexto da diferena entre o minmo e o mximo valor obtido. Nmero Estimado = [menor nmero admitido + 4 * (nmero mdio estimado) + maior nmero admitido] / 6 A Tabela que segue ilustra alguns dos valores que Putnam usa para clculo das estimativas. Componente Padro LOC Arquivos Mdulos Subsistemas Telas Relatrios 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,17 17,5 10,3 6,17

15633 16310 8453 5963

Mtodo de Pontos de Funo Um dos mtodos mais populares para se estimar tamanho de aplicaes de software. Seu criador, Albrecht, identificou cinco funes bsicas que ocorrem frequentemente e as caracterizou conforme suas complexidades. Exemplo: Nmeros Chaves 8 12 4 2 1 Tipos de Funes 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

2- Estimando o Esforo para o Desenvolvimento Existem vrias condutas para se estimar esforo 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 tambm de forma intuitiva podem variar em termos de preciso.

4X

Superestimado

Planejamento

Elabora o

Constru o

Transio

Subestimado X/4

Em geral, quanto mais se estiver nas fases iniciais do desenvolvimento (Planejamento e Elaborao), 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 Fase ainda inicial Entradas grosseiras Estimativas pouco fiis Requisitos em altssimo nvel Arquitetura ainda conceitual Elaborao Fase Inicial de projeto Projeto melhor entendido Estimativas mais fiis Requisitos melhor entendidos Arquitetura melhor entendida Construo Transio Fase ps-arquitetura Projeto bem caracterizado e detalhado Estimativas alta preciso Requisitos mais estveis Arquitetura mais estvel

Para estimarmos o tempo de desenvolvimento, com o objetivo de seguir com o clculo de custo associados, podemos fazer uso do Modelo COCOMO na sua forma bsica, por exemplo. No modelo COCOMO, o esforo nas fases iniciais calculado conforme ilustra as equaes abaixo: Esforo = ab * (Tamanho) * exp(bb), Tempo_Desenvolvimento = cb * (Esforo * exp(db)) onde; Esforo = nmero de homens/hora ou homens/ms Tempo_Desenvolvimento = tempo em meses cronolgicos Tamanho = nmero de pontos de funo ou KLOC estimados ab e bb so coeficientes cb e db so expoentes de ajustes fornecidos na tabela abaixo.

Tabela COCOMO Bsico Projeto de Software Orgnico - projetos simples, relativamente pequenos, requisitos no muito rgidos, com pequenas equipes experientes Semidestacado - projeto intermedirio (em tamanho e complexidade), equipes com experincia heterognea, requisitos mistos (rgidos e no rgidos) Embutido - um projeto com um conjunto rgido de restries operacionais (hardware e software) ab 2,4 bb 1,05 cb 2,5 db 0,38

1,12

2,5

0,35

3,6

1,2

2,5

0,32

Observe que neste modelo bsico do COCOMO, o esforo e por consequncia o custo do projeto estimado em funo do tamanho do cdigo estimado - considera-se um modelo esttico. Outras formas do COCOMO levam em considerao avaliaes subjetivas do produto, do hardware, do pessoal e dos atributos do projeto, alm do impacto de fases que direcionam os custo (anlise, 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? No. Existem boas ferramentas, conforme enumerase 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 programao linear e a tcnica PERT) ESTIMACS, Rubin; (baseada em pontos de funo) SPQR/20, Software Productivity Research (Jones) (baseado num conjunto de mltiplas perguntas e respostas). Uma vez estimando-se o esforo do projeto, que pode ser melhor refinado a cada iterao, estaremos em condies de fazer uma estimativa de custo para o projeto, onde os componentes abaixo so determinantes: Esforo em Homem/ms * 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 ocorrncia de falhas ou erros ao longo do ciclo de desenvolvimento, registrando o momento em que foram detectados e quanto tempo foi necessrio para resolv -los.

Lembrar que os valores devem ser associados ao tempo do projeto. Pro exemplo, trs meses de aluguel de um PC, sala mais percentual de licenas de software.

Adicionalmente, quatro outros indicadores de qualdiade podem ser medidos, como pode ser visto na tabela que segue. Mtrica Mudanas sobre o tempo Propsito Planejamento de iterao, indicador de gesto da convergncia de cronograma O que deve ser registrado Ordens de mudanas de cdigo (OMC) abertas vs. OMC fechadas, organizadas por tipo, por verso/ componente/subsistema LOC retrabalhadas por mudana, organizadas por tipo, por verso/ componente/subsistema Mdia de horas por mudana, organizadas por tipo, por verso/ componente/subsistema Registro de falhas, horas de testes at uma falha ser detectada, por verso/ componente/subsistema

Mdia de quebra na modularidade sobre mudanas sobre o tempo Mdia de retrabalho por mudana sobre o tempo Taxa de defeitos sobre o tempo (MTBF)

Convergncia, pulverizao do software, indicador de qualidade Convergncia, retrabalho no software, indicador de qualidade Cobertura/adequao de testes, robustez do uso, indicador de qualidade

4- Cronograma No processo de planejamento iterativo, o planejamento do conjunto de atividades no cronograma tem como meta a definio de uma sequncia de resultados intermedirios e das principais iteraes. importante que se entenda tal planejamento de forma evolucionria, uma vez que ajustes no contedo e no cronograma sero necessrios ao longo do tempo. Um roteiro genrico a ser seguido deve prever um nmero x de iteraes em cada fase do ciclo de vida. Cada iterao usada para se tentar uma sincronizao ao longo do projeto. O tempo de cada uma delas pode variar, existem iteraes que demandam um ms, uma semana, ou at dias. Algumas tcnicas para confeco do cronograma devem ser utilizadas, tais como PERT e CPM. Ambas apresentam ferramenas quantitativas que permitem planejar: (1) o caminho crtico - uma cadeia de tarefas que totaliza a durao mnima do projeto; (2) estimativas de tempo mais provveis para cada tarefa individual; (3) clculo de limites de tempo que podem ajudar a definir uma "janela" de tempo para uma tarefa em particular (usam-se buffers de contigncia para acontecimentos ocasionais e imprevisveis).