THE UNIVERSITY OF HUDDERSFIELD
School of Computing and Engineering
ASSIGNMENT SPECIFICATION
Module details
Module Code CFS2160
Module Title Software Design and Development
Course Title/s MEng/BSc Software Engineering, MSci/BSc Computer Science,
MComp/BSc Computing, BSc Computer Science with..., BSc
Computer Systems Engineering
Assessment weighting, type and contact details
Title Coursework 2: Developing a Full Program
Weighting 50%
Mode of working for
assessment task
Individual
Note : if the assessment task is to be completed on an individual
basis there should be no collusion or collaboration whilst working on
and subsequently submitting this assignment.
Module Leader Ilias Tachmazidis Contact details:
Submission and feedback details
Hand-out date 18 January 2021
How to submit your
work.
Via Brightspace (to be automatically checked by TurnItIn)
Submission date/s and
times
04-05-2021 23:59 BST
Expected amount of
independent time you
should allocate to
complete this
assessment
30 hours, including time spent in practicals for the module
Submission type and
format
A ‘zip’ file (or similar) containing the software developed and an
accompanying report. Details below.
Date by which your
grade and feedback will
be returned
25 May 2021
4
Additional guidance information
Your
responsibility
It is your responsibility to read and understand the University regulations
regarding conduct in assessment.
Please pay special attention to the assessment regulations (section 4) on
Academic Misconduct.
In brief: ensure that you;
1. DO NOT use the work of another student - this includes students from
previous years and other institutions, as well as current students on the
module.
2. DO NOT make your work available or leave insecure, for other students to
view or use.
3. Any examples provided by the module tutor should be appropriately
referenced, as should examples from external sources.
Further guidance can be found in the SCEN Academic Skills Resource and UoH
Academic Integrity Resource module in Brightspace.
If you experience difficulties with this assessment or with time management,
please speak to the module tutor/s, your Personal Academic Tutor, or the
School’s Guidance Team.
Requesting a
Late
Submission
You are reminded to ‘back-up’ your work as late submission requests will not
be given for lost work, which includes work lost due to hardware and software
failure/s.
Late submission requests will only be approved if you can demonstrate
genuine, unexpected circumstances along with independent supporting
evidence (e.g. medical certificate) that may prevent you submitting an
assessment on time.
Submit your request for Late Submission via MyHud/MyStudies within 2
working days of the due date.
Late submission requests, up to a maximum of 10 working days, but typically 1-
5 working days, will be considered provided that there is appropriate evidence
which clearly indicates reasons for the request.
You will have 5 working days after submitting a request to provide the
evidence. Failure to submit evidence will result in the request being rejected
and your work being marked as a late submission (see below).
If you are unable to submit work within the maximum late submission period of
10 days, contact the School’s Guidance Team. (sce.guidance@hud.ac.uk), as
you may need to submit a claim for Extenuating Circumstances (ECs).
4
Additional guidance information
Extenuating
Circumstances
(ECs)
An EC claim is appropriate in exceptional circumstances, when an extension is
not sufficient due to the nature of the request, or it concerns an examination or
In-Class Test (ICT).
You can access the EC claim form on the Registry website; where you can also
find out more about the process.
You will need to submit independent, verifiable evidence for your claim to be
considered.
Once your EC claim has been reviewed you will get an EC outcome email from
Registry. If you are unsure what it means or what you need to do next, please
speak to the Student Support Office – Room SJ1/01
An approved EC will extend the submission date to the next assessment period
(e.g July resit period).
Late
Submission
(No ECs
approved)
Late submission, up to 5 working days, of the assessment submission deadline,
will result in your grade being capped to a maximum of a pass mark.
Submission after this period, without an approved extension, will result in a 0%
grade for this assessment component.
Tutor Referral
available
NO
Resources • Please note: you can access free Office365 software and you have 1 Tb
of free storage space available on Microsoft’s OneDrive – Guidance on
downloading Office 365.
4
Coursework 2: Developing a Full Program
1. Assignment Aims
To develop skills in modelling using UML.
To develop skills in defining classes.
To develop skills in writing programs.
To develop skills in testing programs.
To demonstrate the need to document software.
2. Learning Outcomes:
This assignment addresses all learning outcomes for the module.
3. Assessment Brief
You are required to design, implement, test and document a Java program (set of classes) for one (1)
of the following problem specifications:
Problem 1 - Supermarket Checkout Simulation
A large supermarket chain would like a simulation of their checkout system for training and
development purposes. You will need to define classes to represent the checkout system. You
should try to design your system and the classes that you will need before starting coding.
Your simulation must have a graphical user interface to display the state of the checkouts at all
times.
To obtain a bare pass your checkout simulation should:
• Include a minimum of two checkouts
• Include of list of products (for simplicity no more than 10 are required) that can be “scanned” with
appropriate product code, description, and price
• Enable items to be “scanned” using the product code
• Keep track of the total cost of items “scanned” for each customer
• Enable goods to be paid for in cash
• Print out a list of items “scanned”
To gain a higher mark you will need to implement some extensions to your checkout simulation.
Some suggestions might be:
• The facility to have more than two checkouts in the system i.e. an arbitrary number of checkouts
• The facility to have different types of checkouts such as 10 items or less, cash only etc.
• Enable the system to keep track of total payments made by all customers
4
• The facility to pay for goods by credit card
• A loyalty card
• Stock control
Problem 2 - Who wants to be a Zillionaire?
The problem is to define classes suitable for playing a game of ‘Who Wants to be a Zillionaire’. This
game is a cross between the successful TV quiz shows ‘Who Wants to be a Millionaire’ and
‘Mastermind’. Players choose a category on which to answer questions. Questions are of a multiplechoice
nature with the answer being one of four possibilities. If the player answers the question
correctly an amount of ‘money’ is credited to that player. Questions have a difficulty level according
to the amount of ‘money’ players are awarded for answering that question correctly. The questions
are asked in ascending order of difficulty and, therefore, value. Players take turns to answer
questions. If a player cannot answer a question, help is available as follows:
• Ask the Public. This involves a simulation of each possible answer being given a rating according to
the likelihood that it is the correct answer. Ratings for all four possible answers must add up to 100%
in total.
• Half-and-half. Two of the possible answers are removed leaving only the right answer and one wrong
answer.
Players are only allowed to use each help facility once per game. If a wrong answer is given that
player is out of the game. The winner is the player with the most money credited at the end of the
game.
To obtain a bare pass your game should have most of the following functionality:
• Allow two players to play the game
• Include a selection of questions that players could be asked
• Allow a player to choose the category of each question (for simplicity have three categories, one of
which should be general knowledge)
• Display a question at random from the available questions
• Provide a facility for the player to enter the answer to each question
• Inform the player whether the answer is correct, or not
• Keep track of the amount of ‘money’ credited to each player
• Implement the help facilities
• Allow a player to win
To gain a higher mark you will need to implement some extensions to your game. Some suggestions
might be:
• Allow more than two players to play the game.
• Facility for easily adding extra questions.
• Add another help facility, e.g. ‘Give us a Clue’.
• Ensure that the same question is not asked twice in any one game.
• Include the use of sound or animation to make the game more interesting.
• Display the ratings for ‘Ask the Public’ in graphical format e.g. a bar chart.
4
Getting started: You will need to identify the use cases and define classes to represent the problem
you have chosen to implement. In addition, your system must include a graphical user interface
showing the state of the system at all times. This interface must be written using JavaFX. You
should try to design your user interface and the classes that you will need before starting coding.
When you are ready to begin coding start with a basic program that has a very simple user interface
and some of the simpler functionality to obtain a pass. When this is working properly improve the
user interface and try implementing some of the more complex functionality. Finally, add one or
more extensions to gain a better mark.
Remember that the extensions given are just suggestions, and you do not need to implement them
all (or indeed any of them, if you can think of some of your own) to gain a high mark. However,
there is no limit to the extensions you can implement; the only limit is your imagination (and
programming skills!).
Formative Feedback: You are invited to submit for formative feedback a one-page use-case diagram
and a one-page class diagram of the design of your software. These should be as complete as
possible and so the use-case diagram should show the actors and associated use cases, and the class
diagram should show fields, methods, visibility etc., as well as relationships between the classes.
Bring your diagrams to any practical class before March 8, 2021.
Final Submission: By the deadline of 04-05-2021 23:59 BST, you must submit:
1. An electronic copy of your classes (including test classes). Electronic copies should be within an
IntelliJ project. All code should be professionally written (including comments and indentation, use
of sensible variable names, etc.).
2. An electronic report that includes:
• The final design documentation for your system, to include as a minimum a one-page use-case
diagram showing the actors and associated use cases and a one-page class diagram of the design of
your software. Note that this should be an updated version of the diagrams you presented for
formative feedback, improved to take into account any feedback received or any changes made as the
software has been implemented. This design documentation should be produced using the Visual
Paradigm UML modelling software. You should also include brief notes (maximum of 500 words) to
explain your design.
• A test plan showing the application tests that you have used. This could include the use of JUnit
Testing where appropriate, along with full system testing. You should include a list of test cases,
based upon the system requirements. Examples might be to ‘Scan an item’ in the supermarket
checkout simulation program, or to ‘Start a Game’ in the ‘Who wants to be a Zillionaire?’ game. You
should include all the test cases you can think of along with a pass/fail indicator to say whether your
software passes that particular test (the obvious implication here being that you need to list test
cases for features that do not actually work). You should also include screen shots of your software to
show how it works as you perform these tests. These screen shots should provide a ‘walk through’ of
the software.
How and where to hand in: Please create a folder labelled with your student ID and name (e.g.:
LastName_FirstName_u1234567). Place your IntelliJ project in this folder with your report.
4
Compress the folder using standard compression software and submit the compressed file
(preferably a ‘zip’ file) to Brightspace. There will be a link for this under “Assessment”.
4. Marking Scheme
The reports will be marked as follows:
• the UML models will be assessed for completeness, correctness, and adherence to UML standards,
and will contribute 30% of the marks for this assignment
• the testing will be marked on completeness and correctness (including tests to show what does not
work - this is essential) and will contribute 30% of the marks for this assignment.
• the submitted code will be examined and assessed on completeness, correctness, code quality and
adherence to software development standards, and will contribute 40% of the marks for this
assignment.
A marking sheet for this will be made available to students via Brightspace in advance of the
submission date.
5. Grading Rubric
The following grade descriptors give an idea of the standard of work required to achieve each grade:
Grade A (70%+)
The code will be complete, well written, well-structured according to object-oriented principles, and
reliable. It will be accompanied by high quality and accurate UML documentation and thorough
testing. The software will perform all core requirements and a significant number of additional
requirements and will have a high-quality user interface.
Grade B (60-69%)
The code will be mostly complete, well written, well-structured according to object-oriented
principles, and mostly reliable. It will be accompanied by good quality and mostly accurate UML
documentation and detailed testing. The software will perform all core requirements and some
additional requirements and will have a good quality user interface.
Grade C (50-59%)
The code will be mostly complete, well written, well-structured according to object-oriented
principles, and mostly reliable, but may have a few minor bugs or functional omissions. It will be
accompanied by good quality and mostly accurate UML documentation and reasonable testing. The
software will perform almost all core requirements and at least one additional requirement and will
have a reasonably good user interface.
4
Grade D (40-49%)
The code will perform the majority of the core requirements but will have few if any additional
features. The structure and quality of the code will be sub-optimal but workable. The report may
have errors and omissions but will at least attempt to provide a usable UML model and some testing.
Grade E (30-39%)
The code is buggy and does not provide a usable proof of concept implementation. The report is
incomplete and/or has significant errors in the models and the testing.
Grade F (0-29%)
Very poor attempt with no working software and a poor report with significant errors and omissions.
Grade U (0%)
No work submitted.