Program Design Comes First: Analysis/Design (and code) is indeed the heart of programming, but is it realistic to expect these activities to reside mainly at the beginning of a project? Document The Design, and/or perhaps the architecture (whatever that might be) is desirable but in answer to the question of 'how much documentation?' Royce states
"[m]y own view is ‘quite a lot;’ certainly more than most programmers, analysts, or program designers are willing to do if left to their own devices. The first rule of managing software development is ruthless enforcement of documentation requirements." (Royce, 1970)On this point Royce suggests that for a "5 million dollar hardware device, I would expect that a 30 page specification would provide adequate detail to control the procurement. In order to procure 5 million dollars of software I would estimate a 1500 page specification is about right in order to achieve comparable control." (Royce, 1970) p332 More ambiguously perhaps he mandates that (at least at the start of a project) "the documentation is the specification and is the design." It is clear that Royce assumes that the document communicates perfectly and unambiguously, that a document overcomes the problems of interpersonal communication (or its lack) by being clear and unambiguous. If we read ‘understanding’ instead of documentation and consider it to be present in ‘communication’ in the processes and practices of communication, of interpersonal interaction and sense making along with the source code and ‘documentation’ then perhaps Royce isn’t far from the mark.
Do It Twice, an insightful recommendation, that the software is actually a product of learning; learning what the requirements really are rather than what they were initially thought to be, learning how a design performs, how it interacts with the hardware and other software, learning how the software is actually used, timing, scale, performance.
Plan, Control, And Monitor Testing. Yes but, perhaps happening later as it does in his model, the model may collapse as bugs, problems and inadequacies leak back again to affect the requirements, design and analysis.
Finally Involve The Customer, perhaps the most insightful recommendation and perhaps one that we still find difficult to achieve.
Royce can be read perhaps as a radical, making recommendations not usually associated with this era, principles and practices which might be understood in Agile Development as emphasizing communication, design/coding as the central activity, responding to change, refactoring design, visibility, and on-site customers. At the end he arrives at a process model for software development, an approach which is essentially iterative, involves customers, and is dominated by strategies to facilitate communication with all involved.
While Royce’s paper was influential in the move towards methodologies and understanding and developing principles for the organization of software development teams, it also (sadly) said very little about the practicalities of organizing teams and actual people. For this one must turn to Brooks (1995 (1987)) and others who followed.
REFERENCES
