ponto de funcao

53
Departamento de Computação Trabalho de Conclusão de Curso THEO IGNEZ PAVAN O Uso de Análise de Pontos por Função no Planejamento de Processo de Desenvolvimento de Software Londrina 2004

Upload: maurynho

Post on 16-Feb-2015

35 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Ponto de Funcao

Departamento de Computação Trabalho de Conclusão de Curso

THEO IGNEZ PAVAN

O Uso de Análise de Pontos por Função no Planejamento de Processo de Desenvolvimento de Software

Londrina 2004

Page 2: Ponto de Funcao

THEO IGNEZ PAVAN

O Uso de Análise de Pontos por Função no Planejamento de Processo de Desenvolvimento de

Software

Trabalho de conclusão de curso obrigatório desenvolvido durante o 4o ano do Curso de Graduação em Ciência da Computação co-mo requisito parcial à obtenção do título de Bacharel. Orientador: Rodolfo Miranda de Barros

2004

Page 3: Ponto de Funcao

THEO IGNEZ PAVAN

O Uso de Análise de Pontos por Função no Planejamento de Processo de Desenvolvimento de

Software

COMISSÃO EXAMINADORA

____________________________________ Prof. Eduardo Cotrin Teixeira UEL

____________________________________

Prof. Esio Dolci UEL

____________________________________

Prof. Rodolfo Miranda de Barros UEL

Londrina, ___ de ___________ de 2004

Page 4: Ponto de Funcao

DEDICATÓRIA

Dedico este trabalho a Deus, que me deu forças, e a meus pais, sem os quais este não seria possível.

Page 5: Ponto de Funcao

RESUMO

Este presente trabalho descreve a importância do planejamento no processo de desenvolvi-

mento de software e por que é necessário estimar durante essa atividade. Mostra também o

conceito de métricas de software, com ênfase na análise de pontos por função. Além disso,

mostra como a ferramenta APF desenvolvida no estágio pode auxiliar no processo de desen-

volvimento de software.

ABSTRACT

This present work describes about the importance of planning in the software development

process and why is necessary to estimate during this activity. It shows the conceit of soft-

ware's metrics, with emphasis in function points analysis. In addition to that, it shows how

APF tools developed can help in the software development process.

Page 6: Ponto de Funcao

Palavras-chave: Análise de Pontos por Função, Métricas Funcionais, Planejamento de Soft-

ware.

Page 7: Ponto de Funcao

SUMÁRIO

1 INTRODUÇÃO...............................................................................................................11

2 A CRISE DO SOFTWARE E ENGENHARIA DE SOFTWARE.............................13

3 PLANEJAMENTO DE PROJETO DE SOFTWARE................................................15

4 MÉTRICAS E MEDIÇÕES DE SOFTWARE............................................................17

4.1 MÉTRICAS DO PRODUTO ....................................................................................18 4.2 MÉTRICAS DO PROCESSO...................................................................................19 4.3 MÉTRICAS DE PRODUTIVIDADE E QUALIDADE DE SOFTWARE E MÉTRICAS TÉCNICAS......................................................................................................19 4.4 MÉTRICAS ORIENTADAS AO TAMANHO ........................................................19 4.5 MÉTRICAS ORIENTADAS A FUNÇÃO ...............................................................20

5 MÉTRICAS FUNCIONAIS – ANÁLISE DE PONTOS POR FUNÇÃO .................21

5.1 IFPUG.......................................................................................................................21 5.2 NESMA ....................................................................................................................22 5.3 MARK II ...................................................................................................................22 5.4 COSMIC – FFP.........................................................................................................22 5.5 IBSG .........................................................................................................................23

6 ANÁLISE DE PONTOS POR FUNÇÃO NO BRASIL ..............................................24

6.1 BFPUG .....................................................................................................................25

7 PROCESSO DE CONTAGEM – ANÁLISE DE PONTOS POR FUNÇÃO............28

7.1 DETERMINAÇÃO DO TIPO DE CONTAGEM.....................................................28 7.1.1 Contagem de um projeto de desenvolvimento..................................................29 7.1.2 Contagem de um projeto de melhoria ..............................................................29 7.1.3 Contagem de uma aplicação (ou baseline) ......................................................29

7.2 O ESCOPO DA CONTAGEM E A FRONTEIRA DA APLICAÇÃO .....................29 7.3 FUNÇÕES DO TIPO DADO....................................................................................29

7.3.1 Arquivo Lógico interno.....................................................................................30 7.3.2 Arquivo de interface externa ............................................................................31

7.4 FUNÇÕES DO TIPO TRANSAÇÃO.......................................................................32 7.4.1 Entrada Externa................................................................................................33 7.4.2 Saída Externa....................................................................................................34 7.4.3 Consulta Externa ..............................................................................................35

7.5 PONTOS POR FUNÇÃO NÃO-AJUSTADOS .......................................................37 7.6 FATOR DE AJUSTE................................................................................................37 7.7 PONTOS POR FUNÇÃO AJUSTADOS .................................................................38

7.7.1 Cálculo para projeto de Desenvolvimento.......................................................38 7.7.2 Cálculo para projeto de Melhoria ....................................................................39 7.7.3 Cálculo para Aplicação ....................................................................................39

8 ESTIMATIVAS ..............................................................................................................41

8.1 MÉTODO DELPHI .................................................................................................41 8.2 MÉTODO WIDEBAND-DELPHI (BOEHM) .........................................................41

Page 8: Ponto de Funcao

8.3 MÉTODO PUTMAN................................................................................................41 8.4 MODELO COCOMO E COCOMO II......................................................................41 8.5 ANÁLISE DE PONTOS POR FUNÇÃO .................................................................42

9 NORMAS E PADRÕES .................................................................................................44

9.1 PADRÃO ISO...........................................................................................................44 9.2 CMM.........................................................................................................................45

10 FERRAMENTA APF.................................................................................................47

10.1 FUNCIONALIDADES.............................................................................................47 10.2 COMO FOI DESENVOLVIDA...............................................................................49 10.3 REQUISITOS MÍNIMOS DE FUNCIONAMENTO...............................................49

11 CONCLUSÃO.............................................................................................................50

REFERÊNCIAS......................................................................................................................51

Page 9: Ponto de Funcao

LISTA DE TABELAS

Tabela 1 – Métricas Orientadas ao Tamanho .......................................................................... 20

Tabela 2 - Métricas primitivas utilizadas para medir a qua lidade dos processos de software..24

Tabela 3 – Métricas primitivas utilizadas para medir a produtividade dos processos de softwa-

re ............................................................................................................................................. 25

Tabela 4 – Exames CFPS Realizados pelo BFPUG ............................................................... 26

Tabela 5 – Países com maiôs número de CFPS ...................................................................... 27

Tabela 6 – Complexidade ALI ................................................................................................ 30

Tabela 7 – Pontos por Função ALI ......................................................................................... 31

Tabela 8 – Complexidade AIE ................................................................................................ 32

Tabela 9 – Pontos por Função AIE ......................................................................................... 32

Tabela 10 – Complexidade EE ............................................................................................... 33

Tabela 11 – Pontos por Função EE ......................................................................................... 34

Tabela 12 – Complexidade SE ................................................................................................ 35

Tabela 13 – Pontos por Função SE ......................................................................................... 35

Tabela 14 – Complexidade CE ............................................................................................... 36

Tabela 15 – Pontos por Função CE ......................................................................................... 36

Tabela 16 – Níveis de Influência ............................................................................................ 38

Tabela 17 – Linguagens de Programação ............................................................................... 43

Tabela 18 – Níveis do modelo CMM ...................................................................................... 45

Tabela 19 – Áreas chaves de cada nível .................................................................................. 46

Page 10: Ponto de Funcao

LISTA DE FIGURAS

Figura 1 - Fases do processo de desenvolvimento de software ................................................15 Figura 2 - Classificação das Métricas de Software...................................................................18 Figura 3 - Métricas primitivas utilizadas para medir a qualidade e produtividade dos

processos de software. ......................................................................................................25 Figura 4 - Evolução da Quantidade de CFPS Brasileiros .........................................................27 Figura 5 - Processo de Contagem.............................................................................................28 Figura 7 - Tela Principal Ferramenta APF ...............................................................................47 Figura 8 - Tela Pontos por Função Não-Ajustados ..................................................................48 Figura 9 - Tela Pontos por Função Ajustados ..........................................................................48 Figura 10 - Funcionamento da Ferramenta APF ......................................................................49

Page 11: Ponto de Funcao

LISTA DE ABREVIATURAS E SIGLAS

APF Análise de Pontos por Função

ALI Arquivo Lógico Interno

AIE Arquivo de Interface Externa

BFPUG Brazilian Function Point Users Group

CE Consulta Externa

CFPS Certificação de especialista em pontos por função

CGS Características gerais de sistema

COSMIC Common Software Measurement International Consortium

CPM Counting Pratices Manual

EE Entrada Externa

FFP Full Function Points

FSM Functional Size Measurement

IBSG International Software Benchmarking Standards Group

IFPUG International Function Point Users Group

NESMA Netherlands Software Metrics Users Association

PF Pontos por Função

SE Saída Externa

VAF Value Adjustment Factor

Page 12: Ponto de Funcao

11

1 INTRODUÇÃO

O trabalho de conclusão de curso (TCC) tem como tema a importância do

planejamento para a obtenção de qualidade no processo de desenvolvimento de software, e a

importância de se estimar durante a fase de planejamento. O trabalho introduz várias formas

de métricas e métodos de estimativa de software, dando ênfase à medição funcional de tama-

nho, ou seja, a Análise de Pontos por Função.

Grande parte dos problemas que ocorre no desenvolvimento de softwares é

causada pela falta de um processo de desenvolvimento do software bem definido, originando

erros de estimativas de prazos e custos, falta de controle do processo, menor qualidade do

produto final, pouca produtividade, inexistência de um processo repetível e vários outros pro-

blemas.

Se as empresas já encontram dificuldade na definição do processo de desen-

volvimento, é normal ainda encontrem dificuldades nas atividades de planejamento e gerenc i-

amento de projeto de software. Para que seja possível realizar essas atividades no processo de

desenvolvimento de software, necessita-se, entre outros pré-requisitos, a determinação do ta-

manho do software. E esta tarefa aparentemente simples acaba se mostrando difícil de ser

realizada.

Há vários métodos de medição de software como os baseados na quantidade

de linhas do código fonte dos programas e muitos outros métodos de medidas derivadas das

características técnicas do software. Ambos tipos não são considerados satisfatórios, pois não

podem ser aplicados no início do processo de desenvolvimento do software ou são pouco

precisos.

O conceito de Medição Funcional de Tamanho (Functional Size Measure-

ment - FSM) ultrapassa essas limitações, deixando de medir o software como implementado,

para medir o tamanho, nos termos das funções requeridas pelo usuário. A contagem dos pon-

tos de função é realizada com base em cinco tipos de componentes de software: arquivos ex-

ternos, arquivos internos, entradas, saídas e consultas. Esses termos possuem um sentido es-

pecífico na Análise de Pontos por Função, e a sua identificação e classificação exigem um es-

pecialista.

Segundo AZEVEDO (2003) a análise por pontos de função auxilia: no cál-

culo do custo real do software, na estimativa do custo do projeto e da implementação, no en-

tendimento dos gastos na manutenção, nas negociações de contrato entre outros.

Page 13: Ponto de Funcao

12

Os capítulos 1,2 e 3 contextualizam a análise de pontos por função na área

da Engenharia de Software. O capítulo 4 discute o que é uma métrica, o por que de se medir

um software e quais tipos de métricas de software existem, e suas características. O capítulo 5

apresenta vários tipos de análise de pontos por função utilizados pelos principais grupos de

usuários do mundo. Já o capítulo 5 mostra o uso de análise de pontos por função no Brasil a-

tualmente. O capítulo 7 mostra como é o processo de contagem de pontos por função segundo

o IFPUG. O capítulo 8 discute os principais métodos de estimativa de software. O capítulo 9

contextualiza a análise de pontos por função dentro das normas e padrões ISO e CMM. O ca-

pítulo 10 descreve a importância da ferramenta desenvolvida no estágio, a ferramenta APF, na

contagem de pontos por função.

Page 14: Ponto de Funcao

13

2 A CRISE DO SOFTWARE E ENGENHARIA DE SOFTWARE

O termo “crise do software” foi muito utilizado na década de 60 devido a

um conjunto de problemas encontrado no processo de desenvolvimento do software. Esses

problemas eram fortemente marcados pela desestruturação dos desenvolvedores, que não

seguiam nenhuma regra, norma ou padrões, ou seja, o desenvolvimento do software

encontrava-se fora de controle.

Os principais problemas relacionados à crise do software são: inadequação

do software, cronogramas e custos imprecisos, insatisfação dos usuários e clientes, comunica-

ção deficiente entre as partes envolvidas, dificuldades na manutenção, etc.

Foi nesse cenário que surgiu a Engenharia de Software, pois era preciso dar

um tratamento mais sistemático e controlado ao processo de desenvolvimento. Sendo assim,

estabeleceram-se padrões, métodos, ferramentas e procedimento para contornar a crise do

software.

A primeira definição atribuída a Engenharia de Software foi dada por Fritz

Bauer em 1969 apud Pressman (1995):

“O estabelecimento e uso de sólidos princípios de engenharia

para se possa obter economicamente um software que seja

confiável e que funcione eficientemente em máquinas reais.”

A definição proposta pelo IEEE, que é uma das mais utilizadas hoje em dia,

defende que a Engenharia de Software é uma aplicação de um processo sistemático, discipli-

nado e quantificado ao desenvolvimento, operação e manutenção de software. Sendo assim, a

engenharia software é nada mais que a aplicação da engenharia ao software.

Os principais objetivos da Engenharia de Software são: melhorar a qualida-

de, entregar o produto dentro dos prazos e custos estabelecidos, incrementar a produtividade

do desenvolvimento, etc.

A principal preocupação da engenharia de software é a qualidade. Segundo

Maldonado (2001) a qualidade de do produto de software está intimamente ligada à qualidade

do processo de software.

O processo de software envolve um conjunto de atividades e resultados as-

sociados que geram o produto de software, ou seja, o produto final (Sommerville, 2003).

Page 15: Ponto de Funcao

14

Prantoni (2001) afirma que um dos maiores problemas encontrados no de-

senvolvimento do software é a determinação correta do tempo e do esforço necessário para o

projeto.

A atividade responsável por essas estimativas é a de planejamento de proje-

tos de software. Através da determinação do tempo e do esforço necessários para o desenvo l-

vimento do software, a empresa consegue prever à qual qualidade e produtividade atingirá o

projeto.

Segundo Cordeiro (2000), se não há previsibilidade, é porque não se conse-

gue realizar estimativas apropriadas e isto é o mesmo que andar no escuro.

Page 16: Ponto de Funcao

15

3 PLANEJAMENTO DE PROJETO DE SOFTWARE

Segundo Maldonado (2001), há três fases no processo de desenvolvimento

de software:

1. Definição: inclui as etapas análise de sistema, o planejamento do proje-

to e a análise de requisitos. Define quais informações serão processa-

das, quais funções e desempenho são desejados, quais interfaces devem

ser estabelecidas, quais restrições do projeto e critérios de validação são

necessários.

2. Construção: inclui as etapas projeto, codificação e o teste do software.

Define como devem ser projetadas as estruturas de dados e a arquitetura

do software.

3. Manutenção: tem como objetivo as mudanças e correções de erros, a-

daptações necessárias e melhoramentos relacionados às novas necessi-

dades do usuário.

Figura 1 - Fases do processo de desenvolvimento de software

Observa-se na figura acima que a atividade de planejamento encontra-se na

fase de definição do projeto. Ela começa a ser realizada no início do ciclo de vida. É muito

comum ocorrer modificações durante as atividades posteriores, uma vez que essas ainda não

estão totalmente definidas.

O planejamento de projeto está fortemente ligado ao desenvolvimento de

um plano. Este plano especifica o que deve ser feito, a divisão de tarefas, estimativas de pra-

zos e custos, etc.

No entanto, é muito comum surgir perguntas do tipo: “por que planejar se já

sei o deve ser feito?”. Segundo Alessandro (2003), um profissional experiente é capaz de sa-

ber o que deve ser feito, porém nenhum projeto envolve apenas uma pessoa.

Page 17: Ponto de Funcao

16

O planejamento é muito importante, pois se reduz à probabilidade de impre-

