* The increasing criticality of software mandates a standardfor software quality assurance plans. Such a standardc,

developed by the Computer Society 's Software EngineeringStandards Subcommittee, appears here.

A Standard for SoftwareQuality Assurance Plans

Fletcher BuckleyRCA Government Systems Division

Computer system usage is booming-the marketis increasing, and microprocessors are entering areassuch as industrial process control and transporta-tion. The signs of another great expansion are allaround us. For example, the global minicomputermarket is growing from $310 million annual sales in1971 to $2 billion in 1976 to an estimated $6.5 billionin 1981.1However, despite all the computer usage to date,

the efforts of many highly-motivated people andorganizations, and the vast outpouring of the soft-ware engineering field, the common computer sys-tems with which we come into daily contact continueto fail. A few close-to-home examples make the point:

* The new software-controlled PABX recently in-stalled in our plant became inoperable four timesin one week. After that, the count was abandoned.

* The vendor-supported software at the corporatecomputer center provided the error statisticsshown below.

MonthMarch 1978April 1978May 1978June 1978

New software errors32353528

The failure of someDP systems, however, would beso disastrous that they cannot be allowed to fail. Apurist would observe that all eventually fail. Never-theless, the possibility of a failure in such systemsmust be as close to zero as possible. Consider, for ex-ample, the following:

* Two aircraft recently collided over San Diego,with tragic results. One aspect of the disasterreceiving attention in the press was the questionof the adequacy of the local flight-controlsystems. Faced with today's dense air traffic andpublic demand for greater safety, the FAA ismoving more and more into computer-assistedflight control.

* Electronic funds transfers are rapidly approach-ing common use. Should a portion of the finan-cial/banking system grind to a halt, for even alimited period of time, the negative social conse-quences might be far reaching indeed.2

* Patient monitoring, using complex medical in-strumentation in hospital intensive care wards,is rapidly becoming computerized.

* Nuclear reactor safety systems, now under in-tense public scrutiny, are coming increasinglyunder computer control.

As a further example, consider the following: Apolice officer is chasing a speeder. In the course of thechase, the police officer is informed via a computer-accessed data base that the speeding vehicle is stolen.The motorist is shot and killed. It is later determinedthat the vehicle was not stolen and that the erroneousreport was made due to a software failure. The speci-fic liabilities associated with excessive use of forceare not clear.Each group addressing these areas is breaking new

ground in hitherto uncharted country. Each is seek-ing to obtain and to provide assurance to others thatthe systems will work, and, further, that the softwarewill work reliably. The question then arises-how isthat assurance to be provided?

0018-9162/7910800-0043$00.75 © 1979 IEEE 43August 1979

PaEfforts to establish the standard

Assurance that a product will work is classicallyprovided by a test of the product at the end of itsdevelopment period. Because of the nature of soft-ware, no test appears sufficiently comprehensive.Hence assurance has taken the form of instrument-ing the development process itself, i.e., softwareengineering methodology, with checks and balances.These checks and balances provide visibility to con-cerned groups.Providing this assurance is made more difficult for

software practitioners because of a number of fac-tors. There are many software engineering method-ologies by which software is developed, and no stan-dard methodology exists to ensure that software ac-quires the required characteristics as developmentprogresses. Moreover, there is no industry standardfor expressing plans to implement assurance pro-grams for software development.The problems mentioned above are not new, and at-

tempts to resolve them require awareness of other ef-forts in the field. The hardware world has facedsimilar problems and from their solutions have comeengineering specialty areas such as quality assuranceand configuration management. In like manner, theDepartment of the Army has originated a separateStandard for Software Quality Assurance Programs,MIL-S-52779, and this is in process of being appliedthroughout the Department of Defense. The Nation-al Bureau of Standards, through its Institute forComputer Science and Technology, has been active inthe development of software standards.3 The Na-tional Security Industrial Association Quality andReliability Assurance Committee has an active soft-ware subgroup concerned with these problems.* TheElectronic Industry Association's G-33 Committeehas been active in the field, particularly in support ofDepartment of Defense efforts.In view of these efforts, the Software Engineering

Standards Subcommittee of the IEEE ComputerSociety's Technical Committee on Software Engi-neering undertook the work of composing a proposedstandard.** This'article provides an overview of the ef-forts aimed at producing an IEEE "Standard forSoftware Quality Assurance Plans." Toward thisend, the rationale which led to the preliminary stan-dard is recapitulated in footnotes appearingthroughout it.

The work progressed as indicated below.

EventInitial organization of subgroupFirst partial proposed draft ofstandard completed

First complete proposed draft ofstandard completed

Second complete proposed draft ofstandard completed

Project approval request forstandard received from IEEEStandards Board

First 'official draft of standardcompleted

Second official draft completedFirst poll of the Software Engi-neering Standards Subcommitteecompleted

Fifth official draft approved bysubgroup

Second poll of the SoftwareEngineering Standards Sub-committee completed*

Proposed standard provided toIEEE Standards Board foradoption as trial-use standard

DateJuly 30, 1976

Nov. 22,1976

Sept. 6, 1977

Feb. 2, 1978

Feb. 5, 1978

April 5, 1978July 10, 1978

Oct. 15, 1978

Dec. 21, 1978

Summer 1979

Projected forFall 1979

The standard

The current draft of the standard appears on thefollowing pages.** Footnotes explain items whichmight otherwise be obscure, and provide backgroundon the subgroup's rationale. The footnotes are notpart of the draft standard.

Trial-Uset Standard forSoftware Quality Assurance Plans

Foreword

This foreword is not a part of Standard P730, Stan-dard for Software Quality Assurance Plans.

*National Security Industrial Association, Union TrustBuilding, 740 15th Street NW, Suite 700, Washington, DC20005.**The path that a standard takes, from inception to ap-proval, is covered elsewhere and so will not be coveredhere.4 One of the items that must be obtained is a consensusof those concerned with the issues. This, together with thefact that the individuals volunteered their time over andabove their normal business workload, resulted in a longeieffort than initially envisioned.

*This involved approximately 108 persons from industry,academia, and government.**This is Draft D5-R1. Rl is identical to Draft D5, but cor-rects two typographical errors.tTrial-use standards are normally issued for a two-yearperiod; the first year is used for collection of comments andthe second year for revision of the document and submis-sion as a full-status IEEE standard. The notation of "Trial-Use" as opposed to' "Full-Status" is authoritatively de-fined in Section 4.2 of reference 4.

Preliminary-Subject to Revision

Providing assurance

44 COMPUTER

This standard assists in the preparation and con-tent of Software Quality Assurance Plans and pro-vides a standard against which such plans can beprepared and assessed. It is directed towards thedevelopment and maintenance of critical software,i.e., where failure could impact safety or cause largefinancial or social losses.*There are three groups to whom this standard ap-

plies: the user, the developer, and the public.(1) The user, who may be another element of the

same organization developing the software,has a need for the product. The user furtherneeds the product to meet the requirementsidentified in the specification. The user thuscannot afford to adopt a "hands-off" attitudetoward the developer and rely solely on a test tobe executed at the end of the software develop-ment time period. If the product should fail, notonly does the same need still exist but also aportion of the development time has been lost.The user therefore needs to obtain a reasonabledegree of confidence that the product is in pro-cess of acquiring required attributes duringsoftware development.**

(2) The developer needs an established standardagainst which to plan and to be measured. It isunreasonable to expect a complete reorienta-tion from project to project. Not only is it notcost-effective, but unless there exists a stableframework on which to base changes, improve-ments cannot be made.

(3) The public may be affected by the user's use ofthe product.These include,forexample, deposi-tors at a bank and passengers using a reserva-tion sytem. These have requirements, e.g., legalrights, which preclude haphazard developmentof software. This may imply, at some later date,

*There are three major reasons for a software qualityassurance prbgram:

(1) Legal Liability. If the product fails, is the producer atfault? Did the producer act as a reasonable and prudent per-son in developing the software? This type of question im-plies a need for a standard for providing assurance that allnecessary actions were identified and taken. Hence thisstandard.

(2) Cost-effectiveness. In this category, beauty lies in theeye of the beholder. There are so many variations in soft-ware methodology that any attempt to specify a standardfor a software quality assurance plan aimed at cost-effectiveness is considered inappropriate at this time. Eachcase is unique and each implementation becomes a matterfor management judgment. Further, while the cost-effectiveness of software quality assurance has beenrepeatedly postulated, the author has been unable to locateany hard numbers in the published literature. One reasonfor this may be that many of the things required by a soft-ware quality assurance plan are already done, at least inpart, under different names in different organizations.

