SlideShare uma empresa Scribd logo
1 de 90
Baixar para ler offline
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
DEPARTMENT OF COMPUTER ENGINEERING
CERTIFICATE
This is to certify that the Project Entitled
QUICK BLOOD DONATE
Submitted by
Mr.Bhavesh N. Jangale ( B120274228)
Miss. Tejal D. Mhaske ( B120274243)
Mr. Sunil S. Musale ( B120274245)
Mr. Sahil D. Salunke ( B120274254)
is a bonafide work carried out by Students under the supervision of Prof. Guide
Name and it is submitted towards the partial fulfillment 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
Mr.Bhavesh N. Jangale ( B120274228)
Miss. Tejal D. Mhaske ( B120274243)
Mr. Sunil S. Musale ( B120274245)
Mr. Sahil D. Salunke ( B120274254)
at
DEPARTMENT OF COMPUTER ENGINEERING
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 specifica-
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 staff 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 efficiency 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 Configuration setting . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
11.8 Ram Requirement Specification . . . . . . . . . . . . . . . . . . . . . 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 specific
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 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,
3
SVIT, Department of Computer 2015-16
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 cen- ters and hospitals. Data mining is used to analyze factors inuencing
donor reactions and insights are shared with the community to help blood center
4
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
and hospital man- agers 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 min- ing 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
SVIT, Department of Computer 2015-16
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 efficiently 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 fulfill 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, un- derstand 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
SVIT, Department of Computer 2015-16
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
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 3.1: Class Diagram
10
SVIT, Department of Computer 2015-16
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
SVIT, Department of Computer 2015-16
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
SVIT, Department of Computer 2015-16
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
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
4.7 Software Resources Required
Platform :
Operating System: Windows Xp And above
IDE: Eclipse(jdk7 and above)
Programming Language: Java
15
SVIT, Department of Computer 2015-16
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
SVIT, Department of Computer 2015-16
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,
staff 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
SVIT, Department of Computer 2015-16
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
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 5.2: Timeline Chart
20
SVIT, Department of Computer 2015-16
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
SVIT, Department of Computer 2015-16
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 specific 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
SVIT, Department of Computer 2015-16
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
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Level 0 Data Flow Diagram
Figure 6.3: DFD0 Diagram
25
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Level 1 Data Flow Diagram
Figure 6.4: DFD1 Diagram
26
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Level 2 Data Flow Diagram
Figure 6.5: DFD2 Diagram
6.4.2 Activity Diagram:
27
SVIT, Department of Computer 2015-16
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
SVIT, Department of Computer 2015-16
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
confidential 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
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 6.7: State Diagram
30
SVIT, Department of Computer 2015-16
Chapter 7
Detailed Design Document using Appendix A and B
7.1 Introduction
This document specifies 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), file 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
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 7.2: Class Diagram
33
SVIT, Department of Computer 2015-16
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 efficiently 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
SVIT, Department of Computer 2015-16
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
SVIT, Department of Computer 2015-16
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
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
or deemed to be of low risk.
39
SVIT, Department of Computer 2015-16
Chapter 10
Results
10.1 Screen shots
Figure 10.1: Home Page
40
QUICK BLOOD DONATE
Figure 10.2: Log In Window
41
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 10.3: Registration Window
42
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 10.4: Storage Analysis
43
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 10.5: Organization of Camp
44
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 10.6: User Messaging
45
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 10.7: Vehical Registration
46
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 10.8: Ambulance Tracking
47
SVIT, Department of Computer 2015-16
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
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 11.3: Selection of Module
50
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 11.4: Assign Port
51
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 11.5: JRE Path
52
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 11.6: Installation Location
53
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 11.7: Configuration setting
54
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 11.8: Ram Requirement Specification
55
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 11.9: Selection of Start Menu Folder
56
SVIT, Department of Computer 2015-16
QUICK BLOOD DONATE
Figure 11.10: Result
57
SVIT, Department of Computer 2015-16
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 Certified 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 identification 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 finds 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 effect 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
Figure 2: Figure 1
Figure 3: Figure 2
Figure 4: Figurel 3
Figure 5: Project Plan 1
Figure 6: Project Plan2
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 field.
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
– Mobile/Contact No. :9405055622
– 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
– Mobile/Contact No. :9960701688
– Placement Details :no
– 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
– Mobile/Contact No. :8983873913
– Placement Details :no
– Paper Published : yes

Mais conteúdo relacionado

Mais procurados

Data replication (software)
Data replication (software) Data replication (software)
Data replication (software)
Masoud Gholami
 
Sap co stepbystep config & user manual part 2
Sap co stepbystep config & user manual part 2Sap co stepbystep config & user manual part 2
Sap co stepbystep config & user manual part 2
PallaviChawla8
 
33134 handbook ict wp2013 fixed deadline calls v2 en
33134 handbook ict wp2013 fixed deadline calls v2 en33134 handbook ict wp2013 fixed deadline calls v2 en
33134 handbook ict wp2013 fixed deadline calls v2 en
Rob Blaauboer
 
SocioTechnical-systems-sim
SocioTechnical-systems-simSocioTechnical-systems-sim
SocioTechnical-systems-sim
Rub Afonso
 
The City of Bakersfield, CA GIS Implementation Plan (1997 - 1998)
The City of Bakersfield, CA GIS Implementation Plan (1997 - 1998)The City of Bakersfield, CA GIS Implementation Plan (1997 - 1998)
The City of Bakersfield, CA GIS Implementation Plan (1997 - 1998)
Juan Tobar
 
COMPUTER INTERGRATED HEAT EXCHANGER LABORATORY APPARATUS
COMPUTER INTERGRATED HEAT EXCHANGER LABORATORY APPARATUS COMPUTER INTERGRATED HEAT EXCHANGER LABORATORY APPARATUS
COMPUTER INTERGRATED HEAT EXCHANGER LABORATORY APPARATUS
pathum maitipe
 

Mais procurados (19)

Data replication (software)
Data replication (software) Data replication (software)
Data replication (software)
 
22024582
2202458222024582
22024582
 
Sap co stepbystep config & user manual part 2
Sap co stepbystep config & user manual part 2Sap co stepbystep config & user manual part 2
Sap co stepbystep config & user manual part 2
 
33134 handbook ict wp2013 fixed deadline calls v2 en
33134 handbook ict wp2013 fixed deadline calls v2 en33134 handbook ict wp2013 fixed deadline calls v2 en
33134 handbook ict wp2013 fixed deadline calls v2 en
 
SocioTechnical-systems-sim
SocioTechnical-systems-simSocioTechnical-systems-sim
SocioTechnical-systems-sim
 
iGUARD: An Intelligent Way To Secure - Report
iGUARD: An Intelligent Way To Secure - ReportiGUARD: An Intelligent Way To Secure - Report
iGUARD: An Intelligent Way To Secure - Report
 
Software Design Description (SDD) sample
Software Design Description (SDD) sampleSoftware Design Description (SDD) sample
Software Design Description (SDD) sample
 
Sma10 4545
Sma10 4545Sma10 4545
Sma10 4545
 
Digital Interventions for Health Systems Strengthening
Digital Interventions for Health Systems Strengthening Digital Interventions for Health Systems Strengthening
Digital Interventions for Health Systems Strengthening
 
The City of Bakersfield, CA GIS Implementation Plan (1997 - 1998)
The City of Bakersfield, CA GIS Implementation Plan (1997 - 1998)The City of Bakersfield, CA GIS Implementation Plan (1997 - 1998)
The City of Bakersfield, CA GIS Implementation Plan (1997 - 1998)
 
Energy assessment guide for commercial buildings
Energy assessment guide for commercial buildingsEnergy assessment guide for commercial buildings
Energy assessment guide for commercial buildings
 
COMPUTER INTERGRATED HEAT EXCHANGER LABORATORY APPARATUS
COMPUTER INTERGRATED HEAT EXCHANGER LABORATORY APPARATUS COMPUTER INTERGRATED HEAT EXCHANGER LABORATORY APPARATUS
COMPUTER INTERGRATED HEAT EXCHANGER LABORATORY APPARATUS
 
Risk analyticsmaster
Risk analyticsmasterRisk analyticsmaster
Risk analyticsmaster
 
Introduction to Solution Architecture Book
Introduction to Solution Architecture BookIntroduction to Solution Architecture Book
Introduction to Solution Architecture Book
 
Rapport d'analyse Dimensionality Reduction
Rapport d'analyse Dimensionality ReductionRapport d'analyse Dimensionality Reduction
Rapport d'analyse Dimensionality Reduction
 
Final Report
Final ReportFinal Report
Final Report
 
Project Plan And Srs Final
Project Plan And Srs FinalProject Plan And Srs Final
Project Plan And Srs Final
 
Tutorial
TutorialTutorial
Tutorial
 
FLOOD-serv - D6.1 Community of Interest Build Up and Engangement Strategy
FLOOD-serv - D6.1 Community of Interest Build Up and Engangement Strategy FLOOD-serv - D6.1 Community of Interest Build Up and Engangement Strategy
FLOOD-serv - D6.1 Community of Interest Build Up and Engangement Strategy
 

Semelhante a QBD_1464843125535 - Copy

ImplementationOFDMFPGA
ImplementationOFDMFPGAImplementationOFDMFPGA
ImplementationOFDMFPGA
Nikita Pinto
 
Report on e-Notice App (An Android Application)
Report on e-Notice App (An Android Application)Report on e-Notice App (An Android Application)
Report on e-Notice App (An Android Application)
Priyanka Kapoor
 
A Machine Learning approach to predict Software Defects
A Machine Learning approach to predict Software DefectsA Machine Learning approach to predict Software Defects
A Machine Learning approach to predict Software Defects
Chetan Hireholi
 

Semelhante a QBD_1464843125535 - Copy (20)

Work Measurement Application - Ghent Internship Report - Adel Belasker
Work Measurement Application - Ghent Internship Report - Adel BelaskerWork Measurement Application - Ghent Internship Report - Adel Belasker
Work Measurement Application - Ghent Internship Report - Adel Belasker
 
Chat Application [Full Documentation]
Chat Application [Full Documentation]Chat Application [Full Documentation]
Chat Application [Full Documentation]
 
ImplementationOFDMFPGA
ImplementationOFDMFPGAImplementationOFDMFPGA
ImplementationOFDMFPGA
 
project Report on LAN Security Manager
project Report on LAN Security Managerproject Report on LAN Security Manager
project Report on LAN Security Manager
 
Report on e-Notice App (An Android Application)
Report on e-Notice App (An Android Application)Report on e-Notice App (An Android Application)
Report on e-Notice App (An Android Application)
 
Bike sharing android application
Bike sharing android applicationBike sharing android application
Bike sharing android application
 
FULLTEXT01.pdf
FULLTEXT01.pdfFULLTEXT01.pdf
FULLTEXT01.pdf
 
Data over dab
Data over dabData over dab
Data over dab
 
digiinfo website project report
digiinfo website project reportdigiinfo website project report
digiinfo website project report
 
Project final report
Project final reportProject final report
Project final report
 
Content and concept filter
Content and concept filterContent and concept filter
Content and concept filter
 
test6
test6test6
test6
 
document
documentdocument
document
 
Master's Thesis
Master's ThesisMaster's Thesis
Master's Thesis
 
Thesis_Report
Thesis_ReportThesis_Report
Thesis_Report
 
ThesisB
ThesisBThesisB
ThesisB
 
A Machine Learning approach to predict Software Defects
A Machine Learning approach to predict Software DefectsA Machine Learning approach to predict Software Defects
A Machine Learning approach to predict Software Defects
 
Sanskrit Parser Report
Sanskrit Parser ReportSanskrit Parser Report
Sanskrit Parser Report
 
CS4099Report
CS4099ReportCS4099Report
CS4099Report
 
Live chat srs
Live chat srsLive chat srs
Live chat srs
 

QBD_1464843125535 - Copy

  • 1. 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
  • 2. DEPARTMENT OF COMPUTER ENGINEERING CERTIFICATE This is to certify that the Project Entitled QUICK BLOOD DONATE Submitted by Mr.Bhavesh N. Jangale ( B120274228) Miss. Tejal D. Mhaske ( B120274243) Mr. Sunil S. Musale ( B120274245) Mr. Sahil D. Salunke ( B120274254) is a bonafide work carried out by Students under the supervision of Prof. Guide Name and it is submitted towards the partial fulfillment 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
  • 3. PROJECT APPROVAL SHEET A Project Title (QUICK BLOOD DONATE) Is successfully completed by Mr.Bhavesh N. Jangale ( B120274228) Miss. Tejal D. Mhaske ( B120274243) Mr. Sunil S. Musale ( B120274245) Mr. Sahil D. Salunke ( B120274254) at DEPARTMENT OF COMPUTER ENGINEERING 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
  • 4. 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 specifica- 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
  • 5. 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 staff 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
  • 6. 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
  • 7. 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
  • 8. 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 efficiency 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
  • 9. 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
  • 10. 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. 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 Configuration setting . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 11.8 Ram Requirement Specification . . . . . . . . . . . . . . . . . . . . . 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
  • 12. 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
  • 13. 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 specific 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
  • 14. 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 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, 3 SVIT, Department of Computer 2015-16
  • 15. 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 cen- ters and hospitals. Data mining is used to analyze factors inuencing donor reactions and insights are shared with the community to help blood center 4 SVIT, Department of Computer 2015-16
  • 16. QUICK BLOOD DONATE and hospital man- agers 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 min- ing 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 SVIT, Department of Computer 2015-16
  • 17. 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
  • 18. 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 efficiently 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 fulfill 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
  • 19. 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, un- derstand 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 SVIT, Department of Computer 2015-16
  • 20. 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 SVIT, Department of Computer 2015-16
  • 21. QUICK BLOOD DONATE Figure 3.1: Class Diagram 10 SVIT, Department of Computer 2015-16
  • 22. 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
  • 23. 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 SVIT, Department of Computer 2015-16
  • 24. 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 SVIT, Department of Computer 2015-16
  • 25. 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 SVIT, Department of Computer 2015-16
  • 26. QUICK BLOOD DONATE 4.7 Software Resources Required Platform : Operating System: Windows Xp And above IDE: Eclipse(jdk7 and above) Programming Language: Java 15 SVIT, Department of Computer 2015-16
  • 27. 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
  • 28. 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 SVIT, Department of Computer 2015-16
  • 29. 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, staff 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 SVIT, Department of Computer 2015-16
  • 30. 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 SVIT, Department of Computer 2015-16
  • 31. QUICK BLOOD DONATE Figure 5.2: Timeline Chart 20 SVIT, Department of Computer 2015-16
  • 32. 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
  • 33. 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 SVIT, Department of Computer 2015-16
  • 34. 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 specific 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 SVIT, Department of Computer 2015-16
  • 35. 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 SVIT, Department of Computer 2015-16
  • 36. QUICK BLOOD DONATE Level 0 Data Flow Diagram Figure 6.3: DFD0 Diagram 25 SVIT, Department of Computer 2015-16
  • 37. QUICK BLOOD DONATE Level 1 Data Flow Diagram Figure 6.4: DFD1 Diagram 26 SVIT, Department of Computer 2015-16
  • 38. QUICK BLOOD DONATE Level 2 Data Flow Diagram Figure 6.5: DFD2 Diagram 6.4.2 Activity Diagram: 27 SVIT, Department of Computer 2015-16
  • 39. 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 SVIT, Department of Computer 2015-16
  • 40. 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 confidential 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 SVIT, Department of Computer 2015-16
  • 41. QUICK BLOOD DONATE Figure 6.7: State Diagram 30 SVIT, Department of Computer 2015-16
  • 42. Chapter 7 Detailed Design Document using Appendix A and B 7.1 Introduction This document specifies 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), file 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
  • 43. 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 SVIT, Department of Computer 2015-16
  • 44. QUICK BLOOD DONATE Figure 7.2: Class Diagram 33 SVIT, Department of Computer 2015-16
  • 45. 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 efficiently 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
  • 46. 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 SVIT, Department of Computer 2015-16
  • 47. 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
  • 48. 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 SVIT, Department of Computer 2015-16
  • 49. 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 SVIT, Department of Computer 2015-16
  • 50. QUICK BLOOD DONATE or deemed to be of low risk. 39 SVIT, Department of Computer 2015-16
  • 51. Chapter 10 Results 10.1 Screen shots Figure 10.1: Home Page 40
  • 52. QUICK BLOOD DONATE Figure 10.2: Log In Window 41 SVIT, Department of Computer 2015-16
  • 53. QUICK BLOOD DONATE Figure 10.3: Registration Window 42 SVIT, Department of Computer 2015-16
  • 54. QUICK BLOOD DONATE Figure 10.4: Storage Analysis 43 SVIT, Department of Computer 2015-16
  • 55. QUICK BLOOD DONATE Figure 10.5: Organization of Camp 44 SVIT, Department of Computer 2015-16
  • 56. QUICK BLOOD DONATE Figure 10.6: User Messaging 45 SVIT, Department of Computer 2015-16
  • 57. QUICK BLOOD DONATE Figure 10.7: Vehical Registration 46 SVIT, Department of Computer 2015-16
  • 58. QUICK BLOOD DONATE Figure 10.8: Ambulance Tracking 47 SVIT, Department of Computer 2015-16
  • 59. 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
  • 60. QUICK BLOOD DONATE Figure 11.2: Licence Agreement 49 SVIT, Department of Computer 2015-16
  • 61. QUICK BLOOD DONATE Figure 11.3: Selection of Module 50 SVIT, Department of Computer 2015-16
  • 62. QUICK BLOOD DONATE Figure 11.4: Assign Port 51 SVIT, Department of Computer 2015-16
  • 63. QUICK BLOOD DONATE Figure 11.5: JRE Path 52 SVIT, Department of Computer 2015-16
  • 64. QUICK BLOOD DONATE Figure 11.6: Installation Location 53 SVIT, Department of Computer 2015-16
  • 65. QUICK BLOOD DONATE Figure 11.7: Configuration setting 54 SVIT, Department of Computer 2015-16
  • 66. QUICK BLOOD DONATE Figure 11.8: Ram Requirement Specification 55 SVIT, Department of Computer 2015-16
  • 67. QUICK BLOOD DONATE Figure 11.9: Selection of Start Menu Folder 56 SVIT, Department of Computer 2015-16
  • 68. QUICK BLOOD DONATE Figure 11.10: Result 57 SVIT, Department of Computer 2015-16
  • 69. 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
  • 70. 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 Certified Organization, Volume 3, Special Issue 1, 59
  • 71. 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
  • 72. 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 identification 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 finds 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.
  • 73. 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 –
  • 74. • 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
  • 75. 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)
  • 76. 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.
  • 77. • 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;
  • 78. • 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 effect 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.
  • 79. Figure 1: Activity Diagram • Mathematical Modeling For Quick Blood Donate
  • 85. 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 field. 5. Corrective actions if any : no
  • 86. APPENDIX-D Plagiarism Report Plagiarism of Quick Blood Donate is 93 percent accuracy.
  • 87. 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
  • 88. 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 – Mobile/Contact No. :9405055622 – Placement Details :no – Paper Published : yes
  • 89. 3. Name : Sunil Shantaram Musale. –– Date of Birth :07/01/1990 – Gender : Male – Permanent Address :Musalgaon,Sinner – E-Mail : sunilmusale07@gmail.com – Mobile/Contact No. :9960701688 – Placement Details :no – Paper Published : Yes
  • 90. 4. Name : Sahil Dilip Salunke. –– Date of Birth :06/01/1994 – Gender : Male – Permanent Address :Narayan recidency,jailroad – E-Mail : sahil.salunke14@gmail.com – Mobile/Contact No. :8983873913 – Placement Details :no – Paper Published : yes