AlllOt '^7633?

of Commence

National Bureau

of Standards

Computer Science

and Technology

NBs NBS Special Publication 500-100

PUBLICATIONS

Toward an Improved

FIPS Cost-Benefit Methodology,

Phase I: Descriptive ModelsData Processing Operations
NATIONAL BUREAU OF STANDARDS

The National Bureau of Standards' was established by an act of Congress on March 3, 1901. The Bureau's overall goal is to strengthen and advance the Nation's science and technology

and facilitate their effective application for public benefit. To this end, the Bureau conducts

research and provides: (1) a basis for the Nation's physical measurement system, (2) scientific and technological services for industry and government, (3) a technical basis for equity in trade, and (4) technical services to promote public safety. The Bureau's technical work is per- formed by the National Measurement Laboratory, the National Engineering Laboratory, and

the Institute for Computer Sciences and Technology.

THE NATIONAL MEASUREMENT LABORATORY provides the national system of

physical and chemical and materials measurement; coordinates the system with measurement

systems of other nations and furnishes essential services leading to accurate and uniform

physical and chemical measurement throughout the Nation's scientific community, industry,

and commerce; conducts materials research leading to improved methods of measurement,

standards, and data on the properties of materials needed by industry, commerce, educational

institutions, and Government; provides advisory and research services to other Government

agencies; develops, produces, and distributes Standard Reference Materials; and provides

calibration services. The Laboratory consists of the following centers:

Absolute Physical Quantities^ — Radiation Research — Chemical Physics —

Analytical Chemistry — Materials Science

THE NATIONAL ENGINEERING LABORATORY provides technology and technical ser- vices to the public and private sectors to address national needs and to solve national problems; conducts research in engineering and applied science in support of these efforts; builds and maintains competence in the necessary disciplines required to carry out this research and technical service; develops engineering data and measurement capabilities;

provides engineering measurement traceability services; develops test methods and proposes

engineering standards and code changes; develops and proposes new engineering practices;

and develops and improves mechanisms to transfer results of its research to the ultimate user. The Laboratory consists of the following centers:

Applied Mathematics — Electronics and Electrical Engineering^ — Manufacturing

Engineering — Building Technology — Fire Research — Chemical Engineering^

THE INSTITUTE FOR COMPUTER SCIENCES AND TECHNOLOGY conducts

research and provides scientific and technical services to aid Federal agencies in the selection,

acquisition, application, and use of computer technology to improve effectiveness and

economy in Government operations in accordance with Public Law 89-306 (40 U.S.C. 759), relevant Executive Orders, and other directives; carries out this mission by managing the Federal Information Processing Standards Program, developing Federal ADP standards

guidelines, and managing Federal participation in ADP voluntary standardization activities; provides scientific and technological advisory services and assistance to Federal agencies; and

provides the technical foundation for computer-related policies of the Federal Government.

The Institute consists of the following centers:

Programming Science and Technology — Computer Systems Engineering.

'Headquarters and Laboratories at Gaithersburg, MD, unless otherwise noted; mailing address Washington, DC 20234. ^Some divisions within the center are located at Boulder, CO 80303.
Computer Science

and Technology

NBS Special Publication 500-100

Toward an Improved

FIPS Cost-Benefit Methodology,

Phase I: Descriptive ModelsData Processing Operations

Marco Fiorello

Peter L Eirich

Peg Kay

Fiorello, Shaw

and Associates

Institute for Computer

6802 Poplar Place

Suite 305

Sciences and Technology

National Bureau of Standards

Washington, DC 20234

McLean, VA 22101

U.S. DEPARTMENT OF COMMERCE

Malcolm Baldrige, Secretary

National Bureau of Standards

Ernest Ambler, Director

Issued January 1983
Reports on Computer Science and Technology

The National Bureau of Standards has a special responsibility within the Federal

Government for computer science and technology activities. The programs of the NBS Institute for Computer Sciences and Technology are designed to provide ADP

standards, guidelines, and technical advisory services to improve the effectiveness

of computer utilization in the Federal sector, and to perform appropriate research

and development efforts as foundation for such activities and programs. This

publication series will report these NBS efforts to the Federal computer community as

well as to interested specialists in the academic and private sectors. Those wishing

to receive notices of publications in this series should complete and return the form

at the end of this publication.

National Bureau of Standards Special Publication 500-100

Natl. Bur. Stand. (U.S.), Spec. Publ. 500-100, 68 pages (Jan. 1983)

CODEN: XNBSAV

Library of Congress Catalog Card Number: 82-600657

U.S. GOVERNMENT PRINTING OFFICE WASHINGTON: 1982

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. 20402

Price $5.00

(Add 25 percent for other than U.S. mailing)
Foreword

The Information Processes Group (IPG) of the Institute for Computer

Sciences and Technology (ICST) was created in 1981 and is responsible for,

among other things, the development of methodologies for assessing the costs

and benefits of Federal Information Processing Standards (FIPS). Almost

immediately, it became apparent that existing cost benefit methodologies were inadequate to the purpose—partly because they were based on "rhetorical", or idealized, models of the Federal ADP environment* and did not take into

account the multiplicity of operational variations among the agencies, the

complex interactions among the components of data processing system management

and operations (see Figure I-l), or the sometimes extreme difference between

the way things are and the way things ought to be. In other words, existing

methodologies are sufficient for "ball park" estimates, but—particularly in cases where anticipated costs and benefits are less than enormous—the expected

margin-of-error is unacceptably large.

In order to reduce the margin-of-error, the IPG embarked on a program to

describe more accurately the Federal ADP environment. Using functional flow

diagrams as the basic tool for description, we hope eventually to have a realistic model of the Federal ADP environment. This report on Data Processing

Operations marks the completion of Phase I of the program. Phase II, which

covers Software Applications Development, is currently underway.

The bulk of the work on this project was done by Dr. Marco Fiorello and

Mr, Peter Eirich of Fiorello, Shaw and Associates, working with Aurora

Associates, Inc. The methodological framework was developed by Peg Kay of ICST.

Like most of the IPG projects, results were obtained and validated through

considerable interaction with personnel from other Federal agencies. In this

case, the comments and suggestions from the other agencies led to a complete

rethinking and revision of the report before the final draft was completed.

We are particularly grateful to personnel from the Department of Energy, HUD,

the Department of Justice, the FCC, the Federal Mediation and Conciliation

Service, the FTC, and NASA for helping to shape the product.

Simultaneously with this attempt to improve the qualitative descriptions, the

IPG looked for ways to improve the analysis of statistics concerning the

Federal ADP inventory. The first product of that effort was the automation of

the General Services Administration (GSA) data base. The first compilation

and analysis based on the automated data base was completed in June 1982. As

segments of the qualitative descriptive models are completed, it is our intention to apply the quantitative analyses to them and gradually to improve

the accuracy of our cost benefit projections.

Another serious barrier to accurate cost-benefit projections is the

absence of reliable base-line data. This series of reports does not address

that issue.

iii
While this program is primarily directed toward the improvement of ICST'

s

products, it is clear that the descriptive models being developed are useful

tools for ADP managers throughout the Federal Government—and probably for ADP

managers in sub-Federal jurisdictions and in industry. Their usefulness is

not confined to cost benefit related studies, but is applicable to a host of

management concerns (e.g., reorganization, workload forecasting, functional

specifications for procurement, and so on). We are therefore making these

reports widely available in the NBS Special Publications series.

Questions or suggestions related to the program are welcome and should be

addressed to Peg Kay, Institute for Computer Sciences and Technology, Building

225, Room B248, National Bureau of Standards, Washington, DC 20234.

iv
ABSTRACT

This report presents a set of functional-flow descriptive models that can be used to categorize the operational activities of Federal data processing

users. Data processing applications may be conceptually represented in

descriptive model form by combining one or more of the basic models. The

comprehensive framework for data processing operations provided by these

descriptive models can be used in the identification of impacts from standards

and guidelines and in the preparation of cost-benefit impact assessments. The

framework provides both macro and micro levels of detail in order to link the

descriptive models to additional data processing issues, such as computer

security issues.

Key words: computer security; computer standards; cost-benefit analysis; data

processing management; data processing operations; data processing standards;

descriptive models; impact assessment; information systems.

V

Table of Contents

Page

Foreword ili

Abstract v

I. Introduction 1

A. General 1 B. Background: Evaluation of Standards ,, 1 C. Project Goals 2

D. Scope of the Phase I Effort 2

E. Overview of this Report 4

II. Descriptive Model Concept 6

A. General 6

B. The Unifying Flow Principle 6

C. Overall Model Structure 6

D. Subsystem Interactions 8

III. Subsystem Descriptions 10

A. General 10

B. Subsystem Descriptions ... 10

C. Subsystem Models 15

IV. Data Processing Applications 17

A. General 17

B. Application Illustrations 17

C. Subsystem Operational Characteristics 19

V. Additional Subsystem Concepts .... 24

A. General 24

B. Micro Layers of Description 24

C. Macro Layers of Description 27

D. Security Considerations 28

E. Presentation Methods 31

VI. Conclusion 34

A. Summary of Phase I Report 34

B. Future Work 34

References 35

Appendix A. Basic Cost-Benefit Analysis Methodology A-1

Appendix B. Subsystem Descriptive Models B-(i)

vii
Tables

Page

IV-A Subsystem Operational Characteristics 22

V-A Seven ISO Layers , 26

V-B Macro and Micro Layers of Description 29

A-1 , Cost-Benefit Impact Elements .. A-3

Figures

I- l V Major Components of DP System Management and

Operation 3

II- l Subsystem Interconnections (Illustration) 9

IV-1 Sample Weekly Accounting Application Purchase Order

Processing 18

IV-2 Sample Logistics Planning Model Application 20

V-1 Computer Network Vulnerabilities .... 30

V-2 Presentation Format for Subsystem and Impact Area

Cross-References 33

Exhibits

B-1 Key to Illustrations B-(iii)

B-2 Summary of Flowchart Sjrmbols B-(iv)

Figure Subsystem Flow Diagrams

B-1 Transaction Data Capture B-1

B-2 Transaction Data Aggregation B-2

B-3a Recordkeeping (on-line, deferred update) B-3

B-3b Recordkeeping (on-line, immediate update) . . B-4

B-4 Transaction Disbursement B-5

B-5 Technical Data Preparation B-6

B-6 Automated Data Capture B-7

B-7 Analysis and Reporting B-8

B-8 Data Retrieval and Analysis B-9

B-9 Data Combination, Analysis, and Reduction B-IO

B-IO Specialized-Data Model Execution B-11

B-11 Integrated-Data Model Execution B-12

B-12 Computer-Aided Task Performance B-13

B-13 Software Development (procedures that affect DP operations) . B-14

viii
I . INTRODUCTION

A. General

The objective of this Phase I report is to present and describe a structure for a "descriptive model" of Federal data processing (DP) activities.

By a descriptive model we mean a qualitative and pictorial (flowchart)

portrayal of types of DP activities and how they interrelate. In simple

terms, the descriptive model presented in this report describes "who does

what" as Federal DP operations are accomplished by computer users. In order

to place this effort in perspective, the role of descriptive models in the

development and assessment of computer-related standards is discussed in the

next section.

B. Background; Evaluation of Standards

Before ICST develops a standard or guideline, an assessment of the

expected costs and benefits is performed. In such an assessment, the analyst

