Sie sind auf Seite 1von 20

CENTRO UNIVERSITÁRIO DA FUNDAÇÃO INSTITUTO DE ENSINO PARA OSASCO

6º SEMESTRE DE ENGENHARIA DE COMPUTAÇÃO – ENGENHARIA DE SOFTWARE I

QUALIDADE DE SOFTWARE – MÉTODOS E MÉTRICAS

Éderson Ramalho

Guthierry Marques

Princes Johny Farias Figueiredo

Thales Batista Pereira

Victor Luque Zorzete

Professor: Artur Pinto Carneiro

OSASCO

10/2013

Introdução

Nos dias de hoje é difícil pensar em qualquer produto ou serviço que não possua um método ou forma de medição que busque garantir sua eficiência diante de seu propósito. Dependendo do setor, o leque de opções de fornecedores é tão grande que, para ser competitivo é crucial utilizar e melhorar continuamente as formas de gestão da qualidade. Com o produto software não é diferente. Por exemplo, quando pensamos em segurança da informação já vem em nossa mente acreditar em uma forma de garantir que dados particulares de pessoas, empresas e instituições em geral estejam protegidas confidencialmente quando trafegadas através da rede. Dessa forma, imaginamos o uso de softwares que garantam essa proteção. Infelizmente, vemos constantemente casos em que dados particulares são interceptados devido à vulnerabilidade desses sistemas. David Chappell nos lembra em seu artigo de 2012 “O valor do negócio da qualidade de software” [Cha12] da falha de segurança da Sony Playstation Network, rede para jogos online onde, cerca de 70 milhões de pessoas tiveram seus dados roubados por hackers. E não é só de segurança que vive um software, se voltarmos alguns anos no tempo, veremos que as principais empresas de desenvolvimento de software perceberam que quantias exorbitantes em dinheiro eram gastas com softwares que não cumpriam com suas funcionalidades. A CIO Magazine, importante revista mundial de gestão e estratégias de negócio em TI, estampou [Lev01] em sua capa da edição de 15 de Outubro de 2001 que 78 bilhões de dólares eram desperdiçados todos os anos em softwares com essas características. Já a Informationweek, outra revista do segmento, publicou [Ric01] em 21 de Maio de 2001 um levantamento realizado pela Standish Group, empresa de pesquisa de mercado, que afirma que 45% do tempo que sistemas computacionais ficam inativos são devidos a códigos mal elaborados e custaram cerca de 100 bilhões de dólares às empresas de TI americanas com manutenção e redução de produtividade no ano 2000. Em um mundo onde cada vez mais os sistemas informatizados controlam as coisas ao nosso redor, garantir a qualidade do produto tornou-se um quesito indispensável.

Uma vez que a tarefa de desenvolvimento de software não é algo repetitivo o que a torna difícil e de certa forma imprevisível, conforme elucida André Koscianski em seu livro Qualidade de Software, a garantia de qualidade desse tipo de produto torna-se uma tarefa árdua. Ao longo do processo de produção de um software, levando em conta parâmetros que visam uma maior qualidade do produto, percebe-se que os problemas

acontecem em todas as etapas de produção, desde a elaboração do escopo e análise dos requisitos até a fase de testes e implantação. Dessa forma, considerando também a exigência de usuários e clientes, criou-se um estímulo para que a comunidade de software elaborasse modelos de desenvolvimento, métodos e métricas que visassem à garantia de qualidade do produto. Mas pensando bem, o que seria em essência essa qualidade de software? Segundo Pressman, “Qualidade de software é a conformidade de requisitos funcionais e de desempenho que foram explicitamente declarados, a padrões de desenvolvimento claramente documentados, e a características implícitas que são esperadas de todo software desenvolvido por profissionais”. Entretanto, quando pensamos em qualidade de software devemos tomar cuidado em até que ponto ela deve ser priorizada em um projeto de um sistema computacional [Pre01a]. Certa vez em uma entrevista [Ven03] publicada na internet, Bertrand Meyer, consultor e acadêmico da área de computação, disse em outras palavras que se perde ao produzir um software de baixa qualidade porque não terá clientes para comprá-lo. Além disso, produzir um software absolutamente perfeito demandaria muito tempo, dinheiro e esforço técnico e, em consequência, a falência de seus produtores. Tal fenômeno é considerado o grande dilema da qualidade de software [Pre01b]. Dessa forma, é necessária uma análise ponderada de diversas características do produto, seu ambiente de aplicação e os prazos para seu desenvolvimento. Não basta somente considerar a qualidade do produto final, mas sim de todo o seu processo de criação, fabricação e testes. Analisar de forma prévia os requisitos, os riscos, o investimento envolvido e os prazos a serem cumpridos são formas de minimizar futuros transtornos que possam gerar retrabalhos, atrasos e, em casos extremos, até mesmo inviabilizar o negócio.

Outro ponto a ser considerado é a diferença que um software como produto apresenta em relação a outros bens de produção. É muito clara toda a abstração envolvida quando pensamos na produção de software se comparada à produção seriada de uma peça qualquer, por exemplo. Dessa maneira, determinadas formas de controle de qualidade são necessárias para atender as características específicas que a produção de software demanda. Alguns institutos de normatização criam ao longo do tempo e de acordo com a necessidade do mercado normas e padrões para que empresas possam ter um guia de desenvolvimento e métrica de qualidade a seguir. Podemos citar entre estes institutos o IEEE (Institute of Electrical and Electronics Engineers), responsável pela criação do padrão IEEE730 que define um Plano de Garantia de Qualidade para Software, e

também a ISO (International Organization for Standardization) e o IEC (International Eletrotechinical Commission) que juntas criaram as normas ISO/IEC 9126 que especifica modelos e métricas para a qualidade do produto de software e a ISO/IEC 14598 que apresenta formas de avaliação do produto de software. Mais tarde, a ISO e IEC desenvolveram a norma ISO/IEC 25000, também conhecido por SQuaRE (Software Product Quality Requirements and Evaluation), com um conteúdo mais completo que aos poucos vem substituindo as normas ISO/IEC 9126 e ISO/IEC 14598. As normas ISO e IEC são as normas adotadas no Brasil pela ABNT (Associação Brasileira de Normas Técnicas) que levam o mesmo nome, porém, com a sigla NBR no início de todas elas.

O resultado da qualidade de software é fruto de um conjunto de ações que auxiliam uma equipe de projeto a atingir um alto nível de qualidade no produto final. O intuito desse artigo é transcorrer sobre os métodos e métricas de qualidade baseados na norma NBR ISO/IEC 9126 e, a partir dela, traçarmos uma conexão com a norma NBR ISO/IEC 25000, uma vez que esta além de apresentar um conjunto de qualidades necessárias ao produto, também mostra toda uma forma de garantia e avaliação da qualidade. Esse modelo pode ser aplicável a todo o tipo de software, sejam programas de computadores ou dados contidos em firmware.

1.

Conceito de Qualidade de Software

O conceito de qualidade é definido como sendo “um conjunto de características de todo produto e serviço ou relação planejada, praticada e verificada, visando superar as expectativas de satisfação das pessoas envolvidas” [SEBRAE] ou “a totalidade das características de uma entidade que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas do cliente” [ISO8402].

Entende-se por entidade tanto o produto como o serviço. Necessidades explícitas são as condições e objetivos pelo produto expressos na definição de requisitos, que definem as condições em que o produto deve ser utilizado, seus objetivos, funções e o desempenho esperado. Entende-se por necessidades implícitas aquelas que não estão expressas nos documentos do produtor, mas que são necessárias para o usuário, entre elas as diferenças entre os usuários, a evolução no tempo, as implicações éticas e questões de segurança.

Qualidade é um termo associado à definição de conformidade às especificações e à visão de satisfação do cliente, sendo que prazos, pontualidade de entrega e flexibilidade também são fatores relevantes para avaliação. Para isso, a ABNT (Associação Brasileira de Normas Técnicas), junto à ISO (Organização Internacional de Padronização), promovem a normalização de produtos e serviços, utilizando determinadas normas, para que a qualidade dos produtos seja melhorada continuamente.

Dessa forma, a ISO estipula alguns procedimentos para que seja feita a verificação correta dos produtos ou processos:

1. Padronização de Processos;

2. Monitoramento e Aferição de Processos;

3. Rastreabilidade de Processos;

4. Inspeção de Qualidade;

5. Revisão Sistemática dos Processos.

Segundo Mark Lefebvre, diretor de Marketing do Sistema de Software da Rational Software (EUA), “em uma pesquisa feita no mercado, cerca de 66% dos projetos de softwares fracassam assim que chegam ao mercado, gerando gastos e riscos desnecessários para as empresas e fabricantes que os desenvolveu, não só pela marca, mas coloca acima de tudo, seus lucros e resultados finais. Isso acontece devido à

pressão competitiva para desenvolver estes produtos resulta em ciclos de vida mais curtos, e a complexidade se une a desafios de manter um padrão único de qualidade”.

Por esse motivo, algumas empresas prestam serviço de consultoria e análise de softwares e produtos, como por exemplo, a IBM com o “IBM Ensure Quality”, que promove o software de “Ponta-a-Ponta” e enfatiza o gerenciamento de qualidade ao longo do seu ciclo de vida.

Explanaremos a seguir um pouco mais sobre as normas ISO, usando a ISO/EIC 9126 e SQuaRE ISO/EIC 25000 como exemplo.

A norma ISO/EIC 9126, sobre o título geral “Engenharia de software – Qualidade de

software”, que tem como principais métodos:

- Modelo de Qualidade

- Métricas Externas

