REQE – Uma Metodologia para Medição
da Qualidade de Aplicações Web na Fase
de Requisitos
Dissertação de Mestrado
Tiago Pessoa Costa Reis
Orientador: Jaelson Freire Brelaz de Castro
1
Tópicos da apresentação





Motivação
Subjetividade nas Avaliações de Qualidade
Engenharia do Domínio
Documento de Requisitos
Requirements Engineering Quality
Evaluation (REQE)
 Exemplo de utilização
 Conclusões
 Trabalhos Futuros
2
Motivação
 Identificação de problemas com as aplicações Web (custo,
tempo, satisfação do cliente etc)
 Necessidade de investir em qualidade
Métodos e
Ferramentas
de Controle
de Qualidade
Verificação,
Validação e
Testes
Avaliar a
Qualidade
do Processo
Técnicas de
Avaliação de
Qualidade
Certificação
Métricas
Avaliar a
Qualidade
do Produto
 Objetivo de incrementar a qualidade
 Prevenir é melhor do que remediar: quanto mais cedo, melhor!
 Projeto WEST (Web-Oriented Software Technology) [WEST01]
3
Subjetividade nas Avaliações de Qualidade
Processo de
avaliação
baseia-se
Requisito 2
Requisito 1
Requisito 3
Requisito 4
Requisito 5
Requisito 6
Requisito n
SERES
HUMANOS
originam-se
SUBJETIVIDADE
SUBJETIVIDADE
Meta 2d
definem
TOMADORES
DE DECISÕES
Meta 1d
Meta 3e
Meta 5e
Meta 4d
Meta 6e
Meta 7d
Meta 8e
Meta n
4
Subjetividade nas Avaliações de Qualidade
 Ainda com relação à subjetividade das
avaliações de qualidade:
 “O avaliador pode usar sua experiência na
Engenharia de Software para realizar a valoração”
[ISO98]
 “Para medir atributos de qualidade de software
devemos identificar um conjunto apropriado de
métricas” [DUJMOVIC96]
 “O uso de métricas de software não elimina a
necessidade do juízo humano na avaliação de
qualidade” [IEEE92]
5
Subjetividade nas Avaliações de Qualidade
 Qual o ponto de partida? [ISO91] [IEEE92]






Usabilidade
Funcionalidade
Confiabilidade
Eficiência
Portabilidade
Manutenibilidade
 Usabilidade
 É fácil de usar?
 Funcionalidade
 As funções e propriedades satisfazem todas
as necessidades explícitas e implícitas dos usuários?
 Confiabilidade
 É imune a falhas?
6
Subjetividade nas Avaliações de Qualidade
 Eficiência
 É rápido e não desperdiça recursos sob certas condições?
 Portabilidade
 É fácil de usar em outro ambiente?
 Manutenibilidade
 É fácil de modificar e testar?
 Em geral, não são práticas de medições diretas dessas
características
 Estas características devem ser decompostas em
subcaracterísticas e atributos de qualidade
 E assim sucessivamente, até atingirmos a objetividade
necessária
7
Engenharia do Domínio
 Surgiu a partir do elevado custo de manutenção de
software (mudanças arbitrárias)
 Engenharia de Software atuando em um meta-nível,
com famílias de aplicações
 Um dos seus objetivos é gerar sistemas baseados em
domínios [LEITE93a]
 Estamos particularmente interessados na Análise do
Domínio
“ Uma tentativa de identificar os objetos, operações e relações entre o que
peritos em um determinado domínio percebem como importante”
[NEIGHBORS81]
 A nossa metodologia recomenda a utilização de
técnicas de Engenharia do Domínio
8
Documento de requisitos
 É a declaração oficial do que é desejado pelo sistema
 Há diversas formas de representar os requisitos, entre
elas:





Linguagem natural
Diagramas, gráficos e tabelas
LAL – Léxico Ampliado da Linguagem [LEITE93b]
ACE – Attempto Controlled English [FUCHS96]
KAOS – Linguagem baseada em objetos, agentes e seus objetivos
[DARDENE93]
 i* (ambientes organizacionais e seus sistemas de informações) [YU97]
 Não exigimos formato especial do documento de
requisitos
 Serve de entrada para a aplicação da metodologia
proposta REQE
9
Requirements Engineering Quality Evaluation
 Baseada na Web-site QEM (Web-Oriented Software
Technology) [OLSINA00b]
 REQE antecipa a avaliação de qualidade [REIS02]
 Possui menos artefatos para basear a avaliação
 Possibilita a construção de um produto de melhor
qualidade
 Possui 5 fases:
 Representação das Características, Subcaracterísticas e
Atributos de Qualidade
 Especificação Descritiva da Árvore de Características,
Subcaracterísticas e Atributos de Qualidade
 Associação de Pesos aos Nós
 Associação de Escores aos Atributos de Qualidade
 Cálculo Geral
10
Fase 1 - Representação das Características,
Subcaracterísticas e Atributos de Qualidade
 Passo 1: Escolha do Domínio da Aplicação e do Perfil
do Interessado
 Passo 2: Especificação da Árvore das Características,
Subcaracterísticas e Atributos de Qualidade (ACSAQ)
 Auxílio da Engenharia do Domínio
 Decomposição top-down de um subconjunto das
características definidas pela norma ISO 9126
 Levar em consideração “modelos de qualidade” ( [ISO91]
[IEEE92] ) e opinião de especialistas
 Vejamos um exemplo
11
Fase 1 - Representação das Características,
Subcaracterísticas e Atributos de Qualidade
12
Fase 1 - Representação das Características,
Subcaracterísticas e Atributos de Qualidade
13
Fase 2 - Especificação Descritiva da Árvore de Características,
Subcaracterísticas e Atributos de Qualidade
 Preencher planilhas de todos os nós da ACSAQ
14
Fase 2 - Especificação Descritiva da Árvore de Características,
Subcaracterísticas e Atributos de Qualidade
15
Fase 2 - Especificação Descritiva da Árvore de Características,
Subcaracterísticas e Atributos de Qualidade
16
Fase 3 - Associação de Pesos aos Nós
 Objetivo: determinar o grau de importância dos nós da ACSAQ
 Distribuir o peso 10 (dez) entre as características
17
Fase 3 - Associação de Pesos aos Nós
 Distribuir o peso 10 (dez) entre as subcaracterísticas e atributos
de qualidade filhos das características
18
Fase 4 - Associação de Escores aos Atributos
 Não são associados escores às características e
subcaracterísticas nesta fase da metodologia
 Associação baseada no Documento de Requisitos
 Propomos a seguinte escala de valores:
Conformidade
Escore
Não atende o atributo de qualidade
0
Atende com sérias restrições
3
Atende parcialmente
6,5
Atende
10
19
Fase 5 - Cálculo Geral
 Objetivo: efetuar o cálculo que consolida todos os
escores de conformidade associados aos atributos e os
pesos associados aos nós
 Ao final teremos a avaliação de qualidade concluída
 A nota de um nó pai será calculada com base na
seguinte fórmula:
 Vejamos um exemplo:
20
Fase 5 - Cálculo Geral
21
Exemplo de Utilização
 Avaliação de qualidade de um site acadêmico
 Perfil do interessado: estudante
 Vide Documento de Requisitos
22
Exemplo de Utilização
23
Exemplo de Utilização
24
Exemplo de Utilização
25
Exemplo de Utilização
Nota final = 4,89
26
Conclusões
 Importância das avaliações de qualidade
 Benefício da utilização do Documento de
Requisitos
 O uso de REQE possibilita:
 Avaliar a qualidade de aplicações Web
 Identificar problemas de uma forma antecipada
 Contribuir com a melhoria da qualidade de
aplicações Web
27
Trabalhos Futuros
 Agregar indicadores de custo aos nós da
ACSAQ
 Especificação de uma ACSAQ mais genérica,
podendo ser aplicada a vários domínios
 Definir preferências ao atribuir pesos [HUI03]
 Desenvolver ferramentas para apoiar a
metodologia
 Propor um template de documento de requisitos
de modo a integrá-lo à ferramenta
28
FIM
Perguntas ?
29
Referências Bibliográficas
[DARDENE93] Dardene, A.; Lamsweerde, A.; Fickas, S. Goal - directed Requirements Acquisition. Science of Computer
Programming, v. 20, p. 3-50, 1993.
[DUJMOVIC96] Dujmovic, J.J., "A Method for Evaluation and Selection of Complex Hardware and Software Systems", The 22nd
Int´l Conference for the Resource Management and Performance Evaluation of Enterprise CS. CMG 96 Proceedings, Vol. 1,
pp.368-378. 1996.
[FUCHS96] Fuchs, N. E.; Schwitter, R. Attempto Controlled English (ACE). In: The First International Workshop on Controlled
Language Applications (CLAW 96), Würzburg, Germany. Proceedings… p. 211-218. 1996.
[IEEE92] IEEE Std 1061, “IEEE Standard for a Software Quality Metrics Methodology”, IEEE Computer Society Press. 1992.
[ISO91] ISO/IEC 9126, International Standard Information technology – Software product evaluation –Quality characteristics and
guidelines for their use. 1991.
[ISO98] ISO/IEC 14598-5: Information technology – Software 1998. product evaluation -- Part 5: Process for evaluators.
[LEITE93a] Leite, J.C.S.P.; Prado, A. F; Sant'anna M., “Draco-Puc: A Case Study on Software Re-engineering.” Position papers of
the 2nd International Workshop on Software Reusability, SWT Memo Nr. 69, Universitat Dortmund, ISSN 093-7725, Pags.
121—124. 1993.
[LEITE93b] Leite J.C.S.P.; Franco, A.P.M. A Strategy for Conceptual Model Acquisition. In: International Symposium on
Requirements Engineering, 1., SanDiego, Ca. Proceedings… IEEE Computer Society Press, p. 243-246. 1993.
[NEIGHBORS81] Neighbors J. Software Construction Using Components. Tese Doutorado) - Universidade da Califórnia, Irvine,
EUA. 1981.
[OLSINA00b] Olsina, L., Metodologia Quantitativa para a Avaliação e Comparação de Qualidade de Sites Web, tese de doutorado
defendida em abril, Facultad de Ciências Exactas, UNLP, La Plata, Argentina. 2000.
[REIS02] Reis, T. P. C.; Castro, J. F. B.; Olsina, L.; Medição da Qualidade de um Projeto Web na Fase de Requisitos, SBES02, XVI
Simpósio Brasileiro de Engenharia de Software, Gramado, outubro de 2002.
[YU97] Yu, E. Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering. Proceedings of the 3th IEEE
International Symposium on Requirements Engineering - RE97, pp.226-235, Jan. 1997.
[WEST01] Web-Oriented Software Technology, disponível em http://www.dsic.upv.es/~west2001/
30
Estado da Arte
 AGORA [KAIYA02] baseada em objetivos e avalia a qualidade
da especificação de requisitos em função de fatores:








Corretude
Não ambiguidade
Completude
Consistência
Verificabilidade
Modificabilidade
Rastreabilidade
Grau de importância e estabilidade
 WebFP_QEM (Web Function Points and Quality Evaluation
Method) [ABRAHÃO02]
 Captura dos objetivos da aplicação por meio de diversos stakeholders
 Leva em consideração requisitos funcionais e não-funcionais
 Propõe reestruturações com base em análises
31
Estado da Arte
 Web-site QEM (Web-Oriented Software Technology)
[OLSINA00b]
 Planificação e Programação da Avaliação de Qualidade
 objetivos estratégicos, táticos e operacionais da avaliação
 Definição e Especificação dos Requisitos de Qualidade
 ente a ser avaliado e suas características
 Definição e Implementação da Avaliação Elementar
 critérios de medição e mapeamento em preferências elementares
 Definição e Implementação da Avaliação Global
 funções de agregação
 Análises dos Resultados, Conclusão e Documentação
 justificativas e comparações entre concorrentes;
 Validação de Métricas
 validar as funções de mapeamento e os domínios de valores
32
Engenharia do Domínio
 As maiores diferenças entre os métodos de
Análise de Domínios são destacadas em três
categorias:
 Produto primário da análise: representar os
resultados da análise e modelagem das atividades
 Foco na análise: fases do método
 Técnicas de representação: representar o
conhecimento de forma que o seu entendimento seja
fácil
33
Engenharia do Domínio
 Feature-oriented Domain Analysis (FODA) [KANG90]
 Baseado em dois conceitos de modelagem:
 Abstração
 Criar produtos genéricos do domínio
 Aplicações do domínio podem ser abstraídas para um nível onde não
existem diferenças
 Refinamento
 Aplicações específicas são desenvolvidas através de refinamentos
desses produtos
 Produto primário da análise: Framework estruturado de modelos
 Foco na Análise:
 Análise do Contexto (escopo, relacionamentos, diagrama de contexto)
 Modelagem do Domínio (semelhanças e diferenças das aplicações)
 Modelagem da Arquitetura (alto nível para reuso)
 Técnicas de representação: integrado com ferramentas que suportam
modelos OO, modelos ER e redes semânticas.
34
Engenharia do Domínio
 Organization Domain Modeling (ODM) [SIMOS96]
 Baseado no programa STARS (abordagem de linhas de
produtos reusáveis)
 Trabalha com Conceitos, Processo, Métodos e Ferramentas
 Objetivo inicial: transformações sistemática de artefatos
 Produto primário da análise: Framework de representação do
conhecimento (arquitetura e base)
 Foco na Análise:
 Planejar o domínio (selecionar, escopo, objetivos)
 Modelar o domínio (grau de variação)
 Base de engenharia (subconjunto das variações,
necessidades específicas)
 Técnicas de representação: diversas ferramentas
35
Referências Bibliográficas - Estado da Arte e Engenharia do Domínio
[ABRAHÃO02] Abrahao S., Olsina L., and Pastor O. Towards the Quality Evaluation of
Functional Aspects of Operative WebApps. 1st International ER Workshop on
Conceptual Modeling Quality (IWCMQ’02), Tempere, Finland, Spring-Verlag.
October 2002
[KANG90] Kang, K., et al. Feature-Oriented Domain Analysis (FODA) Feasibility Study
(CMU/SEI-90-TR-21, ADA 235785). Pittsburgh, PA: Software Engineering Institute,
Carnegie Mellon University, 1990.
[KAIYA02] Kaiya, H.; Horai, H.; Saeki, M.; “AGORA: Attributed Goal-Oriented
Requirements Analysis Method”. 10th IEEE Internacional Requirements Engineering
Conference, University of Essen. 2002.
[OLSINA00b] Olsina, L., Metodologia Quantitativa para a Avaliação e Comparação de
Qualidade de Sites Web, tese de doutorado defendida em abril, Facultad de Ciências
Exactas, UNLP, La Plata, Argentina. 2000.
[SIMOS96] Simos, M., et al. Software Technology for Adaptable Reliable Systems
(STARS) Organization Domain Modeling (ODM) Guidebook Version 2.0 (STARSVC-A025/001/00). Manassas, VA: Lockheed Martin Tactical Defense Systems, 1996.
36