Administração

da Solução
Créditos
Centro Universitário Senac São Paulo – Educação Superior a Distância
Diretor Regional
Luiz Francisco de Assis Salgado
Superintendente Universitário
e de Desenvolvimento
Luiz Carlos Dourado
Reitor
Sidney Zaganin Latorre
Diretor de Graduação
Eduardo Mazzaferro Ehlers
Diretor de Pós-Graduação e Extensão
Daniel Garcia Correa
Gerentes de Desenvolvimento
Claudio Luiz de Souza Silva
Luciana Bon Duarte
Roland Anton Zottele
Sandra Regina Mattos Abreu de Freitas
Coordenadora de Desenvolvimento
Tecnologias Aplicadas à Educação
Regina Helena Ribeiro
Coordenador de Operação
Educação a Distância
Alcir Vilela Junior
Professor Autor
André Filipe de Moraes Batista
Revisor Técnico
João Carlos Neto
Técnica de Desenvolvimento
Fabiana Martins Vilela
Coordenadoras Pedagógicas
Ariádiny Carolina Brasileiro Silva
Izabella Saadi Cerutti Leal Reis
Nivia Pereira Maseri de Moraes
Otacília da Paz Pereira
Equipe de Design Educacional
Alexsandra Cristiane Santos da Silva
Ana Claudia Neif Sanches Yasuraoka
Angélica Lúcia Kanô
Any Frida Silva Paula
Cristina Yurie Takahashi
Diogo Maxwell Santos Felizardo
Flaviana Neri
Francisco Shoiti Tanaka
Gizele Laranjeira de Oliveira Sepulvida
Hágara Rosa da Cunha Araújo
Janandrea Nelci do Espirito Santo
Jackeline Duarte Kodaira
João Francisco Correia de Souza
Juliana Quitério Lopez Salvaia
Jussara Cristina Cubbo
Kamila Harumi Sakurai Simões
Katya Martinez Almeida
Lilian Brito Santos
Luciana Marcheze Miguel
Mariana Valeria Gulin Melcon
Mônica Maria Penalber de Menezes
Mônica Rodrigues dos Santos
Nathália Barros de Souza Santos
Rivia Lima Garcia
Sueli Brianezi Carvalho
Thiago Martins Navarro
Wallace Roberto Bernardo
Equipe de Qualidade
Ana Paula Pigossi Papalia
Josivaldo Petronilo da Silva
Katia Aparecida Nascimento Passos
Coordenador Multimídia e Audiovisual
Ricardo Regis Untem
Equipe de Design Audiovisual
Adriana Mitsue Matsuda
Caio Souza Santos
Camila Lazaresko Madrid
Carlos Eduardo Toshiaki Kokubo
Christian Ratajczyk Puig
Danilo Dos Santos Netto
Hugo Naoto Takizawa Ferreira
Inácio de Assis Bento Nehme
Karina de Morais Vaz Bonna
Marcela Burgarelli Corrente
Marcio Rodrigo dos Reis
Renan Ferreira Alves
Renata Mendes Ribeiro
Thalita de Cassia Mendasoli Gavetti
Thamires Lopes de Castro
Vandré Luiz dos Santos
Victor Giriotas Marçon
William Mordoch
Equipe de Design Multimídia
Alexandre Lemes da Silva
Cristiane Marinho de Souza
Elina Naomi Sakurabu
Emília Correa Abreu
Fernando Eduardo Castro da Silva
Mayra Aoki Aniya
Michel Iuiti Navarro Moreno
Renan Carlos Nunes De Souza
Rodrigo Benites Gonçalves da Silva
Wagner Ferri
Administração da Solução
Aula 01
Métricas e Estimativas de Software

Objetivos Específicos
• Conhecer os fundamentos das métricas e estimativas de software (APF e
COCOMO II).

Temas

Introdução
1 Métricas e estimativas de software
Considerações finais
Referências
Anexo

Professor
André Filipe de Moraes Batista
 Administração da Solução

Introdução
É praticamente impossível não conviver com softwares nos dias de hoje. A informatização
dos processos está presente em quase todas as organizações e elementos da sociedade. Cada
vez mais, o governo faz uso de serviços eletrônicos para atendimento aos cidadãos. Assim,
nos tornamos mais dependentes da tecnologia e dos softwares. É difícil uma organização
sobreviver sem um software, seja ele de prateleira (pronto para ser usado) ou desenvolvido
sob demanda para atender suas necessidades específicas (VAZQUEZ; SIMÕES; ALBERT, 2013).

Em se tratando de desenvolvimento de software, é possível notar que boa parte dos

requisitos de um sistema tende a aumentar com o tempo, tais como qualidade, funcionalidade
e desempenho. Não é raro encontrarmos projetos de desenvolvimento de software em
que após a fase de elicitação de requisitos, seus futuros usuários vão idealizando novas
características inicialmente não percebidas, ao longo do processo de desenvolvimento
e aperfeiçoamento da solução. Este aumento do escopo é algo natural dos projetos e nos
evidencia a natureza expansiva dos requisitos (VAZQUEZ; SIMÕES; ALBERT, 2013).

No entanto, é preciso ter em mente que, para atender tais requisitos e sua consequente
expansão, faz-se necessário o empenho de vários profissionais, recursos físicos e financeiros
e, inclusive, de tempo. É, portanto, imprescindível gerir corretamente os projetos de software
mensurando seu crescimento, assim como as mudanças que acontecerão em seus requisitos, em
função do seu ciclo de vida. É neste ponto que entra o processo de medição e estimativa de software.

Nosso foco passa, então, a ser o custo do desenvolvimento de um software. Porém, para
responder esta pergunta é preciso compreender que este custo representa grande parte do
esforço necessário para desenvolver o software. Este esforço necessita ser mensurado e/ou
estimado, de modo que possamos determinar o custo, cronograma e demais aspectos do
projeto de desenvolvimento.

Portanto, nesta aula, iremos aprofundar os conhecimentos sobre as técnicas de

estimativa e medição de software mais comuns no mercado, contextualizando-as no ciclo de
desenvolvimento de software. Espera-se que você possa ter uma visão clara e objetiva sobre as
vantagens e desvantagens de cada uma, além de seus papéis no processo de desenvolvimento
de soluções de software com qualidade.

1 Métricas e estimativas de software

Em um primeiro momento, quando estamos iniciando o projeto de desenvolvimento de
um software, seus requisitos ainda não estão muito bem definidos, e a equipe não possui
um conhecimento completo de suas características que permita mensurá-lo com precisão.
Nessa etapa, podemos fazer uso de técnicas para estimar o tamanho do software, o esforço
necessário, dentre outros fatores.

Senac São Paulo- Todos os Direitos Reservados 3

 Administração da Solução

É bastante comum entre iniciantes na área de sistemas o uso da métricas de linhas de

código. Não é raro ver estudantes de programação compararem seus programas por meio da
quantidade de linhas de código. Mas, conforme explanado por Vasquez (2013), essa aparente
facilidade de uso da métrica de linhas de código é perigosa. Pode-se, em seu uso, incorrer no
risco de usar dois pesos e duas medidas. Por exemplo:

• Será que devemos contabilizar linhas de comentário nesta contagem?

• A inclusão das bibliotecas deve ser contabilizada?

• Se o programador fizer uso de múltiplos comandos em uma mesma linha, como esta
linha será contabilizada?

Note a fragilidade da métrica. Estamos diante de uma métrica que está dependendo da
linguagem de programação na qual o software está sendo desenvolvido, além de considerar
aspectos subjetivos de decisão de estilo de programação por parte do programador. É importante
também ressaltar a importância do entendimento pelo cliente/usuário da métrica que estamos
fazendo uso. É difícil imaginar um usuário leigo entender que você mensurou todo o projeto de
software porque estimou que o sistema irá possuir mais de 200 mil linhas de código.