vistos e de problemas e, conseqüentemente, falsas expectativas, etc. É fundamental para qua l-

quer empresa que queria obter resultados e melhorias nos processos e no produto final.

A determinação de estimativas do planejamento de software não é uma tare-

fa fácil. Segundo Prantoni (2001), não é possível medir ou estimar características de um soft-

ware sem que haja um método de desenvolvimento bem definido, em cada uma de suas ativi-

dades, fases, entradas e saídas. Essas informações estabelecem pontos de controle para que os

dados necessários para o planejamento possam ser obtidos ao longo do processo. Sendo as-

sim, é através dessas estimativas que a empresa consegue prever o custo de seu projeto e veri-

ficar se há sincronização entre as atividades de desenvolvimento.

Para a determinação de estimativas durante o planejamento de software, em

primeiro lugar, defini-se uma forma de medir o software, ou seja, uma forma de definir um

tamanho para o software. A medição do software é chamada de métrica, e é discutida no capí-

tulo seguinte.

Page 18: Ponto de Funcao

17

4 MÉTRICAS E MEDIÇÕES DE SOFTWARE

Segundo Boehm (1981), uma métrica é uma forma padrão de medir um atri-

buto do processo de desenvolvimento de software. As métricas fornecem informações quant i-

tativas sobre o ambiente e o progresso de desenvolvimento do produto.

Por que medir um software? Segundo Wiegers (1999) os projetos de softwa-

re são famosos por estourar o prazo e o orçamento e por apresentar problemas de qua lidade. A

mensuração de software permite que você quantifique prazo, esforço, tamanho do produto,

status do projeto e desempenho da qualidade. Se o usuário não cuidar de medir seu desempe-

nho atual e utilizar os dados para melhorar suas estimativas futuras, tais estimativas serão a-

penas "chutes". Como os dados de hoje tornam-se os dados históricos no futuro, nunca é tarde

para começar a registrar as informações importantes dos projetos.

Quando se considera boa parte dos empreendimentos técnicos, verifica-se

que as medições e as métricas permitem um melhor entendimento do processo utilizado para

desenvolver um produto, assim como uma melhor avaliação do próprio produto.

A quantificação dos aspectos relacionados ao processo de desenvolvimento

de software, assim como do próprio software, é importante, pelas seguintes razões:

? No caso do processo de desenvolvimento, as medições podem permi-

tir melhorias no processo, aumentando a sua produtividade;

? No caso do produto, as medições podem proporcionar informações a

respeito de sua qualidade.

Segundo Pressman (1995) as medições de software podem ser classificadas

em duas categorias principais:

? Medições diretas, por exemplo, o número de linhas de código (LOC)

produzidas, o tamanho de memória ocupado, a velocidade de execu-

ção, o número de erros registrados num dado período de tempo, etc...

? Medições indiretas, as quais permitem quantificar aspectos como a

funcionalidade, complexidade, eficiência, manutenibilidade, etc...

As medições diretas, tais quais aquelas exemplificadas acima, são de obten-

ção relativamente simples, desde que estabelecidas às convenções específicas para isto. Por

outro lado, aspectos como funcionalidade, complexidade, eficiência, etc..., são bastante difí-

ceis de se quantificar.

Page 19: Ponto de Funcao

18

Segundo Gustafson (2003) as métricas de software podem ser divididas em

métricas do produto e métricas do processo.

Já Pressman (1995) afirma que as métricas de software podem ser divididas

em métricas de produtividade, métricas de qualidade e métricas técnicas. E que uma outra di-

visão em categorias pode ser feita: métricas orientadas ao tamanho, orientadas à função e ori-

entadas às pessoas. Verifica-se melhor essa duas classificações segundo a figura abaixo:

Figura 2 - Classificação das Métricas de Software

4.1 MÉTRICAS DO PRODUTO

Gustafson (2003) relata que métricas do produto são métricas que podem ser

calculadas para o documento, não importando a forma como foi produzido. Geralmente elas

estão relacionadas de alguma maneira à estrutura do código fonte, mas podem ser definidas de

outras formas, por exemplo, pelo número de parágrafos na especificação de requisitos.

Page 20: Ponto de Funcao

19

4.2 MÉTRICAS DO PROCESSO

Métricas do processo são métricas definidas de forma a medir o processo.

Segundo Gustafson (2003) a produtividade é uma das métricas básicas do processo, que é cal-

culada pela divisão do total de linhas de código fonte (LOC) entregues pelos programadores

por dia, atribuídos ao projeto do software. As unidades geralmente são LOC/programador/dia.

4.3 MÉTRICAS DE PRODUTIVIDADE E QUALIDADE DE SOFTWARE E MÉ-TRICAS TÉCNICAS

Pressman (1995) afirma que dentro do contexto de gerenciamento de proje-

tos de software, há uma maior preocupação com métricas de produtividade e de qua lidade,

medidas através do resultado do desenvolvimento de software como uma função do esforço

aplicado e medidas da “adequação ao uso” do resultado que é produzido. Para propósitos de

planejamento e estimativa, o interesse é histórico.

Métricas da produtividade são baseadas na saída do processo de desenvo l-

vimento do software com o objetivo de avaliar o próprio processo. Já as métricas da qualidade

permitem indicar o nível de resposta do software às exigências explícitas e implícitas do cli-

ente.

Nas métricas técnicas, encaixam-se aspectos como funcionalidade, modula-

ridade, manutenibilidade, etc.

4.4 MÉTRICAS ORIENTADAS AO TAMANHO

Segundo Pressman (1995), métricas de software orientadas ao tamanho são

medidas diretas do software e do processo pelo qual ele é produzido. Se a empresa possuir re-

gistros simples, uma tabela como a da figura abaixo, poderá ser criada.

Page 21: Ponto de Funcao

20

Tabela 1 – Métricas Orientadas ao Tamanho

projeto esforço $ LOC págs. do-

cum. erros pessoas

aaa-01 24 168 12.1 365 29 3

ccc-04 62 440 27.2 1224 86 5

fff-03 43 314 20.2 1050 64 6

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

Fonte: (Pressman, 1995)

Segundo JON (1986) apud Pressman (1995), as métricas orientadas ao ta-

manho provocam controvérsias e não são universalmente aceitas como a melhor maneira de

se medir o processo de desenvolvimento de software. O motivo principal é o uso de LOC co-

mo medida, já que seu uso em estimativas é complexo, necessitando de um nível de detalhes

muito grande. O planejador deve estimar o número de linhas de código que serão desenvolvi-

das muito antes que a análise e o projeto tenham sido concluídos.

4.5 MÉTRICAS ORIENTADAS A FUNÇÃO

Pressman (1995) afirma que as métricas de software orientadas à função são

medidas indiretas de software e do processo ao qual é desenvolvido. A métrica orientada à

função não conta linhas de código, e sim a “funcionalidade” ou ”utilidade” do programa.

Métricas orientadas à função serão mais bem comentadas no capítulo Métri-

cas Funcionais – Análise de Pontos por Função.

Page 22: Ponto de Funcao

21

5 MÉTRICAS FUNCIONAIS – ANÁLISE DE PONTOS POR FUNÇÃO

Silva (2000) afirma que a Análise de Pontos por Função procura fornecer

uma unidade de medida para a indústria do software. Esta unidade de medida não depende da

plataforma ou da linguagem em que o software será desenvolvido. Um aplicativo por mais

simples e modesto que seja, sempre executa algumas determinadas funções. Determinar estas

funções segundo critérios precisos e dar-lhes uma medida de referência é o ponto-chave da

Análise de Pontos por Função.

Segundo Pressman (1995) os conceitos sobre pontos de função foram intro-

duzidos por Allan J. Albrech, da IBM, em 1979. Melhorados e transformados em metodologia

formal, esses conceitos vieram a público em 1984. Já em 1986, uma comunidade de usuários

criou o IFPUG – Grupo Internacional de usuários de Pontos por Função, maior divulgador da

técnica nos tempos de hoje. No entanto, há outros grupos como BFPUG, NESMA, Mark II e

COSMIC – FFP, que serão comentados no decorrer deste trabalho.

Mas o que é um ponto por função? Segundo Silva (2000) ponto por função é

uma medida que procura definir o tamanho do que faz o software, independente de como pos-

sa ser produzido e implementado. Assim, tamanho funcional é uma medida de tamanho de

software baseado numa avaliação padronizada dos requisitos lógicos dos usuários.

5.1 IFPUG

O IFPUG1 – International Function Point Users Group (Grupo Internacional

de Usuários de Ponto por Função) é uma entidade sem fins lucrativos, composta por pessoas e

empresas de diversos países, cuja finalidade é promover um melhor gerenciamento dos pro-

cessos de desenvolvimento e manutenção de software, utilizando a técnica de pontos por fun-

ção e outras.

O IFPUG lança desde 1990 o CPM – Counting Pratices Manual ou Manual

de Práticas de Contagem, que está atualmente na versão Release 4.1.1. Desde seu lançamento

este manual é considerado como padrão pela maioria das indústrias de software para pontos

de função.

O Grupo Internacional de Usuários de Ponto por Função realiza conferên-

cias anuais, seminários e workshops educacionais com o intuito de divulgar a técnica de pon-

1 http://www.ifpug.org.

Page 23: Ponto de Funcao

22

tos por função. Além de possuir uma certificação profissional, a CFPS visa dar certificação

aos usuários da técnica como especialistas em pontos de função.

O Grupo também possui vários comitês, como o de certificação responsável

pelo desenvolvimento do programa de certificação, o comitê de comunicação responsável por

manter a comunicação entre o IFPUG e seus membros, o comitê de conferências responsável

por promover a conferência anual, o comitê de práticas de contagem responsável por manter o

CPM, o comitê de educação responsável por promover os seminários e workshops, entre vá-

rios outros comitês responsáveis por manter, desenvolver e divulgar a técnica da Análise de

Pontos por Função.

5.2 NESMA

O NESMA2 – Netherlands Software Metrics Users Association, ou associa-

ção de usuários de métricas de software da Holanda, foi criada inicialmente com o nome de

NEFPUG – Netherlands Function Point Users, ou grupo de usuários de pontos por função da

Holanda. O NESMA é um dos maiores grupos de usuários de pontos por função da Europa,

utilizando filosofia, conceitos termos e regras bem parecidos com as do IFPUG, mas com al-

gumas diretrizes diferentes. A NESMA, desde 1990, possui seu próprio manual de contagem,

atualmente na versão 2.0, sendo que sua forma de contagem é bem próxima da do manual do

IFPUG chegando em resultados bem próximos.

5.3 MARK II3

O Mark II foi formulado por Charles Symons em meados da década de 80,

inspirado por Albrecht. Seu trabalho ficou muito conhecido depois de uma publicação na re-

vista IEEE – Transactions on Software Engineering. No entanto, a técnica não se tornou mui-

to usada pelo fato de que, inicialmente, era um método proprietário da consultoria KPMG.

Hoje a técnica é de domínio público, e a UKSMA, Associação de Métricas

do Reino Unido, é a associação responsáve l por mantê- la. No entanto, a técnica é muito restri-

ta ao Reino Unido.

5.4 COSMIC – FFP

Em 1997, um grupo de pesquisadores da Universidade de Quebec desenvo l-

veu um método chamado FFP – Full Function Points, que era destinado à medição funcional

2 http://www.nesma.nl.

Page 24: Ponto de Funcao

23

de sistemas de tempo real. No entanto, percebeu-se que a mesma técnica poderia ser usada em

sistemas tradicionais. Assim em 1998 um grupo de especialistas liderados por Alain Albran e

Charles Symons, formou o COSMIC4 – Common Software Measurement International Con-

sortium com o objetivo de criar uma nova técnica utilizando o melhor de cada método já exis-

tente.Mas, acabou sendo um refinamento do FFP, sendo chamado então de COSMIC – FFP.

5.5 IBSG

O IBSG5 – International Software Benchmarking Standards Group é uma

organização sem fins lucrativos, resultado da iniciativa de várias organizações métricas do

mundo, de países como Estados Unidos, Reino Unido, Holanda, Japão, Itália, entre outros, cu-

jo principal motivo de existência é manter um repositório público de métricas de projetos de

software que possa ajudar na gestão dos recursos de TI pela melhoria das estimativas de pro-

jeto e produtividade, análise de riscos e benchmarking.

O IBSG fornece um modelo padrão para o registro e coleta de dados de pro-

jetos de software, fornece uma ferramenta de auxílio na coleta de dados, gerencia o repositó-

rio de dados de projetos, coordena uma pesquisa baseada em seu repositório e publica livros e

relatórios. Periodicamente o IBSG publica o “The software Metrics Compendium” que con-

tém uma análise estatística detalhada do seu repositório.

Qualquer organização pode contribuir com informações de seus projetos pa-

ra o repositório do IBSG, este garante que estes dados serão confidenciais.

3 http://www.uksma.co.uk. 4 http://www.cosmicon.com. 5 http://www.ibsg.org.au.

Page 25: Ponto de Funcao

24

6 ANÁLISE DE PONTOS POR FUNÇÃO NO BRASIL

Segundo a pesquisa Tecnologia da Informação – Qualidade e Produtivida-

deno Setor de Software de 2001 do Ministério da Ciência e tecnologia, no Brasil, a medição

de linhas de código foi a métrica mais aplicada no passado, quando o código era dominante

nas estimativas de custo. Desde a década de 1990, vem ganhando espaço a técnica de avalia-

ção de um sistema, conhecida como FPA – Function Point Analysis, baseada na medição do

valor das funções executadas pelos programas, ao invés de utilizar como base o volume ou a

complexidade do código dos programas.

Na pesquisa, verificou-se que para medir a qualidade dos processos de soft-

ware quase 10% das empresas utilizavam pontos por função e 6% linhas de código. A tabela

abaixo ilustra essa situação:

Tabela 2 - Métricas primitivas utilizadas para medir a qualidade dos processos de software

Categorias Nº de organizações %

Linhas de código ( LOC ) 25 5,6

Pontos por função ( function point ) 43 9,6

Outras métricas 26 5,8

Não utiliza 363 81,4

Base 446 100

Fonte: Ministério da Ciência e Tecnologia

Enquanto como métricas primitivas para medir a produtividade, os resulta-

dos eram de 18% para FPA e 10% para linhas de código.A tabela abaixa ilustra essa situação::

Page 26: Ponto de Funcao

25

Tabela 3 – Métricas primitivas utilizadas para medir a produtividade dos processos de softwa-

re.

Categorias Nº de organizações %

Linhas de código ( LOC ) 46 10,3

Pontos por função ( function point ) 81 18,2

Outras métricas 30 6,7

Não utiliza 312 70,0

Base 446 100

Fonte: Ministério da Ciência e Tecnologia

Figura 3 - Métricas primitivas utilizadas para medir a qualidade e produtividade dos processos de software.

O Brasil já possui um grupo de usuários de pontos por função nos moldes

do IFPUG, chamado BFPUG descrito a seguir.

6.1 BFPUG

O BFPUG6 é um grupo de usuários constituído com o objetivo de divulgar a

utilização de métricas no desenvolvimento de sistemas, principalmente a Análise de Pontos de

Função. Destina-se aos profissionais interessados em aprender, praticar e divulgar o uso de

métricas e de Pontos por Função. O BFPUG é a representação brasileira oficial do IFPUG.

Page 27: Ponto de Funcao

26

No Brasil já ocorreram cinco exames da certificação CFPS, sendo o último

realizado no dia 22 de novembro de 2003 sob patrocínio do BFPUG. A tabela abaixo mostra a

evolução dos exames patrocinados pelo BFPUG:

Tabela 4 – Exames CFPS Realizados pelo BFPUG

Ano Mês Candidatos Aprovados % Aprov. Localidade(s) Obs. Qtd CFPS

2001 06 31 10 32 Rio 12

2002 06 56 34 61 Rio 1 recertificou-se 45

2003 03 76 45 59 Rio, São Paulo e Brasília 1 recertificou-se 89

2003 11 105 Aguarde Aguarde Rio, São Paulo, Bra-sília e Vitória

Fonte: BFPUG

Segundo o site do BFPUG, o Brasil possuia, até 22/11/2003, 89 especialis-

tas certificados pelo IFPUG, sendo hoje veja na figura abaixo extraída do site do BFPUG a

evolução do número de certificados com a certificação CFPS no Brasil:

6 http://www.bfpug.com.br.

Page 28: Ponto de Funcao

27

Figura 4 - Evolução da Quantidade de CFPS Brasileiros

Segundo o BFPUG, o Brasil é o terceiro país com maior número de especia-

listas certificados pelo IFPUG. A tabela abaixo, criada com dados do BFPUG, mostra os cin-

co países com maior número de especialistas certificados do mundo:

Tabela 5 – Países com maiôs número de CFPS

Posição País

1 Estados Unidos

2 Itália

3 Brasil

4 Japão

5 Canadá

Fonte: BFPUG

Page 29: Ponto de Funcao

28

7 PROCESSO DE CONTAGEM – ANÁLISE DE PONTOS POR FUNÇÃO

O processo de contagem de pontos por função, segundo o CPM 4.1.1 do IF-

PUG, segue o esquema da figura abaixo retirada de (Vazquez et al, 2003).

Figura 5 - Processo de Contagem

7.1 DETERMINAÇÃO DO TIPO DE CONTAGEM

Segundo Vazquez et al (2003) existem três tipos de contagem de Pontos por

Função, são eles:

? Contagem de um projeto de desenvolvimento;

? Contagem de um projeto de melhoria;

? Contagem de uma aplicação (ou baseline).

A técnica utilizada na contagem é a mesma em cada tipo, a diferença está no

que é considerado em cada um. Essa diferença será vista no cálculo de pontos por função a-

justados.

Page 30: Ponto de Funcao

29

7.1.1 Contagem de um projeto de desenvolvimento

Este tipo de contagem mede a funcionalidade fornecida aos usuários finais

do software quando da sua primeira instalação. Isso significa que essa contagem também a-

brange as eventuais funções de conversão de dados necessárias à implantação do sistema. No

entanto, qualquer contagem feita antes do término de um projeto é, na verdade, uma estimati-

va da funcionalidade que o projeto terá quando estiver pronto.

7.1.2 Contagem de um projeto de melhoria

Este tipo de contagem mede as funções adicionadas, modificadas ou excluí-

das do sistema pelo projeto. Mede ainda as funções de conversão de dados. Quando o projeto

de melhoria é concluído, os pontos por função da aplicação devem ser atualizados para refletir

as alterações desse projeto.

7.1.3 Contagem de uma aplicação (ou baseline)

Este tipo de contagem mede os pontos por função de uma aplicação instala-

da e mostra a atual funcionalidade obtida pelo usuário da aplicação. Este tipo de contagem é

iniciado no final da contagem do projeto de desenvolvimento e é atualizado depois do projeto

de melhoria.

7.2 O ESCOPO DA CONTAGEM E A FRONTEIRA DA APLICAÇÃO

O escopo da contagem define a contagem abrangerá um ou mais sistemas ou

apenas parte de um sistema. Já a fronteira da aplicação deverá separar o software que será

medido e o mundo exterior. Segundo Silva (2000) a fronteira do aplicativo separa os compo-

nentes de um aplicativo dos componentes de outros aplicativos.

7.3 FUNÇÕES DO TIPO DADO

Segundo Vazquez et al (2003) as funções do tipo dado representam a fun-

cionalidade fornecida ao usuário para atender a suas necessidades de dados internos e exter-

nos à aplicação. São classificados em Arquivos Lógicos Internos (ALI) e Arquivos de Interfa-

ce Externa (AIE). O termo Arquivo se refere a um grupo de dados logicamente relacionados e

reconhecido pelo usuário.

O processo de contagem dos ALI e AIE se resumem em: identificar arqui-

vos lógicos internos, sua complexidade e contribuição.

Page 31: Ponto de Funcao

30

7.3.1 Arquivo Lógico interno

Silva (2000) afirma que um Arquivo Lógico Interno (ALI) é um grupo de

dados relacionados, identificados pelo usuário, que reside inteiramente dentro da fronteira do

aplicativo. O conjunto de dados é sempre baseado na visão do usuário e é um elemento lógico

e persistente. É lógico, pois não se prende a qualquer implementação física e persistente, pois

permanece sempre disponível para o usuário.

Segundo Vazquez et al (2003) uma definição para ALI é:

? Um grupo de dados ou informações de controle;

? Identificável pelo usuário;

? Mantido dentro da fronteira da aplicação;

Segundo Silva (2000) o processo de contagem de ALI é baseado em regis-

tros lógicos referenciados e dados elementares referenciados. Um registro lógico referenciado

é um subgrupo de dados que devem ser enxergados como um elemento único. Caso não exis-

tam subgrupos de dados, então considera que o ALI possui um registro. Os dados elementares

referenciados dão suporte às necessidades do usuário, segundo sua própria visão. Não devem

ser contados dados que sejam recursivos.

Com base nos números de registros lógicos referenciados e dados elementa-

res referenciados, deve-se calcular a complexidade do ALI seguindo a tabela a seguir:

Tabela 6 – Complexidade ALI

1 a 19 dados elemen-

tares referenciados

20 a 50 dados ele-

mentares referencia-

dos

51 dados elementares

referenciados em di-

ante

1 registros lógicos re-

ferenciados Simples Simples Média

2 a 5 registros lógi-

cos referenciados Simples Média Complexa

6 registros lógicos re-

ferenciados em dian-

te

Média Complexa Complexa

De acordo com Vaquez et al (2003), depois de determinada a complexidade

de um ALI, determina-se a contribuição que ele vai proporcionar. Na tabela a seguir, verifica-

Page 32: Ponto de Funcao

31

se o número de pontos por função que um Arquivo Lógico Interno proporciona em função de

sua complexidade.

Tabela 7 – Pontos por Função ALI

Complexidade Pontos por Função

Simples 7

Média 10

Complexa 15

7.3.2 Arquivo de interface externa

Segundo Silva (2000) um Arquivo de Interface Externa (AIE) é um grupo

lógico de dados relacionados, identificados pelo usuário, usados apenas como referência pelo

aplicativo. Estes dados residem inteiramente fora da fronteira do aplicativo e são mantidos por

outros aplicativos.

Segundo Vazquez et al (2003) uma definição para AIE é:

? Um grupo de dados ou informações de controle;

? Identificável pelo usuário;

? Logicamente relacionados;

? Mantido dentro da fronteira da aplicação.

O processo de contagem de Arquivos de Interface Externa é semelhante ao

de contagem de Arquivos Lógicos Internos. Ou seja, os dois são baseados em registros lógi-

cos referenciados e dados elementares referenciados.

Sendo assim, com base nos números de registros lógicos referenciados e da-

dos elementares referenciados, calcular-se a complexidade do AIE seguindo a tabela a seguir:

Page 33: Ponto de Funcao

32

Tabela 8 – Complexidade AIE

1 a 19 dados elemen-

tares referenciados

20 a 50 dados ele-

mentares referencia-

dos

51 dados elementares

referenciados em di-

ante

1 registros lógicos re-

ferenciados Simples Simples Média

2 a 5 registros lógi-

cos referenciados Simples Média Complexa

6 registros lógicos re-

ferenciados em dian-

te

Média Complexa Complexa

De acordo com Vaquez et al (2003), depois de determinada a complexidade

de um AIE, determina-se a contribuição que ele vai proporcionar. A tabela a seguir mostra o

número de pontos por função que um Arquivo Interface Externa proporciona em função de

sua complexidade.

Tabela 9 – Pontos por Função AIE

Complexidade Pontos por Função

Simples 5

Média 7

Complexa 10

7.4 FUNÇÕES DO TIPO TRANSAÇÃO

Segundo Vazquez et al (2003) as funções do tipo transação representam a

funcionalidade fornecida ao usuário para atender as suas necessidades de processamento de

dados pela aplicação. São classificadas em Entradas Externas (EE), Saídas Externas (SE) ou

Consultas Externas (CE).

O processo de contagem das funções de transação se resume em determinar

a complexidade e a contribuição de cada EE, SE e CE e somar todas as contribuições.

Page 34: Ponto de Funcao

33

7.4.1 Entrada Externa

Silva (2000) afirma que uma Entrada Externa é um processo elementar que

recebe dados vindos de fora da fronteira do aplicativo. Os dados podem ser recebidos de telas

de entrada de dados ou diretamente de outros aplicativos. Os dados podem ser informações de

negócio ou informações de controle. Uma informação de negócio é um dado que precisa ser

tornado persistente, ou seja, que precisa ser armazenado em algum arquivo lógico interno. Já

uma informação de controle é um dado que influência um processo elementar.

Segundo Vazquez et al (2003) uma definição para Entrada externa é:

? Um processo elementar;

? Que processa dados ou informações de controle recebidos de fora da

fronteira da aplicação;

? Cuja principal intenção é manter um ou mais arquivos lógicos inter-

nos e ou modificar o comportamento do sistema.

A complexidade de uma Entrada Externa é calculada de acordo com o nú-

mero de Arquivos Lógicos referenciados e de dados elementares referenciados, então calcula-

se a complexidade seguindo os dados da tabela à seguir:

Tabela 10 – Complexidade EE

1 a 4 dados elemen-

tares referenciados

5 a 15 dados elemen-

tares referenciados

15 dados elementares

referenciados em di-

ante

0 ou 1 arquivos lógi-

cos referenciados Simples Simples Média

2 arquivos lógicos re-

ferenciados Simples Média Complexa

3 arquivos lógicos re-

ferenciados em dian-

te

Média Complexa Complexa

De acordo com Vaquez et al (2003), depois de determinada a complexidade

de uma EE, determinamos a contribuição que ela vai proporcionar. Na tabela a seguir vemos o

número de pontos por função que uma Entrada Externa proporciona em função de sua com-

plexidade.

Page 35: Ponto de Funcao

34

Tabela 11 – Pontos por Função EE

Complexidade Pontos por Função

Simples 3

Média 4

Complexa 6

7.4.2 Saída Externa

Silva (2000) afirma que uma Saída Externa é um processo elementar através

do qual dados derivados são enviados para além da fronteira do aplicativo. Os dados podem

ser relatórios ou arquivos de saída que são enviados para outros aplicativos. A finalidade bási-

ca de uma saída externa é a de recuperar dados, processá- los e enviá-los para além da frontei-

ra do aplicativo. No entanto, uma saída externa pode, às vezes, atualizar arquivos lógicos in-

ternos.

Segundo Vazquez et al (2003) uma definição para Saída externa é:

? Um processo elementar;

? Que envia dados ou informações de controle para fora da fronteira

da aplicação;

? Cuja principal intenção é apresentar informação ao usuário por meio

de lógica de processamento que não seja apenas a recuperação de

dados ou informações de controle.

A complexidade de uma Saída Externa é calculada de acordo com o número

de Arquivos Lógicos referenciados e de dados elementares referenciados, então calcula-se a

complexidade seguindo os dados da tabela à seguir:

Page 36: Ponto de Funcao

35

Tabela 12 – Complexidade SE

1 a 5 dados elemen-

tares referenciados

6 a 19 dados elemen-

tares referenciados

20 dados elementares

referenciados em di-

ante

0 ou 1 arquivos lógi-

cos referenciados Simples Simples Média

2 ou 3 arquivos lógi-

cos referenciados Simples Média Complexa

4 arquivos lógicos re-

ferenciados em dian-

te

Média Complexa Complexa

De acordo com Vaquez et al (2003), depois de determinada a complexidade

de uma SE, determinamos a contribuição que ela vai proporcionar. Na tabela a seguir vemos o

número de pontos por função que uma Saída Externa proporciona em função de sua comple-

xidade.

Tabela 13 – Pontos por Função SE

Complexidade Pontos por Função

Simples 4

Média 5

Complexa 7

7.4.3 Consulta Externa

Silva (2000) afirma que uma Consulta Externa é um processo elementar

com componentes de entrada e saída recuperados de arquivos lógicos internos e de interface

externa. Os dados são enviados para alem da fronteira da aplicação. O processo não atualiza

nenhum arquivo lógico interno e os dados enviados não sofrem qualquer tipo de transforma-

ção.

Segundo Vazquez et al (2003) uma definição para Consulta externa é:

? Um processo elementar;

Page 37: Ponto de Funcao

36

? Que envia dados ou informações de controle para fora da fronteira

da aplicação;

? Cuja principal intenção é apresentar informação ao usuário por meio

de uma simples recuperação de dados ou informações de controle de

um ALI ou AIE.

A complexidade da Consulta Externa é calculada de acordo com a quantida-

de de arquivos lógicos referenciados e de dados elementares referenciados. Os elementos da

parte de entrada devem ser somados aos elementos da parte de saída. Para a identificação de

uma consulta externa deve-se utilizar as mesma regras usadas para uma entrada externa ou pa-

ra uma saída externa, usando em seguida a tabela a seguir para determinar a complexidade:

Tabela 14 – Complexidade CE

1 a 5 dados elemen-

tares referenciados

6 a 19 dados elemen-

tares referenciados

20 dados elementares

referenciados em di-

ante

0 ou 1 arquivos lógi-

cos referenciados Simples Simples Média

2 ou 3 arquivos lógi-

cos referenciados Simples Média Complexa

4 arquivos lógicos re-

ferenciados em dian-

te

Média Complexa Complexa

De acordo com Vaquez et al (2003), depois de determinada a complexidade

de uma CE, determinamos a contribuição que ela vai proporcionar. Na tabela a seguir verifi-

ca-se o número de pontos por função que uma Consulta Externa proporciona em função de

sua complexidade.

Tabela 15 – Pontos por Função CE

Complexidade Pontos por Função

Simples 3

Média 4

Complexa 6

Page 38: Ponto de Funcao

37

7.5 PONTOS POR FUNÇÃO NÃO-AJUSTADOS

Cada função, tanto do tipo dado, quanto do tipo transação são classificadas

em simples, média ou complexa. E com base nessa classificação foram calculadas suas con-

tribuições, que dependem do tipo de cada função e de sua complexidade. O número de Pontos

por Função Não-Ajustados é o somatório das contribuições de todas as funções do aplicativo.

7.6 FATOR DE AJUSTE

Segundo Silva (2000) o fator de ajuste (VAF – Value Adjustment Factor) é

baseado em 14 características gerais de sistema (CGS), listadas na seqüência:

1. Comunicação de Dados;

2. Performance;

3. Volume de Transações;

4. Interface com o Usuário;

5. Processamento Complexo;

6. Facilidade de Implantação;

7. Múltiplos Locais;

8. Processamento Distribuído;

9. Utilização de Equipamento;

10. Entrada de Dados "on- line";

11. Atualização "on- line";

12. Reutilização de Código ;

13. Facilidade Operacional;

14. Facilidade de Mudanças.

Enquanto as funções do tipo dado refletem um requisito específico de arma-

zenamento e as funções do tipo transação um requisito específico de processamento, as CGS

refletem funções que afetam a aplicação de maneira geral. Cada uma das 14 características re-

cebe um valor de nível de influência de 0 a 5 mostrados na tabela à seguir:

Page 39: Ponto de Funcao

38

Tabela 16 – Níveis de Influência

0 - Não tem influência

1 - Influência incidental

2 - Influência moderada

3 - Influência média

4 - Influência significativa

5 - Influência essencial

Vazquez et al (2003) afirma que o IFPUG fornece diretrizes que ajudam a

diminuir a subjetividade na determinação do nível de influência. O IFPUG diz que determina-

dos os níveis de influência dos 14 CGS, o fator de ajuste é calculado da seguinte forma: VAF

= (TDI x 0,01) + 0,65. Em que TDI (total degree of influence) é o somatório dos níveis de in-

fluencia das características gerais. O fator de ajuste ajusta o número de pontos por função

não-ajustados em no máximo + ou – 35%.

O IFPUG tornou o fator de ajuste facultativo para poder se adequar as nor-

mas do ISO/IEC, pois a determinação do fator de ajuste requer a utilização de requisitos tec-

nológicos e de qualidade, que são incompatíveis com o modelo ISO.

7.7 PONTOS POR FUNÇÃO AJUSTADOS

Segundo o manual do IFPUG existem três formas de se calcular os pontos

por função ajustados. Existe uma para cada tipo de contagem, são elas: projeto de Desenvo l-

vimento, projeto de Melhoria e Aplicação.

7.7.1 Cálculo para projeto de Desenvolvimento

DFP = (UFP + CFP) x VAF

Onde:

? DFP: Número de pontos por função do projeto de desenvolvimento.

? UFP: Número de Pontos por função não ajustados das funções dis-

poníveis após instalação.

