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'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?

share|improve this question
2  
From my reading, you seem too focused on the User Interface part of software development. Prototypes are excellent for developing and refining UIs, not so much for hammering out core logic (or even figuring out exactly what the business logic you're supposed to be implementing is) –  Anon. Dec 13 '10 at 22:53
1  
If there is a human user, usually there is GUI. What GUI has to look like and how it has to perform will affect the design of the whole system. –  Job Dec 14 '10 at 4:08
add comment

7 Answers

up vote 5 down vote accepted

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).

share|improve this answer
    
+1 My company prototype quite often, but only as proof-of-concept, mainly in GUIs, but also when researching a new approach to a problem, server-side as well. –  Orbling Dec 14 '10 at 0:51
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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)

share|improve this answer
add comment

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.

share|improve this answer
    
+1 Very true, the prototype gets seen by marketing who tend to announce the project completion. –  Orbling Dec 14 '10 at 0:50
1  
This is an argument for making your prototypes as good as possible given the time, not for refusing to do prototypes. –  Inaimathi Dec 14 '10 at 1:08
add comment

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.

share|improve this answer
add comment

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.

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.