identifies a specific set of changes that are expected to occur in the existing and projected Federal DP environment as a result of issuing a standard.

The dollar consequences of those changes are then accumulated. If dollar

amounts for projected changes cannot be estimated or imputed, then a qualitative description of the likely impacts is provided, along with a commentary on the relative desirability or undesir ability of the results. At present,

these assessments are performed in accordance with a 1978 set of preliminary

guidelines [FIOR-78]. Appendix A summarizes the major steps in the assessment

procedure.

Implicit in the analyst's identification of projected changes is a conceptual model of DP procedures, an expectation of how government agencies

would act to comply with the standard, and an idea of how these actions would

ultimately affect DP systems and procedures in those agencies. Similar

conceptual models are implicit when standards are proposed and designed.

While portions of these conceptual models are sometimes made explicit in assessment reports or standards design documents, there is no uniform vocabulary or framework in use to evaluate standards. Without a framework, it is difficult

either to compare the impacts of different standards or to be confident that

supporting data have been employed consistently from one assessment to the

next

.

A recent review of six impact assessments [FIOR-81], each completed in

accordance with the 1978 preliminary guidelines, made several points relevant

to the above discussion.

o The analyses tended to focus exclusively on the components or parts

of the ADP system or process, and not mention the relevant procedures

and management actions that must occur to achieve the impact modeled,

(p. 9)

o The interpretation of the nature of impacts was inconsistent across

the studies, (p. 10)

1
The review recommended that the impact assessment guidelines, when revised,

should:

o Improve the discussion of the formulation of the base case and

impact process. The explicit use of scenario constructs and a descriptive model (functional diagrams with unifying flows) should be

introduced, (p. 12)

An important benefit of this modeling effort will be to replace the

analyst's implicit mental models with an explicit, documented, and commonly

understood representation of Federal DP activities. This, in turn, will help

to insure consistency among the different impact assessments of standards

performed for ICST. It will also permit comparisons among the expectations of

standards developers, the benefits projected in the impact assessment, and the

actual benefits that may be computed after a standard has been implemented.

C. Project Goals

The end-product of the overall descriptive model effort will be a set of

functional-flow descriptive models providing a comprehensive representation

of Federal DP activities. Using this framework, it will be possible to

specify the impacts of different standards, collect data organized so as to

aid impact assessments, and define points of measurement for evaluating a standard's actual benefits.

The Phase I descriptive model developed in this report can be applied

immediately to the development of a cost-effective set of computer-related

standards and guidelines. For example, it can improve planning for ICST

products by identifying the types of personnel to be affected by a proposed

standard or guideline. Improved standards will, in turn, assist computer

system and application managers to do a better job of developing and monitoring DP systems.

D. Scope of the Phase I Effort

The descriptive model is intended to encompass the breadth of DP system

management and operation represented in Figure I-l. The scope of this Phase I effort is limited to the "Data Processing Operations" portion of the Figure.

The existence of hardware, system software, and applications software is taken

for granted, and we do not develop descriptive models for how those resources

came to exist in the right place, at the right time. The same is true for

staff and management personnel, security controls, data resources controls,

office space, etc.

This Phase I model is only a first step toward a comprehensive set of

Federal DP descriptive models. Later study phases will develop models comparable to this one for the other areas shown in Figure I-l. Also, this Phase I model will be further refined as it is used for cost-benefit studies and as it serves as a basis for statistical data collection.

2
3
The Phase I effort has identified and defined a generic set of independent

functional flow modules, or "building blocks", for DP operations. For each

module, the descriptive model of DP operations specifies functional flows for

the activities comprising operations. These modules can be assembled in

different combinations to represent consistently the variety of general-purpose

DP applications in the Federal Government.! The "unifying flow" for our description is the transformation of data items into both useful information

and output products in the course of DP processing operations. (The concept

of a unifying flow is discussed in Chapter II.)

The accuracy and completeness of representation was verified by a process of review by a number of Federal data processing managers — a process

that will be repeated during the development of comparable descriptive models

for the acquisition and development of hardware, systems software, and applications software. Later phases of this study effort will also treat broader concerns such as the selection and implementation of security procedures, data resources planning, and overall DP system management. The software applications development process will be the topic of the Phase 11 effort.

E. Overview of this Report

Chapter II presents the concept of a descriptive model composed of

modular, functional-flow building blocks, or subsystems. It identifies the

set of subsystems employed in the model and describes their interrelationships .

Chapter III describes each subsystem and introduces the subsystem

flow diagrams. Chapter IV discusses how the subsystems may be combined to

represent different complete DP applications, and compares the subsystem

operational characteristics.

The subsystem concept is expanded in several ways in Chapter V. First,

the use of subsystem functional flows to organize more macro and more micro

levels of detail is described. Second, security considerations are related to

these levels of detail. Third, the use of subsystem flows to organize data

for planning and assessing standards is discussed. Finally, the use of the

flow diagrams as a presentation medium is illustrated.

Our objective is to adequately cover the broad range of general-purpose

DP activities, while keeping the total number of modules small and manageable. Accordingly, we do not include embedded weapons systems computers

in the scope of this descriptive model, nor do we intend to cover relatively unique special-purpose applications not typical of the federal

government as a whole. For example, the magnetic ink character recognition (MICR) equipment used the Federal Reserve for sorting checks is not

covered by any of the modules.

4
Chapter VI summarizes the work covered in this report, and describes

the steps to be undertaken in Phase II. Appendix A, as mentioned earlier,

summarizes the basic steps in performing a standards impact assessment as described in the 1978 preliminary guidelines [FIOR-78]. Appendix B contains

the flow diagrams for the different subsystems.

5
II, DESCRIPTIVE MODEL CONCEPT

A. General

This chapter explains the principle on which the descriptive model of

DP operations is based and how the subsystem approach to categorizing DP

activities was chosen. The 13 subsystems and their interactions are introduced c

Bo The Unifying Flow Principle

A descriptive model, as the term is used here, traces a sequence of

events or processing steps in a system or organization. The key to preparing

a descriptive model that captures the essence of a system or organization, and

portrays it in a straightforward manner, is to identify the proper "unifying

flow" for the model [NAKA-82],

The basis for a unifying flow is some item or characteristic that can

be traced throughout the system or organization to be modeled. The unifying

flow, specifically, is the path taken by the selected item or characteristic

and is the basis for organizing the descriptive model. For the model of DP

operations developed in this report, the unifying flow is the transformation

of data into information in the course of DP activities. Information may take

the form of outputs used for decision-making, or of specific output products

(for instance, Social Security checks).

Our broad view of DP likens it to an information factory, where various

types and amounts of raw data are pumped in, various things are done to them

and various useful information comes out. One must know who uses the information, and why it is considered information instead of data, in order to

understand the role of DP in an organization. One must also understand the

nature of the data submitted for processing, as well as what is done to them,

and by whom, to understand the functioning of DP operations. All these

elements belong to the descriptive model and are keyed to the unifying flow of

"data into information",

C. Overall Model Structure

The range of Federal DP activities is too broad to be represented in a useful way by any one Integrated descriptive model. Accordingly, our approach

was to develop a set of related descriptive models that could be combined in

different ways to reflect the wide variety of Federal DP activities. To

create a workable set of models it was necessary to categorize DP activities

in such a way that, for each category, a single model could be developed which

would apply reasonably well to the various activities within the category.

A number of likely categorization schemes had to be rejected for a variety of reasons. For instance, while there are many similarities in DP

activities among different agencies, there are still too many differences to

allow building a descriptive model for one agency and applying it (with only

6
minor variations) government-wide. As another example, models based on functions (personnel, accounting, supply) were not practical because there are

too many possible variations for any one function to have only one model for

each, and yet there are enough similarities between different functions to

make the models repetitive in many cases.

Breakdowns based on any of the resources shown in Figure I-l were rejected for similar reasons. These possibilities included breakdowns

by:

o computer hardware used

o system software environment

o application software characteristics

o security requirements

o staff /position characteristics of users

o size of organization

Management-oriented breakdowns were also not satisfactory. In a study

of 56 decision-oriented computer applications^ Steven Alter found that few

significant conclusions seemed to emerge from commonly-used labeling schemes

such as

:

o functional area (marketing, production, finance, etc.)

o decision perspective (operational control, management control,

strategic planning)

o problem type (structured vs. unstructured)

o computer technology (interactive vs. batch)

o modeling approach (simulation vs. optimization)

The breakdown ultimately selected for our descriptive model is an expansion of Alter' s work [ALTE-75; ALTE-77]. Alter found that seven "system

types" served as a useful classification scheme for the 56 applications he

studied. In a broader context, Alter' s "systems" may be viewed as subsystems

of still larger DP applications, and 13 such subsystems are needed to represent

the breadth of general-purpose DP activities in the Federal Government.

Presumably, most or all of them were in the private sector. See [ALTE-77,

pp. 40-41]. Labeling schemes for applications reprinted with permission

(see references)

.

7
The set of data processing operations subsystems is as follows:

1. Transaction Data Capture

2. Transaction Data Aggregation

3. Recordkeeping

4. Transaction Disbursement

5. Technical Data Preparation

6. Automated Data Capture

7. Analysis and Reporting

8. Data Retrieval and Analysis

9. Data Combination, Analysis, and Reduction

10. Specialized-Data Model Execution

11. Integrated-Data Model Execution

12. Computer-Aided Task Performance

13. Software Development

Subsystems 7 through 11 cover the scope of systems studied in [ALTE-75; ALTE-77].

We have redefined his categories to reflect the structure of the DP operations

involved rather than following Alter' s definitions, which reflect system

behavior and intent. While this regrouping of applications is more appropriate

for the analysis of ongoing DP activities, the discussion of subsystems also

refers to Alter' s categories in order to benefit from his research results.

D. Subsystem Interactions

Different subsystems may be combined to form various DP applications. In

general, some subsystems will typically perform input processing, while others

will primarily prepare output products. This can never be completely true,

of course, since the output of one DP system is often the input to the next.

Figure II-l shows the manner in which subsystems are generally interconnected. Types of intermediate files that serve to transfer data from one subsystem to the next are also shown. Again, this is not the only pattern of

interconnection possible, ^ but we believe it is the most typical.

Subsystem interconnections will be treated further in Chapter IV, where

DP applications are discussed. First, a more detailed description of each

subsystem will be presented in Chapter III.

Some additional types of interconnections are indicated in the subsystem flow diagrams in Appendix B.

8

III. SUBSYSTEM DESCRIPTIONS

A. General

This chapter briefly defines and describes each of the 13 subsystems

mentioned in Chapter II and introduces the subsystem models. These descriptions establish the role of each subsystem in the overall DP scheme to prepare

for the explanation of DP applications and operational characteristics in

Chapter IV.

B. Subsystem Descriptions

1« Transaction Data Capture : the entry of data from individual transaction documents such as accounting vouchers onto machine-readable media for

further processing. The results of this procedure are a set of files, reflecting the relevant transaction data, residing on various processing media, and

accompanied by physical documents and control totals (as necessary) to provide

an audit trail. The resulting files are generally forwarded for processing

under a subsystem 2 application (transaction data aggregation).

Examples include accounting, inventory, and timekeeping document entry,

as well as the entry of corrections for errors detected in later stages of

processing.

2. Transaction Data Aggregation : the collection of individual transaction records, when the data entered are essentially additive or cumulative in

effect. The results of this collection are usually a set of master files

updated for a given period and/or a set of merged transaction files for

