COCOMO - brhott.files.wordpress.com · O Modelo COCOMO Intermediário estima o esforço do desenvolvimento de software utilizando atributos que levam em conta:

COCOMO

Bruno Hott

Bruno Hott - DECSI/UFOP 2

Revisão:Estimando o tamanho do projeto

● Medidas mais comuns: Pontos de Função (PF) e Linhas de Código (LOC)

● Vantagem do PF sobre LOC é que os Pontos de Função podem ser obtidos logo no início do ciclo de vida, diretamente dos requisitos ou especificações.

● Os PF são úteis para estimativas independentes de linguagem, realizadas no início do ciclo de vida do projeto.

● Por outro lado, a utilização das LOC na previsão do esforço total de um projeto continua tendo sucesso para uma ampla quantidade de projetos, envolvendo diversas linguagens


NESMA: Early FPA Counting

● A NESMA reconhece três tipos de contagem de pontos de função:

– contagem de pontos de função detalhada

– contagem de pontos de função estimativa

– contagem de pontos de função indicativa

● Os métodos estimativo e indicativo para a contagem de pontos de função foram desenvolvidos pela NESMA para permitir que uma contagem de pontos de função seja feita nos momentos iniciais do ciclo de vida de um sistema. A contagem indicativa da NESMA é também conhecida no mundo como "método holandês".


NESMA:Contagem detalhada de pontos de função

● A contagem (detalhada) de pontos de função:

– determina-se todas as funções de todos os tipos (LIF, EIF, EI, EQ, EO)

– determina-se a complexidade de cada função (Baixa, Média, Alta)

– calcula-se o total de pontos de função não ajustados


NESMA:Contagem estimativa de pontos de função

● A contagem estimativa é realizada da seguinte forma:

– determina-se todas as funções de todos os tipos (LIF, EIF, EI, EQ, EO)

– toda função do tipo dado (LIF, EIF) tem sua complexidade funcional avaliada como Baixa, e toda função transacional (EI, EQ, EO) é avaliada como de complexidade média

– calcula-se o total de pontos de função não ajustados

● Logo, a única diferença em relação à contagem usual de pontos de função é que a complexidade funcional não é determinada individualmente para cada função, mas pré-definida para todas elas.


NESMA:Contagem indicativa de pontos de função

● A contagem indicativa de pontos de função:

– determina-se a quantidade das funções do tipo dado (LIFs e EIFs)

– calcula-se o total total de pontos de função não ajustados da aplicação da seguinte forma:

– tamanho indicativo (pf) = 35 x número de LIFs + 15 x número de EIFs

● Portanto esta estimativa é baseada somente na quantidade de arquivos lógicos existentes (LIFs e EIFs)

● A contagem indicativa é baseada na premissa de que existem aproximadamente três EIs (para adicionar, alterar, e excluir dados do ALI), duas EQs, e uma EO na média para cada ILF, e aproximadamente uma EQ e uma EO para cada EIF.


NESMA:Resultados da pesquisa feita com mais de 100 projetos


NESMA:Resultados da pesquisa feita com mais de 100 projetos


Revisão:Estimando o Esforço e o Prazo

● Modelos Paramétricos – Assumem a existência de uma relação matemática entre tamanho, esforço e prazo. Tal relação é afetada por parâmetros de performance. Os relacionamentos são baseados em suposições teóricas e/ou dados históricos. Exemplos de modelos paramétricos são COCOMO (COnstructive COst Model) e SLiM (Software Life Cycle Model) .

● Modelos Baseados em Atividades – Também chamada estimativa bottom-up, esta modalidade consiste em enumerar todas as atividades do projeto e estimar o esforço e prazo para cada uma delas.

● Analogia – Esta técnica baseia-se na comparação das características do projeto com a de outros projetos concluídos. As diferenças são identificadas, sendo introduzidas as mudanças necessárias para produzir as estimativas.

● Relações Simples de Estimativas – Trata-se de uma simplificação dos modelos paramétricos. Neste caso, utilizam-se relações matemáticas simples, baseadas em dados históricos locais, ao invés de modelos matemáticos abrangentes. De uma forma geral, os relacionamentos deste tipo não são aplicáveis a organizações e contextos diferentes dos originalmente utilizados para a coleta dos dados. Exemplo: Estimar o esforço a partir de um modelo linear do tipo Esforço = Tamanho x Produtividade.


Revisão:Estimando o Esforço e o Prazo

● Normalmente, faltam dados históricos que permitam a utilização de uma abordagem simplificada. Nesse caso, pode ser interessante optar por um modelo paramétrico. Os modelos paramétricos mais amplamente utilizados para a determinação do esforço são o COCOMO (atualmente em sua segunda versão) e o SLIM


COCOMO:Introdução

● COCOMO é um dos modelos de estimativa de software mais amplamente utilizado no mundo

● Desenvolvido por Barry Boehm em 1981

● COCOMO estima o esforço e prazo para o desenvolvimento de um produto baseado em entradas que relacionam o tamanho do software e alguns direcionadores de custo que afetam a produtividade


COCOMO:Modelo

● COCOMO é baseado em uma medida física (linhas de código fonte)

● Estimativas se tornam mais precisas ao longo do desenvolvimento

● Erros de estimativas:

– Estimativas iniciais podem estar erradas por um fator de 4x

