Project management
- To-do list and Task Scheduler -
Project Report
cs-23-SW-2-17
Aalborg University
Institut for Datalogi
Copyright © Aalborg University 2022
The text of To-do list and Task Scheduler is written in Overleaf, a free online LaTeX editor.
Institut for Datalogi
Aalborg University
http://www.aau.dk
Title:
Project managemt
Theme:
A Larger Program
Developed by a Group
Project Period:
Spring Semester 2023
Project Group:
cs-23-sw-2-17
Participant(s):
Daniel Rantzau Bech
Tobias Bjerregaard
Jónas Elís Gunnarsson
Andreas Mertz
Simon Melgaard Skelkjær
Hans Jacob Zachariassen
Supervisor(s):
Olivier Pelgrin
Copies: 1
Page Numbers: 101
Date of Completion:
May 25, 2023
Abstract:
This report will investigate how a
project management tool can assist university students in managing group
projects. The aim of the project is to develop a web-based solution that ensures
accountability and time management
for student group projects. MoSCoW
Requirements for the solution were developed through analysis of optimal
team operations, student experiences
with current project management solutions and existing software solutions.
Through the utilisation of these requirements the design and implementation
of the software solution was created.
Hereupon, the solution was presented
to external testers for testing, and feedback was received. Overall the software
solution managed to fulfill the requirements resulting in it being successful.
The content of this report is freely available, but publication (with reference) may only be pursued due to
agreement with the author.
Contents
Preface
1
1
Introduction
3
2
Initialising problem statement
5
3
Problem analysis
3.1 Team collaboration . . . . . . . . . . . . . . . . . . . . .
3.1.1 High performance teams . . . . . . . . . . . . .
3.1.2 Low performance teams . . . . . . . . . . . . . .
3.1.3 Summary of Team collaboration . . . . . . . . .
3.2 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Analysis of interview . . . . . . . . . . . . . . .
3.2.2 Bias . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 Summary of interview . . . . . . . . . . . . . . .
3.3 Analysis of existing project management tools . . . . .
3.3.1 Analysis method . . . . . . . . . . . . . . . . . .
3.3.2 Example of analysis method . . . . . . . . . . .
3.3.3 Functionality matrix . . . . . . . . . . . . . . . .
3.3.4 Summary of existing project management tools
3.4 Conclusion of problem analysis . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
8
8
8
9
10
10
12
12
13
13
14
16
17
17
4
Problem definition
19
5
Requirements
5.1 MoSCoW Prioritisation Model . . . . . . . . . . . . . . . . . . . . . .
5.2 MoSCoW Requirements . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Summary of requirements . . . . . . . . . . . . . . . . . . . . . . . . .
21
22
23
29
6
Design
6.1 Visual presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Website sketches . . . . . . . . . . . . . . . . . . . . . . . . . .
31
31
32
vii
viii
Contents
6.2
6.3
7
Data objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Summary of design . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementation
7.1 Frameworks / Libraries
7.1.1 Server design . .
7.1.2 Routes . . . . . .
7.1.3 Databases . . . .
7.2 Website functionalities .
7.2.1 Kanban Board . .
7.2.2 GANTT . . . . .
7.3 Unit testing . . . . . . .
7.4 Conclusion . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
39
40
43
44
44
47
48
51
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
55
56
58
Discussion
9.1 Fulfillment of requirements . . . . . . . . . . . . . . . . . . . . . . . .
9.1.1 Fulfillment of problem definition . . . . . . . . . . . . . . . . .
9.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
60
63
63
8 Testing
8.1 User stories . . . . . .
8.1.1 External testing
8.1.2 Feedback . . . .
8.1.3 Conclusion . .
9
37
38
.
.
.
.
10 Conclusion
65
11 Future works
67
Bibliography
69
12 Appendix
12.1 Analysis of existing solutions
12.1.1 Jira . . . . . . . . . . .
12.1.2 Todoist . . . . . . . . .
12.2 Interview . . . . . . . . . . . .
12.2.1 Interview Questions .
12.2.2 Elisa Interview . . . .
12.2.3 Jesse Interview . . . .
12.2.4 Rasmus Interview . .
12.3 Other . . . . . . . . . . . . . .
12.4 Testing . . . . . . . . . . . . .
12.4.1 External tester 1 . . . .
71
71
71
79
82
82
83
87
91
94
95
95
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ix
Contents
12.4.2 External tester 2 . . . . . . . . . . . . . . . . . . . . . . . . . . .
12.4.3 External tester 3 . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
99
1
Contents
Preface
This report has been written by 2nd-semester Aalborg University software students.
We would like to thank our supervisor for his guidance throughout the project.
Aalborg University, May 25, 2023
Daniel Rantzau Bech
Tobias Bjerregaard
<VR75RC@student.aau.dk>
<tbjerr22@student.aau.dk>
Jónas Elís Gunnarsson
Andreas Mertz
<jegu22@student.aau.dk>
<SG82DA@student.aau.dk>
Simon Melgaard Skelkjær
Hans Jacob Zachariassen
<XS68MJ@student.aau.dk>
<FS23DG@student.aau.dk>
Chapter 1
Introduction
This report investigates how to assist university students with project management
through a software solution. As managing group projects can be challenging for
students, as they are an essential part of University that enables students to develop
skills such as teamwork, communication, and problem-solving. However, managing
group projects can be challenging for students, especially when it comes to coordinating tasks, keeping track of deadlines, and ensuring that everyone is on the
same page. Project management tools can assist student groups with important
aspects of project management. By helping the students work more effectively while
attempting to counteract counterproductive group traits.
The problem to be addressed is designing and implementing an effective project
management tool to help students during university group projects. The requirements for the proposed software solution will be created by analysing how teams
operate optimally. In addition, by interviewing students and how their experience
with current project management solutions, uncovers which specific functionalities
are expected by students. The base requirements can be created, by analysing the
existing software solutions and combining this information with the aforementioned
information.
The solution to the problem can be found in the form of a website, through Github.
3
Chapter 2
Initialising problem statement
Figure 2.1: HW-Diagram
During the initial writing process of the report, the goal is to figure out the direction
to address the issues concerning project management, using an HW-diagram [10],
as seen in figure 2.1. Leading towards the main focal point:
What essential project management tools are necessary for optimal workflow
during student group projects?
With the additional follow-up questions:
• What project management issues do students encounter during group projects?
• Which project management software applications do students currently utilise
and what tools do they wish existed?
• What existing project management software applications exist and what functionalities do they include?
5
Chapter 3
Problem analysis
This chapter aims to determine the functionalities that students require from project
management software. Through investigating what attributes define high- and lowperformance teams in university students, to discover which areas the discrepancies
between the two forms of teams exist. In addition, students from Aalborg- and
Aarhus University will be interviewed, in order to understand which tools and
methods can assist students and allow them to be a high-performance team. Providing insights into which functionalities students require from project management
software in order to succeed.
Furthermore, Jira, nTask and Todoist existing project management solutions and
their functionalities to assist users will be analysed. Thus, determining which
functionalities are currently available within existing project management tools
and what functionalities they still require, to improve team performance. A problem statement will be created based on these findings, to figure out how to assist
students with project management through a web application.
7
8
3.1
Chapter 3. Problem analysis
Team collaboration
The objective of this section is to analyse the characteristics of high-performance
and low-performance teams in student group projects. Uncovering which strategies
are prevalent in assisting students learning outcomes during group projects. This is
an imperative part of discovery, as without knowing what steps high-performance
teams take to ensure a good outcome. Implementing a project management tool
without considering collaborative efforts may hinder teamwork. Similarly, it is
important to know which common pitfalls low-performance teams fall into, and
to which areas improvements need to occur to raise a team from low- to highperformance.
3.1.1
High performance teams
Interpersonal interactions, including effective communication and clear expectations, play a significant role in high-performance teams. High-performance teams
demonstrate a shared understanding of expectations among all team members and
the overall project [1].
Intra-team project communication skills are paramount for any collaborative effort.
The use of tools for communicative work overlaps with the regulation of work.
Effective communication within the team is crucial for successful collaboration.
High-performing teams rely on a high level of self- and team regulation, which in
turn rely on communication strategies and tools [1].
Co-regulation is also an aspect of team interaction that high-performance teams
utilise. This is in line with the expectations that each member treats another as
a supporting actor, rather than merely a fellow learner. A form of engagement
through the regulation of others. The outcome of this form of communication
strategy is the co-construction of knowledge and is a vital piece of what makes a
team high-performing [1].
3.1.2
Low performance teams
Low-performance teams were found to show less engagement in projects, as well as
not setting sufficient goals for themselves. Teams lacking adequate planning and
coordination were found to make low-quality work and participate less in group
work than the high-functioning teams. Participants being part of a low-performance
team was shown to be associated with reduced learning outcomes [1].
The success of a team is heavily dependent on interpersonal relationships and
collaboration between team members. A recent study by Dinu 2016 [6] found that
3.1. Team collaboration
9
low-performance teams tended to have poorer communication and collaboration in
contrast to high-performance teams. Ineffective communication was shown to lead
to misunderstandings, delays, and conflicts, which can ultimately jeopardize the
project. Communication and collaboration are therefore crucial, in order to achieve
optimal results.
Thus, showcasing software can play an important role when helping teams improve
on pitfall areas like task management and collaboration, which are key factors in
achieving a high-performance team. Implementing software tools can help facilitate
an online work environment while establishing clear communication and goals.
Active engagement and interpersonal relationships are difficult to address with
software. Project management tools can still help improve team dynamics through
the provided work environment, with the use of the correct functionalities, making
teams more productive. Ultimately achieving increased productivity and quality of
work.
3.1.3
Summary of Team collaboration
In summary, high-performance teams have well-defined expectations and requirements for each member, which are effectively enforced and regulated. Communication strategies and tools play a vital role in facilitating clear communication and
providing an overview of the project.
In contrast, Low-performance teams suffer from a lack of planning and coordination, leading to ineffective communication and collaboration. Addressing these
issues requires both improved planning and increased engagement, which are areas
of weakness within low-performance teams.
10
3.2
Chapter 3. Problem analysis
Interviews
The interview questions were partly created, based on the information gathered in
section 3.1 and can be seen in appendix 12.2.1. In addition, to gain insight into which
collaboration and management tools the students use, the interview also seeks to
figure out group dynamics and success factors. Thereby, understanding how and
why students use these tools and methods, alongside which issues they have with
these. Thus, allowing one to understand how students can be high-performing
teams through communication, responsibility and group expectations.
3.2.1
Analysis of interview
The interview is a qualitative method which resulted in a small sample size of three
interviewees consisting of students from Aalborg University and Aarhus University.
All are students who are actively doing group projects in their studies. One of the
participants has finished their bachelor’s degree while the two others are in their
2nd and 6th semester.
Tools Used
A common link between each of the participants is the tools they use for collaborative efforts. Trello is used for its overview of tasks and deadlines. - Google Drive for
its file-sharing capabilities and basic office-work package. - Facebook Messenger,
Microsoft Teams, Zoom, and Discord are all messaging or meeting applications for
group communications. - And Overleaf is used for its highly customisable word
processing layout.
None of the tools used by the interviewees is used in singularity, as they all
serve different functions depending on the individual project needs and are often
used in collaboration. These tools are not without their flaws when seen through
the specific lens of student project management, however.
Trello for instance, while being a powerful tool for an easy overview, is confusing
at the outset. When discussing Trello, Jesse said in appendix 12.2.3:"people have a
hard time getting introduced to new platforms, so they have to look really simple to use"
Meaning its use needs to be learned by each individual group member to be fully
utilized. This can be a hindrance to the adoption of tools and other software solutions and needs to be weightily considered during the later design phase. A similar
consideration must be done for the creation and maintenance of task overviews, in
a way to aid in co-regulation.
3.2. Interviews
11
The rest of the existing solutions mentioned are also missing the same functionalities, as they are also not meant for project management. Their inclusion herein is
not in vain, as their collaborative use gives insight into the participants’ wants for
increased communication.
Something strongly desired by every participant was for tasks to be overlaid on a
timetable, either by automatically exporting to their own calendar or an internal
date registrar. In the words of Elisa as seen in the appendix 12.2.2: "a calendar, to-do
list with a GANTT chart" This sort of functionality goes hand in hand with the ability
to assign tasks to individuals, as well as teams. Overlaying tasks to be done over
time also requires the ability to set start and end dates for each part of the project
that needs to be done. This happens to also be the definition of a GANTT chart [9].
Furthermore, the inclusion of logbook capabilities, to ensure accountability and for
future reflection, was asked if it was a functionality desired by the interviewees. All
the participants answered in the affirmative, with at least one participant actively
using the concept successfully.
Group Problems
An important aspect to consider when conducting these interviews is the participants’ experience with group projects. More so which factors they conclude lead to
successful group projects and what sort of negative experiences they have had.
A reoccurring theme between the participants is that communication is of high
importance when trying to achieve success within group projects. Many online
platforms allow users to easily communicate with one another, however actively
communicating between group members is down to the individuals. One of the
respondents, Elisa, mentioned having issues with an individual from a previous
project. In the case of this individual, Elisa said in appendix 12.2.2: “The person
would just completely ignore our messages”. Jesse, another one of the participants, also
made mention of issues regarding communication in appendix 12.2.3: “Every time
there was a problem, communication is the foundational problem behind it”.
Whilst communication issues are mainly down to the individuals responsible,
according to the interviewees’ certain tools could be made available to help hold
people accountable for their responsibilities. Something that a project management
tool would certainly aid with, is time management which is a common issue among
the participants. Two out of the three participants mentioned struggling with
deadlines and time management. Rasmus mentioned in appendix 12.2.4: "I think
previously we’ve been a bit loose on deadlines so it would be advantageous to have them
easily accessible". In this situation having a project management tool with a GANTT
12
Chapter 3. Problem analysis
chart could aid in managing and reaching deadlines.
3.2.2
Bias
Due to the small sample size and the selected group of interviewees, consisting
of students with group project experience, it should be noted there is a sampling
bias to be considered [13]. However, the main target group for this project are all
among the small sampling size. Therefore, as the purpose is to find a solution for
this specific target group, this bias does not have significant negative implications
for its credibility.
Furthermore, another bias that occurred in the interview process is commonly
referred to as convergence bias [13]. This bias exists as all of the participants are
engaged with group projects, which corresponds to the investigation of project
management within student groups. Therefore, the biases present do not invalidate
the credibility of this survey.
In addition, the questions have been formed in order to answer specific inquiries
regarding project management, resulting in an answerability bias [15], however, this
bias is acceptable for the research on project management, as specific questions
support the research regarding project management.
3.2.3
Summary of interview
Following the interviews, it has become apparent that communication and time
management are key elements for successful group projects. Therefore, considering
an introduction of a project management tool, with a focus to guide students to be
high-performance teams, would specifically be leaning towards a task scheduler
and to-do list. These functionalities currently do exist, however, the students experienced a slight barrier to entry while learning how to utilise these. In addition, the
interviews showcased a logbook would be a great use in terms of reflection. The
implications of the limitations of the tools will be a focus during the requirements
and design phase of the proposed software solution.
3.3. Analysis of existing project management tools
3.3
13
Analysis of existing project management tools
In this section, an analysis will be done on the free versions of three existing project
management software solutions: Jira [2], Todoist [11] and nTask [19]. These three
will be analysed, to figure out whether they possess specific functionalities commonly requested in the previous sections. Making it possible to create a functionality
matrix, an analysis tool used to compare functionalities across platforms. Thereby,
showcasing the dissimilarities between the requested and existing functionalities
on the different software solutions. Thereby, granting insight into the differences
in the existing functionalities between them and the core components of a project
management tool.
3.3.1
Analysis method
Based on the conclusions of the previous section 3.1 team collaboration, there are
clear characteristic differences between high and low-performance teams. A project
management solution should help its users with the difficulties they experience
during group projects, and utilise functionalities that can encourage its users to
become parts of a high-performance team.
The interviews provide critical insights into the problems that students at Aalborg, and Aarhus University, experience during group work. The interviews from
section 3.2 further promote the importance of communication and time management. According to the interviewees, a task scheduler with assignments and a to-do
list are essential functionalities found within a project management tool, however,
the interviewees expressed some concern about the currently available tools and
wished that they were more intuitive, alongside a logbook for reflection.
The analysis of the existing solution will focus on functionalities, which were
found to be important in section 3.1 regarding Team collaboration, alongside the
feedback from the interviewees in regards to the interviews from section 3.2. The
functionalities have been put into the following table 3.1, which have been ranked
in a top-down hierarchy in terms of importance.
14
Chapter 3. Problem analysis
Explanation of analysed functionalities
Assignments
Users have the ability to delegate work between project
members.
Time Schedule
Gives a mutable overview of tasks overlaying a calendar, with expressed start and end dates.
Kanban Board [4]
An overview of the different tasks which need working
on, in an ordered mutable grid view.
Task Details
The ability to show additional information regarding
assignments.
Logbook
A logbook is a record-keeping book used to document
and track progress and events.
Backlog [5]
A list of tasks that should have been done or needing
to be finished.
Project Settings
The ability to adjust project settings such as project
name and members.
Projects Overview
Pertains to the overview of several different projects at
once.
Push Notifications
Users receive push notifications regarding task assignments nearing deadlines.
Table 3.1: Explanation of functionalities
3.3.2
Example of analysis method
Jira, nTask and Todoist functionalities were all analysed in the same manner. It
should be noted, that the analysis was done using free accounts, meaning any
features behind paywalls have not been examined. The interviewees in section 3.2
have expressed comprehension difficulties utilising the existing solutions. This is an
element of design, therefore, this aspect will not be the focus of the analysis. Only
the existence of the functionalities has been analysed.
3.3. Analysis of existing project management tools
15
Figure 3.1: Todoist - Assignment
Todoist’s assignments were analysed, in order to, illustrate how all of the functionalities were analysed. Tasks can be viewed individually giving the user more options,
as seen in figure 3.1. Assignments allow the user to assign themselves or other users
to a specific task. Thereby, allowing the entire team to see who is currently assigned
to which task.
This procedure for analysing the functionalities of the existing solution has been
done systematically in the same way. The remaining analysis of the functionalities
of the solutions can be found in the appendix 12.
16
3.3.3
Chapter 3. Problem analysis
Functionality matrix
Jira
Todoist
nTask
Assignments
✓
✓
✓
Time schedule
✓
✓
✓
Kanban Board
✓
✓
✓
Task details
✓
✓
✓
Logbook
×
Backlog
✓
×
×
Project settings
✓
×
×
×
Projects overview
✓
✓
✓
Push notifications
✓
×
×
✓
Table 3.2: Functionality Matrix
The result of the analysis can be seen in table 3.2, the functionality matrix showcases an analysis of different functionalities available on three project management
websites: nTask, Todoist, and Jira. The checkmark (✓) and cross (×) symbolise
whether the given solution contains the given functionality. The functionalities that
were analysed include assignments, time schedules, Kanban board, backlog, task
details, logbook, project settings, push notifications, and a project overview. These
functionalities can be seen as core elements in helping teams organise and plan
their projects, according to the previous two sections.
The board and time schedule functionalities, are crucial for task- and time-management
as shown in section 3.2. These functionalities provide users with a visual overview
of their tasks, whilst keeping track of the team’s progress towards their goals. Thus,
allowing teams to enforce high-performance team attributes shown in section 3.1.
Some of the analysed functionalities were found to be unique for certain of the analysed websites. For example, Jira is the only website to have a backlog functionality
and display tasks sorted based on their priority. Logbook was found to be the only
functionality not found on any of the analysed solutions. Based on the conclusions
found in section 3.2, the logbook functionality was found to be a relevant tool in
order for post-process reflection, documentation, and accountability.
3.4. Conclusion of problem analysis
3.3.4
17
Summary of existing project management tools
The existing project management tools, Jira, Todoist and nTask were analysed using
a functionality matrix as seen in table 3.2. With a focus on the functionalities which
were found to be important in the previous sections 3.1, and 3.2. The research gives
insights into the differences in existing functionalities between the three tools and
the core components of a project management tool. Assignments, time schedules,
kanban board, task details, and project overview were all found to be present in
the existing solutions. However, no existing solution provided the functionality of a
logbook. Initial comprehension difficulties, as expressed in prior sections, are part
of the design, and look of the project solution, and have therefore not been analysed
here.
3.4
Conclusion of problem analysis
In conclusion, effective communication, planning, and coordination are crucial for
high-performance teams, while low-performance teams lack these elements. The
introduction of a project management tool can guide students towards becoming
high-performance teams, with a focus on task scheduling and to-do lists. The
research analysed existing project management tools and found that while many
functionalities are present, none offer a logbook feature. The limitations of the
existing tools will be considered during the requirements and design phase of the
proposed software solution. Overall, the use of a well-designed project management tool can enhance team collaboration and time management, leading to more
successful group projects.
Chapter 4
Problem definition
Group projects enable University students to develop skills such as teamwork,
communication, and problem-solving. However, managing group projects can be
challenging for students, especially when it comes to coordinating tasks, keeping
track of deadlines, and ensuring that everyone is on the same page as seen in section
3.2 and 3.1.1.
The analysis also ascertained that current project management solutions have some
pitfall areas, in which they do not suffice the needs of the interviewed students in
section 3.2. A potential solution to this problem is the use of a project management
tool that can help students collaborate effectively and manage their projects efficiently as seen in section 3.3. A tool could provide features such as task assignments,
deadline tracking, progress monitoring, and communication channels to keep team
members informed and on track.
Therefore, the problem to be addressed is how to design and implement an effective
project management tool that can help students during university group projects.
A successful project would consist of a significant portion of these requirements,
thus, while maintaining a user-friendly experience leading to the problem statement:
How can a web-based project management tool be created, in order to
ensure accountability, and time management for student group projects?
19
Chapter 5
Requirements
This chapter will specify the requirements of a project management website solution.
The requirements have been based on the information gathered in the problem
analysis in chapter 3 and the problem definition in chapter 4. The requirements
serve as a guideline in the implementation of the program. By using the MoSCoW
requirements prioritisation model, it ensures that functionalities are developed in
order of importance to the final application. These requirements will later be tested
to determine the success of the final application.
21
22
5.1
Chapter 5. Requirements
MoSCoW Prioritisation Model
The Moscow requirements, also known as the MoSCoW method [20], is a prioritisation model used in project management, to help determine the importance of
different project features or requirements. The findings shown in chapter 4 will be
utilised to create specific requirements, to determine whether the proposed solution is successful [20]. The term MoSCoW stems from the acronym of Must-have,
Should-have, Could-have, and Will-not-have, and is summarised in the following
table.
MoSCoW prioritisation model
Must-have: These requirements can be classified as features being mandatory
for the product, in order, to be evaluated as complete.
Should-have: These requirements can be classified as an overall improvement for
the product. Hence, they have a lower prioritisation but are desired if possible.
Could-have: These requirements can be classified as potential bonus features for
the product, as the impact does not influence the general quality.
Will-not-have: These features can be classified as potential future features, due
to not fitting into the scope due to time constraints.
Table 5.1: MoSCoW prioritisation model [20]
23
5.2. MoSCoW Requirements
5.2
MoSCoW Requirements
M
Must-have requirements
M1
Kanban Board
M2
Time Schedule
M3
Task details
M4
Logbook
M5
Navigation between functionalities
S
Should-have requirements
S1
Backlog
S2
Synchronous collaboration
S3
Synchronisation from Kanban Board to GANTT & Backlog
C
Could-have requirements
C1
GANTT Calendar Export
C2
Login
W
Will-not-have requirements
W1
User accounts
W2
Chat communication
W3
Push notifications
Table 5.2: MoSCoW requirements
The following MoSCoW requirements have been made based upon the information
gathered in chapter 3 and 4. These requirements are largely based upon section
3.2 whilst factoring in the research on high- and low-performance teams and the
analysis on existing project management tools. Table 5.2 showcases the MoSCoW
requirements which have been formed to create a clear outline for the expected
functionalities for a successful project management website. The core components
of the website application, are shown within the must-have requirements. The
potential functionalities for overall improvements can be seen in the should-have requirements. Potential bonus features are showcased in the could-have requirements.
Potential future functionalities can be seen in the will-not-have requirements.
24
M1
Chapter 5. Requirements
Kanban Board
M1.1
The website shall allow users to create new tasks containing the task
name, assignee, start-date, end-date, status, and priority which are then
added to the Kanban Board, while also being able to delete tasks.
M1.2
The website shall allow users to assign assignees to tasks on the Kanban
Board.
M1.3
The website shall allow users to manipulate the status of each task to
either "To-do", "Doing", or "Done", and display the status on its corresponding card on the Kanban Board.
M1.4
The website shall allow users to interact with the Kanban Board to modify
task information and deadlines.
M1.5
The website shall allow users to use a drag-and-drop functionality to
modify task statuses.
M2
Time Schedule
M2.1
The website shall represent the status of each task containing the status
to-do or doing on a GANTT chart viewable by users.
M2.2
The website shall provide a calendar overview, which displays all tasks
with the status of to-do, doing, and their deadlines, and are sorted
according to their start-date, within the selected month.
M3
Task Details
M3.1
The website shall allow users to view task attributes such as description,
priority, and deadlines.
M3.2
The website shall allow the user to be able to edit task details.
M4
Logbook
M4.1
The website shall allow users to create a new logbook entry.
M4.2
The website shall allow the user to document progress through headers
and descriptions with a status.
M4.3
The website shall showcase the specific timestamp of the creation of a
logbook entry.
M4.4
The website shall allow users to view, edit, and delete logbook entries.
M5
M5.1
Navigation of application
The website shall provide the user with the ability to navigate between
functionalities. For example, the user is able to go from Kanban Board to
Logbook.
Table 5.3: Must-haves requirements
5.2. MoSCoW Requirements
25
The must-have functionalities for the website can be seen in table 5.3 and are the
most critical functionalities that were found for project management websites, listed
in a hierarchical order of importance found in table 3.2, with the addition of navigation of the application. In addition, sub-requirements have been utilised to ensure
correct implementation. Allowing them to be testable for future testing with no
confusion about whether they have been fulfilled.
M1 Kanban Board was created to fulfil the requirements for a visual representation
of tasks, deadlines, and priorities. The users would be able to create and manipulate
these tasks depending on their project, thus, helping them to organise their project
and assist their productivity while providing accountability between team members.
M2 Time Schedule fulfils the requirements of a visualisation of the tasks through
a calendar, giving users a clear overview of their timeline for their project. The
calendar should be represented as a GANTT chart and must include a visual representation of task assignees, deadlines, and tasks’ current status in a sorted manner.
M3 Task Details should provide a detailed overview of each task found on the Kanban Board. It should contain the task-name in addition to the attached attributes of
the task, including the following attributes of assignee, status, and task description.
M4 Logbook enables users to document their activities and progress through
the creation and editing of logbooks. Thereby, allowing users to document overall
progress. The logbooks would be sorted accordingly to the creation date, thus,
providing a clear overview and documentation of the progress made by each team
member throughout the entire project.
M5 Navigation of the application should ensure clear and accessible navigation
options for the user to move in between the critical functionalities found on the
website.
26
Chapter 5. Requirements
S1
S1.1
S2
S2.1
S3
S3.1
Backlog
The website should showcase the tasks and specific task details such as
assignee, priority, status, start- and end-date from the Kanban Board,
which are then sorted according to firstly the end-date and then priority.
Synchronous collaboration
The website should provide a real-time update of the Kanban Board,
GANTT, Backlog, and Logbook for all users.
Synchronisation from Kanban Board to GANTT & Backlog
The GANTT should be automatically generated based on the tasks and
their associated deadlines from the Kanban Board.
Table 5.4: Should-have requirements
The should-have functionalities for the website can be seen in table 5.4, and are
desirable functionalities to be found in the project management website. Whilst
these functionalities are not critical in comparison to the must-haves they still greatly
improve the functionality and experience of the program, and should be included
in the final iteration of the website if possible.
S1 Backlog should enable the user to view a sorted version of all the tasks found on
the Kanban Board, on the basis of the most urgent deadlines and priorities. Thus,
visualising the current most critical tasks, which should assist team members to
comprehend which tasks they should focus on.
S2 Synchronous collaboration fulfils the requirement of a collaborative working
environment with real-time updates for all connected users and should enable team
members to work concurrently on the website.
S3 Tasks created on the Kanban Board should automatically be shown on the
Backlog and the GANTT chart to give the users options on how to visualise their
tasks.
5.2. MoSCoW Requirements
C1
C1.1
C2
C2.1
27
Calendar Export
The website could allow users to export tasks to a CSV file.
Login
The website could allow users to log in to the website using a shared
password
Table 5.5: Could-have requirements
The could-have requirements are non-essential features or functionalities found on
the website, that could improve the user experience, but are less important than
must- and should-have requirements.
C1 Calendar export is in the could-have category because it would not benefit
the user experience on the website directly, but could potentially be a valuable
functionality for some users.
C2 Login is considered a could-have requirement, as for a project on this scale, the
collaborative aspects can be handled without having specific accounts to differentiate the users. Therefore, a master login could be implemented to provide security
on the website, so only those who have the master login are able to make changes.
28
W1
Chapter 5. Requirements
User accounts
W1.1
The website will not require users to create an account or log in to use its
features.
W1.2
The website will not provide user-specific settings or personalisation
features.
W2
Chat communication
W2.1
The website will not provide a chat or messaging feature for users to
communicate with each other.
W2.2
The website will not integrate with any external communication platforms.
W2.3
The website will not provide any notification or alert features for chat or
messaging.
W3
Push notifications
W3.1
The website will not provide push notifications to users’ devices.
W3.2
The website will not provide any email or other types of notifications.
Table 5.6: Will-not-have requirements
The will-not-have requirements are the features that will not be included in the
final iteration of the website but could be taken into account as potential future features. This is due to being out of the scope of the project due to the short time frame.
W1 User accounts are in the will-not-have category, due to the time scope for
the final implementation of the website, as a full-scale user accounts implementation would require large time and resource investments. Furthermore, the website is
primarily intended for small-sized project management in terms of students, hence,
it would only focus on one project at a time. Therefore, there is no high importance
to implement specific accounts to differentiate the users through settings or personalisation features, as they would still be able to work concurrently on the website.
W2 Chat communication will not be a functionality included in the final product
as our section 3.2 showcased that students already utilise other software solutions
in order to communicate with each other, moreover the addition of a chat would
introduce additional functionalities for users to learn. The interviewees expressed
concerns about the overwhelming amount of functionalities found in other project
5.3. Summary of requirements
29
management solutions.
W3 Push notifications were a requested feature in the conducted interviews. Implementing push notifications in the absence of user accounts would be counterintuitive as there exist no user accounts for specified settings and personalisation
features, where one would normally find the push notifications option. Thereby,
potentially adding confusion to the users on how to utilise the feature.
5.3
Summary of requirements
In conclusion, the MoSCoW prioritisation model has been utilised to set up requirements for the intended project management solution. The importance of the
functionalities were constructed on the basis of the functionality matrix seen in
table 3.2, with additional important functionalities. The requirements have been
placed in the Must, Should, Could, and Will-not-have requirements to ensure that
functionalities are developed in terms of their importance to the final product and
can be seen in table 5.2. Kanban Board, Time Schedule, Task Details, Logbook, and
Navigation of application are all functionalities that must be fulfilled to ensure the
website is successful for project management as seen in table 5.3.
Chapter 6
Design
The chapter delves into the implementation of the project management solution by
exploring the overall design of the website. The specific requirements set in chapter
5 form the basis of this exploration, with the aim of creating a design template that
will guide future implementation. As part of this process, the psychological concept
of nudging, which can be used to subtly influence user behaviour and enhance
their experience with the website, is also considered. Furthermore, sketches will be
developed to showcase the expected design for the most essential functionalities of
the solution. In addition, the expected data objects will be explored, to assist the
the coming implementation.
6.1
Visual presentation
Visual cues provide direct feedback to the users, so they understand the importance
of each task. For instance, certain design elements can influence user behaviour
through nudging [23]. Digital nudging involves guiding user behaviour, achieved
by using specific colours to indicate the importance level of each task [23].
To highlight the urgency of each task, a status is assigned based on its progress,
accompanied by a corresponding colour. This design decision was made in order
to guide the users’ attention toward, meaningful and urgent tasks while providing
visual cues for the user.
31
32
Chapter 6. Design
Figure 6.1: To do, Doing, Done and Overdue
As seen in figure 6.1, "To-do" should have a blue colour to suggest calmness and
responsibility, in the sense the user’s attention is not yet required, but will be at a
later point in the project [14]. In addition, "Doing" should possess an orange colour
to embrace its progress in movement [14]. Thereby, suggesting the user should pay
attention to this task. "Done" should have a green colour as it possesses calming
attributes [14], and as the task is completed this will provide a corresponding
visual cue to the user. Lastly, "Over-due" should have a red colour to indicate the
importance to complete the task as soon as possible, and also to showcase a danger
for the project, if this task isn’t completed [14].
The tasks should be sorted into four groups, To-do, Doing, Done, and Over-due.
With these groupings, the Kanban Board would be able to provide a visual representation of the tasks’ importance through their statuses. In addition, the time schedule
should likewise possess these attributes, when displaying the tasks through a
GANTT diagram. The tasks’ importance should be sorted through their status from
the start date.
6.1.1
Website sketches
Sketches were created to visually represent the design and functionality of key
features on the main pages of the project management application. These sketches
depict the desired appearance and serve as a guide for the future implementation
of the website, aligning with the requirements outlined in Chapter 5.
33
6.1. Visual presentation
Figure 6.2: KanbanBoardSketch
As seen in figure 6.2, a sketch has been drawn to illustrate how the Kanban Board
is expected to look. Included in the sketch is a navigation bar the user can utilise,
which would be identical across all the functionalities. The Kanban Board should
utilise the colour theory explained previously in section 6.1. The functionality is
expected to have the four different statuses in their own containers, alongside the
list of tasks corresponding to the status. If a task exceeds the planned end date,
then as seen in the sketch it would be automatically moved to the "Overdue" block.
In addition, a task drag ability across containers is desired, where it would change
their status, to whichever container it has been dropped in. The "add new task"
button enables users to create additional tasks.
34
Chapter 6. Design
Figure 6.3: GANTT Sketch
The expected design of the GANTT chart is illustrated through the sketch in figure
6.3. The chart is expected only to showcase non-finished tasks. This means that
all tasks which do not have the status of ’done’ will be displayed. In addition, all
these tasks will be displayed in order of their start and end date, alongside their
colour-coded status specified previously in section 6.1. This provides the users with
a graphical overview of the tasks which are still to be completed. Furthermore, in
the case a user hovers over one of the tasks, tooltips should display the task name,
description, and status. When the user first navigates to GANTT, the current date
will always be in the middle of the GANTT chart, as seen by the line in the sketch.
Lastly, the user is expected to be able to navigate the displayed tasks of the GANTT
chart, with the "previous" and "next-month" buttons. In the case the user presses the
"previous-month" button, they will navigate 1 month back in the GANTT chart, in
contrast, the "next-month" button should navigate 1 month forward in the GANTT
chart. Hereupon it should be noted the current date line will not follow, as it is no
longer within the date range.
35
6.1. Visual presentation
Figure 6.4: Logbook Sketch
As seen in figure 6.4, a sketch has been created in order to illustrate how the
Logbook page is expected to look. It is expected a container should be shown to the
left, which showcases all currently created logbooks. When a user clicks on one of
the logbooks, it would open another container displaying the logbook information.
In addition, they would be able to add new additional headers and paragraphs.
Furthermore, each header has a checkbox which can be checked, if all the tasks
which are talked about in the paragraph have been completed.
36
Chapter 6. Design
Figure 6.5: Backlog Sketch
Figure 6.5 illustrates the expected Backlog design. As seen in the figure, tasks which
are not finished should be displayed in a table-like manner. The table will contain
important task attributes, as shown in the sketch, these include: "Task Name",
"Description", "Status" and "Due date". The tasks displayed in the backlog will be
sorted after the deadline and priority. This means the tasks will be sorted by the
urgency in terms of the deadline. Giving the users a clear overview of which task to
handle first, to avoid tasks becoming overdue. Lastly, each row representing a task
should be coloured coded accordingly to their current status, as defined in section
6.1, to further emphasise the urgency of each task.
37
6.2. Data objects
6.2
Data objects
Figure 6.6: Expected essential data objects
During the initial design phase of a web application, it is crucial to consider the expected data objects that need to be stored. The structure helps define the individual
attributes required for each object and can have an impact on the compatibility of
frameworks and libraries used for the application’s implementation phases. Figure
6.6 represents the expected object structures for this project.
The "Assignee" and "Tasks" objects are expected to follow a structured data format,
with the "Tasks" object containing a nested "TaskAttributes" object as seen in the
figure. In contrast, the "Logbooks" object is expected to have a semi-structured data
format. To further explain, the "Logbook" object is expected to initially consist of
an id and date when a logbook entry is created, where after a varying amount of
"headers", "paragraphs" and "checkboxes" can be added for each logbook entry as
previously explained in section 6.1.1. Structured data follows a defined schema or
model, while semi-structured data has some level of organization but not to the
extent of a structured database.
Clearly defining the data objects provides valuable insights for the implementation phase of the program. Having predefined data objects will help ensure that a
compatible database will be chosen which will help avoid potential complications
later on.
38
6.3
Chapter 6. Design
Summary of design
Chapter 6 discusses the implementation of the project management solution by
exploring the overall design of the website, based on the requirements set in Chapter
5. The concept of nudging has also been considered, and specific colours are used
to indicate the importance of each task and guide user attention. Sketches of the
Kanban Board, GANTT, Logbook, and Backlog pages are included as a guideline for
future implementation. The Kanban Board is expected to display the four different
statuses, while the GANTT chart will display non-finished tasks. Furthermore, the
logbook page should include a container for currently existing logbooks, including
the ability to add new headers and paragraphs. The Backlog page will showcase
ongoing tasks sorted by urgency. Finally, the expected data objects have been
outlined. Overall, these design decisions are intended to enhance user experience
and provide visual cues for prioritising tasks. Thus, providing a template for the
implementation of the base application.
Chapter 7
Implementation
This chapter explains the technical implementation of the project management
website. An overall representation of the server design will be showcased, alongside
how routes have been utilised to handle endpoints and responses. The choice of
database and its utilisation will be defined. In addition, listings will be utilised to
illustrate and explain interesting parts of the code sections, including challenges
that were encountered during the implementation. Furthermore, unit testing will
be implemented prior to the commencement of the external testing phase.
7.1
7.1.1
Frameworks / Libraries
Server design
In order to meet the S2 should-have requirement, which required a synchronous
collaborative experience for the users, a constant connection between the server and
user is required. The book JavaScript: The Definitive Guide by David Flanagan,
has been used to investigate possible ways to make it achievable [7]. It was found
to ensure a collaborative experience for the user, either server-sent events (SSE) or
WebSockets were essential to be implemented in the application. SSEs would allow
the server to establish a unidirectional HTTP connection between the server and
client, ensuring up-to-date information is being displayed for all users. Meanwhile,
WebSockets would allow bi-directional persistent connection between the client
and server which in turn uses a larger amount of resources [7]. Thus, allowing the
user and server to continuously send and receive information, without the need for
multiple repeated requests from the user.
SSEs were chosen for this solution because it provides a persistent server-to-client
communication stream, allowing for real-time updates. Moreover, WebSockets
consume additional resources in comparison to SSEs and are often implemented
39
40
Chapter 7. Implementation
when large amounts of data frequently need to be pushed in both directions.
7.1.2
Routes
Routing refers to the process of handling client requests and directing clients to
appropriate endpoints on web applications. In other words, routing determines
how to application responds to client activity, on a web application. Express is a
commonly used Node.js framework, which is used for building web applications
and contains tools and middleware that simplify the process of handling HTTP
requests and responses [8]. In the context of the website application being developed,
Express was chosen as the framework of choice for handling server-side logic, over
the standard node HTTP library.
1
2
3
4
5
6
7
8
9
10
11
12
const
const
const
const
taskRoutes = require('./routes/serverTasks');
logbookRoutes = require('./routes/serverLogbook');
assigneeRoutes = require('./routes/serverAssignee');
app = express();
app.use(cors());
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: false }));
app.use('/Tasks', taskRoutes);
app.use('/Logbook', logbookRoutes);
app.use('/Assignee', assigneeRoutes);
app.use(express.static(path.join(__dirname, 'scripts')));
app.use(express.static(path.join(__dirname, 'styles')));
Listing 1: routes.js
In the code snippet listing 1, Express was used to create route modules/middleware
for specifically related functionalities. The routes are set up using the ’app’ object
provided by Express, which allows for an imperative approach to defining routes
on the server side. The main routes can be seen in lines 8-10 in listing 1, imported
from their respective files. By utilising express middleware, the implementation
could be broken down into smaller modules/files that can be linked through routes,
which improves the maintainability and scalability of the project.
Using this modular approach, where each route has its own file made the development process more organized. Splitting the server up into individual routes
meant that multiple functionalities could be developed simultaneously, making
co-development easier since it prevented potential issues from merging code, which
can be complicated if projects are large.
41
7.1. Frameworks / Libraries
Lines 11-12 in listing 1 showcases Express’ build in middleware functionality
that lets static files be served with HTML files. This feature enables the server to
respond with an HTML document with its related CSS and JavaScript dependencies.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
router.post('/SendTask', (req, res) => {
console.log("Got POST submitTask request", req.body);
const data = req.body;
taskDataBase.insert(data, (err, newTask) => {
if (err) {
res.status(500).send({ error: err });
}
else {
res.status(200).json({
TaskName: newTask.TaskName,
});
}
});
})
Listing 2: Post endpoint.
The code snippet that can be seen in listing 2 showcases an example of a server
endpoint. The code snippet is of the /Tasks/SendTask endpoint in the /Tasks route.
The route is used for users of the application to submit tasks to the database. The
endpoints receive an HTTP request from the client, with the necessary attributes of
a task and are then stored in the taskDataBase as seen in line 4. A full overview of
the server endpoints and their functionality can be seen in the table on the following
page.
42
Chapter 7. Implementation
Method
Endpoint
Description
GET
/board
Serves the static files for Board
(HTML, JS, CSS).
GET
/gantt
Serves the static files for GANTT.
GET
/backlog
Serves the static files for Backlog.
GET
/logbook
Serves the static files for Logbook.
GET
/Tasks/events
Establish server-sent event stream
for real-time Kanban Board updates.
GET
/Logbooks/events
Sends the logbook entries list to the
logbook page.
GET
/Logbooks/GetLogbookEntry
Sends the logbook entry data given
the logbook entry ID.
GET
/Assignee/events
Establishes a server-sent event
stream for real-time updates of assignees to relevant pages.
PATCH
/Tasks/UpdateStatus
Updates the status of a task with a
given ID on drag and drop.
PATCH
/Tasks/Edit
Edits the attributes of a task with a
given ID.
PATCH
/Logbook/SaveLogbookEntry
Edits the attributes of a logbook
with a given ID.
POST
/Tasks/SendTask
Adds a new task and task attributes
to the task database.
POST
/Logbook/SendLogbook
Adds a new logbook with the date
creation to the logbook database.
POST
/Logbook/UpdatePost
Adds headers and descriptions to
the selected logbook ID.
POST
/Assignee/SendAssignee
Adds a new assignee to the assignee
database.
DELETE
/Tasks/Delete
Deletes a task with a given ID from
the task database.
DELETE
/Logbook/Delete
Deletes a logbook with a given ID
from the logbook database.
DELETE
/Assignee/Delete
Deletes an assignee with a given ID
from the logbook database.
Table 7.1: Server endpoints
7.1. Frameworks / Libraries
43
The full list of the application endpoints website can be seen in table 7.1. As
previously mentioned the server endpoints are used for the user to be able to
interact and receive information from the server. In short, the GET request is used to
serve the client with the appropriate HTML documents and their associated styling
sheets and script files. In addition, the GET /events should be used to establish a
continuously open connection from the server to the client, via server-sent events.
Meanwhile, the other three methods would take the data input from the client,
whereupon the server handles the data depending on whether it should be posting
new data, editing/patching existing data, or deleting existing data on the specified
database. The client-side would send the data to the server through a text input or
button input.
7.1.3
Databases
Databases are organised collections of data, that are used to store, retrieve or otherwise manipulate data. Databases are used as a central storage unit for their users.
This means that users receive/manipulate data from the server database, in order
to utilise web applications. Databases play an essential role in most applications
as they provide the ability to store and retrieve user data, thus, making it possible
to maintain synchronized experiences between different users. When clients are
accessing web applications at the same time, a database is used to store and update
the application’s data in real time, allowing all users to see the same up-to-date
information simultaneously.
This application will utilise databases, in order to store data. For example, when a
user creates a new task or edits an existing task, the database stores this information,
the server then registers that the database has been updated and immediately sends
the updated data to all clients who are currently using the website. If the database
were not used, each user would see non-identical information, which could lead
to potential confusion and inconsistencies in the application’s data. Therefore, a
database is an essential component of a web application, particularly when multiple
users are involved.
NoSQL and SQL databases were both considered when choosing what type of
database to implement. NoSQL databases are known to be flexible and scaleable,
they are suitable for applications that handle large amounts of unstructured or
semi-structured data [17]. Meanwhile, SQL databases are known for their ability to
ensure predefined schemas, ensuring data consistency and are suitable for applications that use complex relationships between data entities and require strong data
consistency [17]. Since some of the data structures were expected to be varying as
discussed in section 6.2, a NoSQL solution was chosen.
44
Chapter 7. Implementation
NeDB [3], a sub API of MongoDB [16], has been chosen as the database solution. One of the advantages of Nedb is its lightweight NoSQL API, which is written
in JavaScript [3]. Additionally, Nedb can store data directly on the server, eliminating the need for an unnecessary link between the client and the data.
NeDB is a document-oriented database that stores data in JSON format. JSON
(JavaScript Object Notation) is a widely used data interchange format that is humanreadable, lightweight, and supported by JavaScript. This makes it easy to store,
retrieve, and manipulate data in NeDB, as the data is stored in a familiar and flexible
JSON format. Although NeDB is no longer maintained, the current version should
still be able to sufficiently achieve the results for what the application requires [3].
However, in case it is not sufficient, MongoDB itself would be another alternative
which could be utilised.
7.2
7.2.1
Website functionalities
Kanban Board
Figure 7.1: Kanban Board
The Kanban board is implemented using JavaScript and HTML, and provides a
visual representation of tasks organized into the different lists "To-do", "Doing",
"Overdue", and "Done" as seen in figure 7.1. The tasks are colour-coded based on
45
7.2. Website functionalities
section 6.1, in order to aid the user, differentiate between task statuses and their
importance. Moreover, each list is dynamically updated such that the most urgent
tasks are displayed at the top of their respective list. The board is interactive and allows users to drag and drop tasks between lists to update their status. Additionally,
the board page also houses the form that creates new tasks.
In order to fulfil the requirements of synchronous collaboration seen in table
5.4, newly created tasks also send a request to the server using the previously seen
HTTP POST in listing 2 and adds the new task to the database. When the server has
successfully added or otherwise manipulated data in the task database, the server
sends the updated data to all clients currently using the website, thus resulting in
the Kanban board being updated in real time using Server-Sent Events (SSE).
1
2
3
4
5
6
7
8
9
10
11
source.addEventListener("message", function getTasks(event) {
const tasks = JSON.parse(event.data);
tasks.sort((a, b) => {
if (a.TaskAttributes.Priority === b.TaskAttributes.Priority) {
// If priority is same, sort by end date
return new Date(a.TaskAttributes.EndDate) - new
,→
Date(b.TaskAttributes.EndDate);
} else {
// Sort by priority
return priorityValues[b.TaskAttributes.Priority] ,→
priorityValues[a.TaskAttributes.Priority];
}
});
Listing 3: Task Sorting
The implementation of the client side can be seen in listing 3. The EventSource
object is used to listen for message events from the server, and the received data
is parsed as JSON. The tasks are then sorted based on their priority and end date
before rendering them on the board. A similar implementation of sorting JSON
objects from the database is utilised across multiple functionalities on the web
application.
46
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Chapter 7. Implementation
function makeDraggable(){
const draggableElements = document.querySelectorAll('[draggable=true]');
const containers = document.querySelectorAll("#TaskList")
draggableElements.forEach((element) => {
element.addEventListener("dragstart", () => {
element.classList.add("dragging")
})
element.addEventListener("dragend", () => {
element.classList.remove("dragging")
})
})
containers.forEach((container) => {
container.addEventListener("dragover", (event) => {
})
Listing 4: Kanban Board makeDraggable()
The Kanban board is designed to be highly interactive and user-friendly, allowing
team members to easily rearrange and manipulate tasks using drag-and-drop
functionality. The drag-and-drop feature is implemented using the draggable
attribute in addition to JavaScript event listeners. The makeDraggable() function
is responsible for attaching the necessary event listeners for the drag-and-drop
functionality. When a task is dragged, its class is updated to reflect that it is being
dragged. When the task is dropped onto a different list, its status is updated and
the task is re-rendered in the correct list. Additionally, the updated task data is also
sent to the server using a PATCH request to update the task’s status.
47
7.2. Website functionalities
7.2.2
GANTT
Figure 7.2: GANTT
Chart.js is a commonly used JavaScript library for making interactive and customizable charts and graphs with JavaScript. Chart.js provides a configurable way to
display data in various chart types such as line charts and bar charts. Chart.js
provides extensive documentation and examples, that have been utilized in the
implementation of the task visualization requirements 5.3.
Chart.js offers a wide range of chart types to choose from, making it versatile
for different use cases. Chart.js with the bar chart configuration has been utilised
to give users an overview of tasks with a GANTT diagram as seen in figure 7.2.
Chart.js provides many options, allowing for customization of the appearance and
the behaviour of charts. Chart.js also supports responsive design, allowing charts to
be dynamically updated.
48
1
2
3
4
5
function updateChart(sortedTasks, barColorsTask, borderColorsTask) {
const chart = Chart.getChart("myChart");
console.log(chart)
chart.config.options.scales.x.min = minCurrentDate
chart.config.options.scales.x.max = maxCurrentDate
6
7
8
9
10
11
Chapter 7. Implementation
}
chart.data.datasets[0].data = sortedTasks;
chart.data.datasets[0].backgroundColor = barColorsTask;
chart.data.datasets[0].borderColor = borderColorsTask;
chart.clear();
chart.update();
Listing 5: GANTT update chart
The implementation of updateChart can be seen in listing 5, tasks are firstly sorted
in the same manner as in the Kanban board. Additionally, the colors for the task
are set for each task, based on their respective status. The previously displayed data
is then removed and the chart is updated.
However, utilising the library Chart.js to simulate a version of a GANTT chart
which worked interactively with the Kanban Board proved challenging. The solution found can be seen in listing 5 on lines 9-10, where the chart is cleared completely
and then updated using the data it receives in line 1. The main issues stemmed
from when new tasks were being added to the chart and were not being displayed
correctly in relation to the previous tasks. Therefore, to ensure all tasks were displayed correctly, this function forced the chart to be redrawn when updates were
required. This solved the issue of the chart not updating correctly and displaying
the correct tasks when added from the Kanban Board.
7.3
Unit testing
Unit testing is where one tests the smallest testable units in a software application.
A unit can be a function, a method, a class, or a module [22]. Unit testing is done
to improve the quality, maintainability, and reliability of software applications, by
ensuring that individual functions work as intended [22].
The testing framework chosen to be used in this project is Jest. The reasoning
behind the choice of Jest is that it is a JavaScript testing framework which should be
simple to use, and is well-documented [12]. Furthermore, the Jest framework allows
for Mock testing. Mock testing allows the developer to imitate data and objects,
which is used to isolate the unit test from external dependencies [12].
49
7.3. Unit testing
However, one of the main complications of the implementation of unit testing,
was that unit testing was implemented after the base application already had been
completed. This meant the unit testing was created after it was concluded the application itself was working through manual testing. This results in difficulties due to
having many nested functions, which would be unsuitable for testing. Furthermore,
due to the remaining time frame for the project, it was decided against refactoring
the code to allow for easier testing. One example of issues arising when trying
to test functions using Jest, was that event listeners were called even though they
were not a part of the function itself. Therefore, the event listeners were mocked
to circumvent this issue as seen in listing 6, even though it was not being used in
the function itself. In addition, as the application was confirmed to be working, the
focus was only on testing the main functions utilised in the code, to create sufficient
code coverage.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
const { sortTasks } = require('../../scripts/board');
global.EventSource = jest.fn();
const mockEventSource = {
addEventListener: jest.fn(),
};
global.EventSource.mockImplementation(() => mockEventSource);
describe("sortTasks function", () => {
it("should sort tasks by end date and priority
const tasks = [
{ TaskAttributes: { EndDate: "2023-04-18",
{ TaskAttributes: { EndDate: "2023-04-16",
{ TaskAttributes: { EndDate: "2023-04-17",
];
const expectedTasks = [
{ TaskAttributes: { EndDate: "2023-04-16",
{ TaskAttributes: { EndDate: "2023-04-17",
{ TaskAttributes: { EndDate: "2023-04-18",
];
correctly", () => {
Priority: "high" } },
Priority: "medium" } },
Priority: "low" } },
Priority: "medium" } },
Priority: "low" } },
Priority: "high" } },
const sortedTasks = sortTasks(tasks);
expect(sortedTasks).toEqual(expectedTasks);
});
});
Listing 6: Board sorting test
In this test, listing 6, the getTasks() function is tested to verify that it correctly sorts
the given tasks. Three out-of-order mocking tasks are created that contain an end
date and a priority. The test file imports the function you want to test and you test it
50
Chapter 7. Implementation
by using the expect() function. The expect() function takes the function you want to
test as a parameter and gives you a whole suite of ’matches’ that allow you to test
the output of the tested function. In this example, the toEqual() matches is used and
it expects that the sortedTasks are equal to the expectedTasks. If the sortedTasks are
indeed equal to the expectedTasks the test will pass.
Figure 7.3: Code Coverage
As seen in figure 7.3, it showcases the code coverage of the application. As aforementioned it was only the most important functions which have been tested. The
justification for not testing everything in the code is that white box testing has been
utilised to manually test the application before the unit testing was implemented.
The main way the application has been tested is that the functionalities were manually tested throughout the implementation to ensure correctness. Thereby, allowing
one to understand if the code was working as intended, and would be sufficient
for external testing. Furthermore, the overall structure of the application was not
created with the expectation of unit testing, which complicated the process of testing
compared to a more component-based application.
In addition, this meant that all event listeners and event sources have been manually
tested. Furthermore, there were issues with importing the global variables for
testing, and it was decided against changing the global variables directly into the
functions they utilised. It was attempted to figure out how to properly test it,
however, due to the time constraint it was decided the manual testing done prior
was sufficient, as the code coverage covered 47.64% lines of the code as seen in
figure 7.3.
7.4. Conclusion
7.4
51
Conclusion
Throughout this chapter, it was discovered that Server-Sent Events needed to be implemented in order to achieve a synchronous collaborative experience for all users.
Moreover, in order to make the server-side implementation easier, the framework
Express was chosen, for its ability to easily set up routes. Furthermore, table 7.1
gives a detailed overview of the available endpoints. NeDB a NoSQL database
library was chosen to be implemented as the data structures were expected to vary.
In addition to allowing for local server storage, and eliminating an additional link
between the client and the data, it also makes the data handling easier by storing it
in JSON format. Lastly, unit testing was done using the framework Jest, which was
utilised to test selected important units of the application where 47.64% of the code
lines have been tested. Thereby, ensuring the application is ready for external testing.
Chapter 8
Testing
The following chapter will be dedicated to user story testing in the context of the
project management tool introduced by this report. This chapter will briefly describe
what user stories are and will delve lightly into the importance of user stories and
how they will be utilized in this project. This chapter will also study the results of
the following tests to consider the overall success of the application.
8.1
User stories
User stories are a core programming component as they help provide a user-focused
framework for daily work. Implementing user stories drives user-oriented testing
and introduces an overall better end product. A user story is a small unit of work
in an agile framework. A user story is not a feature but rather an end goal that has
been expressed from the software user’s perspective. The purpose of a user story is
to express how a part of the work will provide a particular response in return. More
specifically user stories are a few simple sentences that outline a desired outcome
[21].
The reasoning behind the inclusion of user stories is to determine if the introduced software application can be seen as a success or not. User stories also include
the key benefit of being able to acquire additional feedback from the testers. The
feedback and subsequent changes that could follow, will however not be implemented but could be something looked upon in the future.
This section will present a series of tests which has been created based upon
the previously defined MoSCoW Requirements from chapter 5 and the completion
of said tests are crucial in determining whether this software application can be
seen as a success or not. The success of the application is reliant on whether or not
the problem definition from chapter 4 has been answered.
53
54
Chapter 8. Testing
User stories
Req
Test 1
On the Kanban Board, you want to create five unique new
tasks.
M1
Test 2
On the Kanban Board, you want to delete one of the tasks.
M1
Test 3
On the Kanban Board, you want to change the assignee,
status, and deadline using the edit button.
M1
Test 4
On the Kanban Board, you want to click on one of the tasks
and drag them to another status.
M1
Test 5
On the GANTT you want to make sure that tasks from
the Kanban board, with the statuses: "To-do", "Doing" and
"Overdue" are displayed on the GANTT diagram.
M2 | S3
Test 6
On the GANTT page you want to check if the tasks are
sorted correctly after their start date.
M2
Test 7
On the Kanban Board you want to read the task details of
two different tasks.
M3
Test 8
On the Kanban Board you want to edit the description of a
task.
M3
Test 9
On the Logbook page, you want to create two new logbook
entries.
M4
Test 10
On the Logbook page, you want to delete a logbook entry.
M4
Test 11
On the Logbook page, you want to open a logbook entry
create and then delete a header and paragraph.
M4
Test 12
On the Logbook page you want to edit a header and paragraph save the information.
M4
Test 13
On the Backlog page you to make sure that tasks from
the Kanban board, with the statuses: "To-do", "Doing" and
"Overdue" are displayed sorted by end date.
M5 |S1
Test
Table 8.1: User stories for Must-Have requirements
As seen in table 8.1, 13 user stories have been created in order to test the project
management website. These tests have been modified accordingly to ensure all the
must-have requirements from table 5.3 will be tested. Test 1 ensures the first half of
M1.1 is being fulfilled while test 2, would test the second half the M1.1. This is done
to accurately figure out whether the must-have requirement was successful. The
same method has been utilised through the creation of all the user story tests. They
8.1. User stories
55
have been created hierarchically alongside the must-have requirements. This means
user story test 3, would now correspond to the M1.2, as the previous two tested M1.1.
Some of the should-have requirements, as seen in table 5.4, have been added
to the tests, as seen in test 5. Test 5 is mainly corresponding to M2.1 regarding the
GANTT chart, however, the test is created so it also tests the S3.1, as it makes the
user compare the Kanban Board to the GANTT chart. Thus, if this user story test is
successful, then both of the requirements can be marked as a success. This is also
seen with test 13, which specifies the utilisation of the navigation bar towards the
backlog page, which means that the tester has been on every page of the website,
thus, fulfilling M5.1 regarding navigation. In addition, test 13 itself is regarding the
backlog which would fulfil S1.1.
8.1.1
External testing
To ensure the project management website is a success, external testers have been
asked to test the website accordingly to the created user story tests. A total of
three test participants between the age of 22-24 years old in varying stages of their
university studies were chosen. The way the tests were conducted, was the external
testers received one user story test at a time in chronological order from table 8.1,
whereupon no further input was given. This means, the external tester opens the
application for the first time, and immediately receives test 1 in written form to
complete. Hereafter, the external tester will move on to test 2 and so forth. In addition, the think-aloud method was utilised in order for the external testers to express
their thought process throughout the testing of the user stories [18]. Hereafter it
was then noted down whether or not they managed to successfully complete the
user story, alongside useful remarks they provided throughout the testing.
56
Chapter 8. Testing
Test 1
Test 2
Test 3
Test 4
Test 5
Test 6
Test 7
Test 8
Test 9
Test 10
Test 11
Test 12
Test 13
Tester 1
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
Tester 2
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
✓
Tester 3
✓
✓
✓
✓
✓
✓
×
✓
✓
✓
×
✓
✓
Requirement
M1
M1
M1
M1
M2 | S3
M2
M3
M3
M4
M4
M4
M4
M5 | S1
Table 8.2: Results of user story tests
As seen in table 8.2, all the user stories were successfully completed by the external
testers, except for two, and the thought processes of the external users while testing
can be found in the appendix 12.4. As previously mentioned the test results define
whether the program can be defined as successful or unsuccessful. The results
of the conducted user story tests imply that the application can be defined as a
success, as the external testers managed to successfully complete the must-have
requirements previously specified in table 5.3 from chapter 5. The two testing cases
which failed did so on a technicality, and not for lack of ability. The tests that failed
did so due to miss clicks from the tester and upon repeating the tests, the tester
managed to complete them . Additionally, the feedback obtained from these tests
helps identify pitfall areas of the application, according to the external testers.
8.1.2
Feedback
Functionality Feedback
All three external testers encountered issues while testing the functionalities of the
application. Mads had trouble with the "Create task" function in Test 1, where he
mistakenly clicked on the wrong button and had to repeat the process several times.
He also found that the "drag and drop" function did not work under the "Overdue"
status list in Test 4, without realising that this was an intended design decision...
Additionally, in Test 5, Mads discovered that tasks with the same name, assignee,
and start/end date were not differentiated on the GANTT chart, which made it
difficult to distinguish between them.
8.1. User stories
57
Lucas experienced issues with the application when using Firefox in the beginning,
but the issues were resolved when he switched to using Chrome. He encountered
some confusion with the "add assignee" function and wanted to manually input the
dates but found it difficult to do so.
Jesse encountered some issues with the application during the tests. In Test 2,
Jesse suggested that the "Edit" and "Delete" functions could be flipped in order to
evade unintentional task deletions. In Test 3, Jesse attempted to change the status
of a task to "overdue" without changing the deadline, which was not possible, as
the overdue list is designed to contain tasks, which have not been completed before
their deadline. In Test 4, Jesse was unable to drag a task into the "overdue" list
as the end date had not passed, which Jesse found frustrating, and wished that
the overdue list wasn’t hard-coded, such that users could utilise the application
however they wanted. Jesse also encountered a browser-specific error in Test 5 when
a task was double-clicked, which highlighted the word "Logbook" in the navigation
bar, which in turn blocked the ability to change the displayed month. In Test 7, Jesse
clicked on the "Edit" button and found it difficult to exit without either clicking on
"Save changes" or hitting the "ESC" button.
Overall, all three external testers found that the majority of the functions worked as
expected, but there were some issues that could be improved upon to enhance the
user experience.
Visual Impressions / Layout
Mads and Lucas commented on the overall layout and design of the application.
Mads found that the pages were designed in a simple and intuitive manner that
provided a good project and task overview. Lucas thought that the design was clean
and minimalist but felt that the application could benefit from more visual cues to
guide the user, especially when it comes to differentiating between different tasks.
Jesse did not provide any specific feedback on the color scheme or the typography
used in the application but did however experience some difficulties utilising the
application’s functionalities, which potentially could have been improved with
stronger visual cues as Lucas expressed.
General Feedback
As for general feedback, Mads, Lucas, and Jesse all provided valuable feedback on
the application. In general, the external testers found the application to be relatively
intuitive to navigate, the testers were found to be able to understand and utilise
the implemented functionalities. However, all the testers encountered some issues
during their tests. The application was found to be lacking in terms of sufficiently
58
Chapter 8. Testing
guiding the user through the application and its features. Especially the Overdue
list caused confusion among all test subjects, which could have been circumvented
with supplementary visual cues providing additional guidance to the user, on their
first experience using the application. It should be noted, the general feedback
and results from these tests will form the basis of the discussion and future work
chapters.
8.1.3
Conclusion
The external testers passed nearly all the user story tests successfully, as seen in table
8.2, which means the project management website can be called near successful. The
overall feedback was the website was designed in a simple and relatively intuitive
manner, however, the external testers wished for more information to be displayed
for first-time users.
Chapter 9
Discussion
This chapter will investigate the fulfilment of all the MoSCoW requirements created
in chapter 5, and compare them to the test results from chapter 8. Thereby, granting
insights into whether or not specific MoSCoW requirements have been fulfilled. In
addition, the understanding of potential improvements to the application based
on the feedback will be discussed. Furthermore, a discussion of what extent the
problem definition created in chapter 4 has been successfully fulfilled or not, will
be done throughout the chapter. Thus, determining if the problem statement has
been successfully answered.
59
60
9.1
Chapter 9. Discussion
Fulfillment of requirements
The following tables illustrate whether the requirement has been deemed fulfilled or
not, with a ✓ for success, and a × for non-success. Whether or not the requirements
have been successfully fulfilled has been based on the results of chapter 8.
✓/×
M
Must-have requirements
M1
Kanban Board
✓
M2
Time Schedule
✓
M3
Task details
✓
M4
Logbook
✓
M5
Navigation between functionalities
✓
Table 9.1: Fulfillment of MoSCoW Must-have requirements
The fulfilment of the Must-have requirements, which include the Kanban Board,
Time Schedule, Task Details, Logbook, and Navigation functionalities, were deemed
essential for the project management solution to be a success. These requirements
are considered essential because they form the core functionalities of the project
management website, providing the basic functionality necessary for managing
tasks between teams, time scheduling, and project planning resulting in a greater
overview.
Overall the testing results of the must-have requirements were successful. Showcasing the required functionalities for a successful application was found to be
correctly implemented and working. However, the application was found to have
some pitfall areas, which complicated the user experience for first-time users. The
only requirement that was not universally successful was Tests 7 and 11 which were
both failed by the same external tester 8.1.1. Hence, the application was found to
be slightly insufficient in terms of guiding first-time users successfully through the
application. Therefore, additional guiding functionalities would have improved
the overall user experience and caused less confusion for the end user. Overall the
testing of the Must have requirements was deemed successful which indicates that
the solution meets the basis of the intended objectives from the problem definition
in chapter 4.
61
9.1. Fulfillment of requirements
✓/×
S
Should-have requirements
S1
Backlog
✓
S2
Synchronous collaboration
✓
S3
Synchronisation from Kanban Board to GANTT & Backlog
✓
Table 9.2: Fulfillment of MoSCoW Should-have requirements
The fulfilment of the Should-have requirements, which include the Backlog, Synchronous collaboration, and Synchronisation from Kanban Board to GANTT &
Backlog, was not deemed essential for the project management solution to be a
success. However, would improve the overall application significantly if they were
implemented. These features would improve the efficiency of the project management process by enabling teams to work together in real-time, alongside seamless
synchronisation between the functionalities. In addition, the backlog enables the
end users an additional way to view their tasks in an organised table, giving a clear
overview of ongoing tasks which are sorted after their urgency.
Backlog was successfully implemented, and this provides the end-user with a
clear structured deadline tracking which helps ensure teams identify and focus
on the most important unfinished tasks at hand. Allowing teams to understand
which tasks to focus on, and which members are accountable for potentially exceeded deadlines, and progress of the project. Furthermore, to help the end-users
to collaborate effectively, synchronous collaboration enables multiple users to simultaneously use the application, with real-time updates for all users. In addition, the
synchronisation of tasks extends from related functionalities as seen in S3.
Overall the testing of the Should have requirements were deemed successful which
indicates that the solution has improved beyond the fundamental requirements
of the application, specified in the must-have requirements. Thereby, further incorporating features beyond the fundamental requirements found in the problem
definition in chapter 4.
62
Chapter 9. Discussion
C
Could-have requirements
✓/×
C1
GANTT Calendar Export
×
C2
Login
×
Table 9.3: Fulfillment of MoSCoW Could-have requirements
The fulfilment of the Could-have requirements, which include the GANTT calendar
export, and Login, was not deemed essential for the project management solution
to be a success. However, would be desirable if it was possible to implement them.
These features would allow users to easily export the GANTT on the website to their
own desired calendar. Meanwhile, login would add security to the website, ensuring
only team members with the login can make changes to the application. However,
due to the time frame of the project, these features have not been implemented in
the final version of the application. Hence, these features would be in consideration
for future works regarding the application
✓/×
W
Will-not-have requirements
W1
User accounts
×
W2
Chat communication
×
W3
Push notifications
×
Table 9.4: Fulfillment of MoSCoW Will not have requirements
Finally, the Will-not-have requirements, which include User accounts, Chat communication, and Push notifications functionalities, were intentionally excluded
from the project scope. These features were considered non-essential to the project
management system’s core functionality and were, therefore, not included in the
project’s development.
The user accounts would have allowed the end-users to create their own individual
accounts, instead of having to utilise the assignee option which was implemented
instead. However, with the implemented features of functionalities, the option of
being able to specify the assignee manually was deemed sufficient for this project.
In addition, user accounts would have allowed for more user-specific features to be
implemented in the future. Furthermore, the chat communication was not deemed
essential, as the main focus was to make a simple project management tool, and
therefore, the focus was on the aforementioned must-have requirements. The push
notification feature would allow end-users to receive updates and reminders, how-
9.2. Conclusion
63
ever, the feature of a backlog was deemed to handle this sufficiently in terms of the
clear overview it provides. Therefore, these features would be in consideration for
future works regarding the application.
Overall the application has been deemed a success. However, the application
could have benefited from better planning before the commencement of implementation. Better planning would have allowed the presented application to avoid
having numerous nested functions, which resulted in difficulties in testing and
would prove potential challenges in the case of scalability.
9.1.1
Fulfillment of problem definition
In chapter 4 using the problem definition which was based on the problem analysis
in chapter 3, the following problem statement was created:
How can a web-based project management tool be created, in order to
ensure accountability, and time management for student group projects?
As seen in table 9.1, all the must-have requirements have been successfully fulfilled,
therefore, the application can be classified as a success. Additionally, all of the
should-have requirements seen in table 9.2 have also been deemed successful and
improved upon the base program with additional functionality that is non-essential
for the end product. The could-have requirements were not deemed successful, as
they were not implemented in the end product due to the scope and time frame of
the project. The same reasoning can be found for the will-not-have requirements,
which were intentionally left out from the start, but would still improve upon the
overall functionality of the application.
It should be noted the application fulfils all the must-haves and therefore can
be classified as having successfully answered the problem statement. In addition,
all the should-have requirements being fulfilled resulted in an overall improvement
to the end product.
9.2
Conclusion
In conclusion, this chapter discussed the successful fulfilment of the problem definition created in chapter 4 by comparing the MoSCoW requirements made in chapter
5 to the test results from chapter 8. The fulfilment of must- and should-have requirements have all been successfully fulfilled as seen in table 9.1 and 9.2 respectively.
Meanwhile, none of the "could" or "will-not" have been fulfilled successfully. The
fulfilment of the should-have requirements has resulted in an overall better end
64
Chapter 9. Discussion
product. Overall the must-have requirements have been successfully fulfilled, hence,
the solution meets the objective of the problem statement.
Chapter 10
Conclusion
Managing group projects can be challenging for students, especially when it comes
to coordinating tasks, keeping track of deadlines, and ensuring that everyone contributes sufficiently. Therefore, the aim of this project is to answer the following
problem statement to assist students with this issue:
How can a web-based project management tool be created, in order to
ensure accountability, and time management for student group projects?
To develop a solution which could be considered to answer the problem statement
successfully, MoSCoW requirements were created. In addition, it was also taken
into consideration how to make the solution simple and intuitive to use. Therefore,
the delimitation of functionalities to be implemented was hierarchically structured
after importance, and those fitting the time frame and scope of the project have
been successfully implemented in the application.
All the must-have requirements have been fulfilled to ensure the solution can
be considered successful. These consisted of a Kanban board, time schedule, task
details, logbook, and navigation between functionalities. Furthermore, Server-Sent
Events have been implemented in order to achieve a synchronous collaborative experience for all users. In addition, a backlog and synchronisation from Kanban Board
to GANTT and Backlog has successfully been implemented which further improves
the solution beyond the must-have requirements. Although the application has
been considered successful, better planning would have led to an overall improved
product for users, and an easier time implementing and testing the program. User
story tests showed that external testers found the solution to be designed in a simple
and intuitive manner, however, expressed a wish for a more guided experience for
first-time users.
65
Chapter 11
Future works
This chapter contains the improvements which could be implemented to the solution in the future. Although the solution was successful, it would benefit from
fine-tuning and additions of functionalities.
Feedback from the external testers through interviews and user story tests, provided valuable information about the functionalities students found important for a
project management solution. The results of the user story tests revealed that the
solution was successful based on the requirements. However, the user experience
could benefit from additional features.
For instance, the external testers wished for more information to be displayed
for first-time users. This could be achieved through additional information boxes
being displayed, and confirmation messages regarding important decisions such
as deleting or exiting without saving. A tutorial-like experience was also wished
for by one of the testers. It should be noted that it’s difficult to balance finding the
right amount of information to display to the users, in order to sufficiently guide
them through the features, without being too much.
In addition, the could- and will-not have features which were not implemented due
to the time frame and scope of the project, could provide a significant improvement
to the overall application. It should be noted that additional functionalities, outside
the scope of the MoSCoW requirements, could potentially also have improved the
quality of the application.
67
Bibliography
[1] Judith Ainsworth. “Student-Led Project Teams: Significance of Regulation
Strategies in High- and Low-Performing Teams”. eng. In: Journal of Management Education 40.4 (2016), pp. 453–477. issn: 1052-5629.
[2]
Atlassian. Jira Software. Available at https://www.atlassian.com/software/
jira (Accessed 02.09.2023).
[3] louis chatriot. NeDB. Available at https://github.com/louischatriot/nedb
(Accessed 06.04.2023).
[4] Nadja Damij and Talib Damij. “An Approach to Optimizing Kanban Board
Workflow and Shortening the Project Management Plan”. In: IEEE Transactions
on Engineering Management (2021).
[5] Cambridge Dictionary. Backlog definition. Available at https://dictionary.
cambridge.org/dictionary/english/backlog (Accessed on 09.03.2023).
[6] Ana-Maria Dinu. “Project Risk Management - Reasons Why Projects Fail”.
eng. In: Calitatea 17.S3 (2016), pp. 208–208. issn: 1582-2559.
[7] David Flanagan. JavaScript: The Definitive Guide. Seventh Edition. (section
15.11). O’Reilly Media, Inc., 2020.
[8] OpenJS Foundation. Express Fast, unopinionated, minimalist web framework for
Node.js. Available at https://expressjs.com/ (Accessed 08.04.2023).
[9] GANTT. What is a Gantt chart? Available at https://www.gantt.com/ (Accessed 20.12.2022.
[10]
Jette Egelund Holgaard et al. Problembaseret læring og projektarbejde ved de
videregående uddannelser. 2021.
[11]
Doist Inc. Organize your work and life, finally. Available at https://todoist.com
(Accessed 02.09.2023).
[12]
Jestjs.io. Jest. Available at https://jestjs.io/ (Accessed 20.04.2023).
[13]
Swapnil Kangralkar. Types of Biases in Data. Available at https://towardsdatascience.
com/types-of-biases-in-data-cafc4f2634fb(Accessed 12.03.2023). 2021.
69
70
Bibliography
[14]
Andrew Maier. Psychology of web design. 1st edition. Smashing Media GmbH,
2012.
[15]
John Mitchell and Hugo Slim. The bias of interviews. Available at https://
www.iied.org/sites/default/files/pdfs/migrate/G01370.pdf(Accessed
12.03.2023). 1991.
[16]
MongoDB. MongoDB Developer Center. Available at https://www.mongodb.
com/developer/ (Accessed 06.04.2023).
[17]
MongoDB. NoSQL vs. SQL Databases. Available at https://www.mongodb.com/
nosql-explained/nosql-vs-sql (Accessed 16.04.2023).
[18]
J. Nielsen. Thinking Aloud: The #1 Usability Tool. Available at https://www.
nngroup.com/articles/thinking-aloud-the-1-usability-tool/ Accessed
20.04.2023.
[19]
nTask. nTask - Best Project Management Software for Modern Teams. Available at
https://www.ntaskmanager.com/ (Accessed 02.09.2023).
[20]
ProductPlan. MoSCoW Prioritization. Available at https://www.productplan.
com/glossary/moscow-prioritization/ (Accessed 17.11.2022).
[21]
Max Rehkopf. User stories with examples and a template. Available at https:
//www.atlassian.com/agile/project-management/user-stories Accessed
20.04.2023.
[22]
Techtarget.com. UnitT esting. Available at https : / / www . techtarget . com /
searchsoftwarequality/definition/unit-testing (Accessed 24.04.2023).
[23]
Markus Weinmann, Christoph Schneider, and Jan Brocke. Digital Nudging.
Available at https://doi.org/10.1007/s12599-016-0453-1. pages: 433-436.
(2016).
Chapter 12
Appendix
12.1
Analysis of existing solutions
12.1.1
Jira
Kanban Board
Figure 12.1: Jira - Kanban Board
Kanban boards are in this case the overview of created tasks. As seen in figure 12.1,
these are found within a subsection of the tiled interface. Through tasks, assignees
can be attached, along with file attachments, child issues, and link issues. Jira
allows for the incorporation of app extensions, more on that later, which can further
interact with issues through this board menu.
Time Schedule
71
72
Chapter 12. Appendix
Figure 12.2: Jira - Time Schedule
Roadmaps, as the program calls them, are the overview of tasks with respect to
time. A time management tool if you will. Start and end dates for the completion
of tasks are mutable, as well as the ability to link issues throughout each. Filtration
of visible tasks, overlaying either daily, weekly, monthly, or quarterly overview of
scheduled issues to handle.
Backlog
Figure 12.3: Jira - Backlog
Finding the issues which require immediate attention is something which is possible
through the backlog tab. From this functionality, each remaining issue is visible,
but importantly, the backlog of issues is separated into its own category.
Task Details
12.1. Analysis of existing solutions
73
Figure 12.4: Jira - Task Details
Task details provides detailed information of a task as seen, in figure 12.9. The
details include a heading and the current category the task is under, and a task
description. It allows for the addition of attachments, links to the issue and the
creation of child issues if needed to further detail the task. In addition, the task
details provide a comment section, so members have a way to communicate with
one another regarding the task. Jira also allows for the task to be assigned to a
member(s), which is displayed in the task details.
Project Settings
Figure 12.5: Jira - Project Settings
Jira possess many various project settings as seen in figure 12.5. It is possible
to name and categorise a specific project under the details tab. The access tab
under this project settings makes it possible to edit the accessibility of members
by adjusting their roles, while also being able to invite additional members. Jira
makes it possible to enable automatic notifications through e-mails when certain
tasks are completed or updates on tasks are made such as for example comments.
Through the project settings, it is also possible to enable or disable certain features,
74
Chapter 12. Appendix
such as the roadmap or backlog. It is also possible to customise the board from
project settings. In addition, this would also be where you could adjust the apps
connected to the project.
Figure 12.6: Jira - Push notifications
Jira’s notification system is highly customizable and offers a wide range of tools
for team members to receive updates on the status of their tasks and projects. In
addition, to push notifications and emails, Jira also offers the option to receive
notifications via SMS, HipChat, Slack, and other popular communication tools.
Team members can choose to receive notifications for specific events, such as when
a task is assigned to them when a deadline is approaching, when a task’s status is
changed, or when a comment is added to a task.
75
12.1. Analysis of existing solutions
Jira
Assignments
✓
Time schedule
✓
Kanban Board
✓
Backlog
✓
Task details
✓
Logbook
×
Project settings
✓
Push notifications
✓
Projects overview
✓
Table 12.1: Functionality Matrix - Jira
Project Overview
Figure 12.7: nTask - Project Overview
The main page, after signing in, is a project overview as seen in figure 12.7. There is
a view of unstarted, ongoing, and finished projects or the ability to create new ones.
There is also a basic view of how many sub-projects, tasks, issues and members
there are connected to each project.
Board
76
Chapter 12. Appendix
Figure 12.8: nTask - Kanban Board
As seen in figure 12.8, there is an overview of all tasks and labels containing information about them. The are some basic labels on the page, which show the
progress, priority, status, title, ID and planned ending of the tasks. There is the
ability to add many more labels and the ability to colour code each task. Another
feature on this page is the ability to search tasks using either a search function or by
applying filters. The search function searches for the ID and title of tasks, whereas
the filter option allows for a multitude of filters that sort by the labels of tasks. It is
also possible to use these two options in conjunction.
Task Details
Figure 12.9: nTask - Task Details
The task details page, in figure 12.9, contains all of the information pertaining to the
individual task. It allows for the detailed viewing and setting of a vast amount of
options such as time schedule, member assignments, log times, meetings, priority,
and issues, plus the ability to add additional custom options. It also contains a chat
function, and the ability to add documents and adding to-do list items.
12.1. Analysis of existing solutions
77
78
Chapter 12. Appendix
Project Settings
Figure 12.10: nTask - Project Settings
Further functionalities on nTask include the ability to change project settings, as
seen in figure 12.10. Immediately upon entering the settings function, one will
notice that the general information tap has very little to offer besides the option to
upload a photo. Supplementary features include the roles and permissions tap, in
which the team owner is able to change team roles and their respective permissions.
Finally, users are also able to direct themselves towards the task status tap, where
team members can see the current status of assigned tasks.
nTask
Assignments
✓
Time schedule
✓
Kanban Board
✓
Backlog
×
Task details
✓
Logbook
×
Project settings
✓
Push notifications
×
Table 12.2: Functionality Matrix for nTask
12.1. Analysis of existing solutions
12.1.2
79
Todoist
This subsection will feature an analysis of the functionalities available in the existing
project management tool [11], the analysis is done on 02/09/2023, and the web and
software application may have been updated since then. This analysis will be based
on the functionalities found in the free version of Todoist the scope is limited to the
functionalities relevant to project management. Todoist is a software application
and web page that aids individuals and teams to become more organised, in their
personal life or in the workplace.
Project overview
Figure 12.11: Todoist - Project overview
When initially signing in to Todoist the user is presented with the project’s overview
that can be seen in figure 12.11. Projects which the user is a part of show up in this
tab, giving the user a brief overview of the current projects that are being worked
on. The user is able to create additional projects from this screen, in addition, the
user can invite members to be a part of their current projects, delete projects and
click on one of their current projects and be presented with the board of that project.
Kanban Board
80
Chapter 12. Appendix
Figure 12.12: Todoist - Board
The board seen in figure 12.12 can be seen as a notice board. The board includes
an issues/tasks manager, which lets the user create different relevant lists, that
contains user-created tasks. The issues can be assigned to specific project members,
in addition, tasks can be set to different priorities, letting team members know
which tasks are the most important in hand, priorities are shown with colour or
by showing issue details. More options are available when setting up issues. The
user is able to set specific start and end dates for each issue, while also being able
to enter the actual end date for issues.
Time Schedule
Figure 12.13: Todoist - Time Schedule
Todoist also features a time schedule, which can be seen in figure 12.13. The time
schedule is much like the notice board, showing issues related to a user’s projects.
The time schedule shows the specific dates that issues are due to and their priority.
The user is also able to add additional tasks to the specific dates for themselves or a
project that they are a part of. The user is also able to apply filters, for which issues
12.1. Analysis of existing solutions
81
they want to be shown. The filters let the user be presented with issues related to a
specific project, the task’s priority or issues that are set to be completed by a specific
member of the project.
Assignment
Figure 12.14: Todoist - Assignment
Assignments can be viewed individually giving the user more options, as seen in
figure 12.14. Assignments can as previously mentioned be set to be completed by a
specific team member. Each task can also be given a specific label so that it is easier
to sort tasks.
From this analysis it can be concluded that Todoist is a project management tool,
with many features related to project management. The tool lets project members
organise their workplace and gain an overview of their workflow with smart
functionalities, like assignments and a notice board. An extract of the functionalities
found in Todoist can be seen in table 12.3. A full list of the analysed software
application features can be found in the functionality matrix(table) 3.2.
82
Chapter 12. Appendix
Todoist
Assignments
✓
Time schedule
✓
Kanban Board
✓
Backlog
×
Task details
✓
Logbook
Push notifications
×
×
×
Projects overview
✓
Project settings
Table 12.3: Functionality Matrix - Todoist
12.2
Interview
12.2.1
Interview Questions
1. Personal Information for Credibility
• 1. Name
• 2. Age
• 3. Academic status (major/semester/study)
2. Collaboration Tools and Software
• 1. What collaboration tools do you use for group projects?
• 2. Have you ever encountered any challenges or limitations with these?
• 3. What software solutions/functionalities do you wish existed, which could
help during your group projects?
3. Group Project Management
• 1. How do you typically divide tasks and responsibilities among group
members?
• 2. What methods do you use to track progress and manage deadlines?
4. Group Dynamics and Success Factors
• 1. What steps do you take to ensure that everyone in the group is contributing
equally and effectively to the project?
12.2. Interview
83
• 2. What do you think are the key factors that contribute to a successful group
project?
• 3. Have you ever experienced difficulties during a group project, and if so,
which tools do you believe could have helped with it?
5. Personal Experiences and Reflection
• 1. Have you experienced any personal difficulties or challenges during group
projects, such as time management or communication issues?
• 2. How do you reflect on your group project experiences and what have you
learned from them?
– Do you believe a logbook helps with reflecting on group projects?
6. Open question
• 1. In relation to tools for group projects, is there anything you would wish to
add?
12.2.2
Elisa Interview
Simon (interviewer):
If you could state your name, age and field of study.
Elisa (participant):
My name is Elisa, I am 21 years old and I’m currently on my 6th semester on my bachelor’s
in economics and business administration.
Simon (interviewer):
Thank you. What collaboration tools do you use for group projects?
Elisa (participant):
Usually, we use google drive or word has a collaboration kind of thing that we use as well,
we use overleaf and then in general we also use stuff like GANTT charts to keep the overview
of projects.
Simon (interviewer):
Have you ever encountered any challenges or limitations with these?
Elisa (participant):
Google drive has a lot of limitations when it comes to the math side of stuff, like the equations
you don’t really have the most evolved equation mechanism in google docs and stuff. The
same with word, they have a lot of issues with WordMat when you’re collaborating in
a document, if another person has created a math field you can’t go and edit in it, like
change stuff or delete stuff in the math field, it’s only the person who created it who can
actually go and change stuff, which is very annoying. And then overleaf usually has a very
steep learning curve and not everyone is dedicated to learn how to use the program very
84
Chapter 12. Appendix
sufficiently so it takes a lot of time and effort to get to the level where you can actually
collaborate in it sufficiently and if you’re not really into the coding stuff people usually just
give up and use docs or drive or whatever instead.
Simon (interviewer):
So are there any software solutions that you wished existed which could help you during
your projects?
Elisa (participant):
Like I was thinking about like a three in one solution that both has a calendar to do list
with a GANTT chart with the deadlines and then a disposition overview, like the skeleton
of the project that gets ticked off every time a point is done which is synced to each other
and can also be loaded into google calendar or outlook or whatever you use so you can
personally plan around the project as well. It would also be great if you could assign people
or yourself through the program so others in the group easily could see what you’re working
on currently without having to send a message and check up on: “Hey what are you doing
right now?”. So that would be pretty cool if you could have like a three in one solution.
Simon (interviewer):
How do you typically divide your tasks and responsibility amongst group members?
Elisa (participant):
Usually based on skill and interest mostly, also availability of course depending on the
deadline because if one member can’t work on the project for a few days due to something it
maybe isn’t good that they’re assigned to a task that has a deadline inside the timeframe they
can’t really work on it, so they will then be assigned to other work that fits their schedule
more but usually it’s based on skill and people are very good at saying “Hey I’m very good
at this stuff so therefore maybe I should contribute a lot to this point of the project” and
people are also very good at just letting people do what they’re good at and just giving people
space “So okay you’re good at this, would you deal with it and then we can later look at it
together?”.
Simon (interviewer):
How do you track the progress made these assignments?
Elisa (participant):
Usually with the GANTT chart and the disposition or to do list overview mostly. I personally
use calendar a lot, for me it’s very important to be able to actually visible see that the time
assigned to the task is also doable, to compare to how much time we have to work on it,
which is mostly how I structure through calendar. It’s also a lot easier to get an overview of
how to push things around and change the priorities of stuff and still be able to visible see
that we can actually hit our deadlines. So I usually use the calendar and the GANTT chart
for that.
Simon (interviewer):
What steps do you take to ensure that everyone in the group is contributing equally and
effectively to the project?
Elisa (participant):
12.2. Interview
85
Sometimes we write on each section title who is contributing to what and sometimes we
only just make a title at the end of the paper or the project for example stating who is the
main author of what chapter and who contributed to that chapter besides the main author
and then these get updated as we go through the project and it also makes it a lot easier
to assign tasks to people whose name is not really on the list that often. So in google docs
commenting is also a very useful tool that we use, as you highlight what you want others to
focus on when they’re reading through your work or correcting your work and others can
question and suggest however they feel fit without actually changing the work directly, and
then that way we can also see through the comments who actually read through what they
were supposed to read through and like, correct and stuff and then we just all go through the
comments together and discuss them before making any changes and marking them as done.
Simon (interviewer):
What do you think are key factors that contribute to a successful group project?
Elisa (participant):
Communication, 100% communication and also trusting each other. Usually I have found
that a lot of people don’t trust that others can do certain work to a certain, like, level of
expectations. So you have to be able to trust each other that the work that is being done
is actually good work and up to what we talked about and up to the expectations that we
have, and therefore the need of overlooking what everyone else is doing all the time also gets
taken way. This also minimizes the time spent correcting at the end and lets people also see
their own, like, marks on the work when writing. This results in less interruptions as well if
you’re in the zone when you’re working, so people don’t all the time say “wait what do you
mean by that?”. So just trust each other, and communicate when something is wrong or ask
for help and stuff is very, very important.
Simon (interviewer):
How do you build good trust with people?
Elisa (participant):
How you build good trust with people? Well, that’sSimon (interviewer):
Yeah, I know that’s not on the questions in the document, but I thoughtElisa (participant):
Yeah that’s a good question because, that’s a very personal question. Its very depended on
who you are as a person, some people just trust that whoever they’re working with are doing
a good job and then depending on how the outcome of that is, they can like tend to be like:
“oh I can actually trust that.. I can physically see that and read that what you’re doing is
good and the feedback we have gotten is good on your job so I have now experienced you’re
doing a good job”, and other people need more of the.. you have to earn the trust before you
get my trust, so that is a little bit harder if you’re new to a project with new people, to just
go in blind and be like “okay I can just let off control and just let people do their own thing”.
So, its really depended on what kind of a person you are. But it’s a work in progress all the
time the trust part and people can also break your trust in projects if they don’t do deadlines
86
Chapter 12. Appendix
correctly and stuff. That’s going to, like, affect your professional relationship with them and
your trust with them.
Simon (interviewer): Have you experienced difficulties during group projects? And if so
which tools, do you believe would help resolve those issues?
Elisa (participant):
Yeah, of course I’ve experienced difficulties during group projects. We actually had one
recently where we did everything we could to a certain group member actually contribute to
the project, so showing our professor who contributed in the contribution section at the end
of the project was how we had to do it because it was more, of like, personal difficulties and I
don’t really think there was any tools that could be used to help with it if it was going to
happen again, to be honest.
Simon (interviewer):
So my next question was going to be: have you ever experienced any personal difficulties?
You sort of touched on that there. Have you ever felt time issues or communication issues?
Elisa (participant):
Yeah, that was exactly the issue, like, a person who was living rather far away from the
university was not showing up when we all agreed to meet. Also if we said ”lets meet
on zoom instead because you have a long way of travelling to get here, lets just meet on
zoom and do the work on zoom so you can actually be apart of it” The person would just
completely ignore our messages. The always confirmed that okay we can do it at this time,
but when the time came they never showed up or never, like, read our messages or responded
or anything so yeah, it was a lot of issues with that.
Simon (interviewer):
How do you reflect on your group project experiences and what have you learned from them?
Elisa (participant):
Well you learn a lot about how people, like work, their work types and how you like have
to work around their work types. Usually personally I haven’t been in-. I usually work
with the same people so it’s not like I-. I have slowly learned how the other people in the
group, like work so I take mental notes so that later or on other projects I know how a certain
person likes to do their work and then we can take that into account when planning and
structuring the next project. For example if someone is not very good at working during the
day but likes to sit at night and do their work, then we can trust that because we’ve seen
before that they will get their work done that they’re assigned, they will just do it in their
own time at night, we can structure around that and make sure that everything still get
done till deadlines and stuff. You also very quickly learn who you work well with and how
to, like, who to professionally avoid, if you have the choice to avoid them of course.
Simon (interviewer):
Do you believe keeping track with a daily logbook would help reflect on your group projects?
Elisa (participant):
We actually use it right now for our bachelors because it was something that we wanted to
do ourselves because it keeps us on top of our game-ish, you can say, because everything
12.2. Interview
87
is documented from day to day. It’s also very fun to look back on the process you’ve been
through and read all of the changes and decisions and stuff that you had to make to get your
project to what it ended up being. It also helps a lot with the questions like “what would you
have done differently?” that you usually get or have to answer and stuff after the project.
It’s a lot easier to remember “okay what were we actually going through at these different
points when we were writing the different sections and stuff and doing the different work
on the project. It also keeps people up on their word and their promises from one day to
another so you can write them down in the logbook that tomorrow we have all agreed this is
going to be done and were going to do this and maybe someone has something they need
to prepare for tomorrow, then you can keep each other up on that. So I really believe in
logbooks, because its also fun, in the end, to look back on the process.
Simon (interviewer):
And finally: in relation to tools for group projects, is there anything you would wish to add?
Elisa (participant):
I don’t think so, to be honest.
Simon (interviewer):
Okay. Thank you
12.2.3
Jesse Interview
Maria (interviewer):
So, what is your name?
Jesse (participant):
Jesse
Maria (interviewer):
Your age?
Jesse (participant):
24
Maria (interviewer):
And your academic status?
Jesse (participant):
I have a bachelor in English.
Maria (interviewer):
Which semester is that?
Jesse (participant):
I have a different structure than the normal one. So, I’m doing a bachelor in English and
media studies, right now.
Maria (interviewer):
What collaborate tools do you use for group projects?
Jesse (participant):
I mean at the moment we are forced to use Microsoft Teams, which I’m new to, but its fine.
88
Chapter 12. Appendix
Otherwise, I see people mostly using Google Drive.
Maria (interviewer):
So, you mentioned Teams and Drive. Do you have any challenges or limitations with these?
Jesse (participant):
I mean, I like supplementing with Trello or other tools. I mean, we also have to use a lot
of different tools, but its fine, just using Facebook Messenger to communicate, and then
collecting everything in a Drive folder. That kinda the norm.
Maria (interviewer):
So, its Trello, Drive and Messenger for communication. Are there others, or are that strictly
it?
Jesse (participant):
I mean, for what I have seen, that’s the norm. And we used Zoom in English for the first
semester.
Maria (interviewer):
What software solutions or functionalities do you wish existed, which would help during
group projects?
Jesse (participant):
I mean, I like when everybody has a proper overview of what happening, and I do think that
kinda lacking, with the go to sites that people use. I like using Drive, I use it all the time to
keep my text in order, but when you’re during a group project, it’s kind discussions that you
want an overview of. And I think Trello is kinda fine, but again people have a hard time
getting introduced to new platforms, so they have to look really simple to use. I remember in
primary school, we used Prezi, which were great and so much better than Powerpoint, but
now we are using Powerpoint, which kinda sucks.
Maria (interviewer):
How to you typically divide tasks and responsibilities amongst group members?
Jesse (participant):
I mean, of course that depends on the project and we do talk about like the different roles
there needs to be, but its always just like a feeling, like people just do what they wanna do,
and they leave so responsibility to one person in the group or a couple of people, so I don’t
really know if you can say that we keep the roles.
Maria (interviewer):
So voiceless democracy?
Jesse (participant):
I mean, its different from person to person, how seriously they take it and whether they
wanna have a talk about different roles or whether they just wanna do their part and then
do all of the roles at the same time. But I prefer organising stuff and during the secretary,
director, writer work or editing. Anything that has influence.
Maria (interviewer):
What methods do you use to track progress and manage deadlines?
Jesse (participant):
12.2. Interview
89
I mean, from what I have experienced that the projects here is just talk and then we write it
in our calendar. The most planning I have seen is just a person making a Docs document,
where I set up a Trello to do a bit more structured or simple overview, because I thought that
the Docs document was a bit long and confusing, so I wanted to divide it up.
Maria (interviewer):
You wanted overview?
Jesse (participant):
Yes, but they did just write up all of the dates, where people could meet, and then we mostly
talked about it, we didn’t really go that much back to the document and correct it.
Maria (interviewer):
So, it is upkeeping that’s a problem as well?
Jesse (participant):
I mean, it can easily be fixed, but its also just so individual people like to do or want they
can manage to do.
Maria (interviewer):
What steps do you take to ensure that everyone in the group is contributing equally and
effectively to the project? Jesse (participant): I mean, that is what I always tries to do.
I think its difficult, again depends on whether people want to communicate or like what
people expecting from the project. I always try to open up conversations, which is difficult
sometimes, but is important. Sometimes people just have a hard time getting to a place in
the project where they can form ideas, and I like to provide them with things like, a frame,
suggestions or anything that get them in a place where they are thinking about it.
Maria (interviewer):
What do you think are the key factors, that could contribute to a successful group project?
Jesse (participant):
You can do different work and different amount of time and energy into it, and still contribute
in a meaningful way, but this requires communication.
Maria (interviewer):
If you could think of a tool or functionality or something else to help with a better project?
Jesse (participant):
Again, that’s super individual what people need to get motivation.
Maria (interviewer):
What do you need?
Jesse (participant):
I have always known to do the stuff I need to do and keep myself motivated and have an
overview of things.
Maria (interviewer):
So self-regulation is not a problem for you?
Jesse (participant):
I’m over self-regulated. I do a lot of work to do less work. I constantly manage everything.
Maria (interviewer):
90
Chapter 12. Appendix
Have you ever experienced any personal difficulties or challenges during group projects,
such as time management or communication issues?
Jesse (participant):
Of course, time management was a problem, in the first project I was in, and also communication, because every time there was a problem, communication is the foundational problem
behind it, and it was also like that at that time. It was communication one way but not the
other way. The project got postponed because of that and we had to do a lot of work in the
end. So yes definitely.
Maria (interviewer):
Reflecting on that, what have you learn from that?
Jesse (participant):
I have learned that, when I have a good feeling that somebody isn’t able to actually do what
they need to do, or like able to write something that can be put in the paper, for example you
should just accept it and do the extra work, it doesn’t help trying to help the other person,
that suck because I wanted to be like that, but its just extra work, when you could just do it
by yourself. And that sucks to learn that, but that is the education you’re during, self-study,
there is no help. If you’re in a group, it can be an advantage or a disadvantage.
Maria (interviewer):
Following that again, do you believe that keeping a logbook could help reflecting on these
group projects?
Jesse (participant):
Yes of course. This is a part of the communication and keeping track of what you’re doing,
assignment and all of that.
Maria (interviewer):
In relation to tools in group projects, is there anything you wish to add? Other than
overview, time management and assigning things?
Jesse (participant):
I mentioned Trello, if I could introduce people to that, I think that it might help us.
Maria (interviewer):
Definitely, so easy overview and ease of capability, that is important to you? Like visually
its easy to understand what is happening?
Jesse (participant):
I mean yes of course but if its just for me and I don’t have to think about how easy it is
to understand for others, then I like that I can tweak everything. Like for example Adobe
Premier Pro I can adjust all the sizes, I can adjust how the screen looks, and how I want it.
Maria (interviewer):
So, mutability is high?
Jesse (participant):
Yes
Maria (interviewer):
I would like to thank you for participating in this interview.
12.2. Interview
12.2.4
91
Rasmus Interview
Maria (interviewer):
Now, let’s start of with your name?
Rasmus (participant):
My name is Rasmus
Maria (interviewer):
And you are how many years old?
Rasmus (participant):
23, at this time
Maria (interviewer):
And your academic status?
Rasmus (participant):
Currently a student in second semester.
Maria (interviewer):
What collaborate tools do you use for group projects?
Rasmus (participant):
Well, collaboration tools is sort of a wide subject, but the classically considered tools would
be Trello, but for communication we just use Discord.
Maria (interviewer):
Have you encountered any challenges or limitations with the use of these?
Rasmus (participant):
I mean getting to know them of course, but not really no.
Maria (interviewer):
So, what software functionalities or solutions do you wish existed which could help during
group crisis, for instance?
Rasmus (participant):
Group crisis. . . probably easier access to notification. I don’t check my mail that often. And
if all notifications happen over mail I think it presents a problem to some degree.
Maria (interviewer):
So notifications or something to inform you of what’s happening and what’s needed?
Rasmus (participant):
I mean, if you’re doing daily sessions it’s nice to get daily notifications of deadlines or new
additions to the time plan or something like that.
Maria (interviewer):
How to you typically divide tasks and responsibilities amongst your group members?
Rasmus (participant):
Sort of randomly. We just say, we need this done, who wants to do it?
Maria (interviewer):
92
Chapter 12. Appendix
And you think this is fair? This functions adequately?
Rasmus (participant):
Well, absolutely not, because you know. . . some people take more responsibility than others.
Maria (interviewer):
So what do you use to track progress amongst members?
Rasmus (participant):
Oh, we don’t really have a progression tracker, but on Trello you can see who is signed to
what task, and furthermore on GitHub you can see who submits code at what point.
Maria (interviewer):
What steps do you take to ensure that everyone in the group is contributing equally and
effectively to the project?
Rasmus (participant):
No steps. According to our group contracts we personally just give our all to the project. So
we assume that is enough to get people motivated.
Maria (interviewer):
Has that ever failed?
Rasmus (participant):
Yes, because not everybody is equally motivated, so the contribution to the project is of course
always of free volition, but not everybody is willing to do the same amount of work.
Maria (interviewer):
What do you think are the key factors, that could contribute to a successful group project?
Rasmus (participant):
Motivation definitely. I think task distribution is of course another good one, but if you get
distributed a task which you don’t really want to do you’re not going to perform as well, so I
think in the end efficient distribution matters less than the motivation.
Maria (interviewer):
How do you ensure efficient distribution?
Rasmus (participant):
I mean, more or less equal distribution is essentially. . . or especially when it comes to the
code part because everybody is collaborating in the code and we also usually run through
the code together.
Maria (interviewer):
Have you ever experienced difficulties during a group project, and if so what tools do you
believe would help with that?
Rasmus (participant):
Well I think previously we’ve been a bit loose on deadlines, so it would be advantageous to
have them easily accessible.
Maria (interviewer):
Mutable perhaps?
Rasmus (participant):
Yeah
12.2. Interview
93
Maria (interviewer):
So a like a overview, or like a roadmap if you will, that would be something you think would
help?
Rasmus (participant):
Yes definetily.
Maria (interviewer): Have you ever experienced any personal difficulties or challenges
during group projects. Such as time management and poor communication issues.
Rasmus (participant):
I suppose I’ve already answered that question.
Maria (interviewer):
A little bit yeah. If you have anything more to add though, that be. . .
Rasmus (participant):
No, not really I think.
Maria (interviewer):
How do you reflect on your group project experiences and what have you learned from them?
Rasmus (participant):
Usually I’m very critical of the experience, cause I believe the things that are done well, you
know, there’s no reason to analyse those because they came naturally.
Maria (interviewer):
How do you know they’re done well though, is that personal or. . . ?
Rasmus (participant):
Well in part, but also through the response we get from exams
Maria (interviewer):
So outcome based?
Rasmus (participant): Yeah more or less, but you can also tell like during the process if
you get bottlenecked at some point it’s probably due to bad management.
Maria (interviewer):
Do you believe that logbooks would help, like with the reflection?
Rasmus (participant):
Yeah probably. So we also, you know, in our group look back on previous projects, not only
on P1 but also P0, and throughout our high school time as well to sort of reflect on our
experiences.
Maria (interviewer):
And now for the final question. It’s an open one. In relation to tools for group projects is
there anything that you wish to add?
Rasmus (participant):
Like functions to a tool?
Maria (interviewer):
Anything that you would think would help in group management or project leadership. . .
any of that sort, any of that region?
Rasmus (participant):
94
Chapter 12. Appendix
Well perhaps, instead of having a bunch of different tools, like a note tool for the SCRUM
meetings and a timeline tool like Trello and a communication app like Discord, like sort of
gathered up.
Maria (interviewer):
So you want an amalgamation of tools, one program for all of it?
Rasmus (participant):
Yeah, I suppose most communication could be handled in a different app, but like sort of the
timeline, deadlines, the task assignments in one app, which is easily accessible also regarding
notifications.
Maria (interviewer):
Alright. . . well thank you, thanks for your time.
Rasmus (participant):
No problem.
12.3
Other
Figure 12.15: GANTT
12.4. Testing
12.4
Testing
12.4.1
External tester 1
95
External tester 1: Mads is a second semester student at Aalborg studying something
(FIX) (FIX).
Test 1: Mads looks around the website and notices the blue button labeled "create
task" and clicks on it. Then he randomly fills out the form and tries to add the task,
but mistakenly clicks on the green button labeled "+" because he thought it would
add a task due to the name and color. After nothing happened, he realized there
was a smaller blue button labeled "Add task" and clicked on it. He repeated the
correct process 4 more times. (Maybe the function could automatically close after
input, not sure, just feels natural)
Test 2: Here he first closes the "create task" function and then hovers the mouse over
one of the tasks, where he immediately notices the red button labeled "delete" and
clicks on it. (Maybe have a security question like: "Are you sure you want to delete?")
Test 3: In this test, he already knew where the "edit" button was as he had seen it
during task 2. Then he fills out the form according to the task’s conditions.
Test 4: He follows the task instructions and drags one of the tasks across all
the statuses, where he realizes that the function does not work under the "overdue"
status.
Test 5: Here he starts by going to the Gantt chart, where he only sees one task being
displayed, although there should be 4. Then he goes back to the board and checks
the tasks to see if they all have the same date, which they did. Then he goes back to
Gantt where he can see all the squares clearly. (Make it clear how to differentiate
tasks with the same date inside Gantt)
Test 6: Here he first goes to the board to check the dates on the different tasks, and
then goes to Gantt to verify that everything matches, which it did.
Test 7: Here he goes to the board and clicks on "edit" to see the description.
After doing this for 2 of the tasks, he realizes that he hasn’t tried just clicking on the
task to see if it also provides information. When he tries this, he sees the description
for the remaining 2 tasks.
Test 8: In this task, he goes directly to the board, where he immediately clicks
96
Chapter 12. Appendix
on "edit" under a task, changes the description, and finally clicks "save changes".
Test 9: He looks up at the top of the website and sees the title "logbook" and
clicks on it. Then he selects "new logbook" and creates a new one. After creating
it, he goes into it and fills out the "header" and "paragraph" and then clicks "add
entry" and finally "save logbook". After this, he tries to go back to the main page
under "logbook" but instead of clicking on "close logbook", he chooses to click on
the title "logbook" at the top of the website. He repeats this process one more time.
Test 10: Here he clicked on the title "logbook" at the top of the website and clicked
"delete" on the top logbook. (Maybe have a security question like: "Are you sure
you want to delete?")
Test 11: He goes to "logbook" and opens the only one that is there. Then he
creates a "header" and a "paragraph" which he saves and then deletes.
Test 12: Here he went to logbook and selected the top logbook, then he selected
"header" in the top entry and changed both the header and the "paragraph" and
finally clicked on "save changes".
Test 13: He started by going to the board to check the end dates on all the tasks he
had in "To-do", "Doing", and "overdue". Then he went to the backlog and saw that
everything matched as it
After Mads had conducted the test, we had a discussion about general thoughts
on the application. Overall, Mads found that the pages were designed in a simple
and relatively intuitive manner, while still providing the user with a good overview.
Many functions worked as expected, but Mads encountered issues during test
5 where a problem was discovered. Tasks with the same name, assignee, and
start/end date were not differentiated on the GANTT chart. General thoughts
that Mads had during the tests can be found in parentheses under the tests. We
discussed that the page could potentially include more information for users when
they first use the page, so that they can better understand the program.
12.4.2
External tester 2
External tester 2: Lucas is a fourth semester computer science student at Copenhagen University. At the beginning Lucas was using Firefox, and this caused issues
with the website regarding its functionalities. He swapped over to chrome and the
issues were no longer there.
Test 1 On the Kanban Board, you want to create five new tasks.
12.4. Testing
97
Lucas looks around and clicks the create task button. He looks at the form, which
he then fills out from top to bottom. He created the clicks on the add task and then
begins to write a new one and with this one he clicked add task four additional
times. Resulting in four identical tasks being created.
Add assignee is a bit confusing. Make the remaining with new task names and
descriptions. When selecting dates he wanted to write it manually, but this was a
bit difficult and caused incorrect dates to be written. Could be an idea to enforce
the popup of dates when the box is clicked rather than just the icon.
Test 2 On the Kanban Board you want to delete one of the tasks.
He looks at the Kanban Board and started deleting several tasks this was not an
issue.
Test 3 On the Kanban Board, you want to change the assignee, status, and deadline
using the edit button.
He looks around the Kanban Board and then decides to choose one of the tasks
in overdue. He clicks on the task and then clicks the edit button,he systematically
changes each box. However, although he didn’t change the date sufficiently to be
before the current date, which resulted in it still being in overdue. This confused
him, and he tried to edit it again and selected done, which had no issues. The he
tried a task in to-do into doing, which also had no issues.
Overdue seems a bit difficult to comprehend at the beginning. A little information box top right of the overdue task list explaining why it is there might be needed.
Test 4 On the Kanban Board you want to click on one of the tasks and drag
them to another status.
He drags the tasks, but also puts them into overdue as well, and had to figure
out you had to change status manually to move around again. He wanted to keep
moving them around, but when he dragged one of tasks into overdue, he wasn’t
able to drag it anymore. He edited the task to move it again, just like in test 3.
Test 5 On the GANTT you want to make sure that tasks from the Kanban board,
with the statuses: "To-do", "Doing" and "Overdue" are displayed on the GANTT
diagram.
He clicks the navigation to the GANTT. Clicks around with previous month and
next month, and tries to understand how many days it shows. He compares the
two and checks if they align. He opens every task up and checks systemically from
to-do to doing and overdue. Confused as he thought some tasks were missing when
the tasks have the same name, but then he hovered over and realised they were
98
Chapter 12. Appendix
stacked together.
Test 6 On the GANTT page you want to check if the tasks are sorted correctly
after their start-date.
He looked at the first task being displayed on the GANTT chart, and compared it
systematically looking at the start-date. He wanted to have the start and end date,
show when you hover over the tasks. Especially since it displays with two days at the
top, so some information directly could be nice. He also wondered why if they were
in the same category and if they had the same start date, they should be sorted after
length. Furthermore, he wondered if it was possible to sort by category and then
the date. But said it was more of a personal preference and it could maybe be a filter.
Test 7 On the Kanban Board you want to read the task details of two different
tasks.
Clicks on the Board, and chooses two random tasks and reads the task details, he
accidently deleted one by mistake. He wants a trash bin where he has to move them
into or something else to ensure he doesn’t accidentally delete a task, but said this
was more of a personal preference.
Test 8 On the Kanban Board you want to edit the description of a task.
He clicks a task on the Kanban Board, and in the previous tests he wanted to have
description to also have a label when task details was displayed. Therefore, he
clicked the edit button and changed the description where he wrote: Description:
New description. Thereby, he added the description label himself, but he noted this
was more of a personal preference.
Test 9 On the Logbook page, you want to create two new logbook entries.
He uses clicks on Logbook in the navigation bar. He then opens one of the logbooks
and then clicks on the logbook navbar again to go back, then he looks around and
then clicks to create a new logbook.
Test 10 On the Logbook page, you want to delete a logbook entry.
He keeps clicking on the navbar to return to the main logbook page, he doesn’t
click the close logbook. He then deletes the newest created logbook entry.
Test 11 On the Logbook page, you want to open a logbook entry create and then
delete a header and description.
He opened one of the logbook entries and then created multiple different headers
and entries, and deleted a few of them. He thought that checking all the head+p
would be a mass delete. He then clicks the save logbook, but was unsure if it
12.4. Testing
99
actually saved and said it would be nice if there was a popup to say the logbook
had been saved.
Test 12 On the Logbook page you want to edit a header and paragraph save
them He open one of the logbook entries and edits them, and then changes them
and saves the logbook. He accidentally deleted the logbook, and couldn’t check if it
saved. He did it again. And it saved.
Test 13 On the Backlog you want to make sure that tasks from the Kanban board,
with the statuses: "To-do", "Doing" and "Overdue" are displayed sorted after end
date.
He navigates correctly to backlog, and compares the dates to see if the align.
However, he wondered why it was in year-month-day rather than the usual layout
as seen in the previous functionalities on the website.
12.4.3
External tester 3
The testee, Jesse, is a sixth-semester English student at Aalborg University and was
of those originally interviewed in 12.2.3.
The testee was given a URL to enter and they were then handed the first testing
parameters.
Test 1 Upon reading the instructions, the testee began by immediately opening the
"Create task" form. Filling out the yet-to-be-created tasks’ name and description,
stopping briefly at the assignee selection, picking the testing supervisor’s name,
and then proceeding to fill out the rest of the form. The remaining four testing
tasks were quickly completed. Later, when asked about the brief pause during the
assignee selection, the testee replied with a lack of wanting to change the existing
parameters. Meaning the existing examples confused, rather than helped.
Test 2 This was no issue, the user did however exclaim the want for the buttons to be "edit" and "delete" functions to be flipped.
Test 3 This test was done equally without issue. However, upon retrying this, the
user attempted to change the status to Overdue, without changing the deadline. As
the user attempted to change the status to overdue, however, they were unable to. After think for a moment, they realised overdue was related to the deadline of the task.
Test 4 The task moved was the newly user-created task "Task 1". As the user
had created this with a set end date of later than the date, they were unable to drag
the task into the "Overdue" box. Once other boxes had been attempted, the user
100
Chapter 12. Appendix
proclaimed that this inability to interact with the Overdue box, without the end
date having been passed, although understandable, was "stupid".
Test 5 Because the task creation form expands the vertical size of the website,
the navigation bar was not initially visible during this test. The testee quickly
sussed this out and clicked the correct field. Once again, the existing example
created some confusion in that they do not have set periods in which they should
be performed. The user then revealed an unintended browser-specific error. When
a task is double-clicked, the cursor highlights the word Logbook in the navigation
bar. When using Edge, highlighted words often reveal a definition at the bottom of
the browser window.
Blocking the ability to change the displayed month.
Test 6 The only one looked at was the previously mentioned "Task 1" task, as
the task had an end, and start date, known to the user. The dates matched, and the
testee then asked whether it was possible to filter out the various statuses. As it is
not, the testing continued onwards.
Test 7 The navigation was quick, but upon attempting to view task details, the user
clicked on the edit button. This prompts the edit modal to be displayed, and cannot,
much to the dismay of the tester, be exited without either clicking on "save changes"
or by hitting the "ESC" button. The description being visible during the editing
procedure, meant that the test user did not intuitively understand that clicking the
task itself expands it.
Test 8 Due to the prior test, the user was familiar with this functionality and
fulfilled its requirements dutifully.
Test 9 Navigation is become second nature and is quickly over and done with.
On the logbook page, the testee proceeded to create two new logbooks and considered the test to be done. Never once actually creating a new entry within the
created logbooks.
Test 10 asks for the deletion of a logbook entry. This was done immediately
and without qualms or hardships.
12.4. Testing
101
Test 11 The operation was navigated successfully, however, the testee did not
click on the "save logbook" button and did not initially complete the test.
Test 12 During this attempt at testing, the user discovered their mistake in the
prior test and corrected for it. Then went on to edit the header and description
of the same task without issue. When prompted, the user described confusion
about the requirement of saving, seeing the ability as something which should be
automatic.
Test 13 Once navigated and assessed correctly, the user, expecting a follow-up
interview, then asked the attending supervisor what the difference is between the
functions found on this board and the ones on the Kanban board. Further asking
why this functionality exists, and what its use is.