Systems Analysis For Library Management

Systems Analysis for Library Management
Mahfoz Hossain University of Dhaka 2014
Summary of Modules
Module 0. Module 1. Module 2. Module 3. Module 4. Module 5. Module 6. Module 7. Module 8. Module 9. Module 10. Summary & Overview Conceptual Framework Supporting Software Structure of Systems Analysis Objectives & Requirements Methods for Analysis The Library Planning Model Requests for Proposal Measures of Performance Issues in Determining Costs Details of RFP
Module 0. Summary & Overview
Summary
Contexts for Library Systems Analysis Methods for Dealing with such Tasks Supporting Software Tools
System Schematics Steps in Systems Analysis Stages in Systems Analysis Approaches to Systems Analysis
Summary (cont.)
Definition of Objectives Determination of Requirements Functional Requirements Methods for Analysis Approaches to System Design Requests for Proposal Assessment of Effectiveness Assessment of Costs
Overview
A. CONCEPTS, REQUIREMENTS DEFINITION, SCOPE 1. Introduction & Overview 2. Systems Analysis Concepts 3. Scope & Requirements B. METHODS OF ANALYSIS 4. Dimensions of Analysis & Design 5. Data Structures 6. Description of Relationships among Dimensions C. METHODS OF DESIGN & EVALUATION 7. Systems Design 8. Measurement of Effectiveness 9. Measurement of Cost D. PROJECT MANAGEMENT 10. System Implement, Project Manage, Monitor 11. Software
Module 1. Conceptual Framework
Contexts for Library Systems Analysis

Implement Library Automation Evaluate a New Library Service Determine Staffing Assignments Compare Alternative Means for Storage Adapt to Institutional Priorities Justify Budget Submittals Plan a New Library Building Develop Inter-Library Cooperation Support National Library Policies
Methods for Dealing with such Tasks

Experience and Intuition Politics and Negotiation Trial and Error
Systems Analysis
Hermeneutics Analogy
Systems Analysis
SYSTEMS ANALYSIS is derived from scientific and mathematical tradition. It attempts to understand a phenomenon which it calls a system by breaking it into successively more detailed component parts the process of analysis until the parts can be understood in themselves, without further stages of analysis. The great strength of systems analysis is its ability to deal with exceptionally complex phenomena and to provide means for dealing with them, especially for pragmatic purposes. The great deficiency of systems analysis is inherent in the very process of analysis: The approach to analysis predetermines the final picture of the phenomenon; the phenomenon as a whole may be destroyed; and essential inter-relationships among component parts may be lost. Of course, the methodology can in principle compensate for the deficiency by providing means to reconstruct relationships and to identify larger contexts.
Hermeneutics
HERMENEUTICS is derived from theological and philosophical tradition. Originally, it was a methodology for Interpretation, especially of scriptural text. It attempts to understand a phenomenon by identifying its relationships to other phenomena, ultimately encompassing the entire universe. The great strength of hermeneutics is its emphasis on inter-relationships and the resulting ability to interpret interactions and to see the effects on the whole. The great deficiency of hermeneutics is that it provides no means to delve into the structure of a phenomenon or to set boundaries on the scope of inter-relationships to be considered. Inevitably, it thus must encompass the universe. Of course, the methodology can in principle compensate for the deficiency by incorporating some methods of analysis and by setting boundaries on the scope of phenomena to be inter-related.
Analogy
ANALOGY is derived from mathematical and pragmatic tradition. It attempts to understand a phenomenon by identifying its similarities to other phenomena, drawing analogies from them to suggest form, structure, function, and operation. The great strength of analogy is its ability to draw upon past experience and bring it to bear on new situations without the delays that arise from other approaches to dealing with new phenomena. The great deficiency of analogy is that it fails adequately to deal with essential differences, treating similarities as though they reflected identity. As a result, it can lead to serious mis-understanding and disastrous results. Of course, the methodology can in principle compensate for the deficiency by assuring that essential differences are recognized and even emphasized in developing understanding and, especially, in use of the understanding.
Module 2. Supporting Software
Supporting Software Tools

Word Processing, for Reporting Spreadsheets, for Data Analysis Database Management, for Data Storage PowerPoint, for Data Presentation
Computer Aided Systems Analysis, for Methods The Library Planning Model, for Evaluation Project Managers, for Planning & Control
Computer Aided Analysis Methods

Flow charting Data Flow Diagrams State Transition Diagrams Structure Charts Entity-Relationship Diagrams (ERDs) Data Dictionaries
The Library Planning Model

Represent Workloads in User Services Represent Workloads in Technical Processing Estimate Staff Requirements for Workloads Account for Overhead, G&A, and Expenses Determine Requirements for Facilities Allocate to Means for Storage and/or Access Apply various Models of Library Operations Optimize Means for Inter-Library Cooperation Evaluate Future for Information Distribution Assess National Information Development
Project Management

Establish Work Breakdown Structure Determine Task Inter-Relationships Schedule Sequence of Tasks Assign Resources Identify Schedule Conflicts
Module 3. Structure of Systems Analysis
Information System Schematic
Input
Communicate
Storage
Communicate
Output
Process
Feedback
Objectives
Hierarchy of Systems
National Policies
Cooperation Context(s) Information Technologies Political Context(s) Information Sources Information Facilities User Context(s)
Administrative Context(s)
The Library as System of Focus Sub-System 1 Sub-System 2
Sub-System 3
Sub-System 4
Steps in Systems Analysis

Define the problem, its scope and focus Determine the needs Analyze the data, operations, components Synthesize alternative systems Evaluate and make decisions Iterate these steps until satisfied Implement the selected system Monitor its operation
Stages in Systems Analysis

(1) Analyze Feasibility (2) Specify Requirements (3) Detailed Design (4) Develop Software (5) Develop Procedures (6) Functional Test (7) Implement and Install (8) Monitor & Maintain
(1) Analyze Feasibility

Estimate development costs Check reasonableness of estimates Prepare summary budget plan Estimate current and future costs Prepare cost/effectiveness evaluation
(2) Specify Requirements

Determine detailed requirements Analyze contexts Determine hardware & software needs Compare alternative systems Prepare performance specs Assure concurrence of policy makers
(3) Detailed Design

Determine specific equipment Determine details of activity Determine details of response times Determine details of operating environment
(4) Develop Software (5) Develop Procedures (6) Functional Test

Produce software specifications Review and evaluate available software Analyze make-or-buy Develop Procedures Functional Test
(7) Install & Implement (8) Monitor & Maintain

Install Hardware Install Software Prepare Documentation Train Staff Convert Data Files Convert Operations Orient Users
Monitor Operations Maintain Hardware, Software, Procedures
Module 4. Objectives & Requirements
Definition of Objectives
MANAGEMENT OBJECTIVES Strategic and Contextual Objectives Tactical Objectives Operational Objectives TECHNICAL OBJECTIVES Functional Requirements Performance Requirements Cost & Budget Requirements POLITICAL OBJECTIVES Administrative Responsibilities Professional Concerns Capital Commitments Personal Perspectives & Goals
Determination of Requirements
Performance Expectations Boundary Conditions Functional Requirements Political Factors
Performance Expectations
Level of Performance
High Performance Frugal
Resource Implications
Resource Exploitation Resource Creation
Subsistence
Resource Preservation
Boundary Conditions
Issue
Funding Staffing Equipment
Boundary Conditions
Available Resources Maintain, Reduce, Reallocate? A Means or an Objective?
Alternatives
Prescribed or Proscribed?
Functional Requirements
Context Requirement
Operating Procedure
Reporting
Formalize
Identify Formats
ad hoc Procedures
ad hoc Requirement
Establish Means
Isolated Event?
Political Factors
Context Political Issue
Capital Commitments
Administrative Responsibilities Professional Perspectives Personal Objectives
Reluctant to Change
Protect Authority Maintain Commitments Hidden Agendas
Contexts for Determining Requirements

Past Experience Present Operations Future Operations
Sources for Data on Past Operations

Specifics
Internal, Informal Internal, Formal
Examples and components

Memos, ad hoc reports,personal databases Reports, database files, procedures manuals, documentation, organization charts
External, Formal
Publications, national databases
External, Informal Exchanges with colleagues
Present Operations
Specifics
Walk-Throughs

Observe forms and documents, procedures, individual persons
Transactions, files, reports Questionnaires, Interviews, Surveys Monitoring online operations, recording transactions Close observation, Experiments
Statistics Survey Instruments
Use Logs Time & Motion Study
Future Operations
Specifics
Critical Incident Technique
Delphi Technique

Specific need, antecedent context, means used, outcome
Discussion, Questionnaires, Statistics, commentary, Iteration Teams: Identify Needs,Postulate System, Describe Events, Assess Time Horizon, Alternative Bases for Projecting
Scenarios
Project Statistics
Module 5. Methods for Analysis
Alternative Approaches
Evolution from Current Operations Maintains consistency in operations Builds upon data from actual experience Tends to perpetuate existing assumptions and deficiencies Determination of Objectives in terms of User Needs Aims to avoid pre-existing assumptions Builds upon studies of users and their needs Is difficult to identify what are real objectives Revolution to a Brave New World Looks to an ideal system Builds upon models and hypothetical data Tends to create its own assumptions and deficiencies
Alternative Approaches
There are two dramatically different approaches to determination of the requirements for an information system and, as a consequence, to the entire concept of system analysis: the evolutionary approach and the revolutionary one. The former starts from the existing operation, determines what it does and how it does it, then uses the resulting picture as the basis for identifying requirements, extrapolating from current needs, usually as represented by workloads. The latter tries to create a more conceptual picture of an ideal or total set of requirements, determined not by examination of any current operation or the needs it serves but by an examination of users themselves, focusing on the functions they perform and determining requirements from them. Between them lies an approach that mixes the two extremes, by starting from the Evolutionary approach but placing special emphasis on needs of users.
The Evolutionary Approach

Underlying the evolutionary approach are several rationales. First, whatever the new system may be, there must be a process of transition from the existing system; therefore, at least the implementation stage of the systems analysis process must be designed around that necessity. Second, the existing system presumably reflects a pragmatically determined set of requirements, with which users are familiar and with which they expect to be served; determination of requirements must, at some stage, recognize and deal with those expectations. Third, like it or not, the existing system is the only source for real data about actual experience in meeting requirements; those data are crucial if any new design is to have a basis in facts rather than mere conjectures or speculations. Finally, users are difficult to examine, remarkably variable in their behaviors, so any attempt to investigate their "true needs" is fraught with difficulty and likely to be idiosyncratic; in contrast, an existing operation is comparatively easy to examine, and the results are likely to be much more robust.
The Revolutionary Approach

Underlying the revolutionary approach are two fundamental rationales. One rationale is the perception that any existing system pre-determines what needs it will serve by the very nature of what it provides; therefore, if there is to be any possibility of recognizing unmet needs, one cannot start by accepting the existing set. The second rationale is embodied in the "total systems concept" which argues that a new system should be conceived and implemented as an integrated whole rather than as a set of relatively isolated sub-systems; only by looking at requirements external to the means for implementation can such integration be achieved. In a very real sense, the second reflects the addition of a hermeneutic element to the process of systems analysis.
My Choice of Approach
These are not necessarily exclusive alternatives. In fact, in each approach there will be elements of analysis that are best handled by the other. But each systems analyst does adopt one or the other as the basis for working, and I must record that in my own case it is the evolutionary approach combined with emphasis on needs of users. Among my reasons for choosing the evolutionary approach is my experience with the importance of political factors in the entire process. The facts are that information systems, the way in which they are implemented and operate, affect people the people that work in them, the people they serve, the people that provide the resources needed. Those political factors need to be understood and, like it or not, are largely determined by the current situation and the reasons for wanting changes from it. In fact, my experience as a consultant universally has been that the need for analysis arises not from the technical decisions, though they may be seen as providing the answers, but from the political ones. Therefore, as we later examine the determination of scope and of requirements, I will place some emphasis on the political factors.
Approach Adopted in this Course

The approach adopted and presented in this course emphasizes Evolutionary development from current operations. It does so for several reasons: The most reliable data are from current and past operations. Whatever the ultimate system may turn out to be, there will need to be transition to it from current operations, and the evolutionary approach, makes that transition most effectively. Other approaches create their own assumptions and deficiencies which will produce their own problems.
Turning first to the Conceptual Approach:
The Role of Methods

The following discussion will present a set of methods to support the process of systems analysis, design, and evaluation. They also assist in communication among the members of the systems team and with others, outside the team, such as management. It is important to note that these are tools, so they should be used as tools and not as not straight-jackets.
Dimensions of Analysis
Underlying all of the methods are four dimensions:
Data
Entities & Relationships Records & Fields
Functions
Processes Decisions
Components
People Equipment
Time
Sequence Events
The Role of Structure

In each dimension (Data, Function, Component, and Time), there are structures that provide the basis for defining entities within the dimension and relating the entities within that dimension to each other. The first task in analysis is to identify those structures. Among the dimensions, there are relationships among entities from two or more of them. The second task in analysis is to identify inter-dimensional relationships.
The Types of Methods

The methods are means for describing either the structures within each dimension or relationships among dimensions. Some of the methods are graphical, presenting the description in the form of charts. Some of them are algorithmic, providing the basis for creating programs.
The Foundation for Methods

Underlying the methods, whether graphical or algorithmic, is a database, the entries in which are:
a characterization of an entity in one of the dimensions a relationship among entities within a dimension A relationship among entities across dimensions
The entries for a relationship across dimensions take the following form:
Data Entity Function Component Time Parameters Entity Entity Entity
Maintenance of this data base is a central task in conduct of a systems analysis project.
Lets first look at the Data Dimension, since it is the foundation for everything:
APPROACHES TO DEVELOPMENT OF DATA STRUCTURES (1)

In discussing approaches for methodologies of analysis, I identified two contrasting approaches to the process: the conceptual approach, focused on the ideal requirements, and the pragmatic approach, starting from the current operation. As I have indicated, one must in fact encompass both approaches within one's own procedures, so the issue is not which of them one uses but with which one starts. I have found the pragmatic approach to be the most effective starting point for me, but it does have the disadvantage that it is conservative and biased toward definitions of requirements that reflect the current operation rather than an ideal one.

These two approaches can be exemplified by the analysis of data structures. The conceptual approach starts with the identification of "entities", representing external objects relevant to the system (such as persons, places, things, organizations, activities, etc.), moves to the characterization of them by data elements, and in successive stages analyzes those data elements into increasing depths of detail; the final result is the identification of "values" that can appear in the data elements at the lowest level of detail. In later stages of analysis and, later, of design, the entities and their data elements become the potential bases for file structures and then may become related to each other, using specific data elements (serving as identifiers) as the means for establishing the relationships.

In contrast, the pragmatic approach starts with existing records, forms, files, reports, and related data structures. The data elements that make up the "formats" of those data structures serve then as means for identifying the entities and their component data elements to be encompassed by the system. The initial relationships among entities are evidently those embodied in the existing files, records, forms, reports, etc. Of course, that initial definition of relationships does not preclude one from establishing others or from restructuring the initial ones, but it does tend to bias one's thinking along the lines of current operations.
Data Structures
Data Dictionary Meaning of Data Element Composition of Complex Data Element Acceptable Values for Data Element Alternative Values for Data Element Entity and related Properties Key Field Other Required Fields Optional Fields Iteration of Fields (zero or more) Objects: Types and Sub-Types of Entities Shared Properties Distinct Properties
A data dictionary is a centralized depository of data about data as a means for dealing with databases systems of increasing size and complexity. Such systems can have dozens of programs, hundreds of thousands of lines of code, hundreds of data field names in dozens of types of records, many relations and reports, dozens of professional programmers maintaining the system, and hundreds of users. A data dictionary is a necessity to maintain control, to assure uniformity in development, to communicate with users. Historically, this functional need was represented by forms control. Each form, record, and report would be identified and given a form control number. A forms control record would show the fields incorporated in it, identify who was responsible for generating it and transmitting it. The resulting file was a the counterpart of the modern data dictionary.
Maintenance of a data dictionary requires the following elements: Means for defining entries Means for adding, modifying, and deleting entries Means for validating entries Means for inter-relating entries
Data Structures Examples
Data element: Name Alternatives: Corporate, Individual Structure: (Name), ((Title), First, (Middle), Last), Value: (Alpha-Numeric), (Alphabetic) Data element: Customer ID Value: (Numeric) Data Element: Address Structure: (Street, City, State, Mail Code, Country) Alternatives: (Home Address), (Business Address) Data Element: Customer Record Key Field: Customer ID Required Fields: Name, Address Optional Fields: Alternative Address(es)
Relationships
A Relationship is an operational connection among two or more Objects For example, a Purchase is a Relationship among the following Objects: Customer ( there may be one or more) Item Purchased (there may be one or more) Sales Representative Order form A Form (such as an Order Form) embodies a Relationship and contains Fields identifying the Objects (as shown above)
Normalization in Relational Databases

Problems can arise with multiple occurrences of a given Object in a Relationship:
There can be redundancy, with values appearing multiple time can consuming storage space. There can be inconsistencies because of errors in entry of multiple values.
To avoid those problems, a Relational Database defines canonical forms for each Entity and Object which have the following properties:
There is no redundancy, so a given field and its value for a given record (except for IDs) appears only once in the file. All references to an entity are by means solely of its ID field.
Illustration of Normalization (1)

Let's illustrate the process of normalization by considering the following entity types as related to an Order Form. First, an order form typically includes of a "header" containing information about the supplier (name, address, perhaps discount rate, etc.) and about the overall order (date, "deliver to", "bill to", order number, etc.). Second, an order usually consists of a series of "line items", each relating to a particular thing being ordered (quantity, name, identifier, unit price, applied discount, extended amount). Just from the structure of the order form itself, we can establish two entities: the order (represented by the header) and the line item (represented by each of the line items in the order form). But beyond them, there are at least two other entities implicitly represented: the supplier and the purchased thing (for a book, for example, that would be a title). We must now determine, for each of these entities, the minimally necessary data elements for identification and description: Header: Header ID#, Date, Supplier ID#, ... Line Item: Header ID#, Line Item ID#, Thing ID#, Quantity, ... Supplier: Supplier ID#, Name, Address, Discount, ... Thing: Thing ID#, Name, Price, ...
Illustration of Normalization (2)

In each case, there may be additional data, not included in the entity record but calculated from a combination of data from the several entities (such as the extended amount for each line item and the total of them for the header). Furthermore, the ellipses ("...") reflect the fact that there may be essential data elements not evident a priori but that will arise from the operational needs; there may be data elements needed for error control even though redundant (such as a count of the number of line items and an entry for the total of the extended amounts, both included within the header). It is important to note that the record for each entity type (and therefore for each entity within it) contains an ID#. This is a unique identifier, used to relate entity types with other entity types, as is illustrated in the line item entity record (in which Header ID# and Thing ID# provide the links to those entity records). In the case of the entity type called "Thing" above, the data elements necessary for description are likely to be far more extensive than the simple example shown. In the case of books, in fact, necessary data elements are represented by the MARC format, with recognition that some (such as publisher fields and sub-fields) may be replaced by links to other entities (the Publisher entity type, for example).
Warnier-Orr Diagrams
The Warnier-Orr technique uses graphical displays that combine brackets, circular arrows, vertical arrows, numbers (N), and plus signs (+) to portray activities or data elements and the relationships among them. The Warnier-Orr technique as applied to description of data elements starts with the system outputs, including reports, forms, and files, perhaps using means similar to the Worksheets 2 & 3 (to be presented later). Each of them is decomposed into data elements. Hierarchies are identified (for example, as involved in sub-fields of a MARC record) and schematically shown by brackets that enclose data elements supporting or involved in the label to the left of the bracket. Options for data elements, sequences of them, or repetition of them are then shown by the appropriate symbol.
The following slides have been copied from http://www.kenorrinst.com/wo1.htm
Hierarchy
Hierarchy for Data Structure
Hierarchy for Processing Structure
Hierarchy is equivalent to Consists of or Is composed of
Sequence
Sequence example
Repetition
Repetition example (1)
Alternation shown by
Alternation Example
Concurrency example
Recursion (i.e., Repetition)
Lets now turn to the Functional Dimension:
The Functional Dimension

Data Input and Output Processes Data Storage and Retrieval Processes Computational Processes Decision Processes Communication Processes Dataflow Diagrams Process Flow Diagrams (e.g., Flow Charts) State Transition Diagrams Program Languages
Data Flow Diagrams

Data flow diagrams are schematic representations of systems, using symbols to show the ways in which data flows from one entity or process to another. It does not show decisions or usage patterns or great detail. However, by use of data flow diagrams at different hierarchical levels, one can show increasing details. The following example of a data flow diagram is based on the Stages in Systems Analysis as discussed earlier. Note that just four symbols are used: Arrowed Line, to represent data flows within the system Square Box, to represent data sources,stores, or destinations Rounded Box with Headers, to represent data processes or transformations Square Box with Corner Labels, to represent entities outside the focus Actual procedures, such as those to accomplish a specific task, would be detailed in a procedure specification. Procedures will present not only data manipulation, but control, such as deciding which path to take in performing a procedure. Details that are not shown in a data flow diagram (such as amounts of activity, timing, frequency, etc.) are shown on supplementary diagrams.
Project Requestors
Management
Stage 1 Feasibility
Stage 2 Requirements
Stage 3
Systems Development Data Base

Detailed Design
Stage 8 Monitor & Maintain
Stage 7 Implement Install
Stage 6 Functional Test
Stage 5 Develop Procedures
Stage 4 Software Design
Management
Project Requestors
Vendors
The focus is on Data Flow, not Sequence

It is important to note that the focus of a Data Flow Diagram is on the paths of data flow, not on the sequence with which flow may take place. In the Data Flow Diagram of the prior slide, the several stages are not necessarily executed in the sequence implied by the stage numbers, since the data does not flow from stage to stage but instead from each stage to and from the central database, or to and from the external entities. Nothing would prevent the stages from occurring in parallel. Indeed, in some systems development projects, that is exactly what happens.
Data Flow Diagram Symbol Conventions

Various computer software to aid systems analysis may have slightly different conventions for the symbols they use in data flow diagrams. The following two slides are taken from two software packages, using different symbols from the ones of the prior slide. The user needs to become comfortable with whatever may the conventions in the software being used.
Flow Charting
Flow charting is a tool used to show the sequence of steps in a computer program, a procedure, or a process. There are typical conventions for the use of symbols in a flow chart, as illustrated in the following slide. But, as with other examples of schematics, the various computer software packages will differ in the conventions they use. Again, the user needs to become comfortable with whatever may the conventions in the software being used.
C om m e nt
Co re
D isp la y
C on ne cto r
O ff-pa g e Co n ne ctor
O utp ut D ocu m en t O fflin e S to ra ge
G e n eric P roce ss
Term in a l Pro cess (be gin, e nd ) On line Stora g e De cisio n P roce ss Dis ke tte
De cision Pro cess
M a nu al O p e ratio n
In pu t-O utp ut Pro cess
M a gn etic Tap e M an ua l Inp u t P re p ara tio n Pro ce ss M a gn e tic Dru m Pred e fine d P roce ss Inte rna l Su b -ro u tine Pu n che d C ard
Ca rd D eck Extract Pro cess C olla te Pro cess Pu n che d Ta p e M erg e P roce ss So rt P ro ce ss
Flowcharting of Systems Analysis Stages

The following flow chart is again based on the stages identified for the process of Systems Analysis. But this time the focus is on the sequence with which the stages take place. The flow chart is structured into several levels of detail. First, there is an overview. Second, for each process in the overview, there is a chart with greater detail.
Systems Analysis Flow Chart Overview
Details of Preliminary Stage
Details of Stage 1
Details of Stage 2
Details of Stage 3
Details of Stage 4
Details of Stages 5 & 6
Details of Stages 7 & 8
State Transition Diagrams

State transition diagrams are probably the most esoteric of the means for picturing operations in a system, since they are based on the most theoretical concepts of what are called finite state machines. They focus on very specific components of the system entities, such as machines but also parts of the symbolic structure of the system. The entity is pictured as receiving events from the outside world, and each event potentially as causing a transition of the entity from one state to another. State models require identifying each of the possible state of an entity. Thus, they are ideal for describing the behavior of a single entity but they are not useful for describing behavior that involves several entities.
Now, lets turn to the Components Dimension:
Component Dimension
Personnel Components Equipment Components
Organization Charts Operational Relationships Charts
Administrative Hierarchy Centralized

Library Management
M anagement Support Systems Budget & Accounting Personnel Server Development External Facilities Terminals
Training Softw are
Hardware
Cataloging Circulation
Acquisitions
Library Operations
Central Library
Branch Libraries
Technical Services
Reader Services
Hum anities
Social Sciences Selection Acquisition

Receiving
Reference Physical Science Circulation Biological Science

ILL
School of Law Cataloging School of M edicine Conservation School of Engineering
Administrative Hierarchy De-Centralized

University Administration
Central Automated Bibliographic System
Humanities Faculty
Physical Sciences Faculty
Engineering Faculty
Library
Library
Library
Technical Services
Readers Services
Readers Services
Technical Services
Readers Services
Technical Services
Social Sciences Faculty
Biological Sciences Faculty
Law Faculty
Library
Library
Library
Readers Services
Technical Services
Readers Services
Technical Services
Readers Services
Technical Services
Medicine Faculty
Library
Readers Services
Technical Services
Finally, turning to the inter-relationships among Dimensions:
Inter-relationships among Dimensions

Data Component Function Component Function Data Data Time Component Time Function Time Responsibility Matrix Responsibility Matrix Application Matrix Dataflow Diagram Gantt Chart Flow Chart
Component-Function Responsibility Matrix

The Component-Function responsibility matrix provides means for supplementing the administrative hierarchy among component by description of the operational relationships among them. It provides means for identifying the workloads for each component as the relate to functions entailed in the execution of major tasks within the library. The following examples illustrate the elements in the responsibility matrix.
Component-Function Responsibility Matrix Examples

The following two examples (one for ILL processing and the other for Collection Development) show a sequence of functions for the respective tasks and components responsible for each. The first column identifies the sequence of processes for the function. The third column identifies, by classification code, the position of the component in the administrative hierarchy. The fifth column identifies, again by classification code, the position of the software component in the software system. The codes in the third and fifth columns can be used to sequence the matrix so as to bring together all of the functions, in whatever task, for which a given component is responsible. In this way, the responsibility matrix provides means for determining workloads on each component.
Functional Relationships among Components

Example of ILL-related Functions
ILL Borrowing
1 2 3 4 5 6 7 8 9 10 11 12
Personnel Component
11 11 11 11 11 14 23 14 12 12 14 1 Reference Reference Reference Reference Reference ILL Management Receiving ILL Management Circulation Circulation ILL Management Budget & Accounting
Software Component
12 13 13 13 23 23 23 21 21 1 1 OPAC Module OCLC Module OCLC Module OCLC Module ILL Module ILL Module ILL Module Circulation Module Circulation Module Accounting Module Accounting Module
Receive Request Check OPAC Check Bibliographic Request via OCLC Select Source Establish Record Receive Material ILL Manage Circulate to User Return Material Account for Transaction Reconcile Accounts
Functional Relationships among Components

Example of Collection Development Functions
Collection Development Personnel Component
1 2 3 4 4 4 5 6 6 7 8 9 9 10 11 Collection Policy Collection Priorities Budget Allocation Recommendation Recommendation Recommentation Selection Ordering Ordering Receiving Processing Paying Paying Cataloging Shelving 0 0 1 11 30 21 21 22 22 23 23 22 22 24 12 Library Management Library Management Budget & Accounting Reference Branch Libraries Selection Selection Acquisitions Acquisitions Receiving Receiving Acquisitions Acquisitions Cataloging Circulation
Software Component
1 21 21 21 21 21 1 21 12 21 1 22 12 Accounting Module Acquisitions Module Acquisitions Module Acquisitions Module Acquisitions Module Acquisitions Module Accounting Module Acquisitions Module Circulation Module Acquisitions Module Accounting Module Cataloging Module Circulation Module
Gantt Chart
A Gantt chart shows the sequence of a set of functions or activities (called a work breakdown schedule) much as does a flow chart, but in addition it shows the duration of each activity and the inter-dependencies of activities. One can therefore see when, in time, things will occur and can determine which activities may causes delays. In addition, a Gantt chart will frequently show the assignments of activities to components and the resources implies by those assignments. One can therefore see where there are too few or too many resources and where resources may need to be allocated in order to deal with potential delays by shortening the duration of an activity.
Gantt Chart Illustration (1)

The following three slides present an illustrative Gantt Chart which is based on the stages involved in systems development.
The first slide presents the preliminary stage and then Stages 1 and 2. The second slide presents Stages 3 and 4. The third slide presents Stages 5 and, more briefly, Stages 6, 7, and 8.
These slides were produced using the software package Project Manager Pro.
Gantt Chart Illustration (2)

The following three slides present much the same schedule, but this time using the software package Time Line. There are several reasons for presenting this package:

It includes capabilities for showing PERT charts It includes capabilities for assigning resources It includes capabilities for dealing with calendars
Unfortunately, it is DOS-based software rather than Windows-based. Even more unfortunately, it is no longer produced so it is not readily available. Despite those difficulties, it still works well and serves an an illustration of its capabilities. Note that I have left the schedules for tasks under Stages 3 thru 8 undefined, so we can use them as exercises.
PERT Chart Capabilities

The original (i.e., in 1900) Gantt chart, useful though it was, lacked several important features, including dealing with dependencies among tasks. During the 1960s, a variety of extensions of the Gantt chart were created, among them PERT (Program Evaluation & Review Technique), as illustrated in the following three slides.
Staff Resources implied by Schedule

A primary value of a Gantt chart is that it provides a basis for determining the staffing requirements per task and per time period. The following two slides present a distribution of staff over tasks during a ten month period in the implementation of a new system. They are based on an actual project in a large academic library. The tasks include those in database conversion, in training, and in technical work on the software, as well as in current operational responsibilities.
MACRO-SCHEDULE: WORKLOAD DISTRIBUTIONS OF SYSTEM STAFF TO ACTIVITIES FOR AUTOMATION PROJECT Entries are Person-Days per Week Staff are A# = System Staff and L# = Librarian Staff STAFF DEC JAN FEB MAR APR ACTIVITIES A# L# D1 D2 D3 D4 J1 J2 J3 J4 F1 F2 F3 F4 M1 M2 M3 M4 A1 A2 A3 A4 DATABASE ACTIVITIES OCLC Retrocon Assess 3 3 3 3 3 3 System Convert Asssess 7 7 7 7 Transfer to new System 1 2 Transfer OCLC to new system 1 2 Transfer system to lbys 1 2 TRAINING ACTIVITIES New Software Mgt Course 5 1 New Equipment Mgt Course 5 1 New System Lbn Course 2 12 54 28 54 28 54 New System Lbn course 6 TECHNICAL ACTIVITIES New system Tables 2 5 14 14 New system Language Translation 2 5 6 6 6 Non-bilio file convert 1 3 6 12 Sys Oper Procedures 2 Lby Oper Procedures 12 OTHER ACTIVITIES Current Ops Responsibility 5 12 28 25 24 18 Holidays & Vacations 5 12 72 85 85 85 85 85 34 TOTALS 5
3 7
3 7
24
24
24 21 54 21 21 54 30 14 14 6 6 6 6 8 8 8
24 21 21 54 21
14 14 6 6
14 6 6 6
6 6
17 13 22
8 17 17
11 17
12 85 85 85 88 85 88 85 88 85 85 85 85 85 85 85
85 85 85 55 85
MACRO-SCHEDULE: WORKLOAD DISTRIBUTIONS OF SYSTEM STAFF TO ACTIVITIES FOR AUTOMATION PROJECT Entries are Person-Days per Week Staff are A# = System Staff and L# = Librarian Staff STAFF MAY JUN JUL AUG SEP ACTIVITIES A# L# M1 M2 M3 M4 J1 J2 J3 J4 J1 J2 J3 J4 A1 A2 A3 A4 S1 S2 S3 S4 DATABASE ACTIVITIES OCLC Retrocon Assess 3 System Convert Asssess 7 Transfer to new System 1 2 Transfer OCLC to new system 1 2 Transfer system to lbys 1 2 TRAINING ACTIVITIES New Sys Mgt Course 5 1 Ne Equipment Mgt Course 5 1 New System Lbn Course 2 12 New System Lbn course 6 TECHNICAL ACTIVITIES New system Tables 2 5 New system Language Translation 2 5 Non-bilio file convert 1 3 Sys Oper Procedures 2 Lby Oper Procedures 12 OTHER ACTIVITIES Current Ops Responsibility 5 12 Holidays & Vacations 5 12 TOTALS 5
12 12 12
9 21 54 54 42 54 21 21 30 30 30 7 6 6 12 46 34 34
30
30
30
30
30
14 14 14 14 14 6 6 6 6 6 6 6 6 6 6 6 6 9 12 12 12 12 12 12 12 12 13 11 7 40
2 53 17 47 55 85 49
78 55 85 55 85 1 85 85 85 85 85
12 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85
Turning now to the Pragmatic Approach:
Worksheets for Data Gathering

Three worksheets will be presented as means for recording data needed for the processes in systems analysis.
(1) Worksheet 1 provides means for recording data about the administrative structure (2) Worksheet 2 provides means for recording data about files. They would include collections of material (each type of collection being a separate file) as well as administrative and operational data files. The relevant data include identification of the types of records that are stored in each file together with numbers of those records that are stored and are acquired. (3) Worksheet 3 provides means for recording data about records that are stored in files. The relevant data include identifying the fields that are included in the records together with the size and frequency of occurrence of each field.
Worksheet 1: Administrative Description

Administrative Unit Purpose: Special Responsibilities: Supervisor (Name & Title) Related Administrative Duties: Special Administrative Duties: Community Served: Units of Work: Remarks: Personnel FTE Cler Stu Total Costs Direct Burden Workload Mnly Yrly Unit Costs Workload/Costs Reports to (Name & Title) Building Location Net Sq. Ft.
Function
Prof
Dly
Date
Analyst
Source
Page
Worksheet 2: File Description

File Name File Purpose: Who Needs Access: File Location: Sequenced by: How Current Retention Period Remarks Record Name Chars/Record Avg Peak Records per File Avg Peak Transaction Volume Avg Peak Label: Storage Medium File Number
Seq
Date
Analyst
Source
Page
Worksheet 3: Record Description

Record Name Other Names Used: Related Record Numbers: How Prepared: Operations Involved In: Remarks Fields Name Chars/Field Avg Peak Frequency Per Rec Per File Nature of Data A/N Source Record Location Record No.
No.
Date
Analyst
Source
Page
Module 6. The Library Planning Model
The Matrices for Services & Materials

LPM is based on eight matrices, four of clients and services for them and four of materials and technical processes for them. In each case, the first matrix contains data for determining workloads involved; the second contains data for the extent to which workloads use specific services or processes; the third contains workload factors as means for estimating required staff and costs; the fourth contains factors for estimating the need for facilities.
Populations Served
Materials Acquired
Estimation of Required Staffing

Based on the data entered into these matrices, LPM can then estimate the staffing required to handle the associated workloads and compare it with data about the actual or planned staffing.
Served Selection of Populations Results Menu
(1)
(2)
Estimation of Facilities
LPM includes means to estimate the facilities needed to meet the needs of users. LPM includes means to estimate the facilities needed to meet the needs for storage of materials. Since data are reported in many different ways, LPM provides means to convert from one means of measurement to another.
Estimation of Facilities
LPM includes means for estimating the requirements for facilities to meet the needs of users and to store collections.
Representative Space Conversion Parameters

Microform Drawers per Cabinet Square feet per microfilm cabinet 16 mm reels per Drawer 16mm reels per Square Foot 16mm reels per Linear Foot 35 mm reels per Drawer 35mm reels per Square Foot 35mm per Linear Foot Microfiche, Items/Drawer Microfiche, Square feet/Drawer Archives, linear feet/square foot AV & Electronic, Items per Linear Foot AV & Electronic, Items per Square Foot Bound Materials per Linear Foot Bound Materials per Square Foot 17 11 135 209 20 80 124 10 2,500 1 3 15 30 10 15
Module 7. Requests for Proposal
Request for Proposal

(Sections 1 through 7)
Section 1. Section 2. Section 3. Section 4. Section 5. Section 6. Section 7.
Introduction and Summary Instructions to Proposers Evaluation Of Proposals General Requirements Installation & Conversion Documentation, Training, & Help Maintenance
Request for Proposal

(Sections 8 through 11, Appendices 1 through 3)
Section 8. Benchmark & Acceptance Testing Section 9. Specifications For Required Modules Section 10. Desired Optional Modules Section 11. Specifications For Hardware
Appendix 1. The Institution Appendix 2. Computing & Telecommunications Appendix 3. Requirements For External Interfaces
Section 2. Instructions to Proposers

Summary of Proposed Solution Status of Development & Implementation The Substantive Proposal Sub-Section Software for Essential Modules Software for Desired Modules Hardware The System Support Sub- Section The Proposer Qualifications Sub- Section The Cost & Contract Sub- Section
Section 3. Evaluation Of Proposals

Hardware & Software Performance Capability to Deliver Support Services Time Schedule Contractual Provisions Cost Other Criteria
Evaluation Process
Section 4. General Requirements

System Structure Control of Access Workloads & Response Times Languages of Operation Systems Requirements System Availability & Reliability Operation of Terminals Software & Hardware Enhancement Rights to Use of Software
Section 5. Installation & Conversion

Installation Conversion & Migration of Data Conversion of Procedures & Operations
Section 6. Documentation, Training, Help

Documentation Training of Institution Staff Help Support
Education of Users & Assistance to Users
Section 7. Maintenance
Staff Policies of the Proposer Hardware Maintenance Software Maintenance
Section 9. Specifications for Required Modules (1)

Library System Management

Serials

System Records Report Control Records Access Control Records Tables of Definition Records Acquisition Records Vendor Records Fund Account Records
Acquisitions

Serials Subscription Records Serials Holdings Records Materials Management Receiving & Processing Inventory Control Binding
Conservation & Preservation

Cataloging Bibliographic Records Authority Records Cataloging Records
Opac Services
Circulation Transaction Record Patron Record Reserve Book Record Accounting Record Reference Support ILL

Multi-media Management Title Record Equipment Record Rooms & Facilities Network Access CD-ROM Access Campus Databases Internet Interfaces to External Environments
Transaction Records Accounting Records
Section 10. Desired Optional Modules

E-mail Publishing Article Record Journal Record Subscription Record Selective Dissemination of Information Tables of Contents Access Source Record Patron Record
Section 11. Specifications for Hardware

Current Equipment Central & Faculty Library Servers Database Storage Terminals
Appendices
The appendices provide data about the institution, its current information hardware and software, and the needs of the environment external to the institution itself.
Module 8. Measurement of Performance
Needs in Proposal Evaluation

Procedure for Carrying Out Assessment
It is important that there be a well-defined procedure for assessment and that it involve as participants that will represent the persons who will be involved in or affected by the system. That procedure should be clearly identified.
Requirement for Objectivity and Justifiability
For both legal and ethical reasons, it is important that the procedure and assessments be objective and that the basis for the assessments be documents and justifiable
Flexibility in Representing Actual Needs by Specifications
The actual needs may or may not be well represented by the specifications embodied in the RFP. Therefore, they should not be used as a straight-jacket but as a set of guidelines.
Procedure for Assessment

The procedure for assessment could include any or all of the following steps:
A set of Functional Evaluation Teams, each focused on a specific aspect of the RFP, will evaluate the functionality, quality, suitability, and adaptability. A separate Cost Evaluation Team will assess the costs of the proposed systems and the corporate qualifications of the proposers. Each team will make independent rank order assessments and recommendations to the Executive Review Committee which will then weigh and compare them to arrive at it final rank order evaluations and decisions. In is possible that, based on the assessments by the Evaluation Teams, a list of as many as three proposals may be established as the basis for more detailed discussions and demonstrations of the proposed systems at mutually agreed upon sites. In that case, the decision by the Executive Review Committee will then follow the conclusion of those discussions and demonstrations. Following that selection, negotiations would then be started with the selected proposer in order to arrive at a mutually agreeable contract.
Criteria for Assessment

The criteria used in assessment should be identified. The primary criteria should include all of the following:

hardware & software performance capability of the vendor to deliver & to provide support services contractual provisions cost quality of the proposed training program ability to adapt to future changes in hardware and software ability of the system to serve additional future requirements such other factors as may be deemed relevant
Other criteria might include

Sources of Data for Assessment

The primary source of data to be used in assessment should the proposal itself. Beyond it, though, other sources might include:
other documentation from the proposer data from other users of the system records of prior performance by the proposer
Issues in Assessment
BALANCING COSTS WITH EFFECTIVENESS Difference Measures the Problems Ratio Measures the Traps THE MEASUREMENT OF EFFECTIVENESS Multiple Functional Requirements Weighting their Relative Importance Qualitative and Quantitative THE MEASUREMENT OF COST Full-Cost or Marginal Cost Full-Cost or Direct Cost
Cost/Effectiveness Measures of Information System Performance

System Evaluation
S = (Information)/(Response Time) = N/T (Cost) C
Sub-System Evaluation
S = (System Cost) (Sub-System Cost) = N/T * (C CS) (System Cost) CS C
MEANS TO INCORPORATE QUALITATIVE ISSUES (1)

To illustrate one means to represent a qualitative issue, consider comparing levels of quality in cataloging. One catalog record may be more detailed than another, more accurate than another, more conforming to standards, or more specific to a given library's needs than another. How does one represent such differences in quality of cataloging? One means to do so is to represent the alternatives by the functions required to produce them, measuring them by the costs for each. To illustrate, one expects that the quality of the original cataloging will be better than that of copy cataloging (though not necessarily so, since there may be issues of conformity with standards). Lets see what that looks like:
MEANS TO INCORPORATE QUALITATIVE ISSUES (2)

The following matrix represents costs by the labor costs per hour for two levels of staff by (C1 and C2) and the workload factors are the default values used in The Library Planning Model: Copy Cataloging C1*(0.18*2000/1000) C2*(0.02*2000/1000) Original Cataloging C1*(0.05*2000/1000) C2*(1.15*2000/1000)
Clerical Professional
Lets take C1 as $8/hour and C2 at $16 per hour, and consider three different mixes of the two levels of quality with copy cataloging at 100%, 90%, and 70%:
Clerical 3.60 0.10 Professional 0.04 33.00
Mix 1 Mix 2 Mix 3 10 9 7 0 1 3

10
Cost 1 Cost 2 36.00 32.50 0.40 33.36

64.86 6.49
Cost 3 25.50 99.28

124.78 12.48
N/T = 10
10 C = 36.40 CT/N = 3.64
How to Measure Information?

Definition of Information as Processing of Data Levels of Data Processing Measures Appropriate to each Level
Module 9. Issues in Determining Costs
Alternative Means for Cost Assessment
LEVEL
MEANS FOR EVALUATION

Time & Motion Study
RULE OF THUMB RATIOS
Minimum Basic Full Salary Burdened
(Basic)/(Minimum) = 1.50
Direct Labor (Full Salary)/(Basic) = 1.50 Salary & Benefits
(Burdened)/(Full Salary) = 1.50

All Costs
Workload Factors for Estimating Direct FTE

FTE per 1000 Transactions
FUNCTION Acquisition PROCESS Select Order Invoice Original Copy Maintain Charge Shelving Receiving Records Receiving Labeling BibID Handling Records BibID Handling Records WORKLOAD FACTORS Prof Cler Stud 0.25 0.20 0.20 1.60 0.20 0.25 0.03 0.03 0.02 0.10 0.10 0.02 0.06 0.20 0.10 0.20 0.05 0.10 0.20 0.25 0.25
Cataloging Circulation Serials Physical Handling
ILL Borrow
ILL Lending Reference TOTAL Direct FTE
Workload Factors
Relation between FTE per 1000 Transactions and Minutes per Transaction
Assume that a typical working year is 42 weeks (which allows 10 weeks for holidays, vacation, and sick leave). Note that are almost exactly 100,000 minutes in a typical working year: (42*40*60 = 100,800). Hence, one FTE can be taken as 100,000 minutes. Given that, 1.00 FTE per 1000 Transactions implies 100 minutes per transaction and similarly for other numbers of FTE (e.g., 0.25 FTE per 1000 transactions implies 25 minutes per transaction, etc.).
Means for Determining Workload Factors

Time and motion studies. These tend to focus on limited functions (such as keyboarding, sorting, and filing as will be illustrated). Ex post facto accounting. This uses data from current operations, including workloads and staffing, and then analyzes those data, fitting them into a standard accounting structure. Data from a large number of institutions provides means for calibrating, validating, and generalizing. Analogies. These use data from a variety of contexts, including many different types of institutions and operations, and makes comparisons among them to identify common or similar functions and, by analogy, arriving as generalized estimates of rates if performance.
Sorting Time
per item in a batch as a function of (Batch Size) log(Seconds per Item) = 0.25 + 0.25*log(Batch Size)
2.50
log(Seconds per Item)
2.00
1.50
1.00
0.50
0.00 0 1 2 3 4 5 6 7
log(Batch Size)
High 10 Percentile Average Range Low 10 Percentile
Filing Time
per item in a batch as a function of (File Size)/(Batch Size) log(Seconds per Item) = 0.75 + 0.25*log(FileSize/BatchSize)
3.00
log(Seconds per Item in Batch)
2.50
2.00
1.50
1.00
0.50
0.00 0 1 2 3 4 5 6 7
log(FileSize/BatchSize)
High 10 Percentile Average Range Low 10 Percentile
Illustrative Application of Workload Factors

FUNCTION Acquisition PROCESS Select Order Invoice Original Copy Maintain Charge Shelving Receiving Records Receiving Labeling BibID Handling Records BibID Handling Records Workload 30 K titles 20K orders 20 K orders 4 K titles 26 K titles 30 K titles 846 K circs 2537K shelves 30 K titles 30 K titles 91 K items 91 K items 12 K borrows 12 K borrows 12 K borrows 29 K lends 29 K lends 29 K lends 137 K hours Full Time Equivalent Prof Cler Stud 7.57 4.04 4.04 6.15 5.29 7.57 25.37 25.37 50.73 3.03 3.03 1.82 5.45 2.42 1.21 2.42 1.46 2.91 5.82 34.22 68.44 51.82 97.25 85.07 (FTE) Total 7.57 4.04 4.04 8.15 5.29 7.57 50.73 50.73 3.03 3.03 1.82 5.45 2.42 1.21 2.42 1.46 2.91 5.82
Cataloging Circulation Serials Physical Handling ILL Borrow
ILL Lending Reference TOTAL Direct FTE
234.1 3
Alternatives for Overhead Allocation

Category Percent of Total Non-Profit Allocation Industry Allocation
Total Salaries
Direct Salaries
1.00T
0.67T
1.00T
0.67T = 1.00D
Indirect Salaries Salary Benefits Overhead Expenses Sub-Total

G&A Total
0.33T 0.14T 0.20T
0.14T 0.20T
0.67T = 1.00D
1.34T
0.13T 1.47T
1.34T = 2.00D
0.13T = 0.20D 1.47T = 2.20D
Module 10. Details of RFP
Section 2. Instructions to Proposers (1)

GENERAL submit proposal by deadline identify as "Proposal in Response to RFP" clearly identify the name of the proposer stipulate proposal is good for 120 days PROPOSAL STRUCTURE submit proposal in five specified sections submit each section in three copies submit in three-ring binder

PROPOSED SOLUTION respond directly to Sections 4, 9, & 10 present single best answer avoid presenting multiple strategies fully respond to requirements, specifications state extent to which each requirement is met explain means for meeting each requirement provide explanation for any that cannot be met identify exceptions and related requirements Substantive Proposal in specified sequence

THE SUBSTANTIVE PROPOSAL: GENERAL REQUIREMENTS address general requirements SOFTWARE FOR ESSENTIAL MODULES fully implemented turnkey software system address specifications from Section 9 SOFTWARE FOR DESIRED MODULES identify desired modules that are included or specific statement that none is included

THE SUBSTANTIVE PROPOSAL HARDWARE integrated turnkey including hardware, etc. identify hardware required to implement system include all equipment necessary for operation identify differences for essential & optional alternative hardware platforms detailed list of the site requirements detailed list of electrical, etc. requirements identify special conditions or restrictions deliver supplies for initial operation list supplies necessary for initial operation estimate supplies for continued operation provide specifications for all supplies

THE SUBSTANTIVE PROPOSAL STATUS OF DEVELOPMENT & IMPLEMENTATION declare the current status of development declare status for any alternatives presented identify sites for OPTIONAL functions identify sites in test and evaluation identify dates for completion of testing identify dates for completion of development identified status of planning
THE SUBSTANTIVE PROPOSAL THE SYSTEM SUPPORT SECTION INSTALLATION & CONVERSION, DATA & PROCEDURES respond to requirements in Section 5 DOCUMENTATION, TRAINING & HELP respond to requirements in Section 6 MAINTENANCE & SUPPORT respond to requirements in Section 7

THE SUBSTANTIVE PROPOSAL THE PROPOSER QUALIFICATIONS SECTION data to assess financial and staffing CORPORATE DESCRIPTION brief description of the company and parent history, description of organization, staffing identify persons responsible for implementation provide brief resumes for each FINANCIAL CONDITION provide a copy of financial statement audit certified by an officer of the company name, etc. for banking organization disclose judgments, litigation, other problems warrant that no judgment or litigation exists identify any termination of contract warrant if there have been no terminations

THE SUBSTANTIVE PROPOSAL THE PROPOSER QUALIFICATIONS SECTION EXPERIENCE identify customers academic library of the size of the institutional provide data about the size of operation PROPOSED MANAGEMENT PLAN describe management to provide the system time schedule of activities and events provide checkpoints for institutional to review progress identify activities required of institutional

THE SUBSTANTIVE PROPOSAL THE COST & CONTRACT SECTION COST PROPOSAL itemized list of initial & continuing costs costs as unit prices extended to required units identify costs for the essential modules identify costs for desired optional modules identify costs for with identify restrictions on use of the software CONTRACT PROPOSAL identify restrictions on use of software compatible with requirements in institutional usestate owner or licensed to provide software provide licenses to run third party software provide access to source code
Section 3. Evaluation Of Proposals (1)

CAPABILITY TO DELIVER SUPPORT SERVICES previous customers as references evidence of financial viability and continuity evidence of the means for continuing support identify means to provide onsite support identify means to recover from failures identify means to provide hardware maintenance identify hours of support for software

HARDWARE & SOFTWARE PERFORMANCE identify extent of meeting each requirements as necessary identify effects of exceptions extent of flexibility provided and means for it compatibility with US -MARC extent to which multiple languages accommodated means to provide interfaces to other networks conformance with accepted standards limitations on ability to provide reports stipulate if there are no limitations identify statistics that are most valuable

TIME SCHEDULE CONTRACTUAL PROVISIONS COST OTHER CRITERIA training, documentation, means to instruct means for training other institutional library staff ability to adapt to change in technologies ability to serve added requirements EVALUATION PROCESS
Section 4. General Requirements (1)

SYSTEM STRUCTURE integrated database covering all collections viewing whole collection or faculty library switch between one view and the other modular, with easy modification or replacement CONTROL OF ACCESS control of access by different categories basis for access, centrally and at libraries SUPPORT TO LIBRARY & SYSTEM MANAGEMENT information for library and system management information for management of operations management of the system detection and prevention of system failures support library and system management centrally library & system management at faculty library

WORKLOADS & RESPONSE TIMES response times rapid enough replacement values with explanation of reasons extent response time is affected by bandwidth message "Transaction in Process" updated 2 secs indicate likely remaining time for processing LANGUAGES OF OPERATION able fully to operate in multiple languages operation in Local Language, Other Language, and English means for switching languages additional Roman alphabet languages \

SYSTEMS REQUIREMENTS GENERAL software is vendor independent software can be moved to various computers can be output & transport data to other systems means to export and import US -MARC data means to export and import data in MICROISIS means to export and import data in UNIMARC means for import of data for other files fully UNIX compatible consistent with a client/server operation

SYSTEMS REQUIREMENTS SYSTEM AVAILABILITY & RELIABILITY regularly scheduled downtime hours for scheduled downtime percent time fully functional function in a partially connected network procedures for backup of data files procedures for fail-safe operation procedures for operations when system is down schedule of backup to minimize effects OPERATION OF TERMINALS text-based & graphical user interface operation support both PC and Mac terminals support menu driven & command driven operation

SYSTEMS REQUIREMENTS SOFTWARE & HARDWARE ENHANCEMENT means for software and hardware enhancement training support for new or enhanced features requirements to effectively run improvements RIGHTS TO USE OF SOFTWARE guarantee right to use of all software
Section 5. Installation & Conversion (1)

INSTALLATION detailed plan for installation of the system events: hardware, software, conversion percentage of records to be converted plan for phasing into full-scale operation institutional proposed phasing acceptable to the proposer institutional proposed plans for conversion and migration number of records for effective operation alternatives for conversion and of data current system in parallel with the new system schedule for transition from one to the other
Section 5. Installation & Conversion (2)

CONVERSION & MIGRATION OF DATA derive database from existing system & US-MARC records derive authority files from existing system scenario of conversion process views of the most for accomplishing the CONVERSION OF PROCEDURES & OPERATIONS manuals for procedures in use of the system experience in prior conversions
Section 6. Documentation, Training, Help (1)

DOCUMENTATION documentation sufficiently complete deliver full documentation for the hardware provided in English and in Local Language documentation provided by the training time instructions for solving standard problems indexes in both Local Language and English operator manuals for hardware and software provided in both Local Language and English updates during the contract to reflect changes online help for elements of documentation online help in Local Language, English, and Other Language

TRAINING OF institutional STAFF provide a program of training for institutional staff training services for various levels of staff content of training programs means used for instruction the schedule and length for training sessions levels of staff and management each training resources and facilities for training sessions language of instruction means for trainees fluent only in Local Language copies of training manuals included qualifications that institutional staff to train others means they will use for instruction means for training in an operating environment

HELP SUPPORT context sensitive help screens for users tutorial support for untrained users specific help if the system sees a problem hypertext capability help screens to untrained user needs available in Local Language, English, Other Language EDUCATION OF USERS, ASSISTANCE TO USERS advice concerning best means for user education sample materials as an appendix to the proposal
Section 7. Maintenance (1)

STAFF POLICIES OF THE PROPOSER policies affecting the staff commit of time HARDWARE MAINTENANCE procedures for obtaining support for hardware appropriate inventory of parts to be stocked test equipment to be included on site procedures for obtaining support at the site maximum time delay for field support staff costs for alternative delay times support at sites other than central processing procedures for preventive maintenance
Section 7. Maintenance (2)

SOFTWARE MAINTENANCE maintenance of software responsibility for software maintenance procedures for upgrading software costs associated with upgrading procedures for obtaining support for software
Section 8. Benchmark & Acceptance Testing

Procedure for acceptance testing

LIBRARY AND SYSTEM MANAGEMENT functions for management the system reporting on system operation reporting for management of the library system means to specify scope of statistics means to specify content of reports exchange data with all other modules alternatives by which statistics are acquired reports both online, printed or to files output in formats for application software levels of access to functions and data means for specifying formats of displays

SYSTEM HARDWARE & SOFTWARE RECORDS record for each item of hardware & software fields as specified for the record REPORT CONTROL RECORDS record for each report both standard and ad hoc for each new report, for search and access fields for content, calcs, format, sequence fields for use, frequency, and distribution fields identifying the responsible person, etc.

ACCESS CONTROL RECORDS record for each aspect of control of access basis for access control & for effecting it links to records related to individuals TABLES OF DEFINITION RECORDS record for each definition of format of display fields for the role, current spec, history

ACQUISITIONS selection, ordering, receiving, and accounting reporting support management of acquisitions consistent data centrally, at faculty libraries output in institutional specified formats types of orders used in research libraries various conditions of purchase faculty production, student dissertations identify duplicates in the collection identify institutional for exchange in acquisition

ACQUISITIONS support currency conversion exchange data with all other modules available to the OPAC for display to users make OPAC records available to acquisitions means for user to place a request for selection provide data to the serials module means for linking to bibliographic utilities means for linking to book jobbers and databases means to create acquisition record in selection

ACQUISITIONS means for checking for potential duplicates defaulting in repetitive fields consistency criteria for appropriate fields accounting functions for receipt or claiming change acquisitions record & OPAC at receipt means for processing partial shipments growth workloads over the five-year period

ACQUISITION RECORDS acquisition record for each item selected fields as specified searchable and accessible as specified VENDOR RECORDS record for each vendor easy means for processing vendor records fields as specified accessible as specified management of correspondence with vendors information about policies of vendors

FUND ACCOUNT RECORDS fund accounting tracking by institutional criteria track amounts budgeted, encumbered, expended post fund accounts as items are processed adjust values based on authorized changes provide full audit trails for all transactions means for institutional to specify format of reports be a record for each fund account means for processing of fund account records fields as specified

SERIALS means of acquiring and controlling series exchange data with all other modules support all functions in serials interface with all other essential modules receive data from acquisitions at ordering send data to OPAC to display of holdings accommodate active and total titles

SERIALS SUBSCRIPTION RECORDS record for serials with fields as needed SERIALS HOLDINGS RECORDS US-MARC compatible ANSI standard for Serials Holdings Statements
fields as specified

MATERIALS MANAGEMENT manage the physical items in the collection deal with both separate items and serials exchange data with all other essential modules interface with OPAC for change in status interface with circulation missing items

RECEIVING & PROCESSING control receiving of materials support inspection of received items provide means for entry of invoice data identify the person for data entry deal with non-existing records support the physical processing of materials

INVENTORY CONTROL means for taking inventory of library materials means for obtaining the identification data record the date of most recent inventory determining mis-shelved and missing items recognize the status of items update appropriate record to reflect status

BINDING support binding identify materials ready for binding specify details of binding CONSERVATION & PRESERVATION identify items needing preservation work monitor the status of items in preservation

CATALOGING GENERAL create and maintain bibliographic records online processing exchange data with all other modules be available to the OPAC for display to users use records in the OPAC to creat new records linking to bibliographic utilities accommodate multiple items with the same record identify faculty library where item is located one bibliographic record for each title linkage from other records to the master

CATALOGING GENERAL display records related to a current one provide validity and consistency checks detecting duplicates & potential errors spelling checks in Local Language, English, Other Language over-riding mandatory field requirements view authority files and tables in a "window" maintain an "audit trail" of changes in records BIBLIOGRAPHIC RECORDS fully compatible with US-MARC

CATALOGING AUTHORITY RECORDS interactive authority control authority control for author publisher names fully compatible with US-MARC authority records provide different classification schedules handle non-standard classifications CATALOGING TRANSACTION RECORDS record for each cataloging transaction specified fields

OPAC SERVICES OPAC to access and use bibliographic records exchange data with all other modules available from public and staff terminals accessible through dial-up be available for access through the Internet conform to ANSI/NISO Z39.50-1994 standards switched from full to faculty library catalog user searching by natural language or mnemonics screen design and messages

OPAC SERVICES single term search of specified fields specifying an exact match of a field boolean combinations of terms use of comparators use of adjacency, proximity, sequence of terms right truncation of any single word to provide means for left truncation truncation for more than one word in a query display formats be definable

OPAC SERVICES showing the number of hits one-line entries, multiple entries per screen full bibliographic records in full screens highlight search terms within each entry specify sort sequence of multi-entry displays display entry content in user format or US-MARC restrict display of US-MARC to specific users select an entry for full-screen display

OPAC SERVICES "browsing" in the bibliographic file on fields "browsing" in authority files specify retrieved records to be downloaded means for the user to request the download specify the format of downloaded records set limits on the number of records downloaded easy to modify a search query means to narrow a search query by date means to narrow search query by faculty library narrow any search by the type of material store user queries and results

CIRCULATION provide all functions involved in circulation alert operator re any potential problems interface with all other essential modules communicate with OPAC for display of status display of materials charged out to the user providing statistics and reports on operation statistics on frequency of use of items means to identify physical state of materials means for flagging materials as "missing" provide for charge-out, renewal, and discharge accommodate different loan periods provide means for calculating due-dates

CIRCULATION permit circulation of materials in process identifying a borrower lacking a borrower card means for ready creation of a borrower record charge-out of multiple items to a borrower prevent charging prior patron for a current one provide for holds and recalls inform a hold or recall of return of materials cancel holds and recalls for a deleted borrower provide means to control renewal of an overdue have means to block circulation of materials provide means to over-ride restrictions provide for determining overdue status of items

CIRCULATION provide for overdue notices and accounting update accounting records for deleted borrowers means for patrons to self-charge-out materials means for patrons to renew charge-outs functions related to reserve book operations means for online change of parameters means for back-up operation during down-times
TRANSACTION RECORD a record for each circulation transaction specified fields searchable by all fields a notes field for data about the transaction PATRON RECORD be a record for each patron and library specified fields searchable by specified fields means for updating from other files a notes field for data about the patron
RESERVE BOOK RECORD record for each item in reserve book operation specified fields field for use in the reserve book operation RESERVE BOOK CLASS RECORD a record for each class with reserve books specified fields ACCOUNTING RECORD a record of accounting data for fines and fees specified fields

REFERENCE SUPPORT tools to support reference in use of the system interface with all other modules readily exchange data with each of them

ILL: BORROWING & LENDING OR DOCUMENT DELIVERY support borrowing, lending, & document delivery online ILL management of ILL requests interface with the circulation and reference provide reports as necessary for ILL management access by specified fields provide for online editing of requests interface with of electronic mail provide for copyright accounting as necessary

ILL: BORROWING & LENDING OR DOCUMENT DELIVERY TRANSACTION RECORDS a record for each ILL transaction specified fields ACCOUNTING RECORDS a record for each partner institution data for statistics and financial accounting capability for requester records as needed

AUDIO-VISUAL MEDIA & MULTI-MEDIA MANAGEMENT means to manage collections of AV & multi-media means to manage equipment and rooms capability for booking materials and equipment graphic displays for visual review of bookings interface with all other essential modules not duplicate data available in other modules
AV TITLE RECORD a record for each AV or multi-media title managed within the bibliographic database specified fields fields for description of physical condition AV EQUIPMENT RECORD specified fields a record for each item of equipment AV ROOMS & FACILITIES a record for each room or facility specified fields field for booking status of room or facility

NETWORK ACCESS provide means for access to networks tightly integrated with the OPAC module ability to move seamlessly among networks repeat a request on a succession of databases CD-ROM ACCESS be available from the OPAC main menu CAMPUS DATABASES easy to add databases identified as available INTERNET be directly available from the network module

NETWORK ACCESS INTERFACES TO EXTERNAL ENVIRONMENTS interface with the Institutional Computing System interface with libraries of the State access from other libraries within the State access to the Internet accommodate "World-Wide Web"
THE END

Systems Analysis For Library Management

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Systems Analysis For Library Management

Uploaded by

Copyright:

Available Formats

Systems Analysis for Library Management

Mahfoz Hossain University of Dhaka 2014

Module 0. Summary & Overview

Module 1. Conceptual Framework

Contexts for Library Systems Analysis

Methods for Dealing with such Tasks

Module 2. Supporting Software

Supporting Software Tools

Computer Aided Analysis Methods

The Library Planning Model

Module 3. Structure of Systems Analysis

Information System Schematic

Steps in Systems Analysis

Stages in Systems Analysis

(1) Analyze Feasibility

(2) Specify Requirements

(3) Detailed Design

(4) Develop Software (5) Develop Procedures (6) Functional Test

(7) Install & Implement (8) Monitor & Maintain

Monitor Operations Maintain Hardware, Software, Procedures

Module 4. Objectives & Requirements

Contexts for Determining Requirements

Sources for Data on Past Operations

Examples and components

Publications, national databases

External, Informal Exchanges with colleagues

Examples and components

Statistics Survey Instruments

Use Logs Time & Motion Study

Examples and components

Module 5. Methods for Analysis

The Evolutionary Approach

The Revolutionary Approach

Approach Adopted in this Course

Turning first to the Conceptual Approach:

The Role of Methods

The Role of Structure

The Types of Methods

The Foundation for Methods

APPROACHES TO DEVELOPMENT OF DATA STRUCTURES (1)

APPROACHES TO DEVELOPMENT OF DATA STRUCTURES (2)

APPROACHES TO DEVELOPMENT OF DATA STRUCTURES (3)

Data Structures Examples

Normalization in Relational Databases

Illustration of Normalization (1)

Illustration of Normalization (2)

The following slides have been copied from http://www.kenorrinst.com/wo1.htm

Hierarchy for Data Structure

Hierarchy for Processing Structure

Hierarchy is equivalent to Consists of or Is composed of

Repetition example (1)

Repetition example (2)

Repetition example (3)

Recursion (i.e., Repetition)

Lets now turn to the Functional Dimension:

The Functional Dimension

Data Flow Diagrams

Systems Development Data Base

Stage 8 Monitor & Maintain

Stage 7 Implement Install

Stage 6 Functional Test

Stage 5 Develop Procedures

Stage 4 Software Design