Você está na página 1de 11

Visão Geral da Qualidade de Software

Glauber da Rocha Balthazar

Faculdade Metodista Granbery (FMG)


Bacharel em Sistemas de Informação
Rua Batista de Oliveira, 1145 - 36010-532 - Juiz de Fora - MG
glauber_rochab@yahoo.com.br

Abstract. The objective of this work is present a general view about software
quality basing on the described concepts for the Engineering of Software, through
two matures model witch guide how to reach software quality that are Norm NBR
ISO/IEC 9126, in your first part and the CMM (Capability Maturity Model)
model.
Resumo. O objetivo deste trabalho é apresentar uma visão geral da qualidade de
software, baseando-se nos conceitos descritos pela Engenharia de Software, por
meio de dois modelos maduros que orientam como atingir qualidade em software
que são a Norma NBR ISO/IEC 9126, em sua primeira parte e o modelo CMMI
(Capability Maturity Model Integration).

1. Introdução
A preocupação da produção de um software de qualidade não se restringe apenas a atingir
os objetivos (ou requisitos) esperados pelos usuários, mas também em obter um ciclo de
vida de produção de software que apresente as características desejáveis em qualquer
processo de desenvolvimento de software, como boa manutenibilidade, alta reusabilidade e
baixo acoplamento.
A indústria japonesa foi a precursora do Controle de Qualidade Total (TQC – Total
Quality Control), seguida pelos americanos, que definiram o modelo de Gerência da
Qualidade Total (Total Quality Management) (VASCONCELOS, 2006).
O Controle de Qualidade Total Japonesa tem seis características bastante
interessantes, que foi exportada para o ocidente, como: controle de qualidade em toda a
empresa com a participação de todos os membros da organização; educação e treinamento
em controle de qualidade; atividades do círculo de controle de qualidade; auditorias;
utilização de métodos estatísticos e atividades de promoção do controle de qualidade em
toda a nação (ISHIKAWA, 1993).
Ishikawa (1993) afirma que “o Controle de Qualidade é uma revolução do
pensamento administrativo, portanto os processos de pensamento precisam ser

Revista Eletrônica da Faculdade Metodista Granbery - http://re.granbery.edu.br - ISSN 1981 0377


Faculdade de Sistemas de Informação - N. 3, JUL/DEZ 2007
modificados”. Dessa forma, todos são envolvidos nesse processo, desde a gerência e
diretorias até os funcionários de produção. A educação é um fator fundamental nesse
processo; todos realizam cursos de capacitações e treinamentos. Tudo com o objetivo de
mostrar, para todos os envolvidos, a importância de se ter qualidade no processo de
construção de qualquer produto.
Baseado nessas preocupações, este artigo apresenta uma visão geral do que é
qualidade e como este conceito é aplicado na produção de software.
Assim, no segundo capítulo é apresentada uma definição do que é qualidade, sua
história nas organizações; além da sua importância e como a Engenharia de Software trata
deste assunto, não somente no produto software, mas no ciclo de vida de um software. No
terceiro capítulo, são apresentados os requisitos de qualidade de um software baseando-se
nos requisitos descritos na Engenharia de Software como Funcionais e Não Funcionais de
acordo com a Norma NBR ISO/IEC 9126. No quarto capítulo é apresentada uma visão
geral da importância de como tratar qualidade no ciclo de vida com um foco nos produtos e
processos, com o objetivo de visualizar o efeito requerido do produto em um contexto de
uso particular. Em seguida, no quinto capítulo, são apresentados dois modelos que definem
qualidade de software. O sexto capítulo é composto por um resumo das principais
características da Norma ISO 9126 em sua primeira parte (Modelo de qualidade) que
mostra as principais características desejáveis em termos de qualidade para um software.
No sétimo capítulo, é apresentado um resumo do modelo CMMI (Capability Maturity
Model Integration) que categoriza as organizações em cinco níveis de maturidade por meio
de áreas-chaves. Por fim, é realizada uma conclusão no oitavo capítulo, com o objetivo de
descrever a importância da preocupação em se ter qualidade na produção de software.

