Project Management Methodologies and Software Development Process

There have been a lot of software development process created over the years by different PM practitioners. In “Rapid Development”, most of the companies identifies a number of categories of process - most real-life projects employ a blend of these:

• Pure waterfall
• Code-and-fix
• Spiral
• Modified Waterfalls
• Evolutionary Prototyping
• Staged Delivery
• Evolutionary Delivery
• Design-to-Schedule
• Design-to-Tools
• Commercial Off-the-shelf Software

With the exception of code-and-fix, these processes have a few things in common – they assume that software development is analogous to a defined industrial process; they are based on physical engineering processes; they are predictive; and they assume that people can be treated as abstract resources. “It is typical to adopt the defined (theoretical) modelling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice”

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 gurantee 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 predictand 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:

1. Analysis 16%
2. Design 17%
3. Code/Unit Test 34%
4. System/Integration Test 18%
5. Documentation 8%
6. Implementation/Install 7%

In an even more extreme analysis proposed by Jack Reeves - he suggests that code is analogous to an engineering design, and that software is “constructed” by running a compiler. Accordingly, the construction stage in a software development project is essentially free.

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

1. “Agile Software Development with Scrum”, Ken Schwaber and Mike Beedle, Prentice Hall, 2002
2. “The New Methodology”, Martin Fowler,http://www.martinfowler.com/articles/newMethodology.html
3. “Worldwide Benchmark Project Report”, Howard Rubin, Rubin Systems Inc., 1995
4. “What is software design?”, Jack Reeves, http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm

produce design artefacts detailed enough for construction to be straightforward. If construction is analogous to compilation, then we can effectively ignore the construction effort. In either case, processes based on analogies with physical engineering should be treated with suspicion.