NAT'L INST OF STAND S TECH

AlllDt. '^7flM0S

of Commerce

NBS

PUBLICATIONS

National Bureau

of Standards

'"St.

Computer Science

and Technology

NBS Special Publication 500-91

The Introduction

of Software Tools
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 essentia! 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.
or trtAmAMim

SEP Z 0 1982

Computer Science

and Technology

NBS Special Publication 500-91

The Introduction

of Software Tools

U.S. DEPARTMENT OF COMMERCE

Malcolm Baldrige, Secretary

National Bureau of Standards

Ernest Ambler, Director

Issued September 1982

Herbert Hecht

SoHaR Incorporated

1040 So. La Jolla Avenue

Los Angeles, California 90035
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-91

Natl. Bur. Stand. (U.S.), Spec. Publ. 500-91, 41 pages (Sept. 1982)

CODEN: XNBSAV

Library of Congress Catalog Card Number: 82-600577

U.S. GOVERNMENT PRINTING OFFICE WASHINGTON: 1982

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

Price $4.75

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

From a survey of current tool usage It Is concluded that the greatest

obstacles to effective use of software tools are encountered In

organizations employing fewer than 40 programmers , and the needs of

these environments are therefore emphasized. Specific needs for

software tools In programming for management Information systems and

for scientific applications are discussed. Measures are described to

overcome organizational obstacles to use of tools, to deal with

problems arising from the tools, and to reduce the difficulties posed

by existing computer Installations.

Steps required for the successful Introduction of tools are organized

In two ways: by the function responsible for their accomplishment, and

by the time schedule In which they must be completed. The detail work

to be performed In each step Is described.

Key words: computer environments; software; software engineering;

software management; software quality; software tools; tool smith.

Ill
i
TABLE OF CONTENTS

PAGE

1. EXECUTIVE SUMMARY 1

2. INTRODUCTION 3

3. CHARACTERIZATION OF USER ENVIRONMENTS 5 3.1 Classification of Environments 5 3.2 Selection of Target Environments 6

3.3 The Smaller MIS Environment 8

3.4 The Smaller Scientific Environment 10

4. USER TOOL NEEDS 12

4.1 Organizational Factors in Tool Needs 12

4.2 Application Factors in Tool Needs 16

4.3 Needs of Other Environments 19

4.4 Resources for Tool Selection 20

5. DEVELOPMENT OF EVENT SEQUENCES 21

5.1 Purpose of Event Sequences 21

5.2 Recommended Event Sequence 24

REFERENCES 34

APPENDIX - WORKSHOP ON PHASING OF

SOFTWARE TOOLS 35

v
I
SECTION 1

1

EXECUTIVE SUMMARY

This publication Is Intended to provide guidance for the Introduction of

software tools for agencies of the U. S. Government and for computer users at

large. It Is primarily aimed at installations where there had been little or no use of software tools previously. In a survey of software tool usage it was

found that the size of the programming group had a significant effect on the

extent of tool usage, with organizations of less than 40 programmers much less

likely to be tools users. To provide help to these smaller organizations In the

Introduction and use of software tools Is therefore one of the goals of this

document.

Difficulties in the Introduction of tools can arise In three areas:

Organizational obstacles.

Problems arising from the tools.

Obstacles in the computer environment.

Organizational obstacles can be reduced If a responsible management level is

Involved in the Introduction of tools. Those who commit the resources for tool

acquisition and use should participate actively in the relevant decisions.

Their involvement in the following is particularly Important:

1. Identifying the goals to be met by the tool (or by the technique supported

by the tool), and assigning responsibility for the activities required to

meet these goals.

2. Approving a detailed tool acquisition plan that defines the resource

requirements for procurement and In-house activities.

3. Approving procurement of tools and training If this Is not explicit In the

approval of the acquisition plan.

4. Determining after some period of tool use whether the goals have been met.

Prob I ems ar I s I ng from the too I s can be avoided by a careful, methodical

selection of tools. In particular, distinct contributions to the tool selection

are specified for software management and the software engineer. Software

management Is assigned responsibility for:
2

1. Identifying tool objectives.

2. Approving the acquisition plan (higher approvals may also be required).

3. Defining selection criteria,

4. Making the final selection of the tool or the source.

The software engineer Is responsible for:

1. Identifying candidate tools.

2. Applying the selection criteria or preparing technical sections for

a Request for Proposals (RFP).

3. Preparing a ranked list of tools or sources.

Further, the ultimate user of the tool should be Involved In reviewing either

the list of candidate tools or, for formal procurement, the tool requirements.

Obstacles In the computer environment are primar 1

1 y due to the great d I vers I ty

of computer architectures and operating system procedures, and to the lack of

portability of most software tools. Activities associated with the Introduction

of tools can only modestly alleviate these difficulties. Guidance Is provided

for:

1. A methodical process of Identifying candidate tools and selecting among

these on the basis of established criteria. Including a definition of the

computer Interface. This will avoid some of the worst pitfalls associated

with "borrowing" a tool from an acquaintance or procuring one from the most

accessible tool vendor.

2. The assignment and training of a toolsmlth who can make minor modifications

to both the computer environment and the tool. This Is expected to provide

relief where there are version-related or release-related Incompatibilities

with the operating system, or where the memory requirements of the tool

exceed the capabilities of the Installation. In the latter case, remedies

may be provided by removing tool options or by structuring the tool program

I nto over I ays.

As part of this work, an event sequence for the Introduction of tools has been

developed that Identifies specific tasks, the assignment of responsibilities for

the tasks, and the order In which they have to be carried out.
3

SECTION 2

IMTRODUCTION

This publication Is intended to provide guidance for the Introduction of

software tools for agencies of the U. S. Government and for computer users at

large. It is primarily aimed at installations where there had been little or no

use of software tools previously. In a survey of software tool usage it was

found that the size of the programming group had a significant effect on the

extent of tool usage, with organizations of less than 40 programmers much less

likely to be tools users LhECHSIH. In particular, organizations of less than 40

programmers were found to need help In order to acquire and employ software

software tools successfully, and the requirements of these organizations are given special emphasis.

Many of the difficulties reported by novice users with software tools can be

overcome by systematic practices in the selection, acquisition, and preparation

for use of software tools. This report first derives the need for specific

guidance In the introduction of tools by examining a number of programming

environments, and then describes the practices suited to these environments.

Section 3 charaterlzes user environments In terms significant for the

introduction of software tools. In this characterization, two environments were

Identified that will benefit most from formal guidance for the Introduction of

tools, and a vignette of each of these Is presented In the final parts of

Section 3,

Tool needs for various user environments are described In Section 4. First, a fairly broad discussion of organizational and application factors that govern

tool needs Is presented. Then, based on these considerations, a generic

(features based) Identification of tool needs for the two target environments Is

made. Needs of other environments are also discussed, and special attention Is focused on the Integration of tools. The final part of Section 4 covers

resources for the selection of tools. The recent publication of a report on software development tools by NBS/ICST Is of major assistance in this area

LH0UG82I]. The generic software tool nomenclature used In the present report Is taken from LH0UG81I] which in turn incorporates major portions of a Software Tool

