Muito além do desenvolvimento de software

Por Wagner Xavier *

As empresas produtoras de software empresariais, a cada dia buscam desenvolver produtos que gerem resultados esperados pelos clientes e usuários finais, diminuindo custos e insatisfação do cliente, suportes para dúvidas, incidentes e retrabalhos internos e externos.

Por meio de experiências comprovadas em organizações dessa natureza, percebe-se que a utilização das boas práticas na formalização de seus processos de revisões de software traz frutos cada vez mais satisfatórios e consistentes para a qualidade final dos artefatos produzidos.

Lembramos que revisão de software é um conjunto de atividades sistemáticas na área da engenharia de software que visa garantir a alta qualidade em todo o ciclo do desenvolvimento. Essas atividades são divididas em: discussão formal, apresentação, revisões técnicas formais, revisão por pares (peer review), walkthrough e inspeção de software.

Cada uma dessas atividades traz objetivos bem claros, assim como um conjunto de técnicas que permite ao grupo que irá participar, de alguma forma, da construção do artefato, mitigar muitos dos defeitos que podem acompanhá-lo em todas as fases da construção até o produto final.

Neste artigo apresento informações específicas e reais sobre inspeções de software e de como essa ação na prática resulta na diminuição do retrabalho, ganho na produtividade e consequente elevação da qualidade final do produto de software.

Para situar o leitor, a inspeção de software é uma série de práticas que estabelece um processo formal cujo objetivo é a descoberta antecipada de possíveis falhas antes que o artefato final de software seja produzido.

O processo se dá pela preparação do material por meio dos requisitos (funcionais e não funcionais) definidos, leitura, registros e reuniões de inspeção com o grupo, chamado de inspetores e que atuará em qualquer uma das fases do artefato (análise, programação, teste, documentação e treinamento), e ainda possíveis convidados.

Além desse grupo, também deve existir a figura do moderador ou Software Quality Assurance (SQA), responsável por registrar as não conformidades encontradas e acompanhar os planos de ação gerados na inspeção até que todos os requisitos apontados estejam devidamente alinhados. O moderador pode também apontar um redator, para apoiar na documentação gerada durante a inspeção.

Toda a inspeção parte de uma lista de requisitos, que são detalhados antes da efetiva construção do código e dão suporte para a execução dos casos de uso para a equipe de desenvolvimento. E também a casos de testes para a equipe de teste e homologação do artefato final já produzido.

As áreas de documentação e treinamento também são beneficiadas. Além de participar das reuniões, elas acessam todos os documentos gerados durante o planejamento para inspeções realizadas. Os tipos de reunião de inspeção ocorrem durante toda a fase de planejamento e se dividem em: inspeção de requisitos funcionais, técnicos, especificação funcional, especificação técnica, plano de teste, casos de teste e check-list do projeto de teste.

Os resultados das inspeções podem gerar necessidade de revisão de análise em documentos dos requisitos, casos de uso, casos de testes ou planejamento em qualquer uma das fases do desenvolvimento.

Quanto à natureza dos defeitos, os principais podem ser classificados em: defeitos de omissão, fatos incorretos, ambiguidade e informação estranha. Dependendo do tipo de inspeção que será realizada, são indicadas ferramentas que podem variar desde planilhas de cálculo, ferramentas de processadores de testes, software de gerenciamento de atividade e projetos a ferramentas de análise para planos de casos de uso e testes. O mais importante nesse caso são os corretos registros, assim como a geração de documentos que tragam os conteúdos corretos para que as inspeções sejam produtivas e eficazes.

Outro fato fundamental é a disciplina dos inspetores, seja ela por meio do cumprimento dos prazos estabelecidos e horários dos encontros, assim como as corretas e críticas leituras dos documentos gerados.

Resultados práticos

Usamos como base para estudo neste artigo um caso real, cujo objetivo é apontar para indicadores que demonstram a eficiência da inspeção na prática.

Numa seleção de uma fase de um projeto, que englobou 16 rotinas de software, chegou-se ao seguinte número de defeitos encontrados durante as inspeções:

Total de defeitos encontrados: 209

Defeitos em artefatos já inspecionados: 2

Melhorias apontadas: 81

Falsos positivos (alarmes falsos): 45

Os 209 defeitos encontrados foram classificados da seguinte forma:

Ambiguidade: 8

Inconsistência: 56

Fato incorreto: 29

Informação estranha: 15

Falta informação: 101

Em resumo, é notório perceber os principais ganhos com o processo formal de inspeção:

• Conhecimento prévio dos requisitos definidos para o produto de software pelos inspetores;
• Participação de todos os envolvidos (equipe do projeto) em todas as fases de análise e construção, testes e documentação;
• Mitigação de um elevado número de defeitos que foram evitados antes da construção do código;
• Documentação formal dos trabalhos;
• Maior completude e maturidade dos conteúdos;
• Acentuado índice de qualidade no levantamento de requisitos assim como maior nível de detalhamento nos documentos de análise assim como planejamento de testes.

Do ponto de vista informal, ainda será possível perceber maior comprometimento e engajamento da equipe do projeto, simplesmente pelo fato de ela ter sido envolvida em todas as fases do projeto.

E como resultado prático desse processo será possível perceber claramente a evolução e o nível de integração das equipes, assim como uma melhoria substancial na qualidade do produto e, consequentemente, a diminuição do número de retrabalhos quando o cliente final receber o produto já construído e devidamente testado.

* Wagner Xavier é diretor de desenvolvimento e suporte da Prosoft Tecnologia