代写KIT305/KIT607、代做Mobile Application、代写SQL、SQL程序语言调试

日期：2019-04-17 10:25

KIT305/KIT607

Assignment 2

Implementation and Evaluation of a Mobile Application

Journal and Mood Tracking Application

Due Date

The assignment has three assessable components:

- The application code (worth 50%; pair-based work), due on Monday 20th May 2019 23:55 (week 12).

- A report (worth 40%; pair-based work), due on Monday 27th May 2019 23:55 (week 13).

- A demonstration (worth 10%; pair-based work), due in your scheduled tutorial (week 13).

Background

In assignment 1, your task was to design and prototype a native mobile application that allowed a user to create and

modify journal entries and track their mood.

Your task for this assignment 2 is to now implement and evaluate a mobile Android or iOS application that provides

the functionality. An updated list of requirements and additional requirements is provided in this document.

In the week 7 tutorial and in your own time, you will evaluate your different prototypes from assignment 1, to

determine which ones meet the usability goals discussed in this unit, and which should form the basis of your

assignment 2 code. Note that you are not required to match all of the functionality or visual style from assignment 1,

but you should aim for some similarity between your assignment 1 and assignment 2 work. Functionality from

assignment 1 which is not specified in the “Code” section of this document is not required to be complete (for

example, if your assignment 1 featured a login page, you are not expected to make this function, but you are

encouraged to include a non-functional version of this in the app if you have time).

The goal of this assignment is to assess your ability to implement and evaluate mobile applications, and to

demonstrate your understanding of the fundamentals of mobile device programming when applied to a practical

context.

Group Work

This is a pair-based assignment. Group members will need to agree on a target mobile OS (Android or iOS), and - after

some usability think-aloud testing of the available prototypes – agree on the design that is to be implemented in code.

You MUST have a partner chosen by your week 7 tutorial. If you have difficulties finding a partner, use the

discussion board on MyLO, and speak to other students looking for partners. You will be assigned to a group in week

7.

Use the following link to register your group (only one group member needs to do this):

https://forms.gle/srcK1HwaHD6CNBFb6

Changes to group members MUST be approved by the Unit Coordinator. Late changes may not be approved.

Group members should contribute equally to ALL components of the assignment (report, code, demonstration). This

assignment will be subject to peer assessment, further details will be provided on MyLO.

Code (50%)

When you create your application, please use the following bundle identifier:

au.edu.utas.username.assignment2

(replace username with the username of one of the group members)

The Android or iOS application that you are to implement must consist of at least:

- A way of entering a new journal entry and saving it.

o At a minimum, journals should consist of a title, text, and a date of when the journal entry is saved.

Extra meta-data such as location or tagged friends is not required to function correctly.

Storing an image is considered an additional requirement (see below), not a core requirement

for this assignment.

- A way of showing a user’s past journal entries, and seeing more information about them.

- A way of editing and deleting previous journal entries.

- A way of selecting a current mood (this can be separate to creating journal entries or integrated into creating a

journal entry).

- A way of seeing how a user’s mood has changed in the past.

o As a core requirement, this needs only to list past moods. Displaying a graph is considered an

additional requirement (see below).

Data entered by the user should persist between runs of the application. You can use any data persistence method

taught in this unit to accomplish this (e.g. SQLite, file writing, or SharedPreferences/UserPreferences). You should not

“pre-fill” the database with user-entered information (such as existing journal entries), as the application should

function (not crash) when the user has just opened the application for the first time. Remember that any testing data

you enter while developing your application will not be visible to your marker, as they will be installing a fresh

version of your application on their emulator.

An important feature of your application will be its usability, i.e. learnable, memorable, efficient, failure-resistant,

forgiving, and satisfying. For the purpose of this assignment, particular emphasis will be placed on the “efficiency”

aspect of usability. This means that if users choose to, they can create a short journal entry quickly, without too many

additional steps.

Aside from checking for functionality, your program will be assessed on its robustness (i.e. does the application

crash), usability, and aesthetics. You will not be assessed on your coding style, commenting, or indentation, however

given the scale of this application, you are advised to do this to assist in development.

Remember to leave enough time to test your application on the School Mac computers. There may be some problems

when you transfer a project from a personal laptop, so you need to leave enough time to solve these.

When transferring an Android Studio project between computers, use the File -> Export to Zip… option to avoid errors.

Additional requirements

To gain higher marks, additional functionality should be added based upon the list below. Use the CRA below to

work out how many marks you will get for completing these additional requirements.

- The user can store an image in their journal by taking a picture using the phone.

- The user can share a journal entry to another application (such as email, chat program). The shared data,

should just be a plain-text version of the journal entry (you do not need to implement user accounts or a server for

this, see the lecture slides for information on sharing).

- The history of the user’s mood over time is shown using a graph.

o You are allowed to use a 3rd-party plugin for drawing a graph for this part of the assignment (as long

as you cite the author).

If your assignment 1 prototype doesn’t include functionality for these requirements, you can still implement this by

adding this to your application.

Check the CRA at the end of this document to see the weighting of each component.

Report (40%)

You will have been reading many articles throughout the semester that report on the design, iterative refinement, and

evaluation of new mobile and ubiquitous computing applications. Your readings have also been complemented by

articles on interaction design and discount usability methods. Accompanying the implementation of your application

will be a report outlining how you were able to apply the process of usability testing (and specifically think-aloud

evaluation) to iteratively improve the design and usability of your application.

You must write a report that is up to six (6) pages long (single-spaced, 10pt Times font). This page count includes figures

and tables, but excludes references.

Your report should include the following sections:

- Introduction;

- Description of Application (including selected screenshots of lo-fi prototype and final application);

- (Usability) Methodology;

- Results;

- Discussion;

- Conclusions; and

- References.

The Methodology section will outline the usability testing that was employed. It will also include details on how the

testing was conducted, including a description of the user participants and the test-tasks that were chosen for the

think-aloud evaluation (with a table showing tasks in rows and requirements in columns; see week 02 lecture). It is

expected that for a HD-level assignment, that you conduct iterative testing across at least three different prototypes.

Check the CRA for what is required.

The Results section will report the results of the usability testing. You should present a table of results, however only

simple summary statistics are necessary; you are NOT expected to conduct accurate statistical analysis such as t-Tests,

ANOVAs, or correlation). The purpose of this section is to show that you understand the testing process and have

conducted testing, not to get perfect usability scores. You will not be assessed on whether or not your results were

positive or not.

The Discussion section will provide a self-assessment critique of performance on all of the above criteria, and will

include a summary of the strengths and weaknesses of the application. You should refer to your results section to

back up your statements with data.

The report will also reference the set readings, lecture slides, and other literature and resources as appropriate to

justify decisions and provide background information.

Demonstration (10%)

In addition, you are required to demonstrate your application during the week 13 tutorial timeslot. The

demonstrations will be limited to four (4) minutes total. All group members must participate in the demonstrations,

and the 4-minute timeslots will be strictly enforced to ensure that all presentations are completed within the tutorial

session. The group demonstrations will need to:

- State the goals of the work for a broad public;

- Outline the design and testing that was conducted;

- Provide a convincing example of how a person would use the prototype (using either the emulator, a series of

screenshots, or a physical device); and

- Provide convincing evidence that the application meets its goals.

You may choose to create a PowerPoint presentation, but this is not necessary. You choose how to best communicate

the information above.

If you choose to use a physical device for your demonstration, you must ensure you have tested your application

thoroughly on the device prior to the demonstration. There will be no time during the tutorial to deploy to the device,

you must do that at well before your allocated time.

Assignment Submission

The following files must be submitted via MyLO before 23:55 on Monday 20th May (Week 12):

- One zip file, containing the project files. The zip filename should start with your UTAS account name (either

members’ name is fine).

o For Android, you should create this ZIP file using the File -> Export to Zip option. Submit the ZIP file

which is created.

o For iOS, you need to find your .xcodeproj file and project folder in Finder, select them both, right-click

and choose “Compress”. Submit the ZIP file which is created.

- A group assignment coversheet (available from the ICT website):

http://www.utas.edu.au/__data/assets/pdf_file/0005/161375/GroupAssignmentCover.pdf

The following files must be submitted via MyLO before 23:55 on Monday 27th May (Week 13):

- The group report, in PDF format, with a filename that starts with your UTAS account name (either members’

name is fine).

- A group assignment coversheet (available from the ICT website):

http://www.utas.edu.au/__data/assets/pdf_file/0005/161375/GroupAssignmentCover.pdf

Only one group member needs to submit these deliverables.

Peer assessment submission items are to be announced on MyLO, and will be due in Week 13.

Make sure to test your application on the University Mac machines in UC215 before submitting your assignment.

Unzip your application to the desktop of a lab machine you haven’t used before. Test that application opens and

compiles in Android Studio/XCode, and runs in the emulator. Android applications will be tested using a Nexus 5X

emulator. iOS applications will be tested on an iPhone X simulator. (If you have errors attempting to run your project,

be sure to try Build -> Clean Project, and running again).

Plagiarism and Cheating:

Practical assignments are used by the Discipline of ICT for students to both reinforce and demonstrate their

understanding of material which has been presented in class. They have a role both for assessment and for learning. It

is a requirement that work you hand in for assessment is your own.

Working with others

One effective way to grasp principles and concepts is to discuss the issues with your peers and/or friends. You are

encouraged to do this. We also encourage you to discuss aspects of practical assignments with others. However, once

you have clarified the principles of the problem, you must develop a solution entirely by yourself in your pair. In

other words; you and your partner must develop the application yourselves. You can discuss problems, but not share

solutions. Assistance with solutions should be provided by staff.

Cheating

Cheating occurs if you claim work as your own when it is substantially the work of someone else.

o This includes the use of third-party code from online resources.

Cheating is an offence under the Ordinance of Student Discipline within the University. Furthermore, the ICT

profession has ethical standards in which cheating has no place.

Cheating involves two or more parties.

o If you allow written work, computer listings, or electronic versions of your code to be viewed,

borrowed or copied by another student you are an equal partner in the act of cheating.

o You should be careful to ensure that your work is not left in a situation where it may be used/stolen

by others.

Where there is a reasonable cause to believe that a case of cheating has occurred, this will be brought to the attention

of the unit lecturer. If the lecturer considers that there is evidence of cheating, then no marks will be given to any of

the students involved and the case will be referred to the Head of Discipline for consideration of further action.

Note: You are allowed to use a 3rd-party plugin for drawing a graph for the “mood tracking graph” part of this

assignment, and you may use the built-in SQLite implementation provided in tutorials. You may not use any other

3rd-party plugin for any other part of this assignment.

KIT305/KIT607 Assignment 2, Semester 1, 2019: Implementation and Evaluation of a Mobile Application

Criterion High Distinction (HD) Distinction (DN) Credit (CR) Pass (PP) Fail (NN)

Code (50%; ILO2)

Students are to produce a journal and mood tracking

application

Functionality – Journal List (30%):

The application should have a way of showing a

user’s past journal entries, and seeing more

information about them.

The application should have a way of editing and

deleting previous journal entries.

A custom layout/view for each entry is used,

showing appropriate detail for a summary

screen.

The user can delete entries from the journal.

The user can modify entries in the journal

without needing to delete and re-add the items.

The user can see more detail about a journal

entry by navigating to a journal page and

sensible choices were made for this.

The interface for this part is highly intuitive;

provides a consistent look and feel and usage

across all screens and is aesthetically pleasing.

Application never crashes and has been tested

thoroughly to avoid the existence of bugs.

The journal can be filtered or searched in some

way.

A custom layout/view for each entry is

used, showing appropriate detail for a

summary screen.

The user can delete entries from the

journal.

The user can see the quantity required for

each item.

The user can modify items in the list

without needing to delete and re-add the

items.

The user can see more detail about a

journal entry by navigating to a journal

page and sensible choices were made for

this.

The interface for this part is intuitive and

aesthetically pleasing.

Application never crashes. There are only

very minor bugs (if any).

A custom layout/view for each entry is

used, showing details of each journal

entry.

The user can delete entries from the

journal.

The user can see more detail about a

journal entry by navigating to a journal

page.

The interface for this part is somewhat

intuitive.

There are only some bugs (if any) in the

application and/or very rarely crashes.

The title of each journal

entry is listed.

The user can delete

entries from the journal.

A basic list view is

provided.

The user can see more

detail about a journal

entry by navigating to a

journal page.

There are only some

bugs (if any) in the

application and/or rarely

crashes.

The application does not

compile OR crashes on

start-up OR crashes

frequently.

The user is unable to view

all journal entries or is

unable to delete items.

Functionality – Add Entry (15%):

The application should have a way of entering a

new journal entry and saving it.

At a minimum, journals should consist of a

title, text, and a date of when the journal entry

is saved.

Users can add journal entries with a title, text,

date, and sensibly-chosen additional metadata.

The interface for this part is intuitive and

aesthetically pleasing.

Users can add journal entries with a title,

text, and a custom date, and additional

meta-data.

The interface for this part is intuitive and

aesthetically pleasing.

Users can add journal entries with a title,

text, and a custom date and time.

The interface for this part is somewhat

intuitive.

There are only a few bugs (if any) in this

part of the app.

Users can add journal

entries with a title, text,

and the current date

and time.

There are only a few

bugs (if any) in this part

of the app.

The application does not

contain functionality to add

journal entries.

Crashes prevent the user

from adding journal

entries.

Functionality – Mood Tracking (15%):

The application should have a way of selecting a

current mood (this can be separate to creating

journal entries or integrated into creating a journal

entry).

The application should have a way of seeing how

a user’s mood has changed in the past.

Users can enter their mood without having to

create a journal entry. Users can select a

custom mood (if appropriate to design of app).

Users are able to see a history of their moods.

Sensible choices are made for this display.

The interface for this part is intuitive and

aesthetically pleasing.

Users can enter their mood without having

to create a journal entry.

Users are able to see a history of their

moods.

The interface for this part is intuitive.

Users can enter their mood without having

to create a journal entry.

Users are able to see a history of their

moods.

The interface for this part is somewhat

intuitive.

There are only a few bugs (if any) in this

part of the app.

Users can select a

mood when creating a

journal entry.

There are only a few

bugs (if any) in this

screen.

The application provides

no functionality for

entering a mood, or

crashes prevent this part

of the assignment being

assessed.

Functionality – Data Persistence (15%):

Data entered by the user should persist between

runs of the application. You can use any data

persistence method taught in this unit to

accomplish this (e.g. SQLite, file writing, or

SharedPreferences/UserPreferences).

All data entered by the user persists between

runs of the application.

There are no noticeable bugs with the

persistence.

The application functions when there is no data

in the database.

All data entered by the user persists between runs of the application.

There are only some bugs (if any) with the persistence.

The application functions when there is no data in the database.

Most data entered by

the user persists

between runs of the

application.

There are only some

bugs (if any) where

some data does not

save.

The application

functions when there is

no data in the database.

Data does not persist

when the application is

closed and re-opened.

Usability - Efficiency (5%):

The application should make it easy for user to

quickly create short journal entries.

The interface provides well-thought out

functionality for making creation of journal

entries a quick process.

Basic functionality for making the creation of journal entries quickly is provided.

There are no noticeable bugs with this implementation.

Basic functionality for

making the creation of

journal entries quickly is

provided.

There are only some

bugs with this

implementation.

The application does not

have any design decisions

that make creating a

journal entry a quick

process.

Additional Functionality – Camera (10%):

The application should allow the user to add

images to their journal entries.

The application allows you to choose a photo

from the phone’s image gallery or camera and

add it to a journal entry.

The image is displayed on the screen after the

user selected the image and throughout the

rest of the app.

The image is saved to the database (either file

URL or image data is fine).

There are no bugs with the camera

functionality.

The application allows you to choose a photo from the phone’s image gallery or camera

and add it to a journal entry.

The image is displayed on the screen after the user selected the image and throughout

the rest of the app.

The image is saved to the database (either file URL or image data is fine).

The application allows

you to choose a photo

from the phone’s image

gallery or camera and

add it to a journal entry.

The image is displayed

on the screen after the

user selected the

image, but the image

does not persist on

consecutive runs.

The application features

no camera functionality or

the camera functionality

crashes the app when

triggered.

Additional Functionality – Sharing (5%):

The application should allow the user to share

a journal entry to another application on the

phone (such as email, chat program).

The application allows you to use the OS’ builtin

sharing functionality to share a text version of

a journal entry with all details (title, text, date,

mood).

Bonus (difficult): The user can share the text,

AND image attached to the journal entry.

The application allows you to use the OS’ built-in sharing functionality to share a text

version of a journal entry with most details.

The application allows

you to use the OS’ builtin

sharing functionality

to share the title of the

journal entry.

The application features

no sharing functionality or

the sharing functionality

crashes the app when

triggered.

Additional Functionality – Mood Graph (5%):

The application should display a graph to

showing the history of the user’s mood.

The application shows a visually pleasing graph

which uses data from the database (or other

data persistence method).

The graph can be filtered by different time

periods.

There are only a few bugs (if any) with the

graph functionality.

The application shows a simple graph

which uses data from the database (or

other data persistence method).

The graph can be filtered by different time

periods.

There are only some bugs (if any) with the

graph functionality.

The application shows a simple graph

which uses data from the database (or

other data persistence method) but doesn’t

change when the user selects different

time periods (but options still visually exist

to select a time period).

There are only some bugs (if any) with the

graph functionality.

The application shows a

simple graph (that is not

simply a static image).

The graph uses data

from the database (or

other data persistence

method).

The application does not

feature a graph or the

graph crashes the app

when displayed or a static

image is shown for the

graph.

Report (40%; ILOs 1,3,4)

Student is to create a report up to 6 pages long.

Description of Application (25%; ILO3)

The report will describe the functionality that has

been implemented; including images of the low-fi

prototype and final application.

All core functionality is explained in a concise,

and well-written manner.

Screenshots are clear and show the core

functionality of the app.

A reasoned description of how the final

application and lo-fi prototype differ is

provided.

All core functionality is explained in a

well-written manner.

Screenshots are clear and show the core

functionality of the app.

A description of how the final application

and lo-fi prototype differ is provided.

All core functionality is explained.

Screenshots show the core functionality

of the app.

Report contains an

overview of the

functionality and some

screenshots.

Fails to provide a

description section.

Methodology (25%; ILO4)

The report will outline the usability testing that

was conducted and the procedure in which it

was conducted.

The employed usability testing is welldescribed

and well founded; and accompanied

by clear usability test tasks and success

requirements.

Choice of methodology is well-justified.

At least three prototypes are evaluated over

multiple rounds of testing (i.e. iterative testing is

conducted).

The employed usability testing is welldescribed;

and accompanied by clear

usability test tasks and success

requirements.

At least three prototypes are evaluated.

The employed usability testing is welldescribed.

At least two prototypes are evaluated.

At least one prototype

is evaluated, and most

required details of the

testing procedure are

described.

Methodology follows

the recommendations

for this unit.

Fails to provide a

methodology section.

Results (25%; ILO4)

The report will report the results of the

usability tests.

Results are complete (and in a concise table)

and include completion times with summary

statistics. Results match the methodology

described in the report.

Results are complete (and in a concise table), and match the methodology described in

the report.

Basic results are

provided.

Fails to provide a results

section, or some results

are missing or

inconsistent with the

methodology section.

Discussion, Conclusion, and Overall

Report Style (25%; ILO1)

The report will provide a self-critique of the

application’s performance, including strengths

and weaknesses of the application.

The report will link to the set readings and other

literature and resources as appropriate.

A thorough and insightful discussion of the

results exists, sensibly highlighting ways future

versions of the app could be improved.

Report covers all of the required sections. It is

very well structured, has the required length,

and has a logical flow between sections.

English conventions of spelling, grammar, and

punctuation are excellent.

Academic referencing is consistent, with

many references beyond the set readings.

A thorough discussion of the results also

exists.

Report covers all of the required sections.

It is well structured, has the required

length, and has a logical flow between

sections

English conventions of spelling, grammar,

and punctuation are excellent.

Academic referencing is consistent, with

some references beyond the set

readings.

A detailed discussion of the results is

provided.

Report covers all of the required sections.

It is well structured, has the required

length, and has a logical flow between

sections

English spelling, grammar, and

punctuation are good.

Academic referencing is consistent,

linking to the set readings.

Some discussion of the

results is provided.

Report covers all of the

required sections.

Academic referencing

links to the set

readings.

Fails to provide a report,

or report is missing some

required sections.

Demonstration (10%; ILO5): Within the allocated 4-

minute group timeslot, students are to:

- State the goals of the work for a broad public.

- Outline the design and testing that was

conducted.

- Provide an example of how a person would use

the prototype.

- Provide evidence that the application meets its

goals.

The demonstration convincingly covers the

required objectives and holds the attention of

the audience. It is clear and rehearsed; flows

nicely over the different topics and speakers.

The demonstration is coherent, interesting, and

informative; eye contact is made; and the

demonstration is complete within 4 minutes.

The demonstration is not rushed.

The demonstration convincingly covers the

required objectives. It is clear and

rehearsed; flows nicely over the different

topics and speakers.

The demonstration is coherent; and

complete within 4 minutes.

The demonstration is not rushed.

The demonstration covers the required

objectives.

The demonstration is clear and rehearsed

and complete within 4 minutes.

The demonstration

somewhat covers the

required objectives.

Fails to demonstrate.