- Métricas Internas

- Métricas de Qualidades em uso

A

ISO/EIC 9126 é uma revisão da NBR 13596, que visa à avaliação de produtos de

software, onde foram implantadas algumas melhorias, tais como:

- Inclusões das sub-características em caráter normativo, baseadas, em sua maioria, no anexo informativo da NBR 13596, que contém as sub-características de qualidade;

- Especificação de um modelo de qualidade;

- Introdução de qualidade em uso;

- Remoção do processo de avaliação (agora especificado na NBR ISO/IEC 14598);

- Coordenação de seu conteúdo com a NBR ISO/IEC 14598-1.

1.1.

Modelo de Qualidade

Esta parte da norma ISO/EIC 9126 tem como objetivo a qualidade do software, visando que seja especificada e avaliada de diferentes formas e pontos de vista, com aquisição, requisitos, desenvolvimento, uso, avaliação, apoio, manutenção, garantia de qualidade e auditoria de software.

As metas propostas para que haja uma boa avaliação são as seguintes:

- Validar a completitude de uma definição de requisitos;

- Identificar os requisitos do software;

- Identificar objetivos de projeto do software;

- Identificar objetivos para testes de software;

- Identificar critérios para garantia de qualidade;

- Identificar critérios de aceitação para produtos finais de software.

1.2. Métricas Externas

As métricas externas podem ser usadas para medir a qualidade do produto de software através da medição de seu comportamento em um sistema do qual ele faça parte. Métricas externas podem ser usadas apenas durante os estágios de teste do processo de ciclo de vida ou durante qualquer estágio operacional. Consegue-se isso executando o software no ambiente de sistema ao qual ele pretende se encaixar.

Segundo a ABNT:

Qualidade Externa é a totalidade das características do produto de software do ponto de vista externo. É a qualidade quando o software é executado, o qual é tipicamente medido e avaliado enquanto está sendo testado num ambiente simulado, com dados simulados e usando métricas externas. Durante os testes, convém que a maioria dos defeitos seja descoberta e eliminada. Entretanto, alguns defeitos podem permanecer após o teste. Como é difícil corrigir a arquitetura do software ou outro aspecto básico do projeto do software, a base do projeto usualmente permanece inalterada ao longo do teste”.

1.3.

Métricas Internas

As métricas internas podem ser aplicadas a um produto de software não executável, durante os seus estágios de desenvolvimento. Elas proporcionam ao usuário a habilidade de medir a qualidade nas fases intermediárias e, assim, predizer a qualidade final do produto. Isso permite ao usuário detectar falhas e tomar as ações corretivas durante os estágios iniciais de desenvolvimento.

Segundo a ABNT:

Qualidade Interna é a totalidade das características do produto de software do ponto de vista interno. A qualidade interna é medida e avaliada com relação aos requisitos de qualidade interna. Detalhes da qualidade do produto de software podem ser melhorados durante a implementação do código, revisão e teste, mas a natureza fundamental da qualidade do produto de software representada pela qualidade interna mantém-se inalterada, a menos que seja re-projetada.

1.4. Métricas de Qualidade em Uso

As métricas de Qualidade em uso se resumem em qual será a reação, duvidas, aceitabilidade do usuário ao usufruir do software quando pronto. Nesse caso, o desenvolvedor deve pensar em todo e qualquer problema ou dificuldade que o usuário pode ter. Para melhor entendimento, o esquema abaixo pode melhorar a interpretação das etapas deste processo:

pode melhorar a interpretação das etapas deste processo: Fig.1. Características de qualidade de uso (Fonte: [3]).

Fig.1. Características de qualidade de uso (Fonte: [3]).

Eficácia: Capacidade que o produto de software possui capaz de permitir que o

usuário atinja metas determinadas com eficácia e completeza, em um contexto de uso especificado.

Produtividade: Capacidade que o produto de software possui capaz de permitir que os usuários utilizem uma quantidade adequada de recursos em relação à eficácia alcançada em um contexto de uso especificado.

Segurança: Capacidade que o produto de software possui capaz de oferecer níveis

aceitáveis de risco de danos a pessoas, negócios, software, propriedade ou ao ambiente, em um contexto de uso especificado.

Satisfação: Capacidade que o produto de software possui de satisfazer usuários em um contexto de uso especificado.

Usando como referência o padrão imposto pela ABNT, o relacionamento da qualidade em uso com as outras características de qualidade depende do usuário:

- O usuário final, para quem qualidade em uso é, principalmente, resultante de funcionalidade, confiabilidade, usabilidade e eficiência;

- A pessoa que mantém o software, para quem qualidade em uso é resultante de

manutencibilidade; - A pessoa encarregada de portar o software, para quem qualidade em uso é resultante

de portabilidade.

2.

A SquaRE: Norma ISO/ IEC 25000

SquaRE “Software Product Quality Requirements and Evaluation (Requisitos de qualidade e Avaliação de Produtos de Software).

