Curso de Patentes...

Acabei de fazer semana passada um curso sobre patentes que levantou muitas questões interessantes. Assim como a vontade de conseguir registrar ou patentear algo novo.

Também descobri que é muito fácil se perder uma boa idéia fazendo um cadastro equivocado da mesma no instituto nacional de propriedade insdustrial (http://www.inpi.gov.br). Ali existem inúmeras tentativas de patente que não deram certo... E que por não darem certo, entram no estado da arte (são publicadas) e por isso, impedem uma nova tentativa de pedido de patente de algo semelhante, mesmo que a tentativa anterior tenha sido sua mesmo!

Mas acho que o mais interessante foi entender que software pode, sim, conseguir uma patente (mesmo que em geral as regras digam que não deve, atualmente os países todos tem autorizado patentes de software). O registro de autor até serve para você ter em mãos uma forma de punir aqueles que pirateiam o seu software, mas não serve para muito mais do que isso. A patente, porém, pode proteger a sua idéia, dependendo de como escrever isso (tem que ser criativo, porque dependendo de como escrever, pode simplesmente perder a idéia, como disse acima).

Por exemplo, o famoso duplo clique que a Microsoft patenteou e agora processa o linux por fazer uso. Quando tiveram a idéia de usar o duplo clique para acessar uma funcionalidade na Microsoft, alguém muito esperto patenteou a idéia e disse como que implementou a idéia (como que se faz o duplo clique). Agora, independetemente de o Linux ter feito a funcionalidade de duplo clique com um código diferente, eles "roubaram" a idéia da Microsoft e por isso devem pagar... Enfim, apesar de você ter que dizer um meio para conseguir uma patente, os fins são protegidos também, o que torna a patente bastante valiosa, mesmo para software.

O curso também valeu para ouvir falar de algumas patentes brasileiras que fizeram sucesso, como o escorredor de arroz ou o mecanismo que deixa o guarda-chuvas automaticamente aberto - antes você tinha que rosquear o guarda-chuvas para ele se manter aberto. Mas a dica principal mesmo, é para prestar atenção nestas pequenas melhorias que podem ser feitas, mesmo que não esteja inventando o próprio guarda-chuvas... Isto é especialmente verdade em software. Abra os olhos!

Medindo o desempenho do seu teste...

Os testes possuem uma medida de qualidade e estimativa de tempo dos testes (APT) baseada em Pontos por Função que erra por volta de 10%, pelo menos segundo o professor e estatísticas levantadas em uma empresa grande que ele tentou implantar a medida.

Mas como não pretendemos calcular PF na empresa que trabalho, isso já ficou de lado, nem vou comentar muito. Mas ele deu outra estatística (chamada de Defect Removal Efficiency ou DRE), dizendo que o resultado médio das empresas é de 0,3 (sem equipes de testes ou pelo menos um processo de testes bem feito, o que atualmente é raro) e o ideal seria acima de 0,75 (ou ainda chegar acima de 0,9 que é considerado high level). Essa estatística já achei bem mais interessante por ser muito mais fácil de medir e mesmo que não seja 100%, é algum guia.

Esse número é calculado com a fórmula:

NBE = Número de Bugs Encontrados
NBN = Bugs Não Encontrados (achados em produção)

DRE = NBE/(NBE+NBN)

Em média as empresas encontram apenas 1/3 dos defeitos no seu processo de validação. Dito isso eu fiz o cálculo para algumas versões mais simples de calcular, no meu trabalho, o que certamente não é o valor real de verdade, mas deve ser bem razoável (em produção só tenho uma estatística de problemas mais graves, já que detalhes não são pegos lá e são pegos aqui dentro o que distorce um pouco o número).

Por isso acabei descartando os problemas mais simples que encontramos em validação. Ainda assim chegamos em um resultado bem animador de 0,88. Nem perto de estar ruim para uma equipe com um software grande para dar manutenção e sem equipe terceirizada de testes =)