Você está na página 1de 6

Padrões de Qualidade para a Garantia da Confiabilidade de Produto de Software

Maycon Viana Bordin

Faculdade Três de Maio – Campus SETREM 98.910-000 – Três de Maio – RS – Brasil

mayconbordin@gmail.com

Abstract. This paper aims to compare two software quality models, the ISO/IEC 9126 and the IEEE 982.1. The first one was specified to the assessment of software quality, but it is too much ambiguous in the definition of measures and guidelines. While the latter was developed especially to the assessment of software reliability and is much more concise in the definition of measures that should be used to build more reliable software besides allows continuous process improvement.

Resumo. Este artigo tem como objetivo comparar dois modelos de qualidade em software, a ISO/IEC 9126 e a IEEE 982.1. A primeira foi especificada para a avaliação da qualidade do software, mas ela é muito vaga quanto à definição de métricas e procedimentos. Enquanto que a última foi desenvolvida especialmente para a avaliação da confiabilidade de softwares e se mostra muito mais concisa na definição das métricas que devem ser utilizadas para a construção de softwares confiáveis além de permitir a melhoria contínua dos processos.

1. Introdução

Softwares são utilizados atualmente na maioria das empresas de tal modo que não podem mais ser considerados como diferencial estratégico. Entretanto, a qualidade de um software é imprescindível para o êxito das organizações que dependem dele para realizar suas tarefas vitais e outras tarefas com âmbito estratégico e que influenciam diretamente na tomada de decisões.

A importância no desenvolvimento de softwares com qualidade não é um assunto novo e é largamente discutido, ao menos na teoria. Na área de engenharia de software o assunto vem sendo abordado a um bom tempo, o primeiro modelo de qualidade foi concebido 1977 e ficou conhecido como o modelo de McCall. Desde então vários modelos surgiram, os principais são: modelo de McCall, de Boehm, de Dromey, FURPS e a ISO/IEC 9126 [ALQ 10].

De acordo com [KIT 96] os modelos de qualidade surgiram pela necessidade de se entender e medir qualidade. Modelos de qualidade ainda listam características de qualidade que um software deve possuir e a relação entre estas características. Dos modelos citados acima se obtém um total de 17 características para qualidade, sendo que apenas a confiabilidade é comum para todos [ALQ 10]. Um artigo em [KHA 09] faz uma análise entre os modelos de qualidade e além dos modelos acima citados este

estudo adiciona o modelo de Kazman e da IEEE, e ambos definem a confiabilidade como um atributo de qualidade.

Os mais conhecidos modelos de qualidade de software colocam a confiabilidade como um dos atributos importantes a serem contemplados para a garantia de qualidade em um software. Este trabalho tem como objetivo mostrar a importância da confiabilidade de um software e fazer um comparativo entre a ISO/IEC 9126 [ABN 01] e a IEEE 982.1 [IEE 96], modelo de qualidade que define métricas para a avaliação da confiabilidade de softwares.

2. Qualidade de Software

Segundo [YEA 04] qualidade de software significa estar em conformidade com os requisitos dos consumidores ou clientes. Um artigo de [DEN 92] também apóia a idéia de que a qualidade do software deve ser medida levando em conta a satisfação do consumidor deste software.

Em um artigo da IEEE Software [KIT 96] foram descritas as cinco diferentes perspectivas para a qualidade de software definidas por David Garvin. Essas perspectivas são:

Perspectiva transcendental: seria o ideal de qualidade, podendo ficar apenas próximo dele, mas nunca alcançar completamente.

Perspectiva do usuário: são os atributos de qualidade que irão identificar se as necessidades do usuário foram atendidas. Essa perspectiva é abrangida pela norma ISO/IEC 9126, que define os atributos para a qualidade em uso.

Perspectiva do fabricante: nessa perspectiva de qualidade está relacionada à conformidade com os processos e não com as especificações. Essa abordagem garante a uniformidade das saídas, o que por si só não garante qualidade do produto. A ISO 9001 bem como a CMMi dão ênfase na melhoria contínua dos processos para que o produto também tenha maior qualidade.

Perspectiva do produto: nesta abordagem a qualidade do software está relacionada com as características internas do produto, e estas podem ser medidas e modificadas e como consequência haverá uma melhora das qualidades externas do produto. A IEEE 1061 e a ISO/IEC 9126 tratam desta perspectiva.

Perspectiva baseada em valor: essa perspectiva avalia a variação de importância de cada uma das perspectivas anteriores, dependendo de quem está observando.

Modelos de qualidade de software devem contemplar algumas destas perspectivas para definir os requisitos de qualidade de software. Além disso, modelos de qualidade devem decompor os requisitos em características de qualidade, subcaracterísticas e métricas [IEE 98]. Um modelo de qualidade deve permitir a avaliação do produto de software bem como a análise dos resultados para estimar e avaliar os fatores de qualidade [IEE 98].

Definido o que é qualidade de software e quais são as suas perspectivas agora será abordada a confiabilidade de software, uma das características para se obter qualidade em software.

3.

Confiabilidade em Software

Para um sistema ser confiável ele precisa ter formas de lidar com erros humanos, além de gerenciar o mau uso do software e falhas de hardware [YEA 04]. O autor ainda afirma que a confiabilidade em software é um atributo que deve ser levado em consideração em qualquer projeto de software, mas existe uma ênfase nesta característica de qualidade principalmente em sistemas da área de defesa, controle de processos e sistemas bancários.

4. ISO/IEC 9126

A ISO/IEC 9126 segundo [ALK 05] é um modelo para especificação e validação da qualidade de softwares que provê uma linguagem que pode ser compreendida por usuários, desenvolvedores e avaliadores. Esta norma trata da qualidade do produto de software definindo os atributos de qualidade interna, externa e de uso.

A qualidade interna é a mensuração das características do software durante as

fases de desenvolvimento, revisão e teste. Enquanto que a qualidade externa é medida em um ambiente de testes utilizando métricas externas com o objetivo de encontrar e

eliminar erros. E a qualidade em uso mede o nível de adequação do software as necessidades dos usuários [ABN 01].

De acordo com [ABN 01] a confiabilidade é a “capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas.” (p. 8). A confiabilidade de um software pode ser comprometida em decorrência de falhas na especificação dos requisitos, projeto e desenvolvimento.

A

norma [ABN 01] divide o atributo confiabilidade em três subcaracterísticas,

estas são:

Maturidade: “Capacidade do produto de software de evitar falhas decorrentes de defeitos no software.”

Tolerância a falhas: “Capacidade do produto de software de manter um nível de desempenho especificado em casos de defeitos no software ou de violação de sua interface especificada.”

Recuperabilidade: “Capacidade do produto de software de restabelecer seu nível de desempenho especificado e recuperar os dados diretamente afetados no caso

de uma falha.”

Em [SOD 06] afirma-se que “Para obter qualidade em uso é preciso ter

(p. 35).

Entretanto, [KIT 96] afirmam que mais pesquisas precisam ser realizadas para garantir que a qualidade interna garante a qualidade externa e quais aspectos da qualidade interna afetam a qualidade em uso.

qualidade externa, que por sua vez é dependente de qualidade interna [

]”

5. IEEE 982.1

Esse padrão fornece métricas para a avaliação da confiabilidade de um software, ele fornece ainda a forma correta de se aplicar cada uma das métricas, métodos para cálculos e um framework que facilita a comunicação entre os envolvidos. Através desse padrão é possível melhorar os processos bem como o produto de software, e ela ainda

serve para avaliar a confiabilidade de softwares como produto, em seu ambiente de aplicação [IEE 96].

Essa é base para a existência de duas categorias de métricas, as de produto e as de processo. A primeira trata de medir a confiabilidade dos objetos de software produzidos enquanto que a segunda categoria é aplicada nas atividades de desenvolvimento, teste e manutenção [IEE 96].

De acordo com [IEE 96] “as métricas do produto endereçam causa e efeito dos aspectos estáticos e dinâmicos tanto da confiabilidade projetada antes da operação como da confiabilidade operacional.” (p. 17). Essas métricas servem para avaliar o nível de confiabilidade do produto através da avaliação deste com relação às diversas naturezas de erros. As métricas do produto estão dividas em seis subcategorias:

Erros, Defeitos e Falhas: número de falhas que podem ser de origem humana, bugs do software ou mau funcionamento do sistema.

Taxa de falhas: demonstra a quantidade de erros que ocorre em um intervalo de tempo.

Crescimento da Confiabilidade e Projeção: avaliação da evolução do software em relação à quantidade de erros na fase de teste e em operação.

Falhas Persistentes do Produto: avaliação da quantidade de erros do software na fase de desenvolvimento, teste ou manutenção.

Integridade e Consistência: avaliação da existência de todas as partes do software e se elas estão integradas corretamente.

Complexidade: avaliação de fatores confusos no sistema.

As métricas de processo podem ser aplicadas durante o clico de vida de um projeto e permitem a avaliação contínua dos processos, melhorando a confiabilidade e o gerenciamento do projeto. As métricas de processo estão divididas em três categorias [IEE 96]:

Controle do Gerenciamento: avaliação do caminho que está sendo tomado pela fase do desenvolvimento e manutenção.

Cobertura: avaliação da existência de todas as atividades necessárias para o desenvolvimento e manutenção do software.

Riscos, Benefícios e Avaliação de Custo: avaliação dos conflitos que podem ocorrer com relação a custos, cronograma e desempenho.

Em resumo, as métricas do produto permitem a avaliação da confiabilidade do software e como isso permitem o melhoramento do software, enquanto que as métricas de processo avaliam os impactos no projeto decorrentes da falta de confiabilidade.

Cada métrica dentro desse padrão está dividida em aplicação, primitivas e execução. A aplicação descreve em que situação a métrica poderá ser aplicada; as primitivas são dados que servem para descrever de forma quantitativa um software, esses dados são mensuráveis e calculáveis; e a execução descreve os procedimentos que devem ser seguidos para a aplicação da métrica [ABN 01].

6. Avaliação das Normas

De acordo com [SOD 06] a ISO/IEC 9126 possibilita, de forma efetiva, a verificação da qualidade de um produto de software para averiguar a adequabilidade às necessidades dos usuários. Mas de acordo com [BOT 10], devido à natureza genérica desta norma, alguns dos conceitos que ela apresenta precisam ser refinados para que então possam ser aplicados em um projeto.

Os autores de [KIT 96] são mais concisos e rígidos em suas críticas, afirmando que a ISO/IEC 9126 não indica de forma clara como medir as características de qualidade. Segundo os autores, a escolha das características e subcaracterísticas parecem ter sido arbitrárias e não existe nada na norma que possibilite a verificação de que as métricas escolhidas afetam o comportamento da característica observada.

Em outro artigo [ALK 05] também foram feitas menções sobre alguns problemas da ISO/IEC 9126 como a ambigüidade na interpretação da norma, quando o objetivo de tal padrão era exatamente criar uma linguagem padrão para que não houvesse interpretações dúbias, o autor complementa que um glossário de termos deveria ter sido incluído para melhorar a compreensão da norma.

Neste mesmo artigo [ALK 05] os autores citam problemas em relação à norma (ISO/IEC 9126) pelo uso de cálculos com o objetivo de reduzir a subjetividade. Aqui é sugerida a utilização de normas de procedimento para métricas e não cálculos. Além disso, muitas entradas para medidas parecem considerar a fase de análise e de desenvolvimento como sendo a mesma coisa, exigindo na fase de análise medições que só poderiam ser feitas com implementações construídas.

Por outro lado, a IEEE 982.1 apresenta-se concisa na apresentação das métricas para a avaliação da confiabilidade de software. Ao contrário da ISO/IEC 9126, essa norma fornece uma framework bem definida, com um dicionário de definições que evitam possíveis interpretações precipitadas sobre as métricas. Todas as primitivas utilizadas nas métricas estão bem definidas dentro de uma tabela.