Ela é uma das normas mais importantes a respeito de caracterização e medição de qualidade de produto de software, sendo a evolução das séries de normas ISO/IEC 9126

e ISO/IEC 14598.

A tabela abaixo apresenta um comparativo da migração entre as normas ISO/IEC 9126

e ISO/IEC 14598 com a ISO 25000:

ISO/IEC 9126, 14598

ISO25000, SQuaRE

9126: Qualidade do Produto

25000: Divisão de Gestão da Qualidade

1. Métricas de Qualidade

25000: Guia do SQuaRE (NP)

1. Métricas de Qualidade 25000: Guia do SQuaRE (NP) 2. Métricas externas 25001: Planejamento e Gestão
1. Métricas de Qualidade 25000: Guia do SQuaRE (NP) 2. Métricas externas 25001: Planejamento e Gestão

2. Métricas externas

25001: Planejamento e Gestão

3. Métricas internas

25010: Divisão de modelo de qualidade

4. Métricas de qualidade em uso

25010: Modelo de Qualidade (Rev.)

25020: Divisão de Medição Qualidade

Nova Proposta

25020:

medição (NP)

Guia

e

modelo

de

referência

para

Guia para usar 9126 & 14598

25021: Elementos de medição de qualidade

Medidas básicas

25022: Medição de Qualidade interna

Requisitos de qualidade

25023: Medição de Qualidade externa

25024: Medição de Qualidade em uso

14598: Avaliação de Produto

25030: Divisão de requisitos de qualidade

1. Visão Geral

25030: Requisitos de Qualidade (NP)

2. Planejamento e gestão

25040: Divisão de avaliação de qualidade

3. Processo para de desenvolvedores

25040:

avaliação

Guia

e

modelo

de

referência

para

4. Processo para compradores

25041: módulos de avaliação

5. Processo para avaliadores

25041: Processo para desenvolvedores

6. Documentos de módulos de avaliação

25043: Processo para compradores

25044: Processo para avaliadores

Tab.1. Comparativo ISO9126, ISO14598 com ISO25000 (Fonte: [4]).

2.1. A Criação da SquaRE

Criação da SquaRE possibilitou uma melhor organização das normas, pois uniu as das antigas séries ISO/IEC 9126 e ISO/IEC14598, que eram bastante inter-relacionadas, mas tinham conflitos. Foi importante a introdução à orientação coordenada quanto à avaliação e à medição da qualidade de produto de software. A introdução de orientações para uso prático em forma de exemplos facilitou o entendimento para a utilização da norma.

Da Origem: ISO/IEC 9126 e 14598

São compostas por 10 documentos, sendo eles:

9126-1 Modelo de qualidade de software

9126-2 Métricas externas

9126-3 Métricas Internas

9126-4 Métricas para qualidade em uso

14598-1 Guia de avaliação – visão geral

14598-2 Planejamento e gerenciamento de avaliações

14598-3 Processo de avaliação para desenvolvedores

14598-4 Processo de avaliação para adquirentes

14598-5 Processo de avaliação para avaliadores

14589-6 Documentação de módulos de avaliação

Na reorganização da Norma ISO/IEC 25000 houve uma divisão do assunto em cinco tópicos, cada divisão é composta por um conjunto de documentos e trata de um assunto em particular sendo eles:

Requisitos de

qualidade

Modelo de qualidade

Gerenciamento de qualidade

Medições

Fig.2. Características de qualidade de uso (Fonte: [4]).

Avaliação

A reorganização da Norma ISO/IEC 25000 funciona da seguinte forma:

Gerenciamento: Os documentos desta divisão estão voltados a todos possíveis usuários, como gerente, programadores, avaliadores, compradores. Aqui são definidos os termos utilizados em todos os demais documentos e são feitas recomendações e sugestões de caráter geral sobre como utilizar o SQuaRE. [4]

Modelo de qualidade: É definido um modelo hierárquico de características de qualidade, descrevendo o que se espera de um produto. São definidos também os conceitos de qualidade externa, interna e em uso, que permitem orientar diferentes perspectivas de avaliação. [4]

Medição: Define a padronização matemática das métricas de qualidade internas, externas e de uso, junto a um modelo de qualidade e também é um guia prático para implementação do modelo. [4]

Requisitos de qualidade: Abrange as normas destinadas a especificação de requisitos de qualidade, que podem ser orientados tanto para um produto de software que será desenvolvido, quanto para um produto final. [4]

Avaliação: Incluem os requisitos, recomendações e diretrizes para a avaliação da qualidade de um produto de software para clientes e desenvolvedores. [4]

2.2. Modelo de Qualidade

clientes e desenvolvedores. [4] 2.2. Modelo de Qualidade Fig.3. Modelo de Qualidade para Qualidade externa e

Fig.3. Modelo de Qualidade para Qualidade externa e interna (Fonte: [2]).

Qualidade externa: Considera o produto como uma caixa-preta: nada se conhece sobre sua arquitetura, sobre o código ou como funciona. A realização de testes de funcionamento de um produto corresponde a verificar a qualidade externa. [4]

Qualidade interna: é exatamente a arquitetura interna que é levada em conta. A qualidade da organização do código ou a complexidade algorítmica são exemplos de critérios que podem indicar, respectivamente, prováveis custos de manutenção e provável velocidade de execução. [4]

2.3. Tabelas de Métricas

Métricas de processo e de projeto de software são medidas quantitativas que permitem ao pessoal de software ter ideia da eficácia do processo de software e dos projetos que

são conduzidos usando o processo como arcabouço [PRESSMAN]. Portanto, para mostrar como certas características podem ser mensuradas, serão apresentadas nesta seção quatro tabelas com exemplos de métricas aplicáveis a cada uma das características do modelo de qualidade em uso de produtos de software.

Métricas de Efetividade

   

Método

             

Nome da

Métrica

 

Propósito da

Tarefa

de

Aplicação

Medida e

Fórmula

Interpretação

 

Tipo de

Escala

 

Tipo de

Medida

Entrada

Referência

ISO 12207

Público-

Alvo

     

M1 = |1 - ∑A i | 1

         

Usuários

A

=

valor

0 <=M1 <=1

6.5Validação

 

Que proporção da tarefa é completada corretamente?

proporcional

Efetividade

da Tarefa

Teste com

usuário

cada item

perdido ou

incorreto no

de

Quanto mais próximo de 1, melhor.

 

-

 

A = ?

 

Resultado do roteiro de teste

Monitoramento

do Usuário

5.3Teste de

qualificação

Projetistas

de

interface

com

 

resultado da

tarefa.

   

5.4Operação

usuário

     

X

=

A/B

         

Usuários

A

= número de

A=quantidade

Resultado do

6.5Validação

Completude

da Tarefa

 

Que proporção das tarefas é completada?

Teste com

usuário

tarefas

completadas

B

= Total de

tarefas

completadas

0<=X<=1

Quanto mais

próximo de 1,

melhor.

 

Taxa

B=quantidade

X=quantidade/

quantidade

roteiro de teste

Monitoramento

do usuário

5.3Teste de

qualificação

5.4Operação

Projetistas

de

interface

com

usuário

     

X

=

A/T

         

Usuários

A

= número de

0 <= X Quanto mais

Resultado do

6.5Validação

Frequência

 

Qual é a freqüência de erros?

Teste com

erros tomados

 

A

=

roteiro de teste

5.3Teste de

Projetistas

de Erro

usuário

pelo usuário

T

= tempo ou número de

próximo de 0,

melhor.

 

Absoluta

quantidade

Monitoramento

do usuário

qualificação

de

interface

com

 

tarefas

   

5.4Operação

usuário

Tab.2. Métricas Efetividade (Fonte: [1]).

 

Métricas de Produtividade

 
   

Método

             

Nome da

Métrica

Propósito da

Tarefa

de

Aplicação

 

Medida e

Fórmula

 

Interpretação

 

Tipo de

Escala

Tipo de

Medida

Entrada

Referência

ISO 12207

Público-

Alvo

 

Quanto tempo

   

X

= Ta/Tb

     

Resultado do roteiro de teste

6.5Validação

Usuários

Tempo de

tarefa

demora-se

para

Teste com

usuário

Ta

= tempo ocioso

usuário

do

X>=0

Quanto menor,

 

Intervalo

T=tempo

5.3Teste de

qualificação

Projetistas

de

completar

Tb = tempo da

 

melhor

Monitoramento

interface

uma tarefa?

 

tarefa

do Usuário

 

com

 

5.4Operação

usuário

       

X

= M1/T

     

Resultado do roteiro de teste

6.5Validação

Usuários

Eficiência da

Tarefa

 

Quão

Teste com

usuário

M1=efetividade da

X>=0

T=tempo

X

=

5.3Teste de

qualificação

Projetistas

eficientes são

 

tarefa

Quanto maior,

 

-

 

de

 

os usuários?

 

T

=

Tempo da

melhor

 

Monitoramento

interface

 

tarefa

do usuário

 

com

 

5.4Operação

usuário

       

X

= M1/C

     

Resultado do roteiro de teste

6.5Validação

Usuários

Qual o custo efetivo do usuário?

Teste com

usuário

M1=efetividade da

X>=0

T=tempo

X

=

5.3Teste de

qualificação

Projetistas

Custo Efetivo

 

tarefa

Quanto maior,

 

Absoluta

 

de

 

C

= Custo total da tarefa

melhor

 

Monitoramento

interface

 

do usuário

 

com

 

5.4Operação

usuário

       

X

= Ta/Tb

           

Que

Ta

= tempo

6.5Validação

Usuários

proporção o

produtivo = tempo

Resultado do

Proporção

Produtiva

tempo o

usuário está

realizando

ações

Teste com

usuário

da tarefa – tempo

de

ajuda – tempo

perdido com erro – tempo de pesquisa Tb = tempo da tarefa

0<=X<=1

Quanto mais

próximo de 1, melhor.

 

Absoluta

Ta=tempo

Tb=tempo

X=tempo/

tempo

roteiro de teste

Monitoramento

do Usuário

5.3Teste de

qualificação

Projetistas

de

interface

com

produtivas?

 

5.4Operação

usuário

       

X

= A/B

       

6.5Validação

Usuários

Grau de

eficiência do

usuário

Quão eficiente é um usuário comparado com um especialista?

Teste com

usuário

A

= eficiência de

um usuário comum

B

= eficiência de um usuário

0<=X<=1

Quanto mais

próximo de 1, melhor.

 

Absoluta

X

= A/B

Resultado do

roteiro de teste

Monitoramento

5.3Teste de

qualificação

Projetistas

de

interface

 

do usuário

com

 

especializado

   

5.4Operação

usuário

       

X

= A/B

         

Usuários

Quão

produtivo é

A = produtividade de um usuário

0<=X<=1

Resultado do roteiro de teste

6.5Validação

Grau de

produtividade

do usuário

um usuário

comparado

com um

Teste com

usuário

comum

B = produtividade de um usuário

Quanto mais

próximo de 1,

melhor.

 

Absoluta

X

= A/B

Monitoramento

5.3Teste de

qualificação

Projetistas

de

interface

especialista?

   

do usuário

5.4Operação

com

especializado

 

usuário

Tab.3. Métricas produtividade (Fonte: [1]).

Métricas de Segurança

Nome da

Propósito da

 

Método de

Medida e

Interpretação

Tipo de

Tipo de

Entrada

Referência

Público-Alvo

Métrica

Tarefa

Aplicação

Fórmula

Escala

Medida

ISO 12207

 

Qual a

incidência de

 

X

= A/B

A=número de

0<=X<=1

 

A=quantidade

   

Usuários

Bem-estar

problemas de

usuários com LER, fadiga ou dor de cabeça B=Total de

usuários

Quanto mais próximo de 0, melhor.

B=quantidade

Monitoramento

5.4

do usuário

saúde entre

os usuários

do produto?

 

Estatísticas

Absoluta

X=quantidade/

quantidade

do Usuário

Operação

Projetistas de

interface com

usuário

     

X=A/B

           

Qual o nível de perigo incidente às pessoas afetadas pelo uso do sistema?

 

A=número de

Usuários

Segurança das pessoas afetadas pelo uso do sistema

   

Estatísticas

pessoas

colocadas em

perigo

0<=X<=1

Quanto mais próximo de 0, melhor.

Absoluta

A=quantidade

B=quantidade

Monitoramento

do Usuário

5.3Teste de

qualificação

Projetistas de

interface com

 

B=Total de

usuário

pessoas

afetadas pelo

X=quantidade/

quantidade

5.4Operação

Desenvolvedor

   

sistema

 
 

Qual a incidência de perigo para o paciente que recebe tratamento pelo sistema?

   

X=A/B

         

Usuários

A=número de

A=quantidade

Segurança

dos

pacientes

 

Estatísticas

pacientes com

tratamento

prescrito

0<=X<=1

Quanto mais próximo de 0, melhor.

Absoluta

B=quantidade

Monitoramento

do Usuário

5.3Teste de

qualificação

Projetistas de

interface com

usuário

 

incorretamente

X=quantidade/

5.4Operação

B=Total de

 

quantidade

Desenvolvedor

pacientes

     

X=A/B

         

Usuários

A=número de

A=quantidade

Danos

econômicos

Qual a

incidência de

danos

 

Estatísticas

ocorrências de

danos

econômicos

0<=X<=1

Quanto mais próximo de 0, melhor.

Absoluta

B=quantidade

Monitoramento

do Usuário

5.4Operação

Projetistas de

interface com

usuário

econômicos?

 

B=Total de

X=quantidade/

situações

 

quantidade

Desenvolvedor

medidas

     

X=A/B

         

Usuários

A=número de

A=quantidade

Danos do

software

Qual a

incidência de

danos do

 

Estatísticas

ocorrências de

danos no

software

0<=X<=1

Quanto mais próximo de 0, melhor.

Absoluta

B=quantidade

Monitoramento

do Usuário

5.4Operação

Projetistas de

interface com

usuário

software?

 

B=Total de

X=quantidade/

situações

 

quantidade

Desenvolvedor

medidas

Tab.4. Métricas Segurança (Fonte: [1]).

 

Métricas de Satisfação

 
   

Propósito

da Tarefa

     

Tipo

Tipo de

Medida

 