2. O que é qualidade?
Qualidade, palavra derivada do Latim (qualitate), significa aquilo que caracteriza uma
pessoa ou coisa e que a distingue das outras (FERREIRA, 2004).
Para o mercado e a indústria, o conceito de qualidade foi primeiramente associado à
definição de conformidade às especificações de um padrão esperado na construção de um
objeto ou na prestação de um serviço. Posteriormente o conceito evoluiu para a visão de
Satisfação do Cliente (GARVIN, 2002). Vasconcelos (2006) complementa afirmando que
em geral, este conceito está relacionado a uma série de aspectos, tais como normalização e
melhoria de processo, medições, padrões e verificações.
Dessa forma, a Norma NBR ISO 8402 - Gestão da qualidade e garantia da qualidade
- definiu qualidade como a totalidade das características de uma entidade que lhe confere a
capacidade de satisfazer às necessidades explícitas e implícitas.
Para a Engenharia de Software, este conceito não é aplicado apenas nas
funcionalidades esperadas de um sistema, mas também às fases do ciclo de vida desde a sua
concepção, elaboração, implementação e teste do produto produzido.
Pressman (2002) afirma que o controle de qualidade de software é um conjunto
complexo de fatores que podem variar de acordo com as diferentes aplicações e de acordo
com os utilizadores que o requisitam.

3. Requisitos de software
Requisito é descrito como uma condição ou capacidade necessitada por um usuário para
resolver um problema ou alcançar um objetivo, ou seja, é uma condição necessária para a
obtenção de certo objetivo, ou para o preenchimento de certo fim. Em um software,
requisito é o que o sistema tem que ter para atender plenamente ao propósito para o qual foi
criado (FERNANDES, 2005).
Procurando garantir a especificação de requisitos de um sistema que atenda
adequadamente às necessidades e satisfaça às expectativas dos clientes, a engenharia de
requisitos fornece um mecanismo adequado para atender o que é esperado (PRESSMAN,
2005).
Dessa forma, os requisitos de um software são divididos em dois grandes grupos:
requisitos funcionais e requisitos não funcionais.
Sommervile (2003) define os requisitos não funcionais como sendo restrições sobre
os serviços ou as funções oferecidos pelo sistema. Entre eles dessacam-se restrições de
tempo, restrições sobre o processo de desenvolvimento, padrões, entre outros.
Ainda, a Norma NBR ISO/IEC 9126, descreve os requisitos não funcionais como a
qualidade de produto de um software.
Pressman (2002) descreve os requisitos funcionais como sendo declarações de
funções que o sistema deve fornecer; como o sistema deve reagir a entradas específicas e
como deve se comportar em determinadas situações. Em alguns casos, os requisitos
funcionais podem também explicitamente declarar o que o sistema não deve fazer.

4. Ciclo de vida (produto e processos)


As necessidades de qualidade do usuário incluem requisitos de qualidade de uso em
contextos de uso específicos que podem ser usados na especificação da qualidade interna e
externa, aplicando características e subcaracterísticas de qualidade do produto de software
com a intenção de satisfazer as necessidades de qualidade nos processos do ciclo de vida de
desenvolvimento de software. Dessa forma, pode-se avaliar estas características medindo-
se os atributos internos, os atributos externos ou os atributos de qualidade em uso. O
objetivo é que o produto tenha o efeito requerido num contexto de uso particular que é
mostrado na Figura 1 (Norma NBR ISO/IEC 9126-1:2003).

Figura 1 – Qualidade no ciclo de vida (Fonte: Norma NBR ISO/IEC 9126-1:2003)

A qualidade de processo contribui para melhorar a qualidade do produto e a


qualidade do produto contribui para melhorar a qualidade em uso. Por isso, avaliar e
melhorar o processo é um meio de melhorar a qualidade do produto, assim como avaliar e
melhorar a qualidade do produto é um meio de melhorar a qualidade em uso (Norma NBR
ISO/IEC 9126-1:2003).

5. Garantia da Qualidade de Software


Garantia da qualidade é um conjunto de atividades planejadas e sistemáticas,
implementadas com base no sistema da qualidade da organização, a fim de prover a
confiança de que o projeto irá satisfazer padrões relevantes de qualidade (SQUARE, 2000).
As atividades de garantia da qualidade de software são focadas na prevenção de defeitos e
problemas, que podem surgir nos produtos de trabalho. Definição de padrões,
metodologias, técnicas e ferramentas de apoio ao desenvolvimento fazem parte deste
contexto (VASCONCELOS, 2006).
Assim, Garantia da Qualidade consiste nas funções gerenciais de auditar e relatar. A
meta é fornecer à gerencia os dados necessários para que fique informada sobre a qualidade
do produto, ganhando assim compreensão e confiança de que a qualidade do produto está
satisfazendo suas metas (PRESSMAN, 2002).
Para isso um grupo de SQA (Software Quality Assurance) é montado com a missão
de ajudar a equipe de software a conseguir um produto final de alta qualidade baseando-se
em um conjunto de atividades. Pressman (2002) apresenta estas atividades como sendo:

• preparar um plano SQA para um projeto;


• participar no desenvolvimento da descrição do processo de software do projeto;
• rever as atividades de engenharia de software para verificar a satisfação do
processo;
• auditar os produtos do trabalho de software encomendado para verificar a satisfação
do que foi definido como parte do processo de software;
• garantir que os desvios do trabalho de software e dos produtos do trabalho venham a
ser documentados e manipulados de acordo com um procedimento documentado; e
• registrar qualquer eventual não satisfação e a relatar à gerência superior.

Dessa forma consegue-se manter um gerenciamento das atividades que garantem e


asseguram a Qualidade de Software no produto que está sendo construído.

6. Norma ISO 9126 – parte 1 Modelo de qualidade


A preocupação em desenvolver ou selecionar produtos de software de alta qualidade leva a
uma especificação e avaliação da qualidade do produto cujos fatores chaves são utilizados
para garantir uma qualidade adequada. Isto pode ser alcançado pela definição apropriada
das características de qualidade, levando em consideração o uso pretendido do produto de
software.
Dessa forma, a Norma NBR 13596 – Tecnologia da Informação – Avaliação de
produto de software – Características de qualidade e diretrizes para seu uso, reúne as
principais características de qualidade e descreve um modelo de processo para avaliação de
produto de software.
Porém, como estas características podem ser úteis não só à avaliação de produto de
software, mas também para a definição de requisitos de qualidade e outros usos, esta norma
está sendo substituída pela NBR ISO/IEC 9126.
A Norma NBR ISO/IEC 9126 é uma revisão da Norma NBR 13596 e mantém as
mesmas características de qualidade de software. As diferenças são:

• inclusão de subcaracterísticas em caráter normativo, baseadas, em sua maioria, no


anexo informativo da NBR 13596, que contém as subcaracterísticas de qualidade;
• especificação de um modelo de qualidade;
• introdução de qualidade de uso;
• remoção do processo de avaliação; e
• coordenação de seu conteúdo com a NBR ISO/IEC 14598-1.

Assim, esta Norma, em sua primeira parte, descreve um modelo de qualidade do


produto de software, composto por duas partes: qualidade interna e externa e qualidade de
uso. Abaixo, têm-se uma descrição das duas na Tabela 1.

Tipo de Qualidade Descrição


Qualidade Interna e Externa Especifica seis características para qualidade interna e
externa, as quais por sua vez são subdivididas em
subcaracterísticas que são manifestadas externamente,
quando o software é utilizado como parte de um sistema
computacional, e são resultantes de atributos internos do
software.
Qualidade de uso Especifica quatro características de qualidade em uso,
mas não apresenta o modelo de qualidade em uso além
do nível de característica, que é para o usuário, o efeito
combinado das seis características de qualidade do
produto de software.
Tabela 1 – Partes do modelo de qualidade do produto de software da Norma NBR ISO/IEC
9126

A tabela 2 apresenta as seis características definidas na Qualidade Interna e Externa.


Estas características estão relacionadas diretamente com os requisitos não funcionais
esperados de um software. Também é mostrado, respectivamente, as subcaracterísticas de
cada uma característica.

