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.

The best solution in software measurement

APF Métricas Treinamentos & Consultoria
Unidade São Paulo
Rua das Olimpíadas, 205 - Continental Square - 4o. andar - Vila Olímpia - São Paulo - SP
Rua das Grumixamas, 99 - Link Office Jabaquara - 7o. andar - cj. 702 - Jabaquara - São Paulo - SP - Tel. (11) 3588-0227
Unidade Brasília
Setor Comercial Norte - Quadra 2 - Corporate Financial Center - Bloco A - Cj.503/504 - Asa Norte - Brasilia - DF - Tel. (61) 3246-0227
Unidade Curitiba
Rua Comendador Araújo, 499 - Curitiba Corporate Evolution Tower - 10°andar - Curitiba - PR - Tel. (41) 3012-0227

Tags: cocomo

Home - Empresa - Missão - Benefícios - Diferencial - Treinamentos - Consultoria - Fábrica - APF - NESMA - IFPUG - Usuários - APF no Governo - Certificação


Desenvolvido pela WebDesign Arte Digital

Todos os Direitos Reservados a APF Métricas Serviços em Informática Ltda.