Referência

 

Nome da

Métrica

 

Método de

Aplicação

 

Medida e

Fórmula

Interpretação

de

Escala

Entrada

ISO 12207

Público-Alvo

                 

Usuários

 

X

= A/B

Resultado do

6.5Validação

 

Qual o nível de Satisfação do usuário?

A=questionário

A

=

Projetistas de

Escala de

Satisfação

 

Teste com

o

usuário

com escala

psicométrica

B=média da

X > 0

Quanto maior,

melhor

Taxa

quantidade

X

=

quantidade

roteiro de teste

Monitoramento

do Usuário

5.3Teste de

qualificação

interface com

usuário

   

população

5.4Operação

Desenvolvedor

                 

Usuários

Pesquisa

de

 

Qual o nível de Satisfação do usuário em funções específicas?

 

Teste com

 

X

= A

A=resultado da

Comparação

com valores

anteriores ou

Ordinal

A= quantidade

Resultado do

roteiro de teste

6.5Validação

5.3Teste de

Projetistas de

interface com

Satisfação

o

usuário

pesquisa

com a média da população

X= quantidade

Monitoramento

qualificação

usuário

   

do Usuário

5.4Operação

Desenvolvedor

       

X

= A/B

           
 

Qual a

A = número de vezes que a

A=quantidade

6.5Validação

Uso

discreto

do

produto

proporção

dos usuários

potenciais

optou pelo

sistema?

 

Observação

da

utilização

função,

aplicação ou sistema é usado

B = Número que o usuário teve a intenção

de

usar

0<=X<=1

Quanto mais

próximo de 1,

melhor.

Taxa

B=quantidade

X=quantidade/

quantidade

Resultado do

roteiro de teste

Monitoramento

do usuário

5.3Teste de

qualificação

5.4Operação

Usuários

Projetistas de

interface com

usuário

   

Tab.5. Métricas Satisfação (Fonte: [1]).

3.

Qualidade de Produto e o Ciclo de Vida

As visões de qualidade interna, qualidade externa e qualidade em uso mudam durante o

ciclo de vida do software. Como exemplo, os requisitos de qualidade no início do ciclo

de vida são normalmente vistos do ponto de vista do usuário (externo), e difere da

qualidade do produto intermediário, tal como a qualidade do projeto, que é geralmente vista do ponto de vista do desenvolvedor (interno). As tecnologias usadas para alcançar

o nível de qualidade necessário, assim como especificações e avaliações de qualidade, precisam apoiar tanto o ponto de vista dos usuários quanto o dos desenvolvedores. É necessário definir estas perspectivas e as tecnologias associadas à qualidade para gerenciar a qualidade em cada estágio do ciclo de vida.

O objetivo é alcançar a qualidade necessária e suficiente para atingir as reais

necessidades dos usuários. A ISO 8402 define qualidade em termos da habilidade de satisfazer necessidades explícitas e implícitas. Entretanto, as necessidades especificadas por um usuário nem sempre refletem as suas reais necessidades, pois um usuário normalmente não está ciente de suas necessidades, necessidades podem mudar após serem especificadas. Usuários diferentes podem ter ambientes operacionais diferentes, e

pode ser impossível consultar todos os possíveis tipos de usuário. Por causa disso, requisitos de qualidade não podem ser completamente definidos antes do início do projeto. Além disso, é preciso entender as necessidades reais dos usuários da forma mais detalhada possível, e representá-las em requisitos. O objetivo não é, necessariamente, alcançar a qualidade perfeita, mas sim a qualidade necessária e suficiente para cada contexto de uso especificado quando o produto é entregue e realmente utilizado pelos usuários.

Escalas de medidas para as métricas usadas em requisitos de qualidade podem ser divididas entre as categorias correspondentes para os diferentes graus de satisfação dos

requisitos. Como exemplo, a escala poderia ser dividida em duas categorias: satisfatório

e insatisfatório, ou em quatro categorias: excedeu os requisitos, atingiu requisitos suficientemente aceitos e inaceitáveis.

Basta apenas que as categorias sejam especificadas de forma que o usuário e o desenvolvedor possam evitar o excesso de custo e planejamento desnecessário.

A figura abaixo ilustra diferentes visões de qualidade do produto e métricas associadas em diferentes estágios do ciclo de vida do software.

em diferentes estágios do ciclo de vida do software. Fig.4. Qualidade no ciclo de vida do

Fig.4. Qualidade no ciclo de vida do software. (Fonte: [3]).

Conclusão

