Each of the development phases (the Functional Model and the Design and Build Iterations) contains iteration through
prototyping. There are basic controls that must be implemented in order to ensure the success of these activities.
These controls are built into a prototyping cycle and are aligned to the cycles within the timebox process.
A prototyping cycle passes through four stages:
- identify prototype
- agree plan
- create prototype
- review prototype.
Acceptance criteria for the prototype should be defined in outline before any development takes place in order to lead the prototyping activity in the most useful direction.
The Development Plan in its schedule of timeboxes sets a limit on the time to be spent on each prototype. The team must agree the detailed plan for the current prototyping cycle. This includes prototyping the Must Haves first. Lesser parts will be dealt with if time is available.
The plan should not be allowed to slip unless significant problems arise, e.g. unexpected and dramatic changes in scope. However, such problems will probably require halting all activity temporarily while the project direction is
It is important that the reasons for the time limit are clearly understood by the users. It is their priorities that will identify the essential components of a prototype. They must be made fully aware that asking for in-depth investigation of a particular area may mean that they have to decide what other area they can do without.
The prototypes are usually developed collaboratively with users. However later in development where issues such as performance are being addressed, the users will take a back seat.
Prototypes are not necessarily automated. For instance, early in development, a paper-based storyboard may be more cost-effective and flexible than a fully automated user interface to unexplored functionality. Both business and technical imperatives will drive the choice of prototyping medium.
Each prototype should be reviewed by the prototyping team (both developers and users) and other interested parties, where appropriate, (e.g. business analysts and senior user management) to ascertain:
- which objectives it has met successfully
- which areas will have to be included in later development
- which missed areas can be safely postponed (or possibly incorporated in another project) in order to achieve the project’s timescales
- the acceptability of what has been produced.
As well as verifying that the relevant quality criteria have been met, there are two major aims of the review:
- to ensure that the development team are following the right track
- to get the users at all levels to buy in to the completed and future work.