Taxonomy [REIF80J.

The time phasing aspect of the introduction of tools is described In Section 5

by means of event sequences. The purpose of event sequences Is discussed in

general terms, and the specific event sequence for the introduction of software

tools Into the smaller programming environments Is then developed. The events

are classified by area of responsibility and precedence relationships, and each

of the required events Is described in detail.

A preliminary draft of this document was discussed at a Workshop on Phasing of

Software Tools which was held at NBS on 18 May 1981. The agenda and the

attendance list are reproduced In the Appendix. The participants contributed
4

many constructive comments which have been Incorporated Into the present

version. Written comments were received from several Individuals who could not

attend the workshop; these contributors have been listed as "reviewers" in the

Appendix,

The author wishes to acknowledge the contributions of collaborators in the

preparation of this document. Myron Hecht analyzed the survey results which

form the basis for Section 3, and Donald J, Reifer classified tool needs as reported in Section 4. Much helpful guidance In the conduct of this study was received from the technical monitor for the contract, Mr. R. C. Houghton, Jr.

Continued encouragement and many helpful suggestions were furnished by Dr.

Martha Branstad, the ICST Software Quality Program Manager.
5

SECTION 3

CHARACTERIZATION OF USER ENVIRONIErfTS

This section considers the characterization of user environments along lines

that are significant for the Introduction of software tools. The starting point

for this characterization Is the classification of software tool users which Is

summarized In subsection 3.1. The selection of target environments for the

Introduction of software tools, based on this classification. Is described In subsection 3.2. The smaller classes of management Information system (MIS) and

scientific programming environments are Identified as most In need of outside

assistance In tool usage, and vignettes typical of each of these environments

are presented In subsections 3.3 and 3.4, respectively.

3.1 CLASSIFICATION OF ENVIRONMENTS

A Survey of Software Tools Usage ChECHSO considers the effect on tool usage of

a fairly large number of environmental factors. Including:

Size of software organization.

Type of organization (private. Government-support, Government).

Applications (scientific, MIS) and language.

Development environment (batch. Interactive).

Program running environment (batch. Interactive, real-time).

Computer type.

Involvement In tool development.

The first and last factors were found to have a significant effect on the extent

of tool usage. The type of organization was not found to be a major determinant

of the extent of tool usage In this survey. The other factors had some effect

on the types of tools that were used but not on the extent of tool usage (or the

effect was masked by correlation with primary determinants of tool usage).

In the following discussion the extent of tool usage Is classified Into three

I eve I s

:

Level 0 Minimal tool usage - only tools normally provided with the operating

system were In use (assemblers- loaders, compilers, debug aids, and

I nterpreters)

.

Level 1 Intermediate tool usage - special purpose tools suited for the mission

of the organization but without explicit effect on software quality were In use. Examples are simulators, file managers, and elementary

precomp 1 1 ers.
6

Level 2 General purpose tool usage - general purpose tools. Involving static

and dynamic analysis features, were deliberately acquired or developed

In order to enhance software quality and productivity. This group

represents the highest level of tool utilization identified In the

survey.

By Interpreting the level Index (0, 1, or 2) as a number, an average level of

tool utilization can be computed for groups of tool users. The average level of

tool utilization as affected by the size of the organization Is shown In Table

3-1

.

TABLE 3 - 1 LEVEL OF TOOL UTILIZATION

Size of Organization Avg, Level of

Tool UtI I Izatlon

Smal 1 - up to 14 programmers 0.8

Medium - 15 to 39 programmers 0.8

Large - 40 to 99 programmers 1 .4

Very large - over 100 programmers 2.0

The term progranmer Includes analysts, programming supervisors, and programming

trainees but not computer operators, librarians, or other support personnel.

The above data are based on a survey of 22 organizations. Tool developers were

not Included in this population.

3.2 SELECTION OF TARGET ENVIRONMENTS

As can be seen from Table 3-1, the use of general purpose software tools was considerably less prevalent among small and medium software organizations than

among the large and very large organizations. In all size classifications there

was representation of private. Government, and Government-support organizations

(the three classifications for type of organization considered In this study).

No evidence was found that the organization type affecrs the level of tool

usage, but because of the small sample size this Is regarded as only a tentative

cone I us Ion.

These data indicate that small and medium software organizations will represent

the target environment that stands to benefit most from the availability of a comprehensive methodology for the Introduction of software tools. In addition

to the low level of current tool usage shown in Table 3-1, the following facTors

Indicate that small and medium organizations need outside assistance In the

Introduction of tools:

1. Their awareness of tools In general, and their knowledge about specific

tools suited to their needs, are frequently much less than that of larger

organizations.
7

2. Their knowledge of tool acquisition and Installation practices tends to be

Inadequate to permit them to obtain the full benefit from available tools.

3. Even when suitable tools are obtained and Installed, these organizations

frequently cannot mobilize the resources required for optimum tool

utilization, such as training, start-up efforts, and change In practices to

f ul ly uti I Ize a tool

A further consideration (which partly encompasses all of the above) Is that a given level for effort In developing a methodology for the Introduction of tools

can be expected to provide much more significant and measurable results If that

effort Is targeted at organizations at the smaller end of the size range.

The above does not Imply that large, and even very large, organizations cannot

benefit from further developments of methodology for the Introduction of

software tools, and specifically from efforts In that area undertaken by

NBS/ICST. The needs of these environments are further addressed In subsection

4.3 of this report.

The need for outside assistance for the development of a suitable Introduction

methodology Is shared by small and medium size organizations. There are only

minor differences In the details of the application of the methodology between

small and medium size organizations, and to avoid long titles the term "smaller"

will henceforth designate the two groups collectively. Within the smaller size

groups, the Introduction methodology will focus on Government organizations

although, as will be explained shortly, most of the Introductory practices are

not expected to vary significantly as a function of the organization type. The

reasons for focusing on Government organizations are:

1, The demand for uniformity of software practices In Government agencies Is

expected to Increase, and tools can be of assistance In providing and

enforcing this uniformity. Hence, a greater need for tools Is expected to

arise In this environment.

2, Government agencies usually have a greater need to control procedural

aspects of software development, and many tools address that need very

specif leal ly.

3, There are a large number of tools currently In Government Inventory, and some of these are resident on computers that can be accessed by other

Government organizations via terminals. Experience with tools may be

shared, and help with tool problems may be furnished more readily among

Government agencies than within the private sector or between Government

and private organizations. Thus, the opportunity for tool usage Is greater

among Government organizations.

4, Successful use of a tool In a Government organization Is likely to become

generally known (via professional organizations, computer user groups,

etc.) whereas smaller private organizations may wish to restrict the

dissemination of this Information for competitive reasons. Thus, the

ripple effect can be expected to be greater If Government organizations are addressed as the primary target for the tool Introduction methodology.
8

Except for the factors mentioned above, the activities and level of effort

required for the Introduction of tools are not believed to be significantly

different among private. Government-support, and Government organizations. The

greater availability of tools may appear to confer a material advantage on Government organizations but at present this has not been a cause for Increased

usage. The annual licensing fee for a typical tool Is of the order of $ 1,000,

and purchasing costs are five to ten times that amount. These are usually not

the dominant expenses In the Introduction of a software tool. A large number of

tools are In the public domain and copies can be obtained at nominal cost from

computer vendors, universities, and some organizations which specialize In this

field. Thus, although the terminology used In the following may be specific to

Government organizations, the general concepts are believed to be broadly

appi Icable.

Among the smaller Government organizations, the survey found differences In

tool needs that Indicate that administrative and scientific environments may

best be treated separately for some aspects of the Introduction of software

tools. A demonstrable difference Is In the types of tools needed (In turn

dictated by the languages used): the most widely encountered tool In smaller

scientific organizations Is a FORTRAN preprocessor, whereas COBOL environments

frequently use optimization tools that have no direct counterparts In the

scientific environments, A more subtle difference exists In the overall

attitude towards tools. Scientific programmers (specifically engineers and

scientists doubling as programmers) know about tools and may be conscious of

some of the advantages that they confer, but are Interested primarily (sometimes

exclusively) In solving scientific or englneeering problems. They are only

slightly motivated to devote any effort toward the enhancement of software

quality. Programmers and first level supervision In the smaller administrative

or MIS (Management Information Systems) environment may be only vaguely aware of

tools but are highly motivated to Improve the quality of their software,

particularly Its mal ntal nabl I Ity.

The following subsections provide vignettes of the smaller MIS and scientific

environments, respectively, that particularly emphasize factors pertinent in the

Introduction of tools.

3.3 THE SMALLER MIS ENVIRONMENT

The term MIS environment Is Intended to Include all programming for fiscal,

administrative, housekeeping, and record-keeping functions. The predominant

language Is COBOL but a fair amount of assembly language programming (In

application programs) Is also In use. ALGOL and PL/1 are used occasionally In a few agencies. Practically all system programs used by the smaller MIS

organizations are written In assembly language.

By our definition, a smaller organization may Include up to 39 programmers, but

the representative Government organization In this category rarely involves more

than 25 or 30 programmers. It is typically a field office or a central

programming organization for a specialized agency or function within an agency.

There are two levels of supervision. The lower one deals with a specific
9

programming area (systems, disbursals, security, etc.) while the major

responsibility of the upper supervisor Is to maintain liaison with the

headquarters organization which generates the requirements and funding for the

office. Very few. If any, of the smaller Government MIS organizations can make

It a major assignment for one of their employees to provide guidance In software

technology and programming practices. Some of this guidance might be provided

by headquarters organizations, and thus will be relayed through the highest

supervisory level. But without a specific local designee who provides

follow-up, much of the Impact of headquarter guidance will be lost.

The range of programmer skill levels encountered In MIS organizations Is broader

than that prevalent In scientific environments, primarily due to the use of

programmer trainees by the MIS organizations. The formal training of the

programming trainees consists of In-house courses, technical school courses, and

approximately 1 year of attendance at a community college. They are trained for

program writing rather than software design or broader aspects of computer

science or software engineering. There Is also little Involvement In standards

or professional activities among the MIS organizations. Indicating few

opportunities for a continuing, broadening education of the programmers In this

envl ronment.

The primary activity of the smaller MIS organizations frequently Is program

maintenance. The programs undergo almost constant change due to:

Changes In legislation.

Changes In administrative procedures.

Major organizational restructuring.

Program or functional Improvement.

Correction of errors.

Offices have backlogs that range up to 1 year. Maintenance Is a slow and

difficult process because of the lack of good documentation (a facxor that

transcends this environment), the low skill levels, and the lack of good tools.

When available, tools may be used very effectively, e. g., the use of a file

manager for configuration management of the programs, or full employment of the

features of a sophisticated editor.

In general, the smaller Government MIS organizations do not lack motivation for

tool use and make use of available tools. Frequently, however, they lack both

the knowledge and the resources to use tools more effectively. They will

benefit fromoutslde assistance In all of the areas identified In 3.2 above.

As far as tool needs are concerned, the MIS environment presents some unique

problems, e. g., the lack of portability of most COBOL programs, and the

run-time Inefficiencies caused by most commercial COBOL compilers. The first

problem prevents agencies from sharing application programs, even where the

purpose served and the records to be generated are Identical, unless they also

have the same computer. The lack of portability Is more of an obvious problem
10

In this environment than In the scientific one because many applications are common to practically every business environment: payroll, budgeting physical

asset management, and billing. Among Government agencies there are further

commonalities due to Government regulations. Interaction with the General

Services Administration, and requirements of the Office of Management and

Budget. In addition to the obstacles which the lack of portabll Ity represents

to the Interchange of programs. It also creates great problems If a computer Is

being replaced by a more capable model from a different manufacturer.

Conversion activity due to replacement of a central computer complex can extend

over several years and represent resource expenditure comparable to the hardware

cost.

The run time Inefficiencies of COBOL compilers could be tolerated In the past

(at least In some cases) when computer programs were used to generate periodic

hard copy reports which would then serve as the user's primary data base. The

predominant practice today Is to update these reports continuously and to make

them available to the user on Interactive terminals rather than In printed

format. This puts a much higher premium on efficient execution of programs

because of the more frequent access and the need for a rapid response to user

requests. To meet the demands of the current environment, either more computers

have to be Installed or the efficiency of the object code has to be Improved,

The latter approach has some obvious limitations, but within these It Is a much

more cost-effective way of Improving the performance of a computer complex.

Optimization programs of several types are available to deal with this problem.

These are not commonly In use In smaller organizations of any type but they are

frequently encountered In larger MIS organizations.

3.4 THE SMALLER SCIENTIFIC ENVIRONMENT

The typical size of the smaller scientific software development group Is also 25

to 30 programmers, and two levels of supervision are Involved- The lower

supervisory level tends to be application oriented but the top supervisory

function operates much more autonomously than In equivalent MIS agencies.

Though constrained by budgets that are determined at a higher managerial level,

the second level scientific supervisor typically assumes full responsibility for

the technology employed within his or her organization. Where this supervisor

takes an Interest In software technology, structured programming supported by

appropriate tools Is likely to be used. On the other hand. If the Interest of

the supervisor Is confined to a scientific specialty (simulations, engineering

analysis), software technology can be a very low priority Item,

Most programmers In the smaller scientific environment have an engineering or

science degree but their formal training In programming may not be very

advanced. Frequently, It consists of undergraduate computer or programming

courses, supplemented by on-the-job training and an occasional extension course.

In some groups at least one Individual has a degree In computer science or a related field. The motivation of Individual programmers Is governed by the

needs of their application. In the simulation field, which represents a significant part of the smaller scientific programming community, the code tends

to be bound to a specific facility. Although most programming Is In FORTRAN,

there may be frequent recourse to assembly routines to speed up the execution.
11

As a rule, structured programming Is not used In that environment although

Individual programmers may be experimenting with It.

Engineering and scientific analysis programs are sometimes distributed outside

the originating organization, and In those cases portability Is a recognized

requirement, at times enforced by a portability analyzer. Structured and

modular programming Is used more frequently than In the simulation field but Is

seldom formally required. Another characteristic of the engineering or scientific analysis environment that affects tool usage Is that many programming

tasks are of less than 3 months duration, and much of that time Is spent on analysis of the underlying problem rather than on program design or

Implementation. This discourages the use of tools that require much set-up time

or a lengthy learning period.

The emphasis In the scientific programming environment Is more on the generation

of new programs as contrasted with maintenance. Some maintenance activities,

such as the addition of a major feature to a simulation, or the extension of the

capabilities of an analysis program, are regarded as creative and desirable

assignments. More typical maintenance activities, such as modifying a report

format, adapting a program to a change In hardware configuration, or correcting

Interface problems are regarded as less desirable assignments and are given to

junior personnel as "training".

Supervisors regard the documentation and detailed maintenance as problem areas. Although these are recognized as essential elements of the organization's

overall assignment, the senior programmers take little Interest In them, and a good methodology Is not available for breaking them down Into tasks that could

be efficiently handled by less experienced personnel or by personnel not

Involved In the direct programming. Some smaller organizations make effecrlve

use of general purpose development tools to strip headers and comments from

programs and to transform these Into documentation. More typical Is the

approach where supervisors. In some cases second level supervisors, assume the

major responsibility for the review of documentation.

A very significant part of the overall activity In the simulation field Is

version control. New assignments frequently consist of assembling existing

modules, some with minor changes. Into a new configuration. File management

systems can be used very effectively to assist In this process. Editors and

preprocessors (usually without extensive analysis features) are other typical

tools currently used In this environment.

By and large the scientific programming organizations have the technical ability

to acquire and Install software tools. They may lack specific Information on tools suitable for their environment, the resources for the Introduction, and

frequently also the motivation to devote part of their effort to software

engineering. Because of the recognized difficulties In documentation and

maintenance, the second level supervisors will be particularly receptive to

tools that can simplify the work In these areas.
12

SECTION 4

USER TOOL NEEDS

This section discusses those aspects of user tool needs that are pertinent to

the development of guidance for the Introduction of tools. Subsection 4.1

considers organizational factors of tool needs that are largely Independent of

the application area. This Is followed In subsection 4.2 by a detailed

Identification of tool features desired In the target environments described In Section 3. Even experienced tool users can be faced with severe problems In the

adoption of new tools, and the needs that arise In this connection are addressed

In subsection 4.3. The final part of this section describes resources available

to the potential tool user for selection of specific tools to meet the needs

characterized in the earlier parts.

4.1 ORGANIZATIONAL FACTORS IN TOOL NEEDS

The objectives of tool usage (and hence the objectives of many tool features)

are determined largely by the user's organizational environment and by the

management level that authorizes tool acquisitions. Because these

considerations hold for all application areas, they are discussed at the

beginning of this section. For a tool to be readily accepted, it must help in

areas of concern to the management that authorizes the acquisition and

Introduction activities. Thus, If management considers program documentation to

be a particularly critical area It may be difficult to obtain authorization for

the Introduction of test tools. The organizational entities that may be

involved In the acquisition and use of software tools are described under the

headings of:

Software Development Organization,

Project Management, and

Functional Management.

4.1.1 Software Development Organization

The term development Is used In a broad sense that Includes all the activities

directly involved in generating and maintaining programs- Practically all

software development organizations desire tools that:

Increase productivity.

Reduce skill requirements.

Automate routine aspects of software design.

Help In software maintenance.

To some extent the last three Items are individual facets of the first. At the

present time there are few tools that are specifically aimed at a reduction of

skill requirements. The creative and cognitive skills required for designing a
13

sound software structure are not easily packaged Into a software tool. However,

the automation of routine tasks Is a very widely addressed tool objective.

Because they relieve creative personnel from tedious aspects of design, coding,

and testing, these tools compensate partly for the lack of those that reduce the

skill levels. They also contribute to Increased productivity. Examples of such

tools are editors and precompilers used for the preparation or conversion of

source files, formatters for the preparation of reports, and sort/merge

programs. The most common tool features that automate routine tasks are

editing, formatting, comparison, translating, and scanning. Tools that help In software maintenance Include most of those cited for the automation of routine

tasks plus file managers or library systems. In addition, maintenance may make

use of special functions In editing or scanning tools, e. g., to locate

variables or to strip code from a source file. The latter feature Is useful for

creating documentation from the program comments.

AM of the tool functions and features enumerated here are of direct benefit to

the software professional, and there Is seldom any difficulty In Introducing

them at the working level If they provide a reasonably friendly user Interface.

Line management In the software development organization may need to be

convinced that the cost of the tool acquisition and Introduction will be

recovered over a reasonably short time span. Note that the use of these tools

Is largely Independent of emphasis on standards that may prevail In the using

organization.

Where standards are In use, additional tools will be desired that either

facilitate or enforce compliance. Among the former are program design language

processors, and among the latter are code auditors. Environments that emphasize

standards usually also demand discipline in the procedural aspects of software

development such as version control, access to test cases, etc. File managers

and library systems will be found helpful In enforcing this discipline. Tools

that support standards will be readily accepted by a standards-minded line

management. The professionals who have to use the tools may regard them with

Indifference or even hostility. Part of this Is due to apprehension about

having one*s work scrutinized by "Big Brother", and part Is due to obstacles to

Innovation (deviation from standards) which these tools may present. It Is

therefore Important that tools of this type have a particularly good user

Interface so that potential complaints about their use can be minimized- Some

tools, such as auditors, can be combined with the compiler so that they are

automatically Invoked when a new source file Is submitted. This Integration

makes more efficient use of the computer and at the same time avoids problems at

the user Interface.

That they support or enforce standards Is a particularly pertinent factor In

connection with the Introduction of software tools to Government agencies.

Beyond the benefits that always attend uniformity of design practices.

Government agencies will find It easier to Interchange both programs and

personnel If common standards can be adopted. Some of these benefits transcend

the usual concerns of the software development organization. The broader

aspects of tool usage to support software standards are discussed under

Functional Management In 4.1.3.
14

Because Government agencies can have access to tools developed or In use by

other Government organizations, they may particularly benefit from the

appointment of a local too I smith — a person expert In tool usage who may be

able to make software or minor hardware modifications that permit a tool to be

used In a new environment. The role of the tool smith was Introduced several

years ago as a specialist within a software development team In these words

CBROOTSJ:

(The team leader) needs a too I smith, responsible for ensuring this adequacy

of the basic service and for constructing, maintaining, and upgrading

special tools — mostly Interactive computer services — needea by his

team. Each team will need Its own toolsmlth, regardless of the excellence

and reliability of any centrally provided service, for his Job Is to see to

the tools needed or wanted by his (team), without regard to any other

team's needs. The tool-bullder will often construct specialized utilities,

catalogued procedures, and macro libraries.

The designation of a dedicated toolsmlth within each team may be a higher degree

of specialization than can be warranted In smaller software organizations.

However, within each software environment that makes use of a single computing

facility such a specialist will be found very effective and certainly very

valuable for the Introduction of new tools.

4.1.2 Project Management

Project management directs the software development on behalf of the ultimate

user. It Is usual ly more Interested In the functional and Interface aspects of

the programs than In structural or standards aspects. Where project management

Is funding the acquisition of software tools, there may be heavy emphasis on tools that have an Immediate payoff In terms of project objectives- Some of

these tools may be software development tools but the nature of these Is project

dependent and can not be predicted.

There are, however, some software tools that make a direct contribution to

project management, and this area of tools usage Is expected to be expanded In the near future. Some programs of this kind are general purpose scheduling and

reporting algorithms that share more of the characteristics of application

programs than those of software tools. Others, however, are very specific to

the software area and extract Information from the software as It Is being

developed. These are appropriately described as software tools for project

management and are further described below.

Software library systems have already been mentioned In the previous heading as tools that can support disciplined development and aid In software maintenance.

For project management they can furnish the Identification and date of the

latest revision, current file size (number of statements), and change In size

over a selected time Interval, Either by themselves or In conjunction with the

operating system log, these tools can also furnish reports on the total number

of runs, the number of statement changes, the number of different test cases

submitted, and the number of compilation failures or aborted runs. All of this

information can be furnished In hard copy or Interactively on a terminal. In
15

either format, tools furnish these data more conveniently and at a fraction of

the cost of manual methods.

Tools for cost estimation are also Important for the project management area. Development cost, life cycle cost, and computer cost aspects can be estimated by

means of software tools. Development costs are estimated by automating an estimation algorithm such as CD0TY77], Life cycle costs can be developed as an extension of the development costs, such as In the ESD model CJAME77X or from

data on a system under development such as |lPUTN78l]. Computer cost aspects are

estimated by sizing and timing tools. While the jury Is still out on the

accuracy of the cost estimates generated by these tools at present, there Is

little doubt that their use promotes systematic collection of software cost data

and a methodical approach to software costing.

Since the emphasis In this report Is on the Introduction of tools to smaller

programming environments. It should be noted that not all project management

tools need to be very large systems. Management will frequently derive

considerable benefits from small programs that automate follow-up on action

Items, receipt of deliverables from vendors, etc. Programs of this type can be

applied In any environment regardless of size.

4,1.3 Functiona l Management

In organizations where software Is being developed for more than one project,

the Individual development groups usually report to a common management level

which Is referred to here as the functional management or computing function

management. Because personnel must be periodically reassigned to new projects,

functional management will usually be Interested In uniformity of practices

among projects so that retraining can be minimized. Computing function

management can thus be expected to be standards-oriented and to support the

Introduction of tools that enforce standards. This management level Is usually

Inclined to take a long range view and may favor the acquisition of tools that

primarily benefit later software llfecycle phases, e. g., requirements analyzers

(although these are used during the definition stage, the major benefits are usually reduced maintenance costs during the operation phase).

Functional management Is usually also Involved In another Important aspect of

the Introduction of software tools: It must furnish or allocate the facilities

for the execution of the tools. Very few computing facilities have excess

capacity, and this Is particularly true for Government computing facilities.

Therefore, the management of the computing function may object to the

Introduction of tools that extend the execution time or that add Job steps to

frequently run programs. Where a tool has a significant adverse impact on throughput, the benefits of that tool In areas of concern to functional

management should be highlighted: Increased programmer productivity, adherence

to standards, or Improved software quality.
16

Because tool Integration avoids repeated reformatting and multiple data

retrievals. It reduces computer usage and supports the goals of functional

management. It Is at this management level that the greatest recognition of the

benefits of tool Integration efforts can be expected.

Functional management will also be Interested In tools useful for the management

of the computing facility, e. g., those that allocate charges to users, that

report on the operation of the current facilities, and simulation tools that aid

In planning of Improvements. The features of Instrumentation, resource

utilization, simulation, and statistical analysis support the capab 1 1 1 ties of

such tools.

4.2 APPLICATION FACTORS IN TOOL NEEDS

The following discussion focuses on the needs of the two environments that were

Identified In Section 3 as the primary targets for the Introduction of software

tools: the smaller MIS organization and the smaller scientific programming

organization. In the studies leading to the definition of tool needs, six

application areas were considered: business-oriented batch systems- management

Information systems, office automation systems, on I I ne transaction driven

systems, real time command and control systems, and scientific or engineering

programs. It was found that the tool needs of the first four of these were very

similar, and this entire group Is encompassed by the discussion In 4.2.1 below.

Also, the software tool needs of the last two categories were Identical, and

these are described In 4.2.2 below. Within this subsection It Is assumed that

the tool types and features required for the general software development

organization C4.1.1 above] are provided, and therefore only the supplements

dictated by the specific application areas are discussed.

4.2.1 Tool Needs of Smaller MIS Organizations

One of the distinctive tool needs of this environment arises from the use of

COBOL and the Inefficiencies of COBOL compilers that were mentioned earlier

C3.3I1. A sizeable number of commercial tools have been developed to Improve the

performance of COBOL programs. Two specific techniques have been found

particularly helpful In this area: modifying the object code for Improved

performance (the significant tool feature for this Is optimization), and

determining and simplifying the parts of the program which account for the bulk

of the run time (the significant tool feature for this Is tuning). Of course

both of these can also be used together. Tuning Is part of the dynamic analysis

function. It generally requires Instrumenting the program, I. e., the Insertion

of code that counts the number of accesses to the program segments of Interest.

Once this Is done, other attributes of the program's structure and performance

can also be evaluated, and such options are provided In several of the

optimization tools. In connection with the Introduction of tools Into the

smaller MIS organization. It Is suggested to avoid such additional capabilities

In the tool Initially because they extend the run-time of the Instrumented

program, and they make the user Interface more complex than It needs to be.
17

Tools can be used very effectively to aid In program conversion (e. g.. when a new computer Is being Installed) which can present many probleffis In the smal I er MIS environment. Over 270 conversion tools are listed In a publication of the

Federal Conversion Support Center [FCSCSOH. The listing Includes tools that

facilitate conversion (e, g., translators), as well as programs that may

eliminate the need for conversion (e. g,, emulators).

Because of the heavy Involvement of the MIS applications area In the

manipulation of data structures, tools that simplify data base updating and

restructuring are another specific need of this environment. While program

libraries and general purpose file management systems mentioned In 4.1.1 can be

of some help for updating, specialized systems for data base management are preferred, A number of these are commercially available, and they frequently

combine access control, archiving (or providing an audit trail), auditing for

completeness and reasonableness of the Inserted data, and restructuring with the

update capability. Data encryption Is offered as an optional feature of some tools but Is not considered essential for the smaller MIS environment.

4.2,2 Tool Needs of the Smaller Scientific Programming Environment

Just as the use of COBOL Is responsible for some specific tool needs In the MIS

environment, the use of FORTRAN, the current leading language in the scientific

programming environment, has in the past also been a strong motivator for

specific tools. In this case pre-processor s for structured languages.

Pre-processors frequently represent the most advanced software tool in the

inventory of smaller scientific programming organizations. Even though

pre-processors will continue to be used, it Is suggested that a forward looking

program for the Introduction of tools to the smaller scientific programming

environment not emphasize this tool type unduly. One of the reasons Is that. In scientific programming for the defense-connected sector, FORTRAN Is being

replaced by languages which inherently support structured programming practices,

and another reason is that suitable control constructs are evolving for FORTRAN

Cans 178]. But more fundamental Is the need to educate the scientific programmer

In the smaller organization to the benefits of a methodical approach to program

development of which structured programming is but a part.

This need can be met by a general purpose development tool package that takes

the drudgery out of some of the routine programming steps. One such package,

described In the professional literature liKERN76ll. Is In the public domain.

This approach, which Is cited only as an example. Involves a number of

Independent utilities that can be Invoked Individually or interactively by means

of a command line processor to do editing, file management, formatting, and

pre-processing. The efficient application of the tools poses an Intellectual

challenge that may be particularly motivating for scientific and engineering

personnel who are the programmers In this environment. Software tool packages

patterned along these lines are In use In some smaller scientific environments,

and the user reaction seems to be favorable.
18

Once a scientific programming organization Is committed to a disciplined

development approach (and as previously explained some of the smaller

organizations are already at that point), needs for many static analysis

features may arise. Including code auditing, completeness checking, consistency

checking, error checking, and statistical analysis. Tools with these

capabilities will be particularly desired for design analysis programs

supporting critical applications (nuclear Industry, aircraft structures) and for

simulations which furnish output to physically active equipment (e. g., moving

base flight simulators). At present, smaller organizations may find It

difficult or Impossible to acquire these tools In a useful format. Once a general purpose development tools package is In use, the additional checking

tools can be developed In-house. Commercial sources may become Interested in

adding checking functions to an established basic tools package.

Real-time command and control systems pose additional requirements that may

require dynamic analysis features. At present, this applications area Is

primarily served by large organizations that make extensive use of tools, the

4.2.3 Summary of Tool Features Determined by the Application

Table 4-1 lists common and application-dependent tool features. The first

column lists features desired by all software development organizations as described In 4,1.1. The features shown In the table are the ones most desired

by new tool users. The selection Involved some Judgment regarding the

priorities that exist within the software development organization and Its user community. Thus, that error checking is found in the scientific column but not

In the MIS column does not Imply that this feature is not suitable or not

Important In the MIS environment. It does mean that most smaller MIS developers

will place a lower priority on error checking than on the features listed In the

MIS column.

TABLE 4 - 1 FEATURES DETERMINED BY THE APPLICATION

Features Needed For

Common MIS Programming Scientific Programming

Editing

Scanning

Optimization

Tuning

Restructur i ng

Auditing (Data)

Auditing (Code)

FormattI ng

Comparl son Trans I at I on Management

Completeness Checking

Statistical Analysis

Error Checking

Consistency Checking
19

4.3 NEEDS OF OTHER ENVIRONMENTS

Although large and very large software organizations are In most cases already

users of general purpose software tools, they may benefit from programs aimed

at Improving access to tools, standardization of tool Interfaces, or establishing minimum requirements for tool documentation and diagnostics.

Because these organizations (which will be collectively called "larger") have

multiple general purpose tools In Inventory, the Integration of tools Is

particularly pertinent for them. There are at present no clear Indications of

the direction that tool Integration should take. However, there Is a considerable effort being devoted to the area of progranmlng environments within

NBS and elsewhere, and tool Integration Is an Important aspect of these

activities [BRAN81, IEEE81].

The Integration of tools provides two primary benefits: a simplified user Interface and reduced utilization of computer resources. The simplified user

Interface Is achieved by requiring less file manipulation for converting the

output of one tool Into an Input for another, by consistent tool calling

conventions. Input commands, and output formats, and by the capability for

Invoking processing by several tools with a single command string These

benefits will In turn simplify documentation and training and In general Improve

the user acceptance of a system of multiple tools.

The reduced utilization of computer resources Is partly due to the factors just

enumerated, particularly the avoidance of file manipulations, and partly due to

the possibility of combining computer- 1 ntens I ve operations such as parsing and

searching which are now carried out separately. As mentioned In 4.1.3, the

managers of the computing function will particularly appreciate these latter

benefits. The reduction In running time and storage requirements together with

the benefits due to the simplified user Interface promise a high payoff for

efforts In the tool integration area,

A significant step for the Integration of tools developed by different sources

Is represented by the NBS/ICST study of compiler-based tools CBRAY81J. The

association of the tool with the compiler provides access to at least two

(source and object) and sometimes three (parsed code) representations of the

program, and also makes the data and structure checking features of the compiler

available to the tool. A possible disadvantage of this approach Is that a compiler pass may be required In order to Invoke a tool. The adherence to a single (or at least compatible) file format for multiple tools can be readily

enforced by compiler basing.

The Integration of tools Is very significant for extending tool usage In

environments where general purpose tools are already in use. It Is of lesser

Importance for the Introduction of tools to environments that had no prior

experience with general purpose software tools, and It is therefore addressed

here In only a limited way.

A topic partly contained within the area of tool Integration Is the

standardization of tool commands and output formats. The lack of
20

standardization Is particularly obvious and disadvantageous In editors and

related tools (Including word processors). These are among the most widely used

tools, they are frequently the medium through which the Input to other tools Is processed, and there Is better agreement than In most other areas on the

functions which the tool Is required to furnish. There Is thus ample motivation

to standardize but very few concrete accomplishments.

There are at present many different methods for cursor positioning, different

commands for deleting characters, words, or lines, and different procedures as

well as commands for string search or substitution. These inconsistencies cause

errors, necessitate multiple training periods, and certainly constitute a deterrent to tool usage. In view of the basic need for an editor In the use of

many tools, the lack of standardization of editor commands must be regarded as

an obstacle to the introduction of tools.

4.4 RESOURCES FOR TOOL SELECTION

In subsections 4.1 and 4.2 a number of generic tool types and features have been

Identified as suitable for the Introduction of tools to specified organization

and application environments. The present subsection discusses the additional

steps necessary for the actual selection of a tool.

Catalogues of software tools are available from the commercial tool developers,

computer manufacturers^ and computer users* groups. For obvious reasons, the

offerings in each of these are restricted although the restriction imposed by

the last of these may be an appropriate one if only the computer type addressed

by that users' group is available as a tool host and if the group has conducted

a comprehensive survey of suitable tools.

A recent publication by the National Bureau of Standards Is particularly helpful

for the Introduction of tools to smaller programming environments IIH0UG82], It

contains cross references by tool classification (function) and features which

makes it especially suitable for use with the tool Identifications used in this

report.

Once a tool that meets the functional requirements Is identified, the main

section of the catalogue must be consulted to see whether the tool Is usable on

an aval I ab I e computer, whether It handles an appropriate source language (or

other Input format), and whether It can be obtained in a suitable Implementation

language. Other considerations are the licensing arrangements, availability of

documentation and training, and the computer resource utilization.

Some difficulties are usually encountered that must be resolved by language

conversions (of either Input or the tool) or other tool modifications.

Consultation with a toolsmith will be valuable in this connection. Government

agencies will want to know whether other agencies are currently using the tool,

and a central tool usage catalogue will be a beneficial facility. Access at a remote computer can be a very effective first step In a detailed evaluation of

the tool. Hosting problems may be overcome by remote access even on a longer

term basis.
21

SECTION 5

DEVELOPMENT OF EVEMT SEQUENCES

While the preceding sections have discussed the tool needs In selected

environments, this section describes the detailed events that will lead to

successful use of tools. The first subsection describes the purpose and

rationale for an event sequence, and the second subsection recommends a specific

event sequence for the smaller MIS and scientific environments.

5.1 PURPOSE OF EVENT SEQUENCES

The management of any significant project requires that the work be divided Into

tasks for which completion criteria can be defined. The transition from one

task to another Is called an event, and to permit orderly progress of the

activities, here the Introduction of a software tool, the scheduling of these

events must be determined In advance. A general outline for such a schedule Is

provided by the event sequence described In the next subsection. The actual

calendar time schedule will depend on many factors which must be determined for

each specific tool use (particularly on the time required for procurement of the

tool and training). One of the formats used for the event sequence Is

consistent with the Critical Path Method (CPM) of project scheduling and can be

used with that technique for the development of an optimum calendar time

schedu I e.

Most of the activities Included In the event sequence are obviously necessary

but a few were Included specifically to avoid difficulties encountered In

previous tool procurements. Quite frequently tools were obtained 'through the

side door' without adequate consideration of the resources required for the

effective employment of the tool and without determination by a responsible

manager that the tool served a primary need of the organization. Tools acquired

In this manner were seldom used in an optimal way and were sometimes discarded.

Experiences of this type are not conducive to gaining widespread acceptance of

tools In the smaller programming environments where the activities required for

the Introduction of tools will, under the best of circumstances. Impose a severe

drain on resources. A key feature of the proposed approach Is, therefore, that

tool usage will be Initiated only In response to an expressed management goal

for software development or for the entire computing function.

Difficulties In the Introduction of tools can arise In three areas:

Organizational obstacles

Problems arising from the tools

Obstacles In the computer environment

The Individual activities described below as well as the ordering of the event

sequence are designed to eliminate as many of these difficulties as possible.

They are most effective with regard to the first category and probably least

effective with regard to the last category. The need for Involving a reponslble
22

management level In the tool Introduction has already been mentioned, and this

Is Indeed the key provision for avoiding organizational obstacles. "Responsible

management" Is that level that has the authority to obligate the resources

required for the Introduction process. The scope of the resource requirement

will become clearer after all Introduction activities have been described.

Because the criterion for the selection of the management focus Is Its ability

to commit funds, this management level Is hereafter referred to as funding

management. In some organizations this may be the project management as defined

In 4,1.2, in some It may be functional management as defined in 4.1.3, and In yet others It may be an agency or department management not specif leal ly

Identified with a computing function. It should be involved in at least the

following activities associated with the Introduction of tools:

1. Identifying the goals to be met by the tool (or by the technique supported

by the tool), and assigning responsibility for the activities required to

meet these goals.

2. Approving a detailed tool acquisition plan that defines the resource

requirements for procurement and In-house activities.

3. Approving the procurement of tools and training If this Is not explicit In the approval of the acquisition plan,

4. Determining after some period of tool use whether the goals have been met.

Additional organizational obstacles must be overcome by actions of the software

management (local management of the organization that will Introduce the tool),

A pitfall that must be avoided is assigning the details of the tool acquisition

as a sideline to an Individual who carries many other responsbl I ities. Even In

a smal I software organization (up to 14 programmers). It should be possible to

make the tool Introduction the principal assignment of an experienced individual

with adequate professional background. This person Is referred to as the

software engineer. In medium size organizations (15 to 39 programmers) several

Individuals may be Involved In software engineering tasks (not restricted to

tool usage), and this may constitute a software engineering function.

Further, the event sequence Includes activities of a toolsmith who will not be

the same person as the software engineer In most cases- The former assignment

requires expertise In systems programming and specialized knowledge of the tool

to be Introduced. The duties of the software engineer Involve planning project

management, and obtaining cooperation from a variety of Individuals and

