Engenharia de Software/Qualidade de Software

Origem: Wikilivros, livros abertos por um mundo aberto.
< Engenharia de Software
Saltar para a navegação Saltar para a pesquisa

O que é qualidade?[editar | editar código-fonte]

Em seu livro Zen e a Arte da Manutenção de Motocicletas, Robert Pirsig comentou sobre aquilo que denominamos qualidade:

Qualidade... sabemos o que ela é, embora não saibamos o que ela é. Mas essa afir­mação é contraditória. Mas algumas coisas são melhores do que outras; ou seja, elas têm mais qualidade. Mas quando tentamos dizer o que é qualidade, separando-a das coisas que a têm, tudo desaparece como num passe de mágica! Não há nada a dizer a respeito. Mas se não conseguimos dizer o que é qualidade, como sa­ber o que ela é ou como saber até se ela existe mesmo? Se ninguém sabe o que ela é, então, para fins práticos, ela não existe. Porém, para fins práticos, ela realmente existe. Em que mais se baseia a qualidade? Por que outro motivo as pessoas paga­riam fortunas por algumas coisas e jogariam outras na lata de lixo? Obviamente, algumas coisas são melhores do que outras... mas o que quer dizer melhor?... E por aí vai (andando em círculos), girando rodas mentais e em nenhum lugar encon­trando um ponto de tração. Mas o que é mesmo qualidade? O que é?

De fato - o que é isso?

Em um nível mais pragmático, David Garvin, da Harvard Business School, sugere que "qualidade é um conceito complexo e multifacetado" que pode ser descrito segundo cinco pontos de vista diferentes. A visão transcen­dental sustenta (assim como Pirsig) que qualidade é algo que se reconhece ime­diatamente, mas não se consegue definir explicitamente. A visão do usuário enxerga a qualidade em termos das metas específicas de um usuário. Se um produto atende a essas metas, ele apresenta qualidade. A visão do fabricante define qualidade em termos da especificação original do produto. Se o produto atende às especificações, ele apresenta qualidade. A visão do produto sugere que a qualidade pode ser ligada às características inerentes (por exemplo, fun­ções e recursos) de um produto. Finalmente, a visão baseada em valor mede a qualidade tomando como base o quanto um cliente estaria disposto a pagar por um produto. Na realidade, qualidade engloba todas essas visões e outras mais.

Qualidade de projeto refere-se às características que os projetistas espe­cificam para um produto. A qualidade dos materiais, as tolerâncias e as es­pecificações de desempenho, todos são fatores que contribuem para a quali­dade de um projeto. Quanto mais materiais de alta qualidade forem usados, tolerâncias mais rígidas e níveis de desempenho maiores forem especificados, mais aumentará a qualidade de projeto de um produto se ele for fabricado de acordo com essas especificações.

No desenvolvimento de software, a qualidade de um projeto engloba o grau de atendimento às funções e características especificadas no modelo de requisitos. A qualidade de conformidade focaliza o grau em que a implemen­ tação segue o projeto e que o sistema resultante atende às suas necessidades e às metas de desempenho.

Mas qualidade de projeto e qualidade de conformidade são as únicas questões que os engenheiros de software devem considerar? Robert Glass sustenta que o indicado é uma relação mais "intuitiva":

satisfação do usuário = produto compatível + boa qualidade + entrega dentro do orçamento e do prazo previsto

Ou seja, Glass argumenta que a qualidade é importante, mas se o usuário não estiver satisfeito, nada mais importa. DeMarco reforça esse pon­to de vista ao afirmar: "A qualidade de um produto é função do quanto ele transforma o mundo para melhor". Essa visão de qualidade sustenta que se um produto de software fornece benefício substancial a seus usuários, é possível que eles estejam dispostos a tolerar problemas ocasionais de confiabilidade ou desempenho.

Qualidade de software[editar | editar código-fonte]

Até mesmo os desenvolvedores de software mais experientes concordarão que software de alta qualidade é um objetivo importante. Mas como definir a qualidade de software? No sentido mais geral, a qualidade de software pode ser definida como, uma gestão de qualidade efetiva aplicada de modo a criar um produto útil que forneça valor mensurável para aqueles que o produzem e para aqueles que o utilizam.

Não há dúvida nenhuma de que essa definição pode ser modificada ou estendida e debatida interminavelmente. A de­finição serve para enfatizar três pontos importantes:

  1. Uma gestão de qualidade efetiva estabelece a infraestrutura que dá su­porte a qualquer tentativa de construir um produto de software de alta qualidade. Os aspectos administrativos do processo criam mecanismos de controle e equilíbrio de poderes que ajudam a evitar o caos no proje­to - um fator-chave para uma qualidade inadequada. As práticas de en­genharia de software permitem ao desenvolvedor analisar o problema e elaborar uma solução consistente - aspectos críticos na construção de software de alta qualidade. Finalmente, as atividades de apoio, como o gerenciamento de mudanças e as revisões técnicas, têm muito a ver coma qualidade, assim como qualquer outra parte da prática de engenharia de software.
  2. Um produto útil fornece o conteúdo, as funções e os recursos que o usuá­rio deseja; além disso, e não menos importante, deve fornecer confiabi­lidade e isenção de erros. Um produto útil sempre satisfaz às exigências definidas explicitamente pelos envolvidos. Além disso, ele satisfaz a um conjunto de requisitos implícitos (por exemplo, facilidade de uso) que se espera de todo software de alta qualidade.
  3. Ao agregar valor tanto para o fabricante quanto para o usuário de um produto de software, um software de alta qualidade gera benefícios para a empresa de software e para a comunidade de usuários. A empresa fa­bricante do software ganha valor agregado pelo fato de um software de alta qualidade exigir menos manutenção, menos correções de erros e menos suporte ao cliente. Isso permite que os engenheiros de software despendam mais tempo criando aplicações novas e menos tempo em manutenções. A comunidade de usuários ganha um valor agregado, pois a aplicação fornece a capacidade de agilizar algum processo de negócio. O resultado final é: (1) maior receita gerada pelo produto de software, (2) maior rentabilidade quando uma aplicação suporta um processo de negócio e/ou (3) maior disponibilidade de informações cruciais para o negócio.

Dimensões de qualidade de Garvin[editar | editar código-fonte]

David Garvin sugere que a qualidade deve ser considerada adotando­-se um ponto de vista multidimensional que começa com uma avaliação da conformidade e termina com uma visão transcendental (estética). Embora as oito dimensões de qualidade de Garvin não tenham sido desenvolvidas espe­cificamente para software, elas podem ser aplicadas quando se considera qua­lidade de software:

  • Qualidade do desempenho. O software fornece todo o conteúdo, funções e recursos especificados como parte do modelo de requisitos, de forma agerar valor ao usuário?
  • Qualidade dos recursos. O software fornece recursos que surpreendem e encantam usuários que os utilizam pela primeira vez?
  • Confiabilidade. O software fornece todos os recursos e capacidades sem falhas? Está disponível quando necessário? Fornece funcionalidade sema ocorrência de erros?
  • Conformidade. O software está de acordo com os padrões de software locais e externos relacionados com a aplicação? Segue as convenções de projeto e codificação de fato? Por exemplo, a interface do usuário está de acordo com as regras de projeto aceitas para seleção de menus ou entrada de dados?
  • Durabilidade. O software pode ser mantido (modificado) ou corrigido (depurado) sem a geração involuntária de efeitos colaterais indesejados? As mudanças farão com que a taxa de erros ou a confiabilidade degradem com o passar do tempo?
  • Facilidade de manutenção. O software pode ser mantido (modificado) ou corrigido (depurado) em um período de tempo aceitável e curto? O pessoal de suporte pode obter todas as informações necessárias para realizar alte­ rações ou corrigir defeitos? Douglas Adams comenta ironicamente, "A diferença entre algo que pode dar errado e algo que possivelmente não pode dar errado é que quando algo que possivelmente não pode dar errado dá errado, normalmente acaba sendo impossível acessá-lo ou repará-lo".
  • Estética. Não há dúvida nenhuma de que cada um de nós tem uma visão diferente e muito subjetiva do que é estética. Mesmo assim, a maioria de nós concordaria que uma entidade estética tem certa elegância. um fluir único e uma "presença" que são difíceis de quantificar, mas que, não obs­tante, são evidentes. Um software estético possui essas características.
  • Percepção. Em algumas situações, temos alguns preconceitos que in­fluenciarão nossa percepção de qualidade. Por exemplo, se for apresen­tado um produto de software construído por um fornecedor que, no pas­sado, havia produzido software de má qualidade, ficaremos com a nossa percepção de qualidade do produto de software influenciada negativa­mente. Similarmente, se um fornecedor tem uma excelente reputação, talvez percebamos qualidade, mesmo quando ela realmente não existe. As dimensões de qualidade de Garvin nos dão uma visão "indulgente" da qualidade de software. Muitas (mas não todas) dessas dimensões podem ser consideradas apenas subjetivamente. Por tal razão, também precisa­mos de um conjunto de fatores de qualidade que podem ser classificados em duas grandes categorias, (1) fatores que podem ser medidos diretamente (por exemplo. defeitos revelados durante testes) e (2) fatores que podem ser medi­dos apenas indiretamente (por exemplo, usabilidade ou facilidade de manu­tenção). Em cada um dos casos deve ocorrer medição. Devemos comparar o software com algum dado e chegarmos a uma indicação da qualidade.

Fatores de qualidade de McCall[editar | editar código-fonte]

McCall, Richards e Walters criaram uma proposta de categorização dos fatores que afetam a qualidade de software. Esses fatores de qualidade de software se concentram em três importantes aspectos de um produto de software: as características operacionais, a capaci­dade de suportar mudanças e a adaptabilidade a novos ambientes.

McCall e seus colegas fa­zem as seguintes descrições:

  • Correção. O quanto um programa satisfaz a sua especificação e atende aos objeti­vos da missão do cliente.
  • Confiabilidade. O quanto se pode esperar que um programa realize a função pre­tendida com a precisão exigida.
  • Eficiência. A quantidade de recursos computacionais e código exigidos por um programa para desempenhar sua função.
  • Integridade. O quanto o acesso ao software ou dados por pessoas não autorizadas pode ser controlado.
  • Usabilidade. Esforço necessário para aprender, operar, preparar a entrada de da­ dos e interpretar a saída de um programa.
  • Facilidade de manutenção. Esforço necessário para localizar e corrigir um erro em um programa. [Trata-se de uma definição muito limitada.]
  • Flexibilidade. Esforço necessário para modificar um programa em operação.
  • Testabilidade. Esforço necessário para testar um programa de modo a garantir que ele desempenhe a função pretendida.
  • Portabilidade. Esforço necessário para transferir o programa de um ambiente de hardware e/ou software para outro.
  • Reusabilidade. O quanto um programa [ou partes de um programa] pode ser reu­ tilizado em outras aplicações - relacionado com o empacotamento e o escopo das funções que o programa executa.
  • Interoperabilidade. Esforço necessário para integrar um sistema a outro.

É difícil - e, em alguns casos, impossível - desenvolver medidas diretas desses fatores de qualidade. Na realidade, muitas das métricas definidas por McCall e colegas podem ser medidas apenas indiretamente. Entretanto, ava­liar a qualidade de uma aplicação usando esses fatores possibilitará uma sóli­da indicação da qualidade de um software.

Fatores de qualidade ISO 9126[editar | editar código-fonte]

O padrão ISO 9126 foi desenvolvido como uma tentativa de identificar os atri­butos fundamentais de qualidade para software de computador. O padrão identifica seis atributos fundamentais de qualidade,

  • Funcionalidade. O grau com que o software satisfaz as necessidades de­claradas, conforme indicado pelos seguintes subatributos: adequabilida­de, exatidão, interoperabilidade, conformidade e segurança.
  • Confiabilidade. A quantidade de tempo por que o software fica disponível para uso, conforme indicado pelos seguintes subatributos: maturidade, tolerância a falhas, facilidade de recuperação.
  • Usabilidade. O grau de facilidade de utilização do software, conforme in­dicado pelos seguintes subatributos: facilidade de compreensão, facilida­de de aprendizagem, operabilidade. Eficiência. O grau de otimização do uso, pelo software, dos recursos do sistema, conforme indicado pelos seguintes subatributos: comportamento em relação ao tempo, comportamento em relação aos recursos.
  • Facilidade de manutenção. A facilidade com a qual uma correção pode ser realizada no software, conforme indicado pelos seguintes subatribu­tos: facilidade de análise, facilidade de realização de mudanças, estabili­dade, testabilidade.
  • Portabilidade. A facilidade com a qual um software pode ser transposto de um ambiente para outro, conforme indicado pelos seguintes subatri­butos: adaptabilidade, facilidade de instalação, conformidade, facilidade de substituição.

Assim como outros fatores de qualidade de software, os fatores da ISO 9126 não levam, necessariamente, à medição direta. Entretanto, eles fornecem uma base razoável para medidas indiretas e uma excelente lista de verificação para avaliar a qualidade de um sistema.