UNSW Business School
Information Systems and Technology Management
INFS2605 Intermediate Business Programming
INFS2605 Group Assignment Specification
Contents
(1) Introduction.............................................................................................................................................................................2
(2) Context.....................................................................................................................................................................................2
(3) Your Task................................................................................................................................................................................3
(4) Basic Requirements...........................................................................................................................................................3
(4.1) Basic Requirements for DC (Data Capture)....................................................................................................3
(4.2) Basic Requirements for DD (Data Display).....................................................................................................4
(4.3) Basic Requirements for JF (Journey and Flow)...........................................................................................4
(5) Additional Functionalities ................................................................................................................................................5
(5.1) AF1: Drag and Drop Kanban Board......................................................................................................................5
(5.2) AF2: Deep Focus Moods.........................................................................................................................................5
(5.3) AF3: Daily Learnings..................................................................................................................................................5
(6) Submission and Assessment ........................................................................................................................................6
(6.1) Dispatches and Due Date ........................................................................................................................................6
(6.2) Deliverables and Weightings .................................................................................................................................6
(6.3) Assessment by Double-Blind Peer Review ....................................................................................................7
(6.4) Late Submission..........................................................................................................................................................7
(7) Other Comments.................................................................................................................................................................8
Page 2 of 8
Revision 09, 22 October 2019 (19t3)
(1) Introduction
This document is the specification for the INFS2605 student project for Term 3, 2019.
• Assessment: Knowledge Worker Clarity Application
• Weight: This assessment will comprise 30% of the total grade for this course.
• Groups: 3~4 students per group (team). Must be finalised by end of Week 6.
• Task: Develop a database-facing desktop application to empower knowledge workers to
have clarity over their daily activities.
• Due Date: Thursday of Week 9. Please refer to Section 6.1. (Note that you do NOT need
to submit anything in Week 8.)
(2) Context
The concept of “work” has evolved over centuries of technological progress. The agricultural
revolution transformed “work” from hunting and foraging to regular sustained harvest. The
industrial revolution transformed “work” from low-efficiency farm work to high-efficiency factory
work. It has been said that we are now living in the information revolution, which is transforming
“work” from physical tasks to mental tasks. Most of the labour force will soon be working as
knowledge workers who engage with mental tasks rather than manual tasks.
Knowledge work comes with unique challenges. Because work no longer has an obvious physical
manifestation, workers cannot see how much productive output they have produced in a day,
which often deprives workers of their sense of satisfaction. Because work is no longer comprised
of physical movements, the number of hours that a knowledge worker should work for optimum
productivity is controversial. Some advocate for knowledge workers to work far longer hours
(consider the “996” phenomenon in Asia), arguing that mental tasks are not bound by physical
stamina the same way that mental tasks are. Others advocate for knowledge workers to work for
far shorter hours (consider Tim Ferriss’ popular book, The Four-Hour Work Week), arguing that –
unlike with manual tasks – the productive output of mental tasks are not well-estimated by
elapsed time but are instead characterised by cycles of inertia, inspiration, serendipity, sudden
breakthroughs, and rapid progress.
In recent years, there has been interest in developing software solutions that assist knowledge
workers to overcome these unique challenges. A common ambition is to practice a knowledgeworker
interpretation of the martial arts concept mizu no kokoro (の), approximately “heart
like water” / “mind like water”. This idea, introduced into English-speaking popular culture by
Bruce Lee in the 20th century and recently adapted by David Allen (author of popular book
Getting Things Done) and Cal Newport (author of popular book Deep Work), suggests that a
knowledge worker needs extreme levels of focus to achieve the moments of inspiration,
serendipity, sudden breakthrough, and rapid progress. Such levels of focus are said to only be
possible when a knowledge worker is able to release all other kinds of mental record-keeping
(“what have I achieved today”, “how did I use my time today”, “what else do I need to do today”) to
an external system to free up cognitive load and maximise mental clarity.
Some solutions already exist, but do not fully solve the problem of implementing a mental state of
mizu no kokoro and deep focus. “Todo list” software such as Apple Reminders, Microsoft Todo,
and Things keep track of tasks and deadlines, but require a large amount of clicking and typing
through data entry forms to be able to allocate tasks towards “today”, “tomorrow”, “next week”,
etc. Time tracking software such as Toggl can track time towards various categories reasonably
well, but are optimised for ad-hoc usage for billable client-vendor projects rather than keeping
account of how one’s time is spent across 24 hours per day. Frustrated with the limitations of
Page 3 of 8
Revision 09, 22 October 2019 (19t3)
these tools, one knowledge worker currently employed by Tesla Australia created her own
solution, based on Google Sheets, and documented it on her blog1
. This solution, although
functionally almost complete, has its own limitations: It is said to require over 2 hours per week of
data manipulation work, and an in-browser general-purpose spreadsheet tool like Google Sheets
will have significantly reduced performance compared to a structured database like SQLite.
(3) Your Task
You are to build a “Knowledge Worker Clarity App”, using Java (version 8) with JavaFX as a GUI
platform and SQLite as a data storage platform, that addresses the limitations of existing
solutions to the challenges of Knowledge Work clarity as described in Section 2 above. The
requirements for this app are documented in sections below.
(4) Basic Requirements
As per the UNSW Grade Definitions, a “PS” (Pass) grade (mark range: 50~64) indicates “an
acceptable level of performance” that “indicates that the student has addressed the assessment
requirements of the "course and has demonstrated an acceptable understanding of the issues
entailed”. As such, satisfactory completion of these “Basic Requirements”, will earn a PS grade
(mark range: 50~64) for the coding component of the assessment.
(4.1) Basic Requirements for DC (Data Capture)
Your software application needs to be able to capture all these kinds of data through a graphical
user interface (GUI). Your software application must also be able to update and delete entries.
• DC1: A list of categories to which a user can log time. Each category shall have:
▪ Category Name and Category Colour (for colour-coded visualisations)
• DC2: A list of entries about how a user has spent time. Each entry shall have:
▪ Entry Start Time and Entry End Time
▪ Entry Duration (calculated from start and end time)
▪ Entry Description
▪ Entry Category
• DC3: A list of tasks that a user must complete. Each task shall have:
▪ Task Title and Task Description
▪ Task Do-Date (date on which the user plans to do the task)
▪ Task Due-Date (deadline)
▪ Task Priority (0 = Least Important, 100 = Most Important)
1 https://www.immahuman.com/posts/project-time-keeping-an-intro
Page 4 of 8
Revision 09, 22 October 2019 (19t3)
(4.2) Basic Requirements for DD (Data Display)
Your software application needs to be able to display data formatted according to these screens
through a graphical user interface (GUI).
• DD1: “Kanban Board” – A screen that has sections showing:
▪ Tasks completed today
▪ Tasks to do today
▪ Tasks to do tomorrow
▪ Tasks to do over the next 7 days
• DD2: “Deep Focus Screen” – A screen that allows the user to select a single task from the
list of all tasks, and then shows the task name and description in large text alongside a
clock (current time and date) in large text.
• DD3: “Pie Chart of My Life” – Pie chart visualisation of total hours spent, broken down by
percentage according to category, colour-coded (compare with the example on
immahuman.com as per Section 2).
• DD4: “Daily Breakdown” – Bar chart visualisation of typical hours per day spent on top 5
activities (also compare with example on immahuman.com).
• DD5: “Weekly Breakdown” – Bar chart visualisation of typical hours per week spent on top
5 activities (also compare with example on immahuman.com).
• DD6: “Weekly Trends” – Line chart visualisation of percentage of hours spent on selected
activities over multiple weeks (also compare with example on immahuman.com).
(4.3) Basic Requirements for JF (Journey and Flow)
• JF1: “Usability” – Your software application should have minimal defects and should
perform well against usability heuristics such as Nielsen’s Ten Heuristics.
• JF2: “Navigation” – Your software application must be able to navigate between screens
using a navigation aid such as a toolbar, tab bar, master-detail, or menu bar.
• JF3: “About Screen” – Your software application must have a screen with the team’s
unique Submission UUID (see section 6.2), Copyright statement (shown in the box below),
and a list of all third-party libraries and multimedia items that were included.
Copyright © 2019. We, the developers of this software application, declare that it is
our work towards an assessment item submitted to fulfil the requirements of INFS2605
(UNSW Sydney). We declare that it is our own work, except where acknowledged,
and has not been submitted for academic credit elsewhere. We acknowledge that the
assessor of this item may, for the purpose of assessing this item: Reproduce this
assessment item and provide a copy to another member of the University; and/or,
Communicate a copy of this assessment item to a plagiarism checking service (which
may then retain a copy of the assessment item on its database for the purpose of future
plagiarism checking). We certify that we have read and understood the UNSW
University Rules in respect of Student Academic Misconduct.
Page 5 of 8
Revision 09, 22 October 2019 (19t3)
(5) Additional Functionalities
As per the UNSW Grade Definitions, higher grades are awarded to students who go beyond the
bare minimum required for passing. As such, satisfactory completion of these “Additional
Functionalities” (AF1, AF2, and/or AF3), will earn a CR grade (one additional functionality, of your
choice, completed well), DN grade (two additional functionalities, of your choice, completed well),
or HD grade (all three additional functionalities completed well).
(5.1) AF1: Drag and Drop Kanban Board
AF1 is an upgrade of the Kanban Board (basic requirement DD1).
Successful implementation must allow the user to drag and drop tasks between “completed
today”, “do today”, “do tomorrow”, “do over the next 7 days”. To maximise the usefulness of this
feature, the Kanban Board must be able to switch from “do-date mode” to “due-date mode”, i.e., it
must be able to allow drag-and-drop editing of the data not only based on when the task is to be
done but also when the task is due.
(5.2) AF2: Deep Focus Moods
AF2 is an upgrade of the Deep Focus Screen (basic requirement DD2).
Successful implementation must allow the user to select between at least 3 different “moods” for
the Deep Focus Screen. Each “mood” includes a track of background music that plays when the
mood is selected. Examples of moods include “gentle piano”, “café jazz”, “country folk guitar”. If
you decide to implement AF2, you MUST abide by Copyright and Intellectual Property
requirements, and all music that you use must be acknowledged in the About Screen (JF3). It is
advised that you make use of royalty-free music (e.g. music by Kevin MacLeod2
).
(5.3) AF3: Daily Learnings
AF3 involves new screens beyond what has been discussed so far.
Successful implementation must allow the user to answer the questions “What did you do well
today?” and “What could you have done better today?”. The first time the user uses this feature,
they only answer these questions for the current calendar day. However, from that day onwards,
the user will be asked to answer these questions for all days up until the current calendar day, so
that there are minimal gaps in the dataset.
Furthermore, each day, the user must be able to select answers from previous days using a
ComboBox. The software application must be able generate a report of all answers that have
been repeated over the last 30 days, and how often they have been repeated, sorted from most
repeated to least repeated.
2 https://incompetech.com/
Page 6 of 8
Revision 09, 22 October 2019 (19t3)
(6) Submission and Assessment
(6.1) Dispatches and Due Date
Event Time and Date Term 3
Submission UUID Dispatch 8PM, Thursday 7th Nov. Week 8
Submission Due Date 8PM, Thursday 14th Nov. Week 9
Peer Review Delegation Dispatch 8PM, Friday 15th Nov. Week 9
Peer Review UUID Dispatch 8PM, Friday 15th Nov. Week 9
Peer Review Due Date 8PM, Friday 22nd Nov. Week 10
(6.2) Deliverables and Weightings
Your group (team) submission must include the following:
# Description Weighting Submission
Method
1 Source Code
A working Java application that connects to an SQLite database and
carries out the system requirements. The application must select, add,
update, and remove data from a database. You must populate the
database with sample data.
80% ZIP file sent
to Lecturer
(Blair Wang)
2 Usability Summary
A document, no more than one page long, briefly outlining how your
software application applies design principles from EITHER Norman’s
(1998) “design of everyday things”, OR Nielsen’s (1994) heuristics.
10% PDF file
uploaded to
Moodle
3 Project Management Summary
A document, no more than one page long, briefly outlining how your
team managed the progression of tasks and the sharing of source
code. You may wish to draw on concepts such as Scrum3
. You should
describe how your team used version control such as Git.
10% PDF file
uploaded to
Moodle
4 Project Form
A completed project form detailing the working functionality of your
application upon submission (this template will be provided to students
on Moodle). Missing project form will result in an automatic penalty of
10% of the maximum marks available for the assignment.
Mandatory
but not
graded
PDF file
uploaded to
Moodle
5 UNSW Cover Page
This assignment submission must be accompanied by a SIGNED cover
page (this template will be provided to students on Moodle). Please
download the cover page, sign it, then scan and upload it along with
your assignment. Digital signatures are NOT allowed. Missing cover
page or cover page without proper signature will result in an automatic
penalty of 10% of the maximum marks available for the assignment.
Mandatory
but not
graded
PDF file
uploaded to
Moodle
The ZIP file should be sent to the lecturer: Blair Wang – blair.wang@unsw.edu.au
To facilitate the double-blind peer review, each deliverable should be labelled with the team’s
unique Submission UUID, which will be given to all teams on the “Peer Review Delegation
Dispatch” shown in Section 6.1. Your submission should NOT include any other identifying
3 https://www.youtube.com/watch?v=XU0llRltyFM
Page 7 of 8
Revision 09, 22 October 2019 (19t3)
information (team members’ names, UNSW zIDs, tutorial times, tutor names) apart from on the
UNSW Cover Page.
(6.3) Assessment by Double-Blind Peer Review
In addition to the five deliverables listed above due on the “Submission Due Date” described in
Section 6.1, you must also submit three “Peer Review” documents on the date of the “Peer
Review Due Date” described in Section 6.1. The “Peer Review” template will be made available to
students on Moodle and will contain marking criteria for assessing another team’s submission.
The contents of the “Peer Review” documents are based on the Peer Review process below:
1. On the date of the “Submission UUID Dispatch” as per Section 6.1, each team receives
their unique Submission UUID, which will be used to anonymise their submission.
2. On the date of the “Submission Due Date”, as per Section 6.1, each team submits their
deliverables through a combination of Moodle and direct email to the Lecturer.
3. On the date of the “Peer Review Delegation Dispatch”, each team receives three (3)
other teams’ submissions including all deliverables EXCEPT the UNSW Cover Sheet.
Over the course of the following week, they will review each of the other teams’
submissions. This work can be equally divided between team members if required.
4. On the date of the “Peer Review UUID Dispatch”, each team receives their unique Peer
Review UUID, which will be used to anonymise their reviews. Note that the Peer Review
UUID is NOT the same as the Submission UUID.
5. On the date of the “Peer Review Due Date”, each time will submit their Peer Review
documents to Moodle. These should be labelled using the team’s Peer Review UUID, not
their names nor their zIDs nor their Submission UUID.
Peer Review is a mandatory part of the assignment. Teams that do not submit all three (3) peer
review documents will incur an automatic penalty of 10% of the maximum marks available for the
assignment.
Each team’s mark for their Submission is based on the marks given to them during Peer Review;
however, the Teaching Team reserves the right to intervene in cases whether there are
discrepancies between reviewers or when it is determined that students overall are excessively
or insufficiently generous in rewarding marks where such marks are deserved.
(6.4) Late Submission
Late submission of an assignment is not desirable. Assignments are to be submitted on—or
before—the due date. The late submission of assignments carries a penalty of 10% of the
awarded marks for that assignment per day of lateness (including weekends and public holidays)
unless an extension of time has been granted by the LiC. An extension of time to complete an
assignment may be granted by the Lecturer-in-Charge in case of misadventure or illness.
Applications for an extension should be made to the Lecturer-in-Charge by email or in person (at
least) one week before the due date. You will be required to substantiate your application with
appropriate evidence such as medical certificates, accident reports etc. Please note that
workload, work/placement commitments and computer failures are usually considered
insufficient grounds for an extension.
Page 8 of 8
Revision 09, 22 October 2019 (19t3)
(7) Other Comments
Time Commitment: Groups are advised to allocate between 2~3 hours per week on the
assignment. However, depending on students’ knowledge of Java and tutorial attendance, some
groups may need to allocate additional time per week in order to successfully complete the
project on time. In order to minimise the time commitment for this assignment, students should
use any extra time provided during tutorial classes to work on their group assignment. Students
may only work on the assignment during tutorial time if approved by a tutor to do so.
Group Work: Students that commit to a group and then do not honour their commitments will
lose marks. Group members are expected to work in a harmonious and professional way. This
includes appropriate management of non-performing members and conflict management. A
group ‘leader’ may be selected to help organise group activities, but the responsibility for the
group’s performance falls on all its members. You are to report any group problems to your tutor
as early as possible. Weekly Group meetings are advised.
Learning outcomes: This assignment addresses the following learning outcomes:
• Interpret, review and share software code.
• Design, write and evaluate programming solutions for small to medium scale problems.
• Explain and apply MVC architecture in developing programming solutions.
• Design, write and evaluate GUI programs that interface with relational databases.
• Design, write and evaluate programs that use APIs.
• Apply UX methods/techniques in the development of software.
Tutor Assistance: Your tutor will be available to answer questions regarding this assignment
during your tutorials. Students can also use Ed to post questions regarding their assignment.
Plagiarism: The submission of non-original materials may be considered an act of plagiarism.
Refer to the INFS2605 Field Manual posted on Moodle.