A Project Report On

Library Management System

Submitted in partial fulfillment of the requirement for the award of the degree of
Bachelor of Technology

In

Information Technology

By

Amit Saurabh Dhasmana, Ankit Sharma, Kushan Thapar & Ankur Kumar

Under the Guidance of

Mrs. Ritu Pal (I.T. Co-ordinator)

Department of Information Technology

DIT School of Engineering
Approved by A.I.C.T.E.
Affiliated to U.P. Technical University, Lucknow

Greater Noida - 201306

Batch : 2007-2011
 DIT SCHOOL OF ENGINEERING

Approved by A.I.C.T.E., New Delhi

Affiliated to U.P. Technical University, Lucknow
Greater Noida – 201306.

DEPARTMENT OF INFORMATION TECHNOLOGY

CERTIFICATE

This is to certify that Amit Saurabh Dhasmana, Ankit Sharma, Kushan Thapar & Ankur Kumar
(0729113006, 0729113008, 0729113019, 0729113009) of the third year B.Tech. (I.T.) have carried out a
project work on “Library Management System” under the guidance of Mrs. Ritu Pal I.T. Co-ordinator
for the partial fulfillment of the award of the degree of Bachelor of Technology in Information
Technology in DIT School of Engineering, Gr. Noida (Affiliated to U.P. Technology University,
Lucknow) is a bonafide record of work done by them during the year 2009-2010

Head of the Department Internal Guide:

Signature with date Signature with date
Mrs. Ritu Pal
(I.T. Co-ordinator)
 ACKNOWLEDGEMENT

This project report has been made possible through the direct and indirect
cooperation of various persons for whom we wish to express our
appreciation and gratitude.

We are heartily thankful to management of ‘DIT School of Engineering’

(DITSE) for providing us the opportunity to develop the given project as
the part of Information Systems lab work.

We are thankful to MRS. RITU PAL (CO-ORDINATOR) who allowed

us to work under his guidance to gain competent knowledge. We owe a
great intellectual debt to him for the inspiration & stimulating insight
provided by him, to complete our project report.

We would like to accredit our other faculty members also for their
contribution in providing us with information, without which we would
not have compiled this project.

We are beholden to our parents and other family members for their
blessings and encouragement. They deserve special acknowledgement for
willingly enabling us to work for realizing one of the major ambitions of
our life.

It was a productive experience to work under Mrs. Ritu Pal who was a
beacon of light and provided valuable guidance throughout the project.

Amit Saurabh Dhasmana

Ankit Sharma
Kushan Thapar
Ankur Kumar
 TABLE OF CONTENTS

1 Introduction
1.1 About the Project
1.2 Project Features
1.3 Problem Statement

2. Feasibility Study
3. Requirement analysis
4. Design description
4.1 Entity-Relationship Diagram
4.2 Use Case Diagram

5. Cost - Benefit Analysis

6. Testing
7. Conclusion & Future Scope
8.1 Conclusion
8.2 Future Enhancements

8. References
INTRODUCTION
 ABOUT THE PROJECT

TOPIC: LIBRARY MANAGEMENT SYSTEM

LIBRARY

A library is a collection of information resources and services, organized

for use, and maintained by a public body, institution, or private
individual. In the more traditional sense, it means a collection of books.
This collection and services are used by people who choose not to — or
cannot afford to — purchase an extensive collection themselves, who
need material no individual can reasonably be expected to have, or who
require professional assistance with their research.

LIBRARY MANAGEMENT
Basic tasks in library management include the planning of acquisitions
(which materials the library should acquire, by purchase or otherwise),
library classification of acquired materials, preservation of materials
(especially rare and fragile archival materials such as manuscripts), the
deaccessioning of materials, patron borrowing of materials, and
developing and administering library computer systems. More long-term
issues include the planning of the construction of new libraries or
extensions to existing ones, and the development and implementation of
outreach services and reading-enhancement services (such as adult
literacy and children's programming).

LIBRARY MANAGEMENT SYSTEM

Initially LIBRARY MANAGEMENT SYSTEMS involved intervention

of man. The systems employed several different groups of people, each
group to handle a particular section in library-be it issuing books, adding
member details etc. These systems were very time consuming and
required a lot of paper work and maintenance. This sometimes results in
insufficient handling of books and records thereby increasing complexity.

NEW LIBRARY MANAGEMENT SYSTEMS

From our past experiences we have seen that manual management is

difficult and moreover inefficient. Thus, we have designed a computer
based library management system. This system helps us to carry out all
the tasks related to library in an efficient manner. It takes lesser time for
solving our problems and is much easier and safer.
Through this system we can find a better management
scheme. The system we have designed gives correct solutions of our
problems in less time. Need is the mother of invention, so there was the
need of designing such a system for the management of library tasks
which was all the more a very tedious task for a man to manage. Earlier it
was very difficult for man to maintain books and the records related to
those books. But with the help of this system, we can easily issue and
return books, add members and books in our library as well as we can
modify the details of any book or the concerned member (if required). We
can also display the records related to any book or the member (in this
case it is student) if the situation demands. Thus, on the whole, reducing
the labour, cost, time etc will increase the effectiveness and efficiency.
 PROJECT FEATURES

The objective behind this project is for automating the manual library of a
University. Our library management system is going to have the
following functions-

FUNCTIONS OF LIBRARY MANAGEMENT SYSTEM :

1) On the login form the system requests to enter a password to
display the components.
2) After typing the password we can get our options displayed.
3) We have three main options-
a) Student details consisting of add detail, modify detail, delete
detail and display details.
b) Book details consisting of add, modify, delete, display book
details, issue books and return books.
c) Exit – to close the current process.
4) A student of any course can get books issued.
5) A book can be issued in two ways-
a) Book for TBL.
b) Book for 1/4/10 days (that is books in general section).
6) Books from general section are issued to all but TBL books are
issued only for their respective courses.
7) The project takes the current system date as the date of issue and
calculates date of due.
8) We can save the student as well as the book information.
9) The student who has got the book issued can only return the book.
10) Only a registered user (that is the student) can get the books
issued.

PROBLEM STATEMENT
.
A software has to be developed for automating the manual library of a
university. The system should be stand alone in nature. It should be
designed to provide functionality’s as explained below:

ISSUE OF BOOKS:
 A student of any course should be able to get books issued.
 A limitation is imposed on the number of books a student can issue.
 The due date for return of the books is stamped on the book.

RETURN OF BOOKS:
 Any person can return the issue of books.
 The student information is displayed using the bar code detector.
 The information is saved and the corresponding updating take place
in database.

QUERY PROCESSING:
 Availability of a particular book
 Availability of book of any particular author.
ANALYSIS

ANALYSIS
Analysis is a detailed study of the various operations performed by a
system and their relationship within and outside the system. One aspect of
analysis is defining the boundaries of the system and determining whether
or not a candidate system should consider other related system. During
analysis, data are collected on the available files, decision points, and
transactions handled by the present system.

Dataflow diagrams, interviews, on-site observations, and questionnaires

are examples. The interview is commonly used tool in analysis. It
requires special skills and sensitivity to the subjects being interviewed.
Bias in data collection and interpretation can be a problem, training,
experience and commonsense are required for collection of the
information needed to do the analysis.

Once analysis is completed, the next step is to decide how the problem
might be solved. Thus in, system design, we move from the logical to the
physical aspects of the life cycle.

The various steps of requirement analysis are:

1. DRAW THE CONTEXT DIAGRAM: The context diagram is a
simple model that defines the boundaries and interfaces of the
proposed system with the external world.
2. DEVELOPMENT OF A PROTOTYPE: We can use users’
feedback to continuously modify the prototype until the user is
satisfied. Hence, a prototype helps the client to visualize the
proposed system and increase the understanding of requirements.
3. MODEL THE REQUIREMENTS: This process usually consists
of various graphical representations of the function, data entities,
external entities and relationship between them. Such model
includes DFD’s, E-R diagrams.
4. FINALISE THE REQUIREMENTS: After modeling the
requirements we will have better understanding of the system
behaviour. The inconsistencies and ambiguities have been
identified and corrected.
FEASIBILITY
STUDY

FEASIBILITY STUDY
Many feasibility studies are disillusioning for both users and analysts.
First, the study often presupposes that when the feasibility document is
being prepared, the analyst is in a position to evaluate solutions. Second,
most studies tend to overlook the confusion inherent in the system
development-the constraints and assumed attitudes .if the feasibility study
is to serve as decision document, it must answer three key questions:

• Is there a new and a better way to do the job that it will benefit
the user?
• What are the costs and savings of the alternative(s)?
• What is recommended?

The most successful system projects are not necessarily the biggest or
most visible in a business but rather than truly meets user expectations.
Most projects fail because of inflated expectations than for any reason.

Feasibility study is broadly divided into three parts:

• Economic feasibility
• Technical feasibility
• Operational feasibility

1. ECONOMIC FEASIBILITY:

It is the most frequently used method for evaluating the effectiveness of a

candidate system. That is expected from the candidate system and
compares them with costs. If benefits outweigh costs then the decision is
made to design and implement the system. Otherwise, further justification
or alteration in the proposed system will have to be made if it is to have a
change of being approved. This is an ongoing effort that improves in
accuracy at each phase of the system life cycle.

2. TECHNICAL FEASIBILITY:

Technical feasibility centers on the exciting computer system (hardware,

software, etc.) and to what extent it can support the proposed edition for
example, if the current computer is operating at 80 percent capacity-an
arbitrary ceiling- then running another application could overload the
system or require additional hardware. This involves financial
consideration to accommodate technical enhancements. If the budget I
serious constraint, then the project is judged not feasible.

3. OPERATIONAL FEASIBILITY:

People are inherently resistant to change, and computer has been known
to facilitate change. An estimate should be made of how strong a reaction
the user staff is likely to have towards the development of a computerized
system. It is common knowledge that computer installations have
something to do with turnover, transfers, retraining, and changes in
employee hob status.

There is no doubt that the people are inherently resistant to change, and
computers have been known to facilitate change. As in today's world all
the work is computerized because of computerization people only get
benefits. As far as our system is concerned it is only going to benefit the
staff of the library in their daily routine work. Thus our system is
operationally feasible also.
.

DESIGN
DESCRIPTION

ENTITY-RELATIONSHIP DIAGRAM
Entity-Relationship (E-R) diagram model data instead of the flow of data,
which separates them from Data Flow Diagrams. Modeling data is one of
the most important steps involved in designing a successful system. E-R
diagrams layout the structure of the data used by the TO-BE system
without tying it to the computer system such as existing databases.
However it important to first construct E-R diagrams so that the designers
have an idea of what they are working to fix.

SEMES

USE CASE ANALYSIS

BRAN
 A use case is a set of scenarios that describing an interaction between a user
and a system. A use case diagram displays the relationship among actors and use
cases. The two main components of a use case diagram are use cases and actors.

An actor is represents a user or another system that will interact with the
system you are modelling. A use case is an external view of the system that
represents some action the user might perform in order to complete a task.

Use Case Context diagram:-

Log In

Add New Student

Update/Delete Student

Add a Book

Update/Delete Book

Librarian Search for Book

Check-In Book Student

Check-Out Book

Pay Late Fee

View Book Detail

View Student Detail

Search for Student

The above diagram reveals the high-level functionality of the system.

Here in this system, the primary user of the system is librarian who is responsible for
user creation, book item creation, check-in, checkout and all search operations. The
student refers to an end-user of the system who is a member of the library and a
student at the university.

Use case’s description is as shown below:-

Name: Add/Edit/Delete Student record.

Description: Only librarians are responsible for adding/editing/deleting student
record.
Actors: Librarian
Result: The details of the student get updated.
Essential process: Identify user by login process.
Carry out manipulation task according to requirement.
Check student details are updated or not.

Name: Add/Edit/Delete Book item.

Description: Only librarians are responsible for adding/editing/deleting student
record.
Actors: Librarian
Result: The details of the book get updated.
Essential process: Identify user by login process.
Carry out manipulation task according to requirement.
Check book details are updated or not.

Name: Search for book.

Description: Librarians and Student are responsible for search book.
Actors: Librarian, Student
Result: Book details should be displayed.
Essential process: Identify Librarian or Student by login process.
Search for required book.
Check availability of book.
Display required book details.

Name: Check-Out Book.

Description: Librarians and Student are responsible for check-out book.
Actors: Librarian, Student
Result: Check-out confirmed.
Essential process: Identify Librarian or Student by login process.
Check whether check-out is completed or not.

Name: Check-In Book.

Description: Librarians and Student are responsible for check-in book.
Actors: Librarian, Student
Result: Check-in confirmed.
Essential process: Identify Librarian or Student by login process.
Check whether check-in is completed or not.
Overdue alert

Name: Display book-detail.

Description: When the librarian or student searches book for borrow at that time the
system shows the details of the book.
Actors: Librarian, Student
Result: Specific book-details should be displayed in terms of call number, title,
author etc...
Essential process: Identify Librarian or Student by login process.
Search a specific book.
Display book-detail.

Name: View student detail.

Description: Librarian can select a student record for detail view.
Actors: Librarian
Result: Specific student details displayed in terms of student id, phone number, books
issued by that student with the issue date & due date, late fees etc…
Essential process: Identify Librarian or Student by login process.
Search a specific student.
View student detail.
 COST BENEFIT ANALYSIS

For any new software project, it is necessary to know how much it will cost to
develop and how much development time it will take. These estimates are needed
before development is initiated. In many cases estimates are made using past
experience as the only guide. However, in most of the cases projects are different and
hence past experience alone may not be enough. A number of estimation techniques
have been developed and are having following attributes in common:

 Project scope must be established in advance

 Software metrics are used as a basis from which estimates are made
 The project is broken into small pieces which are estimated individually

If costs and benefits can be quantified, they are called tangible; if not, they are called
intangible. Examples of tangible costs are the costs of hardware and software,
employee salaries, and other quantifiable costs needed to develop and implement an
IS solution. Intangible costs are difficult to quantify; they include the loss of customer
goodwill or employee morale caused by errors and disruptions arising from the
installation of a new system.

Tangible benefits are favorable results, such as decrease in payroll costs caused by a
reduction in personnel or a decrease in inventory costs. Intangible benefits are harder
to estimate. Such benefits as better customer service or faster and more accurate
information for management fall into this category.

Estimation techniques

This is also known as cost-benefit analysis. The procedure is to determine the

benefits and savings that are expected from a candidate system and compare them
with costs. If benefits outweigh the costs then the decision is made to design and
implement the system. So we have considered these categories for the purpose of cost
benefit analysis:

 Hardware cost
 Personnel cost
 Facility cost
 Operating cost
TESTING
 SYSTEM TESTING

“Testing is the process of executing a program with the intent of

finding errors”

During system testing the system to be tested is executed with a set of test
cases and the output of the system for the test cases is evaluated to
determine if the system is performing as expected.
The purpose of system testing is to identify and correct errors, which
were not discovered previously in the system. So we can say that testing
is an activity in which a system or the results is observed and recorded
and evaluation is made up.

Strategies for testing software

 Code testing or dynamic testing

This strategy examines the logic of the program. Analyst develop test
cases that result in executing every instruction in the program or
module, that is , every path through the program is tested .

 Specification testing or static testing

The analysts examine the specifications stating what the program
should do and how it should perform under various conditions. Then test
cases are developed for each condition and submitted for processing. By
examining the result, the analysts can determine whether the program
performs according to its specified requirements.

WHITE BOX TESTING

White box testing sometimes called glass box testing or structural testing,
is a test case design method that uses the control structure of the
procedural design to derive test cases. Using white box testing methods,
the software engineer can derive test cases that:

1. Guarantee that all independent paths within a module have been

executed at least once.
2. Exercise all logical decisions on their true and false side.
3. Execute all loops at their boundaries and within their optional bounds.
4. Exercise internal data structures to ensure their val
idity.
BLACK BOX TESTING

Black box testing, also called behavioral testing or functional testing,

focusses on the functional requirements of the software. It enables to
derive sets of input conditions that will fully exercise all functional
requirements for a program. It is a complementary approach that is likely
to uncover a different class of errors than white box methods. Black box
testing attempts to find errors in the following categories:

1. Incorrect or missing functions

2. Interface errors
3. Errors in data structures or external data base access
4. Behaviour or performance errors
5. Initialization and termination errors
CONCLUSION AND
FUTURE SCOPE
 CONCLUSION AND FUTURE SCOPE

The first software project management activity is the determination of

software scope.
Software project scope must be unambiguous and understandable at the
management and technical levels. A statement of software scope must be
bounced. That is, quantitative data are stated explicitly; constraints and
limitations are noted, and mitigating factors are described.

1. This project is very useful for students as they can access the
required books anytime.

2. It is fully automated system and thus no manual searching or

manipulation of records is required.

3. All information is centrally stored in a database that avoids data

redundancy.

4. It saves manual working and time and provides instant information

about any book or the member (that is the student).

The use of this project is also that a lot of manual work is reduced and a
high service is achieved. It provides automated systems.

FUTURE ENHANCEMENT
Since this project has been designed as a part of syllabus of various
courses, scarcity of deep knowledge and practicality has left certain
aspects where further enhancement is possible in the near future.
We look forward for developing more advanced software and a refined
version of the same project by increasing its functionality, efficiency and
effectiveness.
Certain improvements can also be made in the field of security by
creating a more secure mechanism for faculty identification.
We leave all this as a part of enhancements to be made in the future.
REFERENCES
 REFERENCES

 “Software Engineering”
By: KK Agarwal

 “Informatics Practice”
By: Sumita Arora, Roger S.Pressman

 “Management Information System”

By: O’Brien