PROGRAMMING 1 (PRG510S) GROUP ASSIGNMENT, SEMESTER 2, 2024

COURSE DETAILS

Course Code: PRG510S Semester: 2

Course Title: Programming 1

Coordinator: Mr Mike Kale

Lecturer(s)
Dr. A. A. Azeta

Internal Moderator:

SUBMISSION

• Students MUST divide themselves into groups of minimum 5

and maximum 6 per group.
• For each group, each student is to submit a copy of the
documentation.
• Each file should be giving the name and student number (i.e.
Soft Copy:
James-224000000).
• All Submissions of documentations must be done on
eLearning before 11h59, 27 September 2024.
• Date of Group Assignment presentation/defence via Face-to-
Face (F2F) will be 30 September to 04 October 2024.
Hard Copy: • Not required
• Late submissions will NOT be accepted unless prior approval
Late Submission:
has been obtained from the Course Coordinator.
Due Date: Date: Day, 27 September 2024 Time: 11h59

Page 1 of 5
ASSESSMENT

The Assessment is: 20% Groupings: Minimum 5 and maximum 6 students

(Weight) per group.
Assessment Strategy
The assessment strategy is designed to evaluate the student’s achievement of the course
learning outcomes.

ASSIGNMENT DETAILS

The main aim of this Group Assignment is for the students to create a Java application to
demonstrate all that have been leant in the Programming 1 during the semester.
Students/groups are expected to pick a topic and derive the Functionalities, Services and
Requirements (FSR). For example, the following are the FSR that a Hospital Management
System (HMS) software will render:

S.No. NAME OF SOFTWARE DISCRIPTION / ROLE

MENU / ACTORS
MODULE
a. Login Patient PATIENT: Can login using unique Id and Password
Doctor after which the system shall show his/her profile.
Admin DOCTOR: Can login using unique Id and Password
after which the system shall show his/her profile.
ADMIN: Can login using unique Id and Password after
which the system shall show a profile with links to
maintain the system.
b. Registration Patient PATIENT: Can Register by filling all the required
details, after which the system will verify the details
and check if already registered or not. All records
should be kept in a Database for storage and easy
retrieval.
c. Book Patient PATIENT: Can Select doctor, date time and make an
Appointment appointment request after which the system shall
show a confirmation for appointment request.
d. Cancel Patient PATIENT: Can Cancel appointment by just one click
Appointment Doctor after which the system shall ask for re-schedule.
DOCTOR: Can Cancel appointment by just one click
after which the system shall send a message to the
patient.
e. Doctor Admin ADMIN: Can add a new doctor by filling all the details
Module after which the system shall show a confirmation
message. Can Remove a doctor by just one click after
which the system shall show confirmation message.

Page 2 of 5
 f. Patient Patient PATIENT: Can also see or search for a doctor by
Module entering dept, name or doctor id if known, after
which the system will check for the doctor if found
shall show doctor’s profile.

Students/groups are expected to discuss with a professional/someone in the field / domain

of the software in order to acquire the Functionalities, Services and Requirements (FSR)
from the institution/organisation. You may also get the FSR of your software from the
internet. For example, in the case of developing a Hospital Management System (HMS), you
can either get the FSR by discussing with a doctor/nurse in the hospital or get the FSR from
the internet.

PART I: Program Functionality

The program / Application approach is entirely up to you, so long as it follows the
description above. In addition, innovation and creativity will be an added
advantage, however below are guidelines to follow:

1. Different menu levels: For instance, Landing page, Admin Menu, Doctor Menu &
Patient Menu [2 Marks]
2. Database storage using data Structures such Arrays etc. [2 Marks]
3. Each GUI/Menu/Module a. to f. in the above table & Database carries 1½ marks
each (1½ x 6 = 9) [9 Marks]

PART II: Program formatting and presentation

The source code will be marked according to the following indicators.

1. Good modular designs within same program file, different methods per
functionality [2 Marks]
2. Good comments [2 Mark]
3. Ability to explain a portion of the code as may be required by the evaluator
[3 Marks]
TOTAL = 20%

PART III: STUDENTS/GROUPS SHOULD NOT PICK HMS AS A TOPIC, RATHER STUDENTS CAN
PICK ANY OF THE FOLLOWING TOPICS, DEVELOP THE FUNCTIONALITIES/SERVICES AND
REQUIRMENTS SIMILAR TO THAT OF HMS AND WORK ON IT AS A GROUP.

SN SUGGESTED GROUP ASSIGNMENT TOPICS

1 Development Of A Mail Tracking System
2 Development Of A Student Disciplinary Management System
3 Development Of Class Attendance System
4 Development Of An Invoice Management System (Using Shopping Mall As A Case Study)
5 Development Of A Personal Bank Account Management System
6 Development Of A Student Profile Management System
7 Development Of FCI Social Network System
8 Development Of eCampus System
9 Development Of A Property Management System

Page 3 of 5
10 Development Of A Gym Management System
11 Development Of Electricity Management System
12 Development Of A Water Management System
13 Development Of eBanking System
14 Development Of A Food Ordering System
15 Development Of A Vehicle/Bus Seat Reservation System
16 Development Of A Hotel Reservation System
17 Development Of An Online Examination System
18 Development Of A Timetable Management System
19 Development Of Mark/Result Processing System
20 Development Of Restaurant Order/Delivery Management System
21 Development Of eElection Or Evoting System
22 Development Of eGovernment System
23 Development Of An Online Survey System
24 Development Of An eCommerce System
25 Development Of A Job Recruitment System
26 Development Of An eLearning System
27 Development Of Airline Seat Reservation System
28 Development Of A Point-Of-Sales System
29 Development Of A Game Playing System
30 Development Of A Service Request System
31 Development Of A Waste Management System
32 Development of A Payroll System
33 Development of An Information Extraction System
34 Development of a Shopping Mall Management System
35 Development of a Final year project/Thesis storage for easy search of topic, abstract and
content.
36 Development of a Bookshop Management System
37 Development Of Train Seat Reservation System
38 Development of a Police Record Management System (RMS)
39 Development of a Traffic Violation Management System
40 Development of a Document Management System
41 Development of a Logistics Management System
42 Development of a Railway Management System
43 Development of an Emergency/Disaster Management System
44 Development of a Production/Manufacturing Equipment Management System
45 Development of a Finance Fraud Detection System
46 Development of a Lease Management System
47 Development of a Livestock Management System
48 Development of an NGO Donor Management System
49 Development of a Fleet Management System
50 Development of a Property Valuation System
Students/groups that have any other viable topic that is not listed here should send an email to
the Course Coordinator – Mr Mike Kale
Email: mkale@nust.na for approval before starting the project.

PART IV: Further information

• EXTRA MARKS WILL BE AWARDED FOR CRITICAL THINKING AND CREATIVE IDEAS.

Page 4 of 5
• PLEASE NOTE THAT INABILITY TO EXPLAIN YOUR CODE WILL LEAD
TO ALL THE MARKS BEING PEGGED AT ZERO (SEE TEACHING PHYLOSOPHY IN COURSE
OUTLINE).

• PLAGARISM WILL NOT BE TOLERATED AND HENCE IF ASSIGNMENTS ARE COPIED OR COPIED
FROM ONLINE RESOURCES OR SHARED, THEN ALL STUDENTS INVOLVED ARE DISQUALIFIED.

Page 5 of 5