O produto software, diferentemente de uma peça manufaturada em uma fábrica, é algo que já demanda certo grau de abstração pela essência do que é.Aplicar métodos e métricas para garantir a qualidade em uma “peça”, que pela própria natureza abstrata será única e diferente mesmo se produzida diversas vezes, não é uma tarefa simples e pode mesmo se tornar um desafio dependendo da importância que se dá a qualidade a peça. Por exemplo, uma mesma equipe foi contratada para produzir dois softwares distintos, o primeiro destinado ao controle de uma cortina e o segundo será usado para operar uma máquina de radioterapia, por intuição sabemos que o primeiro software não precisa de um controle de qualidade tão rigoroso quanto o segundo, levando se em consideração que a função do primeiro pode ser resumida ao abrir e fechar de uma cortina. No entanto a falta de qualidade do segundo pode agravar os problemas de saúde de alguns pacientes ou até levá-los a morte como mostra o caso real do Therac-25, máquina criada pela empresa AECL (Atomic Energy of Canada Limited), que entre junho de 1985 e janeiro de 1987 ocasionou a morte de quatro pacientes e deixou outros dois com graves problemas devido a doses exageradas de radiação, segundo Nancy G. Leveson publicou em um estudo sobre o caso [NanCla01], o problema do Therac-25, apesar de envolver erros por parte do operador, foi causado basicamente pela má qualidade no software desenvolvido pela empresa.

É fundamental produzir um software que atenda a demanda da melhor forma possível, não só do ponto de vista do cliente, mas também deve ser viável de ser produzido e implementado de forma satisfatória, definido o grau de qualidade que o software deve atingir, usamos as normas e métricas que citamos neste artigo para obtermos tal produto e termos a garantia que este produto é de qualidade suficiente para cumprir o papel ao qual foi proposto, ou seja, deve ser um produto útil, como afirma Pressman, “Um produto útil fornece o conteúdo, as funções e os recursos que o usuário final deseja, além disso, e não menos importante deve fornecer confiabilidade e isenção de erros. Um produto útil sempre satisfaz às exigências definidas explicitamente pelos interessados. Além disso, ele satisfaz a um conjunto de requisitos implícitos (por exemplo, facilidade de uso) que se espera de todo software de alta qualidade” [Pre01c]. Todo software é desenvolvido para um determinado fim, atender uma demanda, entretenimento, educativo e etc. Se ele é útil para todas as partes interessadas em seu desenvolvimento e

atende aos padrões de qualidade propostos, seu software é um produto bem concebido por um processo satisfatório de engenharia de software.

Referências Bibliográficas

[Cha01]

http://davidchappell.com/writing/white_papers/The_Business_Value_of_Software_Qual

ity-v1.0-Chappell.pdf.

Quality:

CHAPPELL,

D.,

The

Business

Value

of

Software

[Lev01] LEVINSON, M., “Let’s Stopping wasting $78 billion a year”, CIO Magazine, 15 de Outubro de 2001:

www.cio.com/article/30599/SOFTWARE_DEVELOPMENT_Let_s_Stop_Wasting_78

_Billion_a_Year.

[NanCla01] NANCY G. L., CLARK S. T., “An investigation of the Therac-25 accidents” IEEE Computer, 26(7):18-41, 1993.

[Ric01] RICADELA, A.; “The State of Software Quality”, Information Week, 21 de Maio de 2001, disponível em: www.informationweek.com/838/quality.htm.

[Ven03] VENNERS, B.; “Design by contract: A conversation with Bertrand Meyer”, Artima Developer, 08 de Dezembro de 2003: www.artima.com/intv/contracts.html.

KOSCIANSKI, A.; SOARES M. S., Novatec, 2007.

Qualidade de Software – Segunda Edição.

[PRESSMAN] PRESSMAN, R.; Engenharia de Software. – Sétima Edição. São Paulo McGraw-Hill, 2011.

[Pre01a] PRESSMAN, R.; Engenharia de Software. – Sétima Edição. São Paulo McGraw-Hill, 2011 Cap. 14.3 (O dilema da Qualidade de Software).

[Pre01b] PRESSMAN, R.; Engenharia de Software. – Sétima Edição. São Paulo McGraw-Hill, 2011 Cap. 14.3 (O dilema da Qualidade de Software).

[Pre01c] PRESSMAN, R.; Engenharia de Software. – Sétima Edição. São Paulo McGraw-Hill, 2011 Cap. 14.2 (O dilema da Qualidade de Software).

IEEE 730-2002, Standard For Software Quality Assurance Plans.

[SEBRAE] SEBRAE. Disponível em <http://www.sebrae.com.br>.

[ISO8402] ISO 8402. Quality Vocabulary, 1994.

[1] ISO/IEC 9126-2, 3: 2002. Software engineering– Software product quality- Part 2:

External Metrics e ISO/IEC 9126-3: 2002. Software engineering– Software product quality- Part 3: Internal Metrics.

[2] ISO/IEC 9126-1: 2000. Software engineering– Software product quality- Part 1:

Quality model.

[3] ISO/IEC 9126-4: 2000. Software engineering– Software product quality- Part 4:

Quality in use metrics.

[4] ISO/IEC 25000:2004. Software engineering – Software product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE.