O que é um ponto de função COSMIC, e em que difere da estimativa em horas?
A Mesterséges Intelligencia Központ Kft., empresa de desenvolvimento de software de Budapeste, mede o tamanho do software em pontos de função COSMIC: assim, o tamanho é uma propriedade do software, não a impressão de quem estima, e é verificável, reprodutível e permite comparar duas propostas.
Em resumo: o COSMIC (ISO/IEC 19761) mede o tamanho funcional do software: cada movimento de dados (entrada, saída, leitura, escrita) vale 1 ponto de função COSMIC (CFP). A estimativa em horas diz quanto trabalho espera quem estima; o tamanho medido diz qual é a dimensão da tarefa. Por isso, é verificável, pode ser medido de novo e permite comparar duas propostas. O esforço pode ser deduzido a partir do tamanho e da produtividade empírica.
O que é a medição do tamanho funcional?
O tamanho do software pode ser expresso de muitas formas: em linhas de código, em horas, em pontos. A medição do tamanho funcional (em inglês, functional size measurement, FSM) mede o que o software tem de fazer do ponto de vista dos seus utilizadores, e não a forma como é implementado. Os seus conceitos básicos são fixados pela norma ISO/IEC 14143-1:2007; segundo a descrição da norma, o objetivo é precisamente que a medição se concentre nas funções pedidas pelo utilizador, e não na forma de implementação.
A base da medição é o conjunto dos requisitos funcionais do utilizador (functional user requirements, FUR): a parte dos requisitos do utilizador que descreve que tarefas e serviços o software tem de executar. O desempenho, a segurança ou a tecnologia escolhida não fazem parte deles; falamos disso mais abaixo, a propósito dos limites.
Existem vários métodos normalizados de medição do tamanho funcional. Os mais conhecidos são o COSMIC (ISO/IEC 19761:2011) e o método IFPUG (ISO/IEC 20926:2009); a ISO normalizou também outros métodos (NESMA, FiSMA, Mk II). Todos partem dos requisitos, mas com regras e unidades de medida diferentes, pelo que os números medidos com métodos diferentes não podem ser comparados diretamente.
O que é o COSMIC?
COSMIC é a sigla de Common Software Measurement International Consortium: uma organização sem fins lucrativos que mantém o método e organiza a certificação dos medidores. O método surgiu no final dos anos noventa como evolução dos métodos anteriores de pontos de função, tornou-se norma ISO em 2003, e a edição atualmente em vigor é a ISO/IEC 19761:2011. A descrição pormenorizada do método, a versão 5.0 do COSMIC Measurement Manual, pode ser descarregada gratuitamente; a primeira parte é de 2021, e a segunda, de 2024.
Segundo a norma, o método é adequado para medir software de aplicação (por exemplo, sistemas empresariais), software de tempo real e combinações de ambos, ou seja, permite medir tanto um sistema ERP, CRM ou de loja online como um software de controlo.
Os conceitos do modelo COSMIC
O COSMIC descreve o software com um modelo simples: o software troca dados com os seus utilizadores funcionais através da sua fronteira e, dentro da fronteira, lê do armazenamento persistente e escreve nele.
| Conceito | O que significa | Exemplo |
|---|---|---|
| Utilizador funcional | quem ou o que envia dados ao software ou espera dados dele: uma pessoa, outro software ou um dispositivo | o funcionário administrativo, o sistema de faturação |
| Fronteira | interface conceptual entre o software medido e os seus utilizadores funcionais | a interface web e as interfaces abertas a outros sistemas |
| Evento desencadeador | um acontecimento em resposta ao qual o utilizador funcional inicia um processo | surge um novo cliente |
| Processo funcional | unidade elementar dos requisitos, executável de forma autónoma; um conjunto coeso de movimentos de dados | «registar um novo cliente» |
| Grupo de dados | conjunto de atributos de dados que dizem respeito a uma única coisa sobre a qual o software tem de tratar dados | o Cliente: nome, morada, número de contribuinte, e-mail |
| Movimento de dados | a deslocação de um único grupo de dados; há quatro tipos | ver abaixo |
Os quatro movimentos de dados:
- Entry (entrada): um grupo de dados chega ao processo, vindo do utilizador funcional, através da fronteira.
- Exit (saída): um grupo de dados sai do processo, através da fronteira, para o utilizador funcional.
- Read (leitura): o processo lê um grupo de dados do armazenamento persistente.
- Write (escrita): o processo escreve um grupo de dados no armazenamento persistente; a eliminação também conta como escrita.
Algumas das regras de medição que determinam a contagem:
- Cada movimento de dados vale 1 CFP. O tamanho de um processo funcional é a soma dos seus movimentos de dados, e o do software é a soma dos tamanhos dos seus processos.
- Cada processo funcional tem pelo menos dois movimentos de dados: uma entrada desencadeadora e pelo menos uma saída ou escrita.
- Dentro de um processo, cada tipo de movimento do mesmo grupo de dados conta apenas uma vez, independentemente do número de campos.
- Todas as mensagens de erro e de confirmação de um processo contam, em conjunto, como uma única saída.
- O tamanho depende dos tipos, e não das ocorrências: registar dez ou dez mil clientes por dia não altera o tamanho.
- O método não mede separadamente o processamento dos dados (cálculos, validações): este faz parte do movimento de dados em causa.
O resultado situa-se numa escala de razão, ou seja, os tamanhos podem ser somados e comparados: duas partes de 40 CFP perfazem, em conjunto, 80 CFP, e os subtotais podem também ser apresentados por grupo de funções.
Um exemplo prático: «registar um novo cliente»
Tomemos um requisito simples: «O funcionário administrativo regista os dados de um novo cliente (nome, morada, número de contribuinte, e-mail). O sistema verifica se o cliente ainda não está registado, guarda-o e informa do êxito ou do erro.» Os passos da medição:
- O utilizador funcional é o funcionário administrativo, e o evento desencadeador é o aparecimento de um novo cliente.
- O grupo de dados é o Cliente; os quatro atributos dizem respeito à mesma coisa, por isso formam um único grupo.
- Os movimentos de dados são identificados a partir das frases do requisito, e cada um deles é contado.
| Passo | Movimento de dados | Grupo de dados | Tamanho |
|---|---|---|---|
| O funcionário envia o formulário | Entry (entrada) | Cliente | 1 CFP |
| O sistema verifica se o cliente já existe | Read (leitura) | Cliente | 1 CFP |
| O sistema guarda o novo cliente | Write (escrita) | Cliente | 1 CFP |
| Informação sobre o êxito ou sobre qualquer erro | Exit (saída) | mensagem de erro e de confirmação | 1 CFP |
| Total | quatro movimentos de dados | um grupo de dados | 4 CFP |
O exemplo «registar um novo trabalhador» do guia publicado no site do COSMIC está construído da mesma forma. As alterações ao requisito refletem-se assim no tamanho:
- Se o sistema também tiver de passar o novo cliente ao sistema de faturação, isso é mais uma saída, para outro utilizador funcional: 5 CFP.
- Se o código postal tiver de ser verificado numa tabela de localidades, isso é mais uma leitura, porque diz respeito a outro grupo de dados: mais 1 CFP.
- Se o formulário pedir doze campos sobre o cliente em vez de quatro, o tamanho não muda, porque o grupo de dados é o mesmo.
- Se for preciso modificar um processo existente, o tamanho da alteração é a soma dos movimentos de dados acrescentados, modificados e eliminados.
O exemplo mostra também porque é que a medição é verificável: por trás de cada CFP há um requisito identificado, um grupo de dados e uma regra. Se alguém a contestar, é possível dizer exatamente de que linha se trata.
Medir cedo, refinar depois
Uma medição COSMIC começa pela definição do objetivo e do âmbito da medição: o que medimos, o que está incluído e para que vamos usar o resultado. Uma medição exata exige requisitos suficientemente pormenorizados para identificar os processos funcionais e os respetivos movimentos de dados. No início de um projeto, muitas vezes estes ainda não existem; para esse caso, o COSMIC publica métodos aproximados para a estimativa precoce do tamanho e, depois de os requisitos estarem elaborados, pode seguir-se a medição exata.
O guia do método alerta também para o facto de muitas necessidades que, à partida, parecem não funcionais (por exemplo, o tempo de resposta ou a facilidade de utilização) se transformarem, ao longo do projeto, em funções do software, o que faz o tamanho crescer aparentemente. Isto não é um defeito da medição; mostra que o requisito ficou mais preciso. Na prática, vale por isso a pena escrever a especificação item a item, medir de novo as alterações com o mesmo método e apresentar à parte o tamanho de cada alteração. Assim, o crescimento do âmbito não acontece em silêncio, mas fica visível em números.
Comparação: horas, story points, IFPUG, COSMIC
| Critério | Estimativa em horas | Story points | Pontos de função IFPUG | Pontos de função COSMIC |
|---|---|---|---|---|
| O que exprime | o trabalho que quem estima espera | a estimativa relativa da equipa; nem sempre é claro se de tamanho, de esforço ou de tempo | tamanho funcional | tamanho funcional |
| É normalizado? | não | não | sim, ISO/IEC 20926:2009 | sim, ISO/IEC 19761:2011 |
| De que depende | da experiência, da prudência e da equipa de quem estima | da equipa concreta; significa algo diferente em cada equipa | dos requisitos | dos requisitos |
| Pode ser verificado de fora? | só com base na explicação de quem estima | dificilmente, fora da equipa | sim, segundo regras públicas | sim, segundo regras públicas e de acesso gratuito |
| Unidade de medida | hora | o ponto próprio da equipa | ponto de função IFPUG | CFP, 1 CFP = 1 movimento de dados |
| Para que serve melhor | planear tarefas curtas e bem conhecidas | o planeamento de sprints da própria equipa | medir o tamanho, comparar | medir o tamanho, comparar, servir de base a propostas e calendários |
A estimativa em horas não é uma má ferramenta; simplesmente mede outra coisa: o trabalho esperado, que, além do tamanho da tarefa, depende também dos conhecimentos, das ferramentas e da prudência da equipa. Os story points são úteis para o planeamento dentro da equipa, mas, segundo o guia publicado no site do COSMIC, são subjetivos e o seu significado varia de equipa para equipa. O IFPUG e o COSMIC são ambos medidas normalizadas do tamanho funcional, mas com regras diferentes, pelo que os números dos dois métodos não são intercambiáveis.
Porque é que o tamanho medido é uma base mais fiável?
Respondendo com precisão à pergunta do título: o COSMIC não estima as horas com mais precisão; mede a dimensão da tarefa, e é isso que torna mais fiável a estimativa do esforço. As razões:
- Mede o requisito, não a implementação. O tamanho funcional resulta apenas dos requisitos, pelo que é independente da tecnologia, do processo e de quem desenvolve o software.
- Pode ser medido de novo segundo regras públicas. As regras são públicas e o resultado da medição tem de ser documentado, pelo que outro medidor o pode verificar a partir da mesma especificação.
- O tamanho e a produtividade ficam separados. A estimativa do esforço resulta do tamanho e de uma produtividade empírica (esforço = tamanho / produtividade). Assim, vê-se que fator muda e porquê.
- A medição melhora os requisitos. Segundo o guia do COSMIC, a medição precoce ajuda a identificar requisitos ambíguos, contraditórios ou em falta.
- É comparável. Duas propostas para a mesma especificação obtêm o mesmo tamanho, pelo que os preços dizem respeito ao mesmo âmbito.
O guia do COSMIC remete para vários estudos em que o tamanho medido em CFP acompanhou mais de perto o esforço real do que a estimativa expressa em story points. O mesmo guia alerta também para o facto de o esforço estimado a partir do tamanho só ser fiável se o processo de desenvolvimento for suficientemente repetível e o esforço for determinado sobretudo pelo tamanho. O tamanho medido é, portanto, um melhor ponto de partida, mas, para uma boa estimativa, é preciso conhecer também a produtividade.
O que é que o COSMIC não mede?
O tamanho COSMIC mede as funções, e a descrição do método di-lo abertamente. O que não exprime:
- Algoritmos complexos. Segundo a norma, o método não foi concebido para medir software caracterizado por algoritmos matemáticos complexos ou por conjuntos de regras especiais (por exemplo, sistemas periciais, simulação, software que aprende por si próprio, previsão meteorológica).
- Processamento de sinais contínuos. O processamento de som e de imagem e, por exemplo, as partes deste tipo dos jogos de computador também ficam fora do âmbito da norma.
- Requisitos verdadeiramente não funcionais. Segundo o método, as restrições tecnológicas, de desempenho e do projeto devem ser registadas, mas não as medimos em CFP.
- Trabalho criativo. Segundo o guia do COSMIC, as tarefas puramente criativas, como a criação artística, não são objeto do método; por isso, o tamanho não exprime o trabalho de grafismo e de design visual personalizado.
- Implementação de um pacote pronto. Se os requisitos forem cobertos, em grande parte, pela configuração de um produto pronto, é preferível estimar o esforço da forma própria desse pacote.
Por isso, uma boa proposta indica à parte, ao lado do tamanho medido, aquilo que o tamanho não exprime: as integrações, os requisitos não funcionais, a interface e os gráficos personalizados, as várias plataformas, a migração de dados, os cálculos complexos e o funcionamento em tempo real. Nas nossas propostas, estes itens aparecem desta forma, como explicamos na página Preços.
Como o usamos no nosso próprio trabalho?
Medimos o tamanho funcional de um desenvolvimento em pontos de função COSMIC. Para a medição, construímos um fluxo de trabalho próprio, assistido por inteligência artificial, e o resultado é verificado por uma pessoa numa ronda de revisão. Os passos:
- Especificação item a item: dividimos o desenvolvimento em grupos de funções e descrevemos cada um com o mesmo modelo: objetivo, intervenientes, dados, funções, funções de IA e aquilo que não faz parte do trabalho (ver Como trabalhamos).
- Várias contagens independentes: vários modelos de linguagem contam cada grupo de funções, várias vezes; a dispersão das contagens mostra a incerteza.
- Ronda de conciliação: garante que cada processo funcional conta exatamente uma vez, mesmo que apareça em várias descrições.
- Revisão: revemos a medição, esclarecemos os pontos incertos e, se necessário, corrigimos manualmente as fusões automáticas.
- Fixação: a medição concluída pode ser fixada como uma versão inalterável, que passa a ser a base do contrato.
Na evolução de um sistema existente, descrevemos separadamente a parte que já existe, para que só a parte nova conte para o tamanho. A medição assinala também aquilo que o tamanho funcional não exprime.
Como é que o tamanho se torna uma proposta e um calendário?
O preço da proposta resulta do tamanho medido, complementado com os itens que o tamanho não exprime. Como vemos o tamanho também por grupo de funções, baseamos nele também o calendário: a ordem das etapas, o conteúdo das demonstrações e os prazos. Se surgir uma nova necessidade pelo caminho, medimo-la da mesma forma, e vê-se quanto muda o âmbito e o que isso significa para o preço e para o calendário. Por isso, só indicamos um preço e um prazo concretos depois da medição, e não com base numa primeira conversa.
Comparar duas propostas pelo tamanho
Se pedir propostas a várias empresas de desenvolvimento, o tamanho ajuda a decidir se dizem respeito à mesma tarefa. Vale a pena proceder assim:
- A mesma especificação: todos os proponentes recebem a mesma descrição item a item.
- O tamanho e a lista de processos: pergunte para que tamanho e para que processos funcionais foi apresentado o preço.
- As razões das diferenças: se duas propostas diferirem, verifique se diferem no tamanho, nos itens que o tamanho não exprime ou no preço por unidade de tamanho.
- Os itens à parte: pergunte o que aparece numa linha à parte (integração, migração de dados, operação) e o que não está incluído no preço.
- A gestão das alterações: pergunte como são medidas e orçamentadas as alterações feitas pelo caminho.
Se um proponente não medir o tamanho funcional, a sua proposta continua a ser comparável, desde que tenha orçamentado a mesma lista de processos item a item. Sobre os restantes critérios na escolha de um fornecedor, escrevemos no artigo Como escolher uma empresa de desenvolvimento de software?; e para decidir se é de todo necessário um desenvolvimento à medida, ajuda o artigo Software à medida ou solução pronta (SaaS)?.
Perguntas frequentes
O que é um ponto de função COSMIC?
O ponto de função COSMIC (CFP) é a unidade de medida do tamanho funcional do software segundo a norma ISO/IEC 19761. Um CFP é um movimento de dados: a entrada, a saída, a leitura ou a escrita de um grupo de dados num processo funcional. O tamanho do software é a soma dos movimentos de dados dos seus processos.
Em que difere da estimativa em horas?
A estimativa em horas indica o trabalho esperado e depende de quem estima e da equipa. O COSMIC mede o tamanho da tarefa a partir dos requisitos, com regras públicas, pelo que outra pessoa pode chegar ao mesmo resultado a partir da mesma especificação. As horas podem depois ser deduzidas a partir do tamanho e da produtividade empírica.
O que é que o COSMIC não mede?
Segundo a norma, não foi concebido para medir algoritmos matemáticos complexos nem o processamento de sinais contínuos (som, imagem), e também não exprime em CFP os requisitos verdadeiramente não funcionais, como as restrições de desempenho ou tecnológicas. Uma boa proposta apresenta-os como itens à parte.
Quem faz a medição, e é possível verificá-la?
A medição é feita por um medidor que conhece o método; no nosso caso, a contagem é feita por um fluxo de trabalho assistido por IA, e o resultado é revisto por uma pessoa. As regras são públicas e a medição é documentada processo a processo, pelo que outro especialista que conheça o método a pode verificar a partir da mesma especificação.
Como é que o tamanho se torna uma proposta?
O preço resulta do tamanho medido, complementado com aquilo que o tamanho não exprime: integrações, requisitos não funcionais, gráficos personalizados, várias plataformas, migração de dados. O calendário assenta no tamanho por grupo de funções, e as alterações são medidas da mesma forma. Os pormenores estão na página Preços.
Como podemos ajudar?
Se está a planear software à medida, escrevemos em conjunto a especificação item a item, medimos o seu tamanho em pontos de função COSMIC e, a partir dele, apresentamos a proposta e o calendário. A pedido, assinamos um acordo de confidencialidade (NDA) e, após a entrega, asseguramos também a operação e a manutenção. O código-fonte e os direitos de utilização regem-se pelo contrato. A primeira consulta é gratuita: escreva-nos através dos contactos indicados na página Contacto.
Fontes
- COSMIC Measurement Manual v5.0, Part 1: Principles, Definitions and Rules (PDF)
- COSMIC Measurement Manual v5.0, Part 2: Guidelines (PDF)
- COSMIC: A Guide to Software Size Measurement (PDF)
- COSMIC Measurement Manual: transferências
- ISO: ISO/IEC 19761:2011, COSMIC: a functional size measurement method
- ISO: ISO/IEC 14143-1:2007, Functional size measurement, Part 1: Definition of concepts
- ISO: ISO/IEC 20926:2009, IFPUG functional size measurement method