segunda-feira, 29 de junho de 2020

Conciliação de Modelos de Estimativas

Normalmente, estimativas de projeto precisas usam pelo menos duas das técnicas de estimativas apresentadas anteriormente. Valores médios (conciliação) de estimativas são então calculados através dos valores de estimativa obtidos das técnicas consideradas.

A conciliação é realizada quando a variação máxima a partir da média obtida não ultrapassa 20%. Nesses casos, há forte razão para acreditar que as estimativas são confiáveis. Caso contrário, mais pesquisa e análise devem ser realizadas.

Pela comparação e conciliação das estimativas derivadas usando diferentes técnicas, é mais provável que o planejador consiga derivar uma estimativa precisa. Vale lembrar que a estimativa de projetos de software não é uma ciência exata. Mas, conforme vimos, dados históricos e técnicas sistemáticas podem melhorar a precisão da estimativa.

O que são Pontos por Caso de Uso (ou Use Case Points)?

Até o início da década de 1990 havia a falsa noção de que a APF não era adequada para medir sistemas orientados a objetos. Aqueles que compartilhavam desta noção, na prática, desconheciam a APF.

Com a disseminação da construção e projeto de sistemas orientados a objetos, houve também uma mudança na forma de se especificar e modelar os sistemas. A UML e os casos de uso rapidamente tornaram-se padrão na indústria de software.

Dentro deste contexto, em 1993 Gustav Karner propôs em um trabalho acadêmico: a metodologia dos Pontos por Caso de Uso (baseado na Análise de Pontos de Função) com o intuito de estimar recursos para projetos de software orientados a objeto desenvolvidos utilizando o processo Objectory.

Fonte: <fattocs>

domingo, 28 de junho de 2020

Estimativa com Pontos de Caso de Uso ou Use Case Points (UCPs)

Conforme já dissemos, os UCs podem ser utilizados na estimativa do tamanho planejado de um projeto de software. Embora não seja fácil utilizá-los, é possível calcular os Pontos de Caso de Uso ou Use Case Points (UCPs). Pressman e Maxim (2016, p. 741) descrevem os passos para o cálculo de UCPs como apresentado a seguir.

  • Passo 1: Cada UC é avaliado para determinar sua complexidade relativa, podendo ser classificado como:
    • UC Simples: possui fator de ponderação 5 e corresponde a uma interface de usuário simples, um único banco de dados com 3 ou menos transações e 5 ou menos implementações de classe.
    • UC Médio: possui fator de ponderação 10 e corresponde a uma interface de usuário mais elaborada, 2 ou 3 banco de dados com 4 a 7 transações e 6 a 10 implementações de classe.
    • UC Complexo: possui fator de ponderação 15 e corresponde a uma interface complexa, vários banco de dados com 8 ou mais transações e 11 ou mais implementações de classe.
    • Deste passo resulta o Unadjusted Use Case Weight – UUCW, que é a soma de todas as contagens de UCs multiplicadas pelos correspondentes fatores de ponderação.
  • Passo 2: cada ator é avaliado,podendo ser classificado como:
    • Ator Simples: possui fator de ponderação 1 e corresponde a autômatos (outros sistemas, máquinas ou dispositivos) que se comunicam por meio de uma API.
    • Ator Médio: possui fator de ponderação 2 e corresponde a autômatos que se comunicam por meio de um protocolo ou depósito de dados.
    • Ator Complexo: possui fator de ponderação 3 e corresponde a seres humanos que se comunicam por meio de uma interface gráfica ou outra interface envolvendo pessoas.
    • Deste passo resulta o Unadjusted Actor Weight – UAW, que é a soma de todas as contagens de atores multiplicadas pelos correspondentes fatores de ponderação.
  • Passo 3: os fatores não ajustados UUCW e UAW são modificados considerando-se fatores de complexidade técnica ou Technical Complexity Factors – TCFs e fatores de complexidade ambiental ou Environmental Complexity Factors – ECFs. Uma vez determinados estes fatores, o valor final do UCP é calculado de acordo com a fórmula:

