CPT109 C Programming and Software Engineering 1 – ASSESSMENT 3
Assessment Number 3 (group project)
Contribution to Overall Marks 15%
Issue Date 30th October 2023,(Week 7)
Submission Deadline 10th December 2023, 23:59 (Week 12)
Assessment Objective
This assessment aims to evaluate students’ ability to develop a significant software solution to a realworld problem by working as a member of a team. Your team will be given a vague specification and
is expected to deliver a software product using C programming language, which meets the
specifications before the due date. This size and type of project is suitable for development in a
modular format, and so teams are encouraged to devise program structures that allow various parts of
the code to be developed independently by each team member. Being a team player means you are
expected not only to apply the knowledge gained during the lectures, laboratory classes and
assignments to specify, design, implement, test and document your own code, but also to cooperate
with your teammates so that the whole project will be delivered on time with good quality.
Grouping
There are 445 students enrolled in this module, and you will be divided into groups consisting of 5
students. Groups will be formed in two stages as follows: Firstly, students will be given the option to
choose their own group members. Students failing to form a group will then be randomly assigned to
a group. Randomly formed groups will contain students with a range of abilities based on their
performance in previous assignments. Each group will then develop a Makerspace Seat Booking
System following the attached specification using C programming language.
Final Deliverables
Each group should submit the following (only 1 submission per group):
1. A report (PDF file), based on the Software Development Process applied throughout this
semester:
a) Problem Statement (Specification: formulate the problem generally) (10%).
b) Analysis: interpret the vague software requirements provided by your design brief and
determine a very clear specification for your software design. (10%)
c) Design: explain how your program is structured in terms of functional blocks and describe
what each block does. A flow diagram may be useful here showing how functions interconnect
and what data is passed between them. (10%)
d) Testing: explain how the program has been tested and verified. Ensure any usernames or
passwords required to test the program are listed in a table. (10%)
2. All C source code (.c files) and the final executable demonstration file (.exe). The source code
2
must be appropriately commented. Include any data files needed for execution. (50%)
3. Contribution form (The contribution form is part of the Assessment 3 download package). The
group should agree on the percentage of contribution of each member to each section and submit
one copy of the form signed by all members.
NOTE: This may lead to different marks for different members of the same group. If necessary, the
module leader may call group members for a short oral test.
Submission Procedure
All the above-mentioned files/deliverables (report, source code, executable, manual, contribution
form, must be compressed into a single file (.rar or .zip). The group leader (identified on the group
formation form) must submit this single compressed file on Learning Mall using his/her account.
NOTE: Each group should only submit ONE copy on Learning Mall. Make sure your report has a
title page and ensure ALL group members’ names and ID numbers are on it.
Marking Scheme
The general marking scheme is shown as follows:
Documentation (50%)
Overall Report Quality 10%
Problem Specification 10%
Analysis 10%
Algorithm Design 10%
Testing 10%
Coding (50%)
Implementation/coding style 40%
Robustness 10%
Important notes:
University late submission policy will be applied.
University Academic Integrity policy will be applied rigorously.
You can find information relating to both of these in ebridge.
3
General Guidelines
The project descriptions are deliberately given in the form of simple customer specifications, which
(as in the real world) are incomplete and often ambiguous, rather than a set of exact functional
specifications. The group members should work methodically together (as the developers in a real
world software project would) to:
1. Analyse and formalise the customer specifications (at this stage, the various design choices and
the software features can be subject to the group’s creativity).
2. Design and decompose the functional and programmatic aspects of the problem and allocate
constituent tasks to each group member. You are expected to use a top-down design which can
then be modularised so that the tasks for each member can be clearly determined.
3. Implement the product with frequent meetings to report progress and decisions to each other and
re-evaluate the agreed courses of action.
4. Implement test procedures, debug and correct the program. Each program module should be
independently testable. Testing of each module and the program as a whole should be performed.
5. Finalise the deliverables.
The specifications are only basic and most of the design choices should be made in your group
meetings. The systems described within the different projects have a variety of different features and
the disambiguation of the customer specifications can be based on the student’s logic and real life
experience.
Assessment will be based on whether the product/program offers reasonable functionality and
features (for the group size, allocated time and project difficulty), its design quality, flexibility,
robustness, software bugs and other stated deliverables.
If the group cannot implement all of the system features mentioned, it is better to have a few features
fully working without run-time crashes than none of the required features working properly due to
bugs or disrupting ripple effects between modules in the project. However, the corresponding marks
deduction will be applied depending on the missing features.
If any group issues arise during the project, it is important to raise these with the module leader as
soon as they do so that resolutions can be found quickly. It is important to work with your group, and
to share the work accordingly. All group members should be responsible for some of the coding.
Individuals may not produce your own work for submission independent of the group.
4
Makerspace Seat Booking System
Project Specification
Overall description:
Your team has been hired by the Management Office of a makerspace to develop a software system
that will handle seat reservations and records. The main requirements from the customer include:
Customer specifications:
The implemented software should have the following capabilities:
**3; Manage bookings for three types of seats: regular, with electrical outlets, and with
computers. Each seat type has a specific price.
**3; Manage customer accounts, which are identified by a unique account number.
**3; Provide business statistics such as the number of seats booked, the number of available
seats, total rent fees within a given time period, and customer information.
**3; Enable customers to log in to the system, search for available seats, make bookings, and pay
the rent fees.
System Users: The system should cater to the following user functionalities:
**3; Manager:
o Able to set or modify seat types and their respective prices
o Manage the seat database (add, edit, remove seats)
o View business statistics such as the number of seats booked and total income
o Additional functionalities may be included if necessary.
**3; Customers:
o Able to register a booking
o Edit booking details (e.g., period of stay or seat type)
o Cancel booking
o View past booking and payment records
o Additional functionalities may be included if necessary
5
CPT109 Assessment 3 - Contribution Form
Group Number:
Signed by all members:
Name ID Number Specification &
Analysis (%) Design (%) Coding (%) Testing (%) Report (%)
1.
2.
3.
4.
5.
Total 100 100 100 100 100
請加QQ：99515681 或郵箱：99515681@qq.com WX：codehelp
