Técnicas de estimativa - Guia rápido

Estimation é o processo de encontrar uma estimativa, ou aproximação, que é um valor que pode ser usado para algum propósito, mesmo que os dados de entrada possam ser incompletos, incertos ou instáveis.

A estimativa determina quanto dinheiro, esforço, recursos e tempo levará para construir um sistema ou produto específico. A estimativa é baseada em -

  • Dados / experiências anteriores
  • Documentos / Conhecimento Disponíveis
  • Assumptions
  • Riscos Identificados

As quatro etapas básicas na Estimativa de Projeto de Software são -

  • Estime o tamanho do produto de desenvolvimento.
  • Faça uma estimativa do esforço em pessoa-mês ou pessoa-hora.
  • Faça uma estimativa da programação em meses do calendário.
  • Estime o custo do projeto na moeda acordada.

Observações sobre estimativa

  • A estimativa não precisa ser uma tarefa única em um projeto. Pode ocorrer durante -

    • Adquirindo um projeto.
    • Planejando o Projeto.
    • Execução do Projeto conforme a necessidade.
  • O escopo do projeto deve ser compreendido antes do início do processo de estimativa. Será útil ter dados históricos do projeto.

  • As métricas do projeto podem fornecer uma perspectiva histórica e informações valiosas para a geração de estimativas quantitativas.

  • O planejamento requer que os gerentes técnicos e a equipe de software assumam um compromisso inicial, pois isso leva à responsabilidade e prestação de contas.

  • A experiência anterior pode ajudar muito.

  • Use pelo menos duas técnicas de estimativa para chegar às estimativas e reconciliar os valores resultantes. Consulte Técnicas de decomposição na próxima seção para aprender sobre como reconciliar estimativas.

  • Os planos devem ser iterativos e permitir ajustes conforme o tempo passa e mais detalhes são conhecidos.

Abordagem de estimativa geral do projeto

A abordagem de estimativa do projeto que é amplamente utilizada é Decomposition Technique. As técnicas de decomposição adotam uma abordagem de dividir para conquistar. As estimativas de tamanho, esforço e custo são realizadas de maneira gradual, dividindo um projeto em funções principais ou atividades de engenharia de software relacionadas.

Step 1 - Compreender o escopo do software a ser construído.

Step 2 - Gere uma estimativa do tamanho do software.

  • Comece com a declaração de escopo.

  • Decomponha o software em funções que podem ser estimadas individualmente.

  • Calcule o tamanho de cada função.

  • Obtenha estimativas de esforço e custo aplicando os valores de tamanho às suas métricas de produtividade de linha de base.

  • Combine as estimativas de funções para produzir uma estimativa geral para todo o projeto.

Step 3- Gere uma estimativa do esforço e custo. Você pode chegar às estimativas de esforço e custo dividindo um projeto em atividades de engenharia de software relacionadas.

  • Identifique a sequência de atividades que precisam ser realizadas para que o projeto seja concluído.

  • Divida as atividades em tarefas que podem ser medidas.

  • Faça uma estimativa do esforço (horas / dias em pessoa) necessário para completar cada tarefa.

  • Combine estimativas de esforço de tarefas de atividade para produzir uma estimativa para a atividade.

  • Obtenha unidades de custo (isto é, custo / esforço unitário) para cada atividade do banco de dados.

  • Calcule o esforço e o custo total de cada atividade.

  • Combine as estimativas de esforço e custo para cada atividade para produzir uma estimativa geral de esforço e custo para todo o projeto.

Step 4- Reconciliar estimativas: compare os valores resultantes da Etapa 3 com os obtidos na Etapa 2. Se os dois conjuntos de estimativas concordarem, então seus números são altamente confiáveis. Caso contrário, se ocorrerem estimativas amplamente divergentes, conduza uma investigação mais aprofundada sobre se -

  • O escopo do projeto não foi adequadamente compreendido ou foi mal interpretado.

  • A divisão da função e / ou atividade não é precisa.

  • Os dados históricos usados ​​para as técnicas de estimativa são inadequados para a aplicação, ou obsoletos, ou foram mal aplicados.

Step 5 - Determinar a causa da divergência e, em seguida, reconciliar as estimativas.

Precisão de estimativa

A precisão é uma indicação de quão próximo algo está da realidade. Sempre que você gera uma estimativa, todos querem saber o quão próximos os números estão da realidade. Você desejará que cada estimativa seja o mais precisa possível, dados os dados de que dispõe no momento de gerá-la. E é claro que você não quer apresentar uma estimativa de uma forma que inspire uma falsa sensação de confiança nos números.

Fatores importantes que afetam a precisão das estimativas são -

  • A precisão de todos os dados de entrada da estimativa.

  • A precisão de qualquer cálculo de estimativa.

  • O quão próximo os dados históricos ou dados da indústria usados ​​para calibrar o modelo correspondem ao projeto que você está estimando.

  • A previsibilidade do processo de desenvolvimento de software da sua organização.

  • A estabilidade dos requisitos do produto e do ambiente que suporta o esforço de engenharia de software.

  • Se o projeto real foi ou não cuidadosamente planejado, monitorado e controlado, e nenhuma grande surpresa ocorreu que causou atrasos inesperados.

A seguir estão algumas diretrizes para obter estimativas confiáveis ​​-

  • Estimativas de base em projetos semelhantes que já foram concluídos.
  • Use técnicas de decomposição relativamente simples para gerar estimativas de custo e esforço do projeto.
  • Use um ou mais modelos de estimativa empírica para estimativa de custo e esforço de software.

Consulte a seção Diretrizes de estimativa neste capítulo.

Para garantir a precisão, sempre é aconselhável fazer uma estimativa usando pelo menos duas técnicas e comparar os resultados.

Problemas de estimativa

Freqüentemente, os gerentes de projeto recorrem a cronogramas de estimativa pulando para estimar o tamanho. Isso pode ser devido aos prazos estabelecidos pela alta administração ou pela equipe de marketing. No entanto, seja qual for o motivo, se isso for feito, em um estágio posterior será difícil estimar os cronogramas para acomodar as mudanças de escopo.

Durante a estimativa, certas suposições podem ser feitas. É importante observar todas essas premissas na planilha de estimativa, pois algumas ainda não documentam as premissas nas planilhas de estimativa.

Mesmo as boas estimativas têm suposições, riscos e incertezas inerentes e, no entanto, são frequentemente tratadas como se fossem precisas.

A melhor forma de expressar as estimativas é como uma gama de resultados possíveis, dizendo, por exemplo, que o projeto levará de 5 a 7 meses em vez de declarar que será concluído em uma determinada data ou será concluído em um nº fixo. de meses. Cuidado para não se comprometer com um intervalo muito estreito, pois isso equivale a se comprometer com uma data definida.

  • Você também pode incluir a incerteza como um valor de probabilidade que o acompanha. Por exemplo, há 90% de probabilidade de que o projeto seja concluído em ou antes de uma data definida.

  • As organizações não coletam dados de projeto precisos. Visto que a precisão das estimativas depende dos dados históricos, isso seria um problema.

  • Para qualquer projeto, existe um cronograma mais curto possível que permitirá incluir a funcionalidade necessária e produzir resultados de qualidade. Se houver uma restrição de cronograma pela gerência e / ou cliente, você pode negociar sobre o escopo e a funcionalidade a ser entregue.

  • Combine com o cliente sobre como lidar com variações de escopo para evitar estouros de cronograma.

  • A falha em acomodar a contingência na estimativa final causa problemas. Por exemplo, reuniões, eventos organizacionais.

  • A utilização de recursos deve ser considerada como inferior a 80%. Isso ocorre porque os recursos seriam produtivos apenas por 80% do seu tempo. Se você atribuir recursos com mais de 80% de utilização, certamente haverá derrapagens.

Diretrizes de estimativa

Deve-se manter as seguintes diretrizes em mente ao estimar um projeto -

  • Durante a estimativa, pergunte as experiências de outras pessoas. Além disso, coloque suas próprias experiências em ação.

  • Suponha que os recursos serão produtivos por apenas 80% do seu tempo. Portanto, durante a estimativa, considere a utilização de recursos como inferior a 80%.

  • Os recursos que trabalham em vários projetos demoram mais para concluir as tarefas devido ao tempo perdido alternando entre eles.

  • Inclua o tempo de gerenciamento em qualquer estimativa.

  • Sempre inclua contingência para solução de problemas, reuniões e outros eventos inesperados.

  • Reserve tempo suficiente para fazer uma estimativa adequada do projeto. Estimativas apressadas são estimativas imprecisas e de alto risco. Para grandes projetos de desenvolvimento, a etapa de estimativa deve realmente ser considerada como um miniprojeto.

  • Sempre que possível, use dados documentados de projetos anteriores semelhantes de sua organização. Isso resultará na estimativa mais precisa. Se sua organização não manteve dados históricos, agora é um bom momento para começar a coletá-los.

  • Use estimativas baseadas no desenvolvedor, pois as estimativas preparadas por outras pessoas além daquelas que farão o trabalho serão menos precisas.

  • Use várias pessoas diferentes para estimar e use várias técnicas de estimativa diferentes.

  • Reconcilie as estimativas. Observe a convergência ou dispersão entre as estimativas. Convergência significa que você fez uma boa estimativa. A técnica Delphi de banda larga pode ser usada para reunir e discutir estimativas usando um grupo de pessoas, com a intenção de produzir uma estimativa precisa e imparcial.

  • Reavalie o projeto várias vezes ao longo de seu ciclo de vida.

UMA Function Point(FP) é uma unidade de medida para expressar a quantidade de funcionalidade de negócios que um sistema de informações (como um produto) fornece a um usuário. Os FPs medem o tamanho do software. Eles são amplamente aceitos como um padrão da indústria para dimensionamento funcional.

Para dimensionamento de software baseado em FP, vários padrões reconhecidos e / ou especificações públicas passaram a existir. A partir de 2013, estes são -

Normas ISO

  • COSMIC- ISO / IEC 19761: 2011 Engenharia de software. Um método de medição de tamanho funcional.

  • FiSMA - ISO / IEC 29881: 2008 Tecnologia da informação - Engenharia de software e sistemas - Método de medição de tamanho funcional FiSMA 1.1.

  • IFPUG - ISO / IEC 20926: 2009 Engenharia de software e sistemas - Medição de software - Método de medição de tamanho funcional do IFPUG.

  • Mark-II - ISO / IEC 20968: 2002 Engenharia de software - Análise de ponto de função Ml II - Manual de práticas de contagem.

  • NESMA - ISO / IEC 24570: 2005 Engenharia de software - Método de medição de tamanho de função NESMA versão 2.1 - Definições e diretrizes de contagem para a aplicação da Análise de Ponto de Função.

