Medir tamanho de um software ?

Olá,

muitas pessoas hoje em dia falam que tal sistema é 'grande', ou que é 'pequeno' ou pior ainda, que o tamanho é 'razoável', sei que existe uma certa dificuldade em medir um sistema simplesmente colocando uma unidade de medida no final, hoje o que vocês consideram de maneira formal medir o tamanho? O ponto de função é ainda a melhor opção ? Eu sinceramente só tenho noção de tamanho quando alguém compara com outros projetos de uma mesma organização, por exemplo o projeto xxxx teve 40mil PF, o yyy teve 10mil PF, como vocês consideram o ponto de função pra estimar tamanho de software ?

Eu costumo pegar uma régua e...

Não, não. Existem diversas maneiras de se medir o tamanho de um software e nenhuma delas estima direito o tamanho do seu sistema. Um método que eu achei bem interessante (mas não menos esotérico do que PF) é o Use Case Points (google it). Basicamente, você pega os Use Cases do seu sistema (ou as user stories, caso você esteja usando algo melhor) e atribui pontos a eles, como se fossem níveis de dificuldade.

Daniel Quirino Oliveira wrote:Eu costumo pegar uma régua e...

Não, não. Existem diversas maneiras de se medir o tamanho de um software e nenhuma delas estima direito o tamanho do seu sistema. Um método que eu achei bem interessante (mas não menos esotérico do que PF) é o Use Case Points (google it). Basicamente, você pega os Use Cases do seu sistema (ou as user stories, caso você esteja usando algo melhor) e atribui pontos a eles, como se fossem níveis de dificuldade.

Ainda se bem feito, por um profissional que conheça a plaforma, sua velocidade e dimensão (itens de influência), o FPA dentre todas é a que se aproxima mais do real.

Já tive algumas experiências, e estou falando como usuário de tal métrica.

Seja lá qual for a métrica que vc for usar, vc só vai afinar a sua medição com o tempo. Por isso é bom ter uma ferramenta, nem que seja uma planilha de excel, pra vc ter um histórico das suas medições pra comparar e errar menos nas próximas.

[]'s

Rodrigo C. A.

Kenobi wrote:

Daniel Quirino Oliveira wrote:Eu costumo pegar uma régua e...

Não, não. Existem diversas maneiras de se medir o tamanho de um software e nenhuma delas estima direito o tamanho do seu sistema. Um método que eu achei bem interessante (mas não menos esotérico do que PF) é o Use Case Points (google it). Basicamente, você pega os Use Cases do seu sistema (ou as user stories, caso você esteja usando algo melhor) e atribui pontos a eles, como se fossem níveis de dificuldade.

Ainda se bem feito, por um profissional que conheça a plaforma, sua velocidade e dimensão (itens de influência), o FPA dentre todas é a que se aproxima mais do real.

Já tive algumas experiências, e estou falando como usuário de tal métrica.

FPA é bom para medir sistemas que a complexidade predominante é na parte GUI. Para sistemas de back-office ou que não envolvem qualquer interação com o usuário use case points é bem mais factivel.

Eu não sei dizer se o UCP tem alguma organização que apoie essa métrica, até porque ela é mais recente, mas FPA tem o IFPUG (International Functions Point Users Group) e também foi considerada uma medida padrão pela ISO.

A UCP fica muito atrelada ao caso de uso descrito, certo? E por mais que você consiga atingir um nível igualitário entre as descrições do caso de uso, ainda existem uma certa variação neles entre diversas pessoas, e isso é fato, pois as pessoas não são robôs. E até que você consiga dentro de uma organização, tudo bem, mas a nível internacional isso fica complicado, quantos autores de livros divergem em relação a descrição de casos de uso por aí ?

E em nível de licitação por exemplo ? Quem é adotado como padrão ? FPA ? ou UCP ?

louds, na tabela pra calcular o FPA, se não me engano, vc tem opções pra colocar um parâmetro e definir sua complexidade, isso não seria aplicável para sistemas de back-office ?

louds wrote:FPA é bom para medir sistemas que a complexidade predominante é na parte GUI. Para sistemas de back-office ou que não envolvem qualquer interação com o usuário use case points é bem mais factivel.

Louds, dei uma fuçada aqui e encontrei uma extensão ao ponto de função, seriam os 'pontos de particularidades', que se enquadra para medir aplicações com um grau de complexidade algorítmica elevada.
A idéia pra medir foi quase como eu mencionei antes, você tem que criar um novo parâmetro de medição e além disso acrescentar um valor, chamado de peso para cada parâmetro.

Fabrício Cozer Martins wrote:Eu não sei dizer se o UCP tem alguma organização que apoie essa métrica, até porque ela é mais recente, mas FPA tem o IFPUG (International Functions Point Users Group) e também foi considerada uma medida padrão pela ISO.

A UCP fica muito atrelada ao caso de uso descrito, certo? E por mais que você consiga atingir um nível igualitário entre as descrições do caso de uso, ainda existem uma certa variação neles entre diversas pessoas, e isso é fato, pois as pessoas não são robôs. E até que você consiga dentro de uma organização, tudo bem, mas a nível internacional isso fica complicado, quantos autores de livros divergem em relação a descrição de casos de uso por aí ?

