Slide Deck: Software Process and Methodologies
“Plan-driven methods work best when developers can determine the requirements in advance . . . and when the requirements remain relatively stable, with change rates on the order of one percent per month.” – Barry Boehm
Plan-driven methodologies were the primary way that large software projects were managed for one simple reason: it’s what engineers knew how to do. Pretty much all other forms of engineering follow some method that would be considered “plan-driven” for a number of reasons, including:
For almost any form of engineering, these are key aspects that make a lot of sense. Of course you need a defined, reliable, detailed plan for constructing a building. It’s almost ludicrous to think otherwise.
Software isn’t all that different in many ways. Software controls systems that, if they failed, could be catastrophic - financially or for the loss of life. This is why some software has to be built in such a way that external entities can verify that the software is safe enough for usage in particular environments.
But even if we take the safety critical aspect out of the equation, there are other very good reasons to be more plan-driven. Imagine you are building a large software system that doesn’t just have a few users - something like Microsoft Word or Gmail. These are systems used by millions of people, but also built by teams of hundreds, spread across multiple continents. In order to keep everyone working toward the same goal, there needs to be documentation that all the developers can refer to as the arbiter of how each feature should be built. Otherwise, there is a good chance the software will never be built.
The Rational Unified Process is a stereotypical plan-driven model. This model utilizes dedicated teams for each phase of the software development process and incorporates interaction within each phase, bringing in different teams as needed. This allows a larger-scale company to rotate teams over to other projects as needed.