Métodos de estimativa de esforço de software

Laird e Brennan (2006, p. 81) declaram a existência de centenas de metodologias, ferramentas e modelos documentados de estimativa de software, sendo que todos apresentam significante limitação. Também reforçam a importância de se ter clara compreensão das fases do ciclo de vida endereçadas por cada modelo, visto que os modelos sempre endereçam parte do ciclo de vida e é relevante saber qual é o ciclo coberto pelo modelo.

Os modelos, métodos e abordagens de estimativa são apresentados com diferentes denominações na literatura. Destaca-se a categorização apresentada por Magne Jørgensen e Martin Shepperd (2006, p. 42) que classificam as abordagens de estimativa em: regressão; analogia; julgamento de especialista; decomposição; pontos por função; CART21; rede neural, teoria; bayesiana; e combinação de estimativas.

A seguir são apresentados alguns dos principais modelos e métodos mais comumente encontrados na literatura. A fim de facilitar a apresentação, destacamos o autor principal antes da descrição dos modelos e a eventual contribuição por outros autores é apontada no momento da inserção da contribuição. Ao final de cada modelo, será apresentada uma análise a fim de verificar sua possível aplicabilidade nas fases iniciais da concepção da mudança de

21 _{Classification and regression trees – classificação e árvores de regressão – é uma técnica não paramétrica que}

produz classificação ou árvore de regressão, dependendo se a variável dependente é respectivamente, categórica ou numérica.

software.

Daniel Galorath e Michael Evans (2006, p. 39 e 40) apresentam como métodos de estimativa mais populares:

Analogia

Compara o projeto proposto com projetos similares previamente concluídos no passado. Dados do projeto concluído são utilizados para estimar o projeto proposto. Também é conhecido como CBR22 no contexto de máquina de aprendizagem e KNNR23 no contexto estatístico e é proposto como uma alternativa válida para o julgamento de especialista e métodos paramétricos (LI et al., 2008, p. 176).

Apresenta como vantagem o uso de dados do projeto atual e da experiência passada para a elaboração da estimativa (STSC, 1995, p. A-3).

Devem existir projetos verdadeiramente similares e a acurácia dos dados históricos disponíveis pode ser suspeita (STSC, 1995, p. A-3).

A projeção por analogia normalmente é realizada por profissionais da área de TI que fazem a comparação com situações já vivenciadas em projetos passados. Entretanto, poderia ser utilizada pela área de negócios se características de negócio pudessem ser representadas por evoluções já realizadas anteriormente e pudessem ser adequadamente armazenadas para futuras comparações.

Julgamento de especialista individual (expert)

Com base na experiência individual na construção de soluções de software, o especialista estima o esforço necessário para a elaboração da solução proposta. Jørgensen, 2002 (apud MCCONNELL, 2006, p. 110) declara tratar-se da abordagem de estimativa de custo mais comum e a mais utilizada nos projetos de desenvolvimento de software. O uso de

checklist ajuda na melhora da estimativa individual visto que evita que o especialista esqueça

aspectos a serem considerados.

Bom para projetos novos ou únicos. Além de serem necessários pouco ou nenhum dado histórico.

O nível de conhecimento às vezes é questionável e pode não ser consistente, além de o especialista tender a ser parcial. McConnell (2006, p. 95) aponta que se trata do modelo de

22 _{CBR – Case-Based Reasoning}

menor acurácia.

Esse modelo só pode ser utilizado por especialistas da área de TI, sendo inviável seu uso pelas áreas de negócio, exceto para situações muito padronizadas, como é o caso da indústria da aviação como proposta por Song et al. (2007, p. 409).

Estimativa de cima para baixo (Top-down)

Inicia com a característica geral do projeto de software. O projeto é então particionado em componentes de mais baixo nível e fases do ciclo de vida (STSC, 1995, p. A-4). Uma decomposição hierárquica do sistema em componentes progressivamente menores é utilizada para estimar o tamanho do componente de software.

Dentre as vantagens apresentadas destacam-se: requer menor detalhamento do projeto; considera atividades ao nível de sistema; é mais rápido e fácil de implementar que o método

