Departamento de Computação Trabalho de Conclusão de Curso
CIBELE CRISTINA PELIZER SODRÉ
Norma ISO/IEC 9126: Avaliação de Qualidade de Produtos de Software
Londrina 2006
CIBELE CRISTINA PELIZER SODRÉ
Norma ISO/IEC 9126: Avaliação de Qualidade de Produtos de Software
Trabalho de Conclusão de Curso desenvolvido durante o 4º ano do Curso de Graduação em Ciência de Computação como requisito parcial à obtenção do título de Bacharel. Orientadora: Katia Romero Felizardo
Londrina 2006
CIBELE CRISTINA PELIZER SODRÉ
Norma ISO/IEC 9126: Avaliação de Qualidade de Produtos de Software
Trabalho de Conclusão de Curso desenvolvido durante o 4º ano do Curso de Graduação em Ciência de Computação como requisito parcial à obtenção do título de Bacharel. Orientadora: Katia Romero Felizardo
Londrina 2006
COMISSÃO EXAMINADORA
____________________________________ Profa. Ms. Katia Romero Felizardo UEL
____________________________________ Prof. Dr. Rodolfo Miranda de Barros UEL
____________________________________ Profa. Helen Cristina de Mattos Senefonte UEL
14
DEDICATÓRIA
À minha mãe, que sempre esteve presente nas horas em que eu precisei e não precisei.
AGRADECIMENTOS Agradeço a toda a minha família pela estrutura que me foi dada, sendo assim possível minha formação de vida.
Agradeço à professora Katia Romero Felizardo por todo apoio, incentivo e paciência dados no decorrer deste trabalho, possibilitando o desenvolvimento do mesmo da melhor maneira possível.
Agradeço aos professores do Departamento de Computação da UEL e de outros departamentos pela formação acadêmica proporcionada.
Agradeço aos amigos. amigos. Àqueles poucos, poucos, porém verdadeiros. Especialmente aos que estiveram comigo durante este curso e entendem tudo que passei. Como já diz uma conhecida frase, amigos são a família que podemos escolher.
Agradeço ao meu namorado, amigo e companheiro, que nos últimos três anos compartilhou comigo as alegrias e tristezas. E que sempre suporta os meus momentos mais nervosos e estressantes com uma calma impressionante. E está sempre ao meu lado, independente das escolhas que eu faça.
Agradeço, enfim, a todos aqueles que direta ou indiretamente prestaram apoio, amizade e confiança e contribuíram para esse momento de vida pelo qual estou passando.
E à minha Mãe (com M maiúsculo), novamente. Porque sem seu amor incondicional, as coisas seriam bem mais difíceis.
LISTA DE TABELAS Tabela 1 – Métricas Externas de Adequação............................................................36 Tabela 2 – Métrica Externa de Acurácia ...................................................................36 Tabela 3 – Métricas Externas de Interoperabilidade .................................................37 Tabela 4 – Métricas Internas de Adequação.............................................................38 Tabela 5 – Métricas Internas de Acurácia.................................................................39 Tabela 6 – Métricas Internas de Interoperabilidade .................................................. 40 Tabela 7 – Métricas de Efetividade ........................................................................... 41 Tabela 8 – Métricas de Produtividade.......................................................................42 Tabela 9 – Métricas de Segurança............................................................................43
LISTA DE SIGLAS E ABREVIATURAS
ABNT: Associação Brasileira de Normas Técnicas CMM: Capability Maturity Model CMMI: Capability Maturity Model Integrated IEC: International Electrotechnical Comission ISO: International Organization for Standardization SEI: Software Engineering Institute SPICE: Software Process Improvement and Capability dEtermination TI: Tecnologia da Informação
LISTA DE FIGURAS Figura 1 – Nível 1 do CMM........................................................................................16 Figura 2 – Nível 2 do CMM........................................................................................16 Figura 3 – Nível 3 do CMM........................................................................................17 Figura 4 – Nível 4 do CMM........................................................................................17 Figura 5 – Nível 5 do CMM........................................................................................18 Figura 6 – Representação da norma ISO/IEC 14598................................................24 Figura 7 – Representação da norma ISO/IEC 9126 e suas representações.............27 Figura 8 – Características e Subcaracterísticas de Qualidade Externa e Interna .....28 Figura 9 – Divisão das Características......................................................................32 Figura 10 – Características de Qualidade em Uso....................................................33 Figura 11 – Relação entre Métricas Internas, Externas e de Qualidade em Uso......35 Figura 12 – Valor satisfatório.....................................................................................46
SUMÁRIO INTRODUÇÃO ..........................................................................................................11 1 Introdução à Qualidade..........................................................................................12 1.1 Histórico de Qualidade.....................................................................................12 2 Qualidade de Processo de Software ......................................................................15 2.1 CMM ................................................................................................................15 2.2 ISO/IEC 12207.................................................................................................18 2.3 SPICE..............................................................................................................19 2.4 Família ISO/IEC 9000......................................................................................21 3 Qualidade de Produto de Software ........................................................................23 3.1 ISO/IEC 14598.................................................................................................23 3.2 ISO/IEC 12119.................................................................................................25 4 A Norma ISO/IEC 9126..........................................................................................26 4.1 ISO/IEC 9126-1: Modelo de Qualidade............................................................27 4.1.1 Modelo de Qualidade para Qualidade Interna e Externa ..........................28 4.1.2 Modelo de Qualidade para Qualidade em Uso .........................................33 4.2 Métricas ...........................................................................................................34 4.2.1 ISO/IEC 9126-2: Métricas Externas ..........................................................35 4.2.2 ISO/IEC 9126-3: Métricas Internas............................................................37 4.2.3 ISO/IEC 9126-4: Métricas de Qualidade em Uso......................................40 5 Processo de Avaliação...........................................................................................45 5.1 Definição de Requisitos de Qualidade.............................................................45 5.2 Preparação da Avaliação.................................................................................45 5.3 Procedimento da Avaliação .............................................................................46 5.4 Um Exemplo de Aplicação...............................................................................47 CONCLUSÃO............................................................................................................49 REFERÊNCIAS BIBLIOGRÁFICAS..........................................................................50
RESUMO Este trabalho aborda a Qualidade de Software ,detalhando normas e padrões de Qualidade de Processo de Software e Qualidade de Produto de Software . O foco do trabalho é a descrição da norma ISO/IEC 9126, que é uma norma de Qualidade de Produto de Software , e suas divisões.
Palavras-chave: Qualidade de Software , ISO/IEC 9126.
ABSTRACT This work approaches the Software Quality, detailing norms and standards of Software Process Quality and Software Product Quality. The focus of the work is the description of norm ISO/IEC 9126, which is a norm of Software Product Quality, and its divisions.
Keywords: Software Quality, ISO/IEC 9126.
INTRODUÇÃO
A área de TI se torna ampla e abrangente a passos largos. Tendo isso em vista, espera-se que os produtos resultantes dessa área atendam aos mais diversos tipos de usuários. Para que as necessidades de tais usuários sejam satisfeitas, é imprescindível que os produtos tenham qualidade. Para satisfazer os usuários de software , foram criadas algumas normas. Para assegurar qualidade no desenvolvimento de software , há as normas de Qualidade de Processo de Software , como por exemplo, a ISO/IEC 9000, a ISO/IEC 12207, o modelo de maturidade CMM e o SPICE. Existem também as normas que avaliam a Qualidade do Produto de Software , que são a ISO/IEC 9126, ISO/IEC 14598 e a ISO/IEC 12207, para avaliar os produtos já finalizados. Este trabalho abordará o tema Qualidade de Software de maneira abrangente e, ao final, será focada a norma de Qualidade de Produto de Software ISO/IEC 9126. No Capítulo 1, será feita uma breve introdução acerca de Qualidade e também será apresentado um histórico para um melhor entendimento sobre a importância da Qualidade de produtos no decorrer das décadas, apresentando assim, a evolução desse conceito, até a maneira como isso é abordado atualmente. No Capítulo 2, são detalhadas algumas normas de melhoria de Qualidade de Processo de Software . No Capítulo 3, é feita a descrição de normas que baseiam a avaliação de Qualidade de Produto de Software . O Capítulo 4 é o foco principal deste trabalho e descreve a norma ISO/IEC 9126 e suas divisões. No Capítulo 5, o Processo de Avaliação de um software é explicado e é dado um exemplo de uso da norma ISO/IEC 9126.
1 INTRODUÇÃO À QUALIDADE
A Qualidade de Software é um tema amplamente discutido da Engenharia de Software . Para um maior entendimento da importância disso, a seguir, será feita uma breve introdução sobre Qualidade. 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 1” [28] ou “a totalidade das características de uma entidade que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas do cliente” [22]. 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. 1.1 Histórico de Qualidade
O primeiro grande marco da história da qualidade nos tempos modernos foi a Revolução Industrial. Nessa época houve um grande crescimento no número de indústrias, o que criou a concorrência entre elas e fez nascer um processo de melhoria contínua de produtos. A partir da década de 20, a produção industrial passou a ter um processo de qualidade, com a finalidade de impedir que chegassem produtos com _____________ 1
Pessoas envolvidas ou partes interessadas: indivíduo ou grupo interessado ou afetado pelo desempenho ambiental de um sistema de produto ou pelos resultados da avaliação do ciclo de vida
defeito às mãos dos clientes. Como as fábricas já produziam em grande quantidade, era impossível verificar a qualidade individual de cada peça, como é feito no produto artesanal. Esse novo processo de qualidade consistia em controle estatístico da produção, que analisava algumas peças aleatoriamente e fazia a medição estatística dessas peças. Quanto mais parecidas e aproximadas do padrão ideal estivessem as medições, maior qualidade possuía aquela linha de produção. Na década de 40, os principais órgãos ligados à qualidade foram criados, como a ABNT e a ISO. Durante a Segunda Guerra Mundial, as técnicas de produção foram melhoradas para a fabricação de materiais bélicos, pois é esperado que este tipo de material apresente taxa de defeito zero 2. O impulso recebido pelas indústrias manteve-se no pós-guerra e foi criado um controle de processos envolvendo a produção desde o projeto até o acabamento. A partir do controle de processos foi criado um novo conceito, a garantia de qualidade, que é a demonstração de que os produtos e serviços possuem qualidade perante clientes e público. Nessa época, as indústrias que mais estavam se desenvolvendo eram a automobilística e aeronáutica. Já havia também computadores digitais para uso restrito a meios militares e acadêmicos. Nos anos 60, houve uma mudança no ambiente de negócios devido à saturação dos mercados, a demanda por produtos diferenciados, adoção da alta tecnologia nos processos produtivos, redução das barreiras do comércio internacional e a intensificação da competição internacional. Como conseqüência, empresas com produtos diferenciados e preços competitivos e acessíveis assumiram a liderança do mercado.[28] Nessa época, os computadores se tornaram mais acessíveis e cada vez mais pessoas passaram a usá-los. Com isso começou a se pensar em Qualidade de Software . Atualmente a satisfação do cliente e a gestão empresarial moderna são as bases da qualidade, mas os bons resultados ainda dependem do uso correto das metodologias pelos desenvolvedores. _____________ 2
Defeito Zero: Atitude de prevenção de defeitos através da compreensão e correspondência às exigências de um trabalho ou tarefa o tempo todo. Padrão de desempenho proposto por Philip B. Crosby em que o lema é "fazer certo desde a primeira vez"; sua meta é buscar a excelência pela prevenção de defeitos. Significa que a qualquer momento, a mais alta prioridade é eliminar os erros antes de escrever qualquer código novo.
13
O conceito de Qualidade de S oftware surgiu devido à necessidade de organização e padronização do desenvolvimento de software s, que não tinham planejamento nem norma de qualidade estabelecidos. A única forma de obter um sistema eficiente3 era através do planejamento feito pelo próprio programador, entretanto esses sistemas tinham manutenção complicada quando realizada por outra pessoa e não eram completamente confiáveis. Em conseqüência disso, foram criados a engenharia de software e os primeiros padrões de qualidade. A Engenharia de Software busca otimizar a construção do software e avaliar os produtos de software procurando facilitar o desenvolvimento, o uso, a adaptação e manutenção, mas também tornando o produto acessível e com cust o reduzido. A melhoria da Qualidade de Software pode ser dividida em melhoria de qualidade de processo de software e melhoria de qualidade de produto de software . As normas para obtenção de qualidade de processo de software fazem um estudo dos requisitos necessários ao cliente, cria um ciclo de vida para os processos e, por final, realiza a instalação e manutenção do mesmo. Já as normas para qualidade de produto de software possuem características que um produto com qualidade deve ter, modo de medir essas características de qualidade e descrições para se fazer a avaliação do produto.
_____________ 3
Eficiente: os objetivos são obtidos com economia de meios.
14
2 QUALIDADE DE PROCESSO DE SOFTWARE
“Processo de software é um conjunto de atividades e resultados associados que levam à produção de um produto de software . Esse processo pode envolver o desenvolvimento de software desde o início, embora, cada vez mais, ocorra o caso de um software novo ser desenvolvido mediante a expansão e a modificação de sistemas já existentes”.[21] O processo de software pode ser dividido em 3 partes: definição, desenvolvimento e manutenção. A fase da definição busca definir o que o sistema vai fazer, sua interface e restrições. Já a fase de desenvolvimento define a arquitetura do sistema, a linguagem de programação a ser usada e como serão realizados os testes. Por fim, na fase da manutenção, podem ocorrer correções, mudanças e adaptações do sistema dependendo da necessidade do cliente. Normas e padrões de qualidade de processo de software foram criados para auxiliar na obtenção de qualidade do produto de software , pois é através da melhoria do processo de software que é obtida a qualidade do produto. Algumas das principais normas serão descritas a seguir. 2.1 CMM
O CMM (Capability Maturiry Model) foi criado em 1991 e procurava padronizar a qualidade dos software s desenvolvidos pela força aérea americana quando foi criado pela SEI.[2] [24] [25] O modelo é baseado nos princípios de qualidade total e no amadurecimento gradativo do processo de desenvolvimento do software dentro da empresa. Cada instituição é avaliada em um dos cinco níveis de maturidade, que estão divididos em áreas-chave dos temas que são abordados. As empresas que estão no nível 1, que é chamado de Inicial, podem obter software s de alta qualidade dependendo do desempenho dos desenvolvedores, mas a substituição da equipe pode prejudicar a qualidade. Os problemas maiores são gerenciais pois o processo é como uma caixa preta na visão do gerente, onde entram os requisitos e sai o sistema pronto, como ilustrado na 15
Figura 1. Neste nível não há área-chave.
Figura 1 – Nível 1 do CMM Fonte: [7]
As empresas do nível 2, nível Repetitivo, acompanham e documentam os métodos de gerenciamento para assegurar o cumprimento de prazos e custos. As práticas bem-sucedidas em outros projetos podem ser reaproveitadas. Nessa etapa, é possível visualizar o processo em certos pontos entre pequenas “caixas-pretas”, como visto na Figura 2. As áreas-chave são: •
Gerenciamento de requisitos;
•
Planejamento de projeto de software ;
•
Acompanhamento de projeto de software ;
•
Gerenciamento de subcontrato de software ;
•
Garantia de qualidade de software ;
•
Gerenciamento da configuração de software .
Figura 2 – Nível 2 do CMM Fonte: [7]
No nível 3 ou nível Definido, o processo de software é documentado, integrado e padronizado em processos padrão para a empresa e todos os projetos usam uma versão aprovada e adaptada para o seu 16
desenvolvimento e manutenção. A Figura 3 mostra que neste nível já é possível enxergar o que há dentro das “caixas-pretas”. Há sete áreas-chave: •
Enfoque no processo da organização;
•
Definição do processo da organização;
•
Programa de treinamento;
•
Gerenciamento integrado de software ;
•
Engenharia de produto de software ;
•
Coordenação intergrupos;
•
Revisão.
Figura 3 – Nível 3 do CMM Fonte: [7]
No nível 4, também conhecido como nível Gerenciado, tanto o processo quanto o produto de software são avaliados quantitativamente e avaliados por medições detalhadas, portanto o gerente tem bases para tomar decisões. As medições fornecem subsídios para atuar no próprio processo, como pode ser observado na Figura 4. Suas áreas-chave são: •
Gerenciamento quantitativo do processo;
•
Gerenciamento da qualidade de software .
Figura 4 – Nível 4 do CMM Fonte: [7] 17
A melhoria contínua do processo pertence ao nível 5 ou nível Otimizado. Essa melhoria pode ocorrer devido à realimentação quantitativa do processo e a partir de idéias e tecnologias novas, como mostra a Figura 5. As três áreas-chave do nível 5 são: •
Prevenção de defeito;
•
Gerenciamento de mudanças tecnológicas;
•
Gerenciamento de mudanças no processo.
Figura 5 – Nível 5 do CMM Fonte: [7]
Em 2001, foi lançada uma evolução do CMM, o CMMI, que pode ter duas representações: em estágio e contínua. A representação em estágio é similar à usada no CMM: define um conjunto de áreas de processo para melhoria, distribuídos em níveis de maturidade. A representação contínua permite que uma área de processo específica seja selecionada e a empresa melhore em relação a ela, usando níveis de capacidade para caracterizar a melhoria relacionada a essa área. 2.2 ISO/IEC 12207
A ISO/IEC 12207 teve seu processo de desenvolvimento iniciado em 1989, mas só foi aprovado em 1995. Seu objetivo é ajudar na definição dos papéis dos desenvolvedores de software , de forma a obter uma visão aperfeiçoada 18
para o usuário das operações realizadas. Essa norma propõe processos de ciclo de vida do software organizados em três classes[20]: •
Processos fundamentais: atendem desde a contratação do sistema até a manutenção do produto, passando por desenvolvimento e operação do mesmo. O ciclo de vida desses processos é composto por processo de aquisição, processo de fornecimento, processo de desenvolvimento, processo de operação e processo de manutenção;
•
Processos de apoio: são empregados para auxiliar na obtenção de qualidade de outros projetos. São eles: processo de documentação, processo de gerência de configuração, processo de garantia de qualidade, processo de verificação, processo de validação, processo de revisão conjunta, processo de auditoria e processo de resolução de problemas;
•
Processos organizacionais: são utilizados fora do domínio do projeto normalmente para a melhoria da organização. Esses processos são processo de gerência, processe de infraestrutura, processo de melhoria e processo de treinamento.
2.3 SPICE
O SPICE (Software Process Improvement and Capability dEtermination) ou ISO/IEC 15504 tem como objetivo gerar normas para avaliar processos, com o intuito de melhorar o processo continuamente e determinar sua capacitação.[25] O SPICE foi criado de forma que pudesse ser utilizado por especialistas que trabalham com as normas já existentes, mas sendo mais abrangente que elas. Há duas dimensões definidas nesse modelo: a dimensão de processo e a dimensão de capacidade. A primeira consiste em uma disposição de processos essenciais para a prática da engenharia de software , enquanto a segunda define um modelo de medição que obtenha a capacidade de um processo 19
de atingir seu objetivo. O SPICE tem como base o conceito de níveis de maturidade de processos do CMM e a arquitetura dos processos do ciclo de vida de um software da ISO/IEC 12207. O modelo define seis níveis de capacitação: •
Nível 0 – Incompleto: há uma falha geral em realizar o objetivo do processo. Não existem produtos de trabalho nem saídas do processo facilmente identificáveis;
•
Nível 1 – Executado: o objetivo do processo em geral é atingido, embora não necessariamente de forma planejada e controlada. Há um consenso na organização de que as ações devem ser realizadas e quando são necessárias. Existem produtos de trabalho para o processo e eles são utilizados para atestar o atendimento dos objetivos;
•
Nível 2 – Gerenciado: o processo produz os produtos de trabalho com qualidade aceitável e dentro do prazo. Isto é feito de forma planejada e controlada. Os produtos de trabalho estão de acordo com padrões e requisitos;
•
Nível 3 – Estabelecido: o processo é realizado e gerenciado usando um processo definido, baseado em princípios de Engenharia de Software . As pessoas que implementam o processo usam processos aprovados, que são versões adaptadas do processo padrão documentado;
•
Nível 4 – Previsível: o processo é realizado de forma consistente, dentro dos limites de controle, para atingir os objetivos. Medidas da realização do processo são coletadas e analisadas. Isto leva a um entendimento quantitativo da capacitação do processo a uma habilidade de prever a realização;
•
Nível 5 – Otimizado: a realização do processo é otimizada para atender às necessidades atuais e futuras do negócio. O
20
processo atinge seus objetivos de negócio e consegue ser repetido. São estabelecidos objetivos quantitativos de eficácia e eficiência para o processo, segundo os objetivos da organização. A monitoração constante do processo segundo estes objetivos é conseguida obtendo feedback quantitativo e o melhoramento é conseguido pela análise dos resultados. A otimização do processo envolve o uso piloto de idéias e tecnologias inovadoras, além da mudança de processos ineficientes para atingir os objetivos definidos. 2.4 Família ISO/IEC 9000
Na década de 80, as empresas utilizam TI em seus processos internos apenas para ter controle de qualidade dos produtos. A partir da década de 90, as instituições passaram a usar a TI em seus processos de negócios, com a finalidade de obter garantia de qualidade de processos. Em vista disso, foram lançadas as normas ISO 9001, 9002 e 9003 em 1987 com o objetivo de garantia de qualidade como requisitos entre clientes e fornecedores. Um ponto forte nessas normas é a flexibilidade, pois elas podem ser adaptadas ou complementadas para atender os requisitos específicos de cada setor produtivo. A ISO 9001 é a norma que abrange o ciclo de vida completo de um produto ou serviço, sendo que na mesma constam os requisitos para garantia de qualidade de produtos e serviços. A ISO 9000-3 foi publicada em 1994 e contém orientações para a aplicação da ISO 9001 em projeto, desenvolvimento, fornecimento, instalação e manutenção de software s. Ela é dividida em três partes: Estrutura, Atividades do Ciclo de Vida e Atividade de Suporte. A Estrutura apresenta os aspectos organizacionais em relação ao sistema de qualidade. São eles: responsabilidade gerencial, sistema de qualidade, auditoria interna de sistema de qualidade e ação corretiva. As Atividades do Ciclo de Vida são as próprias atividades relativas 21
ao desenvolvimento que são: revisão do contrato, especificação dos requisitos do cliente, planejamento de desenvolvimento, planejamento da qualidade, projeto e implementação, testes e validação, aceitação, reprodução, entrega, instalação e manutenção. Já a Atividade de Suporte dão apoio às atividades de desenvolvimento e são: gerência da configuração, controle da documentação, registros da qualidade, medições, regras, práticas e convenções, ferramentas e técnicas, compras, software produto incluso e treinamento.
22
3 QUALIDADE DE PRODUTO DE SOFTWARE
A qualidade de produto de software é baseada em normas que avaliam se o produto satisfaz o cliente e tem fácil manutenção. É o resultado direto das atividades realizadas no processo de desenvolvimento do software . Alguns exemplos de normas de qualidade de produto são as normas ISO/IEC 14598, 12119 e 9126. Essas normas serão expostas na seqüência, destacando-se a norma ISO/IEC 9126, enfoque desse trabalho. 3.1 ISO/IEC 14598
A ISO/IEC 14598 possui um conjunto de guias para orientar e planejar o processo de avaliação de um produto de software , como descrito a seguir e ilustrado na Figura 6: •
ISO/IEC 14598-1 – Visão Geral: contém a estrutura de funcionamento das normas para avaliação da qualidade de produto de software e a definição dos termos técnicos desse modelo. Possui também os conceitos e funcionamento de processo de avaliação de qualquer tipo de software para utilização de pessoas envolvidas em desenvolvimento e uso de tecnologia de avaliação e padronização;
•
ISO/IEC 14598-2 – Planejamento e Gerenciamento: são requisitos e guias para suportar funções de avaliação dos produtos de software , que estão relacionados ao desenvolvimento, aquisição, padronização, controle, transferência e realimentação do uso de tecnologias de avaliação;
•
ISO/IEC 14598-3 – Processo para Equipe de Desenvolvedores: norma para ser usada durante o desenvolvimento e manutenção do software . Fornece critérios para seleção de indicadores de qualidade, guia para avaliar dados de medição e guia para melhoria do processo 23
de medição; •
ISO/IEC 14598-4 – Processo para Compradores: norma para avaliação de produtos tipo pacote com objetivo de ajudar na aceitação de um produto ou selecionar entre diversos produtos tendo como base as características de qualidade da norma ISO/IEC 9126;
•
ISO/IEC 14598-5 – Processo para Avaliadores: possui orientações para a prática da avaliação do produto, definindo as atividades necessárias para analisar os requisitos de avaliação;
•
ISO/IEC 14598-6 – Módulo de Avaliação: define a estrutura e o conteúdo da documentação que será usada na descrição dos Módulos de Avaliação. Descreve e desenvolvimento e a validação dos módulos.
Figura 6 – Representação da norma ISO/IEC 14598 Fonte: [5]
24
3.2 ISO/IEC 12119
A norma ISO/IEC 12119 avalia produtos de software que estão disponíveis no mercado, conhecidos como Pacotes de Software ou Software de Prateleira. Essa norma estabelece os requisitos de qualidade e teste dos Pacotes de Software . O pacote que será testado deve possuir: •
Descrição do Produto: documento que define as propriedades do produto com o objetivo orientar compradores na avaliação de adequação do produto antes da aquisição do mesmo;
•
Manual do Usuário: conjunto de documentos fornecidos como parte integrante do produto e para a aplicação do mesmo;
•
Programa e Dados: conjunto completo de programas e dados necessários para a aplicação do produto de software e também como parte integrante do mesmo.
25
4 A NORMA ISO/IEC 9126
Em 1991, foi publicada a norma ISO/IEC 9126 contendo características e subcaracterísticas que definem um produto de qualidade. Em 1996, foi lançada sua tradução para o Brasil, chamada NBR 13596. Após as revisões e sucessivas melhorias foram criadas divisões dessa norma: •
ISO/IEC 9126-1: Modelo de Qualidade;
•
ISO/IEC 9126-2: Métricas Externas;
•
ISO/IEC 9126-3: Métricas Internas;
•
ISO/IEC 9126-4: Métricas de Qualidade em Uso.
A norma ISO/IEC 9126-1 apresenta um conjunto de características que definem um modelo de qualidade e podem ser aplicadas a qualquer produto de software . Esse modelo de qualidade é formado por duas partes: o Modelo de Qualidade Interna e Externa (Figura 7a) e o Modelo de Qualidade em Uso (Figura 7b). Para realizar a avaliação das características de qualidade externa são utilizadas as métricas externas, ou seja, medições baseadas nas necessidades do usuário, descritas na ISO/IEC 9126-2 (Figura 7c). Para a avaliação das características de qualidade interna são utilizadas as métricas internas, descritas na ISO/IEC 9126-3 (Figura 7d) e a norma ISO/IEC 9126-4 define métricas para a avaliação das características de qualidade em uso (Figura 7e).
26
Figura 7 – Representação da norma ISO/IEC 9126 e suas representações Fonte: Adaptação de [6]
Na seqüência serão detalhados o Modelo de Qualidade, as Métricas Externas, Internas e de Qualidade em Uso, citados acima. 4.1 ISO/IEC 9126-1: Modelo de Qualidade
Como descrito anteriormente, a norma ISO/IEC 9126-1 é formada por dois Modelos de Qualidade: o Modelo de Qualidade Interna e Externa e o Modelo de Qualidade em Uso. Esses dois modelos e suas respectivas características serão detalhados a seguir.
27
4.1.1 Modelo de Qualidade para Qualidade Interna e Externa Qualidade interna é a totalidade de características do produto de software na visão interna.[6] Ela é usada para especificar as propriedades do produto de software intermediário. Analogamente, a qualidade externa é a totalidade de características do produto de software do ponto de vista externo. É a qualidade que normalmente é avaliada quando o produto de software final está sendo testado. Como é possível visualizar na Figura 8, o modelo de qualidade para qualidade interna e externa possui definições de seis características básicas que um produto de software deve ter para ser considerado um software de qualidade: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.
Figura 8 – Características e Subcaracterísticas de Qualidade Externa e Interna Fonte: [6]
A primeira publicação da norma, em 1991, possuía apenas as características e subcaracterísticas de qualidade para avaliar um produto de software . Cada característica e subcaracterística está detalhada na seqüência, 28
sendo que o texto em itálico foi extraído da própria norma e representa a definição de cada uma das subcaracterísticas.[9] A funcionalidade descreve um conjunto de atributos que evidenciam a existência de um conjunto de funções, que satisfazem as necessidades explícitas ou implícitas, e suas propriedades especificadas. Suas subcaracterísticas são: •
Adequação: “Atributos do software que evidenciam a presença de um conjunto de funções e sua apropriação para as tarefas especificadas”;
•
Acurácia: “Atributos do software que evidenciam a geração de resultados ou efeitos corretos ou conforme acordados”;
•
Interoperabilidade: “Atributos do software que evidenciam sua capacidade de interagir com sistemas específicos”;
•
Conformidade: “Atributos do software que fazem com que ele esteja de acordo com as normas, convenções ou regulamentações previstas em leis e descrições similares, relacionadas à aplicação”;
•
Segurança de acesso: “Atributos do software que evidenciam sua capacidade de evitar o acesso não autorizado, acidental ou deliberado, a programas e dados”.
A confiabilidade possui um conjunto de atributos que evidenciam a capacidade do software de manter seu nível de desempenho sob condições estabelecidas durante um período de tempo estabelecido. As suas subcaracterísticas básicas são: •
Maturidade: “Atributos do software que evidenciam a freqüência de falhas ou defeitos no software”;
•
Tolerância a falhas: “Atributos do software que evidenciam sua capacidade em manter um nível de desempenho especificado nos casos de falhas no software ou de violação nas interfaces especificadas”;
•
Recuperabilidade: “Atributos do software que evidenciam sua
29
capacidade de restabelecer seu nível de desempenho e recuperar os dados diretamente afetados, em caso de falha, e no tempo e esforço necessários para tal”. O conjunto de atributos de usabilidade ou capacidade para uso evidencia o esforço necessário para poder-se utilizar o software , bem como o julgamento individual deste uso, por um implícito ou explícito de usuários. As subcaracterísticas são: •
Inteligibilidade: “Atributos do software que evidenciam o esforço do usuário para reconhecer o conceito lógico e sua aplicabilidade”;
•
Apreensibilidade: “Atributos do software que evidenciam o esforço do usuário para aprender sua aplicação (por exemplo: controle de operações, entradas, saídas)”;
•
Operacionalidade: “Atributos do software que evidenciam o esforço do usuário para sua operação e controle da operação”.
A característica da eficiência é constituída por um conjunto de atributos que verifica o relacionamento entre o nível de desempenho do software e a quantidade de recursos usados, mediante condições estabelecidas. Suas subcaracterísticas são: •
Comportamento em relação ao tempo: “Atributos do software que evidenciam seu tempo de resposta, tempo de processamento e velocidade na execução de suas funções”;
•
Comportamento em relação aos recursos: “Atributos do software que evidenciam a quantidade de recursos usados e a duração de seu uso na execução de suas funções”.
A manutenabilidade mostra os atributos que avaliam o esforço necessário para fazer modificações especificadas no software . Suas subcaracterísticas são: •
Analisabilidade: “Atributos do software que evidenciam o esforço necessário para diagnosticar deficiências ou causas 30
de falhas, ou para identificar partes a serem modificadas”; •
Modificabilidade: “Atributos do software que evidenciam o esforço necessário para modificá-lo, remover seus defeitos ou adaptá-lo a mudanças ambientais”;
•
Estabilidade: “Atributos do software que evidenciam o risco de efeitos inesperados, ocasionados por modificações”;
•
Testabilidade: “Atributos do software que evidenciam o esforço necessário para validar o software modificado”.
A portabilidade é a capacidade do software de ser transferido em um ambiente para outro. As subcaracterísticas são: •
Adaptabilidade: “Atributos do software que evidenciam sua capacidade de ser adaptado a ambientes diferentes especificados, sem a necessidade de aplicação de outras ações ou meios além daqueles fornecidos para essa finalidade pelo software considerado”;
•
Capacidade para ser instalado: “Atributos do software que o tornam consonante com padrões ou convenções relacionadas à portabilidade”;
•
Capacidade para substituir: “Atributos do software que evidenciam sua capacidade e esforço necessário para substituir um outro software, no ambiente estabelecido para este outro software”.
Uma revisão da norma foi feita anos mais tarde e novas subcaracterísticas foram incluídas a ela. Na característica usabilidade foi acrescentada a subcaracterística atratividade, que é a capacidade do produto de ser atraente para o usuário. Outra inclusão foi realizada na característica portabilidade, com a adição da subcaracterística de coexistência, que é a capacidade que o software tem de coexistir com outro software independente em um ambiente comum, compartilhando recursos comuns. A última modificação feita foi que em todas as características principais está presente a subcaracterística conformidade. Isso acontece pois em 31
todas as características é possível ser observada a aderência à legislação, padrões internos e normas diversas associadas a elas. Assim como as características principais, as subcaracterísticas não podem ser mensuradas diretamente, portanto elas são divididas em atributos mensuráveis selecionados pelo avaliador, como é exibido na Figura 9.
Figura 9 – Divisão das Características Fonte: [27]
É possível que um atributo tenha influência direta sobre mais de uma característica ou subcaracterística, porém elas não podem se sobrepor umas às outras. Por exemplo, o número de linhas de código pode ser usado como atributo tanto de analisabilidade quanto de adaptabilidade. Entretanto, a definição da característica de confiabilidade não permite que fatores próprios de manutenibilidade sejam considerados. Na aplicação da norma, deve-se definir quais características e subcaracterísticas serão mais importantes para o cliente e aplicá-los dando pesos maiores às mais relevantes. A norma ISO/IEC 9126 define bem as características e subcaracterísticas que podem ser utilizadas, entretanto os atributos mais específicos são definidos dependendo do interesse do usuário no produto de
32
software .
4.1.2 Modelo de Qualidade para Qualidade em Uso Qualidade em uso é a visão de qualidade sob a perspectiva do usuário e é medido pelo efeito do uso do software . O modelo de Qualidade para Qualidade em Uso faz a avaliação de quanto o usuário pode atingir seus objetivos em um ambiente, sem medir as propriedades do produto de software . Esse modelo possui quatro características de qualidade: Efetividade, Produtividade, Segurança e Satisfação, como destacado na Figura 10.
Figura 10 – Características de Qualidade em Uso Fonte: [27]
Cada uma das quatro características de Qualidade em Uso será descrita a seguir: •
Efetividade: capacidade do produto de software de permitir ao usuário atingir metas específicas com acurácia e completude, em um contexto de uso específico;
•
Produtividade: capacidade do produto de software de permitir que seus usuários empreguem quantidade adequada de
33
recursos em relação à efetividade alcançada em um contexto de uso específico; •
Segurança: capacidade do produto de software de apresentar níveis aceitáveis de riscos de danos a pessoas, negócios, software , propriedade ou ambiente em um contexto de uso específico;
•
Satisfação: capacidade do produto de software de satisfazer usuários em um contexto de uso específico.
4.2 Métricas
Para avaliar qualidade, é necessário que haja uma maneira de medí-la. Por isso, é preciso que se estabeleçam métricas. Para saber o valor de uma determinada característica de qualidade, tem que se criar uma métrica para quantificá-la e fazer uma medição para determinar a medida, que é o resultado da aplicação na métrica.[4] As métricas devem resultar em um valor matemático que verifique se o produto de software tem qualidade. Uma métrica pode ser definida como sendo toda particularidade quantificável do software que esteja relacionada a uma característica. Dependendo do produto analisado, diferentes métricas podem ser aplicadas. Porém essas métricas devem ser pertinentes ao paradigma e à tecnologia adotada no desenvolvimento. Sob o ponto de vista de medição, as métricas de software podem ser de dois tipos: diretas ou indiretas. As métricas diretas são realizadas em função dos atributos observados, normalmente determinados por contagem, como o custo, número de linhas de código, número de páginas e capacidade de memória, entre outros. As métricas indiretas são obtidas através de outras métricas, e entre seus exemplos estão funcionalidade, confiabilidade e complexidade. As métricas usadas pela norma ISO/IEC 9126 são consideradas métricas indiretas e são classificadas em três tipos: métricas externas, internas e de qualidade de uso.
34
Para obter qualidade em uso é preciso ter qualidade externa, que por sua vez é dependente de qualidade interna, como se observa na Figura 11.
Figura 11 – Relação entre Métricas Internas, Externas e de Qualidade em Uso Fonte: [6]
4.2.1 ISO/IEC 9126-2: Métricas Externas As métricas externas são usadas para avaliar o produto de software através de medições baseadas nas necessidades do usuário. Essas métricas usam medidas de um produto de software derivadas de medidas do comportamento do sistema do qual faz parte. As Tabelas 1, 2 e 3 exemplificam algumas métricas externas descritas na norma ISO/IEC 9126-2.[10]
35
Nome da métrica
Cobertura de implementação funcional
Propósito da métrica
Identificar a quantidade de funções que estão de acordo com a especificação
Medida e fórmula X=A/B A = número de funções corretamente implementadas, confirmadas através de execução de testes
Tipo de escala
Interpretação
A=quantidade
0 <= X <= 1 Quanto mais próximo de 1, melhor.
Tipo de medida
Absoluta
B=quantidade X=quantidade/ quantidade
B = número de funções descritas na especificação X = 1 - (A / B)
Especificação de estabilidade funcional (volatilidade)
Identificar a estabilidade da especificação funcional de um sistema correto depois de entrar em produção
A = número de funções mudadas depois de ter sido colocado em operação durante um período específico
A=quantidade
0 <= X <= 1 Quanto mais próximo de 1, melhor.
Absoluta
B=quantidade X=quantidade/ quantidade
B = número de funções especificadas Tabela 1 – Métricas Externas de Adequação
Nome da métrica
Propósito da métrica
Qual a freqüência em que o usuário Acurácia encontra computacional inacurácia em resultados que especificou
Medida e fórmula X=A/T
Interpretação
A = número de inacurácias de usuário encontradas
X >= 0
T = Tempo de operação
Quanto mais próximo de 0, melhor.
Tipo de escala
Tipo de medida A=quantidade
Absoluta
T = tempo X=quantidade/ tempo
Tabela 2 – Métrica Externa de Acurácia
36
Nome da métrica
Propósito da métrica
Medida e fórmula
Interpretaçã o
Tipo de escala
Tipo de medida
X=A/B Troca de dados (baseado no formato de dado)
Quão completas são as interfaces de função jusantes?
A = número de formatos de dados que estão aprovados para ser trocado com outro software ou sistema durante teste em dados para troca
A=quantidade
0 <= X <= 1 Quanto mais próximo de 1, melhor.
Taxa
B=quantidade X=quantidade/ quantidade
B = total de formatos de dados para troca X = 1 - (A / B) Troca de dados (baseado em tentativas bem sucedidas do usuário)
Consistência de interface padrão intersistema
Quão bem sucedidas são as transferências de dados de informação?
A = número de vezes que o usuário não conseguiu trocar tipos de dados com outro software ou sistema por motivos de falha
A=quantidade
0 <= X <= 1 Quanto mais próximo de 1, melhor.
Taxa
B=quantidade X=quantidade/ quantidade
B = número de vezes que o usuário tentou trocar dados X=A/B
O padrão para projeto de interface identificado na especificação segue consistenteme nte?
A = número de “checagem” de itens da interface de intersistema que estão aprovadas por teste, os quais são consistentes com padrões/regras do intersistema
A=quantidade
0 <= X <= 1 Quanto mais próximo de 1, melhor.
Taxa
B=quantidade X=quantidade/ quantidade
B = total de número de “checagem” de itens de interface de intersistema
Tabela 3 – Métricas Externas de Interoperabilidade
4.2.2 ISO/IEC 9126-3: Métricas Internas As métricas internas avaliam a especificação ou o código fonte de um produto de software . Podem ser usadas também em partes intermediárias do produto em desenvolvimento para garantir qualidade final. O principal objetivo das métricas internas é assegurar a qualidade externa e qualidade de uso.
37
As Tabelas 4, 5 e 6 exibem algumas métricas internas descritas na norma ISO/IEC 9126-2.[11]
Nome da métrica
Propósito da métrica
Medida e fórmula X=A/B
A = número de funções Proporção de implementadas Cobertura de implementação confirmadas implementação funcional na na revisão funcional revisão B = número de funções descritas na especificação X=A/B Proporção de Adequação da adequação da implementação implementação funcional funcional na revisão
A = número de funções com problemas que foram detectadas na revisão
Tipo de escala
Interpretação
A=quantidade
0 <= X <= 1 Quanto mais próximo de 1, mais completo.
Absoluta
B=quantidade X=quantidade/ quantidade
A=quantidade
0 <= X <= 1 Quanto mais próximo de 1, mais adequado.
Tipo de medida
Absoluta
B = número de funções revisadas
B=quantidade X=quantidade/ quantidade
Tabela 4 – Métricas Internas de Adequação
38
Nome da métrica
Acurácia computacional
Propósito da métrica
Proporção de figuras significantes que se combinam
Medida e fórmula X=A/B A = número de itens de dados que implementam figuras significantes especificadas confirmados na revisão
Tipo de escala
Interpretação
A=quantidade
0 <= X <= 1 Quanto mais próximo de 1, mais completo.
Absoluta
Precisão da acurácia
Proporção de precisão requerida para implementação
A=quantidade
0 <= X <= 1 Quanto mais próximo de 1, melhor.
B=quantidade X=quantidade/ quantidade
B = número de itens de dados que são especificados como figuras significantes X=A/B A = número de itens de dados que implementam o nível de precisão de acurácia especificada, confirmados pela revisão
Tipo de medida
Absoluta
B=quantidade X=quantidade/ quantidade
B = número de itens de dados especificados que requerem precisão de acurácia Tabela 5 – Métricas Internas de Acurácia
39
Nome da métrica
Propósito da métrica
Medida e fórmula
Interpretaçã o
Tipo de escala
Tipo de medida
X=A/B Capacidade de troca de dados (formatos básicos de dados)
Proporção de dados em formato compatível
A = número de formatos de dados que implementam consistência de formato confirmados pela revisão
0 <= X <= 1 Quanto mais próximo de 1, mais consistente.
A=quantidade Taxa
B=quantidade X=quantidade/ quantidade
B = total de formatos de dados para troca X=A/B
Consistência de interfaces (formatos básicos de interfaces)
Proporção de interfaces em formato compatível
A = número de formatos de interfaces que implementam consistência de formato confirmados pela revisão
A=quantidade
0 <= X <= 1 Quanto mais próximo de 1, melhor.
Taxa
B=quantidade X=quantidade/ quantidade
B = número de formatos de interface para troca X=A/B
Consistência de padrões intersistema
Proporção de padrões compatíveis
A = número de itens que implementam consistência com regras e padrões confirmados pela revisão
A=quantidade
0 <= X <= 1 Quanto mais próximo de 1, melhor.
Taxa
B = total de itens que são consistentes com regras e padrões
B=quantidade X=quantidade/ quantidade
Tabela 6 – Métricas Internas de Interoperabilidade
4.2.3 ISO/IEC 9126-4: Métricas de Qualidade em Uso Métricas de qualidade de uso medem quanto um produto de software atende às necessidades de um usuário específico. As medidas são obtidas pela observação do uso do produto ou por uma simulação de um ambiente real.
Através das tabelas 7, 8, 9, e 10 serão descritos alguns exemplos 40
de métricas de qualidade em uso segundo a ISO/IEC 9126-4, e as perguntas feitas para obter um valor.[12]
Nome da Métrica
Propósito da Métrica
Medida e Fórmula M1=|1-ΣAi|
Efetividade da tarefa
Que proporção da tarefa é completada corretamente?
Completude Que proporção de tarefas é da tarefa completada?
A = valor proporcional de cada item perdido ou incorreto no resultado da tarefa X=A / B A = número de tarefas completadas B = total de tarefas testadas X=A / T
Freqüência de erro
A = número de Qual a freqüência erros tomados pelo de erros? usuário T = tempo ou número de tarefas
Interpretação
Tipo de Escala
Tipo de Medida
-
A=?
0 <= M1 <= 1 Quanto mais próximo de 1, melhor.
A=quantidade
0 <= X <= 1 Quanto mais próximo de 1, melhor.
Taxa
B=quantidade X=quantidade/ quantidade
0 <= X Quanto mais próximo de 0, melhor.
Absoluta
A=quantidade
Tabela 7 – Métricas de Efetividade
41
Nome da Métrica
Propósito da Métrica
Medida e Fórmula
Interpretação
Tipo de Tipo de Medida Escala
X = Ta / Tb Tempo da tarefa
Eficiência da tarefa
Quanto tempo demora-se para completar uma tarefa?
Quão eficientes são os usuários?
Ta = tempo ocioso do usuário Tb = tempo da tarefa X = M1 / T M1 = efetividade da tarefa T = tempo da tarefa X = M1 / C
Custo efetivo
Proporção produtiva
Grau de eficiência do usuário
M1 = efetividade da tarefa
Qual o custo efetivo do usuário?
C = custo total da tarefa X = Ta / Tb
Que proporção do tempo o usuário está realizando ações produtivas?
Ta = tempo produtivo Tb = tempo da tarefa X=A/B
Quão eficiente é A = eficiência de um um usuário usuário comum comparado a um especialista? B = eficiência de um usuário especializado X=A/B
Quão produtivo é Grau de um usuário produtividade comparado a um do usuário especialista?
A = produtividade de um usuário comum B = produtividade de um usuário especializado
X >= 0 Quanto menor, Intervalo melhor. X >= 0 Quanto maior, melhor.
-
X >= 0 Quanto maior, melhor.
Absoluta
T = tempo X=
T = tempo X= Ta = tempo
0 <= X <= 1 Quanto mais próximo de 1, melhor.
T = tempo
Absoluta
Tb = tempo X = tempo/ tempo
0 <= X <= 1 Quanto mais próximo de 1, melhor.
Absoluta
X=A/B
Absoluta
X=A/B
0 <= X <= 1 Quanto mais próximo de 1, melhor.
Tabela 8 – Métricas de Produtividade
42
Nome da Métrica
Bem-estar do usuário
Propósito da Métrica Qual é a incidência de problemas de saúde entre os usuários do produto?
Medida e Fórmula
Danos econômicos
A = número de usuários com LER, fadiga ou dor-decabeça
A = número de ocorrências de danos econômicos B = total de situações medidas X= A / B
Danos no software
Qual a incidência de danos no software ?
Quanto mais próximo de 0, melhor.
Absoluta
A = número de ocorrências de danos no software B = total de situações medidas
A=quantidade Absoluta
A=quantidade Absoluta
A=quantidade Absoluta
B=quantidade X=quantidade/ quantidade A=quantidade
0 <= X <= 1 Quanto mais próximo de 0, melhor.
B=quantidade X=quantidade/ quantidade
0 <= X <= 1 Quanto mais próximo de 0, melhor.
B=quantidade X=quantidade/ quantidade
0 <= X <= 1 Quanto mais próximo de 0, melhor.
B=quantidade X=quantidade/ quantidade
0 <= X <= 1 Quanto mais próximo de 0, melhor.
Tipo de Medida A=quantidade
0 <= X <= 1
B = total de usuários X= A / B
Qual a incidência A = número de pacientes com de perigo para o tratamento prescrito paciente que recebe tratamento incorretamente pelo sistema? B = total de pacientes X= A / B Qual a incidência de danos econômicos?
Tipo de Escala
X= A / B
Qual o nível de A = número de Segurança perigo incidente pessoas colocadas das pessoas às pessoas em perigo afetadas afetadas pelo uso pelo sistema B = total de pessoas do sistema? afetadas pelo sistema X= A / B Segurança dos pacientes
Interpretação
Absoluta
B=quantidade X=quantidade/ quantidade
Tabela 9 – Métricas de Segurança
43
Nome da Métrica
Propósito da Métrica
Medida e Fórmula Interpretação Tipo de Escala X= A / B
Escala de satisfação
Qual o nível de satisfação do usuário?
A = questionário com escala psicométrica B = média da população
Pesquisa de satisfação
Qual o nível de satisfação do usuário em funções específicas?
X =A A = resultado da pesquisa
X>0 Quanto maior, melhor. Comparação com valores anteriores ou com a média da população.
Taxa
Ordinal
Tipo de Medida A=quantidade X=quantidade
A=quantidade X=quantidade
X= A / B
Uso discreto do produto
A = número de Qual proporção vezes que a função, 0 <= X <= 1 dos usuários aplicação ou Quanto mais potenciais optou sistema é usado próximo de 1, pelo sistema? melhor. B = número que o usuário teve a intenção de usar
A=quantidade Taxa
B=quantidade X=quantidade/ quantidade
Tabela 10 – Métricas de Satisfação
44
5 PROCESSO DE AVALIAÇÃO
A avaliação de um software pode ser realizada para aquisição, fornecimento, desenvolvimento, operação ou manutenção de produtos finais ou intermediários. O processo de avaliação de um produto de software é dividido em três partes: definição de requisitos de qualidade, preparação da avaliação e procedimento da avaliação.[26] 5.1 Definição de Requisitos de Qualidade
Esse estágio do processo de avaliação consiste em definir as características e possíveis subcaracterísticas que serão usadas na avaliação. O modelo da ISO/IEC 9126-1 é o mais utilizado conjuntamente com o processo de avaliação da ISO/IEC 14598.[16] 5.2 Preparação da Avaliação
Este estágio busca preparar as bases para realizar a avaliação. É dividido em três fases: seleção de métricas, estabelecimento dos níveis de pontuação e definição dos critérios de julgamento. A fase de seleção de métricas depende da parte interessada na avaliação, que pode ser: •
Desenvolvedor: procura uma visão de atributos de qualidade interna e externa para a aplicação aos produtos de software , onde os atributos internos devem representar a qualidade externa ao longo do desenvolvimento;
•
Adquirente: avalia o produto através das métricas externas e de qualidade em uso, podendo haver avaliações preliminares informais, como observação de usuários e documentação.
45
•
Avaliação por terceira parte: analisa a descrição do produto, especifica as medições que devem ser executadas no produto e seus componentes e verificar a especificação produzida em relação aos requisitos de avaliação.
No estabelecimento dos níveis de pontuação são estabelecidas as metas para cada métrica, como na Figura 12.
Figura 12 – Valor satisfatório
Na fase de definição dos critérios de julgamento, são mapeados os resultados das métricas para uma escala, definidos os pesos para as características e subcaracterísticas avaliadas e calculadas médias ponderadas usando os valores das métricas e os pesos das respectivas características e subcaracterísticas. 5.3 Procedimento da Avaliação
Este último estágio da avaliação também possui três fases: obtenção das medidas, comparação dos critérios e julgamento dos resultados. Na obtenção das medidas, aplicam-se as métricas selecionadas ao produto de software , obtendo como resultado os valores nas escalas das métricas. Na comparação de critérios, o valor medido é comparado aos critérios predeterminados. Por fim, na fase de julgamento de resultados, um conjunto de níveis 46
de pontuação é sintetizado e comparado com outros aspectos como tempo e custo. O resultado permitirá a decisão gerencial quanto à aceitação ou rejeição, ou quanto à liberação ou não-liberação do produto de software . 5.4 Um Exemplo de Aplicação
Para exemplificar o Processo de Avaliação descrito será feita uma avaliação de qualidade em sites de Instituições de Ensino Superior sob o ponto de vista do usuário. Para realizar a medição, serão usados os critérios descritos na norma ISO/IEC 9126-1, com as características de qualidade em uso: efetividade, produtividade, satisfação e segurança. As métricas usadas serão algumas das descritas na norma ISO/IEC 9126-4, que medem os efeitos do uso do software em um contexto específico de uso. Para cada característica, será avaliada apenas uma métrica. O objetivo do usuário é obter informações sobre os cursos de graduação: cursos oferecidos, ementas, estrutura curricular e corpo docente. O resultado da avaliação é mostrado no Quadro 1. Os níveis de pontuação foram definidos como satisfatório ou insatisfatório. Para um produto ser considerado aceitável, é necessário que ele tenha pelo menos 80% de resultados satisfatórios nas avaliações, proporção que é definida pelo avaliador dependendo das suas necessidades.
47
Definição de Requisitos de Qualidade Característica
Preparação da Avaliação
Seleção de métrica
Níveis de pontuação
Critérios de julgamento
Procedimento da Avaliação
Obtenção das medidas UEL
Efetividade
Freqüência de erros
S - Satisfatório (sem erros) I - Insatisfatório (um ou mais erros)
Aceitável (80% S)
UNOPAR
Rejeitado IESB
UEL
Produtividade
Tempo das tarefas
S - Satisfatório (tempo <= 10 s) I - Insatisfatório (tempo > 10 s)
Aceitável (80% S)
UNOPAR
Rejeitado IESB
UEL
Segurança
Danos no software
S - Satisfatório (sempre disponíveis) I - Insatisfatório (alguma vez indisponível)
Aceitável (80% S)
UNOPAR
Rejeitado
IESB
UEL
Satisfação
Escala de Satisfação
S - Satisfatório (todas as informações) I - Insatisfatório (falta alguma informação)
Aceitável (80% S)
UNOPAR
Rejeitado IESB
9S 1I 8S 2I 8S 2I 7S 3I 6S 4I 9S 1I 10 S 0I 10 S 0I 10 S 0I 9S 1I 5S 5I 5S 5I
Comparação dos critérios
Julgamento dos resultados
80%
Aceitável
80%
Aceitável
80%
Aceitável
70%
Rejeitado
60%
Rejeitado
90%
Aceitável
100%
Aceitável
100%
Aceitável
100%
Aceitável
90%
Aceitável
50%
Rejeitado
50%
Rejeitado
Quadro1 – Avaliação de sites Institucionais
48
CONCLUSÃO Este trabalho teve o objetivo de expor as normas e padrões que proporcionam Qualidade de Software na fase de desenvolvimento através das normas de Qualidade de Processo, assim como as normas e padrões que avaliam a qualidade do produto já finalizado, através das normas de Qualidade de Produto. O detalhamento ocorreu na norma de Qualidade de Produto de Software ISO/IEC 9126, onde suas divisões foram mostradas. Com isso, foi possível perceber que há maneiras efetivas de verificar se um produto de software é adequado aos diferentes tipos de usuário e suas respectivas necessidades, pois a norma possibilita, através da utilização de métricas, avaliar diferentes características de um mesmo produto.
49
REFERÊNCIAS BIBLIOGRÁFICAS [1] KOSCIANSKI, A.; VILLAS-BOAS, A.; REGO, C. M.; ASANOME, C.; SCALET, D.; ROMERO, D.; CIESLAK, J. M.; PALUDO, M.; FROSSARD, R. S.; VOSTOUPAL, T. M. Guia para Utilização das Normas Sobre Avaliação de Qualidade de Produto de Software – ISO/IEC 9126 e ISO/IEC 14598 .
[2] TSUKUMO, A. N.; REGO, C. M.; SALVIANO, C. F.; AZEVEDO, G. F.; MENEGHETTI, L. K.; COSTA, M. C. C.; CARVALHO, M. B.; COLOMBO, R. M. T. Qualidade de Software: Visões de Produto e Processo de Software . Publicado na II Escola Regional de Informática da Sociedade Brasileira de Computação Regional de São Paulo – Piracicaba, SP. Junho de 1997.
[3] VOLPE, R. L. D.; JOMORI, S. M.; ZABEU, A. C. P. CMM – CMMI: Principais conceitos, diferenças e correlações . Spin-BH, 30 de outubro de 2003.
[4] DUARTE, K. C.; FALBO, R. A. Uma Ontologia de Qualidade de Software .
[5] TELES, F. S. Um Processo para Análise de Desempenho de Produtos de Software . Recife, 11 de março de 2005.
[6] MACHADO, M. P.; SOUZA, S. F. Métricas e Qualidade de Software .
[7] ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade de software. 1a Edição. São Paulo: Prentice Hall, 2001.
[8] PRESSMAN, R. S. Engenharia de software , Tradução da 5a Edição. São Paulo: Mc Graw Hill, 2002
[9] ISO/IEC 9126-1: 2000. Software engineering– Software product quality - Part 1: Quality Model.
50
[10] ISO/IEC 9126-2: 2000. Software engineering– Software product quality - Part 2: External Metrics.
[11] ISO/IEC 9126-3: 2000. Software engineering– Software product quality - Part 3: Internal Metrics.
[12] ISO/IEC 9126-4: 2000. Software engineering– Software product quality - Part 4: Quality in Use Metrics.
[13] WINTER, L. A.; CORDENONZI, W. Avaliação de Qualidade de Software Educacional .
[14] SCALET, D. O Modelo da ISO/IEC JTC1/SC7 para a Avaliação de Produto de Software . Disponível em . Acesso em Maio de 2006.
[15] BEVAN, N. ISO and Industry Standards for User Centred Design . Outubro de 2000. Disponível em .
[16] Seminário de Qualidade de Software do Subcomitê de Software da ABNT. Modelo de Qualidade e Usabilidade de Software . Agosto de 2001.
[17] CORDEIRO, M. A. Métricas de Software . – Bate byte 101 – Setembro de 2000.
[18] VASCONCELOS, A. Introdução a Métricas de Software . 2005
[19] KOSCIANSKI, A.; SOARES, M. S. Qualidade de Software . 1a Edição. Editora Novatec.
[20] WEBER, K. Qualidade e Produtividade em Software . 3a Edição. Editora Makron.
51