organizations. Where there Is a software engineering function, the toolsmith Is

typical ly a member of It,

Obstacles arising from the tools themselves are expected to be avoided In the

event sequence by a careful, methodical selection of tools. In particular,

distinct contributions to the tool selection are specified for software

management and the software engineer. Software management Is assigned

responslbi I tty for:
23

Identifying tool objectives.

Approving the acquisition plan (It may also require

approval by funding management).

Defining selection criteria.

Making the final selection of the tool or the source.

The software engineer Is responsible for:

Identifying candidate tools.

Applying the selection criteria (In Informal procurement)

or preparing RFP Inputs (In formal procurement).

Preparing a ranked list of tools or sourcesFurther, the ultimate user of the tool Is Involved In the recommended event

sequence In reviewing either the list of candidate tools or, for formal

procurement, the tool requirements.

This distribution of responsibilities reduces the chances of selecting a tool

that (1) does not meet the recognized needs of the organization, (2) Is

difficult to use. (3) requires excessive computer resources, or (4) lacks

adequate documentation. The repeated exchange of Information required by the

process outlined above will also avoid undue emphasis on very short-term

objectives which may lead to selection of a tool on the basis of availability

rather than suitability.

The obstacles to tool usage that reside In the computer environment are

primarily due to the great diversity of computer architectures and operating

system procedures, and to the lack of portability In most software tools.

Activities associated with the Introduction of tools can only modestly alleviate

these difficulties. The event sequence provides the following help In this

area:

1. A methodical process of Identifying candidate tools and selecting among

these on the basis of established criteria. This will avoid some of the

worst pitfalls associated with "borrowing" a tool from an acquaintance or procuring one from the most accessible or persuasive tool vendor.

2. The assignment and training of a toolsmlth who can make minor modifications

to both the computer environment and the tool. This Is expected to provide

relief where there are version-related or release-related Incompatibilities

with the operating system, or where the memory requirements of the tool

exceed the capabilities of the Installation, In the latter case, remedies

may be provided by removing tool options or by structuring the tool program

I nto over I ays.
24

The event sequence described below Is conceived as a procedure generally

applicable to tl^e introduction of tools to Federal agencies falling into

pertinent programming environment categories. For this reason, a systematic

reporting of the experience with the Introduction process as well as with the

tool is desirable. The evaluation plan and the evaluation report specified in

the event sequence support these goals.

5.2 RECOMMENDED EVENT SEQUENCE

The event sequence described in this subsection is applicable to both the

smaller MIS and scientific programming environments. The general scope of the

introduction activities and their sequence are identical for the two

environments. Because of differences In tool requirements, personnel

qualifications, and organizational structure, some differences In the content of

the Individual events will be expected. The event sequence addresses only the

Introduction of existing tools. Where a newly developed tool Is Introduced, a considerable modification of the activities and their sequence will be

necessary.

The recommended event sequence allows for two procurement methods: Informal

procurement (e. g., by purchase order) or formal procurement by request for

bids. Obviously, the latter Is much more time consuming but It may lead to the

procurement of better or cheaper tools. Acquisition of tools from the General

Services Administration or from other Government agencies should follow the

Informal procurement steps even when there Is no procedural requirement for

this. As mentioned above, tool acquisitions which do not obtain the concurrence

of all affected operational elements frequently do not achieve their objectives.

The presentation of the event sequence In Table 5-1 Is tailored to tools which are being Introduced for the first time Into a user community which shares

software support information (e. g., a Federal agency or a private sector

company). As a result, some steps are shown which can be combined or eliminated

where less formal control Is exercised or where plans or modifications required

for the introduction of a tool are available from a prior user. The event

sequence Is Intended to cover a wide range of applications, and it was

constructed with the thought that It Is easier for the tool user to eliminate

steps than to be confronted with the need for adding some that had not been

covered In this volume.

The key functions which contribute to the Introduction of tools are listed across the top of Table 5-1, and events for which each function Is responsible

are listed In the column under It. The preferred order of tasks for each

function can thus be directly found from this table. The precedence

relationships between events Is shown In graph form In Figure 5-1. This figure

will be found particularly helpful for scheduling activities by the Critical

Path Method and for the general development of a project schedule. The

numbering of events Is the same In Table 5-1 and Figure 5-1. A detailed

description of each of the numbered events, and of the activities associated

with It, Is presented following the table and figure.
25

TABLE 5 - 1 EVENT SEQUENCE FOR TOOL INTRODUCTION

FUNDING

MANAGEMENT

SOFTWARE

MANAGEMENT

SOFTWARE

ENGINEER

TOOL

USER

1 . Goa I

2. Tool Objectives

3. Procure tool

7, Receive tool

A < 14. Goals met?

A < A < A <

9. Orientation

A <

— 4. Eval uatlon pi an — 5. Tool smithing plan-S — 6. Tralnl ng p 1 an

8. Acceptance test

10. Modi float I ons-S

< 1 1 , Train

— 13. Evaluation report

- participates

ing > 12. Use

A. Acquisition Activities for Informal Procurement

A < A1 . Acquisition plan

A2. Select'n criteria

A6. Select tool

continue wit

A3. Ident. candidates

A5. Score candidates

h step 3 above.

A4 . Rev i ew

E Acquisition Activities for Formal Procurement

A <—

A < B5. Issue RFP

B1 . AcquI sltion pi an

„ A <

B7, Select source

cont i nue w i t

B2. Technical req'mts

- B4. Generate RFP

B6. Proposal Evaluation

h step 3 above.

B3. Review

A = Approval required S = Toolsmith responsibility
26

LU

jQ

O

n

ro c —

ro cl — c

Q- cn fo c —

E

LjJ -i _ (J

O

Q- O

4- O)C Q) - > C —

— 0)

(J

c

c o

O —

CL c O 0) o —

U 1-

ra —

+- u

o

CL

Q)co

Ol— Q_UJt— f— q;<o5:

to

ZJ

ro (1) t_ I/)

0

> o

0) -O CLC U

o— C

+- o

1/1 +- — u

J 0) cr —

(J CD

>• >

4- 0) •— 1_ +-C L. 0) Oi

(/I OJ +-

(0 s —

c

0) (J

1- Q) o —

U 0) < c/> — r3 CO CO

c -I- (0 E

CL cr

0) C L. S — U

in — — c

:3 ^

cr u u CD < (-

QCD cr

a:

CD

to

in

c

o

— — Q.

:j>

CD

CD U_ —

0)U

l_o

in

in H- O (J Q. CD O —

1- CD Q. CO

CN in <<<:<<< ^ lA CO CD CD CO CD CD

UJq:8

Q.

cro

UJo

z

UJ

ZDoUJCO

UJ>

UJ

a:o

I-<

UJ

Z

UJo

UJoUJ

UJ

OHo
27

1 . Goals

The goals to be accomplished should be Identified In a format that permits later

determination (event 14) that they have been met. Typical goal statements are:

reduce average processing time of COBOL programs by one-fifth; achieve complete

Interchangeabl I Ity of programs or data sets with organization Y; adhere to an established standard for documentation format.

The statement of goals shall also Identify responsibilities. In particular the

role that headquarters staff organization may have and coordination requirements

with other organizations. Where a decentralized management method is employedthe statement of goals may have associated with it a not-to-exceed budget and a desired completion date. Once these constraints are specified, funding

management may delegate the approval of the acquisition plan to a lower level.

2. Tool Objectives

The goals generated in event 1 are translated into desired tool features (e.g., see TabI e 4-1 ) , and requirements arising from the development and operating

environment are Identified. Constraints on tool cost end availability may also

be added at this event. A typical statement of tool objectives for a program

formatter Is: Provide header Identification, uniform Indentation, and the

facility of printing listing and comments separately for all FORTRAN X3.9-1978

and ABC Extended FORTRAN programs. Program must run on our ABC computer under

XOSnn. Only tools which have been In commercial use for at least 1 year and at

no less than N different sites shall be considered.

At this point the sequence continues with either A1 or B1 below.

A, Acquisition Activit ies for In formal Procurement

A1 , Acquisition Plan

The acquisition plan communicates the actions of software management both upward

and downward. The plan may also be combined with the statement of the tool

objectives (event 2). The acquisition plan should Include the budgets and

schedules for subsequent steps In the tool introduction, a justification of

resource requirements In the light of expected benefits, contributions to the

Introduction expected from other organizations (e. g., the tool Itself,

modification patches, or training materials), and the assignment of

responsibility for subsequent events within the software organization,

particularly the Identification of the software engineer. Minimum tool

documentation requirements shall also be specified In the plan.

A2. Selection Criteria

The criteria shall Include a ranked or weighted listing of attributes ihat will

support effective utilization of the tool by the user. Typical selection

criteria are:
28

Accomplishment of specified tool objectives.

Ease of use. Ease of Installation.

Minimum processing time.

Compatibility with other tools.

Low purchase or lease cost.

Most of these criteria need to be factored further to permit objective

evaluation, but this step may be left up to the Individual who does the scoring.

Together with the criteria (most of which will normally be capable of a scalar

evaluation), constraints which have been imposed by the preceding events or are

generated at this step should be summarized.

A3. Identify Candidate Tools

This Is the first event for which the software engineer Is responsible. The

starting point for preparing a listing of candidate tools Is a comprehensive

tool catalogue, such as IIH0UG82]. A desirable but not mandatory practice is to