bottom-up (STSC, 1995, p. A-4); provê uma ligação entre a estimativa e os requisitos; e

permite definir a estimativa para componentes de baixo nível. Norman Fenton e Shari Pfleeger (1997, p.434) reforçam que essa abordagem pode ser utilizada como forma de operacionalizar outros modelos de estimativa.

Por outro lado, apresenta as seguintes desvantagens: tem a tendência de ser menos acurado que outros métodos; tende a negligenciar componentes de baixo nível; provê poucos detalhes para justificar a estimativa (STSC, 1995, p. A-4); é necessário validar os requisitos; dificuldade em localizar a arquitetura; influência da engenharia pode levar a subestimar o esforço necessário.

Embora esse método possa ser utilizado nas fases iniciais do projeto, ainda é necessário que a área de TI seja envolvida frente à necessidade de concluir e validar os requisitos para poder gerar a estimativa da solução ou manutenção.

Estimativa de baixo para cima (Bottom-up)

Indivíduos avaliam cada componente do projeto de software separadamente e as estimativas são somadas para definir a estimativa total.

Tem como vantagens: suportar rastreabilidade direta por endereçar cada atividade do ciclo de vida do desenvolvimento do software (STSC, 1995, p. A-4); estimativas corretas são possíveis por causa da base detalhada de estimativa (BOE24_{); possibilita a definição da}

responsabilidade individual. Tal qual apresentado no modelo top-down, Norman Fenton e

Shari Pfleeger (1997, p. 435) declaram que essa abordagem pode ser utilizada como forma de operacionalizar os outros modelos de estimativa.

Como limitações do método, destacam-se: pode não ser viável quando há limitação de recursos ou de tempo (STSC, 1995, p. A-4); método que consome muito tempo; muitas vezes os custos de integração são desconsiderados; influência da engenharia leva, frequentemente, à subestimação; o detalhamento dos dados pode ainda não estar disponível, principalmente nas fases iniciais do ciclo de vida do processo. Seu uso se limita às fases posteriores ao início do ciclo de vida de software e, portanto, de uso exclusivo pela área de TI, não se enquadrando na proposta deste trabalho de buscar estimativa antes de iniciada a fase de desenvolvimento da manutenção do software.

Projeto pelo custo (Design to cost)

Utiliza a análise de especialista para definir quanta funcionalidade pode ser provida pelo orçamento estabelecido.

É fácil de ser obtido sobre o número de clientes, por outro lado, necessita razoável avaliação dos custos da funcionalidade definida e pode ter pouca base na engenharia.

Para obter a avaliação, é necessário forte envolvimento da área de TI a fim de estabelecer em mais detalhes as funcionalidades e o seu custo, não se enquadrando nas necessidades buscadas de fazer a estimativa antes de iniciada a fase de desenvolvimento sem o envolvimento da área de TI.

Jørgensen e Moløkken (2002, p. 425) apresentam a modalidade de julgamento de especialista em grupo, conforme detalhamento a seguir.

Julgamento de especialista em grupo (expert)

O uso de processo grupal para estabelecer intervalos de estimativa é apresentado por Jørgensen e Moløkken (2002, p. 425) como um mecanismo efetivo para refletir as incertezas inerentes à predição de esforço para os projetos de software.

A estimativa de esforço por meio da discussão em grupo de especialistas alcança resultados bem superiores ao apresentado por especialista individual (MCCONNELL, 2006, p. 154) e o uso de modelos de intervalo de predição como os elaborados pelos grupos de discussão pode melhorar os níveis de confiança nas taxas de acerto (JØRGENSEN; MOLØKKEN, 2002, p. 425).

software, requer o envolvimento de especialistas da área de TI na discussão a fim de identificar os riscos e os aspectos relacionados com a mudança para poder estabelecer o esforço necessário, o que torna inviável o seu uso pelas áreas de negócio, exceto para situações muito padronizadas, como é o caso da indústria da aviação proposta por Song et al. (2007, p. 409).

Linda Laird e Carol Brennan (2006, p. 81-105) apresentam como categorização de metodologias de estimativa, também as que seguem:

Dados de benchmark25

É baseado no conceito de que produtividade é uma função do tamanho e do domínio da aplicação. Por esse modelo, a obtenção da quantidade de linhas de código ou de pontos por função se dá pela divisão do tamanho do projeto pela taxa de entrega

) Pr ( a TaxaEntreg ojeto Tamanho

LOC = . A partir do que tem-se a estimativa de esforço necessário para

construir a solução de software.

Esse modelo está focado na quantidade de esforço necessário para se construir um software mais do que estabelecer seu tamanho. O tamanho é uma das suas entradas, motivo pelo qual ele só pode ser utilizado em fase posterior a do estabelecimento do tamanho do software que ocorre durante a fase de desenvolvimento com envolvimento da área de TI da organização.

Pontos de representação (proxy points)

Define o tamanho de um projeto com base em características externas do sistema tal como telas, entradas ou casos de uso. Há um grande número de métodos, entretanto, os principais são: pontos por função: o primeiro e mais conhecido método dessa classificação;

pontos por objeto (object points): objetos são telas, relatórios objetos 3GL – linguagem de

terceira geração – e são utilizados com o método COCOMO II e normalmente são utilizados para estimar desenvolvimento com ferramentas que suportam 4GL – linguagem de quarta geração; pontos por caso de uso: segunda geração de método, em pesquisas tem-se mostrado tão bom, ou melhor, que a opinião de especialista.

Esses métodos de representação ainda requerem a participação de analista da área de

25 _{Benchmarking - é a busca das melhores práticas na indústria que conduzem ao desempenho superior.}

Enquanto o Benchmarking é o processo de identificação de referenciais de excelência, o Benchmark é o referencial de excelência em si.

TI para indicar as funções, os objetos ou a construção dos requisitos – casos de uso. Considera-se que os casos de uso são construídos com o envolvimento da área de TI.

Modelo algorítmico/paramétrico

O modelo algorítmico também é encontrado com a denominação de “paramétrico”, conforme pode ser visto em Daniel Galorath e Michael Evans (2006, p. 40). O STSC (2008, p. 145-151) classifica esse modelo em:

a) primeira ordem: mais simples, onde se aplica a produtividade sobre o tamanho do software;

b) segunda ordem: compensa a queda de produtividade em grandes projetos pela incorporação de um fator de entropia para contabilizar a mudança de produtividade;

c) terceira ordem: incorpora um conjunto de fatores ambientais para ajustar o fator produtividade para uma ampla gama de problemas.

A abordagem algorítmica utiliza os dados e o desempenho de projetos passados para calibrar e produzir modelos matemáticos (RAMIL, 2000, p. 701) e por meio das fórmulas matemáticas estima o software (STSC, 1995, p. A-4). São apoiados em conjuntos de dados de um certo ambiente. Lembrando que os fatores ambientais são direcionadores de custos significantes. Considera normalmente como entrada o tamanho em LOC ou FP as características do processo ou do projeto.

São baseados em modelos manuais ou apoiados por ferramentas. Os modelos manuais utilizam tipicamente a equação Esforço=A+B*(tamanho)c_{, onde A, B e c são constantes}

empiricamente determinadas e o tamanho é em LOC ou FP. Alguns exemplos de equações utilizando KLOC – linhas de código multiplicadas por 1000 – e FP: Walston-Felix:

Esforço=5,2*(KLOC)0,91, Bailey-Basili: Esforço=5,5+0,73*(KLOC)1,16, Iboehm Simple: Esforço=3,2*(KLOC)1,05, Doty: Esforço=5,288*(KLOC)1,047, Albrect-Gaffney: Esforço=13,39+0,0545*FP, Kemerer: Esforço=60,62+7,728*(10-8)*FP3, Matson-Barret- Meltichamp: Esforço=585,7+15,12*FP.

Conforme pode ser visto no gráfico 14, as equações apresentam significativas diferenças nos resultados e isso ocorre tendo em vista que os modelos são muito simples e utilizam tão-somente LOC para estimativa de esforço. Nesse modelo, sempre que se melhorar a produtividade, a constante B irá decrescer e, quando melhorar o gerenciamento de projetos grandes, a constante C irá decrescer também.