UCP = (UUCW + UAW) x TCP x ECF

sábado, 27 de junho de 2020

Modelo COCOMO II

De acordo com Pressman e Maxim (2016, p. 745), COCOMO –COnstructive COst MOdel (Modelo Construtivo de Custo) é uma hierarquia de modelos de estimativa de software proposto por Barry Boehm em 1981. Este modelo evoluiu para um modelo mais abrangente denominado COCOMO II.

O modelo COCOMO II foi derivado dos dados de produtividade coletados de milhares de projetos de software e, com base nestes dados, foi derivado um modelo de estimativa E representado pela equação:

Onde:

E= esforço em pessoas-mês ou pessoas-ano

t = duração do projeto em meses ou anos

B = fator de habilidades especiais (para programas pequenos em torno de 5 a 15 KLOC, B= 0.16 e para programas grandes maiores que 70 KLOC B= 0.39)

P = parâmetro de produtividade (valores típicos podem ser P=2mil para software embarcado ou de tempo real, P= 10mil para softwares de telecomunicações e sistemas e P=28mil para aplicações comerciais).

sexta-feira, 26 de junho de 2020

Modelos de Estimativa Empíricos

Alguns modelos de estimativa para software usam fórmulas empíricas. Essas fórmulas são derivadas usando análise de regressão de dados coletados de projetos anteriores. Normalmente usa-se uma amostra limitada de dados de projetos.

Cada modelo de estimativa é adequado para um determinado conjunto de classes de software e ambientes de desenvolvimento, ou seja, são dependentes dos dados dos projetos que foram usados para obtê-los. Devido a isso, geralmente esses modelos de estimativa devem ser adaptados para as condições locais da organização.

É claro que, antes de serem usados na sua empresa, esses modelos devem ser testados usando resultados de projetos finalizados. Os dados estimados pelo modelo devem ser comparados aos resultados reais e a eficácia do modelo deve ser analisada para as condições locais.

De acordo com Pressman e Maxim (2016, p. 744), a estrutura geral dos modelos empíricos tem a forma:

E = A + B x (ev)c

Onde:

A, B, c são constantes derivadas empiricamente

E esforço em pessoas-mês

ev variável de estimativa (LOC ou PF)

A maioria dos modelos de estimativa tem alguma forma de fator de ajuste ao projeto. Isso permite que a variável E seja ajustada por características específicas do projeto, tais como complexidade do problema, experiência da equipe e ambiente de desenvolvimento.

A seguir, apresentamos alguns exemplos de modelos empíricos orientados a FP para esforço (E):

E = -13.39 + 0.0545 x (PF) (modelo de Albrecht e Gaffney)

E = 60.62 + 7.728 x 10-8 x (PF)3 (modelo de Kemerer)

E = 587.7 + 15.12 x (PF) (modelo de Matson, Barnett e Mellichamp)

E agora, alguns exemplos de modelos empíricos orientados a LOC para esforço (E):

E = 5.2 x (KLOC)0,91 (modelo de Walston-Felix)

E = 5.5 + 0.73 x (KLOC)1,16 (modelo de Bailey-Basili)

E = 3.2 x (KLOC)1,05 (modelo de Boehm simples)

E = 5.288 x (KLOC)1,047 (modelo de Doty para KLOC > 9)

É importante ressaltar que para os mesmos valores de FP ou LOC, os modelos vão gerar resultados diferentes (porque foram gerados, cada qual, em alguns domínios de aplicação específicos). Portanto, para utilizar esses modelos, eles devem ser adaptados para as necessidades locais.

quinta-feira, 25 de junho de 2020

Exemplos de Estimativas Baseadas em LOC (parte 2)

Exemplo 2:

A tabela 1 apresenta as estimativas de tamanho otimista, mais provável e pessimista para cada uma das funções a serem implementadas no software CAD do exemplo 1. Considerando que a empresa de software responsável em desenvolver o projeto produz 400 LOC/por mês, com um valor bruto de mão de obra de R$ 3000,00 por pessoa-mês, podemos, com base nesses dados, obter a estimativa de custo e esforço necessários para construir o software usando a técnica de estimativa baseada em LOC.

