BSCS-F22-09

03-134212-
Laiba Tahir
042

03-134211-
Rizwan Shahid
037

Arrhythmia Prediction System

In partial fulfilment of the requirements for the degree of

Bachelor of Science in Computer Science

Supervisor: Dawood Akram

Department of Computer Sciences

Bahria University, Lahore Campus
December 2024
© Bahria University, 2024
 i

Certificate

We accept the work contained in the report titled,

“Arrhythmia Prediction System”
written by
Laiba Tahir
Rizwan Shahid
as a confirmation to the required standard for the partial fulfilment of the degree of
Bachelor of Science in Computer Science.

Approved by:
Supervisor: Dawood Akram

(Signature)

December 2024
 ii

DECLARATION

We hereby declare that this project report is based on our original work except for
citations and quotations which have been duly acknowledged. We also declare that it
has not been previously and concurrently submitted for any other degree or award at
Bahria University or other institutions.

Enrolment Name Signature

03-134212-042 Laiba Tahir

03-134111-037 Rizwan Shahid

Date: Dec 20, 2023

 iii

Specially dedicated to

All our teachers, our parents, and of course our supervisor

Dawood Akram who brought up us as the way we are today.

Laiba Tahir
Rizwan Shahid
 iv

ACKNOWLEDGEMENTS

We would like to thank everyone who had contributed to the successful completion of
this project. We would like to express our gratitude to our research supervisor, Mr.
Dawood Akram for his invaluable advice, guidance, and his enormous patience
throughout the development of the research.

Laiba Tahir
Rizwan Shahid
 v

ABSTRACT

Arrhythmia, a prevalent cardiovascular disorder, presents significant health risks and

challenges for timely diagnosis and intervention. Current diagnostic methods often
lack precision and accessibility, leaving room for improvement in healthcare
outcomes. To address these challenges, we propose a comprehensive platform that
utilizes deep learning techniques applied to electrocardiogram (ECG) image datasets
for arrhythmia classification and prediction. By leveraging advanced deep learning
algorithms, this project aims to extract intricate features from ECG images, enabling
accurate classification of various arrhythmia types.

In addition, the research extends to the development of a user-friendly mobile

application, integrating the trained deep learning models to facilitate real-time ECG
analysis. This application allows users to capture ECG images via smartphone
cameras and receive instant diagnostic insights, thereby enhancing accessibility to
cardiac healthcare. The proposed system is designed to improve early detection,
promote timely intervention, and reduce the burden on healthcare systems. Through
the integration of cutting-edge deep learning models and mobile technology, this
project underscores the potential to revolutionize cardiac diagnostics, making it
accessible, efficient, and impactful for patients and healthcare providers alike.
 vi

TABLE OF CONTENTS

DECLARATION ii
ACKNOWLEDGEMENTS iv
ABSTRACT v
TABLE OF CONTENTS vi
LIST OF TABLES viii
LIST OF FIGURES ix
LIST OF SYMBOLS / ABBREVIATIONS xi

CHAPTERS

1 INTRODUCTION 1
1.1 Background 1
1.2 Problem Statements 1
1.3 Aims and Objectives 2
1.4 Scope of Project 2

2 LITERATURE REVIEW (and/or SRS) 3

2.1 Product Viewpoint 3
2.2 Operating Environment 3
2.3 User Classes 4
2.4 Design and Implementation Constraints 5
2.5 Assumptions and Dependencies 5
2.6 System Requirements Chart 5

3 DESIGN AND METHODOLOGY 7

3.1 Methodology 7
3.2 Design 8
 vii

4 DATA AND EXPERIMENTS (and/or IMPLMENTATION) 32

4.1 Methodology 32
4.2 Implementation 34

5 RESULTS AND DISCUSSIONS (or USER MANUAL) 37

5.1 Getting Started 37
5.3 Smart FYP Manager View 38

6 CONCLUSION AND RECOMMENDATIONS 47

REFERENCES 48

APPENDICES 49
 viii

LIST OF TABLES

Table 2.1: System Requirement Chart 5

Table 3.1: Use-Case Login 10

Table 3.2: Use-Case Add Batch 10

Table 3.3: Use-Case Upload FYP Document 11

Table 3.4: Use-Case Create Notification 11

Table 3.5: Use-Case Add Supervisor 12

Table 3.6: Use-Case Maintain Track Record 12

Table 3.7: Use-Case View FYP Groups 13

Table 3.8: Use-Case Search FYP Material 14

Table 3.9: Use-Case View Notification 14

Table 3.10: Use-Case View Weekly Logbook 15

Table 3.11: Use-Case Write Weekly Logbook 16

Table 3.12: Use-Case Documentation Marks 16

Table 3.13: Use-Case View Documentation Marks 17

Table 3.14: Use-Case Manage Accounts 17

Table 4.1: Front End Technologies 35

 ix

LIST OF FIGURES

Figure 3.1: Use Case Diagram 9

Figure 3.2: Collaboration Diagram of FYP Coordinator Login 18

Figure 3.3: Collaboration Diagram of FYP Coordinator Add Account 19

