Desempenho- Características operacionais relacionadas com as funções fundamentais do produto

Transcrição

1 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

2 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.

3 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

4 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

5 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., GARVIN, D. A. What does Product Quality really mean? Sloan Management Review, 25 (1): 25-43, GRADY, R. B. & CASWELL, D. L. Software metrics: establishing a company-wide program. Englewood Cliffs, Prentice-Hall, NIELSEN, J. Usability engineering. Boston, AP Professional, PERRY, W. E. Effective methods of EDP quality assurance. Wellesley, QED, PRESSMAN, R. S. Software engineering: a practitioner s approach. 3 ed. New York, McGraw-Hill, SLACK, N. Vantagem competitiva em manufatura. São Paulo, Atlas, 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).