GQS 607 Métricas de Softwareheraldo/gqs607_slides.pdf · GQS 607 – Métricas de Software Prof....

GQS 607 – Métricas de Software Prof. Heraldo L. S. Almeida

- 1 -

GQS 607 – Métricas de Software


- 2 -

1 – Introdução às Métricas de Software

2 – Medição Funcional por Análise de Pontos de Função

3 – Estudos de Caso (dados em sala de aula)

4 – Tópicos Complementares em APF

Conteúdo Programático


- 3 -

1.1. Medidas, Métricas e Indicadores

1.2. Por que medir ?

1.3. Practical Software Measurement (PSM)

1.4. Métricas para Processos, Projetos e Produtos

1.5. Medição de Tamanho Funcional

1. Introdução às Métricas de Software


- 4 -

2.1. Conceitos e Definições

2.2. Visão Geral do Processo

2.3. Reunindo a Documentação Disponível

2.4. Determinando o Escopo e a Fronteira da Contagem

2.5. Identificando os Requisitos Funcionais de Usuário

2.6. Medindo Funções de Dados

2.7. Medindo Funções de Transação

2.8. Calculando o Tamanho Funcional

2.9. Documentando e Relatando

2. Medição de Tamanho Funcional por Análise de Pontos de Função


- 5 -

Os estudo de caso são dados em sala de aula e

trabalhados com os alunos reunidos em grupos.

3. Estudos de Caso


- 6 -

4.1. Implantação Prática do Processo de Métricas

(palestra de convidado externo)

4.2. Medição Funcional Antecipada

4.3. Medição Funcional Ajustada

4. Tópicos Complementares em APF


- 7 -

Análise de Pontos de Função:

Medição, Estimativas e

Gerenciamento de Projetos

de Software

Carlos Eduardo Vazquez,

Guilherme Siqueira Simões e

Renato Machado Albert

9ª edição revisada

Editora Érica

Fontes de Informação


- 8 -

Function Point Counting

Practices Manual

The International

Function Point Users Group

Release 4.3.1

www.ifpug.org

Fontes de Informação

http://www.ifpug.org/


- 9 -

Módulo 01

Introdução às Métricas de Software


- 10 -








- 11 -








- 12 -

Medida, Medição e Métrica (no contexto de Engenharia de Software)


Definição Exemplo

Medida Valor quantitativo da extensão,

quantidade, dimensões, capacidade

ou tamanho de algum atributo do

processo ou produto de software

Número de linhas de código de

um módulo de software.

Quantidade de erros detectados

no teste desse módulo.

Medição Ato de determinar uma medida Registrar os erros encontrados

durante o teste.

Métrica Medida quantitativa do grau em que

um sistema, componente ou processo

possui um determinado atributo

(relaciona medidas individuais).

Quantidade média de erros

por linha de código.

mede quantitativamente o grau de

qualidade do módulo de software


- 13 -

Indicador

Métrica, ou combinação de métricas, que proporcionam uma

compreensão e uma visão aprofundada

do processo

do projeto

ou do produto de software

Indicadores ajudam a ajustar adequadamente produtos, projetos

e processos, visando melhorar sua qualidade ou desempenho.



- 14 -

Exemplo de Utilização de Indicadores

A métrica “quantidade média de erros por linha de código” do slide anterior

pode ser calculada para diferentes situações

(diferentes equipes, ferramentas, metodologias, etc.).

Isto proporcionará uma compreensão dos efeitos de cada alternativa de ajuste

do processo sobre a qualidade do produto que chega na etapa de teste.

Alguém pode descobrir, por exemplo, que a inclusão de revisões técnicas

formais no processo de desenvolvimento ocasiona uma redução de 40% na

taxa de erros encontrados nos testes.

Nesse caso, alguns exemplos de indicadores que poderiam ser úteis para

avaliar a efetividade da inclusão das revisões técnicas no processo seriam:

a taxa de redução percentual de erros na etapa de teste

a economia média líquida de HH por quantidade de código desenvolvido ( HH economizada nos testes menos HH consumida na revisão )

o retorno do investimento



- 15 -

Definição Exemplo

Medida Valor quantitativo da extensão,

quantidade, dimensões, capacidade

ou tamanho de algum atributo do

processo ou produto de software

Número de linhas de código de

um módulo de software.

Quantidade de erros detectados

no teste desse módulo.

Medição Ato de determinar uma medida Registrar os erros encontrados

durante o teste.

Métrica Medida quantitativa do grau em que

um sistema, componente ou processo

possui um determinado atributo

(relaciona medidas individuais).

Quantidade média de erros

por linha de código.

mede quantitativamente o grau de

qualidade do módulo de software

Indicador Métrica, ou combinação de métricas,

que fornece uma visão aprofundada

de um processo, projeto ou produto.

Taxa de redução de erros após a

implantação de revisões

técnicas formais no processo de

desenvolvimento de software.



- 16 -

Indicadores

Portanto, indicadores são instrumentos valiosos para orientar ações

no sentido de melhorar um produto, um projeto ou um processo.

Processo de Medição

Um engenheiro de software coleta medidas e calcula métricas e,

em seguida, avalia essas métricas, visando obter indicadores

que atendam o objetivo de melhorar a qualidade/desempenho do

produto, projeto ou processo.



- 17 -

processo

projeto

produto

Coleta de dados

Cálculo de métricas

Avaliação de métricas

medidas

métricas

indicadores

As Atividades de Medição

Estas atividades devem ser incluídas no Plano de Projeto !



- 18 -

“ If you can not measure it,

you can not improve it ! ”

“ When you cannot express it in numbers,

your knowledge is of a meagre and

unsatisfactory kind.”

Lord Kelvin



Como definir métricas: o método GQM

A idéia básica de GQM é derivar métricas de software a partir de

perguntas e objetivos.

Goal

Quais são as metas/objetivos?

Question

Quais questões se deseja responder?

Metric

Quais métricas poderão ajudar?

- 19 -




Etapas do Processo

1. Listar os principais objetivos do processo de medição;

2. Derivar de cada objetivo as perguntas que devem ser respondidas

para determinar se os objetivos foram atingidos;

3. Decidir o que precisa ser medido para ser capaz de responder as

perguntas adequadamente (definição das métricas).

- 20 -




- 21 -




- 22 -


Decidir quando o software estará pronto para a implantação

Qual é o requisito de estabilidade?

Qual é a atual confiabilidade?

Quais são as métricas temporais?

Tamanho decódigo

Defeitosdescobertos

Casos detestes

Horas deutilização

Horasde teste

Pessoas disponíveis pordia para testes

Decidir quando o software estará pronto para a implantação

Qual é o requisito de estabilidade?

Qual é a atual confiabilidade?

Quais são as métricas temporais?

Tamanho decódigo

Defeitosdescobertos

Casos detestes

Horas deutilização

Horasde teste

Pessoas disponíveis pordia para testes


- 23 -








- 24 -

Razões para medir

Caracterizar

Avaliar

Prever

Aperfeiçoar



- 25 -

Razões para medir

Caracterizar

para ter entendimento dos processos, produtos e recursos.

para estabelecer marcos referenciais, visando comparação futura.

para prever ou aperfeiçoar.

Avaliar

Prever

Aperfeiçoar



- 26 -

Razões para medir

Caracterizar

Avaliar

para determinar o status em relação ao planejado.

para saber o quanto os projetos e processos estão fora de controle.

para verificar o modo de trazer os projetos de volta ao controle.

para verificar o cumprimento de metas de qualidade.

para verificar o impacto de novas tecnologias e/ou processos.

Prever

Aperfeiçoar



- 27 -

Razões para medir

Caracterizar

Avaliar

Prever

para poder planejar o futuro.

para poder extrapolar tendências, analisar riscos e assumir

compromissos.

para poder estabelecer metas viáveis de custo, cronograma e

qualidade.

envolve entender o processo/produto e construir modelos onde as

estimativas de custos, prazos e qualidade possam ser atualizadas.

Aperfeiçoar



- 28 -

Razões para medir

Caracterizar

Avaliar

Prever

Aperfeiçoar

melhorar a qualidade do produto, ou o desempenho do processo.

identificar bloqueios, causas fundamentais, ineficiências e outras

oportunidades de melhorar a qualidade/desempenho do

produto/processo.



- 29 -

Riscos da Ausência de Métricas: A Curva do Pânico !


Tempo

Pro

du

çã

o

Total a Entregar

Prazo

Zona

do

Pânico


- 30 -

O castigo por

não usar métricas:

A Dinâmica

do Pânico !



- 31 -

Os Sucessivos Adiamentos da Entrega do Projeto !



- 32 -

Com o uso de métricas o pânico pode ser evitado !

O problema é detectado

logo no início do projeto,

possibilitando ações

gerenciais corretivas.


Tempo

Pro

du

çã

o

Total a Entregar

Prazo

Zona

do

Pânico

Indicador de

Produtividade

ALERTA:

Produtividade

muito baixa !


- 33 -

Com o uso de métricas o pânico pode ser evitado !


Ação

Gerencial

Ação

Gerencial

Base de

Projetos

Prazos

Previstos

Tempo (meses)

Produção Prevista

Progresso

Pro

du

çã

o Q

ua

ntif

ica

da

#1#2

#3

#4

#5

Indicadores


- 34 -

Métricas e o Gerenciamento de Escopo



- 35 -

O Problema do Scope Creep (rastejamento do escopo)


[1.200 PF]Especificação Inicial

de Requisitos

[1.500 PF]Projeto deAlto Nível

[1.700 PF]Projeto

Detalhado

Estimativa Dimensionamento

[1.900 PF]ProdutoEntregue

Horas, Reais, Pontos de Função, etc.

Estimativa Incial...: 1.200 PFProduto Entregue.: 1.900 PFCrescimento.........: 53%

( 1.900 – 1.200 ) * 1001.200

Projeto A Equipe 1


- 36 -

O Problema do Scope Creep (rastejamento do escopo)


[1.200 PF]Especificação Inicial

de Requisitos

[1.500 PF]Projeto deAlto Nível

[1.700 PF]Projeto

Detalhado

Estimativa Dimensionamento

[1.900 PF]ProdutoEntregue

Horas, Reais, Pontos de Função, etc.

Estimativa Incial...: 1.200 PFProduto Entregue.: 1.900 PFCrescimento.........: 53%

( 1.900 – 1.200 ) * 1001.200

Projeto A Equipe 1

Prezado cliente, sinto informar que, em virtude do crescimento de 53% no

escopo do projeto devido às funcionalidades adicionais solicitadas por V. Sa.,

estamos enviando a fatura correspondente a essa diferença.


- 37 -

O Problema do Scope Creep

Mas quem disse que o escopo mudou ???



- 38 -

O Problema do Scope Creep

Para argumentar com o cliente baseado em métricas, é

necessário estabelecer em comum acordo com o cliente as

métricas e os processos de medição a serem usados no projeto.

Para o devido gerenciamento de escopo, é importante que

cliente e fornecedor utilizem uma métrica comum para medição

dos produtos entregues.



- 39 -








- 40 -


PSM Detailed Integrated Analysis Model

Modelo utilizado pelo Departamento

de Defesa dos EUA.

Ilustra a interação entre diferentes

fatores em um projeto de

desenvolvimento, identificando

pontos onde a medição pode ser

relevante.


- 41 -


1

Functional size represents the amount of

functionality the project is expected to

provide.

This is usually determined by requirements,

change requests or function points.

Functional size is a primary determinant of

physical size (the amount of product that

must be developed or maintained).


- 42 -


2

Most innovative technical approaches

attempt to minimize the quantity of new

product that must be implemented for a

given function.

Examples of technical approaches include

using purchased software, common

architectures and reusable components.

If the effectiveness of the approach does not

yield all of the desired benefit, more of the

system must be developed than planned.

For example, if a purchased system does

not satisfy all of the required functionality as

originally intended, custom code may have

to be developed.

The volatility of any new technology also

influences product size.


- 43 -


3

Increases in product size, and overall size

instability, usually result in the need for

additional personnel.


- 44 -


4

Process performance (the maturity or

capability of a developer’s process)

contributes to the need for personnel

resources and influences development

schedules and product quality.

A development team with a more mature

and capable process performs better than a

team with an ad-hoc or ill-defined one,

assuming other factors are constant.


- 45 -


5

Adding more personnel impacts schedule

and progress.

If personnel are added early inthe project

and if the appropriate training and

communications are in place, the schedule

may be shortened.

If personnel are added later, the schedule

may actually be lengthened because of the

disruptions caused by adding new

personnel not familiar with the project

environment, processes and/or domain.

Schedule shortfalls are associated with

milestone slips and delays in completing

planned life-cycle activities and products,

and often necessitate reductions in build

and release requirements.


- 46 -


6

Schedule shortfalls can cause product

quality problems, including defects in the

product, maintainability issues, and

performance issues.

This happens when test efforts are curtailed

in order to meet tight schedules.

Problems left open and not corrected during

reviews and testing are also a cause of

quality problems.


- 47 -


7

Latent quality problems represent the

rework that requires additional resources to

make current or future releases acceptable

to the user.

The project manager will usually make a

delivery decision based on the number of

open problems, fixing some high-priority

problems and deferring others to the

operations and maintenance phase.


- 48 -


8

Quality problems also worsen product

stability and impact cost.

Managers may be forced to modify or

eliminate some mission requirements to stay

within cost and schedule constraints.


- 49 -


9

For software projects, personnel effort,

including rework, is the primary determinant

of project cost.

Cost control can be achieved only by

controlling other upstream factors.


- 50 -


10

Problems with resource and schedule

overruns, as well as problems with product

quality, all impact customer satisfaction.


- 51 -

Benefícios do Uso de Métricas de Software

(Moller & Paulisch, 1993)

maior entendimento dos efeitos de diferentes ações implementadas na

tentativa de melhorar o processo de desenvolvimento

avaliação mais objetiva dos benefícios gerados por mudanças de

técnicas, métodologias ou ferramentas de desenvolvimento

maior capacidade de controlar e de aprimorar o processo

estimativas mais precisas para custos e cronogramas

estimativas mais precisas do efeito de mudanças no custo e no

cronograma

maior produtividade e eficiência

menor custo de desenvolvimento

menor tempo de ciclo de projeto

maior satisfação e confiança do cliente (produto de maior qualidade)



- 52 -








- 53 -

Medições podem ser aplicadas

ao processo de desenvolvimento de software

a projetos de desenvolvimento de software

a produtos de software

1.4. Métricas de Processo, Projeto e Produto


- 54 -

Métricas de Processo

São usadas com finalidade estratégica, ou seja, visam benefícios para

projetos futuros, e não para o projeto que está sendo medido.

Têm como objetivo melhorar o processo de forma contínua.

Medem características do processo de desenvolvimento como um todo.

Exemplo:

número de defeitos encontrados ao longo do processo,

para diferentes metodologias de teste e de revisão.



- 55 -

Métricas de Projeto

São usadas com finalidade tática, ou seja, para adaptar o fluxo de

trabalho e atividades técnicas de forma imediata, em benefício do

próprio projeto que está sendo medido.

Têm essencialmente dois objetivos:

minimizar o cronograma

monitorar a qualidade do produto

Seu primeiro emprego ocorre nas estimativas preliminares.

À medida em que o projeto evolui, os resultados são confrontados

para monitorar e controlar o progresso.

Exemplos:

taxa de produção

horas de revisão

tamanho (físico ou funcional) dos artefatos produzidos.



- 56 -

Métricas de Produto

São aplicadas ao produto final ou intermediário de uma atividade de

desenvolvimento de software.

Podem ter vários objetivos:

normalizar medidas de qualidade e produtividade

controlar escopo de projeto (monitorar tamanho dos produtos entregues)

estimar custos e prazos de desenvolvimento

estimar custos de suporte e manutenção

auxiliar a gestão de contratos de desenvolvimento ou manutenção

dar subsídios a análises do tipo “make-or-buy”

Podem ser de dois tipos:

orientadas a tamanho

orientadas a funcão



- 57 -

Métricas Orientadas a Tamanho

São medidas de qualidade e produtividade que levam em

consideração o tamanho físico do software que foi produzido.

O tamanho geralmente é medido em

linhas de código (LOC)

quantidade de operações



- 58 -

Métricas Orientadas a Tamanho

Exemplos: Erros por KLOC

Defeitos por KLOC

Custo por KLOC

LOC por Pessoa-Mês, etc.

Não são universalmente aceitas como melhor modo de medir

Argumentos favoráveis:

Facilmente contado

Existem muitos modelos baseados em LOC

Existe muita literatura e dados baseados emLOC

Argumentos contrários:

São dependentes da linguagem de programação

Penalizam programas curtos e eficientes

Estimativas iniciais são difíceis de serem alcançadas



- 59 -

Métricas Orientadas a Função (Métricas Funcionais)

Fornecem uma medida da funcionalidade fornecida pela aplicação como valor

de normalização.

A “funcionalidade” é medida indiretamente, a partir de outras medidas diretas.

O valor resultante é denominado tamanho funcional do sistema.

Objetivos

Medir funcionalidade solicitada, reconhecível e recebida pelo usuário.

Medir de forma independente da tecnologia utilizada,

dentro de uma ótica de negócio e não-técnica

Características desejáveis

Deve ser simples para viabilizar o esforço de medição.

Deve ser consistente entre diferentes projetos e organizações e tecnologias.



- 60 -








- 61 -

Métricas Funcionais

As principais métricas funcionais utilizadas no mercado são:

Pontos de Função

disponível em 4 variantes aderentes ao padrão ISO/IEC 14143,

que normatiza os métodos de medição de tamanho funcional:

IFPUG (ISO/IEC 20926)

COSMIC-FFP (ISO/IEC 19761)

NESMA (ISO/IEC 24570)

MARK II (ISO/IEC 20968)

Pontos de Caso de Uso (não aderente ao padrão ISO)



- 62 -

Quadro Comparativo Pontos de Função x Pontos de Caso de Uso

Pontos de Função Pontos de Caso de Uso

Mais antiga e mais utilizada no mundo Relativamente nova e pouco utilizada

Padrão internacional desde 2002 Ainda não alcançou o nível de padronização e

nem foi incorporada em ferramentas populares

Não requer o uso de notação padrão Baseada no modelo de casos de uso

Largamente discutida na literatura Tem aumentado o uso e a publicação de

estudos na literatura

É suportada pelo IFPUG e diversos grupos

nacionais de usuários e bases históricas de

medidas realizadas

Ainda não possui bons históricos de

produtividade

Possui regras de contagem padronizadas Há dúvidas de qual o nível apropriado de

detalhe que cada caso de uso deve possuir

Alto nível de maturidade Em fase de amadurecimento

Oferece treinamento e certificação Ainda não oferece treinamentos e certificação



- 63 -

Métodos de Medição Funcional ISO-aderentes

Dentre os métodos aderentes ao padrão ISO/IEC 14143

IFPUG (ISO/IEC 20926)

COSMIC-FFP (ISO/IEC 19761)

NESMA (ISO/IEC 24570)

MARK II (ISO/IEC 20968)

o mais utilizado no Brasil e no mundo e que conta com o

mais extenso repositório de projetos medidos é o método

do IFPUG (International Function Points Users Group).



- 64 -

O Método IFPUG de Medição de Tamanho Funcional

É definido pela norma ISO/IEC 20926:2009 .

É descrito no IFPUG Function Points Counting Practices Manual,

cuja última versão é a 4.3.1, de 17-01-2010.



- 65 -

Benefícios da Análise de Pontos de Função (APF)

Contagem de funções incluídas em um pacote adquirido.

Avaliação do custo de desenvolvimento ou aquisição (make-or-buy).

Análise de produtividade e qualidade.

Gerenciamento de escopo e de requisitos

Estimativa de custo e recursos.

Negociação de contratos.

Normalização para comparação de software.



- 66 -

Algumas empresas que utilizam APF no Brasil


IBM

UNISYS

EDS

ACCENTURE

XEROX

ATOS ORIGIN

TCS

CPMBRAXIS

STEFANINI

POLITEC

DBA

CTIS

POLIEDRO

RESOURCE

BRQ

PETROBRÁS

BANCO CENTRAL

BANCO DO BRASIL

SERPRO

BNDES

CAIXA

OI

BRASILTELECOM

REDECARD

DATASUL

CAST

PROCOMP

MONTREAL

GOLDEN CROSS

VALE

CITIBANK

ATECH

ITAIPU

CORREIOS

BRADESCO

PRODEMGE

PRODAM

PRODESP

ANATEL

ANTT

ANAC

ANVISA

ANCINE


- 67 -

Quem usa APF em CONTRATOS :


BNDES

CEF

SERPRO

PM-SP

DATAPREV

CORREIOS

BRADESCO

ABN/REAL

EXÉRCITO

PETROBRÁS

EMBRATEL

PRODEB

EDS

POLITEC

DBA

CPM

STEFANINI

DATASUS


- 68 -

Módulo 02

Medição de Tamanho Funcional por Análise de Pontos de Função

( IFPUG CPM 4.3 – ISO/IEC 20926:2009 )


- 69 -









2.9. Documentando e Reportando



- 70 -












- 71 -

• Usuário

• Fronteira

• Requisitos Funcionais de Usuário

• Processo Elementar

• Componente Funcional Básico

• Função de Dados

• Arquivo Lógico Interno (ALI)

• Arquivo de Interface Externa (AIE)

• Função de Transação


• Entrada Externa (EE)

• Consulta Externa (CE)

• Saída Externa (SE)

• Modelo Conceitual para APF

• Complexidade Funcional

• Dado Elementar Referenciado (DER)

• Registro Lógico Referenciado (RLR)

• Arquivo Lógico Referenciado (ALR)

• Tamanho Funcional


- 72 -

Usuário

Qualquer pessoa ou coisa que se comunique ou interaja com o

software em qualquer momento.

Exemplos de “coisa” incluem (mas não estão limitados a):

outro software

animais

sensores

qualquer tipo de hardware

[ISO/IEC 14143-1:2007, definition 3.11]



- 73 -

Fronteira

Interface conceitual entre o software que está sendo medido e seus

usuários.


Atua como uma ‘membrana’, através da qual os dados processados

pelas transações passam para dentro e para fora da aplicação que

está sendo medida.

Depende da visão externa do negócio do usuário da aplicação.

É independente de considerações técnicas ou de implementação.



- 74 -

Fronteira



- 75 -

Requisitos Funcionais de Usuário

Subconjunto dos requisitos de usuário que descrevem o que o software

deverá fazer, em termos de tarefas e serviços.

Exemplos:

transferência de dados inserir dados do cliente, enviar sinal de controle, etc.

transformação de dados calcular juros bancários, obter temperatura média, etc.

armazenamento de dados armazenar pedido de cliente, gravar curva de temperatura, etc.

recuperação de dados listar funcionários, exibir posição da aeronave, etc.




- 76 -


Contra-exemplos (não são requisitos funcionais de usuário):

requisitos de qualidade usabilidade, confiabilidade, eficiência e portabilidade, etc.

requisitos organizacionais local de operação, plataforma de hardware, aderência a padrões, etc.

requisitos ambientais interoperabilidade, controle de acesso, privacidade, segurança, etc.

requisitos de implementação linguagem de programação, cronograma de entrega, etc.




- 77 -

Processo Elementar (PE)

Menor unidade de atividade que é significativa para o usuário.




- 78 -






- 79 -




significativa para o usuário

reconhecível pelo usuário e que satisfaz um

requisito funcional de usuário.




- 80 -










- 81 -








reconhecível pelo usuário

requisitos para processos e/ou dados entendidos e estabelecidos

em comum acordo pelo usuário e pelo desenvolvedor do software.




- 82 -

Componente Funcional Básico

Unidade elementar dos requisitos funcionais de usuário definidos e

utilizados por um método de medição de tamanho funcional para

propósitos de medição.

Exemplos:

o requisito funcional de usuário “manter cadastro de clientes” pode ser

constituído dos seguintes componentes funcionais básicos:

adicionar um novo cliente

relatar compras de cliente

atualizar informações de cliente

informações de cliente




Componente Funcional Básico

No método de medição do IFPUG (CPM 4.3), os componentes

funcionais básicos podem ser:

funções de dados

funções de transação

No exemplo anterior:

adicionar um novo cliente

relatar compras de cliente

atualizar informações de cliente

informações de cliente

- 83 -



função de dados


Componente Funcional Básico (CFB)

No método de medição do IFPUG (CPM 4.3), existem 5 (cinco)

tipos de componentes funcionais básicos, sendo 2 (dois) deles são

funções de dados e os outros 3 (três) são funções de transação:

Arquivo Lógico Interno (ALI)

Arquivo de Interface Externa (AIE)

Entrada Externa (EE)

Saída Externa (SE)

Consulta Externa (CE)

- 84 -



funções de dados


- 85 -

Função de Dados

Funcionalidade fornecida ao usuário para atender requisitos de

armazenamento externo e interno de dados.

Existem dois tipos de função de dados:




São também denominadas arquivos lógicos.

O termo “arquivo” aqui não significa tabela ou arquivo físico,

mas sim um grupo de dados logicamente relacionados,

não importando sua implementação física.



- 86 -


Grupo de dados ou informações de controle logicamente

relacionados, reconhecível pelo usuário e mantido dentro

da fronteira da aplicação que está sendo medida.

É um dos cinco tipos de componente funcional básico.




- 87 -









- 88 -







informações de controle

dados que influenciam um processo elementar especificando

quando, como e quais dados devem ser processados.


manter

ter capacidade para adicionar, modificar ou excluir dados por

meio de processos elementares.




- 89 -



relacionados que é referenciado pela aplicação que está

sendo medida, mas que é mantido dentro da fronteira de

outra aplicação.





- 90 -

Função de Transação

Processo elementar que fornece ao usuário funcionalidade para

processar dados.

Existem três tipos de função de transação:

▪ Entrada Externa (EE)

▪ Consulta Externa (CE)

▪ Saída Externa (SE)




- 91 -


Processo elementar que processa dados ou informações de controle

recebidos de fora da fronteira.





- 92 -


Processo elementar que envia dados ou informações de controle

para fora da fronteira.





- 93 -

Saída Externa (SE)


para fora da fronteira e inclui lógica de processamento adicional

além daquela de uma Consulta Externa.





- 94 -

Saída Externa (SE)








- 95 -

Saída Externa (SE)






lógica de processamento

qualquer requisito especificamente solicitado pelo usuário para

completar um processo elementar, tal como validações, algoritmos ou

cálculos e leitura ou manutenção de uma função de dados.




- 96 -

Árvore de Classificação dos Componentes Funcionais


Componente

Funcional

Básico

Função de

Transação

Função de

Dados





Saída Externa (SE)


- 97 -

Árvore de Classificação dos Componentes Funcionais


Componente

Funcional

Básico

Função de

Transação

Função de

Dados





Saída Externa (SE) ( processo elementar )

( arquivo lógico )


- 98 -

Funções de Dados


Grupo de dados ou informações de controle logicamente relacionados,

reconhecível pelo usuário e mantido pela aplicação medida.



reconhecível pelo usuário e referenciado pela aplicação medida,

mas mantido por outra aplicação.

É um ALI de outra aplicação referenciado pela aplicação medida !



- 99 -

Intenção Principal das Funções de Dados


Armazenar dados mantidos por meio de um ou mais processos

elementares dentro da fronteira da aplicação medida.


Armazenar dados referenciados por meio de um ou mais processos

