Processos e qualidade de software

Desenvolver software de qualidade não é mais um requinte para poucos, transformou-se num fator de competitividade num mercado cada vez mais exigente.

por Cristiano Caetano

Desenvolver software de qualidade não é mais um requinte para poucos, transformou-se num fator de competitividade num mercado cada vez mais exigente. O filósofo Nietzsche, no século passado, alertava: "Com o aumento da competição, a qualidade se torna mera propaganda. Vence aquele que melhor engana". Essa receita é muito simples e fácil de seguir, todavia, quem tomar esse tipo de postura estará fadado ao fracasso. Nos dias de hoje, a qualidade tornou-se requisito imprescindível para garantir a sobrevida de um software no mercado. Portanto, neste contexto, podemos concluir que as empresas mais competitivas são as empresas que trabalham sob a ótica da melhoria contínua dos processos para aumentar a qualidade do processo de desenvolvimento e, conseqüentemente, aumentar a qualidade do produto final.

Estima-se que o custo decorrente da correção de um bug cresce dramaticamente à medida em que ele é descoberto em fases mais adiantadas no processo de desenvolvimento de software. No entanto, ainda existe uma forte tendência nas empresas em negligenciar essa realidade e não dedicar o tempo mínimo necessário para a realização das atividades de qualidade e testes de software. A Figura 1 apresenta o resultado de uma pesquisa realizada em 2002 pela InformationWeek com 800 profissionais da área de TI contabilizando o custo das falhas, seja por meio de custos mais altos ou por diminuição dos lucros.

Figura 1. Contabilizando as falhas (Fonte: INFORMARTIONWEEK 2002).

Em contrapartida a esse cenário pouco promissor, o novo mantra da indústria é "Faça a coisa certa na primeira tentativa". Gigantes como a Microsoft, por exemplo, já se deram conta de que os consumidores já não confiam tanto nos seus produtos. O grande desafio dessas empresas é criar produtos tão confiáveis quanto os sistemas de distribuição de eletricidade, gás e telefone. Segundo artigos em sites especializados, a tônica dessa estratégia da Microsoft será a consolidação dos componentes fundamentais dos seus aplicativos ao invés de novos lançamentos cheios de novas features (e novos bugs). Apesar do ceticismo dos especialistas em TI, a Microsoft no final de Janeiro deste ano (2006) já admitiu um possível atraso no lançamento do seu novo sistema operacional chamado Windows Vista; conforme a declaração deles o sistema operacional só será lançado se atingir as espectativas de qualidade. Discussões à parte, devemos admitir que essa é uma atitude madura de uma empresa que quer se manter no mercado.

Padronização dos processos (Prós)

Considerando o que foi exposto, devemos destacar a importância da padronização dos processos - desde a concepção até a entrega do produto final - como uma abordagem viável na introdução sistemática de qualidade. Essencialmente, um padrão estabelece dimensão a todas as tarefas rotineiras e, a melhor forma de executá-las. Todo padrão, por mais rudimentar que seja, oferece um alicerce fundamental ao processo de desenvolvimento de software, garantindo que todas as etapas atinjam resultados previsíveis e de qualidade assegurada. Além disso, uma atividade padronizada poderá ser medida com maior eficiência, fornecendo métricas precisas para determinar a efetividade da abordagem por meio de índices de produtividade, curva de aprendizado, entre outros. Afinal, quem consegue medir o caos?

Uma abordagem padronizada estabelece uma linguagem comum entre os membros de uma equipe, estimulando o intercâmbio de conhecimento e, conseqüentemente, otimizando a execução de todas as tarefas. Além disso, os padrões deverão ser renovados, expandidos e aperfeiçoados ao passar do tempo para que não caiam em desuso ou fiquem desatualizados, caso contrário, deteriorarão a ponto de se tornarem inúteis.

A falácia da padronização dos processos (Contras)

Segundo Watts S. Humphrey, criador do CMM (Capability Maturity Model), a qualidade do produto final é diretamente proporcional a qualidade do processo. Muitos processos de desenvolvimento de software tais como CMM (Capability Maturity Model) ou RUP (Rational Unified Process) são fortemente baseados nessa perspectiva. Esses processos definem quais atividades devem ser executadas e como medí-las, mas no entanto, não especificam como executar essas atividades, quais as melhores técnicas, ferramentas, etc. A grande falha desses processos é que eles promovem a melhoria do processo de desenvolvimento de software e não na melhoria do produto final, ou seja, o software.

A qualidade, como veremos mais adiante, é baseada em percepções; ou melhor, em alinhamento de percepções. A experiência tem mostrado que apesar dos processos fornecerem fantásticos frameworks para o a geração de métricas e estimativas formais; assim como, modelos e templates para as mais diversas atividades, existe uma lacuna no ponto de vista de como lidar com a imprevisibilidade do ser humano. Perceba que quando uma estimativa diz que determinada tarefa deverá ser executada em 40 horas/homem. O que isso quer dizer para você? O que quer dizer 1 hora/homem? Será que 1 hora/homem significa uma hora ideal de um profissional com um bom grau de instrução, com cerca de cinco anos de experiência na área, bem treinado na tecnologia em que está trabalhando, sem problemas pessoais numa segunda-feira às oito horas da manhã após tomar uma xícara de café? A motivação principal dessa discussão é: Como alguém pode instituir precisão numa atividade tão incerta, tão imprevisível?

Muitas vezes, a principal chaga dos processos, na minha opinião é a capacidade de algumas empresas transformarem o processo num limitador, homogeneizando o talento e a criatividade. Assumindo que o processo assegura as "ditas" previsibilidade e qualidade, qual o sentido de termos os melhores profissionais disponíveis no mercado, se profissionais menos experientes ou medíocres podem realizar a mesma atividade obtendo o "mesmo" resultado. Assim, muitas vezes, as atividades de teste e qualidade de software, por exemplo, são realizadas por programadores iniciantes, suporte técnico, secretárias (nada contra esses profissionais, estou apenas sendo enfático), já que o processo garante que as atividade sejam realizadas conforme o script pré-definido.

"A grama do vizinho é sempre mais verde" também conhecido como "Qualidade é uma questão de percepção""

Um dos principais desafios enfrentado pelos profissionais de qualidade e teste de software é definir o que é qualidade no contexto do produto em que se está lidando, na estratégia corporativa da empresa, no orçamento, tempo e recursos humanos disponíveis, entre outras variáveis. Assim como nos eventos cotidianos, a significação do que é qualidade está sujeita a pormenores subjetivos ou ruídos entre o transmissor e o receptor da mensagem. Segundo esse princípio, estamos continuamente lidando com conflitos de percepção de qualidade, seja a qualidade da comida de certo restaurante, o enredo de um filme, o arranjo de uma música e assim por diante.

Fundamentalmente, portanto, devemos eliminar esses ruídos e estabelecer uma visão comum entre todos os membros da equipe e usuários. Um exemplo clássico de ruído entre significação e significado pode ser observado na Figura 2. Tente dizer rapidamente o nome da cor da fonte de cada palavra ao invés do nome da cor que está escrito em cada palavra. Você perceberá que apesar do problema estar bem formulado e todas as variáveis claramente definidas, ainda assim, um ruído entre significação e significado criado por um modelo mental seu fará que você cometa alguns erros.

Figura 2. O efeito Stroop (Fonte: American Psychological Association)

Adicionalmente, o exemplo ilustrado na Figura 3, demonstra a natureza âmbigua da percepção humana por meio da ênfase de diferentes palavras em uma frase. A mensagem transmitida pela frase analisada, pode ter um significado totalmente novo conforme as diferentes interpretações da palavra enfatizada.

Figura 3. Podemos obter diferentes percepções enfatizando diferente palavras de um requisito.

Conclusão

É importante compreender que a qualidade não é um estado permanente, mas uma busca constante. Assim, em seu estado mais maduro, os padrões otimizarão todas as etapas do processo de desenvolvimento de software, aumentando a produtividade e minimizando o re-trabalho. No entanto, assumindo que a qualidade é uma percepção no ponto de vista dos usuários do produto, o desafio dos profissionais da área de qualidade e teste de software é encontrar um ponto de equilíbrio entre a percepção de qualidade dos usuários em relação ao produto considerando os demais recursos disponíveis.

Para saber mais...

Quality Software se certifica para atuar no exterior
http://www.itweb.com.br/noticias/artigo_staging.asp?id=108511

Quality First: Users say software quality is critical. But it"s up to them, and their vendors, to do something about it
http://www.informationweek.com/story/IWK20020517S0010

Code It Right The First Time Is Microsoft"s New Mantra
http://www.informationweek.com/story/IWK20020517S0009

Microsoft hints at delay to Vista
http://www.techworld.com/security/news/index.cfm?NewsID=5263

A Personal Commitment to Software Quality
http://www.sei.cmu.edu/publications/documents/95.reports/95.ar.psp.qual.html

Interference: The Stroop Effect
http://www.apa.org/science/stroop.html