Por que eu devo ler este artigo:Neste artigo iremos entender o contexto de mercado que exigiu a criação de uma nova metodologia de metrificação não funcional. Será explicado o que são os requisitos não funcionais e suas principais categorias na visão da ISO e do IFPUG.

Na sequência, veremos os principais objetivos e benefícios do SNAP e conheceremos a metodologia em si. Finalizando, veremos um exemplo simples, porém completo de uma contagem não funcional e iremos analisar as conclusões sobre o que foi exposto neste trabalho.

A medição do escopo serve de base para geração da maior parte das métricas do ciclo de vida do desenvolvimento de software. A utilização do tamanho não funcional como parte do escopo medido, permitirá uma melhor adequação das estimativas, principalmente em métricas relacionadas a esforço e custo.

A medição do software é tão importante quanto à de qualquer outro produto vendido por quantidade, peso ou volume. O framework SNAP apresenta uma divisão de três dimensões em que o software precisaria ser medido: os requisitos técnicos, os requisitos de qualidade e os requisitos funcionais.

Para os requisitos funcionais, o mercado adota largamente a análise de pontos de função (APF – BOX 1) definida pelo IFPUG e padronizada pela ISO desde 2009, apesar da ISO também definir outras metodologias como COSMIC, FiSMA, Mark-II e NESMA.

BOX 1. Análise de Pontos de Função

A APF tem suas origens em um trabalho feito na IBM em 1979 por Allan Albrecht que foi formalizado como um guia em 1984. Já em 1988, a versão 2.0 foi publicada pela primeira vez sob a responsabilidade do International Function Point Users Group, o IFPUG.

Na versão 3.0 de 1990 o IFPUG transformou o que era um conjunto de várias interpretações sobre como contar pontos de função em um guia mais organizado e coerente.

A partir da versão 4.1 de 1999 o guia começou a sofrer revisões constantes, graças ao enorme crescimento no uso da técnica e a um maior apoio da comunidade para que o processo pudesse amadurecer.

No Brasil a APF teve um grande crescimento a partir da publicação da Instrução Normativa 2 de 2008, que sugere o uso de “unidade de medida que permita a mensuração dos resultados”.

Enquanto a APF define bem como medir os requisitos funcionais, os requisitos técnicos e de qualidade não são contemplados pela mesma.

Assim, medições feitas apenas com APF normalmente ignoram dimensões importantes do desenvolvimento do software, que podem gerar distorções no planejamento e nos custos.

Para tentar corrigir tais distorções, o IFPUG havia definido uma etapa da medição funcional, chamada de fator de ajuste, que consistia em um ajuste de até mais ou menos trinta e cinco por cento no tamanho funcional original, ou seja, se o sistema possuía 100 pontos de função (PF), seu tamanho ajustado poderia ser um valor entre 75 PF e 135 PF de acordo com os requisitos não funcionais considerados.

O uso do fator de ajuste não foi muito bem aceito pelo mercado, assim como pela ISO, que a partir de 2009, sugeriu que o mesmo não mais fizesse parte da metodologia APF. Desde lá, o fator de ajuste passou a ser descontinuado e disponibilizado como um apêndice do guia do IFPUG.

O principal motivo para a mudança seria o fato de que o requisito não funcional não deveria alterar o tamanho funcional da aplicação, mas ...

Quer ler esse conteúdo completo? Tenha acesso completo