QBD_1464843125535 - Copy

A
Project Report
on
QUICK BLOOD DONATE(QBD)
Bachelor’s of Engineering
in
Computer Department
Submitted by
Mr.Bhavesh N. Jangale ( B120274228)
Miss. Tejal D. Mhaske ( B120274243)
Mr. Sunil S. Musale ( B120274245)
Mr. Sahil D. Salunke ( B120274254)
Under the Esteemed Guidance of
Prof. D.S.Thosar
For Academic Year
2015-16
DEPARTMENT OF COMPUTER ENGINEERING

CERTIFICATE
This is to certify that the Project Entitled
QUICK BLOOD DONATE
Submitted by
is a bonaﬁde work carried out by Students under the supervision of Prof. Guide
Name and it is submitted towards the partial fulﬁllment of the requirement of
Bachelor of Engineering (Computer Engineering).
Prof. D.S.Thosar Prof.S.M.Rokade
Internal Guide H.O.D
Dept. of Computer Engg. Dept. of Computer Engg.
Dr. S.A.Patil
Principal
S.V.I.T.Nashik
Signature of Internal Examiner Signature of External Examiner

PROJECT APPROVAL SHEET
A Project Title
(QUICK BLOOD DONATE)
Is successfully completed by
at
SIR VISVESVAEAYA INSTITUTE OF TECHNOLOGY,CHICHOLI
SAVITRIBAI PHULE PUNE UNIVERSITY,PUNE
ACADEMIC YEAR 2015-2016
Prof. D.S.Thosar Prof.S.M.Rokade
Internal Guide H.O.D
Dept. of Computer Engg. Dept. of Computer Engg.
2

ABSTRACT
Blood donation is a voluntary activity in the INDIA and provides critical blood
units for transfusions. Blood is collected, processed and transported by blood centers
to hospitals, though some hospitals also collect blood directly from donors. Blood
donation is very safe, but a small percentage of donors can have reactions and some
of these reactions can lead to serious injury. Donors hemovigilance is the surveillance
and analysis of donor reactions with the goal of understanding the factors inuencing
reactions and identifying steps to improve donor safety . Historically in U.S., donor
hemovigilance is managed by individual collection centers to improve their speciﬁca-
tion organizations donation processes.In todays system, supply is less while demand
is more in this industry, so we are trying to increase the supply to meet the demand
by providing a platform for everyone included in this supply chain. In the hospital,
most of the cases, when blood is required, that could not be provided on time causing
unpleasant things. Though donor is available hospital is unaware of it, and donor too.
So to resolve this a communication between hospital, blood bank, donor, and accepter
is important. So we come up with a system providing solution to this. In this system
we will make sure that also in the worst case the blood will be made available to the
patient. There will be three levels. The central blood bank, the smaller blood banks
and hospitals. This application will work on real time data of location, so probability
of getting correct donor is increased. We will be using MySQL so that in future we
can use new big data technologies introduced in next revisions of the product.
Index Terms-Blood donate,Blood Storage, Donors, GPS/GSM Tracking, Google Cloud
Messaging (GCM).
I

ACKNOWLEDGEMENT
It gives us great pleasure in presenting the preliminary project report on ‘QUICK
BLOOD DONATE’.
I would like to take this opportunity to thank my internal guide Prof. D.S.Thosar
for giving me all the help and guidance I needed. I am really grateful to them for their
kind support. Their valuable suggestions were very helpful.
I am also grateful to Prof.S.M.Rokade, Head of Computer Engineering Depart-
ment,S.V.I.T.Nashik for his indispensable support, suggestions.
In the end our special thanks to Other staﬀ for providing various resources such
as laboratory with all needed software platforms, continuous Internet connection, for
Our Project.
Mr.Bhavesh N. Jangale
Miss. Tejal D. Mhaske
Mr. Sunil S. Musale
Mr. Sahil D. Salunke
(B.E. Computer Engg.)
II

INDEX
Abstract I
Acknowledgement I
Index III
List of Figures VII
1 Synopsis 1
1.1 Project Title . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Project Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Internal Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.4 Sponsorship and External Guide . . . . . . . . . . . . . . . . . . . . 1
1.5 Technical Keywords (As per ACM Keywords) . . . . . . . . . . . . . 1
1.6 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.7 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.8 Goals and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.9 Relevant mathematics associated with the Project . . . . . . . . . . . 3
1.10 Names of Conferences / Journals where papers can be published . . . 4
1.11 Review of Conference/Journal Papers supporting Project idea . . . . 4
1.12 Plan of Project Execution . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Technical Keywords 6
2.1 Area of Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Technical Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Introduction 7
3.1 Project Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
III

3.2 Motivation of the Project . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Literature Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4 Problem Definition and scope 11
4.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1 Goals and objectives . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2 Statement of scope . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Major Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 Methodologies of Problem solving and efficiency issues . . . . . . . . 14
4.4 Outcome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.6 Hardware Resources Required . . . . . . . . . . . . . . . . . . . . . . 14
4.7 Software Resources Required . . . . . . . . . . . . . . . . . . . . . . . 15
5 Project Plan 16
5.1 Project Estimates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1 Reconciled Estimates . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.2 Project Resources . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Risk Management w.r.t. NP Hard analysis . . . . . . . . . . . . . . . 17
5.2.1 Risk Identification . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.2 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2.3 Overview of Risk Mitigation, Monitoring, Management . . . . 18
5.3 Project Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.1 Project task set . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3.2 Timeline Chart . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4 Team Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4.1 Team structure . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4.2 Management reporting and communication . . . . . . . . . . . 19
6 Software requirement specification 21
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1.1 Purpose and Scope of Document . . . . . . . . . . . . . . . . 21
6.1.2 Overview of responsibilities of Developer . . . . . . . . . . . . 21
6.2 Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2.1 User profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
IV

6.2.2 Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2.3 Use Case View . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3 Data Model and Description . . . . . . . . . . . . . . . . . . . . . . . 23
6.3.1 Data Description . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.3.2 Data objects and Relationships . . . . . . . . . . . . . . . . . 23
6.4 Functional Model and Description . . . . . . . . . . . . . . . . . . . . 24
6.4.1 Data Flow Diagram . . . . . . . . . . . . . . . . . . . . . . . . 24
6.4.2 Activity Diagram: . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4.3 Non Functional Requirements: . . . . . . . . . . . . . . . . . . 28
6.4.4 State Diagram: . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4.5 Software Interface Description . . . . . . . . . . . . . . . . . . 29
7 Detailed Design Document using Appendix A and B 31
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2 Architectural Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.3 Data design (using Appendices A and B) . . . . . . . . . . . . . . . . 31
7.3.1 Internal software data structure . . . . . . . . . . . . . . . . . 31
7.3.2 Global data structure . . . . . . . . . . . . . . . . . . . . . . . 31
7.3.3 Temporary data structure . . . . . . . . . . . . . . . . . . . . 31
7.3.4 Database description . . . . . . . . . . . . . . . . . . . . . . . 31
7.4 Compoent Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.4.1 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8 Project Implementation 34
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.2 Tools and Technologies Used . . . . . . . . . . . . . . . . . . . . . . . 34
8.3 Methodologies/Algorithm Details . . . . . . . . . . . . . . . . . . . . 34
8.4 Methodologies of Problem solving and eﬃciency issues . . . . . . . . 35
9 Software Testing 36
9.1 Type of Testing Used . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.2 Test Cases and Test Results . . . . . . . . . . . . . . . . . . . . . . . 37
10 Results 40
10.1 Screen shots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
V

