Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
FERRAMENTA DE APOIO AO PROCESSO DE AVALIAÇÃO DE
PRODUTO DE SOFTWARE
Área de Engenharia de Software
por
Eduardo Vieira
Fabiane Barreto Vavassori Benitti, Dr.
Orientadora
Itajaí (SC), março de 2012
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
FERRAMENTA DE APOIO AO PROCESSO DE AVALIAÇÃO DE
PRODUTO DE SOFTWARE
Área de Engenharia de Software
por
Eduardo Vieira
Relatório apresentado à Banca Examinadora do
Trabalho de Conclusão do Curso de Ciência da
Computação para análise e aprovação.
Orientadora: Fabiane Barreto Vavassori Benitti,
Dr.
Itajaí (SC), março de 2012
ii
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................. iv
LISTA DE FIGURAS ................................................................................. v
LISTA DE TABELAS ............................................................................... vi
RESUMO ................................................................................................... vii
ABSTRACT .............................................................................................. viii
1. INTRODUÇÃO ...................................................................................... 1
1.1 OBJETIVOS ........................................................................................................ 4
1.1.1 Objetivo Geral ................................................................................................... 4
1.1.2 Objetivos Específicos ........................................................................................ 4
1.2 METODOLOGIA ................................................................................................ 5
1.3 ESTRUTURA DO TRABALHO ....................................................................... 6
2. FUNDAMENTAÇÃO TEÓRICA ...................................................................... 7
2.1 QUALIDADE DE SOFTWARE ........................................................................ 7
2.2 NORMAS DE QUALIDADE ISO/IEC ............................................................. 8
2.2.1 ISO/IEC 9126 – Qualidade dos produtos de software ................................. 10
2.2.2 ISO/IEC 14598 – Avaliação dos Produtos de Software ............................... 14
2.2.3 ISO/IEC 14598-5 – Processo para avaliadores ............................................ 16
2.2.4 ISO/IEC 14598-6 – Documentação de módulos de avaliação ..................... 18
2.2.5 Relacionamento das normas ISO/IEC 9126 e ISO/IEC 14598 ................... 19
2.2.6 ISO/IEC 12119 – Pacotes de Softwares – Testes e requisitos de Qualidade
20
2.2.7 SQUARE 25000 ............................................................................................... 22
2.3 MÉTODOS DE QUALIDADE ......................................................................... 25
2.3.1 MEDE-PROS ................................................................................................... 26
2.3.1.1 Documentação MEDE-PROS ................................................................. 26
3. TRABALHOS CORRELATOS ....................................................................... 28
4. Desenvolvimento ................................................................................... 36
4.1 Processo Proposto ...................................................................... 36
4.1.1 Detalhamento das atividades ......................................................................... 39
4.1.2 Papéis ................................................................................................................ 42
4.1.3 Artefatos ........................................................................................................... 42
4.1.4 Relação das Normas Atendidas pelo Processo Proposto ............................. 44
4.2 Projeto ......................................................................................... 46
4.2.1 Definição dos Requisitos e Regras de Negócio ............................................. 46
4.2.2 Modelos de Caso de Uso ................................................................................. 49
4.2.3 Modelagem Entidade Relacionamento ......................................................... 50
iii
4.3 Telas do Sistema ........................................................................ 51
4.4 Avaliação da Ferramenta ......................................................... 61
4.4.1 Planejamento da Avaliação ...................................................... 61
4.4.2 Resultados da avaliação ............................................................ 65
4.4.2.1 Resultados da avaliação do produto de software .................................. 65
4.4.2.2 Resultados da avaliação da ferramenta de apoio .................................. 65
5. Conclusão .............................................................................................. 66
5.1 TRABALHOS FUTUROS ................................................................................ 67
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 68
APÊNDICE A – DETALHAMENTO DOS CASOS DE USO ............. 72
APÊNDICE B – DICIONÁRIO DE DADOS DO MODELO ER ....... 79
APÊNDICE C – TELAS DO SISTEMA ............................................... 82
APÊNDICE D – MODELO E LAYOUT DO CHECKLIST DE
AVALIAÇÃO PARA IMPORTAÇÃO .................................................. 85
APÊNDICE E – CHECKLIST DE AVALIAÇÃO DO PRODUTO DE
SOFTWARE OLQR – ONLINE QUICK REPORT ............................ 86
APÊNDICE F – QUESTIONÁRIO DE AVALIAÇÃO DA
FERRAMENTA DE APOIO PARA OS AVALIADORES ................. 87
APÊNDICE G – RELATÓRIO FINAL DE AVALIAÇÃO DO
PRODUTO DE SOFTWARE OLQR ..................................................... 88
iv
LISTA DE ABREVIATURAS
ABNT Associação Brasileira de Normas Técnicas
AJAX Asynchronous Javascript and XML
CenPRA Centro de Pesquisa Renato Archer
COTS Commercial off-the-shelf
ERP Planejamento de Recursos Empresariais
GQM Goal Question Metric
IEC International Electrotechnical Commission
IEEE Institute of Electrical and Electronics Engineers
INPI Instituto Nacional de Propriedade Industrial
ISO International Organization for Standardization
JTC Joint Technical Committees
MCT Ministério da Ciência e Tecnologia
MEDE-PROS O Método de Avaliação de Qualidade de Software
MFAQS Modelo fuzzy para avaliação de qualidade de software
MR Modelo de requisitos
NBR Norma Brasileira
PBQP-Software Programa Brasileiro da Qualidade e Produtividade
RRBT Risk & Requirement Base Testing
SEPIN Secretaria de Política em Informática
SQuaRE Software Product Quality Requirements and Evalution
SWEBOK Software Endy gineering Body Of Knowledge
TCC Trabalho de Conclusão de Curso
UNIVALI Universidade do Vale do Itajaí
v
LISTA DE FIGURAS
Figura 1. Distribuição das organizações de acordo com a utilização de Normas para requisitos de
qualidade de software (valor percentual). .................................................................................. 10 Figura 2. Avaliação segundo norma ISO/IEC 9126 ........................................................................... 10 Figura 3. Processo de avaliação segundo a norma 14598-1. .............................................................. 14 Figura 4. Relacionamento das normas ISO/IEC 14598 ..................................................................... 16 Figura 5. Relacionamento entre as séries de normas ISO/IEC 9126 e 14598. ................................... 20
Figura 6. Estrutura da norma 12119. .................................................................................................. 22 Figura 7. Arquitetura dos documentos que compõem a série de normas SquaRE ............................. 23 Figura 8. Estrutura da lista de verificação de um método de avaliação (MEDE-PROS) ................... 27
Figura 9. Modelo detalhado do método MEDE-PROS. ..................................................................... 28 Figura 10. Tela de cadastro de avaliação da ferramenta web. ............................................................ 31 Figura 11. Processo de avaliação de portabilidade ............................................................................ 32 Figura 12. Processo da Framework de especialização ....................................................................... 33
Figura 13. Processo de avaliação AdeQuas. ...................................................................................... 34 Figura 14. Processo proposto ............................................................................................................. 38 Figura 15. Casos de Uso Módulo Fornecedor e Coordenador ........................................................... 49 Figura 16. Casos de uso módulo avaliador ........................................................................................ 50
Figura 17. Modelagem entidade relacionamento ............................................................................... 51 Figura 18. Acesso ao sistema ............................................................................................................. 52
Figura 19. Cadastro de Coordenador .................................................................................................. 52 Figura 20. Cadastro de produto de software ...................................................................................... 53
Figura 21. Requisitos da avaliação ..................................................................................................... 54 Figura 22. Gerenciar check-list .......................................................................................................... 54
Figura 23. Cadastro de escala ............................................................................................................. 55 Figura 24. Gerar plano de avaliação ................................................................................................... 55 Figura 25. Acompanhar avaliação ...................................................................................................... 56
Figura 26. Avaliar produto ................................................................................................................. 57 Figura 27. Gerar relatório parcial ....................................................................................................... 58 Figura 28. Liberar relatório parcial .................................................................................................... 59
Figura 29. Visualizar relatório final ................................................................................................... 60 Figura 30. OLQR - Online Quick Report ........................................................................................... 62
Figura 31. Etapas e atividades da avaliação ....................................................................................... 64 Figura 32. Gerenciar Coordenador ..................................................................................................... 82
Figura 33. Cadastro de avaliador ........................................................................................................ 82 Figura 34. Cadastro de fornecedor ..................................................................................................... 83 Figura 35. Gerenciar check-list .......................................................................................................... 83
Figura 36. Acompanhar avaliação ...................................................................................................... 84 Figura 37. Modelo e layout do checklist de avaliação ....................................................................... 85
vi
LISTA DE TABELAS
Tabela 1. Características e subcaracterísticas do software. ................................................................ 12
Tabela 2. Protocolo da busca .............................................................................................................. 29 Tabela 3. Trabalhos Correlatos .......................................................................................................... 30 Tabela 4. Comparativo trabalhos correlatos ....................................................................................... 35 Tabela 5. Elementos do diagrama de atividade .................................................................................. 37 Tabela 6. Detalhamento das atividades .............................................................................................. 39
Tabela 7. Relação das normas atendidas quando comparadas ao processo ....................................... 44 Tabela 8. UC01. Login ....................................................................................................................... 72 Tabela 9. UC02 Cadastrar Coordenador ............................................................................................ 72
Tabela 10. UC03 Cadastrar Fornecedor ............................................................................................. 72 Tabela 11. UC04 Cadastrar dados do produto ................................................................................... 72 Tabela 12. UC05 Definir os requisitos da avaliação .......................................................................... 73 Tabela 13. UC06 Acompanhar avaliação ........................................................................................... 73
Tabela 14. UC07 Cadastrar escala ..................................................................................................... 73 Tabela 15. UC08 Definir check-list da avaliação .............................................................................. 74 Tabela 16. UC09 Cadastrar avaliador ................................................................................................ 76 Tabela 17. UC10 Gerar plano da avaliação ........................................................................................ 76
Tabela 18. UC11 Avaliar o produto ................................................................................................... 76 Tabela 19. UC12 Gerar o relatório parcial ......................................................................................... 77
Tabela 20. UC13 Gerar o relatório final ............................................................................................ 78 Tabela 21. Dicionário de dados do modelo ER .................................................................................. 79
vii
RESUMO
VIEIRA, Eduardo. Ferramenta de apoio a avaliação de produto de software. Itajaí, 2012. 105 f.
Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências
Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2012.
As empresas estão se tornando cada vez mais dependentes de tecnologia, resultando em processos
internos conduzidos e direcionados por um crescente número de sistemas informatizados. Esta
tendência é natural e representa a realidade das empresas na sobrevivência de um mercado cada vez
mais competitivo, no qual as corporações procuram a tecnologia para reduzir custos, ganhar
eficiência, melhorar processos e expandir sua forma de atuação. Nestas condições, todo o processo
de desenvolvimento de software cresce de maneira proporcional ao das corporações, aumentando os
riscos de falhas e tornando-se complexo desenvolver ferramentas com um “nível de qualidade”
aceitável. A partir deste cenário, este trabalho aborda o tema "qualidade de produto de software",
que tem como principal objetivo garantir a qualidade nos resultados obtidos no processo de
desenvolvimento. A qualidade de produto de software é fundamentada na série de normas ISO/IEC
9126, 14598, 12119 e mais recentemente a SQuaRE 25000. No Brasil, o CenPRA (Centro de
Pesquisas Renato Archer) desenvolveu o MEDE-PROS, um método de avaliação de qualidade de
produto de software que ganhou destaque nos últimos anos. A partir deste método e das normas
ISO/IEC, propõe-se neste projeto a específicação de um processo para avaliação de qualidade de
produtos de software e, com base neste processo, construir uma ferramenta de apoio. O sistema foi
desenvolvido com o objetivo de flexibilizar o processo de avaliação de software de acordo com as
necessidades do avaliador e do requisitante da avaliação, contemplando o apoio automatizado a
todas as etapas do processo. Outro fator importante que embasa a construção desta ferramenta é a
indisponibilidade dos softwares existentes para uso acadêmico ou comercial. A ferramenta foi
desenvolvida em tecnologia web, buscando uma maior independência de plataforma, priorizando a
portabilidade, e facilitando o acesso simultâneo por vários usuários.
Palavras-chave: Engenharia de software. Qualidade de Produto de Software. Ferramenta de apoio.
viii
ABSTRACT
The companies are becoming more and more dependent of technology, resulting in internal process
managed and directed by an increasing number of computerized systems. This tendency is natural,
and it represents the reality of companies in the survival of an increasingly competitive market,
where corporations seek the technology to reduce costs,gain efficiency, improve processes and
expand the way it operates. In these conditions, all the process of software development is growing
proportionally to the corporations, increasing the risks of faults and becoming complex to develop
tools with a"quality level" acceptable. From this backdrop, we address the theme of "product
quality" software, which has the main objective to ensure quality results obtained in the
development process. The quality of software product is founded on the series of standards ISO/IEC
9126, 14598, 12119 and more recently the SQuaRE 25000. In Brazil, the CenPRA (Renato Archer
Research Center) developed the MEDE-PROS, a method for evaluating the quality of software
product, which has gained prominence in recent years. From these concepts, this project is to
propose the specification of a new process for evaluating the quality of software products and,
based on this process, build a support tool. The system will be developed with the goal of flexibility
in the process of evaluating the software based on the requirements of the evaluator and the
evaluation of the requester as well as includes automated support in the final stage of the
process.Another important factor that supports the construction of that tool is the unavailability of
existing software for academic or commercial use, and the availability of source code. The software
will be developed in web technology, seeking greater platform independence, emphasizing
portability, and facilitating access by multiple users simultaneously.
Keywords: Software engineering. Software Product Quality. Tool support.
1. INTRODUÇÃO
A idéia de qualidade pode parecer muito intuitiva a princípio, porém, Koscianski e Soares
(2007) afirmam que “A qualidade é relativa. O que é qualidade para uma pessoa pode ser falta de
qualidade para outra”. Qualidade de Software é uma área da Engenharia de Software que visa
assegurar que necessidades explícitas e implícitas façam parte do produto de software, o resultado
da qualidade é obtido através de definições e normatizações de processos de desenvolvimento
(GUERRA; COLOMBO, 2009). É praticamente impossível obter qualidade em um software
construído através de processos falhos e deficientes de desenvolvimento, neste caso, tem-se duas
dimensões fundamentais para a qualidade de software: dimensão da qualidade do processo e
dimensão da qualidade do produto (BARTIÉ, 2002).
Segundo Bartié (2002), a qualidade do processo visa garantir a qualidade no ciclo de
desenvolvimento do software, englobando todas as atividades que focam na garantia de qualidade e
permitindo que a maioria dos artefatos gerados tenha um procedimento de avaliação da qualidade.
A qualidade do produto de software tem como principal objetivo garantir a qualidade nos
resultados obtidos no processo de desenvolvimento e, de um modo geral, engloba atividades
destinadas a estressar telas e funcionalidades do sistema (BARTIÉ, 2002). Na avaliação da
qualidade do produto de software, espera-se atingir todas as características implícitas e explícitas da
ferramenta, entende-se por características explícitas todos os requisitos definidos pelo usuário, e
necessidade implícita como as características desejáveis para o sistema, como por exemplo o
desempenho do sistema e até mesmo o cumprimento do cronograma (GUERRA; COLOMBO,
2009).
Para Koscianski e Soares (2007) uma questão básica da qualidade do software é ter
claramente os objetivos que se espera alcançar com o projeto. Para obter tais objetivos é preciso
definir e enumerar qualidades desejáveis, de preferência dados quantitativos, que meçam uma série
de características do software. “As medidas também podem ser usadas para uma definição mais
precisa de requisitos, fixando-se no início do projeto os valores desejados para o produto final”
A qualidade de produto de software é fundamentada na série de normas ISO/IEC 9126,
14598, 12119 e mais recentemente a SQuaRE 25000. A ISO (International Organization for
Standardization) foi criada para definir padrões internacionais e surgiu da necessidade das empresas
em exportarem suas mercadorias e serviços, facilitando o intercâmbio destes itens entre os países.
(GUERRA; COLOMBO, 2009).
2
Koscianski e Soares (2007, p. 204) dizem que uma das mais importantes normas para
caracterização e medição de qualidade de produto de software é a SQuaRE ISO/IEC 25000.
SQuaRE significa Software Product Quality Requirements and Evaluation (Requisitos de
Qualidade e Avaliação de Produtos de Software) e constitui uma revisão e melhoria das normas ISO
9126 e ISO 14598, ambas tratam da qualidade do produto de software. (KOSCIANSKI; SOARES,
2007).
A norma 9126 define um modelo para qualidade do produto e os instrumentos necessários,
apresentando uma série de documentos para comparar dados qualitativos e quantitativos de
qualidade. A ISO 14598 procura abranger os aspectos “gerenciais” de uma empresa, sugerindo uma
metodologia precisa e documentações indispensáveis que são estudadas por diferentes níveis, como
usuário e desenvolvedor. A norma ISO/IEC 12119 é aplicável a pacotes de softwares
(processadores de texto, planilhas eletrônicas, banco de dados, entre outros) e estabelece os
requisitos de qualidade e instruções de como testar um pacote de software com base nos requisitos
estabelecidos. (KOSCIANSKI; SOARES, 2007).
A SQuaRE surgiu com o objetivo de obter maior clareza nas normas de qualidade de
produto, o processo de transição entre as normas 9126 e 14598 foi lenta e trabalhosa onde iniciou-se
um processo de revisão e melhoria das duas normas e posteriormente a implementação da série
25000. (GUERRA; COLOMBO, 2009).
Existe uma gama de entidades de pesquisa em tecnologia da informação que dedicam
esforços para aprimorar a melhoria da qualidade de Software produzido no Brasil. O NAPS (Núcleo
de Avaliação de Produtos de Software), criado pela empresa CELEPAR (Companhia Elétrica do
Estado do Paraná) em parceria com a CITS (Centro de Internacional de Campinas), tem como
objetivo avaliar a qualidade de produtos de software desenvolvidos pela empresa e por terceiros. O
Prêmio ASSESPRO, que tem por objetivo incentivar as empresas de software a melhorar a
qualidade de seus produtos foi criado pela ASSESPRO (Associação Brasileira de Software e
Serviços de Informática). O CenPRA (Centro de Pesquisas Renato Archer) desenvolveu o MEDE-
PROS – Método de Avaliação de Qualidade de Produto de Software, e é uma das iniciativas dentro
da área de qualidade de produto de software que mais tem se destacado nos últimos anos. (ANJOS;
MOURA, 2002).
O método MEDE-PROS foi criado com o objetivo de avaliar a qualidade de produto de
software, tendo como referência as normas NBR ISO/IEC 9126 e NBR ISO/IEC 12119, está
3
registrado na Fundação Biblioteca Nacional, e com o registro de marca no INPI – Instituto Nacional
de Propriedade Industrial. (GUERRA; COLOMBO, 2009).
Outro método existente é o QFD - Função de desdobramento de qualidade, criado por
Macabe e divulgado nos EUA por Don Clausing e pela American Supplier Institute (ASI), utilizado
para transformar as necessidades dos clientes em requisitos de produto e de processo. “Tem por fim
estabelecer a qualidade no projeto, obter a satisfação do cliente, e efetuar o desdobramento das
metas do referido projeto e dos pontos prioritários, em termos de garantia da qualidade, até o
estágio de produção” (VIVEIROS, 2006 p. 9). As funções principais do QFD são: capturar a
necessidade do cliente, minimizar perdas de informações e disponibilizar maneiras em que os
requisitos sejam atendidos pela equipe de desenvolvimento. O QFD é dividido em duas partes,
desdobramento da qualidade, que consiste em transformar as necessidades dos usuários em
características de qualidade, definir a qualidade final do produto acabado e o desdobramento da
qualidade para outros itens e; desdobramento da função da qualidade que consiste no
“desdobramento, em detalhes, das funções profissionais ou dos trabalhos que formam a qualidade,
seguindo a lógica de objetivos e meios” (VIVEIROS, 2006 p. 9).
Existem algumas ferramentas de apoio a qualidade de produtos de software como o
INOVADOR, cujo objetivo é avaliar produtos de software segundo as características descritas na
norma ISO/IEC 9126-1 e as métricas de Qualidade em Uso descritas na norma ISO/IEC 9126-4. A
ferramenta INOVADOR foi criada e desenvolvida por Cibele C. P. Sodré no trabalho de conclusão
de curso de Graduação em Ciência da Computação (SODRÉ, 2006).
Em outro trabalho de conclusão de curso, o acadêmico Jonathan M. Borges desenvolveu um
sistema web baseado no método MEDE-PROS e na norma NBR ISO/IEC 14598-5, além de auxiliar
no processo de avaliação, a ferramenta possibilita o acompanhamento da execução da avaliação
pelo requisitante da avaliação, apresentando os aspectos negativos e positivos do software avaliado
(BORGES, 2006).
Com base nos fundamentos citados neste documento e nas ferramentas já existentes como o
INOVADOR, que implementa e foca somente a norma ISO/IEC 9126 e o Ambiente web de Suporte
ao Processo de Avaliação da Qualidade de Produto de Software que implementa quase que a
totalidade das características do método MEDE-PROS e norma ISO/IEC 14598, propõe-se construir
uma nova ferramenta de apoio no processo de avaliação da qualidade do produto de software,
baseada nas normas ISO/IEC mencionadas e buscando se basear no método MEDE-PROS, porém,
com o objetivo de flexibilizar o processo de avaliação do software de acordo com as necessidades
do avaliador e do requisitante da avaliação, contemplando também o apoio automatizado na etapa
4
final da avaliação, sendo esta uma funcionalidade ausente nos dois trabalhos correlatos citados nos
parágrafos anteriores. Outro fator importante que embasa a construção desta ferramenta é a
indisponibilidade dos softwares existentes, tanto para uso acadêmico e/ou comercial, quanto à
disponibilização do código fonte.
Assim, o tema proposto neste trabalho de conclusão de curso tem como objetivo criar uma
ferramenta baseada nas normas ISO/IEC 9126, 14598, 12119, SQuaRE 25000 e ao método MEDE-
PROS, resultando em um sistema abrangente e flexível de apoio ao processo de avaliação da
qualidade do produto de software. O sistema será web, buscando uma maior independência de
plataforma, priorizando a portabilidade, e facilitando o acesso simultâneo por vários usuários.
1.1 OBJETIVOS
1.1.1 Objetivo Geral
Desenvolver uma ferramenta web de apoio ao processo de avaliação da qualidade de
produto de software baseada nas normas ISO/IEC 9126, 14598, 12119, SQuaRE 25000 e no método
MEDE-PROS.
1.1.2 Objetivos Específicos
Pesquisar sobre qualidade de produto de software e soluções automatizadas para o
processo de avaliação;
Específicar o processo proposto para avaliação do produto de software, baseado nas
normas ISO/IEC 9126, 14598, 12119, SQuaRE 25000 e no método MEDE-PROS;
Específicar a ferramenta para apoio ao processo proposto;
Implementar a ferramenta conforme específicação; e
Testar e avaliar a adequação da ferramenta.
5
1.2 Metodologia
A metodologia utilizada para a realização deste projeto consistiu em duas grandes etapas: (i)
Pesquisa e fundamentação ao tema de estudo; e (ii) desenvolvimento.
A etapa de pesquisa e fundamentação ao tema de estudo consistiu basicamente em pesquisas
de materiais relacionados ao tema “qualidade de produto de software” e a busca por soluções
similares. Os materiais de estudo utilizados para fundamentação foram: normas, livros, artigos (de
periódicos e anais) e trabalhos de doutorado e mestrado, bem como monografias. Os principais
assuntos da pesquisa foram normas e métodos para avaliação de qualidade de produto de software.
Para busca de soluções similares utilizou-se uma estratégia de pesquisa sistemática, utilizando um
protocolo para busca com: string de busca, critérios para seleção e exclusão de estudos e critérios
para extração dos dados.
A segunda etapa, de desenvolvimento, objetivou a criação de um processo para avaliação de
qualidade de produto de software, baseado nas normas e métodos estudados na etapa de
fundmentação. Para especificar o processo foi utilizada uma notação baseada no diagrama de
atividades da UML. Nesta etapa foi detalhado a relação entre as normas e método de avaliação com
o processo proposto. Com base no processo de avaliação criado, iniciou-se a especificação da
ferrramenta de apoio. Nesta fase foram definidos os requisitos funcionais, não funcionais e regras
de negócio do sistema, divididos em três módulos: fornecedor, coordenador e avaliador.
Também foram apresentados os casos de uso da ferramenta, detalhando as principais
funcionalidades do sistema e os papéis envolvidos, e através do diagrama de entidade-
relacionamento, foi realizado o projeto do banco de dados. Com base no modelo entidade-
relacionamento, os requisito e regras de negócio, foi implementado a ferramenta.
Por último, foi apresentado um plano para avaliação da ferramenta, que serviu de base para
avaliar um produto de software, seguindo todas as etapas do processo proposto. No processo de
avaliação, foram selecionadas pessoas específicas para o papel de coordenador, fornecedor e
avaliador. O planejamento e resultado da avaliação foi documentado afim de demonstrar que a
ferramenta atende ao processo no qual foi baseada.
6
1.3 Estrutura do trabalho
Este trabalho está estruturado em 4 capítulos: (i) Introdução; (ii) Fundamentação Teórica;
(iii) Trabalhos Correlatos; e (iv) Desenvolvimento.
O Capítulo 1 apresenta o tema do projeto, abordando suscintamente as necessidades e
objetivos a serem alcançados com o trabalho.
O Capítulo 2 é destinado ao embasamento do projeto, apresentando os conceitos e detalhes
das normas e métodos de qualidade de produto de software, pertinentes ao trabalho.
O Capítulo 3 apresenta os trabalhos similares ao proposto neste projeto, utilizando como
estratégia uma pesquisa sistemática.
Por último, o Capítulo 4, apresenta o processo proposto no projeto e a modelagem da
ferramenta de apoio a avaliação de qualidade de produto de software, relacionando as normas
estudadas com a ferramenta implementada. No mesmo capítulo são demonstradas as telas do
sistema, realacionando–as às etapas do processo de avaliação. O último tópico apresenta o
planejamento e os resultados da avaliação de um produto de software.
2. FUNDAMENTAÇÃO TEÓRICA
Conforme a Pesquisa de Qualidade no Setor de Software Brasileiro 2009 (MARINHO;
SOUZA, 2011), realizada pela SEPIN (Secretaria de Política em Informática), os resultados
indicam a plena conscientização do setor de informática quanto à importância à adoção de modelos,
métodos e normas para melhora da qualidade, permitindo a entrada de empresas brasileiras no
cenário internacional de software.
As próximas seções tem como objetivo fundamentar teoricamente o processo proposto para
avaliação da qualidade de produto de software, conforme mencionado no Item 1.1.2 deste
documento. A Seção 2.1 introduz o assunto qualidade de software, focando em qualidade de
produto de software. A Seção 2.2 apresenta as normas de qualidade ISO/IEC que são utilizadas na
especificação do processo proposto, e os sub itens seguintes detalham as normas. A Seção 2.3
apresenta o conceito de método de qualidade de software genérico e especialista, sendo a Seção
2.3.1 responsável por enfatizar o método MEDE-PROS.
2.1 Qualidade de Software
Definir qualidade de software é uma tarefa difícil, visto que os atributos desta atividade
dependem e variam de acordo do ponto de vista do avaliador e dos envolvidos (SIBISI;
WAVEREN, 2007). Em um contexto geral, qualidade de software pode ser entendida como um
conjunto de características a serem atendidas, alcançando às necessidades explícitas e implícitas de
seus usuários e deve ser construída no processo de desenvolvimento do sistema (DUARTE;
FALBO, 2006).
Em geral, as necessidades explícitas são expressas na definição de requisitos propostos pelo
produtor de software após o levantamento da necessidade do cliente. Esses requisitos
definem as condições em que o produto deve ser utilizado, seus objetivos, funções e o
desempenho esperado. O enfoque da Qualidade centrado no atendimento a esses requisitos
é denominado "conformidade com os requisitos". As necessidades implícitas são aquelas
que não estão expressas nos documentos do produtor, mas são necessárias para o usuário e
são identificadas de acordo com a maturidade do produtor. O enfoque da Qualidade
centrado nessa classe de necessidades está relacionado à "adequação para uso".
(COLOMBO, 2004. p.14)
Segundo Alsultanny e Wohaishi (2009), a tarefa de aplicar métricas de qualidade para
produtos e processo de software é complexa e requer conhecimento referente aos objetivos que se
pretende alcançar. A ausência de qualidade de software tem causado custos significativos para as
empresas de softwares, que enfrentam clientes insatisfeitos e conseqüentemente perdem a
8
credibilidade no mercado, gerando retrabalho. Por outro lado, o problema de falta de qualidade
também afeta os compradores de softwares, que sofrem com sistemas defeituosos e que não
atendem suas necessidades. No início da computação a falta de qualidade era medida com base na
identificação e correção de erros no programa (SIBISI; WAVEREN, 2007). A mesma pessoa que
desenvolvia o sistema também testava, pois não existiam pessoas dedicadas para tal atividade.
Geralmente, a validação do software era realizada quando o produto já estava quase pronto ou
totalmente finalizado. Esta ação evoluiu com o tempo e passou a ser considerada uma má prática do
processo de engenharia de software, apesar disto, continua sendo utilizada por muitas empresas
(BARTIÉ, 2002).
Existem duas etapas nas quais é possível avaliar a qualidade de um software: durante o
desenvolvimento do software, conhecido como qualidade do processo; e quando o software for
entregue ao cliente e aos usuários, definida como qualidade do produto de software (PRESSMAN,
2002). A importância da qualidade de produto de software está proporcionalmente ligada ao
crescente uso dos computadores, nas mais diversas áreas de aplicação, vinculados, por exemplo, ao
sucesso de um negócio e até mesmo a segurança humana. Um estudo realizado por Reed (2000)
indica que se alguns softwares de uso global deixarem de funcionar, aproximadamente 40% da
população sofrerão com as conseqüências.
Considerando este cenário, percebe-se a real importância da qualidade na seleção e
desenvolvimento do produto de software, sempre fazendo o uso de métricas amplamente aceitas e
validadas, resultado que pode ser obtido através do uso de normas técnicas que abrangem as
atividades relacionadas à qualidade de produto de software (ABNT, 2003).
2.2 NORMAS DE QUALIDADE ISO/IEC
Conceitualmente, normalização é "o processo de aplicar regras estabelecidas e executar uma
atividade de maneira ordenada". Os benefícios trazidos na utilização de normas no desenvolvimento
e teste de software podem ser quantitativos, como redução de custos, tempo e erro, e qualitativos
como adequação, facilidade de uso e melhor atendimento dos requisitos solicitados pelo usuário. No
Brasil, o órgão responsável pela normalização é a Associação Brasileira de Normas Técnicas -
ABNT, foi fundada em 1940 e é reconhecida como Foro Nacional de Normalização, é uma entidade
privada e sem fins lucrativos. Existem normas internacionais, regionais, nacionais e organizacionais
em função de sua área de aplicação. A ABNT é responsável por representar o Brasil em entidades
internacionais de normalização, sendo as mais conhecidas a ISO e a IEC. (KOSCIANSKI, 1999)
9
A Organização Internacional para Padronização é um órgão não governamental e
popularmente conhecida como ISO, foi fundada e sediada em 23 de fevereiro de 1947, em Genebra,
na Suíça. A ISO tem como missão a normalização de atividades desenvolvidas a nível mundial,
estabelecendo acordo entre países e publicando-os como normas internacionais. A IEC -
International Electrotechnical Commission, foi fundada em 1906, também em Genebra, Suíça, e é
uma organização internacional de padronização de tecnologias elétricas, eletrônicas e outras
relacionadas que, e em conjunto com a ISO, formam a JTC - Joint Technical Committees,
responsável por elaborar normas na área de tecnologia da informação (KOSCIANSKI, 1999).
A Pesquisa de Qualidade no Setor de Software (2009), realizada pelo Programa Brasileiro
da Qualidade e Produtividade – PBQP-Software, tem como objetivo obter dados e indicadores sobre
a evolução da qualidade no setor de softwares de TI do Brasil, e descreve as principais normas de
qualidade produto de software publicadas pela ISO/IEC e ABNT, sendo elas: NBR ISO/IEC 9126,
NBR ISO/IEC 25000, NBR ISO/IEC 12119 e NBR ISO/IEC 14598.
A norma NBR ISO/IEC 9126-Parte 1:2003 (ABNT, 2003) define as características da
qualidade do produto de software e diretrizes para seu uso. A família de normas NBR
ISO/IEC 14598 (Partes 1 a 6) trata do processo de avaliação de produtos de software. A
Norma NBR ISO/IEC 25000:2008 - Engenharia de software - Requisitos e avaliação da
qualidade de produtos de software (SQuaRE) - Guia do SQuaRE, ... tem o objetivo de
gradativamente substituir o conjunto de Normas NBR ISO/IEC 9126 e NBR ISO/IEC
14598. ... A NBR ISO/IEC 12119:1998 estabelecia os requisitos da qualidade e testes de
pacote de software. (MARINHO; SOUSA, 2011).
Dados obtidos através de pesquisa demonstram que as normas são pouco utilizadas pelas
organizações. Ao total 273 empresas responderam as questões relacionadas à qualidade de produto
de software, sendo que 89% deste total informaram que não utilizam nenhuma das normas
relacionadas. Pode-se considerar um porcentual elevado, considerando que a norma NBR 9126 esta
publicada desde 1996 pela ABNT. Na Figura 1, pode-se observar os resultados obtidos
(MARINHO; SOUSA, 2011).
10
Figura 1. Distribuição das organizações de acordo com a utilização de Normas para
requisitos de qualidade de software (valor percentual).
Fonte: Marinho e Sousa (2011, p. 108).
2.2.1 ISO/IEC 9126 – Qualidade dos produtos de software
A norma ISO/IEC 9126 é referência no processo de avaliação produto de software e define
um modelo de qualidade divido em quatro documentos: modelo de qualidade, métricas externas,
métricas internas e métricas de qualidade de uso (ABNT, 2003). A figura 2 apresenta a sequência de
avaliação segundo a norma ISO/IEC 9126.
Figura 2. Avaliação segundo norma ISO/IEC 9126
Fonte: Colombo (2004).
11
O modelo de qualidade baseado em métricas externas e internas divide a avaliação de um
software em seis características distintas, divididas em subcaracterísticas e, por sua vez, podem ser
desdobradas em mais níveis, que representam os atributos de qualidade (ROCHA; MALDONADO;
WEBER, 2001):
a) Funcionalidade: característica que afere a existência de funções que atendam as
necessidades explícitas ou implícitas do software e suas propriedades específicas.
Adequação, acurácia, interoperabilidade, segurança de acesso e conformidade são
subcaracterísticas da funcionalidade.
b) Confiabilidade: condiz a capacidade de um software manter seu desempenho em
determinadas condições e tempo. Possui como subcaracterísticas: maturidade, tolerância
a falhas, recuperabilidade e conformidade.
c) Usabilidade: refere-se ao esforço na utilização e aprendizado de um produto de software,
assim como o julgamento individual do uso por um conjunto de usuários.
Inteligibilidade, apreensibilidade, operacionalidade, atratividade e conformidade são
suas subcaracterísticas.
d) Eficiência: é a relação entre o desempenho de um produto de software e a quantidade de
recursos utilizados sob uma condição específica. As subcaracterísticas são:
comportamento em relação ao tempo, comportamento em relação aos recursos e à
conformidade.
e) Manutenibilidade: esforço necessário para modificações específicas realizadas no
software e também localizar e reparar erros. Possui como subcaracterísticas:
analisabilidade, modificabilidade, estabilidade, testabilidade e conformidade
f) Portabilidade: é a característica responsável por avaliar a capacidade de um software ser
transportado de um ambiente para outro. Possui como subcaracterísticas: adaptabilidade,
capacidade para ser instalado, coexistência, capacidade para substituir e conformidade.
12
Na Tabela 01 consta a relação das características, subcaracterísticas e sua respectiva
pergunta chave.
Tabela 1. Características e subcaracterísticas do software.
Característica Subcaracterísticas Pergunta chave para subcaracterísticas
Funcionalidade (satisfaz às necessidades?)
Adequação Propõe-se a fazer o que é apropriado?
Acurácia Faz o que foi proposto de forma correta?
Interoperabilidade Interage com os sistemas especificados?
Conformidade Está de acordo com as normas, leis e etc.?
Segurança de acesso Evita o acesso não autorizado aos dados?
Confiabilidade (é imune a falhas?)
Maturidade Com que freqüência apresenta falhas?
Tolerância a falhas Ocorrendo falhas, como ele reage?
Recuperabilidade É capaz de recuperar dados em caso de falha?
Usabilidade (é fácil de usar?)
Inteligibilidade É fácil entender o conceito e a aplicação?
Apreensibilidade É fácil aprender a usar?
Operacionalidade É fácil de operar e controlar?
Eficiência (é rápido e enxuto?)
Tempo Qual é o tempo de resposta, a velocidade de execução?
Recursos Quanto recurso usa? Durante quanto tempo?
Manutenibilidade (é fácil de modificar?)
Analisabilidade É fácil de encontrar uma falha, quando ocorre?
Modificabilidade É fácil modificar e adaptar?
Estabilidade Há grande risco quando se fazem alterações?
Testabilidade É fácil testar quando se fizer alterações?
Portabilidade (é fácil de usar em outro
ambiente?)
Adaptabilidade É fácil adaptar a outros ambientes?
Capacidade para ser instalado É fácil instalar em outros ambientes?
Conformidade Está de acordo com padrões de portabilidade?
Capacidade para substituir É fácil usar para substituir outro?
Fonte: Andrade e Falk (2001)
Métricas de qualidade de uso têm por objetivo medir a capacidade de um produto de
software em atingir os requisitos desejáveis pelos usuários, sendo os atributos classificados em:
eficácia, produtividade, segurança e satisfação (ROCHA; MALDONADO; WEBER, 2001):
a) Efetividade: o software deve permitir que os usuários alcancem metas específicas com
acurácia e completeza, no contexto de uso especificado;
13
b) Produtividade: refere-se à capacidade do produto de software em permitir que seus
usuários executem uma quantidade apropriada de recursos em relação a eficácia obtida,
dentro do contexto de uso especificado;
c) Segurança: o produto de software deve apresentar níveis aceitáveis de riscos a processos,
pessoas, negócios, propriedades e ao meio-ambiente, dentro do contexto de uso
especificado; e
d) Satisfação: capacidade do produto de software em satisfazer usuários, dentro do contexto
de uso especificado.
A norma 9126 possui um total de quatro documentos, um descrevendo o modelo de
qualidade e três documentos para relatórios técnicos, que servem para o apoio na definição de
requisitos e avaliação da qualidade de produto de software (ABNT, 2003):
a) ISO/IEC 9126-1 – modelo de qualidade: descreve um modelo de qualidade de produto
de software;
b) ISO/IEC 9126-2 - métricas externas: define métricas para medir quantitativamente
características e subcaracterísticas externas dos softwares, definidas na norma 9126-1;
c) ISO/IEC 9126-3 – métricas internas: utilizado para medir a qualidade de software de
maneira quantitativa (características internas), também baseado nas definições da norma
9126-1; e
d) ISO/IEC 9125-4 – métricas de qualidade em uso: apóia e auxilia o processo de
determinação das métricas de qualidade de uso descrito na norma 9126-1.
Os relatórios técnicos não definem valores para as métricas e níveis de avaliação, pois estas
são características definidas individualmente para cada produto de software e que dependem de
fatores como a categoria do software, nível de integridade e necessidade dos usuários (ABNT,
2003).
14
2.2.2 ISO/IEC 14598 – Avaliação dos Produtos de Software
A série de normas ISO/IEC 14598 fornece métodos para mensuração, medição e avaliação
de qualidade de produto de software. Descreve métodos de avaliação tanto para o processo de
desenvolvimento de software, quanto para um produto pronto. A ISO/IEC 14598 é destinada para
uso em conjunto com a série de normas ISO/IEC 9126 e é composto por um total de seis
documentos que juntos, fornecem um modelo de avaliação genérico, para avaliação de qualidade de
software (ISO/IEC 14598-1):
a) ISO/IEC 14598-1 – visão geral: o primeiro documento é um guia de avaliação,
apresentando uma visão geral sobre o processo de avaliação, a figura 3 mostra o
processo proposto pela norma;
Fonte: Colombo(2004).
Figura 3. Processo de avaliação segundo a norma 14598-1.
b) ISO/IEC 14598-2 – planejamento e gestão: tem por objetivo ser mais específico na
apresentação dos requisitos, recomendações e orientações que englobam processo de
planejamento e gerenciamento de avaliação de produtos de software, "incluindo:
15
desenvolvimento, aquisição, padronização, controle, transferência e realimentação do
uso de tecnologias de avaliação no âmbito da organização." (MPS.BR, 2011).
c) ISO/IEC 14598-3 – processo para desenvolvedores: é destinado ao processo de
desenvolvimento do produto de software. Através de indicadores e métricas, procura
prever a qualidade a ser obtida no produto final, beneficiando na tomada de decisões;
d) ISO/IEC 14598-4 – processo para adquirentes: é destinada a adquirente de software,
contemplando um processo de avaliação de produtos de software de prateleira, produtos
de software sob encomenda e também modificações em produtos já existentes. O
principal objetivo deste documento é comparar o software a ser avaliado com
alternativas já existentes no mercado, ou garantir que o produto de software final atenda
aos requisitos estabelecidos no desenvolvimento;
e) ISO/IEC 14598-5 – processo para avaliadores: o quinto documento tem por objetivo
orientar a implementação de uma avaliação de produto de software, considerando o
modelo de qualidade descrito na norma ISO/IEC 9126-1. As orientações da norma
ISO/IEC 14598-5 definem "as atividades necessárias para analisar os requisitos de
avaliação de modo a especificar, projetar e executar as atividades de avaliação"
(MPS.BR, 2011); e
f) ISO/IEC 14598-6 – documentação de módulos de avaliação: o sexto e último documento
define como criar um módulo de avaliação, construindo a estrutura e conteúdo da
documentação utilizada no processo, como o relatório final dos resultados obtidos. Um
módulo de avaliação produzido e validado, seguindo a norma ISO/IEC 14598-6, deve
resultar em avaliações imparciais que possam ser repetidas e reproduzidas. (MPS.BR,
2011).
As seções seguintes detalham as normas ISO/IEC 14598-5 e ISO/IEC 14598-6, visto que
estes dois documentos serão bastante utilizados em um dos objetivos gerais deste trabalho:
especificar o processo proposto para avaliação do produto. A Figura 4 mostra o relacionamento das
normas ISO/IEC 14598.
16
Figura 4. Relacionamento das normas ISO/IEC 14598
Fonte: Colombo (2004)
2.2.3 ISO/IEC 14598-5 – Processo para avaliadores
A norma ISO/IEC 14598-5 é responsável por orientar o planejamento e execução de um
processo de avaliação de um software, através de uma série de recomendações. Por sua
generalidade, deve ser executada sempre observando os requisitos do produto a ser avaliado, bem
como as características pertinentes ao domínio para o qual a avaliação será realizada. Os
documentos destinam-se ao processo de avaliação de produtos existentes ou em desenvolvimento,
sendo possível sua utilização por fornecedores, usuários, entidades certificadoras e avaliadores em
laboratório. Vários documentos do software podem ser considerados para o processo de avaliação,
tais como: documentos do projeto, relatórios de teste e validação, código fonte e documentação do
usuário. (FORTES; SILVA; PAIVA, 2001).
Os principais objetivos do processo de avaliação descrito na norma ISO/IEC 14598-5, é
obter quatro características básicas e desejáveis em um processo de avaliação de software
(KOSCIANSKI, 1999):
a) Repetibilidade: uma especificação de avaliação, repetida pelo mesmo avaliador e para o
mesmo produto, produza resultados que possam ser considerados como idênticos;
17
b) Reprodutibilidade: uma especificação de avaliação de um produto, repetida por
avaliadores diferentes, produza resultados que possam ser considerados como idênticos;
c) Imparcialidade: a avaliação deve ser neutra, e que não seja tendenciosa a algum tipo de
resultado em particular;
d) Objetividade: os resultados obtidos devem ser baseados em fatos, sem que haja
interferências dos sentimentos do avaliador.
A norma ISO/IEC 14598-5 sugere uma estrutura de execução no processo de avaliação
dividida em cinco etapas: análise de requisitos, especificação da avaliação, execução da avaliação e
conclusão da avaliação (FORTES; SILVA; PAIVA, 2001).
a) Análise de Requisitos: etapa em que são definidos os requisitos e descritos os objetivos
da avaliação, dependendo dos diferentes usuários do produto.
b) Especificação da Avaliação: etapa onde é definido o escopo da avaliação e medições de
software que serão executadas nos componentes da avaliação. São definidas também as
responsabilidades de todos os envolvidos no processo de avaliação.
c) Planejamento da Avaliação: nesta etapa são definidos os documentos e procedimentos
que serão utilizados pelo avaliador, com base nas especificações da etapa anterior.
"O avaliador deve produzir um plano que descreva os recursos necessários para realizar
a avaliação especificada, a distribuição desses recursos ... bem como os prazos, a equipe
de avaliação, os riscos associados e todas as atividades envolvidas” (FORTES; SILVA;
PAIVA, 2001).
d) Execução da avaliação: etapa onde são obtidos os resultados de execução de acordo com
a análise de requisitos, especificação da avaliação e planejamento. O resultado desta
etapa é o rascunho do relatório e dos dados da avaliação.
e) Conclusão da avaliação: etapa final do processo de avaliação, onde é revisado o relatório
de avaliação e disponibilizados os resultados obtidos.
18
2.2.4 ISO/IEC 14598-6 – Documentação de módulos de avaliação
Em uma visão geral, os módulos de avaliação fornecem uma ligação entre as técnicas de
avaliação, indicadores e métricas de qualidade. O processo de avaliação de um produto de software
é inteiramente baseado em um conjunto de métricas, que em conjunto, fornecem informações sobre
as propriedades do software. As normas ISO/IEC 9126-2 e ISO/IEC 9126-3 possuem o objetivo de
definir as métricas através dos relatórios técnicos. Os módulos de avaliação surgiram da
necessidade de padronizar a forma de documentar estas normas, e utilizá-las de maneira eficiente,
permitindo a troca de informações sobre avaliações. Um módulo de avaliação é uma estrutura de
dados e instruções utilizados para o processo de avaliação e na prática, serve para específicar os
métodos de avaliação aplicáveis para uma dada característica (ou subcaracterísticas) e identificar as
evidências (por exemplo, amostra de código) que ele necessita (KOSCIANSKI, 1999).
Os módulos de avaliação descritos na norma ISO/IEC 14598-6 possuem um padrão que
deve ser seguido, construindo um modelo básico que contém a seguinte estrutura:
a) Prefácio e introdução: parte da estrutura responsável por informações sobre: preparação,
aprovação, contribuições e alterações sofridas pelo módulo de avaliação e
relacionamento com outros documentos e/ou normas;
b) Escopo: na etapa de escopo do módulo de avaliação, são identificadas as características e
subcaracterísticas (em conjunto a norma ISO/IEC 9126), o nível de avaliação e técnicas
utilizadas;
c) Referências: parte onde constam documentos normativos e normas técnicas
relacionadas. Se o módulo de avaliação em questão depender dos resultados de outro
módulo de avaliação, este também fará parte das referências;
d) Termos e definições: parte da estrutura onde ficam todas as definições de termos
técnicos que são utilizados no módulo de avaliação, que também pode ser feito através
da referência a fontes onde possam ser encontradas as definições;
e) Entradas para a avaliação: etapa responsável por identificar as entradas, os dados e as
métricas e medidas usadas:
19
a. Entradas: é a identificação de todas as informações requeridas como entrada para
o módulo de avaliação.
Estes devem ser classificados como componentes de produto (especificação de requisitos de
software, descrição do projeto de software, descrição de programa, código fonte, código
executável, documentação de usuário), informação de produto (relatório de revisão de
requisitos de software, relatório de revisão de projeto de software, relatório de revisão de
programa, relatório de teste de unidade, relatório de revisão de documentação de usuário) e
informações de suporte (plano de garantia de qualidade, plano de gestão de configuração,
plano de teste de programa e descrição de língua de programação e compilador)
(KOSCIANSKI, 1999).
b. Dados: descrevem quais serão os parâmetros para especificação dos elementos de
dados que serão extraídos dos documentos de entradas e demais evidências. A
partir dos elementos de dados, que as métricas de avaliação serão computadas.
c. Métricas e medidas: a partir dos elementos de dados, descreve como as métricas
e medidas serão calculadas.
f) Interpretação dos resultados: compreende o mapeamento das medidas e o relato da
avaliação. Mapeamento das medidas é a interpretação dos resultados obtidos através das
medições e o relato da avaliação descreve "o conteúdo do relatório com o resultado da
aplicação do módulo de avaliação e a visualização dos valores obtidos” (KOSCIANSKI,
1999).
2.2.5 Relacionamento das normas ISO/IEC 9126 e ISO/IEC 14598
As normas ISO/IEC 9126 e ISO/IEC 14598 foram construídas para serem utilizadas em
conjunto, sendo que uma complementa a outra. Em uma visão geral das duas normas, pode-se
resumi-las da seguinte maneira: o modelo de qualidade está descrito na norma ISO/IEC 9126-1,
sendo que os demais documentos (ISO/IEC 9126-2, ISO/IEC 9126-3, ISO/IEC 9126-4)
correspondem aos relatórios técnicos, que são responsáveis por fornecer exemplos de métricas de
qualidade. O documento ISO/IEC 14598-1 define os conceitos envolvidos no processo de avaliação
de qualidade de software de uma maneira genérica. Os documentos ISO/IEC 14598-2 e ISO/IEC
14598-6 oferecem suporte à avaliação e os demais documentos (ISO/IEC 14598-3, ISO/IEC 14598-
4, ISO/IEC 14598-5) são utilizados para apoio no processo de avaliação específico por usuário
(desenvolvedores, adquirentes e avaliadores de software). As ligações entre as duas normas podem
ser visualizadas na Figura 5. (MPS.BR, 2011).
20
Figura 5. Relacionamento entre as séries de normas ISO/IEC 9126 e 14598.
Fonte: MPS.BR (2009, p. 68)
2.2.6 ISO/IEC 12119 – Pacotes de Softwares – Testes e requisitos de Qualidade
Colombo (2004), comenta que Pacotes de softwares é o “conjunto completo e documentado
de programas fornecidos a diversos usuários para uma aplicação ou função genérica”, e são
conhecidos internacionalmente como COTS – Commercial off-the-shelf. Segundo Colombo, “...
COTS se concentra na produção de componentes competitivos e fáceis de integrar, muitas vezes
usando componentes de outros fornecedores”. São exemplos de pacotes de software: programas
utilitários, processadores de texto, softwares gráficos, banco de dados, entre outros.
A norma ISO/IEC 12119 é aplicável a avaliação de pacotes de software finalizados, não
contemplando a avaliação de qualidade no processo de desenvolvimento. O público alvo desta
norma são fornecedores de softwares, entidades responsáveis por certificação, laboratórios de teste
de software, compradores de softwares, auditores responsáveis por auditar laboratórios de teste e
usuários. A norma ISO/IEC 12119 estabelece as necessidades e requisitos que um pacote de
software deve ter, sendo eles: descrição do produto e documentação do usuário (ABNT, 1998).
21
A descrição do produto fornece informações sobre o produto (documentação de usuário,
programas e dados, caso tenham) e é fornecido junto à documentação do software. Segundo a
ABNT (1998), a descrição do produto deve ser completa, organizada e livre de inconsistências
internas, oferecendo aos compradores do pacote de software auxílio na avaliação do produto em
relação as suas necessidades, antes de comprá-lo. As informações que a descrição do produto deve
conter são: identificação da descrição do produto, identificação do produto, fornecedor, tarefa,
requisitos de hardware e software, conformidade a documentos de requisitos, interface com outros
produtos, itens que compõem o pacote, instalação, suporte e manutenção. Os requisitos de
programas de dados são avaliados de acordo com a funcionalidade (instalação, presença de funções,
correção e consistência), confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade
(ABNT, 1998).
As instruções para teste descritas na norma ISO/IEC 12119 incluem "tanto o teste das
propriedades necessárias a todos os produtos de mesmo tipo, quanto o teste das propriedades
especificadas na descrição do produto". Os testes funcionais (caixa-preta) e de inspeção de produto
também são contemplados pela norma. As atividades para teste devem contemplar qualquer
informação que seja fornecido como parte do pacote de software (descrição, documentação do
usuário, programas e dados) e devem abranger todos os requisitos descritos nas normas para estes
dados. Os registros gerados para cada teste devem conter o plano de teste, resultado e identificação
das pessoas envolvidas. Ao final do teste é gerado um relatório, que contém os objetivos e
resultados alcançados, contendo a seguinte estrutura: identificação do produto, sistemas
computacionais usados para o teste, documentos utilizados, resultado dos testes, lista das não
conformidades aos requisitos, lista contendo informações sobre recomendações e não-
conformidades com estas recomendações, e por fim, data do encerramento do teste. Uma vez
realizado o teste no pacote de software, a mesma documentação poderá ser utilizada para um novo
teste, desde que seja no mesmo pacote de software (ABNT, 1998). A Figura 6 mostra a estrutura da
norma ISO/IEC 12119.
22
Figura 6. Estrutura da norma 12119.
Fonte: Colombo(2004).
2.2.7 SQUARE 25000
A série de normas NBR ISO/IEC 25000, formam o modelo de qualidade conhecido como
SQuaRE - Requisitos e avaliação da qualidade de produtos de software, e foi construída com base
nas séries de normas ISO/IEC 9126 e ISO/IEC 14598, visando substituí-las gradativamente. O
objetivo geral da série de normas SQuaRE visa melhorar e unificar os três principais processos
pertinentes a qualidade de software, sendo: especificação de requisitos, medição de qualidade e
avaliação. (MARINHO; SOUSA, 2011).
Segundo Suryn e Abran (2003), a série de normas SQuaRE corresponde a segunda geração
de normas de qualidade de software, e foi construída com base nas seguintes premissas:
a) Unir as normas ISO/IEC 14598 e ISO/IEC 9126 em uma única estrutura de normas;
b) Introduzir uma nova organização de normas;
c) Apresentar um novo modelo de referência geral de qualidade;
d) Padronizar guias de qualidade detalhados;
e) Introduzir um padrão de primitivas de medição;
f) Normalizar os requisitos de qualidade; e
g) Apresentar um guia prático de uso das normas com exemplos.
23
O modelo SQueRE é composto por quatorze documentos distribuídos em cinco módulos:
gestão de qualidade, modelo de qualidade, medição de qualidade, requisitos de qualidade e
avaliação de qualidade, que possuem os seguintes objetivos (MPS.BR, 2011). A Figura 7
exemplifica a arquitetura da norma SQuaRE:
Figura 7. Arquitetura dos documentos que compõem a série de normas
SquaRE
Fonte: Guerra e Colombo (2009).
a) ISO/IEC 2500n - Gestão da Qualidade: módulo responsável por apresentar o modelo de
normas SQuaRE, bem como definir os conceitos, termos e referências mencionados nas
demais divisões da SQuaRE. A ISO ISO/IEC 2500n possui dois documentos distintos:
a. ISO/IEC 25000 - Guia para SQuaRE: apresenta a estrutura SQuaRE,
terminologias, visão geral, modelos de referência e público-alvo;
b. ISO/IEC 25001 - Planejamento e gestão: fornece os requisitos e orientações para
o planejamento e gestão do processo de avaliação de produto de software;
b) ISO/IEC 2501n - Modelo de Qualidade: define um padrão de qualidade detalhado,
especificando as características de qualidade externas, internas e qualidade de uso. A
norma ISO/IEC 2501n é composta de dois documento:
24
a. ISO/IEC 25010 - Guia de modelo de qualidade: determina um modelo,
características e subcaracterísticas para qualidade interna, externa e qualidade de
uso para produto de software;
b. ISO/IEC 25012 - Guia de modelo de qualidade de dados: define um padrão para
uso de dados tanto por pessoas quanto sistemas;
c) ISO/IEC 2502n - Medição da Qualidade: inclui a padronização matemática das métricas
de qualidade internas, externas e em uso, junto a um modelo de qualidade de produto de
software e também um guia prático para implementação do modelo, destinado a
avaliadores, adquirentes e desenvolvedores. Este módulo inclui cinco documentos:
a. ISO/IEC 25020 – Guia e modelo de referência: introduz as explicações, modelo
de referência e definições comuns para as primitivas de medição internas,
externas e de qualidade em uso, destinado a usuários, desenvolvedores e
avaliadores;
b. ISO/IEC 25021 - Medição de primitivas: define um conjunto de medidas para a
construção de métricas para medição de qualidade das características internas,
externas e de uso do produto de software;
c. ISO/IEC 25022 - Métricas para qualidade interna: define uma série de métricas
internas para medir quantitativamente as características e subcaracterísticas de
qualidade interna de um produto de software;
d. ISO/IEC 25023 - Métricas para qualidade externa: define uma série de métricas
externas para medir quantitativamente as características e subcaracterísticas de
qualidade externa de produto de software;
e. ISO/IEC 25024 - Métricas para qualidade em uso: define uma série de métricas
de qualidade em uso para medir quantitativamente as características e
subcaracterísticas de qualidade em uso de produto de software.
d) ISO/IEC 2503n - Requisitos de Qualidade: é a divisão que abrange as normas destinadas
a especificação de requisitos de qualidade. Os requisitos podem ser orientados tanto para
25
um produto de software que será desenvolvido, quanto para um produto final. É
composto de um único documento:
a. ISO/IEC 25030 - Guia de requisito de qualidade: guia destinado a especificação
dos requisitos de qualidade de produto de software.
e) ISO/IEC 2504n - Avaliação da Qualidade: conjunto de normas que incluem os
requisitos, recomendações e diretrizes para avaliação da qualidade de produto de
software para clientes e desenvolvedores. Este modelo é composto dois documentos:
a. ISO/IEC 25040 - Guia e modelo de referência para avaliação de qualidade:
fornece uma estrutura destinada a identificação dos requisitos gerais e conceitos
para especificação e avaliação da qualidade de software descrevendo um
processo de avaliação;
b. ISO/IEC 25041 - Documentação para o módulo de avaliação: define um módulo
de avaliação capaz de avaliar erros induzidos e detectados e a maneira como o
sistema trata e recupera estes eventos.
f) ISO/IEC 25051 – Requisitos de Qualidade para COTS: Extensão da SQuaRE que
fornece requisitos de qualidade e requisitos documentação para pacotes de software
(COTS).
g) ISO/IEC 25062 – Formato Comum da Insdústria para Relatórios de Usabilidade:
segunda extensão da SQuaRE, visa estabelecer um padrão para registro de medidas de
usabilidade, obtidas através de testes.
O modelo de normas para qualidade de produto de software SquaRE possui alguns
documentos que ainda estão em fase de revisão e outros que foram publicados.
2.3 MÉTODOS DE QUALIDADE
Segundo Guerra, Colombo e Villalobos (2005), um método de avaliação de qualidade pode
ser genérico ou especialista. Métodos especialistas são desenvolvidos com o objetivo de avaliar
produtos de software pertencentes a um domínio específico, com determinadas características e
escopo particularmente customizável. Nos métodos de avaliação genéricos, todas as características
de qualidade de um software devem ser consideradas, independente da categoria de software a ser
26
avaliado. O objetivo da próxima sessão é dar ênfase ao método genérico de qualidade de produto de
software desenvolvido pelo CenPRA: MEDE-PROS.
2.3.1 MEDE-PROS
O Método de Avaliação de Qualidade de Software - MEDE-PROS, foi desenvolvido pelo
CenPRA - Centro de Pesquisa Renato Archer e tem como objetivo avaliar um produto de software
sob o ponto de vista do usuário final. O MEDE-PROS encontra-se registrado na Fundação da
Biblioteca Nacional e com registro de marca no INPI (Instituto Nacional de Propriedade Industrial),
no Brasil. Este método avalia seis características de qualidade que devem estar presentes em um
produto de software, sendo: funcionalidade, confiabilidade, portabilidade, usabilidade, eficiência e
manutenibilidade, estas características possuem como referência a norma ISO/IEC 9126. O MEDE-
PROS também define os requisitos de qualidade para pacotes de software (COTS), tendo como
referência a norma ISO/IEC 12119. A partir destas características, o método MEDE-PROS, fornece
um guia de avaliação, "contendo procedimentos e instruções para avaliação e está estruturado
seguindo uma seqüência de passos, agrupados por tarefas específicas, para orientar a avaliação da
qualidade de um produto de software." (GUERRA; COLOMBO; VILLALOBOS, 2005). O
resultado final é um relatório de avaliação, onde são apontadas as características do produto que
atendem as normas de qualidade de software e os pontos que precisam ser revistos e melhoria dos
no produto.
2.3.1.1 Documentação MEDE-PROS
O MEDE-PROS é um método de avaliação genérico formado por três documentos
principais (ROCHA; MALDONADO; WEBER, 2001):
a) Lista de verificação: é uma ferramenta que apóia os avaliadores no processo de avaliação
de qualidade, estando as características e subcaracterísticas do produto decompostas
hierarquicamente em um modelo. A lista de características e subcaracterísticas podem
ser agrupadas em um conjunto de componentes, e estes, por um conjunto de questões.
Ao total, cinco componentes poderão ser avaliados: embalagem, descrição do produto,
documentação do usuário, interface e software. Na Figura 8, pode-se observar a relação
das características e normas de qualidade que contribuíram para a construção da lista de
verificação.
27
Figura 8. Estrutura da lista de verificação de um método de avaliação
(MEDE-PROS)
Fonte: Processo de Avaliação de Produtos de Sotware (2005).
b) Manual do Avaliador: material que contém as diretrizes, informações e recomendações
necessárias para utilização da lista de verificação durante o processo de avaliação de um
produto de software, com o objetivo de auxiliar os avaliadores.
c) Modelo de relatório de avaliação: é um laudo técnico que fornece informações sobre a
qualidade de produto de software, sob o ponto de vista de um usuário final. Aponta as
características do software que estão dentro das normas de qualidade, e também pontos
que não estão em conformidade, apresentando ao final do documento, uma lista de
sugestões que visam adequar o produto de software aos requisitos especificados.
O modelo de avaliação MEDE-PROS, sugere que os componentes de um software sejam
avaliados em três etapas: instalação, execução e desinstalação; e durante estas etapas, o avaliador
poderá medir alguns atributos dos componentes do produto, sendo: software, interface,
documentação, descrição do produto e embalagem (GUERRA; COLOMBO, 2009).
Com base nos modelos e etapas citadas anteriormente nesta seção, pode-se ter uma visão
mais detalhada do modelo de qualidade MEDE-PROS. Ao total, sete componentes fazem parte
deste modelo, sendo que cada componente possui suas respectivas características e
subcaracterísticas de qualidade, e que por sua vez, se desdobram em um total de 526 questões a
serem aplicadas na avaliação de qualidade de um produto de software. (GUERRA; COLOMBO,
2009). Uma visão detalhada do modelo MEDE-PROS pode ser verificada na Figura 9:
28
Figura 9. Modelo detalhado do método MEDE-PROS.
Fonte: Guerra e Colombo (2005).
Na lista de verificação, as subcaracterísticas de qualidade de produto de software são
desdobradas em atributos que podem ser medidos e pontuados. Estes atributos são chamados de
medidas e baseado nos relatórios técnicos ISO/IEC 9126-2, 9126-3 e 9126-4. Como exemplos de
medidas podemos citar:
a) Instalação: esta específicado o tipo de processador necessário para colocar o produto em
uso;
b) Documentação do usuário: os documentos do usuário impressos estão identificados;
c) Interface: apresenta erros gramaticais.
3. Trabalhos Correlatos
Esta seção pretende apresentar os trabalhos similares ao proposto neste projeto. Para
pesquisa dos trabalhos foram utilizadas estratégia de pesquisa sistemática, sendo utilizado um
29
protocolo para a busca, com string de busca, critérios para seleção e exclusão dos estudos, bem
como os critérios para extração dos dados.
Na Tabela 02, pode-se observar o protocolo de busca utilizado na pesquisa.
Tabela 2. Protocolo da busca
Estratégia de
pesquisa
String da busca: ("qualidade de software" OR "qualidade de produto de
software" OR "Avaliação de software") AND ("Processo de avaliação"
OR "Ferramenta de apoio").
Foram analisados os 100 primeiros documentos retornados pela string de
pesquisa, conforme critérios de seleção e exclusão.
Fonte de pesquisa: Google Acadêmico.
Critérios de seleção Os termos de busca devem estar contidos no título ou abstract
Serão considerados apenas trabalhos de conclusão de curso
superior e pós-gradução, artigos científicos e também teses de
mestrados e doutorados, focados no tema qualidade de produto de
software.
Serão considerados trabalhos apenas na língua portuguesa
Critérios de exclusão Trabalhos com título que fogem totalmente do contexto da
pesquisa
Trabalhos que não propõem um novo processo ou ferramenta de
apoio a qualidade de produto de software
Estratégia para
extração dos dados
Leitura do abstract
Leitura dos objetivos gerais e específicos do estudo
Leitura da seção onde é descrito um novo processo ou ferramenta
de apoio a qualidade de produto de software ou ambos
Extrair informações referentes ao: título do projeto, objetivo do
estudo, embasamento, contribuição e descrição.
A partir da string de pesquisa, o Google Acadêmico retornou um total de oitocentos e oitenta
e um (881) resultados, do qual foram analisados os cem (100) primeiros. Dentre os cem
(100)estudos analisados, dezenove (19) estavam de acordo com os critérios de seleção, no qual, ao
30
aplicar os critérios de exclusão, sobraram no total seis (06) documentos. A Tabela 3 mostra os
dados extraídos dos trabalhos selecionados.
Tabela 3. Trabalhos Correlatos
Título Avaliador: Uma Ferramenta de Apoio à Aplicação da norma ISO/IEC
9126 para Avaliação da Qualidade de Produtos de Software (SODRÉ,
2006).
Objetivos do estudo Avaliar produtos de software segundo as características de Qualidade em
Uso da norma ISO/IEC 9126-1 e nas métricas de Qualidade em Uso
descritas na norma ISO/IEC 9126-4.
Embasamento Normas ISO/IEC 9126-1 e ISO/IEC 9126-4.
Contribuição Ferramenta de apoio ao processo de avaliação da qualidade de produdo
software.
Descrição Desenvolvida em linguagem Borland Delphi 7 com banco de dados
PostgreSQL 8.1. Possui três módulos:
a) Administrador: cadastro dos preparadores da avaliação;
b) Preparador: definição das métricas que serão avaliadas, níveis de
pontuação e critérios de julgamento;
c) Avaliador: execução da avaliação definida pelo preparador.
As configurações mínimas de hardware e software são: memória RAM de
32 MB, ambiente windows 95 ou superior e processador de 500 MHz.
Ferramenta não disponível para download.
Título Ambiente web de suporte ao processo de avaliação da qualidade de
produtos de software (BORGES, 2006).
Objetivos do estudo Específicação e implementação de uma ambiente web para auxiliar no
processo de avaliação de produtos de software.
Embasamento Norma 14598-5 e ao método de avaliaçao da qualidade de produto de
software MEDE-PROS.
Contribuição Ferramenta web para auxilio no processo de avaliação de produto de
software.
Descrição O sistema foi desenvolvido em liguagem de programação PHP versão 5,
acessando uma base de dados MySQL versão 5, e utilizando também
HTML, AJAX e biblioteca gráfica PJGraph. Além de auxiliar no processo
de avaliação, possibilita o acompanhamento da execução da avaliação pelo
requisitante da avaliação, apresentando os aspectos positivos e negativos do
software avaliado. Com referência na norma ISO/IEC 14598-4 e o método
MEDE-PROS, foi proposto um ciclo de atividades para o processo de
avaliação: (i) levantamento de requisitos; (ii) específicação e plano de
avaliação; (iii) execução e acompanhamento da avaliação; (iv) finalização
da avaliação. A ferramente não está disponível para utilização.
A figura 10, mostra a tela de cadastro de avaliação da ferramenta web.
31
Figura 10. Tela de cadastro de avaliação da ferramenta web.
Título Um Modelo para avaliação de produtos de software (ANJOS;
MOURA, 2002).
Objetivos do estudo Propor um novo modelo de avaliação para produtos de software, baseado
nas normas ISO, nos processo de avaliação de produtos de software padrão
e modelos de avaliação mais utilizados no mercado de software.
Embasamento Normas ISO/IEC 9126, ISO/IEC 14598 e ISO/IEC 12119.
Contribuição Processo de avaliação de produto de software.
Descrição Propõe um processo baseado nas normas ISO/IEC 9126, ISO/IEC 14598 e
ISO/IEC 12119, adicionando a avaliação do domínio por especialista.
Insere a participação do Avaliador especialista no domínio, que é um
profissional especializado na área objeto do software avaliado, capaz de
verificar o cumprimento de todos os requisitos definidos e identificar e
definir as necessidades implícitas, garantindo assim não apenas a
conformidade das funções aos requisitos, mas sobretudo a acurácia e
adequação. O modelo visa também a diminuição do tempo de atingimento
da maturidade do software, sendo que geralmente esta maturidade é alcança
após um longo período de utilização do software por não especialistas.
Título Um Processo de Avaliação da Portabilidade de unidades de Software
(GOMES FILHO, 2005).
Objetivos do estudo Apresentar uma proposta de um processo de avaliação da portabilidade de
unidade de software.
Embasamento ISO/IEC 9126-1 e ISO/IEC 14598.
Contribuição Processo de avaliação.
Descrição Definir um proceso de avaliação de unidades de software baseado na
família ISO/IEC 14598, focado na característica portabilidade e suas
subcaracterísticas (adaptabilidade, capacidade para ser instaladao,
coexistência e capacidade para substituir) descritas na ISO/IEC 9126-1.
Foram selecionadas métricas internas e externas que serão utilizadas
durante o processo de avaliação da portabilidade de produtos de software e
para cada métrica foi estabelecido um valor mapeado numa escala. Uma
32
vez determinado as métricas e seus valores, restaram os processos de
obtenção de julgamento dos valores obtidos, que são feitos em seis (6)
etapas:
a) Identificar as informações disponíveis sobre a unidade de software;
b) Identificar as dependências do software com o ambiente;
c) Selecionar o método de avaliação da portabilidade adequado a partir
das informações disponíveis;
d) Especificar novos ambientes para a unidade de software dependendo
do método de avaliação selecionado;
e) Executar a avaliação de acordo com o método de avaliação da
portabilidade selecionado;
f) Sintetizar os resultados.
A figura 11 mostra o processo de avaliação de portabilidade de produto de
software.
Figura 11. Processo de avaliação de portabilidade
Título Framework para Especialização de Modelos de Qualidade de Produtos
de Software (SANTOS; PRETZ, 2009).
Objetivos do estudo Propor um framework para construção de modelos de avaliação de
qualidade de produtos de software especializados para áreas de negócio do
Serpro.
Embasamento Estratégia RRBT (Risk & Requirement Base Testing), ISO/IEC 9126-1 e
ISO/IEC 14598 e abordagem GQM (Goal Question Metric).
Contribuição Processo para especialização de modelos de qualidade de produtos de
software.
33
Descrição Especialização do modelo e medição de qualidade. A idéia principal é a
rastreabilidade desde o requisito até a técnica de teste que permitirá a
medição da qualidade, considerando os riscos e atributos da qualidade
associados, a figura 12 exemplifica este proceso. A partir do MR (Modelo
de requisitos), que é um conjunto de artefatos e diagramas que
contextualizam e especificam as necessidades, funcionalidade e requisitos
que o produto de software se propõe a atender, é aplicada a técnica RRBT
para associação de riscos e priorização dos testes. Os atributos de
qualidades são baseados na norma ISO/IEC 9126-1 e o processo baseado na
norma ISO/IEC 14598-4.
Figura 12. Processo da Framework de especialização
Título Ferramenta fuzzy para avaliação da qualidade de software
(OLIVEIRA, 2002).
Objetivos do estudo Desenvolver uma ferramenta de suporte ao processo de avaliação de
software baseado no modelo MFAQS, promovendo mecanismos de
investigação de nível de qualidade, através do julgamento de especialistas,
como também a análise e a obtenção de resultados mais confiáveis.
Embasamento Baseado no modelo MFAQS - modelo fuzzy para avaliação de qualidade de
software.
Contribuição Ferramenta de apoio baseada no modelo MFAQS.
Descrição O AdeQuaS implementa e automatiza o processo de avaliação descrito no
MFAQS, tornando transparente para os participantes do processo de
avaliação as tarefas mais árduas contidas no modelo MFAQS, compostos
por dois módulos: (i) AdeQuaS-Analisador: no qual são realizadas as
principais atividades do processo de avaliação da qualidade desde a
definição da avaliação até a geração de relatórios dos resultados obtidos; e
(ii) AdeQuaS-Avaliador: basicamente um visualizador e um coletor de
informações do objeto de avaliação. O processo de avaliação foi construído
basicamente a partir de quatro etapas:
a) Definição da avaliação;
b) Coleta de dados dos especialistas;
c) Tratamento de dados;
d) Geração de resultados.
34
O processo de avalição proposto pode ser visto na figura 13.
Figura 13. Processo de avaliação AdeQuas.
No documento analisado, não constam dados sobre linguagem de
programação, tecnologia utilizada, e disponibilidade da ferramenta.
35
A Tabela 4 foi criada a partir da comparação dos trabalhos correlatos e a proposta deste
estudo. As características comparadas foram definidas com base nos objetivos deste trabalho.
Tabela 4. Comparativo trabalhos correlatos
Propõe ferramenta?
Propõe Processo?
Qual plataforma?
Disponível a Comunidade?
Normas ISO/IEC
Modelos de qualidade
Avaliador: ferramenta de apoio (SODRÉ, 2006).
SIM NÃO DESKTOP NÃO 9126-1 9126-4
--
Ambiente Web de suporte (BORGES, 2006). SIM NÃO WEB NÃO 14598-5
MEDE-PROS
Modelo de avaliação de produtos de software (ANJOS; MOURA, 2002).
NÃO SIM -- -- 9126 14598 12119
--
Processo avaliação de portabilidade (GOMES FILHO, 2005).
NÃO SIM -- -- 9126-1 14598
--
Framework para especialização (SANTOS; PRETZ, 2009). NÃO SIM -- --
9126-1 14598
--
AdeQuas: Ferramenta Fuzzy (OLIVEIRA, 2002). SIM NÃO DESKTOP NÃO 9126 MFAQS
Ferramenta de apoio a avaliação de qualidade de produto de software – TCC
SIM SIM WEB SIM
9126 14598 12119 25000
MEDE-PROS
Comparando com os trabalhos correlatos pesquisados, pode-se destacar como diferencial do
presente projeto: o embasamento por uma maior quantidade de normas, incluindo a norma mais
atual ISO/IEC 25000, buscando uma ferramenta mais abrangente e genérica para avaliação de
qualidade de produto de software; a disponibilização para a comunidade em geral da ferramenta a
ser desenvolvida; e um novo processo de avaliação de qualidade de produto de software desenhado
e desenvolvido junto a uma ferramenta independente.
36
4. DESENVOLVIMENTO
Nesta seção são apresentadas as características pertinentes a modelagem do processo
proposto e da ferramenta de apoio a qualidade de produto de software. A Subseção 4.1 apresenta o
processo proposto detalhando os aspectos necessários. Na Subseção 4.1.1 à 4.1.5 são apresentadas
as regras do negócio, a definição dos requisitos funcionais e não funcionais, e nas Subseções 4.1.6 e
4.1.7 esta a específicação do diagrama de casos de uso da ferramenta e a modelagem entidade
relacionamento.
4.1 PROCESSO PROPOSTO
Com base nas normas estudas na Seção 2.2, no método MEDE-PROS e nos trabalhos
correlatos, propõem-se neste trabalho um novo processo para avaliação de qualidade de produto de
software. “Um processo ... bem definido deve indicar as atividades a serem executadas, os recursos
requeridos, os artefatos consumidos e produzidos e os procedimentos a serem adotados (métodos,
técnicas, modelos de documentos, entre outros)" (BERTOLLO; SEGRINI; FALBO, 2006). Um
processo padronizado é aquele que possui a descrição das atividades que devem ser considerados
nos projetos de software de uma organização, incluindo também os demais ativos de processo
envolvidos, dentre eles artefatos, procedimentos, ferramentas e papéis. Com base nos conceitos e
padrões de processo, esta seção apresenta o processo de avaliação de qualidade de produto de
software, que serviu de base para o desenvolvimento da ferramenta de apoio. O processo foi
construído a partir de três componentes: papel, atividade e artefato (VILLELA; TRAVASSOS;
ROCHA, 2004):
a) Papel: são os agentes do processo com perfis específico para execução de determinadas
atividades;
b) Atividade: caracteriza-se como uma ação transformadora dentro do processo, sempre
associada a um papel. Pode requerer um artefato de entrada, e também produzir um
artefato de saída; e
c) Artefato: é qualquer produto produzido ou consumido pelo papel em uma determinada
atividade, podendo ser de entrada e/ou saída.
37
Para modelar o processo foi utilizada uma notação baseada no diagrama de atividades da
UML. A Tabela 5 apresenta e descreve os elementos utilizados, facilitando o entendimento do
processo descrito na figura 14.
Tabela 5. Elementos do diagrama de atividade
Item Descrição
Indica uma atividade do processo.
Caixa que identifica um artefato, podendo ser de entrada ou de saída
Indicador de transição entre as atividades do processo
Indica a relação e dependência entre um artefato e uma atividade.
Raia que divide as atividades em relação aos papéis do processo.
Fork/Join: indica o início e fim simultâneo de atividades concorrentes.
Indica o início do processo
Indica o término do processo
Com base na definição do conceito de processo e a apresentação dos elementos utilizados,
propõe-se um novo processo para avaliação de qualidade de produto de software, apresentado na
Figura 14 e detalhado nas seções subsequentes.
38
Figura 14. Processo proposto
39
O processo de avaliação de qualidade de produto de software é composto de três papéis: (i)
fornecedor, que disponibiliza informações referentes ao software; (ii) coordenador, que organiza a
avaliação do ínicio ao fim; e (iii) avaliador, responsável por executar a avaliação do produto com
base no check-list de avaliação, destaca-se o requisito mínimo de 2 (dois) avaliadores por avaliação.
O processo é executado em três fases distintas, sendo: (i) identificação; (ii) planejamento e
execução; e (iii) conclusão.
4.1.1 Detalhamento das atividades
As atividades que compõem o processo de avaliação de qualidade de produto de software
podem ser conhecidas na Tabela 6, a qual apresenta uma descrição das atividades, os papéis
envolvidos, bem como os artefatos de entrada e/ou saída.
Tabela 6. Detalhamento das atividades
Atividade 01 Disponibiliza o software e documentação necessária
Descrição Esta atividade prevê que o fornecedor do produto deverá entregar para avaliação o produto completo, tal como é entregue aos usuários. Por exemplo, se o produto é instalado pelo fornecedor, este deverá proceder a instalação para avaliação. Caso o produto seja entregue em mídia específica para instalação pelo usuário, todos os componentes deverão ser enviados (por exemplo, manual, DVD lacrado, etc...).
Papéis envolvidos Fornecedor
Artefato de saída Documentação do produto de software
Atividade 02 Identifica o tipo de produto a ser avaliado e define os requisitos da avaliação
Descrição Com base no material disponibilizado pelo fornecedor, o coordenador da avaliação irá efetuar uma primeira análise do produto de software, definindo os requisitos e objetivos da avaliação. Tanto o fornecedor quanto o coordenador poderão documentar na ferramenta de apoio, informações sobre o fornecedor e o produto a ser avaliado.
Papéis envolvidos Coordenador e Fornecedor
Artefato de entrada Documentação do produto de software
Artefado de saída Requisitos de avaliação do produto de software
Atividade 03 Define normas e modelo de avaliação
40
Descrição Com o auxílio da documentação do produto de software e os requisitos da avaliação, o coordenador irá definir quais normas e/ou modelo de avaliação orientarão a avaliação. Nesta etapa são definidas quais as características do software serão avaliadas, por exemplo, se um software possui características de pacote de software, então a norma ISO/IEC 12119 poderá ser utilizada para avaliação.
Papéis envolvidos Coordenador
Artefato de entrada Requisitos do produto de software
Atividade 04 Define o check-list de perguntas para os avaliadores, com base nas métricas externas, internas e de uso.
Descrição Uma vez definidas as normas de qualidade para avaliação, o coordenador irá criar o check-list de perguntas, destinado aos avaliadores. As perguntas serão baseadas nas métricas de qualidade externas, internas e de uso.
Papéis envolvidos Coordenador
Artefato de saída Questionário para os avaliadores
Atividade 05 Produz o plano de avaliação e disponibiliza aos avaliadores
Descrição Após concluir a etapa de criação do check-list, o coordenador irá gerar o plano de avaliação, que irá conter a documentação do produto de software junto aos requisitos da avaliação, check-list de perguntas e informações sobre os avaliadores. O documento gerado servirá como auxílio ao fornecedor e coordenador para acompanhamento do processo de avaliação.
Papéis envolvidos Coordenador
Artefato de saída Plano de avaliação
Atividade 06 Acompanha os avaliadores e os resultados parciais
Descrição Com o do plano de avaliação, o coordenador irá acompanhar os resultados parciais da avaliação, monitorando os avaliadores e a evolução da avaliação.
Papéis envolvidos Coordenador
Artefato de entrada Plano de avaliação
Atividade 07 Acompanha o processo de avaliação
Descrição O fornecedor poderá acompanhar o processo de avaliação com o auxílio do plano de avaliação disponibilizado pelo coordenador, possuindo acesso restrito aos resultados parciais e finais.
Papéis envolvidos Fornecedor
Artefato de entrada Plano da avaliação
Atividade 08 Executa avaliação por módulos
41
Descrição Nesta atividade, os avaliadores executam a avaliação através do check-list definido pelo coordenador. As avaliações acontecem paralelamente (minímo dois avaliadores) e os resultados obtidos são documentados na ferramenta de apoio.
Papéis envolvidos Avaliador
Artefato de entrada Questionário para os avaliadores
Artefato de saída Resultado parcial
Atividade 09 Avalia o resultado parcial
Descrição Com base nos resultados parciais gerados, os avaliadores irão analisar as respostas e definir apenas um resultado para cada questão, considerando todas as respostas com o objetivo de chegar a um consenso.
Papéis envolvidos Avaliador
Artefato de entrada Resultado parcial
Atividade 10 Gera relatório parcial e encaminhar ao coordenador
Descrição Ao término da avaliação do resultado parcial, os avaliadores geram o relatório parcial e disponibilizam os resultados ao coordenador.
Papéis envolvidos Avaliador
Artefato de saída Relatório parcial
Atividade 11 Avalia relatório parcial
Descrição O coordenador irá avaliar o relatório parcial, observando se existe alguma divergência no resultado obtido e também se existe coerência nas respostas fornecidas. A partir do relatório parcial o coordenador irá criar o relatório final.
Papéis envolvidos Coordenador
Artefato de entrada Relatório parcial
Atividade 12 Gera o relatório final e encaminha ao fornecedor
Descrição Uma vez avaliado o relatório parcial, o coordenador conclui a avaliação e gera o relatório final. O relatório final será construído com informações que interessam ao fornecedor, tais como o resultado da avaliação e recomendações para melhoria do software.
Papéis envolvidos Coordenador
Artefato de saída Relatório final
Atividade 13 Recebe o resultado da avaliação
Descrição O fornecedor recebe a documentação final do resultado da avaliação do software que foi disponibilizado pelo coordenador.
Papéis envolvidos Fornecedor
Artefato de entrada Relatório final
42
4.1.2 Papéis
O processo proposto terá a participação de três papéis fundamentais:
a) Fornecedor: papel responsável por solicitar a avaliação do software e disponibilizar
informações e a documentação necessária sobre o mesmo;
b) Coordenador: responsável por receber o software, gerando a documentação necessária
para os avaliadores e o documento final para o fornecedor, participando também do
acompanhamento durante o processo de avaliação;
c) Avaliador: papel responsável por executar o questionário definido pelo coordenador,
fornecendo o relatório parcial da avaliação.
4.1.3 Artefatos
Artefatos são os produtos gerados ou utilizados por um papel em uma determinada
atividade. A seguir são descritos os artefatos envolvidos no processo proposto de avaliação de
qualidade de produtos de software.
a) Documentação do produto de software: Documento disponibilizado pelo fornecedor ao
coordenador com as informações do produto de software, necessárias para o coordenador
definir os requisitos da avaliação. Possui os seguintes itens, baseados na norma ISO/IEC
12119 (SQUARE 25051): descrição do produto, documentação de requisitos do sistema,
documentação de usuário.
b) Requisitos do produto de software: Artefato gerado pelo coordenador contendo os
requisitos da avaliação a partir da documentação fornecida pelo fornecedor. Será com base
neste documento que o fornecedor irá gerar o questionário para os avaliadores e também irá
compor o plano de avaliação. O documento gerado possui a lista com os requisitos do
sistema, baseada na série de normas ISO/IEC 9126 (SQUARE 25010, 25022, 25023 e
25024) e ISO/IEC 12119 (SQUARE 25051).
c) Questionário para os avaliadores: Documento gerado pelo coordenador para o avaliador
baseado nas métricas de avaliação de qualidade de produto de software. O artefato deverá
43
conter a lista com as perguntas, associadas as métricas internas, externas e de uso. Todas as
métricas avaliadas serão baseadas na série de normas ISO/IEC 9126 (SQUARE 25010,
25022, 25023 E 25024).
d) Plano de avaliação: Artefato gerado pelo coordenador contendo o plano de avaliação,
destinado ao próprio coordenador e ao fornecedor, para acompanhamento do processo. O
fornecedor terá acesso parcial ao plano de avaliação, itens como lista de perguntas e
resultados parciais, não serão visíveis ao mesmo. O documento gerado deve conter
informações sobre o software a ser avaliado, lista de perguntas gerada para os avaliadores e
dados dos avaliadores além do relatório parcial e final, conforme são concluídos. Este
artefato é baseado na série de normas ISO/IEC 14598-1, 14598-2 e 14598-6 (SQUARE
25001, 25040 e 25041).
e) Resultado parcial: Documento gerado pelos avaliadores ao término de cada avaliação e
contém as respostas para as perguntas que constam no artefato “Questionário para os
avaliadores”. A partir deste artefato, os avaliadores irão gerar o relatório final. O documento
gerado é baseado na norma ISO/IEC 14598-5.
f) Relatório parcial: Artefato gerado pelos avaliadores destinado ao coordenador e que irá
compor o relatório final. O relatório parcial é construído com base nos resultadados parciais
de cada avaliador. O documento gerado deve conter a resposta já analisada de todos os
avaliadores, baseado na norma ISO/IEC 14598-1 e 14598-2 (SQUARE 25001 e 25040).
g) Relatório final: Artefato gerado pelo coordenador e destinado ao fornecedor. É o produto
final da avaliação. Além do relatório parcial e dados do plano de avaliação, podem existir
sugestões de melhorias para a ferramenta avaliada, o que dependerá do resultado da
avaliação. Documento baseado na norma ISO/IEC 14598-6 (SQUARE 25041).
44
4.1.4 Relação das Normas Atendidas pelo Processo Proposto
Na Tabela 7 pode-se visualizar a relação entre as normas de qualidade comparado a cada
atividade do processo proposto, enfatizando os itens das normas que são atendidas pelo processo e
os itens que não são atendidos.
Tabela 7. Relação das normas atendidas quando comparadas ao processo
Norma Doc. Atividade que atende a norma O que não atende?
ISO/IEC 9126
1* Define normas e modelo de avaliação.
2*, 3*, 4* Define as perguntas para os avaliadores, com
base nas métricas externas, internas e de uso.
ISO/IEC 14598
1*, 2*, 6*
Identifica o tipo de produto a ser avaliado e define os requisitos da avaliação
14598-3 - Não contempla processo para desenvolvedores 14598-4 - Não contempla processo para adquirentes
Define normas e modelo de avaliação.
Define as perguntas para os avaliadores, com base nas métricas externas, internas e de uso.
Produz o plano de avaliação e disponibiliza aos avaliadores.
Avalia o resultado parcial e gera o relatório final
5
Executa a avaliação por módulos.
Avalia o resultado parcial.
Gera relatório parcial e encaminha ao coordenador.
ISO/IEC 12119
1*
Disponibiliza o software e documentação necessária.
`- Não atende ao teste de acompanhamento
Identifica o tipo de produto a ser avaliado e define os requisitos da avaliação.
Executa a avaliação por módulos
Gera relatório parcial e encaminha ao coordenador
Avalia o resultado parcial e gera o relatório final
ISO/IEC 25000
25051* Disponibiliza o software e documentação necessária
25012 - Não utiliza guia de modelo de qualidade de dados 25062 - Não contempla formato comum da indústria para relatórios
25000* 25001* 25030* 25040*
Identifica o tipo de produto a ser avaliado e define os requisitos da avaliação.
25000* 25001* 25010*
Define normas e modelo de avaliação.
45
25020* 25021* 25022* 25023* 25024* 25040*
Define as perguntas para os avaliadores, com base nas métricas externas, internas e de uso.*
de usabilidade
25001* 25040* 25041*
Produz o plano de avaliação e disponibiliza aos avaliadores.
25040*
Executa a avaliação por módulos.
Avalia o resultado parcial.
Gera relatório parcial e encaminha ao coordenador.
25001* Avalia o resultado parcial e gera o relatório final.
* O atendimento integral a esta norma também está condicionada às definições do coordenador
É importante ressaltar que o atendimento integral das normas de qualidade durante o
processo de avaliação proposto nesta seção, também depende das definições do coordenador ao
planejar o plano de avaliação.
Pode-se relacionar o método MEDE-PROS e o processo proposto com base nos três
documentos principais que compõem o método. A lista de verificação é atendida através da
atividade 04, onde o coordenador define o check-list de perguntas. Nesta atividade, as perguntas
podem ser baseadas na lista de verificação proposta pelo MEDE-PROS, que é um documento onde
constam exemplos de questões a serem aplicadas na avaliação.. Na etapa seguinte, podemos
relacionar o manual do avaliador à atividade 08, onde os avaliadores executam a avaliação. Nesta
atividade do processo, o documento fornececido pelo MEDE-PROS torna-se útil para orientar os
avaliadores durante a atividade. Por último, o modelo de relatório de avaliação está relacionado à
atividade 10, gerar relatório parcial. Nesta atividade os avaliadores geram o relatório que será
destinado ao fornecedor do produto de software, utilizando o documento do método como base para
gerar o relatório do documento.
46
4.2 PROJETO
Esta seção é responsável pela específicação da ferrramenta de apoio a avaliação da
qualidade de produto software e serviu de base para todo o processo de desenvolvimento do TCC II.
É apresentada em três etapas: (i) Definição dos requisitos e regras de negócio; (ii) Modelagem dos
casos de uso; e (iii) Modelagem entidade relacionamento.
4.2.1 Definição dos Requisitos e Regras de Negócio
Nesta seção são definidos os requisitos funcionais, não funcionais e as regras de negócio da
ferramenta a ser desenvolvida. As definições foram identificadas com base nas características
inerentes ao processo proposto.
Os seguintes requisitos funcionais foram identificados para a ferramenta proposta:
RF01 – O sistema deverá permitir o cadastro do coordenador
RF02 - O sistema deverá permitir ao coordenador e ao fornecedor cadastrar dados do
fornecedor;
RF03 - O sistema deverá permitir ao coordenador e ao fornecedor cadastrar dados do
produto de software;
RF04 – O sistema deverá permitir ao coordenador cadastrar dados dos avaliadores;
RF05 - O sistema deverá permitir ao coordenador e ao fornecedor definirem os
requisitos da avaliação;
RF06 - O sistema deverá permitir ao fornecedor acompanhar o processo de
avaliação;
RF07 - O sistema deverá permitir o coordenador definir o check-list de avaliação;
o RF07.01 – O coordenador poderá importar um check-list; e
o RF07.02 – O coordenador poderá adotar um check-list já cadastrado na
ferramenta.
47
RF08 - O sistema deverá permirir o coordenador gerar o plano de avaliação;
RF09 - O sistema deverá permitir o coordenador acompanhar o processo de
avaliação;
RF10 - O sistema deverá permitir que o avaliador execute o check-list de avaliação;
RF11 - O sistema deverá permitir aos avaliadores definir um relatório parcial e
encaminhar ao coordenador;
RF12 - O sistema deverá permitir o coordenador avaliar o relatório parcial;
RF13 - O sistema deverá permitir o coordenador gerar o relatório final e
disponibilizar ao fornecedor;
RF14 - O sistema deverá permitir ao fornecedor visualizar o relatório final;
RF15 – O sistema deverá permitir o coordenador exportar um check-list existente no
banco de dados da ferramenta; e
RF16 – O sistema deverá permitir o coordenador cadastrar escalas de avaliação.
Os seguintes requisitos não funcionais foram identificados para a ferramenta proposta:
RNF01 - A inteface da ferramenta deverá ser web, escrita em liguagem PHP;
RNF02 - O sistema deverá utilizar javascript para validar formulários;
RNF03 - O sistema deverá utilizar banco de dados MySQL;
RNF04 - O sistema deverá ser compatível com o browser Google Chrome versão
17.0;
RNF05 – A ferramenta deverá conter três módulos, com acessos restritos:
- Fornecedor: Acompanhar parcialmente a avaliação e obter o relatório final;
- Coordenador: Planejar e coordenar a avaliação, gerar o relatório final;
- Avaliador: Gerar os resultados e relatórios parciais da avaliação.
48
RNF06 - O check-list de perguntas deverá ser importado através de um arquivo
excel, com layout pré-definido e salvo em formato de texto separado por tabulação;
As seguintes regras de negócio foram identificadas para a ferramenta proposta:
RN01 - A avaliação deverá ser executada por, no mínimo, dois avaliadores;
RN02 - O relatório parcial só poderá ser gerado após todos os avaliadores
concluírem a avaliação parcial;
RN03 - o coordenador não poderá interferir nos resultados parciais, enquanto não
forem concluídos pelos avaliadores;
RN04 - O fornecedor não poderá ter acesso aos resultados parciais da avaliação;
RN05 - O relatório final só poderá ser gerado quando o reltório parcial for concluído;
RN06 - Os avaliadores não poderão alterar os resultados parciais da avaliação após
liberarem o relatório parcial ao coordenador;
RN07 - O check-list estará disponível aos avaliadores somente após o coordenador
produzir o plano de avaliação;
RN08 - O fornecedor deverá ter acesso aos resultados da avaliação após o
coordenador gerar o relatório final;
49
4.2.2 Modelos de Caso de Uso
Nesta seção são apresentados os diagramas de casos de uso da ferramenta criados na fase de
específicação. Os diagramas foram dividos a partir dos três principais módulos da ferramenta:
fornecedor, coordenador e avaliador. A Figura 15 apresenta os casos de uso do módulo fornecedor e
coordenador, demonstrando visualmente as funcionalidades que cada papel terá acesso na
ferramenta. Os papéis fornecedor e coordenador compartilham o acesso a alguns casos de uso,
como: login, cadatrar fornecedor, cadastrar dados do produto, definir os requisitos da avaliação e
acompanhar a avaliação. Os casos de uso cadastrar coordenador, cadastrar escala, definir o check-
list de avaliação, cadastrar avaliador, gerar plano de avaliação e gerar relatório final, são exclusivos
do papel coordenador.
Figura 15. Casos de Uso Módulo Fornecedor e Coordenador
Os casos de uso do módulo avaliador podem ser observados na Figura 16, basicamente
engloba duas atividades: avaliar o produto e gerar o relatório parcial.
50
Figura 16. Casos de uso módulo avaliador
No apêndice A está o detalhamento dos casos de uso apresentados nesta seção.
4.2.3 Modelagem Entidade Relacionamento
Para modelar a entidade relacionamento do banco de dados MySQL, foi utilizado a
ferramenta freeware MySQL Workbench 5.2 CE. A modelagem pode ser visualizada na figura 17.
Uma visão mais detalhada das tabelas e seus respectivos campos pode ser visualizado no Apêndice
B.
51
Figura 17. Modelagem entidade relacionamento
4.3 TELAS DO SISTEMA
As principais telas do sistema são apresentadas nesta seção. Algumas interfaces foram
anexadas ao apêndice C por serem consideradas menos relevantes.
O primeiro acesso a ferramenta de apoio é através da tela de login e senha. A figura 18 exibe
esta tela. A partir do login é identificado o perfil de acesso ao sistema, dividido em três módulos:
52
coordenador, fornecedor e avaliador, conforme descrito no RNF05. O menu da ferramenta é
carregado dinamicamente, de acordo com tipo de usuário que logou no sistema.
Figura 18. Acesso ao sistema
Através do login com perfil de coordenador, o usuário poderá acessar o cadastro de
coordenadores, avaliadores, fornecedores, produtos de software e escala. Também terá acesso ao
cadastro de requisitos de avaliação, check-list de avaliação (importação e exportação), cadastro do
plano, geração do relatório final, visualização do relatório final e acompanhamento da avaliação.
O usuário que acessar o sistema com login de coordenador terá acesso a alterar o próprio
cadastro, cadastrar produtos e requisitos de software, acompanhar a avaliação e visualizar o
relatório final. Com o perfil de avaliador, o usuário que logar no sistema terá acesso a alterar o
próprio cadastro, avaliar produtos de software e gerar o relatório parcial. A figura 19 exemplifica a
tela de cadastro de coordenador. As telas de cadastro de avaliador e fornecedor podem ser
visualizadas no apêndice C.
Figura 19. Cadastro de Coordenador
53
Após o coordenador responsável pela avaliação cadastrar o fornecedor do produto de
software e os avaliadores, efetuará o cadastrado de produto de software, conforme figura 20. Nesta
tela é possível informar o fornecedor responsável pelo produto, descrição, requisitos de software e
hardware, e demais informações. Esta atividade pode ser executada tanto pelo coordenador, quanto
pelo fornecedor.
Figura 20. Cadastro de produto de software
Ao finalizar a entrada de dados referente ao produto de software, é liberado ao coordenador
e fornecedor o acesso ao cadastro dos requisitos da avaliação, conforme figura 21. Neste tela é
possível informar o propósito, escopo e requisitos da avaliação.
Todos os item descritos nos parágrafos anteriores fazem parte da etapa de identificação do
processo proposto. Os próximos itens desta seção descrevem a fase de: (i) planejamento e controle,
e (ii) fase de conclusão, relacionando as telas do sistema.
54
Figura 21. Requisitos da avaliação
Antes de gerar o plano da avaliação, o coordenador deverá definir o check-list de avaliação.
O check-list poderá ser visualizado, exportado e importado para o banco de dados da ferramenta
através do menu “Check-list”, apresentado na figura 22. O check-list deverá ser importado através
de um arquivo de texto (extensão *.txt), salvo em formato UFT-8 e com layout pré definido. O
modelo para criar o arquivo pode ser consultado no apêndice D.
Figura 22. Gerenciar check-list
Antes de importar o check-list, o coordenador deverá cadastrar as escalas de avaliação
(figura 23), que serão utilizadas pelos avaliadores para responder as perguntas da avaliação. Nesta
tela deverá ser definida uma chave, indicador e a descrição da escala. A chave tem como objetivo
facilitar a importação do arquivo, e serve como um identificador da escala dentro do banco. O
55
coordenador da avaliação cria a chave da escala, elemento utilizado posteriormente no arquivo de
importação das questões para avaliação. O indicador informa se o peso da escala na avaliação será
positiva, negativa ou neutra. A descrição é o texto das possíveis respostas que irão ser apresentadas
para o avaliador, na fase de avaliação e consolidação.
Figura 23. Cadastro de escala
Após definir as escalas e importar o check-list, o próximo passo será cadastrar o plano de
avaliação. Esta funcionalidade permite definir os avaliadores (sendo no mínimo dois), uma data de
início e término e o check-list de avaliação, conforme figura 24. A partir do plano, os avaliadores
terão acesso para avaliar o produto de software e o coordenador e fornecedor poderão acompanhar o
processo de avaliação.
Figura 24. Gerar plano de avaliação
56
Na tela de acompanhamento da avaliação (figura 25), tanto o fornecedor quanto o
coordenador poderão visualizar dados como: número de questões, porcentagem de conclusão geral
e porcentagem por avaliador.
Figura 25. Acompanhar avaliação
57
Após o coordenador concluir o plano, os avaliadores terão acesso para efetuar a avaliação do
produto de software. Nesta tela, representada pela figura 26, será possível visualizar as questões
definidas no check-list. A apresentação é ordenada por categoria e sub-categoria de avaliação,
juntamente ao conjunto de escala definida para a pergunta. Na resposta, o avaliador deverá
obrigatoriamente responder a uma das escalas, podendo informar um comentário e/ou anexar um
arquivo de imagem (extensões gif, png ou jpeg) com evidências dos testes. O avaliador poderá
concluir uma avaliação somente quando todas as questões tiverem sido respondidas.
Figura 26. Avaliar produto
Após todos os avaliadores concluírem a avaliação individual, a tela de consolidação das
respostas é liberada (figura 27). Nesta interface os avaliadores poderão visualizar as respostas
individuais de cada avaliador, junto aos respectivos comentários e anexos.
O processo de consolidação consiste em avaliar e definir uma resposta de consenso por
questão, e também os comentários positivos, negativos e observações de cada categoria avaliada.
Esta funcionalidade foi implementada com o objetivo de facilitar a atividade de geração do relatório
parcial da avaliação. O usuário que efetuar a consolidação poderá visualizar, na mesma tela, a
resposta de cada avaliador para todas as questões do check-list, onde é possível também verificar os
comentários e anexos. Ao clicar no checkbox do comentário individual do avaliador, o texto será
automaticamente incluído na caixa de comentário da categoria. O texto será inserido na caixa de
acordo com o indicador da escala de resposta do avaliador, podendo ser do tipo negativo, positivo
ou observação. O indicador é definido no cadastro de escala.
58
Figura 27. Gerar relatório parcial
Após os avaliadores concluírem a consolidação da avaliação parcial, o sistema permitirá o
coordenador analisar e alterar os resultados de cada categoria avaliada (figura 28). Nesta fase as
respostas individuais por avaliador não serão mais visíveis, sendo possível visualizar e editar apenas
os comentários de cada categoria avaliada. Esta etapa compreende o término da fase de
planejamento e controle do processo proposto, passando para a fase seguinte: conclusão.
59
Figura 28. Liberar relatório parcial
Após a liberação do resultado da avaliação pelo coordenador, o fornecedor do produto em
questão poderá visualizar o relatório final. O objetivo do relatório final é exibir os resultados
negativos, positivos e observações de cada categoria do software avaliado. A tela do relatório final
pode ser visualizada na figura 29.
60
Figura 29. Visualizar relatório final
61
4.4 AVALIAÇÃO DA FERRAMENTA
Com o objetivo de avaliar a ferramenta de apoio, a partir de um produto de sofware
pertencente a empresa no qual o acâdemico trabalha, foi elaborado um plano para a avaliação. As
próximas seções foram destinadas a documentação do planejamento da avaliação e os resultados
obtidos. É importante frisar que esta é uma avaliação preliminar da ferramenta de apoio e, como
trabalhos futuros, sugere-se elaborar um plano de avaliação com outros produtos de software e
outras pessoas para os papéis do processo. O objetivo de efetuar mais avaliações é de validar não
apenas o software, mas também o processo proposto.
4.4.1 PLANEJAMENTO DA AVALIAÇÃO
Para avaliar a ferramenta de apoio tornou-se necessário escolher um produto de software, e
com base neste software, montar um plano de avaliação seguindo os moldes detalhados no processo
proposto. O produto de software escolhido foi um módulo específico de intranet da empresa Brasil
Foods S/A, chamado OLQR - Online Quick Report (figura 30) que tem como objetivo orientar os
colaboradores da empresa através de relatórios contendo o passo à passo na execução de transações
do sistema ERP da empresa. Para reproduzir um cenário de testes seguro e íntegro, foram
selecionadas pessoas diferentes para cada papel na avaliação, sendo: um fornecedor, um
coordenador e dois avaliadores. Vale ressaltar que os avaliadores não possuem conhecimento sobre
qualidade de software ou experiência em avaliação de produto de software. Os resultados da
avaliação destes papéis foram baseados em seus conhecimentos referente ao produto avaliado e
orientações do acâdemico sobre o objetivo da avaliação e como utilizar a ferramenta de apoio.
62
Figura 30. OLQR - Online Quick Report
Para o papel de avaliador, foram selecionados dois colaboradores da Brasil Foods S/A. O
primeiro, Alexsandro Moraes, trabalha na área de controladoria como analista fiscal e acessa o
módulo OLQR esporadicamente quando há dúvidas sobre o processo de execução nas transações
novas. O segundo avaliador, Cristina Bernardi, trabalha na área de melhoria contínua, na função de
analista sênior. Segundo a usuária, o acesso ao módulo é efetuado sempre que surge um processo
desconhecido para ela na empresa. A ferramenta de apoio foi publicada em um servidor web,
fornecido pela UNIVALI, possibilitando o acesso do sistema pelos avaliadores.
O papel de coordenador foi efetuado pela orientadora deste trabalho, Fabiane B. V. Benitti e
para o papel de fornecedor foi definido o próprio acadêmico, que também trabalha na empresa
Brasil Foods S/A e possui acesso ao produto de software avaliado.
Os testes da ferramenta aconteceram nos dias 24 e 25 de fevereiro de 2012. A localização foi
no CSC – Centro de Seviços Compartilhados da Brasil Foods localizado em Itajaí, estado de Santa
Catarina. O tempo de duração foi de aproximadamente duas horas por avaliador. O check-list
utilizado na avaliação esta anexado ao apêndice E, sendo que os critérios adotados foram extraídos
do método de avaliação MEDE-PROS.
63
O cenário de testes seguiu todas as etapas do processo proposto para avaliação. O cadastro
do produto de software e requisitos de avaliação foram efetuados pelo fornecedor e a definição do
checklist e do plano teve a aprovação do coordenador. Os avaliadores receberam o login e senha
para o acesso a ferramenta. O acadêmico repassou os objetivo da atividade e uma breve orientação
de como executar a avaliação e consolidação através da ferramenta. Ao final dos testes foi aplicado
um questionário de avaliação referente ao uso da ferrementa de apoio, com perguntas não objetivas
sobre ao funcionamento geral e interface. O questionário de avaliação pode ser visualizado no
apêndice F. A figura 31 demonstra um diagrama com as etapas da valiação da ferramenta de apoio,
relacionado as atividades aos participantes da avaliação.
64
Figura 31. Etapas e atividades da avaliação
65
4.4.2 RESULTADOS DA AVALIAÇÃO
Esta seção tem como objetivo apresentar os resultados da avaliação do produto de software
avaliado e da ferramenta de apoio. O texto foi escrito com base no relatório final de avaliação do
produto de software e no questionário de avaliação da ferramenta de apoio.
4.4.2.1 Resultados da avaliação do produto de software
Na maioria das questões a resposta dos avaliadores foi unânime, e de uma maneira geral o
resultado foi positivo. A padronização e a formatação de ícones e janelas, a ausênsia de erros
gramaticais e ortográficos e a não ocorrência de falhas durante a execução foram aspectos
considerados positivos no produto de software avaliado. Como aspectos negativos, foram
destacados a dificuldade na utilização da interface de busca de relatórios OLQR e a falta de
entendimento sobre o objetivo do sistema no primeiro acesso do usuário no sistema. Algumas
imagens de tela do produto de software foram anexadas para evidênciar a resposta. O relatório final,
que é o resultado obtido através do processo de avaliação, pode ser visualizado no apêndice G.
4.4.2.2 Resultados da avaliação da ferramenta de apoio
Ao término dos testes, o questionário de avaliação da ferramenta de apoio foi respondido
pelos avaliadores.Os dois avaliadores concordaram que as funcionalidades do sotware estão
apresentadas de forma clara e de fácil entendimento. Ao questionar se as funcionalidades do
software são suficientementes adequadas, um avaliador respondeu que concorda e outro que
concorda veemente. Referente a performance do software, os dois avaliadores concordam veemente
que é satisfatório. Ambos concordaram veemente que há facilidade na utilização do software.
Nas críticas e sugestões um dos avaliadores citou que a funcionalidade de anexos na etapa
de avaliação pode ser melhorada afim de facilitar a forma de upload, pois houve dúvidas no
momento de verificar se uma imagem estava anexado a uma questão. Foi sugerido também uma
funcionalidade de ajuda na ferramenta, com textos explicativos, caso haja dúvidas sobre o
funcionamento do sistema.
66
5. CONCLUSÃO
O conceito deste projeto surgiu da necessidade em ter uma ferramenta que apóie o processo
de avaliação de qualidade de produto de software. Considerando este fator básico, foi desenvolvida
a ideia de um novo processo de avaliação, com base nos conceitos, normas e métodos existentes na
área de estudo relacionada ao tema. A partir deste processo, foi especificada a ferramenta visando
apoiar o processo proposto e garantir que todas as etapas fossem cumpridas.
As pesquisas ao tema de estudo tiveram foco nas normas e métodos de avaliação de
qualidade de software e serviram de base para desenhar o processo proposto dentro de padrões
aceitáveis. A necessidade de pesquisar soluções similares evidenciou a dificuldade em encontrar
ferramentas disponíveis e acessíveis a comunidade em geral, propiciando o estudo e
desenvolvimento de uma ferramenta que atenda esta necessidade. A modelagem do processo foi
representada através de um diagrama de atividades UML e serviu como apoio para especificar a
ferramenta a ser criada.
Durante a implementação do sistema foram efetuadas análises com os diagramas de caso de
uso e de entidade relacionamento, visando garantir que todas os itens especificados fossem
atendidos seguindo o padrão estabelecido no projeto. Ao final do desenvolvimento foram efetuados
os testes de validação da ferramenta, onde constatou-se que o sistema consegue atender todos os
requisitos e regras de negócio.
Através da avaliação, constatou-se que a ferramenta de apoio atende a todas as etapas do
processo proposto, e como resultado, teve-se um produto de software avaliado, onde foram
elencandas as características positivas, negativas e observações referentes aos componentes
avaliados.
Com a conclusão deste trabalho, espera-se que os resultados sejam úteis para a área de
qualidade de produto software, devido a carência de estudos e de ferramentas para automatização
do processo de avaliação disponíveis no meio acâdemico e privado. Como principais contribuições
que este trabalho proporciona pode-se citar a pesquisa na área de qualidade de produto de software,
a proposta de um novo processo de avaliação baseado nas normas mais relevantes do mercado e por
último, uma ferramenta de apoio construída com base no processo.
67
5.1 Trabalhos Futuros
Durante a avaliação do software foi identificado que a interface da ferramenta pode ser
melhorada, exibindo menus mais bem estruturados e otimizando o layout das funcionalidades
existentes.
Outro ponto que pode ser tratado como trabalhos futuros é a funcionalidade de anexo na fase
de avaliação, consolidação e geração do relatório final. Pretende-se otimizar a interface de upload,
além de incluir a opção de edição de arquivos já anexados e também a pré-visualização dos
arquivos na fase de avaliação e consolidação. Foi identificada também a necessidade de efetuar
cenários de teste variados, com outros produtos de software e pessoas diferentes para representar os
papéis, afim de validar não apenas a ferramenta, mas também o processo proposto.
Por fim, identificou-se também a necessidade de implementar uma opção de ajuda para os
usuários da ferramenta, caso existam dúvidas sobre o processo de funcionamento do sistema.
REFERÊNCIAS BIBLIOGRÁFICAS
ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 12119-1:
Tecnologia de informação - Pacotes de software - Teste e requisitos de qualidade. Rio de Janeiro,
1998.
ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 9126-1:
Engenharia de Software - Qualidade de produto - parte 1: modelo de qualidade. Rio de Janeiro,
2003.
ALSULTANNY, Y. A; WOHAISHI, A. M. Requirements of Software quality Assurance
Model. 2009. Artigo da Enviroment and Computer Science – Second Internacional Conference.
ANDRADE, D. Gomes de; FALK, J. Anthony. Eficácia de sistemas de informação e percepção
de mudança organizacional: um estudo de caso. Disponível em:
<http://dx.doi.org/10.1590/S1415-65552001000300004>. Acesso em: 05 ago. 2011.
ANJOS, L. A. Mendonça dos; MOURA, H. P. de. Um modelo para avaliação de produtos de
software. 2002. Artigo da Universidade Federal de Pernambuco.
BARTIÉ, Alexandre. Garantia de qualidade de software: adquirindo maturidade organizacional.
Rio de Janeiro, RJ: Campus, 2002.
BERTOLLO, G.; SEGRINI, B.; FALBO, R. de A. Definição de processos de software em um
ambiente de desenvolvimento de software baseado em ontologias. 2006. Artigo do V Simpósio
Brasileiro de Qualidade de Software.
BORGES, J. Manoel. Ambiente web de suporte ao processo de avaliação da qualidade de
produtos de software. 2006. Trabalho de Conclusão de Curso (Bacharelado em Ciências da
Computação) - Universidade Regional de Blumenau, Blumenau, 2006.
COLOMBO, R. M. Thienne. Processo de avaliação da qualidade de pacotes de software. 2004.
Dissertação de Mestrado (Ciência da Computação) - Universidade Estadual de Campinas,
Campinas, 2004.
DUARTE, K. C; FALBO, R. A. Uma ontologia de qualidade de software. 2006. Dissertação de
Mestrado (Engenharia Mecânica) - Universidade Federal do Espírito Santo, Vitória, 2006.
69
FORTES, R. P. de M.; SILVA, E. A. da; PAIVA, D. M. Barroso. Utilizando a Norma ISO IEC
14598-5 na Avaliação de Qualidade de Hiperdocumentos Web. 2001. Artigo da Universidade de
São Paulo.
GOMES FILHO, M. J. A.. Um processo de avaliação da portabilidade de unidades de software.
2005. Trabalho de Conclusão de curso (Graduação em Ciência da Computação) - Universidade
Federal de Pernambuco, Recife, 2005.
GUERRA, A. C.; COLOMBO, R, T.; VILLALOBOS, M. T. Processo de avaliação de produtos
de software. 2005. Artigo do Centro de Pesquisas Renato Archer.
GUERRA, A. C; COLOMBO, Regina M. T. Tecnologia da informação: qualidade de produto de
software. Brasilia: PBQP, 2009.
KOSCIANSKI, A. et al. ABNT - Guia para utilização das normas sobre avaliação de qualidade
de produto de software - ISO/IEC 9126 e ISO/IEC 14598. Paraná: Curitiba, 1999.
KOSCIANSKI, André; SOARES, M. dos Santos. Qualidade de software: aprenda as
metodologias e técnicas mais modernas para o desenvolvimento de software. 1.ed. São Paulo:
Novatec, 2007.
MARINHO, D. S; SOUSA, E. J. Pesquisa de Qualidade no Setor de Sotware Brasileiro 2009.
Disponível em: < http://www.blogcmmi.com.br/qualidade/pesquisa-de-qualidade-no-setor-de-
software-brasileiro-de-2009 >. Acesso em: 20 ago. 2011.
MPS.BR -Melhoria de Processo do Software Brasileiro Guia de Aquisição. <
http://homepages.dcc.ufmg.br/~rodolfo/GPS1-Turma11/MPS.BR_Guia[1].pdf > Acesso em: 28
ago. 2011.
OLIVEIRA, K. R. AdeQuaS: Ferramenta Fuzzy para Avaliação da Qualidade de Software. 2002.
Dissertação de Mestrado (Informática Aplicada) - Universidade de Fortaleza, Fortaleza, 2002.
PRESSMAN, R.S. Engenharia de Software. 5.ed. Rio de Janeiro: McGraw Hill, 2002.
REED, K. Software engineering – a new millennium?. 2000. Artigo da IEEE Computer Society
Press.
70
ROCHA, A. R. Cavalcanti da; MALDONADO, J. Carlos; WEBER, K. Chaves. Qualidade de
software. São Paulo: Prentice Hall, 2001.
SANTOS, L. dos Bays; PRETZ, E. Framework para Especializações de Modelos de Qualidade
de Produtos de Software. Trabalho de Conclusão de Curso (Bacharelado em Ciência da
Computação) – FEEVALE, Novo Hamburgo, 2009.
SIBISI, M; WAVEREN, C. c. van. A process framework for customising software quality
models. 2007. Artigo da Altech UEC Technol.
SODRÉ, C. C. Pelizer. Avaliador: uma ferramenta de apoio à aplicação da norma ISO/IEC 9126
para avaliação da qualidade de produtos de sofware. Estágio obrigatório desenvolvido durante o 4°
ano do Curso de Graduação (Bacharelado em Ciência da Computação) - Universidade Estadual de
Londrina, Londrina, 2006.
SURYN, W.; ABRAN, A. ISO/IEC SQuaRE. The second generation of standarts for software
product quality. 2003. Artigo do Departament of Electrical Engineering, École de Technologie
Supérieure.
VILLELA, K.; TRAVASSOS, G. H.; ROCHA, A. R. C. Definição e construção de ambientes de
desenvolvimento de software orientados a organização. 2004. Artigo da Universidade Federal do
Rio de Janeiro.
VIVEIROS, S. Pereira. Um estudo para a utilização do método QFD na definição de medidas
de qualidade de produtos de software. Dissertação de Mestrado (Ciência da Computação) -
Universidade Federal de Minas Gerais, Belo Horizonte, 2006.
71
APÊNDICES
72
APÊNDICE A – DETALHAMENTO DOS CASOS DE USO
Da Tabela 8 à 20 são detalhados os casos de uso, visando um melhor entendimento das
funcionalidades previstas.
Tabela 8. UC01. Login
Descrição UC01. Login
Objetivo
Permitir que o coordenador, fornecedor e avaliadores acessem a ferramenta através de um login e senha previamente cadastrados, com o objetivo de restringir o acesso a determinados módulos e funções do sistema.
Relações RNF05
Pré-condição Usuário com cadastro ativo no sistema
Pós-condição Um usuário logado no sistema
Tabela 9. UC02 Cadastrar Coordenador
Descrição UC02. Cadastrar Coordenador
Objetivo
Permitir o coordenador criar, alterar e consultar seu próprio cadastro no sistema, informando dados necessários para o primeiro login na ferramenta com perfil de coordenador. A partir da criação do cadastro do coordenador, será possível iniciar um processo de avaliação.
Relações RF01
Pós-condição Um coordenador foi cadastrado no sistema
Tabela 10. UC03 Cadastrar Fornecedor
Descrição UC03. Cadastrar Fornecedor
Objetivo Permitir ao coordenador criar, alterar, consultar e excluir dados do fornecedor. Após logado no sistema, o fornecedor terá acesso a consulta e alteração do próprio cadastro.
Relações RF02
Pré-condição Um coordenador ou fornecedor logado no sistema
Pós-condição Um fornecedor foi cadastrado no sistema
Tabela 11. UC04 Cadastrar dados do produto
Descrição UC04. Cadastrar dados do produto
73
Objetivo
Permitir que o fornecedor e o coordenador cadastrem um produto de software no sistema. Os dois perfis terão acesso a inclusão, exclusão, alteração e consulta ao produto de software.
Relações RF03
Pré-condição Ter um fornecedor ou um coordenador logado no sistema
Pós-condição Um produto foi cadastrado no sistema
Tabela 12. UC05 Definir os requisitos da avaliação
Descrição UC05. Definir os requisitos da avaliação
Objetivo
Permitir acesso ao fornecedor e ao coordenador cadastrar os requisitos da avaliação do produto de software. Ambos os perfis terão acesso a inclusão, exclusão, alteração e consulta aos requisitos da avaliação.
Relações RF05
Pré-condição Ter um fornecedor ou um coordenador logado no sistema
Pós-condição Os requisitos da avaliação foram cadastrados no sistema.
Tabela 13. UC06 Acompanhar avaliação
Descrição UC06. Acompanhar avaliação
Objetivo
Permitir o acompanhamento da avaliação ao coordenador e ao fornecedor. A ferramenta irá apresentar um relatório com o porcentual e dados referente o andamento da avaliação. Os dados serão mostrados na tela totalizando o total de conclusão da avaliação, dividido por avaliadores e total geral geral.
Relações RF06, RF09, RN06
Pré-condição Um plano de avaliação gerado
Protótipo
Tabela 14. UC07 Cadastrar escala
Descrição UC07. Cadastrar escala
Objetivo
Permitir o coordenador cadastrar escalas de avaliação, que serão utilizadas no processo de importação do arquivo para definir o check-list de avaliação. O cadastro das escalas de avaliação serão baseadas no padrão de respostas descrito na lista de verificação do método MEDE-PROS.
74
Relações RF16
Pré-condição Ter um coordenador logado no sistema
Pós-condição Uma escala foi cadastrada no sistema
Tabela 15. UC08 Definir check-list da avaliação
Descrição UC08. Definir check-list da avaliação
Objetivo
Permitir ao coordenador definir o check-list da avaliação. Para importar um novo check-list, o coordenador deverá editar um template padrão em planilha eletrônica, com formato pré-definido, visando facilitar a criação de check-lists extensos. Após concluir a edição do check-list, o coordenador da avaliação irá utilizar a funcionalidade “importar check-list” para carregar as dados para o sistema. O arquivo de planilha eletronica deverá ser salvo em formato de texto separado por tabulação. Caso coordenador deseje extrair um check-list existente na base de dados, poderá utilizar a funcionalidade exportar check-list. Nesta atividade a importação poderá ser feita de três maneiras diferentes: importar um novo check-list; adotar um check-list já cadastrado; ou editar um já existente.
Relações RF07, RF07.01, RF07.02, RF15, RNF06, RN07
Pré-condição Requisitos do produto de software gerado
Pós-condição Check-list de avaliação criado
Cenário Principal
Importar e gerar check-list
1. O coordenador seleciona a opção "importar check-list";
2. A ferramenta solicita o arquivo para importação;
3. O coordenador localiza e seleciona o arquivo para importar;
4. A ferramenta exibe a mensagem "Confirma importação do check-list?"
5. O coordenador confirma a importação;
6. O arquivo é importado para a ferramenta;
7. A ferramenta exibe a mensagem "Importação realizada com sucesso"
8. A ferramenta exibe o check-list importado
9. O coordenador seleciona a opção “gerar check-list”
10. A ferramenta apresenta a mensagem “Check-list gerado com sucesso”
Cenário Alternativo 01
Definir check-list existente
1. O coordenador seleciona a opção "Selecionar check-list existente"
75
2. A ferramenta apresenta a lista de check-list cadastrados no banco de dados
3. O coordenador seleciona o check-list desejado
4. A ferramenta exibe a mensagem "Confirma seleção do check-list?"
5. O coordenador confirma a seleção
6. A ferramenta exibe a mensagem "Seleção realizada com sucesso"
7. A ferramenta exibe o check-list selecionado
Cenário Alternativo 02
Exportar check-list existente no banco de dados
1. O coordenador seleciona a opção “Exportar check-list”
2. O sistema apresenta uma lista de check-list existentes no banco de dados
3. O coordenador seleciona o check-list desejado
4. A ferramenta abre a caixa de seleção do caminho de diretório onde será salvo o arquivo
5. O coordenador define o caminho e seleciona a opção “abrir”
6. O coordenador seleciona a opção “Exportar”
7. A ferramenta apresenta a mensagem “Confirma a exportação do check-list?”
8. O coordenador confirma a exportação
9. A ferramenta exibe a mensagem “Arquivo exportado com sucesso”
Cenário Exceção
Erro ao importar/exportar o arquivo
Se no passo 4 do cenário principal ocorrer algum erro:
4.1. o sistema apresenta a mensagem de erro: "Erro ao importar, verifique o layout do arquivo selecionado";
4.2. O sistema cancela a importação e volta para o passo 2;
Se no passo 4 do cenário alternativo 01, ocorrer algum erro:
4.1. O sistema apresenta a mensagem de erro: "Erro: arquivo não importado".
4.2. O sistema cancela a importação e volta para o passo 2;
Se no passo 5 do cenário principal, alternativo 01 o fornecedor cancelar a importação ou seleção do arquivo:
5.1. O sistema cancela a importação e volta para o passo 2;
Se no passo 7 do cenário alternativo 02, o coordenador não confirmar a exportação do arquivo:
76
7.2. O Sistema cancela a exportação e retorna ao passo 2.
Se no cenário 9 do cenário alternativo 02, ocorrer algum erro na exportação:
9.1. O sistema apresenta a mensagem “Erro: arquivo não exportado”;
9.2. O sistema volta ao passo 2.
Tabela 16. UC09 Cadastrar avaliador
Descrição UC09. Cadastrar Avaliador
Objetivo Permitir ao coordenador incluir, alterar, excluir e consultar o cadastro dos avaliadores. Os avaliadores terão acesso somente a visualização de seu próprio cadastro.
Relações RF04
Pré-condição Um coordenador logado no sistema
Pós-condição Um avaliador foi cadastrado no sistema
Tabela 17. UC10 Gerar plano da avaliação
Descrição UC10. Gerar plano da avaliação
Objetivo Permitir o coordenador gerar o plano de avaliação do produto de software, permitindo o início da execução da avaliação pelos avaliadores.
Relações RF08
Pré-condição Check-list gerado
Ter um um coordenador logado no sistema
Pós-condição Plano de avaliação criado e avaliação disponível para o avaliador
Tabela 18. UC11 Avaliar o produto
Descrição UC11. Avaliar o produto
Objetivo
Permitir os avaliadores executarem o a avaliação através do check-list de perguntas definido pelo coordenador. Os avaliadores terão acesso a alteração das respostas, o coordenador acesso apenas a visualização e o fornecedor terá acesso restrito as informações geradas por este caso de uso.
Relações RF10, RN01
Pré-condição
Questionário para os avaliadores criado
Ter um avaliador logado no sistema
77
Pós-condição
Resultado parcial criado
Cenário principal
Avaliar o produto
1. O avaliador seleciona a opção “Avaliar produto de software”.
2. O sistema apresenta o check-list de perguntas
3. O avaliador responde as perguntas
4. O avaliador seleciona a opção concluir avaliação
5. O sistema apresenta a mensagem: “Avaliação concluída com sucesso”
Cenário exceção
Erros
Se no passo 4 existir uma ou mais perguntas pendentes de resposta:
6.1. O sistema apresenta a mensagem de erro: “Para concluir a avaliação é necessário que todas as perguntas sejam respondidas”.
6.2. O sistema retorna ao passo 2
Tabela 19. UC12 Gerar o relatório parcial
Descrição UC12. Gerar o relatório parcial
Objetivo
Permitir aos avaliadores efetuar a consolidação dos resultados obtidos através da execução do check-list, obtendo uma única resposta para cada pergunta. O acesso para gerar o relatório parcial será exclusivamente dos avaliadores, sendo que o cordenador e fornecedor não terão acesso a esta função.
Relações RF11, RN02, RN06
Pré-condição Avaliação concluída por todos os avaliadores
Ter um avaliador logado no sistema
Pós-condição Relatório parcial gerado
Cenário Principal
Gerar relatório parcial
1. O avaliador seleciona a opção “Gerar relatório parcial”.
2. O sistema apresenta os resultados parciais
3. Os avaliadores definem e selecionam uma única resposta para as perguntas
4. O avaliador seleciona a opção “Concluir geração do relatório parcial”
5. O sistema apresenta a mensagem “Relatório parcial gerado com sucesso”
78
Cenário exceção
Erros
Se no passo 4 existir uma ou mais perguntas que não foram consolidadas:
1. O sistema apresenta a mensagem de erro: “Para concluir o relatório parcial, todas as respostas devem estar consolidadas”
Se no passo 1 o relatório parcial já estiver sido disponibilizado ao coordenador:
1. O sistema apresenta a mensagem de erro: “Relatório parcial da avaliação já concluído e disponibilizado ao coordenador, não é possível alterar”.
Tabela 20. UC13 Gerar o relatório final
Descrição UC13. Gerar o relatório final
Objetivo
Permitir que o coordenador gere o relatório final com base no relatório parcial gerado pelos avaliadores e que o fornecedor visualize o realtório final. Somente o coordenador da avaliação terá acesso para gerar o relatório final. Uma vez gerado o relatório final, o fornecedor terá acesso para visualização do mesmo. A geração do relatório final consiste em avaliar o relatório parcial e, de acordo com os critérios do coordenador da avaliação, será encaminhado ou não para o fornecedor do produto de software. Neste caso de uso o coordenador irá avaliar se os resultados estão de acordo com os requisitos da avaliação, definidos na primeira etapa do processo e se o resultados estão condizentes com o plano de avaliação.
Relações RF12 , RF13, RN03, RN05, RN08
Pré-condição Relatório parcial gerado
Ter um coordenador logado no sistema
Pós-condição Relatório final gerado
79
APÊNDICE B – DICIONÁRIO DE DADOS DO MODELO ER
Para melhor entendimento de como será a estrutura do banco de dados, a Tabela 21
apresenta o dicionário de dados do modelo entidade relacionamento do banco de dados.
Tabela 21. Dicionário de dados do modelo ER
avaliador
Atributo Tipo Tamanho Descrição
idavaliador INT chave primária
nome_aval VARCHAR 45 nome
login_aval VARCHAR 15 login
senha_aval VARCHAR 15 senha
sex_aval INT sexo
email_aval VARCHAR 45 email
tel_aval VARCHAR 20 telefone
ender_aval VARCHAR 60 endereço
cidade_aval VARCHAR 45 cidade
uf_aval VARCHAR 20 estado
cep_aval VARCHAR 9 cep
avalplan
Atributo Tipo Tamanho Descrição
idavaliador INT cheve estrageira com a tabela avaliador
idplano INT chave estrangeira com a tabela plano
check_categoria
Atributo Tipo Tamanho Descrição
idcheck_categoria INT chave primária
idcheck_subcategoria INT chave da sub-categoria
idchecklist INT chave estrangeira com tabela checklist
desc_categoria VARCHAR 45 descrição da categoria
checklist
Atributo Tipo Tamanho Descrição
idchecklist INT chave primária
nome_checklist VACHAR 45 nome do check-list
consolidacao
Atributo Tipo Tamanho Descrição
idconsolidacao INT chave primária
idcheck_categoria INT chave estrangeira com a tabela check_categoria
positivo_categoria VARCHAR 255 comentário positivo da categoria avaliada
negativo_categoria VARCHAR 255 comentário negativo da categoria avaliada
obs_categoria VARCHAR 255 observação da categoria
80
anexo_cagegoria BLOB anexo da categoria
idplano INT chave estrangeira com a tabela plano
coordenador
Atributo Tipo Tamanho Descrição
idcoordenador INT chave primária
nome_coord VARCHAR 45 nome
login_coord VARCHAR 15 login
senha_coord VARCHAR 45 senha
sex_coord INT sexo
email_coord VARCHAR 45 email
tel_coord VARCHAR 20 telefone
ender_coord VARCHAR 60 endereço
cidade_coord VARCHAR 45 cidade
uf_coord VARCHAR 20 estado
cep_coord VARCHAR 9 cep
escala
Atributo Tipo Tamanho Descrição
idescala INT chave primária
chave_escala VARCHAR 2 chave que indica a escala
ind_escala VARCHAR 45 indicação
desc_escala VARCHAR 45 descrição
fornecedor
Atributo Tipo Tamanho Descrição
idfornecedor INT chave primária
nome_for VARCHAR 45 nome
resp_for VARCHAR 45 reponsável
login_for VARCHAR 15 login
senha_for VARCHAR 15 senha
sex_for INT sexo
email_for VARCHAR 45 email
tel_for VARCHAR 20 telefone
ender_for VARCHAR 60 endereço
cidade_fr VARCHAR 45 cidade
uf_for VARCHAR 20 estado
cep_for VARCHAR 9 cep
grupo_resposta
Atributo Tipo Tamanho Descrição
idquestao INT chave estrangeira com a tabela questao
idescala INT chave estrangeira com a tabela escala
plano
Atributo Tipo Tamanho Descrição
idplano INT chave primária
81
idchecklist INT chave estrangeira com a tabela chacklist
idcoordenador INT chave estrangeira com a tabela coordenador
dt_inicio DATE data início
dt_fim DATE data fim
produto
Atributo Tipo Tamanho Descrição
idproduto INT chave primária
idfornecedor INT chave estrangeira com a tabela fornecedor
idplano INT chave estrangeira com a tabela plano
nome_prod VARCHAR 45 nome do produto
ver_prod VARCHAR 45 versão do produto
desc_prd VARCHAR 45 descrição do produto
desc_prod_anexo BLOB anexo da descrição do produto
req_hard_prod VARCHAR 45 requisitos de hardware
req_soft_prod VARCHAR 45 requisitos de software
docusr_prod VARCHAR 45 documentação do usuário
docusr_prod_anexo BLOB anexo da documentação do usuário
interface_prod INT interface com outros software
soft_inter_prod VARCHAR 45 software de interface
proposito_prod VARCHAR 255 proposito da avaliação
escopo_prod VARCHAR 255 escopo da avaliação
requisito_prod VARCHAR 255 requisito da avaliação
questao
Atributo Tipo Tamanho Descrição
idquestao INT chave primária
idcheck_categoria INT chave estrangeira com a tabela check_categoria
desc_questao VARCHAR 45 descrição da questão
resposta
Atributo Tipo Tamanho Descrição
idresposta INT chave primária
questao_idquestao INT chave estrangeira da tabela questao
avalplan_idavalplan INT chave estrangeira da tabela plano
reposta_avaliador VARCHAR 2 respota do avaliador
resposta_consolidacao VARCHAR 2 resposta da consolidação
anexo_resposta BLOB anexo da resposta
comentario_resposta VARCHAR 255 comentário da resposta
82
APÊNDICE C – TELAS DO SISTEMA
Algumas telas do sistemas foram adcionadas ao apêndice por serrem consideradas menos
relevantes ao texto explicativo das telas.
Figura 32. Gerenciar Coordenador
Figura 33. Cadastro de avaliador
83
Figura 34. Cadastro de fornecedor
Figura 35. Gerenciar check-list
84
Figura 36. Acompanhar avaliação
85
APÊNDICE D – MODELO E LAYOUT DO CHECKLIST DE
AVALIAÇÃO PARA IMPORTAÇÃO
A figura 36 demonstra o modelo e layout de importação do arquivo de texto para a base de
dados da ferramenta de apoio. A primeira coluna representa a numeração sequencial dos
componentes, atributos e questões do checklist. A segunda coluna representa a descrição e a terceira
coluna identifica a chave da escala atribuída a questão, é com esta coluna que serão definidas as
possibilidades de respostas aos avaliadores ao executar a avaliação.
Figura 37. Modelo e layout do checklist de avaliação
86
APÊNDICE E – CHECKLIST DE AVALIAÇÃO DO PRODUTO DE
SOFTWARE OLQR – ONLINE QUICK REPORT
O checklist de avaliação que consta neste apêndice foi utilizado para avaliação do produto de
software OLQR – Online Quick Report.
1 - Interface
1.1 - Aplicabilidade
1.1.1 - A interface orienta o usuário nos passos a serem executados para a realização de uma
determinada tarefa?
( ) Muitos ( ) Poucos ( ) Nenhum
1.2 - Aspectos visuais
1.2.1 - As telas apresentam somente informações necessárias e utilizáveis, sensíveis ao
contexto?
( ) Muitos ( ) Poucos ( ) Nenhum
1.2.2 - As telas apresentam contrastes e cores, facilitando a leitura?
( ) Muitos ( ) Poucos ( ) Nenhum
1.2.3 - As telas exibem as mensagens com bom aspecto visual, utilizando, com moderação,
negrito, itálico e sublinhado?
1.3 - Funcionalidade
1.3.1 - A interface mantém uma padronização propria em relação a configuração de janelas?
( ) Sim ( ) Não
1.3.2 - A interface mantem uma padronização própria em relação a formatação de ícones?
( ) Sim ( ) Não
1.4 - Usabilidade
1.4.1 - A interface apresenta erros gramaticais?
( ) Sim ( ) Não
1.4.2 - A interface apresenta erros ortográficos?
( ) Sim ( ) Não
2 - Software
2.1 - Acurácia
2.1.1 - As funções verificadas no software estão todas implementadas corretamente?
( ) Todos ( ) Alguns ( ) Nenhum
2.1.2 - As funções verificadas no software geram resultados corretos ou conforme o
esperado?
( ) Todos ( ) Alguns ( ) Nenhum
2.2 - Segurança de acesso
2.2.1 - O software impede a utilização de funções não autorizadas?
( ) Sim ( ) Não
2.3 - Ocorrência a falhas
2.3.1 - O software apresentou falhas durante a execução ?
( ) Sim ( ) Não
87
APÊNDICE F – QUESTIONÁRIO DE AVALIAÇÃO DA
FERRAMENTA DE APOIO PARA OS AVALIADORES
QUESTIONÁRIO DE AVALIAÇÃO DE SOFTWARE
data __/__/____
01 Não concordo veemente
02 Não concordo
03 Indiferente
04 Concordo
05 Concordo veemente
1. As funcionalidades do software estão apresentadas de forma clara e de fácil entendimento.
01 02 03 04 05
2. As funcionalidades do software são suficientes e adequadas.
01 02 03 04 05
3. A performance do software é satisfatória.
01 02 03 04 05
4. Os ícones e botões estão dispostos adequadamente na tela, isto é, facilitam a utilização do
software.
01 02 03 04 05
5. Faça um comentário geral sobre o software apresentando critícas e/ou sugestões.
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
88
APÊNDICE G – RELATÓRIO FINAL DE AVALIAÇÃO DO
PRODUTO DE SOFTWARE OLQR
89
90
91
