Plano de Projeto

Tema 3. Gerência de Projetos

Profa. Susana M. Iglesias

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

Modelos Empíricos

� Modelos Empíricos� Modelo simples

� Modelo COCOMO

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)

Modelos Empíricos

� Modelos de estimativas orientados a LOC na literatura� E = 5.2 x (KLOC)0.91 Modelo Walston-Felix� E = 5.5 + 0.73 X (KLOC) 1.16 Modelo Bailey-Basili� E = 3.2 X (KLOC) 1.05 Modelo Boehm simples� E = 5.288 X (KLOC)1.047 Modelo Doty para KLOC > 9

� Modelos de estimativas orientadas a PF� E = -13.39 + 0.0545 FP� E = 60.62 X 7.728 X 10-8 FP3

� E = 585.7 + 15.12 FP� Se são examinados os modelos indicam valores

diferentes para o mesmo valor de LOC e PF.

Modelos Empíricos

� Modelo Walston Felix� RECURSO = C1 X ( característica estimada ) C2

� ESFORÇO E = 5.2 x KLOC0.91 (pessoas-mês)

� DURAÇÃO PROJETO D = 4.1 x KLOC0.36 (meses)

� TAMANHO DA EQUIPE S = 0.54 x E 0.06 (pessoas)

� LINHAS DOCUMENTAÇÃO DOC = 49 x KLOC1.01

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

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)

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.

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.)

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

COCOMO Básico

� Esforço pessoa-mês E = ab(KLOC)bb

� Duração em meses D = cb E db

Tipo de Projeto ab bb cb db

Orgánico 2.40 1.05 2.50 0.38Semi-separado 3.00 1.12 2.50 0.35Embutido 3.60 1.20 2.50 0.32

� 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

COCOMO Intermediário

� Considera Fator de Ajusto de Esforço (EAF). � E = ai KLOC bi X EAF

Tipo de Projeto ai bi

Orgánico 3.20 1.05Semi-separado 3.00 1.12Embutido 2.80 1.20

� 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

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.)

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 B0.333/P3] X (1/t4)� 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 = 28000 para aplicações de negócios.

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

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

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,

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.

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?

Árvore de decisão

System X

construir

reusar

comprar

comprar

$380,000

$450,000

$275,000

$310,000

$490,000

$500,000

$210,000

$400,000

$350,000

simples 0.3

difícil 0.7

pequenos câmbios

grandes câmbios

simples 0.2

complexo 0.8

pequenos câmbios 0.7

grandes câmbios 0.3

sem câmbios 0.6

com câmbios 0.4

A decisão Make - Buy

� Custo esperado = Sum(probabilidade do caminho)i X (custo estimado do caminho)i

� Custo Esperadoconstruir =0.30($380K)+0.70($450K)

= $429K

� Custo Esperadoreusar= 0.40($275K)+0.60[0.20($310K)+0.8($490K)]

= $382

� Custo Esperadocomprar =0.70($210K)+0.30($400K)

= $267K

� Custo Esperadocontratar =0.60($350K)+0.40($500K)

= $429K

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