A tabela 2 apresenta o cálculo do tamanho de cada uma das funções (em LOC) utilizando a expressão apresentada anteriormente T=(Tot + 4Tmp + Tpess)/6.

Tabela 2 – Cálculo do tamanho de cada função
Função Estimativa de LOC
Recursos de Visualização T1 = ( Tot + 4Tmp + Tpess ) / 6 @4433
Recursos de Análise 2D T2 = ( Tot + 4Tmp + Tpess ) / 6 @5583
Recursos de Análise 3D T3 = ( Tot + 4Tmp + Tpess ) / 6 @6883
Recursos de Controle e Interface com o usuário T4 = ( Tot + 4Tmp + Tpess ) / 6 @2600
Administração da Base de Dados T5 = ( Tot + 4Tmp + Tpess ) / 6 @4167
Recursos de Controle de Periféricos T6 = ( Tot + 4Tmp + Tpess ) / 6 @2733
Recursos de Análise de Projetos T7 = ( Tot + 4Tmp + Tpess ) / 6 @7197
Estimativa das Linhas de Código (Total) 34317 LOC

Utilizando as estimativas de tamanho e os dados do valor bruto da mão de obra e produtividade fornecidos anteriormente, podemos calcular as estimativas de esforço e custo total conforme indicado a seguir.

Esforço necessário estimado=(Estimativa de LOC)/(produtividade média)

= (34317 LOC)/(400 LOC/pessoas-mês)

@ 86 pessoas-mês

Custo por LOC = (valor bruto da mão de obra) / (produtividade média)

= (3000 reais/pessoas-mês) / (400 LOC/pessoas-mês)

= 7.50 reais/LOC

Custo total estimado do projeto=(Estimativa de LOC) * (Custo por LOC)

= (34317 LOC) * (7.50 reais/LOC)

@ 257400.00 reais

quarta-feira, 24 de junho de 2020

Exemplos de Estimativas Baseadas em LOC

Exemplo 1:

Suponha um determinado software que será desenvolvido. Este software é do tipo CAD – Computer-Aided Design, ou seja, tem uma aplicação científica. Após a análise do escopo do software, suas funções principais foram identificadas e são relacionadas na tabela.

Principais funções identificadas no software CAD
Função Estimativa de LOC
Recursos de Visualização 3000
Recursos de Análise 2D 5000
Recursos de Análise 3D 6400
Recursos de Controle e Interface com o usuário 3300
Administração da Base de Dados 6000
Recursos de Controle de Periféricos 1000
Recursos de Análise de Projetos 7700
Estimativa das Linhas de Código (Total) 32400

Em seguida, um intervalo de estimativa de LOC é desenvolvido para cada função. Esse intervalo considera as estimativas como otimista, mais provável e pessimista.

Os valores das estimativas apresentados na tabela 3, para cada função, foram obtidos utilizando a expressão para T já apresentada (T =(Tot + 4Tmp + Tpess)/6).

Por exemplo, para a função “Recursos de Análise 3D”, foram obtidas: estimativa otimista Tot= 3800 LOC; mais provável Tmp= 6500 LOC; pessimista TPess= 8600 LOC. Estes valores, aplicados na equação T= (3800 + 4x6500 + 8600)/ 6, produzem um valor esperado de T= 6400 LOC.

Após o cálculo das estimativas de LOC para cada função, foi identificada uma estimativa de 32400 LOC para o sistema a ser desenvolvido.

Considerando que uma análise de dados históricos revelou que a produtividade organizacional média para sistemas desse tipo é de 500 LOC/pessoas-mês e que o valor bruto da mão de obra é de R$ 4000,00 por pessoa-mês, o custo por linha de código é de aproximadamente:

Custo por LOC = (valor bruto da mão de obra)/(produtividade média)

