As Métricas de Software

O objetivo do presente trabalho é trazer um roteiro de métricas a luz dos conceitos e

técnicas da metodologia da Análise de Pontos por Função. Tal análise será realizada levando em consideração exemplo reais e hipotéticos fundamentados e referidos.

3

4. Conteúdo do trabalho

Vivemos em um mundo em que a tecnologia tem ganhado papel cada vez mais

importante na forma como nos relacionamos, fazemos negócios, trabalhamos e realizamos as mais diversas tarefas do dia-a-dia. Diante disto, a demanda por profissionais de desenvolvimento capazes de tirar ideias do papel e solucionar problemas reais transformo-os em linhas de código está aumentando vertiginosamente. Com isso, ferramentas e sistemas surgem todos os dias e de todas as formas possíveis. Isto nos leva aos seguintes questionamentos: Como medir a qualidade do que estamos produzindo no que diz respeito a sistemas? Como garantir que o que está sendo entregue realmente está gerando valor ao usuário? Como estabelecer que as funções realizadas pelo sistema estão de acordo com os cenários da vida real e cotidiana de quem irá utilizá-lo?

Tais questões podem, à primeira vista, parecerem até mesmo filosófica. Entretanto, quem contrata o serviço de desenvolvimento de um sistema espera que este torne sua vida, e de outros que por ventura também o utilizarão, mais simples e confortável. Outro ponto importante de ser ressaltado é em relação aos custos de um projeto. Não é incomum vermos projetos de TI que se iniciam com uma estimativa de custos que se mostra muito fora da realidade de acordo com o tempo vai passando e os problemas vão surgindo.

Outra camada de complexidade nesta problemática é o avanço das ferramentas e linguagens de programação. Antigamente, com linguagens mais prolixas, uma métrica de software plausível seria por contagem de linhas de códigos (metodologia KLOC). Porém, hoje isso não se mostra como uma alternativa viável, assim como levar em consideração somente a quantidade de código que um programador pode desenvolver em determinado período de tempo também não se mostra totalmente de acordo com as necessidades dos stakeholders.

4

Diante mudanças tão profundas na forma como nós, programadores, trabalhamos, novas metodologias precisaram ser criadas a fim de medir nossos custos e qualidade do que criamos, aí é que nos encontramos com a Análise dos Pontos por Função.

A métrica Ponto por Função tem como principal objetivo medir o quão funcional nosso sistema se apresenta. Para isto ela leva em consideração como as funcionalidades que estão presentes se relacionam com os usuários. A Análise de Pontos por Função (APF) lança mão da comparação entre o que o cliente demandou e o que o desenvolvedor entregou. É importante salientar que, além de além de medir a qualidade do software, essa ferramenta também é capaz de estimar custos do projeto como um todo, prever possíveis erros bem como o tamanho do projeto.

A fim de estabelecer padrões para esta metodologia, o Manual de Práticas de Contagem (IFPUG, 2010) compilou regras, procedimentos e instruções para o desenvolvimento de um roteiro de métricas com base na APF.

A primeira etapa para que possamos iniciar nossa análise é, indubitavelmente, a recuperação de toda documentação do projeto que eventualmente esteja disponível. Essa recuperação tem por intenção a identificação dos requisitos funcionais do nosso projeto. A partir deste momento já devemos ter em mente qual o objetivo da análise que estamos estabelecendo, por exemplo a contratação do serviço de desenvolvimento de determinado projeto.

A partir deste ponto já podemos estabelecer qual será o escopo e o tipo de contagem que realizaremos em nossa análise, sendo que por escopo compreende-se quais serão as funcionalidades que serão metrificadas. Quanto aos tipos de contagem, a APF apresenta três possibilidade: desenvolvimento, melhoria ou aplicação instalada. Vale ressaltar que todo este estudo será realizado tendo como limite uma ​fronteira de aplicação​, que trata-se do limite lógico entre o sistema e o usuário, sendo este um conceito puramente subjetivo.

5

Após estabelecermos quais serão nossos objetivos, escopo e limites, devemos então partir para a identificação de requisitos de dados e de funções transacionais, ou seja, valores do domínio de informação. Estes são definidos tendo os seguintes tipos funcionais em vista:

Entradas Externas (Number of External Inputs - EEs)

Entradas externas são geradas através da interação do usuário ou também da transmissão de informações por outras aplicações. Este parâmetro nos fornece diferentes dados que serão orientados à aplicação ou também à informações de controle.

Arquivos Lógicos Internos (Internal Logic Files - ILFs)

Devemos diferenciar o que são entradas do que são apenas consultas, estas informações serão contabilizadas separadamente, sendo que as consultas formam um grupo de dados que estarão dispostos de forma logicamente relacionada.

Saídas Externas (Number of External Outputs - EOs)

Qualquer saída que será fornecida ao usuário partindo de dados que foram gerados em nossa aplicação. A forma como esta saída será apresentada pode ser diversa, e entre elas podemos citar telas, relatórios, mensagens, etc.

Consultas Externas (Number of External Inquiries - EQs)

De forma simplista, uma consulta externa é qualquer interação que leva informações de dentro para fora das fronteiras da aplicação (uma entrada online que gera uma saída online)

Arquivos de Interface Externos (Number of External Interface Files - EIFs)

Conjunto ou conjuntos de arquivos lógicos que estão fora do limite da aplicação mas que fornecem informações úteis para o pleno funcionamento dela.

Logo após a etapa de coleta de dados, devemos estabelecer o nível de complexidade para cada um dos parâmetros de medida, sendo eles ​simples, médio ​ou ​complexo​. Também devemos estabelecer qual é a contribuição mensurável