? CFP: Número de pontos por função não-ajustados das funções de

conversão.

Page 40: Ponto de Funcao

39

? VAF: Valor do fator de ajuste;

7.7.2 Cálculo para projeto de Melhoria

EFP = [(ADD + CHGA + CFP) x VAFA] + (DEL X VAFB)

Onde:

? EFP: Número de pontos por função do projeto de melhoria.

? ADD: Número de pontos por função não-ajustados das funções in-

cluídas pelo projeto de melhoria.

? CHGA: Número de pontos por função não-ajustados das funções

modificadas. Reflete as funções depois das modificações.

? CFP: Número de pontos por função não-ajustados adicionados pela

conversão.

? VAFA: Valor do fator de ajuste da aplicação depois do projeto de

melhoria.

? DEL: Número de pontos por função não-ajustados das funções ex-

cluídas pelo projeto de melhoria.

? VAFB: Valor do fator de ajuste da aplicação antes do projeto de me-

lhoria.

7.7.3 Cálculo para Aplicação

Segundo Vazquez et al (2003), há duas formas de se calcular o número de

pontos por função da aplicação. Uma para a primeira contagem dos pontos por função da a-

plicação e outra para depois do projeto de melhoria.

Fórmula Contagem inicial:

AFP = ADD x VAF

Onde:

? AFP: Número de pontos por função ajustados da aplicação.

? ADD: Pontos por função não-ajustados das funções instaladas.

? VAF: Valor do fator de ajuste da aplicação.

Fórmula após projeto de melhoria:

AFP = [(UFPB + ADD + CHGA) – (CHGB + DEL)] x VAFA

Page 41: Ponto de Funcao

40

Onde:

? AFP: Número de pontos por função ajustado da aplicação.

? UFPB: Pontos por função não-ajustados da aplicação antes do proje-

to de melhoria.

? ADD: Pontos por função não-ajustados das funções incluídas pelo

projeto de melhoria.

? CHGA: Pontos de função não-ajustados das funções alteradas pelo

projeto de melhoria depois de seu término.

? CHGB: Pontos de função não-ajustados das funções alteradas pelo

projeto de melhoria antes de seu término.

? DEL: Pontos de função não-ajustados das funções excluídas pelo

projeto de melhoria.

? VAFA: Valor do fator de ajuste depois do projeto de melhoria.

Page 42: Ponto de Funcao

41

8 ESTIMATIVAS

8.1 MÉTODO DELPHI

A Estimativa de Delphi é um modelo empírico, que se resume à consulta de

especialistas, linguagem de programação e outros assuntos para que, ao utilizar sua experiên-

cia e entendimento do projeto proposto, faça as devidas estimativas.

8.2 MÉTODO WIDEBAND-DELPHI (BOEHM)

Este método sugere que vários desenvolvedores envolvidos no projeto ind i-

quem suas estimativas individualmente. Em seguida, aplica-se o processo Delphi para se obter

uma estimativa convergente. O que difere os métodos Delphi e WideBand-Delphi é que o

primeiro não envolve reuniões entre os especialistas. A escolha entre esses dois modelos fica

a critério da empresa.

8.3 MÉTODO PUTMAN

A Estimativa de Putman é um modelo dinâmico de múltiplas variáveis que

pressupõem uma distribuição do esforço específico ao longo da existência de um projeto de

desenvolvimento de software. Este modelo associa experimentação associada a levantamento

de dados históricos e inferência estatística (Putnam, 1978) apud (Haufe, 1999).

8.4 MODELO COCOMO E COCOMO II

Segundo Sommerville (2003), o modelo COCOMO (constructive cost mo-

del – modelo de custo construtivo) é um modelo empírico. Ele foi derivado da coleta de dados

a partir de um grande número de projetos de software e, em seguida, pela análise desses dados

para descobrir fórmulas que fossem mais adequadas às observações.

Sommerville (2003) afirma que a primeira versão do COCOMO (hoje co-

nhecida como COCOMO 81) possuía três níveis, e cada nível refletia os detalhes da estimati-

va de custos. O primeiro nível, o nível básico, fornecia uma estimativa inicial, preliminar; o

segundo nível modificava essa condição, utilizando uma série de multiplicadores de projeto e

processo, e o nível mais avançado produzia estimativas para diferentes fases do projeto.

Segundo Trindade et al (1999) o modelo COCOMO II é uma versão atuali-

zada do COCOMO 81, que condiz com as tecnologias dos anos 90 e foi desenvolvido já se

pensando nas próximas décadas.

Page 43: Ponto de Funcao

42

Sommerville (2003) identifica níveis para o COCOMO II, são eles:

1. Nível inicial de prototipação: As estimativas de tamanho são feitas

com base em pontos de objeto, e uma fórmula simples de tama-

nho/produtividade é utilizada para estimar o esforço requerido.

2. Nível inicial de projeto: Esse nível corresponde à conclusão dos re-

quisitos do sistema com (talvez) algum projeto inicial. As estimati-

vas são baseadas em pontos por função, que são convertidas para o

número de linhas de código-fonte. A fórmula segue o modo-padrão,

com a diferença de um simples conjunto de multiplicadores associa-

dos a ela.

3. Nível pós-arquitetura: Uma vez projetada a arquitetura do sistema,

uma estimativa razoavelmente exata do tamanho do software pode

ser feita. A estimativa desse nível utiliza um conjunto mais amplo de

multiplicadores, refletindo a capacidade pessoal, as características de

produto e de projeto.

8.5 ANÁLISE DE PONTOS POR FUNÇÃO

Busca medir a complexidade do produto pela quantificação de funcionalida-

de. Um modelo lógico, entretanto, expressa a visão que o usuário tem do mesmo. O modelo

FPA mede o que é o sistema, o seu tamanho funcional e não como este será, além de mensu-

rar a relação do sistema com usuários e com outros sistemas. FPA é completamente indepen-

dente de tecnologia e mede uma aplicação pelas funções que desempenha.

Os modelos COCOMO e Putman e vários outros métodos de estimativa uti-

lizam como base os LOC, linhas de código. No entanto, podemos transformar o número de

pontos por função em número de linhas de código utilizando tabelas padrão que nos indicam o

número de linhas de código aproximado para cada linguagem de programação. A tabela abai-

xo, mostra um exemplo:

Page 44: Ponto de Funcao

43

Tabela 17 – Linguagens de Programação

Linguagem Nº de linhas de código para cada ponto por

função

1st Generation default 3200

2nd Generation default 107

3nd Generation default 80

4nd Generation default 20

5nd Generation default 5

FORTRAN 107

C++ 53

Delphi 29

JAVA 53

Visual C++ 34

Page 45: Ponto de Funcao

44

9 NORMAS E PADRÕES

9.1 PADRÃO ISO

Segundo Vazquez et al (2003) já no final de 1992, existiam vários métodos

de Medição Funcional de Tamanho (Functional Size Measurement – FSM), surgidos a partir

do método original de Análise de Pontos por Função proposto por Allan Albrecht. Com o ob-

jetivo de resolver as inconsistências existentes entre tais métodos e estabelecer um método

mais rigoroso de medição funcional, os grupos de usuários de métricas de software da Austrá-

lia, Estados Unidos, Holanda e Reino Unido formaram o grupo denominado WG12 – Wor-

king Group 12, subordinado ao SC77 – Sub-Committee Seven do JTC1 – Join Technical

Committee One estabelecido pela ISO – International Organization for Standardization em

conjunto com o IEC – International Engineering Consortium.

Dos trabalhos do WG12 foram criados um conjunto de normas internacio-

nais chamado de norma 14143, dividida em cinco partes:

? 14143-1: Definição de conceitos;

? 14143-2: Avaliação da Conformidade de Métodos de Medição de Soft-

ware com relação ao padrão ISSO/IEC 14143-1;

? 14143-3: Verificação de um Método de Medição de Tamanho Funcio-

nal;

? 14143-4: Modelo de Referência para Medição de tamanho Funcional;

? 14143-5: Determinação de Domínios Funcionais para uso com Medição

de Tamanho Funcional.

A norma ISO/IEC 14143 foi desenvolvida com o intuito de garantir que to-

dos os métodos de Medição Funcional de Tamanho sejam baseados em conceitos similares.

Atualmente são quatro os métodos padrão de Medição de Tamanho Funcio-

