From: Andrew Gabb (agabb@tpgi.com.au)
Date: Sat May 01 2004 - 22:52:15 EST
Monterey, Laura CTR wrote:
> The prototype is now supposed to be a tool for eliciting
> requirements for this common display system. Can a prototype
> morph into the actual product? When do you cut off development on
> the prototype?
If you intend or expect the prototype to evolve into an operational product, you need to consider this from the beginning. This is called evolutionary (as opposed the throwaway) prototyping. The reason for this is that the quality of a prototype is usually less than the quality needed (or mandated) for a releasable product, and may include functional shortcuts in areas which are not being tested in the prototype, in both cases to save time and dollars. And it's virtually impossible to 'engineer in' the quality later, though many have tried.
I'm a great believer in throwaway prototyping simply because you have more flexibility, can work faster, and your architecture sometimes needs to be much more flexible than the final product. But the killer is that your 'product' design is subsequently much better because of the experience you have from the prototype, both in architecture and requirements. [Note that evolutionary development can also be regarded as, or include, prototyping.]
When to stop prototyping depends on what you're trying to achieve. Disciplined prototyping usually includes a dynamic prototyping plan which addresses these sorts of issues, and dovetails into the development plan. Consideration of risks, both in prototyping and using RP as a risk reduction activity, should drive the activity.
Some of least effective prototyping I've seen was in fact internal to AusDoD, although I've also seen numerous such examples in industry as well. In these cases there was rarely a serious plan, the objectives were unclear at best ("we're gunna try it out and see what we find out"), scenarios were ad hoc or 'toy' and not designed in any way, termination was either gut feeling or when the time/money ran out, and documentation of tests and results was almost non-existent.
The point I'm trying to make here is that prototyping is a project in itself and it needs to be treated as one. That includes plan, requirements, analysis, design, tests, etc., but with shortcuts as appropriate. It should also include a final report with conclusions and recommendations.
> Would I be wasting my time gathering requirements from people who
> have never used this prototype?
No - but it depends on how many users you have. In some ways this could provide additional validation of the prototype. One of the risks of prototyping is that both the developers and the users can be hypnotised by the current prototype, and this can result in blindspots to other important requirements.
> Should I require that all display users take a look at this
> prototype prior to attending an elicitation workshop?
I think so, noting that by developing the prototype you have actually progressed the design a step or two, and ignoring this fact means that your users are starting from different positions, always a problem in a workshop.
The other critical issue, hinted at above, is the use of carefully designed and validated operational scenarios to test and demo your prototype. I think it's more important that your users understand and agree (more or less) on the validity of the scenarios before they play with the prototype. It also gives them something to chew on when they first use the prototype. Otherwise their 'testing' tends to be rather aimless and focuses on knobology, colours and legends rather than the more important efficiency/effectiveness issues.
Andrew
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Mon May 03 2004 - 09:00:18 EST