the period.

Besides various accounting vouchers where dollar amounts are cumulated,

other examples of transaction aggregation are found in inventory control,

where stock additions/withdrawals are tracked to adjust stock balances, and

in employee timekeeping, where staff hours by project are accumulated.

3. Recordkeeping : the processing of transactions, which take the form of

updates or changes to information in master files (3a—on-line, deferred update)

and/or updates to an on-line data base (3b—on-line, immediate update). Note

that maintenance of historical data in a file, such as previous position titles

and past salaries for an employee in a personnel file, does not make these data

cumulative in the sense of subsystem 2 (transaction data aggregation).

Examples may be found in payroll and personnel systems, where changes to

employee status or salary and additions/deletions of employees are processed.

Other examples are payment systems such as Social Security where transactions entered from field offices are used to change master files and thereby

initiate, terminate, or change computed beneficiary pa3nnents.

4. Transaction Disbursement : the preparation of transaction documents

to be distributed, as opposed to collected.

10
The most obvious example is the preparation of checks, which may be

computed and prepared on the basis of transaction files, master files, or a combination of the two. Payroll systems are an example of a combination of

both sources, since computation of the amount of each check for a pay period

often depends on both the timekeeping data for the pay period (from a type 2

transaction data aggregation subsystem) and the employee master file (from a type 3 recordkeeping subsystem)

.

5. Technical Data Preparation ; the maintenance of data files by

technical personnel, typically for use as inputs to computer models. Unlike

the previous four subsystems, which generally involve formal processing

controls and audit trails, the integrity of the data in this subsystem relies

upon the concern and attention to detail of the responsible analyst. Data

maintenance will usually be accomplished with a generalized text editor,

in contrast to the program-controlled or data base management system (DBMS)-

controlled updates found in subsystem 3 (recordkeeping).

Examples are data preparation for all manner of engineering, scientific,

and economic models. Maintenance procedures will usually be more formalized

for either large-scale models or models where the results are widely publicized.

6. Automated Data Capture : the processing of a stream of real-time or recorded data samples to determine what events of interest have transpired

and to report those events in a usable (or readable) format. This type of

subsystem is typically found in manufacturing and engineering applications and

represents only a "front-end" conversion step to provide inputs for other

subsystem processing.

Examples include the processing of satellite transmissions and the

analysis of recorded data from engineering field tests. The latter can include both environmental data such as underwater sound recordings and/or

internal system information such as the outputs from electronic circuitry or micro-computers that implement decision logic.

7. Analysis and Reporting : primarily the preparation of routine,

standard, periodic reports, using batch computer programs, on a wide variety

of activities in the organization. (Often these are called "vanilla COBOL"

applications when COBOL is the programming language.) They can also be

sophisticated reporting systems utilizing a DBMS or other advanced technique.

The term "analysis" reflects limited manipulation of the data (in

addition to straightforward summary) which may be performed to simplify use

of the report's contents. When these manipulations take the form of evaluating simple decision rules, this subsystem can implement a "decision suggestion"

function wherein specific managerial or operational actions are indicated by

the results of a computer program. ^

Suggestion models represent one decision support system type, as defined

by Alter [ALTE-75; ALTE-77], that may be implemented by several of the

operational subsystems (7, 10, 11) presented here.

11
Examples include summary reports of expenses and/or staff hours by

project, employee, branch, division, etc. Such reports may be found in almost

every sizeable organization. Examples of decision suggestion reports are: a list of employees due for a step increase on the basis of time-in-grade and an inventory list flagging items with stock-on-hand below the appropriate reorder

point

.

8. Data Retrieval and Analysis ; the preparation of data listings and/or

processed reports at the initiation of the end-user. This generally implies

on-line, interactive access, although batch programs may be used in lieu of (or

in addition to) on-line access. The two major usage modes for this subsystem,

data item display and data analysis, are characterized below,

/ 8.1 Data Item Display—the retrieval of status information or other data

concerning specific items. The data may be stored in forms ranging from

sequential files on off-line media to on-line data bases; the key here is that

only a simple "file drawer" type of retrieval is done, with minimal (if any)

aggregation of data. Inquiries can be either ad hoc, or operational and

repetitive

.

Examples include the retrieval of on-hand/on-order information for

inventory items, status information on project expenditures, and employee data

from a personnel database.

8.2 Data Analysis—the preparation of a variety of ad hoc or specialpurpose reports by supplying input parameters to customized software or using

user-oriented data manipulation languages. This includes both generalized

data manipulation languages, such as the query langauges often incorporated

into a DBMS, and specialized languages dealing with specific job or task. The

data could be stored in various file structures or maintained under a DBMS.

While data item display involves the retrieval and display of individual

records, data analysis typically presents aggregate data derived from sets of

selected records. For instance, a data item display program might print all

the outstanding orders for a specified vendor, while a data analysis program

might provide the total amount of outstanding orders overdue by 30 days and a breakdown by vendor.

A variety of examples often may be found wherever a DBMS has been

installed, depending only on the needs and skills of the DBMS users. Other

examples include the use of customized software to provide tabular reports on research project expenditures. In this example the user supplies the variables

to be summarized, and the tailored software determines the row and column

headings, retrieves the appropriate data records, and produces the desired

summary table.

9. Data Combination, Analysis, and Reduction ; the preparation of

intermediate data files and/or special-purpose reports requiring data from more than one operational DP system and/or management database. The

software that makes this possible may be viewed as a collection of models

and data utilities that can be applied by an analyst to gather data from

12
different systems and to perform planning calculations. Such systems often

require cooperation between different software groups, different managers,

and/or different organizations for successful operation and may be operated

on a periodic or ad hoc basis.

One example is a system that extracts and integrates data from several

logistics reporting systems, containing different types of information, and

prepares a specialized database. This specialized database can then be used

to provide summary reports for decision-making and also to generate data for

computer models of the types listed below.

10. Specialized-Data Model Execution : the use of models that operate

from "constructed" databases, such as the output files from either subsystem

5 (technical data preparation) or 9 (data combination, analysis, and reduction),

that will usually be tailored to the needs of the particular model. These

models will typically be used for planning, analysis, and problem-solving, and

will often be set up for use by specialists on an as-needed basis. While any

of the model types described in [ALTE-75; ALTE-77] could fall into this

category, accounting models and representational models are (we believe) more commonly found here and will be characterized below, while optimization

models and suggestion models are covered under subsystem 11 (integrated-data

model execution)

.

10.1. Accounting Model Computation—the use of standardized formulas and

relationships to prepare estimates for management planning and/or operations

activity. These are frequently, but not exclusively, accounting/financial

estimates, 2 As compared to type 8.2 subsystems (data analysis), the computations utilized involve more than simple accumulations or statistical summaries

of stored data, and more than straightforward decision rules applied to such

summaries, but are restricted to cases where the computational relationships

are tightly defined or well-known, even though model parameters may vary. The

"stable" algorithms involved make these models suitable for decision suggestion

applications, and they may be utilized for this purpose as described under

subsystem 11 (integrated-data model execution).

An example is the calculation of estimated retirement benefits for an employee, on the basis of salary and length-of-service data, using different

date-of-retirement assumptions. Other examples would be the computation of

project cost estimates based on estimated staff hours for different skill

levels, project status reporting, and budget projections.

10.2 Representational Model Simulation—the use of mathematical models

to represent more complex processes than might be handled by a simple accounting model, and to predict outcomes on the basis of either varying system

inputs, or making different assumptions concerning the process modeled and/or

the nature of relationships between variables. These models are often used for

We use the term "accounting-model" because it best exemplifies the

type of computations performed. The term does not imply that subsystem

10.1 is found only in accounting applications.

13
engineering design decisions, and for other problems that cannot be treated by one or more definitional formulas like those covered by accounting model

computation. In these problems the interactions between formulas and the

amounts of computation are such that a computer is required, whereas, in an accounting model, it might be merely convenient.

An example is the computer simulation of the responses of a proposed weapon system in different operational environments, such as the performance of a sonar system at different depths and under different ocean temperature-gradient

conditions. Another example is the simulation of the survivability of a ship

under different forms of attack.

11. Integrated-Data Model Execution : the use of models that operate

directly from operational data files or from slightly processed versions of

those files, as opposed to tailored and/or highly aggregated data bases (such

as those utilized for models in subsystem 10). While specialized-data models

will often involve aggregate data inputs, integrated-data models will generally

operate on detailed data and take the form of decision suggestion or trade-off

optimization models.

11.1 Decision Suggestion: the use of a mathematical algorithm to indicate

managerial or operational actions. The basis could be mathematical optimization, accounting model computations, or other decision rules. The expectation

is that the computer-produced suggestions would be implemented, but only so long as the situation remains within the bounds of the circumstances for which

the suggestion model was originally designed.

An example would be a student/class scheduling model for a military

training school.

11.2 Trade-off Optimization—the use, for planning purposes, of

mathematical models that find the combination(s) of resources or system

parameters that maximize or minimize, within specified constraints, the value

of some selected goal variable. These models can be used to evaluate design

or management trade-offs as the constraints are varied. In contrast to a decision suggestion model, which may use optimization techniques to produce

a specific answer, trade-off optimization implies that information about

constraints, sensitivities, and input trade-offs is reviewed and analyzed

in addition to the optimization results, and different scenarios may be

evaluated.

An example is the determination of the mix of spare parts that provides

the maximum expected aircraft availability for any specified level of

additional investment in spare parts. The results of such a model enable

managers to understand the effects of more or less investment in spare parts

and to make better decisions concerning the trade-offs between the amounts

invested in spare parts and other forms of investment such as new aircraft.

Once the level of expenditure for spare parts has been determined, the

optimization model can be used like a decision suggestion model in order

14
to specify which particular spare parts should be purchased, 3 Alternatively,

when used to predict the availability rate that will result from a specified

level of investment, the model is used as a representational model. (In the

latter use, one assumption is that dollars will be spent optimally in terms of

availability.)

12. Computer-Aided Task Performance ; the use of a computer to enhance

the ability of a person to perform a task by executing various operations

under immediate and interactive control by that person. Included here are any

applications where the computer acts to extend the capabilities of the user to

perform some task in a real-time manner. Both printing and CRT terminals,

with or without graphics capabilities, may be used.

An example is the use of computerized drafting systems where the computer

constructs drawings on the basis of real-time instructions from a draftsman.

Computer-aided design applications such as electronic circuit and mechanical

component design can result from integrating this subsystem with a representational model simulation (subsystem 10.2). Word processing systems and

of f ice-of-the-future technology in general also belong under this subsystem.

13. Software Development ; the use of text editors, compilers, and other

system utilities to prepare either application programs, computer system

software, or job control language. The result of this subsystem is the

variety of programs and control statements necessary to implement instances

of the previous 12 subsystems. We include in this subsystem only those

activities that directly involve DP operations; other aspects of software

development (e.g., planning, meetings, documentation) are covered under the

Phase II descriptive model, which also encompasses the elements of this

software development subsystem.

Examples include all types of programs given as examples under subsystems

1 through 12. These may be written in commonly used languages such as FORTRAN, COBOL, PL/1, and BASIC, or may be developed using special-purpose

languages such as DBMS query commands.

C. Subsystem Models

Flow diagrams for the 13 subsystems may be found in Appendix B. Each is

a fundamental building block of the DP operations descriptive model.

Each diagram follows the transformation of data to information within

a subsystem. The figures show the different media and representations used

