Prototyping Processes in Different Software Development Methodologies

Question

I have identified the following iterative process for prototyping:

And its iterative nature makes me think a lot of agile or spiral models, and because of this I think that they are usually more suitable for projects where the scope, the price or the time of delivery are of little concern as compared to its waterfall counterpart.

The question here is, is prototyping for Waterfall different than prototyping refinement for Agile? If so, how? BONUS: Include an illustration of the prototyping process in waterfall.

Answer 1

What is a software model?

For some reason, the branche uses the term "software development model" in presrciptivist fashion, like a knitting pattern or an opera score. It is determined by a creator, and somebody has to follow it to the letter.

In reality, it is a descriptivist tool, more akin to a genre in music or a social stereotype. Bands play what they think is cool, then come the music magazines and say "this one is progressive rock, this one is death metal".

Developers and project managers don't follow a model. They do whatever feels right in their situation, determined by a mix of previous experience, creative reactions to a complex situation, and environmental (organisational) constraints. They give it the label of the process they would like to follow, determined by what is hip at the moment, or what they are ordered to follow by bosses or regulation bodies, or what was advertised in the most convincing book/blog post they read. The real methodology is arbitrarily close or far from the abstract description of the model they say they are following.

There is no prototyping in waterfall

When we are talking about process model theory and using pictures like the one above, we are talking about the abstract process stereotype, the bundle of qualities which taken together make one process recognizable as waterfall and another as agile.

In this context, there is no prototyping in waterfall, period. You can read the original publication by Royce online. It was very innovative for its time (published 1970), as it suggested that in software development, there are phases beside requirements analysis and pure implementation. This was a substantial enough insight for its time to get published at an IEEE conference. Nobody had thought to test code on a prototype first, because 1) tested wasn't officially recognized at all, and 2) CPU hours were way more expensive than programmer hours back then, people implemented their whole programs on paper before converting it to punch cards and loading it into the behevac to run. Running extraneous code would have been a really high cost.

The idea of prototyping was officially introduced in 1988 by Barry Boehm. By then, the waterfall model was widespread enough for people to notice its flaws. So, he published the spiral model which countered some of these flaws, and prototyping was one of the major new features.

Most existing software development methods are derived from one of these two, for example the agile family deriving from the spiral model (with some of them like Scrum ironically reverting back to pure "ask for the specification and code it" from before 1970), and the V Modell XT being a derivate from waterfall. Even the ones which are not direct descendants, like the RUP, are obviously influenced by them.

But I have seen people using prototypes in waterfall

Sure you have, it happens all the time in the wild. This is because nobody uses the pure, abstract form of waterfall, see the explanation above. Royce and Boehm did what the magazines do for music. They didn't create process models from zero and brought them to developers, they observed many projects, looked at the ones which succeed, and extracted the common features of them into a stereotype description. This gives us a way to roughly distinguish between different project "feels" when we talk about projects. Saying that "I am working agile" is a similarly dense-but-unprecise way to convey information as saying that Richard Feynman was a nerd, Opeth is a death metal band, and casatiello is a type of Italian bread.

But in reality, one can do what belongs to one genre while incorporating elements which are considered the antithesis of a genre. Casatiello is so sweet many people mistake it for a cake, Opeth uses clear vocals instead of growling, and Feynman was a samba dancer. In the same way, there are software engineering projects which are recognizable as waterfall, but the team practices prototyping wherever they see fit. This doesn't make prototyping a part of the waterfall model, or the project non-waterfall.

But despite this real-life situation, asking about the role of prototyping in waterfall models is like asking about the role of samba lessons in a nerd's daily routine. It is just not part of the model.

Answer 2

One aspect of the waterfall model is that the requirements are set and their ambiguity is at a bare minimum. It has roots in manufacturing where prototypes are a separate process outside the normal, repeatable en masse process. Inside the manufacturing process, they might be used to test and calibrate machinery before production starts.

If you look at the waterfall model in its most pure form, there is no feedback loop between the team and the customer. In this case, prototypes could be used for the team to demonstrate their understanding of requirements internally. The team can then use the feedback to change or modify their design. Alternatively, prototypes can be made outside the process to demonstrate capability. You can see the similarities between this and manufacturing.

In agile, one role of the customer is to provide continuous feedback. In this case, prototypes could be used to show the customer the team's understanding of the requirements at the time. They can use the feedback to refine use cases, re-prioritize features, and set the direction of future work.

The key takeaway is how to get the biggest return on the prototype. Without the customer (waterfall), it is for the team to understand requirements or demonstrate capability. With the customer (agile), the team and the customer can work together to understand requirements.