Especificação do Grupo de Gerenciamento de Objetos para Ponto de Função Automatizado

Object Management Group (OMG), uma associação aberta e sem fins lucrativos consórcio de padrões da indústria de computadores, adotou a especificação Automated Function Point (AFP) liderada pelo Consortium for IT Software Quality. Ele fornece um padrão para automatizar a contagem de FP de acordo com as diretrizes do International Function Point User Group (IFPUG).

Function Point Analysis (FPA) techniquequantifica as funções contidas no software em termos que sejam significativos para os usuários do software. Os PFs consideram o número de funções sendo desenvolvidas com base na especificação de requisitos.

Function Points (FP) Countingé regido por um conjunto padrão de regras, processos e diretrizes conforme definido pelo International Function Point Users Group (IFPUG). Estes são publicados no Manual de Práticas de Contagem (CPM).

História da Análise de Pontos de Função

O conceito de Pontos de Função foi introduzido por Alan Albrecht da IBM em 1979. Em 1984, Albrecht refinou o método. As primeiras Diretrizes de Pontos de Função foram publicadas em 1984. O Grupo Internacional de Usuários de Pontos de Função (IFPUG) é uma organização mundial de usuários de software métrico de Análise de Pontos de Função com base nos Estados Unidos. oInternational Function Point Users Group (IFPUG)é uma organização sem fins lucrativos, governada por membros, fundada em 1986. O IFPUG possui a Análise de Ponto de Função (FPA), conforme definido na norma ISO 20296: 2009, que especifica as definições, regras e etapas para a aplicação do método de medição de tamanho funcional (FSM) do IFPUG. O IFPUG mantém o Manual de Práticas de Contagem de Pontos de Função (CPM). O CPM 2.0 foi lançado em 1987 e, desde então, houve várias iterações. O CPM Release 4.3 foi em 2010.

O CPM Release 4.3.1 com revisões editoriais ISO incorporadas foi em 2010. O Padrão ISO (IFPUG FSM) - Medição de Tamanho Funcional que faz parte do CPM 4.3.1 é uma técnica para medir software em termos da funcionalidade que ele oferece. O CPM é um padrão aprovado internacionalmente pela ISO / IEC 14143-1 Tecnologia da Informação - Medição de Software.

Processo Elementar (EP)

O Processo Elementar é a menor unidade de requisito funcional do usuário que -

  • É significativo para o usuário.
  • Constitui uma transação completa.
  • É independente e deixa o negócio do aplicativo sendo contado em um estado consistente.

Funções

Existem dois tipos de funções -

  • Funções de Dados
  • Funções de transação

Funções de Dados

Existem dois tipos de funções de dados -

  • Arquivos Lógicos Internos
  • Arquivos de interface externa

Funções de dados são compostas de recursos internos e externos que afetam o sistema.

Internal Logical Files

Arquivo lógico interno (ILF) é um grupo identificável do usuário de dados relacionados logicamente ou informações de controle que residem inteiramente dentro dos limites do aplicativo. A intenção principal de um ILF é manter os dados mantidos por um ou mais processos elementares do aplicativo que está sendo contado. Um ILF tem o significado inerente de que é mantido internamente, tem alguma estrutura lógica e é armazenado em um arquivo. (Consulte a Figura 1)

External Interface Files

O Arquivo de Interface Externa (EIF) é um grupo identificável do usuário de dados relacionados logicamente ou informações de controle que é usado pelo aplicativo apenas para fins de referência. Os dados residem inteiramente fora dos limites do aplicativo e são mantidos em um ILF por outro aplicativo. Um EIF tem o significado inerente de que é mantido externamente, uma interface deve ser desenvolvida para obter os dados do arquivo. (Consulte a Figura 1)

Funções de transação

Existem três tipos de funções de transação.

  • Entradas Externas
  • Saídas Externas
  • Consultas Externas

As funções de transação são formadas pelos processos que são trocados entre o usuário, os aplicativos externos e o aplicativo que está sendo medido.

External Inputs

A entrada externa (EI) é uma função de transação na qual os dados vão “para dentro” do aplicativo de fora do limite para dentro. Esses dados vêm de fora do aplicativo.

  • Os dados podem vir de uma tela de entrada de dados ou de outro aplicativo.
  • Um EI é como um aplicativo obtém informações.
  • Os dados podem ser informações de controle ou informações de negócios.
  • Os dados podem ser usados ​​para manter um ou mais arquivos lógicos internos.
  • Se os dados forem informações de controle, não é necessário atualizar um arquivo lógico interno. (Consulte a Figura 1)

External Outputs

A Saída Externa (EO) é uma função de transação na qual os dados “saem” do sistema. Além disso, um EO pode atualizar um ILF. Os dados criam relatórios ou arquivos de saída enviados para outros aplicativos. (Consulte a Figura 1)

External Inquiries

Consulta externa (EQ) é uma função de transação com componentes de entrada e saída que resultam na recuperação de dados. (Consulte a Figura 1)

Definição de RETs, DETs, FTRs

Tipo de elemento de registro

Um Record Element Type (RET) é o maior subgrupo de elementos identificável pelo usuário em um ILF ou EIF. É melhor examinar os agrupamentos lógicos de dados para ajudar a identificá-los.

Tipo de Elemento de Dados

Tipo de elemento de dados (DET) é o subgrupo de dados em um FTR. Eles são únicos e identificáveis ​​pelo usuário.

Tipo de arquivo referenciado

Tipo de arquivo referenciado (FTR) é o maior subgrupo identificável do usuário dentro do EI, EO ou EQ ao qual é referenciado.

As funções de transação EI, EO, EQ são medidas contando FTRs e DETs que contêm, seguindo as regras de contagem. Da mesma forma, as funções de dados ILF e EIF são medidas pela contagem de DETs e RETs que contêm, seguindo as regras de contagem. As medidas das funções de transação e funções de dados são usadas na contagem de FP que resulta no tamanho funcional ou pontos de função.

O processo de contagem de FP envolve as seguintes etapas -

  • Step 1 - Determine o tipo de contagem.

  • Step 2 - Determine o limite da contagem.

  • Step 3 - Identificar cada Processo Elementar (PE) exigido pelo usuário.

  • Step 4 - Determine os EPs exclusivos.

  • Step 5 - Medir funções de dados.

  • Step 6 - Medir funções transacionais.

  • Step 7 - Calcular o tamanho funcional (contagem de pontos de função não ajustada).

  • Step 8 - Determine o fator de ajuste de valor (VAF).

  • Step 9 - Calcule a contagem de pontos de função ajustada.

Note- Características Gerais do Sistema (GSCs) são opcionais no CPM 4.3.1 e movidas para o Apêndice. Portanto, a Etapa 8 e a Etapa 9 podem ser ignoradas.

Etapa 1: determinar o tipo de contagem

Existem três tipos de contagens de pontos de função -

  • Contagem de pontos de função de desenvolvimento
  • Contagem de pontos de função do aplicativo
  • Contagem de pontos de função de aprimoramento

Contagem de pontos de função de desenvolvimento

Os pontos de função podem ser contados em todas as fases de um projeto de desenvolvimento, desde o requisito até o estágio de implementação. Esse tipo de contagem está associado a novos trabalhos de desenvolvimento e pode incluir os protótipos, que podem ter sido solicitados como solução temporária, que dá suporte ao esforço de conversão. Esse tipo de contagem é chamado de contagem de pontos de função de linha de base.

Contagem de pontos de função do aplicativo

As contagens de aplicativos são calculadas como os pontos de função fornecidos e excluem qualquer esforço de conversão (protótipos ou soluções temporárias) e funcionalidade existente que possa ter existido.

Contagem de pontos de função de aprimoramento

Quando mudanças são feitas no software após a produção, elas são consideradas como aprimoramentos. Para dimensionar esses projetos de aprimoramento, a contagem de pontos de função é adicionada, alterada ou excluída no aplicativo.

Etapa 2: determinar o limite da contagem

O limite indica a fronteira entre o aplicativo que está sendo medido e os aplicativos externos ou o domínio do usuário. (Consulte a Figura 1)

Para determinar o limite, entenda -

  • O objetivo da contagem de pontos de função
  • Escopo do aplicativo sendo medido
  • Como e quais aplicativos mantêm quais dados
  • As áreas de negócios que suportam os aplicativos

Etapa 3: identificar cada processo elementar exigido pelo usuário

Compor e / ou decompor os requisitos funcionais do usuário na menor unidade de atividade, que satisfaça todos os seguintes critérios -

  • É significativo para o usuário.
  • Constitui uma transação completa.
  • É independente.
  • Deixa o negócio do aplicativo sendo contado em um estado consistente.

Por exemplo, o Requisito Funcional do Usuário - “Manter as informações do funcionário” pode ser decomposto em atividades menores, como adicionar funcionário, alterar funcionário, excluir funcionário e consultar sobre funcionário.

Cada unidade de atividade assim identificada é um Processo Elementar (PE).

Etapa 4: determinar os processos elementares exclusivos

Comparando dois EPs já identificados, conte-os como um EP (mesmo EP) se eles -

  • Requer o mesmo conjunto de DETs.
  • Requer o mesmo conjunto de FTRs.
  • Requer o mesmo conjunto de lógica de processamento para completar o EP.

Não divida um EP com várias formas de lógica de processamento em vários Eps.

Por exemplo, se você identificou 'Adicionar Funcionário' como um EP, não deve ser dividido em dois EPs para contabilizar o fato de que um funcionário pode ou não ter dependentes. O EP ainda é 'Adicionar funcionário', e há variação na lógica de processamento e DETs para contabilizar os dependentes.

Etapa 5: funções de medição de dados

Classifique cada função de dados como ILF ou EIF.

Uma função de dados deve ser classificada como um -

  • Arquivo lógico interno (ILF), se for mantido pelo aplicativo que está sendo medido.

  • Arquivo de interface externa (EIF) se for referenciado, mas não mantido pelo aplicativo que está sendo medido.

ILFs e EIFs podem conter dados de negócios, dados de controle e dados baseados em regras. Por exemplo, a comutação telefônica é feita de todos os três tipos - dados de negócios, dados de regras e dados de controle. Os dados da empresa são a chamada real. Os dados da regra são como a chamada deve ser roteada pela rede, e os dados de controle são como os switches se comunicam entre si.

Considere a seguinte documentação para contagem de ILFs e EIFs -

  • Objetivos e restrições do sistema proposto.
  • Documentação referente ao sistema atual, se tal sistema existir.
  • Documentação dos objetivos, problemas e necessidades percebidos pelos usuários.
  • Modelos de dados.

Etapa 5.1: contar os DETs para cada função de dados