De todo modo, a medição por técnicas como linhas de código não é totalmente descartada.
Podemos fazer uso, de alguma maneira, das linhas de código, ao menos para estimar o esforço
do projeto. Em 1981, Barry Boehm publicou um modelo de estimativa denominado COCOMO
(COnstructived COst MOdel) (BOEHM; BROWN, 2009). Este modelo inicial faz uso de linhas de
código para gerar estimativas de esforço, prazo, custo e tamanho da equipe (VAZQUEZ; SIMÕES;
ALBERT, 2013). Este modelo foi evoluído com tempo, para contemplar as técnicas modernas de
desenvolvimento de software, tais como programação visual e componentização, gerando o
modelo COCOMO II que iremos ver com mais detalhes logo adiante.

Há outras técnicas, tais como a Análise de Pontos de Função (APF), que buscam mensurar o
tamanho do software independentemente da tecnologia utilizada. Na prática, esta técnica não só nos
permite mensurar o tamanho do sistema em termos da funcionalidade fornecida ao usuário, como
também mensurar seu tamanho em qualquer fase de seu ciclo de vida. Ao longo do ciclo de vida de
desenvolvimento, nossa estimativa vai se tornando mais apurada, em função do detalhamento mais
natural dos requisitos, e podemos então mensurar o software (VAZQUEZ; SIMÕES; ALBERT, 2013).

A seguir, apresenta-se com mais detalhes as técnicas de Análise de Pontos de Função e COCOMO II.

1.1 Análise de Pontos de Função (APF)

A técnica de APF surgiu na IBM, no início da década de 1970, como uma alternativa
às métricas baseadas em linhas de código. Allan Albrencht, então funcionário da empresa,
foi encarregado de medir a produtividade de vários projetos de software que tinham sido
desenvolvidos em diversas linguagens de programação (VAZQUEZ; SIMÕES; ALBERT, 2013).
Senac São Paulo- Todos os Direitos Reservados 4
 Administração da Solução

Mas como afirmar que um projeto desenvolvido na linguagem X, que possui 10 mil
linhas, é mais ou menos produtivo do que outro projeto de mesma funcionalidade, mas que
possui 6 mil linhas?

Nos dias de hoje, desenvolver 10 mil linhas na linguagem Java, por exemplo, é às vezes
muito mais fácil do que construir um software de 6 mil linhas na linguagem C. Portanto,
tornou-se necessária uma métrica que fosse independente da tecnologia que foi utilizada
para desenvolver o software.

A técnica de análise de pontos de função nos permite mensurar as funcionalidades

fornecidas por um software do ponto de vista de seu usuário final.

Mas o que vem a ser um ponto de função?

O ponto de função é a unidade de medida da técnica, que tem por objetivo

realizar uma medição independente da tecnologia utilizada na construção do
software. Quando mensuramos um software por meio da técnica de APF
estamos buscando medir o que o software faz, e não como ele foi ou será
construído (VAZQUEZ; SIMÕES; ALBERT, 2013).

Realizar a medição por pontos de função é seguir um processo padronizado para avaliar
os requisitos lógicos do usuário. Seguimos este processo para obter o tamanho funcional do
software, e com esta métrica derivamos outras, tais como produtividade, esforço e custo.

Após a apresentação desta técnica à comunidade, houve um crescimento do número de

usuários. Este crescimento motivou a criação de um grupo internacional denominado IFPUG
(International Function Point Users Group), em 1986. Conforme as estatísticas liberadas pelo
BFPUG1 (Brazilian Function Point Users Group), chapter do IFPUG no Brasil, em 2008 o Brasil
era o país com maior número de profissionais certificados em análise de pontos de função
(269), seguido pela Coréia (264), Índia (176), Itália (99) e Estados Unidos (93).

O IFPUG é uma entidade sem fins lucrativos, composta por pessoas e empresas de diversos
países, que visam promover um melhor gerenciamento dos processos de desenvolvimento e
manutenção de software com uso da técnica de pontos de função (VAZQUEZ; SIMÕES; ALBERT, 2013).

O IFPUG mantém um manual de práticas de contagem (CPM - Counting Practices Manual),

com o objetivo de padronizar o uso desta técnica. A versão mais atual deste manual, de
fevereiro de 2015, é 4.3.1. De acordo com Vazquez, Simões e Albert (2013), o padrão definido
pelo IFPUG é o mais utilizado no mercado para pontos de função.

1 Saiba mais em: <http://www.bfpug.com.br/CertificacaoCFPS.htm>. Acesso em: 9 mar. 2015.

Senac São Paulo- Todos os Direitos Reservados 5

 Administração da Solução

O ponto mais central da técnica de APF é a visão do usuário. Ela retrata como o requisito
funcional é percebido por ele. Para Vazquez, Simões e Albert (2013), ela é a descrição formal
das necessidades de negócio do usuário na sua linguagem, isto é, uma descrição das funções
de negócio aprovada pelo usuário.

O conceito de usuário é muito importante para a técnica de APF. De acordo com Vazquez,
Simões e Albert (2013), usuário é qualquer pessoa ou coisa que interaja (isto é, envia ou
recebe dados) com a aplicação. São exemplos de usuários: uma pessoa física, outra aplicação,
um hardware etc.

É fundamental para a técnica de análise de pontos de função a definição do que vem a

ser usuário no escopo da contagem, que irá determinar a visão do sistema a ser mensurado,
inclusive delimitando a fronteira deste com outros sistemas.

Imagine que você deseja mensurar um sistema. Quais instrumentos pode

fazer uso para definir quem é o usuário e como será sua visão, delimitando as
fronteiras do sistema?

É importante ter em mente que, embora a APF faça uso dos requisitos do usuário para
mensurar o tamanho funcional do sistema, isto não significa que os requisitos devem estar
todos elicitados para fazermos uso desta técnica. A Figura 1 ilustra a dinâmica do processo
de utilização da técnica de APF para estimar e mensurar um projeto de desenvolvimento de
software ao longo de seu ciclo de vida.

Figura 1 – Evolução da efetividade da mensuração ao longo do ciclo de vida do software

Fonte: Vazquez, Simões e Albert (2013, p. 45).

Na primeira fase do projeto, quando este está em um estágio de concepção e/ou análise
de sua viabilidade, alguns requisitos são conhecidos muito superficialmente e outros sequer
Senac São Paulo- Todos os Direitos Reservados 6
 Administração da Solução

foram levantados ainda. Podemos então, nessa fase, estimar o tamanho do software com uso
da APF. Ao longo do ciclo de desenvolvimento, conforme os requisitos vão sendo refinados
e o sistema desenvolvido, podemos continuar a estimar, mas é possível também medir o
software ao longo deste ciclo de vida.

Estimar o tamanho funcional de um software normalmente requer menos tempo do que

mensurá-lo. Além disso, como estamos estimando o tamanho, não precisamos que todas as
informações estejam disponíveis.

Outra característica importante da técnica da APF é o fato de ela ser auditável. Por fazer
uso de métodos-padrão de contagem, como os estabelecidos no CPM do IFPUG, é factível que
uma medição funcional seja auditada por outra pessoa ou organização (VAZQUEZ; SIMÕES;
ALBERT, 2013).

Figura 2 – Processo de medição do tamanho funcional pela técnica de APF

Fonte: Vazquez, Simões e Albert (2013, p. 41).

A Figura 2 apresenta as etapas e suas interdependências no processo de medição do

tamanho funcional de um software por meio da técnica de APF.

Senac São Paulo- Todos os Direitos Reservados 7

 Administração da Solução

Para se ter uma ideia do tamanho de um software, fazemos uso de métricas

de tamanho funcional como o ponto de função. Por exemplo, de acordo com
Jones (2007), um dos maiores especialistas na área de métricas, o sistema
Operacional Windows 7 possui aproximadamente 200 mil pontos de função. Já
aplicativos como o Microsoft Word e o Microsoft Excel possuem em torno de
1.500 pontos de função. O Twitter, por sua vez, possui 541 pontos. Com uso do
tamanho funcional, podemos mensurar demais métricas necessárias ao nosso
projeto. Para conhecer o tamanho de outros sistemas, leia mais acessando o
link disponível na Midiateca.

1.2 COnstructived COst MOdel 2 (COCOMO II)

