40. Qualidade de Software: Manifestações aos Olhos dos Clientes
Muito se tem falado sobre qualidade de software. Muitos artigos e livros falam sobre ela, sobre a
necessidade de melhorá-la e sugerem planos de ação para produzi-la e avaliá-la. Entretanto,
aparentemente, há muita discussão e discórdia sobre o conceito de qualidade e, por isso, muitos
planos não proporcionam os resultados desejados. As pessoas se defrontam com dificuldades ao
discutirem o tema e como atacar o problema do ponto de vista prático. A pedra de toque para
dirimir as controvérsias é compreender que software (ou sistema), como qualquer produto, é feito
para ser utilizado por alguém que espera que algum valor lhe seja agregado. Entender o conceito
de qualidade sob a abordagem de sua manifestação aos olhos dos clientes e aplicá-lo ao
desenvolvimento pode ser um caminho para aumentar a satisfação das pessoas que usam o
software.
Pela análise dos conceitos emitidos pelos mestres da qualidade, concluímos que, para todos eles,
ela é a capacidade de um artefato, tangível ou não, de atender ou satisfazer um conjunto de
requisitos ou expectativas do cliente (o usuário de um software é cliente). Assim, devemos pensar,
entender e praticar qualidade, sempre com foco no cliente, pautando nossas ações pelos seus
requerimentos. Isso é válido também para o software que é produzido para atender a
necessidades de um cliente ou classe de clientes. É o cliente que determina a qualidade que quer
e que pode pagar. Ele especifica os requisitos e julga os resultados do nosso trabalho. O nosso
cliente, conhecido como usuário e tido por muitos como um mal necessário, quer coisas como
tempo de resposta curto, resultados corretos, facilidade de aprender e usar, manutenção rápida,
preço baixo, prazo curto, facilidades de correção de erros, controle sobre o sistema, ajudas
eficazes e aumento de produtividade no seu trabalho, entre outros requisitos. Nosso cliente quer
ver e sentir tais características ou dimensões nos softwares que nós lhe entregamos.
A qualidade depende dos requisitos dos clientes que o artefato atende e de como os atende.
Assim, um software precisa apresentar adequação ao cliente e às suas tarefas, custo aceitável,
consistência de comportamento, compatibilidade com a experiência e conhecimentos do cliente e
conformidade às especificações. Portanto, qualidade é um conceito relativo e multidimensional e
se manifesta através de características presentes nos produtos.
Os requisitos e expectativas dos clientes podem ser agrupados e analisados sob um nível de
abstração mais elevado, constituindo tais grupos dimensões da qualidade. Garvin (1987), para
quem a qualidade deve ser avaliada segundo suas manifestações aos olhos dos clientes,
identificou, para produtos tangíveis, oito dimensões da qualidade (Tabela 1).
Tabela 1 – Dimensões da qualidade
Desempenho- Características operacionais relacionadas com as funções fundamentais do produto
Atributos- Características que suplementam seu funcionamento básico
Confiabilidade- Probabilidade de um produto funcionar mal ou falhar em um período de tempo
especificado
Conformidade- Grau de aderência do projeto e suas características operacionais aos padrões
estabelecidos
Durabilidade- A quantidade de tempo durante o qual um produto pode ser usado antes de tornar-se
inoperante ou inadequado às necessidades
Atendimento- Velocidade, cortesia, competência e facilidade de manutenção
Estética- Subjetividade quanto à aparência, sons, sabor, odor, impressão, cores, pressentimento,
sensação, etc.
Demonstração Imagem produzida pela reputação do produtor e inferências obtidas de vários
aspectos tangíveis e intangíveis do produto
Com certeza é, do ponto de vista prático, impossível obter alto nível de qualidade em todas as
dimensões. A qualidade pode, então, ser entendida como um compromisso entre as dimensões,
decorrente das restrições tecnológicas, custos e requisitos dos clientes. Cabe ao produtor
averiguar quais dimensões afetam, de modo mais significativo, a percepção do cliente e traduzi-las
(aqui vale a utilização do QFD – Quality Function Deployment) em termos de especificações de
projeto.
O compromisso é sentido na prática, pois tanto produtos tangíveis e intangíveis quanto software
raramente proporcionam satisfação integral. Sempre há, pelo menos, um requisito – total ou
parcialmente – não atendido.
McCall (ver Perry, 1982, e Pressman, 1992), a partir de estudos sobre os requisitos dos clientes,
obtidos em diversas pesquisas, estabeleceu 11 fatores da qualidade para software (Tabela 2).
Tabela 2 – Fatores da qualidade
Manutenibilidade-Esforço requerido para localizar e corrigir defeitos em um programa
Flexibilidade-Esforço requerido para modificar um programa operacional
Testabilidade- Esforço requerido para testar um software a fim de assegurar que ele execute as
funções para as quais foi construído
Portabilidade- Esforço requerido para transferir um software de um ambiente hardware/software
para outro
Reusabilidade- A extensão em que um software ou partes dele podem ser reutilizados –
relacionados ao empacotamento e escopo das funções executadas
Interoperabilidade-Esforço requerido para acoplar um software a outro
Correção-A extensão em que um programa satisfaz as especificações, os objetivos e missão
estabelecidos pelo usuário
Confiabilidade A probabilidade de um software funcionar sem falhas graves por um determinado
período. Eficiência-Quantidade de recursos/código requeridos por um software para executar sua
missão
Integridade - Proteção oferecida quanto a acessos indevidos
Usabilidade -Esforço requerido para aprender a usar o software, operá-lo, preparar as entradas e
interpretar as saídas
Pela definição de cada um, percebe-se que eles guardam estreita relação com as dimensões
identificadas por Garvin para produtos tangíveis.
A HP (Grady & Caswell, 1987), no seu processo de melhoria da qualidade de software,
desenvolveu o modelo FURPS (Functionality, Usability, Reliability, Performance and
Supportability), que representa as dimensões mais relevantes para seus clientes (Tabela 3).
Novamente, temos a necessidade de estabelecer compromissos, pois a melhoria da qualidade em
uma das dimensões significará piora ou estagnação em outra ou outras. Em cada caso, o que o
cliente prioriza? A resposta dará direção aos projetos e planos.
Tabela 3 – FURPS
Funcionalidade -Funções executadas pelo software, segurança do sistema
Usabilidade- Fatores humanos, estética, consistência e documentação
Confiabilidade Freqüência e severidade das falhas, capacidade de recuperação, acurácia dos
resultados, tempo médio entre falhas e previsibilidade
Desempenho -Velocidade de processamento, tempo de resposta, consumo de recursos, eficiência
e desempenho global
Atendimento - Testabilidade, flexibilidade, manutenibilidade, facilidade de instalação
Nielsen (1995) também discute a qualidade sob a abordagem de dimensões, mas enfatiza a
usabilidade. Essa é parte da “usefulness”, que se refere à capacidade do software de atingir o
objetivo desejado. Essa dimensão é subdividida em duas: utility (utilidade – agregação de valor) e
usability (usabilidade). Esta última se refere à possibilidade e facilidade de uso de um sistema. A
propósito, é conveniente lembrar que, conforme Aristóteles, o objetivo final de qualquer coisa é a
função para a qual foi construída.
Essa dimensão merece destaque. Nielsen escreveu um livro a ela dedicado. Os sistemas com que
nos deparamos nos dias atuais são diferentes dos produzidos nas décadas de 70 ou mesmo 80. A
complexidade é maior e, na maioria, são sistemas “interativos”, com foco na comunicação com o
usuário, o que exige maior atenção e esforço para conceber e implementar a interface.
Aproximadamente 80 por cento do código está relacionado à interface, que para muitos usuários é
o sistema, e destinado a implementar características, tais como facilidade de aprender, utilizar e
memorizar, compatibilidade, confiabilidade e utilidade, respeitando, dentro das limitações da
tecnologia, os objetivos, representações e conhecimentos dos clientes a que se destinam.
Essa dimensão, que reputo a mais complexa de se obter, inclui a adequação do software às
tarefas das pessoas, a interface (gráfica ou não) e a forma de usá-la, os procedimentos de
instalação, entre outras características. É através da interface que o cliente sente e percebe o
sistema. Talvez, para muitos deles, ela seja o sistema. O projeto dos elementos da interação e
interface depende do conhecimento e consideração do conteúdo do trabalho e das características
da tarefa. Assim, tratar a usabilidade corresponde a focalizar questões relativas a: conforto mental
e físico do usuário, comportamento e estratégia de resolução de problemas, memorização,
recordação, percepção e modelagem cognitiva, entre outros, tratados pela ergonomia,
especialmente a ergonomia cognitiva.
As dimensões tratadas anteriormente referem-se, na sua maioria, à qualidade in-trínseca dos
produtos e serviços. Entretanto, quem desenvolve software, assim como quem produz bens e
serviços, de uma forma geral, precisa criar vantagens através de seus processos de negócio. Slack
(1993), tratando da vantagem competitiva em manufatura, diz que tal vantagem significa “fazer
melhor”. Fazer melhor é um conceito que traz, no seu bojo, algumas dimensões da qualidade que
são muito apreciadas pelos clientes e se relacionam diretamente a questões crônicas do
desenvolvimento de software, quais sejam, prazo e orçamento dos projetos (Tabela 4). Essas
dimensões devem ser consideradas no estabelecimento ou escolha da metodologia de
desenvolvimento, das técnicas (estruturada, OO, etc.) e do processo de gestão da produção de
software. Especificamente, a dimensão velocidade sugere “reusabilidade”, que não é privilégio da
orientação a objetos.
Tabela 4 – Dimensões para competitividade
Velocidade - Reduzir o espaço de tempo entre o início do processo de desenvolvimento e a
entrega do software
Pontualidade- Manter a promessa de prazo de implantação. Ter condições de estimar prazos de
projeto com acuidade ou condições de aceitar prazos solicitados pelos clientes.
Flexibilidade - Variar e adaptar métodos e técnicas em função da alteração das necessidades dos
clientes
Custo- Utilizar recursos pouco onerosos e ter processos e técnicas eficientes
Competência -Demonstrar, através de aspectos tangíveis, a capacidade de atender às
necessidades dos clientes
Até aqui, vimos as posições de cinco autores, um dos quais é usuário de informática. Podemos
transpor os modelos da qualidade, utilizados na fabricação de produtos tangíveis, para o
desenvolvimento de software? O que viemos discutindo a propósito das variadas visões dos
autores citados sugere que a visão de “dimensões”, empregada para produtos tangíveis, pode ser
aplicada a software. De uma forma geral, somente os termos e a ordenação são diferentes. O
racional por traz de cada dimensão ou fator é basicamente o mesmo. Por outro lado, o software
também deve apresentar características que manifestem a qualidade aos olhos dos clientes.
Assim, criar um software com o nível adequado de qualidade significa criar um produto com as
características que o cliente quer e que as exiba, formalmente, ao mesmo.
Nossa sugestão é, então, que se trabalhe não com base em conceitos genéricos da qualidade,
mas com base nas expectativas do cliente. A qualidade do software deve ser a que o cliente quer.
Abordá-la sob essa óptica permite atuar de forma mais pragmática no desenvolvimento de
sistemas, bem como tomar melhores decisões sobre os projetos e sobre competitividade. Isso nos
leva a considerar válido propor que um software ou sistema com nível adequado de qualidade seja
conceituado como aquele que satisfaz a classe de usuários a que se destina, no que se refere às
dimensões tidas como relevantes pelos representantes daquela classe, consideradas as restrições
tecnológicas, preço, custo e prazo de entrega.
O processo de desenvolvimento deve, então, permitir construir software de tal sorte que o cliente
“veja” as manifestações da qualidade que ele valoriza. O mesmo deve ocorrer em relação ao
processo de desenvolvimento (metodologia), se queremos ser, realmente, competitivos. Uma
justificativa mais pragmática para tanto é que, quando da aquisição ou encomenda de um software,
o cliente, ou usuário, não pergunta qual o nível de qualidade do mesmo, mas questiona diversos
aspectos relacionados com as dimensões, inclusive prazo e preço. Portanto, a abordagem das
dimensões não só pode, como deve ser aplicada ao desenvolvimento de software.
Decidir sobre a qualidade, com base nas dimensões que representam os requisitos e expectativas
dos clientes, permite maior taxa de acertos na escolha de metodologias, técnicas e tecnologias a
serem empregadas no desenvolvimento de sistemas, no estabelecimento de programas de
qualidade e produtividade em software. Permite também, de forma mais pragmática, responder a
questões como: Do que os meus clientes precisam? O que agrega valor para eles? Qual o meu
produto ou serviço? O processo utilizado permite produzir o software que satisfaz os clientes? As
práticas atuais permitem satisfazer os clientes? Os métodos e técnicas de engenharia de software
são suficientes? A usabilidade dos softwares é a que o cliente quer?
Outra vantagem dessa abordagem é eliminar o desperdício de tempo e de outros recursos com
discussões filosóficas e planos baseados em conceitos gerais, pois qualidade é um conceito
relativo, que depende dos interesses e necessidades de quem a conceitua ou define. Além disso,
as necessidades de cada cliente são diferentes e se modificam ao longo do tempo.
Talvez seja necessária alguma “personalização” nas dimensões para cada situação prática.
Entretanto, substituir um par de subdimensões não parece ser algo complexo, uma vez que os
conceitos estão estabelecidos.
Praticar a qualidade através dos processos e segundo suas manifestações aos olhos dos clientes
propicia um melhor encaminhamento das ações e dos planos para melhorar a satisfação do cliente
e para investir recursos financeiros, humanos e tecnológicos, de forma a obter melhor julgamento
dos clientes, aderência aos objetivos e planos das empresas e, talvez, para garantir
“empregabilidade”. Entretanto, resta ainda uma questão em aberto: a mensuração. Como saber se,
realmente, o meu processo está criando, a cada passo, as dimensões que nossos clientes
valorizam? Como medir a minha vantagem em relação ao meu concorrente?
Referências bibliográficas
Competing on the eight dimensions of quality. Harvard Business Review, 65, (6): 101-9, Nov./Dec.,
1987.
GARVIN, D. A. What does “Product Quality” really mean? Sloan Management Review, 25 (1): 2543, 1984.
GRADY, R. B. & CASWELL, D. L. Software metrics: establishing a company-wide program.
Englewood Cliffs, Prentice-Hall, 1987.
NIELSEN, J. Usability engineering. Boston, AP Professional, 1995.
PERRY, W. E. Effective methods of EDP quality assurance. Wellesley, QED, 1982.
PRESSMAN, R. S. Software engineering: a practitioner’s approach. 3 ed. New York, McGraw-Hill,
1992.
SLACK, N. Vantagem competitiva em manufatura. São Paulo, Atlas, 1993.
Autor: Luís Alves da Silva
Biografia: é mestre em Engenharia de Produção pela EP-USP, graduado em Administração de
Empresas e em Ciências Contábeis pela FEAC-USP, Professor de Auditoria de Sistemas na FASP
(Faculdades Associadas de São Paulo) e Analista Consultor da GSI Serviços de Informática Ltda.
(uma empresa IBM).