= (4000 reais/pessoas-mês)/(500 LOC/pessoas-mês)

= 8 reais/LOC

Portanto, o custo total estimado para o projeto é de:

Custo total estimado do projeto = (Estimativa de LOC)*(Custo por LOC)

= (32400 LOC) * (8 reais/LOC)

= 25920.00 reais/mês

O esforço necessário estimado para desenvolver o projeto é de:

Esforço necessário estimado=(Estimativa de LOC)/(produtividade média)

= (32400 LOC)/(500 LOC/pessoas-mês)

@ 65 pessoas-mês

terça-feira, 23 de junho de 2020

Técnica de decomposição: Estimativa Baseada em Problema

Como uma estimativa de projeto é tão boa quanto a estimativa do tamanho do trabalho a ser realizado, o dimensionamento representa o primeiro grande desafio do planejador de projeto. Para a determinação do tamanho do produto a ser construído, as abordagens mais utilizadas são:

  • abordagem direta (medido em LOC – Lines of Code, por exemplo);
  • abordagem indireta (medido em FP– Function Points, por exemplo).

De acordo com Pressman e Maxim (2016, p. 734), dados de LOC e FP são usados de duas maneiras distintas durante a estimativa do projeto de software: 1) como variáveis de estimativa para dimensionar cada elemento do software e 2) como métricas de referência coletadas de projetos anteriores e usadas em conjunto com variáveis de estimativa para desenvolver projeções de custo e esforço.

Em relação às técnicas de estimativa baseadas em LOC e FP, elas diferem quanto ao nível de detalhe necessário para a decomposição:

  • Estimativa LOC: a decomposição considera que todas as funções podem ser decompostas em subfunções semelhantes a entradas de uma base de dados histórica (quanto maior for o grau de particionamento, mais provável será que estimativas precisas de LOC possam ser desenvolvidas)
  • Estimativa FP: em vez de focalizar a função, é estimada cada uma das características do domínio de informação (entradas, saídas, arquivos de dados, consultas, interfaces externas), bem como os 14 valores de ajuste de complexidade.

Como alternativa, o planejador pode escolher outros componentes para dimensionar, como classes, objetos, casos de uso, modificações ou processos do negócio afetados.

Métricas referenciais de produtividade (por exemplo, LOC/PM ou FP/PM, onde PM=Pessoa por Mês) são então aplicadas à variável de estimativa adequada e o custo ou esforço correspondente à função é derivado. Em seguida, as estimativas de função são combinadas para produzir uma estimativa global para todo o projeto.

A experiência mostra que, frequentemente, há uma variação nos valores das métricas de produtividade de uma organização. Portanto, o uso como referencial de um único valor obtido de uma dada métrica não é recomendável.

O ideal é que a média de cada métrica deva ser calculada por domínio de projeto. Os projetos devem ser agrupados por tamanho de equipe, área de aplicação, complexidade e outros parâmetros relevantes. Em seguida, médias locais dos domínios devem ser calculadas.

No caso de estimativas de um novo projeto, ele deve ser primeiro classificado em um domínio e depois a média da métrica do domínio adequado deve ser usada para gerar a estimativa.

Independentemente da variável de estimativa que é usada (LOC, FP, número de classes, número de casos de usoetc), o planejador começa estimando um intervalo de valores para cada função (LOC, por exemplo) ou o valor do domínio de informação (FP, por exemplo).

Usando dados históricos (ou intuição caso todo o resto falhar), são estimados um valor de tamanho otimista (Tot), um mais provável (Tmp)e um pessimista (Tpess)para cada função ou contagem para cada valor do domínio de informação. Isso possibilita o cálculo de um valor esperado para a variável de estimativa tamanho (T), para cada função (LOC) ou valor do domínio de informação (FP).

Um exemplo de cálculo de um valor esperado para T pode ser a média ponderada:

T = ( Tot + 4Tmp + Tpess ) / 6

Uma vez determinado o valor esperado para a variável de estimativa de tamanho T, os dados históricos de LOC ou PF são aplicados.