Aplique as seguintes regras para contar DETs para ILF / EIF -

  • Conte um DET para cada campo não repetido e identificável de usuário exclusivo mantido ou recuperado do ILF ou EIF por meio da execução de um EP.

  • Conte apenas os DETs usados ​​pelo aplicativo que são medidos quando dois ou mais aplicativos mantêm e / ou fazem referência à mesma função de dados.

  • Conte um DET para cada atributo exigido pelo usuário para estabelecer um relacionamento com outro ILF ou EIF.

  • Revise os atributos relacionados para determinar se eles são agrupados e contados como um único DET ou se são contados como vários DETs. O agrupamento dependerá de como os EPs usam os atributos dentro do aplicativo.

Etapa 5.2: contar os RETs para cada função de dados

Aplique as seguintes regras para contar RETs para ILF / EIF -

  • Conte um RET para cada função de dados.
  • Conte um RET adicional para cada um dos seguintes subgrupos lógicos adicionais de DETs.
    • Entidade associativa com atributos não-chave.
    • Subtipo (diferente do primeiro subtipo).
    • Entidade atributiva, em relação diferente da obrigatória 1: 1.

Etapa 5.3: Determinar a complexidade funcional para cada função de dados

RETS Tipos de elemento de dados (DETs)
1-19 20-50 >50
1 eu eu UMA
2 a 5 eu UMA H
> 5 UMA H H

Complexidade funcional: L = Baixo; A = Média; H = Alto

Etapa 5.4: Medir o tamanho funcional para cada função de dados

Complexidade Funcional Contagem de FP para ILF Contagem de FP para EIF
Baixo 7 5
Média 10 7
Alto 15 10

Etapa 6: Medir funções transacionais

Para medir as funções transacionais, a seguir estão as etapas necessárias -

Etapa 6.1: Classifique cada Função Transacional

As funções transacionais devem ser classificadas como uma entrada externa, uma saída externa ou uma consulta externa.

Entrada externa

A entrada externa (EI) é um processo elementar que processa dados ou informações de controle que vêm de fora da fronteira. A principal intenção de um EI é manter um ou mais ILFs e / ou alterar o comportamento do sistema.

Todas as seguintes regras devem ser aplicadas -

  • Os dados ou informações de controle são recebidos de fora dos limites do aplicativo.

  • Pelo menos um ILF é mantido se os dados que entram no limite não são informações de controle que alteram o comportamento do sistema.

  • Para o PE identificado, uma das três afirmações deve ser aplicada -

    • A lógica de processamento é exclusiva da lógica de processamento executada por outros EIs para o aplicativo.

    • O conjunto de elementos de dados identificados é diferente dos conjuntos identificados para outras EIs no aplicativo.

    • ILFs ou EIFs referenciados são diferentes dos arquivos referenciados por outros EIs no aplicativo.

Saída Externa

Saída Externa (EO) é um Processo Elementar que envia dados ou informações de controle fora dos limites do aplicativo. EO inclui processamento adicional além de uma consulta externa.

O objetivo principal de um EO é apresentar informações a um usuário por meio de uma lógica de processamento diferente ou adicional à recuperação de dados ou informações de controle.

A lógica de processamento deve -

  • Conter pelo menos uma fórmula matemática ou cálculo.
  • Crie dados derivados.
  • Mantenha um ou mais ILFs.
  • Altere o comportamento do sistema.

Todas as seguintes regras devem ser aplicadas -

  • Envia dados ou informações de controle externas aos limites do aplicativo.
  • Para o PE identificado, uma das três afirmações deve ser aplicada -
    • A lógica de processamento é exclusiva da lógica de processamento executada por outros EOs para o aplicativo.
    • O conjunto de elementos de dados identificados é diferente de outros EOs no aplicativo.
    • ILFs ou EIFs referenciados são diferentes dos arquivos referenciados por outros EOs no aplicativo.

Além disso, uma das seguintes regras deve ser aplicada -

  • A lógica de processamento contém pelo menos uma fórmula matemática ou cálculo.
  • A lógica de processamento mantém pelo menos um ILF.
  • A lógica de processamento altera o comportamento do sistema.

Inquérito externo

A Consulta Externa (EQ) é um Processo Elementar que envia dados ou informações de controle para fora dos limites. O objetivo principal de um EQ é apresentar informações ao usuário por meio da recuperação de dados ou informações de controle.

A lógica de processamento não contém fórmulas matemáticas ou cálculos e não cria dados derivados. Nenhum ILF é mantido durante o processamento, nem o comportamento do sistema é alterado.

Todas as seguintes regras devem ser aplicadas -

  • Envia dados ou informações de controle externas aos limites do aplicativo.
  • Para o PE identificado, uma das três afirmações deve ser aplicada -
    • A lógica de processamento é exclusiva da lógica de processamento executada por outros EQs para o aplicativo.
    • O conjunto de elementos de dados identificados são diferentes de outros EQs no aplicativo.
    • Os ILFs ou EIFs referenciados são diferentes dos arquivos referenciados por outros EQs no aplicativo.

Além disso, todas as regras a seguir devem ser aplicadas -

  • A lógica de processamento recupera dados ou informações de controle de um ILF ou EIF.
  • A lógica de processamento não contém fórmula matemática ou cálculo.
  • A lógica de processamento não altera o comportamento do sistema.
  • A lógica de processamento não mantém um ILF.

Etapa 6.2: contar os DETs para cada função transacional

Aplique as seguintes regras para contar DETs para EIs -

  • Reveja tudo o que cruza (entra e / ou sai) da fronteira.

  • Conte um DET para cada atributo não repetido e identificável pelo usuário único que cruzar (entrar e / ou sair) do limite durante o processamento da função transacional.

  • Conte apenas um DET por função transacional para a capacidade de enviar uma mensagem de resposta do aplicativo, mesmo se houver várias mensagens.

  • Conte apenas um DET por função transacional para a capacidade de iniciar ação (ões), mesmo se houver vários meios para fazê-lo.

  • Não conte os seguintes itens como DETs -

    • Atributos gerados dentro do limite por uma função transacional e salvos em um ILF sem sair do limite.

    • Literais como títulos de relatório, identificadores de tela ou painel, cabeçalhos de colunas e títulos de atributos.

    • Carimbos gerados pelo aplicativo, como atributos de data e hora.

    • Variáveis ​​de paginação, números de página e informações de posicionamento, por exemplo, 'Linhas 37 a 54 de 211'.

    • Auxílios de navegação, como a capacidade de navegar em uma lista usando “anterior”, “próximo”, “primeiro”, “último” e seus equivalentes gráficos.

Aplique as seguintes regras para contar DETs para EOs / EQs -

  • Reveja tudo o que cruza (entra e / ou sai) da fronteira.

  • Conte um DET para cada atributo não repetido e identificável pelo usuário único que cruzar (entrar e / ou sair) do limite durante o processamento da função transacional.

  • Conte apenas um DET por função transacional para a capacidade de enviar uma mensagem de resposta do aplicativo, mesmo se houver várias mensagens.

  • Conte apenas um DET por função transacional para a capacidade de iniciar ação (ões), mesmo se houver vários meios para fazê-lo.

  • Não conte os seguintes itens como DETs -

    • Atributos gerados dentro do limite sem cruzar o limite.

    • Literais como títulos de relatório, identificadores de tela ou painel, cabeçalhos de colunas e títulos de atributos.

    • Carimbos gerados pelo aplicativo, como atributos de data e hora.

    • Variáveis ​​de paginação, números de página e informações de posicionamento, por exemplo, 'Linhas 37 a 54 de 211'.

    • Auxílios de navegação, como a capacidade de navegar em uma lista usando “anterior”, “próximo”, “primeiro”, “último” e seus equivalentes gráficos.

Etapa 6.3: contar os FTRs para cada função transacional

Aplique as seguintes regras para contar FTRs para EIs -

  • Conte um FTR para cada ILF mantido.
  • Conte um FTR para cada ILF ou EIF lido durante o processamento do EI.
  • Conte apenas um FTR para cada ILF que é mantido e lido.

Aplique a seguinte regra para contar FTRs para EO / EQs -

  • Conte um FTR para cada ILF ou EIF lido durante o processamento de EP.

Além disso, aplique as seguintes regras para contar FTRs para EOs -

  • Conte um FTR para cada ILF mantido durante o processamento de EP.
  • Conte apenas um FTR para cada ILF que é mantido e lido por EP.

Etapa 6.4: Determinar a complexidade funcional para cada função transacional

FTRs Tipos de elemento de dados (DETs)
1-4 5-15 >=16
0-1 eu eu UMA
2 eu UMA H
> = 3 UMA H H

Complexidade funcional: L = Baixo; A = Média; H = Alto

Determine a complexidade funcional para cada EO / EQ, com a exceção de que EQ deve ter um mínimo de 1 FTR -

EQ deve ter no mínimo 1 FTR

FTRs

Tipos de elemento de dados (DETs)
1-4 5-15 > = 16
0-1 eu eu UMA
2 eu UMA H
> = 3 UMA H H

Complexidade funcional: L = Baixo; A = Média; H = Alto

Etapa 6.5: Medir o tamanho funcional para cada função transacional

Meça o tamanho funcional de cada EI a partir de sua complexidade funcional.

Complexidade Contagem de FP
Baixo 3
Média 4
Alto 6

Meça o tamanho funcional de cada EO / EQ a partir de sua complexidade funcional.

Complexidade Contagem de FP para EO Contagem de FP para EQ
Baixo 4 3
Média 5 4
Alto 6 6

Etapa 7: Calcular o tamanho funcional (contagem de pontos de função não ajustada)

Para calcular o tamanho funcional, deve-se seguir as etapas abaixo -

Etapa 7.1

Relembre o que você encontrou na Etapa 1. Determine o tipo de contagem.

Etapa 7.2

Calcule o tamanho funcional ou a contagem de pontos de função com base no tipo.

  • Para contagem de pontos de função de desenvolvimento, vá para a Etapa 7.3.
  • Para a contagem de pontos de função do aplicativo, vá para a Etapa 7.4.
  • Para contagem de pontos de função de aprimoramento, vá para a Etapa 7.5.

Etapa 7.3

A contagem de pontos de função de desenvolvimento consiste em dois componentes de funcionalidade -

  • Funcionalidade do aplicativo incluída nos requisitos do usuário para o projeto.

  • Funcionalidade de conversão incluída nos requisitos do usuário para o projeto. A funcionalidade de conversão consiste em funções fornecidas apenas na instalação para converter dados e / ou fornecer outros requisitos de conversão especificados pelo usuário, como relatórios de conversão especiais. Por exemplo, um aplicativo existente pode ser substituído por um novo sistema.

DFP = ADD + CFP

Onde,

DFP = Contagem de pontos de função de desenvolvimento

