Dr. Winston W. Royceさんが1970年に発表した論文google:MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS」の原文そのまま。紙スキャンなPDFしか見当たらないので半手動OCR



I am going to describe my personal views about managing large software developments.

I have had various assignments during the past nine years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post-flight analysis.

In these assignments I have experienced different degrees of success with respect to arriving at an operational state, on-time, and within costs.

I have become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.


There are two essential steps common to all computer program developments, regardless of size or complexity.

There is first an analysis step, followed second by a coding step as depicted in Figure 1.

This sort of very simple implementation concept is in fact all that is required if the effort is sufficiently small and if the final product is to be operated by those who built it - as is typically done with computer programs for internal use.

It is also the kind of development effort for which most customers are happy to pay, since both steps involve genuinely creative work which directly contributes to the usefulness of the final product.

An implementation plan to manufacture larger software systems, and keyed only to these steps, however, is doomed to failure.

Many additional development steps are required, none contribute as directly to the final product as analysis and coding, and all drive up the development costs.

Customer personnel typically would rather not pay for them, and development personnel would rather not implement them.

The prime function of management is to sell these concepts to both groups and then enforce compliance on the part of development personnel.

Figure 1. Implementation steps to deliver a small computer program for internal operations.

A more grandiose approach to software development is illustrated in Figure 2.

The analysis and coding steps are still in the picture, but they are preceded by two levels of requirements analysis, are separated by a program design step, and followed by a testing step.

These additions are treated separately from analysis and coding because they are distinctly different in the way they are executed.

They must be planned and staffed differently for best utilization of program resources.

Figure 3 portrays the iterative relationship between successive development phases for this scheme.

The ordering of steps is based on the following concept:

that as each step progresses and the design is further detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in the sequence.

The virtue of all of this is that as the design proceeds the change process is scoped down to manageable limits.

At any point in the design process after the requirements analysis is completed there exists a firm and closeup, moving baseline to which to return in the event of unforeseen design difficulties.

What we have is an effective fallback position that tends to maximize the extent of early work that is salvageable and preserved.

Reprinted from Proceedings, IEEE WESCON, August 1970, pages 1-9.

Copyright c 1970 by The Institute of Electrical and Electronics Engineers, Inc.

Originally published by TRW.