A business intelligence application for interactive budget processes

Full text

(1)LiU-ITN-TEK-A--12/006--SE. A Business Intelligence application for interactive budget processes Albin Carnstam Tobias Ohlsson 2012-01-27. Department of Science and Technology Linköping University SE-601 74 Norrköping , Sw eden. Institutionen för teknik och naturvetenskap Linköpings universitet 601 74 Norrköping.

(2) LiU-ITN-TEK-A--12/006--SE. A Business Intelligence application for interactive budget processes Examensarbete utfört i datateknik vid Tekniska högskolan vid Linköpings universitet. Albin Carnstam Tobias Ohlsson Handledare Pierangelo DellAcqua Examinator Camilla Forsell Norrköping 2012-01-27.

(3) Upphovsrätt Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/ Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/. © Albin Carnstam, Tobias Ohlsson.

(4) Abstract Today budgeting occurs in all types of organizations, from authorities and municipalities, to private companies and non-profit associations. Depending on whether the organization is large or small it can look very different. In large organizations the budget can be such a comprehensive document that it is difficult to keep track of it. Furthermore, in large organizations, the budget work starts very early. Thus, an effective budget process could reduce resources, time and ultimately costs. This master’s thesis report describes a budget application built with the Business Intelligence software QlikView. With the application a budgeter can load desired budget data and through a QlikView Extension Object edit the loaded data and finally follow up the work of different budgets. The Extension Object has been implemented using JavaScript and HTML to create a GUI. The edited data is sent to a back-end interface built with one web server and one database server. To evaluate the usability of the Extension Object’s GUI and determine how the budget application works and to get feedback on the Extension Object and its functionality, a user study was performed. The result of the user study shows that the application simplifies budget processes and has great potential to help budgeters and controllers to increase their effectiveness.. i.

(5) Acknowledgements We would like to thank our examiner, Dr. Camilla Forsell and supervisor, Ass. Prof. Pierangelo Dell’Acqua at Linköping University. Also thanks to our supervisor, Per-Olov Johnsson, and the employees at the department of Business Intelligence at Exsitec for all support and help with troubleshooting during this project. Many thanks to the employees at the Swedish National Heritage Board and TeamOlmed for all help with the application. Finally we would like to thank all employees at Exsitec for a wonderful atmosphere and fellowship. We will miss you. Albin Carnstam & Tobias Ohlsson Norrköping 2012-02-05. ii.

(6) Contents 1 Introduction 1.1 Background 1.2 Purpose . . 1.3 Aim . . . . 1.4 Limitations 1.5 Outline . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 1 1 2 2 2 2. 2 Business Intelligence 2.1 QlikView . . . . . . . . . . . 2.2 QlikView Extension Objects 2.3 Updating fields in QlikView 2.4 Summary . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 3 3 5 5 6. budget process The controller . . . . . . . . . . . . Different budget methods . . . . . Iterative and combination methods Summary . . . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 7 7 7 9 9. 3 The 3.1 3.2 3.3 3.4. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 4 Designing an application 4.1 Capturing the requirements 4.1.1 Context analysis . . 4.1.2 Interviews . . . . . . 4.1.3 Questionnaires . . . 4.1.4 Focus groups . . . . 4.2 Scrum . . . . . . . . . . . . 4.3 Usability . . . . . . . . . . . 4.4 Summary . . . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. 10 10 10 11 11 11 11 13 15. 5 Implementation 5.1 Requirement specification 5.2 Scrum . . . . . . . . . . . 5.3 Technical implementation 5.3.1 Architecture . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 16 16 16 18 18. . . . .. iii.

(7) CONTENTS. 5.4. 5.3.2 Communication steps . . . . . . . . . . . . . . . . . . . . 5.3.3 Extension Object . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. iv 19 20 22. 6 Results 23 6.1 Budget application workflow . . . . . . . . . . . . . . . . . . . . . 23 6.2 Performance measurements . . . . . . . . . . . . . . . . . . . . . 32 7 User study 35 7.1 Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 7.2 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8 Conclusions and discussion 38 8.1 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 8.1.1 Create budgets without previous budget data . . . . . . . 39 8.1.2 Complementary budget support features . . . . . . . . . . 39.

(8) List of Figures 2.1. QlikView architecture. . . . . . . . . . . . . . . . . . . . . . . . .. 4. 3.1 3.2. Decomposition method. . . . . . . . . . . . . . . . . . . . . . . . Composition method. . . . . . . . . . . . . . . . . . . . . . . . .. 8 8. 4.1 4.2. Example of a taskboard and burndown chart adapted from [15]. . Learning curves for novice and expert users. . . . . . . . . . . . .. 13 14. 5.1 5.2 5.3. A burndown chart from one of the sprints in the project. . . . . . Budget application architecture. . . . . . . . . . . . . . . . . . . Simplified node-tree. . . . . . . . . . . . . . . . . . . . . . . . . .. 17 18 20. 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9. The process of creating a budget in the budget application. . . . The “1: Load budget” tab. . . . . . . . . . . . . . . . . . . . . . The “2: Create budget” tab. . . . . . . . . . . . . . . . . . . . . . The “3: Edit budget” tab with the Extension Object (1). . . . . The budget application header. . . . . . . . . . . . . . . . . . . . The “4: Status budget” tab. . . . . . . . . . . . . . . . . . . . . . Average time to load different number of data rows. . . . . . . . Rows loaded per second with increasing number of data rows. . . Average time to perform different methods in different web browsers.. 24 25 27 29 30 31 33 33 34. v.

(9) List of Tables 6.1 6.2. Measurements of time to load data rows in different web browsers. 32 Measurements of time to perform different methods in different web browsers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34. 7.1. Results from tasks regarding the usability attributes learnability and errors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Result from questionnaire regarding the satisfaction attribute. . .. 7.2. vi. 36 37.

(10) Language conventions, names and abbreviations Below we outline the language conventions, names and abbreviations used in the report. Language conventions and names are highlighted in italics while abbreviations are written within (parenthesis).. Language conventions and names Application. ASP.NET Budgeter Interface JavaScript Object. Customized QlikView documents designed to help the user to perform specific tasks by consolidating and visualizing relevant data from multiple sources Web application framework A person working with and drawing up a budget A communication layer by which users interact with a machine or machines interact with each other Prototype-based scripting language QlikView components such as charts and tables used in applications e.g. to search and visualize the data. vii.

(11) LIST OF TABLES. Abbreviations AJAX API ASP BI CSS ERP GUI HTML MS SQL OLE OCX QVD RAM RAÄ SQL VB XML. Asynchronous JavaScript and XML Application Programming Interface Active Server Pages Business Intelligence Cascading Style Sheet Enterprise Resource Planning Graphical User Interface HyperText Markup Language Microsoft SQL Server Object Linking and Embedding OLE Custom Control QlikView Data (file format) Random Access Memory The Swedish National Heritage Board (Riksantikvarieämbetet) Structured Query Language Visual Basic eXtensible Markup Language. viii.

(12) Chapter 1. Introduction This report describes a master’s thesis project carried out at Exsitec AB (hereafter referenced as Exsitec) and the Department of Science and Technology, Linköping University. The aim of the project is to develop a QlikView application, with an Extension Object that enables a budgeter to edit budget data easily without having to use any third-part tool. This chapter presents the background, purpose, aim, limitations and outline of the thesis.. 1.1. Background. Exsitec is a consulting firm focusing on helping companies and organizations to manage important areas where their own Enterprise Resource Planning (ERP) systems are not providing sufficient support [1]. One of their main areas of operations is Business Intelligence (BI) where they develop customized BI applications using the BI software QlikView. The BI applications retrieve data from one or more data sources, such as ERP systems, spreadsheets and text files, loads it into QlikView and present the data in charts, tables and other graphical objects [2]. The customers can then use the applications to collect, search, visualize and analyze the data. One BI application Exsitec provides is a budget application. The application enables the budgeters to load and create budget material in QlikView. Since the current version of QlikView (version 10) only allows limited functionalities for editing data within QlikView, the data was then exported to Excel-files for editing. The Excel-edited files could then be imported back into QlikView for analysis of the new budget. However, Exsitec has discovered a need among their customers, to further improve their budget processes, in providing the ability in the application to also enter data directly into the budget through an object. The object should provide functionality such as commenting and validating the entered budget values and its graphical user interface (GUI) should have good usability. From version 10 of QlikView there is the ability to develop custom objects, called Extension Objects, which are created using JavaScript 1.

(13) CHAPTER 1. INTRODUCTION. 2. and HyperText Markup Language (HTML). This makes it possible to implement the aforementioned requirements of the object.. 1.2. Purpose. The purpose of this master’s thesis project is to enable editing of retrieved data and inserting new data directly within QlikView.. 1.3. Aim. This master’s thesis project’s aim is to develop a QlikView application with an Extension Object that enables a budgeter to edit budget data easily without having to use any third-part tool.. 1.4. Limitations. Since QlikView has a set structure of the Extension Object with eXtensible Markup Language (XML) and JavaScript as mandatory elements, no research on which web technologies/other languages that would have been more optimal to use has been made. Because most of Exsitec’s customers use Microsoft Internet Explorer (hereafter referenced as Internet Explorer) as their main web browser and the popularity of Mozilla Firefox (hereafter referenced as Firefox), holding 38.1% of the browser market as of November 2011 [3], we have primarily investigated how to design our application for Internet Explorer and Firefox. As of consequence of this choice, other web browsers such as Google Chrome and Opera therefore display our Extension Object slightly different with some loss of functionality.. 1.5. Outline. The following three (2-4) chapters are mainly theoretical, describing literature studies focusing on BI, budget processes and how to design an application. After the background theory, chapters 5-6 describe the implementation and result of the application. The report is concluded with two chapters (7-8) about the user study, conclusions, discussion and future work..

(14) Chapter 2. Business Intelligence One of the most important assets of any organization is the information it holds and uses on a daily basis [4]. The digital challenge is to show that information into a single integrated view [5]. Business Intelligence (BI) aims to improve decision making by sieving through large amounts of data, extracting information and turning that information into actionable knowledge [5]. BI applications often uses data gathered from a Data Warehouse. A Data Warehouse is a database system designed to support decision making by presenting an integrated view of data that is copied from different operational data sources. BI applications are used for different business purposes such as analytics, measurement and reporting. The important thing is simplicity and that the data is intuitive and obvious, not merely to the developers but to the business users. Simplicity allows the business users to easily understand and efficiently navigate through the databases [4].. 2.1. QlikView. QlikView, developed by QlikTech, is a BI software for consolidating and visualizing data from multiple sources. Since the beginning of its development in 1993 the software has evolved into a more complete software for BI. The power of QlikView is that it is fast and easy to navigate through large sets of data, enabling the user to quickly understand and get insight of what is important [2]. The software is used both for developing applications and for using them. With security settings, the administrator can decide the authorization level for each user, for example disabling adding new objects to the application.. 3.

(15) CHAPTER 2. BUSINESS INTELLIGENCE. 4. QlikView applications can be used through: • a Desktop client that runs locally on the user’s computer • an Internet Explorer plug-in • an Asynchronous JavaScript and XML (AJAX) client used through a web browser • a web browser-based mobile client (optimized for iPad) • QlikView Object Linking and Embedding (OLE) custom control (OCX), a plug-in for the .NET framework that enables QlikView applications and objects to be loaded and run in external applications, e.g. in C# or Visual Basic (VB) • QlikView Workbench, a plug-in for Microsoft Visual Studio that enables integration of QlikView objects and web technology such as ASP.NET. Figure 2.1: QlikView architecture. The architecture of QlikView is shown in Figure 2.1. Through a script, written by the developer of the application, QlikView retrieves data from one or more data sources, such as ERP systems, spreadsheets and text files, and loads it into the random access memory (RAM) of the computer. This enables very fast access of the data. According to measurements made by Dr. Adam Jacobs, accessing data on RAM can be more than 100,000 times faster than accessing it from a hard disk drive with random access [6]. Since the data is only requested through queries once, when running the initial script, QlikView is very fast. The data is presented through different objects such as charts, tables and graphs, which are placed onto sheets inside the application. Multiple sheets can belong to the same application and are available through tabs..

(16) CHAPTER 2. BUSINESS INTELLIGENCE. 2.2. 5. QlikView Extension Objects. In QlikView version 10, released in October 2010, a new feature called QlikView Extension Objects was introduced. With Extension Objects, developers can create custom objects such as tables or visualizations that can be used in QlikView as any other QlikView objects. However, this feature is only available for the AJAX client or when using the web view mode in the desktop client. The Extension Objects are written with AJAX web technologies in different languages such as JavaScript, HTML, XML and Cascading Style Sheet (CSS) with possibilities to include files in Adobe Flash, Microsoft Silverlight and Java. When creating an Extension Object at least two files must be created and placed inside a folder specified by QlikView: • Definition.xml – XML-file that defines the structure of the Extension Object and the data dimensions and expressions to be loaded • Script.js – JavaScript-file that contains all content and provides the connection between QlikView and the Extension Object Optional files can also be added to the folder: • Icon.png – An icon representing the Extension Object, 32x32 pixels in size. • Properties.qvpp – HTML-structured file defining a custom properties menu for the Extension Object. If not present, a default properties menu will be used • Other content, such as files containing CSS, Adobe Flash, Microsoft Silverlight and JavaScript can also be added and referenced to from Script.js It is up to the developer to decide upon what the Extension Object should do. Basic QlikView behavior and functionality, like associative selections, can be used through the JavaScript Application Programming Interface (API).. 2.3. Updating fields in QlikView. In QlikView there is an option when loading data to make the fields of a column into input fields. When creating a List Box or Table Box object in QlikView the user can then edit the fields and the change will stay in effect during the session. The drawback is that the changed value can’t be saved back into the data source and it will disappear when reloading the application or the data. Another option is to make a VB.NET application with a QlikView OCX component that has the Dynamic Update functionality from QlikView. This solution is more complex than using input fields, since it requires the developer to create a Structured Query Language (SQL) database and use a scheduled SQL Server Agent Job to call the VB.NET application. With the OCX component the application can connect to a QlikView file and with Dynamic Update enable write-back to the loaded data using simple SQL commands. The VB.NET.

(17) CHAPTER 2. BUSINESS INTELLIGENCE. 6. application reads the SQL database and sends the updated fields to the QlikView application. The only way to change the data fields from the QlikView application itself is to make an Extension Object that can act as an interface to the SQL database. The benefits are that the application does not have to be reloaded to get the new data and that the changes are actually saved. The drawback is that the SQL database needs to be used as a data source in the application.. 2.4. Summary. With the BI software QlikView the main idea is to access data and visualize it in an intuitive and easy way to help identify and understand the most important aspects of the business. With version 10 of QlikView a feature called QlikView Extension Object was introduced which can be used to create custom objects, e.g. visualizing data in ways different from the default objects of the software. It can also be used to enable ways to edit retrieved data and insert new data directly within QlikView which makes it possible to use it as a way to analyze budgets and also to create new ones..

(18) Chapter 3. The budget process A budget is a program of action for a company, expressed in economic terms [7]. It can look very different depending on whether the organization is large or small. In large organizations the budget can be such a comprehensive document that it is difficult to keep track of it.. 3.1. The controller. Designing a budget system is as much a question of giving structure to a process as determining the formal content of the budget. The structure must allow budgeters to concentrate on the content rather than on procedures [7]. Many companies have therefore established a position called controller, or in large companies, even a separate budget unit. Their task is not necessarily to create the budget, but rather to coordinate the budget process by preparing and distributing the conditions and instructions for how the process is to be performed. The instructions provide information about which sub-budgets to create and who is responsible for each sub-budget. The conditions shall clarify which events should be considered in the budget process, and how the business during the year should focus. The controller also provides assistance to the budgeters and the management during the budget process.. 3.2. Different budget methods. Budgeting has different purposes, but mainly there are three main objectives for budgeting: 1. Decision making 2. Planing and coordination 3. Motivation. 7.

(19) CHAPTER 3. THE BUDGET PROCESS. 8. Depending on the company’s main objective, there are different suitable budget methods. Anthony [8] says on page 391: “A budget process is either ‘top-down’ or ‘bottom-up’.”. Top-down refers to the first and second objectives where the management takes a very active role. Bottom-up refers to the motivation and planning and coordination objectives where the actual work is performed by the budgeters rather than the management. Decomposition method is a top-down process where the management takes a very active role and determines the goals and establishes a budget for the entire company, see Figure 3.1. The controller then breaks down the budget into sub-budgets which are sent to each budgeter. Their task is to critically review the proposal, complete with details and suggest possible changes. The controller compiles the revised sub-budgets into a total budget that the management determines after possible revisions. Management Budgetediting Proposal Compilation. Budget proposal. Controller Break down Changed subbudget proposal Budgeter. Review. Figure 3.1: Decomposition method. The decomposition method places heavy demands on the management. They must gain an understanding of the employees’ working conditions to be able to submit realistic budgets. If not, the method can lead to a situation where the budgeters of the lower levels of the company feel helpless or ill-treated. Greve [9] and Anthony [8] discuss the importance of letting the budgeter both be involved in the budget process and have influence on the budget’s content to also be motivated to make an effort to cope with the budget. This suggests a bottom-up process such as the composition method, see Figure 3.2. Management General assumptions. Budget proposal Compilation. Controller Instructions. Sub-budget proposal. Budgeter Budgetediting. Figure 3.2: Composition method..

(20) CHAPTER 3. THE BUDGET PROCESS. 9. Even in this method the management takes the initiative, but only through general assumptions for the budget. The controller complements with more specific instructions, but the actual work is performed by the budgeters. When each budgeter has compiled a sub-budget proposal, a compilation of the total budget for the entire company is made. This proposal is then presented to the management that determines the budget after possible revisions. In many cases there is a risk with the composition method of putting a lot of effort on the details which do not "fit" in the final budget. Also, one cannot expect that the draft will fulfill the management’s requirements in all aspects. The method therefore suffers a certain lack of precision. On the other hand, it increases motivation because the budget is something that the budgeters themselves made and therefore feel a commitment to.. 3.3. Iterative and combination methods. To ensure a higher precision of the budget than by the methods, composition and decomposition, the budget can be reworked in several iterations during the budget process. However, the iterative method implies significantly more work and therefore a combination approach using both composition and decomposition can be used. First, one work with designing the various objectives and frameworks for the budgeting according to the top-down process. Next, the budget changes to a bottom-up process similar to the composition method. This allows management to keep the budget under control, reach a high precision of the budget and spare the employees from the comprehensive revisions that the iterative method entails. If one gets the combination method to work well, it is generally very effective. However, this presupposes that the management engage themselves in the budgeting to an extent which have not previously been usual, according to Bergstrand and Olve [7].. 3.4. Summary. Budgeting should not be performed in the same way in every organization, but rather it should be adapted to the particular circumstances of an organization. Bergstrand and Olve [7] says on page 8: “Budget maturity is often a matter of finding one’s own models, the solutions that fit their own company. When you have found such, well thought-out budgeting model that is truly useful for the company, budgeting becomes an effective element in the control system and the employees become thus also generally positive to budgeting.” Thus, using a customized BI application throughout the budget process will simplify processes and increase effectiveness, thereby reduce resources, time and ultimately costs..

(21) Chapter 4. Designing an application This chapter describes different methods for capturing requirements, an agile development methodology to use for implementation of the requirements and attributes to define and measure the usability of implemented requirements.. 4.1. Capturing the requirements. A requirement is an expression of desired behavior and the goal with capturing requirements is to understand the customer’s tasks, problems, working environment and needs. Thus capturing requirements focus on the customer and the problem, not on the solution or the implementation [10]. Capturing requirements involves much more than merely writing down what the customer wants, e.g. finding requirements that everyone understand and can agree upon. There are therefore many different methods, some described below, for capturing requirements. The methods are suitable for different situations depending on factors such as time, scope and economics.. 4.1.1. Context analysis. Since the usability of a product is not only affected by the features of the product itself, but also by user characteristics and the physical environment in which the product is used, awareness of contextual factors is important throughout the development process [11]. Context analysis is a method to analyze the entire environment in which a business operates, from its internal environment, such as knowledge and technology, to its external environment, such as competitors and trends. One of the most well-known context analysis methods is called SWOT [12]. It analyses the business and allows it to gain an insight into their strengths and weaknesses as well as their opportunities and threats posed by the market within which they operate.. 10.

(22) CHAPTER 4. DESIGNING AN APPLICATION. 4.1.2. 11. Interviews. An interview is a conversation between two or more people with the goal of obtaining information from the interviewee by asking questions. Interviews can be used for both quantitative and qualitative research. One quantitative research method often used is structured interviews with a limited and predefined set of questions and a standardized order in which the questions are asked. This method is important for minimizing the impact of context effects and ensuring that the answers can be reliably aggregated. When used in a qualitative research, interviews have several names, e.g. indepth and semi-structured, and generally most of what is said emerges through collaborative interaction between the interviewer and respondent [13]. In contrast to structured interviews, a semi-structured interview is flexible, allowing new questions to be brought up during the interview as a result of what the interviewee says. The interviewer in a semi-structured interview generally has a framework of themes to be explored rather than predefined questions.. 4.1.3. Questionnaires. If a project is limited by scope or economics, a questionnaire is a good alternative to interviews. A questionnaire is a research instrument consisting of a series of questions and/or statements with the purpose of gathering information from respondents similar to structured interviews. The respondents are often asked to indicate their degree of agreement on a scale, generating quantitative data that can be aggregated and analyzed. However, designing a good questionnaire is difficult and respondents could easily misunderstand or not manage to complete all questions. Questionnaires are therefore suitable in conjunction with interviews for validation.. 4.1.4. Focus groups. Focus groups is a qualitative research method similar to interviews. However, instead of interviewing people individually, questions are asked in a group of usually 5-10 participants and all participants are free to answer and discuss the questions with each other. The benefits towards interviews are that it highlight conflicts and can create consensus on important questions. The drawback is that due to group settings important individual opinions can be neglected or never mentioned.. 4.2. Scrum. Scrum is an agile development methodology. The word Scrum originally comes from rugby and refers to the approach of restarting the game. In Scrum development, coordination is done at brief daily status meeting called a “scrum” [10]. The overall goal of agile development is according to Agile Alliance “to satisfy the customer through early and continuous delivery of valuable software.” [14]..

(23) CHAPTER 4. DESIGNING AN APPLICATION. 12. Scrum therefore manages changeable requirements more efficiently than regular development. Three different kinds of roles are involved in the Scrum process: 1. One or several product owner(s) who represents the stakeholders and prioritize the requirements. 2. A Scrum team, usually 5-9 members, who analyse, design, implement and test the actual requirements. 3. A Scrum master who maintain the processes and supports the team. Before a Scrum project begins, the requirements are concretized into one or several stories. A story is a task or a function and each story contains three variables; scope, importance and time estimation, that are highly dependent on each other [15]. The scope and importance are set by the product owner and then sorted based on highest priority in a product backlog. The time estimate is set by the Scrum team. During the project, new requirements, stories and priorities can be added to the product backlog by the product owner. A Scrum project consists of a number of iterations called sprints having a constant length, often between two and four weeks. Every sprint begins with a sprint planning meeting where the tasks for the sprint are identified from the product backlog and a sprint goal is established by the product owner, the Scrum master and the Scrum team. To visualize how the work is progressing during the sprint, a taskboard and burndown chart are often used. The aim of the burndown chart is to “burn” all tasks before the end of the sprint. If not all tasks are “burned” by then, it could depend on too many tasks planned into the sprint or that the planned tasks took more time than planned. It could also depend on external factors such as unplanned tasks, disturbance from colleagues and people being sick. An example of taskboard and burndown chart is shown in Figure 4.1..

(24) CHAPTER 4. DESIGNING AN APPLICATION. 13. Figure 4.1: Example of a taskboard and burndown chart adapted from [15]. Each sprint ends with a sprint review meeting or demo where the product owner gets to test the software made so far. Doing regular demos has a profound effect and several benefits such as attracting vital feedback from the stakeholders and to force the team to actually finish stuff and release it [15]. Finally a sprint retrospective meeting is held within the Scrum team to improve the process by discussing the last sprint, what was good, what could have been better and what they would like to do differently in the following sprint.. 4.3. Usability. According to the International Organization for Standardization, ISO, 9241 standard usability is the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use [16]. According to Shneiderman and Plaisant [17] the ISO 9241 standard focuses on admirable goals while their usability attributes lead more directly to practical evaluation. Together with Nielsen [18] they define usability by the following five attributes: • Learnability – The system should be easy to learn so that users rapidly can start working, i.e. how long does it take for users to accomplish basic tasks the first time? • Efficiency – The system should be efficient to use, i.e. once users have learned the system, how quickly can they perform tasks? • Memorability – The system should be easy to remember, i.e. when users return to the system after some period of not having used it, how easily can they remember how to use it?.

(25) CHAPTER 4. DESIGNING AN APPLICATION. 14. • Errors – The system should have a low error rate, i.e. how many errors do users make, how severe are these errors, and how easily can they recover from the errors? • Satisfaction – The system should be pleasant to use, so that users are subjectively satisfied when using it, i.e. how much do users like using the system? Learnability refers to the novice user’s experience on the initial part of the learning curve in Figure 4.2 while the efficiency attribute refers to the expert user’s steady-state level of performance at the time when the learning curve flattens out [18]. The third major category of users, refereeing to memorability, are casual users. Casual use is typically seen for programs that are only used under exceptional circumstances or at long intervals, such as utility and budget programs. The most common way to measure learnability, efficiency and memorability is to state certain tasks that the users have to complete for each proficiency level (i.e. attribute) and then measure the time needed to perform these tasks. While measuring these attributes, the error rates can easily be measured as well by counting the number of actions made by the users while performing some specified task, which does not accomplish the desired goal.. Usage Proficiency and Efficiency. Focus on expert user. Focus on novice user. Time. Figure 4.2: Learning curves for novice and expert users. To measure the somewhat subjective satisfaction attribute Nielsen [18] suggests simply asking multiple users for their opinion and then averaged together the replies, thereby giving an objective measure of the system’s pleasantness. To ensure consistent measurements, the questions can be asked through a short questionnaire given to the users after a user test..

(26) CHAPTER 4. DESIGNING AN APPLICATION. 4.4. 15. Summary. Capturing requirements involves much more than merely writing down what the customer wants and there are therefore many different methods such as interviews and focus groups, suitable for different situations. Using the agile development methodology Scrum, requirements are concretized into stories and sorted based on highest priority in a product backlog. During the project, consisting of a number of iterations of constant length, called sprints, new stories and priorities can be added to the product backlog. To measure the usability of the implemented requirements, Shneiderman and Plaisant together with Nielsen have defined five attributes: learnability, efficiency, memorability, errors and satisfaction..

(27) Chapter 5. Implementation This chapter presents the implementation of the budget application with the Extension Object. First presenting how requirements was collected, then development methodology and finally presenting a more technical view of how the application and Extension Object was implemented.. 5.1. Requirement specification. The majority of the information about requirements have been collected from qualitative, semi-structured interviews with the employees of one of Exsitec’s customers, the Swedish National Heritage Board (RAÄ). Some follow-up and additions were made through telephone and email contact. The participants have all worked with economy daily as controllers but for different departments and with slightly different responsibilities. They may therefore be assumed to represent a good cross-section of our target user population [19]. Since the information from the RAÄ can be presumed to be subjective and Exsitec wanted a general budget application and Extension Object, interviews with employees of another customer, TeamOlmed, were conducted at a later stage to assure the information. The goal of the budget application is to enable budgeters, within QlikView and without having to use any third-part tool, to create different budgets by loading optional data, editing the loaded data and performing calculations such as periodize costs quarterly. The Extension Object should provide functionality such as commenting and validation of the entered budget values and its GUI should have good usability.. 5.2. Scrum. A clear understanding of the customer and their problems doesn’t guarantee that a useful system will be designed and delivered [20]. One reason is that customers usually have problems to tell the important aspects of their own work practise 16.

(28) CHAPTER 5. IMPLEMENTATION. 17. because they are implicit and unrecognized. Therefore, the development and part of the requirement gathering occurred incrementally according to the agile development methodology Scrum. Since the team only consisted of two people, compared to the usual five to nine, the role of Scrum master became the responsibility of both. Before the development started, the product owner, i.e. RAÄ, prioritized the requirements which were then concretized into stories and gathered together with time estimations of each story made by the team, in the product backlog. The project progressed via five two-week long sprints and at the end of each sprint a demo review was held where the product owner had to test the software made so far, give feedback and discuss and plan the upcoming sprint. During a sprint each day started with a “daily scrum” meeting where each team member described how the last day work went, what he was going to work with next and if he had had any problems. To visualize how the work proceeded, a digital taskboard and burndown chart was used. An example of the burndown chart from one sprint in the project is shown in Figure 5.1.. Figure 5.1: A burndown chart from one of the sprints in the project. As Figure 5.1 shows, throughout the project, not all tasks were finished. From the sprint retrospective meetings we concluded that the cause was due to a combination of inexperience using QlikView and external factors such as problems with the RAÄ retrieved data..

(29) CHAPTER 5. IMPLEMENTATION. 5.3. 18. Technical implementation. Before developing the budget application and the Extension Object an extended architecture, derived from the original QlikView architecture, was designed for handling the communication. Based on this architecture and the requirement specification, the budget application and Extension Object took form.. 5.3.1. Architecture. The default QlikView architecture in Figure 2.1 was used as a starting point for the overall architecture of the budget application. The budget application architecture is displayed in Figure 5.2. The Extension Object is added to the application but the communication between the Extension Object and the application is mostly one way. It is possible to load the data from the application into the Extension Object but not possible to send it back. However, variables defined in the application can be exchanged between the Extension Object and application. An expanded route through a back-end interface is used to pass the edited data back into the budget application and QlikView. A web server receives the data from the Extension Object, handles it and directs it to a database server. From the database the edited data can be reloaded into the application. Separating the original data source from the edited data is necessary to achieve multiple budget versions and to hold extended information such as status and comments. It is also good to keep it separate to not risk overwriting the original data.. Figure 5.2: Budget application architecture..

(30) CHAPTER 5. IMPLEMENTATION. 5.3.2. 19. Communication steps. The data flow, when using the budget application, can be broken down into five steps as seen in Figure 5.2. The steps describe the path starting from the original data source to how and where the changed data values are saved and loaded back into the budget application. Step 1 - Loading data into QlikView The original source data for the budget application are retrieved from RAÄ’s economics system, Agresso, but is processed by Exsitec and transformed into QlikView Data (QVD) files. The QVD-files are then loaded into the application with the fields needed through the loading script. The loading script is a compilation of statements similar to SQL that loads selected data from the different data sources. There is also the possibility to rename fields so that fields from different sources can be linked together. Step 2 - Loading the data into the Extension Object If the data exists in the budget application the data is available in the Extension Object as well. Using the JavaScript API provided by QlikView the requested data, as dimensions and expressions specified in Definitions.xml, are loaded from the application into the Extension Object. Step 3 - Changing values in the Extension Object and sending them to the web server When a value in the data has been changed inside the Extension Object, hidden HTML-input elements are created for the changed field, the key field and the other editable fields in that row of data. A table with these fields also exists in the MS SQL database. If the value in the data is changed again the input element is updated, instead of a duplicate being created. When the user clicks the save button in the application the new values are sent to the web server via the HTTP-POST request method. Step 4 - Preparing data to be sent to the database Using ASP.NET/C# on the web server side, the data is stored into the MS SQL database on the SQL Server. In case of duplicates in incoming and existing data, the corresponding row in the database is updated instead of inserted as a new row..

(31) CHAPTER 5. IMPLEMENTATION. 20. Step 5 - Reloading data into QlikView When reloading the budget application’s loading script it performs a joinfunction of the original data and the table from the MS SQL database with the new data. The join-function makes sure that if a row exists in both the MS SQL database and in the source data, meaning that a change has been made to that row, those changes are replacing the original values.. 5.3.3. Extension Object. AJAX web technologies and JavaScript API In QlikView, the web view mode and the AJAX client use AJAX web technologies to present the application. All objects are loaded asynchronously, meaning that an object can be used and interacted with as soon as it is loaded. Since the Extension Object is only available in this mode it also uses AJAX. Because of the asynchronous nature, sending variables between the QlikView application and the Extension Object must be performed only when all objects in the application are finished loading. This is to ensure that all variables are available. The content of the Extension Object is presented as a web page in HTML, however the file that handles the connection with QlikView, Script.js, is written in JavaScript. Using JavaScript and HTML Document Object Model (DOM), HTML element nodes are generated to create a tree-like structure of nodes, see Figure 5.3. Document. <html>. <head>. <body>. <form>. .... <table>. <thead>. <tbody>. <tr>. .... <td>. Budget data. <input>. .... .... <tr>. <td>. Budget data. Figure 5.3: Simplified node-tree..

(32) CHAPTER 5. IMPLEMENTATION. 21. A node is in the HTML DOM a valid HTML element with required starting and ending tags and optional attributes and inner text, e.g. a link is represented with <a href=”attribute.html”>Inner text</a>. With the DOM interface, accessing a node makes it possible to add/edit attributes and inner text. More importantly a node can hold another node inside itself, hence building the treelike structure with the document (Extension Object in this case) as the top node. With the JavaScript API provided by QlikView some native QlikView functionality is available as well as access of the loaded data. Interactive table The requested data, defined in the Definition.xml-file, is structured as a table with rows and columns. That default structure is, however, not desirable for the intended visualization of the budget application. In the budget data there are several levels of categories and it is requested that the table will group together sub-levels under their parent levels. For the budget application there are three dimensions in the data that are requested to act as grouping levels; a top-level, a mid-level and a lower-level. When looping through all rows of data a comparison is made on the fields of the dimensions for the current and previous row, from the top-level to the low-level dimension. If they are different they don’t belong to the same group and a new group for that level is created. The lower level is the account level; it is a little bit different from the others. The key field in the data which identifies a single account is a concatenated string that contains the ID for each budget category as well as a part that identifies which period (year and month) it is intended for. This way the key for an account will look identical until it is separated by the period. When looping through all rows of data, a comparison is made on the part until the period of the key field, and if it is identical it belongs to the same account. All accounts have twelve months as its sub-level rows. Interaction When the Extension Object has finished loading, only the top level rows are visible, and all sub-level groups and rows are minimized. Through a click on a row the nearest sub-level appear with its rows. This leads down to the lowest level where the months for each account are shown. The fields that are possible to interact with are only the ones that could be changed and saved into the database, budgeted value, periodization key, status and comment. HTML Form To be able to send changed budget values from the budget application to the back-end interface, a hidden HTML form is created when the Extension Object is initialized. Input elements in the form are dynamically created as changes are made in the data. The values in the input elements are then sent to the web server when the user chooses to save..

(33) CHAPTER 5. IMPLEMENTATION. 5.4. 22. Summary. Working according to the agile development methodology Scrum the application was developed through five, two-week long sprints. Before the implementation, semi-structured interviews with employees from the reference customer RAÄ were conducted. Requirements and suggestions were gathered and then concretized into stories in the product backlog. For each sprint some requirements were redefined and some new were also gathered from the customer. The application was developed based on the architecture that was created in an earlier stage of the project. The communication problem between the Extension Object and QlikView was solved by adding a web server and an SQL server to exchange the edited data..

(34) Chapter 6. Results The purpose of this master’s thesis project was to enable editing of retrieved data and insert new data directly within QlikView. The aim was to develop a QlikView application with an Extension Object as an object that enables a budgeter to edit budget data easily without having to use any third-part tool. The Extension Object has been successfully implemented within the budget application. The workflow in the application guides the user through the steps of budgeting and thereby trying to eliminate wrong usage. To build the Extension Object the tools used were the JavaScript API provided by QlikView to get access to the budget data in the application and JavaScript and HTML DOM to create the structural layout. With the tools, an HTML web page was generated in the Extension Object to present the GUI for the edit enabled object. The back-end consists of a web server in ASP.NET that is used to receive the changed data and an MS SQL Server 2008 to store the changes. By reloading the budget data the changes are loaded back into the application.. 6.1. Budget application workflow. RAÄ’s workflow of creating budgets is a bottom-up process similar to the composition method and can be separated into two distinct parts; drawing up subbudgets and compiling the sub-budgets into a total budget. TeamOlmed also uses a budget process similar to the composition method. Although only two of Exsitec’s customers were interviewed, the results corresponds well with the fact that most Swedish companies uses some kind of composition method [7]. Therefore the budget application was developed with the composition method as reference point. Based on the composition method in Figure 3.2, Figure 6.1 shows a simple schematic of how the budget application workflow is designed.. 23.

(35) CHAPTER 6. RESULTS. 24. Figure 6.1: The process of creating a budget in the budget application. The budgeters, head of units or departments, log in to the application and begin with loading desired budget data by selecting cost center, project etc, from the general data source in the “1: Load budget” tab, see Figure 6.2. Chosen budget data is green, associative selections are white and not associative are gray in the list boxes to the left. The colors are default colors in QlikView. The table in the middle shows the outcome for chosen budget data and when the budgeter is satisfied s/he moves to the next tab, “2: Create budget”..

(36) Figure 6.2: The “1: Load budget” tab.. CHAPTER 6. RESULTS 25.

(37) CHAPTER 6. RESULTS. 26. Figure 6.3 shows the “2: Create budget” tab where the budgeter has the possibility, based on possible instructions from controllers or the management, to make general adjustment of the sub-budget, e.g. a fixed, percental, increase of all incomes. Finally the budgeter moves to the next tab, “3: Edit budget” to start edit the sub-budget..

(38) Figure 6.3: The “2: Create budget” tab.. CHAPTER 6. RESULTS 27.

(39) CHAPTER 6. RESULTS. 28. Figure 6.4 shows the budget application with the Extension Object (1) in the middle, in which a sub-budget has been created based on earlier tabs’ instructions. In the Extension Object the user can edit the budget data, including performing calculations such as periodize costs quarterly, commenting and more. When the sub-budget is complete the budgeter sign off the budget, setting the status to “Finished” and thereby locking the budget from further editing..

(40) Figure 6.4: The “3: Edit budget” tab with the Extension Object (1).. CHAPTER 6. RESULTS 29.

(41) CHAPTER 6. RESULTS. 30. In the header of all tabs the budgeter can get help (1), see his/her access rights (2), view general budget information (3) and current selections (4), see Figure 6.5.. Figure 6.5: The budget application header. Since everyone is working towards the same general data source, QlikView automatically compiles the sub-budgets into the total budget and the controllers can continuously follow up all budgeteers work, see Figure 6.6. If the controller is not satisfied with a sub-budget, or is missing something, s/he can go back to the “edit budget” tab and modify the budget to better suit his or her needs. When the controller is satisfied with the total budget, s/he finalizes it by setting the status to “Determined”, thereby locking the total budget from further editing. After determining the budget, the controller can also export it to a file suitable to be imported into their ERP-system...

(42) Figure 6.6: The “4: Status budget” tab.. CHAPTER 6. RESULTS 31.

(43) CHAPTER 6. RESULTS. 6.2. 32. Performance measurements. In a budget data source there can be a lot of data, reaching rows of millions. For each selection made in QlikView, the data is filtered and the number of data rows to be loaded into the Extension Object decreases. In order to investigate the performance, measurements were conducted with different number of data rows loaded and the time it took to finish loading was observed, see Table 6.1. From Figure 6.7 it is shown that the time to load the same number of rows using Internet Explorer is much higher than when using Firefox and rapidly increasing. Analyzing the chart in Figure 6.8 one can see that the performance drops when the number of rows increases when using Internet Explorer while the performance rises when using Firefox. The measurements was discontinued for 16,000 and 32,000 rows using Internet Explorer because of the unreasonable time it would take. RAÄ is a large organization and the use of Internet Explorer is widespread, but considering these measurements staying with the web browser could be troublesome. In the case of RAÄ, the number of rows for a budgeter to load differs quite heavily from around 500 to as much as 46,000 depending on the size of the department or unit.. Browser Average time (s) Rows Internet Explorer 9 Firefox 9 loaded 3.7 10.3 500. Rows per second Internet Explorer 9 48.6. Firefox 9 133.7. 1,000. 26.6. 7.3. 37.6. 136.6. 2,000. 75.1. 12.7. 26.6. 157.5. 4,000. 260.0. 20.9. 15.4. 191.2. 8,000. 848.7. 41.2. 9.4. 194.1. 16,000. -. 78.3. -. 204.4. 32,000. -. 171.8. -. 186.2. Table 6.1: Measurements of time to load data rows in different web browsers. The server (Microsoft Windows Server 2008) used for performing these measurements had 4 GB of RAM and a 2 GHz dual core processor with two users logged in. Measurements was performed five times for each browser and for each number of data rows to be loaded to get an average time..

(44) CHAPTER 6. RESULTS. 33. Figure 6.7: Average time to load different number of data rows.. Figure 6.8: Rows loaded per second with increasing number of data rows. The main reason for the decreased performance when using Internet Explorer as web browser is its JavaScript Engine’s handling of HTML DOM methods to generate element nodes. The HTML DOM API provides great features such as accessing the nodes, but as shown in Table 6.2, the time it takes to use the methods shows that the DOM methods are computationally heavy for Internet Explorer compared to using the innerHTML methods. Compared to other browsers, with different JavaScript engines, Internet Explorer is generally very slow, as much as 12 times slower. However, the benefits of using the DOM method functionalities, such as accessing nodes, overweighs the usage of only innerHTML, and according to the measurements, see Figure 6.9, a change of.

(45) CHAPTER 6. RESULTS. 34. browser could greatly improve performance of the Extension Object. The most used methods in the budget application are W3C DOM 1, W3C DOM Table Methods and innerHTML 1. The measurements have been performed using a provided benchmark test [21] using different web browsers. Each method creates a table with 50 rows and 50 columns and the time is the average of 50 measurements for each method. The results are shown in Table 6.2.. Browser Method W3C DOM 1 Create all elements as they’re created. W3C DOM 2 Create elements once, then clone. W3C DOM Table Methods. Average time (ms) Internet Explorer 9. Firefox 9. Chrome 16. Opera 11.6. 118. 14. 30. 14. 120. 20. 30. 10. 106. 21. 24. 12. 32. 12. 17. 5. 32. 10. 17. 5. Use W3C DOM table methods. innerHTML 1 Concatenate a string. innerHTML 2 Push strings into array, then join array. Table 6.2: Measurements of time to perform different methods in different web browsers.. Figure 6.9: Average time to perform different methods in different web browsers..

(46) Chapter 7. User study One of the requirements was that the Extension Objects GUI should have good usability. To determine how the budget application works and get feedback on the Extension Object and its functionality, a user study was performed. The user study was not conducted until one of the last weeks of the project and it was therefore not a systematic way of solving usability problems, but only to define them.. 7.1. Procedure. The user study was conducted with five employees at RAÄ. The users have all worked with economy daily but for different departments and with slightly different responsibilities. Three of the users had participated during the requirement elicitation and sprint demo reviews. The objective with a group of users with different competences, experiences and responsibilities was to get feedback from different perspectives. The users lack of experience of using the application corresponds to the novice user from the learning curves in Figure 4.2. Therefore, Shneiderman, Plaisant [17] and Nielsen’s [18] usability attributes, learnability and error were chosen to measure. The learnability attribute was measured by having the users perform certain tasks and measure the time the users needed to complete them, with or without assistance. While measuring the learnability attribute, the attribute errors, i.e. number of actions made by the users, which did not accomplish the desired goal, were measured as well. To begin with, a short demonstration of the application was given. All users were given the same seven tasks, described in Table 7.1 and a guide stood next to the user and answered all possible questions. Everything was documented by another person standing behind the user, timing the tasks and counting the number of errors. When the tasks were completed the study ended with a discussion about the overall experience of using the application, which tasks had been difficult to complete and why, and what improvements could be made. Fi35.

(47) CHAPTER 7. USER STUDY. 36. nally the satisfaction attribute was measured using a short questionnaire where the users had to indicate their degree of agreement on a scale from 1 (strongly disagree) to 5 (strongly agree) for each statement. The statements and results from the questionnaire are described in Table 7.2.. 7.2. Result. Most of the tasks were completed by the users with little or no difficulty and the general opinion afterwards was that the application and Extension Object was understandable after a short introduction. Table 7.1 shows the tasks, the average time corresponding to the usability attribute learnability and the error rate corresponding to the errors attribute.. Task. Average time (s). Average error rate. Select one (of each) commonly used Cost center, Funder and Project.. 29.0. 0.2. Undo the selection of Project and instead choose an Activity.. 12.5. 0.2. Make a general adjustment of all costs by 5%.. 56.3. 2.0. Edit the budget value of an optional account, periodize the amount on the third quarter and type the word “Comment” as a comment.. 59.0. 1.4. Edit the budget value of another optional account, periodize the amount manually and change its status to “Done”.. 38.0. 1.2. Change status to “Done” for all current selections and then remove the status of one optional account.. 45.7. 0.4. Save the budget and move to the “Status budget” tab.. 83.7. 0.8. Table 7.1: Results from tasks regarding the usability attributes learnability and errors. Many users had problems making the general cost adjustment since the QlikView object within the application demanded the user to type in 0,05 and not 5 as the users wanted, to get 5%. Also, many users had problems saving the adjustmentvalue as they wanted to click somewhere else with the mouse cursor instead of pushing the Enter-key, as needed. The decimal problem is an easy fix but unfortunately the saving problem is a setting fixed for that object that can’t be changed. However, as many user said, this was only a problem the first time and once they knew how to do it, it was both easy and natural. Another problem and the task that by far took most time was moving to the “Status budget” tab after saving the budget. All users had problem doing.

(48) CHAPTER 7. USER STUDY. 37. this and no user solved it without assistance. The main reason for this was that when within the “Edit budget” tab, all other tabs disappeared making the user confused. Also the name of the button used to leave the tab was vague and the help insufficient. The suggested solution was to rename the button, improve the help text and always showing all tabs but making them gray, making the user understand that they are disabled. All these things should not be to difficult to fix, although it might need a second evaluation before working smoothly. Another problem was to perceive the visual difference among the budget levels and seeing the status column and understanding it was editable. Also, moving within the Extension Objects editable cells, became a problem since some users wanted to use the arrow button, which we had not implemented, other the tab button, but not the way we had anticipated and implemented. Regarding the satisfaction attribute, where the users had to indicate their degree of agreement on a 1-5 scale for each statement, the result from the questionnaire can be seen in Table 7.2.. Average Median Min Max 1. It was very easy to learn how to use this application.. 4.0. 4. 4. 4. 2. Using this application was a very frustrating experience.. 1.0. 1. 1. 1. 4.0. 4. 4. 4. 4. I worry that many of the things I did with this application may have been wrong.. 2.0. 2. 1. 3. 5. This application can do all the things I think I would need.. 3.2. 3. 2. 5. 6. This application is very pleasant to work with.. 4.2. 4. 4. 5. 3. I feel that this application allows me to achieve very high productivity.. Table 7.2: Result from questionnaire regarding the satisfaction attribute. As can be seen, the average satisfaction rates were quite good. The rates of the statement with the least good average, number 5, varied heavily and probably mostly depends on the different users responsibilities and therefore their needs of extra features that was not yet implemented at the time of the user study..

(49) Chapter 8. Conclusions and discussion A customized BI application can be a helpful and powerful tool. By using it throughout the budget process, not only can budgeters edit their budgets but controllers and management can get an overview of the status all the way from an economic summary of all departments down to an individual budgeter’s work progress on a single cost center. One can easily see the potential to simplify organizations processes and increase their effectiveness in terms of reducing resources, time and ultimately costs. The result of this master’s thesis project is a QlikView application with an Extension Object that enables a budgeter to edit budget data. The Extension Object is a work in progress designed as a proof of concept to demonstrate a number of techniques and their possibilities. It could easily be expanded to include additional or other data dimensions or expressions and it would not be to difficult to develop other features. However in the scope of the project we focused on developing a complete application to edit budget data rather than developing different features. Further development could use the concept of our Extension Object to complete the application using desired extra features. As presented in Chapter 7, the performance of the Extension Object varies depending on the choice of web browser but also on the number of data rows loaded into the Extension Object. When the number of data rows increases and when using Internet Explorer the performance decreases heavily, while the performance actually increases when using Firefox. In either case the loading time will increase if the data source gets larger, which is likely if the application would be used in a larger organisation. Since RAÄ’s budgeters do several selections from the general data source before starting editing the budget, the number of data rows to be loaded decreases to an extent making it more manageable to work with. However, the unreasonable time to load data using Internet Explorer makes it a poor choice according to Table 6.1 and therefore a change of browser could greatly improve performance of the Extension Object. Since the application is suitable for both Internet Explorer and Firefox the primary choice should be the latter which also has become the choice of RAÄ.. 38.

(50) CHAPTER 8. CONCLUSIONS AND DISCUSSION. 39. The application requires a demonstration or an explanation in order to be used to its full potential. Although usability has been an important consideration during the project, there is still room for improvement, especially since most users will only use the application for a short period of time and in between, risk forgetting how to use it. To further evaluate the usability of the application and Extension Object, a second user study should be conducted to examine if the feedback and suggestions from the first user study resulted in an improved application. However, the application and Extension Object is still being developed at the time when this report is written and Exsitec expects to continue develop it in the near future. Considering this and the fact that the users managed to complete most of the user study tasks without difficulty, the level of usability is satisfying.. 8.1. Future work. To make the budget application more suited to the budgeters work, some further work is desirable and there are many possibilities to develop new features and improvements, some of which are suggested below.. 8.1.1. Create budgets without previous budget data. In the developed budget application there is no possibility to create budgets or manage accounts with no previous budget data. This is a problem if you e.g. are to create a budget for a completely new project with no previous outcome or need to add a new account to an existing budget. Therefore, this feature was highly demanded from both Exsitec as well as RAÄ and TeamOlmed. Due to limited time the feature wasn’t implemented in the application, but because of its importance, development has started and the feature will be the first thing Exsitec continues develop after this project’s ending.. 8.1.2. Complementary budget support features. Something that both RAÄ and TeamOlmed desired was complementary budget support features such as prognosis and resource budgeting. Prognosis is a budget tool used by many companies. Based on historical data such as last year outcome, different mathematical models can be used to forecast how the business might perform financially for the remaining budget year. Resource budgeting is used to calculate labour costs such as salaries and employment taxes..

(51) CHAPTER 8. CONCLUSIONS AND DISCUSSION. 40. By modifying the Extension Object, developing features like these would not have been too difficult and would have really helped those companies’ in need of it. Since the developed budget application still forces the users to use third-part tools like Excel for calculating aforementioned features it would have further increased the benefits of the budget application. However, since the aim of the project was to develop a complete application to edit budget data rather than developing different features and complementary budget support, implementing these features was not prioritized during the project..

(52) Bibliography [1] Exsitec AB [online]. url: http://www.exsitec.se [retrieved 201201-05] [2] QlikView [online]. url: 2012-01-05]. http://www.qlikview.com [retrieved. [3] Browser Statistics [online]. http://www.w3schools.com/browsers/browsers_stats.asp [retrieved 2012-01-05]. url:. [4] R. Kimball and M. Ross. The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling. John Wiley & Sons, second edition, 2002. [5] T. Connolly, C. Begg and R. Holowczak. Business Database Systems. Addison Wesley, first edition, 2008. [6] The Pathologies of Big Data [online]. url: http://queue.acm.org/detail.cfm?id=1563874 [retrieved 201201-05] [7] J. Bergstrand and N-G. Olve. Styr bättre med bättre budget. Liber, fourth edition, 1996. [8] R. N. Anthony. Management Control Systems. McGraw-Hill Europe, 12th edition, 2007. [9] J. Greve. Budget. Studentlitteratur, first edition, 1996. [10] S. L. Pfleeger and J. M. Atlee. Software Engineering - Theory and Practice. Pearson Education International, fourth edition, 2009. [11] C. Thomas and N. Bevan. Usability Context Analysis: A Practical Guide. National Physical Laboratory, version 4.04, 1996. [12] T R Jain, Mukesh Trehan, Ranju Trehan. Business Environment. V K Publications, second edition, 2009. 41.

(53) BIBLIOGRAPHY. 42. [13] T. R. Lindlof and B. C. Taylor. Qualitative communication research methods. Sage Publications (CA), second edition, 2002. [14] Agile Alliance [online]. url: http://www.agilealliance.org [retrieved 2012-01-05] [15] H. Kniberg. Scrum and XP from the Trenches. InfoQ, 2007. [16] International Organization for Standarization. ISO 9241 Ergonomic Requirements for Office Work with Visual Display Terminals (VDTs), Part 11: Guidance on Usability. Geneva, 1998. [17] B. Shneiderman, C. Plaisant. Designing the user interface. Addison Wesley, fourth edition, 2005. [18] J. Nielsen. Usability Engineering. Morgan Kaufmann Publishers, first edition, 1993. [19] K. Holtzblatt, J. B. Wendell and S. Wood. Rapid contextual design: A how-to guide to key techniques for user-centered design. Morgan Kaufmann Publishers Inc., first edition, 2004. [20] K. Holtzblatt and H. Beyer. Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann Publishers Inc., first edition, 1997. [21] Benchmark - W3C DOM vs. innerHTML [online]. url: http://www.quirksmode.org/dom/innerhtml.html [retrieved 2012-01-05].

(54)

No results found