Sei sulla pagina 1di 40

SOFTWARE ENGINEERING LAB

BCA 3rd YEAR, 5th SEMESTER

Submitted To : Submitted By Group :


Mr. GAURAV CHAWLA ANAM SHAMA
IBRAHIM SIDDIQUI
Mr. BHAVYA ALANKAR FARHAN AHMED
YASIR AHMED
ACKNOWLEDGEMENT

The satisfaction that accompanies that the successful


completion of any task would be incomplete without the
mention of people whose ceaseless cooperation made it
possible, whose constant guidance and encouragement crown
all efforts with success.

We are grateful to our project guide Mr.Gaurav Chawla for the


guidance, inspiration and constructive suggestions that helpful
us in the preparation of this project.

We also thank our colleagues who have helped in successful


completion of the project.
Table of Contents
INTRODUCTION
PROBLEM STATEMENT
NEED
ROLE
SYSTEM ANALYSIS
FEASIBILITY ANALYSIS
WATERFALL METHODOLOGY
SOFTWARE REQUIREMENT SPECIFICATION
SOFTWARE DESIGN
DATA FLOW DIAGRAM
E-R DIAGRAM
USE CASE
SOFTWARE IMPLEMENTATION
DATA TABLES
SNAPSHOTS
SOFTWARE TESTING
CONCLUSION
INTRODUCTION

PROBLEM STATEMENT
Software has to be developed for convinence and to
keep records for the library management system . The
system should be distributed in nature. It should be
designed to provide functionalities as explained below:
LOGIN
BORROW BOOK
RETURN BOOK
MAXIMUM NUMBER OF BOOK ISSUE
REPORT

NEED OF A COMPUTERIZED LIBRARY MANAGEMENT


SYSTEM
It is very important to keep the records of the books that
who borrowed/issued books, when did they returned to
manage the books in order to keep books safe it is
important to use library management software . It is
complex activity as there are thousands of books ,and
borrowers to issue books. Security is also a major
factor for the need of library management system, if
borrowers didnt returned book after issuing book that
will be a conflicting matter.

ROLE Of Library Management System


1.To keep the records about the books that are issued &
is it returned or not?
2. for security purposes.
3. To regain the control of borrowing the books to
avoid scalping & over-issuing of books.
4. To collect statistics in a more efficient manner for
future Book issuing/borrowing.
5. To increase efficiency & stopping doubts or
conflicts.
SYSTEM ANALYSIS
EXISTING SYSTEM:

System Analysis is a detailed study of the various


operations performed by a system and their
relationships within and outside of the system. Here the
key question is- what all problems exist in the present
system? What must be done to solve the problem?
Analysis begins when a user or manager begins a study
of the program using existing system.

During analysis, data collected on the various


files, decision points and transactions handled by the
present system. The commonly used tools in the system
are Data Flow Diagram, interviews, etc. Training,
experience and common sense are required for
collection of relevant information needed to develop the
system. The success of the system depends largely on
how clearly the problem is defined, thoroughly
investigated and properly carried out through the choice
of solution. A good analysis model should provide not
only the mechanisms of problem understanding but also
the frame work of the solution. Thus it should be
studied thoroughly by collecting data about the system.
Then the proposed system should be analyzed
thoroughly in accordance with the needs.
System analysis can be categorized into four parts.
1. System planning and initial investigation
2. Information Gathering
3. Applying analysis tools for structured analysis
4. Feasibility study
5. Cost/ Benefit analysis.

In our existing system all the transaction of books are


done manually, So taking more time for a transaction
like borrowing a book or returning a book and also for
searching of members and books. Another major
disadvantage is that to preparing the list of books
borrowed and the available books in the library will
take more time, currently it is doing as a one day
process for verifying all records. So after conducting
the feasibility study we decided to make the manual
Library management system to be computerized.

PROPOSED SYSTEM
Proposed system is an automated Library Management
System. Through our software user can add members,
add books, search members, search books, update
information, edit information, borrow and return books
in quick time. Our proposed system has the following
advantages.

1) User friendly interface


2) Fast access to database
3) Less error
4) More Storage Capacity
5) Search facility
6) Look and Feel Environment
7) Quick transaction
All the manual difficulties in managing the Library
have been rectified by implementing computerization.

FEASIBILITY ANALYSIS
Whatever we think need not be feasible .It is wise to
think about the feasibility of any problem we undertake.
Feasibility is the study of impact, which happens in the
organization by the development of a system. The
impact can be either positive or negative. When the
positives nominate the negatives, then the system is
considered feasible. Here the feasibility study can be
performed in two ways such as technical feasibility and
Economical Feasibility.
Technical Feasibility:

We can strongly says that it is technically feasible,


since there will not be much difficulty in getting
required resources for the development and maintaining
the system as well. All the resources needed for the
development of the software as well as the maintenance
of the same is available in the organization here we are
utilizing the resources which are available already.

Economical Feasibility:

Development of this application is highly


economically feasible .The organization needed not
spend much m one for the development of t he system
already available. The only thing is to be done is
making an environment for the development with an
effective supervision. I f we are doing so , we can attain
the maximum usability of the corresponding resources
.Even after the development , the organization will not
be in a condition to invest more in t he organization
.There fore , the system is economically feasible.
WATERFALL
METHODOLOGY
The waterfall method illustrates the software
development process in a linear sequential flow. This
means that any phase in the development process
begins only if the previous phase is complete. The
waterfall approach does not define the process to go
back to the previous phase to handle changes in
requirement. Therefore, different projects may follow
different approaches to handle such situations.
The waterfall approach is the earliest approach that was
used for software development. Initially, most projects
followed the waterfall approach because they did not
focus on changing requirements.
Waterfall Approach Phases:

Conception: Triggers when a problem is perceived.


This phase involves identifying goals to be achieved
after the problem is solved, estimating benefits in the
new system over the current system and identifying
other areas that are affected by the solution. This phase
also involves and developing the business case for the
project. A business case provides the information that a
manager needs to decide whether to support a proposed
project, before resources are committed to its
development.

Initiation: Involves a macro level study of the


customer requirements. This phase also involves
defining alternative solutions to the customer
requirement and cost-benefit justification of these
alternatives.

Analysis: Involves carrying out detailed study if the


customer requirements and arriving at the exact
requirements of the proposed system. The phase
involves freezing the requirements before the design
phase begins.

Design: Involves translating the identified requirements


into a logical structure, called design that can be
implemented in a programming logic.
Construction: Involves integrating and testing all the
modules developed in the previous phase as a complete
system.

Integration and testing: Involves integrating and


testing all the modules developed in the previous phase
as a complete system.

Implementation and maintenance: Involves


converting the new system designs into operation. This
may involve implementing the software system and
training the operating staff before the software system
is functional.

Software Requirements
Specification(SRS)
Introduction
Borrowing books, returning books or viewing the
available books at the Library of the local
University is currently done manually where in the
student has to go to the Library and check the
available books at the Library. Students check the
list of books available and borrow the books if the
book is a borrow book otherwise it is of waste for
the student to come to the library to come to check
for the books if the student doesnt get the book.
Then the librarian checks the student id and allows
the member to check out the book and the librarian
then updates the member database and also the
books database. This takes at least one to two hours
if the member is available at the near by place
otherwise it may take more time.

We have decided to investigate the use of an


Online Library Management System. This system
would be used by members who may be students or
professors of that University to check the
availability of the books and borrow the books, and
by the librarian to update the databases. The
purpose of this document is to analyze and
elaborate on the high-level needs and features of
the Online Library System. It focuses on the
capabilities and facilities provided by a Library.
The details of what all are the needs of the Online
Library System and if it fulfils these needs are
detailed in the use-case and supplementary
specifications.

Purpose
The purpose of Software Requirements
Specification (SRS) document is to describe the
external behavior of the Online Library System.
Requirements Specification defines and describes
the operations, interfaces, performance, and quality
assurance requirements of the Online Library
System. The document also describes the
nonfunctional requirements such as the user
interfaces. It also describes the design constraints
that are to be considered when the system is to be
designed, and other factors necessary to provide a
complete and comprehensive description of the
requirements for the software. The Software
Requirements Specification (SRS) captures the
complete software requirements for the system, or
a portion of the system. Requirements described in
this document are derived from the Vision
Document prepared for the Online Library System.

Scope
The Software Requirements Specification captures
all the requirements in a single document. The
Online Library System that is to be developed
provides the members of the Library and
employees of the library with books information,
online blocking of books and many other facilities.
The Online Library System is supposed to have the
following features.
The product provides the members with online
blocking of books capabilities and the Online
Library System is up and running all day.
The system provides logon facility to the
users.
The system provides the members with the
option to check their account and/or change
their options like password of the account
whenever needed all through the day during
the library hours.
The system allows the members to block the
books 24 hours a day and all the through the
semester.
The system lets the library staff to check
which all members have blocked the books
and whether they can borrow any more books
or not.
The system allows the Librarian to create the
books catalog, add/delete books and maintain
the books catalog.
The system updates the billing system as and
when the member borrows or returns a book.
The book catalog is automated and the
decision of offering the book based on the
category of the book is automatically decided.
We also have an order department, which
manages to add or remove a book from the
Library.
The features that are described in this document are
used in the future phases of the software
development cycle. The features described here
meet the needs of all the users. The success criteria
for the system is based in the level up to which the
features described in this document are
implemented in the system.

Overview
Section1:The SRS will provide a detailed
description of the Online Library System. This
document will provide the outline of the
requirements, overview of the characteristics and
constraints of the system.
Section2: This section of the SRS will provide the
general factors that affect the product and its
requirements. It provides the background for those
requirements. The items such as product
perspective, product function, user characteristics,
constraints, assumptions and dependencies and
requirements subsets are described in this section.

Section3: This section of SRS contains all the


software requirements mentioned in section 2 in detail
sufficient enough to enable designers to design the
system to satisfy the requirements and testers to test if
the system satisfies those requirements.
Software Design
DATA FLOW DIAGRAM (DFD)
E-R DIAGRAM

It is clear that the physical objects from the previous section


the member, books, library correspond to entities in the
Entity-Relationship model, and the operations to be done on
those entities holds, checkouts, and so on correspond to
relationships. However, a good design will minimize
redundancy and attempt to store all the required information
in as small a space as possible.
USE CASE DIAGRAM

1. Actors of the Library Management System

Member
Administrator
Librarian
Guest

2. Use cases of Library Management System

Login
View User Details
View Books
View Members
Reserve Books
Search Books
Issue Books
Return Books
Add/Remove Books
Add/Remove Members
3. USE CASE DIAGRAM

Login

View User Details

View Books

Member Reserve Books

Librarian
Search Books

Issue Books

Return Books

View Members Administrator

Guest
Add/Remove
Books

Add/Remove
Members
4. Use Case Scenarios

Use Case: Login


Introduction: To interact with the system, LMS will
validate its registration with this system. It
also defines the actions a user can perform
in LMS.

Actors: Administrator
Librarian
Member

Pre- conditions: User must have proper client installed on


user terminal.

Post- conditions: System should transfer control to the user


main screen to proceed desired further
actions.

Basic Flow: System show login screen


Enter user Id & password
Acknowledge the entry.

Alternative Flow: user Id or password is incorrect, user will


be prompted a message regarding the
error.
Transfer control back to login screen.

Special Requirements: User should acquire user Id & password


before login to the system.

Relationships: The base case includes checking the


database case.
Use Case: View User Details
Introduction: To see the details of the registered user &
the books currently borrowed from the
library.

Actors: Member

Pre- conditions: User must be logged in to the system.

Post- conditions: View user details.


View books borrowed.

Basic Flow: Enter to the view details page


View user details & books borrowed.
Print details.

Alternative Flow: User does not want to print the details,


user can ignore the step.

Special Requirements:
Relationships: The base case includes checking the
database case.
The base case includes retrieve data case.
Use Case: View Books
Introduction: To display the details, when a member,
guest or administrator wants to see the
details on the available books.

Actors: Administrator
guest
Member

Pre- conditions: User should have the client interface.


Books should be stored in the database
& available to retrieve.

Post- conditions: User should be displayed all the


available books with the complete
details.

Basic Flow: Identify the user type member, guest


or administrator
Display the book details
Print the details

Alternative Flow: User does not want to print the details,


user can ignore the step.

Special Requirements:
Relationships: The base case includes checking the
database case.
The base case includes retrieve data
case.
Use Case: Reserve Books
Introduction: User can reserve a book by inputting the
relevant details & the librarian can also
reserve a book for a member.

Actors: Librarian
Member

Pre- conditions: User should be logged into the system.


User should have correct book Id.
Books should be available to reserve.

Post- conditions: User should be reserved the book


successfully.
A message should be prompted regarding
reserving.
Database should be updated.

Basic Flow: Member type identified.


Enter book Id & member Id.
Reserve the book.
Update the system.

Alternative Flow: User Id or book Id is incorrect, user will


be prompted a message regarding the
error.
Transfer control back to user screen.
The book is already issued a message
will be prompted regarding the error.

Special Requirements: User should acquire book Id to reserve a


book.

Relationships: The base case includes checking the


database case.
The base case includes validating
reservation case.
The base case includes update database
case.
Use Case: Search Books
Introduction: Member or guest can search for a
particular book in the book library by
book name or category.

Actors: Member
Guest

Pre- conditions: Guest & member should available the


client interface of the library.
Members should be logged into the
system.
Book should be available to search.

Post- conditions: The user should be given the results of


the search with full details.

Basic Flow: Member type identified.


Select the search type.
Check the availability.
View the search results.

Alternative Flow: The search is not found a message will be


prompted.
The data entered incorrect, a message
will be prompted.

Special Requirements:
Relationships: The base case includes checking the
database case.
The base case includes retrieving data
case
Use Case: Issue Books
Introduction: This use case describes the process of
issuing a certain book for a member by
the librarian.

Actors: Librarian
Member

Pre- conditions: Member should give the member Id to


the librarian.
Books should be available to issue.

Post- conditions: Member should have the issued book.


Confirmationmessageshouldbe
prompted.
Database should be updated-issued.
Member details should be updated.

Basic Flow: Get the member Id & book Id.


Check the availability.
Check number of books taken.
Issue the book.
Update the system

User Id or book Id is incorrect, user will


be prompted a message regarding the
error.
The given book is already issued prompt
a message regarding that.
User already taken 3 books prompt a
message.

Special Requirements: Borrowed books should be below 3.

Relationships: The base case includes checking the


database case.
The base case includes updating database
case
Use Case: Return Books
Introduction: This use case describes the process of
issuing a certain book for a member by
the librarian.

Actors: Librarian
Member

Pre- conditions: Librarian should be logged into the


system.
Member should be borrowed books.
Member should give the member Id to
the librarian.

Post- conditions: Library should have the returned book.


Confirmationmessageshouldbe
prompted.
Database should be updated-available.
Member details should be updated.

Basic Flow: Get the member Id & book Id.


Check the Id accuracy.
Return the book.
Update the system

User Id or book Id is incorrect, user will


be prompted a message regarding the
error.

Special Requirements:
Relationships: The base case includes checking the
database case.
The base case includes updating database
case
4

Use Case: View Members


Introduction: To display the details, when a member,
guest or administrator wants to see the
details on the registered user.

Actors: Administrator
guest
Member

Pre- conditions: User should have the client interface.


Members should be stored in the
database & available to retrieve.

Post- conditions: User should be displayed all the


members with the complete details.

Basic Flow: Identify the user type member, guest


or administrator
Display the member details
Print the details

Alternative Flow: User does not want to print the details,


user can ignore the step.

Special Requirements:
Relationships: The base case includes checking the
database case.
The base case includes retrieve data
case.
Use Case: Add/Remove Books
Introduction: Only librarian & administrator are
allowed to add or remove books from
the library database.

Actors: Administrator
Librarian

Pre- conditions: User should be logged into the system.


Books should be available to remove.
Book details should be available to add.

Post- conditions: Confirmation message should be


prompted upon successful add/remove.
Database should be updated.

Basic Flow: Identify the user type librarian or


administrator
Check the action to be taken whether to
add or remove a book.
Add/remove the book
Update the database.

Alternative Flow: The books Id already available then


prompt the error.
The book Id is invalid when removing,
prompt the error.
The book is not available to remove,
prompt the error.

Special Requirements: Book should be outdated to remove it.


New books should be recognized as
standard editions.

Relationships: The base case includes checking the


database case.
The base case includes update database
case.
The base case includes get details case.
Use Case: Add/Remove Members
Introduction: Only administrator is allowed to add or
remove members from the library
database.

Actors: Administrator

Pre- conditions: Administrator should be logged into the


system.
Members should be available to remove.
Member details should be available to
add.

Post- conditions: Confirmation message should be


prompted upon successful add/remove.
Database should be updated.

Basic Flow: Check the action to be taken whether to


add or remove a member.
Add/remove the member
Update the database.

Alternative Flow: The member Id already available, then


prompt the error.
The member Id is invalid when
removing, prompt the error.
The member is not available to remove,
prompt the error.

Special Requirements: To remove a member, member should


request to leave the library.

Relationships: The base case includes checking the


database case.
The base case includes update database
case.
The base case includes get details case.
SOFTWARE
IMPLEMENTATION
SNAPSHOTS
SOFTWARE TESTING
Is the menu bar displayed in the appropriate contested
some system related features included either in menus or
tools? Do pull Down menu operation and Tool-bars
work properly? Are all menu function and pull down sub
function properly listed ?; Is it possible to invoke each
menu function using a logical assumptions that if all parts
of the system are correct, the goal will be successfully
achieved .? In adequate testing or non-testing will leads to
errors that may appear few months later.

This create two problem

1. Time delay between the cause and appearance of the


problem.

2. The effect of the system errors on files and records


within the system
The purpose of the system testing is to consider all the
likely variations to which it will be suggested and push
the systems to limits.

The testing process focuses on the logical intervals


of the software ensuring that all statements have been
tested and on functional interval is conducting tests to
uncover errors and ensure that defined input will produce

actual results that agree with the required results. Program


level testing, modules level testing integrated and carried
out.

There are two major type of testing they are

1) White Box Testing.


2) Black Box Testing.

White Box Testing:


White box some times called Glass box testing is a test
case design uses the control structure of the procedural
design to drive test case.
Using white box testing methods, the following tests
where made on the system

A) All independent paths within a module have


been exercised once. In our system, ensuring that
case was selected and executed checked all case
structures. The bugs that were prevailing in some part
of the code where fixed
B) All logical decisions were checked for the truth
and falsity of the values.

Black box Testing:


Black box testing focuses on the functional requirements
of the software. This is black box testing enables the
software engineering to derive a set of input conditions
that will fully exercise all functional requirements for a
program. Black box testing is not an alternative to white
box testing rather it is complementary approach that is
likely to uncover a different class of errors that white box
methods like..
1) Interface errors
2) Performance in data structure
3) Performance errors
4) Initializing and termination errors
Conclusion
From a proper analysis of positive points and constraints
on the component, it can be safely concluded that the
product is a highly efficient GUI based component. This
application is working properly and meeting to all user
requirements. This component can be easily plugged in
many other systems.

Potrebbero piacerti anche