BLOOD BANK AND DONOR

MANAGEMENT SYSTEM

A dissertation submitted in partial fulfillment for the award of the degree of

BACHELOR OF ENGINEERING
in
KONGUNADU COLLEGE OF ENGINEERING AND TECHNOLOGY
(AUTONOMOUS)
Submitted by
R.Abinaya (621318104002)
M.Prithika (621318104039)
M.Priyanka (621318104040)

Under the Guidance of

Mr.K.BASKAR, M.E.,(Ph.D),
Assistant Professor
Department of Computer Science and Engineering
KONGUNADU COLLEGE OF ENGINEERING AND TECHNOLOGY
(AUTONOMOUS)
TRICHY-621215
DEC-MAY
2019-2020

1
 BONAFIDE CERTIFICATE

This is to certify that the dissertation entitled “BLOOD BANK AND DONOR
MANAGEMENT SYSTEM” is a bonafide work carried out by R.Abinaya
(621318104002), M.Prithika(621318104039), M.Priyanka(621318104040) my direct
supervision is submitted in partial fulfillment of the requirements for the award of
degree of Bachelor of Engineering in COMPUTER SCIENCE AND ENGINEERING
to Kongunadu College of Engineering and Technology, Trichy – 621 215. No part of
the dissertation has been submitted for any degree/diploma or any other academic award
anywhere before.

SIGNATURE SIGNATURE
Dr .C. SARAVANABHAVAN, M.Tech Ph.D., Mr. K.BASKAR,M.E.,(Ph.D),
HEAD OF THE DEPARTMENT SUPERVISOR
Assistant Professor
Department of Computer Science and Department of Computer Science and
Engineering Engineering
Kongunadu College of Engineering and Kongunadu College of Engineering and
Technology, Thottiam,Trichy-621 215 Technology, Thottiam,Trichy-621 215

2
 ACKNOWLEDGEMENT

We wish to express our sincere thanks to our beloved respectful and honorable
chairman Dr.PSK.R.PERIASWAMY for providing immense facilities in our
institution.
We proudly render our thanks to our Principal Dr. R. ASOKAN, M.S., M.Tech.,
Ph.D., for the facilities and the encouragement given by him to the progress and
completion of my mini project.
We proudly render our immense gratitude to our Head of the Department of
Computer Science and EngineeringDr.C. SARAVANABHAVAN,M.Tech., Ph.D., for
his effective leadership, encouragement and guidance in the mini project.
We highly indebted to provide our heartfelt thanks to my respectful supervisor
Mr.K.BASKAR,M.E.,(Ph.D), for his valuable ideas, constant encouragement and
supportive guidance throughout the project.

We highly indebted to provide our heartfelt thanks to our respectful mini project
coordinator Mr.K.KARTHICK,M.E.,(Ph.D)., for his supportive guidance throughout
the mini project.

We wish to extend our sincere thanks to all teaching and nonteaching staff of
information technology department for their valuable suggestions, cooperation and
encouragement on successful completion of this project.

We wish to acknowledge the help received from various department and various
individuals during the preparation and editing stages of the manuscript.

3
 ABSTRACT

The purpose of the study is to develop blood management information system to

assist in the management of blood donor records and case to control the distribution of
blood in various part of the country based on the hospital demands without quick and
timely access to donor records, creating market strategies for blood donation, lobbying
and sensitization of blood donors become very difficult.

The blood management information system offers functionalities to quick access

donor records. The language behind the project in the part of front end is HTML and the
back end is MySQL. It enables monitoring of results and performance of blood donation
activities such that relevant and measurable object of organization can be checked. All
the updating information can be viewed by the users. It gives answers to various
managements.

4
 TABLE OF CONTENTS
CHAPTER NO TITLE PAGE NO
ABSTRACT 4
1 INTRODUCTION
1.1 Objective 6
1.2 Problem Description 7
2 REQUIREMENT SPECIFICATION
2.1 Hardware specification 12
2.2 Software specification 12
3 ANALYSIS
3.1 Existing system 13
3.2 Feasibility study 14
4 DESIGN
17
4.1 DFD&UML Diagram
30
4.2 Sequence Diagram
35
4.3 Database Design
38
4.4 ER Diagram
42
4.5 Database Table
58
4.6 Data Dictionary
64

5 IMPLEMENTATION
5.1Source Code 71
6 TESTING
6.1 Introduction 77

5
 6.2 Functional testing 78
6.3 Test result 79
7 SCREEN SHOTS 80

8 CONCLUSION
8.1 Conclusion 81
8.2 Limitations 81
8.3 Benefits 82

9 REFERENCE

9.1 References for blood donation 83

6
 CHAPTER-I
1.INTRODUCTION

1.1 Objective:

The Blood Donation Agent is to create an e-Information about the donor and organization
that are related to donating the blood. Through this application any person who is interested in donating
the blood can register himself in the same way if any organization wants to register itself with this site
that can also register. Moreover if any general consumer wants to make request blood online he can also
take the help of this site. Admin is the main authority who can do addition, deletion, an d
modification if required.

1.2Problem Description:
This project is aimed to developing an online Blood Donation Information. The entire project
has been developed keeping in view of the distributed client server computing technology, in mind.
The Blood Donation Agent is to create an e-Information about the donor and organization
that are related to donating the blood. Through this application any person who is interested in donating
the blood can register himself in the same way if any organization wants to register itself with this site
that can also register. Moreover if any general consumer wants to make request blood online he can also
take the help of this site.
Admin is the main authority who can do addition, deletion, and modification if
required.
The project has been planned to be having the view of distributed architecture, with
centralized storage of the database. The application for the storage of the data has been planned. Using
the constructs of MS-SQL Server and all the user interfaces have been designed using the ASP.Net
technologies.
The database connectivity is planned using the “SQL Connection” methodology. The
standards of security and data protective mechanism have been given a big choice for proper usage. The
application takes care of different modules and their associated reports, which are produced as per the

7
applicable strategies and standards that are put forwarded by the administrative staff.
The application takes care of different modules and their associated reports, which are
produced as per the applicable strategies and standards that are put forwarded by the administrative staff.
The entire project has been developed keeping in view of the distributed client server
computing technology, in mind. The specification has been normalized up to 3NF to eliminate all the
anomalies that may arise due to the database transaction that are executed by the general users and the
organizational administration. The user interfaces are browser specific to give distributed accessibility
for the overall system. The internal database has been selected as MS-SQL server 2000.

The basic constructs of table spaces, clusters and indexes have been exploited to provide
higher consistency and reliability for the data storage. The MS-SQL server 2000 was a choice as it
provides the constructs of high-level reliability and security. The total front end was dominated using the
ASP.Net technologies. At all proper levels high care was taken to check that the system manages the data
consistency with proper business rules or validations.

1.3.MODULES:
Administration:

In this module the Administrator has the privileges to add all the Blood search all the
Groups,Blood Type, Organization, Type, Country, State, City, and Location. He can info
about the Organization, Donor.
User Account:
 AccountID
 Username
 Password
 UserDesc
 HintQuestion
 Answer
 RoleID
 Active

