- Pure waterfall
- Modified Waterfalls
- Evolutionary Prototyping
- Staged Delivery
- Evolutionary Delivery
- Commercial Off-the-shelf Software
In process control theory, a “defined” process is one that can be designed and run repeatedly with predictable results. In particular, the inputs to the process and the process itself must have very low levels of noise. When a process cannot be defined precisely enough to guarantee predictable results it is known as a “complex” process. Complex processes require an empirical control model. An empirical control model entails frequent inspection and adaptive response.
Software development is not a defined process, at the very least because the main inputs to the process activities are people. Traditional methodologies contain lists of activities and processes that are depicted as reliable and repeatable, however we all know from experience that this isn't the case. Ask two different groups of people to come up with class diagrams from the same requirements and you'll get two quite different results. The problems with treating software development as a defined process are discussed further by Schwaber and Beedle1.
Physical engineering processes consist of distinct phases. Thed esign phase is difficult to predict and requires creativity and imagination. The primary activities in the design phase are intellectual. The design phase is followed by planning for the construction phase, and then by the construction phase itself. The primary activities in the construction phase are physical, and it is much easier to plan and predict than the design phase. In many physical engineering disciplines construction is much bigger in both cost and time than design and planning. For example, when you build a bridge, the cost of design is about 10% of the total job, with the rest being construction.
For the analogy between software development and physical engineering to hold, we need to be able to separate design from construction, be able to produce a predictable schedule, design artefacts that are complete enough for construction to be straightforward, and be able to perform construction with people of lower skills (who are hopefully cheaper to employ). Construction also needs to be sufficiently large in time and effort to make this worthwhile. The situation in software development is quite different. The most of software development companies reports the following breakdown of software development by activity:
- Analysis 16%
- Design 17%
- Code/Unit Test 34%
- System/Integration Test 18%
- Documentation 8%
- Implementation/Install 7%
Regardless of the exact numbers, it's clear that as a percentage of the overall project effort, construction is much less significant in software development than it is in physical engineering. If construction is analogous to coding, our experience indicates that it's very difficult and expensive to
- “Agile Software Development with Scrum”, Ken Schwaber and Mike Beedle, Prentice Hall, 2002
- “The New Methodology”, Martin Fowler,http://www.martinfowler.com/articles/newMethodology.html
- “Worldwide Benchmark Project Report”, Howard Rubin, Rubin Systems Inc., 1995
- “What is software design?”, Jack Reeves, http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm