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 medindose 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 Qualidade Interna e Externa Qualidade de uso Descrição 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. 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 Funcionalidade: como as funções e propriedades específicas do produto, satisfazem as necessidades do usuário. Confiabilidade: como o produto de software é capaz de manter seu nível de desempenho, ao longo do tempo, nas condições estabelecidas. Usabilidade: o esforço necessário para a utilização do sistema, baseado em um conjunto de implicações e de condições do usuário. Eficiência: como os recursos e os tempos envolvidos são compatíveis com o nível de desempenho requerido pelo software. Manutenibilidade: refere-se ao esforço necessário para a realização de alterações específicas, no produto de software. Subcaracterísticas Adequação: existência de um conjunto de funções apropriadas para as tarefas 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. Maturidade: estado de maturação do software, detectada por sua baixa freqüência de falhas; 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. Inteligibilidade: facilidade de entendimento dos conceitos utilizados no produto de software; Apreensibilidade: facilidade de aprendizado do software; e Operacionalidade: faculdade de operar e controlar operações pertinentes ao software. Comportamento no tempo: refere-se ao tempo de resposta de Processamento; e Comportamento dos recursos: relacionase com a quantidade dos recursos empregados. Analisabilidade: característica de ser possível diagnosticar deficiências e causas 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
Portabilidade: facilidade de o software poder ser transferido de um ambiente para outro. ocorrências de defeitos inesperados no software; e Testabilidade: facilidade de o produto ser testado. Adaptabilidade: faculdade de o produto poder ser adaptado a novos ambientes; 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-aocmmi.html> Acessado em 19/09/2007.