(3) Customer requirements. This is a matter of detailednegotiation between the customer and the producer and isbased, in part, on the customer's perception of his need. Assuch, it does not appear suitable for an industry standard.**From this can be seen that the thrust of the plan is that ofa process specification, i.e., what techniques, procedures,and operations are projected for use.

requirements on the user and the developer toshow that they acted in a reasonable and pru-dent professional manner to ensure that re-quired software attributes were acquired.

This standard was prepared by the SoftwareEngineering Standards Subcommittee of the Soft-ware Engineering Technical Committee of the IEEEComputer Society.At the time it approved the document, the subcom-

mittee had the following membership: *R. Poston, Chairperson

The membership of the working group was asfollows:

F. Buckley, Chairperson

The existence of this document in its present formshould not be construed to imply that a consensuswas achieved on it. Rather, this is intended to be abasis through which consensus can be reached. Com-ments should be provided to:

F. BuckleyRCA103 Wexford DriveCherry Hill, NJ 08003(609) 424-5436

with copies to:R. PostonComputer Sciences Corporation19 Onodago TrailMedford Lakes, NJ 08055

andStandards Liaison**IEEE Standards Office345 East 47th StreetNew York, NY 10017

1. Scope

The purpose of this standard is to provide uniform,minimum acceptable requirements for the prepara-tion and content of Software Quality Assurance(SQA) Plans. tThis standard applies to the development and

maintenance of critical software, i.e., where failurecould impact safety or cause large financial or social

*The list of members of the subcommittee and of the work-ing group for the standard will be furnished later.**The Standards Liaison Office provides long-term con-tinuity throughout the standard's life cycle.- The concern here is that the basic plan of producing thesoftware should be well-defined. In this context it should benoted that various segments of industry have means bywhich plans are expressed. The appearance of this standarddoes not dictate what approach is to be used. It does,however, identify common elements required for qualityassurance.

Preliminary-Subject to RevisionAugust 1979 45

losses. For non-critical software, or for softwarealready developed, a subset of the requirements ofthis standard may be applied.*The existence of this standard should not be con-

strued to prohibit additional content in a SoftwareQuality Assurance Plan. An assessment should bemade for the specific software product item to assureadequacy of coverage. Where this standard is in-voked for a project engaged in producing-several soft-ware items, the applicability of the standard shouldbe specified for each ofthe software product items en-compassed by the project.

2. Definitions**

The definition listed below establishes the meaningof words in the context of their use in this standard.Other definitions can be found in ANSI X3/TR-1-77,the American National Dictionary for InformationProcessing, September 1977.6

Quality Assurance. A planned and systematic pat-tern of all actions necessary to provide adequate con-fidence that the item or product conforms to estab-lished technical requirements.***

3. Software Quality Assurance Plan

The organization responsible for Software QualityAssurance shall prepare a Software QualityAssurance Plan which includes the sections listedbelow. t The sections should be ordered in the describ-ed sequence. tt If there is no information pertinent toa section, the following shall appear below the sectionheading: "This section is not applicable to this plan,"together with the appropriate reasons for this exclu-sion.

*One significant question was faced early in the pro-gram-Should the current military standard, MIL-S-52779, be adopted? The response was negative for thefollowing reasons: (1) The military standard is supported byan internal system of other standards on documentation,configuration management, etc. Those standards, in turn,branch out to still further items and so forth. Review of thecomplete set would be required but was clearly beyond thescope of the group. (2) The military standard is controlledand changed by the United States Department of Defense.It can be and is today being changed by that group. Toadopt their standard would have implied replacing thejudgment of an independent consensus with the judgmentof a group subjected to an authoritative discipline. Thiswas not considered appropriate.

Prior to sending the draft of the standard out for subcom-mittee vote, it was audited against the military standard,the FAA standard, and the NRC standard. No conspicuousomissions were found.**In retrospect, we consumed an inordinate amount of timein defining terms, most of which we eventually did not use.Our subgroup benefited from a parallel software engineer-ing terminology effort (see references 5 axid 6).***This definition was abstracted from MIL-STD-109B.Prior to its abstraction, significant efforts were made torelate "Quality Assurance" to "Quality."

1.0 Purpose2.0 Reference documents3.0 Management4.0 Documentation5.0 Standards, practices, and conventions6.0 Reviews and audits7.0 Configuration management8.0 Problem reporting and corrective action9.0 Tools, techniques, and methodologies

10.0 Code control11.0 Media control12.0 Supplier control

Additional sections may be added at the end, as re-quired. Some of this material may appear in otherdocuments. If so, then reference to those documentsshould be made in the body of this plan.Details for each outline paragraph are contained in

the following.

3.1 Purpose (Section 1.0 of the Plan)

This section shall delineate the specific purpose ofthis particular Software Quality Assurance Plan(SQAP). It shall list the name(s) of the software pro-duct items covered by the SQAP and the intendeduse of the software.

3.2 Referenced documents (Section 2.0 of the Plan)This section shall provide a complete list of

documents referenced elsewhere in the text of thisplan.

3.3 Management (Section 3.0 of the Plan)This section shall describe the organization, tasks,

and responsibilities.

3.3.1 OrganizationThis paragraph shall depict the organizational

structure which influences the quality of the soft-

tNotS that this standard does not specify each and everyaction to be taken by the producer.It does specify the typeof actions that the producer is to identify. In this context,the current actions of a joint working group of IEEE andthe American Nuclear Society, working on ProjectP742-"Standard Criteria for the Application of Program-mable Digital Computer Systems in Safety Systems ofNuclear Power Generating Systems"-are of interest. Thisproject is aimed at providing general guidance for systemsdesign and specific guidance in the application of program-mable digital computer systems. In addressing the needs ofa specific community, their work will provide valuable in-sights into the feasibility of additional standards in, for ex-ample, software verification.Note that no requirement exists for a separate "Quality

Assurance" or "Software Quality Assurance" organiza-tion. This was a very difficult point to reach. A number ofthe individuals in the subcommittee were familiar withDepartment of Defense management methods, which in-clude such an organization. A conscious group effort wasrequired to recognize the broader audience and its needs.tiTo communicate more effectively, and to make it easierto determine adherence to the standard, a specific formatfor presenting the information was considered necessary.

Preliminary-Subject to Revision46 COMPUTER

ware. This shall include a description of each majorelement of the organization together with the dele-gated responsibilities. Organizational dependence or

independence of the elements responsible for SQAfrom those responsible for software development anduse shall be clearly described or depicted.

3.3.2 TasksThis paragraph shall describe the tasks associated

with that portion of the software life cycle covered bythis plan, with special emphasis on software qualityassurance activities.* The sequence of the tasks shallalso be indicated.

3.3.3 ResponsibilitiesThis paragraph shall identify the specific organiza-

tional elements responsible for each task.

3.4 Documentation (Section 4.0 of the Plan)

3.41 Purpose

This section shall:

(1) Identify the documentation governing thedevelopment and verification of the software.

(2) State how the documents are to be checked foradequacy. This shall include identification ofthe review or audit by which the adequacy ofeach document shall be confirmed, withreference to Section 6.0 of the plan.

3.4.2 Minimum documentation requirements

To ensure that the implementation of the softwaresatisfies the requirements, the following documenta-tion is required as a minimum.**

3.4.2.1 Software Requirements Specification (SRS)

The SRS shall clearly and precisely describe each ofthe essential requirements (functions, design con-

straints, and attributes) of the software and the ex-

*The review/audit of the basic plan implementation shouldassure that unauthorized deviations from the plan will beexpeditiously identified. However, management can,should, and will change plans as situations develop. Im-plicit, however, in the management process is gainingassurance that the plan is being followed, especially withcritical software. Hence, some mechanics need to exist toprovide that assurance.

**The recognition of the need for standardization of com-puter program documentation is evidenced by the pro-liferation of standardization documents. For example, theDepartment of Defense has four different standards forcomputer program documentation: MIL-STD-483, MIL-STD-490, SECNAV 3560.1, and DoD Manual 4120.17M.The last item has been recently superseded by DoD Stan-dard 7935.1S. The federal government is addressing theneed, but an industry-wide approach has yet to emerge.

Initially, these subsections were expanded as the group

attempted to deal with this area. A need for a separatedocumentation standards effort was then recognized. Thesubcommittee is now initiating such an effort.

Preliminary-Subject to Revision

NEW AVAILAILEfrom the

IEEE COMPUTER SOCIETY

MICROPROCESSORS& MICROCOMPUTERSMICROPROCESSORS& MICROCOMPUTERSMCROPROCESSORS& MICROCOMPUTERSMICROPROCESSORS& MICROCOMPUTERSMICROPROCESSORS

DINSTITUTE OF ELECTRICAL4kIEEE COMPUTER SOCIETY AND ELECTRONIC ENGINEE-RS

