A Importância do Controle da Qualidade na
Melhoria de Processos de Software
Ana Liddy Cenni de Castro Magalhães1 1SWQuality Consultoria e Sistemas
analiddy@swquality.com.br
Resumo. Este trabalho visa elucidar o conceito e a importância do controle
da qualidade em um programa de melhoria de processos, diferenciando-o das atividades de planejamento e garantia da qualidade, bem como destacar as situações no MR-MPS nas quais o controle da qualidade se mostra presente.
1. Introdução
Um dos grandes desafios para a Engenharia de Software tem sido desenvolver software de qualidade atendendo prazo, esforço e custos estabelecidos. Ao mesmo tempo em que requer software cada vez mais complexo, o mercado anseia por produtos de maior qualidade. Nesta direção, empresas desenvolvedoras de software têm se preocupado cada vez mais com a qualidade dos produtos de software que geram, sendo necessário criar mecanismos por meio dos quais a qualidade possa ser planejada, controlada, avaliada e alcançada. Uma vez que a qualidade do processo interfere significativamente na qualidade do produto resultante [1], torna-se necessário incluir, no processo de obtenção do produto, meios de se avaliar as características da qualidade dos produtos gerados ao longo do ciclo de desenvolvimento, em pontos selecionados do processo.
Este trabalho visa elucidar o conceito e a importância do controle da qualidade em uma organização, diferenciando-o das atividades de planejamento e garantia da qualidade, bem como destacar as situações no MR-MPS nas quais o controle da qualidade se mostra presente. Ele complementa um trabalho anterior, que discutiu a importância e a evolução da garantia da qualidade em uma organização, bem como o papel do SQA na institucionalização de processos [2]. A seção 2 apresenta a distinção entre os conceitos de planejamento, controle e garantia da qualidade. A seção 3 reforça a importância do controle e da garantia da qualidade em um projeto de software. A seção 4 descreve como o controle da qualidade participa dos processos do MR-MPS, considerando o caminho evolucionário da maturidade organizacional segundo os níveis de maturidade. A seção 5 tece algumas conclusões sobre o assunto.
2. As Diversas Interpretações da Qualidade nas Organizações
Segundo o IEEE, o termo "qualidade" pode ser entendido no contexto da Engenharia de Software como o grau no qual um sistema, componente ou processo satisfaz os requisitos especificados e as necessidades e expectativas do cliente/usuário [3]. Engloba tanto a qualidade do produto (conformidade com os requisitos) quanto a qualidade do processo (grau em que o processo garante a qualidade do produto). Sua definição e aplicação, porém, se modifica em função do domínio no qual é tratada. Por esta razão, não é fácil tratar todas as interpretações da qualidade, mesmo se restringindo ao domínio da engenharia de software.
Assegurar a qualidade do software resultante, porém, não é uma tarefa trivial, uma vez que produtos de software são geralmente complexos, possuem requisitos implícitos e muitas vezes ambíguos, utilizam representações variadas e inexatas (linguagens textuais, gráficas e de programação). Tais dificuldades podem acarretar a existência de requisitos incompletos, ausentes ou não testáveis, documentação incompleta ou inconsistente, identificação tardia de defeitos e o conseqüente volume de retrabalho e testes, prejudicando não só a qualidade do produto, mas também seu custo e prazo de entrega. Para que a qualidade seja mais que um mero acaso, torna-se necessário incorporar métodos que aumentem as chances de sucesso do produto e conceitos como "planejamento", "controle" e "garantia" da qualidade.
O "Planejamento da Qualidade" define as atividades de avaliação da qualidade que serão executadas ao longo do projeto, visando desenvolver produtos e processos para atender às necessidades dos clientes [4]. Inclui inicialmente entender essas necessidades, desenvolver características de produto a elas alinhadas e identificar processos e padrões capazes de produzi-las. Este planejamento inclui todas as atividades de avaliação da qualidade de um projeto, que por sua vez devem especificar não apenas “o que” será avaliado, mas também “quando”, “como” e “por quem”. Para concretizar o planejado, é necessário realizar atividades de "garantia" e de "controle" da qualidade.
A "Garantia da Qualidade" visa avaliar a aderência das atividades executadas e dos produtos de trabalho gerados a padrões, processos, procedimentos e requisitos estabelecidos e aplicáveis. Fornece uma visão objetiva e independente, tanto para atividades de processo quanto de produto, em relação a desvios e pontos de melhoria, de forma a assegurar que a qualidade planejada não será comprometida. Além de verificar se o processo está adequado, sendo seguido e trabalhando a favor da organização (evitando retrabalho, melhorando custos e prazos), busca-se identificar desvios o quanto antes e acompanhar a sua resolução até que sejam concluídos [5]. Ferramentas e técnicas utilizadas pela garantia da qualidade incluem auditorias (de produtos ou processos) e avaliações (appraisals ou assessments) [5].
Apesar de não possuir atualmente um significado padrão para a engenharia de software [3], o "Controle da Qualidade" pode ser entendido como um método iterativo de comparação do produto em construção com os seus requisitos e tomada de ações caso existam diferenças. Visa verificar a qualidade dos produtos de trabalho gerados durante o ciclo de vida (intermediários e finais), determinando se estes estão dentro de níveis de tolerância aceitáveis [5]. Ferramentas e técnicas usadas para o controle da qualidade incluem revisões por pares (inspeção e walkthrough) e diferentes níveis e tipos de teste, que são estabelecidos pelos processos Verificação e Validação [5]. Um conjunto bem definido de atividades de controle da qualidade fornece consistência e força aos esforços em busca de produtos com maior qualidade.
A distinção correta entre estes termos é importante para auxiliar as organizações na determinação do conteúdo e direcionamento de seus programas de melhoria. Apesar de possuírem propósitos distintos, muitas pessoas e organizações de software confundem e empregam erroneamente estes conceitos – por exemplo, possuem áreas denominadas “garantia da qualidade” que realizam basicamente testes em seus produtos de software. Visando elucidar estes dois conceitos, a Tabela 1 apresenta as principais diferenças entre “garantia” e “controle” da qualidade.
Tabela 1 – Diferenças entre “garantia” e “controle” da qualidade
Garantia da Qualidade Controle da Qualidade
• Foco: garantir que o projeto emprega todos os processos e padrões necessários para atender aos requisitos
• Forma mais usual: auditorias de processo e de produto, orientadas por check-lists
• Utiliza métodos, procedimentos e padrões para comparar previsto com realizado
• Assegura que o processo empregado é definido e apropriado
• É orientada a processo, visando à prevenção de defeitos
• Cuida da monitoração e melhoria dos processos e padrões empregados
• Assegura que se faz da maneira correta (diz o que faz e faz o que diz)
• Foco: descobrir defeitos em produtos de trabalho gerados ao longo do projeto e eliminar suas causas
• Forma mais usual: testes diversos e revisões por pares (simples, inspeção, walkthrough)
• Utiliza casos de teste, check-lists e revisões para comparar o esperado com o obtido
• Assegura que os produtos de trabalho gerados estão consistentes e alinhados
• É orientado a produto, visando à detecção e correção de defeitos
• Cuida da monitoração e da consistência dos produtos em relação aos requisitos e à utilização • Assegura que se faz as coisas certas (faz certo o
que atende a necessidades e uso pretendido)
A garantia da qualidade fornece suporte ao controle da qualidade por meio de evidência e confiança na habilidade do processo empregado em produzir um produto de software que atenda aos requisitos especificados [1]. Desta forma, a realização de testes é parte do processo de controle da qualidade, enquanto a verificação da aderência ao processo documentado de teste é de responsabilidade da garantia da qualidade.
3. Importância do Controle e da Garantia da Qualidade de Software
A obtenção de um software de qualidade não é uma tarefa simples, necessitando de uma série de cuidados. Inicialmente, deve-se identificar o que é considerado “qualidade” no âmbito do produto de software em questão. Pela dificuldade de se atender diversas características de qualidade simultaneamente, torna-se necessário priorizar aquelas que irão determinar a qualidade do produto, o que faz parte do planejamento da qualidade. Para se obter um software que atenda a qualidade planejada, deve-se avaliar não apenas o produto final, mas acompanhar todo o processo utilizado em sua obtenção, além dos produtos intermediários gerados ao longo deste processo.
Cada etapa do ciclo de vida do produto pode acabar introduzindo erros. Como ilustrado na Figura 1, um conjunto inicial de requisitos poderá possuir parte correta e parte com algum tipo de defeito (inconsistência, ambigüidade, etc). Ao passar para a fase de projeto, além de eventuais problemas inerentes a esta fase que poderão desencadear um projeto defeituoso, erros advindos da fase anterior podem ser não só transmitidos para esta fase, mas também amplificados. Se nada for feito, a ocorrência sucessiva desta situação nas diversas fases de desenvolvimento do produto pode acabar comprometendo em muito a qualidade do produto resultante.
Torna-se necessário, portanto, seguir processos que possibilitem melhorar a qualidade dentro das restrições de imperfeição impostas. Neste contexto, a realização em cada fase de revisões e/ou testes – atividades relacionadas ao controle da qualidade – e de auditorias que verifiquem objetivamente a aderência de produtos e atividades a padrões e processos definidos – atividades relacionadas à garantia da qualidade – constituem um meio efetivo de se aperfeiçoar a qualidade do produto resultante.
Figura 1 - A inevitável introdução de erros ao longo do ciclo de vida
Auditorias, revisões e testes constituem “filtros” aplicados ao processo, detectando erros e evitando sua propagação, como ilustrado na Figura 2. À primeira vista, eles podem parecer retardar o fluxo de desenvolvimento, porém na realidade eles removem problemas que precisam ser tratados, que só seriam evidenciados mais adiante e poderiam ser amplificados. Da mesma forma que ocorre com o processo de filtragem, auditorias, revisões e testes superficiais podem não ser eficientes, porém se realizados em excesso podem travar o processo, sendo necessário buscar um ponto de equilíbrio.
Figura 2 – Auditorias, revisões e testes atuam como filtro de defeitos nos projetos
Em suma, a garantia e o controle da qualidade aplicados em cada fase embutem mecanismos que possibilitam identificar e tratar mais cedo os defeitos inseridos ao longo do ciclo de vida, bem como reduzir o número de defeitos amplificados, colaborando efetivamente para a obtenção de um produto com maior qualidade. Quanto mais cedo um defeito for encontrado, mais fácil e menos dispendioso será corrigi-lo. Detalhes relacionados ao estabelecimento e à evolução da garantia da qualidade em uma organização podem ser obtidos em [2], e ao controle da qualidade na seção 4 a seguir.
4. Estabelecendo e Evoluindo o Controle da Qualidade em uma Organização
É importante notar que as atividades de controle da qualidade evoluem junto com a organização, de forma acumulativa, paralelamente ao seu amadurecimento. Em uma organização imatura, que ainda não despertou para a necessidade de definir e cuidar de seus processos produtivos, o comprometimento e a responsabilidade pelo controle da qualidade constituem um desafio pessoal. Neste estágio, testes e revisões de software, quando existentes, são realizados sem planejamento e de forma ad hoc.
Em estágios iniciais de maturidade, em geral a mesma equipe que constrói o produto realiza também o controle da qualidade. Idealmente, porém, uma equipe de controle da qualidade bem estruturada deve ter independência e autonomia: ser uma equipe separada, com livre acesso à gerência sênior e possuir processos, laboratórios e ferramentas próprias. Esta equipe deve executar seu trabalho com transparência e ser treinada não só nas ferramentas e procedimentos de revisão, inspeção e testes, mas também nas tecnologias aplicadas no desenvolvimento dos produtos.
Além das ferramentas para a realização das atividades de revisão, inspeção e testes, o controle da qualidade deve contar com uma ferramenta para acompanhamento e controle de defeitos e problemas detectados, mais conhecida como ferramenta de bug
tracking, de forma a possibilitar seu registro, monitoramento e efetivo tratamento.
4.1. O Controle da Qualidade e as Atividades de Nível G
O Nível G dá início ao amadurecimento organizacional, disciplinando atividades de Gerência de Projetos no tocante a esforço, custos, cronograma, equipe, dados e riscos, entre outros. O ciclo de vida escolhido deve ser capaz de gerar os produtos de trabalho especificados, porém sem nenhum controle formal da qualidade, apesar de em geral incluir atividades básicas de teste do produto em construção. Estas atividades devem ser estimadas e integradas ao plano do projeto, que é revisado por todos os interessados e utilizado ao longo do projeto como referência para acompanhamento das atividades.
Paralelamente, na Gerência de Requisitos, o entendimento obtido junto a fornecedores autorizados de requisitos é transformado em requisitos de software. Estes devem ser aprovados segundo critérios objetivos (ex: ser claro, consistente, completo, implementável, testável e rastreável). Além disso, planos e produtos de trabalho gerados devem ser revisados visando identificar e corrigir inconsistências em relação aos requisitos, o que também pode ser entendido como uma ação de controle de qualidade. 4.2. O Controle da Qualidade e as Atividades de Nível F
O Nível F implementa a Garantia da Qualidade, assegurando a aderência das atividades realizadas ao processo documentado, bem como a conformidade dos produtos de trabalho gerados aos padrões, procedimentos e requisitos aplicáveis, o que fornece ao controle da qualidade evidência e confiança na habilidade do processo utilizado em gerar um produto que atenda aos requisitos definidos.
No âmbito da Gerência de Configuração, o controle da qualidade do produto está presente na avaliação e revisão da configuração, por meio das auditorias de baselines, que incluem a verificação funcional (se correta) e física (se completa). Todos os problemas detectados em uma auditoria de configuração devem ser tratados como itens de ação da auditoria e acompanhados até a sua efetiva conclusão.
O Nível F introduz também atividades de Medição, que geram uma base de dados objetiva para avaliação das atividades e do andamento do projeto como um todo, propiciando maior visibilidade e permitindo avaliar tendências da qualidade nos processos, nos projetos e na organização.
Na Aquisição de produtos e serviços de software, o controle da qualidade atua por meio de revisões e testes, que devem estar alinhados aos critérios de aceitação do produto a ser adquirido segundo a estratégia de aquisição definida. Em geral, um plano de aquisição é definido, incluindo testes de aceitação e, quando aplicável, testes de integração do produto adquirido ao projeto, treinamentos e suporte. Este plano deve ser revisado e aprovado pelos principais envolvidos, bem como seguido ao longo de toda a aquisição. Quando o produto é disponibilizado, os testes devem ser conduzidos e seus resultados registrados e relatados. Caso necessário, um plano de ação é estabelecido para tratar pendências na aceitação, visando a garantir o encerramento da aquisição. 4.3. O Controle da Qualidade e as Atividades de Nível E
No Nível E, a organização amplia sua estruturação. Está mais voltada para a integração de seus processos em um processo padrão, a ser adaptado para um projeto segundo critérios objetivos. Além de realizar avaliações de processo, a garantia da qualidade assegura que todos usam o que está definido e colaboram para a sua evolução.
Atividades de controle da qualidade ocorrem apenas para credenciar ativos de processo como integrantes da biblioteca de ativos reutilizáveis da organização. No caso do ativo ser um componente de software executável, um dos critérios de aceitação utilizados é sua aprovação após execução de planos de teste. Demais ativos são avaliados segundo um conjunto de atributos que, em geral, incluem seu propósito e alinhamento com o domínio no qual a organização atua.
Para se obter um tratamento adequado do controle da qualidade, é necessário treinar as pessoas para a execução correta de suas atividades, o que está relacionado ao processo de Gerência de Recursos Humanos. Além disso, a eficácia do próprio treinamento deve ser verificada, o que pode ser realizado de diferentes formas, como testes pré e pós-treinamento, auto-avaliação dos participantes e/ou avaliação ao final do projeto para verificar se os conhecimentos adquiridos foram entendidos e utilizados. 4.4. O Controle da Qualidade e as Atividades de Nível D
À medida que a maturidade aumenta, atividades de planejamento, garantia e controle da qualidade vão sendo formalizadas, até que, no Nível D, as principais atividades de controle da qualidade passam a ser cobertas por Planos de Verificação e Validação que, integrados ao Plano de Projeto e ao Plano de Garantia da Qualidade, consolidam as ações cruciais para se obter um produto com qualidade, atendendo satisfatoriamente aos requisitos de cliente e usuários.
O foco principal do controle da qualidade está nos processos de Verificação e Validação. Todos os resultados esperados destes processos estão diretamente relacionados ao controle da qualidade e atuam sobre os produtos de trabalho gerados pelos outros processos durante o projeto, segundo estratégias de verificação e validação definidas e implementadas. Estas estratégias estabelecem cronogramas, envolvidos, recursos e métodos a serem utilizados, que incluem abordagens de teste (funcional/ estrutural), estágios de teste (de unidade, módulo, sistema, aceitação) e tipos de teste (de
interface, aderência ao conteúdo, segurança, robustez, desempenho, stress, entre outros), bem como as ferramentas a serem utilizadas (para geração de massa de dados, inspeção de código, análise de memory leaks, bug-tracking e testes diversos).
Além das abordagens relacionadas a testes, a Verificação inclui também revisões por pares (peer reviews), nas quais um grupo preferencialmente independente de pessoas com perfil técnico semelhante ao de quem desenvolveu o material alvo da revisão (“pares”) avaliam produtos de trabalho visando assegurar que estejam completos e prontos para a próxima atividade planejada. Também verificam se eventuais alterações foram implementadas adequadamente e só afetaram partes anteriormente identificadas.
Dentre os tipos mais comuns de revisões por pares destacam-se a inspeção e o
walkthrough. As inspeções são revisões orientadas por check-list de possíveis defeitos,
sendo mais comuns as realizadas em projetos (desenhos) e programas (código). O
walkthrough é uma revisão de apresentação, realizada em forma de reunião e sem check-list, na qual o autor apresenta o material em ordem lógica a um grupo, que o
verifica durante a apresentação. A revisão por pares também pode ser implementada por uma revisão simples, realizada por uma única pessoa, desde que esta seja um “par” do autor e que critérios objetivos sejam empregados [6].
A validação de um software desenvolvido sob medida para um cliente específico é realizada a partir de uma série de testes de aceitação, sempre conduzidos com a participação do cliente, que avalia o sistema construído em relação ao uso pretendido. Sua realização pode variar de dias a meses. Quando o software obtido é um produto para ser usado por diversos clientes, geralmente a estratégia empregada é a de se realizar testes alfa e beta. Vale ressaltar que a realização de testes de verificação e validação são complementares, pois ambos possuem natureza e objetivos distintos, fortalecendo o processo de detecção de erros e aumentando a qualidade final do produto [6].
O controle da qualidade no processo Desenvolvimento de Requisitos se faz presente na revisão dos requisitos obtidos, geralmente executada por pares ao final da análise, visando garantir que estes são necessários, corretos, testáveis e suficientes.
O controle da qualidade ocorre no Projeto e Construção do Produto pela verificação dos componentes do produto desenvolvidos e de sua documentação associada segundo o que foi especificado no projeto, o que pode ser realizado por meio de revisão por pares e/ou testes. Apesar de não estar explícito na documentação do MR-MPS, também seria interessante aplicar o controle da qualidade na seleção da alternativa de solução a partir de critérios de qualidade associados, bem como na revisão da documentação de projeto dos componentes de produto e suas interfaces.
No caso da Integração de Produto, o controle da qualidade acontece não só na verificação e validação de cada componente de produto, mas também ao assegurar a compatibilidade das interfaces entre componentes de produto a serem integrados e na avaliação dos resultados desta integração. Após o teste de integração, outros tipos de teste podem ser realizados, como teste funcional, de desempenho, de aceitação e de instalação. Além disso, uma estratégia de regressão deve ser desenvolvida e aplicada para uma nova verificação do produto caso ocorra mudança em seus componentes, seja nos requisitos, projeto ou códigos associados. A identificação dos itens associados à mudança pode ser realizada pelo mecanismo de rastreabilidade gerado desde o Nível G.
4.5. O Controle da Qualidade e as Atividades de Nível C
No Nível C, o controle da qualidade se faz presente no processo Desenvolvimento para Reutilização pelo apoio fornecido na revisão dos ativos de domínio. Uma vez desenvolvidos ou adquiridos no mercado, os ativos de domínio devem ser verificados e disponibilizados em uma biblioteca de ativos reutilizáveis.
No tocante à Gerência de Riscos, partindo do ponto de vista de Lewis que afirma que o teste de software “é uma estratégia popular para o gerenciamento de risco” [7], o controle da qualidade pode ser visto como uma forma de se mitigar riscos em projetos. 4.6. O Controle da Qualidade nas Atividades de Níveis B e A
No Nível B, o controle da qualidade passa também a ser responsável por gerenciar quantitativamente os sub-processos selecionados, de forma a mantê-los sob controle estatístico. Ao detectar problemas e/ou resultados insatisfatórios, cabe ao controle da qualidade atuar na identificação, eliminação e bloqueio de sua causa fundamental [4].
No Nível A, a Análise de Causas de Problemas e Resolução apóia o controle da qualidade na identificação e tratamento de questões relacionadas à estabilidade dos pro-cessos, que dificultam alcançar objetivos de qualidade e desempenho estabelecidos [8].
Inovações podem ser selecionadas para resolver problemas específicos nos processos e colaborar para a obtenção de um maior controle da qualidade. No entanto, devem ser introduzidas com cautela, a fim de se evitar efeitos colaterais [8].
5. Conclusão
De uma maneira geral, o controle da qualidade visa assegurar que o software representa o que foi especificado e projetado e atende às necessidades dos clientes. Caso existam problemas (defeitos, inconsistências), estes devem ser identificados, registrados e tratados. Estas atividades devem ser contempladas em todo o ciclo de vida do software.
O controle da qualidade de software não é uma tarefa simples, uma vez que englobaváriasatividadesaolongo do projeto, emprega técnicas e ferramentas específicas eprecisaestar integrado ao planejamento e acompanhamento ao longo de todo o projeto. Os benefícios obtidos com sua realização efetiva podem ser percebidos rapidamente, desde a identificação de oportunidades de melhoria no processo de desenvolvimento até a satisfação de poder contar com um produto confiável e com baixo índice de manutenção corretiva.
Referências
[1] Rocha, Ana Regina, Maldonado, José, Weber, Kival. “Qualidade de Software: teoria e prática”. Prentice Hall, 2001.
[2] Magalhães, Ana Liddy. “A Garantia da Qualidade e o SQA: Sujeito Que Ajuda e Sujeito Que Atrapalha”. Revista Proqualiti, v.2, n.2, nov/2006.
[3] IEEE. “Standard Glossary of Software Engineering Terminology”, Document Number: IEEE 610.12-1990. Institute of Electrical and Electronics Engineers, May/1990.
[4] INDG. Glossário do Instituto de Desenvolvimento Gerencial. Disponível em http://www.indg.com.br/info/glossario, setembro/2008.
[5] Kasse, Tim. “Practical Insight into CMMI”. Artech House Computing Library, 2004. [6] Softex. “MPS.BR - Guia de Implementação - Parte 4, Nível D”, v. 1.1, 2007.
[7] Lewis, William.“SoftwareTestingandContinuousQuality Improvement”,Auerbach, 2005. [8] Softex. “MPS.BR - Guia de Implementação - Parte 7, Nível A”, v. 1.0, 2007.