elementares dentro da fronteira da aplicação medida.



- 100 -

Funções de Transação







Saída Externa (SE)






- 101 -

Intenção Principal das Funções de Transação


Manter um ou mais ALI’s e/ou alterar o comportamento do sistema.


Apresentar informação a um usuário por meio da recuperação de

dados ou informações de controle.

Saída Externa (SE)

Apresentar a informação a um usuário por meio de lógica de

processamento diferente ou adicional à simples recuperação

direta de dados ou informações de controle.



- 102 -

Consulta Externa (CE) x Saída Externa (SE)


Não faz nenhuma das coisas abaixo: não efetua cálculos matemáticos

não mantém nenhum ALI

não altera o comportamento do sistema.

não produz dados derivados

Saída Externa (SE)

Faz pelo menos uma das coisas abaixo: efetua cálculo matemático

mantém um ou mais ALI’s

altera o comportamento do sistema.

produz dados derivados



- 103 -





não altera o comportamento do sistema


Saída Externa (SE)



altera o comportamento do sistema




- 104 -







Saída Externa (SE)






dado derivado

Dado resultante de um

processamento que envolve

passos diferentes ou adicionais

à simples recuperação e

validação da informação obtida

das funções de dados.

ISO/IEC 20926-1:2009, definition 3.17

Exemplo: criar uma abreviatura

com base nas iniciais de um nome.


- 105 -

Modelo Conceitual para Análise de Pontos de Função


Fatto Sistemas __________________

Sumário Executivo de Projeto

Projeto : BR01020 Cliente : Banco Istabel Base : 31/05/1998

Custos x Faturado

......................

......................

......................

......................

......................

......................

......................

software medido

ALI

fronteira

EE

CE

SE

usuário

humano


- 106 -



Fatto Sistemas __________________



Custos x Faturado

......................

......................

......................

......................

......................

......................

......................

software medido outro

software

AIE ALI

EE

fronteiras

CE

SE

EE

CE

SE

usuário

humano


- 107 -



Fatto Sistemas __________________



Custos x Faturado

......................

......................

......................

......................

......................

......................

......................

software medido outro

software

AIE ALI

EE

fronteiras

CE

SE

EE

CE

SE

SE

hardware externo ( sensores, equipamentos controlados, etc.)

usuário

humano EE


- 108 -




- 109 -




- 110 -

Complexidade Funcional

Nível específico de complexidade atribuído a um componente

funcional de acordo com as regras estabelecidas na Norma

ISO/IEC 20926.


Podem ser atribuídos somente 3 valores: baixa, média ou alta.



- 111 -

Complexidade dos Componentes Funcionais

Funções de Dados

Depende dos seguintes parâmetros:

quantidade de Dados Elementares Referenciados (DER)

quantidade de Registros Lógicos Referenciados (RLR)




quantidade de Arquivos Lógicos Referenciados (ALR)



- 112 -


Funções de Dados










- 113 -


Funções de Dados










- 114 -

Dado Elementar Referenciado (DER)

Atributo único, reconhecido pelo usuário e não repetido.


Exemplos

Três campos físicos usados para armazenar dia, mês e ano referentes a uma

data de vencimento (visão do usuário) constituem 1 único DER.

Um campo utilizado para armazenar uma informação técnica desconhecida

pelo usuário (exemplo: um código interno de transação) não é um DER.

Um conjunto de 12 campos usados para armazenar uma mesma informação

referente a cada mês do ano constitui apenas 2 DER’s (mês e valor).



- 115 -

Registro Lógico Referenciado (RLR)

Subgrupo de Dados Elementares Referenciados (DER’s)

reconhecíveis pelo usuário dentro de uma função de dados.


Exemplo

Em uma aplicação de RH são cadastradas informações de funcionários

horistas e mensalistas, juntamente com informações de seus dependentes.

Existem atributos genéricos comuns a ambos os tipos de funcionários,

atributos específicos de horistas e atributos específicos de mensalistas.

Neste caso, o ALI “funcionário” possuirá 3 RLR’s:

Registro de Horista = atributos genéricos + específicos de horista

Registro de Mensalista = atributos genéricos + específicos de mensalista

Registro de Dependente = atributos de dependente (relação 1:n)



- 116 -

Arquivo Lógico Referenciado (ALR)

Função de dados lida e/ou mantida por uma função de transação.


Um ALR é :

um ALI lido e/ou mantido durante o processamento da função de transação

ou

um AIE lido durante o processamento da função de transação.



- 117 -

Complexidade das Funções de Dados


ALI e AIE Quantidade de DER’s

1 a 19 20 a 50 51 ou mais

1 baixa baixa média

2 a 5 baixa média alta

6 ou mais média alta alta Qtd

e.

RL

R’s


- 118 -

Complexidade das Funções de Transação


EE Quantidade de DER’s

1 a 4 5 a 15 16 ou mais

0 a 1 baixa baixa média

2 baixa média alta


e. A

LR

’s


- 119 -



CE Quantidade de DER’s

1 a 5 6 a 19 20 ou mais




e. A

LR

’s


- 120 -



SE Quantidade de DER’s

1 a 5 6 a 19 20 ou mais




e. A

LR

’s


- 121 -

Importante

EE’s e SE’s podem não ter nenhum ALR !

Já uma CE tem que ter no mínimo 1 ALR !

Observe a intenção principal de cada tipo de transação:





Apresentar informação a um usuário por meio da

recuperação de dados ou informações de controle.

Saída Externa (SE)





- 122 -

Importante










Saída Externa (SE)




pode não ter nenhum ALR !


- 123 -

Importante










Saída Externa (SE)




tem que ter pelo menos 1 ALR !


- 124 -

Importante










Saída Externa (SE)




pode não ter nenhum ALR !


- 125 -

Tamanho Funcional

Tamanho do software, derivado a partir da quantificação

dos requisitos funcionais de usuário.


O tamanho funcional é medido em pontos de função (PF).

O tamanho funcional é calculado a partir da complexidade

de cada função de dados e de cada função transacional.

Cada tipo de função possui um valor padrão em PF,

que depende de sua complexidade (baixa, média ou alta).

O tamanho funcional do software é dado pela soma dos

valores de todas as funções de dados e de transação.



- 126 -

Valores em Pontos de Função


Função Complexidade

baixa média alta

ALI 7 10 15

AIE 5 7 10

EE 3 4 6

CE 3 4 6

SE 4 5 7


- 127 -

ALI Arquivo Lógico Interno ILF Internal Logical File

AIE Arquivo de Interface Externa EIF External Interface File

EE Entrada Externa EI External Input

CE Consulta Externa EQ External Inquiry

SE Saída Externa EO External Output


Terminologia Bilingue para os Componentes Funcionais


- 128 -

DER Dado Elementar Referenciado DET Data Element Type

RLR Registro Lógico Referenciado RET Record Element Type

ALR Arquivo Lógico Referenciado FTR File Type Referenced


Terminologia Bilingue para os Parâmetros de Complexidade


- 129 -

IFPUG CPM 4.3.1 em português IFPUG CPM – all releases

DER Dado Elementar Referenciado DET Data Element Type

RLR Registro Lógico Referenciado RET Record Element Type

ALR Arquivo Lógico Referenciado FTR File Type Referenced

Livro Vazquez et al. , 2009 IFPUG CPM – all releases

TD Tipo de Dado DET Data Element Type

TR Tipo de Registro RET Record Element Type

AR Arquivo Referenciado FTR File Type Referenced


Traduções Alternativas (CPM 4.3.1 x Livro Vazquez 2009)


- 130 -












- 131 -

1. Reunir a documentação disponível.

2. Determinar o escopo e a fronteira da contagem

3. Identificar os requisitos funcionais de usuário.

4. Medir funções de dados.

5. Medir funções de transação.

6. Calcular o tamanho funcional.

7. Documentar e reportar.


Etapas do processo de medição funcional:


- 132 -


Determinar o

escopo e a

fronteira da

contagem e

identificar

requisitos

funcionais

de usuário

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível


- 133 -

Determinar o

escopo e a

fronteira da

contagem e

identificar

requisitos

funcionais

de usuário

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível


Reunir a documentação disponível


- 134 -

Determinar o

escopo e a

fronteira da

contagem e

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível identificar

requisitos

funcionais

de usuário


Determinar o escopo e a fronteira da contagem


- 135 -

identificar

requisitos

funcionais

de usuário

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível

Determinar o

escopo e a

fronteira da

contagem e


Identificar requisitos funcionais de usuário


- 136 -


Determinar o

escopo e a

fronteira da

contagem e

identificar

requisitos

funcionais

de usuário

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível

Medir funções de dados


- 137 -


Determinar o

escopo e a

fronteira da

contagem e

identificar

requisitos

funcionais

de usuário

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível

Medir funções de transação


- 138 -


Determinar o

escopo e a

fronteira da

contagem e

identificar

requisitos

funcionais

de usuário

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível

Calcular o tamanho funcional


- 139 -


Determinar o

escopo e a

fronteira da

contagem e

identificar

requisitos

funcionais

de usuário

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível

Documentar e reportar


- 140 -












- 141 -


Determinar o

escopo e a

fronteira da

contagem e

identificar

requisitos

funcionais

de usuário

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível


- 142 -

• A documentação usada para fundamentar a contagem de pontos de

função deve descrever a toda a funcionalidade fornecida pelo software

ao usuário.

• É necessário coletar documentação suficiente para conduzir a

contagem de pontos de função.

• Em caso de documentação incompleta, pouco detalhada ou

desatualizada, informações suplementares devem ser coletadas junto

a especialistas nos processos de negócio e usuários do sistema.

Diretrizes



- 143 -

• proposta de projeto

• especif. de necessidades de negócio

• levantamento de requisitos

• documento de visão

• diagramas de fluxo de dados

• diagramas entidade-relacionamento

• modelos de dados

• modelos de classes

• diagramas de casos de uso

• especificação de casos de uso

• especificações funcionais

• especificações suplementares

• layout de bases de dados

• layout de arquivos de transação

• definição das interfaces

• protótipos de interfaces

• descrição de processos batch

• amostras ou layout de relatórios

• amostras ou layout de telas

• guias de usuário

• manuais de treinamento

• aplicações de "help"

• documentação do projeto do sistema

• demonstração da operação da sistema

• consulta a especialistas no negócio

• consulta a clientes e usuários

Informações úteis para medição funcional



- 144 -












- 145 -


Determinar o

escopo e a

fronteira da

contagem e

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível identificar

requisitos

funcionais

de usuário


- 146 -

Etapas do processo

1. Definir o propósito da contagem.

2. Identificar o tipo de contagem, com base em seu propósito:

contagem de projeto de desenvolvimento

contagem de aplicação

contagem de projeto de melhoria

3. Identificar o escopo da contagem, com base em seu propósito e tipo.

4. Delimitar a fronteira de cada aplicação dentro do escopo da contagem,

com base na visão do usuário, e não na arquitetura técnica.

5. Documentar as decisões tomadas ao longo do processo.



- 147 -

Passo 1 : definindo o propósito da contagem

• O propósito da contagem de pontos de função é fornecer uma resposta

a um problema do negócio.

• O propósito:

determina o tipo e o escopo de uma contagem de pontos de função

requerida para obter a resposta ao problema de negócio em questão;

influencia o posicionamento da fronteira entre o software que está sendo

medido e os softwares vizinhos.

Exemplo: Se for planejada a substituição do Modulo de Pessoal de um

sistema de RH por um pacote comercial, os usuários poderão

decidir reposicionar a fronteira e considerar o Módulo de

Pessoal como uma aplicação separada



- 148 -

Passo 1 : definindo o propósito da contagem

• Exemplos de propósitos:

Fornecer o tamanho funcional como uma entrada de informação para um

processo de estimativa, visando determinar o esforço para desenvolver a

primeira versão de uma aplicação;

Medir o tamanho funcional da base instalada de aplicações, visando

determinar o custo de suporte por ponto de função;

Medir o tamanho funcional de um pacote comercial de software, como

subsídio para uma análise “make or buy”;

Medir o tamanho funcional de dois pacotes de software de diferentes

fornecedores, para possibilitar a comparação das funcionalidades

disponibilizadas como apoio à decisão de compra.



- 149 -

Passo 2 : identificando o tipo de contagem

• As contagens de pontos de função podem estar associadas tanto a

projetos quanto a aplicações.

• Existem três tipos de contagem de pontos de função:

Projeto de desenvolvimento

Projeto de melhoria

Aplicação



- 150 -


Projeto de desenvolvimento

• Consiste em desenvolver e entregar a primeira versão de um software.

Projeto de melhoria

• Consiste em desenvolver e entregar uma nova versão de um software,

envolvendo a adição, modificação e/ou exclusão de funcionalidades.

Aplicação

• Conjunto coeso de procedimentos automatizados e dados suportando

um objetivo de negócio, que pode consistir de um ou mais

componentes, módulos, ou subsistemas.



- 151 -


Contagem de projeto de desenvolvimento

• Mede as funções fornecidas ao usuário com a primeira instalação do

software, disponibilizado no momento em que o projeto é concluído.

Contagem de projeto de melhoria

• Mede as modificações na aplicação existente que incluem, alteram ou

excluem funções disponibilizadas ao usuário na conclusão do projeto.

• Quando uma funcionalidade de um projeto de melhoria é instalada, a

contagem de pontos de função da aplicação deve ser atualizada para

refletir as alterações nas respectivas funcionalidades.



- 152 -


Contagem de aplicação

• Está associada à aplicação instalada (e não a um projeto).

• É também denominada contagem de baseline ou de base instalada.

• Fornece uma medida das funções que a aplicação instalada oferece

ao usuário no momento presente.

• É inicializada no momento em que o projeto de desenvolvimento é

concluído e a primeira versão da aplicação é instalada.