prepare two lists, the first of which does not consider the constraints and

contains all tools meeting the functional requirements. The Cross-Ref erence by

tool features In the appendices of CH0UG82I] will be found particularly valuable

In generating this list of candidates. For the example used In event 2, a program formatting tool, 16 entries are found there. Some of these may be

eliminated by further review of their description In the body of the catalogue

(e. g., because they don't process the specified FORTRAN dialects). For the

remaining viable candidates, literature should be requested from the developer,

and this Is examined for conformance with the given constraints. At this point

a second list Is generated, containing tools that meet both the functional

requirements and the constraints. If this list does not have an adequate number

of entries, relaxation of some constraints will have to be considered,

A4. User Review of Candidates

The user reviews the list of candidate tools prepared by the software engineer.

Because few users can be expected to be very knowledgeable In the software tools

area, specific questions may need to be raised by software management such as:

"Will this tool handle the present file format? Are tool commands consistent

with those of the editor? How much training will be required?" Adequate time

should be budgeted for this review and a due date for responses should be

Indicated. Because the user views this as a far-term task, of lower priority

than many Immediate obligations, considerable follow-up by line management will

be required. If tools can be obtained for trial use, or If a demonstration at

another facility can be arranged. It will make this step much more significant.

A5 . Score Candidates

For each of the criteria previously Identified a numerical score Is generated

on the basis of Information obtained from vendor's literature, from

demonstration of the tool, from the user's review, from observation In a working

environment, or from comments of prior users. If weighting factors for the

criteria are specified, the score for each criterion Is multiplied by the
\

29

appropriate factor and the sum of the products represents the overall tool score. Where only a ranking of the criteria was provided, the outcome of the

scoring may be simply a ranking of each candidate under each of the criteria

headings. Frequently a single tool Is recognized as clearly superior In this

process,

A6. Select Tool

This decision Is reserved for software management In order to provide review of

the scoring, and also to permit additional factors which were not expressed in

the criteria to be taken Into consideration. For example, a report might just

have been received from another agency that the selected vendor did not provide

adequate service. If the selected tool was not scored highest, the software

engineer should have an opportunity to review the tool characteristics

thoroughly to avoid unexpected Installation difficulties. The selection

concludes the separate sequence for Informal procurement. Continue with event

3.

Acquisition Activit ies for Formal Procurement

Bl , Acquisition Plan

The plan generated here must Include all elements mentioned under A1 plus the

constraints on the procurement process (e, g,, set-aside for high labor surplus

areas) and the detailed responsibilities for all procurement documents

(statement of work, technical and administrative provisions In the Request for

Proposa I , etc , )

,

62, Technical Requirements Document

The technical requirements document Is an Informal description of the tool

requirements and the constraints under which the tool has to operate. It will

utilize much of the material from the acquisition plan but should add enough

detail to support a meaningful review by the tool user,

B3, User Review of Requirements

The user reviews the technical requirements for the proposed procurement. As In the case of event A4, the user may need to be prompted with pertinent questions,

and there should be close management follow up In order to get a timely

response,

84, RFP Generation

From the technical requirements document and the user comments on It, the

technical portions of the RFP can be generated. Usually these Include:

1, A specification of the tool as delivered. This should Include

applicable documents, a definition of the operating environment, and

the quality assurance provisions.
30

2. A statement of work governing the tool procurement. This should

state any applicable standards for the process by which the tool Is

generated (e. g., configuration management of the tool), and

documentation or test reports to be furnished with the tool.

Training and operational support requirements are also identified in

the statement of work.

3. Proposal evaluation criteria and format requirements. Evaluation

criteria are listed In the approximate order of Importance.

Subfactors for each may be Identified. Restrictions on proposal

format (major headings, page count, desired sample outputs) may also

be included.

B5. Solicitat ion of Proposals

This activity is carried out by administrative personnel. Capability lists of

potential sources are maintained by most purchasing organizations. Where the

software organization knows of potential bidders, their names should be made

known to the procurement office. When responses are received, they are screened

for compliance with major legal provisions of the RFP.

B6. Technical Evaluation

Each of the proposals received in response to the RFP is evaluated against the

criteria previously established. Failure to meet major technical requirements

can lead to outright disqualification of a proposal. Those deemed to be in "the

competitive range" will be assigned point scores that will then be used together

with cost and schedule factors that are being separately evaluated by

administrative personnel.

B7 . Source Selection

On the basis of the combined cost, schedule, and technical factors, a source for

the tool Is selected. If this was not the highest rated technical proposal,

prudent management will require additional reviews by software management and

the software engineer to determine that it Is Indeed acceptable.

The source selection concludes the separate sequence for formal procurement.

Continue with event 3.

3. Procure Tool

In addition to determining that the cost of the selected tool Is within the

approved budget, the procurement process will also consider the adequacy of

licensing and other contractual provisions and compliance with the "fine print"

associated with all Government procurements. The vendor's responsibility for

furnishing the source program, for meeting specific test and performance

requirements, and for tool maintenance need to be identified. In Informal

procurement, a period of trial use may be considered if this had not already

taken place under one of the previous events.
31

If the acquisition plan Indicates the need for outside training, the ability of

the vendor to supply the training and the cost advantages from combined

procurement of tool and training should be Investigated. If substantial savings

can be realized through simultaneous purchase of tool and training, procurement

may be held up until outside training requirements are defined (event 6).

4. EvaluatlQP Plan

The evaluation plan Is based on the goals Identified In event 1 and the tool

obectlves derived from these In event 2. It describes how the attainment of

these objectives Is to be evaluated for the specific tool selected. Typical

Items to be covered In the plan are milestones for Installation, dates and

performance levels for the Initial operational capability and for subsequent

enhancements. Where Improvements In throughput, response time, or turn-around

time are expected, the reports from which these data are to be obtained should

be Identified, Responsibility for tests, reports and other actions should be

assigned In the plan. A topical outline of the Evaluation Report should be

I ncl uded.

The procedure for the acceptance test Is a part of the Evaluation Plan, although

In a major tool procurement It may be a separate document. It lists the

detailed steps necessary to test the tool In accordance with the procurement

provisions when It is received, to evaluate the Interaction of the tool with the

computer environment (e. g., adverse effects on throughput), and for generating

an acceptance report,

5. Toolsmlthlng Plan

The plan will describe the selection of the toolsmlth, the responsibilities for

the adaptation of the tool, and the training which will be required. The

toolsmlth should preferably be an experienced system programmer, familiar with

the current operating system. Training In the operation and Installation of the

selected tool In the form of review of documentation, visits to current users of

the tool, or training by the vendor must be arranged. The toolsmlthlng plan Is

listed here as an event for which the software engineer Is responsible, and In

the discussion of further events It Is assumed that the toolsmlth will work

under the direction of the software engineer. The toolsmlthlng plan should be

approved by software management.

6. Training Plan

The training plan should first consider the training Inherently provided with

the tool, e, g,, documentation, test cases, on-line diagnostics, HELP. These

features may be supplemented by standard training aids supplied by the vendor

for In-house training such as audio or video cassettes and lecturers. Because

of the expense, training sessions at other locations should be considered only

where none of the previous categories Is available. The number of personnel to

receive formal training should also be specified In the plan, and adequacy of

In-house facilities (number of terminals, computer time, etc.) should be

addressed. If training by the tool vendor Is desired, this should be Identified

as early as possible to take permit training to be procured with the tool (see
32

step 3). User Involvement In the preparation of the training plan Is highly

desirable, and coordination with the user Is considered essential. The training

plan Is normally prepared by the software engineer and approved by software

management. Portions of the plan should be furnished to procurement staff If

outside personnel or facilities are to be utilized.

7. Tool Received

The tool is turned over by the procuring organization to the software engineer.

8. Acceptance Test

The software engineer or staff test the tool. This is done as much as possible

In an "as received" condition with only those modifications made that are

essential for bringing it up on the host computer. A report on the test Is

issued. After approval by software management it constitutes the official

acceptance of the tool.

9. Qr i^ntat ion

When it has been determined that the tool has been received in a satisfactory

condition, software management holds an orientation meeting for all personnel

Involved In the use of the tool and tool products (reports or listings generated

by the tool). The main purpose Is to communicate as directly as possible the

objectives of the tool use, such as increased throughput or Improved legibility

of listings. Highlights of the evaluation plan should also be presented, and

any changes In duties associated with the introduction of the tool should be

described. Personnel should be reassured that allowance will be made for

problems encountered during the Introduction, and that the full benefits of the

tool may not make themselves felt for some time.

10. Modifications

This step Is carried out by the toolsmlth In accordance with the approved

toolsmlthing plan. It includes modifications of the tool Itself, of the

documentation, and of the operating system. In rare cases some modification of

the computer proper may also be necessary (channel assignments, etc.). Typical

tool modifications involve deletion of unused options, changes in prompts or diagnostics, and other adaptations made for efficient use in the prevailing

environment. Documentation of the modifications Is an essential part of this

event.

Vendor literature for the tool Is reviewed In detail and Is tailored for the

prevailing computer environment and for the tool modifications which have been

made. Deleting sections which are not applicable can be Just as useful as adding material that Is required for the specific programming environment.

Unused options shall be clearly marked or removed from the manuals. If there Is some resident software for which the tool should not be used (e. g., because of

language Incompatibility or conflicts In the operating system interface),

warning notices should be inserted into the tool manual.
33

1 1 . Tra I n I ng

Training Is a joint responsibility of the software engineer and the tool user. The former Is responsible for the content (In accordance with the approved

training plan), and the latter should have control over the length and

scheduling of sessions. Training Is an excellent opportunity to motivate the

user to utilize the tool. The tool user should have the privilege of

terminating steps In the training that are not helpful and of extending portions

that are helpful but In which greater depth Is desired. Training Is not a one-time activity. Retraining or training in the use of additional options

after the Introductory period Is desirable. This also provides an opportunity

for users to talk about problems with the tool.

12. Use In the Operating Environment

The first use of the tool In the operational environment should Involve the most

qualified user personnel and minimal use of options. The first use should not

be on a project with tight schedule constraints. Any difficulties resulting

from this use must be resolved before expanded service is initiated. If the

first use is successful, then use by additional personnel and use of further

options may commence.

User comments on training, first use of the tool, and use of extended

capabilities are prepared and furnished to the software engineer. Desired

improvements In the user Interface, speed or format of response, and in

utilization of computer resources are appropriate topics. Formal comments may

be solicited shortly after the Initial use, after 6 months, and again after 1 year.

13. Evaluation Report

The soft-ware engineer prepares the Evaluation Report, using the outline

generated In event 4. The user comments and observations of the tool smith form

important inputs to this document. Most of all. It must discuss how the general

goals and the tool objectives were met. The report may Include, of course,

observations on the Installation and use of the tool, cooperation received from

the vendor in installation or training, and any other "lessons learned". Tool

and host computer modifications shall be described In the report. It may

contain a section of comments useful to future users of the tool. The report Is

approved by software management and preferably also by funding management,

14. Determine If Goals Are Met

Funding management receives the Evaluation Report and determines whether the

goals established In event 1 have been met. This determination shal I be In

writing and It shall Include:

Attainment of technical objectives.

Adherence to budget and other resource constraints.

Timeliness of the effort.

Cooperation from other agencies.

Recommendations for future tool acquisitions.
34

REFERENCES

ANSI78 American National Standards Institute. "Programming Language FORTRAN - American National Standard X3. 9-1 978"

BRAN81 Martha A. Branstad and W. Richards Adrlon, "NBS Programming Workshop

Report", NBS Special Publication 500-78. National Bureau of Standards,

June 1981

BRAY81 Gary Bray et a I., "Compiler-Based Programming Support Capabilities",

NBSIR 81-2423, January 1982

BR0075 F. P. Brooks, Jr., The Mythical Man-Month , Add I son-Wes I ey, Reading MA,

1975

D0TY77 D. Doty et al., "Software Cost Estimation Study" (2 vols),

RADC-TR-77-220. Rome Air Development Center, August 1977

FCSC80 Federal Conversion Support Center. "Conversion Products/Aids Survey",

Report No. GSA/FCSC-80-01 (138 pp.)

HECH81 H. Hecht, "A Survey of Software Tools Usage", NBS Special Publication,

In preparation

H0UG81 R. C. Houghton, Jr., "Features of Software Development Tools", National

Bureau of Standards, NBS Special Publication 500-74, February 1981

H0UG82 R. C. Houghton. Jr., "Software Development Tools", National Bureau of

Standards, NBS Special Publication 500-88, March 1982

IEEE81 IEEE Computer Society, Co mputer , Special Issue on Programming

Environments, April 1981

JAME77 T. G. James, Jr., "Software Cost Estimating Methodology", NAECQN'77

Proceedings , pp. 22-28, Dayton OH. May 1977

KERN76 Brian Kernlghan and P. J. Plauger. Software Tools ^ Add I son-Wes I ey.

Reading MA, 1976

PUTN78 Lawrence H. Putnam, "Example of an Early Sizing, Cost and Schedule

Estimate for an Application Software System", Proc. CQMPSAC'78 . pp.

827-832, November 1978

REIF80 D. J. Relfer and H. A. Montgomery, "Software Tool Taxonomy", Report

SMC-TR-004. Software Management Consultants, Torrance CA, June 1980
35

APPENDIX

WORKSHOP ON PHASING OF SOFTWARE TOOLS

NATIONAL BUREAU OF STANDARDS

Lecture Room B, Administration Building

Monday, 18 May 1981

AGENDA

0900 - 0930 Welcome to NBS

0930 ~ 1000 Software Automation Project and

Objectives of the Workshop

1000 - 1015 Coffee Break

1015 - 1100 Survey of Software Tool Usage

1100 - 1215 Tools Introduction Experience

NASA Lang ley

Naval Air Development Center

NASA Goddard

M. Branstad, NBS

R. C. Houghton, NBS

H. Hecht, SoHaR

S. Volgt

H. Stuebing

F. McGarry

1215 - 1313 Lunch

1315 - 1400 Guidelines for Phasing Software Tools

Into Development Environments

1400 - 1445 Discussion Groups

1445 - 1500 Coffee Break

1500 - 1545 Event Sequence for Tool Introduction

1545 - 1630 Discussion Groups

1630 - 1700 Wrap-Up

H. Hecht, SoHaR

H. Hecht, SoHaR
WORKSHOP ON PHASING OF SOFTWARE TOOLS

PARTICIPANTS

36

Leo Beltracchl

Nuclear Regulatory Commission

Martha Branstad

National Bureau of Standards

Arthur F. Chantker

Federal Aviation Administration

Lorral ne Duval I NT Research Institute

Shel la Frankel

National Bureau of Standards

Tony Green

Federal Trade Commission

Herbert Hecht

SoHaR Incorporated

Terry Heidelberg

Lawrence LIvermore Laboratory

Larry Hoover

CRC

Raymond Houghton

National Bureau of Standards

Arnold Johnson

Federal Computer Testing Center

Linda Lawrle

US Army - CERL

Larry Lombando

Rome Air Development Center

Frank McGarry

NASA Goddard Spaceflight Center

Albert Moy

Federal Bureau of Investigations

Albrecht Neumann

National Bureau of Standards

Pat Powel

I

National Bureau of Standards

Carol Proctor

Illinois Institute of Technology

Wray Sexson

Defense Mapping Agency

A I Sorkowltz

Department of Housing & Urban Devlpmt,

Janet Stearns

Defense Mapping Agency

Henry G. Steublng

Naval Air Development Center

Susan Volgt

NASA Lang ley Research Center

REVIEWERS

Plo De Feo Marvin Zelkowltz

NASA Ames Research Center University of Maryland

Patricia (Santonl) Oberndorf

Naval Ocean Systems Center
NBS-lUA (REV. 2-8C) U.S. DEPT. OF COMM.

BIBLIOGRAPHIC VI Vlw 1 V VI 1 •1 III w DATA w r 1 I SHEET (See instructions)

1. PUBLICATION OR

REPORT NO.

NBS SP 500-91

2. Performing Organ. Report No .1 3. Publication Date September 1982

4. TITLE AND SUBTITLE

Computer Science and Technology:

The Introduction of Software Tools

5. AUTHOR(S)

Herbert Hecht

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

SoHaR Incorporated

1040 So. La Jolla Avenue

Los Angeles, California 90035

7. Contract/Grant No.

8. Type of Report & Period Covered

Final

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

National Bureau of Standards

Washington, DC 20234

10. SUPPLEMENTARY NOTES

Library of Congress Catalog Card Number: 82-600577

[]J Document describes a computer program; SF-185, FlPS Software Summary, is attached.

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

bibliography or literature survey, mention it here)

