代写GUI application、代做data留学生程序、c/c++编程语言调试

日期：2020-12-11 11:23

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.