Which software development methodologies can be seen as foundations

Question

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.

Answer 1

The names in your list are not all methodologies and they scale on different levels :

• Iterative is a characteristic, a trait shared by several methods and techniques. Scrum is an iterative methodology, TDD is an iterative technique.
• I see Agile as a methodology superset that remains at a conceptual/philosophical level. In object oriented programming you could describe it as abstract - it's a set of values and principles that cannot be instantiated and have to be derived and implemented. That's what Scrum and XP do.
• Cleanroom, RAD, RUP, Spiral, Waterfall, XP, Lean, Scrum, V-Model are proper methodologies, ie software development processes (though Scrum claims to be a lightweight "framework" as opposed to a heavy process)
• Prototyping and TDD are techniques, activities. TDD is an XP practice.

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.

Answer 2

There are Three:

1. none (aka cowboy coding)
2. waterfall
3. rapid application development (RAD or spiral)

the rest are variants and combinations of these

note that the artifacts from waterfall (inception, requirements, functional spec, design spec, testing spec, quality control spec, etc.) all cover things that are important to the project, most if not all of which are covered by other methodologies but in very different ways. For example, in TDD the features, user stories, and test descriptions cover the requirements, functional spec, and testing spec from waterfall. In RUP even more artifacts are added which break off a piece of the waterfall specs (the Stakeholders document, for example, is a piece of the Inception document) but proceeds in a spiral manner

please publish a link to your results when done, it sounds like an interesting paper!

Answer 3

Maybe you want to just mention antique methodologies (not 'methodology's) like:

1. batch processing: submit a deck of cards and get the output back the next day. Drawbacks: too much time between submissions; for debugging, study a core dump.

2. cli methods -- use vi or emacs, then compile; all from the command line just like is done in a linux shell even to this day. Drawbacks: hard to debug (gdb? are you kiddin' me?), obscure 40-year-old shell commands.

Just a thought.

Answer 4

You can mention three basics approaches: Prototyping, Spiral and Waterfall. I wouldn't consider Lean, TDD or Cleanroom as a methodology, but rather process which can be a part of methodology.