Systems Analysis (2)

Systems Analysis for Library Management

Summary of ModulesModule 0. Summary & OverviewModule 1. Conceptual FrameworkModule 2. Supporting SoftwareModule 3. Structure of Systems AnalysisModule 4. Objectives & RequirementsModule 5. Methods for AnalysisModule 6. The Library Planning ModelModule 7. Requests for ProposalModule 8. Measures of PerformanceModule 9. Issues in Determining CostsModule 10. Details of RFP

Module 0. Summary & Overview

SummaryContexts 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

Overview

Module 1. Conceptual Framework

Contexts for Library Systems AnalysisImplement 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 TasksExperience and IntuitionSystems Analysis

Hermeneutics

Analogy

Politics and Negotiation

Trial and Error

Systems AnalysisSYSTEMS ANALYSIS is derived from scientific and mathematical tradition. It attempts to understand a phenomenon which it calls a system by breaking it into successively more detailed component parts the process of analysis until the parts can be understood in themselves, without further stages of analysis.The great strength of systems analysis is its ability to deal with exceptionally complex phenomena and to provide means for dealing with them, especially for pragmatic purposes.The great deficiency of systems analysis is inherent in the very process of analysis: The approach to analysis predetermines the final picture of the phenomenon; the phenomenon as a whole may be destroyed; and essential inter-relationships among component parts may be lost.Of course, the methodology can in principle compensate for the deficiency by providing means to reconstruct relationships and to identify larger contexts.

Hermeneutics

HERMENEUTICS is derived from theological and philosophical tradition. Originally, it was a methodology for Interpretation, especially of scriptural text. It attempts to understand a phenomenon by identifying its relationships to other phenomena, ultimately encompassing the entire universe.

The great strength of hermeneutics is its emphasis on inter-relationships and the resulting ability to interpret interactions and to see the effects on the whole.

The great deficiency of hermeneutics is that it provides no means to delve into the structure of a phenomenon or to set boundaries on the scope of inter-relationships to be considered. Inevitably, it thus must encompass the universe.

Of course, the methodology can in principle compensate for the deficiency by incorporating some methods of analysis and by setting boundaries on the scope of phenomena to be inter-related.

Analogy

Module 2. Supporting Software

Supporting Software ToolsWord 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 MethodsFlow chartingData Flow DiagramsState Transition Diagrams Structure Charts Entity-Relationship Diagrams (ERDs)Data Dictionaries

The Library Planning ModelRepresent 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 ManagementEstablish Work Breakdown StructureDetermine Task Inter-RelationshipsSchedule Sequence of TasksAssign ResourcesIdentify Schedule Conflicts

Module 3. Structure of Systems Analysis

Information System Schematic

Input

CommunicateStorage

Process

Feedback

Communicate

Output

Objectives

Hierarchy of SystemsInformation TechnologiesInformation SourcesCooperation Context(s)Political Context(s)Information FacilitiesUser Context(s)Administrative Context(s)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 TestProduce software specifications Review and evaluate available software Analyze make-or-buy

Develop Procedures

Functional Test

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

Install HardwareInstall SoftwarePrepare DocumentationTrain StaffConvert Data FilesConvert OperationsOrient Users

Monitor OperationsMaintain Hardware, Software, Procedures

Module 4. Objectives & Requirements

Definition of Objectives MANAGEMENT OBJECTIVESStrategic and Contextual ObjectivesTactical ObjectivesOperational Objectives TECHNICAL OBJECTIVESFunctional RequirementsPerformance RequirementsCost & Budget Requirements POLITICAL OBJECTIVESAdministrative ResponsibilitiesProfessional ConcernsCapital CommitmentsPersonal Perspectives & Goals

Determination of Requirements

Performance Expectations Boundary ConditionsFunctional RequirementsPolitical Factors

Performance Expectations

Level of PerformanceResource ImplicationsHigh PerformanceResource ExploitationFrugalResource CreationSubsistenceResource Preservation

Boundary Conditions

IssueBoundary ConditionsFundingAvailable ResourcesStaffingMaintain, Reduce, Reallocate?EquipmentA Means or an Objective?AlternativesPrescribed or Proscribed?

Functional Requirements

ContextRequirementOperating ProcedureFormalizeReporting Identify Formatsad hoc ProceduresEstablish Meansad hoc RequirementIsolated Event?

Political Factors

ContextPolitical IssueCapital CommitmentsReluctant to Change Administrative Responsibilities Protect Authority Professional Perspectives Maintain Commitments Personal ObjectivesHidden Agendas

Contexts for Determining Requirements

Past ExperiencePresent OperationsFuture Operations

Sources for Data on Past Operations

SpecificsExamples and componentsInternal, InformalMemos, ad hoc reports,personal databasesInternal, Formal Reports, database files, procedures manuals, documentation, organization chartsExternal, Formal Publications, national databases External, Informal Exchanges with colleagues

Present Operations

SpecificsExamples and componentsWalk-ThroughsObserve forms and documents, procedures, individual personsStatisticsTransactions, files, reportsSurvey Instruments Questionnaires, Interviews, Surveys Use LogsMonitoring online operations,recording transactions Time & Motion StudyClose observation, Experiments

Future Operations

SpecificsExamples and componentsCritical Incident TechniqueSpecific need, antecedent context, means used, outcomeDelphi Technique Discussion, Questionnaires,Statistics, commentary, IterationScenariosTeams: Identify Needs,Postulate System, Describe Events, Assess Project StatisticsTime Horizon, Alternative Bases for Projecting

Module 5. Methods for Analysis

Alternative ApproachesEvolution from Current OperationsMaintains consistency in operationsBuilds upon data from actual experienceTends to perpetuate existing assumptions and deficienciesDetermination of Objectives in terms of User NeedsAims to avoid pre-existing assumptionsBuilds upon studies of users and their needsIs difficult to identify what are real objectivesRevolution to a Brave New WorldLooks to an ideal systemBuilds upon models and hypothetical dataTends to create its own assumptions and deficiencies

Alternative ApproachesThere 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 ApproachUnderlying 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 ApproachUnderlying 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 ApproachThese 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 MethodsThe 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 AnalysisUnderlying all of the methods are four dimensions:DataEntities & RelationshipsRecords & FieldsFunctionsProcessesDecisionsComponentsPeopleEquipmentTimeSequenceEvents

The Role of StructureIn 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 MethodsThe 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 MethodsUnderlying 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 dimensionA relationship among entities across dimensionsThe 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 EntityFunctionEntityComponentEntityTime EntityParameters

Lets first look at the Data Dimension, since it is the foundation for everything:

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

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 StructuresData DictionaryMeaning of Data ElementComposition of Complex Data ElementAcceptable Values for Data ElementAlternative Values for Data ElementEntity and related PropertiesKey FieldOther Required FieldsOptional FieldsIteration of Fields (zero or more)Objects: Types and Sub-Types of EntitiesShared PropertiesDistinct 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: NameAlternatives: Corporate, Individual Structure: (Name), ((Title), First, (Middle), Last),Value: (Alpha-Numeric), (Alphabetic)Data element: Customer IDValue: (Numeric)Data Element: AddressStructure: (Street, City, State, Mail Code, Country)Alternatives: (Home Address), (Business Address)Data Element: Customer RecordKey Field: Customer IDRequired Fields: Name, AddressOptional Fields: Alternative Address(es)

RelationshipsA Relationship is an operational connection among two or more ObjectsFor 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 RepresentativeOrder formA Form (such as an Order Form) embodies a Relationship and contains Fields identifying the Objects (as shown above)

Normalization in Relational DatabasesProblems 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 DiagramsThe Warnier-Orr technique uses graphical displays that combine brackets, circular arrows, vertical arrows, numbers (N), and plus signs (+) to portray activities or data elements and the relationships among them. The Warnier-Orr technique as applied to description of data elements starts with the system outputs, including reports, forms, and files, perhaps using means similar to the Worksheets 2 & 3 (to be presented later). Each of them is decomposed into data elements.

Hierarchies are identified (for example, as involved in sub-fields of a MARC record) and schematically shown by brackets that enclose data elements supporting or involved in the label to the left of the bracket. Options for data elements, sequences of them, or repetition of them are then shown by the appropriate symbol.

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

Hierarchy

Hierarchy for Data Structure

Hierarchy for Processing Structure

Hierarchy is equivalent to Consists of or Is composed of

Sequence

Sequence example

Repetition

Repetition example (1)

Alternation shown by

Alternation Example

Concurrency example

Recursion (i.e., Repetition)

Lets now turn to the Functional Dimension:

The Functional Dimension

Data Input and Output 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 focusActual 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.

The focus is on Data Flow, not SequenceIt 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 ConventionsVarious 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 ChartingFlow 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.

Flowcharting of Systems Analysis StagesThe 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 DiagramsState transition diagrams are probably the most esoteric of the means for picturing operations in a system, since they are based on the most theoretical concepts of what are called finite state machines.They focus on very specific components of the system entities, such as machines but also parts of the symbolic structure of the system.The entity is pictured as receiving events from the outside world, and each event potentially as causing a transition of the entity from one state to another. State models require identifying each of the possible state of an entity. Thus, they are ideal for describing the behavior of a single entity but they are not useful for describing behavior that involves several entities.

Now, lets turn to the Components Dimension:

Component DimensionPersonnel ComponentsEquipment Components

Organization ChartsOperational Relationships Charts

Administrative Hierarchy Centralized

Administrative Hierarchy De-Centralized

Finally, turning to the inter-relationships among Dimensions:

Inter-relationships among DimensionsData Component Responsibility MatrixFunction Component Responsibility MatrixFunction Data Application MatrixData Time Dataflow DiagramComponent Time Gantt ChartFunction Time Flow Chart

Component-Function Responsibility MatrixThe 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 MatrixExamplesThe 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

Sheet1

ILL BorrowingPersonnel ComponentSoftware Component

1Receive Request11Reference

2Check OPAC11Reference12OPAC Module

3Check Bibliographic11Reference13OCLC Module

4Request via OCLC11Reference13OCLC Module

5Select Source11Reference13OCLC Module

6Establish Record14ILL Management23ILL Module

7Receive Material23Receiving23ILL Module

8ILL Manage14ILL Management23ILL Module

9Circulate to User12Circulation21Circulation Module

10Return Material12Circulation21Circulation Module

11Account for Transaction14ILL Management1Accounting Module

12Reconcile Accounts1Budget & Accounting1Accounting Module

Sheet2

Sheet3

Functional Relationships among ComponentsExample of Collection Development Functions

Sheet1

Collection DevelopmentPersonnel ComponentSoftware Component

1Collection Policy0Library Management

2Collection Priorities0Library Management

3Budget Allocation1Budget & Accounting1Accounting Module

4Recommendation11Reference21Acquisitions Module

4Recommendation30Branch Libraries21Acquisitions Module

4Recommentation21Selection21Acquisitions Module

5Selection21Selection21Acquisitions Module

6Ordering22Acquisitions21Acquisitions Module

6Ordering22Acquisitions1Accounting Module

7Receiving23Receiving21Acquisitions Module

8Processing23Receiving12Circulation Module

9Paying22Acquisitions21Acquisitions Module

9Paying22Acquisitions1Accounting Module

10Cataloging24Cataloging22Cataloging Module

