Plano de Projeto. Tema 3. Gerência de Projetos Profa. Susana M. Iglesias

Transcrição

1 Plano de Projeto Tema 3. Gerência de Projetos Profa. Susana M. Iglesias

2 Modelos Empíricos Modelos de Estimativas de Custo e Esforço. Modelos Empíricos: Usam formulas empíricas para predizer esforço em função das LOC ou PF estimadas como os modelos diretos, mas ao invés de usar as tabelas os valores obtidos de LOC ou PF são usadas em modelos de estimação. Os dados são obtidos de uma quantidade limitada de projetos. Não todos os modelos se adaptam a todo tipo de projetos Devem ser usados judiciosamente

3 Modelos Empíricos Modelos Empíricos Modelo simples Modelo COCOMO

4 Modelos Empíricos Modelos orientados a LOC E = A + B X (ev) c A, B e C constantes empiricamente obtidas E esforço pessoa/mês ev variável da estimativa (LOC ou PF)

5 Modelos Empíricos Modelos de estimativas orientados a LOC na literatura E = 5.2 x (KLOC) 0.91 Modelo Walston-Felix E = X (KLOC) 1.16 Modelo Bailey-Basili E = 3.2 X (KLOC) 1.05 Modelo Boehm simples E = X (KLOC) Modelo Doty para KLOC > 9 Modelos de estimativas orientadas a PF E = FP E = X X 10-8 FP 3 E = FP Se são examinados os modelos indicam valores diferentes para o mesmo valor de LOC e PF.

6 Modelos Empíricos Modelo Walston Felix RECURSO = C1 X ( característica estimada ) C2 ESFORÇO E = 5.2 x KLOC 0.91 (pessoas-mês) DURAÇÃO PROJETO D = 4.1 x KLOC 0.36 (meses) TAMANHO DA EQUIPE S = 0.54 x E 0.06 (pessoas) LINHAS DOCUMENTAÇÃO DOC = 49 x KLOC 1.01

7 Modelo COCOMO Modelo COCOMO Introduzido por Barry Boehm em Software Engeneering Economics COnstructive COst MOdel 3 Modelos em hierarquia Modelo 1 COCOMO básico Modelo 2 COCOMO Intermediário Modelo 2 COCOMO Avançado

8 Modelo COCOMO Modelo 1: Modelo COCOMO Básico (Boehm) modelo estático de variável simples esforço de desenvolvimento calculado em função do tamanho do software (LOC)

9 Modelo COCOMO Modelo 2: Modelo COCOMO Intermediário esforço de desenvolvimento calculado em função do tamanho do software (LOC) e de um conjunto de "direcionadores de custo que incluem avaliações de produtos, hardware, pessoal e atributos do projeto.

10 Modelo COCOMO Modelo 3: Modelo COCOMO Avançado mesmas características do modelo intermediário avaliação do impacto dos "direcionadores de custo" em cada passo do processo de construção (análises, design, etc.)

11 Modelo COCOMO Exemplos Básico e Intermediário Definem-se 3 classes de projetos Orgânicos Projetos pequenos Equipes pequenas e com baixa experiência Requisitos não muito rígidos Ex. programa de analises termais desenvolvido por um grupo de transferência de calor Semi-separados projetos com tamanho e complexidade médios equipes com experiências variadas requisitos rígidos e não rígidos Ex. Sistema de processamento de transações com elementos fixos de hardware e banco de dados Embutido restrições rígidas de hardware, software e operacionais Ex. Software de controle de vôo

12 COCOMO Básico Tipo de Projeto ab bb cb db Orgánico Semi-separado Embutido Esforço pessoa-mês E = ab(kloc) bb Duração em meses D = cb E db

13 Exemplo Software CAD. Usando LOC = 33.3 E = 2.4 (33.3) 1.05 E = 95 pessoa-mês (56 no modelo de decomposição) D = 2.5 E 0.35 D = 12.3 messes N = E/D = 8 pessoas

14 COCOMO Intermediário Tipo de Projeto ai bi Orgánico Semi-separado Embutido Considera Fator de Ajusto de Esforço (EAF). E = ai KLOC bi X EAF

15 Fator de Ajuste de Esforço. Usa atributos de custo divididos em 4 categorias Atributos do Produto: complexidade, confiabilidade exigida, tamanho do banco de dados Atributos do Hardware: restrições de desempenho, restrições de memória, etc. Atributos Pessoais: capacidade, experiência Atributos de projeto: uso de ferramentas, métodos, etc. Cada atributo é ponderado numa escala de 6 pontos e, através de tabelas publicadas por Boehm, obtem-se o FAE, que varia de 0.9 a 1.14

