spd: a humanized documentation technology

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-il, NO. 9, SEPTEMEBER 1985

led research and development of interactive software systems to supportdecision makers such as battlefield commanders, managers, planners,analysts, system designers, and programmers. He is currently supervis-ing work on expert systems for software engineering, database access,decision support, and a variety of analysis applications.Dr. McCune is on the Editorial Advisory Board of Defense Electronics

and the Advisory Board of The Artificial Intelligence Report.

Richard M. Tong (M'80) received the Ph.D. degree from CambridgeUniversity, Cambridge, England, in 1975.His main research interests are in intelligent decision support systems,

fuzzy set theory, theories of approximate reasoning, and artificial intel-ligence. He joined Advanced Information & Decision Systems in 1980where he is the Department Head for the Decision Systems Department.He has been conducting a program of research designed to explore theeffects of various forms of uncertainty representation in expert systems,and is currently leading a team that is performing research for the devel-opment of an intelligent informnation retrieval system.

(Wi4~ Jeffrey S. Dean (S'77-M'79j received the B.A.ffi _degree from Hampshire College, Amherst, MA,in 1978, and the M.S. degree in computer sci-

l ence from Stanford University, Stanford, CA,l1ll - ll in 1979.

He joined Advanced Information & Decisionl h* Systems in 198i, where he has pursued research

in artificial intelligence applied to programmingenvironments, software engineering, informa-tion retrieval, documentation, and user inter-faces.

Mr. Dean is a member of the Association for Computing Machinery,the American Association for Artificial Intelligence, and ComputerProfessionals for Social Responsibility.

* Daniel G. Shapiro received the M.S. degreefrom the M.I.T. Artificial Intelligence Lab,Massachusetts Institute of Technology, Cam-bridge, in 1981.

_ g Since that time, he has worked for AI&DS onthe topics of intelligent editors, uncertaintyrepresentation, Al applied to information re-trieval, and Al planning. He is currently direct-ing research towards a planning system whichwill guide the DARPA autonomous land vehiclethrough long distances in cross-country terrain.

SPD: A Humanized Documentation TechnologyMOTOEI AZUMA, TETSU TABATA, YOSHIHIRO OKI, AND SUSUMU KAMIYA

Abstract-The SPD (Structured Programming Diagram) it a documen-tation technology used to design well structured programs. With SPD,designers can easily express functional structure, control structure, andphysical layout of a program on one sheet of paper. Its straightforwardexpression appeals to both document writers and readers. SPD conceptand conventions are introduced in this paper. SPD usage is then ex-plained with a program-design example. Other documentation technol-ogies used in coordination with SPD are briefly touched upon. Finally,SPD reputation and evolution in the last ten years are reviewed.

Index Terms-Documentation, software development, StructuredProgramming Design.

I. INTRODUCTIONN OBODY is successful in software development withoutN sufficient documentation. Documentation provides in-formation to support the effective design, managemnent, imple-mentation, and mnaintenance, and to facilitate the interchangeof information. Documentation technology is important inorder to accomplish development smoothly and efficiently,and to maximize the return on development investment.

Manuscript received November 7, 1983.The authors are with the NEC Corporation, 7-15 Shiba, Minatoku,

Tokyo 108, Japan.

As a result of software engineering research and developmentactivities up to now, various useful programming technologieshave been developed, such as structured programming [1 ] -[3],stepwise refinement [41, top-down design [5], one page coding[6], structured design [7], [8], composite design [9], mod-ular programming method [10], [11], Warnier programmingmethod [12], M. Jackson programming method [13], etc.Reflecting these technologies, flowchart usefulness was ques-tioned [17], and various documentation techniques whichsupport these programming technologies to be use, have alsobeen developed, such as Warnier-Orr diagram [12], [14], [15],Jackson diagram [13], [16], NS chart [18], [19], Chapinchart [20], HIPO [21], etc. Although these documentationtechnologies differ in details, they have a common essentialcharacteristic, that is, to represent a hierarchy of program func-tions and basic control constructs in a comprehensive fashion.This characteristic is the minimum required quality of adocumentation technology for a modern programming method.In order to improve software productivity, one of the best

ways is to reuse existing programs. Ironically, it is obvious thatthe fewer new programs are created, the greater the productiv-ity gained. However, it is very difficult to manage what and

0098-5589/85/0900-0945$01.00 © 1985 IEEE

945

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-il, NO. 9, SEPTEMBER 1985

Leve I Leve 2

< Initial processing >Open files FILE-OPENInitiate comuunicationSet end-switch = false

< Main processing >WHILE: End-switch = false

Receive enterd message ICI RCV-MISGf1IF: Message is suited to format

[THEN]CASE: Process switch =

OF: I[NQ]Inquiry INQUIRY

[OF: UPO]Update UPDATE

[OF: END]Job end JOB-END

[OTHER]Switch error processing

[ELSE]Format error processing

Send reply message

< End processing >Terminate communicationClose files

14F I LE-CLSE 15

01 Open master file02 Open journal file03

040506

07

08

Read master fileIF: The key is invalid )

[THEN]Edit key error message

[ELSE]Calculate inquired dataEdit reply message

09 Read "aster fileIF: the key is invalid


[ELSE]10 Calculate update data

Rew'rite master fileWrite journal file

iI Edit reply message

12 Edit end massage13 Set end switch = true

Close master fileClose journal file

Fig. 1. An SPD example.

where programs have been reused especially in a large softwaredevelopment organization. A documentation technology,specifically designed for this purpose, is the only means toattain managerial visibility.A documentation technology must not only have an excellent

theoretical basis but must also match the organization anddevelopment environments, such as methodologies and rules.Moreover, it must have friendliness to its users.In the beginning, SPD (Structured Programming Diagram)

was developed to support structurdd programming under theeffect of Warnier-Orr diagram [11], [14], [15] roughly tenyears ago. Since then, it has been improved and matured as apart of STEPS [25], [26] by adopting advice from its users.SPD is equipped with three important facilities which are

necessary to documentation technologies. They are as follows:1) fitness to the modern programming methods-SPD is pos-

itively designed to represent a function hidrarchy and controlstructures.2) visibility to program reuse-SPD is positively designed to

represent physical layout of program modules.3) friendliness to its users-SPD convention is simple, and its

symbols are easy to understand.Now, SPD is used by many customers in more than 1200

sites including government offices, public offices and privateenterprise.In this paper, the SPD concept and characteristics are outlined,

conventions for symbols and notations follow, and then asso-ciated documentation technologies are introduced.

II. SPD CONCEPT AND CHARACTERISTICSAn SPD example is shown in Fig. 1. SPD can represent three

kinds of structures on one sheet of paper together; functionalstructures that specify what a program does, control structuresthat specify the sequence in which each program function is tobe executed, and physical structures that specify how the pro-gram be assigned to the modules which are often reusable andprepared as standard libraries.

1617

C. READ-Mi 1819

C,EYERRB 20

2122

CIAEAD-M 2324

iCi KEYERR 11 25

26272829

3031

32

Procedure part 1

Procedure part 2

Procedure pirt 3Fig. 2. Sequential construct.

The functional structure means the hierarchy for the func-tions the program accomplishes. To depict the functionalstructure, it is desirable that the function description methodspossess versatility of describing the hierarchy structures froinentirety to details with a function refining pace, step by step.There are several methods for representing hierarchy structures,such as HIPO [211, [22], SADT [23], [24], etc. However,SPD has widely adaptable friendliness because it follows na-tural styles that a person usually takes, such as an index in abook or a listing in a telephone directory.

It is well known that a program can be composed of onlythree kinds of constructs: sequential, repetitive, and selective.Each basic construct consists of two parts: a procedure part,which contains one or more operations to be performed, and acontrol part, which determines'the manner in which the proc-dure part is to be executed. In SPD, a control part is to berepresented by the symbol placed on the SPD node. The se-quential construct has no special symbol on the node. Itdetermines that the procedure parts are to be executed exactlyonce. (See Fig. 2.) The control part of either repetitive orselective construct determines explicitly the manner in whichthe procedure part is to be executed. Typically, it consists oftwo parts: a directive which determines the consequences ofthe truth 'value in its condition part, and a condition part, whichis a Boolean expression. Selective and repetitive constructshave special symbols, diamond and circle, respectively, on theSPD node. The diamond has been used and accustomed as aflowchart selective symbol for a long time, and the circle iseasy to recognize its meaning. These familiar symbols arelearned with no effort. (See Figs. 3 and 4.)The physical structure specifies the program form at the

946

AZUMA et al.: SPD: HUMANIZED DOCUMENTATION TECHNOLOGY

CASE: DIRECTIVE)

[OF: Cond.1JProcedure part 1

[OF: Cond.2JProcedure part 2

[OTHER]Procedure part 0

Fig. 3. Selective construct.

WHILE: CONTROL)

Procedure partFig. 4. Reptitive construct.

<Block name>Procedure part 1

Procedure part 2

Procedure part 3Fig. 5. Blocked functions-description.

Level 1 Level 2

Procedure part I Procedure part 21

Procedure part 2 1odule I Procedure part 22

Procedure part 3 Procedure part 23

Fig. 6. Level description.

coding level. At the very beginning of a design phase, relevantprocedures may be described as one gross block. As the designproceeds, it is refined to more detail functions. However, it isdesirable to represent that these functions are being relevant asa whole. Therefore, it is required that documentation technolo-gies can provide the blocked functions description capability.Blocked functions are depicted in Fig. 5.The one page coding principle is to code relevant functions

within the limit of one page, in order to attain source codesreadability. According to this, a program may be divided intoseveral hierarchical levels. Items described in a higher level aremore abstract than those in a lower level. SPD can specifyabstract levels where each module belongs, and their relations.(See Fig. 6.) Besides, procedures that are often used are neededto describe how to assign external modules, i.e., macro, copylibrary, subroutine, etc. SPD can specify the assignment methodand module names as symbols and rectangles on the right sideof the function descriptions.When designing a program using with the SPD, a designer can

follow his natural thinking order, rather than the sequence ofdetail functions. That is, first, he describes main functions.Second, he describes detail functions. Third, he describes con-trol structures. Finally, he refines and describes physicalstructures.

III. SYMBOLS AND CONVENTIONSSPD can represent three kinds of structure (functional, con-

trol, and physical) together. Symbols and conventions for eachstructure are described here.

Node

Input path

I Output/input path

!n Procedure part

tOutput path

Fig. 7. Node in a level.

Input/outputpath

Node nProcedure part 1

Procedure part n

Fig. 8. Node between two levels.

A. Functional StructureThe only convention is as follows. The functions hierarchy

is to be described by indentation. The highest level is describedat the left most position on a sheet. The lower the levels are,the farther to the right they are described.

B. Control StructureIn SPD, a vertical course represents the basic process sequence.

Conversely, a horizontal course represents the functions hier-archy. Control is transferred by passing a node which is abranching point in the logical control flow. SPD has two dif-ferent kinds of nodes. One is the node for the transfer of con-trol within a level. The other is the node for the transfer ofcontrol between two different levels.1) Node in a Level: Each node in a level consists of one in-

put, one output, and one output/input path. As control con-tinues along the input path for node n and reaches node n, thecontrol flow passes first to output/input path. After executingthe procedure part, control falls back and continues along theoutput path. (See Fig. 7.)2) Node Between Two Levels: In a lower level, one node

and one input/ou-tput path exist to an upper level. As controlis transferred from an upper level to node n in a lower level, allprocedure parts in the lower level are executed according tothe rule within a level. After that, control falls back and con-tinues along the input/output path. (See Fig. 8.)With this principle, individual basic control constructs, de-

scribed with using SPD, are depicted in Table I.In addition to these constructs, connector symbols are spec-

ified. Exit and destination for a GO TO statement are depictedas shown in Fig. 9. It is suggested that connector symbolsshould be used as little as possible. A GO TO connector mustnot be used for connection to another page. When one SPD isexpanded to another page, a continuous connector is used. Avertical connection example is shown in Fig. 10. A horizontalconnection example is shown in Fig. 11.

C. Physical StructureThree symbols are employed to represent physical structure.1) Module Symbols: The modules assignment is represented

by a module symbol. Table II shows a variety of module sym-

947


TABLE ISPD CONTROL CONSTRUCTS

No. Construct Name SPD Flow Chart

I Imperative - P.P. [j.P]

2 sequential P.P.-t P.

P.P.-2 P.P.-2,

3.1 Iterativeloop (WHILE:Cont.) Dirl

P.P. Cond.

P. P.

3.2 Repetitiveloop +(I TIL:Ccnt. ) PiP

I_ P.P. rCond.

3.3 Continuous (LOOP)loop PP

P.P.

4.1 Monadic - (IF:Cond.) Dchoice (THEN]

P.P. o

4.2 Diadic (IF:Cond.) rchoice (THEN]

P.P.-1 Cond.-1 Cond.-2

(ELSE] P..-1 r.P. -2__ P. P.-2 _ ' 3

4.3 Multiple (CASE:Dir.) Direxclusive tOF:Cond.-l1choice P.P.-1

(OF:Cond.-2] Cond.-1P. . -2 P.P.X2

Cond.-2(OTHER]~P.P.-O

Cond.-n

4.4 Multtple -00(CASE:Dir.) Dirinclusive [OF:Cond.-1lchoice P. P.-1 .

EOF:Cond.-2] Cond.-1P.P.-2 PP-

Cond.-2

I ..- ~~~~~Cond.-n

Legend: P.P. (Procedure Part)Cont. (Control)Cond. (Condition)Dir. (Directive)

Fig. 9. GO TO connector.

4 (a)

Procedure part

Procedure part 2

Procedure part 3

(b) Procedure part 4

Fig. 10. Vertical connector.

bols and descriptions. If the module is defined at some otherplace in the same program, the module contents are placed on

the lower level, as shown in Fig. 12. If the module is definedexternally, only a module symbol is written, as shown in Fig.13.

Procedure part

Procedure part 2 ZZ 1 >

Procedure part 3

(a) (b)

Fig. 11. Horizontal connector.

TABLE IIMODULE SYMBOLS

NIh Symbol Description

I Module name Module call

Module is2 -Module name 71 standardized

3 PE frora name Program call

Program is4 EliProgras name! standardized

5 CI Macro name Macro call

Macro is6 C Macro naie standardized

Procedure part 21

Procedure part 2n

Procedure part I Modul Procedure part 11

Procedure part In

Fig. 12. Internal module description.

Procedure part Mliodule mbol

Fig. 13. External module description.

2) Block Symbol: A block symbol is employed to clarifyblock functions. The block symbol is depicted in Fig. 5.3) Level Symbol: Level symbols can be specified to the

abstraction levels, if necessary. The level number is assigned inthe abstraction sequence such as Level 1, Level 2,*e . A levelsymbol example is depicted in Fig. 6.

IV. DESIGNING PROGRAM USING THE SPDA designing process example, using the SPD, is shown below.

Outline of the Example ProgramReceive message from the terminal. The message contains a

retrieve key data, process switch value, and, in case of updateprocessing, a new master data. Inquiry or update process is per-formed according to the condition of the process switch. Thereply message displays the processing result to the terminal.Step 1: List main functions without thinking about control

structures. Write in natural style and do not use programmingtechnical terms (Fig. 14).Step 2: Describe detail functions, considering the basic pro-

cess sequence. Peculiar program functions (i.e., initiation,termination) are described in this step (Fig. 15).Step 3: Control structures are described. The most important

thing in this step is to clarify control conditions. Level symbolsand block symbols are also written (Fig. 16).

948

AZUMA et al.: SPD: HUMANIZED DOCUMENTATION TECHNOLOGY

Receive message from terminal

If the process switch indicates inquiry processing,read master file usins the retrieve key dataand get master data required

If the process switch indicates update processing,read master file using the retrive key dataand replace the old data with the new data sent from the terminal

Send message to the operated terminal,the reply message is the result of either inquiryor update processing

Fig. 14. Step 1.

Initiate ( files. Switch and Communication

- Receive entered message

Confirm the message format

Select process,according to the process switch

Inquiry

Update

- Send reply message

Terminate ( files and Communication )

Read master fileCalculate inquired dataEdit reply message

Read master fileCaluculate update dataRewrite master fileWrite journal fileEdit reply sessage

Fig. 15. Step 2.

Leve 1 I Leve 1 2

< Initial processing >Open filesInitiate communicationSet end-switch = false

< Main processing >WHILE: End-switch = false

Receive enterd messageIF: Message is suited to format

[THEN]CASE: Process switch

(OF: INQ)Inquiry

[OF: UPD]Update

(OF: END]Job end

tOTHER]Switch error processing

[ELSE]Format error processing

Send reply message

End processing >Terminate communicationClose files

Open master fileOpen journal file

Read master fileIF: The key is invalid


[ELSE]Calculate inquired dataEdit reply message

Read master fileIF: The key is invalid


[ELSE]Calculate update dataRewrite master fileWrite journal fileEdit reply message

Edit end massageSet end switch = true

Close master fileClose journal file

Fig. 16. Step 3.

Step 4: Module assignment methods are investigated and 5) Use other STEPS documentation techniques at the samespecified as module symbols (Fig. 1). time. (See Section V.)Summarizing these factors, the following cautions are re- 6) Number the specification code. (See Section V.)

commended to enable obtaining good results.1) Write from left to right and from the top down, with V. ASSOCIATED DOCUMENTATION TECHNOLOGIES

process function abstraction levels. Generally, a system contains many programs. They are con-2) Define abstraction criteria for levels. For example, the solidated and performed organically to accomplish the required

top level corresponds to files, the next level corresponds to system functions. Therefore, the system must be developedrecords within a file, and so on. on a step by step basis, such as; divide the whole system into3) List functions first. Then describe relations among func. subsystems, the subsystem into programs, and program into

tions (i.e., control structures). modules. However, each step requires a different documenta-4) Do not write in too many details. tion technology or standard. Therefore, the authors have de-

949


Fig. 17. A conversation specification example.

veloped a system for systematic standardization, called STEPS(Standardized Technology & Engineering for Programming Sup-port) to support every development step [25], [26]. STEPSis an integrated standard, covering all the software life cycle.It prepares many kinds of documentation technologies, i.e., torepresent a whole system image, relation between subsystems,etc.SPD is one of the STEPS technologies. It was developed to

specify a program structure in the design phase. Since STEPSis indeed an enormous system, the entire system not can bedescribed here. Therefore, some documentation technologiesthat are recommended for use with SPD are shown in this sec-tion. The integration of these documents gives a completespecification for a program.

A. Conversation Specification

When the man-,machine system was investigated, processefficiency, accuracy, and operation were effected by conversa-tional format and screen design. Conversation specificationcan represent screen design, operation at the terminal, and thedata processing at the center machine. An example is shown«nFig. 17.

B. Logic TableLogic Table is employed to clarify the relations between

data and each procedure part in SPD. Specification code,procedure part name, input data, procedure part description,and output data are described in an IPO form. In procedurepart description fields, a natural language, decision table, SPD,flow chart and so on can be used. A logic table example isshown in Fig. 18.

C. PND (Program Network Diagram)PND represents data and control flow and the relations be-

tween programs and files. SPD is a detail specification of eachprogram in PND. A PND example is shown in Fig. 19. PNDsymbols are explained in Table III. Besides symbols for dataflow by the communication line, terminals, slips, peripheralequipment, connectors, and terminators should utilize thequalified ISO flow diagram symbols.

D. Specification CodeSpecification Code specifies the correspondence between SPD

and other documents (logic table, decision table, etc.) or be-tween SPD and program list. The code organization may be

950

AZUMA etal.: SPD: HUMANIZED DOCUMENTATION TECHNOLOGY

Procedure part name Input data Procedure part description Output data

00010Date set processing Date from Accept processing date Data item for

operating system 1st header

00020Initialize Constant 'O' Initialize page counter Page counter itemOutput file 2 (Work area)

00030Edit Output file I Input file I Posting Output file I

.Slip No. SIlip No.Date Date.Correspondent code Correspondent code.Commodity code Commodity codeQuantity QuantityCommodity class code Commodity class code

Input file 2 Posting Output file ICommodity name Commodity nameUnit price Unit price

00040Header edit, print Exucute common sobroutine ( HEAD-RTN

00050Edit output file 2 Execute collate-key-match record edit

routine ( EDIT-MATCH-PR-PROC )

Fig. 18. A logic table example.

Frum sales ardoroperatIon

S

Stc nd

Ts sales aroeroperal Ien

S

To on l nep ropgr am

Fig. 19. A PND example.

established by the user. A code organization example is shown E. Data Structure-in Fig. 20. Specification codes are assigned to all the processing It is desirable to specify data structures easily and clearlywithout external call expansion on SPD. An example of speci- throughout a software system development. SPD can alsofication codes on SPD is shown in Fig. 1. represent hierarchical data structures using with the same

951

I

S

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-11, NO. 9, SEPTEMBER 1985

TABLE IIIPND SYMBOLS

Symbol Description

Processing symbol: This describes the job stepProgram name ( program ) or task.

Partition: This indicates that the centerPattern Partition processing/terminal processing

name or human processing is to be enterd.

Data symbol: This describes the file ( recordor memorY area.

Enter the name of input data, output data,Data file, record, etc.name Do not fail to enter the file classification

code ( M: Master or T: Transaction ) and fileorganization code ( S: Sequential, 1: Indexedor R: Relative ).

Indicates the data flow.Enter the access mode ( S: Sequential orR: Randam ) and processing mode ( 1: Input,0: Output, A: Adittional or U: Update ).If available, do not fail to enter the key itemname that would represent the basis ofProcessing like assortwent, collating, etc.

Indicates the control flow.

(a) 00320

E Serial number

(b) 4

Process categorySerial numberProgram category

Fig. 20. A code organization example.

< Header >

Order numberDate/ti be

5 Order slip body >WHILE: Max ten times

< Ite data >

Commodity CodeCommodity nameLot numberQuantityIF: New type commodity

[THEN]Temporary price

[ELSE]Unit price

Amount< Total >

Total amount

IF: Necessary )[THEN3

Remark

Fig. 21. A data structure example.

convention as program structure representation. A data struc-ture description example is shown in Fig. 21.

VI. EVALUATION AND CONCLUSIONIn 1974, SPD was introduced as a part of STEPS, an inte-

grated software standard. At first, this method was not ac-

cepted smoothly by expert engineers, who had their own designmethods. However, those managers and engineers who were

interested in software productivity or quality had started usingthis method. Since then SPD has been accepted and diffused.Engineers who understood the structured programming prin-ciple or beginner programmers, who had no knowledge of con-ventional disciplines, mastered it smoothly. On the contrary,experienced programmers, who could created sophisticatedspaghetti programs, tended to resist'changing their designingmethod. Except for those who have never used SPD and refuseto touch it, the authors have never heard that a programmer

who had taken this method once changed to another methodor went back to the old method. However, different tales are

often reported wherein a group who had used other methodschanged to SPD. These factors indicate the SPD predominance.In the beginning, SPD had no node control symbols and no

module symbols. It had only lines and notations. It was re-

commended to use SPD with logic table and specification code.With the experience gained from using SPD increasing, some

shortcomings have been detected and improved. The controlsymbols are added to the diagram node to represent the controlstructures. After that, the distinction between the loop in a

level and a loop in another level are represented (i.e., in-lineperform and usual perform). Further, module symbols are

employed to indicate the modules assignment form (i.e., copylibrary, macro, subroutine, and compile unit). These improve-ments increased the number of SPD users. Today, there are

too many users to trace. Investigation in 1978 showed thatSPD was offered to a total of more than 800 companies. So,based on the authors' best guess, SPD may be used in over 1200companies.

SPD can be easily described by using regular word processors,with the exception of the control symbols. Therefore, SPDdocuments are easy to maintain. Software tools that'generateSPD from source codes had already been developed. Efforts are

being made to develop a tool that generates a source code fromSPD.

ACKNOWLEDGMENTThe authors wish to thank Dr. Y. Mizuno, Senior Vice Presi-

dent of NEC, who made an important contribution to the ini-tial stage of STEPS development. Thanks are also due to Dr.K. Fujino ofthe NEC Software Product Engineering Laboratoryfor his encouragement and helpful comments during this work.

REFERENCES[1] E. W. Dijkstra, A Discipline of Programming. Englewood Cliffs,

NJ: Prentice-Hall, 1976.[2] -, "Structured programming," in Software Engineering: Con-

cepts and Techniques. 1976, pp. 222-226.[3] H. D. Mills, "Mathematical foundations for structured program-

ming," IBM Rep. FSC 72-6012, pp. 18-83, Feb. 1972.[4] N. Wirth, "Program development by stepwise refinement,"

Commun. ACM, Apr. 1971.[5] E. Yourdon "Top-down design and testing," in Managing the

Structured Techniques. Yourdon, 1976, pp. 58-87.[6] H. D. Mills, "Top down programming in large systems," in De-

bugging Techniques in Large Systems (Courant Comput. Sci.Symp. 1), R. Rustin, Ed., New York Univ., New York, 1971, pp.41-55.

[7] W. P. Stevens et al., "Structured design," IBM Syst. J., vol. 13,no. 2, 1974.

[8] E. Yourdon et al., Structured Design: Fundamentals ofDisciplineofComputer Program and System Design. Englewood Cliffs, NJ:Prentice-Hall, 1979.

[9] G. J. Mayers, "Reliable software through composite design,"Petroceli/charter, 1975.

[10] D. L. Parnas, "On the criteria to be used in decomposing systemsinto modules," Commun. ACM, Dec. 1979.

[11] -, "A technique for software module specification with exam-ple," Commun. ACM, vol. 15, no. 5, pp. 330-336, May 1972.

[121 J. D. Warnier, Logical Construction of Programs. New York:Van Nostrand Reinhold, 1974.

[13] M. A. Jackson, Principles of Program Design. New York: Aca-demic, 1975.

[14] D. A. Higgins "Structured programming with Warnier-Orr dia-

952

AZUMA etal.: SPD: HUMANIZED DOCUMENTATION TECHNOLOGY

gram," in IEEE Tutorial: Software Design Strategies, 1979, pp.60-71.

[15] P. A. Verdgraal et al., "The Warnier-Orr diagram," in Dig. COMP-CON '79, 1979, pp. 301-306.

[16] M. A. Jackson, "Constructive methods of program design," inIEEE Tutorial: Software Design Techniques, 1976, pp. 394-412.

[17] B. Schneiderman et al., "Experimental investigations of theutility of the detailed flowcharts in programming," Commun.ACM, vol. 20, no. 6, pp. 373-381, June 1977.

[18] 1. Nassi and B. Shneiderman, "Flowchart techniques for structuredprogramming," SIGPLANNot. Aug. 1973.

[19] C. M. Yoder, "Nassi-Schneiderman charts: An alternative flow-chart for design," in IEEE Tutorial on Software Design Tech-niques, pp. 386-393, 1978.

[20] N.. Chapin, "New format for flowcharts," Software Practice andExperience, voL 4, pp. 341-357, 1974.

[21] J. P. Stay, "HIPO and integrated program design," IBM Syst. J.,vol. 15, no. 2, pp. 143-154, (1976).

[22] "HIPO-A design aid and documentation technique," IBM Corp.,Rep. 20-1851, 1974.

[23] D. Ross, "Structured analysis (SA): A language for communicat-ing design," IEEE Trans. Software Eng., Jan. 1977.

[24] M. E. Dickover et al., "Software design using SADT," StructuredAnalysis and Design, vol. 2, pp. 101-114, 1978.

[25] M. Azuma and Y. Mizuno, Software Standardization. NipponKeizai Shinbun, 1977.

[26] -, "STEPS: Integrated software standards and its productivityimpact," in Proc. COMPCON '81, Washington, Sept. 1981.

n0 ,_ g | Motoei Azuma received the B.E. degree in in-dustrial engineering from Waseda University.He has been Manager of the Software Manage-

ment Engineering Department, Software Pro-duct Engineering Laboratory, NEC Corporation,since 1982. He is responsible for improvingsoftware quality and productivity at NEC byresearching, developing, and transferring soft-ware management technologies. He joined NECin 1963, and has been involved in several com-

puter based system projects as a system andsoftware designer and a software project manager. He was a VisitingLecturer at Kogakuin University during 1977-1978, and at WasedaUniversity during 1979-1980. His research interests include systemanalysis, software engineering, and software management, especiallyrequirement analysis, documentation, quality management, and humanfactors.He is a member of the IEEE Computer Society, the Information

Processing Society of Japan, and Japan Industrial Engineering Society.He has been a COMPSAC Program Committee member since 1983. Hehas been also involved in software engineering standard activities, as amember of ISO/TC97/SC7.

Tetsu Tabata graduated from an electric courseat Isesaki technical high school.

< He is the Senior Researcher of the SoftwareManagement Engineering Department, SoftwareProduct Engineering Laboratory, NEC Corpora-tion. He is responsible for research and develop-ment of software development methodology,software management, and software documentstandardization to improve software qualityand productivity. He joined NEC in 1965, andhas been involved in enhancement of Cobol

compiler, field support of business systems, and consultation ofsoftwaredevelopment standardization. His research interests include reusablesoftware parts, specification technology, and computer aided engineer-ing for software development and maintenance.

| Yoshihiro Oki received the B.E. degree in in-dustrial engineering from Osaka Prefecture Uni-versity in 1981.He is a Researcher in the Software Manage-

ment Engineering Department, Software Pro-duct Enginieering Laboratory, NEC Corporation.He joined NEC in 1981, and has been involvedin the research and development of softwareengineering standards, especially software doc-umentation guidelines, programming style stan-dards. *His research interests include software

engineering framework, software project management, and programmingenvironments.He is a member of Information Processing Society of Japan.

Susumu Kamiya received the B.S. and M.S. de-grees in mathematics from Tohoku Universityin 1969 and 1971, respectively.He has been supervisor of the Second Systems

Support Department, EDP Marketing SupportDivision, NEC Corporation, since 1980. Hisresponsibilities consist mainly ofimproving soft-ware quality and productivity at NEC, by re-searching, developing, and transferring softwareproduction technology. HejoinedNECin 1971,and has been involved in many projects as a soft-

ware designer and a chief programmer. His current research interestsinclude software engineering, especially software documentation andsoftware production technology transfer.

953

spd: a humanized documentation technology

Documents