辅导GUI application、讲解data留学生程序、c/c++编程语言调试
辅导Web开发|辅导留学生Prolog
Tom Kelly (MS Teams)
Coursework 3: The Process
Date set: 23.11.20
Date due: 18.12.20
Weighting: 50%
Goals for this CW:
Experience agile software lifecycles in a collaborative environment
Evaluate, design, and develop a complex GUI application in Qt
Getting started:
Before the first meeting, everyone should get the Tomeo prototype
running.
Watch the introductory video.
Download the.zip file (right click...download) and open the
.pro project in Qt Creator.
!!Beware: this program shows flashing videos!!
Run the project. When a dialog pops up, click yes to open a
link to OneDrive and download the video files. Extract the
videos and set the absolute path of the videos directory as the
first command line argument to the project.
Run the initial Tomeo prototype in Qt Creator, explore its
(limited and buggy) functionality.
Make a note of any issues you observe with the usability of the initial
prototype.
Explore the code. In particular note the following classes, and read
any Qt documentation you need to:
tomeo.cpp: contains the main method and creates a list of
video files that have thumbnails.
the_button.cpp: a subclass of QPushButton which shows
the icon, and has a signal (jumpTo) that is fired when someone
clicks it.
the_player.cpp: a subclass QMediaPlayer which controls
the playback of the video in the QVideoWidget class.
Your task:
Your group will improve the Tomeo prototype for the following market
segment:
Outdoor enthusiasts who want to explore and organise a large personal
video library. This group collects massive quantities of video from
action cameras (e.g. GoPro), video drones (e.g. DJI Mavic), and mobile
phones (e.g. slow-motion footage from an iPhone). The video is
typically from a variety of locations, is of different lengths (ranging from
a "moving photo" of a few seconds to 3 hours of raw skiing footage),
and activities (e.g. cycling, parascending, football, or skiing).
Arrange a first meeting time with your group members.
your group should have 4 or 5 people in it
select an empty group in Minerva and each of the group
should sign up
If you need to be removed from a group, email Tom and
remember to give the group number to be removed from.
In the first meeting:
Exchange contact details with your group members, set up a
shared code repository (e.g. git, GitLab, Github….), and a
shared process document (e.g. Office 365, Google docs….).
Arrange a weekly time to meet and update each other on your
progress.
Explore the initial Tomeo prototype together.
Discuss the requirements of users from the market segment.
For this coursework you should invent realistic requirements
rather than gathering data yourself:
perform a PACT analysis to scope the problem space
write a persona to represent your users
write two scenarios which detail use-cases for the
persona
personas and scenarios should be realistic but
fictional
You will then complete at least 3 development cycles of the Tomeo
application before the due date above. For this coursework, one cycle
consists of:
i. prototyping a new design
ii. evaluating the prototype
iii. implementing desired changes to the application
You will create a process document detailing the design process with
the following structure:
1. the members of your group and their usernames.
2. the PACT analysis, persona (one paragraph), and two use
scenarios (one paragraph per scenario) which refine your
requirements.
3. the platform you are targeting (desktop, mobile, web, etc…).
All our development will take place with Qt and C++, but we can
design for other hardware / software.
4. a title and description of each cycle in the following format
(compare i-iii above):
i. prototype
a. one paragraph describing the goal of this
cycle.
b. the name of the prototyping technique and any
software used (technique: sketch, paper,
native…. software: Photoshop, Gimp, Qt
Designer, etc…)
c. one paragraph motivating the design shown in
your prototype.
d. one paragraph giving the reason for the
chosen technique.
e. evidence of the design (a photo, screenshot, a
video of a paper prototype, etc...)
ii. evaluation
a. the name of the evaluation technique used
(heuristic evaluation, cognitive walkthrough,
questionnaire, interview, etc...)
b. one paragraph describing why this technique
was chosen.
c. one paragraph describing the outcomes of the
evaluation.
d. evidence of the evaluation (a table of the
results, a video of the interactions, etc...)
iii. code
a. a video illustrating the changes compared to
the previous version.
b. a link to a code repository with the developed
code for this cycle (e.g. for Github this could be a
link to a tag, or press 'y' on the github project
page to get a link to the current commit).
c. one paragraph describing any differences
between the prototype and the implementation
because of the evaluation or technical difficulties.
e. An ethics statement, explaining how you complied with the
university regulations for ethical research on humans. Include
the information sheets and consent form(s) any participants
2020/11/25 https://minerva.leeds.ac.uk/bbcswebdav/pid-8263077-dt-content-rid-17887531_2/courses/202021_34881_XJCO2811/swjtu_CW3TheProcess.html
https://minerva.leeds.ac.uk/bbcswebdav/pid-8263077-dt-content-rid-17887531_2/courses/202021_34881_XJCO2811/swjtu_CW3TheProcess.html 3/4
have completed (do not include the completed forms
themselves).
Notes:
Ask questions on MS Teams channels as usual.
The paragraph limit on documentation is intended to make you
choose your language and conclusions carefully. A paragraph is
typically 1-2 sentences giving a statement, followed by 6-8 sentences
supporting the statement.
Supporting statements should make use of the terminology and
theory you have learnt in the module.
Note that our emphasis here is not on writing code or the final output.
We care (and award marks for) the design process you go through. It is
acceptable to abandon the result of a cycle if there is a well argued
reason.
You can run different cycles in parallel (at the same time) to spread
the work, as long as the cycles can be merged into a single code base
if successful. For example:
different people could perform parallel cycles to prototype,
evaluate, and code the layout of the home screen - as long as
the best implementation is merged.
different components could be built by different pairs of
people - a dialog box could be a parallel cycle to the main
screen layout.
Video evidence should be less than 45 seconds long. Include your
videos in the zip files uploaded to minerva.
Be sure to obtain permission to include people in videos. Find
alternatives if they do not want to be recorded (e.g. a transcript, voice
only, etc…)
We do not care about the quality of the videos (noise, camerawork
etc… are beyond the scope of this assignment). But they should be
understandable on a first viewing when the accompanying paragraph is
read.
Check all the links in your document before submission.
Code guidelines:
comment your code with single-line comments (using //)
such that someone familiar with C++ and this coursework
description (i.e. the person doing the grading) is able to follow it.
indentation and braces as per 1TBS.
class names begin with capital letters,
variable names begin with lower-case letters.
constant globals to begin with a lower-case 'k'.
function length should be limited to 50 lines (excluding empty
lines and comments).
line length should be limited to 100 characters.
there should be no unused (commented or inaccessible)
code.
Marks will be awarded for:
The quality of your PACT scoping analysis, scenario, and persona
design.
The quality of your evaluation and prototypes, as well as how well
they match your chosen scenario and persona.
The variety of evaluation and prototyping techniques applied.
Completing at least three cycles. Extension marks are available for a
fourth cycle.
Developing significant improvements to the Tomeo application which
match the persona and scenarios.
Following the code guidelines.
The quality of writing in your process document:
structure
arguments and supporting statements
application of a wide range of user experience theory (as
taught in the module)
written English
Your ethics compliance documents
2020/11/25 https://minerva.leeds.ac.uk/bbcswebdav/pid-8263077-dt-content-rid-17887531_2/courses/202021_34881_XJCO2811/swjtu_CW3TheProcess.html
https://minerva.leeds.ac.uk/bbcswebdav/pid-8263077-dt-content-rid-17887531_2/courses/202021_34881_XJCO2811/swjtu_CW3TheProcess.html 4/4
Contribution:
All members of the group will get the same mark, unless...
...all members of the group agree to a different mark split. To do this,
include this form in your submission. It must be signed by all group
members to be valid.
To submit:
You submission should be a zip file containing:
the PDF document in exactly the format detailed above
your final code which compiles and runs in QtCreator
optionally: a signed and scanned contribution form
Name your zip file for your usernames, e.g.:
scstke_scs20pop_sc12ghj_sc49ksh_sc88zxy.zip
A single member of your group should submit the zip file by the
deadline at the top of this page.
Submit your zip file using minerva.