This section discusses a number of key issues that surface in the management of the prototyping process.
There are several aspects that have to be managed in order to achieve successful passage through prototyping
activities. These are:
- change control
- configuration management
- user involvement
- quality assurance of products
- learning from earlier iterations.
Strict adherence to timeboxes ensures that prototyping cycles are not allowed to lose their focus on delivering to the agreed priorities and that the quality of products is assessed within each timebox.
The procedures for change control must enable change to be introduced quickly and effectively. Over-prescriptive procedures will slow down development.
In order to be able to backtrack to a previous prototype, strong configuration management must be enforced. For instance, users may decide that a previous user interface was preferable to the current one or that the functionality is
progressing in the wrong direction to meet their most immediate business needs. In such circumstances, it must be possible to move backwards smoothly and for all developers to be sure of which version or variant is the current one.
ensure that a representative set of users is included in prototyping activities.
- investigation to see whether the right approach is being taken
- refinement to build on the comments and feedback after the investigative prototype
- consolidation to fully satisfy the objectives of the prototype.
This will mean three prototype cycles leading to a part of the Functional Model and three prototype cycles leading to a part of the Tested System. However, if the nature of the application and/or the technical environment mean that functional modelling and design and build merge then the number of prototypes will obviously be reduced. It is generally advisable to avoid more than three iterations since this can encourage a feeling that things can be left until later.
Collaboration and consensus
Prototyping requires collaboration and consensus between the developers and the users, as distinct from a contract negotiated at the start of the process, which can frequently be a source of confrontation between developers and users.
Choosing what to prototype
When producing the Development Plan, the project manager and the team decide where the categories of prototypes (and any combinations of them) are most appropriate, given the business and technical environment.
Horizontal vs. vertical approach
Having chosen the area to prototype, the DSDM team must first choose whether to build their prototypes in a horizontal or a vertical way. The choice is simply a way of slicing up the application, so any category of prototype may appear in a
horizontal or a vertical application slice.
With a horizontal approach the whole system is first built at a high level to check how it will cover the scope of the project. The detail is filled in later. With a vertical approach a section of the computer system is built incrementally until
it is fully understood, then the next section is started.
Both approaches have their advantages and disadvantages. If the whole concept of the system/business area is new then a horizontal approach may be safer. If the overall structure of the system is well understood but the detail is unclear then a vertical approach might be better. One advantage of the vertical approach is that it allows incremental deployment of subsystems for immediate business benefit. Generally, systems will be built using a combination of horizontal and vertical approaches.