A qualidade de software como base competitiva

  Em postagens anteriores, tivemos muitas discussões sobre como a qualidade do desenvolvimento de software influencia na segurança da informação. Pensando nisso, estou postando um resumo da tese de especialização que o colega Lucas Pereira elaborou e publicou no site http://testelabs.blogspot.com.
Boa leitura.

Nos dias atuais, com um mercado altamente competitivo, que reúne vários fabricantes e fornecedores de diversos tipos de produtos e serviços, a qualidade deixa de ser um diferencial competitivo e passa a ser um item básico de sobrevivência das organizações, uma necessidade permanente. Desta forma, uma empresa que forneça bens e/ou serviços com baixa qualidade corre um sério risco de ser descartada pelo mercado consumidor.

Devido a esse mercado altamente competitivo, as empresas passaram a se preocupar em adotar as técnicas mais modernas de qualidade e produtividade para combinar os recursos disponíveis de maneira a aumentar o seu volume de negócios, garantindo a satisfação dos seus clientes e suas margens de lucro.

Em contrapartida, se as empresas não entregam novos produtos ou funcionalidades aos clientes, rapidamente se tornam obsoletas. Assim, o grande desafio é equilibrar as ações para entregar constantemente novos produtos com qualidade e custos adequados. 

Esta teoria é facilmente compreendida através da triângulo da qualidade (TRIPLE CONSTRAINT). Uma estrutura para a avaliação de demandas conflitantes, um triângulo em que um dos lados ou um dos cantos representa um dos parâmetros que está sendo gerenciado pela equipe do projeto. (PMI, 2004:375) 

O triângulo trata do gerenciamento de necessidades conflitantes do projeto, como o escopo, o tempo e o custo. No que tange a qualidade do projeto é necessário encontrar o balanceamento desses três fatores.

Para encontrar esse equilíbrio existem diversas ferramentas como, por exemplo, o PDCA (Plan, Do, Check, Action), o KAMBAN e o 05 Porquês, que têm a função de ajudar as empresas a atingir a excelência nos seus projetos, melhorando continuamente e aplicando valor ao seu produto.

Existem inúmeras vantagens para se efetuar testes de qualidade nos softwares desenvolvidos. A principal delas é a satisfação dos clientes, pois reduzindo o número de reclamações deles, o produto passa a ser indicado e a imagem da empresa melhora a cada dia. Com isso, surge a fidelização em relação aos produtos, a maturidade e estabilidade dos softwares passam a ser atingidas rapidamente e os custos com desenvolvimento e manutenção são reduzidos, gerando maior receita à empresa.

Com base na pesquisa e na observação das empresas estudadas, seguem as recomendações sobre a estrutura organizacional que melhor se adéquam ao departamento de testes de software:

- Não é recomendado que o Departamento de Qualidade e Testes de Software seja coordenado pela mesma gerência da Equipe de Desenvolvimento, pois pode haver conflitos de interesse;

- O departamento de Testes de Software deve estar preferencialmente abaixo de uma diretoria específica de qualidade da empresa;

- A estrutura interna do Departamento de Teste de Software deve seguir os padrões de certificações existentes, citadas anteriormente, que são:

• Líder do Projeto de Testes: responsável pela liderança de um projeto de teste específico, normalmente relacionado a um sistema de desenvolvimento, seja um projeto novo ou em manutenção (RIOS e MOREIRA, 2006);

• Engenheiro/Arquiteto de Teste: responsável pela montagem da infraestrutura de teste, montando o ambiente de teste, escolhendo as ferramentas de teste e preparando a equipe para executar o seu trabalho neste ambiente de teste;

• Analista de Teste: responsável por modelar, especificar e documentar os casos de testes que devem ser realizados, em resumo esta função cria os Planos de Testes que o testador irá executar;

• Testador: responsável por executar os testes e analisar os resultados obtidos, seguindo parâmetros previamente definidos no Plano de Testes.

Para o profissional, temos algumas certificações no mercado. São elas:

Para as empresas desenvolvedoras temos:

Bullying, mais uma ameaça à segurança das corporações.

A palavra bullying apareceu em nosso país há pouco tempo. Em épocas passadas – as quais remontam à minha infância – ser chamado de gordinho, narigudo, magrelo ou baixinho causava no máximo uma chateação temporária e em poucos casos levava a traumas incuráveis. Então, o que exatamente fez uma brincadeira sem graça transformar-se em bullying?

Imagem: meioambientetecnico.blogspot.com.br

Note, vez ou outra, todos nós corremos o risco de fazer uma brincadeira infeliz e acabar desagradando alguém, seja propositalmente ou não. Quando percebemos o incômodo do outro, a maioria de nós pede desculpas. Entretanto, há pessoas que continuam insistindo na mesma brincadeira de forma agressiva e sistêmica, isso é bullying. 

Essa insistência caracteriza uma intenção de humilhar e prejudicar o outro em situações que vão além do contexto da brincadeira. Foi o que aconteceu com a inspetora escolar Karen Klein. Vítima de insultos por parte dos alunos, sua história repercutiu na Internet e causou grande comoção.  

O aumento progressivo dessas situações de violência levou as autoridades, inclusive, a tomar algumas atitudes mais severas. No Distrito Federal, por exemplo, já existe uma iniciativa legal para combater esse tipo de comportamento dentro das escolas. 

No ambiente corporativo, episódios de desrespeito também tendem a ocorrer cada vez mais, afinal o estudante de hoje é o profissional de amanhã. Muitos casos têm chegado à Justiça e denunciam profissionais que ameaçam divulgar informações da empresa, como áudios de reunião ou fotos/vídeos de chefia em situações comprometedores, caso sejam demitidos. Essas situações podem ser flagradas entre colaboradores ou entre chefes e subordinados.

A atual facilidade de se disponibilizar um dado (áudio ou vídeo) pela Internet passou a trazer prejuízos maiores às empresas.  Isso porque o conteúdo do material divulgado nem precisa ser altamente relevante à corporação para causar problemas, basta que a informação esteja contextualizada de modo a prejudicar a empresa ou a pessoa.   

Por exemplo, se o presidente de uma determinada marca de bebida for fotografado tomando uma bebida do concorrente, esta foto pode ser facilmente utilizada como mecanismo de pressão. Caso vá para a Internet, o dano será do ocupante do cargo, mas atingirá também a empresa, em consequência da exibição pública de seu principal diretor consumindo o produto do concorrente.

Do ponto de vista da segurança da informação, essa mudança no comportamento social obriga as empresas a adotar medidas preventivas em relação a determinadas atitudes. Já que, agora, a exposição do indivíduo pode afetar diretamente o negócio, comprometendo tanto a imagem da corporação quanto as relações internas. 

Então, o que as empresas podem fazer para evitar certos transtornos? Trabalhos realizados com o intuito de minimizar a fofoca ou estabelecer comportamentos adequados dentro das instituições devem ser ampliados pela equipe de RH, principalmente no que diz respeito às mídias sociais e o impacto direto delas no trabalho de cada um. Campanhas de conscientização e normatização sobre o assunto precisam ser inseridas nas cartilhas. É necessário que o problema seja tratado corporativamente, de forma que, caso algo aconteça, as vítimas possam sentir-se seguras e informar suas chefias. 

Se a empresa ficar ciente de algum episódio interno que possa ser considerado bullying, ela deve tomar ações imediatas para conter o problema, levando-o às autoridades competentes. É preciso ter em mente que mesmo que o caso tenha apenas repercussão interna, as vítimas podem processar a empresa por conivência, assim a normatização e o registro documental imediato do ocorrido devem ser providenciados.  

Desenvolvimento aberto e backdoors

Recentemente, tive uma dessas discussões apaixonadas sobre desenvolvimento aberto – das quais já não costumo mais ter paciência para participar.  Aprendi com o tempo que a área de tecnologia não deve ser movida por paixões, mas por decisões práticas e objetivas, que levem em consideração o ambiente ao redor. E partindo desse princípio, pode-se dizer que a grande maioria das técnicas e tecnologias é aplicável. 

Imagem: slashgear.com

Desenvolvimento aberto (código aberto e software livre são utilizados popularmente como sinônimos, o que não exatamente apropriado) é uma forma de desenvolvimento de software, nada mais. Nem é preciso entrar nos meandros da discussão, porque ela agrega muito pouco no quesito segurança e nada, nos paradigmas fundamentais da programação. 

O desafio atual da segurança no desenvolvimento reside naquela clássica questão de se saber o que realmente um código está fazendo (por exemplo, se ele está ou não em looping), um problema sem solução.

Hoje, temos ferramentas que “fiscalizam” as melhores práticas de programação, capazes de detectar, em tempo real, um bom nível de erros de codificação. Mas no que diz respeito ao problema apresentado, são incompletas em sua funcionalidade. No final das contas, pressupõe-se que a intervenção humana ainda é necessária. 

