Qualidade, Qualidade de Software e Garantia da Qualidade de Software São as Mesmas Coisas ? | TestExpert
Início › Blogs › Blog de fabio_martinho Qualidade, Qualidade de Software e Garantia da Qualidade de Software São as Mesmas Coisas ? ter, 11/03/2008 - 13:37 — fabio_martinho
O termo TQM (Total Quality Management), amplamente usado nas organizações, também descreve uma abordagem para a melhoria da qualidade. De acordo com Kan (2002), "O termo tem tomado vários significados, dependendo de quem interpreta e como se aplica." (KAN, 2002, p. 30). Independente dos seus vários tipos de implementação, os elementos chave do TQM podem ser resumidos conforme Figura 1, abaixo:
Figura 1 - Elementos chave do TQM.
a) "O sistema de software deve fazer o que é suposto que se faça. Em outras palavras, eles devem fazer certo as coisas". (TIAN, 2005, p. 35)
b) "Eles devem realizar estas tarefas especificas corretamente e satisfatoriamente. Em outras palavras, eles devem fazer as coisas certas". (TIAN, 2005, p. 35)
- Tentar prevenir defeitos ao invés de consertá-los;
- Ter a certeza que os defeitos que foram encontrados, sejam corrigidos o mais rápido possível.
- Estabelecer e eliminar as causas, bem como os sintomas dos defeitos;
- Auditar o trabalho de acordo com padrões e procedimentos previamente estabelecidos.
Segundo ainda a NBR ISO 8402, o conceito de qualidade é "A totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas". As necessidades explícitas são aquelas expressas na definição formal de requisitos propostos pelo cliente. Esses requisitos definem as condições em que o produto ou serviço devem ser utilizados bem como seus objetivos, funções e o desempenho esperado. Já as necessidades implícitas são aquelas que, embora não expressas pelo cliente nos documentos de requisitos, são necessárias para o usuário. Estão incluídos nessas classes tanto os requisitos que não precisam ser declarados por serem óbvios como aqueles requisitos que não são percebidos como necessários no momento que o produto foi desenvolvido, mas que pela gravidade de suas conseqüências devem ser atendidos.
A qualidade, seja ela usada no contexto de software ou de produtos e serviços, hoje não mais é uma obrigação e um diferencial das empresas. A mesma se tornou um padrão em qualquer ramo de atividade e indústria sendo assim necessária para garantir a satisfação do cliente. Qualidade hoje em dia, não é apenas um diferencial de mercado para as empresas conseguirem vender e lucrar mais, é um pré-requisito que se deve conquistar para conseguir colocar o produto ou serviço no Mercado Global. De acordo com Jack Welch, "A qualidade é a nossa melhor garantia da fidelidade do cliente, a nossa mais forte defesa contra a competição estrangeira e o único caminho para o crescimento e para os lucros."
a) "Definir explicitamente o termo qualidade de software, quando o mesmo é dito";(PRESSMAN, 2005, p. 193)
b) "Criar um conjunto de atividades que irão ajudar a garantir que cada produto de trabalho da engenharia de software exiba alta qualidade"; (PRESSMAN, 2005, p. 193)
c) "Realizar atividades de segurança da qualidade em cada projeto de software";(PRESSMAN, 2005, p. 193)
d) "Usar métricas para desenvolver estratégias para a melhoria de processo de software e, como conseqüência, a qualidade no produto final"; (PRESSMAN, 2005, p. 193)
Uma possível definição mais abrangente e completa para qualidade de software seria a proposta por Bartié (2002): "Qualidade de software é um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos". (BARTIÉ, 2002, p. 16)
Figura 2 - Os Fatores da Qualidade de McCall.
Assim como o modelo proposto por McCall e Cavano (1978), "a Hewlett-Packard desenvolveu também um modelo que referencia fatores da qualidade de software e que primeiramente publicado por Grady and Caswell (1987), denominado FURPS: Functionality, Usability, Reliability, Performance e Supportability. Estes fatores estabelecem as métricas de qualidade de software para cada fase do processo de engenharia de software". (PRESSMAN, 2005, p. 539)
Além desse modelos de métricas para qualidade de software, nota-se que a constante busca pela mesma se tornou uma atividade essencial dentro das empresas. Colocando-se todos esses conceitos dentro do contexto apresentado, podemos dizer que "qualidade não é uma fase do ciclo de desenvolvimento de software ... é parte de todas as fases".(BARTIÉ, 2002, p. 16)
Segundo Lewis (2004), uma definição formal de Software Quality Assurance(SQA) é "atividades sistemáticas fornecendo evidências para o uso pretendido para o produto total de software".(LEWIS, 2004, p. 18)
Sendo assim, podemos ainda definir como Quality Assurance "o conjunto de atividades de apoio para fornecer confiança de que os processos estão estabelecidos e estão continuamente melhorados para produzir produtos que atendam as especificações e que sejam adequados para o uso pretendido".(LEWIS, 2004, p. 18)
Com isso, o SQA envolve todo o processo de desenvolvimento de software fazendo as devidas monitorações e melhorias de processos pertinentes, fazendo com que os padrões, procedimentos acordados estão sendo seguidos e garantindo que problemas são encontrados e ações corretivas são tomadas. Esse tipo de ação é orientada a prevenção. O IEEE 610.12-1990 cita qualidade de software como "(1) Um padrão planejado e sistemático de todas as ações necessárias para fornecer confiança adequada que um item ou produto está em conformidade com os requisitos técnicos estabelecidos. (2) Um conjunto de atividades projetadas para avaliar o processo pelo qual produtos são desenvolvidos ou manufaturados".
Figura 3 - Componentes do SQA.
a) Teste de Software (Software Testing): Conforme Lewis (2004), "É uma estratégia popular para o gerenciamento de risco". (LEWIS, 2004, p. 19)
O controle da qualidade consistem de checklists bem definidos em um produto que é especificado no plano de garantia da qualidade. Um exemplos clássico de controle da qualidade são as inspeções de software. A inspeção é o grau mais maduro e formal dentro das revisões, sendo necessária uma preparação prévia, participantes definidos adequadamente e critérios de entrado e saída bem definidos. O controle da qualidade é projetado para detectar defeitos e corrigir esses defeitos encontrados, enquanto que a garantida da qualidade é orientada através da prevenção de defeitos.
c) Gerenciamento de Configuração de Software (SCM - Software Configuration Management): O SCM é responsável por identificar, rastrear e controlar mudanças nos elementos do software de um sistema. O SCM controla a evolução do sistema de software , gerenciando versões dos componentes de software e seus relacionamentos. O propósito é identificar todos os componentes inter-relacionados do software e para controlar sua evolução através das várias fases no ciclo de vida de desenvolvimento de software.
Para que também toda essa estrutura esta devidamente documentada e aceita por todos os membros do time do projeto, é necessário um planejamento adequado. Esse planejamento é feito no Software Quality Assurance Plan ou Plano de Garantia da Qualidade de software. Segundo Lewis (2004), "O plano de garantia da qualidade de software é um resumo ou esboço das medidas de qualidade para garantir níveis de qualidade dentro do esforço do desenvolvimento de software".(LEWIS, 2004, p. 22)
O plano é usado como um baseline para comparar os níveis atuais de qualidade durante o desenvolvimento com os níveis planejados de qualidade. "O plano de SQA provê o framework e guias para o desenvolvimento de um código entendível e que seja de fácil manutenção"(LEWIS, 2004, p. 22).
A Tabela 1 - Diferenças entre Garantia da Qualidade e Controle da Qualidade mostra a diferença entre estas duas atividades:
1. As atividades de controle da qualidade focam na descoberta de defeitos em i específicos.
2. Um exemplo de controle da qualidade poderia ser: "Os requisitos definidos são os requisitos certos?".
3. Controle da qualidade é orientado a produto.
4. Controle da qualidade é orientado a detecção.
5. Inspeções e garantia de que o produto de trabalho atenda aos requisitos especificados.
6. As atividades são focadas no final das fases no ciclo de vida de desenvolvimento de software.
7. Controle da qualidade garante que os resultados do seu trabalho são os esperados conforme requisitos.
Figura 4 - SWEBOK - KA de Software Quality.
Segundo Bartié (2002), "Um dos maiores desafios a ser considerados é estabelecer um modelo de custos relacionados a implantação de um processo de garantia da qualidade de software." (BARTIÉ, 2002, p. 29)
Figura 5 - Modelo de Custo de Qualidade de Software.
- Revisões de requisitos;
- Revisões de Modelagem;
- Revisões de Planos de Teste;
- Inspeções de código;
- Testes de Software.
- Ferramentas de apoio ao processo de desenvolvimento;
- Definição de Políticas;
- Especificações e convenções;
- Planejamento do SQA;
- Relatórios de Qualidade para melhoria de processo.
- Re-reviões;
- Re-testes;
- Correções de código-fonte e documentação muito constantes;
- Redistribuição das versões do software;
- Atrasos no cronograma;
- Falhas na produção.
Com isso, "O modelo apresentado deverá ser associado a todas as atividades de um processo de engenharia de software. Em todos os projetos a serem construídos ou modificados, todas as atividades deveriam ter uma política de alocação de custos semelhante ao modelo apresentado." (BARTIÉ, 2002, p. 29)
Figura 6 - NBR ISO/IEC 9126-1 - Características da Qualidade de Software.
d) Eficiência(Rápido e "Enxuto"): É a capacidade do produto de software de prover performance apropriada, relativa ao conjunto de recursos usados quando o software está em uso dentro das condições especificadas.
a) ISO/IEC 9126-2 - Métricas Externas: Podem ser aplicadas para um produto não executável durante os estágios de desenvolvimento. Medem a qualidade de produtos intermediários e predizem a qualidade do produto final.
b) ISO/IEC 9126-3 - Métricas Internas: Utilizadas para medir a qualidade do software através do comportamento do sistema ou de parte dele. Só podem ser usadas durante a fase de testes do ciclo de vida e durante a operação do sistema.
c) ISO/IEC 9126-4 - Métricas da Qualidade do Uso: medem se o produto atende ou não as necessidades dos usuários, fazendo-os atingir seus objetivos com efetividade, produtividade, segurança e satisfação. Só podem ser usadas no ambiente real ou em uma aproximação do ambiente real.
Figura 7 - Gerenciamento da Qualidade do Projeto segundo o PMBOK do PMI.
De acordo com o PMBOK (2004), "Os processos de gerenciamento da qualidade do projeto incluem todas as atividades da organização executora que determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que o projeto atenda às necessidades que motivaram sua realização. Eles implementam o sistema de gerenciamento da qualidade através da política, dos procedimentos e dos processos de planejamento da qualidade, garantia da qualidade e controle da qualidade, com atividades de melhoria contínua dos processos conduzidas do início ao fim, conforme adequado". (PMI, 2004, p.179)
a) Planejamento da Qualidade: "Identificação dos padrões de qualidade relevantes para o projeto e determinação de como satisfazê-los." (PMI, 2004, p. 179)
b) Garantia da Qualidade: "Aplicação das atividades de qualidade planejadas e sistemáticas para garantir que o projeto emprega todos os processos necessários para atender aos requisitos.".(PMI, 2004, p. 179)
c) Controle da Qualidade: "Monitoramento de resultados específicos do projeto a fim de determinar se eles estão de acordo com os padrões relevantes de qualidade e identificação de maneiras de eliminar as causas de um desempenho insatisfatório." (PMI, 2004, p. 179)
Fábio Martinho Campos, CBTS® CST®
CBTS - Certified Brazilian Tester in Software
CST - Certified Software Testing
Especialista em Qualidade de Software e Testes de SI/Softwares
Software Quality and SI/Softwares Test Specialist Garantia de Qualidade
sex, 15/05/2009 - 16:19 — Celso Martins
Parabéns pelo artigo. Muito completo.
Eu tenho visto as pessoas não citarem a legibilidade (inclusive em algumas obras que já li) como um dos fatores da qualidade (eu costumo chamar de princípios). Eu acredito que este fator não possa ser derivado de nenhum dos outros. Também acredito que a sua importância seja inquestionável.
Será que estou enganado com relação a isso?
Tenho um blog onde estou falando de qualidade de software, mas em um contexto um pouco diferente do apresentado aqui.