COnstructive COst MOdel - COCOMO II
O que é Cocomo II?
Constructive Cost Model é um modelo paramétrico, criado pela USC - University of Southern California, que permite calcular o esforço, o custo e o prazo de um projeto através de equações matemáticas complexas que levam em consideração particularidades de cada projeto como: características do Produto, Processo, Experiência da Equipe e Plataforma de Desenvolvimento.
Esses fatores são denominados Cost Drivers, sendo alguns de efeito linear e outros de efeito exponencial.
Para implantar este modelo, as Organizações precisam de uma base histórica de projetos, suficiente para estudos estatísticos. Normalmente as empresas iniciam o uso do COCOMO II quando as técnicas de estimativas de projetos como APF e NESMA já estão consolidadas.
Conheça um pouco mais do COCOMO II
Início do COCOMO II
Para atender às necessidades de um modelo de custo de projeto de software
mais adequado às práticas de ciclo de vida de software dos anos 1990 e 2000, teve
início, em 1994, o projeto COCOMO II, com o objetivo de desenvolver um modelo de
custo mais atualizado que os modelos antecessores, o COCOMO original e o Ada
COCOMO.
A maioria das referências ao COCOMO encontradas na literatura publicadas a
partir de 1995 referem-se ao COCOMO II. Se os termos utilizados no contexto da
discussão no modelo COCOMO forem: Básico, Intermediário ou Detalhado, para
nomes dos modelos; Orgânico, Semidestacado ou Embutido, para “modo de
desenvolvimento”, o modelo apresentado refere-se ao COCOMO original,
apresentado em 1981. Todavia, se os nomes mencionados dos modelos forem
Application Composition, Early Design, ou Post-architecture; ou ainda, se forem
mencionados “fatores de escala”, o modelo discutido é o COCOMO II.
O projeto COCOMO II foi uma iniciativa da University of Southern
California, contando inicialmente com a colaboração das empresas Bellcore, da Texas
Instruments e da Xerox Corporation como membros afiliados e posteriormente com
os seguintes membros: Air Force Cost Analysis Agency, Allied Signal, AT&T,
Bellcore, EDS, E-Systems, Hughes, IDA, Litton, Lockheed, Martin, Loral, MCC,
MDAC, Motorola, Northrop Grumman, Rational, Rockwell, SAIC, SEI, SPC, SUN,
TI, TRW, USAF Rome Lab, US Army Reserach Labs e Xerox.
Para direcionar os trabalhos do projeto COCOMO II, foi levado em
consideração um estudo da estimativa do futuro das práticas e dos setores de software
para a próxima década de desenvolvimento.
Segundo o estudo, por volta do ano 2005 haverá uma grande participação do
setor de Programação de Usuário Final, com aproximadamente 55 milhões de
praticantes nos Estados Unidos e um setor básico, o setor de Infra-estrutura, que
contará com cerca de 750 mil praticantes.
Três setores serão intermediários: Geradores de Aplicações e Auxiliares de
Composição (600 mil praticantes); Composição de Aplicações (700 mil praticantes); e
Integração de Sistemas de Grande Escala e/ou Sistemas de Software Embutidos (700
mil praticantes).
COCOMO II – APPLICATION COMPOSITION
O modelo Application Composition foi projetado especificamente para o setor
Composição de Aplicações, cujas aplicações são desenvolvidas por equipes pequenas
em poucas semanas ou meses.
O modelo foi projetado para prever esforço de prototipação envolvido no uso
de ambientes integrados de composição rápida de aplicações de software auxiliados
por computador ou ICASE – Integrated Computer Aided Software Environment
(ambientes construtores de GUI, ferramentas de desenvolvimento de software, etc.).
O modelo prevê a contagem de Pontos de Objeto, uma nova abordagem de
medição de tamanho de software para estimar custo e prazo de projetos. Pontos de
Objeto são um tipo de contagem funcional de telas, relatórios e de módulos de
linguagem de terceira geração, onde cada um dos elementos contados recebe uma
classificação em níveis de complexidade (simples, média e alta).
Segundo os projetistas do COCOMO II, estimativas de Pontos de Objeto
foram comparadas a estimativas de Pontos de Função e mostraram resultados mais
adequados aos tipos de aplicação a que se destina o modelo Application Composition
[COCOMOII, 2000].
O procedimento para contagem de Pontos de Objeto apresentado no
COCOMO II para estimativa de esforço referente a projetos de composição de
aplicações e prototipação é uma síntese do procedimento efetuado por Kauffman e
Kumar e de dados de produtividade de 19 projetos [COCOMOII, 2000].
Para a contagem de Pontos de Objeto, as seguintes etapas deverão ser seguidas:
1. Efetuar contagens de objetos: estimar o número de telas, relatórios e componentes de 3GL que
constituirão a aplicação. Deve-se assumir as definições padrões desses objetos no ambiente ICASE
utilizado.
2. Classificar cada instância de objeto segundo sua complexidade (nível simples, médio ou difícil),
dependendo dos valores das dimensões características.
3. Atribuir um número para cada atributo utilizando-se a Tabela 12. Os pesos refletem o esforço
relativo necessário à implementação.
4. Determinar os Pontos de Objeto. Somar todos os pesos para obter o total de Pontos de Objeto.
5. Estimar a porcentagem de reuso esperada no projeto que está sendo contado. Computar os novos
Pontos de Objeto (NOP) que serão desenvolvidos utilizando-se a Equação 4. O modelo para
cálculo de reuso está detalhado em [COCOMOII, 2000].
6. Determinar a taxa de produtividade utilizando-se a Equação 5. A taxa de produtividade é estimada
analisando-se a média subjetiva da experiência dos desenvolvedores e da maturidade com o uso de
ICASE (Tabela 13).
7. No modelo COCOMO II, o esforço é expresso em pessoas/mês.
COCOMO II – EARLY DESIGN
As etapas posteriores às fases iniciais de projetos ou ciclos de vida espirais
podem requerer a pesquisa de arquiteturas alternativas ou estratégias de
desenvolvimento incremental. O modelo Early Design do COCOMO II foi
desenvolvido para elaborar estimativas iniciais e apoiar essas atividades.
O nível de detalhes que o modelo utiliza é consistente com o nível de
informações disponíveis e com o nível de precisão necessário nessa fase. As
principais variáveis de entrada para o modelo são: o tamanho estimado do sistema e
os direcionadores de custo.
O tamanho da aplicação que vai ser desenvolvida é a principal variável de
entrada para cálculo de esforço e tempo. Derivado da estimativa do tamanho dos
módulos de software que irão constituir a aplicação ou programa, o tamanho deve ser
expresso em unidade de milhares de linhas de código (KLOC).
O modelo Early Design permite que o tamanho da aplicação possa ser
estimado em pontos de função não ajustados, posteriormente convertidos em linhas de
código pelo modelo. Pontos de função podem ser utilizados como boas estimativas
porque são baseados em informações que estão disponíveis logo no início do ciclo de
vida do projeto.
Pontos de função medem o tamanho funcional de um projeto de software
através da quantificação da informação da funcionalidade de processamento da
aplicação. Para contar pontos de função, cinco tipos de funções ou componentes
lógicos da aplicação devem ser avaliados: Arquivos Lógicos Internos (ALI), Arquivos de Interface Externa (AIE), Entradas Externas (EE), Saídas Externas
(SE) e Consultas Externas (CE).
Depois de identificadas, cada uma das funções deve ser classificada quanto à
sua complexidade funcional relativa: simples, média ou complexa
10
. Em seguida,
calcula-se os pontos de função brutos ou não ajustados – métrica de tamanho
utilizada pelo COCOMO II – através da aplicação de pesos de acordo com tabelas
específicas para cada tipo de função.
O processo usual de contagem de pontos de função prevê o ajuste dos pontos
de função contados, aplicando-se um fator obtido na avaliação do grau de
influência de 14 características de projeto de software, tais como volume de
transações, performance e atualização on-line do sistema.
O COCOMO II utiliza apenas os pontos de função não ajustados para estimar
o tamanho da aplicação porque o grau de contribuição das 14 características do
projeto no esforço estimado é considerado inconsistente com a experiência do
COCOMO.
A contagem de pontos de função não ajustados do COCOMO II deve ser
realizada de acordo com o processo descrito a seguir. Esse processo pode ser utilizado
nos modelos Early Design e Post-Architecture.
1. Determinar os tipos de função. A contagem de pontos de função não ajustados deve ser efetuada
por uma pessoa treinada na técnica de pontos de função, baseando-se na informação
disponibilizada no documento de requisitos do software e nos documentos do projeto disponíveis
(modelo de entidade-relacionamento, layouts de telas, relatórios, etc).
2. Determinar o nível de complexidade das funções contadas. Classificar cada função em um nível de
complexidade (Baixa, Média ou Alta), dependendo do número de elementos de dados contidos e
do número de tipos de arquivos referenciados. A Tabela 14 deve ser utilizada.
3. Aplicar pesos de acordo com a complexidade. Um número deve ser atribuído para cada tipo de
função.
4. Computar os pontos de função não ajustados. Totalizar todas as contagens dos tipos de função para
obter o total de pontos de função não ajustados.
Para determinar a quantidade de pessoas/mês, os pontos de função não ajustados devem ser
convertidos em linhas de código, de acordo com a linguagem de implementação escolhida (Assembly,
linguagem de Quarta-Geração, etc.). Os modelos Early Design e Post-Architecture utilizam uma tabela
para converter pontos de função não ajustados na quantidade equivalente de linhas de código.
O modelo Early Design utiliza um conjunto reduzido de direcionadores de
custo. Esses direcionadores de custo foram obtidos através da combinação dos
direcionadores de custo do modelo Post-Architecture.
As escalas correspondentes e os multiplicadores de esforço dos direcionadores
de custo do modelo Early Design mantém relacionamento consistente com os
direcionadores combinados do modelo Post-Architecture, para assegurar a
consistência das estimativas dos dois modelos.
O mapeamento dos direcionadores de custo e escalas de classificação do
modelo Post-Architecture para o modelo Early Design, foi feito com o uso e
combinação de equivalentes numéricos do níveis de classificação.
Os valores numéricos dos direcionadores de custo do modelo PostArchitecture
(Muito Baixa corresponde a uma classificação numérica de 1, Baixa é 2,
Nominal é 3, Alta é 4, Muito Alta é 5 e Extra Alta é 6) foram somados e os totais
resultantes foram distribuídos em uma escala de classificação expandida, que varia de
Extra Baixo até Extra Alto.
O direcionador de custo RCPX combina quatro direcionadores de
custo: Confiabilidade Requerida do Software (RELY), Tamanho da Base de Dados
(DATA), Complexidade do Produto (CPLX) e Documentação adequada às
necessidades do ciclo de vida (DOCU).
O direcionador de custo RUSE é o mesmo direcionador do modelo PostArchitecture.