16 Ferramentas automatizadas As Técnicas de Decomposição e os Modelos Empíricos de Estimativas podem ser implementados em software. Esses softwares exigem os seguintes tipos de dados: estimativas quantitativas do tamanho ou funcionalidade do software (LOC ou PF) características qualitativas do projeto (complexidade, confiabilidade exigida, etc.) descrição do pessoal de desenvolvimento e/ou ambiente de trabalho (experiência, motivação, etc.)

17 A equação do software Modelo multivariavel que assume uma distribuição específica de esforço através do ciclo de vida do software. Putnam e Myers. Derivado da analise de produtividade de mais de 4000 projetos contemporâneos de software E = [LOC X B /P 3 ] X (1/t 4 ) E esforço, t duração do projeto, B Fator de habilidade (para projetos pequenos KLOC = 5 a 15 B = 0.16 Para grandes projetos KLOC > 70 B = 0.39) P Parâmetro de produtividade que reflete maturidade do processo, boas praticas de engenharia de software, nível da linguagem de programação, estado do ambiente de desenvolvimento, habilidade e experiência do grupo e a complexidade da aplicação. Valores típicos P = 2000 para projetos de tempo real embutidos, P =10000 para software de sistema e telecomunicações, P = para aplicações de negócios.

18 Para resumir Quanto às Métricas: Sem medir, não há maneira de determinar se existe melhoria A medição resulta em mudança cultural Ao criar uma baseline (banco de dados contendo medições do processo e do produto), engenheiros e gerentes podem ter uma melhor visão do processo e do produto Quanto às Estimativas: Não constituem uma ciência exata; sempre existem Riscos Para diminuir os Riscos, devem ser baseadas em Dados Históricos, que são construídos ao longo do tempo através da utilização de Métricas Estimativas mais precisas devem fazer uso de várias técnicas

19 A decisão Make - Buy Em muitas áreas freqüentemente é mais efetivo em termos de custo adquirir que desenvolver Softwares Gerente deve tomar a decisão de fazer ou comprar que pode ser complicada pelo número de opções de aquisição Software pode ser comprado ou licenciado (off-the-shelf) Experiências totais ou parciais de componentes podem ser adquiridas e modificadas e depois integradas para abranger necessidades específicas Software pode ser custom-buildt por um contratado para cobrir as especificações do cliente

20 A decisão Make - Buy Os passos envolvidos para a aquisição são definidos pela criticalidade do software a ser comprado e do custo final. Em alguns casos como software de PC baratos é menos custoso comprar e experimentar que conduzir uma longa avaliação,

21 A decisão Make - Buy porem para produtos de software mais caros deve ser aplicadas as seguintes diretrizes. Desenvolver uma especificação por função ou performance do software desejado. Defina características medíveis quando possível Estime o custo interno de desenvolvimento e a data de entrega Selecione 3 ou 4 candidatos que melhor se conheçam as especificações Paralelamente selecione componentes reusáveis que ajudara, na construção da aplicação Desenvolva uma matriz de comparação com as questões fundamentais. Alternativamente conduza testes padrões para comparar software candidatos. Avalie cada pacote de software ou baseado em componente com produtividade passada, suporte do vendedor, direção do produto, reputação entre outros Contate outros usuários e pergunte opiniões.

22 A decisão Make - Buy A decisão é baseada nas seguintes condições A data de liberação do produto vai ser menor que ao desenvolvido internamente? O custo de aquisição mais o de customização é menor que o custo do software desenvolvido internamente? O custo de suporte externo ou contrato de manutenção será menor que o custo interno de manutenção?

23 Árvore de decisão construir simples 0.3 difícil 0.7 pequenos câmbios $380,000 $450,000 $275,000 System X reusar grandes câmbios simples 0.2 complexo 0.8 $310,000 $490,000 comprar comprar pequenos câmbios 0.7 grandes câmbios 0.3 sem câmbios 0.6 com câmbios 0.4 $210,000 $400,000 $350,000 $500,000

24 A decisão Make - Buy Custo esperado = Sum(probabilidade do caminho) i X (custo estimado do caminho) i Custo Esperado construir =0.30($380K)+0.70($450K) = $429K Custo Esperado reusar = 0.40($275K)+0.60[0.20($310K)+0.8($490K)] Custo Esperado comprar Custo Esperado contratar = $382 =0.70($210K)+0.30($400K) = $267K =0.60($350K)+0.40($500K) = $429K

25 A decisão Make - Buy Lembrar não só o custo importa. Disponibilidade, experiência do desenvolvedor/vendedor/contratado, conformidade com os requisitos, política local, probabilidade de cambio são outros aspectos a levar em consideração