Categories of prototypes as recommended by DSDM

Dynamic Systems Development Method (DSDM) is a framework for delivering business solutions that relies heavily upon prototyping as a core technique, and is itself ISO 9001 approved. DSDM uses the word ‘prototyping’ because that is the industry ‘standard’, but they are not truly prototypes: they are partial system components. A DSDM prototype is not ‘all done by mirrors’, but is built using the platform on which all the development work is done, and meeting all the required  standards. In other words, the prototypes are intended to be evolutionary {may be evolved horizontally (breadth then depth) }rather than throwaway {each section is built in detail with additional iterations detailing subsequent sections}: they will evolve into the delivered system. Of course, there will be occasions when it is better to throw something away and start again, but the aim at all times should be to build on what is there already.

Four categories of prototype are recommended by DSDM that are used at different stages of development, and have very different purpose. They are:

  • Business prototypes
  • Usability prototypes
  • Performance and capacity prototypes
  • Capability / design prototypes

While the purpose of each prototype category is different, it will often be the case that some combination of them will be used. For instance, a common combination is the business and usability prototype, but this approach should not be taken as a matter of course. If the functionality is at all complex, it may be better to get it right before worrying about the presentation aspects. Conversely, if there is no standard for user interface design, it is good idea to get some usability prototyping done first. The categories of prototype to be built in a timebox should be decided at its outset based on the aims of the timebox.

Business prototypes

  • Purpose:
    A business prototype demonstrates the developers’ understanding of the functional requirements. The developers can use this prototype to demonstrate to the users how the final system could work. This will enable the users to better formulate their real business requirements.
  • Description:
    A business prototype is designed only to demonstrate how the business processes are supported by the computer system. It is not designed to look good or to be particularly user-friendly: nor will secondary functionality, such as error checking, necessarily be implemented. It is very important that the users understand the purpose of demonstrating a business prototype.
  • How used:
    A business prototype enables the developers to demonstrate to the users their understanding of the key system requirements early in the project. This early prototype can then be evolved to cover more of the functionality and to incorporate non-functional aspects. Typically, the developer will use a scripted demonstration to ensure that the functionality is demonstrated to best effect. Any discrepancies between the developers’ understanding and the business requirements are noted.
  • Position in the project lifecycle :
    The first business prototype will be demonstrated as early as possible in the project lifecycle (possibly as early as the Feasibility Study, but no later than early in the Functional Model Iteration). This will confirm the right system is being built. First, the fundamental functionality of the system will be demonstrated. Later on, more detailed functional requirements can be demonstrated and/or other areas can be business prototyped.The final business prototype will clearly demonstrate to the users how the system will work. It may not look very pleasing, and have lots of missing functionality, but it will ensure the right system is being built.
Usability prototypes
  • Purpose: A usability prototype ensures the computer system will be as easy and intuitive to use as possible. Users should enjoyusing the system and it should be obvious how the system can be used. If this is done well, end-users will need less training before they can use the system effectively, while still having a good understanding of the full capabilities of the system.
  • Description:
    Well-designed computer systems are simple and straightforward, easy to learn and understand, and fun to use. It is impossible to achieve usability without trying the system out on the users. A usability prototype demonstrates how the user interacts with the system. It may not actually automate the business process. For example a form is displayed, the user adds data, but nothing is written to disk. The user can understand how to move around the system and how the  interface works.
  • How used:
    A user carries out a number of tasks using the prototype.  Any difficulties encountered by the user in achieving those tasks are noted so that the usability of the system can be improved.Contrast this with the business prototype where the developer will typically demonstrate the system, to show the functionality only. A business prototype may be rather user-unfriendly so it is better if the developer removes the need for a user to learn the interface.There is a danger of building a usability prototype that cannot be developed into the final system. Developers must take care not to create any unrealistic expectations.
  • Position in the project lifecycle:
    usability prototype may be built during either the Functional Model Iteration or the Design and Build Iteration, but there are many benefits in building it as early as possible. For a computer system to be easy to use, it must have a simple conceptual  model that the users can easily understand to help them move around the system.
    A usability prototype confirms that a good conceptual model has been chosen. If this is not done early on in the project and the model is wrong, it could adversely affect the design of the system. To reduce the risk of this, a high-level usability prototype should be built in the Functional Model Iteration or early on in the Design and Build Iteration. More detailed usability, such as the buttons in a window, can be designed later. If standards for the user interface are chosen early on, then all programs can be built to the agreed standard, reducing the need for rework. Having a stable installation Style Guide in place before prototyping commences on any project would help even more.In practice there are many benefits in combining the business and usability prototypes.
Performance and capacity prototypes
  • Purpose:
    A performance and/or capacity prototype ensures that the final computer system will be able to handle the full peak time workload required. While users may be involved, this category of prototype is typically for the benefit of the developers.
  • Description:
    This prototype deals with the non-functional aspects of the system, such as concurrent transaction volumes, data loading, overnight batch reports, and month end batch runs, as well as on-line screen performance. Checks will be made that the target system has enough resources to function adequately in the live environment, even when other systems are competing for machine resources.
  • How used:
    Performance and capacity prototypes are usually developed for the benefit of the developers to ensure the computer system can meet its desired performance requirements. A test scenario is set up and repeated while changing different aspects of the system to see how it performs. This process is best automated so that it is easily repeated, but it can be
    done manually where a group of users follow a script. The system is monitored to see where any “bottlenecks” occur.
  • Position in the project lifecycle:
    This category of prototype is typically used during Design and Build Iteration, after the required functionality has been determined. Often existing business prototypes will be used for performance testing. Sometimes early in the project design, the developers may be concerned as to whether a certain piece of functionality can be provided within the
    constraints of the machine/network environment. In this case, a performance and capacity prototype can be specially built to check where the limits might be. Such a prototype might look very different from the final system.
Capability/technique prototypes
  • Purpose:
    Developers often have a range of design options and sometimes a choice of tools to use. A capability/technique prototype tries out a particular design approach or tool to help in choosing between these options.
  • Description:
    This category of prototype is typically limited in functionality and is for the benefit of the developers only. The prototype demonstrates the capabilities and limitations of an approach, a technique or a tool to the developers.
  • How used:
    The developer builds a number of prototypes and weighs up the benefits of each technical approach.
  • Position in the project lifecycle:
    Although selection of a tool is usually made outside any one particular project, a tool capability prototype can be developed during the Feasibility Study to ensure that the potential technical approach will be soundly based. Later design capability/technique prototypes are created during the design phase of a project.Different designs or tools are used to build prototypes that represent the options available to the developer. Each prototype can then be assessed and the best approach, technique or tool selected.
Sources:

One thought on “Categories of prototypes as recommended by DSDM

  1. Pingback: » Managing the prototyping process in DSDM

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s