for the data at different stages of processing, while still maintaining fairly

general descriptions concerning the nature of the data. Each figure shows

major steps in processing and the personnel that directly interact with the DP

system or the data.

In practice, the suggested purchases are seldom followed exactly because of

localized constraints and miscellaneous "real-world" factors that managers

take into account when placing an order.

15
Decimal numbers are used for the figures in Appendix B. The numerical

portion represents the subsystem number. A lower-case letter in the figure

number indicates that the diagram is one of several common variations for the

particular subsystem. Such variations occur when different computer technologies cause significant changes in the processing flow. Differences

between batch and interactive processing, for example, are reflected within

each figure as appropriate. When variations due to technology are minor,

these are simply noted on the primary diagram.

Taken together, these subsystems represent the major variations of

processing found in general-purpose DP activities in the Federal Government,

They should be reviewed before proceeding to the next chapter, which

illustrates how DP applications may be represented by combinations of the

subsystems

.

16
IV. DATA PROCESSING APPLICATIONS

A. General

This chapter begins by discussing the structural relationship between

applications and the set of DP subsystems. The subsystems' operational

characteristics are then compared. Our non-rigorous definition of an application is: a sequence of DP procedures that begins with some user data

or computer files that exist independently (they are not simply intermediate

by-products of a processing sequence) and ends with printed outputs or computer files that serve a definite organizational purpose.

B. Application Illustrations

In the descriptive model, applications are considered as combinations of

subsystems linked by intermediate products of the processing sequence. For

example, as illustrated in Figure IV-lj a minimal accounting voucher application usually consists of transaction data capture and aggregation subsystems

to prepare a weekly transaction file, and an analysis and reporting subsystem

to turn out weekly (or periodic) summary reports. There is little transformation of data into information — the output reports are simply recapitulations,

with totals, of the input documents. The subsystems are linked by a welldefined intermediate product — a file containing the accumulated weekly

transactions (typically grouped into batches of transactions, with batches in

sequence according to an assigned control number). The intermediate file is

shown as stored on tape, since we believe this to be the most common practice,

but the application would not be affected if disk storage were used. 1

As indicated in Figure IV-1 , intermediate products can be shared among

applications. As a result, drawing the boundaries between different applications can be somewhat arbitrary and can vary from organization to organization. As a general rule, the boundaries of applications will be drawn

along lines of management responsibility (for the data and products) at some level in the organization. In this example, the accounting department "owns"

(i.e., controls) both the input vouchers and output reports.

In general, application diagrams may be formed as subsets of the subsystem

interactions diagram shown earlier as Figure II-l. For example, a basic

personnel application would consist of subsystems 3 and 7 — a recordkeeping subsystem to maintain the employee master file and an analysis

and reporting subsystem to prepare periodic staffing reports. However, other

subsystems using the employee master file as input may also be found in

personnel applications, as follows:

Where the type of media is important to the nature of processing, such

as the need for disk storage when random access is required, it will be

specifically noted.

17
18
o a transaction disbursement subsystem may be included to produce

standard personnel action forms for filing in employee folders (as

opposed to personnel systems that use these forms as input documents);

o a data retrieval and analysis subsystem may be used for simple on-line

inquiries regarding employee status;

o a data retrieval and analysis subsystem may provide infrequent or

ad hoc reports for a specific manager;

o a representational model in a specialized-data model subsystem can

be included to simulate the effects of anticipated retirements and to

project staffing needs.

The particular mix of such "advanced" features in an application will depend

as much on the personality of the responsible manager as on organizational

size and environment. As a result, while the functions of the personnel

application will be comparable from site to site, the degree of automation and

the provision of advanced analysis capabilities will vary.

More complex applications can vary from the typical pattern of interconnections shown in Figure II-l. For example. Figure IV-2 shows the subsystem

structure of an advanced logistics planning model that processes data on all

(expensive) repairable spare parts in the Air Force inventory. The difficulty

of the problem forces a series of models to process data in sequence, with one model supplying inputs to the next. This is in contrast to the parallel

organization in Figure II-l, where each model is implied to be optional and

independent

.

In the logistics planning model, there is extensive transformation of data

into information. The data retrieval and analysis subsystem shown provides

information to the planners — it presents them with capability estimates in

response to trial budget allocations and thereby allows them to make better

budgeting decisions. The suggestion model shown provides information to

logistics item managers concerning which parts to purchase. The original

input tapes are simply not useful to logistics planners for budgeting purposes:

without pre-processing, the mass of detail is impossible for a decision-maker

to absorb. Until the data are transformed by the models, and presented in such

a way that a decision-maker can make decisions and take actions, it cannot be

said that those input tapes provide information — only that the potential is

there

,

This section has introduced the concept of an application as comprising

different DP subsystems, each serving as a module or building block for the

application. Later phases of this effort may attempt to catalog the various

ways subsystems are combined to form DP applications in the Federal Government,

C, Subsystem Operational Characteristics

The DP subsystems presented earlier can exhibit different operational

characteristics because of both the types of applications in which they are

19
20
included and the skill required to operate them and/or utilize their products.

Master files are both an output from recordkeeping systems and an input to

transaction disbursement systems, for instance. Transaction aggregation

systems are typically used by clerical personnel, while representational

models (in specialized-data model subsystems) are generally used either by

economists or by technical, business, or policy analysts.

Table IV-A lists different operational characteristics for subsystems in

several categories of variation. "Key Role" indicates the type of personnel

most responsible for the successful operation of the subsystem. "DecisionMaker" indicates the type of personnel acting upon subsystem outputs. The

other categories are self-explanatory.

For subsystems 8.1 through 11.2, the information on type of task, handson-user, decision maker, key role, and key usage problem comes from [ALTK-77].

The following definitions from Alter' s 1975 work [ALTE-75, ch. 6] apply:

o Feeders are people who provide data for a system, but either do

not use it directly for their own decisions or do not derive benefit

from it for other reasons. This role is common in budgeting and

planning systems in which people at various organizational levels

are required to provide information which is later digested and

consolidated by the system,

o A user is a person who communicates directly with the system in either

on-line mode or batch mode and receives and decodes its outputs.

o A decision-maker is a person who makes decisions based on the outputs

of the system. These outputs may have been filtered or interpreted by

the user before the decision-maker receives them. In this case, the user is referred to as an intermediary .

And, in the context of subsystem 5,

o A designer is the programmer/analyst and/or electronics engineer

responsible for creating hardware and software linkages to sample and

record the process data.

Other portions of the table are postulated from a general knowledge of

DP applications.

Alter covers some other categories as well, but these deal with system

design and implementation and will be covered under the descriptive model

for application software development. This portion of Table IV-A reprinted

with permission (see references)

.

Reprinted with permission of the author.

21
r-t

—i

CO 0 o - 00 o c u 00 u B u 00 0 ij iJ U B O kl kl

1-t

BB E V 1-1B

B

4J

O o 1) a klOU

u CJ BO - o bO a >,

u BO

u a o c 50 B BO c *• CO 3 s u kl • E 3 c: >> -H E >-. •H CO Q. •o 00 B >> IS B /—. CO b •H Li O. « a o u u i; kl Q. £ 11 o 0 V 4J O E D iH kl u iH a o CJ a —^ w

<U

B

U 11 E iJ

B

—(

i-t o ^ CL <u a 10

u kl iH kl

u ^ 1-^ 3 B J<! 3 E 0 o CO -H O c o u BO B IS CO BO —' CO a 0 OJ 11 O 1^ 00 ki •H O l-l iH B u CO iH U 10 s U > a U > s >< CJ > a BO o E E > CJ CO B E iH « CJ B O E V CO O E CO >4 B o V CO E O <a IS O IS

CO iH

U CO -H a o. IB --I O. BH

U 11 BO a iH CO

u i 1-1

B

kJ < 3

CJu

B 11

U 1)

0) kl

X -o

4J

B 3 a UB

B

u

O BO

O 1) 3 o 0 •o •V >< B iH 1-1 tS kl r-l s E E B E 11 00 u 11 kl BO cu CD 1) -a 3 B >^ CO CO CO O kl E CD kl >^ CO E 0 >. 13 E

COUu c u

B

U E 1-t CO 0 kl 00 o kl CO > H 01 kl CO

O 3 o O B o o B 0 O B O kl 3 •H 3 iH CS •r4 kJ 1^ B r-t r 0

BO o bOu 0 klO T-t CD •o

U CJ 00 01 -H kl kl

H a. kl oj <ki a) CJ -H 1-1 •H u u kl 4J m kl U CJ B E H O 0 CD o 10 j: IS

CO

V CO

M 11 4J

V CJ

U kl

UB CO E CD

O kl Q. a kl 0) £ kl kl 0)

CJ

U CO o u CJ 11

V SI 3 CJ 3 U kl Q. 5 IS JS

t-l 3 -O CO 1> CO

u CO 1> kl Q. CO 01 kl kl j= o 3 O 10 u u 4J iJ U a u u TJ a o V -a B kl kl 1 0

01 0 CJ

UQ CO <u 0 COUO o 0 s

ID

BH

B UH 0]

B CO 3 -H a CO

CO COu

y •o •a o •a 73 CJu a CO kl CO

O 3 IS

U

O 3 D rH N IS iH

rH

IS ISa

CJ

V

B

B E kl CO

— E B 91 00

O o 0 o V

U kl >% 00

O

O Q.B 0 1 1 1 1 E iH CO 1 kl kl 1 1 Vi 0

OS 00 CS 00 E >s kl CO a CO CO <tH T3 u C3 T3 kl •H J= V H T5 T3 k< C3 kl kl kl >1 6 11 E D E u E 11 00 O CO kl T3 1) E 01 E U E CO V 3 CS CO 00 a CO CO CS V U B E 1> 11 CD CS CD CO V U

it: j: 3 £ 3 ji 3 s: 3 T3 kl IS 1-t a £ 3 £ 3 CO E

11

W

kl a

o.

u

u •-t

U -H

u 1—11) 1-t 1) kl a.

1.1

u klu CD

B CO

B E

Qiu

V 11 •H E 1-t E kl CM -H

u BO BO BC BO kl

O kl

O 0 • 1 >^ O CO CO CO iH ^ CD u CO U CO O -1 c 00 B B B CD CD E BO kl BO • 0 U •H CO CO o u U IH 10 ID 01 CD 11 kl U

-H c > Q 6 a iH

u iH

VB E o. C Q. OJ

U •O —1

CO <u E BOB to ID CO BO E E

•H 1 11 1> 1) CD CO

u a VB 11 IS E CO £ O >^ o. B B CJ B O B E c E B C E 10 BO V 11 3 H •H 11 CD u CO 1-t o H 0 1-t CO — 3 Q M 00 iH -H kl a kl a r-< 6 I—1 E -H B O. • O o j:

1) -H rH > rH

CO kl CO 1—1

11 r-t 1) iH 00 CO

11

B CO E CO E to E V

CO

U

O >\ CD 0 •H E iH

B IS iH • 1 0 4J 1-1 1—1 O 1-1 U O I- 0 3 kl CO tJ CO -H kl V 00 01 X IS kl —1 C ^ U Ui H 10 E E IS a) BO kl BO l-i ^ j: E —1 O CO u 0 CO kl CO X kl CJ kl CO V CO U kl X bJ % 1 U B iJ /I 1 o CO 11 CJ IS CS 11 B o. E i:k CD IS u

CO

« CO •H a a. Vkl 11 >-, c a. Q. CO ID kl >^ o u 1 u Ui CJ O 3 CM kl .H 0 3 a 11 a i> 00 -H kl • E c <i) >% u 11 u o (0 10 "u CD O B B EE ID o —- O

<t rHu a _j

« rH Cu

u kl

B

u

B a. kl o •H 0 iH kl E 00 1^

X

U j>: 0 CJ ^ O CS a BO CS o CO 10 a BO

B t-H E O 10 % kl > ^ 3

1-t CJ

00 CO i; 3 iH X

Q 1-1 00 Ij] 00 O 1 CO u >s

BB

V

U o kl kl

X rH rH 0 O ^ -H CO IS 10 >^ CO 3 U U CO 1) •H •H CO u CO 00 -a kl u Q. 0 o E -O E <H 3 k) 10 -H E BO BO 01 < 0

CB

u 00

y CD

H t3

B a H

H a 00 11 >s

B 11 >^ E r 4J CO CO k4 kl tH D 11 B U.I u kl B IS iH E IS -H 3 CO 00 1) « 4J > a -H 3 i-( CO kl kl i-< iH kl lH rH kl o B CD o- B o E 4J E rt 3 O. •J) 10 11 B o f-^ O. B -H D. E kl CD kl

CO CJ CO T5

O •o

O a kl •-t iH a. 1 CO 1 CO iH CS 3 u v B •rt E O 10 kl CO 0 kl V B 1-1 U c u T5 rH Q o u u i B 9 00 0 o a a. kl O T3 a 0 -a a. IS 1 13 > -0 E 11 91 B U •H kl O CJ 00 •a 00 00 ki kl 18

CD

m •r^

U 1-1 kl i> kl

uB kl kl iJ u U 11 B B B « CO 1.1 U BO B M m B CJ kl O U 1-1 kl 11 1) CO OS 11

CO

V 11 CO 00 kl a a 11 kl E B -O kl kl

4J CJ

B o a 00 CO 00 kJ a 1 kl

B

V 00

H

B •H 0 CD

B 3 u 3 C O 1.1 3 Ban o iH kl i) 10 kl 11 1) 10 B kl rH a 3 U CO U 3 U u 3 u kj a u IS 1^ 1 -H 1 kl CD c O O O o kl U 1-1 .H cr a 11 o IS IS E •H E 10 kl O kl M a T5 CO o kl o ^ i> 3 o e o. e >kl 0 Ikl o -o 3 B

Si kl 91 B CO

M

11 91

CO r-( 1—t ^ ^ CO kl 00 kl eg <« (0 CO CO CO CO iH CO CO CD 1-t 00 11 a. H B c E E B E 7) B E E IS tH 1) O 0 0 0 0 o >^ o o 0 >\ r-t a. kl

i-( •H iH 1-1 1.1 1^ iH •H ^ 11 o u iJ kl kJ kl CO kl kl 4J CD 1—1

IH CM

CS fl3 CO CD a 10 E IS IS IS E CS u bi kl kl u CO u u kl CD CJ CM -H

a. 1) 0) 11

V 1)

VV 11 11 iH

>, a a a a. 0. a. kl a. 0. a u oo H 0 0 o o o 0 o o o o o

kl T5

B • B CO /-N

91 kl 0) a CO CO ri.

B ki c e B E kl E B r- Sfe 0 3 0 o O V 3 o IS 00 ^ 4J 1-* 1-1 a kl iH bO a CO

4-1 a u kl 11 11 O. CO

U 00 E « a C50

—1 BO CM CJ CO u 03 1 60 CJ 00 kl CD CJ IS 1-1 iH kl >. H •o E

CO o (d bO •a

B CD kl CO

O iH kl CD kl

M COO 01 CO IS -ri

B CD OD

u •H IS 3 B

B IS >. kl 1-t o 91U kl

w E CO C 09 o O.

B ^ o CO j: to a. 0 IS a CO E iH iH

U

CO 4J (d 4-) 00

u 11 CO 00 kl kl o kl

v CS a kl 00 kl

Q 11 kl k>O

mu CO 1-1 CO

V 11 kl Tt 3 CDu ISMV IS 10

B kl kl kl Q.

>>

H o HO et

H

Q < a H

Q Ou o o Q < B E E 91 00 h-t u u aii ^ CS 3

C/3 -3-

m 00 CM

22
09O 4J •H o m u 4) e 10 o

•H

Q 00 l-i

U o a a OS a CO 3 c » -H o

b. 00 o 01 01 c 1-1 u 00 B a

01

uu 01 C 01 -H e « CO H O bO a c l-l 01 o CD IS B <a 01 CO 3 U B 3 o. OJ 4J 01 2 cn D. 0 Li 00 Q. s aV ID O m

•Hu 00

03

B 01 o 01 tH H o u > o

SuH o;

B

U a 0 ex

U o u

H

bO OJ ot 4J bO

<8 4J CO c

0) U-l

B l-l •H 3 0) H bo B

01 e

>i 3 01 4.J CO 01 0 SI B u H O.

01 •

iH >^ O 1 u 1.1 Of u 0 IS V •rt 01 H

>>

u o T3

01 c 0)B a a a

o;

IBU

u o o C • o u U u

•H 01 OJ 0) 01 to QO c bO c ^ c CO B u C CO c (S

OJ CO Q s a c u

01 CO cn

ts >> 3 u a CO 01 C c E bO o CS CO 10 1o u-l >M 10 •o <M U-l a c 10 CO

10 4J iJu

X

m CO a

10 u«

•0 o >. T3 00 ij Ut 01 3 10 CO 4J ki o. ^

01

B 0

4J a 3 3 U 01 O CO O. u a CO 00 0 4J 01

\u CO —(

CO cw •o 00 u> 3 a M u-l 4J o CO u 01 10 3 01 11 10 u X CO 4.1 IB J.I >> 3 <0 > CO 0

CO

(d ECO bO <w •H B o 00 •H >. B

01

B a CO 10 >. c H 10 D. B

gjo bO

•H

BB

W CO

O

H a •H s c 00 u B

>^ o 3 .H

01 <« 3 O 01 u a 10 u T3 o CO o e 01 u O o o < OS < s CD3 o

bOB 00 •H B

l-i

O -B

01 -HO

<U

u

U e 10 10 •H Li 01 bO 01 00 B a. 01 01 O b

01 u -O

•H a

10 10 4J ki B

00

O 10

B

Oa

Li 01 a Li

01

0)

V I Li a U 01 IS 01 U Li CO B IS 3 OJ O.

01 •O

B I o o B r -H

01 I u

OD l-l CO

01 IS —I UBS o. o a

01 fl tH

PS *J i«

Li 01 0 B

LI

B

BO

01 CO > U B I O T3

•rf

B

O -o a B3

10

B

•H

B

Li

O

O 00 bO Li

<g OJ C Q.

COE 01 B B O -H B

01 00 bO U

CO 01 a 01 B B O -H

fi ^

-O to

01 LI

LI Li B O

•H Q.

Li OJ a LiBO B -H O Ll •H 0)

09 01 •H bO u bo

B

bO CO I Li

Li CO

01 T-*

4-1 -O B 01 •H a

•-H 0)

COBB

Li Li

O 0 01 CO bO Li U 10 01

01 C O.

bO 10

10 a 01 B E B IBOE -H

18

tM bO

u-l 10 01

10 E E

O.

U 10 T3

U-l CO 0 N ' "d

01 a

CS 4.1 Li a H O

CO

01

01 4-1 Li u-l -H

CJ CO bO

01 LiB

OJ -O 01 E

bcO E I T5 CD ^ E 10 E « >>

•H > 01 u-l

B CJ

CO -H -H

OOB

Li 4.1U •H 01

U

O UH 00 4J •H S CO <0 U

Li 01 Li iH

01 TI 01

B

CO

B 00 l-l 3 CO 3 B 01

CS 00 Si 3

01 Li e o

Li is 0 -H

U.4 >

Li Li

01 01 Q. a.3 ^ CO

00

01o. U.I O 01

rH a Li 3

IS 10

O CO

01 -H 4J 01

Li -O CD L4

01 3 a O.B a 01

01 ID

Li 3

0)

J<!

O I 00 B

Li CO

m

01

H a

4-1 Li 3 -O O

Q. 01 U-l S Li O •'^ 01 O < Ou

IDa csl a 01 —1 O 4J

Li S 3

U-l

X

U

m SI

4J

B 3

CO 00 -4 E

01 bO a E B B 01 O 'H

•H

M -H

U 4.)

O tH 4J 3 E E 3 IS t3 0) CS O" O a u 01 CD a

00 Li >u II

O

bO

bO . U U B 01

01 01 10 >

00 Q.X 01 3 CD O T3

bO -H O CO U B

a. CO

01 >< Li a cn -E

-a 4-1

TSE

01 CO —1

J3 00 01

10 a t-H bO

4J 10 o 10 3 u U 3 U bO u bO

01 0 E E X u 0 10

01 a <J E a 01 01 IS a U Li 01 01 bO 4.1 4-1 o a B Li 4J

01 O- IS

01ao

UJ > O 01 CO o • B ^ IS o^ CO ^ -H w OD B ^ O 0) -J E u < 3u u

01 01 X -o U E3

01 -o •O B O 3 r 0

U.I IS

4-t 01

10 £i Q1 0

•O 10

01 -H N 03 •H >.

10 ISa o

01 10 O. E

C/5

O

LI 4-1 E 10 01 4-1 CO E

01 01 u a

Cl 01 01 -H

Li O.a

CM T* • o — a —1 E

10 -E

bO

— 3 • O O X

01 —4 4J >

09 IS 4J 01 00 iH 3 Li 10 4-1 ^ X E —1

UJ %

0)

Li • B 0 O

CO -H

0) % 4J > w 3

•1-1 (J

COm o> 3 H X

CO U3 oM I—( ^

01 CS

u E -O

01 < 0

-a z a o E CS

4.J IS 4J

10 o -I Q

01 to 1 T3 > -0 E 01 01

01 •H 4J

4.1u IS E 4-1 U

0) bo

qS 01 4J 4-1 0 10 E

4J

Q 4-» B W

4) ^

Li 01 IX Li

01 1—1

Li (M

COo CN —1 a CO

>> •a

4.1 TJ E B IS

CO IS

CO

10 00

— bO o E

01 CD IS o 01 01 4-1 B Li 01 Li U 0

4J 4.1 4-1 o. E E C 01 U U a:

-H CM

23
V. ADDITIONAL SUBSYSTEM CONCEPTS

A. General

The previous chapters have presented a descriptive model of DP operations.

This chapter introduces some associated concepts which further develop the

framework. It also describes some practical uses of the model made possible

by combining those concepts with the earlier subsystem descriptions.

B. Micro Layers of Description

Each of the descriptive flow diagrams in Appendix B characterizes DP

operational subsystems in terms of the interaction between employees, data

processing steps, and various media containing data. The types of personnel,

processing, and data are indicated. This level of detail is a process description: it shows what is done to data, by whom, and in what sequence, as well

as what kinds of data (and, if desired, which data elements) are present.

While this level of detail is adequate for a descriptive model, much more information is necessary to evaluate a variety of computer-related standards

and guidelines. For example, it could be important to the evaluation of

certain standards to know what percentage of the data input terminals

represented in Figure B-2 employed a standard ASCII character set. Later

phases of the effort will, ultimately, expand the descriptive model to include

such data.

This expansion will be accomplished by defining additional layers of

detail within the constraints and patterns of interconnection established by

the process descriptions. Comparable aspects of DP system activities will be

grouped within the same layer. For example, plugging a cable into a terminal

on one end and a modem on the other requires physical standards for pin

configurations and connector dimensions. This, and all other mechanical

interactions, would be included in descriptions of the "physical control"

layer of the model. The subsystems represent the breadth of DP activities;

the layers of detail represent the depth of description.

Much of the subsequent discussion of layers may not be familiar to the

nontechnical reader. However, for the purposes of this report, it is only

necessary to have a general understanding that information about DP activities

can be meaningfully separated into layers of description.

The interactions (flows) between the blocks in each subsystem are

the key to incorporating additional information into the descriptive model

framework. The layers that will be used to relate the important characteristics of each flow are the seven layers of communication standards defined by

the International Standards Organization (ISO). This structure was selected

because it is compatible with existing standards and covers anticipated future

standards

.

24
A brief description for each layer is as follows:

(7) process control - the high-level events and steps in a data

processing procedure, including the personnel, DP equipment,

software, and data involved.

(6) presentation control - functions relating to character sets,

character encoding, and the presentation of character data.

(5) session control - procedures for establishing the rules for

how a dialogue will take place between two elements (which

machine will speak and in what sequence),

(4) transport end-to-end control - integrity controls for the flow

of transactions between two user devices and/or computers,

insuring completeness of transmission.

(3) network control - procedures for establishing a route for data

through a shared network (a "virtual circuit") and for transmitting data through the network.

(2) link control - procedures for sending blocks of data over a physical transmission line.

(1) physical control - specifications for mechanical, electrical,

or other physical interconnections that establish a transmission link between two devices.

Table V-A shows these layers, and lists some of the elements and processes

found in each.^ For example, in this breakdown, an ASCII character set

is one of the character set options under layer 6 (presentation control), and

the use of ASCII would be recorded as a layer 6 detail of the descriptive

model. The subsystem descriptions presented earlier have involved only layer

7 (process control).

These layers apply to all system interfaces. For example, for the clerk

in Figure B-2 to use a terminal to communicate with a computer, or for any of

the flows in the subsystem description to exist, a "compatible" linkage must

be established between terminal and computer at each of the seven layers.

Compatibility means the specification, at each layer, of the procedures in use. For some of the layers, few, if any, of the procedures may be relevant

to the interconnection. For example, layer 3 (network control) procedures do

not apply to most timesharing computer users who dial the computer center

directly.

The level of the interface layer is indicated by the number in parentheses.

From [MART-80] , but "character sets" and "data representations" have

been added to clarify points for this descriptive model. Reprinted with

permission (see references)

.

25
TABLE V-A

SEVEN ISO LAYERS

7. PROCESS CONTROL

APPLICATION & APPLICATION SYSTEM

ACTIVITIES

DATA REPRESENTATIONS (ABBREVIATION & CODING)

OPERATOR FUNCTIONS

DISTRIBUTED FILE & DATABASE

6. PRESENTATION CONTROL

CHARACTER SETS

DATA FORMATS

DATA TRANSFORMATIONS

EDITING

COMPACTION

CRYPTOGRAPHY

VIRTUAL DISPLAY SPACE, ETC.

5. SESSION CONTROL

ACTIVATE AND DEACTIVATE SESSIONS

BIND

ENFORCE DIALOGUE CONTROL

CHECKPOINTING & RECOVERY

4. TRANSPORT END-TO-END CONTROL

DATA ASSURANCE

PACKETIZING, ADDRESSING,

FLOW CONTROL

tJETWORK- INDEPENDENCE INTERFACE

3. NETWORK CONTROL

X.25 PACKET LEVEL

INTERFACE TO NETWORK

2. LINK CONTROL

HDLC, ADCCP

1. PHYSICAL CONTROL

V.24, V.25, EIA RS 232C, EIA RS 366

X.21, X.21 BIS

From [MART-80], but "character sets" and "data representations" have

been added to clarify points for this descriptive model. Reprinted with

permission (see references)

.

26
To adapt the ISO layers concept for this descriptive model, the concept

must be broadened. For instance, ISO layer 3 (network control) covers the

establishment of "virtual circuits" in computer networks. The descriptive

model layer 3 includes much simpler cases such as a clerk' s dialing the phone

number of the computer center or an installer's connecting a hard-wired cable

at one point in time. As another example, layer 1 (physical control) often

implies the use of a standard 25-pin electrical connector. However, in the

broader context of the descriptive model, it can mean any physical interface

such as the sound waves carrying data between an acoustic coupler on a terminal

and a telephone receiver (an energy linkage) or one employee handing a piece

of paper to another (a physical, "touching" linkage).

Possible interfaces at the different descriptive layers could be described

at great length, and a later phase of this effort may cross-reference the set

of Federal Information Processing Standards to the descriptive model subsystems

and produce some interface specifications. The present purpose is simply to

show that the descriptive model concept is not limited to descriptions of DP

procedures. All kinds of data about computer systems may be incorporated into

the descriptive model, in an organized fashion, by employing the micro layers

of description outlined above.

C. Macro Layers of Description

Certain broader questions of interest to Federal DP activities cannot be

represented within the seven-layer framework, and an expansion to higher

levels is needed. For example, subsystem 1 (transaction aggregation) indicates

that transaction documents are received and keypunched but does not imply what

kind of information contained in the transactions. In the application

illustrated in Figure IV-1, purchase order processing, expense information is

contained in the transactions. However, subsystem 1 transactions could

contain other types of information such as stock level changes. As indicated

in the Chapter IV examples, the information flowing through the system can change as additional processing is performed, depending on who interprets the

data and in what context. For example, repair action information from an airbase, after much processing and aggregation, eventually becomes budget

planning information. Layer 8 (information) will be designated for any

discussion of the interpretation of the data items covered in the descriptive

model.

The benefits of standards and guidelines that affect the accuracy and

integrity of computer processing, most notably those related to computer

security, will primarily depend on the actions taken, and the decisions made,

based on the data. The value of the benefits will depend on the financial or other impacts of those actions and decisions. Discussion of such actions and

decisions will be assigned to layer 9 (decisions).

Decisions are generally made in the context of one or more business or organizational functions, and layer 10 (organizational functions) is designated

for information on organizational functions such as production, accounting,

personnel, R&D, etc. Finally, layer 11 (organizational environment) is

provided to describe the organizational environment that both constrains and

motivates DP activities.

27
Table V-B shows the complete 11 layer hierarchy designed to organize

DP information in the context of the descriptive model. While the higher

numbered layers will not be utilized immediately, they are defined here to

insure that a robust model structure will be available when needed. The next

sections further elaborate the multi-layer concept.

D. Security Considerations

The descriptive model does not explicitly include computer security.

However, combining the flow diagrams and the multi-layer hierarchy provides a different approach to categorizing and modeling security issues.

Figure V-1, [WARE-79], is a widely used representation of computer

system vulnerabilities. It provides an overview of threat or "leakage" points

for computer systems. These are areas where a system designer must provide

protective features to safeguard information against both accidential and

deliberate events. They may be classified into five major categories:

physical surroundings, hardware, software, communication links, and organizational aspects (personnel and procedures).

In terms of the definitions given earlier, it is evident that Figure V-1

contains a mixture of elements from different descriptive layers. Categorizing

both threats and system vulnerabilities in terms of the applicable descriptive

layers makes a comprehensive and organized treatment of computer security

possible. Heretofore, the literature has been characterized by a plethora of

ad hoc, overlapping, and incomplete security categories, which have varied

with the interests of the author. The combination of subsystem flow diagrams

(covering the breadth of DP activity) and a multi-layer descriptive framework

(covering the depth of DP activity) can both absorb the various existing

security schema and provide a basis for analysis.

In any functioning DP subsystem, communication between layers occurs at

many of the interfaces between data flows (the lines in the subsystem flow

diagrams) and subsystem elements (the boxes in subsystem diagrams — processing

or action steps, and storage media). When a user enters data at a terminal by

striking a key (layer 1), the terminal translates that action into a string of

bits in accordance with the ASCII standard or some other defined character set

(layer 6), other bits may be added if intermediate levels (2 through 5) are active, and the bit stream is translated into electrical impulses (layer 1),

Between instances of communication between layers, activities or data flows in

all active layers are considered to occur simultaneously and in parallel.

This conceptualization leads to several principles:

o To compromise a system, a perpetrator must be able to detect (and

correctly interpret) data flows of interest at all layers between 1 and

8 that are in use at his point of system access.

o To manipulate a system, a perpetrator must be able to compromise the

system and also influence or control at least one layer at one point in

a subsystem.

28
TABLE V-B

MACRO Mm MICRO LAYERS OF DESCRIPTION

Layer

11

10

9

8

7

6

5

4

3

2

1

(MACRO)

(PROCEDURAL)

(MICRO)

Title

ORGANIZATIONAL ENVIRONMENT (GOALS, RESOURCES,

CHARACTERISTICS)

ORGANIZATIONAL FUNCTIONS

DECISIONS

INFORMATION

PROCESS CONTROL ^

PRESENTATION CONTROL

SESSION CONTROL

TRANSPORT END-TO-END CONTROL

NETWORK CONTROL

LINK CONTROL

PHYSICAL CONTROL

The subsystem descriptions in this report represent the process

control layer.

29
0)u3

txO H I PdIo

30
o To disrupt a system, a perpetrator needs only to disrupt any one layer,

which may be accomplished by destroying data, inserting noise, or severing linkages. It is not necessary for the perpetrator to possess

the in-depth knowledge of system processing that might be required to

accomplish a compromise or manipulation,

o Errors and omissions need occur only at one level, like disruptions.

As an illustration, to compromise a system by wiretapping, a perpetrator

must be able not only to detect the electrical impulses in the phone line

(layer 1) but also correctly interpret those impulses as characters (layer 6)

in order to gain information (layer 8). Secure encryption prevents the

perpetrator from correctly interpreting any text (in layer 6) to get to the

information desired (in layer 8). It is more difficult to manipulate a system

by interrupting telephone communications. The perpetrator has to not only

insert new signals but also have full knowledge of the higher layers if the new signals are to have the desired effects on, say, the data presentation

(layer 6), while not affecting any intervening layers in a way that can be

detected.

To disrupt a system communication, the perpetrator need only cut the

telephone line or inject noise into it (layer 1); there is no need to

manipulate or compromise the higher numbered layers. More extensive disruptions require either more extensive or more critical physical destruction, or an ability to manipulate the lower layers so as to disrupt the system at

higher layers. An instance of the latter is the submission of a program that

in fact "takes over" an operating system.

Detected errors or omissions are in general a form of disruption — they cause additional work to be performed to straighten them out, and they slow

down operations. Undetected errors and omissions are like manipulations —

they cause improper actions as they flow through a system.

In addressing security issues, layers 9 through 11 must be considered

twice — once for the perpetrator and once for the victim organization. The

first instance involves the perpetrator point of view and addresses the costs

and benefits of attacking the system; the second addresses both the costs of

protecting the system from attack and the potential losses from not protecting

the system, using the organization's point of view. Both sets of costs and

benefits must be considered in the selection of security measures.

Both threats and protective measures can be cross-indexed in terms of

subsystems and descriptive layers. This provides a powerful tool for security

analysis, and is an illustration of how security issues may be incorporated

into these descriptive models.

E. Presentation Methods

The set of descriptive flow diagrams presented in Appendix B can be used

for more visually-oriented presentations of the impacts of standards.

31
Figure V-2 illustrates how the impacts of a hypothetical standard could be cross- referenced to points of impact in the descriptive model. This illustration

shows only the aggregate totals for major impact areas, but other headings,

such as detailed impact areas, 3 could be used if more space were available.

While the "Impact Areas" columns contain dollar impacts, the "Impact

Descriptions" columns contain commentary text. The "Specific Impacts" column

would show which system characteristics would be influenced by the standard in

order to achieve the projected impacts. The "Measurements" column would list

the data characteristics to be measured, the data to be collected, the

methodology to be employed in data collection and analysis, and estimates of

probable error.

Another use for this type of format would be to cross-reference impact

categories and different standards and guidelines in a family or even different

families. Such a presentation would highlight possible cross-impacts and

indicate the need to explore whether the standards were complementary or in

conflict. Standards could also be grouped by other criteria such as the

descriptive layer affected or the specific points of impact in each subsystem.

Table A-1 in Appendix A lists impact areas.

32
w

too

(Hi UHOH

PQMooMHZUu

pa>u3

bO <OHHZ

x:i

()isia

aDVHOIS

XdOO

ONIXHOM

sxNawnDoa

aSHSIMII

DNiiiaa

N33^DS ONV

AMNa IX3I

aAIXDVH31NI

(H3indW0D0HDIW)

ONISSSDOHd

ixax z

-a o c co

4-1 00c

•H a

•H

)-i cu -o ^

Q) CO

:s C "

(U OJ u *-> U 3

n) 4-1 12 -H

4-1 >, CO X) cM

T3

0) 4J CL C o cu rH E

0)> o

a) I—i

TD CU>

4-1 0) & Q

Q)U <U O CCE

CO >-i O C M-i O 5-1 0) T3 P-i (DCO !-i

CT3

O

PQ iw

X

00HM

CO

td

H Z CO w 0

pa

u

33
VI. CONCLUSION

A. Summary of Phase I Report

This report has presented flow-diagram descriptions for a set of DP

operational subsystems. These diagrams and the specifications for the subsystems are the basic elements for a descriptive model of Federal DP

operational activities. The subsystems serve as building blocks for computer

applications. Different applications can comprise the sane combinations of

subsystems — the processing can be similar even though the data items are different and serve different parts of an organization.

It will be useful for analytical purposes to associate information about

system standards and guidelines and their impacts with the descriptive model.

This may be accomplished through use of the multiple descriptive layers

presented Chapter V. The layers characterize interfaces between elements in

the descriptive flow diagrams. The concept is particularly useful for analyzing security issues, since security violators generally must access a system

using the same types of interfaces as system users, and analysis by layers

allows a more precise treatment of those interfaces. A brief overview was given of potential uses of the descriptive model for presenting interrelationships between DP systems and standards.

B. Future Work

During later study phases, the breadth of the Phase I descriptive models

will be extended by the preparation of additional descriptive models for

hardware acquisition, software acquisition, application software development,

data resources planning, security, and overall DP management. Eventually, all

secondary areas shown in Figure I-l should be developed to a stage comparable

to the model presented in this report for DP operations.

The focus of the Phase II effort is the development of descriptive models

for applications software development. The Phase II model traces the unifying

flow from initial problem to ultimate software solution, and intersects the

Phase I model in subsystem 13, which in turn may intersect the remaining 12

subsystems at any point where in-house software is utilized. In addition, a parallel effort on a security-related descriptive model is now underway.

3A
REFERENCES

[ALTE-75] Alter, Steven. "A Study of Computer Aided Decision Making in

Organizations," Ph.D. dissertation, Sloan School of Management,

M.I.T., 1975

[ALTE-77] Alter, Steven, "A Taxonomy of Decision Support Systems", Sloan

Management Review , (Volume 19, Number 1), Massachusetts Institute

of Technology, Fall 1977, pp. 39-56. [overview and summary of key

results from the 1975 work]l

[ANSI-71] American National Standard Flowchart Symbols and Their Usage in

Information Processing (ANSI X3. 5-1970), American National Standards

Institute, Inc., New York, 1971

[FIOR-78] Fiorello, M. and Jaffin, S, Costs and Benefits of Federal

Automated Data Processing Standards; Guidelines for Analyses and

Preliminary Estimating Techniques , Logistics Management Institute,

Washington, D.C., 1978

[FIOR-81] Fiorello, M. "Preliminary FIPS Cost-Benefit Guidelines:

Assessment and Improvements" (Draft Working Note for ICST),

May 1981

[ICST-73] Flowchart Symbols and Their Usage in Information Processing . Federal Information Processing Standards Publication 24 (FIPS PUB

24), Institute for Computer Sciences and Technology, June 30, 1973

[MART-80] Martin, J. "The New DP Revolution" (James Martin Seminar)

Technology Transfer Institute, Los Angeles, Spring 1980^

[NAKA-82] Nay, J. and Kay, P. Government Oversight and Evaluabillty

Assessment , Lexington Books, D.C. Heath and Company, Lexington, MA,

1982

[WARE-79] Ware, W.H., ed. Security Controls for Computer Systems , Report

R-609-1, Rand Corporation, Santa Monica, California, October 1979

Labeling schemes (p. 7), portions of Table IV-A (p. 21), and other [ALTE-77]

excerpts, were reprinted from [ALTE-77] by permission of the publisher.

Copyright 1977 by the Sloan Management Review Association. All rights

reserved

.

Table V-A (p. 26) reprinted from [MART-80] by permission of the publisher.

Copyright 1980 by the Technology Transfer Institute. All rights reserved.

35

APPENDIX A

BASIC COST-BENEFIT ANALYSIS

METHODOLOGY

APPENDIX A

BASIC COST-BENEFIT ANALYSIS METHODOLOGY

1. Specifying the Goals and Objectives for the Standard . Identifies which

ICST goal(s) and objectives(s) the prospective standard is expected to

contribute to and achieve, respectively.

2. Preparing the Standards Definition Statement . Summarizes all the

essential information about the standard necessary to conduct the costbenefit analysis. At a minimum this includes:

- How the standard will be developed, used and supported.

- Essential assumptions and information for the cost and benefit

estimates submitted.

- The historical data trail on the evolution of the standard's design

and development and the corresponding impact and cost estimates from

the beginning to the formal implementation of the standard. The trail

is provided by the chronological sequence of updated definition

statements

.

- A basis for a critical review of the standard's objectives and a discussion on how well the proposed design and development process

will satisfy them.

- Descriptions of the areas of high technological risk and cost-benefit

uncertainty.

The statement can also reference selected information in the backup

material that documents the cost and benefit estimates. Each time a cost-benefit analysis is prepared, a Standards Definition Statement will

also be prepared. In this way, the statement provides a readily

available audit trail and a basis for critical review of the standard.

3. Defining the Base Case . Defines the status quo for those cost-benefit

impact dimensions relevant to the standard. The base case can be defined

for one or several FIPS that are under consideration. The several

FIPS case would occur where the impacts from two or more alternatives tend

to overlap, and the individual impacts are not readily distinguishable.

It also provides a basis for the projection of future conditions if the

standard is not developed and implemented.

Based on the 1978 preliminary guidelines for impact assessments of

standards [FIOR-78].

A-1
4. Selecting the Cost-Benefit Impact Areas . Specifies cost and benefit

Impact areas relevant to the standard, A standard will require certain

costs for development, Implementation, validation and maintenance. In

addition, there are costs that can be Incurred by the Federal ADP

installations that utilize the standard. On the benefit side, a standard

will typically tend to have its major economic impacts in one of three

areas: procurement, operations, or conversion. These impact areas and

elements further delineate how a standard contributes to the ICST goals

and objectives concerned with achieving economies in ADP procurement,

operations, and conversion. Table A-1 gives the list of impact areas.

5. Constructing the Cost-Benefit Analysis Model . Provides the appropriate

model form to quantify the cost and benefit impacts expected of the

standard. The model is used to estimate the flows of costs and benefits

attributable to the standard over time. Adjustments for the time value of

money can be incorporated in the model by using appropriate discount

factors.

6. Obtaining Data . Collects the data to perform the analysis. In addition

we expect to utilize the data and analyses from the cost-benefit analysis

of selected, individual standards.

7. Estimating and Evaluating the Cost-Benefit . Represents the consolidation

of the qualitative and quantitative analyses performed up to this point.

The basis of the cost-benefit analysis will be the generation of the base

-case parameters and the computation, within specific confidence intervals,

of the effect a new standard scenario will have on cost levels. The

techniques used to generate the figures comprising the base case address

the areas of: (1) level of expected resource consumption, (2) Federal

ADP installation's unit cost for each resource, and (3) projected

impact(s) of the proposed ADP standard. To aid in this process, cost

element equations will be used. To determine the net cost-benefit impact

of a FIPS, the costs to the Federal Government (specifically ICST) of

developing and implementing the FIPS will be defined and incorporated into

the analysis.

8. Presenting and Interpreting the Results . Translates the cost-benefits

attributable to the FIPS in the context of the Federal agencies that are expected to be impacted by the standard. This step is crucial as it

specifies whether actual budget dollars will be changed (such as in

procurement impacts) or whether the impacts are productivity changes (such

as when a resource is freed up for other activities).

A2
TABLE A-1

COST-BENEFIT IMPACT ELEMENTS

100 PROCUREMENT

101 Hardware

102 Software

103 Testing

104 Planning & Analysis

105 Initial Training

106 Documentation

107 Installation

200 OPERATIONS

201 Operating

202 System Management

203 Maintenance

203.1 Hardware Maintenance

203.2 Software Maintenance

204 Programming

205 Ongoing Training

206 Facilities

207 Security Provisions

300 CONVERSION

301 Program Transfer

302 Retrofit

400 SYSTEM PERFORMANCE

401 Computer System

402 Applications Software

403 System Users

500 COMPUTER MISUSE

501 Errors and Omissions

502 Computer-Related Fraud and Embezzlement

503 Privacy Intrusion

504 Alteration of Computer Records

505 Theft of Computerized Information

506 Unauthorized Usage

507 Denial of Service

508 Equipment Damage

A3

APPENDIX B

SUBSYSTEM DESCRIPTIVE MODELS

APPENDIX B

SUBSYSTEM DESCRIPTIVE MODELS

CONTENTS

Page

Overview B-(ii)

Exhibit

B-1 Key to Illustrations B-(iii)

B-2 Summary of Flowchart Symbols B-(iv)

Figure Subsystem Flow Diagram

B-1 Transaction Data Capture B-1

B-2 Transaction Data Aggregation B-2

B-3a Recordkeeping (on-line, deferred update) B-3a

B-3b Recordkeeping (on-line, immediate update) B-3b

B-4 Transaction Disbursement B-4

B-5 Technical Data Preparation B-5

B-6 Automated Data Capture B-6

B-7 Analysis and Reporting B-7

B-8 Data Retrieval and Analysis B-8

B-9 Data Combination, Analysis, and Reduction B-9

B-10 Specialized-Data Model Execution B-10

B-11 Integrated-Data Model Execution B-11

B-12 Computer-Aided Task Performance B-1

2

B-13 Software Development (procedures that affect

DP operations) B-13

B-(i)
APPENDIX B

SUBSYSTEM DESCRIPTIVE MODELS

Overview

This Appendix contains flow diagrams to illustrate representative

processing procedures for the 13 operational subsystems defined in the

text.

These flow diagrams are a breakdown of Data Processing Operations as represented in Figure I-l , and may be viewed as existing in that larger

context. Technology variations and interactive vs. batch options are shown

where appropriate within each flow diagram, with the exception of subsystem 3

(recordkeeping), where two separate flow diagrams were used to represent the

differences between "standard" and DBMS processing. Exhibit B-1 introduces

the symbols used in the flow diagrams and notes extensions to the standard

sj^bols shown in Exhibit B-2,

B-(ii)
Exhibit B-1. KEY TO ILLUSTRATIONS

The subsystem flow diagrams in this Appendix have been prepared in

accordance with FTPS PUB 24 [ICST-73], which adopts the flowchart symbols

specified in [ANSI-71]. However, for the purposes of these flow diagrams, the

extensions noted below were necessary to provide uniformity and clarity of

representation. Please refer to Exhibit B— 2 for a summary of the standard

symbols

.

(ANNOTATIONS) and COMMENTS

Interfaces between users and

subsystems

The combination of "manual input" and

"display" shown here represents any

user-interactive terminal , which may be

a CRT, printing terminal, or CRT with

attached printer. The symbol may have

either a left- or right- orientation

in order to face the illustration of a user in a flow diagram.

The on-line storage symbol is used to

represent either tape, disk, or other

storage media accessible on-line, in

accordance with FTPS PUB 24. However,

its usage includes instances where the more specific magnetic disk symbol

would have been more correct. This was

done in order to reserve the magnetic

disk symbol for the emphasis of particular technology variations and/or

database random access in the appropriate

subsystems

.

(DISPLAY)

USER

(MANUAL INPUT)

(ON-LINE STORAGE)

B-(iii)
Exhibit B-2. Summary of Flowchart Symbols

Basic Symbols

Input/Output Process Flowline

Crossing of Flowlines

Junction of Flowlines Annotation, Comnnent

Specialized Input/Output Symbols

Punched Card

Deck of Cards

File of Cards

Online Storage

Magnetic Tape

Punched Tape

Magnetic Disk

Core

Document

Manual Input

Display

Communication

Link

Magnetic Drum Offline Storage

From [ANSI-70]

B-(iv)
Exhibit B-2. Summary of Flowchart Symbols

Specialized Process Symbols

(Continued)

Decision

Predefined

Process

Preparation

Manual

Operation

Additional Symbols

Connector

Parallel Mode

B-(v)
I

I
B-1
B-2
P ill

p.3

0)

t-l 0)

0)

0)

iHI coM

Ph5o

CO mI «

0)u3

&0

•H

n

CO

U

M

H

Q

CH AN o H a H < z M 1—1 O M pa M ij J z M w

EE

u 6 EM

MU

H <

era EM RD

u YS

Q o H o H (/: w u AN CO O

SUB RE SY SY LO o

B-3
B^4
B-5
B-6
I

a;u

3

B-7
u

o

2 MOD

1

REPORT]

O

PROGl c ?SIMP 1

DECISION

B-8
B-9
o

u

2:

COHW

to

cM

H

U

Q

cnM

<

oM

o

<

ON

I P3

(U

1-4 D

oo

•H

B-10
B-11
en

H Pi

H

Q OS Z w w W

H >- H H M

OM 1^

M O" PtS

u i-J

U z M < H w Pi 8 H O 3: w M H < O M

Pd

uu

Q • >>J s < < U o > o M CO M Pi X H H < in

ER Pi ZM

w

U

Pi

B > u

H ^ W fx. ^ M H o M < H W H CO M> tnZ Mz MZ FA

VE

HO

U o 1 o M

Q

RA

H z P3

pt; o w u w hJ H u H < hJ

EX

M

PQ

M

M > M 3

I-J uu

Pi

PQHCO

B-12
CNII PQ

(UUa

60 • to

CO

wo 0 o (X

2: CO 0 H w H M OS

to :s w M 0 w H z

COw • >- M

•—(

C/2 I—( 0M W 1 p H PS Z M < M iJ CO 1 1=1 0 z f—1 0

MS

M

w

H

H

CO

n

MU

w

H

M

w

c/:

H

g

CO 5 w

M

B-13
u

B-14
NBS-n4A (REV. 2-8C) U.S. DEPT. OF COMM.

BIBLIOGRAPHIC DATA

SHEET (See instructions)

1. PUBLICATION OR

REPORT NO.

NBS SP 500-100

2. Performing Organ. Report No. 3. Publ ication Date

January 1983

4. TITLE AND SUBTITLE

Computer Science and Technology

Toward an Improved PIPS Cost-Benefit Methodology,

Phase I: Descriptive Models - Data Processing Operations

5. AUTHOR(S) M. Fiorello and P. Eirich Peg Kay

Fiorello, Shaw and Associates Institute for Computer Sciences and Technol-

-ogy, NBS

6. PERFORMING ORGANIZATION (If joint or other than NBS. se^ instructions)

| 7. Contract/Grant No. (l) Fiorello, Shaw and Associates (2) Natl. Bureau of Standards

6802 Poplar Place, Suite 305 Department of Commerce

McLean, Va. 22101 Washington, D. C. 20234

8. Type of Report & Period Covered

Final

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City, State. ZIP)

Same as No. (2) of Item 6 above.

10. SUPPLEMENTARY NOTES

Library of Congress Catalog Card Number: 82-600657

Document describes a computer program; SF-185, FIPS Software Summary, is attached.

11. ABSTRACT (/A 200-word or less factual summary of most si gnificant information, if document includes a significant

bi bliography or literature survey, mention it here)

This report presents a set of functional-flow descriptive models that can be used

to categorize the operational activities of Federal data processing users. Data

processing applications may be conceptually represented in descriptive model form

by combining one or more of the basic models. The comprehensive framework for data

processing operations provided by these descriptive models can be used in the

identification of impacts from standards and guidelines and in the preparation of

cost-benefit impact assessments. The framework provides both macro and micro levels

of detail in order to link the descriptive models to additional data processing

issues, such as computer security issues.

12. KEY WORDS (Six to twelve entries; alphabetical order; capitalize only proper names; and separate key words by semicolons)

computer security; computer standards; cost-benefit analysis; data processing management; data processing operations; data processing standards; descriptive models;

impact assessment; information systems.

13. AVAILABILITY

rjTI Unl imited

I I For Official Distribution. Do Not Release to NTIS

&n Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C.

20402.

Order From National Technical Information Service (NTIS), Springfield, VA. 22161

14. NO. OF

PRINTED PAGES

68

15, Price

$5.00

USCOMM-DC 6043-P80

ANNOUNCEMENT OF NEW PUBLICATIONS ON

COMPUTER SCIENCE & TECHNOLOGY

Superintendent of Documents,

Government Printing Office,

Washington, DC 20402

Dear Sir:

Please add my name to the announcement list of new publications to be issued in the

series: National Bureau of Standards Special Publication 500-.

Name

Company

Address

City State Zip Code

(Notification key N-S03)

U.S. GOVERNMENT PRINTING OFFICE : 1982 O—380-997 (2390)

NBS TECHNICAL PUBLICATIONS

PERIODICALS

JOURNAL OF RESEARCH—The Journal of Research of the National Bureau of Standards reports NBS research and develop- ment in those disciplines of the physical and engineering sciences in which the Bureau is active. These include physics, chemistry,

engineering, mathematics, and computer sciences. Papers cover a broad range of subjects, with major emphasis on measurement

methodology and the basic technology underlying standardization. Also included from time to lime are survey articles on topics

closely related to the Bureau's technical and scientific programs. As a special service to subscribers each issue contains complete

citations to all recent Bureau publications in both NBS and non- NBS media. Issued six times a year. Annual subscription: domestic

$18; foreign $22.50. Single copy, $5.50 domestic; $6.90 foreign.

NONPERiODICALS

Monographs—Major contributions to the technical literature on

various subjects related to the Bureau's scientific and technical activities. Handbooks—Recommended codes of engineering and industrial practice (including safety codes) developed in cooperation with in- terested industries, professional organizations, and regulatory

bodies. Special Publications—Include proceedings of conferences sponsored by NBS, NBS annual reports, and other special publications

appropriate to this grouping such as wall charts, pocket cards, and

bibliographies.

Applied Mathematics Series—Mathematical tables, manuals, and

studies of special interest to physicists, engineers, chemists,

biologists, mathematicians, computer programmers, and others engaged in scientific and technical work.

National Standard Reference Data Series—Provides quantitative data on the physical and chemical properties of materials, compiled from the world's literature and critically evaluated. Developed under a worldwide program coordinated by NBS under

the authority of the National Standard Data Act (Public Law

90-396).

NOTE: The principal publication outlet for the foregoing data is the Journal of Physical and Chemical Reference Data (JPCRD)

published quarterly for NBS by the American Chemical Society

(ACS) and the American Institute of Physics (AlP). Subscriptions,

reprints, and supplements available from ACS, 1 155 Sixteenth St., NW, Washington, DC 20056.

Building Science Series—Disseminates technical i- formation developed at the Bureau on building materials, components,

systems, and whole structures. The series presents research results,

test methods, and performance criteria related to the structural and

environmental functions and the durability and safety characteristics of building elements and systems.

Technical Notes—Studies or reports which are complete in themselves but restrictive in their treatment of a subject. Analogous to monographs but not so comprehensive in scope or definitive in treatment of the subject area. Often serve as a vehicle for final reports of work performed at NBS under the sponsorship of other government agencies.

Voluntary Product Standards—Developed under procedures

published by the Department of Commerce in Part 10, Title 15, of

the Code of Federal Regulations. The standards establish nationally recognized requirements for products, and provide all concerned interests with a basis for common understanding of the

characteristics of the products. NBS administers this program as a supplement to the activities of the private sector standardizing

organizations. Consumer Information Series—Practical information, based on NBS research and experience, covering areas of interest to the con- sumer. Easily understandable language and illustrations provide

useful background knowledge for shopping in today's tech- nological marketplace. Order the above NBS publications from: Superintendent of Documents, Government Printing Office. Washington, DC 20402. Order the following NBS publications—FIPS and NBSIR s—from

the National Technical Information Service, Springfield, yA 22161

.

Federal Information Processing Standards Publications (FIFS

PUB)—Publications in this series collectively constitute the Federal Information Processing Standards Register. The Register

serves as the official source of information in the Federal Govern- ment regardmg standards issued by NBS pursuant to the Federal Property and Administrative Services Act of 1949 as amended.

Public Law 89-306 (79 Stat. 1127). and as implemented by Executive Order 1 1717 (38 FR 12315, dated May 1 1, 1973) and Part 6 of Title 15 CFR (Code of Federal Regulations).

NBS Interagency Reports (NBSIR)—A special series of interim or

final reports on work performed by NBS for outside sponsors

(both government and non-government). In general, initial dis- tribution is handled by the sponsor; public distribution is by the National Technical Information Service , Springfield, VA 22161,

in paper copy or microfiche form.
U.S. Department of Commerce

National Bureau of Standards

Washington, D.C. 20234

Official Business

Penalty for Private Use $300

POSTAGE AND FEES PAID

U S. DEPARTMENT OF COMMERCE

COM-215

THIRD CLASS BULK RATE