Bachelor Thesis Computer Science and Engineering, 300 credits

Backend Development for Onboarding Xperience

Computer science and engineering, 15 credits

Halmstad 2021-06-11 Oskar Nilsson, Benjamin Lilje HALMSTAD UNIVERSITY

Abstract

The onboarding process is one of the most critical moments to ensure the productiveness of new employees, and companies are constantly striving to make theirs better and more effective. One way to achieve this is to create a more engaging and memorable experience for the employee but without the expense of feedback to the employer.

This thesis aims to create a reliable way for a company to oversee the progress of their new employee and efficiently get them up to speed through developing a back­end system for a new onboarding application. The application shows the employee lists of tasks they can complete, earning experience and leveling up as they complete them. The employer view should give oversight of how far along a new employee is and create new introductory tasks if they so desire.

The thesis managed to build a modular back­end system by utilizing REST architecture and MVC design and technologies such as ORM’s and HTTP to display information to the employer through a web interface and interact with the mobile application.

Keywords

MVC, HTTP, Back­end development, REST­architecture, Database, Onboarding, Middleware, Admin UI

i Sammanfattning

Onboardingprocessen är ett av de mest kritiska ögonblicken för att säkerställa produktiviteten hos nyanställda, och företag strävar ständigt efter att göra deras bättre och mer effektiv. Ett sätt att uppnå detta är att skapa en mer engagerande och minnesvärd upplevelse för den anställde men utan bekostnaden för feedback till arbetsgivaren.

Denna uppsats antar problemet att skapa ett tillförlitligt sätt för ett företag att övervaka utvecklingen över nya medarbetare och effektivt få dem att komma igång. Detta genom att utveckla ett backend­system för en ny onboarding­ applikation. Applikationen visar de anställda flertal listor över uppgifter värda olika poäng som de kan utföra för att intjäna erfarenhetspoäng och uppnå nya nivåer. Arbetsgivarens syn bör ge en överblick över hur långt en ny anställd har kommit och möjligheten till att skapa nya introduktionsuppgifter om de så önskar.

Projektet lyckades bygga ett modulärt backend­system genom att använda REST­arkitektur och MVC­design och tekniker som ORM och HTTP för att visa information till arbetsgivaren via ett webbgränssnitt och interagera med mobilapplikationen.

Nyckelord

MVC, HTTP, Back­end utveckling, REST­arkitektur, Database, Onboarding, Mellanprogramvara, Administration UI

ii Acknowledgments

We want to start this thesis by expressing our sincerest gratitude towards our supervisor Sundas Munir. Without her input and advice on this project on approaching and solving problems, this thesis would not have been possible.

A big thank you to Phoniro for making us feel welcome from the very start. Our stay with the company has been highly fulfilling with everything from valuable insight into the project, to watching ”the great moose migration” together.

Of course, we would also like to give a final thank you to Linus for being so helpful when connecting the Phone application to the developed system. We could not have done this without you.

iii Authors

Oskar Nilsson and Benjamin Lilje Halmstad University

Place for project

Halmstad, Sweden

Examiner

Veronica Gaspes, PhD Halmstad University

Supervisor

Sundas Munir, PhD student Halmstad University Contents

1 Introduction 1 1.1 Background ...... 1 1.2 Problem ...... 1 1.3 Goals & Restrictions ...... 2 1.4 Functional Requirements ...... 2 1.5 Phoniro ...... 3

2 Related Work 5 2.1 ElateMe Backend ...... 5 2.2 Backend Application for Public Complaint Systems ...... 5

3 Theoretical Background 7 3.1 Admin UI ...... 7 3.1.1 Usability Engineering Principles and UCD Theory ...... 7 3.1.2 User analysis ...... 7 3.1.3 Architecture design ...... 8 3.1.4 Graphical Design ...... 8 3.1.5 Evaluation ...... 10 3.2 Database ...... 10 3.2.1 Relational database ...... 10 3.2.2 Database design ...... 11 3.2.3 SQL­Triggers ...... 11 3.3 Middleware ...... 12 3.3.1 HTTP requests ...... 12 3.3.2 REST architecture ...... 14 3.3.3 Model­View­Controller (MVC) ...... 15

4 Method 17 4.1 Development Process ...... 17 4.2 Software Used ...... 18 4.3 Database design ...... 19 4.4 Admin UI Design ...... 21 4.5 Database communication (Model) ...... 23

v 4.6 User Interaction (Controller) ...... 24 4.6.1 Web application ...... 24 4.6.2 Mobile application ...... 26 4.7 User Interface (View) ...... 27 4.8 Security ...... 28 4.9 Result Analysis ...... 28

5 Result 31 5.1 Middleware ...... 31 5.2 Web UI ...... 31 5.2.1 Iteration ...... 31 5.2.2 Functional requirements ...... 31 5.3 Database ...... 32 5.3.1 Relationships ...... 32 5.3.2 Normalization ...... 33

6 Discussion 35 6.1 Development ...... 35 6.2 Comparison to existing solutions ...... 35 6.3 Integrity aspect ...... 36 6.4 Sustainable employment ...... 36 6.5 Future development ...... 36

7 Conclusion 37

References 39

8 Appendix 44

vi 1 Introduction

This bachelor thesis is in cooperation with Phoniro [35] in Halmstad to improve their onboarding process by giving them a tool to monitor new employees and their current progress in their onboarding process. Phoniro started this project to streamline their incorporation process for new employees and avoid overwhelming them with information. Since then, they have begun developing an app to gamify the process and are now looking to expand upon the idea by adding a back­end system. That is what this thesis seeks to create.

1.1 Background

A fair onboarding process engages the new employee in the process and keeps it enjoyable, which the app already solves. A good onboarding also requires supervision or frequent updates to management to know when they should move on to the next step; this is what our backend solution seeks to create. The solution will contain three separate parts, an admin UI, a communication layer, and a relational database. An informative and straightforward UI will show all new employees currently enrolled on the app and their current progress. A well­defined communication layer with clear rules and restrictions will make the solution more secure, flexible, and able to be expanded upon in the future. Lastly, a relational database that contains task and user data. This solution will eliminate unnecessary meetings, make sure that employees enter the working environment more swiftly with no process or safety procedure missed.

1.2 Problem

Currently, there is no way for Phoniro to monitor new employees’ progress in the app except by users showing their employers the app, adding extra complexity to the onboarding process instead of reducing it. Implementing a back­end solution in addition to the application, Phoniro will gain a tool to monitor users’ progress and create a more effective onboarding process.

1 1.3 Goals & Restrictions

This thesis seeks to set up a complete back­end solution (database and web app) to structure, monitor, and manage data from an onboarding mobile app. Requirements and restrictions for the project are presented below.

Figure 1.1: A visual representation of the proposed system

Goals Restrictions Set up a relational database Limited lifelike test possibilities since that contains a minimum amount realistic tests would require a of redundancy and allows insertion, significant amount of both people and removal, and modification of rows and time. tables without inconsistencies. Description of entities and Since this project is performed as their relations in the database should a candidate Thesis, time is limited be well­made to make it so that adding and is, therefore, a restriction of the new tables to the database takes little software’s quality. to no effort. Develop a user­friendly UI that gives The design of the database is going to an overview of users, be limited by GDPR, making the final passwords, hiring dates, deadlines for solution have fewer fields than initially onboarding tasks, and the number of intended. collected points for individual users.

Table 1.1: Goals and Restrictions

1.4 Functional Requirements

Functional requirements specify features or functions that developers must implement into the system to enable users to accomplish their tasks [44]. They

2 describe the behavior the system will show under specific conditions and are a collection of ”shall” statements [47], for example, ”Users shall be able to see all employees registered on the application.” With these requirements set in place, designing the system and later testing will be more straightforward since the purposes of the functions will be clear.

Before the functional requirements, user stories were established; user stories display the features in the system from the user’s perspective and give insight into how developers intend the system to be utilized [13].

As a I want to So that Employer Know all my current new I can monitor and help them employees with their onboarding Employer See the progress of a new I can know when this person is employee ready to start working Employer Introduce a new safety routine Reduce the risk of injuries in for the company the workplace

Table 1.2: User stories for the employer

With the user stories in table 1.2 defined, this resulted in a collection of features that the final solution was required to contain to fulfill the derived stories’ needs. To keep the thesis focused on fulfilling the goals and not derailing, the functional requirements were slotted into categories of importance CORE, should have, and nice to have. The CORE classified features then became our Minimum Viable Product or MVP and are presented in 1.3.

1.5 Phoniro

Phoniro, in cooperation with ASSA ABLOY Global Solutions, works with implementing innovation and IT­solutions into an already existing elderly care system and has since 2004 developed multiple new welfare technologies. Phoniro care [36] is their cohesive platform for their welfare technologies and extensive modules. The platform includes software such as UI and phone apps and hardware, including digital locks, alarms, and cameras. Together they create a compelling and qualitative solution to digitize the elderly care system. With more

3 Functional Requirements F1 Add new employees Employers shall be able to add new employees, set it’s username, password, starting date. The user should start at a default of 0 experience. F2 Remove employees Employers shall be able to target and remove an existing user from the system, leaving no trace of in the database F3 Observe employees Employers shall be able to select an employee to view their progress by selecting a list of tasks and be presented with their state. F4 Add a new list Employers shall be able to add a new list of tasks, that list shall show up for all new and existing users F5 Remove a list Employers shall be able to delete an existing list, removing it from all current employees F6 Add a task Employers shall be able to add a new task to an existing list, updating it for all current employees F7 Remove a task Employers shall be able to remove existing tasks, leaving no trace of them in the database F8 Accept a task Employees shall be able to accept a task in the application F9 Finish a task Employees shall be able to finish a task and be awarded experience for it

Table 1.3: CORE feature of the proposed system innovation on the horizon, Phoniro is now looking to effectively get new employees into the company to help them on their way.

4 2 Related Work

2.1 ElateMe Backend

Kuzmovych Yevhen developed in 2017 a back­end solution for the crowdfunding platform ElateMe [48]. ElateMe is a web application with mobile clients which aims to provide functionalities of creating a crowdfunding project (a Wish), receiving or donating money to an established project, and viewing friends’ wishes. The project establishes functional, non­functional requirements and use cases of the system and develops a suitable database model, server architecture, and API. The solution utilizes REST 3.3.1 to set up a structure for data transfer between the server and its clients. Authentication of users employs OAuth 2.0 and Facebook Graph API to create and validate the system’s users.

2.2 Backend Application for Public Complaint Systems

The same year Hatama, Dedy Puji, and Aris published an article on developing a back­end for a public complaints system with the help of micro­services [41]. The solution once again uses functional requirements to design its system. The system gets implemented with the help of REST and a Model­View­Controller structure, modeling controllers, and their REST methods after their micro­service requirements. Both concepts are further explained in 3.3.1 and 3.3.2.

5 6 3 Theoretical Background

This section will provide the knowledge required for understanding concepts presented during the report. This includes HTTP codes, how they are structured, and how client­server communication can benefit from them. The background theory of the design with user­centered theory covering the architecture, graphical design and evaluation for it.

3.1 Admin UI

3.1.1 Usability Engineering Principles and UCD Theory

“There is no ’cookbook’ approach to applying these principles to ensure good interface design.” Says Deborah J. Mayhew. Though some of the principles are General Design, User Feedback, Conceptual Design, Iterative Conceptual Model Evaluation and Detailed User Interface Design [23].

The purpose of UCD, user­centered design, is putting the users of a product in the middle of the development for the design and application. Every path in the design path is affected by the user, prioritizing their needs and wants. Evaluating if the different contents in the design is satisfying for the users. Giving the user an impact on the product via their requirements and feedback [7, 37].

3.1.2 User analysis

UCD focuses on user requirements rather than the technical ones. Design depends on how well the user interacts during the iterative prototyping development process. Creating and using personas can determine functions and content, increasing and providing the clarity and focus for both the design and software development. Personas are typically created through the contact of real users but might be elaborated with imaginary stories or details of truth and defined from the users needs and goals. Creating user stories will help to brainstorm and prioritize on functions and features. However, it is not always designed for everyone, therefore there is at least one primary persona and in this case it’s the stakeholder Phoniro. With this a Minimum Viable Product (MVP) was defined and explained previously in the Introduction [34].

7 3.1.3 Architecture design

Combining navigation, one of the five basic design elements, with a good user interface and labeling could enhance how the information is provided to the users making it easier to grasp. As for creating links, they should be used through text instead of images. When navigating deep, shortcuts is commonly used with examples of lists of content and drop­down menus [33].

Interactivity, content, and responsiveness are three parts of the basic design element. Regarding content, a thing to keep in mind is the placement of the content. When a path towards an item is used and requires several clicks, the risk for the user to make a mistake along the way increases. Content like a common icon, such as the cogwheel for settings or the plus sign for increment helps the user recognize features for a faster approach [33].

3.1.4 Graphical Design

When designing a UI, there are ten general aspects to have in mind. In summary, it is about keeping it in a logical style with relevant information, granting a feeling of confidence and freedom, being consistent and keeping up to the standards, preventing errors, and help users to recover from it. Adaptive for both new and experienced users, documented help when needed, and visualizing it to be clear and allow the user to recognize rather than remember [31].

1. Help the user anticipate what’s happening next. No consequences should be possible to happen before reporting feedback to the user, letting them know as soon as possible if an error might occur.

2. Using design and language that speaks to the user. The design must be created from a user’s perspective, formed in a natural mapping, making the interface easier to use and remember. Never assume the users understand your concept and choice of words [38].

3. Users need a choice to exit and undo mistakes, granting them trust in themself and the app. It also results in reducing frustration or getting stuck. Just like in real life, there is a physical emergency exit.

4. Reduce the amount of learning for the user to minimize the cognitive load.

8 Just like a computer the human brain can only process so much. By using templates or structure from other sites and/or applications that is popular will decrease the total of learning a user have to experience, minimize the cognitive load,altering the focus towards the application itself. One way is to replace a text with a picture hence it’ll be, easier and faster to read and understand [46].

5. Prevent the errors happening in the first place by presenting a warning to the user when they try to do something they might regret, or an option to confirm their choice. Make suggestions to the user and create a forgiving design. Let the user type information in their way while in the backend rectify it for optimal storage.

6. Minimize the users short term memory load by helping the user to recognize rather than remembering details. Start with good default settings and not always limit the users choice but add constraints. This will help the process of using the web application become more agile.

7. Designing it both for experienced and inexperienced users by adding customization for the content and shortcuts. By accelerating the usage for experienced users it’ll be more efficient and less frustrating when the option to skip steps is given.

8. Prioritize the relevant information in the interface to primarily support the purpose of the application. Do not let unnecessary design choices distract the user from their objective.

9. When the user has made a mistake, help them acknowledge what went wrong and how to recover from it. Use the standard of errors with bold and/or red text, displaying it in clear text and not in code. Visualize it to help the user understand what went wrong and how to fix it.

10. If the user were to be stuck, documented help should be quick and easy to find. Relevant information and in steps if needed.

9 3.1.5 Evaluation

Not even the professionals can create a complete and perfect design on their first try. This requires iteration of the design. At least three iterations may increase the usability significantly. The plan is to create the MVP for Phoniro to test the web application and give feedback for further iterations. One of the benefits from iterations was showcased in Karat’s study 1990 (Karat, cited in Nielsen 1993) [30]

The security application had 22,876 users. Each could be expected to save 4.67 minutes by using version 3 rather than version 1 to perform a set of 12 initial tasks (corresponding to one day’s system use), for a total savings of 1,781 work hours. From this. Karat estimated saved personnel costs of $41,700. which compared very favorably with the increased development costs of $20.700 for iterative design. The true savings were likely to be considerably larger. since the improved interface was also faster after the first day.

The purpose of evaluating the design are to detect and prevent issues for the users before it reaches development [17].

3.2 Database

A database is structured data organized in columns and rows, typically stored in a electronic system. Rows may be referred to a tuple or record and columns may be referred to attributes. The columns stores specific information, such as name, phone number, type of measure or an address etc. while the data in rows specifies what and/or how much it is in that specific tuple [6, 32].

3.2.1 Relational database

Writing structured data into a database implies it is a relational database, compared to the non­relational database that have unstructured or semi­ structured data stored in a non­tabular form [28, 32, 39]. Working with a relational database uses queries to view a specific column, table of columns or alter the data. This requires Structured Query Language (SQL). When there is a relational database something must create the relations. That is the primary and foreign keys. Primary keys helps to set the uniqueness in each tuple, either

10 through the individual record itself or an ID is created. Foreign keys are set to identify and link to another tuple in a different table where the reference are set to a primary key from the other table [39, 45]. Altering the tables and columns is Data Definition Language (DDL) and altering the data within the rows are Data Manipulation Language (DML) [19].

3.2.2 Database design

In general when creating a database, the steps in table 3.1 are a good guide to follow.[40] This gives a clear purpose of the structured data and information that can be properly put into tables. From there normalization is used in the order of 1NF, 2NF to 3NF with the intention to reduce redundancy. Normalization may go further but usually most practical in 3NF form [8, 20].

Step Description 1 Decide the point of the database 2 Retrieve and structure up the information 3 Create tables with the information 4 Transform information into columns 5 State the primary keys 6 Organize the relationship between the tables 7 Polish the design 8 Normalize according to the rules

Table 3.1: Database design steps

3.2.3 SQL­Triggers

By using stored procedures and triggers the data performance will be optimized. A stored procedure is in short terms a saved query. Instead of rewriting the same query again and again this could be used to save time and increase the efficiency. A triggers is similar but automated that occurs on certain events. [15] It can be divide into three categories: DDL, DML and Login in to the SQL server. In DDL it covers for CREATE, ALTER and DROP. For DML it covers INSERT, UPDATE and DELETE. [12, 15]

11 Pros with Triggers

1. The Trigger could be recursive. Triggering another trigger within them self.

2. Code relatively easy, similar to a Stored Procedure

3. Functions and stored procedures can be called from inside the Trigger

4. Triggers can ensure the database system administrator that a row in fact has been update, inserted or deleted.

Cons with Triggers

1. When importing data directly into a SQL server using the Transact SQL Bulk Insert, the triggers are not fired automatically. The trigger must be activated manually using FIRE_TRIGGERS in the Bulk statement.

2. Recursive and nested triggers can be hard to debug

3.3 Middleware

This section will provide input into concepts vital to understanding the development of the middleware. When developing a back­end solution, it is essential to design an API that gives the end­user the freedom to interact with the system in the way it wants but minimizes the system’s risk of unintended manipulation. Utilization of HTTP requests, REST Architectural constraints, and an MVC pattern, we seek to solve these issues.

3.3.1 HTTP requests

HTTP is a protocol designed to enable communication between clients and servers through requests and responses. A request­line consists of four entities, a method, a uniform resource identifier(URI), none or multiple headers, and an optional message body. The method indicates what the client is requesting and consists of a collection of concrete functions [2] where the most common are listed below. The URI informs the servers upon which element to navigate to or change [1]. Headers are optional but are used to provide the server with additional information regarding the request. The message body provides the server with data to utilize

12 if the method requires it, as in this thesis when adding a new task or employee to the database.

Method Description GET Retrieves information from the given URI. POST Transmits data to the server. PUT Comparable to POST but instead replaces the current representation at the target URI with the uploaded content. DELETE Removes all the current representation at the defined URI.

Table 3.2: The most common HTTP request methods supported in HTTP/1.1

As data travels over the web, web servers read out the data from the network connection and parse out the information from the requested message [18] and is depicted in 3.1. The server first looks at the request line looking for a request method, the specific resource it targets (URI), and the version number, each separated by a single space. The line ends with a CRLF sequence—followed by the message headers specifying, for example, the content type and length. In the end, the server read the request body specified by the content type and content length from the headers.

Figure 3.1: Representation of message parsing done by server

To a request, there is always a response code that consists of a three­digit integer code. Giving feedback to the client about its sent request and informs if it was

13 successful or an error occurred along the way [3]. The first digit of the code defines the class of the response and represents one of five classes informational (1xx), successful (2xx), redirection (3xx), client error (4xx), and server error (5xx). There is an extensive list of status codes [4]; below in the table are the ones regarding this thesis and its planned development.

Code Reason­Phrase Description

200 OK Indicates that the request has succeeded

201 Created Indicates that the request has been successful and that one or more new recourse have been created

400 Bad Request Indicates a rejection of processing the request due to something perceived as a client error

401 Unauthorized The client must authenticate itself before reaching this part of the controller.

404 Not found Signals an error where the origin server did not find a current representation for the target resource.

Table 3.3: HTTP response codes as per definition of HTTP/1.1

3.3.2 REST architecture

REST stands for representational state transfer and is an architectural pattern defined by Roy Fielding in an attempt to modernize legacy systems [16]. When applied correctly, it promises to eliminate any relation between the client and the server. To create a RESTful system, it needs to adhere to the six constraints shown in table 3.4.

A RESTful system has multiple advantages; it has no dependency on a specific platform or programming language, making it easy to understand. It does not store the state of clients on the server, decoupling the entities. It is also accessible to any type of client, both mobile, desktop, and web.

14 Constraint Purpose Client­Server Improves portability of the system across multiple platforms by separating UI and data storage concerns Stateless Improves scalability of the system by making sure every request is handled independently Cache Aimed at improving efficiency of the system by reducing amount of repeated requests Uniform Interface Central feature of REST aimed at decoupling the system by defining how communication is handled Layered System Increase maintainability of the system by separating primary components into ”layers” Code­On­Demand Aimed at improving functionality of the system by (optional) allowing clients to download applets/scrips from the server

Table 3.4: Name and purpose of REST constraints

Works such as ”Design of REST API for Local Public Transportation Information Services in Malang City” [22] Agi Putra Kharisma and Aryo Pinandito show how REST utilization can provide a good overview of the system before implementation. Even if the systems end­users differ from this one, the work provides insight into the design process.

3.3.3 Model­View­Controller (MVC)

When developing any form of software, an important thing to consider is to have a good design for the planned software. Utilizing architectural patterns will improve the code’s lifespan and make it easier for other developers to maintain and minimizes the risk of unwanted behavior. Architectural patterns seek to solve these issues by conveying an abstract framework for a family of systems. It provides a vocabulary of components, connections, and constraints that set a style for shaping an application [26].

The Model View Controller architecture achieves this by dividing the problem into three separate entities. The model represents the persistent part of the application, is responsible for encapsulating the information and storing and fetching it in the database [9]. Since the model’s only responsibility is to manage

15 the application’s business logic, it should know nothing about the client trying to access the data. It is important to note that while both the view and controller depend on the model, the model never depends on either.

Views handle the output and display data from the model to the user through almost any string, number, or image. While views focus on displaying information, it also provides the user a way to interact with the data by initiating actions such as a click of a button or keystrokes. The view converts those events into actions and passes them on to the controller for execution.

Controllers manage the input and implement the application’s actions [11]. Actions are initiated by view objects through user events and sent to the controller. The controller then checks the format of the data and updates the model with the new values or entities.

In addition to defining what parts of the system are responsible for, MVC also describes how these parts should communicate. The only part of the system that should be interacting with the raw data of the database is the model. For a user to access it, they would have to interact with the controller, which would send a request to the model to make changes. After applying the change to the database, the model then sends an update to the view to show the requested change to the user, an overview of the system is shown in 3.2.

Figure 3.2: A visual representation of a Model View Controller application

16 4 Method

This section will present the software used as well as how the design was implemented. It will explain how URI’s are applied to determine if it is talking to an app user or an admin and what response to send back. It will also show the database design, admin UI design iteration and tests to validate the goals set in the introductory part of this thesis.

4.1 Development Process

The usage of Scrum was upon the request of Phoniro, so this section will not explain why it was chosen, but more as to what Scrum has to benefit the thesis.

The methodology of scrum contains the processes from table 4.1:

Type Description Scrum Master The person in the team that coordinates meetings and holds the contact to the stakeholders and/or other Scrum Masters across teams. Scrum meetings Frequency determined by the team and length usually short, 10 to 20 minutes daily. During the meetings it is common that the Scrum Master directs and gives everyone a moment to answer the three most ordinary questions; “what have you done for today?”, “Did you came across any problem?” and “What will be finished until next time?”. Backlogs Different tasks and features with deadlines for the project. Possible to be altered during the development. Sprints Some of the tasks and features from the backlog should be accomplished during the time limit of 2­ 4 weeks. Demos In order to obtain evaluation of on the product demos are hold for the customer to evaluate.s

Table 4.1: Scrum

Blount, Viktorov, Puntikov and Sutherland says that “Scrum is an Agile software development process designed to add energy, focus, clarity, and transparency to

17 project teams developing software systems”. Working with sprints encourages iterations of the work, and for it, the user stories are essential, though not necessarily long nor short, could be detailed and might not [14, 42].

4.2 Software Used

For development, Microsoft Visual Studio was the choice. Visual Studio offers access to the .NET Framework [24] which provides a framework to create cross­ platform server applications. It also provides an extensive library of well­written documentation [25] and access to NuGet packages [27]. A downside to using Visual Studio is its wealth of features, making finding the right solution time­ consuming and challenging, which because of the time constraint, could cause problems. To mitigate this potential problem, before development, a detailed design of the system was conceived. In combination with the goals set out for the thesis already, the design was used to narrow potential solutions and finally settle on the .NET framework.

.NET has many benefits when it comes to application development. As previously mentioned, .NET offers access to NuGet packages. NuGet packages are a collection of code that the solution can implement to reuse without writing them from scratch, saving time on development. When developing an admin UI, security is a big concern; unauthorized users should not access the site without the proper authentication. .NET offers multiple authentication choices either through Windows OS, an external API or as in this thesis with the help of Identity.

There are still problems with .NET; it does not have a built­in object­relational mapper (ORM), making interaction with the database more complicated and would require SQL queries to be written out plainly in the code. Increasing the complexity of the solution, and if not well written, could cause issues with redundant data in the database and faulty values being able to be put in. However, .NET offers access to the EntityFramework, a lightweight ORM designed. While not as powerful as writing plain SQL code, it will suffice for this thesis. It will reduce the amount of time spent on configuring communication between the database and the middleware.

18 Development environment for prototype Development Environment Operating system: Windows 10 - OS version 19041.928 Visual Studio: version 16.9.0 Microsoft .NET 5.0

Database Properties Operating system: Windows 10 pro: (10.0) Microsoft SQL Server Developer (64-bit): version 15.0.2080.9 Memory: 16333MB Processors: 8

4.3 Database design

The design of the database was based on the information given by our stakeholders and the criteria presented earlier in table 1.3. Because of the restrictions mentioned in the introduction, the database design avoids any personal data that can identify someone. When designed, the steps from table 3.1 were followed. Tables were created with primary keys and relations established. In order to reduce redundancy and transitive dependency, the design was normalized from the first into the third normal form. Transitive dependency is a short term to say that the fields, which are not keys, should be acquired from each other. Shown in figure 4.1 the information required is in the first normal form. Here every value is unique. For transition into the second normal form, it is required to be in the

Figure 4.1: 1NF

19 (a) 2NF (b) 3NF

Figure 4.2: Third and second normal form first normal form. Creating connections and establishing tables with relations to a primary key, with only one primary key per table. Dividing it into four tables with each having an ID as a primary key.

Like first to second normal form, transforming to the following normal form requires being in the previous. Though from the second to the third, there was a struggle to avoid many­to­many relationships and transitive dependency with status. Because many players can have many lists and one list can have many players, and the status needs to be checked for every task for individual players to update the status for the list. Since the status table is purely static and will not have any insertions, it was removed and created as a field in AssignedTask. Therefore the two new tables AssignedTask and AssignedList were created to track what players’ task is updated to what status [8].

The ER­Model in table 4.3 was also created to determine the one­to­many, many­ to­one relationships. Just looking at the relationships in an abstract method can be difficult, though it can be simplified with the help of a conceptional model as a middleman. The method of creating a conceptual model in any design environment is a well­built tool nevertheless [10, 43].

20 Figure 4.3: ER­Model

4.4 Admin UI Design

The initial design for the admin user interface was focusing on fulfilling the criteria of the MVP previously presented in table 1.3, to add, remove and inspect employees, and add or remove tasks from the existing employees. As mentioned in section 3.1.5, three iterations increase the usability significantly. The first two are displayed, while the final iteration is described in the results and presented in the appendix.

21 General Home­page Player

English language No view button Possibility for unique task

Independent logo Log out button Divided into columns

Remove users title More comprehensible indication of task status

Smaller and relocated cogwheel

Altered the name of lists to mission

Removed category

Removed title

Table 4.2: Feedback from stakeholders

Figure 4.4: First design of a Player

After the input from Phoniro the design for the inspection of players adjusted towards the kanban style with its own logo, and is shown in figure 4.5.

22 Figure 4.5: Iteration of Player design

4.5 Database communication (Model)

To allow the middleware to communicate with the database, it required a model and a connection string. With these two, the application can, through SQL queries, manipulate the database. The model classes represent the tables and their contents from the database and consist of a collection of get­set functions. To make use of EntityFramework, it also needs a Database context class; the advantages of this were explained previously. The context class is the class that coordinates the EF functionality. The class replaces the need for the controller to call upon the model classes by representing a session with the database wherein the application can query and save instances of entities. The context for the application derives from the DbContext class and contains public DbSets for every table (or model class) in the database. The DBSets define what entities to include in the data model the application can access. Whenever the program initializes the context class, it automatically fetches all public Dbset in the class and calls the method OnModelCreating. The method is overridden to customize the model further and add composite keys and relations between DbSet; this causes the middleware to consider relations between tables when manipulating the data and reducing rouge data risk. With EntityFramework, the controller classes now do not need explicit SQL queries written in them. Instead, they use the ORM feature of EntityFramework to write C# code that the application translates into queries,

23 speeding up development.

Figure 4.6: Change made to OnModelCreate to create composite keys and many­ to­many relations

4.6 User Interaction (Controller)

Whenever a user navigates the web page, wants to create a new user, or completes a task on the phone application, the middleware needs to parse that information and call the suitable methods. Since the application will communicate through the web, incoming traffic will be HTTP requests. The middleware handles this by constructing various controllers, three different to handle incoming traffic from the web page that sends HTTP requests with HTML bodies and one API controller for the phone application to fetch and update the database through JSON data.

4.6.1 Web application

Interaction from an admin includes monitoring employees’ progress, creating new tasks for them to execute, and adding new employees to the onboarding process. As a result, the web interface interacts with three different controllers instead of one: employees, lists, and tasks. Separating the concern of the admin from one controller into three causes the code to be much more maintainable for the future and more straightforward to test since everything relating to employees in the system will be in the EmployeeController.

Whenever the user calls upon one of the methods, the controller uses Eager

24 loading to retrieve the data needed for the method. Eager loading retrieves the entity and all related data in a single join query, even if it ends up not being used, reducing the number of times the server has to access the database. This solution keeps the performance high since the complexity of the data model is not too complex. An alternative if the model would have been more complex would be the explicit loading of entities. Explicit loading results in multiple queries but simplifies them by only loading data when it is needed.

Figure 4.7: Eager loading of a employee entity

Since a web server has a limited amount of threads available, there is always a risk of having none available when there is an incoming request. To negate this potential risk, the controller employs asynchronous code, allowing process waiting for I/O to complete to free up space for new requests. As a result, both the server and clients resources can be used more efficiently and enable more traffic.

To avoid overcomplicated join queries to the database when fetching data, the controllers also uses view models. View models enable the system to shape entities from multiple tables into one single object. Increasing performance by reducing the number of tables the database has to look through and simplifies rendering logic by supplying the views with one rendering object instead of multiple.

25 Figure 4.8: Visual represenation of code execution synchronously and asynchronously

4.6.2 Mobile application

Incoming request from the phone application has a predetermined format. The controller’s responsibility here is to parse the information from the request and map it into the correct model. As a result of this, the controller only has three methods. Two GET methods, one to validate that the user trying to log in exists and one to fetch the information related to the employee. The PUT method allows the application to update the status of tasks as employees complete them.

The incoming request from the application looks different from how the data models storing it in the database do. The controller parses this information through the use of Data Transfer Objects or DTO for short. DTO’s limit the data that can be input and returned by combining a subset of the original models into a new one. Hiding properties from the application stops it from over­posting data and manipulating fields it should not reach. It also reduces the payload size and minimizes the number of changes done to the application since it does not have to introduce a new function to parse the information from the server.

26 (b) DTO model for update task request (a) JSON body from request to update task

Figure 4.9: JSON and DTO model for UpdateTask message

4.7 User Interface (View)

When creating the views for the web application, a static navigation bar on the left was requested. Therefore, the decision was made to write this code into a shared page shown across all the views. This reduces the total amount of code written, keeps a visual consistency across all views, and reduces the page’s load time. The code is shown in figure 4.10.

Figure 4.10: Layout view

The views handle the relationship to the users and their interactions with the web application. In the ASP.NET MVC, the views are HTML templates with a Razor Markup template that assembles a web page for the user. These views are written in cshtml, which supports the C# language, similar to java taught at the school. Here different views are acted upon by different controllers. Such that the views for Home, List, and Task have their controllers.

Some of the benefits of using views are that it reduces the probability of redundancy of user interface components—the layout is used on every page but

27 only written once. In general, the views are grouped by their features, making it easier to work on associated views. Because of the separated views and the organization, it is more straightforward to test a specific interface [5].

Peter Kellner, an independent software consultant who specialized in .NET development from 1985 through 2001, stated in 2018, that ”View Components are easily testable, as they can be written to have no side effects, which means fewer bugs.” [21].

4.8 Security

The application has two primary forms of security to worry about: secure the web interface from being accessible only to the authorized user and if a rouge user would gain access to the REST API URL.

To create a secure web interface, the solution implements an authentication service through a Nuget package called Identity. Identity provides the server with UI login functionality and manages user login information in addition to login tokens. The login information gets stored in a separate ER table in the database not reachable from the one containing the actual application data.

On the other hand, the REST API does not require the same comprehensive security solution since sensitive data cannot be reached through the API. The DTO model specified previously limits the data that a rouge user would be able to access when they gain access to the API. The API still needs a method to validate that a user trying to log in exists. It does this by receiving the username and password from the incoming request, checking the credentials against existing users, and returning either a response of OK(200) or Unauthorized(401).

4.9 Result Analysis

After development, the result analysis will be done through unit tests. To validate that the system’s parts work independently without relying on each other to achieve the functional requirements presented prior in table 1.3. As mentioned earlier in the introduction, one of the restrictions of the thesis was the limitation of life­like tests mentioned in table 1.1. Instead, to validate that the system works,

28 smaller unit tests with a database of 5­10 users will be made. The tests will attempt to provide the correct input, non­existent data, and false data to verify that the functions work as intended and achieve the requirements set at the beginning. Instead of the SQL database used during development, the tests will use the SQLite database provided by Entity Framework. Each test can generate a new database, fill it with data, and have it in a well­known state before each test.

29 30 5 Result

This section will show the result of the implementation based on how well they achieved the goals and functional requirements set for the thesis.

5.1 Middleware

Middleware was set up based on the MVC pattern to handle the incoming messages from the application and web interface. The final product does fulfill all the functional requirements set at the beginning of the thesis. Unit tests were performed to verify that the system works as intended and proves that the system’s parts work independently, their results are presented in the appendix.

5.2 Web UI

Web user interface results are divided into two parts—one covering the last iteration and the other covering the functional requirements and user stories.

5.2.1 Iteration

The last iteration has more accessible views and indications of the current location than earlier ones. The user now also has a more straightforward path to add, edit and delete employees, lists, and tasks. The user has an overview of all current lists depicted in figure 8.9. They can then click buttons to either delete or edit a list or create a new one. For more details on a single task, the employee can press on its name. Here they are presented with the task specifics, at the top what list it belongs to, and a ”back­button” to return. Even though we do not have to deal with the GDPR rules because there is no personal data stored, we shall not allow whomever to access the data and progress of the employees.

5.2.2 Functional requirements

To achieve the desired results from the functional requirements and user stories, we tested the web application accordingly and played a demo to our stakeholders. In figure 8.5, the employer can observe all employees in general. However, the

31 employer can also click on their names for more detailed observation. There is also the option to add, remove or edit an existing employee, covering requirements from F1­F3 and the first and second user story. Creating a new employee in the web application adds the existing lists to it, and their experience to zero, and tasks status defaults as todo.

Further requirements for the functions were to manipulate tasks and lists. Once created, the list or task is applied to all existing employees, with the default starting status as todo. Here the user will be confronted with a confirmation before they delete the task. It works the same for deleting a list or employee. Visual representation will be in the appendix

5.3 Database

Divided into two parts. Relationships covering the results from the relationships created. Normalization reconciliation of the database.

5.3.1 Relationships

In order to establish a relational database model, we had to remove the many­ to­many relationships. As shown previously in the ER­model in figure 4.3, a ”bridge” is created between the employees and lists, as well as employees and tasks, though with an added status field to track the status on each task for an employee. Introducing these two entities, Assigned­Task and Assigned­Mission, instead gives a one­to­many and many­to­one relationship.

The records stored in the composite entities are children to their parents from the employee and Task or List tables. To free up unused data and remove the risk for rouge data, the children are cascade deleted whenever one of their parents are deleted.

An example would be the list that has the ID 1 and contains 3 task with ID’s 3­ 5 within the database, and Oskar that has the ID 14. By comparing the tables before and after delete in figs. 8.12 to 8.14, it is shown that all task with the foreign key List ID of value 1 were deleted, regardless of what employee or status connected to it. Then for Oskar the lists and tasks assigned were cascade deleted,

32 as intended.

5.3.2 Normalization

To ensure that our table is in the third normal form, we can compare it to the goals for each form. Each normal form requires the previous normal form. For the first normal form, only single values in each record and a two­dimensional table, second normal form, all attributes are dependent on the primary key if they are a non­key attribute and for third normal form, no transitive dependencies. If the second normal form did not have any transitive dependencies, it is automatically in the third normal form. Each table has its attributes depending on its primary key, except the composite entities. For composite entities to exist, they must be directly related to their parent [20].

33 34 6 Discussion

This section will discuss and analyze the project’s development and results. It will also discuss the comparison of the prototype to the related works presented earlier and aspects concerning the final project.

6.1 Development

Development mainly went smooth and only made minor changes to the final prototype as the system had clear goals set out and a design pattern in mind. The original design used Razor components in .NET instead of Views to create more dynamic web pages. Due to incompatibility with the MVC design and blurring the line between business logic and UI logic, making the solution more time­ consuming to test, the choice was made to go with the Views implementation instead. This resulted in a less interactive UI but a system that was easier to test and still something that could achieve the goals of the thesis.

The original design used SQL triggers to update records and statuses depending on the application’s incoming data to create a cleaner middleware. Even with the upside of tidier middleware, the reduced modularity of the system was deemed a more significant downside, and instead opted to use an ORM to implement this feature.

The result of the thesis is similar to the design thought out at the beginning. Even if elements on the web UI went through iteration, the base interaction stayed the same. The tests for this thesis to validate the results were written after the developed prototype was done. To improve both prototype and development, the thesis should have adopted a more test­driven project module, with pre­written tests for features would have made them easier to verify and less time would have been used troubleshooting

6.2 Comparison to existing solutions

In chapter two, related work to the project was presented, a back­end solution for a crowdfunding platform and a public complaint system. While this project learned from both projects of setting measurable goals and benefits of utilizing REST

35 architecture, the goals of the three projects are entirely different, and their choice of implementation differs vastly. While the project restricted Kuzmovych Yevhen to Python and Django Framework for his development, this project instead had to interact with a Xamarin application making the more suitable implementation through .NET and C#.

6.3 Integrity aspect

The thesis first intended to use personal identification numbers to keep track of application users to give Phoniro a way to tie the accounts to their employees somehow. Because of the added rules through GDPR, the data would have to abide by how long it could be stored and purge all data related to the identification number, et cetera. Because of the added complexity to the system and its management, it was concluded that an appropriate system to contain the information could not be developed in the designated time frame.

6.4 Sustainable employment

One of the UN’s 17 goals for sustainable development is goal eight [29], decent work and economic growth. This project contributes to the goal through target 8.8, which specifies protecting labor rights and promoting safe and secure working environments for all workers. With the developed prototype, Phoniro can introduce security routines such as fire safety through the application and monitor whether all their employees are familiar with the routines, reducing the risk of both fatal and non­fatal occupational injuries.

6.5 Future development

One possible future improvement to the back­end solution is to give the employers a way to delegate separate tasks and missions to individual employees. An idea for this could be to add another table for particular tasks, including fields as the existing task table, though instead of ListID or a connection to the assigned task table, it connects to the PlayerID directly with its status column.

36 7 Conclusion

Based on the result presented and feedback from Phoniro, the conclusion that the project has provided a functional prototype of the system can be made.

The prototype fulfilled all the functional requirements and could receive data from the phone application, and the admin UI was updated appropriately. The tests also proved that the MVC pattern was a suitable solution because of its advantage of the separation of concerns, making both development and testing stay within their set out timeframes. For the future, the system can now easily be implemented into Phoniros set up infrastructure by changing the connection string the middleware fetches database from the prototype one to an existing one and uploading the system to a virtual machine or docker container.

37 38 References

[1] Fielding et al. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing). Tech. rep. Internet Engineering Task Force. Chap. 2.7. URL: https : / / tools . ietf . org / html / rfc7230 # section - 2 . 7 (visited on 03/08/2020).

[2] Fielding et al. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. Tech. rep. Internet Engineering Task Force. Chap. 4.3. URL: https : / / tools . ietf . org / html / rfc7231 # page - 24 (visited on 03/08/2020).

[3] Fielding et al. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. Tech. rep. Internet Engineering Task Force. Chap. 6.0. URL: https : / / tools . ietf . org / html / rfc7231 # page - 47 (visited on 03/08/2020).

[4] Fielding et al. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. Tech. rep. Internet Engineering Task Force. Chap. 6.1. URL: https : / / tools . ietf . org / html / rfc7231 # page - 48 (visited on 03/08/2020).

[5] Smith et al. Views in ASP.NET Core MVC. URL: https://docs.microsoft. com/en-us/aspnet/core/mvc/views/overview?view=aspnetcore-5.0. Accessed: 2020­05­03.

[6] Stein et al. Databases. URL: https://docs.microsoft.com/en-us/sql/ relational-databases/databases/databases?view=sql-server-ver15. Accessed: 2020­03­09.

[7] Nick Babich. User Centered Design Principles Methods. URL: https:// xd.adobe.com/ideas/principles/human-computer-interaction/user- centered-design/. Accessed: 2020­03­07.

[8] Jonas Björk. Databashantering. 2003. URL: https : / / docplayer . se / 3184773-Databashantering-jonas-bjork-jonas-trinix-se.html.

[9] James Bucanek. Learn Objective­C for Java Developers. 2009. Chap. 20.

39 [10] S. Ceri, P. Fraternali, and M. Matera. “Conceptual modeling of data­ intensive Web applications”. In: IEEE Internet Computing 6.4 (2002), pp. 20–30. DOI: 10.1109/MIC.2002.1020321.

[11] John Deacon. “Model­View­Controller (MVC)”. In: Academia (2009).

[12] Emil Drkusic. Learn SQL: SQL Triggers. URL: https://www.sqlshack. com/learn-sql-sql-triggers//. Accessed: 2020­02­15.

[13] Ulf Eriksson. Usin User Stories to Document Requirments. URL: https: / / reqtest . com / agile - blog / using - user - stories - to - document - requirements/. Accessed: 2020­06­01.

[14] V. T. Faniran, A. Badru, and N. Ajayi. “Adopting Scrum as an Agile approach in distributed software development: A review of literature”. In: 2017 1st International Conference on Next Generation Computing Applications (NextComp). 2017, pp. 36–40. DOI: 10.1109/NEXTCOMP.2017.8016173. Accessed: 2020­03­08.

[15] Daniel Farina. SQL Server Trigger Example. URL: https : / / www . mssqltips . com / sqlservertip / 5909 / sql - server - trigger - example/. Accessed: 2020­02­15.

[16] Roy Thomas Fielding. “Architectural Styles and the Design of Network­ based Software Architectures”. Tech. rep. UNIVERSITY OF CALIFORNIA, IRVINE, 2000. (Visited on 03/09/2020).

[17] D. Fox, J. Sillito, and F. Maurer. “Agile Methods and User­Centered Design: How These Two Methodologies are Being Successfully Integrated in Industry”. In: Agile 2008 Conference. 2008, pp. 63–72. DOI: 10.1109/ Agile.2008.78.

[18] AvDavid Gourley and Brian Totty et al. HTTP The Definitive Guide. 2002. Chap. 5.

[19] Guru99. SQL Commands: DML, DDL, DCL, TCL, DQL with Query Example. URL: https://www.guru99.com/sql-commands-dbms-query. html. Accessed: 2020­03­09.

[20] Jan L. Harrington. Relational database design and implementation. 4th ed. Elsevier Science Technology, 2016.

40 [21] Peter Kellner. Why You Should Use View Components, not Partial Views, in ASP.NET Core. URL: https://www.telerik.com/blogs/why- you- should - use - view - components - not - partial - views - aspnet - core. Accessed: 2020­05­03.

[22] Agi Putra Kharisma and Aryo Pinandito. “Design of REST API for Local Public Transportation Information Services in Malang City”. eng. In: Journal of Information Technology and Computer Science 2.2 (2017). ISSN: 2540­9433.

[23] Deborah J Mayhew. “The usability engineering lifecycle”. In: CHI’99 Extended Abstracts on Human Factors in Computing Systems. 1999, pp. 147–148.

[24] Microsoft. .NET. URL: https://dotnet.microsoft.com/. Accessed: 2021­ 03­25.

[25] Microsoft. .NET Documentation. URL: https://docs.microsoft.com/en- us/dotnet/. Accessed: 2020­04­25.

[26] Microsoft. Chapter 3: Architectural Patterns and Styles. URL: https:// docs.microsoft.com/en-us/previous-versions/msp-n-p/ee658117(v= pandp.10)?redirectedfrom=MSDN. Accessed: 2020­01­28.

[27] Microsoft. NuGet Documentation. URL: https://docs.microsoft.com/ en-us/nuget/. Accessed: 2020­04­25.

[28] MongoDB. What is a Non­Relational Database? URL: https : / / www . mongodb.com/non-relational-database. Accessed: 2020­03­09.

[29] United Nations. THE 17 GOALS. URL: https : / / sdgs . un . org / goals. Accessed: 2021­05­10.

[30] J. Nielsen. “Iterative user­interface design”. In: Computer 26.11 (1993), pp. 32–41. DOI: 10.1109/2.241424.

[31] Jacob Nielsen. 10 Usability Heuristics for User Interface Design. URL: https : / / www . nngroup . com / articles / ten - usability - heuristics/. Accessed: 2020­01­25.

[32] Oracle. Databases defined. URL: https://www.oracle.com/database/ what-is-database/. Accessed: 2020­03­09.

41 [33] J. Palmer. “Designing for Web site usability”. In: Computer 35.7 (2002), pp. 102–103. DOI: 10.1109/MC.2002.1016906.

[34] Pei Yan and Jiao Guo. “The research of Web usability design”. In: 2010 The 2nd International Conference on Computer and Automation Engineering (ICCAE). Vol. 4. 2010, pp. 480–483. DOI: 10.1109/ICCAE.2010.5451619.

[35] Phoniro. Phoniro. URL: https://www.phoniro.com/. Accessed: 2020­01­ 20.

[36] Phoniro. Phoniro Care. URL: https://www.phoniro.com/sv/phoniro- care/. Accessed: 2020­03­03.

[37] Andy Pratt and Jason Nunes. Interactive design: An introduction to the theory and application of user­centered design. Rockport Pub, 2012, p. 12.

[38] Katie Sherwin. Natural Mappings and Stimulus­Response Compatibility in User Interface Design. URL: https://www.nngroup.com/articles/ natural-mappings/. Accessed: 2020­01­26.

[39] Östelid J Skarman M. Relationsdatabas eller NoSQL? URL: http://www. diva-portal.org/smash/get/diva2:937849/FULLTEXT02.pdf. Accessed: 2020­03­09.

[40] Microsoft Support. Database design basics. URL: https : / / support . microsoft.com/en- us/office/database- design- basics- eb2159cf- 1e30-401a-8084-bd4f9c9ca1f5. Accessed: 2020­03­09.

[41] Hatma Suryotrisongko, Dedy Puji Jayanto, and Aris Tjahyanto. “Design and Development of Backend Application for Public Complaint Systems Using Microservice Spring Boot”. In: Procedia Computer Science 124 (2017). 4th Information Systems International Conference 2017, ISICO 2017, 6­8 November 2017, Bali, Indonesia, pp. 736–743. ISSN: 1877­0509. DOI: https://doi.org/10.1016/j.procs.2017.12.212. URL: https: //www.sciencedirect.com/science/article/pii/S1877050917329800.

[42] J. Sutherland et al. “Distributed Scrum: Agile Project Management with Outsourced Development Teams”. In: 2007 40th Annual Hawaii International Conference on System Sciences (HICSS’07). 2007, 274a– 274a. DOI: 10.1109/HICSS.2007.180. Accessed: 2020­03­08.

42 [43] Bernhard Thalheim. Conceptual modeling foundations: The notion of a model in conceptual modeling. 2018.

[44] “The System Engineering Process”. eng. In: System Engineering Management. Hoboken, NJ, USA: John Wiley Sons, Inc, 2016, pp. 53– 124. ISBN: 111904782X.

[45] W3schools. SQL FOREIGN KEY Constraint. URL: https : / / www . w3schools.com/sql/sql_foreignkey.asp. Accessed: 2020­03­09.

[46] Kathryn Whitenton. Minimize Cognitive Load to Maximize Usability. URL: https://www.nngroup.com/articles/minimize-cognitive-load/. Accessed: 2020­01­26.

[47] Karl Wiegers and Joy Beatty. Software Requirements. 2013.

[48] Kuzmovych Yevhen. “ElateMe ­ Backend”. Bachelor’s Thesis. CZECH TECHNICAL UNIVERSITY IN PRAGUE FACULTY OF INFORMATION TECHNOLOGY, 2017.

43 8 Appendix

Figure 8.1: List of tests performed and their result

Figure 8.2: List of tests performed on the controller responsible for list management and their results

44 Figure 8.3: Tests performed on the task controller and their results

Figure 8.4: List of tests made on the REST API to validate it’s functionality

Figure 8.5: Home page

45 Figure 8.6: One of the players

Figure 8.7: Create list

Figure 8.8: Create task

46 Figure 8.9: The page with all current available missions for the players

Figure 8.10: Example of a mission with its details

Figure 8.11: Example of a delete confirmation

47 (a) List Table (b) Task table

(c) AssignedMission Table (d) AssignedTask Table

(e) Player Table

Figure 8.12: Before deleting Enjoy Breakfast

48 (a) List Table (b) Task Table

(c) AssignedMission Table

(d) AssignedTask Table

Figure 8.13: After deleting mission Enjoy Breakfast

49 (a) AssignedMission Table (b) AssignedTask Table

(c) Player Table

Figure 8.14: After deleting Player Oskar

50 Benjamin Lilje

Oskar Nilsson

PO Box 823, SE-301 18 Halmstad Phone: +35 46 16 71 00 E-mail: [email protected] www.hh.se