From a survey of current tool usage It Is concluded that the greatest

obstacles to effective use of software tools are encountered In

organizations employing fewer than 40 programmers , and the needs of

these environments are therefore emphasized. Specific needs for

software tools In programming for management Information systems and

for scientific applications are discussed. Measures are described to

overcome organizational obstacles to use of tools, to deal with

problems arising from the tools, and to reduce the difficulties posed

by existing computer Installations.

Steps required for the successful Introduction of tools are organized

In two ways: by the function responsible for their accomplishment, and

by the time schedule In which they must be completed. The detail work

to be performed In each step Is described.

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

computer environments; software; software engineering; software management;

software quality; software tools; tool smith.

13. AVAILABILITY

^5 Unl imited Q For Official Distribution. Do Not Release to NTIS

gX] 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

41

15. Price

$4.75

USCOMM-DC 6043-P80

<l U . S . GOVERNMENT PRINTING OFFICE: 1 9 8 2-360- 997 /2 207
i
ANNOUNCEMENT OF NEW PUBLICATIONS ON

COMPUTER SCIENCE & TECHNOLOGY

Superintendent of Documents,

Government Printing Office,

Washington, D. C. 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

(Notiflcation key N-S03)



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 time 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, $4.25 domestic; $5.35 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 information 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 administer.s 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 technological marketplace. Order the above NBS publications from: Superintendent oj Documents. Government Printing Office. Washington. DC 20402. Order the following NBS publications—FIPS and NBSIR's—Jrom

the National Technical Information Services. Springfield. VA 22161

Federal Information Processing Standards Publications (FIPS

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 regarding standards issued by NBS pursuant to the Federal Properly 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 II, 1973) and Pari 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 Services, 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