Já falamos sobre como a técnica de APF – Análise por Pontos de Função é muito empregada no Brasil para estimar o tamanho de um software a partir de seus aspectos funcionais.
Apesar de suas fragilidades e das críticas que recebe, precisamos reconhecer sua importância e abrangência de utilização como base de medida de software por inúmeras empresas e, também, por vários órgãos do Governo Federal.
Vamos tentar demonstrar como a aplicação das regras da Análise de Pontos de Função fica facilitada pela estruturação e definição dos Requisitos.
Segundo o IFPUG – International Function Point User Group, que mantém as regras básicas desta métrica funcional, o tamanho de um software é estabelecido a partir das funcionalidades definidas pelo usuário, e independente de aspectos de implementação tecnológica. Portanto, estamos falando, basicamente, de requisitos de software
A técnica como hoje é conhecida, sofreu uma série de alterações e aprimoramentos, desde que foi criada em 1979, por Allan Albrecht, então da IBM.
Existem outras métricas funcionais, ou seja, que buscam medir o tamanho de um software a partir de suas funcionalidades. Entre elas, podemos citar:
- NESMA FPA Methodology
- COSMIC Functional Size Measurement Method
- UKSMA Mk2 FPAou Mark2 Function Point Analysis
- UCP – Use Case Points
Mas voltando à Análise de Pontos de Função, o seu objetivo é medir o TAMANHO FUNCIONAL de um software do PONTO DE VISTA DO USUÁRIO.
A VISÃO DO USUÁRIO representa uma descrição formal das necessidades do negócio do usuário, na sua “linguagem”. A partir disso, os desenvolvedores traduzem essa informação para uma linguagem tecnológica, com objetivo de prover uma solução.
Em outras palavras, o que vai ser “contado” na aplicação da técnica de APF precisa ser “reconhecido” pelo usuário. Eventuais “soluções tecnológicas” não poderão se consideradas nesta contagem. Portanto, a APF pode (e deve) ser aplicada aos requisitos funcionais e não funcionais definidos pelo Analista de Requisitos.
Se conseguirmos identificar os requisitos funcionais, os requisitos não funcionais, os dados e as regras de execução envolvidos, podemos, desde os primeiros momentos, dimensionar o software a ser desenvolvido e começar também a estimar o esforço para desenvolvê-lo.
Na medida em que o domínio dos requisitos vai aumentando e o projeto vai sendo detalhado, o valor das contagens vão se aproximando do valor final, obtido quando o software estiver pronto.
Fica evidente a necessidade de domínio da Análise de Requisitos pelo Analista de Métrica.
Isso ainda vai dar “pano pra manga”… Nos vemos mais adiante.
Fernando Guimarães é coordenador e professor do Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas do Centro Universitário de Brasília – UniCEUB. Também é professor do Curso de Pós-graduação Lato Sensu em Engenharia de Requisitos do UniCEUB, nas modalidades presencial e a distância. Graduado em Engenharia Elétrica, com especialização Eletrônica, pela UnB – Universidade de Brasília, fez especialização em Análise de Sistemas na UCB – Universidade Católica de Brasília. Possui Mestrado em Gestão do Conhecimento e da Tecnologia da Informação pela UCB – Universidade Católica de Brasília. Possui Certificação PMP – Project Management Professional, pelo PMI – Project Management Institute e Certificação CBPP – Certified Business Process Professional, pela ABPMP – The Association of Business Process Management Professionals. Toda a atividade profissional exercida foi em Projetos de Desenvolvimento de Software e em consultoria em Gerenciamento de Processos de Negócios.
Endereço do Currículo Lattes: http://lattes.cnpq.br/5724480423308682
Endereço no Linkedin: https://www.linkedin.com/in/fernando-de-albuquerque-guimarães-msc-pmp-cbpp-78924423/