40 Anos de Pontos de Função: Passado, Presente, Futuro

Por Louis Bouillon

Somente 40 anos atrás, em outubro 1979, Dr. Allan Albrecht proposto pela primeira vez uma técnica para dimensionar a funcionalidade de um sistema de software. Sua técnica foi adotada, tornou-se um padrão internacional, e inspirou várias outras técnicas e muito mais. Este trabalho mostra o passado, e presente (possível) contribuições futuras de Análise de Pontos de Função.

O passado: origens, Motivação e Fundamentação

Nos anos 1970, Linhas de Código (LOCs) foram indevidamente utilizados para o dimensionamento de sistemas de software (e ainda são hoje em alguns domínios funcionais como a sistemas automotivos militar e em tempo real e, só para citar alguns) e isso levou a que Capers Jones rotulado o “paradoxo da produtividade” [1]: escrevendo mais LOCs não significa necessariamente ser mais produtivo ... o estilo de programação, a expressividade de uma determinada linguagem de programação, a regra de contagem de LOCs (físico ou lógico, com / sem linhas comentadas ...) criou uma enorme variabilidade no projeto (sim, projeto!) estimativa. Porque naquela época, tínhamos apenas mainframes, não PCs ou mini-computadores. portanto, a (Programas) esforço produto para implantação foi mais das funcionalidades globais de esforço de projeto e software foram concebidos como a principal prestação concreta de um projeto de software. Como consequência, por muitos anos (e ainda em muitos contratos), Pontos de função (PQ) estavam (e são) erroneamente concebido como o “tamanho do projeto”, enquanto eles só expressar o tamanho funcional do produto. De qualquer forma, O objetivo de Albrecht foi para superar o “paradoxo da produtividade” e encontrar uma maneira de normalizar cálculos de produtividade de uma perspectiva de negócios [2]. A grande idéia era a basear a sua técnica em algo tecnologia independente: processos e dados. portanto, um cálculo FP (e tamanho funcional produto relacionado) derivada da análise de um conjunto de requisitos funcionais do usuário (peles) é o mesmo, apesar da tecnologia e estilo organizacional adotada, enquanto esforço, duração e custo / preço são, claro, variável de acordo com tais elementos. O exemplo típico proposta ao longo dos anos foi a olhar para FP metros quadrados como para medir o “tamanho” de um apartamento: o número de metros quadrados pode ser o mesmo para dois apartamentos em dois lugares diferentes, mas o tempo para construí-las podem diferir (por exemplo. um plano pode ser construído com tijolos ou ser pré-fabricados), bem como os seus custos de produção e valor comercial (um plano em Manhattan, Nova york, deve custar mais por metro quadrado do que outro em outro lugar); o custo não é valor.

O primeiro papel, datado 1979, fundações existem para essa meta, como indicado no seu título (“A produtividade de desenvolvimento de aplicações de medição”). Representou um big-bang para estimativas, tentando trecho entradas / saídas / consultas e dados de uma análise funcional em particular porque um novo número tão poderia ter sido derivada antes da programação e não mais tarde, como fez com uma contagem LOC. Como não é possível prever com um certo nível de precisão o número de LOCs sua equipe irá produzir amanhã ... muita variabilidade!

Há muitas vantagens, mas também algumas questões em aberto: a correlação entre o esforço de projecto (dias de homem) e o tamanho do produto funcional (em FP) não era tão alto, e um Fator de Ajuste Valor (VAF) foi introduzida, a fim de melhorar uma tal relação e o valor de R2 de uma análise de regressão linear. VAF foi inicialmente calculado com 10 Características do Sistema Geral (GSCS) com uma variabilidade de ± 25% no primeiro 1979 papel, alargada a 14 GSCS no segundo e último papel, datado 1983 [3], com uma variabilidade de ± 35% em relação ao valor inicial FP “não ajustadas”. VAF foi, assim sendo, a primeira maneira de indiretamente “tamanho” a contribuição de Requisitos Não Funcionais (NFRs), tanto no produto, bem como o nível de projeto. Este segundo e último papel de Allan Albrecht declarou a estrutura final FPA, dividindo o MESTRE tipo de função de dados inicial para ILF e FEI, e declarou o sistema de ponderação final, (como ainda é válido na IFPUG versão atual CPM v4.3.1, datado 2010 [4]) daquele tempo. portanto, é possível comparar -do ponto de vista dimensionamento funcional- um produto de software realizado hoje com um outro lançado anos atrás para fins de aferição.

Em 1987, IFPUG nasceu e foi realizada em suas mãos a gestão e evolução da técnica de Albrecht. Nos anos seguintes, várias técnicas afastou-se ideias de Albrecht, e apenas alguns tornou-se normas ISO, como mostrado na Fig. 1:

FIG. 1: Normas ISO FSM (com linhas pontilhadas azuis)

FIG. 1: Normas ISO FSM (com linhas pontilhadas azuis)

Eles são (por ordem de aparecimento): Mark-II (1988), NESMA FPA (1990), FISMA (199X) e COSMIC (1998), com um monte de variantes menores (Aqui [5] uma lista de alguns deles).

Primeiros usos da FPA foram determinar o tamanho funcional de produtos de software para fins de estimativa e avaliação do desempenho e -para simplificar- como uma unidade contratual para o pagamento de um contrato de TIC.

Em 1998, ISO começou a criação de uma família de padrões sob o rótulo “14143” com os princípios comuns para a chamada medição Dimensionamento Funcional (FSM) métodos, afirmando de forma clara que tais métodos dimensionado um produto (não um projeto) e só quando se deslocam de peles produtos, que excluiu as versões ISO relacionados que inicialmente incluídos factores de ajustamento tais como VAF [6]. a lógica? Tais fatores “ajuste / calibração” veio de NFRs, portanto, estão fora de alcance para um método EFM. Como evidência: ISO 20926:2003 foi o padrão ISO para v4.1 IFPUG CPM “não ajustados.” versões 4.x -do 1999 em- definições versão refinada e conceitos básicos, em particular “usuário” e “limite”. v4.3 Versão (2010) definitivamente caiu VAF do texto normativo (também na norma ISO / IEC 20926:2009) e manteve-lo para fins históricos no Anexo C.

Enquanto isso, desde peles e NFRs precisam de ser tratados de uma forma paralela, Processo de Avaliação de Software não-funcionais (SNAP) projecto teve início em 2007, libertando v1.0 em 2011 [7], para um novo, primeira medição dimensionamento não-funcionais (NFSM) método, que moveu a partir da norma ISO sobre a qualidade do software do produto (9126 antes [8], e evoluiu para o atual 25010:2011 padrão [9]) durante a tentativa de complementar o dimensionamento funcional, tanto quanto possível. FIG. 2 ajuda a determinar o escopo do projeto direita, com três tipos de requisitos:

FIG. 2: Três tipos de requisitos (do esquema do ‘ABC’)

FIG. 2: Três tipos de requisitos (do esquema do ‘ABC’)

A informação foi escrito de forma diferente do que v4.1 CPM. Eu claramente num 2012 papel que eu escrevi para MetricViews [10], Esquema O ‘ABC’; tal taxonomia também foi usada numa 2015 papel co-escrito por IFPUG / COSMIC para melhor expressar uma taxonomia para NFRs [11]. Esta classificação é crítico desde o início de qualquer projeto para analisar e comparar-los com uma boa análise de benchmarking corretamente. FIG. 3 resume como um requisito usuário poderia ser implantado e divisão, no caso mais amplo, em três pedaços: peles produtos (UMA), NFRs produtos (B) e restrições do projeto / requisitos (C).

FIG. 3: O esquema ABC [10]