Em 1994 teve início o projeto COCOMO II (BOEHM; BROWN, 2009), como uma evolução
do modelo COCOMO, de 1981, com o objetivo de desenvolver um modelo de custo mais
atualizado e alinhado às práticas de ciclo de vida de software que vigoraram entre os anos de
1990 e 2000, além de aspectos como a prototipação rápida e reutilização. A última versão do
COCOMO II foi publicada no ano 2000 (JÚNIOR; SANCHES, 2000).

Para Boehm e Brown (2009), o COCOMO II é um método que busca medir o esforço,
prazo, tamanho de equipe e custo necessário para o desenvolvimento de um projeto de
software, a partir de sua dimensão, por meio de uma estimativa de seu tamanho. Para uso
do COCOMO II as organizações necessitam construir uma base de dados histórica, registando
informações sobre projetos anteriores, para que o modelo possa gerar estimativas de custo,
prazo e esforço mais acuradas.

O COCOMO II nos auxilia a estimar o custo de projeto de software e, consequentemente,

o tempo em pessoas/mês, determinando o baseline do projeto. Para esta predição, o
COCOMO II faz uso do tamanho do produto de software (normalmente em linhas de código,
mas podemos fazer uso de pontos de função que, por meio de uma tabela de conversão, são
convertidos em linhas de código) e outros fatores que afetam a produtividade. A abordagem
de predizer não apenas com base no tamanho do produto de software, mas considerar fatores
que afetam a produtividade, permite-nos tomar decisões gerenciais que possam minimizar o
impacto destes fatores no esforço necessário para o desenvolvimento (LOPÉZ, 2005).

O modelo COCOMO II faz uso de equações matemáticas para descrever as relações entre
o tamanho de software (normalmente representando em pontos de função) e outros fatores
secundários, denominados drivers de custo, que buscam para representar as características
do desenvolvimento do software que afetam o esforço necessário para terminar o projeto
de software. Como já dito, o COCOMO II faz uso de dados históricos para descobrir quais
fórmulas melhor representam o cenário a ser mensurado (BOEHM; BROWN, 2009).
Senac São Paulo- Todos os Direitos Reservados 8
 Administração da Solução

Ainda de acordo com Boehm e Brown (2009), o modelo COCOMO II é dividido em três
submodelos que tratam as diferentes fases em que o projeto ou a atividade se encontra. A
utilização de cada submodelo aumenta a precisão e fidelidade da estimativa efetuada, ao
longo do processo de desenvolvimento.

Por exemplo, para o estágio de prototipação de um sistema, podemos fazer uso do

submodelo de composição da aplicação, baseado em pontos de objeto e aplicado nos
primeiros fluxos de trabalho, quando existe um conhecimento mínimo sobre o produto a ser
construído. Pontos de objeto é uma contagem funcional de telas, relatórios e componentes,
que provavelmente serão necessários para a construção do software (LOPÉZ, 2005; BOEHM;
BROWN, 2009).

Cada um dos elementos necessários recebe uma classificação de acordo com sua
complexidade (simples, média e alta, por exemplo) e cada classificação receberá um peso.
Com isto, pode-se estimar o esforço, calculando os pontos de objeto necessários para
o desenvolvimento. Avalia-se, então, a taxa de desenvolvimento histórica para projetos
similares, de modo a determinar quantos pontos de objeto poderão ser produzidos por mês.
Após isto, busca-se gerar a taxa de desenvolvimento na forma pessoas/mês (LOPÉZ, 2005;
BOEHM; BROWN, 2009).

Quando boa parte dos requisitos estão elicitados e as possíveis arquiteturas do sistema
já foram exploradas, faz-se uso do submodelo projeto inicial. Este modelo faz uso de pontos
de função que são convertidos a milhares de linhas de código-fonte (KSLOC - Kilo Source Line
of Code).

O COCOMO II apresenta algumas sugestões para conversão de pontos de

função para linhas de código. Por exemplo, 1 PF equivale a 127 linhas de código
para a linguagem C. Se a linguagem a ser utilizada fosse Java, por exemplo, 1 PF
equivaleria a 53 linhas de código. Saiba mais sobre esta equivalência no Manual
do COCOMO II, por meio do link disponível na Midiateca.

Quando estamos na fase de construção do software, podemos fazer uso do submodelo

