Tribhuvan University

Faculty of Humanities and Social Sciences

BDMS: BLOOD DONATION MANAGEMENT SYSTEM

A PROJECT REPORT

In partial fulfillment of the requirements for the Bachelors in Computer Application

Submitted to
Department of Bachelors in Computer Application
Model Campus Damak
Damak, Jhapa

Submitted by
Suman Sitaula
Pranish Dulal

Under the Supervision of

Mr. Randhir Singh
 Tribhuvan University
Faculty of Humanities and Social Sciences
Model Campus Damak

SUPERVISOR’S RECOMMENDATION

I hereby recommend that this project prepared under my supervision by Pranish Dulal
and Suman Sitaula entitled “BDMS” in the partial fulfillment of the requirements for
the degree of Bachelor of Computer Application is recommended for the final evaluation.

SIGNATURE
Randhir Singh
SUPERVISOR
Bachelor of Computer Application
Damak, Jhapa
 Tribhuvan University
Faculty of Humanities and Social Sciences
Model Campus Damak

LETTER OF APPROVAL

This is to certify that this project prepared by Pranish Dulal and Suman Sitaula entitled
“BDMS” in the partial fulfillment of the requirements for the degree of Bachelor in
Computer Application has been evaluated. In my opinion it is satisfactory in the scope
and quality as a project for the required degree.

....................................
........................................

Program
Supervisor
Co-ordinator
Mr. Randhir Singh
Model Campus Damak
Bachelor of Computer
Application Damak, Jhapa
Damak, Jhapa

........................................
........................................ Internal Examiner
External Examiner
 ACKNOWLEDGEMENT

In the accomplishment of this project successfully, many people bestowed upon us their
blessings and the heart pledged support, this time we are utilizing to thank all the people
who have been concerned with this project.

We would like to thank our supervisor Mr. Randhir Singh sir whose valuable guidance
has been the ones that helped me patch this project and make it full proof success. Their
suggestions and instructions have served as the major contributor towards the completion
of the project.

Yours sincerely,
Pranish Dulal,
Suman Sitaula
 ABSTRACT
● Blood Donation Management System (BDMS) is an innovative project designed
to streamline the organization, management, and operation of blood donation
processes. It serves as a comprehensive platform that connects donors and blood
banks, facilitating real-time tracking of blood inventories and improving the
efficiency of donation drives. The system automates donor registration, visibility,
blood amount. Additionally, BDMS offers robust data management capabilities,
enabling healthcare organizations to maintain accurate records of donor history,
blood type compatibility, and donation frequency, contributing to safer and more
efficient blood transfusions. By integrating these functionalities, the BDMS
enhances the overall accessibility and transparency of blood donation services,
ultimately saving lives.
 TABLE OF CONTENTS
Contents
BDMS a BLOOD DONATION MANAGEMENT SYSTEM................................................................................ 1

SUPERVISOR’S RECOMMENDATION..............................................................................................................1

LETTER OF APPROVAL...................................................................................................................................... 2
ACKNOWLEDGEMENT......................................................................................................................3
ABSTRACT.............................................................................................................................................4
TABLE OF CONTENTS........................................................................................................................5
LIST OF FIGURES................................................................................................................................ 7
LIST OF TABLES.................................................................................................................................. 8
CHAPTER 1: INTRODUCTION..........................................................................................................1

1.1 Introduction................................................................................................................................................. 1

1.2 Problem Statement.......................................................................................................................................2

1.3 Objectives..................................................................................................................................................... 2

1.4 Scope and Limitations................................................................................................................................. 3

1.4.1 Scope......................................................................................................................................... 3
1.4.2 Limitations................................................................................................................................ 3

1.5 Report Organization.................................................................................................................................... 3

CHAPTER 2: BACKGROUND STUDY AND LITERATURE REVIEW....................................... 5

2.1 Background Study....................................................................................................................................... 5

2.2 Literature Review.........................................................................................................................................5

CHAPTER 3: APPLICATION ANALYSIS AND DESIGN............................................................... 7

3.1 Application Analysis.................................................................................................................................... 7

3.1.1 Requirement Analysis............................................................................................................... 7
i. Functional Requirement................................................................................................................. 7
ii. Non-Functional Requirement......................................................................................................... 9
3.1.2 Feasibility Analysis...................................................................................................................9
3.1.3 Data Modeling (ER-Diagram).................................................................................................10
3.1.4 Process Modeling (DFD)........................................................................................................ 12
3.2. Application Design.................................................................................................................................... 14
3.2.1. Architectural Design.............................................................................................................14
[Link]. Login/Signup flowchart.................................................................................................... 15
CHAPTER 4: IMPLEMENTATION AND TESTING....................................................................... 18

4.1. Implementation.......................................................................................................................................... 18
4.1.1. Tools Used (CASE tools, Programming language, Database platforms).............................18
4.1.2. Implementation Details of Modules (Description of procedures/functions)........................18
∙ Registration Module:....................................................................................................................19

∙ Login Module:..............................................................................................................................19

∙ Admin Module:............................................................................................................................ 19

∙ User Module:................................................................................................................................19

∙ Donor Module:............................................................................................................................. 19

∙ Add and Manage BloodGroup module:....................................................................................... 19

∙ Manage Pages module:.................................................................................................................20

∙ Poll(create,manage,view) module:............................................................................................... 20

∙ View Blood request module:........................................................................................................ 20

∙ Manage Blood storage module:....................................................................................................20

Test Case for User Registration...........................................................................................................20

Test Case for Admin Login................................................................................................................. 22
Test Case for Login User.....................................................................................................................23
CHAPTER 5: LESSON LEARNT CONCLUSION AND FUTURE RECOMMENDATIONS... 25

5.1. Lesson Learnt / Outcome.......................................................................................................................... 25

5.2. Conclusion................................................................................................................................................. 25

5.3. Future Recommendations......................................................................................................................... 25

REFERENCES......................................................................................................................................26

APPENDIX
 LIST OF FIGURES

Figure 3.1: Waterfall Methodology 6

Figure 3.2: Use Case of BDMS 8
Figure 3.3: Gantt chart for BDMS 10
Figure 3.4: Entity Relationship Diagram for BDMS 11
Figure 3.5: Context Diagram of BDMS 12
Figure 3.6: Level 1 DFD of BDMS 13
Figure 3.7: Application architecture 14
Figure 3.8: Flowchart of login process BDMS 16
Figure 3.10: Database Schema of BDMS 19
 LIST OF TABLES

Table 4.1: Test Case for User Registration 22

Table 4.2: Test Case for Admin Creation 23
Table 4.3: Test Case for Admin Login 23
Table 4.4: Test Case for User Login 24
Table 4.5: Test Case for Blood Donating 25
Table 4.6: Test Case for adding new product 25
 LIST OF ABBREVIATIONS

XML Extensible Markup Language

CRUD Create, Read, Update and Delete
DFD Data Flow Diagram
ERD Entity Relationship Diagram
HTML Hyper Text Markup Language
DB Database
Auth Authentication
 CHAPTER 1: INTRODUCTION

1.1Introduction

The global reach of blood donation management system allows the needy and donors to
overcome geographical constraints and help each other anytime from anywhere over the
internet. Although physical presence is required, the information reach allows the user or
the needs of the blood to access it easier and faster. This is not a profit-oriented software
but a service-oriented software. The online management helps users to reach the
essentials of the blood faster. The use of BDMS will make it faster as there is no need for
the assumption of the presence of blood and sometimes due to the absence of this time lag
we can save a couple of lives. Although this BDMS covers a single red cross organization
of a small periphery or surrounding, implementing it all over the country will be more
profitable and sharing the data across every organization will make it more reachable. The
numbers of internet users have grown rapidly over the past years, with this is mind it is
fairly simple to imagine that people sooner or later would want a platform where they will
be able to find and interact with such information remotely(with the use of internet). This
is where BDMS comes being able to provide then a place where they can freely look over
the information about the presence of the required blood or the donors around them
through the use of websites.
1.2Problem Statement

The search for blood has always been a crucial activity to most people in the country and
in the whole globe. The requirement of blood is always at a crucial moment such as
accidents, surgery and many others dangerous incidents. In such moments people can’t
even think straight due to the rush. We have come across many situations where people
lost their life merely because of blood. This is because of the lack of information to the
people. Blood is stored in the red cross instead of hospital. During the need of blood,
collaborating with the doctors and hospital it will be more effective. Imagine a situation
where the person who’s very close to you is hurt and in need of the blood. You hurried
there and the required blood group is not available. This is what has caused the death of
some patients. The lack of information about such crucial thing is not acceptable.
Moreover, the BDMS not only provides the information but does much more.
There are many campaigns organized by the red cross society but due to the busy
schedule of the people the donors cannot attend it. We have solved this problem by
creating a poll system where you can give multiple option to take opinion for the
information. Also, the people don’t get recognized and their good work are thrown to the
shadow. This system has solved the problem by highlighting their deeds in the internet.
This system also provides the certificate to the donors on issuing with a single click.

1.3Objectives

The general objective of this project is to develop an online web-App which will provide
a interface to create a proper communication between the blood donor, requirer and the
red cross society including the maintenance inside the organization .

The prior objective of the designated website would be:

● Create an online platform for the maintenance of the red cross organizations.
● To provide an effect communicating medium for the Blood requirer and donor.
● To implement and test the workability of the newly developed web-app.
1.4Scope and Limitations

1.4.1 Scope

The project aims to create an application which will allow the user to connect with the
blood donor and the red cross society in need of blood. Some of the scopes are as follow:

● You can request for blood of any blood group to the administrator and the donor.
● You can become a donor too with the required details and certificates.
● Any (Authorized, Guest) user can use this Application
● Build a user-friendly application.

1.4.2 Limitations

There are some criteria that may not be fulfilled by our application implemented. Some of
such limitations of our project are mentioned below:

● The cloud makes it slow.

● Limited data security measures applied.
● It’s only supported through websites.

1.5 Report Organization

⮚ Chapter 1: Introduction of the project along with project scope limitations and

objectives are described.

⮚ Chapter 2: Background study related to the project along with general

descriptions of project functions and components. Literature review in order to

have broader understanding of the project concepts based on research done
previously and analyze similar Applications for comparison with project.

⮚ Chapter 3: Application Analysis and Design of the Application using various

charts and figures. Functional requirements defined using use case and other
techniques. ER diagram, DFD, database schema diagrams included.
⮚ Chapter 4: Tools and techniques used for project implementation along with

algorithm used in the project and creation of test cases to test the Application
as a unit and as a whole.

⮚ Chapter 5: Lessons learnt from start to finishing the project, future

recommendations for other projects and project conclusion.

 CHAPTER 2: BACKGROUND STUDY AND LITERATURE
REVIEW

2.1 Background Study

Blood is necessary for several treatments and surgeries, and still a limited resource. The
need for the blood is about ten million units per year in the USA, 2.1 in Italy and 2 in
Turkey; moreover, people still die in some countries because of inadequate supply of
blood products.(World Health organization 2014).Blood Donation plays a fundamental
role in healthcare systems, aiming at guaranteeing an adequate blood availability to meet
the demand and save lives. Blood is collected from the donors, i.e., unpaid individuals
who give their blood voluntarily. The amount of death sue to the scarcity of the blood is
rising. It is often heard that the time is the essence instead of the availability of the blood.
We can’t reach to the donor at the time of demand that cause the loss of the valuable lives.
Blood donation system is divided in four phases collection, transportation, storage and
utilization. The utilization and collection are difficult to achieve.
This project shall handle this issue by creating an online platform where the utilization of
the blood and the collection of the blood is effective. The availability of the donors
through the address makes the project more flexible. Similarly, the campaigns according
to the polling system is always been more effective.
The application has to be secure enough so that users won’t be afraid if the information is
genuine or not. The admin can manage, edit and delete and can perform many other
functionalities which gives clients a reassurance but also does increase the load of the
admins.

2.2 Literature Review

Blood donation system requires precautions for providing the information and
functionalities as a person whole life depends on the blood availability in the expected
area. As mentioned above it requires four steps in a pipeline fashion to be able to use
which makes it more crucial than it is. A successful Blood Donation should meet the daily
demand of blood and follow its temporal pattern. According to Sundaram and Santhanam
(2011), BD supply chain and the related management problems can be classified on the
main phases of a blood bag life: donor registration, blood collection, blood
Screening/evaluation, inventory storage and delivery. But according to Pierskalla(2004),
the management of BD supply chain concerns both strategic decisions ( e.g. location of
blood centers ) and tactical operational decisions (e.g. production of multiple products ,
control of inventory levels , blood allocation and delivery). Many Paper address the
management of BD supply chain (Belien and Force): however, there are still some open
issues.

Since screening is done through the expertise and cannot be done with the system without
human manpower it is not included in our MGMT System. Except this we have done our
best to cover the whole process/phases. Some of the similar running websites are:-
HamrolifeBank: HamrolifeBank is the popular site of Nepal that too provides the blood
upon request. They use the same method: allows communication between the user and the
donor. Some of the functionalities are:-
● They uses the geographical location through API that makes it more effective
● They provide android and ios app too.
● It is multi-lingual website. English and Nepali
E-raktakosh: E-raktakosh is another website that have the same functionalities. It is also
popular website of India. The minimum content in a page makes it look better than other
websites. They have put high emphasis on the UI that makes it easier to navigate through
their page. Some of the key functionalities of [Link] are:
● You don’t need to login to access the blood.
● Every information is spot in the first glance.
● Simple and effective UI.
● Faster than other sites.
[Link]: The red cross blood website is much more than the BDMS software.
It assigns the roles to the user. The roles differ from Leader to volunteer to general user. It
offers Other multiple biomedical services too. Some key functionalities of redcross blood
are:-
● Plain UI
● Huge Density
● Difficult to navigate
● Covers wide range of scope

What our Application BDMS does which are not done by these Applications is the
hosting it on a local base. Another key feature of BDMS is that every page and
component in this app is dynamic that provides higher room of flexibility.
 CHAPTER 3: APPLICATION ANALYSIS AND DESIGN

3.1 Application Analysis

As the requirements are very well known so waterfall model is use in this project.
Requirements are already known so design is carried out according to the requirement.
After the design process, coding and development part is started. With the starting of
coding part, testing is also done in the Application. After the Application is tested fully
the Application come in operation otherwise maintenance is done.

Figure 3.1: Waterfall Methodology

3.1.1 Requirement Analysis

To design and develop Application, functional as well as non-functional requirement

of the Application has been studied as given below:

i. Functional Requirement

These are the requirements that the website fulfills. It shows outlines of workflows
performed by the website.

For Users

● Users can Request to donor

● Users can look at the inventory.
● Users can Submit poll.
 ● Users can take part in donation.
● Users can send query through the contact page.

Use Case Representation:

In the given use case, there are two actors they are: admin and donor. There are use cases
which is use by the actor and represented by the use arrows. Admin can do majority if
stuff such as add new poll, add blood group, manage other users, display the poll info,
verify user etc. The donor with limited cases where they can signup/login and view
different pages and request as per their need.

Figure 3.2: Use Case diagram of BDMS

ii. Non-Functional Requirement

The website must be user-friendly which means customers must not feel difficulty
while using it. In addition to these requirements, the website has embraced the
following requirements:

⮚ Performance: The Application is hosted on local host so the Application

response time is quick. The database is also centrally hosted with limited data
so there is little performance drop when using the Application.

⮚ Security: In terms of security, only basic data security measures are followed.

Only admin has access to backend so it is safe from unauthorized user access.

⮚ Maintenance: The Application is not to use as it is developed keeping both

technical and non-technical users in mind so maintaining the Application is not

complicated.

⮚ Availability: This Application is available in online only.

3.1.2 Feasibility Analysis

Under the feasibility study, technical feasibility, operational feasibility, economic

feasibility and schedule feasibility are studied and performed.

i. Technical Feasibility Study: To design this Application, it uses off-self and

existing technologies, software, and hardware so there is no technological
hurdle to build this Application. There is no need of a bunch of technical
people; a team of two can easily work for the development of the website.

ii. Operational Feasibility Study: This Application can be easily operated as

well as implemented so it can be operational feasible. Also, users with little
knowledge of websites can operate easily which makes the website operable.
 iii. Economic Feasibility Study: The Application does not require extra software
and hardware i.e., it uses open-source technologies. So, there is no recurring
cost than just the internet connection. Also, because it can work on any mobile
devices and desktops with internet connection, no additional cost is to be made
for devices.
iv. Schedule Feasibility Study: The time frame to develop the Application was
adequate. Around three months’ time to create a Application was divided into
pairs with two and half hours spent by each member daily on the project.

Figure 3.3: Gantt chart for BDMS

3.1.3 Data Modeling (ER-Diagram)

In the given figure, there are three entities which are admin, user and products. Only a
limited ER-Diagram was made in order to make sure that the documentation maintains its
simplicity and readability to even non-tech students. Each entity has its own attributes
such as the entity donor has attributes such as ID, fname, lname, email and passcode. The
entity poll has attribute ID, question, value1, date, , option1. Entity donor has attributes
uid, name, email, password, joined date.
Figure 3.4: Entity Relationship Diagram for BDMS
3.1.4 Process Modeling (DFD)

Data Flow Diagram of BDMS Application consists of three levels of DFD level 0 DFD
and level 1 DFD.

In the given diagram, the external entities are admin and user. Admin first login the
Application and process to get details of the products and manages the products as needed
like adding a new poll to the page. Then the user logins/signup to the Application and
does his part.

Figure 3.5: Context Diagram of BDMS

The DFD level 1 diagram has three entities: admin, user and product. Each entity has
different roles, admin logins in the Application and manages various actions such as add
product, modify product and delete product. Since he is the one who has access to
database almost all actions made by the admin are stored in the database. Products are
entity which are simply added by the admin onto the auction, the admin performs various
actions on them. Users are the entities who logins/signups to the Application and views
the different pages including the poll submission and send blood requests.
Figure 3.6: Level 1 DFD of BDMS
3.2. Application Design

3.2.1. Architectural Design

For developing the Application, three tier architectural design is used. In the top level,
there is a user interface where the user can view the Application, and can-do login to the
Application. While doing login in the Application the data must be processed which is
handled by the application tier. The data is stored in the MySQL server. The data is stored
and manage in data tier

Figure 3.7: Architectural design of BDMS

[Link]. Login/Signup flowchart

In the given figure, The login process of both admin and user is shown. The user must
register first if he/she has not registered before then the user can login using the email and
password used by him during the creation of the id. The Application first checks if the
user has an account or not if he does then he is allowed to login else he must signup first.
The login process goes through an authentication process which checks where the user is
valid or not. If the user is valid then he/she is allowed to enter the Application and
perform the activities that they desire. The authentication process checks the database if
the username and password provided by the user matches the one that is in the database.
Figure 3.8: Flowchart of BDMS
 3.2.3. Database Schema:

The following picture represents the complete schema of our Application. The schema contains
full representation of the database and tables that it contains.

Figure 3.10: Schema design

 CHAPTER 4: IMPLEMENTATION AND TESTING

4.1. Implementation

4.1.1. Tools Used (CASE tools, Programming language, Database platforms)

⮚ Sublime Text 3: Entire coding of the Application is done in the sublime text.

Sublime Text 3 is used for managing files easily and debugging errors faster. With
the help of built-in plugin available in Sublime Text 3 code were managed
properly for easy understanding.

⮚ HTML, CSS and Bootstrap: HTML, CSS and bootstrap is used for making

frontend of the Application. HTML is used for creating different webpage of this
Application like headings, sections, paragraphs using different tags. CSS is used
for to design the different component by using class and id Bootstrap is used to
design overall portal by extending tags from existing library.

⮚ JavaScript: JS is used in this Application to make a Application dynamic,

responsive and interactive. JS is also used to add events and triggers to the web
portal. It is also used to for client-side validation.

⮚ PHP with MySQL: PHP used for server-side scripting validation and purpose to

add connectivity to the database. MySQL is used to store data of all users,
employee, admins and their activities. With the help of PHP with MySQL CRUD
operation such as create, read, update and delete is performed.

⮚ XAMPP Server: XAMPP server is used to run php files, using mail server to

verify email and creating fast and dynamic web pages. XAMMP server is also
used for connectivity of MySQL database to perform CRUD operation.

4.1.2. Implementation Details of Modules (Description of procedures/functions)

In this project, there are many modules which describe information of the module and
supported component. The modules are described below:
● Registration Module:
Registration module is the main thing in the Application. Without registration
user cannot enter in the Application and cannot use the service of the
Application. After the registration user and got their username and password,
by using username and password they can enter into the Application.

● Login Module:
For entering the Application either username or admin have to login first with
their email and password respectively. Once you have login into the
Application then, email and password will save in session until and unless
session or caches are not cleared user will not have to login next time. Once
user clear he caches or logout the Application then next time they have to
login the Application again.

● Admin Module:
Admin manages the Application. Admin manages the most of site such as
viewing, modifying and deleting records. The blood groups, poll is created by
admin. And the further management of the such options are managed by
admin. Not only the online but admin has to act offline too for BDMS.

● User Module:
User can request the blood without registering. The poll in the inventory too
can be submitted by providing name and address. The request is thus
responded by either admin or donor as per the request.

● Donor Module:
Donor can respond to the request sent by the user. The donor can perform
attend action that allows the donor to reach the required person. Donor can
also issue the certificate of the donor as per the records performed by him. He
can set his status to active or inactive. Donor too can participate in the poll.

● Add and Manage BloodGroup module:

This action is performed by the admin which allows the admin to add blood
group in the database that user can view and register. The Blood Group can be
managed in the manage blood group where the admin can delete the
BloodGroup.
 ● Manage Pages module:

The admin has access to this module which allows the admin to update the
about us page and contact us page content which can be viewed by the guest
user and the donor.

● Poll(create,manage,view) module:

The admin has access to this module which allows the admin to create manage
and view the poll.

● View Blood request module:

When the user request for blood he can either request to the admin or to the
donors. This allows the admin to view the blood request. The request sent to
donors and admin are viewed separately and whether it is attended or not is
shown on the status.

● Manage Blood storage module:

The blood amount in pound stored in the organization is shown in the

inventory page. The information of the blood storage is managed by admin
where either the amount of blood is either subtracted or added by the admin.

Test Case for User Registration

In T01, user enter full name, email and password, if all the data is entered then it goes to
store in database and directed to the home page, but in T02 there is missing the data to fill
up so Application will not let to enter in the profile page and display the message as all
field are required to enter. For successfully entering in Application the users have to fill
the data correctly.

Table 4.1: Test Case for User Registration

Test Test Test steps Test data Expect Actual Pass/Fail

case scenario ed Result
Result
T01 Check Enter name Full name: Sagar Goes As Pass
registrati Enter mobile No:9824094476 directly expected
on with no Email: to the
valid data Enter email Sagar@gmail.c profile
address om page.
Enter Age Age:24
Select Gender Gender:Male
Select BG:A+
BloodGroup Address:Damak
Enter Address Message:Hi
Enter Message password:
Enter admin
password Image:[Link]
Select image Profile:[Link]
Select profile
Enter signup
button
T02 Check Enter Email: Messag As Pass
registrati email krisha@gmail.c e shows expected
on with address om like all
invalid password: field are
data Enter password required
admin
Enter signup to fill.
button
Test Case for Admin Login

In T04 admin enters email and password and after checking in database success message
is displayed and logged in. If admin wants to login the Application, then admin have to
enter the verified email and same password which is created either during the Application
creation or created by another user. In T05 admin enter email and password and after
checking in database, displayed a message as incorrect password and cannot login.

Table 4.3: Test Case for Admin Login

Test Test Test Steps Test Data Expected Actual Pass/Fail

case scenario Result Result
id
T04 Check 1) Ente Username: admin Admin As Pass
r
admin passwords: should be expected
username
login Test@123 login and
2) Enter
with directed
password
valid to the
3) Clic
data dashboard
k
Login
Test Test Test Steps Test Data Expected Actual Pass/Fail
Case scenario Result Result
id
T05 Check 1) Enter Username: admin Error As Pass
admin email Passwords:abcd12 message expected
login 2) Ente should be
with r displayed
invalid password and
data 3) Click stayed in
login
button same page

Test Case for Login User

User enter email and password and after checking in database success message is
displayed and logged in. If the user forgot their email and password or enter wrong email
or password then user cannot login. If user try to login with invalid data then Application
display message as wrong password or wrong email and stayed in same page. User who
does not have create account before wants to login the Application then the Application
displays a message as not as sign up first.

Table 4.4 : Test Case for User Login

Test Test Steps Test Data Expected Actual Pass/Fail

Test scenario Result Result
case
id
Check Email: Success As Pass
T06 login 1) Enter Sagar@gmai message expected
of user email and [Link] should
password Password: display.
admin
2) Click
login
button
Check 1) Enter email Email: Error As Pass
T07 user 2) Enter Sagar@gmai message expected
login password [Link] should
with 3) Click Password: display
invalid login admin123 and stay
data button in same
page
T08 Check 1. Enter email Email: Error As pass
whether 2. Enter sabinn@gm message expected
user have password ai [Link] display as
created 3. Click login not
account button Password: a
or not syvan123 member
 CHAPTER 5: LESSON LEARNT CONCLUSION AND
FUTURE RECOMMENDATIONS

5.1. Lesson Learnt / Outcome

As the completion of the project, we have a simple good-looking website whose interface
is user-friendly to everyone. Users are able to send the blood request to either donor or
the admin that will reduce the workload and make the crucial situation better by providing
the information of the donor around the country/globe.

5.2. Conclusion

The project was started to make the process of managing the blood donation system. This
idea was struck to us during the pandemic where we are unable to communicate with
other people and blood donation were very risky. The post important part of website is to
provide a digital platform for both the requirer and donor to supply and receive the blood
during emergency.

5.3. Future Recommendations

Some of the enhancement that can be made in the project in the future can be as follows:

● Login through Social Media can be added to website.

● Adding feature of Chat Application.
● Able to add a game that could engage the user
● Add small quality of life changes that might make the viewing experience better
 REFERENCES

[1] " Belien and Force " [Online]. Available:

[Link]

[2] " Sundaram and Santhanam (2011)," [Online]. Available:

[Link]
_blood_donor_classification_data_mining_models
[3] "E-raktakosh - Wikipedia," [Online]. Available:
[Link]
[4] "[Link] - Wikipedia," [Online]. Available:
[Link]

[5] "Hamrolifebank - Wikipedia," [Online]. Available:

[Link]
[6] "Stack overflow," [Online]. Available: [Link]

[7] "Git hub," [Online]. Available: [Link]

 APPENDIX

HOME PAGE

LOGIN PAGE
REGISTER PAGE
 Inventory

Admin panel