_

I

Rs

August 1979

ternal interfaces. Each requirement shall be definedsuch that its achievement is capable of being objec-tively determined by a prescribed method.

3.4.2.2 Software Design Description (SDD)The SDD shall describe the major components of

the software design, including data bases and inter-nal interfaces. An expansion of this description shallbe included to describe each subcomponent of the ma-jor components.

3.4.2.3 Software Verification Plan (SVP)The SVP shall describe the methods to be used to

verify that:(1) The requirements in the SRS are implemented

in the design expressed in the SDD, and furtherinto the code.

(2) The code, when executed, meets the re-quirements expressed in the SRS.

3.4.3 OtherOther documentation may include the following:(1) Computer program development plan.(2) Configuration management plan.(3) Standards and procedures manual.

3.5 Standards, practices, and conventions (Section 5.0of the Plan)

3.5.1 PurposeThis section shall:(1) Identify the standards, practices, and conven-

tions to be applied.(2) State how compliance with these items is to be

monitored and assured.

3.5.2 ContentThe subjects covered shall include the basic

technical, design, and programming activities in-volved, such as documentation naming and coding,programming languages, and unit testing. As aminimum the following shall be provided:*

(1) Documentation standards.(2) Logic structure standards.(3) Coding standards.(4) Commentary standards.

3.6 Review and audits (Section 6.0 of the Plan)

3.6.1 PurposeThis section shall:(1) Define the technical reviews and audits to be

conducted.

*The list varied as the project progressed, going up to 25 atone point. Finally, the group decided that this set of fourwas sufficient for a "trial-use" standard. The interaction onthis section did, however, demonstrate'the need for addi-tional standards efforts.

(2) State how the reviews and audits are to be ac-complished.

3.6.2 Minimum requirementsAs a minimum, the following shall be conducted:

3.6.2.1 Software Requirements Review (SRR)The SRR is held to ensure the adequacy of the re-

quirements stated in the Software RequirementsSpecification.

3.6.2.2 Preliminary Design Review (PDR)The PDR is held to evaluate the technical adequacy

of the preliminary design of the software as depictedin a preliminary version of the Software DesignDescription.

3.6.2.3 Critical Design Review (CDR)The CDR is held to determine the acceptability of

the detailed software designs, as depicted in the Soft-ware Design Description, in satisfying the require-ments of the Software Requirements Specification.

3.6.2.4 Functional auditThis audit is held prior to the software delivery to

verify that all requirements specified in the SoftwareRequirements Specification have been met.

3.6.2.5 Physical auditThis audit is held to verify that the software and its

documentation are internally consistent and areready for delivery.

3.6.2.6 In-process auditsIn-process audits of a sample of the design are held

to verify consistency of the design, including:(1) Code versus design documentation.(2) Interface specifications (hardware and soft-

ware).(3) Design implementations versus functional re-

quirements.(4) Functional requirements versus test descrip-

tions.

3.7 Configuration management (Section 7.0 of thePlan)This section shall document the methods to be used

for identifying the software product items, control-ling and implementing changes, and recording andreporting change implementation status. Thisdocumentation shall either be provided explicitly inthis section or by reference to an existing configura-tion management plan.*

*Industry has already recognized the need to define dif-ferent configurations of code accurately, to control changesto these configurations, and to report on the status ofchange implementation. To reduce confusion concerningimplementation, a set of recommended practices would behighly desirable. Work to initiate this effort is underway inthe subcommittee.

48Preliminary-Subject to Revision48 COMPUTER

3.8 Problem reporting and corrective action (Section8.0 of the Plan)

3.8.1 PurposeThis section shall:(1) Describe the practices and procedures to be

followed for reporting, tracking, and resolvingsoftware problems.

(2) State the specific organizational respon-sibilities concerned with their implementation.

3.9 Tools, techniques, and methodologies (Section 9.0of the Plan)This section shall describe the special software

tools, techniques, and methodologies employed onthe specific project which support the QualityAssurance objectives, shall state their purposesand describe how their use will augment or satisfythese objectives.

3.10 Code control (Section 10.0 of the Plan)This section shall define the methods and facilities

used to maintain and store controlled versions ofidentified software. This may be implemented in con-junction with a computer program library.

3.11 Media control (Section 11.0 of the Plan)This section shall state the methods and facilities

to be used to protect computer program physical

PURCHASEFULL OWNERSHIP AND LEASE PLANS

