Father Guido Sarducci, in presenting his idea for a Five Minute University, explained Economics in simple terms: “Supply and Demand. That’s it.” (Five Minutes doesn’t leave much time to devote more to the subject.) Funny thing is, he was right. These are the cornerstones upon which everything else is built.
Which brings me to a white paper I’m reading: Managing the Development of Large Software Systems, by Dr. Winston Royce. It’s a fascinating read on what (and what not) to do to ensure success when developing incrementally. Dr. Royce describes all software development as having just two, essential steps:
“There are two essential steps common to all computer program development, regardless of size or complexity. There is an analysis step, followed second by a coding step,” he says.
Of, course, he goes on to explain that, while these two steps are sufficient for very small, low-risk projects, limiting larger projects to these two steps dooms them to failure. Go figure.
To reduce the risk of failure, larger projects require more than the basic steps—notably requirements definition steps before the analysis step; a design step in between the analysis and coding steps; and a testing step after coding. Also, as anyone familiar with iterative development techniques will tell you, if we develop iteratively, with each iteration building on the deliverables of its predecessor, we can reduce risk further because we move our development baseline forward with the completion of each iteration—that is, the more we build, the less risk there is to contend with.
There’s one hitch though: Because our view of the over-all solution is limited to the code delivered with the iterations that have been completed, any testing is also limited. Thus, it is entirely possible that, when testing Iteration 4, we discover a fundamental flaw related to work done in iteration 1; which, in turn, could require significant rework of components from iteration 1 on-ward.
Says Dr. Royce:
“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.”
To respond to this risk, Dr. Royce suggests five steps:
First, introduce a “preliminary program design” step between requirements generation and analysis to determine storage, timing and operational constraints (a.k.a. Performance and Supportability); and hone the design by collaborating with analyst input. In other words, establish a baselined architecture to minimize architecturally-significant risks. To ensure success, Dr. Royce suggests three, key factors to ensure success:
- Begin the process with the designers
- Design, define and allocate the data processing modes (Architectural Candidates)
- Write an overview document (a.k.a. Vision) so that everyone has an elemental understanding of the system.
Second, document the design. A lot. “Management of software is simply impossible without a very high degree of documentation,” he says. Why so much documentation?
- Evidence of completion. As opposed to a verbal statement of completion status (“How a far along are you?” “I am 90 percent done, same as last month”), design documentation is forces designers to provide clear, tangible evidence of completion state that management can base decisions on.
- When documented, the design becomes real. Until that happens, the design is nothing more than people thinking and talking about the design. (Reminds me of the astronomers’ adage that, if you didn’t write it down, it never happened.)
- Downstream processes (development, testing, operations, etc.) require strong design documentation in order to succeed. Take testing, for example: “Without good documentation, every mistake, large or small, is analyzed by one man who probably made the mistake in the first place because he is the only man who understands the program area,” Royce says.
Third, “Do it twice”—that is build a functional prototype that simulates the high-risk elements of the system to be built; then, once you are satisfied that the high-risk items have been addressed, proceed to build the real thing—the version that will be delivered to the customer. Royce is careful to point out the unique background required by project staff involved at this stage:
“They must have an intuitive feel for analysis, coding and program design. They must quickly sense the trouble spots in the design, model them, model their alternatives, forget the straightforward aspects of the design which aren’t worth studying at this early point, and finally arrive at an error-free-program.”
Fourth: plan, monitor and control testing. Two of Royce’s suggestions for success are:
- Testing must be completed by independent testing specialists who have not contributed to the design based on documentation created in earlier stages.
- Visual code scans to pick up code errors. Again, this should be done by someone who’s not as close to the code as the developer. Can you say verification testing?
Finally, involve the customer—early and often. Says Royce, “To give the (contractor) free rein between requirement definition and cooperation is inviting trouble.”
Does any of this sound familiar? It should—it’s RUP 101. Here’s the kicker: Dr. Royce wrote this paper in 1970. His white paper can be found at: Managing the Development of Large Software Systems