Olá, estudante! Quando falamos em métrica, logo associamos ao conceito de medida ou ao ato de medir algo. Assim, a ideia central do tema Métrica de Software é medir o tamanho do software que está sendo desenvolvido e, para isso, nos baseamos, muitas vezes, nos modelos da UML ou nas características funcionais e não funcionais do software.
As métricas de um software são um conjunto de organização lógica daquilo que o programa deve fazer e daquilo que é necessário para a sua execução. Sendo assim, as métricas permitem que o projetista, além de ter uma estimativa do seu custo e desempenho, estabeleça um cronograma para o projeto.
Nesta lição, você aprenderá como medir um software seguindo uma das principais metodologias da literatura e aplicada nas organizações: a métrica por pontos de função. Apesar de não ser a única forma de medir um software é, sem dúvida, a mais utilizada e conceituada na literatura e no campo organizacional.
Tenho certeza que esta lição será de grande valia para a sua carreira como profissional no campo de Análise e Projeto de Sistemas. Vamos lá!
O desenvolvimento de um software envolve, muitas vezes, consideráveis recursos financeiros, recursos humanos e, por vezes, está cerceado por muita expectativa dos seus usuários. Assim, o projeto de um software deve se basear em dados concretos e previsíveis, para que haja provisionamentos dos custos, prazos e recursos humanos necessários antes do início do desenvolvimento.
Nesse sentido, a métrica de software é o principal elemento possível de fornecer ao projetista de um software a possibilidade de medir, com mais precisão, o tamanho daquele software, o quanto ele pode custar, qual o tempo para desenvolvê-lo e quantas pessoas devem estar envolvidas para que prazos e custos sejam equilibrados. Esta não é uma tarefa simples e muito menos rápida de ser realizada.
Para medir um software, é necessário que outros elementos tenham sido muito bem executados e identificados. Dentre eles, destacaremos o levantamento dos requisitos e as especificações dos requisitos funcionais e não funcionais do software. Os diagramas da UML também podem ajudar bastante no momento de “metrificar” o programa, contudo o elemento mais importante ou não para auxiliar na métrica dependerá do tipo de metodologia de métrica de software que você está usando.
Nesta lição, você aprenderá a utilizar a metodologia sugerida pelo IFPUG (International Function Point Users Group – Grupo Internacional de Usuários de Pontos por Função https://ifpug.org/). O termo “Pontos por Função” é a métrica para medir um software e tem reconhecimento internacional, sendo utilizada por organizações brasileiras, órgãos públicos e entidades internacionais. Por isso foi feita a escolha dessa métrica, mas existem outras na literatura.
Imagine que você é o(a) desenvolvedor(a) de um software e, logo no início das discussões sobre a ideia do software, é questionado(a) sobre quanto aquele software pode custar, quanto tempo demorará desenvolvê-lo e quantas pessoas precisam trabalhar nele, a fim de o entregar dentro do orçamento e no prazo estabelecido. Esses são questionamentos os quais você, certamente, receberá num ambiente organizacional. Aí eu te pergunto:
O que você faria? O que você responderia?
Qual seria a sua primeira atitude com relação a um questionamento dessa natureza?
Bem, vou te ajudar com essas respostas. Vamos lá!
O primeiro passo que você deve realizar nessa situação é fazer o levantamento dos requisitos junto aos stakeholders (veja as nossas lições sobre esse tema). Sem clareza sobre o “o que” o software deve fazer, não há como metrificá-lo.
Após o levantamento dos requisitos, dê continuidade ao processo de Engenharia de Requisitos (veja as nossas lições sobre esse tema), onde uma especificação detalhada dos requisitos funcionais e não funcionais do software deverá ser criada.
De posse da Especificação de Requisitos do Software, você pode iniciar a modelagem do seu programa por meio da UML. Os Diagramas de Caso de Uso e de Classe, apesar de não serem obrigatórios na metodologia de métrica de software do IFPUG, podem te ajudar. Faça-os e mantenha-os à sua disposição.
O próximo passo é seguir o método de métrica de software chamado Pontos por Função, o qual aprenderemos nesta lição. Aqui é o momento no qual você já possui elementos suficientes para medir o seu software e estabelecer métricas com relação ao seu projeto.
A Análise de Pontos de Função é uma abordagem direta para a medição de software que sugere ao projetista pensar em termos de requisitos lógicos dos usuários. A métrica de ponto por função tem um grupo mantenedor das suas práticas, o IFPUG (International Function Point Users Group – Grupo Internacional de Usuários de Pontos de Função - https://ifpug.org/), que permite a realização pelos profissionais de certificações sobre métricas de software. No Brasil, temos um órgão associado ao IFPUG, o Brazilian Function Point Users Group – Grupo Brasileiro de Usuários de Pontos de Função (https://bfpug.wordpress.com/).
Muitos desenvolvedores e contadores de pontos de função iniciantes frequentemente “tropeçam” nas suas contagens iniciais por não entenderem que os mesmos termos utilizados na contagem de pontos de função e na tecnologia da informação têm significados diferentes, a depender do contexto que está sendo aplicado.
DICA: preste muita atenção nas definições usadas na contagem, para não confundir o termo dentro da contagem de ponto de função com o termo usado no seu dia a dia.
Um dos desafios na implementação da Análise de Pontos de Função é tornar o método compreensível aos profissionais. Por serem baseados em requisitos funcionais dos usuários (o que o software faz), os pontos de função “forçam” os projetistas de sistemas a pensarem em termos lógicos.
A Análise de Pontos de Função (APF) é um método simples que determina o tamanho funcional de um sistema de informação ou projeto. O tamanho funcional pode ser usado para diferentes propósitos, por exemplo: orçamento, cálculo do prazo e qualquer outra finalidade associada ao tamanho do software.
De acordo com Manual de Práticas de Contagem do IFPUG (BRASIL, [s. d.]), existem cinco tipos de funções que são contados e avaliados. Vamos conhecê-los:
Arquivo Lógico Interno (ALI).
Arquivo de Interface Externa (AIE).
Entrada Externa (EE).
Saída Externa (SE).
Consulta Externa (CE).
A Figura 1, a seguir, apresenta a localização de cada uma dessas métricas/funções com relação à sua associação na fronteira do sistema.
Agora, iremos para uma parte muito importante desta lição: conhecer cada um dos tipos de acordo com suas funções.
Basicamente, são as tabelas, relacionamentos e atributos que compõem o projeto de banco de dados do sistema.
É praticamente a mesma coisa de uma ALI, porém refere-se a dados externos ao sistema. Busca medir dados que o sistema pode receber de um ambiente externo (outro sistema, por exemplo).
São os formulários para a entrada de dados, as telas onde o usuário do software entra com dados. Quanto maiores e mais complexos forem esses formulários, maior será a sua métrica e esforço para o seu desenvolvimento.
São os relatórios que um sistema deve emitir ou a geração de arquivos para integração com outros sistemas. Tudo que é gerado pelo sistema e que cria uma saída, ou seja, um novo documento/arquivo digital em qualquer formato é considerado um SE.
A consulta externa tem uma particularidade. É algo que entra no sistema, é processado e tem uma saída, ou seja, diferencia-se do EE, que apenas recebe dados, e do SE, o qual apenas envia dados. Neste caso, o CE é algo que vem de fora, é processado pelo sistema internamente e, então, enviado novamente para o destinatário ou não.
Exemplo: o sistema de consultas do Serasa Experian. Um sistema pode enviar o número de um CPF ao WebService do Serasa Experian, o sistema recebe esse CPF, consulta a base de dados e retorna pendências ou não sobre dívidas daquela pessoa. No caso, o WebService seria essa CE. Pode-se considerar que grande parte dos Web Services se enquadram na classificação de uma CE na contagem de pontos de função.
Até o momento, demos o primeiro passo para conhecer as funções da métrica pontos de função. Agora, veja, a seguir, todos os passos até chegarmos no cálculo do tamanho do software:
Passo 1: identificar as funções do sistema que são relevantes ao usuário (Engenharia de Requisitos).
Passo 2: determinar a complexidade funcional de cada função (ver como nas tabelas, a seguir).
Passo 3: calcular a contagem dos pontos de função não ajustados do sistema, os pontos de função brutos (veja nas discussões posteriores).
Passo 4: indicar os requerimentos gerais para o sistema usando as 14 características gerais dele (serão discutidas mais à frente).
Passo 5: calcular a contagem dos pontos de função ajustados do sistema (como fazer este cálculo é o nosso objetivo final).
Para ser possível calcular cada tipo de função que acabamos de comentar (ALI, AIE, EE, SE, CE), é utilizada, inicialmente, uma tabela com as complexidades (baixa, média ou alta) das funções (Passo 2), conforme as Tabelas 1, 2 e 3, a seguir:
As tabelas anteriores deverão ser consultadas para a classificação e montagem da tabela da primeira parte da contagem (Passo 3)!
Para realizarmos a nossa contagem, consideramos que o software tem 15 telas no total (EE), sendo: 3 telas de complexidade alta, 7 telas de complexidade média e 5 telas de complexidade baixa. Com o intuito de auxiliar no nosso exemplo, estamos considerando que há 3 ALI de complexidade baixa, 2 de complexidade média e 2 de complexidade alta.
Atenção: atente-se ao fato de que o número de EE não necessariamente será igual ao número de ALI. Isso ocorre porque o processo de Normalização do Projeto de Banco de Dados pode separar os atributos em mais ou menos tabelas.
Agora, você montará uma tabela, preenchendo-a com estes dados e calculando um total para cada linha, com base nos dados das Tabelas 1, 2 e 3. Depois disso, some o total de cada linha, a fim de achar um total geral, o que chamamos de ponto de função bruto. Veja um exemplo na Tabela 4:
No exemplo, não foram preenchidas todas as linhas, para que o nosso cálculo fique mais simples de ser compreendido. Pode acontecer, mas é bem difícil existir um software que não tenha nem Saída Externa, nem consulta externa, mas como era somente para demonstrar o uso da tabela, não houve preocupação com isso. Veja, a seguir, a tabela de cálculo padrão sem nenhum dado (limpa).
Com base nas tabelas anteriores, você lançará os valores na Tabela 5, para encontrar o valor do ponto de função bruto.
O penúltimo passo na contagem de pontos de função envolve o ajuste da contagem por meio de um Fator de Ajuste de Valor (FAV), o qual avalia restrições de negócios adicionais do software não consideradas pelos cinco tipos de funções. O FAV foi criado para considerar, também, na contagem, aspectos de requisitos não funcionais do software, e não somente os requisitos funcionais (ponto de função bruto). O FAV é composto por 14 características gerais de sistema, vejamos cada uma delas:
Comunicação de dados: descreve a forma de comunicação dos dados do sistema. Exemplo: TCP/IP com criptografia, que tipo de criptografia etc.
Processamento de dados distribuído: observa se o sistema tem a necessidade de que haja um processamento dos dados em diferentes estações. Geralmente, esta é uma realidade de softwares matemáticos e científicos, não sendo exigida em softwares comerciais.
Desempenho: é difícil de estabelecer, mas, na maioria das vezes, está vinculado a softwares de tempo real e embarcados, onde o tempo de resposta deve ser medido cuidadosamente.
Utilização do equipamento (restrições de recursos computacionais): são observadas as necessidades de hardwares externos necessários ao sistema em desenvolvimento.
Volume de transações: busca avaliar a capacidade necessária para suportar o tráfego de dados que o sistema pode ter. Muito tráfego gera a necessidade de infraestruturas mais robustas, encarecendo o projeto.
Entrada de dados online: verifica se o sistema terá uma interface online, ou seja, via web para o recebimento de dados. Sistemas online têm exigências diferentes de sistemas desktop, principalmente os relacionados à segurança da informação.
Eficiência do usuário final (usabilidade): refere-se à necessidade de atender o usuário final, do ponto de vista das necessidades dele. Hoje em dia, é um recurso indispensável aos sistemas computacionais conhecer o usuário e desenvolver um produto de acordo com as suas necessidades.
Atualização online: busca avaliar se o sistema precisará receber atualizações online, diretamente via internet, como é o caso do Windows, por exemplo. Muitos sistemas não utilizam esse recurso por ser complexo de se controlar. Geralmente, as empresas optam por enviar um novo arquivo de instalação.
Processamento complexo: verifica se o sistema possui um processamento de informações complexo, como é o caso de sistemas de inteligência de negócios (Business Intelligence), sistemas de inteligência artificial e outros que necessitem de uma lógica complexa para processar os dados.
Reusabilidade: está diretamente relacionada à utilização de padrões de desenvolvimento do software. Caso haja essa exigência por parte do contratante, este item deve ser considerado com pontuação máxima.
Facilidade de implantação: muitos softwares são simples de serem implantados, necessitando de poucas horas, enquanto outros envolvem diferentes empresas, filiais, paralisação da linha de produção, entre outras demandas. Avalia-se, aqui, esta dificuldade para a implantação do sistema.
Facilidade operacional (processos operacionais, tais como inicialização, cópia de segurança, recuperação etc.): este item busca avaliar o quanto o sistema possui recursos automatizados, por exemplo, salvamentos automáticos de um texto, recursos internos para validação de dados, integração com pacotes de escritório, entre outros. Quanto mais recursos, mais avaliado deve ser. O motivo é óbvio, quanto mais funcionalidades o sistema tiver, mais caro ele fica.
Múltiplos locais e organizações do usuário: está relacionado ao quesito implantação, sistemas que precisam ser implantados em diferentes locais tendem a ser mais complexos e, consequentemente, mais caros, penosos e com mais exigência de controle dos múltiplos locais.
Facilidade de mudanças (manutenibilidade): busca avaliar a capacidade do ambiente em suportar uma mudança. Algumas empresas possuem forte resistência a mudanças, enquanto outras já se acostumaram e qualquer migração ou qualquer novo sistema é bem acomodado. Busca-se avaliar, aqui, as dificuldades que um novo sistema poderá ter.
Você deve, agora, calcular o nível de influência de cada item. Para encontrar o valor, basta multiplicar cada uma das 14 características pelo seu nível de influência, cada uma dessas características é avaliada em uma classificação de 0 (sem influência) a 5 (muita influência). Veja o quadro, a seguir, capaz de te auxiliar neste cálculo.
A soma total, também denominada Nível de Influência, pode ter valor que varia entre 0 (14 x 0) e 70 (14 x 5).
Usando o Nível de Influência das características gerais do sistema (passo 4), podemos calcular o Fator de Ajuste de Valor dado pela seguinte fórmula:
Fator de Ajuste = 0,65 + 0,01 * Nível de Influência
Os valores de 0,65 e 0,01, apresentados na fórmula, foram definidos pelo IFPUG (BRASIL, [s. d.]) e não carecem de serem discutidos neste trabalho.
A contagem dos Pontos de Função Ajustados é calculada da seguinte forma:
Contagem dos Pontos de Função Ajustados = Contagem dos Pontos de Função Não Ajustados * Fator de Ajuste
Parece bastante trabalhoso o cálculo dos pontos de função, mas não é tão difícil assim se tivermos em mãos uma ótima documentação dos requisitos funcionais e não funcionais do software. Todas as nossas lições anteriormente estudadas te ajudarão a chegar neste momento com essa documentação.
Acredito que você tenha percebido, ao longo das páginas desta lição, que a métrica de software somente é possível caso você tenha uma documentação adequada de aspectos internos (por exemplo, projeto do banco de dados ou Diagrama de Classe) e dos requisitos funcionais (Especificação de Requisitos de Software e/ou Diagrama de Caso de Uso) do software a ser “metrificado”. Não é possível aplicar a métrica de pontos de função sem essa compreensão profunda do software.
Com a aplicação das muitas formas para se elicitar, analisar e especificar requisitos bem como projetar um software, você tem plenas condições de aplicar a métrica de pontos de função sem dificuldades. Tenha em mente que saber a métrica de um software é a base para ter condições de calcular o custo desse software e um prazo médio à sua realização, a fim de ser possível analisar se “vale a pena” desenvolver o software internamente, contratar uma empresa para essa tarefa ou comprar um software pronto. Essa é uma decisão estratégica que, muitas vezes, está nas mãos da equipe de TI. Quanto mais preciso for o cálculo da métrica do software a se desenvolver, mais assertiva será a decisão.
Apresentarei a você um cálculo hipotético de um software, passo a passo. Vamos lá!
1. Identificar as funções do sistema (isso deve vir da sua etapa de Engenharia de Requisitos e Projeto):
- Cadastrar livros.
- Cadastrar usuários.
- Gerir empréstimos de livros.
- Gerir devolução de livros.
- Consultar livros disponíveis.
- Gerar relatório de empréstimos.
2. Classificar e determinar o nível de complexidade de cada função:
ALI (Arquivo Lógico Interno)
- Cadastrar livros: médio (estamos supondo que este cadastro envolve de duas a cinco tabelas e de 20 a 50 atributos).
- Cadastrar usuários: baixo (estamos supondo que este cadastro envolve apenas uma tabela e de 1 a 19 atributos).
EE (Entradas externas)
- Gerir empréstimo de livros: médio (estamos supondo que este formulário usa até duas tabelas e de 5 a 15 atributos).
- Gerir devolução de livros: baixo (estamos supondo que este formulário faz referência a apenas uma tabela e de 1 a 4 atributos).
SE (Saída externa)
- Consultar livros disponíveis: baixo. (estamos supondo que este formulário faz referência a apenas uma tabela e de 1 a 4 atributos).
- Gerar relatório de empréstimos: alto (estamos supondo que este formulário faz referência a até duas tabelas e 16 ou mais atributos).
3. Colocar os valores na nossa tabela de cálculo:
Até o momento, temos o cálculo dos requisitos funcionais do sistema, o qual totalizou 35 pontos de função. Contudo precisamos considerar os requisitos não funcionais os quais todo sistema possui.
4. Acrescentar o Fator de Ajuste de Valor (FAV) ao cálculo anterior, levando em consideração as 14 características gerais do sistema de gerenciamento de biblioteca.
Lembrando que cada característica recebe um valor de 0 a 5, no qual 0 indica nenhuma influência e 5 indica influência máxima.
Suponha os seguintes valores para cada característica:
Comunicação de dados: 4
Processamento distribuído: 3
Desempenho: 3
Configuração e instalação: 2
Facilidade de uso: 4
Facilidade de operação: 3
Portabilidade: 2
Facilidade de mudança: 4
Concorrentes externos: 1
Segurança de acesso: 4
Funções especiais: 2
Processamento complexo: 3
Integração de banco de dados: 3
Reutilização de código: 1
Agora, calcularemos o Fator de Ajuste de Valor (FAV) somando os valores das características:
FAV = 4 + 3 + 3 + 2 + 4 + 3 + 2 + 4 + 1 + 4 + 2 + 3 + 3 + 1 = 41
Em seguida, multiplicamos o FAV pelo valor padrão de 0,01:
FAV = 41 * 0,01 = 0,41
5. Agora, podemos recalcular os pontos de função, considerando o Fator de Ajuste de Valor:
Pontos de função ajustado = 35 * 0,41 = 14,35 pontos de função.
6. Por fim, para calcular o valor do software com base nos pontos de função, é necessário levar em consideração o valor do ponto no mercado.
Observação
O valor de um ponto de função no mercado de software brasileiro pode variar dependendo de diversos fatores, como localização geográfica, complexidade do projeto, experiência da equipe, demanda de mercado, entre outros. Não existe um valor fixo estabelecido, pois cada projeto e empresa tem suas próprias políticas de precificação.
Como uma referência aproximada, no entanto, é comum encontrar valores de ponto de função na faixa de R$ 80,00 a R$ 200,00. É importante ressaltar que esses valores são apenas uma estimativa e podem variar, consideravelmente, dependendo das circunstâncias específicas do projeto e das negociações entre as partes envolvidas.
Para calcular o valor do software, multiplicamos o número total de pontos de função pelo valor do ponto de função no mercado ou pelo que foi acordado entre as partes. Suponha que foi definido um valor de ponto de função de R$ 100,00. Assim, temos:
Valor do software = Pontos de função * Valor do ponto de função
Valor do software = 14,35 * R$ 100
Valor do software = R$ 1.435,00
Assim, o valor estimado desse software seria de R$ 1.435,00.
As discussões sobre a métrica de um software são bastante dinâmicas porque acompanham a evolução das tecnologias. Assim, você deve acompanhar, constantemente, as organizações responsáveis por essas métricas bem como as publicações mais recentes, para se manter atualizado(a).
BRASIL. Manual de Medição Funcional de Software. Brasília: Tribunal de Contas da União, [s. d.]. (Versão 4.0).
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. São Paulo: Érica, 2013.