Gráfico 14 – Comparação entre modelos KLOC (LAIRD; BRENNAN, 2006, p.81)

Dentre os modelos de algoritmos, o mais popular e famoso é o COCOMO, desenvolvido por Barry Boehm na década de 1970. A equação do COCOMO I é também dependente do KLOC e possui três equações de esforço, dependendo da classe a que o projeto de software pertence: orgânico: projetos pequenos, ambiente conhecido, equipe pequena e experiente; semi-separado: um misto de projetos de tamanhos médios com média complexidade; embutidos: sistemas que trabalham em ambiente inflexível e limitado. Dependendo do projeto, as equações a serem consideradas estão na tabela 6 a seguir:

Tabela 6 – Equações do Cocomo I.

Classe do Projeto Esforço Duração

Orgânico _2.4* 1.05 KLOC E = D =2.5*E0.38 Semi-Separado _3.0* 1.12 KLOC E = D =2.5*E0.35 Embutido 1.2 * 6 . 3 KLOC E = D =2.5*E0.32

(Fonte: LAIRD; BRENNAN, 2006, p.81)

O Cocomo II foi evoluído a partir das necessidades da aplicação do método em uma gama maior de ambientes e nas novas técnicas de desenvolvimento e abordagens. O modelo é dividido em três grandes estágios (FENTON; PFLEEGER, 1997, p. 441-443):

a) primeiro estágio – composição da aplicação: o projeto normalmente constrói protótipos para resolver aspectos de alto risco envolvendo interação com o usuário, interações com sistemas, desempenho e maturidade tecnológica. Nessa fase pouco é conhecido do tamanho do produto final a ser construído, por isso utiliza a estimativa do tamanho em pontos por objeto;

b) segundo estágio – pré-projeto: no segundo estágio são exploradas as alternativas de arquitetura e conceitos de operação. Nesse estágio são utilizados pontos por função para estimar o tamanho do software a partir dos requisitos gerados;

c) terceiro estágio – pós-arquitetura: esse corresponde ao modelo original do Cocomo, o desenvolvimento iniciou e muito mais informação é conhecida. Nesse estágio muitos fatores de custo podem ser estimados com certo grau de conforto e o tamanho do software pode ser feito em LOC.

Outro modelo estatístico de estimativa muito citado é o SLIM26 _{de Putnam, que utiliza}

coleções de curvas Rayleigh27 _{(gráfico 15) representando a distribuição do esforço envolvido}

no desenvolvimento de projetos de software. Esse modelo não inclui a fase de requisitos e sua utilidade se dá a partir da fase de design e codificação. Ele modelo tem sido muito criticado por utilizar como base uma observação empírica realizada por Norden (FENTON; PFLEEGER, 1997, p. 443-444).

Gráfico 15 – Curvas Rayleigh (PUTNAM, 1978, p. 347)

Ainda dentro dos modelos algorítmicos, há os modelos apoiados por ferramentas. Essas ferramentas utilizam uma estimativa de tamanho, normalmente em LOC ou FP, alguns atributos do projeto e criam o planejamento, a estimativa total do esforço e os custos estimados. Atualmente as principais ferramentas apontadas são: COCOMO, SPR, e

Checkpoint. Essas ferramentas são bastante sofisticadas e utilizam várias técnicas tais como a

de Monte Carlo para a modelagem de análise de risco.

26 _{Software LIfecycle Management – O modelo de Putnam é um modelo empírico de estimativa de esforço de}

software.

27 _{Putnam-Norden-Rayleigh Curve – também conhecida como PNR Curve, é uma curva gráfica derivada de uma}

equação matemática que indica o relacionamento entre o esforço aplicado e o tempo de entrega em relação a um projeto de software.

O modelo estatístico possui muitas vantagens: é hábil para gerar resultados repetíveis; possui facilidade em modificar a entrada de dados; suas fórmulas são facilmente refinadas e customizadas; devido à possibilidade de analisar as fórmulas, o método de estimativa pode ser melhor compreendido (STSC, 1995, p. A-4).