FIG. 3: O esquema ABC [10]

A partir necessidades dos utilizadores para o esforço global do projecto final e os custos – O esquema “ABC” [10] em 1997 ISBSG (isbsg.org) nasceu e todos os mais ativos Associações medição de software (SMAs) adere a esta iniciativa de benchmarking. o 2019 lançamento [12] inclui mais de 9,000 projetos, principalmente dimensionado usando os métodos IFPUG e cósmica FPA. Outra norma complementar foi a norma ISO / IEC 14143-5:2004 [13], que propõe critérios para a definição de “domínios funcionais” e permite uma comparação razoável entre os sistemas de software com características semelhantes e distribuição de esforço por tipos de requisitos (abc). Não faz sentido comparar maçãs com laranjas ...

 

O presente: O que está acontecendo?

métodos FSM são difusamente usado em Informação & Tecnologia de comunicação (TIC) contratos, com uma concentração mais elevada, em alguns países (por exemplo. Itália, Brasil, Polônia, Índia), e representam uma base quantitativa para dimensionar o tamanho funcional do produto e pode ajudar na análise de benchmarking para determinar qual poderia ser (aproximadamente) o esforço não funcional em um projeto, como mostrado na Fig.4:

FIG. 4: distribuição de esforço por tipo de requisito (abc) por domínio funcional: um exemplo

FIG. 4: distribuição de esforço por tipo de requisito (abc) por domínio funcional: um exemplo

Um exemplo de distribuição de esforço por tipo de requisito (abc) por domínio funcional é dividir o que é não-funcionais de acordo com o esquema ABC. Um requisito do tipo B pode ser realizado e implementado por um especialista em TI (por exemplo. um administrador de banco de dados, especialista em usabilidade ...) que normalmente custa menos do que um outro profissional (por exemplo. a / gerente de serviço do projeto, um especialista em medição, uma pessoa de garantia de qualidade ...) executando uma exigência do tipo C, mas mais de um profissional (por exemplo. analista / programador) executando uma exigência do tipo A. FIG. 5 mostra as duas pirâmides opostos para uma distribuição típica de esforço do projeto por tipo de exigência e custo por homem / dia para cada tipo de profissional [14].

FIG. 5: distribuição de esforço por tipo exigência e custo / homem-dia (de acordo com o esquema ABC)

distribuição de esforço por tipo exigência e custo / homem-dia (de acordo com o esquema ABC). Novamente, lições aprendidas 40 anos de experiência ajudou a definir melhor (e refinar) princípios e regras sobre o âmbito de aplicação da FPA. O ‘123’ esquema é outra classificação [15] para afirmar que tipo de exigências podem estar presentes em uma determinada fase de um projeto (1: dev, 2: Ops, 3: Svc, Manutenção).

FIG. 6: O ‘123’ esquema em conjunto com o esquema do ‘ABC’

