Improving Software Economics, Part 3 of 7: Top 10 Principles of Conventional Software Management
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Most software engineering references present the waterfall model [1] as the source of the "conventional" software management process, and I use these terms interchangeably. Years ago, I asserted the top 10 principles of the conventional software process to capture its spirit and provide a benchmark for comparison with modern methods. The interpretation of these principles and their order of importance are judgments that I made based on experiences from hundreds of project evaluations, project diagnoses performed by the Rational team, and discussions with Winston Royce, one of the pioneers in software management processes. My father is well-known for his work on the waterfall model, but he was always more passionate about iterative and Agile techniques well before they became popular.
Top 10 Management Principles of Waterfall Development
- Freeze requirements before design.
- Forbid coding prior to detailed design review.
- Use a higher order programming language.
- Complete unit testing before integration.
- Maintain detailed traceability among all artifacts.
- Thoroughly document each stage of the design.
- Assess quality with an independent team.
- Inspect everything.
- Plan everything early with high fidelity.
- Control source code baselines rigorously.
Conventional software management techniques typically follow a sequential transition from requirements to design to code to test, with extensive paper-based artifacts that attempt to capture complete intermediate representations at every stage. Requirements are first captured in complete detail in ad hoc text, and then design documents are fully elaborated in ad hoc notations. After coding and unit-testing individual code units, they're integrated together into a complete system. This integration activity is the first time that significant inconsistencies among components (their interfaces and behavior) can be tangibly exposed, and many of them are extremely difficult to resolve. Integration—getting the software to operate reliably enough to test its usefulness—almost always takes much longer than planned. Budget and schedule pressures drive teams to shoehorn in the quickest fixes. Refactoring the design or reconsideration of requirements is usually out of the question. Testing of system threads, operational usefulness, and requirements compliance gets performed through a series of releases until the software is judged adequate for the user. More than 80% of the time, the end result is a late, over-budget, fragile, and expensive-to-maintain software system.
Hindsight from thousands of software project postmortems has revealed a common symptom of governing a software project with an engineering management style: The project's integration and test activities require an excessive expenditure of resources in time and effort. This excessive rework is predominantly a result of postponing the resolution of architecturally significant issues (i.e., resolving the more serious requirements and design uncertainties) until the integration and test phase. We observed that better-performing projects would be completed with about 40% of their effort spent in integration and test. Unsuccessful projects spent even more. With less than one in five projects succeeding, better governance methods were imperative.
One of the most common failure patterns in the software industry is to develop a five-digits-of-precision version of a requirement specification (or plan) when you have only a one-digit-of-precision understanding of the problem. A prolonged effort to build precise requirements or a detailed plan only delays a more thorough understanding of the architecturally significant issues—that is, the essential structure of a system and its primary behaviors, interfaces, and design tradeoffs. How many frighteningly thick requirements documents or highly precise plans (i.e., inchstones rather than milestones) have you worked on, perfected, and painstakingly reviewed, only to completely overhaul these documents months later?
The single most important lesson learned in managing software projects with the waterfall model was that software projects contain much more uncertainty than can be accommodated with an engineering governance approach. This traditional approach presumes well-understood requirements and straightforward production activities based on mature engineering precedent.
References
[1] Winston W. Royce, "Managing the Development of Large Software Systems," Proceedings of IEEE WESCON 26 (August 1970): 1–9.