Características Subcaracterísticas
Funcionalidade: como as funções e Adequação: existência de um conjunto de
propriedades específicas do produto, funções apropriadas para as tarefas
satisfazem as necessidades do usuário. requeridas;
Acurácia: produção de resultados ou efeitos
corretos;
Interoperabilidade: habilidade de
interação do produto de software com
outros produtos;
Conformidade: o produto está de acordo
com as convenções, as normas ou os
regulamentos estabelecidos; e
Segurança: aptidão para evitar acessos não
autorizados a programas e dados.
Confiabilidade: como o produto de Maturidade: estado de maturação do
software é capaz de manter seu nível de software, detectada por sua baixa freqüência
desempenho, ao longo do tempo, nas de falhas;
condições estabelecidas. Tolerância a falhas: o nível de
desempenho é mantido, quando ocorrem
falhas; e
Recuperabilidade: existem mecanismos
que restabelecem e restauram os dados após
a ocorrência de falhas.
Usabilidade: o esforço necessário para a Inteligibilidade: facilidade de
utilização do sistema, baseado em um entendimento dos conceitos utilizados no
conjunto de implicações e de condições do produto de software;
usuário. Apreensibilidade: facilidade de
aprendizado do software; e
Operacionalidade: faculdade de operar e
controlar operações pertinentes ao software.
Eficiência: como os recursos e os tempos Comportamento no tempo: refere-se ao
envolvidos são compatíveis com o nível de tempo de resposta de Processamento; e
desempenho requerido pelo software. Comportamento dos recursos: relaciona-
se com a quantidade dos recursos
empregados.
Manutenibilidade: refere-se ao esforço Analisabilidade: característica de ser
necessário para a realização de alterações possível diagnosticar deficiências e causas
específicas, no produto de software. de falhas;
Modificabilidade: característica que o
produto deve ter de forma a facilitar
modificações e remoções de defeitos;
Estabilidade: ausência de riscos ou
ocorrências de defeitos inesperados no
software; e
Testabilidade: facilidade de o produto ser
testado.
Portabilidade: facilidade de o software Adaptabilidade: faculdade de o produto
poder ser transferido de um ambiente para poder ser adaptado a novos ambientes;
outro. Instalabilidade: facilidade de instalação do
produto de Software Conformidade com
padrões;
Portatilidade: o produto está segundo os
padrões ou convenções de portatilidade; e
Substituibilidade: o produto de software
pode ser substituído por outro, sem grandes
esforços.
Tabela 2 – Características da Qualidade Interna e Externa

A tabela 3 apresenta as quatro características definidas na Qualidade de uso.

Características
Eficácia: capacidade do produto de software de permitir que seus usuários atinjam metas
especificadas com acurácia e completitude, em um contexto de uso especificado.
Produtividade: capacidade do produto de software de permitir que seus usuários
empreguem quantidade apropriada de recursos em relação à eficácia obtida, em um
contexto de uso especificado.
Segurança: capacidade do produto de software de apresentar níveis aceitáveis de riscos de
danos a pessoas, negócios, software, propriedades ou ao ambiente, em um contexto de uso
especificado.
Satisfação: capacidade do produto de satisfazer usuários, em um contexto de uso
especificado.
Tabela 3 – Características da Qualidade de uso

Dessa forma, esta norma apresenta as principais características esperadas, em


termos de qualidade, para um software.

7. Modelo CMMI (Capability Maturity Model Integration)


O modelo CMM (CMM - Capability Maturity Model) dessaca-se porque tem sido
largamente adotado pela comunidade de software internacional. Este modelo é focado na
capacidade organizacional. Assim, ele categoriza as organizações em cinco níveis de
maturidade, desde um processo ad hoc e desorganizado (nível 1), até um estágio altamente
gerenciado de melhoria contínua (nível 5). Esses níveis de maturidade são definidos em
áreas-chave de processo, que por sua vez, possuem metas que devem ser atingidas por meio
da implementação de práticas-chaves, categorizadas no que o modelo chama de
características comuns (VASCONCELOS, 2006).
Porém, no mercado, existem vários modelos e não apenas “um CMM”. Existe o
SW-CMM (software-CMM), voltado ao desenvolvimento e manutenção de software; o
SECM (Systems Engineering Capability Model), voltado à engenharia de sistemas; o SA-
CMM (Software Acquisition Capability Maturity Model), voltado ao processo de compras
ou aquisição, entre outros.
Assim, estes modelos evoluíram para o CMMI (Capability Maturity Model
Integration) que é um modelo de referência que provê orientação para o desenvolvimento
de processos de software. Isso é realizado por meio de áreas de processo que elucidam os
tópicos mais importantes para a indústria de software.
Essas áreas são divididas em quatro disciplinas: Gerência de Projetos; Gerência de
Processos; Engenharia e Apoio, e em cinco níveis de maturidade (Ponto da Tecnologia,
2007). A Figura 2 mostra as áreas de processos e seus respectivos níveis e disciplinas.