pós-arquitetura, que utiliza pontos de função ou linhas de código. Este é o modelo mais
detalhado do COCOMO II. Fazemos uso desse modelo após todos os requisitos estarem bem
definidos, assim como a arquitetura da solução. Neste submodelo, o COCOMO II faz uso
dos novos drivers de custo, novas regras para contabilizar linhas de código e equações mais
detalhadas para estimar o esforço necessário ao desenvolvimento do projeto (LOPÉZ, 2005).

Uma etapa comum para os submodelos do COCOMO II é a calibração do modelo,

fazendo uso da base histórica de projetos da organização. Com a calibração, determina-se
Senac São Paulo- Todos os Direitos Reservados 9
 Administração da Solução

os coeficientes a serem utilizados nas fórmulas, de modo a melhor representar o cenário

que estamos estimando. Esta calibração nem sempre é uma tarefa fácil, sendo necessária, às
vezes, uma adaptação na calibração ao longo do projeto (LOPÉZ, 2005).

De um modo geral, a fórmula estabelecida pelo COCOMO II para estimativa do esforço

necessário ao desenvolvimento de um projeto de software é dada por (SCHACH, 2008):

Esforço = A * Drivers de Custo * (TAMANHO)Expoente

Na qual A é um coeficiente decorrente do processo de calibração do COCOMO II. A

variável Expoente normalmente é estabelecida com base em cinco fatores do projeto, quais
sejam: precedência, flexibilidade de desenvolvimento, resolução da arquitetura/riscos,
coesão do grupo e maturidade do processo. O valor do Expoente, portanto, varia entre 1,01 e
1,26 (SCHACH, 2008, p. 265). Os drivers de custo são 17, dentre eles, citamos: confiabilidade,
tamanho da base de dados, complexidade, capacidade de reutilização necessária, tempo
de execução, volatilidade da plataforma, experiência da equipe, ferramentas de software a
serem utilizadas etc.

Como vimos, o COCOMO II é um modelo de estimativa e métrica de projetos de

desenvolvimento de software dependente da linguagem de programação, uma vez que há
uma conversão de métricas para KSLOC.

Considerações finais
A administração de projetos que visam gerar soluções de software para as mais diversas
aplicações requer a noção do tamanho do software como elemento necessário para a
determinação de demais fatores, tais como custo, prazos, dentre outros (VAZQUEZ; SIMÕES;
ALBERT). As técnicas de estimativas e medição do tamanho do software, mais conhecido
como tamanho funcional, permitem-nos mensurar os esforços necessários em cada etapa do
ciclo de desenvolvimento de software. As técnicas de APF e COCOMO II nos permitem obter
esta mensuração. A técnica de APF, por sua vez, é independente de tecnologia, enquanto a
COCOMO II depende da linguagem de programação a ser utilizada para o desenvolvimento do
software, assim como é baseada em uma análise histórica de projetos anteriores na mesma
plataforma, para determinar o tamanho atual do projeto e os esforços necessários (LOPÉZ,
2005; VAZQUEZ; SIMÕES; ALBERT, 2013).

É preciso, portanto, ter um conhecimento amplo sobre o universo de métricas de

software, uma vez que elas estarão presentes em boa parte dos projetos modernos. As
métricas nos permitem compreender o quão grande e complexo é o nosso projeto, permitindo
avaliar parâmetros tais como custo, tempo, recursos humanos etc. Espero que você tenha
compreendido um pouco mais sobre este assunto tão fundamental para o desenvolvimento
e gestão de soluções de software.

Senac São Paulo- Todos os Direitos Reservados 10

 Administração da Solução

Referências
BOEHM, Barry W.; BROWN, A. Winsor. Software Cost Estimation with COCOMO II. New Jersey:
Prentice Hall, 2009.

DEKKERS, Carol A. Measuring the “logical” or “functional” Size of Software Projects and
Software Application. Spotlight Software, ISO Bulletin May 2003 pp. 10-13.

JONES, Capers. Estimating Software Costs. Second Edition. Mc Graw Hill, 2007.

