Gestão da Qualidade


Precisamos atender a tudo que pedirem no sistema, e um pouco mais…?

Tudo bem, vamos perseguir todos, na nossa equipe, a entrega de um sistema com alto padrão de qualidade. Mas,… o que seria “alto padrão de qualidade” ? Bem, sua empresa precisa ter um padrão por ela estipulado, baseado nas normas e padrões internacionais de qualidade. E…será que precisa mesmo, ou nós iremos idealizar nosso mundo ideal?

O que deve balizar sua gerência e liderança para seguir e cobrar qualidade da sua equipe pode vir acompanhado de siglas não muito familiares, a princípio, como CMM, CMMI, COBIT, ISO, ITIL, etc. (sendo esta ultima “entre outras coisas”). Não podemos desvalorizar o fato de se ter um grupo de profissionais, na sua empresa, com a missão de definir um Processo de Desenvolvimento de Sistemas, zele por permear padrões de sucesso reconhecido internacionalmente provê credibilidade e sustentação para o aculturamento da empresa e denota uma percepção bastante sólida de qualidade para seu cliente final.

Voltando ao primeiro artigo, apreciemos o que 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”.

E o que vem a ser um Requisito ? Requisito é uma capacidade ou característica, que o sistema deve ter ou prover, para atender a uma necessidade de negócio do cliente. Logo, um dos fatores cruciais para determinar a qualidade do sistema que sua equipe está entregando é a qualidade de 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 seguinte do ciclo de vida de desenvolvimento, quando normalmente são gerados os modelos de arquitetura, classes, componentes, módulos e programas. Conseqüentemente o projeto ficará comprometido na medida em que os requisitos estiverem incompletos, incorretos e/ou ambíguos. seguros.

Estudos apontam que os custos relativos para a eliminação dos mesmos problemas nas etapas do desenvolvimento do projeto elevarão os custos 4X maior para eliminação do erro na fase de testes e na fase de manutenção será 10X maior.

Antes de aprofundarmos aqui sobre Engenharia de Requisitos, baseado no SWEBOK (Software Enginnering body of knowledgment), abrangendo a Elicitação, Análise, Especificação e Validação de Requisitos, precisaremos abordar conceitos básicos de modelo de processo de desenvolvimento de sistemas. E por que? Simples. Não há como seguirmos, dentro de uma organização que exige “o máximo de velocidade com o máximo de qualidade” , uma metodologia em engenharia de requisitos se esta não estiver respaldada pelo Processo de Desenvolvimento de sistemas desta organização.

Este processo tem força de norma, isto é, você tem que seguir a norma da organização. Não existe como produzir um sistema sem seguir o Processo de Desenvolvimento da empresa. Se este processo precisa melhorar, evoluir, etc, tudo bem , é outro assunto. Porém, não seguir processo algum seria algo análogo a imagirnarmos aqui que a linha de montagem de uma fabricante de automóveis estaria mudando a cada novo funcionário criativo que chegasse. Não iremos demorar muito para concluir que um processo consolidado e altamente respeitado em uma linha de produção de automóveis garante, ou melhor, é uma forte garantia, entre outras, de que o produto final estará respeitando “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 VEÍCULO profissionalmente desenvolvido.

Abraços

Marcelo Jacintho
marcelo.jacinto@internativa.com.br