Estudo Dirigido

Curso: sistema de informaçãoDisciplina: PE- medidas do esforço no desenvolvimento de softwareMódulo:Eixo:Aula 07 estimativas Putnam e métodos voltado para ponto função

Todos os itens abaixo elencados são de preenchimento obrigatório pelo autor conteudista que deverá preencher um documento deste a cada aula da disciplina.Legenda:

** Instruções para o conteudista preparar o conteúdo a ser inserido em cada ícone.

* Texto padrão a ser utilizado pelo conteudista caso não haja conteúdo a ser inserido no

ícone. – Exemplo: utilizar o texto padrão para Livro no campo Livro se não existir nenhuma

indicação de capítulo para a aula em questão.

**Redigir objetivos claros e diretos. Começar objetivos com verbos. Não ser prolixo ao

enumerar aos objetivos. Usar os objetivos como uma ferramenta que direcione o que o aluno

deve ter como foco ao relacionar os objetivos apresentados ao conteúdo da aula.

Cuidado! Geralmente pensamos em objetivos do tipo: Estudar o panorama da economia mundial pós-guerra. Isso não pode ser o objetivo do aluno. Nesse caso, poderia ser Identificar três aspectos que afetaram a economia mundial no período pós-guerra.

*Nesta aula, você irá:

Nesta aula você irá:

- Aprender sobre o método de Putnam - Analisar a fórmula do Método de Putnam.- Aprender sobre outras formas de estimativas de projetos orientado a objetos

- aprender sobre Estimativas com métodos ágeis

- aprendeu a usar APF para determinar estimativas

Introdução da Aula 07

**Escrever um pequeno texto (no máximo 3 parágrafos) apresentando o tema que será

estudado e motivando o aluno para a realização do estudo. Neste ícone, o conteudista dá uma

visão geral dos tópicos a serem abordados na aula, introduzindo o assunto ao aluno.

*A partir deste texto introdutório, você será capaz de entender melhor os conceitos

estudados nesta aula, sendo capaz de relacionar o conteúdo que será aprendido ao contexto

em que está inserido.

Olá!

Nesta aula vamos aprender que existem outras formas de estimativas, ainda usando Linhas de código temos o método de Putnam que considera múltiplas variáveis e considera o ciclo de desenvolvimento do projeto. Vamos aprender sobre métodos para estimar quando usamos métodos rápidos para processo de desenvolvimento e a importância de se trabalhar com PF.

Aula teletransmitida

** Neste ícone, o conteudista discrimina os tópicos a serem abordados na aula. É importante

verificar se os tópicos aqui apresentados estão relacionados aos da aula online para que não

haja disparidade entre os conteúdos apresentados em cada modalidade. É importante

destacar:

- Principais tópicos a serem abordados.

- Conceitos a serem tratados na aula.

- Enfoques que serão dados aos tópicos estudados.

- Indicação do assunto no Livro Universitário (Customizado): indicar as páginas, capítulos

pertinentes para cada tópico.

* Assista à aula teletransmitida 00 que aborda os seguintes tópicos:

- Tópico 1.

- Tópico 2.

- Tópico 3.

- Explicar que existem outras propostas de outros pesquisadores

- Explicar os objetivos do método de Putnam mostrando a diferença do método cocomo.

- Mostrar como se usa um método baseado em Ponto Função.

- desenvolver um exemplo utilizando ponto função e fazer estimativas

- mostrar a necessidade de se manter uma base estatística para possibilitar novas estimativas.

- mostrar os métodos ágeis e como fazer estimativas quando se usa estes métodos.

- mostrar a vantagem de se trabalhar com PF e não com métodos de tamanho.

- desenvolver um exemplo fazendo estimativas com o cocomo e APF

Livro

** Neste ícone, o conteudista indica a bibliografia a ser lida pelo aluno, ou seja, os capítulos do

material didático que o aluno recebe a serem lidos nesta aula.

Antes de indicar o livro, verificar se o mesmo está disponível na pasta do professor

(https://pastadoprofessor.com.br/) ou no pool de editoras participantes.

*Não deixe de reler o material didático que você recebeu. Também aumente o seu

conhecimento pesquisando sobre os tópicos abordados na aula. Desta forma, você vai estar

se preparando melhor para realizar suas avaliações. No caso de dúvidas, entre em contato

com seu professor online.

Acesse a biblioteca virtual da sua disciplina e leia o material disponível.

- Medidas de tamanho de desenvolvimento e de melhorias de software.

- Título: Engenharia de Software Editora: Pearson Education Autor: Pressman,Roger S.EAN-13: 9788587918369Ano: 2006Edição: 6ªCapítulo23: ESTIMATIVAS DE PROJETO DE SOFTWARE- Título: 23.7 Modelos de estimativa Empíricos

Pagina 519 a 543. (24 páginas). 

Aula online

*Estude o conteúdo da sua aula online prestando atenção aos objetivos apresentados.

Percorra atentamente o conteúdo da aula e realize todas as atividades propostas. Realize os

exercícios propostos e se autoavalie. Após concluir o estudo, verifique se entendeu todo o

conteúdo e, se tiver alguma dúvida, procure esclarecê-la com seu professor online. Para isso,

utilize os recursos do ambiente de aprendizagem.

Para esta aula sugiro que: Leia o texto condutor da aula. Leia o capítulo 23 do livro Engenharia de Software do

prof Pressman Faça o desafio. Participe do Fórum Coloque, no mural, o resultado de sua pesquisa

Aprenda mais!

Visite os sites abaixo para completar os seus estudos

1 . Como fazer estimativas num Projeto de Software?

www.dsc.ufcg.edu.br/~patricia/pct/aula9/estimativas.PDF

2 . Análise de Pontos de Função: Medição, Estimativas e Gerenciamento ...

www.fattocs.com.br/livro.asp - Em   cache - Similares

3. INICIAÇÃO DO PROJETO PLANEJAMENTO PRELIMINAR

www.facom.ufu.br/~bacala/PIS2011/Planejamento_Esforco.pdf

** Neste ícone, o conteudista irá indicar sites complementares, artigos a serem lidos,

pesquisas, vídeos a serem assistidos ou qualquer outro material que possa ser usado para

aumentar o conhecimento do aluno.

Os temas dos fóruns, bem como as aulas em que eles entrarão também devem ser apontados

neste espaço.

*Para saber mais sobre os tópicos estudados nesta aula, pesquise na internet sites, vídeos e

artigos relacionados ao conteúdo visto. Se ainda tiver alguma dúvida, fale com seu professor

online utilizando os recursos disponíveis no ambiente de aprendizagem.

**Reforçar os principais pontos estudados e seus objetivos. Por exemplo:

*Nesta aula, você:

- Aprendeu sobre a formula de estimativas de Putnam

- Aprendeu que existem outras proposta de estimativas

- Aprendeu a estimar por pontos de Objetos (telas, relatórios...)

- Aprendeu a fazer estimativas mesmo quando se usa métodos ágeis

- Aprendeu a utilidade de se estimar por ponto função

- Acompanhou o desenvolvimento de um exemplo completo

Próxima aula

** Neste ícone, deverá entrar sempre os tópicos a serem estudados na aula seguinte.

*Na próxima aula, você vai estudar sobre os assuntos seguintes:

- Assunto 1.

- Assunto 2.

- Assunto 3.

Na próxima aula vamos aprender:- a usar as estimativas para gerenciar um projeto- a usar a técnica de ponto função como instrumento de gestão. - Vamos aprender a dimensionar receita e custos a partir de ponto função. - Vamos aprender a utilizar estes valores se distribuem no processo de desenvolvimento, na gestão do projeto e da empresa- Definir métricas que sirvam de parâmetros para a gestão.

**Elaborar de 2 a 5 questões objetivas de múltipla escolha (5 opções de resposta) com gabarito.

INSERIR AQUI OS EXERCÍCIOS DE AUTOCORREÇÃO

1 – considere a constante CK na formula

a) Representa as condições de trabalho da empresa refletido por projetos já realizados

b) Representa um determinado projeto K para os quais devemos analisar as condições

c) Representa uma função que reflete o crescimento de uma empresa

d) Representa o esforço despendido em pessoas-anoe) Representa a fase do projeto, refletindo a etapa K

Resposta a

2 – No Software orientado a objetos, segundo o Prof. Pressman, podemos afirmar:

A) Deve-se usar a estimativa de tamanho para dimensionar um caso e uso.

B) Deve-s analisar cada caso e uso e fazer estimativas de tamanho somando-os no final

C) Deve-se usar a estimativa por PF usando-se a decomposição de casos e uso

D) Deve-se definir um caso e uso padrão e o resultado aplicado ao longo do projeto

E) Devem-se modelar as classes principais e depois aplicar PF que servirá de unidade para o resto do projeto.

Resposta c

3 – Considerando a pesquisa realizada pela Secretaria de Política de Informática – SEPIN , em 2001, cujo resultado é apresentado na tabela:

Categorias Nº de organizações Percentual(%)Linhas de código ( LOC ) 25 5,6Pontos por função ( Function Point ) 43 9,6Outras métricas 26 5,8Não utiliza 363 81,4Base 446 100

Podemos concluir de forma correta:

a) As empresas que utilizam LOC são todas do governo.b) As empresas que utilizam Ponto função são todas do governoc) Todas as empresas do Governo e privadas usam LOC ou Ponto funçãod) As estimativas no Brasil ainda são feitas, na sua maioria, sem métodoe) As estimativas no Brasil feitas com ponto função tem muita rejeição.

Resposta d

4) A primeira coisa a ser feita em uma empresa que vai implementar um processo de estimativas confiáveis é:

a) Definir um processo e determinar valores a serem coletados dos projetos. No inicio tentar buscar uma base histórica em outra empresa.

b) Treinar todos os funcionários no uso de ponto funçãoc) Fazer sessões de avaliação para novos projetos, de forma estruturada, para obter

estimativasd) Usar métodos baseado em tamanho, com uma linguagem padronizada para uso na

empresa.e) Estimular os programadores em desenvolverem código, sem método, pois quanto

maior o código melhor para a estimativa.

Resposta letra a

DESAFIO 1;Considere uma empresa que tem uma base histórica que mostra que o tempo de desenvolvimento de um PF é de 38 horas. E o custo hora da empresa é de R$ 45,00

Necessita-se fazer um software que com características funcionais mostrou uma contagem de 335 PF.

Estudando e avaliando os 14 aspectos encontrou-se um valor do fator de ajuste (VFA) de 0,85

Conteúdo Online

Texto

(aula 7 ) ESTIMATIVAS – outros modelos e uso de PF

Este modelo é um modelo dinâmico de múltiplas variáveis que pressupõem a distribuição do esforço ao longo da existência de um projeto de desenvolvimento. Foi construído analisando-se grandes projetos.

O esforço em grandes projetos é caracterizado como mostrado na figura abaixo, reproduzida do professor Pressmam.

Resposta do desafio:

Valor de PF ajustado = 335 * 0,85 = 274,85 Prazo para o projeto: 274,85 * 38horas = 10 820,50 horas Vou arredondar para 10 821 horas Valor do projeto: 10 821 hora * R$ 45,00/hora = R$ 486.945,00

DESAFIO 2;

Considere uma empresa que tem uma base histórica que mostra que o tempo de desenvolvimento de um PF é de 22 horas. E o custo hora da empresa é de R$ 55,20. O APF indicou 210 PF, e 0,92 como fator de ajuste.Determine o prazo (em horas) e custo para desenvolver este software.

Esta figura mostra curvas clássicas que foram apresentadas por Lorde Rayleigh e forma compilados por Norden, por este motivo a curva é chamada de curva Rayleigh-Nortem. Esta curva pode é usada para derivar a equação do software que relaciona linhas de código fonte ao tempo e esforço do desenvolvimento:

Onde Ck é uma constante do estado da tecnologia e reflete restrições que impedem o progresso do programador. Tipicamente pode ser:

CK =2000 em ambiente para desenvolvimento de software (sem metodologia, documentação revisões precárias. Execução batch)

Ck =8000 desenvolvimento de software bom (boa metodologia, documentação, execução interativa

Ck=11000 ambiente ótimo com uso de ferramenta case.

A constante CK pode ser determinada para as condições de uma empresa compilando-se dados históricos de desenvolvimentos passados. Trabalhando-se a equação pode-se chegar à expressão para o desenvolvimento K, onde K é o esforço despendido em pessoas-ano ao longo do ciclo de vida para o desenvolvimento em anos.

Td é o tempo de desenvolvimento em anos. A equação para o esforço de desenvolvimento pode ser relacionada com o custo de desenvolvimento incluindo-se o fator de mão de obra (R$/ano)

L é o numero de linhas.

Estimativas de projetos orientado a objetos (Pressman)O software orientado a objetos deve ter outra abordagem:

1- Desenvolver estimativas usando decomposição de esforço e análise FP que seja aplicável a aplicações convencionais.

2- Desenvolver o diagrama de casos usos com o seu respectivo dicionário e determine a contagem do número de funcionalidades identificadas. Reconhecer que o número de casos e uso podem modificar à medida que se desenvolve o projeto.

3- A partir do modelo de análise determinar o número de classes-chave.4- Categorizar o tipo de interface para aplicação para as classes de apoio.

Multiplicar o número de classes chaves pelo multiplicador para obter uma estimativa para o número de classes de apoio.

Tabela

Tipo de interface MultiplicadorNão IGI 2,0Interface com o usuário baseado em texto 2,25IGI 2,5IGU complexa 3,0

5 – Multiplicar o número total de classes (chave e apoio) pelo número médio de unidades de trabalho por classes. Autores como Lorenz sugerem entre 15 a 29 pessoas dia por classe

6 – Fazer a verificação cruzada em estimativas baseadas em classes multiplicando o número médio de unidades por caso e uso

Estimativas com métodos ágeis

Um projeto usando um processo de desenvolvimento ágil e feito como um conjunto de cenários de usuários. É possível desenvolver uma estimativa com razoável significado com os seguintes passos:

1. Cada cenário de usuário é considerado separadamente para a estimativa.

2. O cenário é composto de um conjunto de funções e tarefas de engenharia. de software.

3 a. Cada tarefa é estimada separadamente.

3 b. O tamanho do cenário pode ser estimado em LOC, PF ou alguma outra medida orientada a volume

4.a As estimativas de cada tarefa são somadas para criar uma estimativa de cenário

4.b O volume de esforço é estimado para o cenário criado e depois é quantificado para o esforço necessário, a partir de dados históricos referentes a outros projetos

5. As estimativas de esforço para todos os cenários que devem implementar um incremento de software são somadas para definir a estimativa para o incremento.

Normalmente a duração do desenvolvimento de um incremento é da ordem de 3-6 semanas, a estimativa serve para garantir que o número de cenários a ser incluído no incremento esta de acordo com os recursos disponíveis.

Estimativa usando Caso e USO

PCU – Pontos por Caso de Uso – Foram criados por Gustav Karner em 1993 como uma adaptação específica dos Pontos de Função para medir o tamanho de projetos de software orientados a objeto. Explora o modelo e descrição do caso de uso, substituindo algumas características técnicas proposta pelos Pontos de Função. É um método simples e de fácil utilização, entretanto, mas ainda esta em fase de pesquisas e não existem regras de contagem padronizadas. Têm se estudado a aplicação em conjunto da PCU e APF tentando explorar a relação entre elas existente(EDMÉIA,2004)

Estimativas usando ponto função

A estimativa de tamanho de um projeto de software é uma atividade crítica pois tem um impacto tanto na solução técnica apresentada como no gerenciamento do projeto de software devendo ser efetuada não somente no início do projeto mas durante o ciclo de vida do projeto.

Uma pesquisa realizada pela Secretaria de Política de Informática – SEPIN, em 2001, indicou que a utilização da APF vem crescendo no Brasil, conforme mostra a tabela 2.1:

Tabela 2.1: Métricas primitivas utilizadas para medir a qualidade dos processos de software.

Categorias Nº de organizações Percentual (%)Linhas de código ( LOC ) 25 5,6

Pontos por função ( Function Point ) 43 9,6Outras métricas 26 5,8

Não utiliza 363 81,4Base 446 100

Fonte: SEPIN , 2005

Considerando que a APF é uma das técnicas funcionais mais antigas, que possui um dos grupos de usuários mais bem estruturados e atuantes e que a partir de 2002 passou a condição de padrão internacional através da norma ISO/IEC 20926. A técnica pode ser considerada como uma das melhores alternativas de medição de tamanho do projeto de software.

APF serve como um instrumento para acompanhar estimativas de custo e recursos requeridos para o desenvolvimento e manutenção de software.

Exemplo de estimativas com APF:

Sistema de Manutenção de Clientes

Descrição do sistema:

- Em um sistema de manutenção de clientes um usuário (funcionário de empresa) registra as entradas, alterações, exclusões e saídas (relatório) dos dados relativos a um cliente da empresa no sistema. Qualquer usuário da empresa poderá acessar o sistema e efetuar o cadastramento. (Não haverá controle de acesso no sistema). Será emitido um relatório de todos os clientes cadastrados e dos dados de um determinado cliente.

Características do sistema:

- O sistema irá permitir o acesso sem restrições para qualquer usuário da empresa, não havendo portanto, controle de acesso.

- Não existe qualquer interface com outros sistemas existentes

- Deverão ser cadastrados os seguintes dados de um cliente: Nome, endereço, Cidade , Cep , Telefone , Email e Observações.

- O nome do cliente, endereço, cidade,  cep e email são obrigatórios e deverão ser sempre informados

Lista de ator(es):

Usuário (funcionário da empresa)

Casos de uso identificados

1. Exibir Clientes Cadastrados 2. Efetuar Manutenção de clientes

Diagrama de caso de uso simplificado:

Para determinar um custo “Justo” para o software devem-se realizar estimativas de tamanho, custo, esforço e qualidade de software.

Normalmente as estimativas são feitas com base em um histórico de informações durante o ciclo de desenvolvimento do projeto e que servem de base para a tomada de decisão.

Usando–se Análise de Pontos de Função, que tem sido cada vez mais utilizada para estimativas de tamanho, esforço e prazo, de um sistema de software com base na funcionalidade fornecida ao usuário. Vamos estimar o preço e prazo para desenvolver o sistema de manutenção de clientes.

Suponha que precisamos dar um orçamento para desenvolver o sistema.

Para isto vamos usar APF para:

1. estimativa do tamanho funcional da aplicação2. estimativa do custo e esforço para desenvolvimento

1. Determinar o tamanho funcional do sistema de manutenção

Entidades e funções do processo de manutenção de clientes

1- Usuário (funcionário)

2- Gestão do cadastro de clientes

3- Cadastros

4- Clientes

A tecnologia usada no sistema para manutenção de cliente será de implementação em um site (processamento nas nuvens) usando a linguagem PHP (com suporte a objetos) envolvendo 3 camadas : camada de dados , camada de aplicação e camada de apresentação.

Para estimar o tamanho será feita uma contagem estimativa segundo o modelo que estudamos nas aulas anteriores - IFPUG.

Vamos usar o processo de contagem conforme preconiza o manual do IFPUG para determinar o número de pontos por função de um projeto de software.

Vamos usar as etapas do processo de contagem da APF conforme a figura abaixo:

A figura etapas da contagem da APF.(gráfico retirado de

http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/APF.pdf )

Determinar Funções do tipo dado – etapa 3 da figura

O sistema usa o banco de dados Cadastro.mdb e a tabela Clientes que possui a seguinte estrutura:

Para determinar se a tabela Clientes é um ALI devemos fazer duas perguntas:

É um grupo lógico de dados identificável pelo usuário ? Sim.

É mantido por um processo elementar dentro da fronteira da aplicação ? Sim.

A aplicação possui somente um ALI.

Após identificar os ALI e AIE devemos classificar a função de acordo com sua complexidade funcional. Para alcançar este objetivo devemos determinar:

1. Número de Tipos de Dados (TD) - é um campo único, reconhecido pelo usuário, não repetido.

2. Número de Tipos de Registros (TR) - é um subgrupo de tipo de dados, reconhecido pelo usuário, componente de um ALI ou AIE.

Após determinar as quantidades de tipos de dados e tipos de registros, devemos classificar a complexidade de acordo com a seguinte tabela:

  Tipos de DadosTipos de Registros

 < 20

 20 - 50

 > 50

  1 Baixa

 Baixa

 Média

  2 - 5

 Baixa

 Média

 Alta

  > 5

 Média

 Alta

 Alta

Após determinar a complexidade dos arquivos , devemos calcular sua contribuição conforme a seguinte tabela:

Tipo de Função Baixa Média Alta

Arquivo Lógico Interno - ALI   7 PF   10

PF   15 PF

Arquivo de Interface Externa - AIE

  5 PF    7 PF    10 PF

Determinação dos ALI

ALI - Arquivo Lógico Interno - é um grupo de dados logicamente relacionados ou de informações de controle identificáveis pelo usuário e mantido dentro das fronteiras da aplicação.

No projeto,o cliente visualiza portanto o conjunto de informação como um registro lógico. A aplicação apresenta então somente 1 Registro Lógico.

Como todos os campos da tabela serão usados pelo usuário, com exceção do CodigoCliente que será atribuição do sistema, a aplicação apresenta 7 tipos de dados (basta contar em clientes:tabela).

Chegamos à conclusão pela tabela ( 1 <--> 7 )  que nossa aplicação possui a definição de complexidade Baixa.

Pela tabela a contribuição será de 7 PF.

O total de pontos por função para as funções do tipo dado para a aplicação é igual a  7 PFDeterminação dos AIE

AIE - Arquivo de interface externa - é um grupo de dados logicamente relacionados que é usado pela aplicação entrtanto sofre manutenção a partir de outra aplicação.

A aplicação não tem nenhum AIE.  Com contribuição de 0 PF.

4- Determinar as funções do tipo Transação

As funções do tipo transação representam a funcionalidade fornecida ao usuário para atender os requisitos da aplicação. São classificadas como:

1. Entradas Externas - EE - Processa as informações e/ou dados recebidos de fora da fronteira da aplicação

2. Saídas Externas - SE - Envia dados ou informações para fora da fronteira da aplicação 3. Consultas Externas - CE - Envia dados ou informações de controle para fora da fronteira

da aplicação.

Cada função do tipo transação deve ser classificada com relação a sua complexidade funcional em:

1. Número de Arquivos Referenciados - AR - Um ALI lido ou mantido pela função do tipo transação ou um AIE lido pela função do tipo transação.

2. Número de Tipos de Dado - TD -  Um campo único, reconhecido pelo usuário, não repetido.

Após determinar a quantidade de AR e TD da aplicação podemos definir a sua complexidade de acordo com as seguintes tabelas:

Tabela de complexidade para Entradas Externas:

  Tipos de Dados

Arquivos Referenciados

 < 5  5 - 15  > 15

 < 2  Baixa  Baixa  Média   2  Baixa  Média  Alta > 2  Média  Alta  Alta

Tabela de complexidade para Saídas Externas e Consultas Externas:

  Tipos de Dados

Arquivos Referenciados

 < 6  6 - 19  > 19

 < 2  Baixa  Baixa  Média 2 - 3  Baixa  Média  Alta > 3  Média  Alta  Alta

Determinando a quantidade de AR e TD da aplicação

Vamos criar uma tabela para indicar as funções do tipo transação identificada e  para cada uma delas a quantidade de AR e TD.

Função Tipo  AR  TD

Cadastro de Clientes

     

 - Incluir EE      1     7

 - Alterar EE      1     7

 - Excluir EE      1     7

 - Listar SE      1

    10 (*)

 - Consultar CE     

1     8

(*) - além dos campos de dados estamos estimando ou contando os comandos ( botão e mensagem ao usuário)

Após determinar a complexidade das funções de transação podemos calcular sua contribuição de acordo com a tabela abaixo:

Tipo de Função  Baixa  Média  Alta

Entrada Externa - EE

 3 PF  4 PF  6 PF

Saída Externa - SE

 4 PF  5 PF  7 PF

Consulta Externa - CE

 3 PF  4 PF  6 PF

Determinando a contribuição em PF para as funções de transação da aplicação

Abaixo temos a tabela que exibe as funções do tipo Transação para a aplicação manutenção de clientes.

Função

Tipo

 Complexidade

 PF

Cadastro de Clientes

     

 - Incluir

EE  Baixa  

3

 - Alterar

EE  Baixa  

3

 - Excluir

EE  Baixa  

3

 - Listar

SE  Baixa  

4

 - Consultar

CE  Baixa  

3

Total dos Pontos de função para as funções de tipo transação da aplicação:  16 PF

O total geral dos pontos de função não ajustados para a aplicação é de 23 PF ( 16 + 7 )Cálculo do fator de ajuste

O valor do fator de ajuste (VFA) é baseado em 14 características gerais de sistema listadas abaixo:

1. COMUNICAÇÃO DE DADOS: Quando são utilizados recursos de Comunicação de Dados para o envio ou recebimento de dados e informações de controles utilizados pela aplicação;

2. PROCESSAMENTO DISTRIBUÍDO: Quando a aplicação prevê a distribuição de dados ou de processamento entre várias CPUs da instalação;

3. PERFORMANCE: Esta característica identifica os objetivos de performance da aplicação, estabelecidos e aprovados pelo usuário, que influenciaram (ou irão influenciar) o desenho, desenvolvimento, implantação e suporte da aplicação;

4. UTILIZAÇÃO DO EQUIPAMENTO: Representa a necessidade de se fazer considerações especiais no desenho dos sistemas para que a configuração do equipamento não sofra degradação;

5. VOLUME DE TRANSAÇÕES: Avalia o impacto no desenho da aplicação do volume de transações previsto para ela;

6. ENTRADA DE DADOS "ON-LINE": Avalia o volume de transações que são entradas de dados interativas;

7. EFICIÊNCIA DO USUÁRIO FINAL: Analisa as funções "on-line" desenhadas e disponibilizadas voltadas para a eficiência do usuário final;

8. ATUALIZAÇÃO "ON-LINE": Verifica o volume de arquivos lógicos internos que sofrem manutenção "on-line" e o impacto do processo de recuperação de seus dados;

9. PROCESSAMENTO COMPLEXO: Considera o impacto, sobre o desenho da aplicação, causado pelo tipo de complexidade do processamento;

10.REUTILIZAÇÃO DE CÓDIGO: Avalia se a aplicação e seu código foram especificamente projetados e desenvolvidos para serem reutilizados em outras aplicações;

11.FACILIDADES DE IMPLANTAÇÃO: Considera o esforço gasto para o atendimento dos requerimentos de conversão de dados para a implantação da aplicação;

12.FACILIDADE OPERACIONAL: Avalia o desenho da aplicação quanto aos requisitos estabelecidos para inicialização, "backup" e recuperação voltados à minimização da intervenção manual do operador;

13.MÚLTIPLOS LOCAIS: Quando a aplicação for especificamente projetada e desenvolvida para ser instalada em múltiplos locais ou para múltiplas organizações;

14.FACILIDADES DE MUDANÇAS: Quando os requisitos da aplicação prevêem o projeto e desenvolvimento de mecanismos que facilitem mudanças operacionais, tais como: capacidade de emissão de relatórios genéricos, de consultas flexíveis ou de alterações nos dados de controle do negócio (parametrização).

Cada uma destas características possui um nível de influência sobre a aplicação que pode variar em um intervalo de zero a cinco (0 a 5):

0 - Nenhum Influência1 - Influência Mínima2 - Influência Moderada3 - Influência Média4 - Influência Significativa5 - Grande Influência

Após determinar os níveis de influência das 14 características gerais o fator de ajuste é calculado com a seguinte fórmula:

VFA =  (Σ NI  x 0,01) + 0,65Onde:Σ  - é o somatório dos níveis de influência para as 14 característicasNI - NI é nível de influência  

Uma equipe de profissionais respondeu e deu nota para os 14 características:

As notas dadas para os itens foram:

Característica

Influência

Característica

Influência

1 4 8 02 0 9 23 0 10 04 3 11 45 0 12 36 0 13 07 0 14 4                                       Valor Total =>

20

Chegamos portanto a um nível de influência igual a 20.

Calculando o fator de ajuste pela fórmula   VFA =  ( ΣNI  x 0,01) + 0,65  temos:

VFA = (20 x 00,1 ) + 0,65 = 0,85  O valor do fator de ajuste é igual a 0,85.Portanto o número de pontos de função para o projeto é obtido da seguinte forma:

NPF = PFNA * VFA   onde temos    NPF = 27 * 0,85  = 22,95

Onde : NPF - número de pontos de função  

Finalmente conseguimos obter uma medida para o tamanho da nossa aplicação. O seu tamanho é igual a 22,95 PF.Neste ponto para se fazer a estimativa temos de ter informações de projetos anteriores para basearmos nossa estimativa, por experiências passadas podemos trabalhar por analogia. Já foi considerado os aspectos de complexidade e de característica do software quando colocamos o valor de ajuste..

Quanto mais informações você puder obter melhor será a sua estimativa , ou seja, menos erro ela terá. O prazo correto, como em qualquer projeto, só será obtido com 100% de acerto só será obtido no fim do projeto

O ambiente de desenvolvimento , a experiência da equipe no projeto , os métodos usados no processo de software , etc. todos estes fatores influenciam na medida de estimativa a ser obtida.

Como estamos usando as regras do manual de contagem, que também são usadas por outras empresas . Isto nos facilita, pois se não tivermos uma base histórica podemos buscar informações em outras empresas a fim de subsidiar sua estimativa.

O esforço em horas pode-se obter pela formula

Esforço Total (horas ) =  PF * índice de produtividade e os índices de produtividade podem ser expressos em Horas/PF ou PF/mês .

Para a aplicação em questão que possui 22,95 PF , se o índice de produtividade da empresa ou equipe for de 10 horas/PF o esforço demando seria algo em torno de 229,5 horas.

Assim o projeto demandará 229 horas para ser desenvolvido.

Com base na informação de 229 horas e sabendo-se o custo da equipe por hora podemos definir o preço

Com base nisto , sabendo o valor pago pela empresa o custo seria de fácil obtenção.

Na próxima aula vamos abordar o uso de dados estatísticos e estabelecimentos de padrões de gestão e estimativa usando PF.

Conclusão: O uso de PF é mais uniforme, e nos leva a resultados mais consistentes. Assim uma boa base de informações em relação ao PF nos leva a resultados mais consistentes. Trabalhar com LOC é muito impreciso, pois depende da linguagem que pode não estar escolhida. Também o fato que esta medida não favorece a boa estruturação de um projeto. Um projeto bem estruturado com 50.000 linhas é prejudicado ao se analisar outro projeto com 60.000 linhas feitas sem método e estruturação.