Santo Graal da Qualidade de Software (1)

De modo geral a qualidade de software é encarada como o resultado final, o objetivo, de um esforço pontual. Contudo a qualidade, e em particular a qualidade de software, não se compadece com esforços pontuais. Quem assim pensa está condenado a desperdiçar tempo e dinheiro, pois os seus esforços traduzir-se-ão em alguns benefícios temporários que rapidamente desaparecerão. Como os casamentos felizes, a qualidade para ser duradoura exige um compromisso a longo prazo e que se aprofunda com o tempo.

A análise e medição dos processos de desenvolvimento de software, permite-nos conhecimento e experiência acrescidos os quais potenciam a introdução de novas melhorias, num processo que é iterativo e se vai desenvolvendo ao longo do tempo. Parte do êxito de um projeto de melhoria de qualidade assenta na capacidade que esse projeto teve para abrir caminho a subsequentes projetos de melhoria.

Neste contexto o esforço de qualidade deve centrar-se na procura da melhoria contínua e no suporte às equipes de desenvolvimento de software no sentido de as levar a acreditar nos benefícios inerentes aos princípios da gestão da qualidade.

Como as necessidades, e o estádio de desenvolvimento depende de equipa para equipa, o primeiro passo passa por saber o estádio atual de forma a acompanha-los no desenvolvimento das etapas seguintes. As oito etapas do processo de melhoria contínua da qualidade são os seguintes:

1. Testar e corrigir - Inicialmente, o foco de quase todas as equipas de desenvolvimento de software está em fazer com que o software funcione. O objetivo dos técnicos de desenvolvimento é finalizar o desenvolvimento do produto para iniciar a etapa de testes o mais rapidamente possível.

Daí inicia-se o ciclo de testar e corrigir (e testar e corrigir e testar e corrigir e…) até que o software funcione suficientemente bem para ser disponibilizado aos utilizadores. Nesta fase, a única forma que os técnicos conhecem para melhorar a qualidade do software é gastar mais tempo e dinheiro em testes. O desafio que se lhes propõe é mudar esse paradigma errado fazendo-os evoluir o mais rápido possível para as etapas de 2 a 8 do processo de qualidade.

2. Inspecionar - A etapa seguinte é quando os técnicos de desenvolvimento e gestores começam a remover os defeitos antes da etapa de testes funcionais. Isso geralmente é feito recorrendo a vários tipos de inspeções. O desafio típico nesta etapa é conseguir com que os técnicos façam todas as inspeções necessárias e as façam corretamente.

3. Medição parcial - À medida que as iniciativas de inspeção amadurecem, os técnicos de desenvolvimento começam a medir e a usar os dados obtidos durante as atividades de inspeção para melhorar o processo de inspeção e para obter informação que lhes permita concentrar as inspeções sobre os elementos mais problemáticos do software. Agora o desafio é obter dados adequados e utilizar esses dados para melhorar o software.

4. Dono da qualidade - Como os técnicos de desenvolvimento participam das atividades de inspeção, eles tenderão a ficar sensíveis aos erros que cometem. Como resultado começarão a rever a forma como organizam o seu trabalho, com o intuito de eliminar o maior número possível de problemas. Chagados a este ponto a qualidade do software por eles produzido irá melhorar rapidamente.

5. Medições pessoais - Para que os técnicos de desenvolvimento possam melhorar a qualidade do seu trabalho, eles necessitam de dados concretos e objetivos referentes aos defeitos que cada um introduziu e removeu, bem como à dimensão e ao tempo gasto no desenvolvimento do software. Aqui o desafio é criar as condições para a recolha, tratamento e disponibilização desses dados. À medida que os técnicos examinam os dados sobre os defeitos que escaparam ás atividades de inspeção, a qualidade dos testes e do produto final de software irá novamente aumentar.

6. Erros de Desenho - Uma vez que os técnicos de desenvolvimento tenham aprendido a gerir os seus defeitos de codificação, eles podem focar-se agora nos defeitos de desenho. Isso exige a utilização de práticas precisas de desenho e também de métodos de verificação adequados. O desafio é usar métodos de desenho homogéneos para todos os programas (grandes ou pequenos) e utilizar métodos de verificação de desenho em todas as inspeções e revisões de desenho de cada técnico.

7. Prevenção de defeitos - Enquanto o uso de métodos de desenho e de medição reduzem as taxas de incorporação de defeitos em cerca de duas vezes, programas eficazes de prevenção de defeitos seguem um processo estruturado para identificar problemas no processo desenvolvimento de software e fazer as mudanças necessárias para eliminar ainda mais a ocorrência de defeitos. O desafio é fazer com que o programa de prevenção de defeitos seja iniciado e, em seguida, sustentá-lo para que seja ampliado e possa cobrir o ciclo de vida completo de desenvolvimento de software.

8. Medição baseada no utilizador - Finalmente, o programa de qualidade deve ser direcionado por medidas de qualidade baseadas nos utilizadores (ver os nossos artigos sobre as normas ISO 14598 / 9126. O principal desafio é entender as características de qualidade que são mais importantes para os utilizadores e medir essas características de uma forma que tenha significado tanto para os técnicos de desenvolvimento como para os utilizadores.

A mensagem principal deste processo contínuo é a de que a qualidade depende da nossa capacidade para aumentar a maturidade do processo de desenvolvimento. Os níveis de maturidade mais altos, correspondentes às etapas 6, 7 e 8, só serão possíveis após o processo de desenvolvimento ter percorrido as etapas iniciais, as quais dotarão a equipa dos dados necessários à avaliação pormenorizada e ao aprofundamento do processo de qualidade.

Esse aumento de maturidade exige uma estratégia que defina os objetivos e o caminho para os atingir, uma forma de avaliar a situação atual e de medir os sucessivos objetivos intermédios. 
_____________________ 

(1) - Originalmente este artigo foi publicado por Sidney Galeote no blog http://blog.prasabermais.com.

Postagens mais visitadas deste blog

PMBOK v6: 7.4 Controlar os Custos do Projeto

PMBOK v6: 5.2 Coletar os Requisitos