/

NBS TECHNICAL NOTE 832

U.S. DEPARTMENT OF COMMERCE/ National Bureau of Standards

Report on Planning Sess

on Software Engineering

Handbook

I oo

X5153
NATIONAL BUREAU OF STANDARDS

The National Bureau of Standards' was established by an act of Congress 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 consists of the Institute for Basic Standards, the Institute for Materials Research, the Institute for Applied Technology,

the Institute for Computer Sciences and Technology, and the Office for Information Programs.

THE INSTITUTE FOR BASIC STANDARDS provides the central basis within the United

States of a complete and consistent system of physical measurement; coordinates that system

with measurement systems of other nations; and furnishes essential services leading to accurate and uniform physical measurements throughout the Nation's scientific community, industry,

and commerce. The Institute consists of a Center for Radiation Research, an Office of Measurement Services and the following divisions: Applied Mathematics — Electricity — Mechanics — Heat — Optical Physics — Nuclear

Sciences - — Applied Radiation - — Quantum Electronics n — Electromagnetics 3 — Time

and Frequency s — Laboratory Astrophysics ' — Cryogenics \

THE INSTITUTE FOR MATERIALS RESEARCH conducts materials research leading to improved methods of measurement, standards, and data on the properties of well-characterized materials needed by industry, commerce, educational institutions, and Government; provides

advisory and research services to other Government agencies; and develops, produces, and

distributes standard reference materials. The Institute consists of the Office of Standard

Reference Materials and the following divisions: Analytical Chemistry — Polymers — Metallurgy — Inorganic Materials — Reactor

Radiation — Physical Chemistry.

THE INSTITUTE FOR APPLIED TECHNOLOGY provides technical services to promote

the use of available technology and to facilitate technological innovation in industry and Government; cooperates with public and private organizations leading to the development of

technological standards (including mandatory safety standards), codes and methods of test; and provides technical advice and services to Government agencies upon request. The Institute consists of a Center for Building Technology and the following divisions and offices: Engineering and Product Standards — Weights and Measures — Invention and Innovation —• Product Evaluation Technology — Electronic Technology — Technical Analysis — Measurement Engineering — Structures, Materials, and Life Safety * — Building

Environment * — Technical Evaluation and Application * — Fire Technology.

THE INSTITUTE FOR COMPUTER SCIENCES AND TECHNOLOGY conducts research and provides technical services designed to aid Government agencies in improving cost effec- tiveness in the conduct of their programs through the selection, acquisition, and effective

utilization of automatic data processing equipment; and serves as the principal focus within

the executive branch for the development of Federal standards for automatic data processing

equipment, techniques, and computer languages. The Institute consists of the following

divisions: Computer Services — Systems and Software — Computer Systems Engineering — Information Technology.

THE OFFICE FOR INFORMATION PROGRAMS promotes optimum dissemination and

accessibility of scientific information generated within NBS and other agencies of the Federal Government; promotes the development of the National Standard Reference Data System and

a system of information analysis centers dealing with the broader aspects of the National Measurement System; provides appropriate services to ensure that the NBS staff has optimum

accessibility to the scientific information of the world. The Office consists of the following

organizational units: Office of Standard Reference Data — Office of Information Activities — Office of Technical

Publications — Library — Office of International Relations.

1 Headquarters and Laboratories at Gaithersburg. Maryland, unless otherwise noted; mailing address Washington, D.C. 20234.

3 Part of the Center for Radiation Research.

3 Located at Boulder, Colorado 80302.

4 Part of the Center for Building Technology.
.3

Report on Planning Session on

Software Engineering Handbook

Selden L. Stewart, Editor

Systems and Software Division

Institute for Computer Sciences and Technology

J ,S< National Bureau of Standards

Washington, D.C. 20234

£._

\gl(i\as\\(±oJ v\(y\ei r\c- ^33-

.er*T OP -

%

*0 J

°*Eau of

U.S. DEPARTMENT OF COMMERCE, Frederick B. Dent, Secretary

NATIONAL BUREAU OF STANDARDS, Richard W. Roberts, Director

Issued November 1974
Library of Congress Catalog Card Number: 74-600091

National Bureau of Standards Technical Note 832

Nat. Bur. Stand. (U.S.), Tech. Note 832, 18 pages (Nov. 1974) CODEN: NBTNAE

U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON: 1974

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. 20402 (Order by SD Catalog No. C13.46:832). Price 70 cents.
TABLE OF CONTENTS

Page

rLDS Cx (3CC

•••••••*••••• J.

1.0 Introduction .......... 1

2.0 General Discussion of Contents ...... 4

2.1 Potential Breadth of Subject ...... 4

2.2 Potential Depth of Coverage ...... 4

2 . 3 Kinds of Programs ........ 5

2.4 Desired Changes in Tools ...... 5

3.0 Potential Structuring of the Handbook ..... 6

4.0 The Next Steps ......... 6

Sponsors' Acknowledgement ........

Appendices

Appendix I. Specific Suggestions for Software Engineering

Techniques Contents ....... 8

Appendix II. Specific Suggestions for Software Engineering

Management Contents ....... 12

in

REPORT ON PLANNING SESSION ON SOFTWARE

ENGINEERING HANDBOOK

Software Engineering Handbook Planning Committee

R. G. Canning, Chairman

S. L. Stewart/ Editor

This report from a planning committee sponsored by the

National Bureau of Standards , the National Science Foundation,

and the Association for Computing Machinery discusses the need

for, coverage of, and audience for a proposed Software Engineering Handbook.

Key Words: Programming, quality software, software engineering.

1 . INTRODUCTION

A planning session was conducted in Washington, D. C. on March 4-6,

1973, as the first step in what hopefully will result in a handbook on software engineering. The planning session was conducted under the

auspices of the National Bureau of Standards , the National Science Foundation, and the Association for Computing Machinery.

Participants in the planning session included

Mr. Joel D. Aron, IBM Federal Systems Division

Mr. Anthony D'Anna, Western Electric

Dr. Edsger W. Dijkstra, Technological University Eindhoven

Dr. Dennis W. Fife, NBS

Dr. Aaron Finerman, Jet Propulsion Laboratory

Prof. Robert W. Floyd, Stanford University

Mr. John Gosden, Equitable Life Assurance Society

Mr. Harry T. Larson, California Computer Products, Inc.

Mr. Charles P. Lecht, Advanced Computer Techniques Corp.

Dr. Barbara H. Liskov, M.I.T. Project MAC.

Dr. Daniel Teichroew, University of Michigan

Mr. Richard G. Canning, Canning Publications, Inc. (Chairman)

In addition, the following sponsors were present:

Dr. D. D. Aufenkamp, NSF

Mr. Walter Carlson, IBM, representing ACM

Mr. S. Jeffery, NBS

The goals of the workshop were stated as follows: Define

What is most urgently needed?

Who is the target audience?

What should be covered in the Handbook?

Who should create it?

1
What is most urgently needed?

The participants identified two main areas of concern — first

principles for software engineering , and the managing of software engineering of software . The material should be based on an understanding

of the programmer' s decision process—what decisions the programmer is

expected to make. For each significant decision, the available alternatives should be identified , with at least a brief discussion of the

advantages or disadvantage of each alternative. The discussion should

be in terms of general principles that can be applied, ones that have

been tested in use. Guidelines should be presented for using each of

the general principles , along with examples of use, and cost-effectiveness trade-offs

.

The participants also felt that the Handbook should give recommendations on the managing of software engineering , so as to provide the

environment in which the engineering of software can best be accomplished

This material should include first principles of successful management

for R&D type projects , which can be applied to software development

projects. The material should also point out that the managerial decisions, and even the project organization , can have a significant effect

on the architecture of the software.

Who is the target audience?

The target audience for the Handbook was identified in terms of the

staff of one large business organization, as an illustrative example —

but the same situations exist in engineering and scientific programming.

In addition to job categories , the current approximate percent of total

staff was given for each category.

Category Job % of staff

A Large system architects 1

B Large system project managers 1

C Computer scientists (Ph.D.s) 1

D Business system analysts with little

knowledge of programming 10

E Professional programmers , experienced,

interested in keeping up with the

technology , have initiative to do selftraining, capable of recognizing that

others have already solved a particular

problem. 22

F Craftsmen programmers , less experienced

,

have less initiative, are less likely to

recognize that a problem has been solved
by others; willing to use a Handbook, if

directed. 44

G Dull programmers, with little or no interest or initiative; just doing a job. 22

In the next three to four years, the "center of gravity" may shift

downward from F toward the G category , based on present trends in the

organization under discussion. After that period of time, the F category

may represent only 22 percent of the total, and the G category 44 percent.

In addition, the participants recognized the growth in the number

of users who perform programming- type functions but whose job titles

are not "programmer". These people include engineers, operations

researchers, etc., who use the computer perhaps via a time sharing

terminal. So an additional category, H, might be added — the nonprofessional programmers.

RECOMMENDATION : As far as the "first principles of software engineering"

are concerned , the main target audience is the E category.

Material of interest to categories A, B, C, and D, might

also be included.

Write the Handbook so that it can be read by the category F people. (Some participants recommended that F

people be included with E people, as the main target

audience.

)

The Handbook should not be aimed at the G and H categories.

One participant commented that many people in the target audience may be

turned off by the term ''software engineering." None of the group could

estimate the impact of this on the acceptance of the Handbook, should

it be true. Another participant suggested that a "better title" is

needed. Others favored the proposed title. There was no consensus on this point.

RECOMMENDATION : As far as managing software engineering projects is concerned, the prime audience is the project manager with

from 5 to 20 people under him. The Handbook should help

him get his job done. Further, a different set of

management techniques is needed for very large projects,

employing scores to hundreds of people. This audience

probably should not be chosen as the prime target for

the Handbook.

It was observed that various levels of management between project

management and top management perhaps unknowingly can impose undesirable

pressures or constraints that influence system architecture. Management selects the approach, the programming languages , the installation

standards , the measures , and the project organization. By default,
management may become the system architect. One of the goals of the

Handbook should be to make the several levels of management aware of

these architecture-influencing decisions.

2.0 GENERAL DISCUSSION OF CONTENTS

2.1 Potential Breadth of Subject

The creation of a new software-using system involves many components

beyond the software itself. These components include the hardware,

programs for the hardware, people, and procedures for the people. The

ways in which these components are used are influenced by the technology

,

by financial considerations , by inter-organizational politics, and by

intra-organization psychology. In theory, the Handbook could address

this whole subject area.

The types of decisions involved in creating a new software-using

system includes those on the software (make or buy) , the hardware

(selecting major components , selecting minor components, etc.), procedures ("operator" procedures, interfacing with other systems, etc.)

and people. Also, the scope of the software must be defined; it can include source code, object code, documentation, firmware , logic em- bedded in LSI chips, and so on.

RECOMMENDATION: It was the consensus of the group that the Handbook

not be concerned with all of these aspects, as important as they may be to the overall success of the

new system.

Instead, the Handbook should be concerned with computer

program design, construction, and quality assurance. Computer programs include both software systems and

application programs.

2.2 Potential Depth of Coverage

It would not be desirable to aim the Handbook at too low a level of

capability. There should be no implication that "anybody can be a software engineer by using this Handbook."

At the same time, it is recognized that the majority of today's

practicing programmers received their original programming training

from computer manufacturer or employer training courses — at least,

of the F and G level programmers. Only a small percentage have received

computer science education at the masters, or even bachelors, level

.

The major portion of the software engineering portion of the

Handbook should be addressed to the level E professional programmer

,
as roughly defined above. As mentioned previously , the Handbook should be

understandable by the level F programmers . While some of the material can be addressed to the levels A, B, C, and D, such material probably should

be clearly identified as for those audiences

.

2.3 Kinds of Programs

A variety of kinds of computer programs were identified for which the

first principles discussed in the Handbook would apply. These included

applications software (scientific, engineering , business , military , space

and process control) , and systems software (operating systems, compilers

,

assemblers , data management, etc.). Further, the systems software might

be developed for an existing machine, or for a machine which itself is

still under development.

RECOMMENDATION : The same general design techniques can be used for both

application software and systems software . However, the

design decisions can be more complex for large systems

of either type.

Two types of computer programs were identified for which the

principles discussed in the Handbook probably would not apply. These

were: hybrid computation programs , and ad hoc problem solving programs

which would be used only one or two times.

2.4 Desired Changes in Tools

It was contended by one participant that the programming language

used for a given program, or set of programs, influences the way the

programmer conceives the program design. It was further contended that

the most popular existing languages—FORTRAN, COBOL, and ALGOL 60—exert

undesirable types of influence and are not appropriate vehicles for

guiding the programmer' s thought. Further, the largest gains from

software engineering will come from using more appropriate primitives

.

It was felt that the Handbook should try to force such needed changes.

It was further contended that it will be difficult to find languageindependent first principles for program design. The programming language

that is used permeates the design.

There was not a consensus on these contentions . In rebuttal to them,

it was argued that perhaps 90 percent of the first principles of program

design are language-independent . Further, regardless of opinions about

the existing languages , the fact remains that they will continue to be

used for the bulk of the programming for some years to come. The engineering of software must take into account that these languages will be

widely used.

The question of how strongly the Handbook should press for significant changes in the tools thus did not get answered at this meeting.
3.0 POTENTIAL STRUCTURING OF THE HANDBOOK

The participants saw the structure of the Handbook as consisting of

three main sections : rationale for using the Handbook (about one percent

of the total pages) , managing the engineering of software (about nine

percent of the total pages) , and software engineering (about 90 percent of

the total pages)

.

The first section would include not only the rationale for using the

Handbook but also the goals of the Handbook , how to use it, and criteria

for making design decisions . (One participant believes that one percent

of the total pages is not enough for this section.

)

The section on managing software engineering should include the "time

structure" of a software project, and first principles of successful

management of projects of this type. There was mixed opinion as to whether

professional responsibility and ethics should be included.

The software engineering section was viewed as consisting of three

parts. One would be the architecture part, dealing with the highest level

design decisions . Next would be the engineering part, the next level of

design decisions , wherein the technology is used to achieve a design that

meets the postulated criteria. Finally, there would be the construction

part, involving the lowest level of design decisions , such as the details

of program segmentation. Further details on this section are included as an Appendix.

4.0 THE NEXT STEPS

A brief discussion was conducted on how best to proceed with the

Handbook project. While a number of suggestions were advanced , there was no consensus on how best to proceed. This subject really was outside of

the charge of this planning meeting; the meeting was to concentrate on the

problem definition stage of the Handbook project, involving the aspects of

what and who , rather than how .

Since no consensus was reached , and since the sponsoring organizations

had representatives in attendance, it was agreed that these representatives

would decide on the plan of action for the next steps, based on the

recommendations made in this report.
SPONSORS ' ACKNOWLEDGEMENT

This report was prepared by Richard G. Canning, Chairman of the

NBS/NSF/ACM Planning Committee for a Software Engineering Handbook. The

committee members provided extensive supplementary material and comments

on an earlier draft of this report. All of this material will be of

assistance in the future development of a software engineering handbook.

Even though space precludes reprinting all the comments , Mr. Canning has

incorporated them in the report insofar as was practical.

The sponsors would like to thank the members of the committee for

their fine work and Mr. Canning in particular for his double duty as chairman and author of this report.
APPENDIX I. SPECIFIC SUGGESTIONS FOR SOFTWARE ENGINEERING TECHNIQUES

CONTENTS

System/Program/Pat a Architecture

Deals with defining the overall structure.

Involves selection of an architecture.

Present survey of theories on program structuring and examples of

how to use them; for instance, with combinatorial type problems

,

structure so that the number of cases adds rather than multiplies.

Present guidelines for modularizing system, programs, and data so

as to minimize chances of errors. Minimize the number of interconnections between modules.

Present concepts of structured programming and proof of correctness

.

Present survey of useful abstraction patterns and the various forms

found in computer programs , including parallelism.

Codify the constraints where the architect may have little or no freedom of choice (as in the case of the hardv/are , or operating

system) .

The data must be structured , as well as the system and the programs.

Includes both file structuring and data base structuring. Show

relationships between data modules and program modules.

System/Program/Data Engineering

Discuss criteria for judging a design: maintainability , utility,

effectiveness , availability , resilience , extensibility , defensive

design, modifiability, economics , understandability , transferability

,

reliability , simplicity , generality , and flexibility

.

Promote the understanding of: modularity , design methodology, effect

of scale (magnitude) of projects , the desire for quality software as opposed to acceptable software , identifying hardware design features

that result in unresolvable conflicts for the software , and the

ability to judge a priori if particular tools will apply to a job,

and how well.

Discuss use of models and quantitative techniques for making design

decisions

.
Discuss quality assurance. With regular design, involves a test

plan developed at the outset. With structured programming , involves

proof of correctness , where testing and integration occur throughout

construction , and not after it.

Discuss ways to adapt to changes in system specifications , providing

for change in original design via scaffolding; use of configuration

control and formal change control; repair and maintenance; patching.

System/Program/Data Construction

List of available tools:

Languages —benefits and drawbacks of particular languages

,

including data manipulation and data descriptive

languages ; how to choose a language ; some tricky

features of common programming languages

.

Operating systems—benefits and drawbacks; if choice is

available , how to choose an operating system.

Data base management system—same as operating systems.

Testing aids.

Construction aids.

List of available techniques , including pros and cons of each:

Sorting techniques

Data compression; data coding

Searching

Validation techniques

Queuing

Paging

Segmentation

Parsing

Listing processing

Query processing

Translation techniques—compilation , interpretation , generation
Implicit versus explicit data definitions

Survey of program construction techniques , with examples

example: use of "superfluous" code for mapping problem into

more manageable form.

Display technology

Benchmarking

Concurrent processing

How to interact in multi-programming environment

Effect on design of various construction techniques

Instrumentation, monitoring

Use of models for estimation of resources required and for

making design trade-offs

.

Hashing methods

Overlay techniques

Flow charting (as a design tool, more than as a documentation method) .

Decision tables

(Comment : when several alternative versions of a technique

are available , as in the case of sorting algorithms , might

present a decision table for aiding in the selection of the

most appropriate algorithm. In addition , might illustrate

by comparing several algori thms . )

(Question : how to discuss proprietary techniques , such as automatic flowcharters or program module test beds?)

List of standards and conventions, including documentation standards

National standards and conventions: ADCII , EBCDIC, etc.

Samples of typical (but good) installation standards

Useful tables

Random numbers

Powers of 2

10
Probably exclude : tables of instructions for particular computers

and/or operating systems.

Question : What use of samples of code? In which programming

language? (One participant observed that samples of code must

be used to illustrate first principles — and that several high

level languages should be used.)

Question : Should the Handbook teach how to construct algorithms?

Acceptability testing

Test plan preparation

Acceptance testing

Test case generation

Proof of correctness , with today's limitations

Volume and functional test drivers

Test beds for modules

Systems integrity packages; testing for no deterioration since

last update; in simplest case, a test problem.

Methodology for desk checking.

Quality assurance of documentation

.

(Reference was made to the very short time required for quality

assurance testing under the IBM Chief Programmer Team approach,

for the New York Times Information Retrieval System.)

Large scale systems

A chapter perhaps should be devoted to special considerations

that must be given to the design and construction of large

systems

.

Concepts involved include:

Autonomous sub-systems versus a man-layered hierarchy

Phasing of sub-systems

"Creeping commitment" for retaining options as long as possible.

11
APPENDIX II. SPECIFIC SUGGESTIONS FOR SOFTWARE ENGINEERING

MANAGEMENT CONTENTS

The techniques of managing software projects are very similar to the

techniques used for managing R&D projects where the design has a high

degree of uncertainty

.

Traditionally in the software field, projects have ended up over cost,

over schedule , and deliver less performance than promised. Better

management techniques can help to alleviate these problems.

First Principles of Managing Software Projects

Define the problem to be solved at the outset; state the system

requirements in a language that is understandable by the users;

get user management approval of these requirements and problem

statement.

Make the design easy to change; implies a modular design.

Consider the idea of the "creeping commitment" , for large

projects and/or those where the design is very subject to change.

Identify alternative solutions , then select the best of the

alternatives according to criteria.

Quality assurance should not be separated from construction.

Plan the quality assurance at the outset, using either proof

of correctness or conventional testing. The constructor must

demonstrate that a module meets its specifications.

Once the design selection has been made, institute a change review

and approval process, so as to control changes.

Every software engineer is a manager, even if just of himself.

He must plan his activities , so that management techniques are

as appropriate to his work as design techniques . He should

apply first principles to the resources under his control, and

try to influence his boss to use those first principles . The

fact that a particular manager does not understand the principles

of software engineering should have no influence on the profession

of software engineering.

Recognize that constraints imposed by management are of two types —

mandatory and negotiable. Recognize , also, that some "mandatory"

constraints are really negotiable.

The structure of a project organization will have a vitally important

effect on the architecture and engineering of the resultant system,

since it defines the lines of communications . Both democratic and

autocratic project structures are being proposed these days, with

12
some instances of impressive performance under autocratic structuring.

A "Standard" Project Discipline

Problem definition

Define system

Decompose into parts

Define parts

Decompose into sub-parts

Develop system specifications , for new system

Perform system design and test design; institute formal

change procedure

Perform program design

Perform program building and quality assurance

Perform system test and integration

Perform conversion , operation , and maintenance

Comment: Project administration functions would be conducted in

parallel with the above activities . Also, installation

standards should be employed.

Comment: Measures are needed by which the individual programmer

can tell how much progress he has made, and how much he

still has to do, to finish the job.

Comment: A reduced version of the above project discipline may be

needed for small projects , and for to-be-used-one-timeonly programs.

Ques ti ons :

Should the Handbook include guidance for executive management,

since they often make constraining decisions? (One participant

argued that such material should be included , if at all, only in

the opening tutorial section.

)

Should the Handbook address the question of training management

in some aspects of software engineering?

Should the Handbook address the subject of the professional

responsibility and ethics of the software engineer?

13
NBS-114A (REV. 7-73)

U.S. DEPT. OF COMM. BIBLIOGRAPHIC DATA

SHEET

1. PUBLICATION OR REPORT NO. NBS TN-832

2. Gov't Accession

No.

3. Recipient's Accession No.

4. TITLF AND SUBTITLE

REPORT ON PLANNING SESSION ON SOFTVIARE ENGINEERING HANDBOOK

5. Publication Date November 1973

6. Performing Organization Code

7. AUTHOR(S)

S. L. Stewart

8. Performing Organ. Report No.

9. PERFORMING ORGANIZATION NAME AND ADDRESS

NATIONAL BUREAU OF STANDARDS

DEPARTMENT OF COMMERCE

WASHINGTON. D.C. 20234

10. Project /Task/Work Unit No. 640-1129

11. Contract/Grant No.

12. Sponsoring Organization Name and Complete Address (Street, City, State, ZIP)

Same as #9

13. Type of Report & Period Covered

14. Sponsoring Agency Code

15. SUPPLEMENTARY NOTES

Library of Congress Catalog Card Number: 74-600091

16. ABSTRACT (A 200-word or less factual summary ot most significant information. If document includes a significant bibliography or literature survey, mention it here.)

This report from a planning committee sponsored by the National Bureau of

Standards, the National Science Foundation, and the Association for Computing

Machinery discusses the need for, coverage of, and audience for a proposed

Software Engineering Handbook.

17. KEY WORDS (six to twelve entries; alphabetical order; capitalize only the first letter of the first key word unless a proper name; separated by semicolons)

Programming, quality software , software engineering.

18. AVAILABILITY [~jc Unlimited

_ For Official Distribution. Do Not Release to NTIS

\_K Order From Sup. of Doc, U.S. Government Prirv«ir>«„0^fice Washington, D.C. 20402, SD Cat. No. CI 3 . 46:832

Order From National Technical Information Service NT IS l Springfield, Virginia 22151

19. SECURITY CLASS

(THIS REPORT)

UNCLASSIFIED

20. SECURITY CLASS

(THIS PAGE)

UNCLASSIFIED

21. NO. OF PAGES

18

22. Price

70 cents

USCOMM.DC 29042-P74


NBS TECHNICAL PUBLICATIONS

PERIODICALS JOURNAL OF RESEARCH reports National Bureau

of Standards research and development in physics,

mathematics, and chemistry. Comprehensive scientific papers give complete details of the work, including

laboratory data, experimental procedures, and theoretical and mathematical analyses. Illustrated with photographs, drawings, and charts. Includes listings of other NBS papers as issued. Published in two sections, available separately:

• Physics and Chemistry (Section A)

Papers of interest primarily to scientists working in these fields. This section covers a broad range of physical and chemical research, with major emphasis on

standards of physical measurement, fundamental constants, and properties of matter. Issued six times a

year. Annual subscription: Domestic, $17.00; Foreign,

521.25.

• Mathematical Sciences (Section B)

Studies and compilations designed mainly for the mathematician and theoretical physicist. Topics in mathematical statistics, theory of experiment design, numerical analysis, theoretical physics and chemistry, logical design and programming of computers and computer

systems. Short numerical tables. Issued quarterly. Annual subscription: Domestic, $9.00: Foreign, $11.25. DIMENSIONS/NBS (formerly Technical News Bulletin) —This monthly magazine is published to inform

scientists, engineers, businessmen, industry, teachers,

students, and consumers of the latest advances in science and technology, with primary emphasis on the work at NBS. DIMENSIONS/NBS highlights and reviews such

issues as energy research, fire protection, building

technology, metric conversion, pollution abatement,

health and safety, and consumer product performance.

In addition, DIMENSIONS/NBS reports the results of Bureau programs in measurement standards and tech- niques, properties of matter and materials, engineering standards and services, instrumentation, and automatic

data processing. Annual subscription: Domestic, $6.50; Foreign, $8.25.

N0NPERI0DICALS Monographs—Major contributions to the technical liter- ature 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 interested industries, professional

organizations, and regulatory bodies. Special Publications—Include proceedings of high-level national and international conferences sponsored by

NBS, precision measurement and calibration volumes,

NBS annual reports, and other special publications

appropriate to this grouping such as wall charts 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 world-wide program coordinated by NBS. Program under authority

of National Standard Data Act (Public Law 90-396). See also Section 1.2.3. Building Science Series—Disseminates technical infor- mation 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 pro- cedures published by the Department of Commerce in Part 10, Title 15, of the Code of Federal Regulations. The purpose of the standards is to establish nationally

recognized requirements for products, and to provide

all concerned interests with a basis for common understanding of the characteristics of the products. The

National Bureau of Standards administers the Voluntary Product Standards program as a supplement to the activities of the private sector standardizing

organizations. Federal Information Processing Standards Publications (FIPS PUBS) —Publications in this series collectively constitute the Federal Information Processing Standards Register. The purpose of the Register is to serve

as the official source of information in the Federal Gov- ernment regarding 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 11717

(38 FR 12315, dated May 11, 1973) and Part 6 of Title 15 CFR (Code of Federal Regulations). FIPS PUBS

will include approved Federal information processing standards information of general interest, and a complete index of relevant standards publications. Consumer Information Series—Practical information, based on NBS research and experience, covering areas

of interest to the consumer. Easily understandable language and illustrations provide useful background

knowledge for shopping in today's technological

marketplace.

NBS Interagency Reports—A special series of interim

or final reports on work performed by NBS for outside sponsors (both government and non-government). In general, initial distribution is handled by the sponsor;

public distribution is by the National Technical Infor- mation Service (Springfield, Va. 22151) in paper copy

or microfiche form. Order NBS publications (except Bibliographic Subscription Services) from: Superintendent of Documents, Government Printing Office, Washington, D.C. 20402. BIBLIOGRAPHIC SUBSCRIPTION SERVICES

The following current-awareness and literature-survey

bibliographies are issued periodically by the Bureau:

Cryogenic Data Center Current Awareness Service (Publications and Reports of Interest in Cryogenics).

A literature survey issued weekly. Annual subscription: Domestic, $20.00; foreign, $25.00. Liquefied Natural Gas. A literature survey issued quarterly. Annual subscription: $20.00. Superconducting Devices and Materials. A literature survey issued quarterly. Annual subscription: $20.00. Send subscription orders and remittances for the preceding bibliographic services to the U.S. Department

of Commerce, National Technical Information Service, Springfield, Va. 22151. Electromagnetic Metrology Current Awareness Service (Abstracts of Selected Articles on Measurement

Techniques and Standards of Electromagnetic Quantities from D-C to Millimeter-Wave Frequencies).

Issued monthly. Annual subscription: $100.00 (Special rates for multi-subscriptions). Send subscription order and remittance to the Electromagnetic Metrol- ogy Information Center, Electromagnetics Division, National Bureau of Standards, Boulder, Colo. 80302.
U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Washington. DC. 20234

OFFICIAL BUSINESS

Penalty for Private Use. $300

POSTAGE AND FEES PAID

U.S. DEPARTMENT OF COMMERCE COM-21 5

'^6-i9i6 1298