PURCHASE PER MONTHDESCRIPTION PRICE 12 MOS. 24 MOS. 36 MOS.

LA36 DECwriter II ........... $1,595 $ 152 $ 83 $ 56LA34 DECwriter IV .......... 1,295 124 67 45LA120 DECwriter III, KSR .... 2,295 219 120 80LS120 DECwriter Ill, RO ..... 1,995 190 104 70LA180 DECprinter I, RO...... 1,995 190 104 70VT100 CRT DECscope ....... 1,695 162 88 59VT132 CRT DECscope ....... 1,895 181 97 66T1745 Portable Terminal ..... 1,875 179 98 66T1765 Bubble Memory Term. . 2,795 267 145 98Tl810 RO Printer .......... 1,895 181 99 66T1820 KSR Printer . ......... 2,395 229 125 84AOM3A CRT Terminal ....... 875 84 46 31OUME Letter Quality KSR..... 3,195 306 166 112QUME Letter Quality RO...... 2,795 268 145 98HAZELTINE 1410 CRT ....... 895 86 47 32HAZELTINE 1500 CRT ....... 1,195 115 62 42HAZELTINE 1520 CRT ....... 1,595 152 83 56DataProducts 2230 .......... 7,900 755 410 277DATAMATE Mini Floppy...... 1,750 167 91 61

FULL OWNERSHIP AFTER 12 OR 24 MONTHS10% PURCHASE OPTION AFTER 36 MONTHS

ACCESSORIES AND PERIPHERAL EQUIPMENACOUSTIC COUPLERS . MODEMS * THERMAL PAPERRIBBONS . INTERFACE MODULES . FLOPPY DISK UNITS

PROMPT DELIVERY - EFFICIENT SERVICE~~~ X_

Reader11 O m 1

Reader Service Number 10

media from unauthorized access or inadvertentdamage or degradation.

3.12 Supplier control (Section 12.0 of the Plan)This section shall state the provisions for assuring

vendor-provided and subcontractor-developed'soft-ware meets established technical requirements. As aminimum the supplier shall be required to prepareand implement a Software Quality Assurance Planin accordance with this standard. M

Acknowledgment

Production of this draft standard is due principallyto the support and assistance of the following: J.Cellini, D. Fife, H. Hecht, T. Hannan, P. Howley, J.McKissick, S. Mohanty, A. Neuman, R. Poston, andJ. Spalding.

References

1. B. Szuprowicz, "Minicomputer Markets Around theWorld," Mini-Micro Systems, Vol. 11, No. 4, May1978, p. 60.

2. For some of the concerns from the individual con-sumer's viewpoint see "The New Money, Promisesand Pitfalls of Electronic Funds Transfer," ConsumerReports, Vol. 43, No. 6, June 1978, pp. 354-358.

3. See, for example, Guidelines for Documentation ofComputer Programs and Automated Data Systems,FIPS PUB 38, Feb. 15,1976. Copies available from theSuperintendent of Documents, US Government Print-ing Office, Washington, DC 20402 (order SD CatalogNo. C13.52:38).

4. IEEE Standards Manual and Style for IEEE Stan-dards, IEEE Standards Board, 345 East 47th St., NewYork, NY 10017.

5. Draft Software Engineering Terminology, compiledby the Subcommittee on Software Engineering Stan-dards, Technical Committee on Software Engineering,IEEE Computer Society, March 23, 1978. Copy avail-able from R. Poston, CSC, 19 Onodago Trail, MedfordLakes, NJ 08055.

6. American National Standards Committee X3,American National Dictionary for Information Pro-cessing, Computers and Information 'ProcessingTechnical Report X3/TR 1-77, Sept. 1977, publishedby Computer and Business Equipment Manufac-turers Association, 1828 I St. NW, Washington, DC20036. This dictionary was adopted for use by thefederal government by FIPS PUB 11-1, and is for saleby the National Technical Information Service, USDepartment of Commerce, Springfield, VA 22161.

Fletcher Buckley is employed by RCA,where he works on software/firmwaredevelopment approaches. Prior to thathe worked on the development ofseveral Army command and control

' systems. Mr. Buckley received the BSdegree from the United States Military

f Academy in 1954 and the MSEE degreefrom Stanford in 1961. He.is a member

&jl̂ ^ l lof ACM-, IEEE, and the IEEE Com-puter Society.

Preliminary-Subject to Revision COMPUTER