Por outro lado, projetos que utilizam nova tecnologia podem ter os resultados das estimativas questionados e as fórmulas normalmente não conseguem tratar situações excepcionais – pessoas, equipe de trabalho, casamento entre nível de habilidades e tarefas. Além disso, só podem ser calibrados manualmente (KULTUR et al., 2008, p. 331).

Por utilizar a combinação de parâmetros com base na história passada dos projetos, é possível elaborar uma indicação do esforço necessário para realizar uma manutenção. Como a base histórica existe e desde que apoiada em parâmetros adequados, entende-se possível utilizar esse método como solução para o problema deste trabalho.

Modelos customizados

São utilizados para melhorar a estimativa obtida pelos métodos padrões, por meio da introdução de aspectos relacionados com a própria organização ou mesmo pela construção de um modelo próprio de estimativa. Um modelo simples pode ser composto por quatro etapas: decompor os elementos de custo; formular uma teoria de custos; colecionar dados; e correlacionar os dados.

O modelo customizado também se apresenta como alternativa válida para a necessidade apresentada nesse trabalho, visto que a partir da decomposição dos elementos de custos que podem ser obtidos na fase inicial de avaliação, pode-se formular uma teoria de custos e, a partir dos dados colecionados, obter uma correlação válida que permita obter uma estimativa válida.

Finalmente, Kultur et al. (2008, p. 331) relacionando os modelos de estimativa mais utilizados, apresentam também as máquinas de aprendizagem.

Modelos de máquinas de aprendizagem

Esses modelos focam a aprendizagem a partir de projetos passados para a elaboração da estimativa para os projetos futuros e têm sido muito utilizado pelos pesquisadores. Dentre os mais populares modelos destacam-se alguns métodos classificados em outros modelos, mas vale a pena relacioná-los nessa classificação dado à importância da classificação (KULTUR;

a) caso baseado na razão: um dos modelos mais utilizados é a estimativa pela analogia. A similaridade dos projetos pode ser obtida por meio de diferentes abordagens, incluindo

nearest neighbor algorithms28;

b) árvores de regressão: é um modelo hierárquico onde uma região é identificada por meio de uma sucessão de divisões recursivas;

c) algoritmos genéticos: tratam equações de esforço de software como cromossomos. Em um primeiro momento, um conjunto de equações de esforço randômico é gerado. Na sequência, a partir das equações anteriores novas são geradas pela aplicação de operações genéticas para as equações mais acuradas, até que uma equação seja derivada;

d) redes neurais: são aproximadores universais podendo aprender qualquer função. Considerando que o software é composto de um conjunto de características, a partir dos dados passados, a rede neural pode aprender uma função e utilizá-la para estimar o esforço de novos projetos de software.

A base desses métodos é o uso de um conjunto de direcionadores de custos baseados no processo, projeto, pessoas e medidas do produto (SHUKLA; MISRA, 2008, p. 107)

Os métodos de máquina de aprendizagem conseguem lidar bem com condições adversas decorrentes de pessoas, equipe de trabalho e a junção entre habilidade e tarefa. Por outro lado, as redes neurais são estruturas instáveis onde pequena mudança no treinamento gera grandes diferenças no resultado. Excesso de treinamento tem um impacto negativo na acurácia da predição (KULTUR et al., 2008, p. 331).

Esse modelo, similar ao modelo paramétrico e estatístico, apresenta-se como uma boa alternativa para ser utilizado para a elaboração de estimativa precoce de custo de manutenção de software, principalmente por utilizar dados preexistentes para a construção de uma função para estimar a projeção futura. Dentro desse contexto, muitos aspectos relacionados com a complexidade da aplicação, habilidade da equipe, entre outros fatores, já estarão incorporados ao modelo.

Considerados os modelos existentes, é relevante entender quais são os principais elementos preditivos utilizados pelos modelos de estimativa.

28 _{k-nearest neighbors algorithm (k-NN) – é um método para classificar objetos baseado na proximidade}