ADD = Tamanho das funções entregues ao usuário pelo projeto de desenvolvimento

CFP = Tamanho da funcionalidade de conversão

ADD = Contagem de FP (ILFs) + Contagem de FP (EIFs) + Contagem de FP (EIs) + Contagem de FP (EOs) + Contagem de FP (EQs)

CFP = Contagem de FP (ILFs) + Contagem de FP (EIFs) + Contagem de FP (EIs) + Contagem de FP (EOs) + Contagem de FP (EQs)

Etapa 7.4

Calcular a contagem de pontos de função do aplicativo

AFP = ADD

Onde,

AFP = Contagem de pontos de função do aplicativo

ADD = Tamanho das funções entregues ao usuário pelo projeto de desenvolvimento (excluindo o tamanho de qualquer funcionalidade de conversão), ou a funcionalidade que existe sempre que o aplicativo é contado.

ADD = Contagem de FP (ILFs) + Contagem de FP (EIFs) + Contagem de FP (EIs) + Contagem de FP (EOs) + Contagem de FP (EQs)

Etapa 7.5

A contagem de pontos de função de aprimoramento considera os quatro componentes de funcionalidade a seguir -

  • Funcionalidade que é adicionada ao aplicativo.
  • Funcionalidade que é modificada no aplicativo.
  • Funcionalidade de conversão.
  • Funcionalidade que é excluída do aplicativo.

EFP = ADD + CHGA + CFP + DEL

Onde,

EFP = Contagem de Pontos de Função de Melhoria

ADD = Tamanho das funções adicionadas pelo projeto de melhoria

CHGA = Tamanho das funções sendo alteradas pelo projeto de melhoria

CFP = Tamanho da funcionalidade de conversão

DEL = Tamanho das funções sendo excluídas pelo projeto de melhoria

ADD = Contagem de FP (ILFs) + Contagem de FP (EIFs) + Contagem de FP (EIs) + Contagem de FP (EOs) + Contagem de FP (EQs)

CHGA = Contagem de FP (ILFs) + Contagem de FP (EIFs) + Contagem de FP (EIs) + Contagem de FP (EOs) + Contagem de FP (EQs)

CFP = Contagem de FP (ILFs) + Contagem de FP (EIFs) + Contagem de FP (EIs) + Contagem de FP (EOs) + Contagem de FP (EQs)

DEL = Contagem FP (ILFs) + Contagem FP (EIFs) + CONTAGEM FP (EIs) + Contagem FP (EOs) + Contagem FP (EQs)

Etapa 8: determinar o fator de ajuste de valor

GSCs são opcionais no CPM 4.3.1 e movidos para o Apêndice. Portanto, a Etapa 8 e a Etapa 9 podem ser ignoradas.

O Value Adjustment Factor (VAF) é baseado em 14 GSCs que classificam a funcionalidade geral do aplicativo que está sendo contado. GSCs são restrições de negócios do usuário independentes de tecnologia. Cada característica tem descrições associadas para determinar o grau de influência.

Características Gerais do Sistema Descrição breve
Comunicações de Dados Quantas facilidades de comunicação existem para auxiliar na transferência ou troca de informações com o aplicativo ou sistema?
Processamento Distribuído de Dados Como os dados distribuídos e as funções de processamento são tratados?
atuação O usuário solicitou tempo de resposta ou taxa de transferência?
Configuração altamente utilizada Quão fortemente utilizada é a plataforma de hardware atual onde o aplicativo será executado?
Taxa de transação Com que frequência as transações são executadas diariamente, semanalmente, mensalmente, etc.?
Entrada de dados on-line Qual porcentagem das informações é inserida online?
Eficiência do usuário final O aplicativo foi projetado para eficiência do usuário final?
Atualização Online Quantos ILFs são atualizados por transação online?
Processamento Complexo O aplicativo possui processamento lógico ou matemático extenso?
Reutilização O aplicativo foi desenvolvido para atender às necessidades de um ou mais usuários?
Facilidade de instalação Quão difícil é a conversão e instalação?
Facilidade operacional Quão eficazes e / ou automatizados são os procedimentos de inicialização, backup e recuperação?
Multiple Sites O aplicativo foi projetado, desenvolvido e com suporte especificamente para ser instalado em vários locais para várias organizações?
Facilite a mudança O aplicativo foi projetado, desenvolvido e apoiado especificamente para facilitar a mudança?

O grau de influência varia em uma escala de zero a cinco, de nenhuma influência a forte influência.

Avaliação Grau de Influência
0 Ausente ou sem influência
1 Influência incidental
2 Influência moderada
3 Influência média
4 Influência significante
5 Forte influência em toda

Determine o grau de influência de cada um dos 14 GSCs.

A soma dos valores dos 14 GSCs assim obtidos é denominada Grau Total de Influência (TDI).

TDI = ∑14 Degrees of Influence

Em seguida, calcule o Fator de Ajuste de Valor (VAF) como

VAF = (TDI × 0.01) + 0.65

Cada GSC pode variar de 0 a 5, o TDI pode variar de (0 × 14) a (5 × 14), ou seja, 0 (quando todos os GSCs são baixos) a 70 (quando todos os GSCs são altos) ou seja, 0 ≤ TDI ≤ 70. Portanto, VAF pode variar na faixa de 0,65 (quando todos os GSCs são baixos) a 1,35 (quando todos os GSCs são altos), ou seja, 0,65 ≤ VAF ≤ 1,35.

Etapa 9: Calcular a contagem de pontos de função ajustados

De acordo com a abordagem FPA que usa o VAF (versões CPM anteriores a V4.3.1), isso é determinado por,

Adjusted FP Count = Unadjusted FP Count × VAF

Onde, a contagem de FP não ajustada é o tamanho funcional que você calculou na Etapa 7.

Como o VAF pode variar de 0,65 a 1,35, o VAF exerce influência de ± 35% na contagem final ajustada de FP.

Benefícios dos pontos de função

Os pontos de função são úteis -

  • Em medir o tamanho da solução em vez do tamanho do problema.

  • Como os requisitos são a única coisa necessária para a contagem dos pontos de função.

  • Por ser independente de tecnologia.

  • Como é independente de linguagens de programação.

  • Na estimativa de projetos de teste.

  • Na estimativa de custos gerais do projeto, cronograma e esforço.

  • Nas negociações de contratos, pois fornece um método de comunicação mais fácil com grupos de negócios.

  • À medida que quantifica e atribui um valor aos usos, interfaces e propósitos reais das funções no software.

  • Na criação de proporções com outras métricas, como horas, custo, número de funcionários, duração e outras métricas de aplicativo.

Repositórios FP

O International Software Benchmarking Standards Group (ISBSG) cresce e mantém dois repositórios de dados de TI.

  • Projetos de Desenvolvimento e Melhoria
  • Aplicativos de manutenção e suporte

Existem mais de 6.000 projetos no repositório de Projetos de Desenvolvimento e Melhoria.

Os dados são entregues no formato Microsoft Excel, tornando mais fácil para análises futuras que você deseja fazer com eles, ou você pode até mesmo usar os dados para alguma outra finalidade.

A licença do repositório ISBSG pode ser adquirida em: http://www.isbsg.com/

O ISBSG oferece 10% de desconto para membros do IFPUG para compras online quando o código de desconto “IFPUGMembers” é usado.

As atualizações do lançamento de dados do projeto de software ISBSG podem ser encontradas em: http://www.ifpug.org/isbsg/

O COSMIC e o IFPUG colaboraram para produzir um Glossário de termos para Requisitos Não Funcionais e de Projeto de software. Ele pode ser baixado em - cosmic-sizing.org

UMA Use-Case é uma série de interações relacionadas entre um usuário e um sistema que permite ao usuário atingir um objetivo.

Os casos de uso são uma forma de capturar os requisitos funcionais de um sistema. O usuário do sistema é referido como 'Ator'. Os casos de uso estão fundamentalmente na forma de texto.

Pontos de caso de uso - definição

Use-Case Points (UCP)é uma técnica de estimativa de software usada para medir o tamanho do software com casos de uso. O conceito de UCP é semelhante ao de FPs.

O número de UCPs em um projeto é baseado no seguinte -

  • O número e a complexidade dos casos de uso no sistema.
  • O número e a complexidade dos atores no sistema.
    • Vários requisitos não funcionais (como portabilidade, desempenho, capacidade de manutenção) que não são escritos como casos de uso.

    • O ambiente em que o projeto será desenvolvido (como o idioma, a motivação da equipe, etc.)

A estimativa com UCPs requer que todos os casos de uso sejam escritos com um objetivo e aproximadamente no mesmo nível, fornecendo a mesma quantidade de detalhes. Portanto, antes da estimativa, a equipe do projeto deve garantir que escreveu seus casos de uso com metas definidas e em nível detalhado. O caso de uso normalmente é concluído em uma única sessão e, depois que o objetivo é alcançado, o usuário pode prosseguir para alguma outra atividade.

História de pontos de caso de uso

O método de estimativa de Ponto de Caso de Uso foi introduzido por Gustav Karner em 1993. O trabalho foi posteriormente licenciado pela Rational Software, que se fundiu à IBM.

Processo de contagem de pontos de caso de uso

O processo de contagem de Pontos de Caso de Uso tem as seguintes etapas -

  • Calcular UCPs não ajustados
  • Ajuste para complexidade técnica
  • Ajuste para a complexidade ambiental
  • Calcular UCPs ajustados

Etapa 1: Calcular pontos de casos de uso não ajustados.

Você calcula os pontos de caso de uso não ajustados primeiro, pelas seguintes etapas -

  • Determine o peso não ajustado do caso de uso
  • Determine o peso do ator não ajustado
  • Calcular pontos de caso de uso não ajustados

Step 1.1 - Determine o peso do caso de uso não ajustado.

Step 1.1.1 - Encontre o número de transações em cada caso de uso.

Se os Casos de Uso forem escritos com Níveis de Objetivo do Usuário, uma transação será equivalente a uma etapa no Caso de Uso. Encontre o número de transações contando as etapas no Caso de Uso.

Step 1.1.2- Classifique cada Caso de Uso como Simples, Médio ou Complexo com base no número de transações no Caso de Uso. Além disso, atribua Peso de Caso de Uso conforme mostrado na tabela a seguir -

Complexidade de caso de uso Número de transações Peso de caso de uso
Simples ≤3 5
Média 4 a 7 10
Complexo > 7 15

Step 1.1.3- Repita para cada caso de uso e obtenha todos os pesos de caso de uso. Peso de caso de uso não ajustado (UUCW) é a soma de todos os pesos de caso de uso.

Step 1.1.4 - Encontre Peso de Caso de Uso Não Ajustado (UUCW) usando a tabela a seguir -

