Qualidade de Software: Uma questão de eficiência

É um trabalho reescrever códigos ao invés de criar novos códigos, inovar, criar novas soluções. Existem empresas que já estão na versão 5 de seu software, mas tem clientes que ainda usam a versão 3, porque os clientes morrem de medo de atualizar, por causa dos históricos de erros em novas versões – eles preferem os problemas já conhecidos. Empresas que levam o software ao cliente e uma tela não funciona, ou uma correção de um problema que afetou outro lugar no sistema e uma infinidade de questões, aqui vamos ilustrar apenas algumas:

Não existem requisitos ou documentação

Geralmente desenvolvedores não fazem a tarefa de casa levantando os requisitos de software, já começam a escrever o código conforme é pedido. Ou, pior, não fazem as documentações necessárias de análise antes do desenvolvimento de um software. Isso causa diversos problemas:

• Quando o desenvolvedor desconhece os requisitos, ele provavelmente voltará a reescrever um código que já foi escrito, pela falta de análise, desordem, descaso por não levantar os requisitos;
• Às vezes pode até haver requisitos, mas numa equipe cada desenvolvedor pode interpretar os requisitos de uma forma diferente;
• Requisitos mal levantados ou mal escritos por falta de conhecimento ou experiência;
• Falta de uma documentação do software;
• Documentação mal elaborada.

Quando há a falta de documentação o serviço de software fica complicado em diversos sentidos: há uma grande dificuldade de encontrar mão de obra especializada, e quando encontram, devido à falta de documentação, os contratados levam meses para conhecer o software da empresa, afinal, o conhecimento está na cabeça de alguns; é difícil fazer teste de software para garantir um menor risco de erros; o desenvolvimento de software é comprometido aumentando as chances de erros do software. Estes são apenas alguns exemplos.

Não existe a fase de projeto de software

Simplesmente levantam-se rapidamente os requisitos e inicia o desenvolvimento, sem uma análise e projeto. Isso leva a falta de documentação e início de vários problemas de, no futuro, ter que reescrever códigos com erro, além de dificultar para a equipe de testes a análise do software.

Controle de mudanças e de versões inadequadas ou inexistentes

Não há um controle do que foi mudado, um muda o banco de dados sem comunicar e interferem outros módulos do software. Não há uso de controle de versões. O que é um erro. Há diversas ferramentas que fazem este controle, como o CVS.

Foco na entrega

Muitos pensam em entregar o mais rápido o software, sem se preocupar com a qualidade. Isso faz o software voltar com diversos erros encontrados, muitas vezes pelos clientes, o que é péssimo. É melhor colocar um prazo real e entregar com qualidade, que correr para entregar rápido. Há empresas que eliminam a análise de documentação do projeto em nome de "produtividade", mas está suposta "produtividade" é apenas ilusória.

Inexistência de um time de testes

Geralmente quem faz os testes são os desenvolvedores. Isso é um erro. Eles seguem uma lógica que é diferente da lógica de usuários finais. Ou quando tem uma equipe de testes, é a secretária, o office-boy, ou outros funcionários da empresa que não fazem um teste correto. Ou a falta de ferramentas de automação de testes. Ou o teste é realizado pelos próprios clientes, o que é pior.

Time de testes focado em testes superficiais

Quando há, como foi citado no item anterior, não utilizam ferramentas de automação de testes, de ferramentas de gestão de testes, de gestão de defeitos, etc. Fazem aquele teste de usuário, mesmo assim superficial, não fazem teste do banco de dados, do desempenho do sistema, de análise do código, não catalogam os defeitos em níveis de defeitos, não criam regras de mensagens de erros para ajudar ao usuário a contornar os possíveis erros, etc. Hoje montar uma equipe de testes é importante, se estuda muito teste de software, são raros os profissionais especializados e são muito bem remunerados.

Desenvolvimento reativo

O desenvolvimento é focado na correção de erros, ao invés da evolução do software ou novas soluções. Isso devido aos fatores já mencionados.

O teste e a qualidade de software hoje em dia são tão importantes e é um assunto muito discutido no mundo todo e já há alguns anos no Brasil, porque hoje tudo depende de software: o piloto de avião para navegar, sistemas de pagamentos de contas, sistemas bancários, enfim, uma afinidade de softwares que todos nós dependemos. Um erro pode colocar a vida de pessoas em risco, perdas de negócio e produtividade, prejuízos financeiros, comprometimento da reputação da empresa, etc. Vemos quase que diariamente notícias de empresas prejudicadas devido a erros em softwares.

Hoje softwares se comunicam com tudo: WebService de nota fiscal eletrônica, PAD, celulares, internet, rede, etc. Devem se portar para os mais diversos sistemas operacionais, os mais diversos browsers, e tudo isso leva a uma maior complexidade, não apenas de código mas de análise, e uma boa documentação para manutenção e continuidade dos softwares.

Sem um bom levantamento de requisitos, análise, documentação e projeto a chance de erros é enorme e pior: sem todos estes passos antes do desenvolvimento será um grande pesadelo difícil de sair.

Se a engenharia em geral gasta seu tempo em análise, documentação, projeto e uma série de bateria de testes, porque a engenharia de software deve ser diferente? É preciso mudar a mentalidade e cultura dos desenvolvedores e empresas de software a investirem mais nestes itens, não apenas para a melhora na qualidade do software, mas para melhorar o rendimento da equipe interna, de novos contratados, criação de novos produtos ao invés do foco reativo, diminuição da equipe de suporte técnico, consecutivamente dos custos da empresa, maior competitividade no mercado, consecutivamente um lucro maior.

Trocam tudo isso em nome de “maior produtividade”, o que é um erro, não aumenta a produtividade coisa nenhuma, só piora, é comprovado através de pesquisas que a grande maioria das empresas brasileiras gastam 70% do tempo de desenvolvimento corrigindo erros, por falta dos itens já mencionados. Onde está a produtividade? É uma ilusão pensar que economizando nestes itens haverá maior produtividade. Além do mais, basta utilizar ferramentas CASE que geram o código a partir da documentação. E vamos falar um pouco de ferramentas CASE.

Sobre ferramentas CASE

Ferramentas CASE (do inglês Computer-Aided Software Engineering) é uma classificação que abrange todas as ferramentas baseada em computadores que auxiliam atividades de engenharia de software, desde análise de requisitos e modelagem até programação e testes. Podem ser consideradas como ferramentas automatizadas que tem como objetivo auxiliar o desenvolvedor de sistemas em uma ou várias etapas do ciclo de desenvolvimento de software.

Objetivos

• Melhoria da qualidade de software;
• Aumento da produtividade no processo de software.

Vantagens do uso de ferramentas CASE

• Qualidade no produto final;
• Produtividade;
• Agilizar o tempo para tomada de decisão;
• Menor quantidade de códigos de programação;
• Melhoria e redução de custos na manutenção;
• Agilidade no retrabalho do software.

Desvantagem do uso de ferramentas CASE

• Incompatibilidade de ferramentas;
• Treinamento para utilização.

Uma ferramenta CASE que gosto bastante é o Enterprise Architect, que permite tudo isso e ainda gerar códigos em:

• ActionScript
• Ada
• C e C++
• C#
• Java
• Delphi
• Verilog
• PHP
• VHDL
• Python
• System C
• VB.Net
• Visual Basic
• E mais…

Esta é apenas uma solução para documentação e análise de sistema, que permite aumentar a qualidade melhorando ainda mais a produtividade no desenvolvimento de software.

Muito foi falado de testes neste artigo, então apresento a seguir algumas ferramentas de testes open-source.

Ferramentas de Testes

Para automação de testes podemos citar as seguintes ferramentas open-source:

• Selenium–Testes - Automatizados para Web por meios Funcionais e de Aceitação.
• Testes de performance em aplicações de diferentes tipos de servidores (HTTP/HTTPS, SOAP, JMS, etc.).
• Watir – Testes Automatizados para Web escritos na linguagem Ruby. Existem derivações em .Net (WatN) e Java (WatJ).

Conclusão

É preciso mudar a mentalidade e cultura de desenvolvedores e empresas de software para aumentar não apenas a qualidade de software, mas a rentabilidade das empresas de software em geral. Um grande desafio, uma vez que as faculdades, universidades e cursos técnicos formam desenvolvedores com esta mentalidade e cultura atrasados no mundo de hoje.

Os profissionais e empresas de software deveriam investir em treinamentos de análise, documentação e orientação a objetos, além de testes de software e, incentivar os funcionários a adotarem a risco estas metodologias de análise, desenvolvimento e testes de software. Só assim poderemos melhorar o cenário do mercado de software nacional, podendo inclusive competir com o mercado internacional.