I'm writing a small research paper which involves software development methodologiess. I was looking into all the available methodology's and I was wondering, from all methodologies, are there any that have provided the foundations for the others?
For an example, looking at the following methodologies:
Agile, Prototyping, Cleanroom, Iterative, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model, TDD.
Can we say that:
Prototyping, Iterative, Spiral and Waterfall are the "foundation" for the others?
Or is there no such thing as "foundations" and does each methodology has it's own unique history?
I would ofcourse like to describe all the methodology's in my research paper, but I simply don't have the time to do so and that is why I would like to know which methodologies can be seen as representatives.
Best Answer
The names in your list are not all methodologies and they scale on different levels :
Distinguishing which is the foundation of which is a difficult job. You can draw a historical line obviously, but a methodology is rarely directly based on another. They rather overlap, borrow from one another, sometimes respond to each other...I can see no clearly defined classification, though you could probably outline a few big families.
Another way to look at it is from a generation perspective. In terms of enterprise software I would say we have known 2 generations of methodologies. The first ones, among which Waterfall and V-Model, were mostly pre-existing processes from other engineering disciplines applied to software. The second generation (you can call it Agile but it started long before the term Agile was coined) was initiated in reaction to the heaviness of first generation processes, when people started realizing that software was a totally different animal and that the criteria that make good software and the steps that can ensure these criteria were really specific and still had to be explored.
Finally you should note though that, in software maybe even more than in other disciplines, methodologies are not recipes that you can just apply to make things work. Software development has as many human aspects as technical aspects and a team or a manager coming up with a silver bullet methodology and a checklist of things to blindly apply can expect some surprises. Just looking at studies on software project success rates like the Chaos Report year after year, you can tell the history of software methodologies has more to do with a series of failed attempts than the rule of solid, scientifically established, repeatable processes.