Case study: library book circulation system

N. L. Sarda I.I.T. Bombay

BOOK CIRCULATION
Organization
IIT Bombay Central Library Main functions
book acquisition journals/periodicals book circulation about 3,00,000 books about 1,500 journals employs 50 persons

One of the largest technical books library

BOOK CIRCULATION.
Organization
Library users
IIT faculty and staff students corporate members

Circulation function not satisfactory for many reasons

high book-keeping poor service to users (long queues seen often) many persons tied up for this task
3

BOOK CIRCULATION.
Librarian would like to computerize this work ( note : this is a solution, not a problem !) An analyst from IITs Computer Services Section called to investigate Analysts real objectives :
find more efficient and cost-effective system identify benefits and costs

BOOK CIRCULATION.
Define Scope
project cost limit : library can provide about Rs. 5 lakhs development cost : in-house is an alternative what can be reasonable limit on project cost? should library go beyond this point? limit of Rs. 7.5 lakhs seems reasonable

BOOK CIRCULATION.
Estimate cost and duration for next step
duration : 2 weeks cost : Rs. 10,000

Prepare Problem Definition document Identify users of the system:

Assistant Librarian (Circulation) Counter Clerks Faculty / Student

STATEMENT OF PROJECT SCOPE AND OBJECTIVES

1. THE PROJECT : CIRCULATION 2. THE PROBLEM :
Present system is too slow. Present system is not cost-effective.

3. PROJECT OBJECTIVES :
To investigate and propose more efficient and cost-effective system for circulation.

4. PROJECT SCOPE :
The project cost, including systems and software development, should not exceed Rs. 7.5 lakhs
7

STATEMENT OF PROJECT SCOPE AND OBJECTIVES

5. PRELIMINARY IDEAS :
One possible solution would be to computerize circulation function. A system with a server and at least 3 work stations will be required.

6. THE FEASIBILITY STUDY :

A feasibility study by one analyst lasting about 2 weeks will be undertaken to fully investigate possibilities for the project. The study will cost Rs. 10,000
8

THE FEASIBILITY STUDY : CIRCULATION

propose possible solutions, evaluate them and make recommendation in limited time, cost and efforts start by clearly understanding objectives study the existing system
what tasks are performed what are reasons for the problems

FEASIBILITY
make a logical model for proposed system consider alternatives, analyze each for feasibility make a recommendation and develop a plan of action for the project Existing System study completed by interviewing users, finding out tasks performed, data handled and problems faced
10

FEASIBILITY ..
tasks performed include
issue a book return a book claims for books fine handling (for late returns) handling user enquiries regular reports for Librarian different member types have different rules about number of books allowed and period of issue
11

study circulation rules

FEASIBILITY ..
problems of members (library users)
long queues poor (in fact, unacceptable) claim and enquiry service excessive book keeping : date-stamping and signatures at 4-5 places

counter clerks problems

verification : quota exceeding, signatures, delayed returns, etc.

claim handling clumsy enquiries (such as : is book .. issued? to whom? ) difficult to handle

12

FEASIBILITY ..
management / administration problems
inefficient / unsatisfactory handling of reports and statistics problems with overdue and lost books

After obtaining general understanding of existing system, prepare data flow diagrams

13

14

FEASIBILITY ..
Sign book and member card at issue time; alternatives:
fixed for a book (need to put back in book pouch) use for any book (slip serial numbers recorded in DB, release at return time )

rows of trays containing book and member cards kept at counter no need to prepare detailed data flow diagrams as other procedures are obvious
15

FEASIBILITY ..
main reasons contributing to problems
duplication due to requirement of two modes of accessing :
using accession number of book using member identification

duplication increases work at counter book cards and member cards must be kept sorted in trays at counter

16

FEASIBILITY ..
main reasons contributing to problems
enquiry and return processing require book and member cards to be located, put back in book / trays or returned to user after due cancellations claims handled by attaching slips to book cards : subject to mishaps / tampering

17

FEASIBILITY ..
Characteristics
it is primarily an on-line system issue, return and claiming are basic tasks; partial automation is meaningless (no alternatives based on automation boundaries) signed record of issue must be kept both to confirm signatures and for legal purpose until book is returned high cost alternative can be considered to include other divisions of library
18

FEASIBILITY ..
possible to propose alternatives at physical level
server options (unix / linux, windows) LAN with 3 / 4 nodes data entry using bar codes DBMS or conventional file based handling of signed records

prepare logical data-flow diagram

19

FEASIBILITY ..
alternative 1 : LAN-based solution one 40 GB file server with 3 workstations data entry (mostly member ids and accession numbers) through keyboard at counters

20

FEASIBILITY ..
Costs
Systems DBMS : Rs. 4.00 lakhs : Rs. 0.20 lakhs

application software development : Rs. 0.30 lakhs Initial book & member data entry : Rs. 2.50 lakhs ----------------Total : Rs. 7.00 lakhs

21

FEASIBILITY ..
alternative 2 : LAN-based with bar-code data entry
will further reduce time for users at counter additional investments :
3 bar-code readers and associated software bar-coding of books and member id cards Total : Rs. 1.50 lakhs : Rs. 1.50 lakhs -----------------: Rs. 10.00 lakhs

22

FEASIBILITY ..
examine each alternative for feasibility
both alternatives are technically and operationally feasible as they are based on well-proven technology, and there would be no operational difficulties with adequate training economic feasibility must be as detailed as possible ( given later )

23

FEASIBILITY ..
have we given a range of alternatives?
low-cost solution : this could be based on changes in existing manual procedures without computerization; unlikely to reduce problems substantially; also, partial computerization not possible medium-cost : the above alternatives fall in this category high-cost : extend scope further by integrating other functions, such as book acquisition
24

Financial analysis for alternatives 1 :

Initial cost : Rs. 7.0 lakhs benefits and costs (yearly basis)
saving in salaries of 4 persons out of 7(these can be re-deployed) : 4 x 12 x 4000 operational costs (including maintenance, stationary) earlier operating cost better service time as well as more services is considered worth the cost of 1 employee : Rs. 1.92 lakhs

: Rs. 1.10 lakhs : Rs. 0.20 lakhs : Rs. 0.48 lakhs

net return per year = (1.92 + 0.48 + 1.10 + 0.2) = Rs. 1.5 lakhs
25

Financial analysis for alternatives1:..

investment analysis
year saving
(lakhs)

present value
( at 12 %)

cumulative
present value

--------------------------------------------------------------------------------------1 1.5 1.34 1.34 2 1.5 1.20 2.54 3 1.5 1.07 3.61 4 1.5 0.95 4.56 5 1.5 0.85 5.41 6 1.5 0.76 6.17 7 1.5 0.68 6.85

26

Financial analysis for alternatives1:..

assume system life to be 7 years giving net present value : Rs. 6.85 lakhs net present investment : Rs. 7.00 lakhs we just break even in seven years the cost on data entry of books (Rs. 2.5 lakhs) is not lost at end of system life hence, actual payback period is only 4 years we can compute internal rate of return
27

Financial analysis for alternatives1:..

economic feasibility for alternative 2 :
cost (i.e., investment) Rs. 10.00 lakhs benefits
saving in salary operational cost earlier operating cost improved service worth (about 1 persons) : Rs. 1.92 lakhs : Rs. 1.60 lakhs : Rs. 0.20 lakhs : Rs. 0.73 lakhs

net return is Rs. 1.25 lakhs

28

Financial analysis for alternatives1:..

economic feasibility for alternative 2 :.
return reduced due to higher operational cost it is not a better investment than alternative 1, but may have more impact value not recommended on cost-benefit basis

make a formal feasibility report

29

Plan for alternatives1:..

make a rough implementation schedule :
phase requirements analysis design detailed design Implementation effort 2w 2w 3w 8w calendar time 3w 3w 4w 4w

computer system acquisition process will begin at end of design phase data entry is a massive work; it is expected to be contracted out and begin at end of detailed design phase
30

Financial analysis for alternatives1:..

make a presentation to users, management assume that we get go-ahead signal for alternative 1

31

Requirements Analysis
to determine what exactly the system has to do
define inputs, outputs, processing detailed enough for design work

start with study of existing system in feasibility report and DFDs expand them into further details compile list of all data elements in inputs, outputs, and specify processing details
32

Requirements Analysis
prepare requirements specification finally, arrange user review and peer view work at logical level : understand and emphasize
what needs to be done not how it be done

33

Requirements Analysis
use appropriate tools to store the findings
data flow diagrams contains flow of data & relationships between inputs, outputs & process data dictionary contains data descriptions procedures as flow-charts, decision tables, or pseudo-language description

34

Start with Context diagram:

35

Draw first level DFD

Let us concentrate more on process 1 explosion

36

37

38

39

Requirements Analysis
contents of data store book
accno authors price ISBN title publisher year classification book-type

note : book-type indicates book category that may have issue restrictions (only to certain member categories and for certain periods)

40

Requirements Analysis
contents of data store member
id category name termination-date dept

note : category defines privileges of member (no. of books, period of issue, etc)
id due-date accno return-date accno issue-date fine claim-date
41

contents of data store issue

contents of data store claim

id

Refinement of issue process

42

Requirements Analysis
Notes :
claim data is modified if an issue is against claim made earlier no response could be given by any validate process (not shown) D5 and D6 data stores define member categories and issue schemes D7 contains holiday data for use in computing due date for return

43

Requirements Analysis
refine further where necessary interact with user to obtain procedural and data details prepare Requirements Specification Document

44

Requirements Specification .
ABSTRACT: The system to be developed will handle issuing of books to members of library. Other important and associated tasks are book claims and fines for late returns. This document follows IEEE standards format. 1 Introduction 1.1 PURPOSE : This document describes functional tasks, user interfaces and main data domains for the book circulation system 1.2 SCOPE : This document acts as a baseline for requirements definition, and any changes must go through a formal change process. This system will be referred as CIRCULATION system, whose major goals are reduction of costs and better service to members. It includes an extensive data entry effort for all books in the library. 1.3 DEFINITIONS, ACRONYMS : not applicable 1.4 REFERENCES : Feasibility document dated April 1, 1998 1.5 DEVELOPERS RESPONSIBILITIES : (a) design and implement the system (b) define formats/programs for data entry work (c) assist in system acquisition (d) install the system, and (e) provide maintenance for 1 year 45

SRS
2 General Description
2.1 PRODUCT PERSPECTIVE : It is a stand-alone and self-contained
package; no interfaces to other systems 2.2 PRODUCT FUNCTIONS : Overview of these functions: (a) maintain data about members and type of facilities allowed to them (category) (b) maintain data about books and restrictions on their issuing (type) (c) book issue: issue a book provided category and type validations are met; compute due date for return, taking into account holidays. Summer vacation is treated as holidays. (d) book return : compute fine, if late return

46

SRS
2.2 PRODUCT FUNCTIONS : Overview of these functions:.. (e) claim processing : upto 3 claims/book and 5 claims/user are permitted. Claims accepted only for issued books. Issue task checks for claims on book. Issue against claim updates claims data. (f) enquiry/reports: various online, detail and summary enquiries on members, books, issues and claims will be provided for both members and management. (g) fine payments/lost books, etc. are additional functions to be implemented 2.3 USER CHARACTERISTICS : main users are counter clerks (issue/return/claim/fine); members can use for enquiry. Users, being from a premier technical institute, are literate about computers

2.4 GENERAL CONSTRAINTS : nil about existing systems 2.5 ASSUMPTIONS & DEPENDENCIES : not applicable
47

SRS
3. SPECIFIC REQUIREMENTS : This section describes the relevant functional
requirements, performance requirements, design constraints, etc.

3.1

FUNCTIONAL REQUIREMENTS : We give here, for each function, its description, inputs, processing and outputs. Inputs which are largely common need be described only once

3.1.1 FILES : Describe here contents of all major files/datastores (i.e., member, book, issue and claim). Left as exercise 3.1.2 FUNCTIONS : The CIRCULATION system is basically an on-line transaction processing system. The important transactions and corresponding system tasks are:
(a) Book issue : Given members id and accno of a book, issue the book provided the following conditions are met:

I) the type of book is permitted for the member II) member has not finished her quota of books III) there is currently no claim on the book by any other member
48

SRS
3.1.2 FUNCTIONS..

The issue date is recorded, the due date of return of book is calculated based on members category and book type. The due date is suitably adjusted if it falls on a holiday. If there was a claim on the book, the claim list is adjusted. Note : In similar fashion, describe all other functions of the system. Left as exercise

3.1.3 PERFORMANCE REQUIREMENTS : This may be given in

terms of static and dynamic requirements Static : - number of terminals to be supported : 4 - number of simultaneous users : 4 - number of files to be handled : 6 - file sizes - MEMBER : 2500 - BOOKS : 200000 - ISSUES : 50000 Dynamic :- number of transactions to be processed per minute : 5 - response time per transaction : less than 1 sec 49

SRS
3.1.4 DESIGN CONSTRAINTS : These constraints may be imposed
by hardware limitations, standards, etc. Standards compliance may include Report formats, Data naming, Accounting procedures, Audit tracing, etc. For the CIRCULATION system, there are no specific constraints 3.1.5 ATTRIBUTES : This section should list specific requirements on software. These could include some of the following : I) availability : This attribute is important but not critical for CIRCULATION. Appropriate checkpoint, recovery and restart procedures will be defined. II) Security : This attribute defines requirements on software to protect data and programs from accidents or malicious access/use, modification, destruction, or disclosure. The design of CIRCULATION system will include user authentification, menus tailored as per requirements, keeping of logs/history, computing some critical quantities for verification (e.g., total books issued at this counter) 50

SRS
3.1.5 ATTRIBUTES
III) Maintainability : specification of measures to make maintenance easier. These may include metrics on module size, module coupling, etc 3.2 EXTERNAL INTERFACE REQUIREMENTS 3.2.1 USER INTERFACES : We specify here software requirements for supporting each human interface. This should include screen formats, command formats, report layouts, error messages, timings, etc. This section, in fact, is equivalent to user manual. We will illustrate by specifying user interface for issue function.

51

SRS
a) Issue :
I) Screen layout :

Member id : --------------Member name : xxxxxxxxx Member.dept : xxxxxx OK (y/n?) : ---Book accno : --------------Book title : xxx.xxxxx OK (y/n?) : ---ACCEPTED/REJECTED : xx More books (y/n?) : ---( ----- user input; xxx system supplied)
II) actions for counter clerk a) enter members id from his/her card and press return b) check name/dept displayed by system with that on the card 52

SRS
a) Issue :. II) actions for counter clerk. (c) respond by y or n key. System goes to step (d) or (a)
from here.

(d) enter accession number of book

(e) check displayed title with books title (f) press y or n (if n, hand-over the book to system administrator) (g) note systems response. If ACCEPTED, stamp the book and release it to member (h) if the member wants more books, press y else press n

53

SRS
a) Issue :.

(iii) possible error messages :

err-iss-1: member unknown to system err-iss-2: book unknown to system Rejection code : R1 : book has claims by others R2 : members quota completed R3 : member has excessive accumulated fine Note : As exercise, indicate what else needs to be specified in above specification for issue, and make similar specifications for at least one more interface

3.2.2 HARDWARE INTERFACES : Not applicable 3.2.3 SOFTWARE INTERFACES : Not applicable
54

SRS
3.2.4 COMMUNICATION INTERFACES : CIRCULATION system will
be developed on LAN running Windows system. There is no direct interface of software with lower level protocols

3.3 OTHER REQUIREMENTS 3.3.1 DATABASE : If any existing database package is used, it should
be named in sec. 3.2.3 and details of using it should be given here, in terms of type of information usage, access capabilities, database schema, database retention requirements, etc. In the circulation system, we will not use any DBMS package. Sec. 3.1.1 has already described information in files. We should indicate here usage and access requirements, data retention, etc. We will give this specification only for ISSUE file, and leave others as exercises.

55

SRS
a) ISSUE file Usage: Type tasks frequency (per day) activity ratio (no of rec) 10 1 1

retrieval enquiry 100 update insert issue 500 delete return 400 Accessing : On accno for issue/return/enquiry On member id for enquiry
Retention :

An issue record need to be online until the return or fine is paid. It is kept off-line for 1 year, then summarized and purged 56

SRS
3.3.2 OPERATIONS : We should indicate here the operations to be
initiated by users, including start-of-day, end-of-day, backup and restart

3.3.3 SITE ADAPTION REQUIREMENTS : We specify here

requirements which may be specific to a site or an installation. The CIRCULATION system is a single installation system, and there are no specific requirements in this category

4. Acceptance Criteria : Before acceptance of the system by the

Library, the developers will demonstrate all functionalities of the system for sample data of 100 members and 2000 books. The developer will supply suitable test cases, expected results and demonstrate them to user. ------- end 57

System Design : CIRCULATION

Perform a high-level design of the software Identify the main physical components
Software architecture and modules Files Manual procedures (un-automated parts)

58

System Design
Consider a few implementation alternatives
We know requirements in greater details than at feasibility time Alternatives may be based again on automation boundaries and technical options Do cost-benefit analysis again, if necessary (cost rises significantly here- after)

59

System Design
Estimate effort and develop preliminary implementation strategy Prepare design document (left as exercise) Schedule technical inspection and management review

60

E-R DIAGRAM

Holiday can be defined as entity A category entity can be defined to store member categories; it will have 1-to-many relationship with member entity

61

System Design
database design steps
prepare E-R diagram define tables for entities and relationships (normalized DB design) based on usage characteristics, modify table designs and select access (index) structures

for CIRCULATION system, next few slides illustrate physical DB design

62

Table Design
logical table definition obtained from E-R diagram
MEMBER contains:
id dept category term-date title price type id name

Book contains:
accno publisher class-code authors year ISBN claim-date
63

CLAIMS contains:
accno

Table Design
HOLIDAYS contains:
start-date no-of-days day-allowed

CATEGORY contains:
category books-allowed max-fine-allowed

64

Table Design
BOOK-TYPE contains:
type-code name mem-cat max-days (e.g., reference books are allowed only to faculty for 3 days)

ISSUE contains:
mem-id accno issuedate duedate fine

65

Physical DB Design
Denormalizaion : changing contents for processing efficiency
by splitting a table by merging tables by factoring out data over many records (tuples) and introducing repeating fields by introducing additional fields

deciding on file organization, indexes, etc. (DBMS specific issue)

66

Physical DB Design
MEMBER table
following summary fields can be added
number-of-books-issued number-claimed accumulated-fine

the table can be split into two based on update activity

MEMBER1 : id, no-issued, no-claimed, acc-fine MEMBER2 : id, name, address,

both tables can be indexed on members id

67

Physical DB Design
BOOK table
both issue/return functions access this and CLAIMS table on accno field a summary field will be useful:
no-claims (number of claims)

68

Physical DB Design
CLAIMS table
factoring can be applied to group claims on one book in one record record now contains an array of size 3:
accno no-claims {user-id,claim-date}

index on accno to facilitate random access on accno

69

Physical DB Design
ISSUE table
accno is key field most operations access this table on accno choose index on accno to find books issued to a particular member, a secondary index on members id is desirable; this is a frequent query

70

Physical DB Design
CATEGORY and BOOK-TYPE tables
sizes of tables are small can be memory resident (read into arrays within programs)

Ex: will it be desirable to combine ISSUE and CLAIMS tables?

71

System Design
Software architecture design steps
start from DFDs convert them in to software structure chart (some techniques available) evaluate modules for complexity, cohesion and coupling

72

Software Architecture
Can be obtained from DFDs

73

Software Architecture

74

Software Architecture

75

Software Architecture

76

Implementation Schedule
Identify main tasks, expected effort (in days, weeks, etc.), and skill for the task (e.g., whether analyst or programmer should do it) make a schedule using bar chart or activity network diagram indicate resource allocation on the schedule

77

Implementation Schedule
also indicate possible parallel activities during management review, we can decide on additional resources to speed-up implementation

78

Implementation Schedule
List of main activities and effort
ACTIVITY IMPLEMENTATION 1w DETAILED DESIGN 1. file definitions (analysis) w 2. data entry programs w (programmer) for book data and member data 3. management reports w design (analyst) 4. management report programs (programmer) 5. member enquiry w design (analyst) 6. member enquiry programs (programmer)

1w 1w
79

Implementation Schedule

7.

List of main activities and effort

ACTIVITY DETAILED DESIGN w w w IMPLEMENTATION 1w w w 1w 1w
80

issue function design (analyst) 8. issue program (programmer) 9. return program design & coding (programmer) 10. claim program design & coding (programmer) 11. System testing (both) 12. user training (analyst)

Implementation Schedule
assume that services of 1 analyst and two programmers will be available for detailed design and implementation based on parallelism in activities, allocate persons to tasks estimate time to complete implementation estimate when and how long (calendar time) services of persons will be required

81

Design documentation
Left as exercise !

82

Detailed Design
design document defines modules by specifying their inputs, outputs, and description of processing purpose of detailed design is to give precise specification of each module
data structures internal logic interface

use a suitable Program Design Language (PDL) (or, pseudo language)

83

Detailed Design
verify that detailed design is consistent with the system design
use design walk throughs module coupling module cohesiveness

evaluate the detailed design technically

we will illustrate one module specification at this level

84

Data and Module Specification

CAT-TAB: global array of {category: string; books-allowed, days-allowed; int} PROC check-category (given-cat, cat-ok, no-books, no-days)

85

Module
BEGIN search table CAT-TAB with category(I) = given-cat if found cat-ok = true no-books = books-allowed(I) no-days =days-allowed(I) if not found cat-ok = false no-books = no-days =0 end-search END
86

Implementation
step consists of coding, documenting, and debugging of programs use well-proven principles
structured programming programming standards documentation standards testing standards program walk-throughs

87

Implementation .
system testing
use realistic as well as extreme cases involve all system elements: programs, files, forms, people counter-clerk training system administration training direct conversion recommended (no need for parallel running)
88

user training

plan a switchover

Summary
The case study illustrated various steps and deliverables Each step uses techniques, tools to do its activities We must follow documentation standards Reviews are very important

89