E em nível de licitação por exemplo ? Quem é adotado como padrão ? FPA ? ou UCP ?

louds, na tabela pra calcular o FPA, se não me engano, vc tem opções pra colocar um parâmetro e definir sua complexidade, isso não seria aplicável para sistemas de back-office ?

Esses ajustes de complexidade ajudam a ajustar e calibrar os pontos, mas não em casos comuns de back-office. Não adianta você colocar todos ajustes lá em cima se no final das contas o sistema vai continuar com 1 duzia de pontos não ajustados.

Não conheço como funciona essa extensão, "pontos de particulariedades", então não tenho como falar a respeito.

Enfim, acho que FPA é muito bom para softwares centrados na UI, para o resto acaba criando muitos artefatos.

e a documentação? não vejo como falar do "tamanho" de um sistema sem levar em consideração sua documentação - o que pra sistemas grandes já seria uma pusta dor de cabeça pois vc teria de questionar, dentre todos os artefatos do sistema, quais são relevantes.

ai vc escolhe uma penca de artefatos, doc, pdf, xls, ppt sei lá. vai calcular o tamanha desses caras como?

agodinhost wrote:e a documentação? não vejo como falar do "tamanho" de um sistema sem levar em consideração sua documentação - o que pra sistemas grandes já seria uma pusta dor de cabeça pois vc teria de questionar, dentre todos os artefatos do sistema, quais são relevantes.

ai vc escolhe uma penca de artefatos, doc, pdf, xls, ppt sei lá. vai calcular o tamanha desses caras como?

Documentação é um artefato ortogonal a complexidade e tamanho do software.

louds wrote:Documentação é um artefato ortogonal a complexidade e tamanho do software.

perdão por minha ignorância mas o quê exatamente vc quer dizer com isso? procurei no aurélio e só achei isso:
Adjetivo de dois gêneros
1.Geom. Que forma ângulos retos. ~ V. base ?, coordenadas ortogonais, coordenadas cartesianas ortogonais, polinômios ortogonais e vetores ortogonais.

se vc quer dizer com isso que não conta eu discordo. Tem horas que só linha de código e javadoc não são suficientes pra avaliar a extensão de um sistema.

agodinhost wrote:

louds wrote:Documentação é um artefato ortogonal a complexidade e tamanho do software.

perdão por minha ignorância mas o quê exatamente vc quer dizer com isso? procurei no aurélio e só achei isso:
Adjetivo de dois gêneros
1.Geom. Que forma ângulos retos. ~ V. base ?, coordenadas ortogonais, coordenadas cartesianas ortogonais, polinômios ortogonais e vetores ortogonais.

se vc quer dizer com isso que não conta eu discordo. Tem horas que só linha de código e javadoc não são suficientes pra avaliar a extensão de um sistema.

Por ortogonal quis dizer que o tamanho da documentação não está diretamente associada ao tamanho do software. Medir o tamanho da documentação só tem importância para calcular o custo de produção e manutenção de um software, para demais fins é apenas um artefato que não possui relevância.

Além disso, ninguém aqui propôs usar linhas de código como medida de tamanho e sim métricas mais realistas como FPA e UCP.

louds wrote:Medir o tamanho da documentação só tem importância para calcular o custo de produção e manutenção de um software, para demais fins é apenas um artefato que não possui relevância.

é, faz sentido.
um carro tem x metros independentemente dos manuais.
o preço pode variar, mas continua tendo x metros.
é isso?

louds wrote:Por ortogonal quis dizer que o tamanho da documentação não está diretamente associada ao tamanho do software. Medir o tamanho da documentação só tem importância para calcular o custo de produção e manutenção de um software, para demais fins é apenas um artefato que não possui relevância.

Além disso, ninguém aqui propôs usar linhas de código como medida de tamanho e sim métricas mais realistas como FPA e UCP.

Sim, medir o tamanho pelo número de linhas de código é maluquice a certo ponto, mas a partir do momento que você tem um PMD da vida que tenta padronizar o código fonte, pode até ser que diminua a margem de erro de medida, mas mesmo assim essa medida pelo que li, é pouco realista, e utilizada.

Uma pergunta ... quais artefatos iniciais são utilizados pra estimar a medida de um software ? Seria um DER ? Um protótipo ? Casos de Uso ?
Pela lógica deveria ser um que não fosse tão demorado pra se produzir e que conseguisse abranger o maior número de detalhes possíveis...

agodinhost, esse era meu ponto. Que tamanho não se traduz diretamente para custo.

Fabrício, como medir o custo de um software depende de uma série de fatores. O principal, na minha opinião, é a relação entre cliente e fornecedor.

No caso de ser uma empresa contratando outra, tem de ser o mínimo possivel que permita estimar quanto cobrar.

Mas se for um cliente interno é bem diferente, não existe o problema de perder para a concorrência o contrato. Neste caso o melhor é gerar os artefatos iniciais da metodologia e levantar o custo preliminar para ver se o projeto vai ser executado ou não.

Notícias, artigos e o maior fórum brasileiro sobre Java