Systems Analysis.ppt

Systems Analysis for

Library Management

Robert M. Hayes

2002

Summary of Modules Module 0. Summary & Overview Module 1. Conceptual Framework Module 2. Supporting Software Module 3. Structure of Systems Analysis Module 4. Objectives & Requirements Module 5. Methods for Analysis Module 6. The Library Planning Model Module 7. Requests for Proposal Module 8. Measures of Performance Module 9. Issues in Determining Costs Module 10. Details of RFP

Module 0. Summary & Overview

Summary

Contexts for Library Systems AnalysisMethods for Dealing with such TasksSupporting Software Tools

System SchematicsSteps in Systems AnalysisStages in Systems AnalysisApproaches to Systems Analysis

Summary (cont.)

Definition of ObjectivesDetermination of RequirementsFunctional RequirementsMethods for Analysis

Approaches to System DesignRequests for ProposalAssessment of EffectivenessAssessment of Costs

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

Overview

Module 1. Conceptual Framework

Contexts for Library Systems Analysis

Implement Library AutomationEvaluate a New Library ServiceDetermine Staffing AssignmentsCompare Alternative Means for StorageAdapt to Institutional PrioritiesJustify Budget SubmittalsPlan a New Library BuildingDevelop Inter-Library CooperationSupport National Library Policies

Methods for Dealing with such Tasks

Experience and Intuition

Systems Analysis

HermeneuticsAnalogy

Politics and Negotiation

Trial and Error

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.

AnalogyANALOGY 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 ReportingSpreadsheets, for Data AnalysisDatabase Management, for Data StoragePowerPoint, for Data Presentation

Computer Aided Systems Analysis, for MethodsThe Library Planning Model, for EvaluationProject Managers, for Planning & Control

Computer Aided Analysis Methods

Flow chartingData Flow DiagramsState Transition Diagrams Structure Charts Entity-Relationship Diagrams (ERDs)Data Dictionaries

The Library Planning Model

Represent Workloads in User ServicesRepresent Workloads in Technical ProcessingEstimate Staff Requirements for WorkloadsAccount for Overhead, G&A, and ExpensesDetermine Requirements for FacilitiesAllocate to Means for Storage and/or AccessApply various Models of Library OperationsOptimize Means for Inter-Library CooperationEvaluate Future for Information DistributionAssess National Information Development

Project Management

Establish Work Breakdown StructureDetermine Task Inter-RelationshipsSchedule Sequence of TasksAssign Resources Identify Schedule Conflicts

Module 3. Structure of Systems Analysis

Information System Schematic

Input Communicate Storage

Process

Feedback

Communicate Output

Objectives

Hierarchy of Systems

Information Technologies

Information Sources

Cooperation Context(s)

Political Context(s)

Information Facilities

User Context(s)

Administrative Context(s)

The Library as System of Focus

Sub-System 3 Sub-System 4

Sub-System 1 Sub-System 2

National Policies

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 costsCheck reasonableness of estimatesPrepare summary budget planEstimate current and future costsPrepare cost/effectiveness evaluation

(2) Specify Requirements

Determine detailed requirementsAnalyze contextsDetermine hardware & software needsCompare alternative systemsPrepare performance specsAssure concurrence of policy makers

(3) Detailed Design

Determine specific equipmentDetermine details of activityDetermine 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 Resource Implications

High Performance Resource Exploitation

Frugal Resource Creation

Subsistence Resource Preservation

Boundary Conditions

Issue Boundary Conditions

Funding Available Resources

Staffing Maintain, Reduce, Reallocate?

Equipment A Means or an Objective?

Alternatives Prescribed or Proscribed?

Functional Requirements

Context Requirement

Operating Procedure Formalize

Reporting Identify Formats

ad hoc Procedures Establish Means

ad hoc Requirement Isolated Event?

Political Factors

Context Political Issue

Capital Commitments Reluctant to Change

Administrative Responsibilities

Protect Authority

Professional Perspectives Maintain Commitments

Personal Objectives Hidden Agendas

Contexts for Determining Requirements

Past ExperiencePresent OperationsFuture Operations

Sources for Data on Past Operations

Specifics Examples and componentsInternal, Informal Memos, ad hoc reports,personal

databases

Internal, Formal Reports, database files, procedures manuals, documentation, organization charts

External, Formal Publications, national databases

External, Informal Exchanges with colleagues

Present Operations

Specifics Examples and components

Walk-Throughs Observe forms and documents, procedures, individual persons

Statistics Transactions, files, reports

Survey Instruments Questionnaires, Interviews, Surveys

Use Logs Monitoring online operations,

recording transactions

Time & Motion Study Close observation, Experiments

Future Operations

Specifics Examples and components

Critical Incident Technique

Specific need, antecedent context, means used, outcome

Delphi Technique Discussion, Questionnaires,

Statistics, commentary, Iteration

Scenarios Teams: Identify Needs,Postulate System, Describe Events, Assess

Project Statistics Time Horizon, Alternative Bases for Projecting

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:

Maintenance of this data base is a central task in conduct of a systems analysis project.

Data

Entity

Function

Entity

Component

Entity

Time

Entity

Parameters

Let’s 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)

Let’s now turn to the Functional Dimension:

The Functional Dimension

Data Input and Output ProcessesData Storage and Retrieval ProcessesComputational ProcessesDecision ProcessesCommunication Processes

Dataflow DiagramsProcess Flow Diagrams (e.g., Flow Charts)State Transition DiagramsProgram Languages

Data Flow DiagramsData 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.

ProjectRequestors

Management

Stage 1

Feasibility

Stage 2

Requirements

Stage 7

ImplementInstall

Stage 5

DevelopProcedures

Stage 4

SoftwareDesign

Stage 3

Detailed Design

Systems Development Data Base

Vendors

Stage 6

Functional Test

Stage 8

Monitor &Maintain

Management ProjectRequestors

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.

Card Deck

Generic Process

Input-Output Process

Decision Process Decision Process

Collate Process

Comment Core

Connector

Diskette

Display

Output Document

Extract Process

Internal Sub-routine

Magnetic Drum

MagneticTape

Manual Input

Manual Operation

Merge Process

Offline Storage

Off-page Connector

Online Storage

Predefined Process

Preparation Process

Punched Card

Punched TapeSort Process

Terminal Process(begin, end)

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, let’s turn to the Components Dimension:

Component Dimension

Personnel ComponentsEquipment Components

Organization ChartsOperational Relationships Charts

Administrative Hierarchy – Centralized

Budget & Accounting

Personnel

Developm ent

Facilities

T raining

M anagem ent Support

Server

External

T erm inals

Hardw are

Cataloging

Circulation

Acquisitions

Softw are

System s

Selection

Acquisition

Receiving

Cataloging

Conservation

T echnical Services

Reference

Circulation

ILL

Reader Services

Central Library

Hum anities

Social Sciences

Physical Science

Biological Science

School of Law

School of M edicine

School of Engineering

Branch Libraries

Library Operations

Library M anagem ent

Administrative Hierarchy – De-Centralized

Central Autom atedBibliographic System

T echnicalServices

ReadersServices

Library

Hum anities Faculty

ReadersServices

T echnicalServices

Library

Social Sciences Faculty

ReadersServices

T echnicalServices

Library

Physical Sciences Faculty

ReadersServices

T echnicalServices

Library

Biological Sciences Faculty

ReadersServices

T echnicalServices

Library

Engineering Faculty

ReadersServices

T echnicalServices

Library

Law Faculty

ReadersServices

T echnicalServices

Library

M edicine Faculty

University Adm inistration

Finally, turning to the inter-relationships among Dimensions:

Inter-relationships among Dimensions

Data – Component Responsibility MatrixFunction – Component Responsibility MatrixFunction – Data Application MatrixData – Time Dataflow DiagramComponent – Time Gantt ChartFunction – Time 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 MatrixExamples

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 ComponentsExample of ILL-related Functions

ILL Borrowing Personnel Component Software Component1 Receive Request 11 Reference2 Check OPAC 11 Reference 12 OPAC Module3 Check Bibliographic 11 Reference 13 OCLC Module4 Request via OCLC 11 Reference 13 OCLC Module5 Select Source 11 Reference 13 OCLC Module6 Establish Record 14 ILL Management 23 ILL Module7 Receive Material 23 Receiving 23 ILL Module8 ILL Manage 14 ILL Management 23 ILL Module9 Circulate to User 12 Circulation 21 Circulation Module

10 Return Material 12 Circulation 21 Circulation Module11 Account for Transaction 14 ILL Management 1 Accounting Module12 Reconcile Accounts 1 Budget & Accounting 1 Accounting Module

Functional Relationships among ComponentsExample of Collection Development Functions

Collection Development Personnel Component Software Component1 Collection Policy 0 Library Management2 Collection Priorities 0 Library Management3 Budget Allocation 1 Budget & Accounting 1 Accounting Module4 Recommendation 11 Reference 21 Acquisitions Module4 Recommendation 30 Branch Libraries 21 Acquisitions Module4 Recommentation 21 Selection 21 Acquisitions Module5 Selection 21 Selection 21 Acquisitions Module6 Ordering 22 Acquisitions 21 Acquisitions Module6 Ordering 22 Acquisitions 1 Accounting Module7 Receiving 23 Receiving 21 Acquisitions Module8 Processing 23 Receiving 12 Circulation Module9 Paying 22 Acquisitions 21 Acquisitions Module9 Paying 22 Acquisitions 1 Accounting Module

10 Cataloging 24 Cataloging 22 Cataloging Module11 Shelving 12 Circulation 12 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 PROJECTEntries are Person-Days per WeekStaff are A# = System Staff and L# = Librarian Staff

STAFF DEC JAN FEB MAR APRACTIVITIES A# L# D1 D2 D3 D4 J1 J2 J3 J4 F1 F2 F3 F4 M1 M2 M3 M4 A1 A2 A3 A4

DATABASE ACTIVITIESOCLC Retrocon Assess 3 3 3 3 3 3 3 3 3 3 3System Convert Asssess 7 7 7 7 7 7Transfer to new System 1 2Transfer OCLC to new system1 2Transfer system to lbys 1 2

TRAINING ACTIVITIESNew Software Mgt Course 5 1 24 24 24New Equipment Mgt Course5 1 24New System Lbn Course 2 12 54 28 54 28 54 21 21 54 21 21 54 21 21 54New System Lbn course 6 30

TECHNICAL ACTIVITIESNew system Tables 2 5 14 14 14 14 14 14 14 New system Language Translation2 5 6 6 6 6 6 6 6 6 6 6 6 Non-bilio file convert 1 3 6 12 6 6 6 Sys Oper Procedures 2 8 8 8 Lby Oper Procedures 12

OTHER ACTIVITIESCurrent Ops Responsibility 5 12 28 25 24 18 17 13 22 7 8 17 3 11Holidays & Vacations 5 12 72 85 85 85 85 85 34 17 17

TOTALS 5 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 PROJECTEntries are Person-Days per WeekStaff are A# = System Staff and L# = Librarian Staff

STAFF MAY JUN JUL AUG SEPACTIVITIES A# L# M1 M2 M3 M4 J1 J2 J3 J4 J1 J2 J3 J4 A1 A2 A3 A4 S1 S2 S3 S4

DATABASE ACTIVITIESOCLC Retrocon Assess 3System Convert Asssess 7Transfer to new System 1 2 12Transfer OCLC to new system1 2 12Transfer system to lbys 1 2 12

TRAINING ACTIVITIESNew Sys Mgt Course 5 1Ne Equipment Mgt Course 5 1New System Lbn Course 2 12 9 21 54 54 42 54 21 21 New System Lbn course 6 30 30 30 30 30 30 30 30

TECHNICAL ACTIVITIESNew system Tables 2 5 7 14 14 14 14 14 New system Language Translation2 5 6 6 6 6 6 6 6 6 6 6 Non-bilio file convert 1 3 6 6 6 6 6 6 6Sys Oper Procedures 2Lby Oper Procedures 12 12 9 12 12 12 12 12 12 12 12

OTHER ACTIVITIESCurrent Ops Responsibility 5 12 46 13 11 7 40 2 53 17 47 55 85 49 78 55 85 55 85Holidays & Vacations 5 12 34 34 1

TOTALS 5 12 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85 85

Turning now to the Pragmatic Approach:

Worksheets for Data GatheringThree 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 DescriptionAdministrative Unit

Building Location Net Sq. Ft.

Purpose: Special Responsibilities: Supervisor (Name & Title) Reports to (Name & Title)

Related Administrative Duties: Special Administrative Duties: Community Served: Units of Work: Remarks: Personnel FTE Costs Workload Unit Costs Function Prof Cler Stu Total Direct Burden Dly Mnly Yrly Workload/Costs Date Analyst

Source Page

Worksheet 2: File Description

File Name

Storage Medium File Number

File Purpose: Who Needs Access: File Location: Sequenced by:

Label:

How Current Retention Period Remarks

Record Chars/Record Records per File Transaction Volume Seq Name Avg Peak Avg Peak Avg Peak

Date Analyst

Source Page

Worksheet 3: Record Description

Record Name

Record Location Record No.

Other Names Used: Related Record Numbers: How Prepared: Operations Involved In: Remarks

Fields Chars/Field Frequency Nature of Data No. Name Avg Peak Per Rec Per File A/N Source

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.

Selection of “Results Menu”Populations Served

(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. Introduction and Summary Section 2. Instructions to Proposers Section 3. Evaluation Of Proposals Section 4. General Requirements Section 5. Installation & Conversion Section 6. Documentation, Training, & Help Section 7. 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 System Records Report Control Records Access Control Records Tables of Definition Records

Acquisitions Acquisition Records Vendor Records Fund Account Records

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

Conservation & Preservation


Required Modules (2)

Cataloging Bibliographic Records Authority Records Cataloging Records Opac Services

Circulation Transaction Record Patron Record Reserve Book Record Accounting Record

Reference Support ILL

Transaction Records Accounting Records

Multi-media Management Title Record Equipment Record Rooms & Facilities

Network Access CD-ROM Access Campus Databases Internet Interfaces to External

Environments

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


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

Other criteria might include 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

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 ImportanceQualitative 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). Let’s 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 Original Cataloging Clerical C1*(0.18*2000/1000) C1*(0.05*2000/1000) Professional C2*(0.02*2000/1000) C2*(1.15*2000/1000)

Let’s 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%:

Mix 1 Mix 2 Mix 3 Cost 1 Cost 2 Cost 3Clerical 3.60 0.10 10 9 7 36.00 32.50 25.50Professional 0.04 33.00 0 1 3 0.40 33.36 99.28 N/T = 10 10 10 C = 36.40 64.86 124.78 CT/N = 3.64 6.49 12.48

How to Measure Information?

Definition of Information as Processing of DataLevels of Data ProcessingMeasures Appropriate to each Level

Microsoft PowerPoint

Presentation

Module 9. Issues in Determining Costs

Alternative Means for Cost Assessment

LEVEL

Minimum

Basic

Full Salary

Burdened

MEANS FOR EVALUATION

Time & Motion Study

Direct Labor

Salary & Benefits

All Costs

RULE OF THUMB

RATIOS

(Basic)/(Minimum) = 1.50

(Full Salary)/(Basic) = 1.50

(Burdened)/(Full Salary) = 1.50

WORKLOAD FACTORS FUNCTION PROCESS Prof Cler Stud

Select 0.25 Order 0.20

Acquisition

Invoice 0.20 Original 1.60 Copy 0.20

Cataloging

Maintain 0.25 Charge 0.03 0.03 Circulation Shelving 0.02 Receiving 0.10 Serials Records 0.10 Receiving 0.02 Physical Handling Labeling 0.06 BibID 0.20 Handling 0.10

ILL Borrow

Records 0.20 BibID 0.05 Handling 0.10

ILL Lending

Records 0.20 Reference 0.25 0.25 TOTAL Direct FTE

Workload Factors for Estimating Direct FTEFTE per 1000 Transactions

Workload FactorsRelation 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 Timeper item in a batch as a function of (Batch Size)

log(Seconds per Item) = 0.25 + 0.25*log(Batch Size)

0.00

0.50

1.00

1.50

2.00

2.50

0 1 2 3 4 5 6 7

log(Batch Size)

log(

Sec

onds

per

Item

)

High 10 Percentile Average Range Low 10 Percentile

Filing Timeper item in a batch as a function of (File Size)/(Batch Size)

log(Seconds per Item) = 0.75 + 0.25*log(FileSize/BatchSize)

0.00

0.50

1.00

1.50

2.00

2.50

3.00

0 1 2 3 4 5 6 7

log(FileSize/BatchSize)

log(

Sec

onds

per

Item

in B

atch

)

High 10 Percentile Average Range Low 10 Percentile

Full Time Equivalent (FTE) FUNCTION PROCESS Workload Prof Cler Stud Total

Select 30 K titles 7.57 7.57 Order 20K orders 4.04 4.04

Acquisition

Invoice 20 K orders 4.04 4.04 Original 4 K titles 6.15 8.15 Copy 26 K titles 5.29 5.29

Cataloging

Maintain 30 K titles 7.57 7.57 Charge 846 K circs 25.37 25.37 50.73 Circulation Shelving 2537K shelves 50.73 50.73 Receiving 30 K titles 3.03 3.03 Serials Records 30 K titles 3.03 3.03 Receiving 91 K items 1.82 1.82 Physical

Handling Labeling 91 K items 5.45 5.45 BibID 12 K borrows 2.42 2.42 Handling 12 K borrows 1.21 1.21

ILL Borrow

Records 12 K borrows 2.42 2.42 BibID 29 K lends 1.46 1.46 Handling 29 K lends 2.91 2.91

ILL Lending

Records 29 K lends 5.82 5.82 Reference 137 K hours 34.22 68.44 TOTAL Direct FTE

51.82

97.25

85.07

234.1

3

Illustrative Application of Workload Factors

Alternatives for Overhead Allocation

Category Percent

of Total

Non-Profit

Allocation

Industry

Allocation

Total Salaries

Direct Salaries

Indirect Salaries

Salary Benefits

Overhead Expenses

Sub-Total

G & A

Total

1.00T

0.67T

0.33T

0.14T

0.20T

1.00T

0.14T

0.20T

1.34T

0.13T

1.47T

0.67T = 1.00D

0.67T = 1.00D

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

Section 2. Instructions to Proposers (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 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 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

Section 4. General Requirements (2)

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 MICRO-

ISIS• 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

Section 9. Specifications for Required Modules (1)

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


• 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



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

Documents

Systems Analysis.ppt