– Ao longo do processo de desenvolvimento, as estimativas se tornam mais precisas (e o modelo leva em conta parametros mais detalhados)


COCOMO:Estrutura Geral

● Todos os modelos COCOMO possuem a mesma estrutura básica

● OUTPUT pode ser esforço ou tempo

● A medida fundamental é o tamanho do código (expresso em número de linhas de código

● O tamanho do código tem um efeito exponencial no esforço (porém é bem próximo de 1)

● Vários fatores de ajuste são usados para fazer com que o modelo seja mais preciso

OUTPUT=A⋅(size)B⋅M


COCOMO:

● 1 pessoa-mês = 152 horas de trabalho

● SLOC = DSI (Delivered Source Instructions)

– Apenas o código entregue ao cliente. Isto é, não contam testes de unidades, código de conversão, utilidades, etc.)


COCOMO 81


COCOMO 81:Três modelos

● Modelo básico:

– Estimativa rápida

– Utilizado nos primeiros estágios de desenvolvimento

● Modelo Intermediário:

– Mais acurado, necessita de mais características do produto

– Utilizado em estágios mais avançados de desenvolvimento

● Modelo Detalhado:

– Mais detalhado, requer mais informação


COCOMO 81:Tipos de projetos

● Modo Orgânico (Organic)

– Equipes pequenas, ambiente familiar, aplicações bem entendidas, similar aos projetos previamente desenvolvidos, requisitos simples, relativamente pequeno e requer pouca inovação (FÁCIL)

● Modo Semidestacado (Semidetached)

– Equipe do projeto tem experiências diversas, requisitos mais complexos, organização possui menos familiaridade com a aplicação (MÉDIO)

● Modo Embutido (Embedded)

– Requisitos rigorosos e inflexíveis, produto requer grande inovação, equipe não possui nenhuma familiaridade ou experiência (DIFÍCIL)


Os modos de desenvolvimento:características do projeto

Development Mode

Project Characteristics

Size Innovation Deadline/ constraints

Dev. Environment

Organic Small Little Not tight Stable

Semi-detached Medium Medium Medium Medium

Embedded Large Greater Tight Complex


Equações

Basic COCOMO a b c

Organic 2.4 1.05 0.38

Semi-detached 3.0 1.12 0.35

Embedded 3.6 1.20 0.32

MM=a×(KDSI)b

TDEV=2.5×(MM )c


Efeito exponencial do COCOMO


Exemplo

● Foi determinado que o projeto se enquadra na características do modo Semi-destacado.

● Foi estimado que o projeto terá 32000 DSI. Utilizando as fórmulas, pode-se estimar:


Exemplo

● Foi determinado que o projeto se enquadra na características do modo Semi-destacado.

● Foi estimado que o projeto terá 32000 DSI. Utilizando as fórmulas, pode-se estimar:

● Esforço: 3.0*(32)1.12 = 146 pessoa-mês

● Prazo: 2.5*(146)0.35 = 14 meses

● Produtividade: 32.000 / 146 = 219 DSI/pm

● Número médio de pessoas: 146 / 14 = 10 pessoas


Modelo COCOMO Intermediário

● O Modelo COCOMO Intermediário estima o esforço do desenvolvimento de software utilizando atributos que levam em conta:

– requisitos funcionais e não-funcionais

– atributos do projeto

● As variáveis direcionadoras são organizadas em 4 classes e 15 subitens

● Cada valor corresponde a um multiplicador na faixa de [0.7, 1.66] (multiplicador menor que 1 implica em redução de custo

● Todos os valores são multiplicados juntos para modular esforço


Direcionadores


Equações

Intermediate COCOMO a b c

Organic 3.2 1.05 0.38

Semi-detached 3.0 1.12 0.35

Embedded 2.8 1.20 0.32

MM=a×(KDSI)b

TDEV=2.5×(MM )c

MM Korr=MM×∏i=1

15

EAFi


Modelo Intermediário:Exemplo

● Projeto A, semidestacado, é um software com 32,000 DSI. Está numa área de missão crítica, de forma que a confiabilidade exigida é alta (RELY HIGH = 1.15). Pode-se estimar:


Modelo Intermediário:Exemplo

● Projeto A, semidestacado, é um software com 32,000 DSI. Está numa área de missão crítica, de forma que a confiabilidade exigida é alta (RELY HIGH = 1.15). Pode-se estimar:

● Esforço: 1.15*3.0*(32)1.12 = 167 pm

● Prazo: 2.5*(167)0.35 = 15 meses

● Produtividade: 32,000 / 167 = 192 DSI/pm

● Número médio de pessoas: 167 / 15 = 11 pessoas


COCOMO 81:Modelo Detalhado

● Possui mais multiplicadores para cada fase do desenvolvimento

● Organiza os parâmetros hierarquicamente para simplificar a computação dos sistemas que possuem de diversos módulos

● Projetos são organizados em quatro fases:

– Requirements Planning and Product Design (PRD)

– Detailed Design (DD)

– Code and Unit Test (CUT)

– Integration Test (IT)

● Direcionadores são estimados por fase

● Dados das fases são então agregados para criar uma estimativa total


COCOMO 81:Modelo Detalhado

Documents

COCOMO - brhott.files.wordpress.com · O Modelo COCOMO Intermediário estima o esforço do desenvolvimento de software utilizando atributos que levam em conta: