Análise de Ponto de Função: estudo de caso para valoração de
custos no desenvolvimento de um sistema computacional em NITs

Function Point Analysis: case study for cost
evaluation in the development of a computational system in NITs

Keylha Santana Hüller

https://orcid.org/0000-0001-6082-0965

Mestra
em Propriedade Intelectual e Transferência de Tecnologia para a Inovação.
Universidade Federal do Vale do São Francisco (UNIVASF) – Brasil. [email-masked].

Dênis Ricardo Hüller

https://orcid.org/0000-0002-0078-5958

Mestre
em Engenharia Elétrica. Universidade Federal de Campina Grande (UFCG) –
Brasil. [email-masked].

Jorge Henrique Coelho Gomes

https://orcid.org/0000-0003-1130-8468

Graduando em Engenharia de Computação. Universidade Federal do Vale do São Francisco
(UNIVASF) – Brasil. [email-masked].

Vivianni
Marques Leite dos Santos

https://orcid.org/0000-0001-8741-8888

Doutora em Química. Universidade Federal de
Pernambuco (UFPE). Brasil.

[email-masked].

RESUMO

A valoração da tecnologia é uma
tarefa fundamental que propicia aos gestores dos Núcleos de Inovações
Tecnológicas (NITs) um maior poder de decisão nos
momentos de negociação de contratos de Transferência de Tecnologia (TT). Este
artigo tem por objetivo apresentar um estudo de caso acerca da utilização da
Análise de Ponto de Função (APF) como uma alternativa para valorar o
desenvolvimento de um sistema computacional, o Acadigitus,
uma plataforma tecnológica em fase final de desenvolvimento na Universidade
Federal do Vale do São Francisco (UNIVASF). O método de APF consiste em determinar
o tamanho de um programa, por meio da contagem das funcionalidades
identificadas pelo usuário. A metodologia, baseou-se na pesquisa exploratória e
descritiva, de abordagem quanti-qualitativa, sendo efetuado consultas em
portais de periódicos científicos, por meio CAPES e SCIELO, além de sites
institucionais com temas relacionados aos conceitos atrelados ao objeto de estudo.
Ademais, foram analisados os documentos técnicos do Acadigitus,
para fins de levantamento dos requisitos funcionais, no qual se calculou o
tamanho do sistema e, a partir disso, obteve-se o valor do custo, do prazo e do
esforço empregado no desenvolvimento da referida tecnologia. A aplicação da
análise de ponto de função descrita, trata-se de uma referência para valoração
de sistemas computacionais a partir do NIT/UNIVASF e outras instituições
congêneres que possuem esses tipos de ativos de propriedade intelectual.

Palavras-chave: Valoração. Programa de
Computador. Inovação.

ABSTRACT

The
valuation of technology is a fundamental task that provides the managers of the
Technological Innovation Centers (NITs) with a greater power of decision when
negotiating Technology Transfer (TT) contracts. This article aims to present a
case study about the use of Function Point Analysis (APF) as an alternative to
value the development of a computational system, Acadigitus,
a technological platform in the final stage of development at the Universidade Federal do Vale do São Francisco (UNIVASF).
The APF method consists in determining the size of a program, by counting the
functionalities identified by the user. The methodology was based on
exploratory and descriptive research, of  quantitative-qualitative approach,
carried out through consultations in portals of scientific journals, via CAPES
and SCIELO, and also  to institutional
sites with themes related to the concepts linked to the object of study. In
addition, the technical documents of Acadigitus were
analyzed in order to survey the functional requirements, in which the size of
the system was calculated and, from this, the value of
the cost, time and effort employed in the development of this technology was
obtained. The application of the function point analysis described, is a
reference for the valuation of computational systems from NIT/UNIVASF and other
similar institutions that have these types of intellectual property assets.

Keywords: Valuation. Computer Program. Innovation

Recebido em 12/11/2020.  Aprovado em 05/01/2021. Avaliado pelo
sistema double blind peer review. Publicado conforme normas da ABNT

https://doi.org/10.22279/navus.2021.v11.p01-18.1469

1 INTRODUÇÃO

O desenvolvimento de
tecnologias para inovação advém da necessidade de solucionar algum problema
demandado pela sociedade, momento em que surge a oportunidade propicia à
atividade inovativa, resultando na concepção de novos produtos e serviços
inseridos no mercado (GRÜTZMANN; ZAMBALDE; BERMEJO, 2019). De acordo com a Lei nº
13.243, de 11 de janeiro de 2016, a inovação é “introdução de novidade ou
aperfeiçoamento no ambiente produtivo ou social que resulte em novos produtos,
processos ou serviços” (BRASIL, 2016a, p. 2), que gera benefícios econômicos,
sociais e culturais.

Nas Instituições de
Ensino Superior (IES), a inovação é decorrente de pesquisas aplicadas que
despertam o interesse do setor produtivo, sendo os Núcleos de Inovações
Tecnológicas (NITs), os responsáveis pelo
fortalecimento dessas pesquisas, através da proteção legal e do gerenciamento
dos ativos de propriedade intelectual, atuando, ainda, na mediação dos
processos que envolvem a TT desenvolvida (DESIDÉRIO; ZILBER, 2014).

Com relação aos
processos de TT, os NITs desempenham um papel
preponderante, uma vez que são encarregados de transferir as invenções, por
meio de contratos e acordos, para os setores produtivos que, por sua vez,
disponibilizam novas tecnologias à sociedade (FERREIRA et
al., 2020). A própria Lei de Inovação atribui competências aos NITs, com intuito de favorecer as questões relativas à
inovação, além de incentivar a criação de um ambiente propício à interação
entre as Instituições Científicas e Tecnológicas e de Inovação (ICTs), indústria e governo, o que se configura na
denominação de hélice tripla (ROSÁRIO; LIMA, 2019).

Ao considerar o Art.
16, inciso X, da supracitada Lei, no qual define a responsabilidade dos NITs em negociar e gerir os acordos de TT, verifica-se a importância
da atividade de valoração de tecnologia, subsidiando a negociação de contratos
de transferência, através do fornecimento de informações essenciais à determinação
do valor justo de uma tecnologia, o que possibilita o ganha-ganha a todos os
envolvidas no processo (QUINTELLA; TEODORO; FREY, 2019).

Souza (2009, p. 65) conceitua a valoração como método
que “consiste em quantificar o valor monetário de uma tecnologia, visando a sua
comercialização e/ou seu licenciamento a terceiros”. A
valoração pode ser realizada por meio de três abordagens distintas: Custo;
Mercado e; Renda. O custo, considera o valor gasto na produção da
tecnologia, relacionados a recursos materiais, físicos e humanos. “Esse método,
baseia-se na concepção de que o esforço de PD&I deve, no mínimo, ser
ressarcido quando da negociação para a cessão ou o licenciamento de uma
tecnologia” (QUINTELLA et al., 2019, p. 152).

A abordagem pelo
mercado, segundo Hong et al., (2010), é um método que utiliza
informações sobre transações anteriores de ativos semelhantes, em que os dados
servem como base para obter o valor estimado por meio de um processo de
comparação com outras tecnologias do mercado. Em se tratando da Renda, realiza-se
uma estimativa de valor baseada no potencial de renda, a partir da
comercialização ativo, no qual são auferidos os lucros com a sua exploração (TUKOFF-GUIMARÃES et al., 2014).

Entretanto, apesar dessas
abordagens, Ernst, Legler e Lichtenthaler
(2010), apontam a atividade de valoração como grande desafio, pois, não existe
uma receita genérica que possa se aplicar a todas as situações, sendo necessária
a utilização de métodos complementares ou ferramentas adicionais para se determinar
o valor de um ativo de propriedade intelectual, em especial, quando se trata de
tecnologias em desenvolvimento, tendo em vista diversas variáveis que levam a
incertezas relativas ao seu uso no futuro.

Os
mesmos autores, ao tratar de valoração de patentes, afirmam que muitas técnicas
existentes podem simplificar excessivamente a realidade do ativo a ser valorado,
bem como podem complicar, de modo que, ambas as possibilidades culminam em uma
aplicação prática limitada. “A complexidade na valoração de ativos intangíveis
reside na escolha do melhor método e, também, na seleção dos parâmetros para a
construção do fluxo de caixa esperado para a tecnologia” (CARVALHO et al.,
2019, p. 8).

Por outro lado, estudos
anteriores apresentam uma forte tendência em se adotar a abordagem pela renda,
através de técnicas como Fluxo de Caixa Descontado (FDC), Teoria de Opções
Reais (TOR), Modelo de Precificação de Ativos Financeiros (CAMP), entre outros.
Contudo, observa-se, também, a aplicação desses métodos voltados à valoração de
patentes, não sendo encontrado na literatura, as mesmas aplicações em outros
ativos, a exemplo do Registro de Programa de computador (RPC). Para esse,
tem-se como alternativas a abordagem de mercado e custo.

Na valoração de RPC,
verifica-se a possibilidade da abordagem de mercado, quando existem outros softwares
similares em comercialização. Mas, ao se tratar de programa ou sistema
computacional novo, a atividade de valorar fica prejudicada, por ausência de
parâmetros necessários à comparação. Quintella et
al., (2019) argumentam que para uma invenção radical, cujo mercado ainda
não está formado, é difícil encontrar dados confiáveis para aplicação da
abordagem de mercado. Além disso, é importante mencionar que cada software
possui características intrínsecas ao contexto de desenvolvimento e, apesar da
possibilidade de se encontrar produtos idênticos no mercado, dificilmente irão
atender, de modo satisfatório, todas as necessidades do público consumidor.

Deste modo,
entende-se que a abordagem pelo custo para valorar RPC pode ser uma opção
viável. Entre os métodos utilizados nessa abordagem, destaca-se o método de
Análise de Ponto de Função (APF), no qual leva em conta a determinação do
tamanho de um programa de computador, realizando a contagem de suas
funcionalidades na perspectiva do usuário (GUIMARÃES,
2017). Grosso modo, calcula-se o valor do programa com base nas
funcionalidades percebidas pelo usuário que irá manipular o sistema.

Em vários projetos
de desenvolvimento de um sistema computacional, o tamanho do programa, o
esforço e o custo são aspectos essenciais no planejamento de cronogramas de
desenvolvimento para alcançar o resultado desejado, sendo a APF é um método
preciso e confiável, capaz de atender a esse propósito (HILLMAN; SUBRIADI, 2019).
A técnica em si é derivada de uma série de fases, usando um conjunto
padronizado de critérios básicos, em que para cada função é atribuído um índice
numérico, conforme o seu tipo e complexidade (IFPUG,
2020).

O Tribunal de Contas
da União (TCU) do Brasil recomenda, por meio do o
Acordão nº 1.782/2007, a técnica de APF para efetuar pagamentos de serviços de
desenvolvimento e manutenção de programa de computador (BRASIL, 2018a), ou
seja, considera a referida técnica adequada para precificar programas de
computador ou softwares. De igual modo,
entidades governamentais em outros países, a exemplo da Coréia do Sul, adotam a
APF como método padrão para medir o tamanho funcional e o custo de
desenvolvimento dos softwares (KANG; LEE, 2018).

Adicionalmente, publicações
contendo estudos acerca da aplicação de métodos para valoração destes tipos de
intangíveis contribuem com o desenvolvimento das atribuições dos gestores de
ambientes de inovação, tal como os NITs nas
Universidades, e também para o desenvolvimento de
novos métodos. “Conceitos e exemplos práticos devem ser utilizados como
ferramenta para identificar, mensurar e reconhecer ativos não corpóreos
(intangíveis) vinculados à capacidade inventiva, dispostos no ambiente de
negociação” (QUINTELLA et al., 2019, p. 142).

Diante do exposto,
este artigo teve por objetivo apresentar um estudo acerca da utilização da APF na
valoração de um sistema computacional, o Acadigitus,
produto tecnológico que está em fase final de desenvolvimento na Universidade
Federal do Vale do São Francisco (UNIVASF), para gerenciar os documentos do
assentamento acadêmico dos discente e expedir o diploma digital dos egressos.

2 FUNDAMENTAÇÃO TEÓRICA

Na expectativa de melhor compreensão sobre o
método de APF, são descritos alguns conceitos básicos acerca das etapas
necessárias à utilização do referido método, proporcionando ao leitor um
entendimento simples, mas suficiente para aplicá-lo em diversos contextos. Por
questões de padronização, neste trabalho, os termos softwares, programa,
programa de computador, sistema, sistema computacional e aplicação serão
utilizados como sinônimos.

De acordo com Hillman
e Subriadi (2019), a APF
é reconhecida e amplamente utilizada entre os profissionais, cuja técnica se
tornou um padrão industrial para estimar o custo, o esforço e o tempo
necessário ao desenvolvimento, melhoria e implementação de um software.
Nesse método, efetua-se uma contagem das funcionalidades solicitadas pelo
usuário do sistema, focando, explicitamente, nas suas necessidades. “É um
método compreensível pelo usuário do software, independente da
tecnologia aplicada” (CASTRO; HERNANDES, 2016, p. 59).

Assim sendo, retomando as definições da AFP é
importante mencionar que essa é uma técnica padronizada pela Internacional Function Point Users Group (IFPUG), no qual
as regras, os procedimentos e as práticas de contagem são definidas pelo Manual
de Práticas de Contagem de Ponto de Função (IFPUG, 2010).
Outrossim, a padronização do método adere a norma ISO/IEC
20926 (ISO; IEC, 2009).

A
determinação do tamanho do software é o primeiro passo para conseguir obter
a estimativa de custo, tempo e esforço empregado na execução do projeto. Nessa
fase é necessário conhecer a unidade a ser medida, por meio do documento
inicial de requisitos funcionais do sistema e, a partir disso, prosseguir com
as etapas de contagem apresentadas pela Figura 1.

Figura 1 – Etapas de contagem de APF

Fonte: Adaptado de Santin
(2014).

2.1 Etapa 1 - Determinação do tipo de contagem

A definição do tipo
de contagem visa nortear todas as etapas posteriores. Nessa etapa,
identifica-se as especificidades do sistema que será valorado. Conforme Bomfim e Andrade (2015) O tipo de contagem é
determinado pelo propósito do projeto, havendo três possibilidades, quais
sejam:

a) Projeto de
desenvolvimento: consiste em projeto novo, em que é realizada a contagem de
funções na fase inicial, estimando-se um valor a partir do levantamento de
requisitos, até a instalação do programa;

b) Projeto de
melhoria: mede as modificações realizadas em um programa existente, inclui-se
adição, exclusão e atualizações de funções;

c) Projeto de
aplicação: refere-se a contagem das funcionalidades de uma aplicação pronta, no
qual se avalia as funcionalidades correntes providas aos usuários finais.

2.2 Etapa 2- Escopo e Fronteira da Aplicação

O escopo e a
fronteira de aplicação, representam as funções que serão incluídas na contagem.
Conforme Guimarães (2017, p. 39), “a fronteira é a
interface conceitual que separa logicamente a aplicação que está sendo medida e
o mundo externo”.  Em se tratando do
escopo, pode-se dizer que é o elemento que norteia a contagem a ser realizada. Vazquez, Simões e Albert (2013) afirmam que o
escopo pode abranger todas as funcionalidades do sistema ou apenas algumas
específicas de usuários. A título de exemplificação, tem-se a medição baseada
nas funções do usuário com permissão de administrador do sistema.

2.3 Etapa 3- Contagem de função do Tipo Dado

De acordo com Martino
et al. (2016), a função do Tipo dado se refere a entidades lógicas
relacionadas ao armazenamento de informações. A função é caracterizada por dois
grupos de arquivos lógicos, a saber: Arquivo Lógico Interno (ALI), cujo
objetivo principal é armazenar dados mantidos pela aplicação. E o Arquivo de
Interface Externa (AIE), são arquivos lógicos que são referenciados pelo
sistema, mas estão fora da sua fronteira de aplicação, ou seja, quando o
sistema acessa o dado de outro sistema (PINHEIRO, 2017).

Segundo Gomes (2017) os arquivos lógicos são medidos, conforme
um grau de complexidade e de contribuição. A complexidade de cada ALI e AIE é
determinada pela quantidade de Tipo de Dado (TD)[1]  e Tipo
de Registro (TR)[2], sendo classificada em baixa, média ou alta,
ao passo que a contribuição converte o grau de complexidade em pontos de função
(PF), conforme padrão (Quadro 1) estabelecido pela IFPUG (2010).

Quadro 1 – Grau de
complexidade e contribuição dos arquivos ALI e AIE

Complexidade

ALI e AIE

Contribuição
em ponto de função

TD

TR

< 20

20 a 50

>50

ALI

AIE

1

Baixa

Baixa

Média

Baixa

7

5

2 a 5

Baixa

Média

Alta

Média

10

7

>5

Média

Alta

Alta

Alta

15

10

Fonte: Adaptado de IFPUG (2010).

2.4 Etapa 3- Contagem de função do Tipo Transação

Para Guimarães
(2017), a contagem do Tipo Transação corresponde aos processos elementares que
fornecem as funcionalidades ao usuário. Existem três tipos de transações:

a) Entradas Externas
(EE):  é um processo elementar, cujo
objetivo de uma EE é manter um ou mais arquivos lógicos internos. Pode-se dizer
que são as funções relativas ao cadastro, a exemplo de adicionar, remover,
alterar, entre outros.

b) Saídas Externas (SE):
responsável por apresentar os dados ao usuário, por meio de lógica de
processamento que não seja, apenas, a de recuperação de informações, devendo
conter, obrigatoriamente, cálculos ou fórmulas matemáticas para criar dados
derivados. Como exemplo tem-se os relatórios que possuem totalizações e as
informações em formatos de gráficos.

c) Consultas
Externas (CE): procedimento que visa apresentar os dados ao usuário, através da
recuperação das informações. Na CE não é realizado processamento de dados com cálculos
matemáticos. A CE possibilita a geração de relatórios simples, isto é, sem
totalização de dados.

Do mesmo modo que na
contagem do Tipo Dado, na contagem de função do Tipo Transação, também é
especificado o grau de complexidade e de contribuição. Santin
(2014), afirma que a complexidade é determinada por meio da contagem de Tipos
de Dados (TD) que a transação manipula e dos Arquivos Referenciados (AR)[3], sendo a contribuição responsável pela
transformação do grau de complexidade em PF, em conformidade com o padrão
(Quadro 2) instituído pelo IFPUG (2010).

Quadro 2 – Grau de
complexidade e contribuição dos arquivos EE, SE, CE

Complexidade

EE

Complexidade

SE e CE

Contribuição em ponto de função

TD

TD

AR

< 5

5 a 15

>15

AR

< 6

6 a 19

>19

EE

SE

CE

< 2

Baixa

Baixa

Média

< 2

Baixa

Baixa

Média

Baixa

3

4

3

2

Baixa

Média

Alta

2 a 3

Baixa

Média

Alta

Média

4

5

4

>2

Média

Alta

Alta

>3

Média

Alta

Alta

Alta

6

7

6

Fonte: Adaptado de IFPUG (2010).

2.5 Etapa 4- Contagem dos pontos de função não
ajustados

De acordo com Meller (2002), depois de definidas todas as
funções da aplicação, bem como suas respectivas complexidades, calcula-se os pontos
de função não ajustados. Esse é caracterizado, segundo Vazquez, Simões e Albert (2013), pela
contagem dos requisitos especificados pelo usuário, em que se efetua a soma dos
valores obtidos nas funções do Tipo Dado e do Tipo Transação.

2.6 Etapa 5- Fator de ajuste

O fator de ajuste é baseado
em um conjunto de informações que contempla 14 características gerais do sistema
(GSC, do inglês, General System Characteristics)
listados no Quadro 3.

Quadro 3 - Características
Gerais do Sistema

Características Gerais do Sistema

1

Comunicação
de Dados

8

Atualização
On-line

2

Processamento
Distribuído de dados

9

Processamento
Complexo

3

Performance

10

Reutilização

4

Configuração
muito usada

11

Facilidade
de instalação

5

Taxa
de transação

12

Facilidade
operacional

6

Entrada
de dados On-line

13

Múltiplos
sites

7

Eficiência
para o usuário final

14

Facilita
mudanças

Fonte: Adaptado de Raju
e Krishnegowda (2013)

As características
do GSC possuem descrições vinculadas a si que ajudam a determinar o grau de
influência. As mesmas descrições podem ser encontradas em produções de autores
como: Lokan (2000); Pratiwi
(2013) e; Kang e Lee (2018), cujo grau de influência de
cada GSC é representado por um indicador numérico que varia de zero à cinco, como descrito abaixo:

0 – “Não presente ou
sem influência”;

1 – “Influência
acidental”;

2 – “Influência
moderada”;

3 – “Influência
média”;

4 – “Influência
significativa”;

5 – “Influência
forte em todo o processo”.

Entretanto, a atribuição
do grau de influência é de caráter subjetivo e sua acurácia está atrelada a
experiência da pessoa designada para avaliar a complexidade do sistema,
mediante as 14 características. Por este motivo, o valor do fator de ajuste, que
depende dos valores designados no GSC, pode apresentar uma variação de +/- 35%
no tamanho do sistema (BRASIL, 2018a).

Sobre
essa questão, Morrow; Wilkie e Mcchesney
(2014), informam que o cálculo do fator de ajuste é amplamente criticado,
tendo em vista a ausência de base teórica sólida, bem como falta de informação
sobre como os pontos de função estão relacionados ao esforço de
desenvolvimento. Adicionalmente, destaca-se o entendimento do TCU, Acórdãos nº
2.348/2009 e 1.647/2010, que determinam a desconsideração do cálculo do fator
de ajuste na contagem de pontos de função (BRASIL, 2018a).

Por
outro lado, Lokan (2000) relatou uma investigação
empírica sobre o uso e valor prático do fator de ajuste, através das análises
dos GSC, de uma coleção de 235 projetos classificados e separados por sua área
de atuação. No estudo, foi observado que os registros dos GSC podem auxiliar a
compreender os dimensionamentos dos custos do projeto e servem como base para
trabalhos semelhantes. O autor apresentou, ainda, uma análise acerca dos
fatores de ajuste existentes nos projetos, no qual extraiu uma média e mediana,
obtendo-se os valores de 1,01 e 1,0, respectivamente. A partir disso, verificou-se
por meio da curva de distribuição normal, um pico atingido em 1,0, levando o autor
a constatar que o fator de ajuste com valor igual a 1,0 é adequado para se
aplicar na estimativa de contagem de pontos de função.

2.7 Etapa 6 - Cálculo numérico dos pontos de função
ajustados

Conforme Santin (2014), a definição
dos pontos de função ajustados é a última etapa da contagem, momento que é
determinado o tamanho funcional do software. Para tanto, emprega-se uma
equação específica a cada tipo de contagem realizada; isto é, a escolha do tipo
vai depender da finalidade do projeto que está sendo medido, podendo ser:
Desenvolvimento; Melhoria ou Aplicação.

2.8 Estimativa
de Esforço

Segundo Wolfart
(2012), o esforço é entendido como a quantidade de trabalho empregado na
execução de um projeto, sendo expresso por um total de horas, dias, semanas ou
meses gastos por um grupo de pessoas na realização das atividades do projeto. Para
Hazan e Staa (2005), o
esforço é comumente estimado, por meio de um Modelo Simplificado de Estimativas,
no qual se baseia em dois parâmetros: tamanho do software e índice de
produtividade em horas/pontos de função.

Brasil (2018a), argumenta que o
índice de produtividade depende de fatores que vão desde a escolha da linguagem
de programação, até a complexidade do domínio, segurança, desempenho, entre
outros e, por isso, é importante que o órgão ou entidade tenha a sua própria
tabela de produtividade, baseada no histórico dos projetos desenvolvidos.
Ademais, Lopes e Braga (2011), sugere usar
como referência o índice de produtividade mínima para desenvolvimento e
manutenção de sistemas, estabelecido pela Agência Nacional de Cinema (Ancine), apresentada no Quadro 4.

Quadro 4 – Índice de produtividade mínima da Ancine

Desenvolvimento
e manutenção de sistemas

Tecnologia

Produtividade
mínima

Java

15
h/PF

ASP (Script e Java script)

10
h/PF

PHP

11
h/PF

JSP

13
h/PF

HTML

07
h/PF

Cold
Fusion

11
h/PF

Delphi

09
h/PF

Crystal
reports

09
h/PF

PL/SQL

09
h/PF

Visual
Basic

09
h/PF

Fonte: Lopes e Braga (2011).

Vale ressaltar que esse índice
serve, apenas, como parâmetro para embasar a estimativa de esforço, entretanto,
o ideal é que a instituição utilize dados internos, como número de horas
alocadas em projetos elaborados pela própria equipe, visto que, conforme
ressaltado por Lopes e Braga (2011), cada empresa tem sua realidade específica,
com funcionários, processos e consequentes produtividades diferenciadas.

2.10
Estimativa do Prazo

Por meio das informações acerca do tamanho e o esforço
empregado no desenvolvimento de um software, é possível prever o seu
prazo de conclusão. De acordo com Wolfart (2012), a
estimativa de prazo é efetuada, de modo simplificado, pela razão entre o
esforço previsto (em número de horas) e a quantidade de recursos disponíveis na
execução do projeto. O mesmo autor argumenta, que a definição do prazo, também,
auxilia no planejamento das atividades inerentes ao projeto, principalmente, no
delineamento da equipe de elaboração, bem como dos recursos necessários à
concretização da tecnologia.

Adicionalmente, Gomes (2003 apud WOLFART, 2012, p. 25)
faz uma ressalva com relação ao tamanho da equipe e o prazo, informando que “ao estimar o tempo de duração do projeto, deve-se
tomar cuidado com a relação tempo/pessoas, pois se um projeto for estimado em
dez pessoas-mês e há cinco pessoas disponíveis, não necessariamente, ele levará
dois meses para ser concluído”. Vazquez, Simões e Albert (2013), ao realizarem uma análise empírica, demostram que
na estimativa de prazo não existe linearidade.

2.9
Estimativa de Custo

Para Freire (2008), o custo em projetos de software é,
em geral, proporcional ao esforço aplicado no seu desenvolvimento, sendo
associado a fatores como homens-mês ou homens-hora. Nesse sentido, faz-se
necessário ter o conhecimento acerca do valor da hora de trabalho da equipe de
desenvolvimento e o valor de um ponto de função para a empresa.

3
METODOLOGIA

O presente estudo
possui abordagem quanti-qualitativa, voltado para elementos que envolvem uma
dada realidade, a fim de intervir em situações insatisfatórias e mudar condições
entendidas como transformáveis (CHIZZOTTI, 2009). Trata-se
de uma pesquisa exploratória e descritiva, pois buscou obter maior
familiaridade com o problema, tornando-o mais explícito, bem como inclui o
detalhamento acerca da aplicação de um método de análise (GIL,
2002). Também foram realizadas consultas em periódicos científicos, através
da CAPES e SCIELO, além de sites institucionais com temas relacionados aos conceitos
atrelados ao objeto de estudo.

Quanto ao tipo, caracterizou-se
como estudo de caso, em razão de envolver a investigação de um fenômeno em seu
contexto real (YIN, 2015), no qual apresentou a
aplicação prática da APF como método de valoração a ser empregada no sistema
computacional intitulado Acadigitus, desenvolvido por
meio de pesquisa aplicada na UNIVASF, para fins de gerenciamento da
documentação acadêmica dos discentes e expedição do diploma digital do egresso.

Para a valoração do Acadigitus usando o APF, buscou-se entender o seu modelo
relacional e identificar os casos de usos e os tipos de funções executadas, na
perspectiva dos usuários. A partir disso, aplicou-se o referido método, visando
a estimativa de custo, prazo e esforço empregado no desenvolvimento do projeto,
conforme etapas apresentadas na Figura 2.

Figura 2 – Método
de APF para o Acadigitus

Fonte: Elaborado
pelos autores (2020).

Incialmente, realizou-se o
levantamento sobre os requisitos funcionais do sistema, em que foram identificadas
todas as necessidades apontadas pela Secretaria de Registro e Controle Acadêmico
(SRCA)/UNIVASF, a fim de mapear as principais características do sistema, cuja
missão é transpor do meio físico, os documentos do assentamento acadêmico do
discente, para o meio totalmente digital, alicerçado na obrigatoriedade
estabelecida pelo Ministério da Educação, por meio da Portaria nº 315, de 04 de
abril de 2018 (BRASIL, 2018b) e Portaria nº 330, de
05 de abril 2018 (BRASIL, 2018c). A partir das informações obtidas, deu-se
início o processo de contagem, conforme etapas descritas a seguir:

3.1 Determinação
do tamanho do sistema

a)
Para o tipo de contagem, escolhe-se o Projeto de
Desenvolvimento, por se tratar de um sistema computacional novo, no qual foram
analisadas as funções, desde o estágio inicial do projeto, até a sua instalação
definitiva.

b)
Com relação ao escopo, opta-se por contar as funcionalidades
destinadas ao usurário com perfil do Administrador Servidor, por deter todas as
permissões operacionais do sistema. Quanto a fronteira, considera-se a
possibilidade de acesso a bases de dados externas, tendo em vista a interação com
outros sistemas da Instituição, no qual compartilham informações.

c)
Em se tratando das funções do Tipo Dado e Transação, analisou-se
o modelo relacional do sistema e, então, identificou-se as funções de dados com
ALIs e AIEs, bem como as
funções de EE, CE, SE. A contagem das funções do tipo Dado e Transação foram baseadas
nos graus de complexidades e contribuições, apresentadas nos Quadros 1 e 2, seção
2.3 e 2.4, deste trabalho.

d)
No que diz respeito a contagem dos pontos de função não
ajustados, realiza-se o somatório das funções de Dados e Transações (Equação 1
- Adaptado de Lopes e Braga, 2011).

UFP
= SFTD + SFTT

(1)

Onde:

UFP: Número de pontos de função não
ajustados das funções disponíveis aos usuários;

SFTD: Soma das funções do Tipo da Dado;

SFTT: Soma das funções do Tipo Transação.

e)
Para o fator de ajuste, utiliza-se o número 1,0,
tomando por base o estudo apontado por Lokan (2000), bem
como os Acórdãos do TCU nº 2.348/2009 e 1.647/2010 que recomendam a desconsideração
do fator de ajuste (BRASIL,2018a), conforme descrito na seção 2.6, deste
trabalho.

f) No cálculo dos Pontos de
função ajustados, define-se o tamanho do sistema, no qual se emprega a (Equação
2 – IFPUG, 2010), específica para a contagem do tipo Projeto de
Desenvolvimento.

DFP = (UFP + CFP) x VAF

(2)

Onde:

DFP: Tamanho do projeto de
desenvolvimento (número total de pontos de função);

UFP: Número
de pontos de função não ajustados das funções disponíveis aos usuários;

CFP: Total de
pontos de função não ajustados das funções de conversão;

VAF: Valor do
fator de ajuste.

De
acordo com Vazquez, Simões e Albert (2013), a função
de conversão (CFP) é utilizada quando existe a necessidade de importar dados de
um sistema antigo para o novo sistema. Assim sendo, no processo de contagem dos
pontos de função do Acadigitus, o valor de conversão
não será aplicado, uma vez que não haverá migração de dados de outros softwares
da Universidade.

3.2
Estimativa de Esforço, prazo e custo

No cálculo da estimativa de esforço
(Equação 3 – com nomenclatura adaptada a partir de Aranha e Cardoso, 2017),
considera-se o número total de pontos de função (DFP) e o índice de
produtividade (IP), relativo à linguagem PHP, 11 h/PF, conforme o Quadro 4, seção
2.8, deste trabalho.

Esforço
= DFP x IP

(3)

A
estimativa do prazo (Equação 4 – Wolfart, 2012) é determinada
com base no valor do Esforço, dividido pela quantidade de recurso disponível,
ou seja, o número de profissionais envolvidos no desenvolvimento do sistema. Para
a determinação do prazo necessário à elaboração do Acadigitus,
considera-se como recurso, um servidor Técnico Administrativo em Educação (TAE),
com cargo de Analista de Sistema, em regime de dedicação exclusiva, cuja carga
horária é 40h semanais ou 160h mensais.

Prazo
= Esforço/Quantidade de recurso

(4)

O custo (Equação 5 - Adaptado de
Brasil, 2018a), obtém-se por meio da multiplicação do valor correspondente o
número total de pontos de função (DFP) com o custo de um ponto de função (CPF)
que, por sua vez, abrange o custo da hora de trabalho do Analista de Sistema pelo
índice de produtividade. Neste trabalho, optou-se pela linguagem PHP, sendo o
índice estabelecido em 11h/PH (LOPES; BRAGA, 2011). Assim, CPF = (C/H x 11h/
PF).

Custo
= DFP x CPF

(5)

4 RESULTADOS
E DISCUSSÃO

Ao considerar os conceitos
relativos ao uso da APF, buscou-se fazer o levantamento dos requisitos
funcionais do sistema e, então, foram iniciadas as etapas de contagem das
funções, visando a estimativa do custo, esforço empregado no desenvolvimento e
o prazo para conclusão do projeto. Com as informações obtidas por parte dos
servidores da SRCA e Analista responsável pelo desenvolvimento do sistema,
deu-se início a valoração por APF, conforme as seguintes etapas:

4.1
Identificação do tipo de contagem, escopo e a fronteira da aplicação

Como
primeira etapa, identificou-se o tipo de contagem a ser realizada no projeto,
sendo efetuada para o Acadigitus, o tipo denominado Projeto
de Desenvolvimento, por se tratar de um sistema novo em estágio de produção na
UNIVASF. Em face disso, projetou-se um modelo (Figura 3), a fim de delimitar o
perfil dos usuários do sistema e definir o escopo e a fronteira da aplicação, segunda
etapa, especificada na contagem de pontos de função da estimativa de APF.

Figura 3 – Perfis
de usuários do Acadigitus

Fonte: Elaborado
pelos autores (2020).

O
modelo (Figura 3) exibe, de modo simplificado, as interfaces do projeto, cujos
perfis serão destinados ao Administrador Master, designado como usuário que
possui a permissão de fornecer todos os acessos ao sistema, entre outras
configurações. O segundo perfil é o de Administrador Servidor, caracterizado
pelo usuário do órgão que irá gerenciar o sistema. Os outros dois perfis serão
fornecidos, respectivamente, ao usuário Servidor Padrão e Discente que possuem permissão,
apenas, de consultas, sem que haja possibilidade de intervenções ou
modificações no sistema.

Assim, para o escopo de
contagem utilizada neste projeto, levou-se em conta as funcionalidades
destinadas ao perfil do Administrador Servidor, uma vez que contempla todas as
tarefas desempenhadas pelo Acadigitus, tanto no atendimento
das demandas do acervo acadêmico, quanto na emissão do diploma digital. Assim,
evita-se contagens de modo redundante.

Em se tratando da fronteira,
considerou-se a possibilidade de se utilizar informações de fora da aplicação,
tendo em vista a necessidade de integração futura do Acadigitus
com outros sistemas da Instituição. Deste modo, o modelo relacional foi
construído, considerando a comunicação entre bases de dados diferentes.

4.2 Contagem
das funções do Tipo Dado e do Tipo Transação

Nesta
etapa, ao contemplar como escopo o perfil de Administrador Servidor, efetuou-se
o procedimento de contagem (Quadro 5 e 6), baseando-se nos fatores de
complexidade e contribuição das funções do Tipo Dado TD e Transação.

Quadro 5 – Funções do Tipo Dado

Descrição

Tipo de processo

Quantidade de TD1

Quantidade de TR2

Complexidade

Contribuição

Usuários

ALI

5

2

Baixa

7

Instituições

ALI

31

1

Baixa

7

Documentos

ALI

11

3

Baixa

7

Registros

ALI

71

5

Alta

15

Endereços

ALI

8

1

Baixa

7

Subtipos de
documentos

ALI

2

1

Baixa

7

Código
de Classificação

ALI

4

1

Baixa

7

Cursos

ALI

14

2

Baixa

7

Discentes

AIE

40

2

Média

7

Vínculos

AIE

28

2

Média

7

Cursos
sistema registro

AIE

4

1

Baixa

7

Soma das
funções do Tipo Dado (SFTD)

85

Nota: 1TD
– Tipo de Dado; 2TR – Tipo de Registro

Fonte:
Elaborado pelos autores (2020).

A partir da contagem das funções
do Tipo Dado, obteve-se um total de 85 pontos.  No Acadigitus, os ALIs foram criados para atender os requisitos funcionais do
sistema, ao passo que, os AIEs representam os arquivos
que não correspondem a fronteira da aplicação, uma vez que são informações pertencentes
a outro banco de dados, utilizado para cadastrar os discentes ingressantes da
Instituição. Deste modo, à medida que os dados são alimentados pelo sistema de
ingresso, o sistema Acadigitus realiza as consultas,
mas sem a possibilidade de intervenções ou atualizações. Esse padrão foi
adotado, a fim de manter a interoperabilidade ente os sistemas que atuam, tanto
no registro acadêmico, quanto na documentação acadêmica.

Quadro 6 – Funções do Tipo
Transação

Descrição

Tipo
de processo

Quantidade
TD

Quantidade
AR3

Complexidade

Contribuição

Cadastrar perfil para Discente

EE

4

2

Baixa

3

Cadastrar Servidor

EE

7

2

Média

4

Modificar dados do Servidor

EE

7

2

Média

4

Excluir Servidor

EE

3

2

Baixa

3

Adicionar Documentos

EE

8

1

Baixa

3

Cadastrar Curso

EE

19

2

Média

4

Modificar Curso

EE

19

2

Média

4

Excluir Curso

EE

3

1

Baixa

3

Cadastrar Instituição

EE

34

1

Média

4

Modificar Instituição

EE

34

1

Média

4

Excluir Instituição

EE

3

1

Baixa

3

Modificar Documento Matrícula

EE

10

3

Alta

6

Excluir Documento Matrícula

EE

3

1

Baixa

3

Modificar Processo

EE

11

3

Alta

6

Excluir Processo

EE

3

1

Baixa

3

Modificar Solicitação Diversa

EE

11

3

Alta

6

Excluir Solicitação Diversa

EE

3

1

Baixa

3

Cadastrar Cód. de Classificação

EE

7

1

Baixa

3

Modificar Cód. de Classificação

EE

7

1

Baixa

3

Excluir Código de Classificação

EE

3

1

Baixa

3

Cadastrar Subtipo Documento

EE

5

1

Baixa

3

Modificar Subtipo Documento

EE

5

1

Baixa

3

Excluir Subtipo de Documento

EE

3

1

Baixa

3

Excluir Documento Relatório

EE

3

1

Baixa

3

Cadastrar Livro

EE

8

2

Média

4

Modificar Livro

EE

7

2

Média

4

Excluir Livro

EE

3

1

Baixa

3

Fechar Livro

EE

5

1

Baixa

3

Modificar Registro

EE

23

5

Alta

6

Excluir Registro

EE

3

1

Baixa

3

Consultar Servidores

CE

9

2

Média

4

Consultar Discente

CE

14

1

Baixa

3

Consultar Cursos

CE

11

2

Baixa

3

Visualizar Curso

CE

20

2

Média

4

Consultar Instituições

CE

9

1

Baixa

3

Visualizar Instituição

CE

34

1

Média

4

Consultar Documento Matrícula

CE

9

2

Média

4

Visualizar Documento Matrícula

CE

6

3

Baixa

3

Consultar Processos

CE

10

2

Média

4

Visualizar Processo

CE

7

3

Média

4

Consultar Solicitações Diversas

CE

10

2

Média

4

Visualizar Solicitação Diversa

CE

7

3

Média

4

Consultar Cód. de Classificação

CE

9

1

Baixa

3

Consultar Subtipo Documento

CE

7

1

Baixa

3

Visualizar Documento Relatório

CE

10

5

Alta

6

Consultar Livros

CE

8

1

Baixa

3

Visualizar Livro

CE

5

2

Baixa

3

Consultar Registros

CE

11

5

Alta

6

Visualizar Registro

CE

23

5

Alta

6

Registrar Diploma

SE

51

5

Alta

7

Gerar Relatório Documento

SE

12

3

Média

5

Gerar Livro

SE

25

1

Média

5

Registro Coletivo

SE

23

5

Alta

7

Soma das funções do tipo transação (SFTT)

208

Nota: 3AR – Arquivo Referenciado

Fonte:
Elaborado pelos autores (2020).

A contagem das funções do Tipo Transação, resultou em 208 pontos caracterizados
pelas operações de Entradas, Saídas e Consulta Externas, executadas pelo perfil
de Administrador Servidor do Sistema. Com isso, definiram-se os pontos de
função não ajustados (UFP), aplicando-se a Equação 1, cujo valor foi determinado
em 293 pontos de função.

Na sequência, efetuou-se o cálculo relativo aos pontos de funções
ajustados (DFP), Equação 2, em que se considera a quantidade de UFP, somado ao
número de pontes de função de conversão (CFP) e multiplicado pelo fator de
ajuste (VAF). Na contagem do Acadigitus, a CFP não
foi aplicada, uma vez que não haverá necessidade de migração de dados de outro
sistema. Assim como, para o VAF, admitiu-se o valor igual a 1,0, tendo o
tamanho funcional do software definidor por: DFP = (293 + 0) x 1 = 293
pontos de função.

4.3 Esforço,
prazo e custo

Devido ao
sistema Acadigitus
ser desenvolvido em linguagem de programação Hypertext Preprocessor
(PHP), optou-se por adotar o índice de produtividade (IP = 11h/PH),
estabelecido pela Ancine (LOPES; BRAGA, 2011). Deste
modo, o esforço empregado no desenvolvimento do sistema foi estimado pelo
produto entre o valor do DFP e o IP (Equação 3), correspondendo a:

Esforço = 293 x 11 =
3.223h.

Ademais,
considerou-se como responsável pelo desenvolvimento do Sistema, um Servidor
Analista da Instituição, com carga horária de trabalho equivalente a 40 horas
semanais, ou 160 horas mensais. Dessarte, a estimativa de prazo (Equação 4) para duração do
projeto foi determinada por meio da razão entre o Esforço e a quantidade de
horas envolvidas no desenvolvimento, implicando em:

Prazo
= 3.223h/ 160h = 20.144.

Com isso, observa-se
que o sistema poderá ser finalizado dentro de um prazo de, aproximadamente, 20
meses e 3 semanas, levando em conta que apenas um servidor atuará no projeto,
trabalhando em
regime de dedicação exclusiva na elaboração da referida tecnologia. Contudo, é
importante esclarecer que, mesmo sendo designado um número maior de pessoas à produção
do sistema, não significa que o prazo poderá ser reduzido ou proporcional ao
tamanho da equipe. Esse parâmetro foi escolhido, com intuito de demostrar o
método, mas o ideal é usar o histórico de desempenho da equipe de analista da
instituição, sobretudo, para estabelecer um prazo mais assertivo.

Ao
realizar a estimativa do custo, verificou-se a média salarial do Analista e,
então, definiu-se o valor de cada hora trabalhada por pontos de função
desenvolvido na aplicação. Em se tratando do Acadigitus,
o cômputo foi baseado no salário do servidor TAE, Analista de Sistemas (classe
E), cujo padrão mensal de vencimento básico é R$ 4.180,66  (quatro mil, cento e oitenta reais e sessenta
e seis centavos), estabelecido pela Lei nº 13.325/2016, Anexo X, que trata do Plano
de Carreira dos Cargos Técnico-Administrativos em Educação - PCCTAE (BRASIL,
2016b).

Isto
posto, tomando por base a faixa salarial do Analista, dividido por sua carga
horária mensal, tem-se a quantia de R$ 26,13 (vinte e seis reais e treze
centavos), correspondente ao valor da hora trabalhada e, ao multiplicar pelo
IP, obteve-se o valor de R$ 287,43 (duzentos e oitenta e sete reais e quarenta
e três centavos) equivalente a cada ponto de função (CPF). Dessa maneira, o
custo de desenvolvimento do Acadigitus foi estimado
pelo produto entre a DFP e o CPF, conforme a Equação 5.

Custo = 293
x 287,43

Custo = R$ 84.216,99 (oitenta e quatro
mil e duzentos e dezesseis reais e noventa e nove centavos)

Diante dos resultados, demonstrou-se
o método de APF, no qual foi estimado o esforço, prazo e custo de
desenvolvimento do sistema Acadigitus, produzido pela
UNIVASF. É válido salientar, que o estudo poderá servir como base para
aplicação em outros sistemas existentes na Instituição, contribuindo com o
NIT/UNIVASF na tarefa de valorar os RPCs disponíveis
à negociação de contratos de TT.

5
CONSIDERAÇÕES FINAIS

A valoração de tecnologias faz parte do conjunto de
atividades desempenhadas pelos NITs, especialmente,
aquelas voltadas à contratos de TT. Por isso, dispor de métodos que sirvam como
referência na atribuição do valor ao ativo de propriedade intelectual, é o
pontapé inicial, para uma negociação bem-sucedida, na qual todas as partes
dialogam, no sentido de atribuírem um preço justo à tecnologia.

Em relação a valoração
de programa de computador, o presente trabalho, abordou os conceitos atrelados
ao método de APF, bem como a sua aplicação prática, em que, a priori,
definiu-se o tamanho funcional do sistema Acadigitus,
através do cálculo dos pontos de função e, a partir disso, obteve-se o valor do
custo, do prazo e do esforço empregado no desenvolvimento do produto
tecnológico.

Mediante a utilização
do método de APF, destacaram-se várias características positivas, a exemplo da
facilidade de compreensão, a clareza na identificação dos elementos de
contagem, dos arquivos lógicos e transacionais. Por outro lado, verificou-se
como ponto negativo, a falta de consenso na literatura, acerca do cálculo do
fator de ajuste, tendo em vista a subjetividade na determinação do grau de
influência das caraterísticas gerais do sistema. Contudo, baseado na
recomendação do TCU e argumentação de autores encontrados na literatura sobre o
tema, optou-se por desconsiderar o fator de ajuste neste trabalho.

Além disso, por motivo
de ausência de dados históricos sobre o desempenho da equipe de analista da
UNIVASF, utilizou-se como referência um índice de produtividade estabelecido
por outra instituição, a fim de demostrar a estimativa de esforço. Assim como,
para determinar o prazo e o custo, foram realizadas suposições acerca da
quantidade de horas trabalhas e a remuneração do analista, responsável pelo desenvolvimento
do sistema.

Desta forma, é
importante esclarecer que o valor estimado do custo, obtido na valoração do Acadigitus, serviu para apresentar e demostrar o uso do
método de APF, o que não, necessariamente, equivale ao valor real do Sistema,
observando-se os fatores supracitados, em especial, a produtividade. Pois, como
visto, o índice influencia diretamente no resultado obtido. Por isso, o ideal é
que sejam realizadas as estimativas, por meio de informações precisas, sempre
que possível, nas quais representem a situação real do contexto de
desenvolvimento do sistema, a fim de evitar a superestimação ou defasagem no
preço final da tecnologia.

Por fim, ressalta-se a importância deste trabalho, uma vez
que ao abordar um novo método de valoração de RPCs para
uma tecnologia com titularidade da UNIVASF, cuja equipe ainda não havia
utilizado a análise de ponto de função no NIT/UNIVAS para valoração de seus
programas de computador, estima-se proporcionar a obtenção de valores alternativos
para comparações prévias à etapa de negociação dos programas de computador,
facilitando o processo de tomada de decisão entre as partes, além de servir como
material de referência para utilização em outros NITs,
de outras ICTs.

REFERÊNCIAS

ARANHA, P. D.; CARDOSO, M. O. Métodos e Métricas
para Estimativas e Planejamento de Projetos Ágeis de Software: Estudo
Comparativo entre Pontos de Função e Story Points.
2017. 65 f. Monografia (Graduação em engenharia de Software), Universidade de
Brasília, Brasília, 2017. Disponível em: https://bdm.unb.br/bitstream/10483/20412/1/2017_DandaraAranha_MaxwellCardoso_tcc.pdf.  Acesso em: 22 out. 2020.

BOMFIM, M.R.G.; ANDRADE, J.R. Guia de Contagem de
Pontos de Função do Ministério do Planejamento. Versão 1.0: Ministério do
Planejamento, 2015. Disponível em: https://www.gov.br/economia/pt-br/centrais-de-conteudo/publicacoes/planejamento/tecnologia-da-informacao/GuiadeContagemdePontosdeFuncaov1.pdf/@@download/file/guiadecontagemdepontosdefuncaov1.pdf.
Acesso em: 12 ago. 2020.

BRASIL. Lei nº 13.243, de 11 de janeiro de 2016.
Dispõe sobre estímulos ao desenvolvimento científico, à pesquisa, à capacitação
científica e tecnológica e à inovação. Brasília, DF, 11 jan. 2016a. Disponível
em: http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2016/lei/l13243.htm.
Acesso em: 11 ago. 2020.

BRASIL. Lei nº 13.325, de 29 de julho de 2016.
Altera a remuneração, as regras de promoção, as regras de incorporação de
gratificação de desempenho a aposentadoria e pensões de servidores públicos da
área da educação, e dá outras providências. Brasília, DF, 29 de jul. 2016b.
Disponível em: http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2016/lei/l13325.htm.
Acesso em: 01 set. 2020.

BRASIL. Ministério do Planejamento, Desenvolvimento e
Gestão. Secretaria de Tecnologia da Informação e Comunicação SETIC. Roteiro
de Métricas de Software do SISP: versão 2.3.  Brasília: MP, 2018a. Disponível em:
http://www.sisp.gov.br/metricas/wiki/en/roteirometricas. Acesso em: 12 ago.
2020.

BRASIL. Ministério da Educação. Portaria nº 315, de 4
de abril de 2018. Dispõe sobre os procedimentos de supervisão e monitoramento
de instituições de educação superior. Diário Oficial da República Federativa
do Brasil. Brasília, DF, 4 abr. 2018b. Disponível em:
http://pesquisa.in.gov.br/imprensa/jsp/visualiza/index.jsp?data=05/04/2018&jornal=515&pagina=13&totalArquivos=72.
Acesso em: 15 ago. 2020.

BRASIL.
Ministério da Educação. Portaria nº 330, de 5 de abril de 2018. Dispõe sobre a
emissão de diplomas em formato digital nas instituições de ensino superior
pertencentes ao sistema federal de ensino. Diário Oficial [da] República
Federativa do Brasil. Brasília, DF, 5 abr. 2018c. Disponível em: http://pesquisa.in.gov.br/imprensa/jsp/visualiza/index.jsp?data=06/04/2018&jornal=515&pagina=114. Acesso em: 15 ago. 2020.

CARVALHO, G.A.; AMARAL, H.F.; BATISTA, P.O.S.;
RIBEIRO, J.E. Valoração de ativos intangíveis com opções reais: estudo de caso
em uma transferência de tecnologia da Universidade Federal de Minas Gerais. Navus
- Revista de Gestão e Tecnologia, Florianópolis, v. 9, n. 2, p. 07-23, abr./jun.
2019. ISSN 2237-4558. DOI: 10.22279/navus.2019.v9n2.p07-23.740 Disponível em: http://navus.sc.senac.br/index.php/navus/article/view/740. Acesso em: 07 nov. 2020.

CASTRO, M.V.B.; HERNANDES, C.A.M. A Metric of Software Size as a Tool for IT Governance.
Revista do TCU (Brazilian
Federal Court of Accounts),
n. 135, p. 56-75, jan./abr. 2013. DOI: 10.1109/SBES.2013.13.
Disponível em: https://ieeexplore.ieee.org/document/6800186.
Acesso em: 12 ago. 2020.

CHIZZOTTI, A. Pesquisa em ciências
humanas e sociais. São Paulo: Cortez, 2009.

DESIDÉRIO, P.H.M.; ZILBER, M.A. Barreiras no processo
de transferência tecnológica entre agências de inovação e empresas: observações
em universidades públicas e privadas. Revista Gestão & Tecnologia. [S.l.], v. 14, n. 2, p. 101-126, ago. 2014. ISSN 2177-6652.
DOI 10.20397/2177-6652/2014.v14i2.650. Disponível em:
http://revistagt.fpl.edu.br/get/article/view/650/536. Acesso em:
11 ago. 2020.

ERNST, H.; LEGLER, S.; LICHTENTHALER,
U. Determinants of patent value: Insights from a simulation analysis. Technological
Forecasting and Social Change, v. 77, n. 1, p. 1-19, 2010. ISSN 0040-1625.
DOI: 10.1016/j.techfore.2009.06.009. Disponível em:
http://www.sciencedirect.com/science/article/pii/S0040162509000845. Acesso em:
01 nov. 2020.

FERREIRA, A.R.F.; SOUZA, A.L.R.; SILVÃO, C.F.;
MARQUES, E.F.; FARIA, J.A.; RIBEIRO, N.M.
Valoração de Propriedade Intelectual para a Negociação e Transferência
da Tecnologia: O caso NIT/IFBA. Navus - Revista de Gestão e Tecnologia, Florianópolis,
v. 10, p. 01-23, jan./dez. 2020. ISSN 2237-4558. DOI: 10.22279/navus. 2020.v10.p01-23.1046. Disponível em:
http://navus.sc.senac.br/index.php/navus/article/view/1046. Acesso em: 11 ago.
2020.

FREIRE, Y. M. A. TUC-M- Pontos de casos de uso
técnica para manutenção de software. 2008. 168 f. Dissertação (Mestrado em
Informática Aplicada) – Fundação Edson Queiroz, Universidade de Fortaleza,
Fortaleza, 2008. Disponível em: http://fattocs.com/files/pt/livro-apf/citacao/YaraMariaAlmeidaFreire-2008.pdf.
Acesso em: 26 ago. 2020.

GIL, A.C. Como elaborar projetos de pesquisa.
4. ed. São Paulo: Atlas, 2002.

GOMES, L.C.P. Scrum Root: ferramenta para
integrar APF e Scrum. 2017. 85 f. Trabalho de Conclusão de Curso (Graduação em
Análise e Desenvolvimento de Sistemas) - Departamento Acadêmico de Informática,
Universidade Tecnológica Federal do Paraná, Ponta Grossa, 2017. Disponível em: http://repositorio.roca.utfpr.edu.br/jspui/handle/1/8344.
Acesso em: 19 ago. 2020.

GRÜTZMANN, A.; ZAMBALDE, A. L.; BERMEJO, P. H. S.
Inovação, Desenvolvimento de Novos Produtos e as Tecnologias Internet: estudo
em empresas brasileiras. Gest. Prod.,
v. 26, n. 1, e1451.  2019. DOI:
10.1590/0104-530x1451-19. Disponível em:
http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-530X2019000100216&lng=en&nrm=iso.
Acesso em: 11 ago.  2020.

GUIMARÃES, V. A. Aplicação de Análise de Pontos
por Função na Mensuração de Software com SOA e BPM. 2017. 91 f. Dissertação
(Mestrado em Engenharia Elétrica) - Faculdade de Tecnologia de Departamento de
Engenharia Elétrica, Universidade de Brasília, Brasília, 2017. Disponível em:
https://www.ppgee.unb.br/images/unb_ft/Trabalhos/valeria.pdf. Acesso em: 19
ago. 2020.

HILLMAN, M.F.; SUBRIADI, A.P.  40 Years Journey of Function Point Analysis:
Against Real-time and Multimedia Applications. Procedia
Computer Science, v.161, p. 266-274, 2019. DOI: 10.1016/j.procs.2019.11.123.
Disponível em: https://www.sciencedirect.com/science/article/pii/S1877050919318332?via%3Dihub. Acesso em 30
out. 2020.

HAZAN,
C.; STAA, A.V. Análise e melhoria de um processo de estimativas de tamanho
de projeto de software. 2005. 37 f. Monografias (Ciência da Computação) –
Departamento de Informática, Pontifícia Universidade Católica do Rio de
Janeiro, Rio de Janeiro, 2005. Disponível em: ftp://ftp.inf.puc-rio.br/pub/docs/techreports/05_04_hazan.pdf. Acesso em: 22 out. 2020.

HONG,
S.J.; SEO, J.W.; KIM, Y.S.; KANG, S.H. Construction Technology Valuation
for Patent Transaction. KSCE Journal of Civil Engineering, v. 14, n.
2, p. 111–122, 2010. DOI: 10.1007/s12205-010-0111-y. Disponível em: https://link.springer.com/article/10.1007/s12205-010-0111-y.
Acesso em: 07 nov. 2020.

IFPUG. Manual
de Práticas de Contagem de Pontos de Função, Versão 4.3.1.[S.l.: s.n.], 2010. disponível em https://www.ifpug.org/faqs-2/?lang=pt.
Acesso em:
18 Ago. 2020.

IFPUG. Portal
da International Function Point Users Group. Disponível em:
https://www.ifpug.org/about-function-point-analysis/?lang=pt. Acesso em:
17 ago. 2020.

KANG, B.; LEE, J.  Estimating Procedure for Function Point and
Development Cost in South Korea.  International
Journal of Networked and Distributed Computing, v. 6, n. 3, p. 185-194,
2018. ISSN: 22117938. DOI: 10.2991/ijndc.2018.3.6.6.
Disponível em: https://www.atlantis-press.com/journals/ijndc/25905549. Acesso em: 07 nov.
2020.

ISO –
International Organization for Standardization; IEC- International Electrotechical Commission. 20926:2009: Software
engineering – IFPUG 4.1 Unadjusted functional size measurement method –
Counting practices manual. 2009. Disponível em: https://www.iso.org/standard/35582.html.
Acesso em:
12 ago. 2020.

LOKAN, C. J.
An empirical analysis of function point adjustment factors. Information and
Software Technology, v. 42, n. 9, p. 649-659, June 2000. DOI: 10.1016/S0950-5849(00)00108-7. Disponível em: https://www.sciencedirect.com/science/article/abs/pii/S0950584900001087.
Acesso em: 10 out. 2020.

LOPES, J. S.; BRAGA, J. L. Guia Prático em Análise
de Ponto de Função. 2011. Disponível em: http://fattocs.com/files/pt/livro-apf/citacao/JhoneySLopes-JoseLBraga-2011.pdf.
Acesso em:
19 ago. 2020.

MARTINO, S.D.; FERRUCCI, F.; GRAVINO, C.;
SARRO, F. Web Effort Estimation: Function Point Analysis Vs. COSMIC. Information
and Software Technology, v. 72, p. 90-109, 2016. DOI: 10.1016/j.infsof.2015.12.001. Disponível
em: https://www.sciencedirect.com/science/article/abs/pii/S0950584915002037. Acesso em: 07 nov. 2020.

MELLER, M.C. Modelos para estimar custo de
software: estudo comparativo com software de pequeno porte. 2002. 163 f.
Dissertação (Mestrado em Ciência da Computação) – Programa de Pós-Graduação em
Ciência da Computação, Universidade Federal de Santa Catarina, Florianópolis,
2002. Disponível em: https://repositorio.ufsc.br/xmlui/bitstream/handle/123456789/82351/184841.pdf?sequence=1. Acesso em:
20 ago. 2020.

MORROW, P.; WILKIE, F.G.; MCCHESNEY, I.R. Function
point analysis using NESMA: simplifying the sizing without simplifying the
size. Software Quality Journal, v. 22, p. 611-650, 2014. DOI 10.1007/s11219-013-9215-1. Disponível em: https://link.springer.com/article/10.1007/s11219-013-9215-1. Acesso em: 05 out. 2020.

PINHEIRO, A. F. Análise de Ponto de Função. Recife:
Ed. do Autor,
2017.

PRATIWI, D. Implementation
of Function Point Analysis in Measuring The Volume
Estimation of Software System in Object Oriented and Structural Model of
Academic System. International Journal of Computer Applications, v.70,
n.10, May, 2013. ISSN: 0975-8887. DOI: 10.5120/11995-7879. Disponível em: https://arxiv.org/abs/1309.2404v1. Acesso em: 05 out. 2020.

QUINTELLA, C.M.; TEODORO, A.F.O.; FREY, I. A. Vantagens
econômicas da transferência de tecnologia. In: FREY, I.A.; TONHOLO, J.;
QUINTELLA, C.M. (org.). Conceitos e aplicações de Transferência de Tecnologia.
v.1. Salvador, 2019. p. 103-138. Disponível em:
http://www.profnit.org.br/wp-content/uploads/2019/10/PROFNIT-Serie-Transferencia-de-Tecnologia-Volume-I-WEB-2.pdf.
Acesso em: 12 ago. 2020.

QUINTELLA, C.M.; TEODORO, A. F. O.; FREY, I.A.;
GHESTI, G.F. Valoração de ativos de
propriedade intelectual. In: FREY, I.A.; TONHOLO, J.; QUINTELLA,
C.M. (org.). Conceitos e aplicações de
Transferência de Tecnologia. v.1. Salvador, 2019. p. 139-178. Disponível
em: http://www.profnit.org.br/wp-content/uploads/2019/10/PROFNIT-Serie-Transferencia-de-Tecnologia-Volume-I-WEB-2.pdf.
Acesso em: 12 ago. 2020.

RAJU,
H.K.; KRISHNEGOWDA, T. Software Sizing and Productivity with Function Points. Lecture
Notes on Software Engineering, v. 1, n. 2, p. 204-208, May,
2013. ISSN: 2301-3559. DOI:
10.7763/LNSE.2013.V1.46. Disponível em: http://www.lnse.org/papers/46-IE2038.pdf.
Acesso em: 20 out. 2020.

ROSÁRIO, F.J.P.; LIMA, A.A. A hélice tripla, os
habitats de inovação e a promoção de negócios inovadores a partir da academia. In:
FREY, I.A.; TONHOLO, J.; QUINTELLA, C.M. (org.). Conceitos e aplicações de
Transferência de Tecnologia. v.1. Salvador, 2019. p. 25-43. Disponível em:
http://www.profnit.org.br/wp-content/uploads/2019/10/PROFNIT-Serie-Transferencia-de-Tecnologia-Volume-I-WEB-2.pdf.
Acesso em: 12 ago. 2020.

SANTIN, L.C. Análise de Pontos de Função: um
estudo de caso em uma empresa com mps.br nível f. 2014. 59 f. Trabalho de Conclusão
de Curso (Bacharelado em Ciência da Computação) – Universidade Estadual de
Londrina, Londrina, 2014. Disponível em: http://www.uel.br/cce/dc/wp-content/uploads/TCC-LeticiaSantin-BCC-UEL-2014.pdf.
Acesso em:  05 nov. 2020.

SOUZA, R.O. Valoração de ativos intangíveis: seu
papel na transferência de tecnologia e na promoção da inovação tecnológica.
2009. 140 f.  Dissertação (Mestrado em
Tecnologia de Processos Químicos e Bioquímicos) – Programa de Pós-Graduação da
Escola de Química, Universidade Federal do Rio de Janeiro, Rio de Janeiro,
2009. Disponível em:
http://tpqb.eq.ufrj.br/download/valoracao-de-ativos-intangiveis.pdf. Acesso em:
12 ago. 2020.

TUKOFF-GUIMARÃES, Y.B.; KNIESS, C.T.; MACCARI,
E.A.; QUONIAN, L. Valoração de patentes: o caso do núcleo de inovação
tecnológica de uma instituição de pesquisa brasileira. Exacta
Engenharia de Produção, São Paulo, v. 12, n. 2, p. 161-172, 2014. DOI 10.5585/exactaep.v12n2.4843. Disponível em: https://periodicos.uninove.br/exacta/article/view/4843. Acesso em: 02 set. 2020.

VAZQUEZ, C.E.; SIMÕES, G.S.; ALBERT, R.M. Análise
de Pontos de Função - Medição, Estimativas e Gerenciamento de Projetos de
Software. 13. ed. São Paulo: Érica, 2013.

WOLFART, D. Estimativa de tamanho de software por
meio da técnica de análise de pontos de função. 2012. 89 f.  Monografia (Especialização em Engenharia de
Software) – Diretoria de Pesquisa e Pós-Graduação, Universidade Tecnológica
Federal do Paraná, Medianeira, Paraná, 2012. Disponível em: http://repositorio.roca.utfpr.edu.br/jspui/bitstream/1/1122/3/MD_ENGESS_I_2012_05.pdf.
Acesso em 25 ago. 2020.

YIN, R. K. Estudos de caso: planejamento e métodos.
5. ed. Porto Alegre: Bookman, 2015.

[1] TD: campos
reconhecidos pelo usuário e não tenha repetição (SANTIN, 2014).

[2] TR: tabela
caracterizada como um único arquivo lógico ALI ou AIE (SANTIN, 2014).

[3] AR: arquivo lógico
acessado no contexto da aplicação, podendo ser uma ALI ou AIE (CASTRO;
HERNANDES, 2013).