É primordial que os requisitos de software sejam escritos de forma coerente com a nova forma de medição, que é Pontos de Função. Embora a engenharia de requisitos tradicional não aconselhe, o que vemos na prática é que os requisitos devem ser fracionados de forma tal a representar a mínima unidade funcional que seja compreendida pelo usuário e que seja testável pelo desenvolvedor.
Este fracionamento traz a organização e o controle dos requisitos de forma tal a conhecer o produto da melhor maneira possível, além de que é mais fácil gerenciar mudanças em requisitos menores. O Capability Maturity Model Integration (CMMI) não trata da forma como os requisitos serão escritos, mas ainda assim, quando se trata de APF algumas observações devem ser consideradas.
7.1.1. GRANULARIDADE X QUANTIDADE DE REQUISITOS
Ponto de função aponta claramente o conceito de processo elementar que representa um “requisito” do usuário. Isso quer dizer que ele é completo do ponto de vista de usuário, deixa o sistema consistente e a funcionalidade entregue é reconhecida pelo usuário.
Desta forma, ao fracionar demais os requisitos várias funcionalidades são quebradas em partes que sozinhas não tem valor de negócio algum, o que pode levar a um desentendimento sobre o “processo elementar”.
Por exemplo, uma funcionalidade solicitada pelo usuário que é composta por 3 passos, realizadas em momentos diferentes por pessoas diferentes, provavelmente será um ÚNICO requisito pois se mostra como um único processo elementar que só faz sentido se os 3 passos forem dados. Assim, tanto faz realizar 0, 1 ou 2 passos, para o usuário aquela parte não concluída é irrelevante.
Seguindo o exemplo anterior, suponha que a função é uma SE complexa (Que custa 7 PF) poderia ser quebrada em 2 EE simples (3 pontos cada uma) e 1 SE simples (4 Pontos) o que levaria ao total de 10 PF, 3 Pontos mais caro em uma única funcionalidade. Então identificar o processo elementar é um passo mais importante do que identificar requisitos e fluxo de serviços.
7.1.2. ATENÇÃO A REQUISITOS NÃO FUNCIONAIS
O Ponto por Função mede software de acordo com seu tamanho funcional (Requisitos funcionais) e os requisitos não funcionais estão com preço “embutido” dentro do ponto de função (Ver a parte de precificação na seção de considerações para a contagem). Então certos cuidados ao solicitar melhorias não funcionais devem ser observados.
Por exemplo, um caso recente que houve na ATI, se tratava de um sistema que criava e gerenciava documentos. Só que para motivos de usabilidade, foi solicitado que dois tipos especiais de documentos fossem criados e gerenciados (Atas de Registro de Preço e Licitações). Esta solicitação visou o ganho de tempo da criação de atas e licitações bem como preparar o sistema para trabalhar com estes dois modelos.
Desta forma, os dois tipos de documentos solicitados foram a criação do produto final do sistema, criação de documentos, e não novas funcionalidades. Ou seja, um usuário do sistema poderia ter criado o documento tipo Ata e o documento tipo Licitações e disponibilizar para o estado sem o ônus.
Parece pouca coisa, mas a interferência no sistema, uma vez que as atas e licitações eram gerenciadas como quaisquer documentos, mas em locais específicos, o que tornou o sistema 40% maior do que o necessário, implicando em aumento nos custos.
Então é pedido atenção neste aspecto, e alguns cuidados como solicitar as melhorias não funcionais para TODO o sistema. Ou seja, se é necessário que um requisito de segurança seja aplicado em uma transação, solicitar que este requisito seja estendido a todo sistema. Isso pode baratear o produto.
7.1.3. ATENÇÃO A RELATÓRIOS
Os relatórios são um dos pontos mais problemáticos em pontos de função uma vez que é relativamente comum aparecer em um sistema relatórios parecidos, mas que são “diferentes” nos dados em que apresentam. Isso significa que novas funcionalidades (Consultas ou Saídas Externas) surgem a cada novo relatório e que relatórios parecidos significam funcionalidades diferentes embora parecidas.
Então neste ponto é recomendada a junção de vários relatórios parecidos em um único relatório que atende a todas as demandas. Isto significa uma redução não só do pagamento, mas do tamanho do sistema uma vez que manutenções no sistema ocorrerão uma vez só.
7.2. DICAS NA DEFINIÇÃO DA FRONTEIRA
A fronteira determina o que é interno e externo para uma aplicação, de acordo com a visão do usuário, sendo de fundamental importância na medição funcional. Um erro nesta atividade pode ocasionar duplicidade na identificação de funções, identificação incorreta ou até sua omissão. Em muitos casos isto reflete no aumento da contagem, trazendo prejuízo para a instituição.
Seguem algumas dicas que podem auxiliar na identificação da fronteira:
• A fronteira deve ser delineada de uma perspectiva de negócio, não devendo levar em consideração detalhes técnicos ou de implementação.
• Obtenha uma documentação do fluxo de dados do sistema e desenhe uma fronteira em volta para destacar quais partes são internas e externas à aplicação.
• Verifique como a aplicação é gerenciada; se é desenvolvida ou mantida em sua totalidade ou em partes por equipes distintas.
• Verifique se há usuários distintos especificando requisitos para cada parte do software. Isto pode representar fronteiras entre os sistemas.
• Identifique áreas funcionais atribuindo propriedade a certos tipos de objetos, como entidades e processos.
• Documente previamente as fronteiras de todas as aplicações que poderão ser objeto de medição.
7.3. DICAS NA IMPLANTAÇÃO DO PROCESSO
A utilização de pontos de função na contratação de desenvolvimento de software têm crescido bastante no mercado brasileiro. Entretanto este processo ainda não atingiu sua total maturidade. Por isso, algumas empresas encontram dificuldade na utilização da técnica e acabam sendo mal sucedidas em seus projetos. Seguem algumas dicas que podem minimizar ou até evitar problemas na implantação deste processo:
• Capacitação: conhecer corretamente a técnica de pontos de função é fundamental. Embora seja óbvio, observa-se que muitas organizações erram neste passo básico.
• Estabelecer objetivos iniciais modestos: começar com um projeto piloto em um sistema simples. Avaliar os resultados, efetuar as correções necessárias, revisar os objetivos e seguir em frente.
• Esteja ciente das limitações da técnica: Existem domínios de problema em que a APF não é indicada. Por exemplo, em sistemas de otimização a técnica não é adequada para medir as partes com alta complexidade algorítmica. A técnica também não é recomendada para estimativa de projetos muito pequenos (< 100) ou atividades pontuais, pois pode haver distorções significativas.
• Busque ajuda se necessário: Uma consultoria externa pode evitar "cabeçadas desnecessárias" e agilizar o processo, trazendo experiências e ajudando a corrigir rumos. Também existe um grupo de usuários muito ativo no Brasil, o BFPUG (Brazilian Function Point Users Group) que possui um fórum de discussão ideal para este objetivo.
• Cuidado com os conflitos de interesse: a medição do serviço em pontos de função nunca deve ser realizada somente pelo fornecedor, pois ele será remunerado justamente pelo resultado da medição! Observa-se esta prática indesejável em algumas organizações (inclusive públicas). Pode-se utilizar pessoal interno para realizar a medição, ou na pior das hipóteses validar por amostragem as medições realizadas. Outra opção é contratar uma empresa externa para este serviço.
• Esteja atento ao preço do ponto de função: este item é tão importante que vale abordá-lo em mais detalhes.