Revisão: Estimando o tamanho do projeto

Transcrição

1 Bruno Hott COCOMO

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 Bruno Hott - DECSI/UFOP 2

3 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". Bruno Hott - DECSI/UFOP 3

4 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 Bruno Hott - DECSI/UFOP 4

5 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. Bruno Hott - DECSI/UFOP 5

6 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. Bruno Hott - DECSI/UFOP 6

7 NESMA: Resultados da pesquisa feita com mais de 100 projetos Bruno Hott - DECSI/UFOP 7

8 NESMA: Resultados da pesquisa feita com mais de 100 projetos Bruno Hott - DECSI/UFOP 8

9 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. Bruno Hott - DECSI/UFOP 9

10 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 Bruno Hott - DECSI/UFOP 10

11 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 Bruno Hott - DECSI/UFOP 11

12 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) Bruno Hott - DECSI/UFOP 12

13 COCOMO: Estrutura Geral OUTPUT= A (size) B M 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 Bruno Hott - DECSI/UFOP 13

14 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.) Bruno Hott - DECSI/UFOP 14

15 COCOMO 81 Bruno Hott - DECSI/UFOP 15

16 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 Bruno Hott - DECSI/UFOP 16

17 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) Bruno Hott - DECSI/UFOP 17

18 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 Bruno Hott - DECSI/UFOP 18

19 Equações MM=a (KDSI) b TDEV=2.5 (MM ) c Basic COCOMO a b c Organic Semi-detached Embedded Bruno Hott - DECSI/UFOP 19

20 Efeito exponencial do COCOMO Bruno Hott - DECSI/UFOP 20

21 Exemplo Foi determinado que o projeto se enquadra na características do modo Semi-destacado. Foi estimado que o projeto terá DSI. Utilizando as fórmulas, pode-se estimar: Bruno Hott - DECSI/UFOP 21

22 Exemplo Foi determinado que o projeto se enquadra na características do modo Semi-destacado. Foi estimado que o projeto terá 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: / 146 = 219 DSI/pm Número médio de pessoas: 146 / 14 = 10 pessoas Bruno Hott - DECSI/UFOP 22

23 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 Bruno Hott - DECSI/UFOP 23

24 Direcionadores Bruno Hott - DECSI/UFOP 24

25 Equações MM=a (KDSI) b 15 MM Korr = MM i=1 EAF i TDEV=2.5 (MM ) c Intermediate COCOMO a b c Organic Semi-detached Embedded Bruno Hott - DECSI/UFOP 25

26 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: Bruno Hott - DECSI/UFOP 26

27 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 Bruno Hott - DECSI/UFOP 27

28 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 Bruno Hott - DECSI/UFOP 28

29 COCOMO 81: Modelo Detalhado Bruno Hott - DECSI/UFOP 29