Degree project Maintenance of the Quality Monitor Web-Application Author: Maksym Ponomarenko Supervisor: Rüdiger Lincke Date: 2013-09-11 Course Code: 4DV00E, 15 credits Level: Master Department of Computer Science Abstract Applied Research in System Analysis (ARiSA) is a company specialized in the development of the customer-specific quality models and applied research work. In order to improve the quality of the projects and to reduce maintenance costs, ARiSA developed Quality Monitor (QM) – a web application for quality analysis. QM application has been originally developed as a basic program to enable customers to evaluate the quality of the sources. Therefore, the business logic of the application was simplified and certain limitations were imposed on it, which in its turn leads to a number of issues related to user experience, performance and architecture design. These aspects are important for both application as a product, and for its future promotion. Moreover, this is important for customers, as end users. Main application issues, which were added to the maintenance list are: manual data upload, insufficient server resources to handle long-running and resource consuming operations, no background processing and status reporting, simplistic presentation of analysis results and known usability issues, weak integration between analysis back-ends and front- end. In order to address known issues and to make improvements of the existing limitations, a maintenance phase of QM application is initiated. First of all, it is intended to stabilize current version and improve user experience. It also needed for refactoring and implementation of more efficient data uploads processing in the background. In addition, extended functionality of QM would fulfill customer needs and transform application from the project into a product. Extended functionality includes: automated data upload from different build processes, new data visualizations, and improvement of the current functionality according to customer comments. Maintenance phase of QM application has been successfully completed and master thesis goals are met. Current version is more stable and more responsive from user experience perspective. Data processing is more efficient, and now it is implemented as background analysis with automatic data import. User interface has been updated with visualizations for client-side interaction and progress reporting. The solution has been evaluated and tested in close cooperation with QM application customers. This thesis describes requirements analysis, technology stack with choice rationale and implementation to show maintenance results. Key-words: software quality, metrics, maintenance, analysis, visualization, Quality Monitor, ARiSA, optimization, architecture, data-driven documents. i Abbreviations and Definitions ARiSA – Applied Research in System Analysis, an IT consulting company [1]; QM – Quality Monitor web application; CPU – a Central Processing Unit, hardware in a computer that executes processing instructions; RAM – Random-Access Memory, type of memory in computers; XML – Extensible Markup Language, text markup language for representing data in a human- and computer-readable format [2]; GML – Geography Markup Language, an XML-based format for storing geographic information [3]; PNG – Portable Network Graphics, a raster graphics format for storing data in portable, lossless representation with definite compression level [4]; SVG – Scalable Vector Graphics, an XML-based vector image format for graphics with interaction and animation elements [5]; BIRT – Business Intelligence and Reporting Tools [6]; DOM – Document Object Model, a platform- and language-independent document model based on objects and their interaction [7]; D3 – Data-Driven Documents, a JavaScript library for documents manipulation based on data [8]; HTML – HyperText Markup Language, the markup language to create web-browser pages [9]; CSS – Cascading Style Sheets [10]; W3C – The World Wide Web Consortium [11]; JSON – JavaScript Object Notation, a text-based data representation format [12]; CSV – Comma-Separated Values, a plain-text format for storing data [13]; NFR – Non-Function Requirement; I18N (i18n) – Internationalization; L10N (l10n) – Localization; N/A – Not Applicable; SSH – Secure Shell; UML – Unified Modeling Language; UC – Use Case; ii Contents 1 INTRODUCTION ........................................................................................................................................... 1 1.1 PROBLEM AND MOTIVATION ................................................................................................................ 1 1.2 GOALS AND CRITERIA .......................................................................................................................... 1 1.3 THESIS OUTLINE .................................................................................................................................. 2 2 BACKGROUND .............................................................................................................................................. 3 2.1 SOFTWARE QUALITY ........................................................................................................................... 3 2.2 QUALITY MONITOR APPLICATION ........................................................................................................ 3 3 FEATURES AND REQUIREMENTS ANALYSIS ...................................................................................... 5 3.1 USERS .................................................................................................................................................. 5 3.2 FUNCTIONAL REQUIREMENTS .............................................................................................................. 5 3.3 NON-FUNCTIONAL REQUIREMENTS ...................................................................................................... 6 4 TECHNOLOGY RATIONALE ..................................................................................................................... 9 4.1 WEB TOOLKIT...................................................................................................................................... 9 4.1.1 Choice Rationale ........................................................................................................................... 9 4.1.2 Google Web Toolkit ..................................................................................................................... 10 4.2 WEB SERVER ..................................................................................................................................... 10 4.2.1 Choice Rationale ......................................................................................................................... 10 4.2.2 Apache Tomcat ............................................................................................................................ 11 4.3 DATABASE SERVER ............................................................................................................................ 11 4.3.1 Choice Rationale ......................................................................................................................... 11 4.3.2 MySQL Overview ......................................................................................................................... 12 4.4 DATA VISUALIZATION TOOLKIT ........................................................................................................ 12 4.4.1 Choice Rationale ......................................................................................................................... 12 4.4.2 Data-Driven Documents .............................................................................................................. 13 4.5 TECHNOLOGY CHOICE SUMMARY ...................................................................................................... 14 5 ARCHITECTURE DESIGN ......................................................................................................................... 15 5.1 ARCHITECTURE STRATEGY ................................................................................................................ 15 5.1.1 Modularity .............................................................................................................................. 15 5.1.2 Localization ............................................................................................................................ 15 5.1.3 Errors Handling ...................................................................................................................... 15 5.1.3.1 Critical Errors .................................................................................................................... 15 5.1.3.2 Operational Errors.............................................................................................................. 15 5.2 ARCHITECTURE VIEWS ...................................................................................................................... 16 5.2.1 Logical View ................................................................................................................................ 16 5.2.1.1 Quality Monitor – Daemon ................................................................................................ 17 5.2.1.2 Quality Monitor – Web .....................................................................................................