O Modelo Early Design

O modelo Early Design é usado para avaliar arquiteturas alternativas de sistema/software e conceitos de operação. Uma contagem de pontos de pontos de função não ajustados (UFC) é usada para estimar tamanho. Este valor é convertido para SLOC usando tabelas tais como a Tabela 2.17 [Stutzke-05] [Boehm-00].

Linguagem Mínimo (Desvio padrão -1)

Moda (Valor mais comum)

Máximo (Desvio padrão +1) C 60 128 170 C++ 40 55 140 C# 40 55 80 Cobol 65 107 150 Java 40 55 80 Perl 10 20 30 SQL 7 13 15 MS Visual Basic 15 32 41

Tabela 2.17 – Quantidade de linhas de código fonte por ponto de função por linguagem [Stutzke-05] [Boehm-00]

Desta forma se você tem um sistema de 284 pontos de função para implementar em Java, você poderia variar de 40 a 80 SLOC por ponto de função, multiplicando este valor por 284 para chegar em uma estimativa de tamanho de 11.360 a 22.270 SLOC, com um valor esperado de 55 vezes 284, ou 15.675 pontos de função. Para evitar um falso senso de acurácia, você pode simplificar estes números para 11.000 a 23.000 SLOC, com um valor esperado de 16.000 SLOC. Estes valores podem ser utilizados conforme a Figura 2.11 [ISBSG-07] indica, devendo os valores serem considerados de acordo com as características do projeto.

Centro de Informática – UFPE Página 46

Figura 2.11 – Aplicação Valores SLOC de Acordo com Características de Projeto [ISBSG-07]

A equação do modelo Early Design é:

E = a * KSLOCb * EAF

Onde E é o esforço em pessoas-mês, a é uma constante, definida como 2,94 e b é calculado como:

b = 1,01 + 0,01 * SUM(SFi)

Onde SF é o conjunto dos 5 fatores de escala mostrados na Tabela 2.18 [Boehm-00]. Fator de Escala

(SF) Muito Baixo Baixo Nominal Alto Muito Alto Extra Alto

PREC Reflete a

experiência prévia da organização com este tipo de projeto

Totalmente sem precedentes Praticamente sem precedentes Poucos precedentes Alguma familiaridade Muito familiar Totalmente familiar

FLEX Reflete o nível

de flexibilidade no processo de desenvolvimento. Rigor e inflexibilidade exagerados Alto grau de rigor e inflexibilidade Rigor moderado Alguma flexibilidade, com padrão Boa flexibilidade, com padrão Metas gerais, dentro de padrões normais RESL Reflete a extensão da análise de riscos realizada. Especificações são apenas 20% do necessário 40% 60% 75% 90% 100% sob domínio

TEAM Reflete quão

bem o time de desenvolvimento se conhece e trabalha em conjunto. Interações muito difíceis Algumas dificuldades de interação Interações cooperativas básicas Boa interação Altamente cooperativa Interação total PMAT Reflete a maturidade do processo de desenvolvimento da organização. CMM 1 (baixo) CMM 1 (alto) CMM 2 CMM 3 CMM 4 CMM 5

Tabela 2.18 – Fatores de Escala COCOMO II [Boehm-00]

Estimativa (Mediana)

Mais Baixa Mais Alta

Projetos neste limite de variação podem refletir um contexto de mais baixo risco, por exemplo:

•Time experiente

•Gerente de Projeto experiente •Tecnologia conhecida •Cliente comprometido •Entrega em apenas um site

•Requerimentos detalhados acordados

Projetos neste limite de variação podem refletir um contexto de mais alto risco, por exemplo:

•Time inexperiente

•Gerente de Projeto inexperiente •Tecnologia nova

•Cliente descomprometido •Entrega em diversos sites •Requerimentos vagos

Centro de Informática – UFPE Página 47 A valoração dos fatores de escala é realizada atribuindo os valores 0 (Muito Baixo), 1 (Baixo), 2 (Nominal), 3 (Alto), 4 (Muito Alto) e 5 (Extra Alto).

A técnica COCOMO II foi originalmente calibrada com dados de 161 projetos. Os mesmos foram selecionados entre 2000 projetos candidatos. Para cada um dos 161 projetos escolhidos foram realizadas entrevistas e visitas, a fim de garantir a consistência das definições e suposições da técnica. Com base nesta calibragem, Boehm propos que o coeficiente a deveria ser 2,94. O tamanho do sistema é expresso em KSLOC, que é o número de milhares de linhas de código fonte.

O expoente b reflete o aumento de esforço requerido quando o tamanho do projeto aumenta. Ele não é fixo para diferentes tipos de Sistemas, como em COCOMO 81, mas pode variar de 1,01 a 1,26 dependendo da experiência prévia da organização com este tipo de projeto, a flexibilidade do processo de desenvolvimento, a extensão da análise de riscos realizada, a coesão do time de desenvolvimento e a maturidade do processo de desenvolvimento da organização. Isto reflete os níveis de complexidade do projeto. Enquanto os projetos vão se tornando mais complexos, os efeitos de aumentar o tamanho do sistema se tornam mais significativos. Contudo, boas práticas e procedimentos organizacionais podem controlar esta “deseconomia de escala”. Isto é reconhecido em COCOMO II, onde o intervalo de valores para o expoente b é contínuo ao invés de discreto.

