Qualidade de software: importância da revisão de requisitos e de código

A dificuldade na obtenção dos requisitos. Referência: Dilbert.com

A fase de desenho em um projeto de engenharia de software é quando os requisitos iniciais do cliente - que é, ou representa, o futuro usuário do software - se transformam no modelo detalhado do que será construído, testado, implantado e suportado nas etapas seguintes do ciclo de vida de uma solução de software.

Os engenheiros de software sabem que uma fase de desenho bem sucedida é determinante para um bom resultado do projeto, para uma quantidade pequena de mudanças nos requisitos e, posteriormente, no código construído ou reusado (pois pode garantir, neste caso, que o código reutilizado atende, de fato, às necessidades do usuário).

Considerando como qualidade na fase de desenho a mínima quantidade possível de erros e mudanças no software que virá a ser construído, vamos explorar algumas estatísticas sobre quantidade de erros em projetos de software. É importante ressaltar que esse parâmetro, no entanto, é apenas uma faceta da qualidade de software, pois se percebe claramente que ele não tem influência na usabilidade da interface de um aplicativo, por exemplo, e a clareza na interface é um parâmetro essencial da qualidade percebida pelo usuário.


Conforme estatísticas do mercado norte americano de desenvolvimento de software, para cada ponto de função construído, encontraremos, tipicamente, 5 erros. No momento que este aplicativo for disponibilizado para uso, em torno de 3% destes erros ainda estarão presentes (97% de eficiência na remoção dos erros) se forem empregadas técnicas de revisão de requisitos, revisão de código e análise estática (static program analysis). Se estas técnicas não forem empregadas, em torno de 15% dos erros no código ainda estarão presentes no software (85% de eficiência na remoção dos erros).


Para exemplificar, um software de 2.000 pontos de função, que seria um aplicativo de porte médio, terá, no mínimo, 300 erros no seu código (eficiência de 97% na retirada dos erros gerados), podendo chegar a 1.500 (eficiência de 85% na remoção dos erros).


Se considerarmos que em torno de 15% dos erros são críticos, teremos de 45 a 225 erros críticos no momento do início do uso do nosso software. Isso é muito. Entregamos aos nossos usuários, segundo esta estatística, em um software de porte médio, até 225 erros que o farão parar o seu processo de negócio e lhe trarão impacto financeiro de algum tipo.


Se refizermos as contas para um software grande (10.000 pontos de função) chegaremos a uma expectativa de encontrar entre 1.500 e 7.500 erros no momento da entrega do software, sendo de 225 a 1.125 erros críticos.


Fica bem evidente que perseguir a qualidade no processo da engenharia de software é um esforço primordial. A revisão dos requisitos capturados e do código desenvolvido se torna fundamental para que o projeto se aproxime do máximo de eficiência na remoção dos erros (97%), mas estas práticas não são, infelizmente, comuns no mercado de software hoje em dia. 


Uma alternativa é estabelecer uma revisão informal entre os analistas de requisitos e programadores envolvidos em um projeto, de forma que eles revisem mutuamente os requisitos e códigos uns dos outros. Com isso não será atingido o máximo de eficiência que a revisão formal permitiria (97%), mas será atingido mais que os 85% medianos.




Referência:

Software Engineering Best Practices by Capers Jones.