20/04/2004 08:46
O software livre é seguro?

Por Marco Bueno

"Há mais de cinqüenta anos, Grace Hoper usou de sua experiência em programar o Univac (Universal Automatic Computer) com a linguagem 'flowmatic' – aliás, um projeto de software livre – e escreveu o primeiro compilador. A era da computação moderna começou. O Univac foi o primeiro computador totalmente projetado para fins comerciais. A primeira versão foi usada em 1952 pela rede americana de TV CBS em pesquisas eleitorais. Alguém poderia dizer que as coisas não melhoraram muito desde aquele dia.

Os programadores e analistas de sistema foram os últimos a utilizar o computador para auxiliar em suas próprias tarefas profissionais. Programadores, lá no fundo, consideram-se artistas e são avessos a regras de quaisquer tipos, sejam de estilo, sejam de padrões de programação.

Mesmo com os progressos ocorridos – como as OOL (Object Oriented Languages), AI (Artificial Inteligence), UML (Unified Modeling Language), Workbenches de Programação, CMMI (Capability Maturity Model Integrated) etc. –, a arte de mapear os processos reais em sistemas computacionais continua extremamente personalista.

O Nist (National Institute of Standards and Technology) dos EUA estima que em 2001 cerca de US$ 59 bilhões, ou cerca de 0,6% do PIB americano, foi perdido por causa dos erros (bugs) de software. O SCC (Sustainable Computing Consortium), uma iniciativa de escolas, governo e empresas privadas para direcionar aperfeiçoamentos da TI, estima que este valor é apenas a parte 'de baixo' do gráfico. O custo real dos defeitos em sistemas nas companhias americanas deve somar pelo menos US$ 200 bilhões, de acordo com o SCC.

Dificilmente passa uma semana sem que um importante bug de software ou um buraco na segurança de algum sistema seja reportado na imprensa. Como diz George Tassey, o economista-sênior responsável pelo relatório do Nist, 'o software está muito acima dos outros produtos industriais, em termos de erros e bugs, quando é comercializado'.

Jin Laruf, pesquisador sênior da Microsoft Research, concorda: 'Nós estamos escrevendo software há cerca de 50 anos e ainda produzimos um produto com grande número de erros e bugs. As ferramentas de trabalho tornaram-se muito melhores, mas a qualidade do código gerado não reflete isso necessariamente.'

Uma regra de polegar geralmente aceita diz que são necessários US$ 10 para corrigir um bug durante o desenvolvimento do projeto; US$ 100 para corrigi-lo durante o processo de Controle de Qualidade (QA, ou quality assurance); US$ 1.000 para a correção durante o beta teste; e US$ 10.000 ou mais para corrigir um bug num sistema em produção.

Por que se desperdiçam tanto tempo e dinheiro? Jim Johnson, diretor do Standish Group, empresa especializada em planejar e avaliar investimentos em TI, diz que isto se deve ao fato de que 'a Microsoft nos ensinou que não tínhamos como escapar dos erros de código, éramos obrigados a conviver com eles. Da metade dos anos 90 até 2000, a programação foi geralmente muito descuidada. Agora há uma pressão maior por qualidade vinda dos usuários que sentiram o real custo dos bugs para suas empresas.'

Com freqüência, sistemas são desenvolvidos precipitadamente, somente para atender a cronogramas apertados e irreais, e a correção dos bugs é normalmente aceita como parte do processo de suporte técnico. Talvez não seja um ensinamento da Microsoft, mas com certeza é uma combinação dos fatores mencionados por Johnson e a característica proprietária do software.

Avaliação constante

Acredita-se que a principal razão pela qual o software livre é melhor e mais seguro é justamente o fato de haver mais olhos treinados avaliando o código. Há muito mais chances de alguém encontrar um problema.

Não necessariamente alguém será remunerado por fazer isso ou terá a sua avaliação de performance afetada. Como apontou Eric Raymond em seu clássico 'The Cathedral and the Bazaar', não é nenhum desses fatores que normalmente motivam os programadores de sistemas com o código aberto. Ao invés disso, eles são motivados pela busca da excelência e pelo reconhecimento de seus pares (a comunidade). O estilo de trabalho do software aberto acelera a avaliação do código e a descoberta de erros. Além disso, embora pouco divulgado, os programadores aceitos para contribuir com os sistemas de código aberto seguem normas e padrões rígidos de estilo e programação, exercendo uma grande disciplina. Caso contrário, seu código não será aceito pela comunidade para ser incorporado ao sistema.

Para entender o porquê da maior eficácia na criação e correção do código livre, vale recorrer à explanação de Eric Raymond: 'No informe de erros, os usuários de código fechado normalmente reportam apenas sintomas superficiais. Assim, são omitidos dados de background e raramente é incluída uma receita para replicar o problema apontado. O problema não aparente é a diferença entre os modelos mentais de quem testa e de quem programa. Este, de dentro, olha para fora, e o outro, de fora, olha para dentro, tentando compreender o incompreensível. Isso pode causar muita frustração a ambos os lados.'

O modelo de desenvolvimento com fontes abertas quebra este ciclo fechado, pois ambos os parceiros compactuam a mesma visão dos fatos e podem comunicar-se efetivamente sobre deles. Não existe programa de beta teste para sistemas de código fechado que possa duplicar esse modelo. Por isso, devido à rapidez na correção de bugs e no atendimento a padrões, inclusive de segurança, o programa de código aberto é inerentemente mais seguro que o de código fechado.

Para uma empresa, representa um valor inestimável possuir um sistema que ela pode alterar, modificar ou ainda corrigir, sem depender da boa vontade ou capacidade de outros. Tudo isso sem gastar nada, ou quase nada.

Fonte:
AOL Notícias


enviada por Projeto Monera






Feed: Seja avisado quando este blog for atualizado :: (O que é isso?)