How common is prototyping as the first stage of development?

Question

I've been taking some software design courses in the past few semesters, and while I see the benefit in a lot of the formalism, I feel like it doesn't tell me anything about the program itself:

• You can't tell how the program is going to operate from the Use Case spec, even though it discusses what the program can do.
• You can't tell anything about the user experience from the requirements document, even though it can include quality requirements.
• Sequence diagrams are a good description of how the software works as the call stack, but are very limited, and give a highly partial view of the overall system.
• Class diagrams are great for describing how the system is built, but are utterly useless in helping you figure out what the software needs to be.

Where in all this formalism is the bottom line: how the program looks, operates, and what experience it gives? Doesn't it make more sense to design off of that? Isn't it better to figure out how the program should work via a prototype and strive to implement it for real?

I know that I'm probably suffering from being taught engineering by theoreticians, but I need to ask, do they do this in the industry? How do people figure out what the program actually is, not what it should conform to? Do people prototype a lot, or do they mostly use the formal tools like UML and I just didn't get the hang of using them yet?

Answer 1

If we're building a GUI application we almost ALWAYS create a prototype or POC (proof-of-concept). We'll establish what the visual vocabulary of the app will be. We usually get our client involved part way through the POC and make sure they understand what the purpose is and what they should be focusing on. I've never been sorry that I produced a prototype. Just be sure that you don't try to turn the prototype code into the production code, start the production code from scratch based on what you learned from the prototype.

Having said all that, we almost never prototype server side applications (services, middleware, etc.). I don't really see the return on investment for that (unless you are doing some new technology and need to prove different concepts out).

Answer 2

In the business world, it matters a-lot

I too use to think that, until you hit the business world. Then its no longer simple enough to just take requirements and go forth and build.

Its in business that user "flow" diagrams, and lo-fi prototypes really make sense.

How the "program" operates is probably the easy part. In LOB (Line Of Business) apps, most of it is just CRUD. The challenge lies in the business logic and rules. This is where user flow diagrams and business process flows become extremely important in order to understand and plan effectively.

Answer 3

What do you mean by how the program "operates"? You seem to be looking for exact implementation details in something other than the specific final implementation, which doesn't make sense. Higher-level elements are supposed to guide implementation, not determine it.

From my experience, prototyping is somewhat uncommon. I was certainly taught it in conjunction with specification, requirements, architecture, etc. though, and it can be very useful.

As for "what the software needs to be", that IS the requirements. You appear to be missing the entire point.

Interfaces are often sketched out beforehand, and use cases can be used for interface "flow". The user experience is not missing at all. If you feel some element is missing, then do something else your professors haven't mentioned. Design does not consist of a clear set of rules handed down from heaven.

Answer 4

My personal observation is that prototyping is given much lip service but all too often the prototype, once it is showing signs of life, is simply rebranded as 'Beta' or, even worse, v1.0.

Answer 5

there are two kinds of prototyping - three, actually:

1. we build prototypes to refine the design and reduce risks before starting the "real" coding (Engineering)

2. we build the project as a series of refined prototypes (Agile)

3. we build a prototype and ship it as soon as it works (Cowboy)

Answer 6

What you are looking for is called the spec - you can read a description of that here in one of Joel's articles

http://www.joelonsoftware.com/articles/fog0000000035.html

Answer 7

A prototype can also be considered "iteration 0" of what you need to do. It fulfills several things:

• It proves that the concept can be done. This may be to your boss or to a paying client.
• It allows you to identify things that may be hard to get to production strength, and give you a general idea of the amount of work needed.
• You actually have code that does something. This is immensely important!

All in all the prototype should with high probability be useful for building the final product, unless you've found that a completely different approach is necessary.