Primeira camada

O principal direcionador em uma estimativa de software é o tamanho do software a ser construído, visto que o tamanho, mais que qualquer outro fator, possui a maior variação (MCCONNELL, 2006, p. 57; STSC, 2008, p. 4; FENTON; PFLEEGER, 1997, p. 446; SNEED; HUANG, 2007, p. 172).

O gráfico 12 demonstra o crescimento linear do tamanho de um software e a quantidade de esforço necessário para desenvolvê-lo. Percebe-se que, diferentemente dos demais ramos de indústria, quanto mais cresce o tamanho do projeto de software mais recursos são necessários para o seu desenvolvimento. Esse crescimento chega a atingir 300 vezes – pior caso –, quando considerado o esforço necessário para um projeto de 1.000.000 de

LOC, quando comparado ao esforço necessário para um projeto de 10.000 LOC.

Gráfico 12 – Esforço x crescimento do tamanho do software (MCCONNELL, 2006, p.67)

Esse fator é denominado “deseconomia” da escala em oposição à economia de escala que normalmente é gerada pela redução de custos que o tamanho normalmente proporciona (MCCONNELL, 2006, p. 68) em outras indústrias.

McConnell (2006, p. 68) apresenta o resultado da análise realizada por diferentes estudos que reforçam a queda da produtividade média quando há aumento no tamanho do software: de 3.200 LOC por homem/ano para projetos com 10.000 LOC para 1.600 LOC para projetos com 10.000.000 LOC.

Fenton e Pfleeger (1997, p. 446) declaram não haver consenso sobre o exato relacionamento entre esforço e tamanho do software. Sugerem que o relacionamento entre o tamanho do software e o esforço pode ser representado pela equação:

a tamanho

Esforço= b× Onde:

tamanho = tamanho do software

b = constante ajustável em função da deseconomia de escala a = constante representativa do esforço

Sendo que a constante b, em alguns estudos, é levemente superior a 1, devido à deseconomia de escala, enquanto para outros o valor é igual a 1. Por outro lado, alguns construtores de modelos apresentam que a duração ótima de um projeto é proporcional a raiz cúbica do esforço (_{duração =}3 _{Esforço) (FENTON; PFLEEGER, 1997, p. 446).}

Norman Fenton e Shari Pfleeger (1997, p. 245) sugerem que o tamanho do software pode ser descrito por meio dos seguintes atributos:

a) comprimento: tamanho físico do produto, normalmente medido em LOC ou KLOC ou comandos (SNEED; HUANG, 2007, p.172);

b) funcionalidades: quantidade de funcionalidades fornecidas para o usuário do produto, normalmente medido em pontos por função (FP19), pontos por objeto (OP20) e apontado por Sneed e Huang (2007, p. 172), pontos por caso de uso;

c) complexidade: pode ser medida de diferentes perspectivas: complexidade do problema, do algoritmo, da estrutura ou cognitiva, também apontada por Hirota et al. (1994, p. 439), como de compreensão;

d) reuso: quanto do software foi reutilizado de outro software existente.

Os autores apontam ainda que, para estimativas prévias, é importante considerar o tamanho dos documentos resultantes do processo de desenvolvimento de software, tais como: especificação e design, além do código. Sneed e Huang (2007, p.172) relacionam também o fator qualidade como relevante para definir o tamanho do esforço da manutenção.

Tipo de software

O segundo fator que influencia a estimativa é o tipo de software que está sendo desenvolvido. Um software de missão crítica, onde há vida em jogo, requer muito maior esforço que o desenvolvimento de um sistema de negócios. A tabela 3 demonstra exemplos de linhas de código por homem mês para diferentes tipos de projetos de software. Pelos exemplos, pode ser percebido que uma equipe de desenvolvimento de sistemas internos de intranet deve gerar código de 10 a 20 vezes mais rápido que uma equipe desenvolvendo um software para a indústria aviônica. Essa mesma tabela demonstra a deseconomia da escala, ou seja, quanto maior o tamanho do software, menor a produtividade, independente do tipo de software (MCCONNELL, 2006, p. 70).

19 _{Function Point (FP) – Pontos por função - é uma unidade de medida para expressar o conjunto de}

funcionalidades de negócios providos por um sistema de informação para um usuário.

20 _{Object Points – pontos por objeto: 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 (LAIRD; BRENNAN, 2006, p.81-105).

Tabela 3 – Taxa de produtividade para tipos de projetos comuns

(Fonte: MCCONNELL, 2006, p.70) Fatores pessoais

O terceiro fator da primeira camada é o composto pelos fatores pessoais que geram significativa influência nos resultados do projeto. Dentre esses fatores, destacam-se: capacidade dos analistas de requisitos, capacidade dos programadores, turnover do pessoal, experiência na aplicação do negócio, experiência na linguagem e ferramenta, experiência na plataforma e coesão da equipe. De acordo com o modelo Cocomo II, os efeitos provocados pelos fatores pessoais podem variar a estimativa em um fator de até 22 vezes do esforço total se considerado o pior e o melhor grau de cada categoria.

Para exemplificar a importância dos fatores pessoais na estimativa dos projetos, apresenta-se a seguir o gráfico 13 com o percentual de participação de cada elemento na composição dos custos do projeto. Um projeto que tenha na sua composição os piores

analistas de requisitos requer 42% mais esforço que o nominal, enquanto um projeto com os melhores analistas requer 29% menos esforço que o nominal (MCCONNELL, 2006, p. 70).

Gráfico 13 – Esforço a ser considerado no projeto com base no aspecto pessoal (MCCONNELL, 2006, p.72)

Linguagem de programação

O quarto fator da primeira camada é a linguagem de programação que afeta a estimativa em pelo menos quatro modos (MCCONNELL, 2006, p. 73):

a) experiência com a linguagem e ferramenta: equipes com experiência na linguagem específica e na ferramenta que serão usados no projeto de software tem um impacto de 40% na taxa de produtividade média do projeto;

b) produtividade da linguagem: algumas linguagens geram mais funcionalidade por linhas de códigos que outras. A tabela 4 apresenta um comparativo das linguagens frente ao desenvolvimento da linguagem C;

Tabela 4 – Equivalência entre declarações de linguagem de alto nível e a linguagem C.

Linguagem Nível Relativo à Linguagem C

C 1 para 1 C# 1 para 2,5 C++ 1 para 2,5 Cobol 1 para 1,5 Fortran 95 1 para 2 Java 1 para 2,5

Linguagem Nível Relativo à Linguagem C

Macro Assembly 2 para 1

Perl 1 para 6

Smalltalk 1 para 6

SQL 1 para 10

Visual Basic 1 para 4,5

Origem: Adapted from Estimating Software Costs (Jones 1998) and Software Cost Estimation with Cocomo II (Boehm 2000).

(Fonte: MCCONNELL, 2006, p. 73)

c) suporte da ferramenta: o uso de ferramentas que apresentam forte suporte à linguagem e ao ambiente proporciona, de acordo com o COCOMO II, uma redução na ordem de 50% do esforço total do projeto;

d) linguagens interpretadas apresentam um fator de produtividade maior, na ordem de 2 vezes, quando comparadas às linguagens compiladas.