Aqui vamos explicar o que é o SNAP, suas soluções alternativas e como ele se relaciona com a APF em uma suite integrada do IFPUG para suporte à medição na Gestão de Software.

O que há de comum

Inicialmente antes de entrarmos no mérito da relação entre o SNAP e APF, é necessário estabelecer o que ambos têm de comum: Ambos são usados em modelos paramétricos de estimativa na produção de unidades de produto, cuja quantidade é a variável independente ou conhecida para estimar ou prescrever esforço ou custo, como variável dependente ou desconhecida.

O objeto medido na Análise de Pontos de Função

No caso da Análise de Pontos de Função, os pontos de função são, dependendo do propósito, medidas ou aproximações da quantidade e complexidade da funcionalidade solicitada e entregue ao usuário. Para esse fim, o processo de medição considera exclusivamente os requisitos funcionais do usuário. Obviamente, um produto de software não atende exclusivamente requisitos funcionais.

Indicadores de produtividade em Pontos de Função

Portanto, o uso de indicadores de produtividade em pontos de função para estimativas ou gestão de software pressupõe balanceamento no esforço ou custo para atender os requisitos não funcionais correspondentes em determinado escopo avaliado. Normalmente, isso é alcançado por um escopo de certo tamanho e porque a dimensão funcional reflete o comportamento do software ao absorver uma tarefa ou serviço do usuário, enquanto o atendimento aos requisitos não funcionais aproximam-se mais de um comportamento geral; portanto, abordado pela arquitetura. No entanto, isso não é sempre assim; por exemplo, quando uma demanda é referente especificamente à adequação do software ao atendimento de um requisito não funcional.

Demandas para Requisitos Não Funcionais

A própria definição do que seja uma demanda como essa não é trivial. Isso porque se mudarmos o referencial de quem seja o usuário quase toda demanda pode ser considerada como funcional. Essa é a abordagem usada pelo COSMIC para medir requisitos não funcionais.

Um ponto de atenção é a necessidade de se considerar as particularidades referentes aos diferentes processos produtivos em cada nível de usuário.

Por exemplo, medir software de arquitetura, onde os usuários são componentes de software interagindo entre si, não necessariamente envolve o mesmo custo unitário ( R$ / PF ) ou taxa de entrega ( HH / PF ) que os respectivos indicadores para o desenvolvimento de aplicações comerciais, onde os usuários são pessoas e outras aplicações no mesmo nível.

A solução histórica do IFPUG – Valor do Fator de Ajuste (VAF)

No passado o IFPUG tentou definir um modelo em que sua unidade de medição fosse o resultado da medição dos requisitos funcionais e, ao resultado dessa medição, fosse aplicado um fator de ajuste. Isso buscava capturar no tamanho a variância no esforço advindo de diferentes restrições descritas nas 14 Características Gerais de Sistemas (GSC).

Esse modelo faliu quando o universo da aplicação da APF extrapolou, em muito, a realidade de meados da década de 1980. Naquela época, a variação de 1% de variação no tamanho a cada variação de 1 na avaliação dos Níveis de Influência (DI) de cada GSC era razoável. Desde há bastante tempo já não o é mais.

Ademais, ele era e é inútil para caracterizar a medição especificamente de demandas relativas a serviços que não estejam relacionados especificamente a uma tarefa ou serviço do usuário: qualquer valor de fator de ajuste multiplicado por zero é zero!

O inception do SNAP

Dai, surge o problema para o qual o SNAP nasceu como proposta de solução. Seu foco é definir um procedimento de avaliação de software em termos de seus requisitos não funcionais (SNAP é a a sigla para Software Non-Functional Assessment Process) e o manual que define seu procedimento é o APF (Assessment Practices Manual) .

SNAP Points (SP): Unidade de medida no SNAP: Apurados a partir da análise do projeto (design) dividido em componentes, processos ou atividades usados no atendimento de requisitos não funcionais

Casos de uso do SNAP

Como exemplo de itens de projeto citados acima temos:

• Projeto para adequar aplicação em que o volume de transações chega a comprometer a manutenção dos níveis de serviço de tempo de resposta.
• Programas que implementam algumas funções reestruturados para parte de seu processamento ser on line e o restante processado ao final do dia;
• Tabelas de banco de dados antes normalizadas reorganizadas para agora incorporar alguma redundância em troca de maior velocidade na recuperação de dados

Soluções alternativas ao SNAP

Podemos dizer que o SNAP vem como uma alternativa a algumas orientações do Roteiro de Métricas de Software do SISP. Ele tentou usar os pontos de função da aplicação relativos às funcionalidades impactadas e um fator conforme o tipo de demanda como base para cálculo de demandas não funcionais. O ponto fraco nesses itens do SISP é que efetivamente o trabalho (esforço ou custo) relativo ao atendimento dessas demandas pode ter pouca correlação com os pontos de função; portanto, introduz sérios riscos que provoquem a subestimativa ou superestimativa do esforço ou custo.

Como o SNAP funciona

O núcleo do SNAP são as categorias e subcategorias que buscam enquadram componentes, processos ou atividades do design:

• Enquadrados conforme uma hierarquia de 04 categorias e 15 subcategorias;
• Pretende abordar todos os requisitos não funcionais incluindo os requisitos técnicos e de qualidade;
• Atendimento de requisito não funcional pode envolver o emprego de componentes, processos e atividades em um número de subcategorias.

POR EXEMPLO: O projeto será avaliado em termos das subcategorias “3.3 Processos em Lotes” e “3.2 Tecnologia de Banco de Dados”.

Cada subcategoria tem características em comum:

• SCU associado a cada categoria
• Regras específicas para Identificar e ponderar a quantidade de SP a partir da avaliação da SCU

POR EXEMPLO: SCU da categoria Tecnologia de Banco de Dados é o processo elementar (dimensão funcional)

A relação entre as categorias e os SCU é apresentado na tabela abaixo:

<tabela>

POR EXEMPLO

Subcategoria “3.2 Tecnologia de Banco de Dados”

A partir da aplicação do SNAP e da APF podemos vislumbrar alguns modelos:

• Esforço dependendo da medição integral dos requisitos funcionais E dos requisitos não funcionais:

HH = PF x Taxa de Entrega (HH / PF) + SP x Taxa de Entrega (HH / SP)

• Ajuste do esforço a partir complexidade derivada do SNAP

HH = PF x Taxa de Entrega (HH / PF) x Fator derivado de SP / PF

• Seleção de taxa de entrega com base na complexidade SP / PF

HH = PF x Taxa de Entrega (HH / PF) conforme tabela de faixas de SP / PF

Além desses três casos, uma variedade de soluções pode ser desenvolvida; por exemplo, considerar a quantidade de HH / PF dentro de uma franquia de SP / PF e, as funcionalidades acima dessa franquia terem alguma medição adicional.

Ou então, usar apenas algumas categorias do SNAP relativas a elementos de projeto, por exemplo Múltiplas Mídias, cuja implementação promove desvios graves em relação à produtividade média. Então, agregar à medição da produção unidades referentes a presença desses elementos a partir de um esquema de compatibilização de PF e SP.

Próximos passos

Quem quiser conhecer melhor o SNAP, entre em contato conosco sobre o interesse porque pensamos em montar um seminário sobre o assunto e o interesse de nossa comunidade é um fator crítico de investirmos nesse sentido.