11Shelving12Circulation12Circulation Module

Sheet2

Sheet3

Gantt ChartA 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 chartsIt includes capabilities for assigning resourcesIt includes capabilities for dealing with calendarsUnfortunately, 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 CapabilitiesThe 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 ScheduleA 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.

Sheet1

MACRO-SCHEDULE: WORKLOAD DISTRIBUTIONS OF SYSTEM STAFF TO ACTIVITIES FOR AUTOMATION PROJECT

Entries are Person-Days per Week

Staff are A# = System Staff and L# = Librarian Staff

STAFFDECJANFEBMARAPR

ACTIVITIESA#L#D1D2D3D4J1J2J3J4F1F2F3F4M1M2M3M4A1A2A3A4

DATABASE ACTIVITIES

OCLC Retrocon Assess33333333333

System Convert Asssess777777

Transfer to new System12

Transfer OCLC to new system12

Transfer system to lbys12

TRAINING ACTIVITIES

New Software Mgt Course51242424

New Equipment Mgt Course5124

New System Lbn Course2125428542854212154212154212154

New System Lbn course630

TECHNICAL ACTIVITIES

New system Tables2514141414141414

New system Language Translation2566666666666

Non-bilio file convert13612666

Sys Oper Procedures2888

Lby Oper Procedures12

OTHER ACTIVITIES

Current Ops Responsibility512282524181713227817311

Holidays & Vacations512728585858585341717

TOTALS5128585858885888588858585858585858585855585

STAFFMAYJUNJULAUGSEP

ACTIVITIESM1M2M3M4J1J2J3J4J1J2J3J4A1A2A3A4S1S2S3S4

DATABASE ACTIVITIES






TRAINING ACTIVITIES

New Sys Mgt Course51

Ne Equipment Mgt Course51









OTHER ACTIVITIES



TOTALS5128585858585858585858585858585858585858585

Sheet2

Sheet3

Sheet1




STAFFDECJANFEBMARAPR

ACTIVITIESA#L#D1D2D3D4J1J2J3J4F1F2F3F4M1M2M3M4A1A2A3A4

DATABASE ACTIVITIES






TRAINING ACTIVITIES

New Software Mgt Course51242424

New Equipment Mgt Course5124









OTHER ACTIVITIES



TOTALS5128585858885888588858585858585858585855585




STAFFMAYJUNJULAUGSEP

ACTIVITIESA#L#M1M2M3M4J1J2J3J4J1J2J3J4A1A2A3A4S1S2S3S4

DATABASE ACTIVITIES






TRAINING ACTIVITIES

New Sys Mgt Course51

Ne Equipment Mgt Course51









OTHER ACTIVITIES



TOTALS5128585858585858585858585858585858585858585

Sheet2

Sheet3

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 Description

Administrative 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 MenuPopulations Served

(1)(2)

Estimation of FacilitiesLPM 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 FacilitiesLPM 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 CabinetSquare feet per microfilm cabinet16 mm reels per Drawer16mm reels per Square Foot16mm reels per Linear Foot35 mm reels per Drawer35mm reels per Square Foot35mm per Linear FootMicrofiche, Items/DrawerMicrofiche, Square feet/DrawerArchives, linear feet/square footAV & Electronic, Items per Linear FootAV & Electronic, Items per Square FootBound Materials per Linear FootBound Materials per Square Foot17111352092080124102,5001315301015

Module 7. Requests for Proposal

Request for Proposal(Sections 1 through 7)Section 1. Introduction and SummarySection 2. Instructions to ProposersSection 3. Evaluation Of ProposalsSection 4. General RequirementsSection 5. Installation & ConversionSection 6. Documentation, Training, & HelpSection 7. Maintenance

Request for Proposal(Sections 8 through 11, Appendices 1 through 3)Section 8. Benchmark & Acceptance TestingSection 9. Specifications For Required ModulesSection 10. Desired Optional ModulesSection 11. Specifications For HardwareAppendix 1. The InstitutionAppendix 2. Computing & Telecommunications Appendix 3. Requirements For External Interfaces

Section 2. Instructions to Proposers

Summary of Proposed SolutionStatus of Development & Implementation The Substantive Proposal Sub-SectionSoftware for Essential ModulesSoftware for Desired ModulesHardware

The System Support Sub- SectionThe Proposer Qualifications Sub- Section The Cost & Contract Sub- Section

Section 3. Evaluation Of ProposalsHardware & Software PerformanceCapability to Deliver Support ServicesTime ScheduleContractual ProvisionsCostOther CriteriaEvaluation Process

Section 4. General RequirementsSystem StructureControl of AccessWorkloads & Response TimesLanguages of OperationSystems RequirementsSystem Availability & ReliabilityOperation of TerminalsSoftware & Hardware EnhancementRights to Use of Software

Section 5. Installation & ConversionInstallationConversion & Migration of DataConversion of Procedures & Operations

Section 6. Documentation, Training, HelpDocumentationTraining of Institution StaffHelp SupportEducation of Users & Assistance to Users

Section 7. MaintenanceStaff Policies of the ProposerHardware MaintenanceSoftware Maintenance

Section 9. Specifications for Required Modules (1)Library System ManagementSystem RecordsReport Control RecordsAccess Control RecordsTables of Definition RecordsAcquisitionsAcquisition RecordsVendor RecordsFund Account RecordsSerialsSerials Subscription RecordsSerials Holdings RecordsMaterials ManagementReceiving & ProcessingInventory ControlBindingConservation & Preservation

Section 9. Specifications for Required Modules (2)CatalogingBibliographic RecordsAuthority RecordsCataloging RecordsOpac ServicesCirculationTransaction RecordPatron RecordReserve Book RecordAccounting RecordReference SupportILL Transaction RecordsAccounting Records

Multi-media ManagementTitle RecordEquipment RecordRooms & FacilitiesNetwork AccessCD-ROM AccessCampus DatabasesInternetInterfaces to External Environments

Section 10. Desired Optional ModulesE-mailPublishingArticle RecordJournal RecordSubscription RecordSelective Dissemination of InformationTables of Contents AccessSource RecordPatron Record

Section 11. Specifications for HardwareCurrent EquipmentCentral & Faculty Library ServersDatabase StorageTerminals

AppendicesThe 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 AssessmentIt 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 JustifiabilityFor 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 justifiableFlexibility in Representing Actual Needs by SpecificationsThe 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 AssessmentThe 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 AssessmentThe 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 servicescontractual provisions cost Other criteria might includequality 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 AssessmentThe primary source of data to be used in assessment should the proposal itself.Beyond it, though, other sources might include:other documentation from the proposerdata from other users of the systemrecords 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). Lets see what that looks like:

MEANS TO INCORPORATE QUALITATIVE ISSUES (2)The following matrix represents costs by the labor costs per hour for two levels of staff by (C1 and C2) and the workload factors are the default values used in The Library Planning Model:

Copy Cataloging Original Cataloging Clerical C1*(0.18*2000/1000) C1*(0.05*2000/1000) Professional C2*(0.02*2000/1000) C2*(1.15*2000/1000)

Lets take C1 as $8/hour and C2 at $16 per hour, and consider three different mixes of the two levels of quality with copy cataloging at 100%, 90%, and 70%:

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

The Measurement of Information

Robert M. Hayes

Summary

This presentation will provide a set of measures for information, including one (the Shannon measure) that is well established and of proven value in the design of communication systems. But it will also provide other, speculative measures for potential application in more complex information systems.Before presenting those measures, though, it is of value to discuss some terminology.

EXISTING USES OF TERMS

It must be said that the term information and a number of related terms carry a lot of intellectual baggage. They are in colloquial use, many of them in ambiguous, overlapping ways. Beyond the colloquial uses, though, are the even more complex roles of these terms in philosophy for the past many millennia.In a moment, I will present a schematic to show the relationships among terms as I use them and, thus, as they will be used in this presentation.But before doing so, simply to illustrate the complexities, the following presents the enumeration by one person of an array of meanings for the term information

Belkin's Range of Information Concepts

part of human cognitionsomething produced by a generatorsomething that affects a usersomething that is requested or desiredthe basis for purposeful social communicationa commoditya processa state of knowingsemantic content

Schematic of Relationships among Terms

The following schematic shows the relationships among relevant terms as I use them.Thus, Facts are represented by Data.Data are processed to produce Information.Information is communicated. leading to Understanding.Understanding is integrated together to becomes KnowledgeKnowledge is used to make Decisions.

Fact Data Information Understanding Knowledge Decisions \ / \ / \ / \ / \ / Represent Process Communicate Integrate Use \/ \/ EXTERNAL TO RECIPIENT INTERNAL TO RECIPIENT

For a discussion of the philosophical background for these terms and concepts, click on the title page shown below.

Definition of Information as a Result of Data Processing

Information is that property of data (i.e., recorded symbols) which represents (and measures) effects of processing of them.

Levels of Data Processing

Data Transfer (e.g., communication by the telephone)

Data Selection (e.g., retrieval from a file)

Data Analysis (e.g., sequencing and formatting)

Data Reduction (e.g., replacement of data by a surrogate)

What is Data Transfer?

The simplest level of processing is data transfer or data transmission. If a sheet of paper containing data is given to someone or if those same data are copied to another medium or sent through a telephone line, the process is that of data transfer. In either event, the recipient has received some level of information as a result of that process even though nothing more may have been done to the data. Data transfer is measured by the only recognized measure of information. It is that developed by Claude Shannon and used in "information theory" (for which read communication theory). It measures the amount of information (but not its value) by the statistical properties of the signals transmitted.

Measurement of Information for Data Transfer

Let X = (x1, x2,...,xM) be a set of signals. Let pi = p(xi) be the a priori probability that signal xi is transferred. Let ni = log(1/pi).

Then, the amount of information conveyed by signal xi is given by H(xi) = - log(pi) = log(1/pi) = ni

For the set of signals X = (x1, x2,...,xM):

H(X) = - pi*log(pi) = pi*log(1/pi) = pi*ni

An Interpretation of ni

The value ni can be interpreted as the average number of binary decisions required to search a file containing the semantic significance of signals. It thus has a role in determining the magnitude of the task involved in dealing with and responding to signals as they are received. In particular, it measures the size of the files required to store the semantic meaning of signals and the times required to search for and retrieve those meanings.To illustrate, if all signals are equally likely, pi = 1/N, where N is the total number of signals and thus the size of the semantic file. Hence, ni = log(1/pi) = log(N), which is the number of binary decisions in search of that file.

What is Data Selection?

The second level of processing, data selection, is best illustrated by operation of a computer database search in which records "relevant to" a request are identified and retrieved from the files. Note that this process is expected to include data transmission but it also includes much more, since the recipient will receive information as a result of the process of selection, but the amount of information clearly depends upon the degree to which the process of selection indeed identifies "relevant" materials. (For this discussion, the meaning of the term "relevant" will be taken as a primitive, to be interpreted as may be appropriate to specific contexts. )

Measurement of Information for Data Selection

Let X = (x1, x2,...,xM) be a set of signals. Let pi = p(xi) be the a priori probability that signal xi is transferred. Let ni = log(1/pi).Let ri = r(xi) measure the importance of the signal. Such a measure of importance can be illustrated by "relevancy", in the sense in which that term is used in retrieval systems.The weighted entropy measure for a given signal is given by:

S(xi) = ri*log(1/pi) = ri*ni

For the set of signals X = (x1, x2,...,xM):

S(X) = ri*pi*log(1/pi) = ri*pi*ni

What is Data Analysis?

The third level of processing, data analysis, is best illustrated by placing data into a format or structure. As a result of that process, the recipient receives information not only from the transmitted data or selected data but from relationships shown in the structure in which they are presented. The sentence "man bites dog" thus is meaningful both because of the data and the "subject-verb-object" syntax of the sentence. In the context of an information retrieval system, data analysis might be illustrated by sequencing of selected records according to some criterion (by order of relevance, chronologically by date, or alphabetically by author, as examples). In a database system, it is represented by the creation of matrices, tables, and relationships as means for organization of the data. In an interactive computer system, it is represented by the formats of displays.Note that, in each case, the information is conveyed by both a semantic component and a syntactic one (in the format).

The Definition for Semantic Information

Let the source signal be N bits in length (so that we have 2N symbols). Divide it into F fields of lengths (n1, n2,...,nF) bits, averaging N/F. First, suppose that all values for a given field have equal probability. Instead of looking among 2N entries, we need look only among the sum of the (2ni). The logarithm of that sum will be called semantic information, since it is that part of the total symbol that involves table look-up, conveying meaning, with the remainder being "syntactic information, conveyed by the structure. Note that, as F increases (N being held constant) the amount of semantic information rapidly decreases, and the syntactic information increases.

If the values in a given field have unequal probabilities, their probabilities will again play the same role they do in the Shannon measure.

Illustrative Example

Consider a symbol set that is used to identify people. Each of 16 persons could be uniquely identified by a four-bit array; one would need to have a table with 16 entries in order to determine which person was represented by a given four-bit code. But now, let's impose a structure on that code: (Male/Female),(Young/Old),(Rich/Poor),(Urban/Rural)Suddenly, instead of needing to recognize 16 different things, we need recognize only 8 different things, the combination of which gives us the full set of 16. Receiving a signal, say 0110, we can identify the category as "male, old, poor, urban"; we have looked at four tables of just two entries each, yet we have identified one from 16 categories. The logarithm of the size of the set of tables required to interpret the signal is then a measure of the semantic information.

Measurement of Information for Information Organization

Consider a record of F fields. Associate with each possible value in each field an a priori probability; thus for field j and value jji, there is a probability p(jji), where for each j, i (p(jji)) = 1. A given signal is then the combination of a specific set of values, one for each field. The probability of the particular combination, assuming independence, is then the product of the p(jji), and the amount of information conveyed by the signal is the logarithm of that product. That TOTAL amount of information, however, is more than just the signal, since the structure conveys information as well. The total, for signal (jj1, jj2,, jjM), therefore is divided between semantic and syntactic as follows: Semantic Information Syntactic Information

F F F log( 1/p(jji)) log(1/p(jji)) - log( 1/p( jji)) j=1 j=1 j=1

The Size of the Semantic Files

To show the effect of the number of fields, consider a signal of 64 bits. The total number of signals is huge (i.e., 264 which is greater than 1019), as is the size of the file required to translate each possible signal.The following graph shows the extent to which information is transferred from semantic to syntactic as the number of fields is increased. The result is a dramatic decrease in the size of the semantic files.Note that the big transfer of information from semantic to syntactic occurs in going from one field (i.e., the signal being treated as a whole) to two fields. In this case, the size of semantic files is reduced from 264 to 8.6*232 (about 8.6 trillion entries). Four fields reduces the size of semantic files to 4*216 which is just 262,144 entries.

Chart1

064

3133

4618

5311

568

577

577

Syntactic

Semantic

Number of (Equal-Sized) Fields

Distribution of Information

For a Record of 64 Bits Total

Sheet1

064164

31332

46184

53118

56816

57732

57764

Sheet1

Syntactic

Semantic

Number of (Equal-Sized) Fields

Distribution of Information

For a Record of 64 Bits Total

Sheet2

Sheet3

Sheet1

Number of Fields1248163264

Size of Files1.8*10198.6*10 9262,1442,048256128128

Sheet2

Sheet3

What is Data Reduction?

The fourth level of processing, data reduction, is best illustrated by the replacement of large collections of data by equations. For example, linear regression analysis of a set of say 1000 two-dimensional data points replaces 2000 values by two values (the parameters of the linear regression line). The result is information derived both from the process of reduction and from the effective replacement of massive amounts of data by a few parameters. It can be exemplified by curve fitting, factor analysis, clustering and similar means for reducing large amounts of data to a very limited set of parameters. In general these mathematical processes can be considered as transformations of the data, treated as a vector space, into alternative dimensional representations in which the original data have nearly zero values on a large number of the transformed dimensions.

Measure for Information in Data Reduction?

The potential measures here are still too speculative.

The Characterizing Problems

For each of the four levels of processing, there are characterizing problems:For data transfer, the problem is noiseFor data selection, the problem is uncertaintyFor data analysis, the problem is mismatch between structuresFor data reduction, the problem is loss of precisionThe solution to these problems lies in inter-active communications, in which the source and recipient inter-change their roles with the objective of resolving the problems.Beyond inter-active communication, each process may entail means for avoiding the problems:For data transfer, it is adequate bandwidth and redundancyFor data selection, it is broadened searchFor data analysis, it is inter-active communicationFpr data reduction, it again is inter-active communication

Module 9. Issues in Determining Costs

Alternative Means for Cost Assessment

LEVEL

MinimumBasicFull SalaryBurdenedMEANS FOR EVALUATIONTime & Motion Study Direct Labor Salary & Benefits All CostsRULE OF THUMB RATIOS(Basic)/(Minimum) = 1.50 (Full Salary)/(Basic) = 1.50 (Burdened)/(Full Salary) = 1.50

Workload Factors for Estimating Direct FTEFTE per 1000 Transactions

WORKLOAD FACTORS

FUNCTION

PROCESS

Prof

Cler

Stud

Acquisition

Select

0.25

Order

0.20

Invoice

0.20

Cataloging

Original

1.60

Copy

0.20

Maintain

0.25

Circulation

Charge

0.03

0.03

Shelving

0.02

Serials

Receiving

0.10

Records

0.10

Physical Handling

Receiving

0.02

Labeling

0.06

ILL Borrow

BibID

0.20

Handling

0.10

Records

0.20

ILL Lending

BibID

0.05

Handling

0.10

Records

0.20

Reference

0.25

0.25

TOTAL Direct FTE

Workload FactorsRelation between FTE per 1000 Transactions andMinutes per TransactionAssume 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 FactorsTime 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)

Chart2

0.30.250.2

0.550.50.45

0.80.750.7

1.0510.95

1.31.251.2

1.551.51.45

1.81.751.7

2.0521.95

High 10 Percentile

Average Range

Low 10 Percentile

log(Batch Size)

log(Seconds per Item)

Sheet1

01234567

0.30.300.550.801.051.301.551.802.05

0.250.250.500.751.001.251.501.752.00

0.20.200.450.700.951.201.451.701.95

Sheet2

Sheet3

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)

Chart2

0.30.250.2

0.550.50.45

0.80.750.7

1.0510.95

1.31.251.2

1.551.51.45

1.81.751.7

2.0521.95

High 10 Percentile

Average Range

Low 10 Percentile

log(Batch Size)

log(Seconds per Item)

Chart3

0.80.750.7

1.0510.95

1.31.251.2

1.551.51.45

1.81.751.7

2.0521.95

2.32.252.2

2.552.52.45

High 10 Percentile

Average Range

Low 10 Percentile

log(FileSize/BatchSize)

log(Seconds per Item in Batch)

Sheet1

01234567

0.80.801.051.301.551.802.052.302.55

0.750.751.001.251.501.752.002.252.50

0.70.700.951.201.451.701.952.202.45

Sheet2

Sheet3

Illustrative Application of Workload Factors

Full Time Equivalent (FTE)

FUNCTION

PROCESS

Workload

Prof

Cler

Stud

Total

Acquisition

Select

30 K titles

7.57

7.57

Order

20K orders

4.04

4.04

Invoice

20 K orders

4.04

4.04

Cataloging

Original

4 K titles

6.15

8.15

Copy

26 K titles

5.29

5.29

Maintain

30 K titles

7.57

7.57

Circulation

Charge

846 K circs

25.37

25.37

50.73

Shelving

2537K shelves

50.73

50.73

Serials

Receiving

30 K titles

3.03

3.03

Records

30 K titles

3.03

3.03

Physical Handling

Receiving

91 K items

1.82

1.82

Labeling

91 K items

5.45

5.45

ILL Borrow

BibID

12 K borrows

2.42

2.42

Handling

12 K borrows

1.21

1.21

Records

12 K borrows

2.42

2.42

ILL Lending

BibID

29 K lends

1.46

1.46

Handling

29 K lends

2.91

2.91

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

Alternatives for Overhead Allocation

CategoryPercent of TotalNon-ProfitAllocationIndustryAllocationTotal Salaries

Direct Salaries

Indirect SalariesSalary BenefitsOverhead ExpensesSub-TotalG & ATotal1.00T

0.67T

0.33T0.14T0.20T1.00T

0.14T 0.20T1.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)GENERALsubmit proposal by deadlineidentify as "Proposal in Response to RFP"clearly identify the name of the proposerstipulate proposal is good for 120 daysPROPOSAL STRUCTUREsubmit proposal in five specified sectionssubmit each section in three copiessubmit in three-ring binder

Section 2. Instructions to Proposers (2)PROPOSED SOLUTIONrespond directly to Sections 4, 9, & 10present single best answeravoid presenting multiple strategiesfully respond to requirements, specificationsstate extent to which each requirement is metexplain means for meeting each requirementprovide explanation for any that cannot be metidentify exceptions and related requirementsSubstantive Proposal in specified sequence

Section 2. Instructions to Proposers (3)THE SUBSTANTIVE PROPOSAL: GENERAL REQUIREMENTSaddress general requirementsSOFTWARE FOR ESSENTIAL MODULESfully implemented turnkey software systemaddress specifications from Section 9SOFTWARE FOR DESIRED MODULESidentify desired modules that are includedor specific statement that none is included

Section 2. Instructions to Proposers (4)THE SUBSTANTIVE PROPOSALHARDWAREintegrated turnkey including hardware, etc.identify hardware required to implement systeminclude all equipment necessary for operationidentify differences for essential & optionalalternative hardware platformsdetailed list of the site requirementsdetailed list of electrical, etc. requirementsidentify special conditions or restrictionsdeliver supplies for initial operationlist supplies necessary for initial operationestimate supplies for continued operationprovide specifications for all supplies

Section 2. Instructions to Proposers (5)THE SUBSTANTIVE PROPOSALSTATUS OF DEVELOPMENT & IMPLEMENTATIONdeclare the current status of developmentdeclare status for any alternatives presentedidentify sites for OPTIONAL functionsidentify sites in test and evaluationidentify dates for completion of testingidentify dates for completion of developmentidentified status of planning

Section 2. Instructions to Proposers (6)

THE SUBSTANTIVE PROPOSAL THE SYSTEM SUPPORT SECTIONINSTALLATION & CONVERSION, DATA & PROCEDURESrespond to requirements in Section 5DOCUMENTATION, TRAINING & HELPrespond to requirements in Section 6MAINTENANCE & SUPPORTrespond to requirements in Section 7

Section 2. Instructions to Proposers (7)THE SUBSTANTIVE PROPOSAL THE PROPOSER QUALIFICATIONS SECTIONdata to assess financial and staffingCORPORATE DESCRIPTIONbrief description of the company and parenthistory, description of organization, staffingidentify persons responsible for implementationprovide brief resumes for eachFINANCIAL CONDITIONprovide a copy of financial statementaudit certified by an officer of the companyname, etc. for banking organizationdisclose judgments, litigation, other problemswarrant that no judgment or litigation existsidentify any termination of contractwarrant if there have been no terminations

Section 2. Instructions to Proposers (8)THE SUBSTANTIVE PROPOSAL THE PROPOSER QUALIFICATIONS SECTIONEXPERIENCEidentify customersacademic library of the size of the institutionalprovide data about the size of operationPROPOSED MANAGEMENT PLANdescribe management to provide the systemtime schedule of activities and eventsprovide checkpoints for institutional to review progressidentify activities required of institutional

Section 2. Instructions to Proposers (9)THE SUBSTANTIVE PROPOSAL THE COST & CONTRACT SECTIONCOST PROPOSALitemized list of initial & continuing costscosts as unit prices extended to required unitsidentify costs for the essential modulesidentify costs for desired optional modulesidentify costs for withidentify restrictions on use of the softwareCONTRACT PROPOSALidentify restrictions on use of softwarecompatible with requirements in institutional usestate owner or licensed to provide softwareprovide licenses to run third party softwareprovide access to source code

Section 3. Evaluation Of Proposals (1)CAPABILITY TO DELIVER SUPPORT SERVICESprevious customers as referencesevidence of financial viability and continuityevidence of the means for continuing supportidentify means to provide onsite supportidentify means to recover from failuresidentify means to provide hardware maintenanceidentify hours of support for software

Section 3. Evaluation Of Proposals (2)HARDWARE & SOFTWARE PERFORMANCEidentify extent of meeting each requirementsas necessary identify effects of exceptionsextent of flexibility provided and means for itcompatibility with US -MARCextent to which multiple languages accommodatedmeans to provide interfaces to other networksconformance with accepted standardslimitations on ability to provide reportsstipulate if there are no limitationsidentify statistics that are most valuable

Section 3. Evaluation Of Proposals (3)TIME SCHEDULECONTRACTUAL PROVISIONSCOSTOTHER CRITERIAtraining, documentation, means to instructmeans for training other institutional library staffability to adapt to change in technologiesability to serve added requirementsEVALUATION PROCESS

Section 4. General Requirements (1)SYSTEM STRUCTUREintegrated database covering all collectionsviewing whole collection or faculty libraryswitch between one view and the othermodular, with easy modification or replacementCONTROL OF ACCESScontrol of access by different categoriesbasis for access, centrally and at librariesSUPPORT TO LIBRARY & SYSTEM MANAGEMENTinformation for library and system managementinformation for management of operationsmanagement of the systemdetection and prevention of system failuressupport library and system management centrallylibrary & system management at faculty library

Section 4. General Requirements (2)WORKLOADS & RESPONSE TIMESresponse times rapid enoughreplacement values with explanation of reasonsextent response time is affected by bandwidthmessage "Transaction in Process" updated 2 secsindicate likely remaining time for processingLANGUAGES OF OPERATIONable fully to operate in multiple languagesoperation in Local Language, Other Language, and Englishmeans for switching languagesadditional Roman alphabet languages\

Section 4. General Requirements (3)SYSTEMS REQUIREMENTSGENERALsoftware is vendor independentsoftware can be moved to various computerscan be output & transport data to other systemsmeans to export and import US -MARC datameans to export and import data in MICRO-ISISmeans to export and import data in UNIMARCmeans for import of data for other filesfully UNIX compatibleconsistent with a client/server operation

Section 4. General Requirements (4)SYSTEMS REQUIREMENTSSYSTEM AVAILABILITY & RELIABILITYregularly scheduled downtimehours for scheduled downtimepercent time fully functionalfunction in a partially connected networkprocedures for backup of data filesprocedures for fail-safe operationprocedures for operations when system is downschedule of backup to minimize effectsOPERATION OF TERMINALStext-based & graphical user interface operationsupport both PC and Mac terminalssupport menu driven & command driven operation

Section 4. General Requirements (5)SYSTEMS REQUIREMENTSSOFTWARE & HARDWARE ENHANCEMENTmeans for software and hardware enhancementtraining support for new or enhanced featuresrequirements to effectively run improvementsRIGHTS TO USE OF SOFTWAREguarantee right to use of all software

Section 5. Installation & Conversion (1)INSTALLATIONdetailed plan for installation of the systemevents: hardware, software, conversionpercentage of records to be convertedplan for phasing into full-scale operationinstitutional proposed phasing acceptable to the proposerinstitutional proposed plans for conversion and migrationnumber of records for effective operationalternatives for conversion and of datacurrent system in parallel with the new systemschedule for transition from one to the other

Section 5. Installation & Conversion (2)CONVERSION & MIGRATION OF DATAderive database from existing system & US-MARC recordsderive authority files from existing systemscenario of conversion processviews of the most for accomplishing theCONVERSION OF PROCEDURES & OPERATIONSmanuals for procedures in use of the systemexperience in prior conversions

Section 6. Documentation, Training, Help (1) DOCUMENTATIONdocumentation sufficiently completedeliver full documentation for the hardwareprovided in English and in Local Languagedocumentation provided by the training timeinstructions for solving standard problemsindexes in both Local Language and Englishoperator manuals for hardware and softwareprovided in both Local Language and Englishupdates during the contract to reflect changesonline help for elements of documentationonline help in Local Language, English, and Other Language

Section 6. Documentation, Training, Help (2) TRAINING OF institutional STAFFprovide a program of training for institutional stafftraining services for various levels of staffcontent of training programsmeans used for instructionthe schedule and length for training sessionslevels of staff and management each trainingresources and facilities for training sessionslanguage of instructionmeans for trainees fluent only in Local Languagecopies of training manuals includedqualifications that institutional staff to train othersmeans they will use for instructionmeans for training in an operating environment

Section 6. Documentation, Training, Help (3) HELP SUPPORTcontext sensitive help screens for userstutorial support for untrained usersspecific help if the system sees a problemhypertext capabilityhelp screens to untrained user needsavailable in Local Language, English, Other LanguageEDUCATION OF USERS, ASSISTANCE TO USERSadvice concerning best means for user educationsample materials as an appendix to the proposal

Section 7. Maintenance (1)STAFF POLICIES OF THE PROPOSERpolicies affecting the staff commit of timeHARDWARE MAINTENANCEprocedures for obtaining support for hardwareappropriate inventory of parts to be stockedtest equipment to be included on siteprocedures for obtaining support at the sitemaximum time delay for field support staffcosts for alternative delay timessupport at sites other than central processingprocedures for preventive maintenance

Section 7. Maintenance (2)SOFTWARE MAINTENANCEmaintenance of softwareresponsibility for software maintenanceprocedures for upgrading softwarecosts associated with upgradingprocedures for obtaining support for software

Section 8. Benchmark & Acceptance TestingProcedure for acceptance testing

Section 9. Specifications for Required Modules (1)LIBRARY AND SYSTEM MANAGEMENTfunctions for management the systemreporting on system operationreporting for management of the library systemmeans to specify scope of statisticsmeans to specify content of reportsexchange data with all other modulesalternatives by which statistics are acquiredreports both online, printed or to filesoutput in formats for application softwarelevels of access to functions and datameans for specifying formats of displays

Section 9. Specifications for Required Modules (2)SYSTEM HARDWARE & SOFTWARE RECORDSrecord for each item of hardware & softwarefields as specified for the recordREPORT CONTROL RECORDSrecord for each report both standard and ad hocfor each new report, for search and accessfields for content, calcs, format, sequencefields for use, frequency, and distributionfields identifying the responsible person, etc.

Section 9. Specifications for Required Modules (3)ACCESS CONTROL RECORDSrecord for each aspect of control of accessbasis for access control & for effecting itlinks to records related to individualsTABLES OF DEFINITION RECORDSrecord for each definition of format of displayfields for the role, current spec, history

Section 9. Specifications for Required Modules (4)ACQUISITIONSselection, ordering, receiving, and accountingreporting support management of acquisitionsconsistent data centrally, at faculty librariesoutput in institutional specified formatstypes of orders used in research librariesvarious conditions of purchasefaculty production, student dissertationsidentify duplicates in the collectionidentify institutional for exchange in acquisition

Section 9. Specifications for Required Modules (5)ACQUISITIONSsupport currency conversionexchange data with all other modulesavailable to the OPAC for display to usersmake OPAC records available to acquisitionsmeans for user to place a request for selectionprovide data to the serials modulemeans for linking to bibliographic utilitiesmeans for linking to book jobbers and databasesmeans to create acquisition record in selection

Section 9. Specifications for Required Modules (6)ACQUISITIONSmeans for checking for potential duplicatesdefaulting in repetitive fieldsconsistency criteria for appropriate fieldsaccounting functions for receipt or claimingchange acquisitions record & OPAC at receiptmeans for processing partial shipmentsgrowth workloads over the five-year period

Section 9. Specifications for Required Modules (7)ACQUISITION RECORDSacquisition record for each item selectedfields as specifiedsearchable and accessible as specifiedVENDOR RECORDSrecord for each vendoreasy means for processing vendor recordsfields as specifiedaccessible as specifiedmanagement of correspondence with vendorsinformation about policies of vendors

Section 9. Specifications for Required Modules (8)FUND ACCOUNT RECORDSfund accounting tracking by institutional criteriatrack amounts budgeted, encumbered, expendedpost fund accounts as items are processedadjust values based on authorized changesprovide full audit trails for all transactionsmeans for institutional to specify format of reportsbe a record for each fund accountmeans for processing of fund account recordsfields as specified

Section 9. Specifications for Required Modules (9)SERIALSmeans of acquiring and controlling seriesexchange data with all other modulessupport all functions in serialsinterface with all other essential modulesreceive data from acquisitions at orderingsend data to OPAC to display of holdingsaccommodate active and total titles

Section 9. Specifications for Required Modules (10)SERIALS SUBSCRIPTION RECORDSrecord for serials with fields as neededSERIALS HOLDINGS RECORDSUS-MARC compatibleANSI standard for Serials Holdings Statementsfields as specified

Section 9. Specifications for Required Modules (11)MATERIALS MANAGEMENTmanage the physical items in the collectiondeal with both separate items and serialsexchange data with all other essential modulesinterface with OPAC for change in statusinterface with circulation missing items

Section 9. Specifications for Required Modules (12)RECEIVING & PROCESSINGcontrol receiving of materialssupport inspection of received itemsprovide means for entry of invoice dataidentify the person for data entrydeal with non-existing recordssupport the physical processing of materials

Section 9. Specifications for Required Modules (13)INVENTORY CONTROLmeans for taking inventory of library materialsmeans for obtaining the identification datarecord the date of most recent

Systems Analysis (2)

Documents

Transcript of Systems Analysis (2)