A partir do valor de b, podem-se capturar os efeitos do projeto e chegar às seguintes premissas:

b < 1,0: O projeto apresenta economia de escala. Se porventura o tamanho do produto

dobra, o esforço relativo ao projeto é menor que o dobro. A produtividade do projeto aumenta à medida que aumenta o tamanho do produto. Podem-se alcançar algumas economias de escala do projeto com ferramentas de projeto específicas. Para projetos pequenos, fixar custos de saída, tais como reuniões periódicas e ainda relatórios administrativos, são a rigor uma fonte de economia.

b = 1,0: As economias e gastos estão em um nível de equilíbrio. Este modelo linear é

Centro de Informática – UFPE Página 48

b > 1,0: O projeto apresenta gastos de escala. Isto se deve normalmente a dois fatores

principais: o crescimento do gasto em comunicações e o gasto em crescimento da integração de um grande sistema. Os projetos maiores alocam mais recursos humanos, e conseqüentemente uma maior comunicação e iteração interpessoal produzindo despesas. Integrar um produto pequeno como parte de um maior não requer apenas esforço de desenvolver o produto pequeno como também a despesa adicional de esforço para projetar, manter, integrar e testar suas interfaces com o resto do produto.

O expoente b é obtido através dos fatores de escala. A seleção dos fatores de escala é embasada na razão de que são recursos significativos de variação exponencial de esforço ou variação da produtividade do projeto. Cada fator tem um intervalo de níveis de valores que vão desde Muito Baixo até Extra Alto, conforme é apresentado na Tabela 2.18. Cada nível de valores possui um peso, SF, e o valor específico do peso é chamado Fator de Escala. Um fator de escala de um projeto é calculado realizando o somatório de todos os fatores e é utilizado para determinar o expoente b.

A calibragem da técnica para um ambiente específico consiste no ajuste da constante a, que indica o percentual de reutilização de código. O objetivo da calibragem é obter a distribuição da produtividade e atividade de desenvolvimento para um ambiente específico. Embora o COCOMO II possa ser executado com os parâmetros nominais, sua correta utilização pressupõe a calibragem para o ambiente-alvo. Com a calibragem em projetos do mesmo ramo é possível modificar o valor das constantes das fórmulas padrões. Na ausência de dados históricos disponíveis para o ambiente-alvo em questão, devem ser selecionados projetos equivalentes para efetuar a calibração. Os dados históricos selecionados devem ser validados antes de sua utilização, calculando os coeficientes calibrados e, posteriormente, verificando se a diferença percentual (estimado – real)/estimado encontra-se compatível com o nível de erro pretendido para as estimativas. Devido ao seu impacto exponencial, não é recomendável calibrar a técnica quando houver menos de 10 projetos disponíveis para a calibração [Boehm-00]. A calibragem é suportada por ferramentas de software, alimentadas com dados históricos da organização.

Centro de Informática – UFPE Página 49 O fator de ajuste de esforço (EAF) é calculado como na técnica original COCOMO, usando os sete direcionadores de custo mostrados na Tabela 2.19 e Tabela 2.20 [Boehm-00]. O produto de todos os direcionadores de custo é o EAF. Os direcionadores de custo Early Design são obtidos pela combinação dos direcionadores Post-Architecture mostrados na Tabela 2.21 [Boehm-00]. O detalhamento dos direcionadores de custo do COCOMO II pode ser consultado no Apêndice B.

Direcionador de

Custo Descrição

Direcionador de Custo Post- Architecture Combinado

RCPX Confiabilidade e complexidade do produto RELY, DATA, CPLX, DOCU

RUSE Reutilização requerida RUSE

PDIF Dificuldade da plataforma TIME, STOR, PVOL

PERS Capacidade do pessoal ACAP, PCAP, PCON

PREX Experiência do pessoal AEXP, PEXP, LTEX

FCIL Facilidades (uso de ferramentas de software e _{desenvolvimento multi-local)} TOOL, SITE SCED Cronograma (restrição de cronograma imposta ao _{time de projeto)} SCED

Tabela 2.19 – Direcionadores de Custo Early Design [Boehm-00]

Fator de Escala

Extra Baixo

Muito

Baixo Baixo Normal Alto

Muito Alto Extra Alto RCPX Disponibilidade de produto e complexidade 0,73 0,81 0,98 1 1,30 1,74 2,38

RUSE Reutilização requerida 0 0 0,95 1 1,07 1,15 1,24

PDIF Dificuldade da plataforma 0 0 0,87 1 1,29 1,81 2,61

PERS Capacidade do pessoal 2,12 1,62 1,26 1 0,83 0,63 0,50 PREX Experiência do pessoal 1,59 1,33 1,12 1 0,87 0,71 0,62

FCIL Facilidades 1,43 1,30 1,10 1 0,87 0,73 0,62

SCED Cronograma 0 1,42 1,14 1 1 1 0

Centro de Informática – UFPE Página 50