Figure 3.4: Collaboration Diagram of FYP Coordinator Add Supervisor 19

Figure 3.5: Collaboration Diagram of FYP Coordinator View Supervisor 20

Figure 3.6: Collaboration Diagram of FYP Coordinator Add Student 20

Figure 3.7: Collaboration Diagram of FYP Coordinator View Student 21

Figure 3.8: Collaboration Diagram of FYP Coordinator Add Announcement 21

Figure 3.9: Collaboration Diagram of FYP Coordinator View Announcement 22

Figure 3.10: Collaboration Diagram of FYP Coordinator Manage Account 22

Figure 3.11: Collaboration Diagram of FYP Coordinator Search FYP Material 23

Figure 3.12: Collaboration Diagram of FYP Coordinator Logbook 23

Figure 3.13: Collaboration Diagram of FYP Coordinator Upload FYP Material 24

Figure 3.14: Collaboration Diagram of Supervisor Login 24

Figure 3.15: Collaboration Diagram of Supervisor Add Announcement 25

Figure 3.16: Collaboration Diagram of Supervisor View Announcement 25

Figure 3.17: Collaboration Diagram of Supervisor Search FYP Material 26

Figure 3.18: Collaboration Diagram of Supervisor Logbook 26

Figure 3.19: Collaboration Diagram of Supervisor Upload Document Marks 27

Figure 3.20: Collaboration Diagram of Supervisor View Documentation Marks 27

Figure 3.21: Collaboration Diagram of Student Login 28

Figure 3.22: Collaboration Diagram of Student Search FYP Material 28

Figure 3.23: Collaboration Diagram of Student Logbook 29

 x

Figure 3.24: Collaboration Diagram of Student View Documentation Marks 29

Figure 3.25: Complete Sequence Diagram 30

Figure 3.26: Entity Relationship Diagram 31

Figure 4.1: Feature Driven Development Model 32

Figure 4.2: Structure of Back End Technologies 35

Figure 5.1: Landing Page 38

Figure 5.2: Admin Login Page 38

Figure 5.3: FYP Coordinator Side Bar View 39

Figure 5.4: FYP Coordinator Sending Alert 39

Figure 5.5: FYP Coordinator Notification View 40

Figure 5.6: FYP Coordinator Assignment Mark view 40

Figure 5.7: FYP Coordinator Adding Previous FYP 40

Figure 5.8: FYP Coordinator Added Project View 41

Figure 5.9: FYP Coordinator See All Supervisor View 41

Figure 5.10: FYP Coordinator Edit All Supervisor View 42

Figure 5.11: FYP Coordinator Add New Supervisor View 42

Figure 5.12: FYP Coordinator Edit all Students View 42

Figure 5.13: FYP Coordinator Add New Student View 43

Figure 5.14: Supervisor Side Panel View 43

Figure 5.15: Supervisor View all supervisor 44

Figure 5.16: Supervisor My Student View 44

Figure 5.17: Student Side Panel View 45

Figure 5.18: Student View all Announcement 45

Figure 5.19: Student my Submission View 46

Figure 5.20: Student my Supervisor View 46

 xi

LIST OF SYMBOLS / ABBREVIATIONS

FYP Final Year Project

Html Hyper-text markup language
CSS Cascading Style Sheet
Js JavaScript
MERN MongoDB – Express – React – Node
DB Database
CRUD Create – Remove – Update – Delete
 1

CHAPTER 1

INTRODUCTION

1.1 Background

Heart disease is a leading cause of mortality worldwide, with arrhythmia being a

significant contributor. Accurate and early detection of arrhythmia is crucial for
effective treatment and improved patient outcomes. However, traditional methods of
analyzing ECG data rely heavily on manual interpretation by healthcare professionals.
These approaches, while valuable, are time-consuming, prone to human error, and
often inaccessible in remote or resource-limited areas. Advancements in artificial
intelligence, particularly deep learning, offer promising solutions for enhancing the
accuracy and efficiency of arrhythmia detection. Deep learning models are capable of
processing large and complex ECG datasets to extract patterns that enable precise
classification of arrhythmias. Integrating these technologies into a user-friendly
application has the potential to transform cardiac diagnostics, making it more
accessible, reliable, and efficient for both patients and healthcare providers. This
project aims to leverage state-of-the-art deep learning techniques to develop a robust
arrhythmia detection system. By combining these algorithms with a mobile
application, the system seeks to bridge the gap between advanced diagnostics and
accessibility, empowering users to monitor their cardiac health effectively.

1.2 Problem Statements

Despite the critical need for early detection of arrhythmia, current diagnostic systems
remain inadequate in terms of accuracy, accessibility, and efficiency. Traditional
methods depend on manual analysis, which is not only time-intensive but also prone
to errors, particularly when diagnosing complex cases. Additionally, the lack of
 2

scalable and accessible tools prevents individuals, especially in remote areas, from
receiving timely and accurate cardiac evaluations. These challenges highlight the
pressing need for an automated solution that provides precise and real-time
arrhythmia detection. Without such a system, many patients face delayed diagnoses,
leading to severe health complications and increased strain on healthcare systems.
There is a clear need for a reliable and accessible diagnostic tool that empowers
patients and assists healthcare providers in delivering faster, more accurate cardiac
care.

1.3 Aims and Objectives

1. To develop a comprehensive system that utilizes deep learning techniques for

accurate arrhythmia classification using ECG image datasets.
2. To design and implement a mobile application that integrates trained deep
learning models for real-time ECG analysis.
3. To enhance accessibility to arrhythmia detection by enabling users to capture
and upload ECG images via smartphone cameras for instant diagnostic insights.
4. To improve early detection and intervention for cardiac abnormalities,
empowering both patients and healthcare professionals with a reliable diagnostic
tool.

1.4 Scope of Project

This project aims to develop a deep learning-based platform for arrhythmia detection
and classification using ECG image datasets. Accessible via a mobile application, the
system enables real-time ECG analysis, providing accurate diagnostic insights to
patients and healthcare providers. The platform bridges gaps in cardiac healthcare by
improving early detection, enhancing accessibility, and streamlining diagnostics,
especially in underserved areas.
 3

CHAPTER 2

LITERATURE REVIEW (and/or SRS)

2.1 Product Viewpoint

We are proposing a platform for arrhythmia detection and classification, leveraging

deep learning techniques to analyze ECG image datasets. This platform integrates
advanced algorithms to provide accurate and real-time diagnostic insights. The system
is designed as a mobile application to ensure accessibility and convenience for users,
enabling them to upload ECG images directly for instant analysis. The application is
developed using a robust technology stack, including Python for deep learning model
development and integration, and a user-friendly mobile framework for the front-end.
By combining artificial intelligence with mobile technology, the platform aims to
bridge the gap in cardiac healthcare, making diagnostics more efficient, accurate, and
widely accessible. This system reduces dependency on traditional diagnostic methods,
improves early detection rates, and empowers both patients and healthcare providers
to make timely decisions for better health outcomes.

2.2 Operating Environment

This is a mobile application platform which would run and executed finely on devices
supporting:
 A camera capable of capturing clear ECG images
 Devices running Android
 Flutter for cross-platform compatibility
 Flask or FastAPI for API integration
 Frameworks like TensorFlow or PyTorch for model execution
 4

2.3 User Classes

This platform would be having three kinds of users listed as followings:
 FYP Coordinator
 Supervisor(s)
 And of course, Student(s)

2.3.1 FYP Coordinator

 FYP Coordinator would be able to add Supervisor(s)

 FYP Coordinator would be able to edit Supervisor(s)
 FYP Coordinator would be able to delete Supervisor(s)
 FYP Coordinator would be able to view all Supervisor(s)
 FYP Coordinator would also be able to add Student(s) for the Supervisor(s)
 FYP Coordinator would be able to view Student(s) of any Supervisor(s)
 FYP Coordinator would be able to send Emails to Supervisor(s) and
Student(s)

2.3.2 Supervisor(s)

 Supervisor(s) would be able to view their student(s)

 Supervisor(s)would be able to add meeting record(s)
 Supervisor(s)would also be able to evaluate the progress of their student(s)

2.3.3 Student(s)

 Student(s) would be able to view their submission(s)

 Student(s) would be able to see the notifications or emails.
 Student(s)would also be able to upload their FYP related documents.
 5

2.4 Design and Implementation Constraints

The client side, or front end, of this application is developed using Flutter, a cross-
platform mobile development framework. Flutter leverages Dart programming
language to provide a seamless and interactive user interface compatible with both
Android and iOS devices.

The server side, or back end, is implemented using Python with frameworks
such as Flask or FastAPI, enabling efficient communication between the mobile
application and the deep learning model. The deep learning models, built using
TensorFlow or PyTorch, are hosted on a cloud-based server to handle ECG image
analysis and predictions.

Additionally, data storage is managed using Firebase or Cloud Firestore for

storing user data, authentication credentials, and diagnostic logs. This setup ensures a
scalable, reliable, and efficient environment for the application's operations.

2.5 Assumptions and Dependencies

The proposed arrhythmia detection platform is a mobile-based application, the user's

device must be a smartphone or tablet running android. For platform to function
properly the device must have a functional camera with adequate resolution for
capturing clear ECG images.

2.6 System Requirements Chart

Table 2.1: System Requirement Chart

ID Priority Type Contained in Description

Use-Case
Use-Case High Functional Use-Case 1 Registration
Smart FYP
Manager R1
Use-Case High Functional Use-Case 2 Login
Smart FYP
Manager R2
 6

Use-Case High Functional Use-Case 4 Search Project

Smart FYP
Manager R3
Use-Case High Functional Use-Case 5 View Project
Smart FYP
Manager R4
Use-Case High Functional Use-Case 6 Request Project
Smart FYP
Manager R5
Use-Case High Functional N/A List of SH
Smart FYP
Manager R6
Use-Case High Functional Use-Case 9 Discussion Forum (Chat with
Smart FYP Users)
Manager R7
Use-Case High Functional Use-Case 3 Upload project
Smart FYP
Manager R8
Use-Case Medium Functional Use-Case 6 Accept/Decline Request
Smart FYP
Manager R9
Use-Case Medium Functional Use-Case 8 Add new Teacher Account
Smart FYP
Manager R10
Use-Case Medium Functional Use-Case 8 Delete Teacher Account
Smart FYP
Manager R11
Use-Case High Functional Use-Case 8 Add FYP office Account
Smart FYP
Manager R12
Use-Case Medium Non- Use-Case 8 Responsive website Design
Smart FYP Functional
Manager R13
Use-Case Medium Non- N/A Testing Website will be done
Smart FYP Functional module by module
Manager R14
Use-Case Medium Non- N/A Design best Architecture for better
Smart FYP Functional data retrieval from server
Manager R15
Use-Case High Non- N/A The final integrated project code
Smart FYP Functional will undergo testing to confirm that
Manager R16 the entire project is well-integrated
and operating as intended.
 7

CHAPTER 3

DESIGN AND METHODOLOGY

3.1 Methodology

We are using FDD (Feature Driven Development) which is an Agile Model. In this
model, we pass through an iterative process with the following steps:
 Authorization of student(s), supervisor(s) or FYP coordinator
 Notification section in student(s) section
 Log of students(s) and supervisor(s)
 Attendance marking section.
 Availability of teacher(s) which could be selected as supervisor(s)
 Available supervisor(s) domains, or relevant field
 FYP Groups information in FYP coordinator section
 Relevant students’ information in supervisor(s) section

3.1.1 Build Feature List

 FYP Coordinator would be able to add Supervisor(s)

 FYP Coordinator would be able to edit Supervisor(s)
 FYP Coordinator would be able to delete Supervisor(s)
 FYP Coordinator would be able to view all Supervisor(s)
 FYP Coordinator would also be able to add Student(s) for the Supervisor(s)
 FYP Coordinator would be able to view Student(s) of any Supervisor(s)
 FYP Coordinator would be able to send Emails to Supervisor(s) and
Student(s)
 Supervisor(s) would be able to view their student(s)
 Supervisor(s)would be able to add meeting record(s)
 Supervisor(s)would also be able to evaluate the progress of their student(s)
 Student(s) would be able to view their submission(s)
 8

 Student(s) would be able to see the notifications or emails.

 Student(s)would also be able to upload their FYP related documents.

3.1.2 Sprint Planning

The next thing is to develop a plan which is known as “sprint planning”. Moreover, it
also shows the duration or time period of the sprints.

3.1.3 Daily Sprint Planning

This phase contains daily meetings with supervisor to discuss and share the problems
and difficulties being faced during the FYP, and it also includes the discussion about
future of our FYP.

3.1.4 Next Sprint Planning

In this phase the things which would come under discussion would be the ways how
to improve the development or implementation process of the FYP in terms of time
management, team management, teamwork and how to write/ develop more user-
friendly code as well.

3.2 Design

Following artefacts included in this Chapter.

1. Use case diagram.
2. Use case description.
3. Collaboration Diagram
4. Sequence Diagram
5. ERD
 9

3.2.1 Use Case Diagram

Figure 3.1: Use Case Diagram

 10

3.2.2 Use Case Description

Following are the narrative parts of every bubble in above use case diagrams.

Table 3.2: Use-Case Login

Name Login
Use-Case Id Smart FYP Manager R1
Priority High
Primary Actor FYP Coordinator
Other participating Actor(s) Supervisor/Student
Description This use case will login all stake holders of Smart FYP Manager
Pre-condition FYP Coordinator /Supervisor/Student must be logged in
Trigger This use case initiates when FYP Coordinator will add account of the
Students and Supervisors.
Typical flow of Event 1. Open Smart FYP Manager
2. Log in as FYP Coordinator/Supervisor/Student
Alternate flow of Event FYP Coordinator will not add Student, Supervisor
Post condition Successfully FYP Coordinator will add Students, Supervisor account
Alternate post condition Have not add Students, Supervisor account

Table 3.3: Use-Case Add Batch

Name Add batch
Use-Case Id Smart FYP Manager R2
Priority High
Primary Actor FYP Coordinator
Other participating Actor(s) N/A
Description This use case describes when FYP Coordinator will login at Smart FYP
Manager
Pre-condition FYP Coordinator must have account at Smart FYP Manager
Trigger This use case initiates when a FYP Coordinator adds batch
Post condition Batch successfully created
Alternate post condition Batch not created

Table 3.4: Use-Case Upload FYP Document

Name Upload FYP documents
Use-Case Id Smart FYP Manager R3
Priority High
Primary Actor FYP Coordinator, Supervisor, Student
Other participating Actor(s) --
Description This use case describes when FYP Coordinator, Supervisor, Student
 11

upload FYP documents

Pre-condition User must open Smart FYP Manager in browser and must be logged in
Trigger This use case initiates when FYP Coordinator will upload FYP
documents in Smart FYP Manager
Typical flow of Event 1. Open Smart FYP Manager
2. Log in as FYP Coordinator/Supervisor/Student
3. Upload FYP documents
Alternate flow of Event User will not upload FYP document
Post condition Successfully user will upload FYP document
Alternate post condition Have not upload FYP document

Table 3.5: Use-Case Create Notification

Name Create Notification
Use-Case Id Smart FYP Manager R4
Priority Medium
Primary Actor FYP Coordinator
Other participating Actor(s) --
Description This use case describes when FYP Coordinator will notify regarding
FYP
Pre-condition The FYP students should have account in Smart FYP Manager
Trigger This use case initiates when FYP Coordinator will notify regarding FYP
Typical flow of Event 1. Open Smart FYP Manager
2. Log in as FYP Coordinator
3. Click on Add Notification
Alternate flow of Event The FYP Coordinator are not added in Smart FYP Manager
Post condition Successfully notified regarding FYP
Alternate post condition No notification made

Table 3.6: Use-Case Add Supervisor

Name Add Supervisor
Use-Case Id Smart FYP Manager R5
Priority High
Primary Actor FYP Coordinator
Other participating Actor(s) ---
Description This use case describes when FYP Coordinator will add supervisor for
FYP in Smart FYP Manager
Pre-condition The FYP Coordinator should be register in Smart FYP Manager
Trigger This use case initiates when FYP Coordinator will add supervisor in
Smart FYP Manager
 12

Typical flow of Event 1. Open Smart FYP Manager

2. Log in as FYP Coordinator
3. Select supervisor
4. Click on Add supervisor
Alternate flow of Event Supervisor will not be added in Smart FYP Manager
Post condition Successfully added supervisor
Alternate post condition No supervisor added

Table 3.7: Use-Case Maintain Track Record

Name Maintain Track Record
Use-Case Id Smart FYP Manager R6
Priority Medium
Primary Actor FYP Coordinator
Other participating Actor(s) N/A
Description This use case describes when FYP Coordinator will maintain the records
of FYP in Smart FYP Manager
Pre-condition 1. FYP Coordinator must open Smart FYP Manager in browser and must
be logged in.
2. Students must be added in FYP
Trigger This use case initiates when a FYP Coordinator will maintain the record
of registered FYP groups
Typical flow of Event 1. Open Smart FYP Manager
2. Log in as FYP Coordinator
3. Search FYP Group ID
Alternate flow of Event FYP Coordinator have not search FYP Group id
Post condition Successfully maintain the record of the added FYP Students
Alternate post condition Have not maintain the record of the added FYP Students

Table 3.8: Use-Case View FYP Groups

Name View FYP groups
Use-Case Id Smart FYP Manager R7
Priority High
Primary Actor FYP Coordinator
Other participating Actor(s) N/A
Description This use case describes when FYP Coordinator will view FYP groups in
Smart FYP Manager
Pre-condition FYP Coordinator must open Smart FYP Manager in browser and must
be logged in.
Trigger This use case initiates when a FYP Coordinator will view FYP groups in
 13

Smart FYP Manager

Typical flow of Event 1. Open Smart FYP Manager
2. Log in as FYP Coordinator
3. View FYP Groups
Alternate flow of Event FYP Coordinator will not view FYP Group
Post condition Successfully FYP Coordinator will view FYP Group
Alternate post condition Have not view FYP Group

Table 3.9: Use-Case Search FYP Material

Name Search FYP material
Use-Case Id Smart FYP Manager R8
Priority Medium
Primary Actor FYP Coordinator /Supervisor/Students
Other participating Actor(s) N/A
Description This use case describes when FYP Coordinator will search FYP material
Pre-condition 1. FYP Coordinator must open Smart FYP Manager in browser and must
be logged in
2. Supervisor must open Smart FYP Manager in browser and must be
logged in
3. Students must open Smart FYP Manager in browser and must be
logged in
Trigger This use case initiates when FYP Coordinator/Supervisor/ Students will
search FYP material in Smart FYP Manager
Typical flow of Event 1. Open Smart FYP Manager
2. Log in as FYP Coordinator/Supervisor/ Students
3. Search FYP material
Alternate flow of Event FYP Coordinator login and will not search FYP material
Post condition Successfully FYP Coordinator will search FYP material
Alternate post condition Have not search FYP material

Table 3.10: Use-Case View Notification

Name View Notification
Use-Case Id Smart FYP Manager R10
Priority Medium
Primary Actor FYP office, Students, supervisor
Other participating Actor(s) N/A
Description This use case describes when FYP Coordinator/Supervisor/ Students will
 14

view notification regarding FYP

Pre-condition The FYP Coordinator, FYP Students and Supervisor should be register
in Smart FYP Manager
Trigger This use case initiates when FYP Coordinator/Supervisor/ Students will
view notification regarding FYP
Typical flow of Event 1. Open Smart FYP Manager
2. Log in as FYP Coordinator/Supervisor/ Students
3. Click on view notification.
Alternate flow of Event The FYP Coordinator, Supervisor and Students are not add in Smart
FYP Manager
Post condition Successfully view notification regarding FYP
Alternate post condition FYP Coordinator/Supervisor/ Students will not view notification

Table 3.11: Use-Case View Weekly Logbook

Name View weekly logbook
Use-Case Id Smart FYP Manager R11
Priority Medium
Primary Actor Students, FYP Coordinator
Other participating Actor(s) N/A
Description This use case describes when Group and FYP office will view weekly
logbook
Pre-condition The FYP Coordinator and Students should be register in Smart FYP
Manager
Trigger This use case initiates when the Group and FYP Coordinator will view
weekly logbook
Typical flow of Event 1. Open Smart FYP Manager
2. Log in as FYP Coordinator / Students
3. Click on view weekly logbook
Alternate flow of Event The FYP Coordinator and Students are not add in Smart FYP Manager
Post condition Successfully view weekly logbook
Alternate post condition FYP Coordinator and Students will not view weekly logbook

Table 3.12: Use-Case Write Weekly Logbook

Name Write weekly logbook
Use-Case Id Smart FYP Manager R12
Priority High
Primary Actor Students
Other participating Actor(s) N/A
 15

Description This use case describes when Students will write weekly logbook
Pre-condition The students should be added in Smart FYP Manager
Trigger This use case will initiate after generating weekly logbook by FYP
Coordinator
Typical flow of Event 1. Open Smart FYP Manager
2. Click on weekly logbook
Alternate flow of Event Students are not adding in Smart FYP Manager
Post condition Successfully weekly logbook written
Alternate post condition Students will not write weekly logbook

Table 3.13: Use-Case Documentation Marks

Name Documentation marks
Use-Case Id Smart FYP Manager R13
Priority Medium
Primary Actor Supervisor
Other participating Actor(s) N/A
Description This use case describes when supervisor will grade documents
Pre-condition The supervisor should be added in Smart FYP Manager
Trigger This use case initiates when supervisor will grade documents
Typical flow of Event 1. Open Smart FYP Manager
2. Click on announcement submissions
Alternate flow of Event The supervisors are not added in Smart FYP Manager
Post condition Successfully graded documents
Alternate post condition Supervisors will not grade document

Table 3.14: Use-Case View Documentation Marks

Name View documentation marks
Use-Case Id Smart FYP Manager R14
Priority Medium
Primary Actor FYP Coordinator, Students and Supervisor
Other participating Actor(s) N/A
Description This use case describes when supervisor will grade FYP document
Pre-condition The FYP Coordinator, Students and Supervisor should be register in
Smart FYP Manager
Trigger This use case initiates when FYP Coordinator, Students and Supervisor
will view FYP document marks
Typical flow of Event 1. Open Smart FYP Manager
 16

2. Click on view announcement

Alternate flow of Event  FYP Coordinator, Students and Supervisor will not
be logged in Smart FYP Manager
 The document is not graded
Post condition Successfully view documentation marks
Alternate post condition FYP Coordinator, Students and Supervisor will not view documentation
marks

Table 3.15: Use-Case Manage Accounts

Name Manage accounts
Use-Case Id Smart FYP Manager R15
Priority Medium
Primary Actor FYP Coordinator
Other participating Actor(s) N/A
Description This use case describes when FYP Coordinator will view accounts
Pre-condition FYP Coordinator should be registered in Smart FYP Manager
Trigger This use case describes when FYP Coordinator will view accounts
Typical flow of Event 2. Click on view announcement
Alternate flow of Event  FYP Coordinator will not be logged in Smart FYP
Manager
 The accounts will not be edited
Post condition Successfully managed account
Alternate post condition FYP Coordinator will not manage account

3.2.3 Collaboration Diagram

A collaboration diagram defines a pattern of item interaction; it illustrates object
engagement through connections between the objects. Collaboration diagrams are
used to show how objects interact to provide the desired behaviour of a use case, or a
portion of a use case. Designers use collaboration to describe and elucidate the
features of the items that carry out a specific flow of a collection of a use-case.
A collaboration diagram, as opposed to a sequence diagram, shows the connections
between the objects. Sequence diagrams and collaboration diagrams present the same
information in different ways. Because of their format, collaboration diagrams are
preferable for analysis. They are particularly better suited to illustrating more
straightforward interactions between fewer items. The "Smart FYP Manager"
Collaboration Diagrams are listed below.
 17

3.2.3.1 FYP Coordinator Collaboration Diagram

Figure 3.2: Collaboration Diagram of FYP Coordinator Login

Figure 3.3: Collaboration Diagram of FYP Coordinator Add Account

 18

Figure 3.4: Collaboration Diagram of FYP Coordinator Add Supervisor

Figure 3.5: Collaboration Diagram of FYP Coordinator View Supervisor

 19

Figure 3.6: Collaboration Diagram of FYP Coordinator Add Student

Figure 3.7: Collaboration Diagram of FYP Coordinator View Student

 20

Figure 3.8: Collaboration Diagram of FYP Coordinator Add Announcement

Figure 3.9: Collaboration Diagram of FYP Coordinator View Announcement

 21

Figure 3.10: Collaboration Diagram of FYP Coordinator Manage Account

Figure 3.11: Collaboration Diagram of FYP Coordinator Search FYP Material

 22

Figure 3.12: Collaboration Diagram of FYP Coordinator Logbook

Figure 3.13: Collaboration Diagram of FYP Coordinator Upload FYP Material

3.2.3.2 Supervisor Collaboration Diagram

 23

Figure 3.14: Collaboration Diagram of Supervisor Login

Figure 3.15: Collaboration Diagram of Supervisor Add Announcement

 24

Figure 3.16: Collaboration Diagram of Supervisor View Announcement

Figure 3.17: Collaboration Diagram of Supervisor Search FYP Material

 25

Figure 3.18: Collaboration Diagram of Supervisor Logbook

Figure 3.19: Collaboration Diagram of Supervisor Upload Document Marks

 26

Figure 3.20: Collaboration Diagram of Supervisor View Documentation Marks

3.2.3.3 Student Collaboration Diagram

Figure 3.21: Collaboration Diagram of Student Login

 27

Figure 3.22: Collaboration Diagram of Student Search FYP Material

Figure 3.23: Collaboration Diagram of Student Logbook

 28

Figure 3.24: Collaboration Diagram of Student View Documentation Marks

3.2.4 Sequence Diagram

 29

Figure 3.25: Complete Sequence Diagram

3.2.5 Entity Relationship Diagram

 30

Figure 3.26: Entity Relationship Diagram

 31

CHAPTER 4

DATA AND EXPERIMENTS (and/or IMPLMENTATION)

4.1 Methodology

Methodology used for this project is FDD which is a sub-group of agile methodology;
the purpose of using FDD is because of its simplicity and iterative development. The
FDD methodology includes further definitions and specifications but purses the
values and principles of agile. Class diagram and sequence diagram will be used in
the system analysis, and feedback on the initial design will be acquired from real
users of the system.

Figure 4.27: Feature Driven Development Model

Following are the FDD phases that will be followed in this project.

4.1.1 Build Feature List

 FYP Coordinator would be able to add Supervisor(s)

 FYP Coordinator would be able to edit Supervisor(s)
 FYP Coordinator would be able to delete Supervisor(s)
 32

 FYP Coordinator would be able to view all Supervisor(s)

 FYP Coordinator would also be able to add Student(s) for the Supervisor(s)
 FYP Coordinator would be able to view Student(s) of any Supervisor(s)
 FYP Coordinator would be able to send Emails to Supervisor(s) and
Student(s)
 Supervisor(s) would be able to view their student(s)
 Supervisor(s)would be able to add meeting record(s)
 Supervisor(s)would also be able to evaluate the progress of their student(s)
 Student(s) would be able to view their submission(s)
 Student(s) would be able to see the notifications or emails.
 Student(s)would also be able to upload their FYP related documents.

4.1.2 Sprint Planning

The next thing is to develop a plan which is known as “sprint planning”. Moreover, it
also shows the duration or time of the sprints.

4.1.3 Daily Sprint Planning

This phase contains daily meetings with supervisor to discuss and share the problems
and difficulties being faced during the FYP, and it also includes the discussion about
future of our FYP.

4.1.4 Next Sprint Planning

In this phase the things which would come under discussion would be the ways how
to improve the development or implementation process of the FYP in terms of time
management, team management, teamwork and how to write/ develop more user-
friendly code as well.
 33

4.1.5 Testing and sprint demonstration

The team demonstrates the results of their current sprint by creating a review.
Supervisor takes a decision about further project changes after examining the
demonstration.

4.1.6 Retrospective and Next Sprint Planning

In this phase sprint's result will be discussed by supervisor and determine the ways
how to improve development process. After this next sprint planning will be started.

4.2 Implementation

Implementation phase illustrates design development.

4.2.1 Tools Used

The following tools are used in Smart FYP Manager to extend its functionality:

4.2.1.1 Visual Studio Code

Visual Studio Code editor tool for writing code in different programming languages.
It is a powerful text editor containing plug-ins, clever auto-completion, and many
other features.

4.2.1.2 Visual Paradigm

Visual Paradigm for is used for designing purpose. Visual Paradigm is a famous
platform for deigning UML diagrams.

4.2.1.3 Adobe photoshop

Adobe Photoshop is used in this project for designing interfaces.

4.2.2 Hardware Used

"Smart FYP Manager" is a web-based platform is developed by using DELL Latitude

E6220 containing operating system Microsoft Windows 10 Education. Specifications
of the laptop are mentioned below:
 34

 (RAM) 8GB
 500GB ROM
 Processor Intel Core i5

4.2.3 Technical Aspect of Smart FYP Manager

Since the " Smart FYP Manager " is a web-based platform, both web server and
database management system are necessary. A high-level system architecture diagram
is illustrated below.
The system consists of front-end and back-end and is categorized into five layers.

4.2.3.1 Front End Technologies

Table 4.16: Front End Technologies

Technology Major functions on a web page

HTML Outline the structure of a web, it serves as the building blocks

CSS Set the visual style to provide a better user interface

JavaScript Provide interactive elements

4.2.3.2 Back End Technologies

Front end Smart FYP Manager L5 Application Layer

Web Server L4 Web Server Layer

MongoDB L3 Database System

Back end

Windows L2 Operating System

Hardware L1 Hardware Layer

 35

Figure 4.28: Structure of Back End Technologies

The details of each layer in the architecture above figure discussed below.
L0: Hardware layer contains necessary hardware (Personal Computer) for the
Smart FYP Manager to deploy.
LI: Smart FYP Manager will deploy under the Windows operating system, which
operated above the hardware layer
L2: MongoDB is chosen as the database system. It is non-relational database system
that is renowned for its reliability and data integrity.
L3: The Smart FYP Manager uses the Node JS as its back-end system.
 36

CHAPTER 5

RESULTS AND DISCUSSIONS (or USER MANUAL)

5.1 Getting Started

Smart FYP Manager is a web-based platform which provides communication between
supervisor, students and FYP coordinator.

5.2 User Access, Roles, and Privileges

The users of the application are the Supervisors, Students and FYP coordinator of
university. " Smart FYP Manager" require authorization. All supervisors and groups
will get their credentials from FYP coordinator.

5.2.1 FYP Coordinator Roles

 FYP coordinator will register Supervisor and Groups
 FYP coordinator will register Batch of FYP
 Keep track records of weekly logbook.
 FYP coordinator will send announcement to Groups and supervisors regarding
their projects.
 FYP coordinator will attach template format of projects.

5.2.2 Supervisor Roles

 Supervisor will give marks of documentation on portal.
 Supervisor will only see announcement from FYP coordinator.
 Supervisor will see their groups.
5.2.3 Student Role
 Student will see their result of documentation. Group will upload their FYP
documentation on portal.
 Student will fill their weekly logbook.
 Student will get announcement from FYP coordinator.
 37

5.3 Smart FYP Manager View

5.3.1 Smart FYP Landing Page

Figure 5.29: Landing Page

5.3.2 FYP Coordinator View

Figure 5.30: Admin Login Page

 38

Figure 5.31: FYP Coordinator Side Bar View

Figure 5.32: FYP Coordinator Sending Alert

 39

Figure 5.33: FYP Coordinator Notification View

Figure 5.34: FYP Coordinator Assignment Mark view

Figure 5.35: FYP Coordinator Adding Previous FYP

 40

Figure 5.36: FYP Coordinator Added Project View

Figure 5.37: FYP Coordinator See All Supervisor View

 41

Figure 5.38: FYP Coordinator Edit All Supervisor View

Figure 5.39: FYP Coordinator Add New Supervisor View

Figure 5.40: FYP Coordinator Edit all Students View

 42

Figure 5.41: FYP Coordinator Add New Student View

5.3.3 Supervisor View

Figure 5.42: Supervisor Side Panel View

 43

Figure 5.43: Supervisor View all supervisor

Figure 5.44: Supervisor My Student View

 44

5.3.4 Students View

Figure 5.45: Student Side Panel View

Figure 5.46: Student View all Announcement

 45

Figure 5.47: Student my Submission View

Figure 5.48: Student my Supervisor View

 46

CHAPTER 6

CONCLUSION AND RECOMMENDATIONS

This project's goal was to give Bahria University a system that would enhance
communication and learning processes. Under tight usability constraints, the
development largely focused on the application's usability and the user's functional
requirements. Early in the project, it became clear that a useful solution needed a
database to power the application's content.
The system's satisfactory completion of the user's usability and functional
requirements led to their adoption. The success of the project is demonstrated by the
rollout of this application on a local server. However, the application's user testing
and review revealed areas that may be expanded and improved. Even though all user
requirements were met. Therefore, the programme might be improved to include more
features and provide the user more power.
 47

REFERENCES

Books:

Jeffrey L. Whitten, System Analysis and Design Methods, 7th Edition, McGraw Hill,
New York, 2007 [1]

Technical Report and Theses:

Paul Chapman, Software Engineering with Web Development Frameworks, BSc
Computer Science Final Report, University of Leeds, Minerva, 2007 [2]
Gary Ingham, A Content Management System to support small sports clubs, BSc
Computing (Industry) Final Report, University of Leeds, Minerva, 2006 [3]

Internet:
"System Development Methodologies for Web Enabled E-Business: A Customization
Paradigm"; Linda Night, Theresa Steinbach, and Vince Kellen; November 2001;
(http://www.kellen.net/SysDev.htm)
 48

APPENDICES

Requirement List

R1: GUI should be compatible with Chrome and Mozilla both.

R2: Components of the project code will be tested alongside the implementation
phase to ensure that they are functional.
R3: Final, integrated project code will test to ensure that complete project is integrated
well and functioning properly.
R4: Display all the content after loading of web page.
R5: Server response should be kept in mind while designing data retrieval algorithms.

FYP Coordinator Module Requirement List

R1: FYP Coordinator is the admin of the system.

R2: To login FYP Coordinator have their Access.
R3: Generate group key and password.
R4: Generate FYP Batch
R5: Provide Login to supervisor.
R6: Create notification.
R7: Keep Track through Logbook.

Supervisor Module Requirement List

R1: Supervisor login

R2: Give marks of documentation.
R3: Supervisor will see their groups.
Student Requirement List
R1: Student login
R2: Upload their documentation.
R3: Receive Notification from FYP coordinator.
R4: View their marks of documentation.
R5: Write their weekly logbook.