Google SDLC – Software Development Life-Cycle Methodologies Used by Google

Even in a strictly 1-man project (you coding software for yourself with no schedule) you have to:

1. Figure out what you actually want/need.
2. Figure out how it can be done (various approaches).
3. Implement it.
4. See what you got and go back to 1), refining the requirements.

You could do it informally (cowboy), but given that the 1-man project is a special edge case (usually there's at least you and someone else you're working for), doing it with some well founded light formalism is virtually always preferable. Keep in mind that the core of the Agile Manifesto is really just a few principles. The formal methodologies (e.g. Scrum) aimed to reach those principles can and should be tailored according to the team size etc.

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.