A classificação das métricas na IEEE 982.1 é muito mais clara. Além disso, a proposta dessa norma é muito mais interessante, pois além de permitir a avaliação da confiabilidade de um software ela ainda fornece métricas que servem para a melhoria dos processos durante o ciclo de vida do projeto, que tem grande importância estratégica para indicar os gastos, atrasos e o desempenho do projeto em decorrência da confiabilidade.

Outro ponto forte da IEEE 982.1 é a forma como as métricas foram estabelecidas. Isso porque cada métrica possui uma descrição detalhada sobre em que circunstância ela deve ser aplicada, quais os dados que serão obtidos através dessa métrica e o que eles significam, e a forma como essa métrica deverá ser aplicada.

7. Conclusão

Através deste estudo foi possível avaliar as normas ISO/IEC 9126 e IEEE 982.1, analisando suas características e aplicabilidade. Enquanto que a primeira norma se mostrou vaga em alguns aspectos, além de não fornecer procedimentos claros para a aplicação das métricas. A IEEE 982.1 mostrou prover de forma clara e concisa um

conjunto de métricas que possibilitam a avaliação da confiabilidade de software e ainda fornecem métricas para o aperfeiçoamento dos processos do projeto.

Desta forma, fica evidente que para um modelo de qualidade consiga atingir seus objetivos ela precisa ser muito bem fundamentada, além de prover uma linguagem clara, métricas concretas e bem definidas. Para então permitir a correta utilização destas ferramentas e auxiliar na construção de sistemas mais confiáveis e de maior qualidade.

Referências

[ALK 05]

Al-Kilidar, Hyiam; Cox, Karl; Kitchenham, Barbara (2005). “The Use and Usefulness of the ISO/IEC 9126 Quality Standard”, International Symposium on Empirical Software Engineering, p. 7, 2005.

[ALQ 10]

Al-Qutaish, Rafa E. (2010). “Quality Models in Software Engineering Literature: An Analytical and Comparative Study”, The Journal of American Science, Volume 6, Issue 3, Cumulated No. 24, March 1, 2010.

[ABN 01] Associação Brasileira de Normas Técnicas (2001). “NBR ISO/IEC 9126- 1:2001, Engenharia de Software Qualidade do Produto Parte 1: Modelo de Qualidade”.

[BOT 10]

Botella, P. et al (2010). “ISO/IEC 9126 in practice: what do we need to know?”, Group of Software Engineering for Information Systems, Universitat Politècnica de Catalunya. Acesso em: Abril de 2010.

Disponível

em:

http://www.essi.upc.edu/~webgessi/publicacions/SMEF%2704-ISO-

QualityModels.pdf.

[DEN 92]

Denning, Peter J. (1992). What is Software Quality?”, A Commentary from Communications of ACM, Jan. 1992. Disponível em:

http://cs.gmu.edu/cne/pjd/PUBS/softqual92.pdf.

[IEE 96]

Institute of Electrical and Electronics Engineers (1996). IEEE 982.1:

Standard Dictionary of Measures to Produce Reliable Software”.

[IEE 98]

Institute of Electrical and Electronics Engineers (1998). IEEE 1061-1998:

Standard for a Software Quality Metrics Methodology”.

[KHA 09] Khayami, R.; Towhidi, A.; Ziarati, K. (2009). “The Analytical Comparison of Qualitative Models of Software Systems”, World Applied Sciences Journal 6 (Supplement 1): 01-06, 2009.

[KIT 96]

Kitchenham, Barbara; Pfleeger, Shari Lawrence (1996). "Software Quality:

The Elusive Target", IEEE Software, vol. 13, no. 1, p. 12-21, Jan. 1996.

[SOD 06]

Sodré, Cibele Cristina Pelizer (2006). Norma ISO/IEC 9126: Avaliação de Qualidade de Produtos de Software”, Universidade Estadual de Londrina, Departamento de Computação, Trabalho de Conclusão de Curso, Londrina:

2006.