O principal argumento da suposta segurança dos sistemas abertos baseia-se na abertura e na visualização do código por milhões de pessoas. A alegação apresenta um componente de obviedade tentador. Afinal, algo visto e validado por milhões de pessoas deve ser mais seguro do que aquilo que ficou restrito a duas ou três. Mas a realidade é outra. 

O código aberto não é nenhuma novidade, existe há muito tempo. Um exemplo clássico foi o bug da pilha TCP/IP que atingiu 100% dos Sistemas Operacionais, há mais de 10 anos.  Ou seja, todos os fornecedores tinham o mesmo bug. Isso significa que utilizaram o mesmo código, fatalmente derivado de um BSD, que era aberto, livre para uso. 

Ainda que o código tenha sido visto por milhões de pessoas de diferentes corporações, o bug existiu por muito tempo. Então, por que, ao olharem para o código, não viram o bug?

Muitas pessoas confundem a velocidade na correção de um problema de segurança com a inexistência dele.  Um grande equívoco! Já que a agilidade em corrigi-lo está vinculada diretamente ao compromisso do fornecedor em fazê-lo, seja ele aberto ou fechado. 

Assim, conclui-se que o sistema não está livre de problemas de segurança, já que os fornecedores, abertos ou fechados, têm esses mecanismos de fornecimento.

Então, onde estão os analistas de código? Por que o código aberto não é mais seguro?

Se oferecesse maior segurança, o software livre (baseado em desenvolvimento aberto) não teria bugs. Todos podem visualizar o código, entretanto 99,9999% dos bugs são descobertos em tempo de execução na maioria dos sistemas, e não com análise de código.  

Analisar o código, aliás, é algo mais complexo do que desenvolver o próprio código. Não existe um processo de automação que diga o que um código está fazendo. Além disso, já se tem poucas pessoas desenvolvendo código em comparação às pessoas que usam os produtos e, talvez, praticamente ninguém verificando.

Podemos até fazer uma analogia com os processos de compra do Governo. Todos eles são públicos e estão disponíveis para a população verificar. Nem por isso o número de problemas apresentados na televisão em relação a esses procedimentos diminui. A população em geral que tem acesso a tais processos não tem capacidade de avaliá-los, apesar de pagar por eles e usufruir de seu resultado.

Para piorar (no que diz respeito à segurança), temos as bibliotecas de terceiros, amplamente usadas, as BIOS de computador e os sistemas de apoio embarcados para processamentos especializados (FPGA, por exemplo). Todos, livres ou não, com possibilidades de backdoors. O mercado sempre foi colaborativo, não se esqueçam desse ponto. Bibliotecas, integrações e compartilhamento de código entre sistemas sempre existiram. Todas essas camadas de apoio, que são ligadas à execução de um sistema, podem esconder brechas de segurança.

Quantas vezes você, leitor, verificou o código aberto de alguma aplicação para ver se existe algo suspeito nele? Será que este “IF” esconde um backdoor? Quantas pessoas você conhece que já fizeram isso? Eu não me lembro de nenhuma nos últimos 15 anos – pelo menos que tenha descoberto algo  relevante. Conheci muita gente que o fez para corrigir um problema ou aprender como se faz algo, mas nunca para tirar conclusões sobre aspectos de segurança ou corretude do sistema.

Como se já não bastasse a dificuldade técnica na avaliação de um código feito por outra pessoa (em ambientes de desenvolvimento essa é uma reclamação constante de novos programadores que entram na equipe), ainda existe a possibilidade de estarem escondidas entre os códigos, ações não tão óbvias.

Lembro de um campeonato que existia na época de faculdade, cujo objetivo era desenvolver um programa em C que parecia fazer algo específico, mas, na verdade, escondia outras operações. Havia também uma competição que premiava o programa em C mais “confuso”, de modo que, ao ser lido, o leitor não pudesse saber o que ele fazia. Um dos requisitos desses campeonatos era que o programa fosse pequeno, capaz de ser analisado por uma pessoa. 

Se é possível esconder códigos em programas pequenos, pense agora no volume de códigos existentes atualmente! 

Um backdoor pode ser apenas uma atribuição errônea de uma variável ou um conjunto de 03 linhas de código, bem diferente de milhares de linhas de código, como ocorreu no FLAME. 

Resiliência: Os backdoors vieram para ficar, sejam por erros de programação ou inserção proposital.