Software

Use prototyping to visualize project requirements

Prototypes are built early in the development lifecycle, and they're used to provide valuable insight into the look, feel, and general workflow of an application. Here's what creating a prototype entails.

A prototype represents the shell of an actual production application. Prototypes are built early in the development lifecycle, and they're used to provide valuable insight into the look, feel, and general workflow of an application. (Sometimes people call the first production implementation a prototype, but that's not correct. If you have multiple implementations, the first one is more aptly called a pilot test. Likewise, a prototype is not used to validate whether a proposed solution works. This is more aptly called a proof-of-concept.)

The main purpose of a prototype is to gather and document requirements. If you're pretty confident that you have a good set of requirements, there's not necessarily a reason to build an initial prototype. After you build an initial prototype you should show it to the clients to validate the work done so far looks okay. You then use the prototype to gather additional requirements. As you receive requirements, you should document them in the same way you would document the additional requirements you're gathering though other means.

The prototype starts off as a shell that contains the online screens. There should be very little programming of the core business processes and only enough program code to allow the prototype to go from screen to screen. The point of the prototype is to provide a visual representation of the application, not the complex business logic that goes behind it.

What happens to the prototype?

There are two options for what happens to the prototype once it's built.

  • Complete or partial throw-away. Typically, if you build a prototype, you'll throw it away after the requirements have been gathered. Remember that the prototype does not have to be the start of the final solution. The main purpose is to gather requirements. I've seen online applications that appeared to be running on the web, when, in reality, the team members built the prototype in PowerPoint or Excel. There was no thought that somehow this PowerPoint prototype would be reused further as the project progresses. On the other hand, in many instances you'll build a prototype using the same technology as the final solution. In this case, there may be some aspects that can be reused. You may be able to leverage some of the physical components of the prototype as a starting point for the Design and Construct Phases of the project.
  • Iteratively develop into final application. If you're using an iterative development approach, the first prototype should still be put together quickly. However, instead of the work being abandoned or thrown away, the prototype is updated with the new requirements. In the second pass, more business logic is also placed into the application. At this point, it's no longer called a prototype. Instead, the prototype shell is used as the basis for developing the final solution.

In summary, prototypes are used to gather requirements, and are especially useful in visualizing the look and feel of an application and the process workflow. The useful life of a prototype will vary according to the project lifecycle model. It's possible that the prototype can be thrown away, or that some components can be reused later in the project. It's also possible that the prototype can be used as the basis for developing the final solution.

19 comments
khamsahassan
khamsahassan

which 1 is not good use of prototyping

1.obtaining user suggestions about changing the prototyped system 

2.revising plans for the part of the system which need to be done first 

MrGrumpy
MrGrumpy

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.

nairharish
nairharish

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

thomas.ratliff
thomas.ratliff

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.

mabingle
mabingle

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

kmuralidharan66
kmuralidharan66

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

dogknees
dogknees

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.

Dr Dij
Dr Dij

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.

Tony Hopkinson
Tony Hopkinson

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.

BALTHOR
BALTHOR

They just might end up in somebody's menagerie.

Tony Hopkinson
Tony Hopkinson

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.

dconnolly
dconnolly

I have had good success with this approach, particularly in BI projects, use of Power Point for relatively simple componets to build a BI dashboard visual can be very helpful. Caution: DO NOT show somethign that your toolset or DB cannot support when it comes to building the genuine application. I use it to solicit input and requirements for version one of the application.

ShimCode
ShimCode

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

meryllogue
meryllogue

Sorry... you will never compare... only contrast. Could you put that post in plain English?

meryllogue
meryllogue

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.

Dr Dij
Dr Dij

these tools are "slicker 'n baby snot". I think is a mistake to setup actual working prototype before you have a visualization of how it works done. You hash out a prototype in 'code' and it is likely to have its guts 'refactored' onto a new database or technology during your iterations on the project. with a 'visualization' type software, you are NOT worrying about the guts to make the prototype simply show the use cases you want. (the functions of the prog are the use cases) AND you can show this to the sponsors / users BEFORE you start coding or even start the project possibly. Plus these are (in iRise case at least) a visual repository for reqts / use cases.

Tony Hopkinson
Tony Hopkinson

that if it's for layout , use a drawing package, and if it's for tech do a console app. Not because it's a better way to do it, but because you don't end up with something they'll try to sell.