Case study: library book circulation system

1
Case study library book circulation system

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

2
BOOK CIRCULATION

• Organization
• IIT Bombay Central Library
• Main functions
• book acquisition
• journals/periodicals
• book circulation
• One of the largest technical books library
• about 3,00,000 books
• about 1,500 journals
• employs 50 persons

3
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

4
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

5
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

6
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

7
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

8
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

9
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

10
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

11
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
• study circulation rules
• different member types have different rules about
  number of books allowed and period of issue

12
FEASIBILITY ..

• problems of members (library users)
• long queues
• poor (in fact, unacceptable) claim and enquiry
  service
• counter clerks problems
• excessive book keeping date-stamping and
  signatures at 4-5 places
• verification quota exceeding, signatures,
  delayed returns, etc.
• claim handling clumsy
• enquiries (such as is book .. issued? to
  whom? ) difficult to handle

13
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

14
(No Transcript)
15
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

16
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

17
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

18
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

19
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

20
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

21
FEASIBILITY ..

• Costs
• Systems Rs. 4.00 lakhs
• DBMS 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

22
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 Rs. 1.50 lakhs
• bar-coding of books and Rs. 1.50 lakhs
• member id cards
• ------------------
• Total Rs. 10.00 lakhs

23
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 )

24
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

25
Financial analysis for alternatives 1

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

26
Financial analysis for alternatives1..

• investment analysis
• year saving present value cumulative
• (lakhs) ( at 12 ) 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

27
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

28
Financial analysis for alternatives1..

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

29
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

30
Plan for alternatives1..

• make a rough implementation schedule
• phase effort calendar time
• requirements 2 w 3 w
• analysis
• design 2 w 3 w
• detailed design 3 w 4 w
• Implementation 8 w 4 w
• 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

31
Financial analysis for alternatives1..

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

32
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

33
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

34
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

35

• Start with Context diagram

36

• Draw first level DFD

• Let us concentrate more on process 1 explosion

37
(No Transcript)
38
(No Transcript)
39
(No Transcript)
40
Requirements Analysis

• contents of data store book
• accno ISBN title
• authors publisher year
• price classification book-type
• note book-type indicates book category that may
  have issue restrictions (only to certain member
  categories and for certain periods)

41
Requirements Analysis

• contents of data store member
• id name dept
• category termination-date
• note category defines privileges of member (no.
  of books, period of issue, etc)
• contents of data store issue
• id accno issue-date
• due-date return-date fine
• contents of data store claim
• id accno claim-date

42

• Refinement of issue process

43
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

44
Requirements Analysis

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

45
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

46
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

47
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

48
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

49
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

50
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)

51
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.

52
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

53
SRS

• 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

54
SRS

• 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

55
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.

56
SRS

• a) ISSUE file
• Usage
• Type tasks frequency activity ratio
• (per day) (no of rec)
• retrieval enquiry 100 10
• update - - -
• insert issue 500 1
• delete return 400 1
• 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

57
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

58
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)

59
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)

60
System Design

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

61
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

62
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

63
Table Design

• logical table definition obtained from E-R
  diagram
• MEMBER contains
• id category name
• dept term-date
• Book contains
• accno title authors
• publisher price year
• class-code type ISBN
• CLAIMS contains
• accno id claim-date

64
Table Design

• HOLIDAYS contains
• start-date no-of-days
• CATEGORY contains
• category books-allowed day-allowed
• max-fine-allowed

65
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

66
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)

67
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

68
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)

69
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

70
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

71
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?

72
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

73
Software Architecture

• Can be obtained from DFDs

74
Software Architecture
75
Software Architecture
76
Software Architecture
77
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

78
Implementation Schedule

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

79
Implementation Schedule

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

80
Implementation Schedule

• List of main activities and effort
• ACTIVITY DETAILED IMPLEMENTATION
• DESIGN
• issue function design ½ w -
• (analyst)
• issue program - 1 w
• (programmer)
• return program design ½ w ½ w
• coding (programmer)
• 10. claim program design coding ½ w ½ w
• (programmer)
• 11. System testing (both) - 1 w
• 12. user training (analyst) - 1 w

81
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

82
Design documentation

• Left as exercise !

83
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)

84
Detailed Design

• verify that detailed design is consistent with
  the system design
• use design walk throughs
• evaluate the detailed design technically
• module coupling
• module cohesiveness
• we will illustrate one module specification at
  this level

85
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)

86
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

87
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

88
Implementation .

• system testing
• use realistic as well as extreme cases
• involve all system elements programs, files,
  forms, people
• user training
• counter-clerk training
• system administration training
• plan a switchover
• direct conversion recommended (no need for
  parallel running)

89
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