8
 Functionality:
 Association User Account with Organisation.
 Association User Account with personal Details.
 Association User Account with Employee deatails.
 Association User Account with BloodDonation Details.
Alerts:
 All fields are mandatory
 Select user role
 Select role id
 Select role name
UserRole:
 RoleName
 RoleDesc
 Active
Functionality:
 Association user role with user Account
Alerts:
 Select Role Id
 Select role name
BDA State:
 StateID
 StateName
 StateCode
 StateDesc
 CountryID
 Active
Functionality:
 Association state with city
 Assocition state with Address

9
Alerts:
 Select State id
 Select state name
Country:
 CountryID
 CountryName
 CountryDesc
 CountryCode
 Active
Functionality:
 Association state with country
 Assocition state with Address
Alerts:
 Select countryId
 Select countryname
 Select country code
BDA City:
 CityID
 CityName
 CityDesc
 CityCode
 StateID
 Active
Functionality:
 Association Location with city
 Assocition Address with city.
Alerts:
 Select cityId

10
  Select cityNane
 Select state code
BDALocation:
 LocationID
 LocationName
 LocationDesc
 LocationCode
 CityID
 Pin code
 Active
Functionality:
 Association Location with Address.
Alerts:
 Select LocationId
 Select Location Name
 Select Pincode.
BloodGroup:
 BloodGroupID
 BloodGroup
 Description
 Active
Functionality:
 Association Blood group with Personal details.
Alerts:
 Select BloodGroupID
 Select BloodGroupID
Blood Type:
 BloodTypeID

11
  TypeName
 TypeDesc
 Active
Functionality:
 Association Blood type with Personal details.
Personal Details:
 UserAccountID
 FirstName
 MiddleName
 LastName
 Email
 DOB
 Weight
 Gender
 ImageURL
Functionality:
 Association personal detaials withpreferd location Day Time Details.

12
 CHAPTER-II
2.REQUIREMENT SPECIFICATION

2.1. HARDWARE SPECIFICATION:

1.PIV 2.8 GHz Processor

2.RAM 512MB and Above
3.HDD 20 GB Hard Disk Space and Above

2.2 SOFTWARE SPECIFICATION:

1.WINDOWS OS (XP / 2000 / 200 Server / 2003 Server)

2.Visual Studio .Net 2005 Enterprise Edition
3.Internet Information Server 5.0 (IIS)
4.Visual Studio .Net Framework (Minimal for Deployment)
5.SQL Server 2000 Enterprise Edition

13
 CHAPTER-III
3. SYSTEM ANALYSIS
Software Requirement Specification (SRS)
The software, Site Explorer is designed for management of web sites from a remote location.
INTRODUCTION
Purpose: The main purpose for preparing this document is to give a general insight into the analysis
and requirements of the existing system or situation and for determining the operating characteristics of
the system.
Scope: This Document plays a vital role in the development life cycle (SDLC) and it describes the
complete requirement of the system. It is meant for use by the developers and will be the basic during
testing phase. Any changes made to the requirements in the future will have to go through formal
change approval process.

DEVELOPERS RESPONSIBILITIES OVERVIEW:

The developer is responsible for:

 Developing the system, which meets the SRS and solving all the requirements of the system?
 Demonstrating the system and installing the system at client's location after the acceptance testing is
successful.
 Submitting the required user manual describing the system interfaces to work on it and also the
documents of the system.
 Conducting any user training that might be needed for using the system.
 Maintaining the system for a period of one year after installation.

3.1.Existing System:
 Cannot Upload and Download the latest updates.
 No use of Web Services and Remoting.
 Risk of mismanagement and of data when the project is under development.
 Less Security.

14
  No proper coordination between different Applications and Users.
 Fewer Users – Friendly

Disadvantages
1. User friendliness is provided in the application with various controls.
2. The system makes the overall project management much easier and flexible.
3. Readily upload the latest updates, allows user to download the alerts by clicking the URL.
4. There is no risk of data mismanagement at any level while the project development is under
process.
5. It provides high level of security with different level of authentication.

Proposed System:
To debug the existing system, remove procedures those cause data redundancy, make navigational
sequence proper. To provide information about audits on different level and also to reflect the current
work status depending on organization/auditor or date. To build strong password mechanism.

Advantages:
 User friendliness I provided in the application with various controls.
 The system makes the overall project management much easier and flexible.
 Readily upload the latest updates ,allows user to download the alerts by clicking the url.
 It provides high level of security with different level of authentication.

3.2. Feasibility Study:

Preliminary investigation examine project feasibility, the likelihood the system will be useful to
the organization. The main objective of the feasibility study is to test the Technical, Operational and
Economical feasibility for adding new modules and debugging old running system. All system is
feasible if they are unlimited resources and infinite time. There are aspects in the feasibility study
portion of the preliminary investigation:

15
  Technical Feasibility
 Operation Feasibility
 Economical Feasibility

Technical Feasibility

The technical issue usually raised during the feasibility stage of the investigation includes the
following:

 Does the necessary technology exist to do what is suggested?

 Do the proposed equipments have the technical capacity to hold the data required to use the new
system?
 Will the proposed system provide adequate response to inquiries, regardless of the number or
location of users?
 Can the system be upgraded if developed?
 Are there technical guarantees of accuracy, reliability, ease of access and data security?

Earlier no system existed to cater to the needs of ‘Secure Infrastructure Implementation

System’. The current system developed is technically feasible. It is a web based user interface for audit
workflow at NIC-CSD. Thus it provides an easy access to the users.

The database’s purpose is to create, establish and maintain a workflow among various entities in
order to facilitate all concerned users in their various capacities or roles. Permission to the users would
be granted based on the roles specified. Therefore, it provides the technical guarantee of accuracy,
reliability and security.

The software and hard requirements for the development of this project are not many and are
already available in-house at NIC or are available as free as open source. The work for the project is
done with the current equipment and existing software technology. Necessary bandwidth exists for
providing a fast feedback to the users irrespective of the number of users using the system.

16
Operational Feasibility

Proposed projects are beneficial only if they can be turned out into information system. That
will meet the organization’s operating requirements. Operational feasibility aspects of the project are to
be taken as an important part of the project implementation. Some of the important issues raised are to
test the operational feasibility of a project includes the following: -

 Is there sufficient support for the management from the users?

 Will the system be used and work properly if it is being developed and implemented?
 Will there be any resistance from the user that will undermine the possible application benefits?

This system is targeted to be in accordance with the above-mentioned issues. Beforehand, the
management issues and user requirements have been taken into consideration. So there is no question
of resistance from the users that can undermine the possible application benefits.

The well-planned design would ensure the optimal utilization of the computer resources and would help
in the improvement of performance status.

Economic Feasibility

A system can be developed technically and that will be used if installed must still be a good investment
for the organization. In the economical feasibility, the development cost in creating the system is
evaluated against the ultimate benefit derived from the new systems. Financial benefits must equal or
exceed the costs.

The system is economically feasible. It does not require any addition hardware or software.
Since the interface for this system is developed using the existing resources and technologies available
at NIC, There is nominal expenditure and economical feasibility for certain.

17
 CHAPTER-IV

4. SYSTEM DESIGN
4.1. Data Flow Diagrams (DFD)
A data flow diagram is graphical tool used to describe and analyze movement of data through a
system. These are the central tool and the basis from which the other components are developed. The
transformation of data from input to output, through processed, may be described logically and
independently of physical components associated with the system. These are known as the logical data
flow diagrams.
The physical data flow diagrams show the actual implements and movement of data between
people, departments and workstations. A full description of a system actually consists of a set of data
flow diagrams. Using two familiar notations Yourdon, Gane and Sarson notation develops the data
flow diagrams. Each component in a DFD is labeled with a descriptive name. Process is further
identified with a number that will be used for identification purpose.
The development of DFD’S is done in several levels. Each process in lower level diagrams can
be broken down into a more detailed DFD in the next level. The lop-level diagram is often called
context diagram. It consists a single process bit, which plays vital role in studying the current system.
The process in the context level diagram is exploded into other process at the first level DFD.
The idea behind the explosion of a process into more process is that understanding at one level
of detail is exploded into greater detail at the next level. This is done until further explosion is
necessary and an adequate amount of detail is described for analyst to understand the process.
Larry Constantine first developed the DFD as a way of expressing system requirements in a
graphical from, this lead to the modular design.
A DFD is also known as a “bubble Chart” has the purpose of clarifying system requirements
and identifying major transformations that will become programs in system design. So it is the starting
point of the design to the lowest level of detail. A DFD consists of a series of bubbles joined by data
flows in the system.

18
DFD SYMBOLS:
In the DFD, there are four symbols
1. A square defines a source(originator) or destination of system data
2. An arrow identifies data flow. It is the pipeline through which the information flows
3. A circle or a bubble represents a process that transforms incoming data flow into outgoing data
flows.
4. An open rectangle is a data store, data at rest or a temporary repository of data

Process that transforms data flow.

Source or Destination of data

Data flow

Data Store

CONSTRUCTING A DFD:
Several rules of thumb are used in drawing DFD’S:

1. Process should be named and numbered for an easy reference. Each name should be representative
of the process.
2. The direction of flow is from top to bottom and from left to right. Data traditionally flow from
source to the destination although they may flow back to the source. One way to indicate this is to
draw long flow line back to a source. An alternative way is to repeat the source symbol as a
destination. Since it is used more than once in the DFD it is marked with a short diagonal.
3. When a process is exploded into lower level details, they are numbered.
4. The names of data stores and destinations are written in capital letters. Process and dataflow names
have the first letter of each work capitalized

19
 A DFD typically shows the minimum contents of data store. Each data store should contain all
the data elements that flow in and out.
Questionnaires should contain all the data elements that flow in and out. Missing interfaces
redundancies and like is then accounted for often through interviews.

SAILENT FEATURES OF DFD’S

1. The DFD shows flow of data, not of control loops and decision are controlled considerations do not
appear on a DFD.
2. The DFD does not indicate the time factor involved in any process whether the dataflow take place
daily, weekly, monthly or yearly.
3. The sequence of events is not brought out on the DFD.

TYPES OF DATA FLOW DIAGRAMS

1. Current Physical
2. Current Logical
3. New Logical
4. New Physical

CURRENT PHYSICAL:
In Current Physical DFD proecess label include the name of people or their positions or the
names of computer systems that might provide some of the overall system-processing label includes an
identification of the technology used to process the data. Similarly data flows and data stores are often
labels with the names of the actual physical media on which data are stored such as file folders,
computer files, business forms or computer tapes.

CURRENT LOGICAL:
The physical aspects at the system are removed as mush as possible so that the current system is
reduced to its essence to the data and the processors that transform them regardless of actual physical
form.

20
NEW LOGICAL:
This is exactly like a current logical model if the user were completely happy with he user were
completely happy with the functionality of the current system but had problems with how it was
implemented typically through the new logical model will differ from current logical model while
having additional functions, absolute function removal and inefficient flows recognized.

NEW PHYSICAL:
The new physical represents only the physical implementation of the new system.

RULES GOVERNING THE DFD’S

PROCESS
1) No process can have only outputs.
2) No process can have only inputs. If an object has only inputs than it must be a sink.
3) A process has a verb phrase label.

DATA STORE
1) Data cannot move directly from one data store to another data store, a process must move data.
2) Data cannot move directly from an outside source to a data store, a process, which receives, must
move data from the source and place the data into data store
3) A data store has a noun phrase label.

SOURCE OR SINK
The origin and /or destination of data.

1) Data cannot move direly from a source to sink it must be moved by a process
2) A source and /or sink has a noun phrase land

DATA FLOW
1) A Data Flow has only one direction of flow between symbols. It may flow in both directions
between a process and a data store to show a read before an update. The later is usually indicated
however by two separate arrows since these happen at different type.

21
2) A join in DFD means that exactly the same data comes from any of two or more different processes
data store or sink to a common location.
3) A data flow cannot go directly back to the same process it leads. There must be atleast one other
process that handles the data flow produce some other data flow returns the original data into the
beginning process.
4) A Data flow to a data store means update (delete or change).
5) A data Flow from a data store means retrieve or use.

Context Diagram

Admin

DataBase

Call Center

Blood Donation
Donor
Agent

Organization

Future Use

22
1st Level DFD’s

Level 1 DFD: For Admin Module

Admin

Admin
Login data
login

Value Abilities View of value

Table Abilities details

Level 1 DFD: For Users Module

Call center

Login

Value Abilities updating and

Table editing

23
DFD For Donor Creation

Donor Donor Id
Details

Insert New
Donor
Insert Donor
Verify Id Verify
Data Data

1.1 1.2

Insert

DonorDetails

24
 DFD For Operator Creation

Operator Id
Operator
Details

Verify
Insert New Data
Operator

Verify 2.2
Data

2.1

Insert
Operator Id

Inser
t

Operator
Details

25
DFD For Call Center Creation

Call Center
Call Center Id
Details

Verify
Insert New Data
Call Center
Verify
Data 3.2
3.1

Insert Call
Center Id

Call Center
Details

Insert

Donor
Details

26
DFD for Donor Creation

Donor Donor Id
Organizati
Details on Details

Insert New
Donor
Verify Data Verify Data
Verify Data
4.1 4.2
4.3

Insert
Donor
Details
Insert Donor Id
Check in
Organization

Check for
Check for Dates
Check for
Verify Blood Type Verify Appointm Verify
ent Data
Data Data
Details
4.4

4.6 4.5

Appointment Dates
Blood Details Details Details

Insert

Donor Details 27
 3rd Level DFD’S
DFD For Donor Creation

Donor Details Organization Details Dates Details

Request for new

Donor
Generate Validate
Validate
Donor-Id Org-Id ()
() Dates-Id ()

Validate Validate
Blood-Id () App-Id ()
Commit
()

Database
Updated

Blood Details Appointment Details

Donar Details

28
 Work Flow of All Modules

Administrator

Login data

Logs In

Donar

Call Organiza

Appointment Center tion

Details

Various Reports Blood Details View Random

Generated the Information for
Donar the App Donar
Donor Report

Operator Report

Call Center Report

29
4.2. UML Diagrams

Use Case Diagram:

 The unified modeling language allows the software engineer to express an analysis model using the
modeling notation that is governed by a set of syntactic semantic and pragmatic rules.

 A UML system is represented using five different views that describe the system from distinctly
different perspective. Each view is defined by a set of diagram, which is as follows.

 User Model View

i. This view represents the system from the users perspective.

ii. The analysis representation describes a usage scenario from the end-users perspective.
Structural model view
1.In this model the data and functionality are arrived from inside the system.

2.This model view models the static structures.

Behavioral model view

It represents the dynamic of behavioral as parts of the system, depicting the interactions
of collection between various structural elements described in the user model and structural model
view.

Implementation Model View

In this the structural and behavioral as parts of the system are represented as they are to be built.

Environmental Model View

In this the structural and behavioral aspects of the environment in which the system is to
be implemented are represented.

30
UML is specifically constructed through two different domains they are

 UML Analysis modeling, which focuses on the user model and structural model views of the
system.

 UML design modeling, which focuses on the behavioral modeling, implementation modeling and
environmental model views.

Use case Diagrams represent the functionality of the system from a user’s point of view. Use cases
are used during requirements elicitation and analysis to represent the functionality of the system. Use
cases focus on the behavior of the system from external point of view.
Actorsare external entities that interact with the system. Examples of actors include users like
administrator, bank customer …etc., or another system like central database.

Use case Model

SYSTEM NAME

Use case 1

Use case 2

Actor
Actor

Use case n

31
Use Cases of Blood Donation Agent Interface
Use case For Admin Module

Blood Donation Agent Interface

Home Page

Login Page

Donar Home Page

DonorAccountDetail

Admin MakeRequestForBlood

OrganizationSearchPage

Search

Contact S

About US

32
Use case For Donor Module

Blood Donation Agent Interface

Home page

Login Page

Donar Home Page

DonorAccountDetail

MakeRequestForBlood

OrganizationSearchPage

Search

Contact S

About us

Donor

33
Use case name Login
Participating Admin, Donor, Call Center, Organization
actors
Flow of events The Actor will give the user name and password to the system. The
system will verify the authentication.
Entry The actor will enter the system by using username and password
Condition
Exit condition If un authenticated should be exited
Quality Password must satisfy the complexity requirements.
Requirements

Use case name Admin Registration

Participating Admin
actors
Flow of events The Admin will submit all the details and place in the application.
Entry Must satisfy all the norms given by the Blood Donation Agent interface
Condition site.
Exit condition Successful or Un successful completion of creation of account.
Quality All fields are mandatory.
Requirements

Use case name Donor Registration

Participating Donor
actors
Flow of events The Donor must enter all his personal details.
Entry View Home page
Condition
Exit condition Registered Donor should be successfully logged out. Error Message

34
 should be displayed on Un successful creation.
Quality Best Error Handling techniques. Check on Mandatory fields.
Requirements

Use case name CallCenter Registration

Participating CallCenter
actors
Flow of events The CallCenter must enter all his personal details.
Entry View Home page
Condition
Exit condition Registered CallCenter should be successfully logged out. Error
Message should be displayed on Un successful creation.
Quality Best Error Handling techniques. Check on Mandatory fields.
Requirements

Use case name Organization Registration

Participating Organization
actors
Flow of events The Organization must enter all his personal details.
Entry View Home page
Condition
Exit condition Registered Organization should be successfully logged out. Error
Message should be displayed on Un successful creation.
Quality Best Error Handling techniques. Check on Mandatory fields.
Requirements

35
4.3.SEQUENCE DIAGRAM:
Sequence Diagrams Represent the objects participating the interaction horizontally and time
vertically.

Sequence Diagram for Admin

: Login : Create Bank : Log Out

Account
Admin
Use url

Press login button

Press Create Account

Time

Sequence Diagram for Donor

: Login : Accounts DB

Donor

Press login button ()

Get login page ()

Validate forms ()

Press create accounts button ()

36
Sequence Diagram for organization

: Login : Accounts DB

Organization

Press login button ()

Get login page ()

Validate forms ()

Press create accounts button ()

Sequence Diagram 5

: Login Admin : TX Validate : Account : DB

Home
Page Validate
Admin

Press login button()

Select Validate or Reject
Transaction ()

Press Accept/Reject Button

Select Validate or Reject Account()

Reports()

37
4.4. Database Design
Entities with Attributes:
1.Administration:
User Account:
 AccountID
 Username
 Password
 UserDesc
 HintQuestion
 Answer
 RoleID
 Active
UserRole:
 RoleID
 RoleName
 RoleDesc
 Active
BDAState:
 StateID
 StateName
 StateCode
 StateDesc
 CountryID
 Active
Country:
 CountryID
 CountryName
 CountryDesc
 CountryCode

38
BDACity:
 CityID
 CityName
 CityDesc
 CityCode
 StateID
 Active
BDALocation:
 LocationID
 LocationName
 LocationDesc
 LocationCode
 CityID
 Pin code
 Active
BloodGroup:
 BloodGroupID
 BloodGroup
 Description
 Active
BloodType:
 BloodTypeID
 TypeName
 TypeDesc
 Active
PersonalDetails:
 UserAccountID
 FirstName
 MiddleName

39
  LastName
 Email
 DOB
 Weight
 Gender
 ImageURL
 BloodGroupID
 BloodType
 BloodType
 AddressID
 ContactNo_Office
 ContactNo_Residence
 MobileNo
 Active
EmployeeDetail:
 EmpId
 Name
 Address
 Phone
 Email
 Active
DonationFrequencies:
 FrequencyID
 Frequency
 Description
 Active
Donor Preferred Organization:
 UserAcountID
 OrganisationID

40
  Active
Organisation:
 OrgID
 OrgName
 OrgType
 Email
 OrgAddrID
 OrgImageURL
 OrgDescription
 ContactNo
 MobileNo
 Active
 Comment
OrganisationType:
 TypeID
 Type name
 TypeDescription

41
 4.5. ER Diagrams:
ER diagram for User Account and Users

Has/
User Account: UserRole:
belo
ngs
e

UserAccount: UserRole:
RoleID
AccountID
RoleName
Username RoleDesc

Password Active

UserDesc

HintQuestion

Answer

RoleID

42
 ER diagram for User Account and Organisation

User Account Has/ Organisation:

belo
ngs

Organisation:
UserAccount:
OrgID
AccountID OrgName
OrgType
Username
Email
Password OrgAddrID
OrgImageURL
UserDesc
OrgDescription
Hint Question ContactNo
MobileNo
Answer Active

RoleID Comment

43
 ER diagram for Users Account and Personal Details

Has/
belo Personal details
User Account: ngs

UserAccount: Personal Details:

AccountID First Name

Email
Username
DOB
Password Weight
UserDesc Gender
ImageURL
HintQuestion
BloodGroupID
Answer
BloodType
RoleID BloodType
AddressID
ContactNo_Office
ContactNo_Residence
MobileNo
Active
MiddleName

44
 ER diagram for User Account and Employee Details

Employee Details
User Account
Has/
belo
ngs

User Account: Employee Details:

Emp Id
AccountID
Name
Username
Address
Password Phone
Email
User Desc
Active
Hint Question

Answer

Role ID

45
 ER diagram for User Role and Blood User account

Has/ User Account

UserRole belo
ngs

User Account:
UserRole:
AccountID
RoleID
Username
RoleName
Password
RoleDesc
User Desc
Active
Hint Question

Answer

Role ID

46
 ER diagram for State and BDA City

Has/
State BDAcity
belo
ngs

BDACity:
BDAState:
CityID

StateID
CityName

StateName
CityDesc

StateCode
CityCode
StateDesc
StateID

CountryID
Active
Active

47
 ER diagram for State and Address

State Has/ Address:

belo
ngs

dBDA_Address
BDAState:

AddressID
StateID

AddressLine1
StateName

LocationID
StateCode

CityID
StateDesc

StateID
CountryID

CountryID
Active

CountryID

Zipcode

Active

48
 ER diagram for State and Country:

State Has/ Country

belo
ngs

BDAState:
Country:
StateID
CountryID
StateName
CountryName
StateCode
CountryDesc
StateDesc
CountryCode
CountryID
Active
Active

49
 ER diagram for Location and City

Has/
Location: belo State
ngs

BDALocation:
BDAState:

LocationID
StateID

LocationName
StateName

LocationDesc
StateCode

LocationCode
StateDesc
CityID
CountryID
Pin code
Active
Active

50
 ER diagram for Location and City

Has/ City:
DBDAddress:
belo
ngs

BDACity:
dBDA_Address
CityID
AddressID
CityName
AddressLine1
CityDesc
LocationID
CityCode
CityID
StateID
StateID
Active
CountryID

CountryID

Zipcode

Active

51
 ER diagram for Location and Address

BDALocation: DBDAddress:
Has/
belo
ngs

BDALocation: DBDAAddress

LocationID AddressID

LocationName AddressLine1

LocationDesc LocationID

LocationCode CityID

CityID StateID

Pin code CountryID

Active CountryID

Zipcode

Active

52
ER diagram for Blood group Personal details

Has/
Blood group: Personal details
belo
ngs

Personal details:
BloodGroup:
UserAccountID
BloodGroupID
FirstName
BloodGroup
MiddleName
Description
LastName
Active
Email

DOB

Weight

Gender

ImageURL

BloodGroupID

BloodType

AddressID

ContactNo_Office

ContactNo_Residence

MobileNo

Active

53
 ER diagram for Personal details and Blood Donation preferences

Personal details Preferd location Day Time Details.

Has/
belo
ngs
Personal details:
PreferredDonationDayTime
UserAccountID DonorPreferenceID

FirstName WeekDay

MiddleName TimeFrom

LastName TimeFrom
Email TimeUpto
DOB UserAccountID
Weight Comment

Gender Active

ImageURL

BloodGroupID

BloodType

AddressID

ContactNo_Office

ContactNo_Residence

MobileNo

54
Active

ER diagram for Donor Frequencies and Blood Donation Preferences

Has/
belo 55
ngs
DonationFrequencies: BloodDonationPrefere
nce

BloodDonationPreference:
DonationFrequencies:
PreferenceID
FrequencyID
UserAccountID
Frequency
DonationFrequencyID
Description
WantToDonateWhitecells
Active
Active

ER diagram for Donor preferred organization and personal details

Has/
belo
ngs

56
DonorPreferredOrganisation:
 UserAcountID
Donar preferred organization Persan
OrganisationID

Active
Personal details:

UserAccountID

FirstName

MiddleName

LastName

Email

DOB

Weight

Gender

ImageURL

BloodGroupID

BloodType

AddressID

ContactNo_Office

ContactNo_Residence

MobileNo

Active

ER diagram for Organization type and Organization

Organization type Has/ Organization

belo
ngs
57
 Organisation:
OrganisationType: OrgID

TypeID OrgName
OrgType
TypeName Email
OrgAddrID
TypeDescription
OrgImageURL

OrgImage OrgDescription
ContactNo
Active MobileNo
Active
Comment

4.6. Database Tables

1.Entities

 BDA_BloodDonationDetails

58
  BDA_BloodDonationPreference
 BDA_BloodGroup
 BDA_BloodRequest
 BDA_BloodType
 BDA_City
 BDA_Country
 BDA_DonationFrequencies
 BDA_DonorPreferredOrganisation
 BDA_EmployeeDetail
 BDA_FAQ
 BDA_Location
 BDA_Organisation
 BDA_OrganisationType
 BDA_PersonalDetails
 BDA_PreferredDonationDayTime
 BDA_State
 BDA_UserAccount
 BDA_UserRole

2.Entities with Attributes

1. BDA Address
 AddressID
 AddressLine1
 LocationID
 CityID
 StateID
 CountryID
 Zipcode
 Active
2. BDA BloodDonationDetails

59
  ID
 DonorID
 DonationDate
 TakerID
 OrgID
 Quantity
 Comment
 Active
3. BDA BloodDonationPreference
 PreferenceID
 UserAccountID
 DonationFrequencyID
 WantToDonateWhitecells
 Active
4. BDA BloodRequest
 RequestID
 DonorId
 OrgId
 Name
 Email
 Phone
 Country
 State
 City
 Location
 BloodRequireAddress
 BloodType
 BloodGroup
 AppDate
 Request Date

60
  Status
 RequestType
5. BDA BloodGroup
 BloodGroupID
 BloodGroup
 Description
 Active
6. BDA BloodType
 BloodTypeID
 TypeName
 TypeDesc
 Active
7. BDA City
 CityID
 CityName
 CityDesc
 CityCode
 StateID
 Active
8. BDA Country
 CountryID
 CountryName
 CountryDesc
 CountryCode
 Active

9. BDA DonationFrequencies
 FrequencyID
 Frequency

61
  Description
 Active
10. BDA DonorPreferredOrganisation
 UserAcountID
 OrganisationID
 Active
11. BDA EmployeeDetail
 EmpId
 Name
 Address
 Phone
 Email
 Active
12. BDA_FAQ
 FaqID
 Question
 Answer
 Active
13. BDA Location
 LocationID
 LocationName
 LocationDesc
 LocationCode
 CityID
 Pincode
 Active
14. BDA Organisation
 OrgID
 OrgName
 OrgType

62
  Email
 OrgAddress ID
 OrgImageURL
 OrgDescription
 ContactNo
 MobileNo
 Active
 Comment
15. BDA OrganisationType
 TypeID
 TypeName
 TypeDescription
 OrgImage
 Active
16. BDA PersonalDetails
 UserAccountID
 FirstName
 MiddleName
 LastName
 Email
 DOB
 Weight
 Gender
 ImageURL
 BloodGroupID
 BloodType
 AddressID
 Contact No Office
 Contact No Residence
 MobileNo

63
  Active
17. BDA PreferredDonationDayTime
 DonorPreferenceID
 WeekDay
 TimeFrom
 TimeUpto
 UserAccountID
 Comment
 Active
18. BDA State
 StateID
 StateName
 StateCode
 StateDesc
 CountryID
 Active
19. BDA UserAccount
 AccountID
 Username
 Password
 UserDesc
 HintQuestion
 Answer
 RoleID

4.7. Data Dictionary:

BDA_ Address

Sno Column name Data type Constraint reference

64
1 AddressID Bigint Primary Key
2 AddressLine1 varchar(512) Not null
3 LocationID Bigint Foreign key BDA_Location
4 CityID Bigint Foreign key BDA_City
5 StateID Bigint Foreign key BDA_state
6 CountryID Bigint Allow Null BDA_Country
7 Zipcode varchar(10) Allow Null
8 Active Bit Not Null

BDA_BloodDonationDetails

Sno Column name Datatype Constraint reference

1 ID Bigint Primary Key
2 DonorID Bigint Foreign key BDA_BloodRequest
3 DonationDate Datetime Notnull
4 TakerID Bigint Foreign key BDA_UserAccount
5 OrgID Bigint Foreign key Bda_Organisation
6 Quantity varchar(10) Allow Null
7 Comment varchar(1024) Allow Null
8 Active Bit Notnull

BDA_BloodDonationPreference

Sno Columnname Datatype Constraint Reference

1 PreferenceID Bigint Primary key

65
2 UserAccountID Bigint Foreign key BDA_UserAccount

3 DonationFrequencyID Tinyint Foreign key BDA_Donation Frequencies

4 WantToDonateWhitecells Bit AllowNull

5 Active Bit AllowNull

BDA_BloodGroup

Sno Columnname Datatype Constraint reference

1 BloodGroupID Tinyint Primary Key
2 BloodGroup varchar(10) Not Null
3 Description varchar(1024) Allow Null
4 Active Bit Not Null

BDA_BloodRequest

Sno Columnname Datatype Constraint Reference

1 RequestID Int Primary Key
2 DonorId Bigint Foreign key BDA_UserAccount
3 OrgId Bigint Foreign key BDA_Organisation
4 Name varchar(50) Allow Null
5 Email varchar(50) Allow Null
6 Phone varchar(20) Allow Null
7 Country varchar(50) Allow Null
8 State varchar(50) Allow Null
9 City varchar(50) Allow Null
10 Location varchar(50) Allow Null
11 BloodRequireAddress varchar(100) Allow Null
12 BloodType varchar(50) Allow Null
13 BloodGroup varchar(50) Allow Null

66
14 AppDate Datetime Allow Null
15 ReqDate Datetime Allow Null
16 Status varchar(10) Allow Null
17 RequestType varchar(50) Allow Null

BDA_City

Sno Columnname Datatype Constraint Reference

1 CityID Bigint Primary key
2 CityName varchar(100) Not null
3 CityDesc varchar(1024) Allownull
4 CityCode varchar(5) Allownull
5 StateID Bigint Foreign key BDA_State
6 Active Bit Notnull

BDA_BloodType

Sno Columnnames Datatypes Constraint reference

1 BloodTypeID Tinyint Primary Key
2 TypeName varchar(50) Not null
3 TypeDesc varchar(1024) AllowNull
4 Active Bit Notnull

BDA_Country

Sno Columnname Datatype Constraint Reference

1 CountryID Bigint Primary key

67
2 CountryName varchar(100) Not null
3 CountryDesc varchar(1024) Allow Null
4 CountryCode varchar(5) Allow Null
5 Active Bit Not null

BDA_DonationFrequencies

Sno Columnname Datatype Constraint Reference

1 FrequencyID Tinyint Primary key
2 Frequency varchar(50) Not null
3 Description varchar(255) Allow null
4 Active Bit Allow null

BDA_DonorPreferredOrganisation

Sno Columnname Datatype Constraint Reference

1 UserAcountID Bigint Primary key
2 OrganisationID Bigint Not null
3 Active Bit Allow null

BDA_EmployeeDetail

Sno Columnname Datatype Constraint reference

1 EmpId Bigint Primary Key
2 Name varchar(60) Allow Null
3 Address varchar(150) Allow Null
4 Phone varchar(20) Allow Null
5 Email varchar(25) Allow Null
6 Active Tinyint Allow Null

68
BDA_FAQ

Sno Columnname Datatype Constraint reference

1 FaqID Bigint Primary key
2 Question varchar(300) Allow null
3 Answer varchar(1000) Allow null
4 Active Bit Allow null

BDA_Location

Sno Columnname Datatype Constraints reference

1 LocationID Bigint Primary Key
2 LocationName varchar(100) Not Null
3 LocationDesc varchar(1024) Allow null
4 LocationCode varchar(5) Allow null
5 CityID Bigint Allow null
6 Pincode varchar(10) Allow null
7 Active Bit Allow null

BDA_Organisation

Sno Columnname Datatype Constraint reference

1 OrgID Bigint Primary key
2 OrgName varchar(100) Not null
3 OrgType Tinyint Foreign key BDA_Organisation Type
4 Email varchar(50) Allownull
5 OrgAddrID Bigint Foreign key BDA_Address
6 OrgImageURL varchar(155) Allownull
7 OrgDescription varchar(1024) Allownull

69
8 ContactNo varchar(20) Allownull
9 MobileNo varchar(20) Allownull
10 Active Bit Allownull
11 Comment varchar(512) Allownull

BDA_OrganisationType

Sno Columnname Datatype Constraint Reference

1 TypeID Tinyint Primary key
2 TypeName varchar(50) Not null
3 TypeDescription varchar(50) Allow null
4 OrgImage varchar(300) Allow null
5 Active Bit Allow null

BDA_PreferredDonationDayTime

Sno Columnnames Datattype Constarint Reference

1 DonorPreferenceID Bigint Primary Key
2 WeekDay varchar(10) Not null
3 TimeFrom varchar(10) Allow null
4 TimeUpto varchar(10) Allow null
5 UserAccountID Bigint Allow null
6 Comment varchar(1024) Allow null
7 Active Bit Not null

BDA_PersonalDetails
Sno Columnname Datatype Constraint Reference
1 UserAccountID Bigint Primary Key
2 FirstName varchar(50) Not Null
3 MiddleName varchar(50) Allow Null

70
4 LastName varchar(50) Allow Null
5 Email varchar(100) Allow Null
6 DOB Datetime Notnull
7 Weight Float Allow Null
8 Gender varchar(6) Not Null
9 ImageURL varchar(155) Allow Null
10 BloodGroupID Tinyint Foreign key BDA_Bloodgroup
11 BloodType Tinyint Foreign key BDA_BloodType
12 AddressID Bigint Foreign key BDA_Address
13 ContactNo_Office varchar(20) Allow Null
14 ContactNo_Residence varchar(20) Allow Null
15 MobileNo varchar(20) Not Null
16 Active Bit Allow Null

BDA_UserRole

Sno Columnname DAtatype Constraint Reference

1 RoleID Tinyint Primary key
2 RoleName varchar(50) Not null
3 RoleDesc varchar(1024) Allow null
4 Active Bit Not null

BDA_State

Sno Columnname Datatype Constraint Reference

1 StateID Bigint Primary key

71
2 StateName varchar(100) Not null

3 StateCode varchar(5) Allow null

4 StateDesc varchar(1024 Allow null

)
5 CountryID Bigint Foreign Key BDA_Country
6 Active Bit Not null

BDA_UserAccount

Sno Columnname Datatype Constraint Reference

1 AccountID Bigint Primary key
2 Username varchar(100) Not null
3 Password varchar(100) Not null
4 UserDesc varchar(1024) Allow null
5 HintQuestion varchar(155) Allow null
6 Answer varchar(155) Allow null
7 RoleID Tinyint Foreign key BDA_UserRole

CHAPTER-V
5.IMPLEMENTATION
5.1.CODING:
WEBCONFIG FILE:(Design Code)

72
Used to set the connections of each page.
<?xmlversion="1.0"?>
<!--
Note: As an alternative to hand editing this file you can use the
web admin tool to configure settings for your application. Use
the Website->Asp.Net Configuration option in Visual Studio.
A full list of settings and comments can be found in
machine.config.comments usually located in
\Windows\Microsoft.Net\Framework\v2.x\Config
-->
<configuration>
<appSettings>
<addkey="ConnStr"value="data source=RAMYA-
2DCA5B123;database=BloodBequeathFederalAgent;integrated security=sspi"/>
</appSettings>
<connectionStrings>
<addname="BloodDonationAgentConnectionString"connectionString="Data Source=RAMYA-
2DCA5B123;Initial Catalog=BloodDonationAgent;integrated security=sspi"
providerName="System.Data.SqlClient" />
</connectionStrings>
<system.web>
<!--
Set compilation debug="true" to insert debugging
symbols into the compiled page. Because this
affects performance, set this value to true only
during development.
-->
<compilationdebug="true">
<assemblies>
<addassembly="System.Design, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=B03F5F7F11D50A3A"/>
<addassembly="System.Web.Extensions, Version=1.0.61025.0,
Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<addassembly="System.Web.Extensions.Design, Version=1.0.61025.0,
Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<addassembly="System.Windows.Forms, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=B77A5C561934E089"/></assemblies></compilation>
<!--
The <authentication> section enables configuration
of the security authentication mode used by
ASP.NET to identify an incoming user.
-->
<authenticationmode="Windows"/>
<!--
The <customErrors> section enables configuration

73
 of what to do if/when an unhandled error occurs
during the execution of a request. Specifically,
it enables developers to configure html error pages
to be displayed in place of a error stack trace.

<customErrors mode="RemoteOnly" defaultRedirect="GenericErrorPage.htm">

<error statusCode="403" redirect="NoAccess.htm" />
<error statusCode="404" redirect="FileNotFound.htm" />
</customErrors>
-->
</system.web>
</configuration>

User Login Form

using System;
using System.Data;
using System.Configuration;
using System.Collections;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;
publicpartialclassLogin : System.Web.UI.Page
{
CheckUser user = newCheckUser();
UserAccountBusinessLayer account = newUserAccountBusinessLayer();
OrganizationAccountBusinessLayer org = newOrganizationAccountBusinessLayer();
protectedvoid Page_Load(object sender, EventArgs e)
{
txtUsername.Focus();
}

protectedvoid btnLogin_Click(object sender, EventArgs e)

{
try
{
user.Username = txtUsername.Text;
user.Password = txtPassword.Text;
//Check User

if (user.GetUser() == true)
{
account.Username = txtUsername.Text;
DataSet ds = newDataSet();
ds = account.GetAccountId();
string AcId = ds.Tables[0].Rows[0][0].ToString();
Session["username"] = txtUsername.Text;
Session["Acid"] = AcId;
DataSet ds1 = newDataSet();
account.Accountid =int.Parse(AcId);

74
 ds1 = account.GetAddressId();
Session["addid"] = ds1.Tables[0].Rows[0][0].ToString();
Response.Redirect("~/Donor/DonorHome.aspx");
}
else
Image2.Visible = true;
lblMsg.Text = "Your Login Attempt Is Failed Plz try Again....!";
txtPassword.Text = "";
txtUsername.Focus();
//Checking Organization
if (user.GetOrganization() == true)
{
account.Username = txtUsername.Text;
DataSet ds = newDataSet();
ds = account.GetAccountId();
string AcId = ds.Tables[0].Rows[0][0].ToString();
Session["username"] = txtUsername.Text;
Session["Acid"] = AcId;
DataSet ds1 = newDataSet();
org.Orgid =int.Parse(AcId);
ds1 = org.GetOrgAddressId();
Session["addid"]=ds1.Tables[0].Rows[0][0].ToString();
Response.Redirect("~/Organization/OrganizationHome.aspx");
}
else
Image2.Visible = true;
lblMsg.Text = "Your Login Atempt Is Failed Plz try Again....!";
txtPassword.Text = "";
txtUsername.Focus();
//Employee Checking
if (user.CheckEmployee() == true)
{
account.Username = txtUsername.Text;
DataSet ds = newDataSet();
ds = account.GetAccountId();
string AcId = ds.Tables[0].Rows[0][0].ToString();
Session["username"] = txtUsername.Text;
Session["Acid"] = AcId;
Response.Redirect("~/CallCenter/CallCenterHome.aspx");}} }

CHAPTER-VI
6. TESTING
6.1. INTRODUCTION

75
 Software testing is a critical element of software quality assurance and represents the ultimate
review of specification, design and coding. In fact, testing is the one step in the software engineering
process that could be viewed as destructive rather than constructive.

A strategy for software testing integrates software test case design methods into a well-planned
series of steps that result in the successful construction of software. Testing is the set of activities that
can be planned in advance and conducted systematically. The underlying motivation of program testing
is to affirm software quality with methods that can economically and effectively apply to both strategic
to both large and small-scale systems.

6.2. Functional Testing:

The software engineering process can be viewed as a spiral. Initially system engineering defines
the role of software and leads to software requirement analysis where the information domain,
functions, behavior, performance, constraints and validation criteria for software are established.
Moving inward along the spiral, we come to design and finally to coding. To develop computer
software we spiral in along streamlines that decrease the level of abstraction on each turn.
TYPES OF TESTING:
1.Unit testing
2.Module testing
3.Sub system testing
4.System testing
5.Acceptance testing

6.3. Unit Testing

Unit testing focuses verification effort on the smallest unit of software design, the module. The unit
testing we have is white box oriented and some modules the steps are conducted in parallel.

1. WHITE BOX TESTING

This type of testing ensures that

 All independent paths have been exercised at least once
 All logical decisions have been exercised on their true and false sides

76
 All loops are executed at their boundaries and within their operational bounds
 All internal data structures have been exercised to assure their validity.
To follow the concept of white box testing we have tested each form .we have created independently to
verify that Data flow is correct, All conditions are exercised to check their validity, All loops are
executed on their boundaries.

2. BASIC PATH TESTING

Established technique of flow graph with Cyclomatic complexity was used to derive test cases for all
the functions. The main steps in deriving test cases were:
Use the design of the code and draw correspondent flow graph.
Determine the Cyclomatic complexity of resultant flow graph, using formula:
V(G)=E-N+2 or
V(G)=P+1 or
V(G)=Number Of Regions
Where V(G) is Cyclomatic complexity,
E is the number of edges,
N is the number of flow graph nodes,
P is the number of predicate nodes.
Determine the basis of set of linearly independent paths.

3. CONDITIONAL TESTING
In this part of the testing each of the conditions were tested to both true and false aspects. And all the
resulting paths were tested. So that each path that may be generate on particular condition is traced to
uncover any possible errors.

4. DATA FLOW TESTING

This type of testing selects the path of the program according to the location of definition and
use of variables. This kind of testing was used only when some local variable were declared. The
definition-use chain method was used in this type of testing. These were particularly useful in nested
statements.

77
5. LOOP TESTING
In this type of testing all the loops are tested to all the limits possible. The following exercise was
adopted for all loops:

 All the loops were tested at their limits, just above them and just below them.
 All the loops were skipped at least once.
 For nested loops test the inner most loop first and then work outwards.
 For concatenated loops the values of dependent loops were set with the help of connected loop.
 Unstructured loops were resolved into nested loops or concatenated loops and tested as above.
Each unit has been separately tested by the development team itself and all the input have been

78
CHAPTER-VII

6. SCREENSHOT

79
 CHAPTER-VIII
8. CONCLUSION

8.1. CONCLUSION:
It has been a great pleasure for me to work on this exciting and challenging

Project.This project proved good for me as it provided practical knowledge of not only

programming in ASP.NET and VB.NET web based application and no some extent Windows

Application and SQL server,but also about all handling procedure related with “Blood Bequeth

Federal” .It also provides knowledge about the latest technology used in developing web enable

Application and client server technology that will be great demand in future.This will provide

Betteroppurtunities andguidance in future in developing projects independently.

8.2.BENEFITS:

The project is identified by the merits of the system offered to the user. The merits of this project are as
follows: -

 It’s a web-enabled project.

 This project offers user to enter the data through simple and interactive forms. This is very helpful
for the client to enter the desired information through so much simplicity.
 The user is mainly more concerned about the validity of the data, whatever he is entering. There are
checks on every stages of any new creation, data entry or updation so that the user cannot enter the
invalid data, which can create problems at later date.
 Sometimes the user finds in the later stages of using project that he needs to update some of the
information that he entered earlier. There are options for him by which he can update the
Records. Moreover there is restriction for his that he cannot change the primary data field. This
keeps the validity of the data to longer extent.

80
 User is provided the option of monitoring the records he entered earlier. He can see the desired
records with the variety of options provided by him.From every part of the project the user is
provided with the links through framing so that he can go from one option of the project to other as
per the requirement. This is bound to be simple and very friendly as per the user is concerned. That
is, we can said that the project is user friendly which is one of the primary concerns of any good
project.
 Data storage and retrieval will become faster and easier to maintain because data is stored in a
systematic manner and in a single database.
 Decision making process would be greatly enhanced because of faster processing of information
since data collection from information available on computer takes much less time then manual
system.
 Allocating of sample results becomes much faster because at a time the user can see the records of
last years.
 Easier and faster data transfer through latest technology associated with the computer and
communication.

8.3. LIMITATIONS:

 The size of the database increases day-by-day, increasing the load on the database back up and data
maintenance activity.
 Training for simple computer operations is necessary for the users working on the system

81
 CHAPTER-IX
9. REFERENCE
9.1. REFERENCES:

1).Safe blood and blood products. Module 1: Safe blood donation. Geneva: World Health Organization;
2002. [17 August 2012]. http://www.who.int/bloodsafety/transfusion_services/bts_learningmaterials
/en/index.html
2).Blood donor selection Guidelines on assessing donor suitability for blood donation Annex 3.Geneva:
World Health Organization; 2012. [17 August 2012]. http://www.who.int/bloodsafety
/voluntary_donation/blood_donor_selection_counselling/en/ [PubMed]

3).Aide-mémoireBlood safety. Geneva: World Health Organization; 2002. [17 August

2012]. http://www.who.int/bloodsafety/publications/who_bct_02_03/en/index.html.

4).WHO/IFRC. Towards 100% voluntary blood donation: A global framework for action. Geneva:
World Health Organization; 2010. [17 August 2012]. http://www.who.int/bloodsafety/publications
/9789241599696/en/

5).The Melbourne Declaration on 100% voluntary non-remunerated donation of blood and blood
components. Geneva: World Health Organization; 2009. [17 August 2012]. http://www
.who.int/worldblooddonorday/Melbourne_Declaration_VNRBD_2009.pdf.

6).WHO/CDC/IFRC. Blood donor counselling: Implementation guidelines. Geneva: World Health

Organization; 2012. [17 August 2012]. http://www.who.int/bloodsafety/voluntary_donation
/blood_donor_selection_counselling/en/

7).Screening donated blood for transfusion-transmissible infections. Geneva: World Health

Organization; 2010. [17 August 2012]. http://www.who.int/bloodsafety/publications
/bts_screendondbloodtransf/en/index.html.
8).Reiss RF. Blood donor well-being: a primary responsibility of blood collection agencies. Annals of
Clinical & Laboratory Science. 2011;41(1):3–[PubMed]

9).Global Database on Blood Safety. Summary report 2011. Geneva: World Health Organization; 2011.
[22 August 2012]. http://www.who.int/entity/bloodsafety/global_database
/GDBS_Summary_Report_2011.pdf.

10).Boulton F. Evidence-based criteria for the care and selection of blood donors, with some comments
on the relationship to blood supply and emphasis on the management of donation-induced iron
depletion. Transfusion Medicine. 2008;18:13–27. [PubMed]

11).Fifty-Eighth World Health Assembly. Resolution WHA58.13: Blood safety: proposal to establish
World Blood Donor Day. Geneva: World Health Organization; 2005. [17 August 2012]. http://www

82
.who.int/bloodsafety/resolutions/en/index.html & http://www.who.int/entity/bloodsafety/BTS
_ResolutionsAdopted.pdf.

12).Sixty-Third World Health Assembly. Resolution WHA63.12: Availability, safety and quality of
blood products. Geneva: World Health Organization; 2010. [17 August 2012]. http://www
.who.int/bloodsafety/resolutions/en/index.html & http://www.who.int/entity/bloodsafety/BTS
_ResolutionsAdopted.pdf.

13).WHO handbook for guideline development. Geneva: World Health Organization; 2012. [10 August
2012]. http://apps.who.int/iris/bitstream/10665/75146/1/9789241548441_eng.pdf.

14).WHO/CDC. Donor selection and counselling.Report of inter-regional workshop on blood donor

selection and donor counselling for priority countries in the African and Eastern Mediterranean
regions. Geneva: World Health Organization; Jun, 2011. [17 August 2012]. 2011.

83