11 Deployment and Maintenance 48
11.1 Installation and un-installation . . . . . . . . . . . . . . . . . . . . . 48
11.2 Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
12 Conclusion and future scope 58
Bibliography 59
Appendix A 60
Appendix B 64
Appendix C 67
Appendix D 68
Appendix E 69
VI

List of Figures
1.1 Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Risk Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 Timeline Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2 Data Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3 DFD0 Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.4 DFD1 Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.5 DFD2 Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.6 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.7 State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1 Architectural Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 32
7.2 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1 Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.2 Log In Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.3 Registration Window . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
10.4 Storage Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.5 Organization of Camp . . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.6 User Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
10.7 Vehical Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.8 Ambulance Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
VII

11.1 Welcome Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
11.2 Licence Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.3 Selection of Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
11.4 Assign Port . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
11.5 JRE Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
11.6 Installation Location . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.7 Conﬁguration setting . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
11.8 Ram Requirement Speciﬁcation . . . . . . . . . . . . . . . . . . . . . 55
11.9 Selection of Start Menu Folder . . . . . . . . . . . . . . . . . . . . . . 56
11.10Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
1 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2 Figure 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3 Figure 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4 Figurel 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5 Project Plan 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6 Project Plan2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
VIII

Chapter 1
Synopsis
1.1 Project Title
QUICK BLOOD DONATE
1.2 Project Option
Yes.by OPULENT PVT.LTD Nashik
1.3 Internal Guide
Prof. D.S.Thosar
1.4 Sponsorship and External Guide
yes
1.5 Technical Keywords (As per ACM Keywords)
Please note ACM Keywords can be found : http://www.acm.org/about/class/ccs98-
html
Example is given as
1. C. Computer Systems Organization
(a) COMPUTER-COMMUNICATION NETWORKS
i. Distributed Systems
A. Client/server
1

QUICK BLOOD DONATE
B. Blood donate
C. Blood Storage
D. GPS/GSM Tracking
E. Google Cloud Messaging (GCM).
F. Donors
1.6 Problem Statement
In most of the cases, when blood is required, that could not be provided on time
causing unpleasant things. Though donor is available hospital is unaware of it, and
donor too. So to resolve this a communication between hospital, blood bank, donor,
and accepter is important. So we come up with a system providing solution to this.
1. In this system we will make sure that also in the worst case the blood will be
made available to the patient. There will be three levels. The central blood
bank, the smaller blood banks and hospitals.
2. The central blood bank will supply to the smaller banks and they will supply
to the nearby hospitals as per requirement. There will be a web application.
1.7 Abstract
Blood donation is a voluntary activity in the INDIA and provides critical blood
units for transfusions. Blood is collected, processed and transported by blood centers
to hospitals, though some hospitals also collect blood directly from donors. Blood
donation is very safe, but a small percentage of donors can have reactions and some
of these reactions can lead to serious injury. Donors hemovigilance is the surveillance
and analysis of donor reactions with the goal of understanding the factors inuencing
reactions and identifying steps to improve donor safety . Historically in U.S., donor
hemovigilance is managed by individual collection centers to improve their speciﬁc
organizations donation processes.In todays system, supply is less while demand is
more in this industry, so we are trying to increase the supply to meet the demand
by providing a platform for everyone included in this supply chain. In the hospital,
most of the cases, when blood is required, that could not be provided on time causing
2
SVIT, Department of Computer 2015-16

QUICK BLOOD DONATE
unpleasant things. Though donor is available hospital is unaware of it, and donor too.
So to resolve this a communication between hospital, blood bank, donor, and accepter
is important. So we come up with a system providing solution to this. In this system
we will make sure that also in the worst case the blood will be made available to the
patient. There will be three levels. The central blood bank, the smaller blood banks
and hospitals. This application will work on real time data of location, so probability
of getting correct donor is increased. We will be using MySQL so that in future we
can use new big data technologies introduced in next revisions of the product.
1.8 Goals and Objectives
• Detecting Blood Storage.
• Produce an alarm and Broadcast Blood Requirement Messages local peoples.
• Provide User authentication by providing donor user name or ID.
• Live Tracking of Ambulance.
• Provide better communication between hospitals, blood banks, donor and ac-
ceptor.
1.9 Relevant mathematics associated with the Project
System Description:
• Let S be the — Quick blood donate as the ﬁnal set S
• Identify the inputs as D , Q, I, P
S = D, Q, I, P,
D = D1, D2, D3, D4, — D given database updates
Q= Q1, Q2, Q3, — Q gives the request by person or hospital needing blood
I = I1, I2, —I gives user ID for login
P= P1, P2, —P gives the respective password for login ID
• Identify the outputs as O
S = D, Q, I, P, N, R,
3

QUICK BLOOD DONATE
N = N1, N2, N3, N4, — N given Notifications for blood requirement
R= R1, R2 — R is the Response for the blood request
• Identify the functions as F
S = D, Q, I, P, N, R, F
F = F1(), F2(), F3(), F4(), F5()
F1( V ) :: Update Database
F2 ( V) :: Process Requests
F3 ( V ) :: Send notification
F4 ( T ) :: Respond to notifications
F5 ( D ) :: login
1.10 Names of Conferences / Journals where papers can be published
• International Journal of Computer Science and Mobile Computing, Vol. 4,
Issue. 10, October 2015, pg.87 89
1.11 Review of Conference/Journal Papers supporting Project idea
Literature Survey : The literature survey contains a summary of all the information
from books, journal articles, reasearch papers and internet that is relevant to the
development of project. Along with all literature survey police officers advise also
consider. Efforts are taken to have the brief overview and proper understandig of
software used in the designingof this system. This chapter has given the opportunity
to describe, un derstand and implement the basic concepts required for Criminal
Identification and Investigation System.
1. Blood donation is very safe in the U.S., but a small percentage of donors can
have reactions and some of these reactions can lead to serious injury. Donor
hemovigilance is the surveillance and analysis of donor reactions with the goal
of understanding the factors inuencing reactions and taking steps to improve
donor safety. HHS has developed the DonorHART tool that collects, organizes
and assists with t he analysis of donor reaction data reported from participating
blood centers and hospitals. Data mining is used to analyze factors inuencing
donor reactions and insights are shared with the community to help blood center
4

QUICK BLOOD DONATE
and hospital managers and quality improvement administrators undertake in-
terventions to improve donor safety.This paper presents two studies performed
on data reported to the DonorHART tool: multiple vasovagal reactions, and
delayed vasovagal reactions with loss of consciousness. Insights gained by per-
forming multivariate Logistics Regression (LR) modeling and Odds Ratio (OR)
calculations in terms of characteristics associated with multiple vasovagal reac-
tions and delayed vasovagal reactions are presented. The systematic collection
of donor hemovigilance data on a national level using data mining and analysis
can lead to interventions to improve donor safety.
2. To develop a web application as well as an android application for blood banks
and hospitals for quick availability of blood, which will also involve Donor and
acceptor directly.
1.12 Plan of Project Execution
Figure 1.1: Plan
5

Chapter 2
Technical Keywords
2.1 Area of Project
Networking and Database
2.2 Technical Keywords
• Blood donate
• Blood Storage
• GPS/GSM Tracking
• Google Cloud Messaging (GCM).
• Donors
6

Chapter 3
Introduction
3.1 Project Idea
In the hospital, most of the cases, when blood is required, that could not be
provided on time causing unpleasant things. Though donor is available hospital
is unaware of it, and donor too. So to resolve this communication between
hospital, blood bank, donor, and accepter is important. So we come up with a
system providing solution to this. In this system we will make sure that also in
the worst case the blood will be made available to the patient. There will be
three levels. The central blood banks, the smaller blood banks and hospitals.
The central blood bank will supply to the smaller banks and they will supply
to the nearby hospitals as per requirement. There will be a web application.
City Peoples who wish to donate blood but not able to because of the busy day
schedule they can eﬃciently donate blood from any place in the city with the
help of webpage which our system is providing for local citizens. Webpage will
help citizens to track ambulance from their current location and then they can
donate blood by simply contacting the nearest ambulance.
3.2 Motivation of the Project
In todays time there general blood donation systems were present. Blood do-
nation camps were arranged to fulﬁll the need of blood storage.there are some
websites present for donating blood were the phone numbers of the donors are
present which are not reliable since they dont get often updated. At present
there are no proper websites. There is no proper care of person who donates
blood to patients. That is the medical history about the donor is not available
7

QUICK BLOOD DONATE
with the website. If a donor has or had any medical problem comes forward to
donate blood to a patient then it may lead to threat. Proposed system is to
develop a web application for blood banks and hospitals for quick availability
of blood, this will also involve donor and acceptor directly. Analysed the Blood
Storage and further produce alarm and broadcast Blood requirement messages
to local peoples and handle blood storage and donation process in systematic
manner.
3.3 Literature Survey
The literature survey contains a summary of all the information from books, journal
articles, reasearch papers and internet that is relevant to the development of project.
Along with all literature survey police officers advise also consider. Efforts are taken
to have the brief overview and proper understandig of software used in the designingof
this system. This chapter has given the opportunity to describe, understand and
implement the basic concepts required for Criminal Identification and Investigation
System.
The Existance of this System is that Blood donation is very safe in the U.S., but a
small percentage of donors can have reactions and some of these reactions can lead to
serious injury. Donor hemovigilance is the surveillance and analysis of donor reactions
with the goal of understanding the factors inuencing reactions and taking steps to
improve donor safety. HHS has developed the DonorHART tool that collects, orga-
nizes and assists with the analysis of donor reaction data reported from participating
blood centers and hospitals. Data mining is used to analyze factors inuencing donor
reactions and insights are shared with the community to help blood center and hos-
pital managers and quality improvement administrators undertake interventions to
improve donor safety. This paper presents two studies performed on data reported
to the DonorHEART tool:
••• multiple vasovagal reactions
• delayed vasovagal reactions with loss of consciousness. Insights gained by per-
forming multivariate Logistics Regression (LR) modeling and Odds Ratio (OR)
calculations in terms of characteristics associated with multiple vasovagal reac-
tions and delayed vasovagal reactions are presented. The systematic collection
8

QUICK BLOOD DONATE
of donor hemovigilance data on a national level using data min-ing and analysis
can lead to interventions to improve donor safety. So our Proposed of system
is System to develop a web application as well as an android application for
blood banks and hospitals for quick availability of blood, which will also involve
Donor and acceptor directly.
• Let S be the — Quick blood donate as the final set S
• Identify the inputs as D , Q, I, P
S = D, Q, I, P,
D = D1, D2, D3, D4, — D given database updates
Q= Q1, Q2, Q3, — Q gives the request by person or hospital needing blood
I = I1, I2, —I gives user ID for login
P= P1, P2, —P gives the respective password for login ID
• Identify the outputs as O
S = D, Q, I, P, N, R,
N = N1, N2, N3, N4, — N given Notifications for blood requirement
R= R1, R2 — R is the Response for the blood request
• Identify the functions as F
S = D, Q, I, P, N, R, F
F = F1(), F2(), F3(), F4(), F5()
F1( V ) :: Update Database
F2 ( V) :: Process Requests
F3 ( V ) :: Send notification
F4 ( T ) :: Respond to notifications
F5 ( D ) :: login
9

QUICK BLOOD DONATE
Figure 3.1: Class Diagram
10

Chapter 4
Problem Definition and scope
4.1 Problem Statement
In most of the cases, when blood is required, that could not be provided on time
causing unpleasant things. Though donor is available hospital is unaware of it, and
donor too. So to resolve this a communication between hospital, blood bank, donor,
and accepter is important. So we come up with a system providing solution to this.
In this system we will make sure that also in the worst case the blood will be made
available to the patient. There will be three levels. The central blood bank, the
smaller blood banks and hospitals. The central blood bank will supply to the smaller
banks and they will supply to the nearby hospitals as per requirement. There will be
a web application.
4.1.1 Goals and objectives
Goal and Objectives:
The performance of the proposed fingerprints mixing approach was tested using two
different datasets. The first dataset was taken from the West Virginia University
(WVU) multimodal biometric database [27]. A subset of 1000 images correspond-
ing to 500 fingers (two impressions per finger) was used. The second dataset was
taken from the FVC2002-DB2A fingerprint database containing 100 fingers with 2
impressions per finger (a total of 200 fingerprints). The VeriFinger SDK was used to
generate the normalized fingerprint images and the matching scores. Also, an open
source Matlab implementation [28] based on Hong et al.s approach [20] was used to
compute the orientation and frequency images of the fingerprints. In order to estab-
lish the baseline performance, for each finger in each dataset, one impression was used
11

QUICK BLOOD DONATE
as probe image and the other impression was added to the gallery. This resulted in a
rank-1 accuracy of for the WVU dataset and for the FVC2002 dataset. The EERs for
these two datasets were 0.5 percent and 0.2 percent, respectively. In Sections III-A
and III-B, different experiments are discussed. These experiments investigate if the
new approach for image level fusion can be utilized to (a) generate a new identity by
mixing two distinct fingerprints and (b) de-identify a fingerprint by mixing it with
another fingerprint.
• Detecting Blood Storage.
• Produce an alarm and Broadcast Blood Requirement Messages local peoples.
• Provide User authentication by providing donor user name or ID.
• Live Tracking of Ambulance.
• Provide better communication between hospitals, blood banks, donor and ac-
ceptor.
4.1.2 Statement of scope
In todays time there general blood donation systems were present. Blood do-
nation camps were arranged to fulfil the need of blood storage. Also there are
some websites present for donating blood were the phone numbers of the donors
are present which are not reliable since they dont get often updated. At present
there are no proper websites. There is no proper care of person who donates
blood to patients. That is the medical history about the donor is not available
with the website. If a donor has or had any medical problem comes forward to
donate blood to a patient then it may lead to threat. Proposed system is to
develop a web application for blood banks and hospitals for quick availability
of blood, this will also involve donor and acceptor directly. Analysed the Blood
Storage and further produce alarm and broadcast Blood requirement messages
to local peoples and handle blood storage and donation process in systematic
manner.
12

QUICK BLOOD DONATE
Figure 4.1: Block Diagram
4.2 Major Constraints
The Quick Blood Donate (QBD) works as follows:
1. Central DB- Central Database holds the following data : Details of every blood
bank and hospital, Blood storage count, Donors information, and Citizens con-
tact details.
2. Web Application Blood Bank/Hospitals- Hold all blood bank/hospitals details.
Blood Storage count. Produces alarm when storage reaches to 30 percent.
Broadcast Messages to local peoples for blood requirement.
3. Web Application For Donors- The web application has a system database where
it consists
of the information regarding existing and new donors and acceptors. The main
problem is related with the information about knowing the details of donors in
the city. - Proposed System solve this by Provide a user name and id for unique
13

QUICK BLOOD DONATE
authentication to every new donor as a proof of blood donation. It is a kind of
a digital certificate which holds every medical detail of donor.
4. Web Page for Citizens- It contains GPS/GSM tracking of ambulance and its
details. So that, user just have to add its current location and proceed then itll
show the live tracking of nearest ambulance and also provide its details so user
can contact it and donate blood form that location.
4.3 Methodologies of Problem solving and efficiency issues
Performance requirements for proposed system are as follows-System will per-
form if proper dataset is been provided. Will result better if handle efficiently
by the user . Proper input data methods
4.4 Outcome
Never Ending Blood storage
4.5 Applications
It can be used in:-To provide a constant blood supply. To maintain all details
of blood banks and hospitals of city. To increase blood storage by finding
maximum donors. Digital certification will help users for safe and ease access
to their medical details. Live tracking of ambulance.
4.6 Hardware Resources Required
Processor - Pentium IV and above
Speed- 1.1 GHz
RAM- 256 MB (min)
Hard Disk- 512 GB
Key Board- Standard Windows Keyboard
Mouse- Two or Three Button Mouse
Monitor- SVGA
14

QUICK BLOOD DONATE
4.7 Software Resources Required
Platform :
Operating System: Windows Xp And above
IDE: Eclipse(jdk7 and above)
Programming Language: Java
15

Chapter 5
Project Plan
5.1 Project Estimates
The Project Planning step is the most critical step in the project management life
cycle. The reason is that its only when we list all of the tasks in our project plan,
that we truly have an idea of what its going to take, to deliver our project on time.
So to perform Project Planning in a smart and efficient way, we need a well-defined
and organized project plan to help is to do it.This chapter explains all the project
planning features. It lists our tasks, create schedules, project management approach,
projected project budget, project timeline, etc. Project planning is a discipline for
stating how to complete a project within a certain time frame, usually with defined
stages, and with designated resources. with the help of this Plan, One can Know
efforts and estimate.
5.1.1 Reconciled Estimates
Cost Estimate
The cost of the project is calculated in terms of the effort applied and the resources
used. The other parameters that account for cost estimation are:
-Man/Month
-Technology used
-Benefits
- Machine cost
16

QUICK BLOOD DONATE
Time Estimates
The total time for overall project completion undergoing various phases of develop-
ment is given as eight months (approx).
5.1.2 Project Resources
Blood storage Database
5.2 Risk Management w.r.t. NP Hard analysis
5.2.1 Risk Identification
Risk is made up of two parts: the probability of something going wrong, and the
negative consequences if it does.Risk can be hard to spot, however, let alone prepare
for and manage. And, if you’re hit by a consequence that you hadn’t planned for,
costs, time, and reputations could be on the line.This makes Risk Analysis an essential
tool when your work involves risk. It can help you identify and understand the risks
that you could face in your role. In turn, this helps you manage these risks, and
minimize their impact on your plans.In this article, we’ll look at how you can use
Risk Analysis to identify and manage risk effectively. Please refer table for all the
risks. You can refereed following risk identification questionnaire.
5.2.2 Risk Analysis
The risks for the Project can be analyzed within the constraints of time and quality.
What is Risk Analysis?
Risk Analysis is a process that helps you identify and manage potential problems that
could undermine key business initiatives or projects. To carry out a Risk Analysis,
you must first identify the possible threats that you face, and then estimate the likeli-
hood that these threats will materialize. Risk Analysis can be complex, as you’ll need
to draw on detailed information such as project plans, financial data, security proto-
cols, marketing forecasts, and other relevant information. However, it’s an essential
planning tool, and one that could save time, money, and reputations
17

QUICK BLOOD DONATE
Figure 5.1: Risk Analysis
••••••••
5.2.3 Overview of Risk Mitigation, Monitoring, Management
When to Use Risk Analysis?
Risk analysis is useful in many situations:
• When you’re planning projects, to help you anticipate and neutralize possible
problems.
• When you’re deciding whether or not to move forward with a project.
• When you’re improving safety and managing potential risks in the workplace.
• When you’re preparing for events such as equipment or technology failure, theft,
staﬀ sickness, or natural disasters.
• When you’re planning for changes in your environment, such as new competitors
coming into the market, or changes to government policy
5.3 Project Schedule
5.3.1 Project task set
Major Tasks in the Project stages are:
Detail Project Work breakdown (detail with task)
• T1: Communication: Project starts with the communication between devel-
opers. According to need of project, we gathered the requirements related to
project.
18

QUICK BLOOD DONATE
• T1.1 Project Initiation
• T1.2 Requirement Analysis
• T2: Planning: It includes complete estimation and scheduling (complete time-
line chart for project development) and tracking.
• T2.2 Project Scheduling
• T2.1 Project Estimation
• T3: Modeling: It includes detailed requirement analysis and project design.
• T3.1 Analysis
• T3.2 Design
• T4: Risk Management: It includes identifying the risk during project develop-
ment according to that, managing the risk which affects the project development
the most.
• T5: Risk Analysis Management
• T6: Testing
• T6.1 Unit Testing
• T6.2 Integration Testing
5.3.2 Timeline Chart
5.4 Team Organization
The manner in which staff is organized and the mechanisms for reporting are noted.
5.4.1 Team structure
The team structure for the project is identified. Roles are defined.
5.4.2 Management reporting and communication
Mechanisms for progress reporting and inter/intra team communication are identified
as per assessment sheet and lab time table.
19

QUICK BLOOD DONATE
Figure 5.2: Timeline Chart
20

Chapter 6
Software requirement specification
6.1 Introduction
6.1.1 Purpose and Scope of Document
To develop a web application as well as an android application for blood banks and
hospitals for quick availability of blood, which will also involve Donor and acceptor
directly. Analyze the Blood Storage and further produce alarm and broadcast Blood
requirement messages to local peoples and handle blood storage and donation process
in systematic manner.
6.1.2 Overview of responsibilities of Developer
Developer work out on system.he works on his output and input.and gives best result
6.2 Usage Scenario
A use case diagram in the Unified Modeling Language (UML)is a type of behavioral
diagram denied by and created from a Use-case analysis. Its purpose is to present a
graphical overview of the functionality provided by a system in terms of actors, their
goals , and any dependencies between those use cases.
6.2.1 User profiles
Actor: You can picture an actor as a user of the IT system, for example Mr.Steel or
Mrs. Smith from check-in. Because in-dividual persons are irrelevant for the model,
they are abstracted. So the actors are called check-in employee or passenger. Actors
represent roles that users take on when they use the IT system, e.g., the role of a
21

QUICK BLOOD DONATE
check-in employee. One person can act in more than one role toward the IT system.
It is important for the IT system in which role a person is acting. Therefore, it is
necessary to log on to many IT systems in a certain role, for in-stance, as a normal user
or as an administrator. Use cases describe the interactions that take place between
actors and IT systems during the execution of business processes. An association is
a connection between an actor and a use case.An association indicates that an actor
can carry out a use case.Several actors at one use case mean that each actor can carry
out the use case on his or her own and not that the actors carry out the use case
together. In fact, Association shows the associativity between an actor and a use
case. Include Relationships: An include relationship is a relationship between two
use cases.
6.2.2 Use-cases
All use-cases for the software are presented. Description of all main Use cases using
use case template is to be provided.
22

QUICK BLOOD DONATE
6.2.3 Use Case View
Use Case Diagram. Example is given below
Figure 6.1: Use Case Diagram
6.3 Data Model and Description
6.3.1 Data Description
Data move in speciﬁc direction from an origin to a destination.
6.3.2 Data objects and Relationships
Data objects and their major attributes and relationships among data objects are
described using an ERD- like form.
23

QUICK BLOOD DONATE
Figure 6.2: Data Diagram
6.4 Functional Model and Description
A description of the program architecture is presented. Subsystem design or Block
diagram,PackageDiagram,Deployment diagram with description is to be presented.
6.4.1 Data Flow Diagram
24

QUICK BLOOD DONATE
Level 0 Data Flow Diagram
Figure 6.3: DFD0 Diagram
25

QUICK BLOOD DONATE
26

QUICK BLOOD DONATE
6.4.2 Activity Diagram:
27

QUICK BLOOD DONATE
• The Activity diagram represents the steps taken.
Figure 6.6: Activity Diagram
6.4.3 Non Functional Requirements:
• Interface Requirements -There is need for communication interface, because we
need to provide training to user about our scheme then and only then user can
use it.
28

QUICK BLOOD DONATE
• Performance Requirements Performance requirements concern the speed of op-
eration of system .
Types of performance requirements:
• Response requirements - how quickly the system reacts to a user input.
• Throughput requirements - how much the system can accomplish within a
specifed amount of time.
• Availability requirements - is the system available for service when requested
by end users.
• Scalability - the capability of a system to increase total throughput under an
increased load when resources typically hardware are added. Secure access of
conﬁdential data users details.
6.4.4 State Diagram:
State Transition Diagram
6.4.5 Software Interface Description
Software interface required for application connection. A MySQL .NET Native Provider
is available, which allows native MySQL to .NET access without the need for OLE
DB. MySQL is most commonly used for Web applications and for embedded applica-
tions and has become a popular alternative to proprietary database systems because
of its speed and reliability.
29

QUICK BLOOD DONATE
Figure 6.7: State Diagram
30

Chapter 7
Detailed Design Document using Appendix A and B
7.1 Introduction
This document speciﬁes the design that is used to solve the problem of Product.
7.2 Architectural Design
A description of the program architecture is presented. Subsystem design or Block
diagram,Package Diagram,Deployment diagram with description is to be presented.
7.3 Data design (using Appendices A and B)
A description of all data structures including internal, global, and temporary data
structures, database design (tables), ﬁle formats.
7.3.1 Internal software data structure
Data structures that are passed among components the software are described.
7.3.2 Global data structure
Data structured that are available to major portions of the architecture are described.
7.3.3 Temporary data structure
Files created for interim use are described.
7.3.4 Database description
Database(s) / Files created/used as part of the application is(are) described.
31

QUICK BLOOD DONATE
Figure 7.1: Architectural Diagram
7.4 Compoent Design
Class diagrams, Interaction Diagrams, Algorithms. Description of each component
description required.
7.4.1 Class Diagram
32

QUICK BLOOD DONATE
Figure 7.2: Class Diagram
33

Chapter 8
Project Implementation
8.1 Introduction
In the hospital, most of the cases, when blood is required, that could not be provided
on time causing unpleasant things. Though donor is available hospital is unaware of
it, and donor too. So to resolve this communication between hospital, blood bank,
donor, and accepter is important. So we come up with a system providing solution
to this. In this system we will make sure that also in the worst case the blood will be
made available to the patient. There will be three levels. The central blood banks,
the smaller blood banks and hospitals. The central blood bank will supply to the
smaller banks and they will supply to the nearby hospitals as per requirement. There
will be a web application. City Peoples who wish to donate blood but not able to
because of the busy day schedule they can eﬃciently donate blood from any place in
the city with the help of webpage which our system is providing for local citizens.
Webpage will help citizens to track ambulance from their current location and then
they can donate blood by simply contacting the nearest ambulance.
8.2 Tools and Technologies Used
1. Eclipse IDE
2. Android Visual Studio
3. mySQL Workbench
8.3 Methodologies/Algorithm Details
The Quick Blood Donate (QBD) works as follows:
34

QUICK BLOOD DONATE
1. Central DB- Central Database holds the following data : Details of every blood
bank and hospital,
Blood storage count, Donors information, and Citizens contact details.
2. Web Application Blood Bank/Hospitals- Hold all blood bank/hospitals details.
Blood Storage count. Produces alarm when storage reaches to 30 percent.
Broadcast Messages to local peoples for blood requirement.
3. Web Application For Donors- The web application has a system database where
it consists
of the information regarding existing and new donors and acceptors. The main
problem is related with the information about knowing the details of donors in
the city. - Proposed System solve this by Provide a user name and id for unique
authentication to every new donor as a proof of blood donation. It is a kind of
a digital certificate which holds every medical detail of donor.
4. Web Page for Citizens- It contains GPS/GSM tracking of ambulance and its
details. So that, user just
have to add its current location and proceed then itll show the live tracking of
nearest ambulance and also provide its details so user can contact it and donate
blood form that location.
8.4 Methodologies of Problem solving and efficiency issues
Performance requirements for proposed system are as follows-System will per-
form if proper dataset is been provided. Will result better if handle efficiently
by the user . Proper input data methods
35

Chapter 9
Software Testing
9.1 Type of Testing Used
Software testing is an investigation conducted to provide stakeholders with informa-
tion about the quality of the product or service under test. Software testing can also
provide an objective, independent view of the software to allow the business to appre-
ciate and understand the risks of software implementation. Test techniques include,
but are not limited to the process of executing a program or application with the intent
of ending software bugs (errors or other defects). Software testing can be stated as
the process of validating and verifying that a computer program/application/product:
meets the requirements that guided its design and development,works as expected, can
be implemented with the same characteristics, and satisfies the needs of stakeholders.
Software testing, depending on the testing method employed, can be implemented
at any time in the software development process. Traditionally most of the test ef-
fort occurs after the requirements have been denied and the coding process has been
completed, but in the Agile approaches most of the test effort is on-going. As such,
the methodology of the test is governed by the chosen software development method-
ology. testing is the process of analysing a software item to detect the differences
between existing and required conditions (that is defects/errors/bugs) and to evalu-
ate the features of the software item. Testing the software is the process of validating
and verifying of a software program. The errors are to be identified in order to fix
those errors. Thus the main objective of software testing is to maintain and deliver
a quality product to the client. Every software is expected to meet certain needs. So
when a software is developed it is required to check whether it fulfils those needs[13].
36

QUICK BLOOD DONATE
9.2 Test Cases and Test Results
DEFINITION:
•••1. A test case is a set of conditions or variables under which a tester will determine
whether a system under test satisfies requirements or works correctly. The
process of developing test cases can also help find problems in the requirements
or design of an application.
2. In software engineering, a test case is a set of conditions or variables under
which a tester will determine if a requirement upon an application is partially
or fully satisfied. It may take many test cases to determine that a requirement is
fully satisfied. In order to fully test that all the requirements of an application
are met, there must be at least one test case for each requirement unless a
requirement has sub requirements. In that situation, each sub requirement
must have at least one test case.
• Formal test cases:
In order to fully test that all the requirements of an application are met, there
must beat least two test cases for each requirement: one positive test and one
negative test. If a requirement has sub-requirements, each sub-requirement
must have at least two test cases. keeping track of the link between the re-
quirement and the test is frequently done using a traceability matrix. Written
test cases should include a description of the functionality to be tested, and the
preparation required to ensure that the test can be conducted.
• Informal test cases:
For applications or systems without formal requirements, test cases can be
written based on the accepted normal operation of programs of a similar class.
In some schools of testing, test cases are not written at all but the activities
and results are reported after the tests have been run.
• Unit testing:
Unit testing, also known as component testing, refers to tests that verify the
functionality ofa specific section of code, usually at the function level. In an
object-oriented environment,this is usually at the class level, and the minimal
unit tests include the constructors and destructors.
37

QUICK BLOOD DONATE
• Integration testing: Integration testing is any type of software testing that seeks
to verify the interfaces between components against a software design. Software
components may be integrated in an iterative way or all together (”big bang”).
Normally the former is considered a better practice since it allows interface
issues to be located more quickly and fixed. Integration testing works to ex-
pose defects in the interfaces and interaction between integrated components
(modules). Progressively larger groups of tested software components corre-
sponding to elements of the architectural design are integrated and tested until
the software works as a system.
• System testing:
System testing, or end-to-end testing, tests a completely integrated system to
verify that it meets its requirements. For example, a system test might involve
testing a logon interface,then creating and editing an entry, plus sending or
printing results, followed by summary processing or deletion (or archiving) of
entries, then logo.In addition, the software testing should ensure that the pro-
gram, as well as working as expected, does not also destroy or partially corrupt
its operating environment or cause other processes within that environment to
become inoperative (this includes not corrupting shared memory, not consuming
or locking up excessive resources and leaving any parallel processes unharmed
by its presence).
• Regression testing:
Regression testing focuses on finding defects after a major code change has
occurred. Specif- ically, it seeks to uncover software regressions, as degraded or
lost features, including old bugs that have come back. Such regressions occur
whenever software functionality that was previously working, correctly, stops
working as intended. Typically, regressions occur as an unintended consequence
of program changes, when the newly developed part of the software collides with
the previously existing code. Common methods of regression testing include re-
running previous sets of test-cases and checking whether previously fixed faults
have re- emerged. The depth of testing depends on the phase in the release
process and the risk of the added features. They can either be complete, for
changes added late in the release or deemed to be risky, or be very shallow,
consisting of positive tests on each feature, if the changes are early in the release
38

QUICK BLOOD DONATE
or deemed to be of low risk.
39

Chapter 10
Results
10.1 Screen shots
Figure 10.1: Home Page
40

QUICK BLOOD DONATE
Figure 10.2: Log In Window
41

QUICK BLOOD DONATE
Figure 10.3: Registration Window
42

QUICK BLOOD DONATE
Figure 10.4: Storage Analysis
43

QUICK BLOOD DONATE
Figure 10.5: Organization of Camp
44

QUICK BLOOD DONATE
Figure 10.6: User Messaging
45

QUICK BLOOD DONATE
Figure 10.7: Vehical Registration
46

QUICK BLOOD DONATE
Figure 10.8: Ambulance Tracking
47

Chapter 11
Deployment and Maintenance
11.1 Installation and un-installation
Instalation Of Apache Tomcat 7.0
Figure 11.1: Welcome Wizard
Instalation Of Android Studio
11.2 Outputs
48

QUICK BLOOD DONATE
Figure 11.2: Licence Agreement
49

QUICK BLOOD DONATE
Figure 11.3: Selection of Module
50

QUICK BLOOD DONATE
Figure 11.4: Assign Port
51

QUICK BLOOD DONATE
Figure 11.5: JRE Path
52

QUICK BLOOD DONATE
Figure 11.6: Installation Location
53

QUICK BLOOD DONATE
Figure 11.7: Conﬁguration setting
54

QUICK BLOOD DONATE
Figure 11.8: Ram Requirement Speciﬁcation
55

QUICK BLOOD DONATE
Figure 11.9: Selection of Start Menu Folder
56

QUICK BLOOD DONATE
Figure 11.10: Result
57

Chapter 12
Conclusion and future scope
User who wishes to donate blood can register on our System, when he registers himself
he will be able to have a look at the total blood storage, accordingly if there is need
of Blood he can donate blood via Blood donation camps. If in case he is not able to
visit the blood donation camps, he can track the nearby ambulance and donate the
bold.
Medical history of the donor is stored in our system, i.e. he can have a look at the
total blood donated by him from the time he registered himself on our system. This
system trying to increase the supply of blood to meet the demand by providing a
platform for everyone included in this supply chain, this application will work on real
time data of location, so probability of getting correct donor is increased. Blood bank
will have access to all donors register from web site. They can broadcast messages
as and when required. Blood bank can organize blood bank camp. Blood bank can
search the blood availability.
58

Bibliography
[1] Arvind Sharma, P.C. Gupta, Predicting the Number of Blood Donors through
their Age and Blood Group by using Data Mining Tool, International Journal of
Communication and Computer Technologies, Volume 01 No.6, Issue: 02 Septem-
ber 2012.
[2] S.R. Okuboyejo, N.A. Ikhu-Omoregbe, A Framework for the Design of a Mobile-
Based Alert Systemfor Outpatient Adherence in Nigeria, African Journal of
Computing ICT, Vol 5
[3] Arif, M. ; Sreevas, S. ; Nafseer, K. ; Rahul, R, Automated online Blood bank
database, 978-1-4673-2270-6 India Conference
[4] en.wikihow.org/
[5] Source.android.com/compatibility
[6] http://en.wikipedia.org/wiki
[7] International Journal of Electrical, Electronicsand Computer Engineering A
New Concept of Blood Bank Management System using Cloud Computing for
Rural Area (INDIA) ISSN No. (Online): 2277-2626 by Javed Akhtar Khan and
M.R. Alony
[8] International Journal of Innovative Research in Science, Engineering and Tech-
nology An ISO 3297: 2007 Certiﬁed Organization, Volume 3, Special Issue 1,
59

February 2014 International Conference on Engineering Technology and Science-
(ICETS14) The Optimization of Blood Donor Information and Management Sys-
tem by Technopedia
[9] Blood Bank Management Information System in India Author: Vikas Kul-
shreshtha Research Scholar, Dr. Sharad Maheshwari, Associate Professor Vikas
Kulshreshtha, Dr. Sharad Maheshwari, / International Journal of Engineering
Research and Applications (IJERA) ISSN: 2248-9622 www.ijera.com Vol. 1, Is-
sue 2, pp.260-263
[10] 2014 47th Hawaii International Conference on System Science 978-1-4799-2504-
9/14 31.002014IEEEDOI10.1109/HICSS.2014.105789DataMiningtoImproveSafetyofBloo
[11] IJCSI International Journal of Computer Science Issues, Vol. 8, Issue 5, No 2, Septem-
ber 2011 Real-Time Blood Donor Management Using Dashboards Based on Data
Mining Models ISSN (Online): 1694-0814 www.IJCSI.org 159

APPENDIX-A
Laboratory assignments on Project Analysis of Algorithmic Design
• To develop the problem under consideration and justify feasibilty using concepts
of knowledge canvas and IDEA Matrix.
Refer [?] for IDEA Matrix and Knowledge canvas model. Case studies are given
in this book. IDEA Matrix is represented in the following form. Knowledge
canvas represents about identiﬁcation of opportunity for product. Feasibility is
represented w.r.t. business perspective.
• Project problem statement feasibility assessment using NP-Hard, NP-Complete
or satisfy ability issues using modern algebra and/or relevant mathematical
models.
NP Hard and NP complete
These refer to how long it takes a program to run. Problems in class P can be
solved with algorithms that run in polynomial time.
Say you have an algorithm that ﬁnds the smallest integer in an array. One way
to do this is by iterating over all the integers of the array and keeping track of
the smallest number you’ve seen up to that point. Every time you look at an
element, you compare it to the current minimum, and if it’s smaller, you update
the minimum. How long does this take? Let’s say there are n elements in the
array. For every element the algorithm has to perform a constant number of
operations. Therefore we can say that the algorithm runs in O(n) time, or that
the runtime is a linear function of how many elements are in the array.* So this
algorithm runs in linear time.
You can also have algorithms that run in quadratic time (O(n*n)),exponential
time (O(2*n)), or even logarithmic time (O(log n)). Binary search (on a bal-
anced tree) runs in logarithmic time because the height of the binary search tree
is a logarithmic function of the number of elements in the tree. If the running
time is some polynomial function of the size of the input**, for instance if the
algorithm runs in linear time or quadratic time or cubic time, then we say the
algorithm runs in polynomial time and the problem it solves is in class P.

NP
Now there are a lot of programs that don’t (necessarily) run in polynomial
time on a regular computer, but do run in polynomial time on a nondetermin-
istic Turing machine. These programs solve problems in NP, which stands for
nondeterministic polynomial time. A nondeterministic Turing machine can do
everything a regular computer can and more.*** This means all problems in P
are also in NP. An equivalent way to define NP is by pointing to the problems
that can be verified in polynomial time. This means there is not necessarily a
polynomial-time way to find a solution, but once you have a solution it only
takes polynomial time to verify that it is correct.
Some people think P = NP, which means any problem that can be verified in
polynomial time can also be solved in polynomial time and vice versa. If they
could prove this, it would revolutionize computer science because people would
be able to construct faster algorithms for a lot of important problems. NP-hard
What does NP-hard mean? A lot of times you can solve a problem by reducing
it to a different problem. I can reduce Problem B to Problem A if, given a
solution to Problem A, I can easily construct a solution to Problem B. (In this
case, ”easily” means ”in polynomial time.”) If a problem is NP-hard, this means
I can reduce any problem in NP to that problem. This means if I can solve that
problem, I can easily solve any problem in NP. If we could solve an NP-hard
problem in polynomial time, this would prove P = NP.
NP-complete
A problem is NP-complete if the problem is both
• NP-hard, and
• NP.
Complexity classes are one way to talk about how difficult or easy a problem is.
Complexity theory gets very technical but the basics are actually extraordinarily
intuitive, and it’s possible to understand the P versus NP issue with very little
math background.
The kinds of problems we deal with in complexity theory come in pairs: a
”search” version and a ”verification” version. For example –

• Problem: sorting. Search version: input a list of numbers X and output the
same list in sorted order (call it Y). Verification version: input a list of numbers
X and another list Y, and output ”YES” if Y is the sorted version of X and
”NO” otherwise.
• Problem: graph coloring. Search version: input a network of nodes and edges
X, and output colors Y for each node such that no adjacent nodes have the
same color. Verification version: input a network X and a set of colors Y and
output ”YES” if all adjacent nodes have different colors and ”NO” otherwise.
• Problem: Partition Search version: input some numbers X and divide the num-
bers into two groups that add up to exactly the same value (call the assignment
of numbers to their group Y). Verification version: input some numbers X and
the groupings Y and output ”YES” if the two groups add up to the same value,
or ”NO” otherwise.
This is the P versus NP problem: Are there any problems for which the verifica-
tion version can be solved efficiently but for which there is no efficient solution
to the search version? If there is a fast solution to the search version of a prob-
lem then the problem is said to be Polynomial-time, or P for short. If there
is a fast solution to the verification version of a problem then the problem is
said to be Nondeterministic Polynomial-time or NP for short. The question of
”P=NP” is then the question of whether these sets are identical.
In the case of the sorting problem above, there are fast algorithms for both the
search and verification versions. But for the other two problems, the verifica-
tion versions are easy (heck, my grandmother could probably write a computer
program to check that two lists of numbers add up to the same value) but the
search versions are difficult, and indeed there are no fast solutions known. So
all three problems are in NP, but only the first is (known to be) in P. Some
problems can be translated into one another in such a way that a fast solution
to one problem would automatically give us a fast solution to the other. There
are some problems that every single problem in NP can be translated into, and
a fast solution to such a problem would automatically give us a fast solution
to every problem in NP. This group of problems are known as NP-Hard. Some
problems in NP-Hard are actually not themselves in NP; the group of problems

that are in both NP and NP-Hard is called NP-Complete. You start to see the
far-reaching implications of a fast solution to any one problem in NP-Hard: we
would automatically get a fast solution to every problem in NP, which would
mean that whenever there is a fast solution to the verification version of a prob-
lem then there is always a fast solution to the corresponding search version.
Remember how the verification versions of those problems seemed easy but the
search versions seemed hard? A fast solution to any NP-Complete problem
would be mean that as long as you can verify proposed solutions to a problem
you would never need to search through a substantial fraction of the search
space to find solutions; there would always be a faster way.
• input x,output y, y=f(x)

APPENDIX-B
Laboratory assignments on Project Quality and Reliability Testing of
Project Design
It should include assignments such as
• Use of divide and conquer strategies to exploit distributed/parallel/concurrent
processing of the above to identify object, morphisms, overloading in functions
(if any), and functional relations and any other dependencies (as per require-
ments).
• Functional Requirement:
• User Interfaces
To mix two fingerprints, each fingerprint pattern is decomposed into two differ-
ent components, viz., the continuous and spiral components. After prealigning
the components of each fingerprint, the continuous component of one fingerprint
is combined with the spiral component of the other fingerprint.
• Hardware Interfaces
No any hardware interface.
• Software Interfaces
Software interface required for application connection. A MySQL .NET Native
Provider is available, which allows native MySQL to .NET access without the
need for OLE DB. MySQL is most commonly used for Web applications and
for embedded applications and has become a popular alternative to proprietary
database systems because of its speed and reliability. Communication Interfaces
There is need for communication interface, because we need to provide training
to user about our scheme then and only then user can use it.
• Non Functional Requirement:
• Performance Requirement
Performance requirements concern the speed of operation of system Types of
performance requirements:
• Response requirements - how quickly the system reacts to a user input.

• Throughput requirements - how much the system can accomplish within a spec-
ifieded amount of time.
• Availability requirements - is the system available for service when requested
by end users.
• Scalability - the capability of a system to increase total throughput under an
increased load when resources typically hardware are added. Secure access of
confidential data users details.
• Safety Requirements
Safety requirements are the shall not requirements which exclude unsafe situ-
ations from the possible solution space of the system Security Requirements.
Many safety standards use the concept of a safety requirement to ensure that
the system carries out the functions needed to make it acceptably safe. For the
safety requirements to achieve this (in terms of the risk reduction being both
sufficient and necessary), an adequate risk assessment must have been carried
out.
• Security Requirements
Security requirements are included in a system to ensure: Unauthorized access
to the system and its data is not allowed Ensure the integrity of the system
from accidental or malicious damage. Authentication password techniques used
for security purpose .As authentication techniques generate passwords but they
have to face attacks like dictionary attacks, brute force attacks, shoulder surfing.
Authentication needs more powerful authentication techniques which remove all
drawback of as mentioned above in authentication password techniques.
• Software Quality Attributes
In the context of software engineering, software quality refers to two related but
distinct notions that exist wherever quality is denied in a business context:
• Software functional quality reects how well it complies with or conforms to a
given design, based on functional requirements or specifications. That attribute
can also be described as the fitness for purpose of a piece of software or how it
compares to competitors in the marketplace as a worthwhile product;

• Software structural quality refers to how it meets non-functional requirements
that support the delivery of the functional requirements, such as robustness or
maintainability, the degree to which the software was produced correctly. Struc-
tural quality is evaluated through the analysis of the software inner structure,
its source code, at the unit level, the technology level and the system level,
which is in eﬀect how its architecture adheres to sound principles of software
architecture outlined in a paper on the topic by OMG. In contrast, functional
quality is typically enforced and measured through software testing.
• Use of above to draw functional dependency graphs and relevant Software mod-
eling methods, techniques including UML diagrams or other necessities using
appropriate tools.

Figure 1: Activity Diagram
• Mathematical Modeling For Quick Blood Donate

APPENDIX-C
Reviewers Comments of Paper Submitted
1. Paper Title:Quick Blood Donate
2. Name of the Conference/Journal where paper submitted :International
Journal of Computer Science and Mobile Computing
3. Paper accepted/rejected : Accepted
4. Review comments by reviewer :A good attempt to make revolution in
Bio-medical ﬁeld.
5. Corrective actions if any : no

APPENDIX-D
Plagiarism Report
Plagiarism of Quick Blood Donate is 93 percent accuracy.

APPENDIX-E
Information of Project Group Members
1.
Name :Bhavesh Narendra Jangale.
–– Date of Birth :10/01/1994
– Gender : Male
– Permanent Address :N32/N5-5/6 ganesh Chowk,cidco,New Nashik
09
– E-Mail : bprince001@gmail.com
– Mobile/Contact No. :9766159399
– Paper Published : Yes

2.
Name : Tejal Deviprakash Mhaske
–– Date of Birth :20/11/1993
– Gender : Female
– Permanent Address :Flat no-07, Vimal Park, Jagtap nagar, untwadi,
nashik-08
– E-Mail : tejalmhaske@gmail.com
– Placement Details :no
– Paper Published : yes

3.
Name : Sunil Shantaram Musale.
–– Date of Birth :07/01/1990
– Gender : Male
– Permanent Address :Musalgaon,Sinner
– E-Mail : sunilmusale07@gmail.com
– Paper Published : Yes

4.
Name : Sahil Dilip Salunke.
–– Date of Birth :06/01/1994
– Gender : Male
– Permanent Address :Narayan recidency,jailroad
– E-Mail : sahil.salunke14@gmail.com
– Paper Published : yes

QBD_1464843125535 - Copy

More Related Content

What's hot (19)

Similar to QBD_1464843125535 - Copy (20)

QBD_1464843125535 - Copy