Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

migrated from stackoverflow.com Feb 28 '11 at 13:55

This question came from our site for professional and enthusiast programmers.

add comment

4 Answers 4

up vote 5 down vote accepted

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.

share|improve this answer
    
I recommend this academic paper that compares 2 types of software processes similar to the 2 generations I was mentioning : paulralph.name/wp-content/uploads/2011/01/… –  guillaume31 Mar 13 '11 at 10:03
add comment

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!

share|improve this answer
    
@Bas: James Martin is credited with coining the term 'rapid application development' in 1991 en.wikipedia.org/wiki/… –  Steven A. Lowe Mar 1 '11 at 20:19
    
Thank you very much for this answer! I'll see if I can publish the results later on as it is part of an assignment I'm doing for a company. So I'll try and see if I can make it independent from the company's assignment :) –  Bas Mar 2 '11 at 7:12
add comment

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.

share|improve this answer
1  
This wasn't really what I was looking for. I really would like to know about the software development methodologies which are being used in software development projects. –  Bas Feb 28 '11 at 9:47
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.