nal reconhecidos pela norma ISO/IEC 14143, são eles:

? IFPUG CPM 4.1 (ISO/IEC 20926:2002);

? NESMA CPM 2.0 (ISO/IEC 24570:2002);

? Mark II COM 1.3.1 (ISO/IEC 20968:2002);

7 http://www.jtcl-sc7.org

Page 46: Ponto de Funcao

45

? COSMIC-FFP Measurement Manual 2.1 (ISO/IEC 19761:2003).

9.2 CMM

O CMM é o modelo de capacitação para medição de maturidade mais am-

plamente aceito para o entendimento do processo de desenvolvimento de software. Segundo

Pádua (2003), um modelo de capacitação serve de referência para avaliar a maturidade dos

processos de uma organização.

Há cinco níveis de maturidade e cada uma delas, exceto o nível 1, possui á-

reas chaves que identificam quais questões devem ser resolvidas para atingir esse nível e defi-

nem um conjunto de metas Pádua (2003).

Tabela 18 – Níveis do modelo CMM

Número do nível Nome do nível Características dos processos

Nível 1 Inicial Caótico Nível 2 Repetitivo Disciplinados Nível 3 Definido Padronizados Nível 4 Gerido Previsíveis Nível 5 Otimizante Melhoria contínua

Fonte: (Pádua, 2003)

Page 47: Ponto de Funcao

46

Tabela 19 – Áreas chaves de cada nível

Nível CMM Áreas Chaves

1 - Inicial ------------------------------------------------

2- Repetitivo

Gerenciamento de Requisitos Planejamento do Projeto de Software Acompanhamento e Supervisão do Projeto de Software Gerência de Subcontratação de Software Garantia da Qualidade de Software

Gerenciamento de Configuração de Software

3- Definido

Processos de engenharia e apoio Foco do processo organizacional Definição do processo organizacional Programa de treinamento Gerenciamento de software integrado Engenharia de produto de software Coordenação intergrupos Revisão conjunta

4- Gerido Qualidade do produto e do processo Gerenciamento quantitativo dos processos Gerenciamento da qualidade de software

5- Otimizante Melhoramento contínuo do processo Prevenção de defeitos Gerenciamento de mudanças tecnológicas Gerenciamento de mudanças no processo

O nível 2 está relacionado a um ambiente estável para que ocorra a repetição

de práticas de sucesso. A organização é capaz de assumir compromissos referentes a requis i-

tos, prazos e custos com alta probabilidade de cumpri- los Pádua (2003).

Quanto à área chave Planejamento do Projeto de Software, seu objetivo é

estabelecer planos razoáveis para a execução das atividades e gerenciamento do projeto de

software. É onde ocorre o cálculo de estimativas, estabelecimento de compromissos necessá-

rios e a definição de um plano de execução de trabalho. Uma das metas dessa área chave é

documentar as estimativas de software para o uso e acompanhamento no projeto de software.

Page 48: Ponto de Funcao

47

10 FERRAMENTA APF

10.1 FUNCIONALIDADES

A ferramenta APF tem como principal função auxiliar o desenvolvedor de

software no cálculo do tamanho funcional da aplicação que será desenvolvida. É usada duran-

te o planejamento de software e, com base nos dados inseridos pelo usuário, a ferramenta cal-

cula os pontos por função do software a ser desenvolvido.

A ferramenta APF também pode auxiliar o usuário na obtenção de estima-

tivas do modelo COCOMO II, como estimativa de esforço pessoas/mês e de tempo de desen-

volvimento em meses.

Figura 6 - Tela Principal Ferramenta APF

Page 49: Ponto de Funcao

48

Figura 7 - Tela Pontos por Função Não-Ajustados

Figura 8 - Tela Pontos por Função Ajustados

Page 50: Ponto de Funcao

49

10.2 COMO FOI DESENVOLVIDA

A ferramenta APF foi desenvolvida utilizando o ambiente de programação

visual Borland Delphi 6.0 e o banco de dados Borland Interbase 6.0, e o help da ferramenta

foi desenvolvido utilizando o Microsoft FrontPage.

A ferramenta se comunica com o banco de dados BD_APF.GDB por meio

de componentes do tipo IBDatabase, IBTransaction, IBDataSet e DataSource presentes no

form3 (conexão.pas), este é um form invisível do tipo DataModule. Conforme na figura abai-

xo:

Figura 9 - Funcionamento da Ferramenta APF

10.3 REQUISITOS MÍNIMOS DE FUNCIONAMENTO

Um computador precisa dos seguintes programas instalados para executar a

ferramenta APF:

? Borland Delphi 6.0;

? Borland Interbase 6.0;

? Windows 98 ou superior.

O computador precisa ter os requisitos mínimos de hardware para a execu-

ção dos programas acima citados para que possa executar a ferramenta APF sem problemas.

Page 51: Ponto de Funcao

50

11 CONCLUSÃO

O planejamento de projeto de software é muito importante, pois se reduz à

probabilidade de problemas no desenvolvimento do software. No entanto, é certo de que ape-

nas o planejamento não garante que o processo de software obtenha qualidade, ele é apenas

uma ferramenta que auxilia na obtenção desta qualidade.

Dentro do planejamento, a análise de pontos por função é uma técnica ex-

tremamente útil, pois permite não só medir o tamanho do sistema em termos da funcionalida-

de fornecida ao usuário, mas também estimar o seu tamanho em qualquer fase do seu ciclo de

vida, mesmo que os requisitos ainda não tenham sido detalhados.

Page 52: Ponto de Funcao

51

REFERÊNCIAS

(Alessandro, 2003) ALESSANDRO, A. Planejamento e Acompanhamento de Projetos – Os

Principais Problemas Típicos. Revista Developers, n. 81, ano 7, p. 15-16, maio, 2003.

(Azevedo 2003), Douglas José Peixoto de. Disponível na Internet: http://www.SoftwareMetrics.com

(29/05/2003)

(Boehm, 1981) BOEHM, BARRY W. Software Engineering Economics. New Jersey, Prentice Hall

PTR, 1981.

(Cordeiro, 2000) CORDEIRO M. A. Foco no Processo. Disponível em

http://www.pr.gov.br/batebyte/edicoes/2000/bb100/foco.htm

(Gustafson, 2003) GUSTAFSON D. A.. Engenharia de Software. Porto Alegre, Bookman, 2003.

(Haufe, 1999) HAUFE, M. I. Produtividade no desenvolvimento de software. In: Semana A-

cadêmica do Programa de Pós Graduação em Computação. RS, 1999.

(Maldonado, 2001) MALDONADO, J.C.; Weber, K.C. e ROCHA, A.R.C. Qualidade de Soft-

ware - Teoria e Prática , Makron Books, 2001.

(Pádua, 2003) PAULA FILHO, W. P. Engenharia de Software – fundamentos, métodos e pa-

drões. Rio de Janeiro, LTC, 2003.

(Prantoni, 2001) PRANTONI G. Estimativa de Tamanho de Software Baseada em Objetos,

2001 Disponível em http://www.choose.com.br/infochoose/artigos/viewer.asp?n=37&a=2

(Pressman, 1995) PRESSMAN, Roger S. Engenharia de Software. São Paulo, Makron Bo-

oks, 1995.

(Silva, 2000) SILVA I. J. de M.. Delphi 5 – Análise de Pontos por Função. Rio de Janeiro,

Book Express, 2000.

(Sommerville, 2003) SOMMERVILLE, I. Engenharia de Software. Addison Wesley, 2003.

(Trindade et al, 1999) TRINDADE A. L. P.; PESSÔA M. S. P.; SPINOLA M. M.. COCOMO

II uma compilação de informações sobre a nova métrica. In V Congresso Interbacional de

Page 53: Ponto de Funcao

52

Engenharia Informática da Universidade de Buenos Aires – Argentina. Disponível em

http://www.psphome.hpg.ig.com.br/downloads/cocomo2.pdf

(Vazquez et al, 2003) VAZQUEZ, C. E.; SIMÕES G. S.; ALBERT R. M. Análise de Pontos

por Função. São Paulo, Érica, 2003.

(Wiegers, 1999) WIEGERS K. E. Process Impact. Tradução Mauricio Aguiar. Disponível em

http://www.bfpug.org/fpug_rio/Newsletter/0101/Introducao_Metricas_Software.htm