Hatena::Groupprogram

桜、抹茶、白、日記(支店)

2010-05-02

[] MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS(2/11) はてなブックマーク -  MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS(2/11) - 桜、抹茶、白、日記(支店)

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

PDFの2ページ目。

COMPUTER PROGRAM DEVELOPMENT FUNCTIONSの続き

Figure 2. Implementation steps to develop a large computer program for delivery to a customer.


I believe in this concept, but the implementation described above is risky and invites failure.

The problem is illustrated in Figure 4.

The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed.

These phenomena are not precisely analyzable.

They are not the solutions to the standard partial differential equations of mathematical physics for instance.

Yet if these phenomena fail to satisfy the various external constraints, then invariably a major redesign is required.

A simple octal patch or redo of some isolated code will not fix these kinds of difficulties.

The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated.

Either the requirements must be modified, or a substantial change in the design is required.

In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.


One might note that there has been a skipping-over of the analysis and code phases.

One cannot, of course, produce software without these steps, but generally these phases are managed with relative ease and have little impact on requirements, design, and testing.

In my experience there are whole departments consumed with the analysis of orbit mechanics, spacecraft attitude determination, mathematical optimization of payload activity and so forth, but when these departments have completed their difficult and complex work, the resultant program steps involve a few lines of serial arithmetic code.

If in the execution of their difficult and complex work the analysts have made a mistake, the correction is invariably implemented by a minor change in the code with no disruptive feedback into the other development bases.


However, I believe the illustrated approach to be fundamentally sound.

The remainder of this discussion presents five additional features that must be added to this basic approach to eliminate most of the development risks.