Complexidade de caso de uso Peso de caso de uso Número de casos de uso produtos
Simples 5 NSUC 5 × NSUC
Média 10 NAUC 10 × NAUC
Complexo 15 NCUC 15 × NCUC
Unadjusted Use-Case Weight (UUCW) 5 × NSUC + 10 × NAUC + 15 × NCUC

Onde,

NSUC é o não. de casos de uso simples.

NAUC é o não. de casos de uso médios.

NCUC é o não. de Casos de Uso Complexos.

Step 1.2 - Determine o peso do ator não ajustado.

Um ator em um caso de uso pode ser uma pessoa, outro programa, etc. Alguns atores, como um sistema com API definida, têm necessidades muito simples e aumentam a complexidade de um caso de uso apenas ligeiramente.

Alguns atores, como um sistema interagindo por meio de um protocolo, têm mais necessidades e aumentam a complexidade de um Caso de Uso até certo ponto.

Outros Atores, como um usuário interagindo por meio da GUI, têm um impacto significativo na complexidade de um Caso de Uso. Com base nessas diferenças, você pode classificar os atores como Simples, Médio e Complexo.

Step 1.2.1 - Classifique os atores como simples, médios e complexos e atribua pesos dos atores conforme mostrado na tabela a seguir -

Complexidade do ator Exemplo Peso do Ator
Simples Um sistema com API definida 1
Média Um sistema interagindo por meio de um protocolo 2
Complexo Um usuário interagindo por meio da GUI 3

Step 1.2.2- Repita para cada ator e obtenha todos os pesos do ator. Peso do ator não ajustado (UAW) é a soma de todos os pesos do ator.

Step 1.2.3 - Encontre Peso do Ator Não Ajustado (UAW) usando a seguinte tabela -

Complexidade do ator Peso do Ator Número de Atores produtos
Simples 1 NSA 1 × NSA
Média 2 NAA 2 × NAA
Complexo 3 NCA 3 × NCA
Unadjusted Actor Weight (UAW) 1 × NSA + 2 × NAA + 3 × NCA

Onde,

NSA é o não. de Atores Simples.

NAA é o não. de Atores Médios.

NCA é o não. de Atores Complexos.

Step 1.3 - Calcular pontos de caso de uso não ajustados.

O Unadjusted Use-Case Weight (UUCW) e o Unadjusted Actor Weight (UAW) juntos fornecem o tamanho não ajustado do sistema, referido como Unadjusted Use-Case Points.

Unadjusted Use-Case Points (UUCP) = UUCW + UAW

As próximas etapas são ajustar os pontos de caso de uso não ajustados (UUCP) para complexidade técnica e complexidade ambiental.

Etapa 2: ajuste para complexidade técnica

Step 2.1 - Considere os 13 fatores que contribuem para o impacto da Complexidade Técnica de um projeto nos Pontos de Caso de Uso e seus Pesos correspondentes, conforme fornecido na tabela a seguir -

Fator Descrição Peso
T1 Sistema distribuído 2.0
T2 Tempo de resposta ou objetivos de desempenho de rendimento 1.0
T3 Eficiência do usuário final 1.0
T4 Processamento interno complexo 1.0
T5 O código deve ser reutilizável 1.0
T6 Fácil de instalar 0,5
T7 Fácil de usar 0,5
T8 Portátil 2.0
T9 Fácil de mudar 1.0
T10 Concorrente 1.0
T11 Inclui objetivos especiais de segurança 1.0
T12 Fornece acesso direto para terceiros 1.0
T13 Instalações especiais de treinamento de usuário são necessárias 1.0

Muitos desses fatores representam os requisitos não funcionais do projeto.

Step 2.2 - Para cada um dos 13 fatores, avalie o projeto e avalie de 0 (irrelevante) a 5 (muito importante).

Step 2.3 - Calcular o impacto do fator de peso de impacto do fator e o valor nominal para o projeto como

Impact of the Factor = Impact Weight × Rated Value

Step (2.4)- Calcule a soma do impacto de todos os fatores. Isso dá o Fator Técnico Total (TFactor) conforme indicado na tabela abaixo -

Fator Descrição Peso (W) Valor nominal (0 a 5) (RV) Impacto (I = W × RV)
T1 Sistema distribuído 2.0
T2 Tempo de resposta ou objetivos de desempenho de rendimento 1.0
T3 Eficiência do usuário final 1.0
T4 Processamento interno complexo 1.0
T5 O código deve ser reutilizável 1.0
T6 Fácil de instalar 0,5
T7 Fácil de usar 0,5
T8 Portátil 2.0
T9 Fácil de mudar 1.0
T10 Concorrente 1.0
T11 Inclui objetivos especiais de segurança 1.0
T12 Fornece acesso direto para terceiros 1.0
T13 Instalações especiais de treinamento de usuário são necessárias 1.0
Total Technical Factor (TFactor)

Step 2.5 - Calcular o fator de complexidade técnica (TCF) como -

TCF = 0.6 + (0.01 × TFactor)

Etapa 3: ajuste para complexidade ambiental

Step 3.1 - Considere os 8 Fatores Ambientais que podem afetar a execução do projeto e seus respectivos Pesos, conforme apresentado na tabela a seguir -

Fator Descrição Peso
F1 Familiarizado com o modelo de projeto que é usado 1,5
F2 Experiência de aplicação 0,5
F3 Experiência orientada a objetos 1.0
F4 Capacidade de analista líder 0,5
F5 Motivação 1.0
F6 Requisitos estáveis 2.0
F7 Equipe de meio período -1,0
F8 Linguagem de programação difícil -1,0

Step 3.2 - Para cada um dos 8 fatores, avalie o projeto e avalie de 0 (irrelevante) a 5 (muito importante).

Step 3.3 - Calcular o impacto do fator de peso de impacto do fator e o valor nominal para o projeto como

Impact of the Factor = Impact Weight × Rated Value

Step 3.4- Calcule a soma do impacto de todos os fatores. Isso dá o Fator Ambiental Total (EFactor) conforme dado na tabela a seguir -

Fator Descrição Peso (W) Valor nominal (0 a 5) (RV) Impacto (I = W × RV)
F1 Familiarizado com o modelo de projeto que é usado 1,5
F2 Experiência de aplicação 0,5
F3 Experiência orientada a objetos 1.0
F4 Capacidade de analista líder 0,5
F5 Motivação 1.0
F6 Requisitos estáveis 2.0
F7 Equipe de meio período -1,0
F8 Linguagem de programação difícil -1,0
Total Environment Factor (EFactor)

Step 3.5 - Calcule o Fator Ambiental (EF) como -

1.4 + (-0.03 × EFactor)

Etapa 4: Calcular Pontos de Caso de Uso Ajustados (UCP)

Calcule os pontos de caso de uso ajustados (UCP) como -

UCP = UUCP × TCF × EF

Vantagens e desvantagens dos pontos de caso de uso

Vantagens dos pontos de caso de uso

  • Os UCPs são baseados em casos de uso e podem ser medidos no início do ciclo de vida do projeto.

  • UCP (estimativa de tamanho) será independente do tamanho, habilidade e experiência da equipe que implementa o projeto.

  • As estimativas baseadas em UCP estão próximas dos reais quando a estimativa é realizada por pessoas experientes.

  • O UCP é fácil de usar e não requer análises adicionais.

  • Os casos de uso estão sendo amplamente usados ​​como método de escolha para descrever requisitos. Nesses casos, UCP é a técnica de estimativa mais adequada.

Desvantagens dos pontos de caso de uso

  • UCP pode ser usado apenas quando os requisitos são escritos na forma de casos de uso.

  • Depende de casos de uso bem escritos e orientados a objetivos. Se os casos de uso não forem bem ou uniformemente estruturados, o UCP resultante pode não ser preciso.

  • Fatores técnicos e ambientais têm um alto impacto na UCP. É preciso ter cuidado ao atribuir valores aos fatores técnicos e ambientais.

  • O UCP é útil para a estimativa inicial do tamanho geral do projeto, mas são muito menos úteis para conduzir o trabalho de iteração a iteração de uma equipe.

Delphi Methodé uma técnica de comunicação estruturada, originalmente desenvolvida como um método de previsão sistemático e interativo que conta com um painel de especialistas. Os especialistas respondem aos questionários em duas ou mais rodadas. Após cada rodada, um facilitador fornece um resumo anônimo das previsões dos especialistas da rodada anterior com os motivos de seus julgamentos. Os especialistas são então incentivados a revisar suas respostas anteriores à luz das respostas de outros membros do painel.

Acredita-se que durante esse processo o leque de respostas diminuirá e o grupo convergirá para a resposta "correta". Finalmente, o processo é interrompido após um critério de parada predefinido (por exemplo, número de rodadas, obtenção de consenso e estabilidade dos resultados) e a pontuação média ou mediana das rodadas finais determina os resultados.

O Método Delphi foi desenvolvido na década de 1950-1960 na RAND Corporation.

Técnica Delphi de banda larga

Na década de 1970, Barry Boehm e John A. Farquhar criaram a variante de banda larga do método Delphi. O termo "banda larga" é utilizado porque, comparada ao Método Delphi, a Técnica Delphi de banda larga envolveu maior interação e mais comunicação entre os participantes.

Na Wideband Delphi Technique, a equipe de estimativa compreende o gerente de projeto, moderador, especialistas e representantes da equipe de desenvolvimento, constituindo uma equipe de 3 a 7 membros. Existem duas reuniões -

  • Reunião de lançamento
  • Reunião de Estimativa

Técnica Delphi de banda larga - Passos

Step 1 - Escolha a equipe de estimativa e um moderador.

Step 2- O moderador conduz a reunião inicial, na qual é apresentada à equipe a especificação do problema e uma lista de tarefas de alto nível, quaisquer suposições ou restrições do projeto. A equipe discute o problema e as questões de estimativa, se houver. Eles também decidem sobre as unidades de estimativa. O moderador orienta toda a discussão, monitora o tempo e, após a reunião inicial, prepara um documento estruturado contendo a especificação do problema, lista de tarefas de alto nível, suposições e as unidades de estimativa que são decididas. Em seguida, ele encaminha cópias deste documento para a próxima etapa.

Step 3 - Cada membro da equipe de estimativa gera individualmente uma EAP detalhada, estima cada tarefa na EAP e documenta as suposições feitas.

Step 4- O moderador chama a equipe de Estimativa para a reunião de Estimativa. Se algum dos membros da equipe de Estimativa responder dizendo que as estimativas não estão prontas, o moderador dá mais tempo e reenvia o Convite para Reunião.

Step 5 - Toda a equipe de estimativa se reúne para a reunião de estimativa.

Step 5.1 - No início da reunião de Estimativa, o moderador coleta as estimativas iniciais de cada um dos membros da equipe.

Step 5.2- Ele então traça um gráfico no quadro branco. Ele plota a estimativa de projeto total de cada membro como um X na linha da Rodada 1, sem revelar os nomes correspondentes. A equipe de Estimação tem uma ideia da gama de estimativas, que inicialmente pode ser grande.

Step 5.3- Cada membro da equipe lê em voz alta a lista de tarefas detalhada que ele / ela fez, identificando quaisquer suposições feitas e levantando quaisquer dúvidas ou problemas. As estimativas de tarefas não são divulgadas.

As listas de tarefas detalhadas individuais contribuem para uma lista de tarefas mais completa quando combinadas.

Step 5.4 - A equipe então discute qualquer dúvida / problema que eles tenham sobre as tarefas às quais chegaram, suposições feitas e problemas de estimativa.

Step 5.5- Cada membro da equipe então revisita sua lista de tarefas e suposições e faz alterações, se necessário. As estimativas de tarefa também podem exigir ajustes com base na discussão, que são indicados como + N horas. para mais esforço e –N Hrs. por menos esforço.

Os membros da equipe então combinam as mudanças nas estimativas de tarefa para chegar à estimativa total do projeto.

Step 5.6 - O moderador coleta as estimativas alteradas de todos os membros da equipe e as plota na linha da segunda rodada.

Nesta rodada, o intervalo será mais estreito em comparação com a anterior, pois é mais baseado em consenso.

Step 5.7 - A equipe então discute as modificações de tarefa que fizeram e as suposições.

Step 5.8- Cada membro da equipe então revisita sua lista de tarefas e suposições e faz alterações, se necessário. As estimativas de tarefa também podem exigir ajustes com base na discussão.

Os membros da equipe, então, mais uma vez combinam as mudanças na estimativa da tarefa para chegar à estimativa total do projeto.

Step 5.9 - O moderador coleta as estimativas alteradas de todos os membros novamente e as plota na linha da terceira rodada.

Novamente, nesta rodada, o intervalo será mais estreito em comparação com o anterior.

Step 5.10 - As etapas 5.7, 5.8, 5.9 são repetidas até que um dos seguintes critérios seja atendido -

  • Os resultados são convergentes para uma faixa aceitavelmente estreita.
  • Todos os membros da equipe não estão dispostos a alterar suas estimativas mais recentes.
  • O tempo alocado para a reunião de estimativa acabou.

Step 6 - O Gerente de Projeto então monta os resultados da reunião de Estimativa.

Step 6.1 - Ele compila as listas de tarefas individuais e as estimativas correspondentes em uma única lista de tarefas mestre.

Step 6.2 - Ele também combina as listas individuais de suposições.

Step 6.3 - Ele então analisa a lista de tarefas final com a equipe de Estimação.

Vantagens e desvantagens da técnica Delphi de banda larga

Vantagens

  • A técnica Delphi de banda larga é uma técnica de estimativa baseada em consenso para estimar o esforço.
  • Útil ao estimar o tempo para realizar uma tarefa.
  • A participação de pessoas experientes e suas estimativas individuais levariam a resultados confiáveis.
  • As pessoas que fariam o trabalho estão fazendo estimativas, portanto, fazendo estimativas válidas.
  • O anonimato mantido o tempo todo possibilita que todos expressem seus resultados com segurança.
  • Uma técnica muito simples.
  • As premissas são documentadas, discutidas e acordadas.

Desvantagens

  • É necessário suporte de gerenciamento.
  • Os resultados da estimativa podem não ser o que a administração deseja ouvir.

A estimativa de três pontos considera três valores -

  • a estimativa mais otimista (O),
  • uma estimativa mais provável (M), e
  • uma estimativa pessimista (estimativa menos provável (L)).

Tem havido alguma confusão em relação à Estimativa de três pontos e PERT no setor. No entanto, as técnicas são diferentes. Você verá as diferenças ao aprender as duas técnicas. Além disso, no final da técnica PERT, as diferenças são comparadas e apresentadas. Se quiser dar uma olhada neles primeiro, você pode.

A estimativa de três pontos (E) é baseada na média simples e segue uma distribuição triangular.

E = (O + M + L) / 3

Desvio padrão

Na Distribuição Triangular,

Média = (O + M + L) / 3

Desvio padrão = √ [((O - E) 2 + (M - E) 2 + (L - E) 2 ) / 2]

Etapas de estimativa de três pontos

Step 1 - Chegue na WBS.

Step 2 - Para cada tarefa, encontre três valores - estimativa mais otimista (O), uma estimativa mais provável (M) e uma estimativa pessimista (L).

Step 3 - Calcule a média dos três valores.

Mean = (O + M + L) / 3

Step 4- Calcule a estimativa de três pontos da tarefa. A estimativa de três pontos é a média. Conseqüentemente,

E = Mean = (O + M + L) / 3

Step 5 - Calcular o desvio padrão da tarefa.

Standard Deviation (SD) = √ [((O − E)2 + (M − E)2 + (L - E)2)/2]

Step 6 - Repita as etapas 2, 3, 4 para todas as tarefas da EAP.

Step 7 - Calcular a estimativa de três pontos do projeto.

E (Project) = ∑ E (Task)

Step 8 - Calcular o desvio padrão do projeto.

SD (Project) = √ (∑SD (Task)2)

Converta as estimativas do projeto em níveis de confiança

A estimativa de três pontos (E) e o desvio padrão (DP) assim calculados são usados ​​para converter as estimativas do projeto para “Níveis de confiança”.

A conversão é baseada de forma que -

  • O nível de confiança em E +/– DP é de aproximadamente 68%.
  • O nível de confiança no valor E +/– 1,645 × DP é de aproximadamente 90%.
  • O nível de confiança no valor E +/– 2 × DP é de aproximadamente 95%.
  • O nível de confiança no valor E +/– 3 × DP é de aproximadamente 99,7%.

Normalmente, o nível de confiança de 95%, ou seja, valor E + 2 × SD, é usado para todas as estimativas de projeto e tarefa.

A estimativa da técnica de avaliação e revisão do projeto (PERT) considera três valores: a estimativa mais otimista (O), uma estimativa mais provável (M) e uma estimativa pessimista (estimativa menos provável (L)). Tem havido alguma confusão em relação à estimativa de três pontos e PERT na indústria. No entanto, as técnicas são diferentes. Você verá as diferenças ao aprender as duas técnicas. Além disso, no final deste capítulo, as diferenças são comparadas e apresentadas.

PERT é baseado em três valores - estimativa mais otimista (O), uma estimativa mais provável (M) e uma estimativa pessimista (estimativa menos provável (L)). A estimativa mais provável é 4 vezes mais ponderada do que as outras duas estimativas (otimista e pessimista).

A estimativa PERT (E) é baseada na média ponderada e segue a distribuição beta.

E = (O + 4 × M + L)/6

PERT é freqüentemente usado junto com Critical Path Method (CPM). CPM fala sobre as tarefas que são críticas no projeto. Se houver um atraso nessas tarefas, o projeto fica atrasado.

Desvio padrão

O Desvio Padrão (DP) mede a variabilidade ou incerteza na estimativa.

Na distribuição beta,

Média = (O + 4 × M + L) / 6

Desvio Padrão (SD) = (L - O) / 6

Etapas de estimativa PERT

Step (1) - Chegue na WBS.

Step (2) - Para cada tarefa, encontre três valores de estimativa mais otimista (O), uma estimativa mais provável (M) e uma estimativa pessimista (L).

Step (3) - Média PERT = (O + 4 × M + L) / 6

Média PERT = (O + 4 × M + L) / 3

Step (4) - Calcular o desvio padrão da tarefa.

Desvio Padrão (SD) = (L - O) / 6

Step (6) - Repita as etapas 2, 3, 4 para todas as tarefas na EAP.

Step (7) - Calcular a estimativa PERT do projeto.

E (Projeto) = ∑ E (Tarefa)

Step (8) - Calcular o desvio padrão do projeto.

SD (Projeto) = √ (ΣSD (Tarefa) 2 )

Converta as estimativas do projeto em níveis de confiança

Estimativa PERT (E) e Desvio Padrão (SD) assim calculados são usados ​​para converter as estimativas do projeto para níveis de confiança.

A conversão é baseada de forma que

  • O nível de confiança em E +/– SD é de aproximadamente 68%.
  • O nível de confiança no valor E +/– 1,645 × SD é de aproximadamente 90%.
  • O nível de confiança no valor E +/– 2 × DP é de aproximadamente 95%.
  • O nível de confiança no valor E +/– 3 × SD é de aproximadamente 99,7%.

Normalmente, o nível de confiança de 95%, ou seja, Valor E + 2 × SD, é usado para todas as estimativas de projeto e tarefa.

Diferenças entre a estimativa de três pontos e PERT

A seguir estão as diferenças entre a estimativa de três pontos e PERT -

Estimativa de três pontos PERT
Média simples Média ponderada
Segue a distribuição triangular Segue a distribuição beta
Usado para pequenos projetos repetitivos Usado para grandes projetos não repetitivos, geralmente projetos de P&D. Usado junto com o Método do Caminho Crítico (CPM)

E = Média = (O + M + L) / 3

Esta é a média simples

E = Média = (O + 4 × M + L) / 6

Esta é a média ponderada

SD = √ [((O - E) 2 + (M - E) 2 + (L - E) 2 ) / 2] SD = (L - O) / 6

Analogous Estimationusa informações de projetos anteriores semelhantes para estimar a duração ou o custo do projeto atual, daí a palavra "analogia". Você pode usar uma estimativa análoga quando houver informações limitadas sobre seu projeto atual.

Freqüentemente, haverá situações em que os gerentes de projeto serão solicitados a fornecer estimativas de custo e duração para um novo projeto, pois os executivos precisam de dados de tomada de decisão para decidir se vale a pena fazer o projeto. Normalmente, nem o gerente de projeto nem qualquer outra pessoa na organização jamais realizou um projeto como o novo, mas os executivos ainda querem estimativas precisas de custo e duração.

Nesses casos, a estimativa análoga é a melhor solução. Pode não ser perfeito, mas é preciso, pois se baseia em dados anteriores. A estimativa análoga é uma técnica fácil de implementar. A taxa de sucesso do projeto pode ser de até 60% em comparação com as estimativas iniciais.

Estimativa análoga - Definição

Estimativa análoga é uma técnica que usa os valores dos parâmetros de dados históricos como base para estimar parâmetros semelhantes para uma atividade futura. Exemplos de parâmetros: escopo, custo e duração. Exemplos de medidas de escala - tamanho, peso e complexidade.

Como a experiência e o julgamento do gerente de projeto e, possivelmente, da equipe são aplicados ao processo de estimativa, ele é considerado uma combinação de informações históricas e opinião especializada.

Requisitos de estimativa análoga

Para estimativa análoga, o seguinte é o requisito -

  • Dados de projetos anteriores e em andamento
    • Horas de trabalho semanais de cada membro da equipe
    • Custos envolvidos para concluir o projeto
  • Projeto próximo ao projeto atual
  • Caso o projeto atual seja novo e nenhum projeto anterior seja semelhante
    • Módulos de projetos anteriores semelhantes aos do projeto atual
    • Atividades de projetos anteriores semelhantes às do projeto atual
    • Dados desses selecionados
  • Participação do gerente de projeto e equipe de estimativa para garantir julgamento experiente nas estimativas.

Etapas de estimativa análogas

O gerente de projeto e a equipe devem fazer estimativas análogas coletivamente.

  • Step 1 - Identificar o domínio do projeto atual.

  • Step 2 - Identificar a tecnologia do projeto atual.

  • Step 3- Procure no banco de dados da organização se dados de projeto semelhantes estão disponíveis. Se disponível, vá para a Etapa (4). Caso contrário, vá para a Etapa (6).

  • Step 4 - Compare o projeto atual com os dados de projetos anteriores identificados.

  • Step 5- Chegar à estimativa de duração e custo do projeto atual. Isso encerra a estimativa análoga do projeto.

  • Step 6 - Procure no banco de dados da organização se algum projeto anterior possui módulos semelhantes aos do projeto atual.

  • Step 7 - Procure no banco de dados da organização se algum projeto anterior teve atividades semelhantes às do projeto atual.

  • Step 8 - Colete todos aqueles e use a opinião de especialistas para chegar às estimativas de duração e custo do projeto atual.

Vantagens da estimativa análoga

  • A estimativa análoga é a melhor maneira de estimar nos estágios iniciais do projeto, quando poucos detalhes são conhecidos.

  • A técnica é simples e o tempo necessário para a estimativa é muito menor.

  • Pode-se esperar que a taxa de sucesso da organização seja alta, já que a técnica é baseada nos dados de projetos anteriores da organização.

  • A estimativa análoga também pode ser usada para estimar o esforço e a duração de tarefas individuais. Portanto, na WBS, ao estimar as tarefas, você pode usar a Analogia.

A Estrutura Analítica do Projeto (WBS), em Gerenciamento de Projetos e Engenharia de Sistemas, é uma decomposição orientada para a entrega de um projeto em componentes menores. A WBS é uma entrega importante do projeto que organiza o trabalho da equipe em seções gerenciáveis. O Project Management Body of Knowledge (PMBOK) define a EAP como uma "decomposição hierárquica orientada para entregas do trabalho a ser executado pela equipe do projeto."

O elemento WBS pode ser um produto, dados, serviço ou qualquer combinação destes. A WBS também fornece a estrutura necessária para estimativa e controle de custos detalhados, juntamente com orientações para o desenvolvimento e controle do cronograma.

Representação da WBS

A WBS é representada como uma lista hierárquica das atividades de trabalho do projeto. Existem dois formatos de WBS -

  • Visão de esboço (formato recuado)
  • Visualização da estrutura em árvore (organograma)

Vamos primeiro discutir como usar a visualização de esboço para preparar uma WBS.

Vista de destaques

A visualização do contorno é um layout muito amigável. Apresenta uma boa visão de todo o projeto e também permite modificações fáceis. Ele usa números para registrar as várias etapas de um projeto. É um pouco semelhante ao seguinte -

  • Software Development

    • Scope

      • Determinar o escopo do projeto
      • Patrocínio seguro do projeto
      • Definir recursos preliminares
      • Recursos essenciais seguros
      • Escopo completo
    • Analysis/Software Requirements

      • Realizar análise de necessidades
      • Rascunho de especificações preliminares de software
      • Desenvolver orçamento preliminar
      • Revise as especificações / orçamento do software com a equipe
      • Incorpore feedback sobre especificações de software
      • Desenvolver cronograma de entrega
      • Obtenha aprovações para prosseguir (conceito, cronograma e orçamento)
      • Proteja os recursos necessários
      • Análise completa
    • Design

      • Revise as especificações preliminares do software
      • Desenvolva especificações funcionais
      • Obtenha aprovação para prosseguir
      • Design completo
    • Development

      • Revise as especificações funcionais
      • Identifique os parâmetros de design modular / em camadas
      • Desenvolver código
      • Teste de desenvolvedor (depuração primária)
      • Desenvolvimento completo
    • Testing

      • Desenvolver planos de teste de unidade usando especificações de produto
      • Desenvolver planos de teste de integração usando especificações de produto
    • Training

      • Desenvolver especificações de treinamento para usuários finais
      • Identifique a metodologia de entrega de treinamento (online, sala de aula, etc.)
      • Desenvolver materiais de treinamento
      • Finalizar os materiais de treinamento
      • Desenvolver mecanismo de entrega de treinamento
      • Materiais de treinamento completos
    • Deployment

      • Determine a estratégia de implantação final
      • Desenvolver metodologia de implantação
      • Recursos de implantação seguros
      • Treinar equipe de suporte
      • Implantar software
      • Implantação concluída

Vamos agora dar uma olhada na visualização da estrutura em árvore.

Visão da Estrutura da Árvore

A Tree Structure View apresenta uma visão muito fácil de entender de todo o projeto. A ilustração a seguir mostra a aparência de uma visualização da estrutura em árvore. Este tipo de estrutura de organograma pode ser facilmente desenhado com os recursos disponíveis no MS-Word.

Tipos de WBS

Existem dois tipos de WBS -

  • Functional WBS- Na WBS funcional, o sistema é quebrado com base nas funções do aplicativo a ser desenvolvido. Isso é útil para estimar o tamanho do sistema.

  • Activity WBS- Na atividade WBS, o sistema é quebrado com base nas atividades no sistema. As atividades são subdivididas em tarefas. Isso é útil para estimar o esforço e o cronograma do sistema.

Tamanho estimado

Step 1 - Comece com WBS funcional.

Step 2 - Considere os nós de folha.

Step 3 - Use Analogy ou Wideband Delphi para chegar às estimativas de tamanho.

Esforço de estimativa

Step 1- Use a técnica Delphi de banda larga para construir a WBS. Sugerimos que as tarefas não durem mais de 8 horas. Se uma tarefa tiver uma duração maior, divida-a.

Step 2 - Use a Técnica Delphi de Banda Larga ou Estimativa de Três Pontos para chegar às Estimativas de Esforço para as Tarefas.

Agendamento

Assim que a EAP estiver pronta e as estimativas de tamanho e esforço forem conhecidas, você estará pronto para programar as tarefas.

Ao programar as tarefas, certas coisas devem ser levadas em consideração -

  • Precedence - Diz-se que uma tarefa que deve ocorrer antes de outra tem precedência sobre a outra.

  • Concurrence - Tarefas simultâneas são aquelas que podem ocorrer ao mesmo tempo (em paralelo).

  • Critical Path - Conjunto específico de tarefas sequenciais das quais depende a data de conclusão do projeto.

    • Todos os projetos têm um caminho crítico.
    • A aceleração de tarefas não críticas não encurta diretamente o cronograma.

Método do Caminho Crítico

Método do caminho crítico (CPM) é o processo para determinar e otimizar o caminho crítico. As tarefas de caminho não crítico podem começar mais cedo ou mais tarde, sem afetar a data de conclusão.

Observe que o caminho crítico pode mudar para outro conforme você encurta o atual. Por exemplo, para WBS na figura anterior, o caminho crítico seria o seguinte -

Como a data de conclusão do projeto é baseada em um conjunto de tarefas sequenciais, essas tarefas são chamadas de tarefas críticas.

A data de conclusão do projeto não é baseada no treinamento, documentação e implantação. Essas tarefas são chamadas de tarefas não críticas.

Relacionamentos de Dependência de Tarefa

Algumas vezes, durante o agendamento, pode ser necessário considerar os relacionamentos de dependência de tarefa. Os relacionamentos de dependência de tarefas importantes são -

  • Concluir para iniciar (FS)
  • Fim a Fim (FF)

Concluir para iniciar (FS)

No relacionamento de dependência de tarefa Concluir para Iniciar (FS), a Tarefa B não pode ser iniciada até que a Tarefa A seja concluída.

Fim a Fim (FF)

No relacionamento de dependência de tarefa Concluir para Concluir (FF), a Tarefa B não pode terminar até que a Tarefa A seja concluída.

Gráfico de Gantt

Um gráfico de Gantt é um tipo de gráfico de barras, adaptado por Karol Adamiecki em 1896 e independentemente por Henry Gantt na década de 1910, que ilustra um cronograma de projeto. Os gráficos de Gantt ilustram as datas de início e término dos elementos terminais e elementos de resumo de um projeto.

Você pode usar o formato de estrutura de tópicos da Figura 2 no Microsoft Project para obter uma visualização do gráfico de Gantt.

Milestones

Marcos são os estágios críticos de sua programação. Eles terão uma duração zero e são usados ​​para sinalizar que você concluiu um determinado conjunto de tarefas. Os marcos geralmente são mostrados como um diamante.

Por exemplo, no Gráfico de Gantt acima, Design Complete e Development Complete são mostrados como marcos, representados com uma forma de diamante.

Os marcos podem ser vinculados aos termos do contrato.

Vantagens da estimativa usando WBS

WBS simplifica o processo de estimativa de projeto em grande medida. Ele oferece as seguintes vantagens sobre outras técnicas de estimativa -

  • Na WBS, todo o trabalho a ser feito pelo projeto é identificado. Portanto, ao revisar a EAP com as partes interessadas do projeto, você terá menos probabilidade de omitir qualquer trabalho necessário para entregar as entregas do projeto desejadas.

  • A WBS resulta em estimativas de custo e cronograma mais precisas.

  • O gerente do projeto obtém a participação da equipe para finalizar a EAP. Esse envolvimento da equipe gera entusiasmo e responsabilidade no projeto.

  • A WBS fornece uma base para as atribuições de tarefas. Como uma tarefa precisa é atribuída a um determinado membro da equipe que seria responsável por sua realização.

  • A WBS permite monitorar e controlar no nível da tarefa. Isso permite medir o progresso e garantir que seu projeto seja entregue no prazo.

Planning Poker Estimation

O Planning Poker é uma técnica de estimativa baseada em consenso, usada principalmente para estimar o esforço ou o tamanho relativo das histórias de usuário no Scrum.

O Planning Poker combina três técnicas de estimativa - Wideband Delphi Technique, Analogous Estimation e Estimation using WBS.

O Planning Poker foi definido e nomeado pela primeira vez por James Grenning em 2002 e mais tarde popularizado por Mike Cohn em seu livro "Agile Estimating and Planning", cujo comércio marcou o termo.

