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.
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 ...