portanto, na fase OPS um software é usado, não produziu / mudado, e gera um “zero FP” contagem, bem como quando uma solicitação de mudança incluirá apenas os requisitos do tipo B (por exemplo. para uma manutenção correctiva / perfective, como indicado na norma ISO / IEC 14764:2006 padrão [16], Também citado em v4.3.1 CPM – parte 3, capítulo 4, Páginas 20-21). Mesmo se definições e critérios sobre o que FUR ou NFR foi criado, explicadas e difundida ao longo do tempo, ainda há uma dívida cultural em práticas contratuais e de negócios para usar pelo menos uma unidade de medida (UoM) para o dimensionamento requisitos Um tipo (PQ, qualquer tipo) conjuntamente com o UoM para dimensionar os requisitos do tipo B (por exemplo. com pontos de IFPUG SNAP ou medidas de ISO / IEC 25023 [17], bem como as actividades do tipo C que completam o escopo para estimar todo o esforço necessário para definir o escopo de um projeto. Só quando dimensionar todos os requisitos para os três (abc) tipos, é possível reduzir o “aumento do escopo,”Enquanto ainda há um equívoco histórico sobre o que um tamanhos FP eo que não faz. Mas seria suficiente para saber em um método FSM, que são a sua base de componentes funcionais (BFCs) para a inclusão (ou não) uma actividade ou actividades tais.

Por último mas não menos importante, FP e automação. Dr. Albrecht criou uma “medida de design” para permitir uma estimativa nas fases iniciais de um ciclo de vida. Algumas ferramentas de hoje, depois de 40 anos, derivaria PQ (qualquer tipo) análise de código de software ou trabalhando em algumas formas de notações PELE. Alguns (senso comum) observações e pensamentos: automação é útil se é respeitoso dos quatro critérios: Mais rápido, mais preciso, mais oportuna e mais baixo custo. Se precisarmos de tamanho um novo PELE, um código de ferramenta de análise (como afirmado na nova ISO 19515 padrão em Automated FP [18]) seria inútil e dispendiosa. Ou, usando uma ferramenta assumindo algumas notações UML como entradas implicaria mais horas-homem (e custos relacionados) para traduzir uma exigência escrita de base humana em um formato de meta-linguagem. Além disso, uma organização precisa analisar cuidadosamente o retorno sobre o investimento para essa escolha(s) de acordo com os quatro critérios acima mencionados. criar rapidamente um projecto de linha de base em que o tempo e o esforço são activos críticos pode ser ok sob as condições prévias de que é verificada por meio de um CFPS humana e que o UoM sob âmbito são iguais. De outra forma, automação pode tornar-se arriscada ou difícil de gerir.

 

O futuro: O que podemos esperar?

Como muitas pessoas diriam, o futuro é agora ... mas o que podemos esperar da FPA em um futuro próximo? FPA tem bases sólidas e é independente da tecnologia; o que aprendemos com o passado é que os próximos passos devem ser:

  • Uma melhor e mais acessíveis Requisitos do usuário (UR) gestão, âmbito e a medição durante as fases iniciais de um projecto: este é o objetivo principal e primário que deve ser alcançado.
  • Adoção de FPA às novas tecnologias, através da interpretação adequada da FPA regras básicas de 1979/84. Ainda não podemos medir e tamanho através de novas tecnologias FPA como computação em nuvem [19], Internet das Coisas (Internet das coisas) [20], inteligência artificial e qualquer nova tecnologia nos próximos anos vai trazer-nos.

A nossa melhor aposta não é inventar algo novo, mas para analisar profundamente os nossos processos e dados atuais para determinar novas e diferentes maneiras de engenheiro um sistema de software e ainda dimensionar uma pele com FPA!

Pretendemos continuar usando e melhorando a função valor medição.” (Allan Albrecht, Outubro 1979)

 

Referências

  1. Jones, C., Quais são Pontos de Função? website SPR, URL: http://tiny.cc/tgur7y
  2. Albrecht A. J., “Medir a produtividade de desenvolvimento de aplicações” em Proc. quota conjunta, GUIA, e Desenvolvimento IBM Aplicação , 1979, pp. 83-92. http://tiny.cc/2ywacz
  3. Albrecht A. J. & Gaffney J. E., “função de software, linhas de código fonte, e previsão esforço de desenvolvimento: A validação científica software,” IEEE Trans. Software Eng., vol. 9, não. 6, novembro 1983, pp. 639-647. http://tiny.cc/1zwacz
  4. IFPUG, Ponto de Função manual de Contagem Practice (CPM), lançamento 4.3.1, janeiro 2010, URL: ifpug.org
  5. Lother M., Dumke R., Pontos-Metrics: Comparações e Análise”, em: Tendências Atuais em Medição de Software, Publishing Shaker, 2001, pp.228-267
  6. ISO / IEC, Padrão internacional 14143-1 – Tecnologia da informação – Medição de software – Medição Tamanho Funcional – Parte 1: definição de conceitos, fevereiro 2007
  7. IFPUG, Processo de Avaliação de Software não-funcional (SNAP) Manual de Prática de Avaliação (APM), versão 1.0, setembro 2011, URL: ifpug.org
  8. ISO / IEC, É 9126-1:2001 – Engenharia de software – Qualidade do produto – Parte 1: Modelo de qualidade, Organização Internacional para Padronização, 2001
  9. ISO / IEC, É 25010:2011 -Sistemas e software de engenharia de sistemas Requisitos e Avaliação e Qualidade (Quadrado)-modelos de qualidade do sistema e software, Organização Internacional para Padronização, Março 2011
  10. Bouillon L., The Next Frontier: Medir e avaliar a produtividade não-funcionais, MetricViews, agosto 2012, URL:https://www.ifpug.org/Metric%20Views/MVBuglione.pdf
  11. COSMIC / IFPUG, Glossário de termos de Requisitos Não Funcionais e Requisitos de Projeto usado em medição de desempenho de projetos de software, benchmarking e estimar, v1.0, setembro 2015
  12. ISBSG, D&E (Desenvolvimento & Aprimoramento) repositório, R2019, URL:isbsg.org
  13. ISO / IEC, Relatório técnico 14143-5 – Tecnologia da informação – Medição de software – Medição Tamanho Funcional – Parte 5: determinação dos domínios funcionais para utilização com a medição do tamanho funcional, 2004 (R2019)
  14. Bouillon L., Como lidar com projetos uniformes e mensuráveis: se concentrar em tipos e requisitos, ZeroUnoWeb, Maio 3 2019, URL: http://tiny.cc/y1tr7y
  15. Bouillon L., Interpretar DevOps para medir o bem (e melhor) projetos, PMExpo2017, Apresentação, Outubro 2017, URL:https://www.pmexpo.it/2017/programma/009tk
  16. ISO / IEC, Padrão internacional 14764:2006 - Processos do Ciclo de Vida do Software - Engenharia de Software – Manutenção, 2006
  17. ISO / IEC, Padrão internacional 25023:2016 – Sistemas e engenharia de software – Sistemas e requisitos de qualidade de software e Avaliação (Quadrado) – Medição do sistema e qualidade de produto de software, Junho 2016
  18. ISO / IEC, Padrão internacional 19515:2019 – Tecnologia da informação – Object Management Group Automated Pontos de Função (AFP), 1.0, Maio 2019
  19. Woodward S., Função de ponto de Análise Esclarece em um mundo nublado, Metricas 2012, São Paulo (Brasil), novembro 28-29 2012, URL:http://www.bfpug.com.br/metricas2012/woodward.pdf
  20. Cagley T., Pontos de Função e IOT, ou como a minha cozinha é me espionando!, IFPUG ISMA17, Bangalore (Índia), Março 8, 2019

Sobre o autor

Luigi Buglione é o diretor IFPUG para Conferência / Educação e Presidente da Função Gruppo Utenti Ponto Italia – Italiano Software Metrics Association (GUFPI-ISMA) (www.gufpi-isma.org). Ele trabalha como Medição e Processos Especialista Melhoria em Engenharia Ing. Inf. SpA em Roma, Itália e Professor Associado na École de Technologie Supérieure (ETS) - University of Quebec, Canadá. Ele alcançou várias certificações, incluindo CFPS IFPUG, CSP, CSMS, e CCFL COSMIC sobre Medição de Software. Ele é um orador regular em conferências internacionais sobre Sw Medição / Serviço, Melhoria de Processos e Qualidade e está ativamente parte do Internacional e Associações Técnica Nacional de tais questões. Ele recebeu um Ph.D. no MIS e uma cum laude grau em Economia. Luigi pode ser alcançado em luigi.buglione@eng.it.

Você pode gostar...