Técnica de estimativa de poker de planejamento

Em Planning Poker Estimation Technique, as estimativas para as histórias de usuários são derivadas do planejamento de poker. Todo o time Scrum está envolvido e isso resulta em estimativas rápidas, mas confiáveis.

  • O Planning Poker é jogado com um baralho de cartas. Como a sequência de Fibonacci é usada, as cartas têm números - 1, 2, 3, 5, 8, 13, 21, 34, etc. Esses números representam os “Story Points”. Cada avaliador possui um baralho de cartas. Os números nos cartões devem ser grandes o suficiente para serem visíveis a todos os membros da equipe, quando um dos membros da equipe segura um cartão.

  • Um dos membros da equipe é selecionado como moderador. O moderador lê a descrição da história do usuário para a qual a estimativa está sendo feita. Se os avaliadores tiverem alguma dúvida, o product owner responde.

  • Cada avaliador seleciona em particular uma carta que representa sua estimativa. Os cartões não são exibidos até que todos os estimadores tenham feito uma seleção. Nesse momento, todos os cartões são virados e erguidos simultaneamente para que todos os membros da equipe possam ver cada estimativa.

  • Na primeira rodada, é muito provável que as estimativas variem. Os estimadores alto e baixo explicam o motivo de suas estimativas. Deve-se ter cuidado para que todas as discussões sejam destinadas apenas à compreensão e nada seja para ser levado pessoalmente. O moderador deve garantir o mesmo.

  • A equipe pode discutir a história e suas estimativas por mais alguns minutos.

  • O moderador pode fazer anotações sobre a discussão que serão úteis quando a história específica for desenvolvida. Após a discussão, cada estimador faz uma nova estimativa, selecionando novamente um cartão. Os cartões são mais uma vez mantidos em sigilo até que todos façam uma estimativa, momento em que são entregues ao mesmo tempo.

Repita o processo até que as estimativas convergem para uma única estimativa que pode ser usada para a história. O número de rodadas de estimativa pode variar de uma história de usuário para outra.

Benefícios do Planning Poker Estimation

O Planning Poker combina três métodos de estimativa -

Expert Opinion- Na abordagem de estimativa baseada na opinião de especialistas, pergunta-se a um especialista quanto tempo algo levará ou quão grande será. O especialista fornece uma estimativa com base em sua experiência, intuição ou intuição. A estimativa de opinião de especialista geralmente não leva muito tempo e é mais precisa em comparação com alguns dos métodos analíticos.

Analogy- A estimativa de analogia usa a comparação de histórias de usuários. A história do usuário sob estimativa é comparada com histórias de usuário semelhantes implementadas anteriormente, fornecendo resultados precisos, pois a estimativa é baseada em dados comprovados.

Disaggregation- A estimativa de desagregação é feita dividindo uma história de usuário em histórias de usuário menores e mais fáceis de estimar. As histórias de usuário a serem incluídas em um sprint levam normalmente de dois a cinco dias para serem desenvolvidas. Portanto, as histórias de usuário que possivelmente demoram mais precisam ser divididas em casos de uso menores. Essa abordagem também garante que haja muitas histórias comparáveis.

Os esforços de teste não são baseados em nenhum período de tempo definitivo. Os esforços continuam até que algum cronograma pré-definido seja definido, independentemente da conclusão dos testes.

Isso se deve principalmente ao fato de que, convencionalmente, test effort estimation é uma parte do development estimation. Apenas no caso de técnicas de estimativa que usam WBS, como Wideband Delphi, Three-point Estimation, PERT e WBS, você pode obter os valores para as estimativas das atividades de teste.

Se você obteve as estimativas como Pontos de Função (FP), então de acordo com Caper Jones,

Number of Test Cases = (Number of Function Points) × 1.2

Depois de ter o número de casos de teste, você pode obter dados de produtividade do banco de dados organizacional e chegar ao esforço necessário para o teste.

Método de porcentagem de esforço de desenvolvimento

O esforço de teste necessário é uma proporção direta ou porcentagem do esforço de desenvolvimento. O esforço de desenvolvimento pode ser estimado usando linhas de código (LOC) ou pontos de função (FP). Em seguida, a porcentagem de esforço para teste é obtida no banco de dados da organização. A porcentagem assim obtida é usada para chegar à estimativa de esforço para teste.

Estimando Projetos de Teste

Várias organizações estão agora fornecendo serviços independentes de verificação e validação para seus clientes e isso significaria que as atividades do projeto seriam inteiramente atividades de teste.

A estimativa de projetos de teste requer experiência em projetos variados para o ciclo de vida do teste de software. Quando você está estimando um projeto de teste, considere -

  • Habilidades de equipe
  • Conhecimento de Domínio
  • Complexidade do aplicativo
  • Data histórica
  • Ciclos de bug para o projeto
  • Disponibilidade de recursos
  • Variações de produtividade
  • Ambiente do sistema e tempo de inatividade

Técnicas de estimativa de teste

As seguintes técnicas de estimativa de teste são comprovadamente precisas e são amplamente utilizadas -

  • Técnica de estimativa de teste de software PERT
  • Método UCP
  • WBS
  • Técnica Delphi de banda larga
  • Análise de ponto de função / ponto de teste
  • Distribuição percentual
  • Técnica de estimativa de teste baseada na experiência

Técnica de estimativa de teste de software PERT

A técnica de estimativa de teste de software PERT é baseada em métodos estatísticos nos quais cada tarefa de teste é dividida em subtarefas e, em seguida, três tipos de estimativa são feitos em cada subtarefa.

A fórmula usada por esta técnica é -

Test Estimate = (O + (4 × M) + E)/6

Onde,

O = Estimativa otimista (melhor cenário em que nada dá errado e todas as condições são ótimas).

M = Estimativa mais provável (duração mais provável e pode haver algum problema, mas a maioria das coisas dará certo).

L = Estimativa pessimista (pior cenário em que tudo dá errado).

O desvio padrão para a técnica é calculado como -

Standard Deviation (SD) = (E − O)/6

Método de Ponto de Caso de Uso

O Método UCP é baseado nos casos de uso em que calculamos os pesos dos atores não ajustados e os pesos dos casos de uso não ajustados para determinar a estimativa de teste de software.

Caso de uso é um documento que especifica diferentes usuários, sistemas ou outras partes interessadas interagindo com o aplicativo em questão. Eles são chamados de “Atores”. As interações alcançam alguns objetivos definidos protegendo o interesse de todas as partes interessadas por meio de diferentes comportamentos ou fluxos denominados como cenários.

Step 1- Conte o não. de atores. Os atores incluem positivo, negativo e excepcional.

Step 2 - Calcular pesos de ator não ajustados como

Unadjusted Actor Weights = Total no. of Actors

Step 3 - Conte o número de casos de uso.

Step 4 - Calcular pesos de casos de uso não ajustados como

Unadjusted Use-Case Weights = Total no. of Use-Cases

Step 5 - Calcular pontos de caso de uso não ajustados como

Unadjusted Use-Case Points = (Unadjusted Actor Weights + Unadjusted Use-Case Weights)

Step 6- Determinar o fator técnico / ambiental (TEF). Se indisponível, considere 0,50.

Step 7 - Calcular o ponto de caso de uso ajustado como

Adjusted Use-Case Point = Unadjusted Use-Case Points × [0.65 + (0.01 × TEF]

Step 8 - Calcule o esforço total como

Total Effort = Adjusted Use-Case Point × 2

TrabalhoDemolirEstrutura

Step 1 - Crie WBS dividindo o projeto de teste em pequenos pedaços.

Step 2 - Divida os módulos em submódulos.

Step 3 Divida os submódulos ainda mais em funcionalidades.

Step 4 - Divida as funcionalidades em subfuncionalidades.

Step 5 - Revise todos os requisitos de teste para garantir que eles sejam adicionados à EAP.

Step 6 - Descubra o número de tarefas que sua equipe precisa concluir.

Step 7 - Estime o esforço para cada tarefa.

Step 8 - Estimar a duração de cada tarefa.

Técnica Delphi de banda larga

No método Delphi de banda larga, a WBS é distribuída para uma equipe composta de 3 a 7 membros para re-estimar as tarefas. A estimativa final é o resultado das estimativas resumidas com base no consenso da equipe.

Este método fala mais sobre a experiência do que qualquer fórmula estatística. Este método foi popularizado por Barry Boehm para enfatizar a iteração do grupo para chegar a um consenso onde a equipe visualizava diferentes aspectos dos problemas enquanto estimava o esforço do teste.

Análise de Ponto de Função / Ponto de Teste

Os FPs indicam a funcionalidade do aplicativo de software da perspectiva do usuário e são usados ​​como uma técnica para estimar o tamanho de um projeto de software.

No teste, a estimativa é baseada no documento de especificação de requisitos ou em um protótipo criado anteriormente do aplicativo. Para calcular o PF de um projeto, alguns componentes principais são necessários. Eles são -

  • Unadjusted Data Function Points - i) Arquivos internos, ii) Interfaces externas

  • Unadjusted Transaction Function Points - i) Entradas do usuário, ii) Saídas do usuário e iii) Consultas do usuário

  • Capers Jones basic formula -

    Número de casos de teste = (número de pontos de função) × 1,2

  • Total Actual Effort (TAE) -

    (Número de casos de teste) × (Porcentagem de esforço de desenvolvimento / 100)

Distribuição percentual

Nesta técnica, todas as fases do Ciclo de Vida de Desenvolvimento de Software (SDLC) são atribuídas esforço em%. Isso pode ser baseado em dados anteriores de projetos semelhantes. Por exemplo -

Fase % de esforço
Gerenciamento de Projetos 7%
Requisitos 9%
Projeto 16%
Codificação 26%
Teste (todas as fases de teste) 27%
Documentação 9%
Instalação e treinamento 6%

Em seguida,% de esforço para teste (todas as fases de teste) é distribuído para todas as fases de teste -

Todas as fases de teste % de esforço
Teste de Componente 16
Teste Independente 84
Total 100
Teste Independente % de esforço
Teste de integração 24
Teste de Sistema 52
Teste de aceitação 24
Total 100
Teste de Sistema % de esforço
Teste de sistema funcional 65
Teste de sistema não funcional 35
Total 100
Planejamento de teste e arquitetura de design 50%
Fase de revisão 50%

Técnica de estimativa de teste baseada na experiência

Esta técnica é baseada em analogias e especialistas. A técnica pressupõe que você já testou aplicativos semelhantes em projetos anteriores e coletou métricas desses projetos. Você também coletou métricas de testes anteriores. Receba contribuições de especialistas no assunto que conhecem o aplicativo (bem como o teste) muito bem e use as métricas que você coletou e chegue ao esforço de teste.