• Tem que ser atualizada toda vez que um projeto de melhoria alterar

as funções da aplicação.



- 153 -


Contagem Estimada x Contagem Final

• A medição funcional efetuada no início do ciclo de vida de um projeto

corresponde, geralmente, a uma estimativa aproximada das funcionalidades

que serão disponibilizadas.

• À medida que o desenvolvimento avança e o escopo é melhor esclarecido,

frequentemente são identificadas funcionalidades adicionais que não

estavam originalmente especificadas.

• Este fenômeno é chamado de scope creep.

• Por isso é essencial atualizar a contagem da aplicação na conclusão do

projeto, para que a contagem de pontos de função reflita corretamente as

funcionalidades disponibilizadas ao usuário, possibilitando a inicialização

correta do baseline.



- 154 -


Cenário Típico de Scope Creep


100 PFs 120 PFs 130 PFs 135 PFs

• Tela de entrada do

código do estado

alterada (3 PFs)

• Acrescentada interface

arquivo N&A (10 PFs)

• Consulta N&A e ao

código do estado

acrescentadas (7 PFs)

• Nova tabela legal

acrescentada (10

PFs)

• Relatório resumo

incluído (5 PFs)

100 PFs 120 PFs 130 PFs 135 PFs

• Tela de entrada do

código do estado

alterada (3 PFs)

• Acrescentada interface

arquivo N&A (10 PFs)

• Consulta N&A e ao

código do estado

acrescentadas (7 PFs)

• Nova tabela legal

acrescentada (10

PFs)

• Relatório resumo

incluído (5 PFs)

Impacto

Esforço

Cronograma

Custo

+ 1 mês

+ 2 semanas

+ $5000

+ 0.5 meses

+ 2 semanas

+ $2500

+ 0.25 meses

+ 2.5 dias

+ $1250

Impacto

Esforço

Cronograma

Custo

+ 1 mês

+ 2 semanas

+ $5000

+ 0.5 meses

+ 2 semanas

+ $2500

+ 0.25 meses

+ 2.5 dias

+ $1250

Aplicativo

Entregue

Projeto

Detalhado

Projeto

FuncionalRequisitos



Cenário típico ilustrando a evolução de diferentes tipos de contagem:


- 155 -

1. Desenvolvimento iniciado

projeto de desenvolvimento

iniciado





- 156 -

Cont. Estimada

Projeto de

Desenvolvimento


cont. estimada desenvolvimento


iniciado





- 157 -

Cont. Estimada

Projeto de

Desenvolvimento

projeto concluído



2. Desenvolvimento concluído

projeto de

desenvolvimento iniciado





- 158 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

projeto concluído




contagem final desenvolvimento projeto de






- 159 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Contagem

Aplicação

(baseline)

projeto concluído




contagem final desenvolvimento inicializar contagem do baseline

inicializar projeto de



projeto de melhoria iniciado




- 160 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Contagem

Aplicação

(baseline)

projeto concluído





3. Projeto de melhoria iniciado







- 161 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Cont. Estimada

Projeto de

Melhoria

Contagem

Aplicação

(baseline)

projeto concluído






contagem estimada melhoria





projeto concluído




- 162 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Cont. Estimada

Projeto de

Melhoria

Contagem

Aplicação

(baseline)

projeto concluído







4. Projeto de melhoria concluído








- 163 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Cont. Estimada

Projeto de

Melhoria

Contagem Final

Projeto de

Melhoria

Contagem

Aplicação

(baseline)

projeto concluído

projeto concluído








contagem final melhoria








- 164 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Cont. Estimada

Projeto de

Melhoria

Contagem Final

Projeto de

Melhoria

Contagem

Aplicação

(baseline)

projeto concluído

projeto concluído








contagem final melhoria atualizar contagem do baseline

inicializar

atualizar


iniciado






- 165 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Cont. Estimada

Projeto de

Melhoria

Contagem Final

Projeto de

Melhoria

Contagem

Aplicação

(baseline)

projeto concluído

projeto concluído









inicializar

atualizar


iniciado



- 166 -


Passo 3 : identificando o escopo da contagem

Definição

• O escopo da contagem define o subconjunto das funcionalidades que

serão incluídas em uma contagem de pontos de função específica.

Características :

• define um subconjunto do software que está sendo medido;

• é determinado pelo propósito da contagem de pontos de função;

• identifica quais funções serão incluídas na contagem de pontos de

função para fornecer respostas relevantes ao propósito da contagem;

• pode incluir mais de uma aplicação.


- 167 -


No caso de projetos de desenvolvimento :

• O escopo inclui todas as funcionalidades impactadas (construídas ou

customizadas) pelas atividades do projeto.

• São incluídas também funcionalidades de conversão de dados

construídas durante o projeto.

No caso de projetos de melhoria :

• O escopo inclui todas as funcionalidades adicionadas, modificadas ou

excluídas da aplicação que está sofrendo manutenção.

• São incluídas também funcionalidades de conversão de dados

construídas durante o projeto.

• A fronteira das aplicações impactadas permanece a mesma.



- 168 -


No caso de contagem de aplicação (baseline) :

• O escopo pode incluir, dependendo do propósito:

apenas as funções utilizadas pelo usuário

todas as funções disponibilizadas

O tamanho funcional medido será diferente em cada caso

A fronteira da aplicação é a mesma e independe do escopo



- 169 -


Dicas para identificação do escopo da contagem :

• Atenção ao propósito da contagem !!!

• No caso de contagem de base instalada de aplicação (baseline),

inclua todas as funcionalidades que estiverem atualmente em

produção e que sejam utilizadas pelos usuários.

Exemplo: quando o propósito da contagem for medir o tamanho

funcional atendido pelo grupo de suporte e/ou manutenção.



- 170 -


Passo 4 : delimitando a fronteira de cada aplicação

Definição

• A fronteira da aplicação indica o limite entre o sistema que está sendo

medido e o usuário.

lembrando que o “usuário” pode ser também um sistema externo

Características :

• é uma interface conceitual entre a aplicação ‘interna’ e o usuário ‘externo’;

• atua como uma ‘membrana’, através da qual os dados processados pelas

transações (EEs, SEs e CEs) passam para dentro e para fora da aplicação;

• inclui dados lógicos mantidos pela aplicação (ALIs);

• ajuda na identificação dos dados que são lidos (referenciados) pela aplicação,

mas mantidos por processos externos (AIEs);

• depende da visão externa do negócio do usuário da aplicação;

• é independente de considerações técnicas ou de implementação


- 171 -



Exemplo :


- 172 -



Regras para delimitação da fronteira

• A fronteira é determinada com base na visão do usuário. O foco está no

que o usuário pode entender e descrever.

• A fronteira entre aplicações relacionadas se baseia nas diferentes áreas

funcionais como vistas pelo usuário, e não em considerações técnicas.

• A fronteira inicial já estabelecida para a aplicação (ou aplicações) que

está sendo modificada não é influenciada pelo escopo da contagem.


- 173 -



Importante

• Pode haver mais de uma aplicação incluída no escopo da contagem.

• Neste caso, deverão ser identificadas múltiplas fronteiras de aplicações.

• Quando a fronteira da aplicação não estiver bem definida (por exemplo:

na fase inicial do projeto), ela deverá ser posicionada da forma mais

exata que for possível.


- 174 -


Dicas para identificação da fronteira :

• Utilize especificações externas do sistema, ou obtenha um fluxo do mesmo,

e desenhe a respectiva fronteira, destacando as partes interna e externa à

aplicação.

• Verifique como os grupos de dados estão sendo mantidos.

• Identifique as áreas funcionais, alocando certos tipos de objetos da análise (tais

como entidades ou processos elementares) a uma área funcional.

• Observe dados de medição correlatos, tais como esforço, custo e defeitos. As

fronteiras consideradas para os pontos de função e para os outros dados de

medição devem ser as mesmas.

• Entreviste usuários e especialistas nos processos de negócio para obter auxílio

na identificação das fronteiras.



- 175 -


Importante :

• O posicionamento da fronteira da aplicação entre o sistema em análise

e outras aplicações de software pode ser subjetivo.

• É freqüentemente difícil delinear onde uma aplicação termina e outra

começa.

• Deve-se procurar estabelecer a fronteira a partir da perspectiva do

negócio, ao invés de considerações físicas ou técnicas.

• É importante que a fronteira da aplicação seja estabelecida com

cuidado, uma vez que todos os dados que atravessam a fronteira

podem, a princípio, ser incluídos no escopo da contagem.



- 176 -

Passo 5 : documentando as decisões tomadas

Os seguintes itens devem ser documentados :

• o propósito da contagem

• o escopo da contagem

• as fronteiras das aplicações

• quaisquer suposições relacionadas aos itens acima



- 177 -












- 178 -


identificar

requisitos

funcionais

de usuário

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível

Determinar o

escopo e a

fronteira da

contagem e


- 179 -

Usuário

Pessoa ou coisa que em algum momento interage com o software

(envia/recebe dados) ou especifica seus requisitos.

Requisitos Funcionais do Usuário

Subconjunto dos requisitos do usuário que descrevem o que o software

deverá fazer, em termos de tarefas e serviços.

Visão do Usuário

Descrição formal das necessidades de negócio do usuário, expressa na

linguagem do usuário.



- 180 -

Visão do Usuário

• É uma descrição das funções do negócio

• É aprovada pelo usuário

• Pode ser usada para medir o tamanho funcional do sistema

• Pode variar na forma física (propostas comerciais, documento de

requisitos, especificações externas, especificações detalhadas, etc.)

• Pode até mesmo ser expressa por declarações verbais do usuário

Usuário x Desenvolvedor

• Os desenvolvedores traduzem a informação do usuário para uma

linguagem técnica, com o objetivo de fornecer uma solução.

• A medição funcional deve ser efetuada com base em informações

expressas em uma linguagem comum a usuários e a desenvolvedores.



- 181 -

Maturidade dos Requisitos x Precisão da Medição

• Em um estágio inicial do processo de desenvolvimento, as

necessidades de negócio do usuário podem ser as únicas informações

disponíveis para fundamentar a medição funcional do sistema.

• Nesse momento, devido ao baixo grau de maturidade das informações,

premissas a respeito de funcionalidades ainda desconhecidas precisam

ser assumidas para viabilizar uma estimativa do tamanho funcional.

• Na medida em que o projeto evolui e novas características e

detalhamentos dos requisitos são descobertos, as premissas

assumidas para encobrir incertezas vão sendo eliminadas.

• A precisão da medição funcional dependerá da qualidade e da

maturidade dos requisitos identificados.



- 182 -

O Processo de Amadurecimento dos Requisitos

• Enquanto os requisitos forem expressos apenas como necessidades de

negócio, eles poderão apresentar as seguintes características:

- muito genéricos e às vezes ambíguos

- expressos em terminologia não compreensível pelo desenvolvedor

- incompletos

- instáveis, sujeitos a mudanças

• Na medida em que a visão do usuário começa a ser interpretada e

complementada com a visão do desenvolvedor, os requisitos:

- tornam-se mais específicos e sem ambiguidades

- passam a ser expressos em terminologia inteligível por todos

- fornecem descrição integrada das necessidades de todos os usuários

- tendem a permanecer relativamente estáveis



- 183 -

Fonte: Vazquez et al., 2009




- 184 -


• A título de ilustração, consideremos um modelo que divide o grau de

maturidade dos documentos de requisitos em 3 fases:

- Fase 1: requisitos iniciais de usuário

esta fase representa os requisitos dos usuários antes

dos primeiros contatos com os desenvolvedores

- Fase 2: requisitos técnicos iniciais

esta fase representa a visão dos desenvolvedores

a respeito dos requisitos criados na fase anterior

- Fase 3: requisitos funcionais finais (fase 3)

são requisitos funcionais consistentes e completos, produzidos

em conjunto por usuários e desenvolvedores



- 185 -

Exemplo de situação na Fase 1

Suponha que um usuário do RH expresse seu requisito assim:

"Preciso manter um cadastro de funcionários e quero, a qualquer momento,

entrar com o nome de um funcionário e ver todos os seus dados cadastrais.”

Funções identificadas na Fase 1

Este requisito implica no desenvolvimento de uma tela de consulta e de

um arquivo lógico com dados de funcionário.

Tipo Descrição

CE Consultar dados cadastrais de um funcionário específico

ALI Dados cadastrais dos funcionários



- 186 -

A mesma situação na Fase 2

Ao examinar o requisito, o desenvolvedor declara:

“OK, vamos implementar a consulta. Mas precisaremos criar, além da tabela de

funcionários, um arquivo com um índice para acelerar a recuperação dos dados”


O arquivo cuja criação foi proposta pelo desenvolvedor pode ser

equivocadamente considerado como um ALI.

Tipo Descrição



ALI Índice com ordenação dos funcionários pelo nome



- 187 -


Ao examinar o requisito, o desenvolvedor declara:

“OK, vamos implementar a consulta. Mas precisaremos criar, além da tabela de

funcionários, um arquivo com um índice para acelerar a recuperação dos dados”


O arquivo cuja criação foi proposta pelo desenvolvedor pode ser

equivocadamente considerado como um ALI. Mas não é, pois trata-se

de um arquivo criado apenas para cumprir requisitos não-funcionais.

Tipo Descrição



ALI Índice com ordenação dos funcionários pelo nome



- 188 -


Após uma análise mais detalhada, o desenvolvedor declara:

“Nem sempre será possível selecionar um único funcionário com base apenas

no nome. Sugiro a exibição de uma lista de clientes com nome, matrícula e

localização, na qual será possível selecionar funcionários individualmente.”

O usuário responde:

“OK ! Aproveitaremos a lista para outros propósitos além de selecionar cliente.”


Tipo Descrição


CE Exibir lista de funcionários




- 189 -

Fase 1: Requisitos Iniciais de Usuário

Podem ter uma ou mais dentre as características abaixo:

• incompletos exemplo: faltando especificar integridade referencial

• com funcionalidades faltantes exemplo: consultas e relatórios indispensáveis podem estar faltando

• impossíveis de implementar ou de uso muito difícil exemplo: uma consulta online que requeira 1 hora de processamento

• muito genéricos exemplo: os requisitos podem não incluir a lista de campos de um relatório

• não atendem as necessidades de todos os usuários exemplo: o usuário que especificou desconhece necessidades de outros usuários

• definidos sem levar em conta a fronteira da aplicação exemplo: usuário pede um campo novo que precisaria ser gravado em sistema externo

• expressos em diferente contexto ou em terminologia incompatível c/ APF



- 190 -

Fase 2: Requisitos Técnicos Iniciais

Podem ter uma ou mais dentre as características abaixo:

• dependência tecnológica exemplo: arquivos físicos variam conforme o ambiente de banco de dados

• identificação incorreta das necessidades funcionais dos usuários exemplo: inclusão de funcionalidades não solicitadas pelo usuário por motivo técnico

• terminologia não-familiar aos usuários exemplo: referir-se a tabelas físicas em lugar de grupos lógicos de dados

• delineamento das funcionalidades com ênfase em restrições técnicas exemplo: limitar/alterar requisitos funcionais com base nos recursos computacionais disponíveis no momento na organização

• fronteira delimitada por arquitetura técnica (e não por processos) exemplo: pode haver requisitos técnicos distintos para os lados cliente e servidor, mas do pto de vista funcional o processo todo está dentro da mesma fronteira



- 191 -

Fase 3: Requisitos Funcionais Finais

• São requisitos completos e consistentes, resultantes de reuniões

conjuntas entre usuários e desenvolvedores. Correspondem à

versão final e possuem as seguintes características:

- sua terminologia é entendida por usuários e desenvolvedores

- fornecem descrições integradas de todos os requisitos de usuário,

inclusive requisitos de diferentes usuários.

- definem completamente todos os processos de negócio, incluindo: todas as ações do usuário

todos os campos que entram e saem pela fronteira da aplicação

todas as fontes de dados, internas e externas

todos os processos de validação de dados

- cada processo e cada grupo de dados é aprovado pelo usuário

- a viabilidade e usabilidade são aprovadas pelos desenvolvedores



- 192 -












- 193 -

Determinar o

escopo e a

fronteira da

contagem e

identificar

requisitos

funcionais

de usuário

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível



- 194 -

Funções de Dados






reconhecível pelo usuário e referenciado pela aplicação medida, mas

mantido por outra aplicação.




- 195 -

Etapas do Processo

1. Identificar e agrupar todos os dados lógicos em funções de dados

2. Classificar cada função de dados como ALI ou AIE

3. Contar os DER’s para cada função de dados

4. Contar os RLR’s para cada função de dados

5. Determinar a complexidade funcional de cada função de dados

6. Determinar o tamanho funcional de cada função de dados



- 196 -

Etapas do Processo









- 197 -

Passo 1 : Identificar e agrupar todos os dados lógicos

em funções de dados


Regra Descrição

1.1 Identificar todos os dados e informações de controle logicamente

relacionados que estejam dentro do escopo da contagem.

1.2 Excluir entidades que não são mantidas por nenhuma aplicação.

1.3 Agrupar entidades dependentes com suas entidades principais.

1.4 Excluir entidades referentes a dados de código.

1.5 Excluir entidades que não tenham atributos requeridos pelo usuário.

1.6 Remover entidades associativas que contenham somente chaves

estrangeiras e/ou atributos adicionais não requeridos pelo usuário,

agrupando os atributos de chave estrangeira com as entidades

primárias.


- 198 -




Regra

1.1

Identificar todos os dados e informações de controle logicamente

relacionados que estejam dentro do escopo da contagem.

Dicas:

Verificar entidades e atributos em diagramas entidade/relacionamento ou

modelos de dados ou no próprio de banco de dados físico.

Verificar os campos exibidos nas telas do sistema.

Verificar campos digitados e caixas de seleção nas telas do sistema.

Verificar informações exibidas em gráficos e relatórios emitidos pelo sistema.

Verificar layout de arquivos recebidos/enviados de/para outros sistemas.


- 199 -




Regra

1.2

Excluir entidades que não são mantidas por nenhuma aplicação.

Observações:

Toda função de dados tem que ser mantida por pelo menos uma aplicação,

seja a aplicação que está sendo medida (no caso de ALI’s) ou alguma outra.

Arquivos ou tabelas com conteúdo estático não são funções de dados.


- 200 -




Regra

1.3

Agrupar entidades dependentes com suas entidades principais.


- 201 -




Regra

1.3



- 202 -




Regra

1.3


Entidade Dependente

Entidade X que não faz sentido ou não é relevante para o negócio sem a

presença de outra entidade Y tal que:

toda ocorrência de X tem que estar vinculada a uma ocorrência de Y;

a exclusão de uma ocorrência de Y implica na exclusão de todas as

ocorrências de X a ela relacionadas.



- 203 -




Regra

1.3


Exemplo:

Em um sistema de RH, a entidade “Dependente” é geralmente uma entidade

dependente da entidade “Funcionário”, visto que:

todo dependente tem que estar vinculado a um funcionário;

a exclusão de um funcionário implica na exclusão de todos os

dependentes a ele relacionados.

Neste caso a entidade “Dependente” deve ser agrupada com a entidade

“Funcionário” e o grupo terá RLR’s distintos para funcionário e dependente.


- 204 -




Regra

1.4

Excluir entidades referentes a dados de código.


- 205 -




Regra

1.4



- 206 -




Regra

1.4


Dados de Código

São dados que existem somente para atender requisitos não-funcionais,

por razões técnicas, ou devido à implementação física ou a requisitos de

qualidade.


- 207 -




Regra

1.4


São considerados dados de código:

Entidades de substituição de dados que contêm apenas um código e um nome

explicativo ou uma descrição.

Entidades com uma única ocorrência que contenham atributos raramente alterados.

Entidades que contêm dados essencialmente estáticos ou que mudem raramente.

Entidades contendo valores default para preencher atributos.

Entidades que armazenam valores para seleção ou validação.

Entidades que contenham uma faixa de valores para validação.


- 208 -




Regra

1.4


Observação:

Mesmo no caso de tais entidades possuírem atributos adicionais com

propósito de auditoria ou de definir períodos de validade, a presença desses

atributos não altera a natureza dessas entidades. Continuam sendo

consideradas dados de código e devem ser excluídas da contagem.


- 209 -




Regra

1.5

Excluir entidades que não tenham atributos requeridos pelo usuário.

Observações:

Entidades sem atributos reconhecíveis pelo usuário não contam pontos de

função, mesmo que seu conteúdo seja atualizado frequentemente.

Geralmente são entidades criadas pelos desenvolvedores, por motivos

técnicos.


- 210 -




Regra

1.6

Remover entidades associativas que contenham somente chaves



primárias.


- 211 -




Regra

1.6




primárias.


- 212 -




Regra

1.6




primárias.

Entidade Associativa

Entidade que contém atributos que descrevem um relacionamento

“muitos-para-muitos” entre duas outras entidades.



- 213 -

Etapas do Processo









- 214 -

Passo 2 : Classificar as funções de dados

como ALI ou AIE







reconhecível pelo usuário e referenciado pela aplicação medida, mas

mantido por outra aplicação.



- 215 -


como ALI ou AIE


Regra Descrição

2.1 Classificar como ALI as funções de dados mantidas pela aplicação

que está sendo medida.

2.2 Classificar como AIE as funções de dados referenciadas (mas não

mantidas) pela aplicação que está sendo medida e identificadas

como ALI em uma ou mais outras aplicações.


- 216 -


como ALI ou AIE


Regra

2.1

Classificar como ALI as funções de dados mantidas pela aplicação

que está sendo medida.

Observações:

Tomar cuidado para não confundir a fronteira funcional com uma

fronteira de arquitetura técnica.

Para ser um ALI, o que importa é que ele seja mantido por processos

elementares da aplicação que está sendo medida, mesmo que o arquivo

físico fique numa plataforma de hardware ou sistema operacional

diferente da aplicação que está sendo medida.


- 217 -


como ALI ou AIE


Regra

2.2

Classificar como AIE as funções de dados referenciadas (mas não

mantidas) pela aplicação que está sendo medida e identificadas

como ALI em uma ou mais outras aplicações.

Observações:

Somente dados que sejam mantidos por alguma aplicação podem ser

considerados AIE.

Tabelas ou arquivos estáticos não são funções de dados.


- 218 -

Etapas do Processo









- 219 -

Passo 3 : Contar os DER’s para cada função de dados


Dado Elementar Referenciado (DER)

Atributo único, reconhecido pelo usuário e não repetido.

Exemplos


data de vencimento (visão do usuário) constituem 1 único DER.

Um campo utilizado para armazenar uma informação técnica desconhecida

pelo usuário (exemplo: um código interno de transação) não é um DER.

Um conjunto de 12 campos usados para armazenar uma mesma informação

referente a cada mês do ano constitui apenas 2 DER’s (mês e valor).


- 220 -



Regra Descrição

3.1 Contar 1 DER para cada atributo único, não repetido e reconhecível

pelo usuário, que seja mantido ou recuperado pela função de dados

por meio da execução de processos elementares dentro do escopo

da contagem.

3.2 No caso de dados compartilhados com outras aplicações, contar

somente os DER’s referenciados ou mantidos pela aplicação que

está sendo contada.

3.3 Contar 1 DER para cada atributo requerido pelo usuário que

estabeleça um relacionamento com outra função de dados.

3.4 Rever atributos interrelacionados para determinar se devem ser

considerados como DER’s independentes ou como 1 único DER.


- 221 -



Regra

3.1

Contar 1 DER para cada atributo único, não repetido e reconhecível



da contagem.

Dicas:

1. Um “array” de campos com o mesmo significado deve ser tratado como 1

único DER, porém acrescido de um segundo DER para “indexação do array”:

Doze campos referentes aos valores orçados para os 12 meses do ano devem

ser representados por apenas 2 DER’s: um para o valor e outro para o mês.

Isto porque os 12 campos não constituem atributos únicos.

Todos são o mesmo atributo (para meses diferentes).


- 222 -



Regra

3.1




da contagem.

Dicas:

2. Dados repetidos devem ser contados 1 única vez:

Se a matrícula de funcionário aparece duas vezes em um ALI ou AIE: (1) como

chave do registro do funcionário e (2) como chave estrangeira do registro do

dependente, deve ser contado 1 único DER.

Sempre que duas tabelas de banco de dados são agrupadas no mesmo ALI,

a chave estrangeira da entidade dependente e a chave primária da entidade

principal devem ser contadas como 1 único DET, visto que são a mesma

informação de negócio.

se a chave for composta por mais de 1 campo, contar todos 1 só vez


- 223 -



Regra

3.1




da contagem.

Dicas:

3. Somente dados mantidos ou referenciados pela aplicação que está sendo

contada podem ser DER’s:

Se o arquivo ou tabela física identificado como ALI ou AIE contém campos que não

são mantidos e nem referenciados pela aplicação que está sendo medida, estes

campos não devem ser contados como DER’s.


- 224 -



Regra

3.1




da contagem.

Dicas:

4. Campos de caráter técnico podem ser considerados DER’s quando são

reconhecidos e requisitados pelo usuário.

Por exemplo, um timestamp que seja requisitado pelo usuário pode ser um DER.


- 225 -



Regra

3.1




da contagem.

Dicas:

5. Campos calculados também são contados como DER.

Por exemplo, o resultado de um cálculo de um processo elementar, como o valor

do imposto sobre uma venda, referente a um pedido de cliente mantido em um

ALI, é contado como um DER no ALI de pedido de cliente.


- 226 -



Regra

3.2

No caso de dados compartilhados com outras aplicações, contar



Exemplo

Suponha que a Aplicação X mantém e/ou referencia um ALI que contém CPF,

Nome, Rua, Caixa Postal, Cidade, Estado e CEP.

A Aplicação Z mantém e/ou referencia Nome, Cidade e Estado.

Devem ser contados:

7 DER’s para a Aplicação X

3 DER’s para a Aplicação Z.


- 227 -



Regra

3.2

No caso de dados compartilhados com outras aplicações, contar



Dica:

O mesmo conjunto de campos pode corresponder a um número diferente de

DER’s para aplicações distintas:

Suponha que a Aplicação A identifica e utiliza separadamente os campos

“rua”, “cidade”, “estado” e “CEP”.

Já a Aplicação B referencia os mesmos campos, mas trata o endereço

como um bloco de dados sem considerar os componentes.

Neste caso são contados 4 DER’s para a Aplicação A,

mas somente 1 DER para a Aplicação B.


- 228 -



Regra

3.3

Contar 1 DER para cada atributo requerido pelo usuário que


Exemplo 1:

Em uma aplicação de RH, as informações dos funcionários são mantidas em

um cadastro, dentre elas o código do departamento onde ele está lotado,

que é uma chave estrangeira para uma tabela de departamentos mantida

por outra aplicação.

Este campo é contado como DER do ALI “Funcionário” porque é necessário

para relacionar o funcionário a um departamento existente na organização.


- 229 -



Regra

3.3

Contar 1 DER para cada atributo requerido pelo usuário que


Exemplo 2:

Em uma aplicação orientada a objetos (OO), o usuário solicita uma associação

entre classes de objetos, as quais foram identificadas como ALI’s distintos.

O nome da localidade já é um DER do ALI “Localidade”, mas essa informação

também é requerida ao processar as informações do funcionário.

Consequentemente, o nome da localidade onde o funcionário trabalha também é

contado como um DER dentro do ALI “Funcionário”.


- 230 -



Regra

3.4

Rever atributos interrelacionados para determinar se devem ser


Exemplos:


“data de vencimento” (na visão do usuário) constituem 1 único DER.

Três campos correspondentes a banco, agência e conta-corrente podem

constituir 1 único DER, se a aplicação os trata sempre como um conjunto

(a “conta-corrente do cliente”, na visão do usuário).

Duas imagem (“antes” e “depois”) de um grupo de 10 campos (total 20 campos)

mantidas para fins de auditoria deve ser representadas por apenas 2 DER’s.


- 231 -



Regra

3.4

Rever atributos interrelacionados para determinar se devem ser


Um outro exemplo:

Os atributos “primeiro nome”, “nome do meio” e “último nome” são

agrupados e contados como:

1 único DER “nome”, composto pelos 3 atributos, no caso de serem

usados sempre em conjunto;

2 DER’s: “primeiros nomes”, composto pelos dois primeiros atributos,

e “último nome”, no caso de o último nome ser referenciado

separadamente em algumas situações;

3 DER’s distintos, no caso de os 3 atributos serem usados

separadamente.


- 232 -

Etapas do Processo









- 233 -

Passo 4 : Contar os RLR’s para cada função de dados





Exemplo

Em uma aplicação de RH são cadastradas informações de funcionários

horistas e mensalistas, juntamente com informações de seus dependentes.

Existem atributos genéricos comuns a ambos os tipos de funcionários,

atributos específicos de horistas e atributos específicos de mensalistas.

Neste caso, o ALI “funcionário” possuirá 3 RLR’s:

Registro de Horista = atributos genéricos + específicos de horista

Registro de Mensalista = atributos genéricos + específicos de mensalista

Registro de Dependente = atributos de dependente (relação 1:n)


- 234 -






Subgrupos opcionais x obrigatórios

Existem dois tipos de subgrupos de DER’s que podem compor RLR’s:

opcionais

obrigatórios

Exemplo

Na aplicação de RH mencionada anteriormente,

os RLR’s “Horista” e “Mensalista” são obrigatórios,

enquanto que o subgrupo “Dependente” é opcional.


- 235 -



Regra Descrição

4.1 Contar 1 RLR para cada função de dados.

4.2 Contar 1 RLR adicional para:

- cada entidade associativa com atributos além das chaves;

- cada subtipo, a partir do segundo;

- entidade atributiva com relacionamento

diferente de 1:1 obrigatório.


- 236 -



Regra

4.1

Contar 1 RLR para cada função de dados.

Motivo

Por default, tem pelo menos 1 subgrupo de DER’s que constitui um RLR.


- 237 -



Regra

4.2

Contar 1 RLR adicional para:






- 238 -



Regra

4.2






Exemplo

Uma empresa mantém um cadastro de professores e um cadastro de cursos.

O valor-hora pago a um mesmo professor pode ser diferente para cada curso.

Haverá 3 entidades de dados, sendo duas independentes (Professor e Curso)

e uma associativa, que conterá, além das chaves, o valor-hora a ser pago a

cada professor específico em cada curso específico.

Portanto, esta entidade associativa tem atributo de negócio reconhecido pelo

usuário. Ela será agrupada no ALI Professor e este ALI terá 2 RLR’s.


- 239 -



Regra

4.2






Exemplos

Cliente pessoa física x cliente pessoa jurídica.

Funcionário horista x funcionário mensalista.

Nesses casos, existem atributos específicos exclusivos de cada subtipo.

Haverá 1 RLR para cada subtipo: o RLR default da regra 4.1 para o primeiro

subtipo e um ou mais RLR’s adicionais para cada subtipo a partir do segundo.


- 240 -



Regra

4.2







- 241 -



Regra

4.2






Entidade Atributiva

Entidade que descreve um ou mais atributos adicionais de uma outra entidade.


Entidades atributivas são entidades dependentes da entidade principal

(a verdadeira “dona” dos atributos) e por isso são agrupadas no mesmo ALI.

Porém, cada entidade atributiva que possua um relacionamento 1:1 opcional,

1:n ou m:n com a principal contribuirá com 1 RLR adicional para o ALI.


- 242 -



Regra

4.2






Exemplo

Em um sistema de RH a entidade “Dependente” é uma entidade atributiva que

tem um relacionamento 1,1:0,n com a entidade “Funcionário”.

Por ser uma entidade dependente da entidade “Funcionário”, ela é agrupada

no ALI “Funcionário” e, por ser uma entidade atributiva com relacionamento

diferente de 1:1 obrigatório com a entidade “dona” dos atributos, ela contribuirá

com 1 RLR adicional para o ALI “Funcionário”.


- 243 -



Dica

Caso não haja um modelo de dados disponível, examine cada grupo

repetitivo de dados e verifique se é ou não um RLR.

Exemplos

No caso de fatura contendo seção de cabeçalho com informações do cliente,

seguida de uma lista com informações dos itens vendidos (qtde, preço, etc.),

devem ser contados 2 RLR’s: cabeçalho + grupo de dados que se repete.

Entretanto, um caso de ocorrência de múltiplos grupos de DER’s tal como

{ano, mês e valor do orçamento}, mesmo constituindo um grupo repetitivo,

não é contado como um RLR, mas sim como 3 DER’s.

A diferença é que os meses do ano não são uma entidade de negócio,

enquanto que itens vendidos certamente o são !

Idem para dependentes de funcionário (são relevantes para o negócio).


- 244 -



Atenção

Um único atributo de negócio que se repete, como múltiplas contas bancárias

para um mesmo cliente, não constitui um grupo repetitivo e deve ser contado

como um DER, e não um RLR.


- 245 -

Etapas do Processo









- 246 -

Passo 5 : Determinar a complexidade funcional

para cada função de dados


Regra Descrição

5.1 Utilizar a tabela abaixo:

ALI e AIE Quantidade de DER’s

1 a 19 20 a 50 51 ou mais




e.

RL

R’s


- 247 -

Etapas do Processo









- 248 -

Passo 6 : Determinar o tamanho funcional

para cada função de dados


Regra Descrição



baixa média alta

ALI 7 10 15

AIE 5 7 10


- 249 -












- 250 -


Determinar o

escopo e a

fronteira da

contagem e

identificar

requisitos

funcionais

de usuário

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível


- 251 -








Saída Externa (SE)






- 252 -

Intenção Primária das Funções de Transação


Atualizar 1 ou mais ALI’s ou alterar o comportamento da aplicação.


Apresentar informações ao usuário.

Saída Externa (SE)

Apresentar informações ao usuário.



- 253 -

Intenção Primária das Funções de Transação


Ação

Tipo de Função de Transação

EE SE CE

Alterar o

comportamento

da aplicação

intenção

primária

pode

ocorrer

não

ocorre

Atualizar

1 ou mais

ALI’s

intenção

primária

pode

ocorrer

não

ocorre

Apresentar

informação

ao usuário

pode

ocorrer

intenção

primária

intenção

primária


- 254 -







Saída Externa (SE)







- 255 -





não altera o comportamento do sistema


Saída Externa (SE)



altera o comportamento do sistema




- 256 -







Saída Externa (SE)





dado derivado

Dado resultante de um

processamento que envolve

passos diferentes ou adicionais

à simples recuperação e

validação da informação obtida

das funções de dados.

ISO/IEC 20926-1:2009, definition 3.17

Exemplo: criar uma abreviatura

com base nas iniciais de um nome.



- 257 -

Saída Externa (SE)







- 258 -

Saída Externa (SE)





lógica de processamento

qualquer requisito especificamente solicitado pelo usuário para

completar um processo elementar, tal como validações, algoritmos ou

cálculos e leitura ou manutenção de uma função de dados.




- 259 -

Formas de Lógica de Processamento

Forma de Lógica de Processamento EE SE CE

1. Efetuar validações. pode pode pode

2. Efetuar cálculos matemáticos. pode deve* não pode

3. Converter valores equivalentes. pode pode pode

4. Filtrar e selecionar dados pode pode pode

5. Analisar condições para verificar quais se aplicam. pode pode pode

6.Atualizar pelo menos 1 ALI. deve* deve* não pode

7. Referenciar pelo menos 1 ALI ou AIE. pode pode deve

8. Recuperar dados ou informações de controle. pode pode deve

9.Criar dados derivados. pode deve* não pode

10. Alterar o comportamento da aplicação. deve* deve* não pode

11. Preparar e apresentar informações a usuário. pode deve deve

12. Receber dados ou informações de controle de fora da fronteira deve pode pode

13. Ordenar ou organizar grupos de dados. pode pode pode



- 260 -





Exemplo:

Quando um novo funcionário é incluído no sistema, a aplicação verifica a

validade de diversas informações, tais como:

verificar se o dígito verificador do CPF está correto;

verificar se a data de nascimento informada é válida (não aceitar 30/fev, 31/set, etc.);

verificar se o novo funcionário é maior de 18 anos;

verificar se o salário configurado é superior ao piso ou e inferior ao teto salarial

estabelecido para o cargo que foi informado.


- 261 -





Exemplo:

Telas, relatórios e gráficos que informam totais, percentuais, etc.

Atenção:

Nem sempre os valores calculados são apresentados ao usuário.

Exemplo:

considere um processo que emite a lista com os nomes dos 10 funcionários

que tiveram o maior índice de reclamações por cliente atendido;

embora o índice não seja exibido ao usuário, ele teve que ser calculado

internamente, durante a execução do processo, para que fosse possível

determinar quais os 10 funcionários a serem listados.


- 262 -





Exemplos:

Um processo elementar referencia taxas de câmbio do dólar para outras

moedas, sendo que a conversão é executada através da recuperação de

valores de tabelas, de modo que cálculos não são necessários.

Em lugar do valor do salário, um processo elementar exibe a faixa salarial

do funcionário, obtida por meio de uma tabela de limites das faixas.


- 263 -





Exemplo:

Para gerar uma lista de funcionários por atribuição, um processo elementar

compara o código da tarefa de uma atribuição para selecionar e listar os

funcionários com esta atribuição.

Uma tela de consulta permite que o usuário selecione somente os produtos

da linha de Informática, disponíveis no estoque da loja de Duque de Caxias.


- 264 -





Exemplo:

A lógica de processamento empregada por um processo elementar na

inclusão de um funcionário, que irá variar dependendo do funcionário ser

pago através de salário mensal ou horas trabalhadas.

Sempre que o país de nascimento do novo funcionário for diferente de Brasil,

o sistema passa a permitir que o número do passaporte seja preenchido em

lugar do número do RG.


- 265 -





Exemplos:

Ao ser cadastrado um novo funcionário, um processo elementar atualiza o

ALI “Funcionário” incluindo as informações do novo funcionário.

Ao emitir uma remessa de pagamento ao banco, um processo elementar

atualiza automaticamente um campo do ALI “Fatura” indicando que a fatura

correspondente foi paga.


- 266 -





Exemplos:

Ao incluir um funcionário, o AIE “moeda” é referenciado para usar a taxa de

câmbio do dólar correta, para determinar o valor da hora do funcionário em

dólares.

Para permitir que um usuário selecione uma dentre as filiais existentes em

uma empresa em uma caixa de seleção na tela, um processo elementar

recupera os nomes de todas as filiais armazenadas no ALI “Filial” que

tenham o campo “ativa” marcado como verdadeiro.


- 267 -





Exemplo:

Para exibir uma lista de faixas salariais possíveis, um processo elementar

recupera as faixas armazenadas em um ALI.

Um processo elementar permite que o administrador da aplicação visualize

parâmetros de controle, tais como:

o dia do mês em que o relatório mensal de vendas é emitido;

o prazo (em horas ou dias) a partir do qual uma reclamação não-atendida

é encaminhada por e-mail ao gerente do funcionário responsável;


- 268 -





Exemplo:

Para determinar (derivar) o código de registro de cada paciente, u sistema

hospitalar concatena as seguintes informações:

as 3 primeiras letras do último nome do paciente;

as 2 primeiras letras do primeiro nome do paciente;

um número sequencial de 2 dígitos, começando de “01”.

Por exemplo, a paciente Maria Aparecida da Silva recebe o código SILMA01.


- 269 -





Exemplo:

O comportamento do processo elementar de pagamento de funcionários é

alterado quando uma mudança é feita para pagá-los às sextas-feiras, a cada

duas semanas, em vez de pagá-los no 15º dia e no último dia do mês.


- 270 -





Exemplos:

Uma lista de clientes é formatada e apresentada ao usuário em uma tela.

Um relatório de vendas é impresso.

Um gráfico de acompanhamento em tempo real da cotação de uma

mercadoria é exibido em uma tela.


- 271 -





Exemplo:

Um usuário entra com várias informações para incluir uma ordem de compra

no sistema.

Um usuário cadastra um novo cliente no sistema.

Um usuário altera as configurações utilizadas na emissão periódica

automática do relatório consolidado de vendas.


- 272 -





Exemplo:

Uma tela de consulta de funcionários oferece opções para ordenar a lista

exibida pelo nome da filial, pelo nome do funcionário ou por outros campos.

Uma tela de registro de pedido de compra organiza as informações

existentes no cabeçalho da ordem no topo da tela e as informações

existentes no corpo da ordem na parte inferior da tela.

Um processo elementar que emite uma listagem de resultados de vendas

organiza e agrupa as informações por filial e por família de produto,

apresentando legendas e resultados parciais por filial e família.


- 273 -



Importante:

Um único processo elementar pode incluir múltiplas formas de lógica de

processamento.

Exemplo:

Um processo elementar que emite um relatório de vendas pode incluir:

validações

filtragem

cálculos matemáticos

atualização de ALI (registrando que o relatório foi emitido)

ordenação e organização de dados


- 274 -


















- 275 -

Etapas do processo de medição:

1. Identificar os processos elementares

2. Verificar a unicidade dos processo elementares

3. Classificar cada PE como função de transação

4. Contar os ALR’s para cada função de transação

5. Contar os DER’s para cada função de transação

6. Determinar a complexidade funcional para cada função de transação

7. Determinar o tamanho funcional para cada função de transação



- 276 -

Etapas:




4. Contar os ARL’s para cada função de transação






- 277 -

Passo 1 : Identificar os processos elementares

Regra Descrição

1.1 Compor e/ou decompor os Requisitos Funcionais de Usuário nas

menores unidades de atividade tais que cada uma delas: – seja significativa para o usuário

– constitua uma transação completa e autocontida

– deixe o “negócio” da aplicação contada em estado consistente

1.2 Identificar um Processo Elementar para cada atividade que satisfizer

todos os requisitos acima.



- 278 -


Regra

1.1

Compor e/ou decompor os Requisitos Funcionais de Usuário nas





Exemplo

Um requisito funcional de usuário pode especificar que o sistema deve

manter um cadastro de funcionários.

Este requisito deve ser decomposto nas menores unidades de atividade

significativas para o usuário que constituam transações completas e

autocontidas e que deixem a aplicação em um estado consistente.

Exemplos:

incluir novo funcionário consultar dados de funcionário

alterar dados de funcionário listar funcionários

excluir funcionário


- 279 -


Regra

1.1







- 280 -


Regra

1.1











- 281 -


Regra

1.1







- 282 -


Regra

1.1






autocontida

que não requeira nenhum passo de processamento anterior ou

subsequente para iniciar ou completar o(s) requisito(s) funcional(is)

de usuário que se propõe a cumprir.


completa

que processa toda a informação necessária para satisfazer o(s)

requisito(s) funcional(is) de usuário que se propõe a cumprir.


- 283 -


Regra

1.1






Transação completa e autocontida (exemplo)

Suponha um formulário de entrada de dados composto por uma sequência de 3 telas,

com um botão Continuar nas duas primeiras telas e um botão Gravar na última tela.

O preenchimento apenas da primeira tela, seguido do acionamento do botão

Continuar, não constitui uma transação completa e autocontida, visto que requer

processamento adicional para cumprir o requisito funcional de usuário.

Somente o preenchimento das 3 telas, seguido do acionamento do botão Gravar,

constituirá uma transação completa e autocontida.


- 284 -


Regra

1.1







- 285 -


Regra

1.1






estado consistente

Ponto no qual todo o processamento foi

executado e o requisito funcional de usuário

foi plenamente satisfeito, não havendo mais

nada a fazer.



- 286 -


Regra

1.1






Estado consistente (exemplo)

Suponha que o requisito funcional de usuário seja imprimir um cheque e

marcar a respectiva conta como paga.

Neste caso, se o cheque for impresso sem marcar a respectiva conta como

paga, ou se a conta for marcada sem imprimir o respectivo cheque, o

sistema ficará em um estado inconsistente.


- 287 -


Regra

1.2

Identificar um Processo Elementar para cada atividade que satisfizer

todos os requisitos acima.


Cada atividade que tenha significado para o usuário e que

seja completa e autocontida, deixando a aplicação em um

estado consistente, será identificada como um processo elementar.


- 288 -

Etapas:


2. Verificar a unicidade dos processos elementares








- 289 -

Passo 2 : Verificar unicidade dos processos elementares

Regra Descrição

2.1 Considerar como 1 único Processo Elementar aqueles que tenham: – mesmo conjunto de DER’s

– mesmo conjunto de ALR’s

– mesmo conjunto de lógicas de processamento

2.2 Não dividir um Processo Elementar com múltiplas formas de

processamento em múltiplos Processos Elementares.



- 290 -






Observação

Embora expostas aqui em formato sequencial, as atividades de

medição funcional são iterativas.

Por exemplo: a verificação de unicidade descrita aqui no passo 2

requer a contagem de ALR’s e de DER’s descrita nos passos 4 e 5.


- 291 -






Observação

Um mesmo processo elementar pode apresentar pequenas variações nos

DER’s e ALR’s, bem como múltiplas alternativas, variações e ocorrências

dos 13 tipos de processamento lógico mencionados anteriormente.

Exemplo:

Um processo elementar para incluir novo funcionário pode ter variações de

DER e de lógica de processamento, dependendo de o novo funcionário ter

dependentes ou não.

Mesmo assim trata-se de 1 único PE, e não um PE para funcionários com

dependentes e outro PE para funcionários com dependentes.


- 292 -


2.2 Não dividir um Processo Elementar com múltiplas formas de

processamento em múltiplos Processos Elementares.


Exemplo

Considere um processo elementar que recebe e valida informações do

usuário para, com base nessas informações, recuperar dados de um ALI,

filtrar esses dados e organizá-los para exibição ao usuário.

Embora execute múltiplas formas de lógica de processamento, trata-se de

1 único processo elementar.

Ele não poderia ser dividido em múltiplos PE’s porque as atividades isoladas

de validação, filtragem, etc. não constituiriam transações completas.


- 293 -

Etapas:










- 294 -

Passo 3 : Classificar cada PE como função de transação

Regra Descrição

3.1 Identificar a intenção primária de cada PE dentre uma das seguintes: – atualizar um ou mais ALI’s ou alterar o comportamento da aplicação;

– apresentar informação ao usuário.

3.2 Classificar como EE os Processos Elementares que: – têm como intenção primária atualizar ALI’s ou alterar o comportamento da aplicação;

– incluem lógica de processamento para aceitar dados ou informações de controle

que entram pela fronteira da aplicação;

3.3 Classificar como SE os Processos Elementares que: – têm como intenção primária apresentar informações ao usuário;

– incluem pelo menos uma dentre as seguintes lógicas de processamento:

efetuar cálculos matemáticos criar dados derivados

alterar o comportamento da aplicação atualizar 1 ou mais ALI’s

3.4 Classificar como CE os Processos Elementares que: – têm como intenção primária apresentar informações ao usuário;

– não incluem nenhuma das lógicas de processamento requeridas para SE’s.



- 295 -


3.1 Identificar a intenção primária de cada PE dentre uma das seguintes: – atualizar um ou mais ALI’s ou alterar o comportamento da aplicação;

– apresentar informação ao usuário.



- 296 -


3.2 Classificar como EE os Processos Elementares que: – têm como intenção primária atualizar ALI’s ou alterar o comportamento da aplicação;

– incluem lógica de processamento para aceitar dados ou informações de controle

que entram pela fronteira da aplicação;



- 297 -


3.3 Classificar como SE os Processos Elementares que: – têm como intenção primária apresentar informações ao usuário;

– incluem pelo menos uma dentre as seguintes lógicas de processamento:

efetuar cálculos matemáticos criar dados derivados

alterar o comportamento da aplicação atualizar 1 ou mais ALI’s



- 298 -


3.4 Classificar como CE os Processos Elementares que: – têm como intenção primária apresentar informações ao usuário;

– não incluem nenhuma das lógicas de processamento requeridas para SE’s.



- 299 -

Etapas:




4. Contar os ALR’s para cada função de transação






- 300 -

Passo 4 : Contar ALR’s para cada função de transação

Regra Descrição

4.1 Contar 1 ALR para cada ALI lido ou mantido pelo processo elementar.

4.2 Contar 1 ALR para cada AIE lido pelo processo elementar.



- 301 -


4.1 Contar 1 ALR para cada ALI lido ou mantido pelo processo elementar.



- 302 -


4.2 Contar 1 ALR para cada AIE lido pelo processo elementar.



- 303 -

Etapas:










- 304 -

Passo 5 : Contar DER’s para cada função de transação

Regra Descrição

5.1 Contar 1 DER para cada atributo único, reconhecível pelo usuário e não-

repetido, que cruze a fronteira (entrando ou saindo) durante o processamento.

5.2 Acrescentar 1 (e somente 1) DER no caso de a função de transação envolver o

envio de 1 ou mais mensagens de resposta (confirmação, erro, etc.).

5.3 Acrescentar 1 DER pela capacidade de o usuário iniciar a ação do processo

elementar (apenas 1 DER, mesmo havendo múltiplos meios de iniciação).

5.4 Não considerar os seguintes itens como DER: literais tais como títulos de relatórios, legendas de telas e de painéis, etc.

estampas geradas pela aplicação, tais como data e hora

variáveis de paginação, números de página e atributos de posicionamento

recursos de auxílio à navegação (“anterior”, “próximo”, “primeiro”, “último”, etc.)

atributos gerados dentro da fronteira e gravados em ALI sem cruzar a fronteira

atributos recuperados de ALI ou AIE e usados no processamento sem cruzar a fronteira



- 305 -


5.1 Contar 1 DER para cada atributo único, reconhecível pelo usuário e não-

repetido, que cruze a fronteira (entrando ou saindo) durante o processamento.



- 306 -


5.2 Acrescentar 1 (e somente 1) DER no caso de a função de transação envolver o

envio de 1 ou mais mensagens de resposta (confirmação, erro, etc.).



- 307 -


5.3 Acrescentar 1 DER pela capacidade de o usuário iniciar a ação do processo

elementar (apenas 1 DER, mesmo havendo múltiplos meios de iniciação).



- 308 -


5.4 Não considerar os seguintes itens como DER: literais tais como títulos de relatórios, legendas de telas e de painéis, etc.

estampas geradas pela aplicação, tais como data e hora

variáveis de paginação, números de página e atributos de posicionamento

recursos de auxílio à navegação (“anterior”, “próximo”, “primeiro”, “último”, etc.)

atributos gerados dentro da fronteira e gravados em ALI sem cruzar a fronteira

atributos recuperados de ALI ou AIE e usados no processamento sem cruzar a fronteira



- 309 -

Etapas:










- 310 -


para cada função de transação

Regra Descrição

6.1 Para EE’s, utilizar a tabela abaixo:

EE Quantidade de DER’s

1 a 4 5 a 15 16 ou mais


2 baixa média alta


e. A

LR

’s



- 311 -



Regra Descrição

6.2 Para CE’s, utilizar a tabela abaixo:

CE Quantidade de DER’s

1 a 5 6 a 19 20 ou mais




e. A

LR

’s



- 312 -



Regra Descrição

6.3 Para SE’s, utilizar a tabela abaixo:

SE Quantidade de DER’s

1 a 5 6 a 19 20 ou mais




e. A

LR

’s



- 313 -

Etapas:










- 314 -

Passo 7 : Determinar o tamanho funcional


Regra Descrição



baixa média alta

EE 3 4 6

CE 3 4 6

SE 4 5 7



- 315 -












- 316 -


Determinar o

escopo e a

fronteira da

contagem e

identificar

requisitos

funcionais

de usuário

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível


- 317 -


Tipos de Contagem

A forma de calcular o tamanho funcional depende do tipo de contagem

que está sendo feita, que pode ser:

Contagem de Projeto de Desenvolvimento

Contagem Inicial da Aplicação (após desenvolvimento)

Contagem de Projeto de Melhoria

Atualização da Contagem da Aplicação (após melhoria)


Tipos de Contagem


- 318 -



iniciado



- 319 -

Cont. Estimada

Projeto de

Desenvolvimento




iniciado

Tipos de Contagem




- 320 -

Cont. Estimada

Projeto de

Desenvolvimento

projeto concluído




projeto de


Tipos de Contagem




- 321 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

projeto concluído




contagem final desenvolvimento projeto de


Tipos de Contagem




- 322 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Contagem

Aplicação

(baseline)

projeto concluído







Tipos de Contagem





- 323 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Contagem

Aplicação

(baseline)

projeto concluído








Tipos de Contagem




- 324 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Cont. Estimada

Projeto de

Melhoria

Contagem

Aplicação

(baseline)

projeto concluído










Tipos de Contagem




projeto concluído

- 325 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Cont. Estimada

Projeto de

Melhoria

Contagem

Aplicação

(baseline)

projeto concluído











Tipos de Contagem




- 326 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Cont. Estimada

Projeto de

Melhoria

Contagem Final

Projeto de

Melhoria

Contagem

Aplicação

(baseline)

projeto concluído

projeto concluído








contagem final melhoria




Tipos de Contagem




- 327 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Cont. Estimada

Projeto de

Melhoria

Contagem Final

Projeto de

Melhoria

Contagem

Aplicação

(baseline)

projeto concluído

projeto concluído









inicializar

atualizar


iniciado


Tipos de Contagem




- 328 -

Cont. Estimada

Projeto de

Desenvolvimento

Contagem Final

Projeto de

Desenvolvimento

Cont. Estimada

Projeto de

Melhoria

Contagem Final

Projeto de

Melhoria

Contagem

Aplicação

(baseline)

projeto concluído

projeto concluído









inicializar

atualizar


iniciado


Tipos de Contagem




- 329 -


Fórmulas para cada Tipo de Contagem






- 330 -








- 331 -


Fórmula para Projeto de Desenvolvimento:

DFP = ADD + CFP

onde:

DFP = pontuação do projeto de desenvolvimento Development project Function Point count

ADD = pontuação das funções entregues ao usuário

ADDed functions

CFP = pontuação das funcionalidades de conversão

Conversion functionality Function Point count


- 332 -


Fórmula para Contagem Inicial de Aplicação:

AFP = ADD

onde:

AFP = pontuação da aplicação Application Function Point count

ADD = pontuação das funções entregues ao usuário

ADDed functions


- 333 -


Exemplo: Sistema de Registro de Visitantes


Registrar informações a respeito de cada visitante que entrar na empresa (XX informações significativas para o usuário + botão de ação + mensagens de confirmação/erro)

Uma das informações registradas é o nome do funcionário visitado, que deverá

ser selecionado em uma lista obtida de tabela mantida pelo sistema de RH.

Emitir relatório de visitantes (YY informações significativas para o usuário + botão de ação)

Emitir relatório de funcionários visitados (ZZ informações significativas para o usuário + botão de ação)


- 334 -



Requisitos de Conversão de Dados

Migrar para o novo sistema os registros de visitantes antigos, gravados em

planilhas Excel, convertendo o nome do funcionário visitado em matrícula, com

auxílio da tabela de funcionários mantida pelo sistema de RH. (YY informações significativas para o usuário)

Gerar listagem com registros que não puderem ser migrados. (YY informações significativas para o usuário)


- 335 -



Projeto de Desenvolvimento

Função Novas (ADD) Tipo DER RLR ALR Complex. PF

Visitante ALI 10 1 - baixa 7

Visitante – registrar visitante EE 12 - 2 média 4

Visitante – emitir relatório de visitantes SE 11 - 2 média 5

Visitante – emitir relatório de visitados SE 11 - 2 média 5

Funcionário AIE 2 1 - baixa 5

Funcionário – listar na caixa de seleção CE 3 - 1 baixa 3

TOTAL ADD 29


- 336 -











TOTAL ADD 29

Funcionalidades de conversão ?


- 337 -











TOTAL ADD 29

Funcionalidades de Conversão (CFP) Tipo DER RLR ALR Complex. PF

Funcionário – migrar das planilhas Excel EE 10 - 2 média 4

TOTAL CFP 4


- 338 -




Contagem do Projeto de Desenvolvimento

DFP = ADD + CFP = 29 + 4 = 33

Contagem Inicial da Aplicação

AFP = ADD = 29


- 339 -








- 340 -


Fórmula para Projeto de Melhoria:

EFP = ADD + CHGA + CFP + DEL

onde:

EFP = pontuação do projeto de melhoria Enhancement project Function Point count

ADD = pontuação das funções adicionadas

ADDed functions

CHGA = pontuação das funções modificadas após a melhoria

CHanGed functions (After enhancement)

CFP = pontuação das funcionalidades de conversão

Conversion functionality Function Point count

DEL = pontuação das funções excluidas

DELeted functions


- 341 -


Fórmula para Contagem de Aplicação após Melhoria:

AFPA = AFPB + ADD + CHGA – CHGB – DEL

onde:

AFPA = pontuação da aplicação após a melhoria Application Function Point count (After enhancement)

AFPB = pontuação da aplicação antes da melhoria Application Function Point count (Before enhancement)

ADD = pontuação das funções adicionadas

ADDed functions

CHGA = pontuação das funções modificadas após a melhoria

CHanGed functions (After enhancement)

CHGB = pontuação das funções modificadas antes da melhoria

CHanGed functions (Before enhancement)

DEL = pontuação das funções excluidas

DELeted functions


- 342 -



Requisitos Funcionais de Usuário (Projeto de Manutenção)

Passar a incluir, entre as informações a serem registradas no sistema e

exibidas no relatório de visitantes, o nome do prédio onde foi feita a visita.

O nome do prédio deve ser selecionado de uma lista obtida a partir de tabela

mantida pelo sistema de Ativo Fixo

Desativar o relatório de visitados.


- 343 -



Requisitos de Conversão de Dados (Projeto de Manutenção)

Na ocasião da implementação da novo campo contendo o nome do prédio, os

registros pré-existentes deverão ter esse campo preenchido automaticamente

com o nome “PASTEUR”, que é o nome do prédio onde fica a matriz da

empresa.


- 344 -



Projeto de Melhoria

Aplicação Antes da Melhoria (AFPB) Tipo DER RLR ALR Complex. PF







TOTAL AFPB 29


- 345 -



Projeto de Melhoria








TOTAL AFPB 29

Funcionalidades de conversão ?


- 346 -



Projeto de Melhoria








TOTAL AFPB 29

Não há ! ! !

Preenchimento com valor fixo não é PE (não atravessa a fronteira)


- 347 -



Projeto de Melhoria

Funcionalidades Adicionadas (ADD) Tipo DER RLR ALR Complex. PF







Prédio AIE 2 1 - baixa 5

Prédio – listar na caixa de seleção CE 3 - 1 baixa 3

TOTAL ADD 8


- 348 -



Projeto de Melhoria

Funções a Modificar (CHGB) Tipo DER RLR ALR Complex. PF









TOTAL CHGB 16


- 349 -



Projeto de Melhoria

Funções Modificadas (CHGA) Tipo DER RLR ALR Complex. PF


Visitante – registrar visitante EE 13 - 3 alta 6







TOTAL CHGA 18


- 350 -



Projeto de Melhoria

Funções Desativadas/Excluidas (DEL) Tipo DER RLR ALR Complex. PF









TOTAL DEL 5


- 351 -



Projeto de Melhoria

Aplicação Após Melhoria (AFPA) Tipo DER RLR ALR Complex. PF









TOTAL AFPA 34


- 352 -




Contagem do Projeto de Melhoria

EFP = ADD + CHGA + CFP + DEL = 8 + 18 + 0 + 5 = 31

Atualização da Contagem da Aplicação Após Melhoria

AFPA = AFPB + ADD + CHGA – CHGB – DEL

= 29 + 8 + 18 – 16 – 5 = 34


- 353 -












- 354 -


Determinar o

escopo e a

fronteira da

contagem e

identificar

requisitos

funcionais

de usuário

Medir

funções de

dados

Medir

funções de

transação

Calcular o

tamanho

funcional

Documentar

e reportar

Reunir a

documentação

disponível


- 355 -

Módulo 03

Estudos de Caso

( os estudos de caso são dados em sala de aula )


- 356 -

Módulo 04

Tópicos Complementares em APF


- 357 -







- 358 -







- 359 -







- 360 -

Consiste em estimar o tamanho funcional por meio de um

processo simplificado de contagem de pontos de função.

É empregada geralmente com os seguintes objetivos:

• Estimar o tamanho funcional em curtíssimo prazo e/ou com baixo

consumo de horas de especialistas;

• Estimar o tamanho funcional de uma aplicação ou projeto para o

qual ainda não existam muitas informações disponíveis.

– Exemplo: para orçar projeto de desenvolvimento ou manutenção em

seus estágios iniciais de concepção, antes de mesmo de existir um

detalhamento de seus requisitos funcionais.



- 361 -

A NESMA reconhece três tipos de medição funcional:

• Contagem DETALHADA método IFPUG padrão

• Contagem ESTIMATIVA

• Contagem INDICATIVA

Os métodos antecipativos visam possibilitar a medição

funcional nos momentos iniciais do ciclo de vida de um

sistema, quando há poucas informações disponíveis.

A contagem indicativa da NESMA é também conhecida

como método holandês.

métodos antecipativos



- 362 -

Contagem DETALHADA

A contagem detalhada é o método usual de contagem de medição

funcional definido pelo IFPUG, que consiste em:

1. Identificar todos os tipos de função (ALI, AIE, EE, CE e SE).

2. Determinar a complexidade (baixa/média/alta) para todos os tipos de

função (ALI, AIE, EE, CE e SE).

3. Calcular o total de pontos de função.

A contagem detalhada requer a identificação e a contagem dos

DET’s, RET’s e FTR’s para a determinação da complexidade de

todas as funções.



- 363 -

Contagem ESTIMATIVA

A contagem estimativa é um método simplificado de medição

funcional que consiste em:

1. Identificar todos os tipos de função (ALI, AIE, EE, CE e SE).

2. Considerar complexidade baixa para todas as funções

de dados (ALI e AIE).

3. Considerar complexidade média para todas as funções transacionais

(EE, CE e SE).

4. Calcular o total de pontos de função.

A diferença em relação à contagem detalhada é que

a complexidade das funções é pré-definida.

Desnecessário identificar e contar DET’s, RET’s e FTR’s.



- 364 -

Fundamentação

A contagem estimativa se baseia em médias de mercado apuradas

no ISBG Benchmark :

Tipo de

Função

Média

de PF

Complex.

Baixa

Complex.

Média

Complex.

Alta

ALI 7,4 7 10 15

AIE 5,5 5 7 10

EE 4,3 3 4 6

SE 5,4 4 5 7

CE 3,8 3 4 6

Fonte: ISBSG Benchmark release 5

Contagem ESTIMATIVA



- 365 -

A contagem indicativa é um método simplificado de

medição funcional que consiste em:

1. Identificar somente as funções de dados (ALI e AIE).

2. Calcular o total de pontos de função considerando

35 pontos para cada ALI e 15 pontos para cada AIE.

A diferença em relação à contagem estimativa é que as

funções transacionais não precisam ser identificadas.

Contagem INDICATIVA



- 366 -

Fundamentação

A contagem indicativa se baseia nas médias de mercado

apuradas no ISBSG Benchmark considerando que :

• a cada ALI estão associadas, em média, três EE’s (adicionar,

alterar e excluir dados), 1 CE e 2 SE’s ;

• a cada AIE estão associadas, em média, 1 CE e 1 SE.

Desta forma, pontua-se :

• para ALI: 7,4 (ALI) + 3 x 4,3 (EE) + 1 x 3,8 (CE) + 2 x 5,4 (SE) 35

• para AIE: 5,5 (AIE) + 1 x 3,8 (CE) + 1 x 5,4 (SE) 15

Contagem INDICATIVA



- 367 -

Quanto menos detalhado o método de contagem, menos

informação necessária para estimar o tamanho funcional.

Método de Contagem Informação Necessária

Contagem Detalhada

( IFPUG )

Identificar funções de dados

Identificar funções de transação

Identificar e contar DET’s, RET’s e FTR’s.

Contagem Estimativa Identificar funções de dados

Identificar funções de transação

Contagem Indicativa Identificar funções de dados

Quadro Comparativo



- 368 -

Requisitos de Usuário:

O usuário deseja manter dados de cliente e produto e referenciar

dados de fornecedor.

A informação acima é suficiente para uma contagem indicativa !

Funções de Dados Identificadas:

ALI’s: Cliente e Produto

AIE’s: Fornecedor

Exemplo de Contagem INDICATIVA



- 369 -


O usuário deseja manter dados de cliente e produto e referenciar

dados de fornecedor.

Contagem Indicativa:

Função de Dados

Tipo de

Função

Pontuação

(pré-definida)

Produto ALI 35

Cliente ALI 35

Fornecedor AIE 15

Indicativo do tamanho funcional 85 pf

Exemplo de Contagem INDICATIVA



- 370 -


É necessário manter um cadastro de clientes, com funcionalidade para

adicionar, alterar, excluir e visualizar dados, do qual poderão ser emitidos 4

diferentes tipos de relatórios.

É necessário manter um cadastro de produtos, com funcionalidade para

adicionar, alterar, excluir e visualizar dados, do qual poderá ser emitido um

relatório.

É necessário consultar dados dos fornecedores dos produtos por meio de

seu número e emitir um relatório com totalização de dados de

fornecedores.

As informações acima permitem uma contagem estimativa !

Exemplo de Contagem ESTIMATIVA



- 371 -

Função de Dados ou Transacional Tipo de Função Complexidade Pontuação Cliente ALI Baixa 7

Produto ALI Baixa 7

Fornecedor AIE Baixa 5

Cliente – incluir EE Média 4

Cliente – alterar dados EE Média 4

Cliente – excluir EE Média 4

Cliente – consultar CE Média 4

Cliente – relatório 1 SE Média 5




Produto – incluir EE Média 4

Produto – alterar dados EE Média 4

Produto – excluir EE Média 4

Produto – consultar CE Média 4

Produto – relatório 5 SE Média 5

Fornecedor – consultar CE Média 4

Fornecedor – relatório 6 SE Média 5

Estimativa do tamanho funcional 85 fp

Exemplo de Contagem ESTIMATIVA



- 372 -

Para efetuar uma medição funcional por meio da contagem

detalhada de pontos de função segundo o padrão IFPUG, é

necessário que esteja definido o detalhamento dos campos de dados

dos arquivos lógicos, das telas e dos relatórios previstos no projeto.

De posse dessa informação, pode ser avaliada a complexidade real

de cada uma das funções de dados e transacionais identificadas,

como no exemplo a seguir . . .

Detalhando a Contagem ESTIMATIVA . . .



- 373 -

Função de Dados ou Transacional Tipo de Função Complexidade Pontuação Cliente ALI Média 10

Produto ALI Baixa 7

Fornecedor AIE Baixa 5

Cliente – incluir EE Alta 6

Cliente – alterar dados EE Média 4

Cliente – excluir EE Baixa 3

Cliente – consultar CE Baixa 3

Cliente – relatório 1 SE Baixa 4


Cliente – relatório 3 SE Baixa 4

Cliente – relatório 4 SE Alta 7

Produto – incluir EE Média 4

Produto – alterar dados EE Média 4

Produto – excluir EE Baixa 3

Produto – consultar CE Média 4

Produto – relatório 5 SE Média 5

Fornecedor – consultar CE Baixa 3

Fornecedor – relatório 6 SE Média 5

Estimativa do tamanho funcional 86 fp

Possível Contagem DETALHADA



- 374 -

No exemplo visto, as medições indicativa e estimativa forneceram

valores muito próximos ao resultado da medição detalhada.

Mas nem sempre isso ocorre !

Até que ponto podemos confiar em medições antecipativas

(estimativa e indicativa) ???

Na prática, quanto menor o nível de detalhamento na medição,

menor é a exatidão da medida.

Os gráficos a seguir mostram os resultados de um levantamento

comparativo das medições indicativa, estimativa e detalhada,

realizado pela NESMA, que envolveu de 100 projetos . . .

Detalhamento X Precisão da Medida



- 375 -

Estimativa x Detalhada



- 376 -

Indicativa x Detalhada



- 377 -







- 378 -

Muito Obrigado !

GQS 607 Métricas de Softwareheraldo/gqs607_slides.pdf · GQS 607 – Métricas de Software Prof....

Documents

Transcript of GQS 607 Métricas de Softwareheraldo/gqs607_slides.pdf · GQS 607 – Métricas de Software Prof....