JÚNIOR, Waine Teixeira; SANCHES, Rosely. Modelos de Estimativas de Custo de Software COCOMO
& COCOMO II. Relatórios Técnicos do ICMC. nº. 106. 2000. Disponível em: <http://www.icmc.usp.
br/CMS/Arquivos/arquivos_enviados/BIBLIOTECA_113_RT_106.pdf>. Acesso em: 28 fev. 2015.

LOPÉZ, Pablo Ariel do Prado. COCOMO II - Um Modelo para estimativa de custo de Gerência de
Projetos. In: VII Encontro de Estudantes de Informática do Estado do Tocantins, 2005. Anais
Eletrônicos... Palmas, 2005.

SCHACH, Stephen R. Engenharia de Software - Os Paradigmas Clássico e Orientado a Objetos.

7. ed. São Paulo: McGraw-Hill, 2008.

VAZQUEZ, Carlos Eduardo; SIMÕES, Guilherme Siqueira; ALBERT, Renato Machado. Análise de
pontos de função: medição, estimativas e gerenciamento de projetos de software. São Paulo:
Érica, 2013.

Senac São Paulo- Todos os Direitos Reservados 11

 Administração da Solução

Anexo
Quadro 1 – Etapas e suas interdependências no processo de medição do tamanhofuncional
de um software por meio da técnica de APF

Reunir a documentação disponível e determinar o propósito da contagem: o primeiro passo no

processo da medição é a busca da documentação sobre o sistema e/ou projeto a ser medido. Esta
Etapa I documentação é norteada pelo propósito da contagem. O propósito (se estamos medindo um
software a ser desenvolvido ou uma melhora em um software já existente, por exemplo) nos indica
quais serão os documentos mais interessante a serem analisados no processo de medição.
Determinar o tipo de contagem: a contagem em APF pode ser feita de maneiras diferentes,
definindo assim o tipo de contagem. Há três tipos de contagens possíveis: contagem de um
projeto de desenvolvimento (mede a funcionalidade a ser fornecida aos usuários finais quando
Etapa II da primeira instalação do software), contagem de melhoria (mensura as funções adicionadas,
modificadas ou excluídas de um software existente) e contagem de aplicação (mede a
funcionalidade fornecida por uma aplicação já existente).
Determinar a fronteira da aplicação e o escopo da contagem: após a definição do tipo
contagem, precisamos identificar a fronteira da aplicação e o escopo da contagem. A fronteira é
uma interface que delimita o software a ser medido e o mundo exterior (isto é, seus usuários).
Etapa III Trata-se de uma etapa crucial do processo, pois é em função da fronteira que o software será
medido. Mudando a fronteira, há uma grande chance de a medição ser diferente daquela feita
com a concepção de fronteira anterior. Com relação ao escopo, definimos se a contagem irá
abranger, por exemplo, todo um sistema ou parte dele.
Medir funções de dados e de transação: trata-se do processo de identificar e classificar as
Etapa IV funções do tipo dado e do tipo transação, com base em diversas regras estabelecidas no CPM e
em exemplos que o manual nos fornece. É esta a etapa mais operacional da técnica.
Cálculo do tamanho funcional: cada função do tipo dado e transação, mensuradas na etapa
anterior, possuem um peso em PF, determinado pela complexidade da função, que pode ser
baixa, média ou alta. A complexidade das funções do tipo dados, por exemplo, é determinada
pela quantidade de tipos de dados (campos) e quantidade de tipos de registros que possuem.
Etapa V Já as funções do tipo transação possuem sua complexidade definida com base na quantidade
de tipo de dados e na quantidade de arquivos referenciados. Após a identificação e classificação
das funções existentes na contagem, o número de pontos de função do sistema, isto é, seu
tamanho funcional, será a soma do peso de cada uma das funções.
Documentar e reportar: esta é a etapa final do processo de medição, a qual consiste em
documentar e reportar o resultado da medição. Normalmente são gerados artefatos que permitam
Etapa VI auditar a contagem feita e compreender os valores obtidos. Normalmente fazemos uso de uma
planilha eletrônica para registrar a contagem feita e registrar o tamanho funcional do sistema.

Fonte: Vazquez, Simões e Albert (2013, p. 50-59).

Senac São Paulo- Todos os Direitos Reservados 12