Gestão da Qualidade


Mas, este sistema visa atender o que? E a quem?

Tudo bem, vamos perseguir todos, na nossa equipe, a entrega de um sistema com alto padrão de qualidade. Mas, qual são os objetivos de negócio que serão alcançados por este sistema? Quem são as pessoas que estão interessadas nos resultados deste sistema? E, quais são os desejos e interesses destas pessoas? Ora, já passamos muito do tempo de debatermos tão somente a qualidade do código. Não há ganho algum para o usuário e para a empresa, que são nossos clientes, quando o código está numa inigualável pureza e precisão, quando os resultados da execução ainda não estão atendendo aos objetivos de negócio. Não podemos esquecer que, ao sermos contratados para desenvolver um sistema, adentramos na missão de entregar uma solução de negócios, isto é, alguém está interessando em investir nesta solução, visando retorno deste investimento.

É claro que existe um grande valor agregado ao sistema recém-construído quando este passa por auditoria e demais revisões de código, porém não podemos ficar satisfeitos somente com isso. Vamos abordar mais uma vez aqui sobre Requisitos, que são as características que devem constar no sistema, visando atender necessidades do cliente.

Temos na Engenharia de Software, segundo Pressman, 2000, quando este define qualidade de software como: “conformidade a requisitos funcionais e de desempenho explicitamente declarados a padrões de desenvolvimento claramente documentados e a características implícitas que são esperados de todo software profissionalmente desenvolvidos”. Logo, o fator determinante do que virá a ser o sistema passa pela completa compreensão dos requisitos, e a partir da definição detalhada e sem ambigüidade dos mesmos, é possível saber se a equipe está construindo uma solução com o nível de qualidade esperado. E, qual é a qualidade que está sendo empregada para definir e especificar requisitos?

Em atividades de elicitação (ou descoberta ou levantamento) de requisitos persegue-se a identificação dos objetivos do cliente. Levantamentos dos requisitos mal formulados, mal definidos ou incompletos impactarão negativamente nas fases seguintes do ciclo de vida do projeto. Pois são estes requisitos que são base para a geração de modelos de arquitetura, classes, componentes, módulos e programas. Conseqüentemente o projeto ficará comprometido na medida em que os requisitos persistirem incompletos, incorretos e/ou ambíguos. Estudos apontam que os custos relativos para a eliminação de problemas, durante cada fase de desenvolvimento de um projeto, tendem a aumentar com o passar do tempo, ou seja, é mais barato corrigir algo antes da fase de Codificação/programação, e este custo é aproximadamente 4 vezes maior quando esta eliminação ocorre na fase de testes, e é aproximadamente 10 vezes maior na fase de manutenção.

Qual é então o primeiro passo? Esforcemo-nos a identificar as fontes de requisitos, que podem ser pessoas como o cliente e seus representantes, potenciais usuários finais, um sistema legado, manuais, normas, leis, padrões de mercado. Continuamos no próximo artigo.

Marcelo Jacintho
marcelo.jacinto@internativa.com.br