REQE – Uma Metodologia para Medição da Qualidade de Aplicações Web na Fase de Requisitos

1. 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

2. 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

3. 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 Técnicas de Avaliação de Qualidade Técnicas de Avaliação de Qualidade Certificação Métricas Avaliar a Qualidade do Produto Avaliar a Qualidade do Produto Avaliar a Qualidade do Processo • Objetivo de incrementar a qualidade • Prevenir é melhor do que remediar: quanto mais cedo, melhor! • Projeto WEST (Web-Oriented Software Technology) [WEST01]

4. Requisito 2 Requisito 1 baseia-se Requisito 4 Requisito 3 Requisito 5 Requisito 6 Requisito n SUBJETIVIDADE SUBJETIVIDADE originam-se SERES HUMANOS Meta 2d Meta 3e Meta 5e Meta 1d Meta 7d definem TOMADORES DE DECISÕES Meta 4d Meta 6e Meta 8e Meta n Subjetividade nas Avaliações de Qualidade Processo de avaliação

5. 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]

6. 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?

7. 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

8. 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

9. 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

10. 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

11. 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

12. Fase 1 - Representação das Características, Subcaracterísticas e Atributos de Qualidade

13. Fase 1 - Representação das Características, Subcaracterísticas e Atributos de Qualidade

14. 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

15. Fase 2 - Especificação Descritiva da Árvore de Características, Subcaracterísticas e Atributos de Qualidade

16. Fase 2 - Especificação Descritiva da Árvore de Características, Subcaracterísticas e Atributos de Qualidade

17. 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

18. 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

19. 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:

20. 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:

21. Fase 5 - Cálculo Geral

22. Exemplo de Utilização • Avaliação de qualidade de um site acadêmico • Perfil do interessado: estudante • Vide Documento de Requisitos

23. Exemplo de Utilização

24. Exemplo de Utilização

25. Exemplo de Utilização

26. Exemplo de Utilização Nota final = 4,89

27. 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

28. 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

29. FIM Perguntas ?

30. 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/

31. 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

32. 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

33. 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

34. 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.

35. 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

36. 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 (STARS-VC-A025/001/00). Manassas, VA: Lockheed Martin Tactical Defense Systems, 1996.