Figura 2 - Áreas de processos e seus respectivos níveis e disciplinas

Estes níveis são classificados da seguinte forma:


• Nível 1. Inicial – a empresa possui processos “ad hoc” e caóticos. Nesse ponto ela
ainda não possui nenhuma das áreas de processo implementadas;
• Nível 2. Gerenciado – a empresa possui processos gerenciados e caracterizados por
projetos, mas muitas vezes ainda trabalha de forma reativa;
• Nível 3. Definido – a empresa possui processos definidos e caracterizados para a
organização. Normalmente a empresa trabalha de forma ativa;
• Nível 4. Gerenciado Quantitativamente – a empresa mede e controla os seus
processos;
• Nível 5. Em Otimização – a empresa tem o foco em descobrir a causa de seus
problemas e melhorar continuamente os seus processos.

8. Considerações Finais
Nesse artigo foi apresentada uma visão geral do conceito de Qualidade de Software
baseando-se em dois modelos que definem as características e métricas necessárias para se
atingir qualidade em um produto de software.
Pode-se concluir que diversos fatores influenciam na qualidade de um software e
esta deve ser analisada em todos os momentos do desenvolvimento. O ciclo de vida de
produção de um software deve ser constantemente avaliado para verificar se as
características apresentadas na Norma NBR ISO/IEC 9126 estão sendo cumpridas e se o
padrão de construção está seguindo as regras definidas no modelo CMMI, de forma a se
encaixar em um dos cinco níveis propostos.
A qualidade é um fator crucial, pois é ele quem define a satisfação do usuário em
relação ao produto construído. Dessa forma, a adoção de modelos e padrões, que podem
causar certo desconforto por parte dos desenvolvedores e engenheiros por conta do
aumento do tempo de desenvolvimento assim como a formalização de certas tarefas, gera
um produto mais confiável e que atende aos requisitos esperados, visto não somente pelo
usuário final, mas também pela própria empresa que desenvolve, pois ganha-se em diversas
características definidas pela Engenharia de Software como reusabilidade de código, por
exemplo.
9. Referências Bibliográficas

FERREIRA, Aurelio B. Holanda. Aurélio Dicionário da Língua Portuguesa. 6 ed. Rio de


Janeiro: Positivo, 2004.

GARVIN, David A. Gerenciando a Qualidade. Rio de Janeiro: Qualitymark, 2002.

PRESSMAN, Roger S. Engenharia de Software. 5. ed. Rio de Janeiro: McGraw-Hill,


2002.

FERNANDES, Daniel Batista. Análise de Sistemas Orientada ao Sucesso - Por que os


Projetos Atrasam? Rio de Janeiro: Ciência Moderna, 2005.

VASCONCELOS, Alexandre Marcos Lins de., [et. al]. Engenharia de Software para
Software Livre 1. Lavras: UFLA, 2006.

SQUARE, Newtown. A Guide to the Project Management Body of Knowledge, PMI-


Project Management Institute. USA, Pennsylvania, 2000.

SOMMERVILE,

ISHIKAWA, K. Controle de Qualidade total à maneira Japonesa. Rio de Janeiro: Campus,


1993.

NBR ISO/IEC 9126-1:2003, Engenharia de Software – Qualidade de produto - Parte 1:


Modelo de qualidade.

Ponto da Tecnologia <http://www.pontodatecnologia.com.br/2006/07/introduo-ao-


cmmi.html> Acessado em 19/09/2007.

Você também pode gostar