Post on 22-Dec-2015
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.
APPROACHES TO DEVELOPMENT OF DATA STRUCTURES (2)
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.
APPROACHES TO DEVELOPMENT OF DATA STRUCTURES (3)
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)
Repetition example (2)
Repetition example (3)
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
Section 9. Specifications for
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
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
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
Section 2. Instructions to Proposers (2)
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
Section 2. Instructions to Proposers (3)
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
Section 2. Instructions to Proposers (4)
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
Section 2. Instructions to Proposers (5)
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
Section 2. Instructions to Proposers (6)
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
Section 2. Instructions to Proposers (8) 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
Section 2. Instructions to Proposers (9) 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
Section 3. Evaluation Of Proposals (2)
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
Section 3. Evaluation Of Proposals (3)
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 \
Section 4. General Requirements (3)
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
Section 4. General Requirements (4)
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
Section 4. General Requirements (5)
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
Section 6. Documentation, Training, Help (2)
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
Section 6. Documentation, Training, Help (3)
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
Section 9. Specifications for Required Modules (2)
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.
Section 9. Specifications for Required Modules (3)
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
Section 9. Specifications for Required Modules (4)
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
Section 9. Specifications for Required Modules (5)
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
Section 9. Specifications for Required Modules (6)
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
Section 9. Specifications for Required Modules (7)
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
Section 9. Specifications for Required Modules (8)
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
Section 9. Specifications for Required Modules (9)
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
Section 9. Specifications for Required Modules (10)
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
Section 9. Specifications for Required Modules (11)
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
Section 9. Specifications for Required Modules (12)
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
Section 9. Specifications for Required Modules (13)
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
Section 9. Specifications for Required Modules (14)
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
Section 9. Specifications for Required Modules (15)
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
Section 9. Specifications for Required Modules (16)
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
Section 9. Specifications for Required Modules (17)
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
Section 9. Specifications for Required Modules (18)
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
Section 9. Specifications for Required Modules (19)
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
Section 9. Specifications for Required Modules (20)
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
Section 9. Specifications for Required Modules (21)
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
Section 9. Specifications for Required Modules (22)
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
Section 9. Specifications for Required Modules (23)
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
Section 9. Specifications for Required Modules (24)
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
Section 9. Specifications for Required Modules (25)
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
Section 9. Specifications for Required Modules (26)
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
Section 9. Specifications for Required Modules (27)
REFERENCE SUPPORT tools to support reference in use of the system interface with all other modules readily exchange data with each of them
Section 9. Specifications for Required Modules (28)
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
Section 9. Specifications for Required Modules (29)
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
Section 9. Specifications for Required Modules (30)
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
Section 9. Specifications for Required Modules (31)
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
Section 9. Specifications for Required Modules (32)
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
Section 9. Specifications for Required Modules (32)
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