代做INFS2605、代写Business Programming、代写SQL编程语言、代做SQL代写

日期：2019-11-06 08:58

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.