Daily Archives: October 23, 2011

Running prototype demonstrations in DSDM

Posted in Agile Software Development by

In order to get the best value out of prototype demonstrations, the guidelines below should be followed.

The demonstrators should prepare the audience for any prototype demonstration session. The objectives of the session should be clearly stated together with the known limitations of what will be seen. It can be too easy to assume that, since one or two users have been involved in the development of a prototype, the rest of the user community are as knowledgeable about what is going on. Indeed, the Ambassador Users will talk to their colleagues but this communication channel should not be totally relied upon until working software has been demonstrated to the wider user population, as it is often difficult to explain what has not been seen – the reason why DSDM is the way it is.

During the session, discussion should be encouraged. Putting the prototype through its paces at such a speed that the users cannot see what may be expected of them in the future is worse than useless. The development team may come away from the session feeling reassured that they are following the right track, whereas all that has happened is that any comments have been stifled.

The Scribe should record all comments made during the demonstration. Otherwise, since the focus of the developers  and the users will be on the behaviour of the prototype, some feedback may be forgotten.

Source:

Testing prototypes in DSDM

Posted in Agile Software Development by

DSDM prototype serves two different roles:

  • it is a partial build of the system that will be delivered
  • it is a technique for gathering information to clarify functional or non-functional requirements.
Different test criteria apply depending on the role the prototype is serving:
  • To the extent that the prototype represents part of the functionality of the final system, a test pass/fail can be based on whether or not the test result from the prototype matches an expected result based on the known  requirements.
  • To the extent that the prototype is intended to clarify requirements, the criterion for test success or failure is whether or not the prototype generates the expected information. This is exploratory. The expected
    information cannot be predefined in the same way that an expected result can be. The test of the prototype is being used to expand the knowledge and understanding of the prototype builder. The test is successful if this
    is achieved in the area under investigation.

A single prototype may serve in both roles and therefore should be tested against both criteria.In the Functional Model and Design and Build Iteration phases, prototyping generally iterates up to three times in line with the timeboxing process.  The prototypes that are produced can fall within any one of four categories. Prototypes of all categories can be tested against a mixture of “expected result” and “expected information” criteria.

This iterative lifecycle is summarised in the table below, which shows the categories of prototype and the type of testing criteria that will tend to apply at each iteration.

Iteration within Timebox
Prototype Category Investigation Refinement Consolidation
Business EI EI/ER ER
Usability EI EI/ER ER
Performance EI EI/ER ER
Capability EI EI/ER ER
Testing criteria for the categories of prototype (EI = Expected Information, ER = Expected Result)

Managing the prototyping process in DSDM

Posted in Agile Software Development by

This section discusses a number of key issues that surface in the management of the prototyping process.

Managing iteration

There are several aspects that have to be managed in order to achieve successful passage through prototyping
activities. These are:

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

While prototyping without user involvement is impossible, it is important that the users do not drive the development in the wrong direction through lack of knowledge outside their own sphere of activities. Senior user management must
ensure that a representative set of users is included in prototyping activities.
To ensure that prototyping progresses as fast as possible, it is important that the selected user representatives are available at all times when they are needed.
By keeping the team consistent throughout development, the team can learn from previous prototyping activity and so improve the quality of the products and the efficiency of working.
The number of iterations
As a general rule, it is recommended that three iterations be allowed – and that they are aligned to the timebox process:
  • 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.

Source:

Prototyping cycles in DSDM

Posted in Agile Software Development by

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.
Identify prototype
Before embarking on building a prototype, what is to be prototyped must be clearly identified. This decision will be based on the relative priorities given to the functional and non-functional requirements. Having partitioned the application into possible prototypes, it should be made clear which are the essential parts of each prototype and which are “extras” through applying the MoSCoW rules. This will limit the scope of activity in each prototyping cycle and determine the priorities of the developers and users who are building the prototype.
The prototypes can be selected by various criteria: business area, basic processing required, the user groups, information accessed and the criticality of the processing to the final system.
The results of reviews from previous prototyping cycles provide valuable information when identifying the prototypes to be developed.

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.

Agree plan

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

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.

Create prototype

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.

Review prototype

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

Categories of prototypes as recommended by DSDM

Posted in Agile Software Development by

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: