EEE101 C Programming and Software Engineering 1 – ASSESSMENT 4
Assessment Number 4
Contribution to Overall Marks 35%
Issue Date 21/11/2019
Submission Deadline 24/12/2019 at 17:00 (5pm)
Assessment Objective
This assessment aims at evaluating students’ ability to develop a significant software solution to a
real-world 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 in the C programming language, which
meets the specifications before the due date. This size and type of the project is suitable for
development in 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 266 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 ability based on
their performance in previous assignments. Each group will then be randomly assigned one of 5
projects. Students wishing to form their own group should submit a copy of the form provided on
ICE having been filled in with all details and signed by all group members.
Final Deliverables
Each group should submit the following:
1. A report (a single MS-Word or PDF file), provides the following details based on the Software
Development Process applied throughout this semester:
a) Problem Statement (Specification: formulate the problem generally).
b) Analysis: interpret the vague software requirements provided in each design brief and
determine a very clear specification for your software design.
c) Design: explain how your program is structured, what each functional block does and if
possible why you have chosen this method.
d) Testing: explain how the program has been tested and verified.
2. All C source code (.c files) and the final executable demonstration file (.exe). The source code
must be appropriately commented.
3. A simple program manual (MS-WORD, or PDF), describing your programs basic functionality
(how it works), any necessary account names and passwords, known bugs, and functionality
status.
4. A personal reflection statement (1 page) from each member of the group that describes (i) how
he or she contributed to the group, (ii) what were the main technical difficulties he or she
encountered in the project.
5. A contribution form (The contribution form is part of the assessment 4 package zip file). 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 of the above-mentioned files/deliverables (report, source code, executable, manual, personal
contribution (1 per person)) must be zipped into a single file (RAR or ZIP). Then, the coordinator of
each group must submit this single file on ICE using his/her account.
NOTE: Each group should only submit ONE copy on ICE. Make sure your report has a title page
and ensure ALL group members names are on it.
Marking Scheme
This assessment requires the routine of code development using the software development process.
The general marking scheme is shown as follows:
Documentation (55%)
Overall Quality of Report 10%
Specifications 10%
Analysis 10%
Algorithm Design 10%
Testing 10%
User Manual 5%
Coding (45%)
Implementation/coding style 35%
Robustness 10%
A detailed marking scheme is attached (filename: 2017-18 EEE101 Marking Guidelines
Assignment 4.pdf)
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. Analyze and formalize 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 modularized so that the tasks for each member can be clearly determined. Designs
which mimic object oriented programming (by using abstract data types) are encouraged
although not required.
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. Finalize 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.
Project A: Bank Information System
Overall description:
Your team is employed by a bank to implement a system to manage the banking affairs.
Customer specifications:
The implementation of the banking system should be able to provide facilities to:
Register a new customer and store details such as name, address, telephone number, 6-digit
personal identification number (PIN) number (security code for using the card) as well as some
extra information (e.g., type of identification presented for joining the bank), etc.
Store and manage customer account information. Customers can have one or more accounts and
each account is uniquely identifiable by an account number generated by the system.
Collect and display bank statistical information e.g. number of customers, number of accounts.
Allow the following banking activities:
o Display current account balance.
o Allow withdrawals from an account.
o Register a deposit.
System Users
The system should be able to provide functionality for different users listed below:
Manager who will be able to:
o View banking statistics (as described above).
Bank clerk who will be able to:
o Add/delete/edit accounts for an existing customer.
o Make deposits to a customer’s account.
Customer who will be able to:
o Access their account information and perform banking activities except the deposit of money.
o All banking activities require the customer to enter their PIN number.
Project B: Hotel Management Information System
Overall description:
Your team is employed by the conference centre hotel to implement a software system responsible
for the overall management of room booking and customer records.
Customer specifications:
The implemented hotel systems should be able to provide facilities to:
Manage bookings for 80 rooms (10 per floor) and four classes of room (**, ***, **** and VIP).
Each room is assigned a single price class.
Manage customer accounts.
Offer hotel business statistics e.g. numbers of VIP customers, average numbers of hotel guests.
System Users
The system should be able to provide functionality for different users listed below:
Manager who will be able to:
o Set/amend classes for each room and the price per class. Each room should have a single price.
o Manage a customer database (add/edit/remove customers).
o View hotel business statistics (e.g. number of rooms booked).
Receptionist who will be able to:
o Register a booking (by recording a customer’s name, address, telephone number and hotel
member card no.). Customers without a hotel membership card, cannot book a VIP room.
o A search facility should be provided for room availability and dates. Additionally, the
operator can book one or more rooms to a registered customer.
o Record the arrival of a customer in the system.
o Edit booking details e.g. period of stay or room.
o Check-out customers by calculating charges.
Project C: DVD Rental System
Overall description:
Your team is employed by a DVD rental company to implement a software product to store their
movie database and handle customer rentals.
Customer specifications:
The implemented video-rental system should be able to provide facilities to:
Store movie titles, number of copies, title information (e.g., directors and actors), age limits (e.g.
films for children or films not suitable for children) and genre (i.e. type of the film, horror, action,
drama etc.).
Store customers’ information, identifiable by a unique account number. Customer information
should include name, age, telephone, address, pending charges, rental history, etc.
Provide facilities for search by title, actor and/or movie director.
System Users
The system should be able to provide the functionality for different users listed below:
Branch manager who will be able to:
o Add new titles and rental copies as well as edit/delete them.
o Specify rental duration and set/alter charges.
o Add/remove/edit customers information (see above).
o View current stock status by listing all titles and the number of copies available/on loan.
Rental desk worker who will be able to:
o Allow existing customers to rent available titles or return current loans.
o Determine charges and penalties.
Project D: Library Information System
Overall description:
The university library needs a new electronic rental system and your team is employed to build it.
Customer specifications:
The implemented system should be able to handle the basic operations of a library including the
following features:
Catalogue the library books; this should be stored in an indexed order (e.g. by author name or
shelf-mark).
The information about each book title should include: author(s), title, ISBN, subject, loan type
(normal, short loan, no-take-out), shelf-mark, loan status, number of copies, etc.
Provide search functionality so that any user can find a book.
System Users
The system should be able to provide functionality for different users listed below:
Administrator who should be able to:
o Add and edit book information including mark a book as lost or damaged.
o Register new library users as staff or student, each with varying privileges (e.g. staff can keep
books longer) including the user’s personal details.
o Ability to extend the loan period for a borrower’s existing loan.
o Print a list of available and borrowed books.
o Record the return of a book from a borrower.
Borrower (Staff or Student) who should be able to:
o Ability to borrow books.
o Ability to edit their personal details.
o Ability to renew their current loans for a pre-set number of times.
Project E: Parking Management System
Overall description:
Your team is employed for the implementation of a parking payment system in a university car-park.
The parking space consists of:
A 10x15x10 multi-story car-park, where each of the 10 floors is a 10x15 rectangular grid of car
parking spaces;
A 8x8 rectangular grid of e-bike parking spaces each with an electrical recharge plug is provided;
A 15x15 rectangular grid of e-bike parking spaces with no recharge facility (cost should be lower
than that for a recharging space).
Customer specifications:
The implemented parking system should be able to provide facilities to:
Maintain a database of registered drivers including their personal details including name,
university ID number, address, phone number, account balance and staff or student status.
Registered users should be able to pre-pay for their parking or to accumulate charges (up to a
pre-set amount).
System Users
The system should be able to provide functionality for different users listed below:
Administrator who will be able to:
o Add/delete/edit drivers’ personal details.
o Credit a drivers account.
o Set parking charges.
Entry/Exit system worker who will be able to:
o Record the entry of a registered driver.
o Allocate a randomly chosen parking space to a car. For an e-bike, the driver should be asked
if they would like a space with/without recharging and then a randomly chosen space is
allocated.
o View current car-park occupation and number of free spaces.
o Free a previously allocated car slot.
o Charge the leaving customer accordingly.