Discussion on:

Use prototyping to visualize project requirements

They just might end up in somebody's menagerie.

end up Version 1 Alpha, and usually for the wrong reasons. They are valuable and sometimes the only effective way you can approach solving a problem.

When you do one though, keep in mind what it's for.

Don't be tempted to bolt in out of scope stuff to make it 'look' better, don't waste effort making things faster, more robust. Unless that's what the prototype is for!

Remember how many things you bodged to get onto the 'interesting' bit. Document it, and delete it.

If you are doing iteration one of phased design, you are not doing a prototype, you are doing a product, that's an obvious major difference but one that is foolishly skipped over by the sales type shrink-wrapping that experiment you did last week.

Last but not least, look at what you want to do and then choose a lifecycle. Do not look at how to make what you want to do fit an already chosen lifecycle.

sw like iRise or prophesy.
they detail use cases in a model independent of pgmg language.

for this reason is not a prototype of the functioning sw but saves you endlessly in getting reqts right.

Sorry... you will never compare... only contrast.

Could you put that post in plain English?

Oops

Closely related to prototyping is the maxim "always plan to throw the first one away". The first version often being a prototype that's bashed and hacked about to refine the requirements.

This often results in a heap of junk code and data that ultimately has to be removed, rewritten or refactored to get to the final version.

It's often better to simply start over than to try and refactor or modify it into the final version.

Terrific. I wish a lot more to see in future of this sort. These sorts of articles really useful for the young ones who are waiting to plunge. I cherish and wish the great service to the tech community continue...vibrantly

Muralidharan Kuppuswami Iyer- India

I've been prototyping apps for over 20 years. The best developers I know do the same thing. The best PMs I know require them.

However, you must make everyone understand that the proto isn't the end-all. It's just the beginning.....

Prototyping, proof of concepts, and piloting are excellent approaches to clarifying requirements and improving the ultimate success of the project. However, it can be a challenging sell to recommend any one of these routes to inexperienced executive/senior management when the perception is this will take more time up front and they want the solution in place tomorrow.

This is a great post and I'm totally game for prototyping provided there's a tool which's available for creating such prototypes.

I've started playing with this and it seems very useful. It's free too and integrates with a few widely used developed tools.

BTW...I'm not connected to Serena.

ShimCode

This is what causes me so much confusion about the role of the Project Manager versus the role of the Business Analyst/Systems Analyst or even the Programmer Analyst. I am concerned at how involved the PM should be involved in something lie SW development. In this scenario, the PM appears to be playing the role of Business Analyst.

If you are building a prototype to collect / amplify requirements from an essentially nebulous spec, then the initial management phase has got to be collection and analysis, after all until you you know what you have to do, you can't manage anything after it.

So the PM might chase up getting a first draft prototype built, usually with an analyst and a developer, if you are lucky even a customer.

Once things start getting nailed down then there are some more things to manage.

It's amazing how many times you see the time for building, testing, deploying and documenting budgeted and allocated before the prototype is even started. All too often this explains why the prototype ended up as the product.

The other prototype that gets built is say one to examine the use of a particular technology.

Usually you do that from a fairly well known set of requirements, perhaps even an existing application.

This might be switching from client side web to server side, client server to web based or say using Silverlight, or EJB.

Obviously the results can have a serious impact on the project but it shouldn't (unless you respecify) affect the meat of what you want to build.

Either one is potentially 'wasted' effort , if you intepret the effort as not producing a deliverable. A myopic viewpoint to say the least but we are talking about bean counters here.

I've just had yet another bad experince with a prototype, to be quite honest I'm coming to opinion that formally declaring you are going to do one is a serious risk. There are far too many types in charge, who don't know what one is.

I would think (re: your last paragraph) that this is one place where a clean description of the prototype (visio, powerpoint, html with minimal code, etc.) becomes so important.