DSDM: Technology Support

The need for technology support

The technology used to visualize what the developers are thinking and to gain feed-back from that visualization is the basis of much of agile development. However, it is not the total answer. The technology support for a controlled process does not lie solely in the easy generation of analysis and design models, screens, and code. If the process is to be controlled, then strong emphasis should also be placed on automated support for the necessary controls. Controls are an overhead on productive work, albeit a necessary one. Saving in effort can be made by automating the control of the status of, and access to, work products and in ensuring that they have been created correctly.

Agile developers would much rather spend their time creating the solution than controlling it. So it is the control activities that are likely to be squeezed out of their schedules when they are under pressure to deliver. Another area that does not enthrall developers is configuration management. However, configuration management is of the elements of an agile support environment where more things are being produced and changed at a faster rate than in traditional method. The need for support in this area is obviously fundamental. It should be easy for the developers to place their works under configuration management as soon as possible and as often as they should, without causing them to slow down in their development activities. Testing also looms large as something which developers see as a necessary evil, but which would be a much more productive activity with tool support. The list goes on.

DSDM Support Environments

DSDM has defined an agile tool ‘nirvana’. It is an environment which will support the whole process from feasibility to implementation (including aspects such as reverse engineering for legacy code) with all the necessary controls as automated as possible. It does not exist and it is unlikely that any one tool vendor will offer the fully integrated set. Indeed it is yet another cry for an IPSE (integrated project support environment), but one which is designed for SDSM projects. Such an environment requires integration at a number of levels:

  • presentation to provide a common ‘look and feel’ across all tools;
  • data so that all tools share the same repository;
  • control so that one tool can notify and/or initiate actions in other tools;
  • platform, in order to port the toolset from one platform to another

May be such an environment will exist in the future, but in the meantime we have to be more realistic and look for tools that will make savings in time and effort without being too costly. If we focus in the money side, several low-cost tools have been found to have a beneficial impact on effort. Low-cost tools for code and schema generation are available, as are tools for prototype generation. Both of these speed up development markedly compared with coding by hand. Another area where inexpensive tools can help is in the perennial headache of documentation. Automated support for creating documentation is readily available. Fortunately, many tools are self-documenting.

Testing Tools

One of the components of the DSDM support environment is testing tools. There are many varieties of testing tool available on the market and DSDM strongly advocates the use of tools in this area. Producing a tested system in a very short time can only be made easier with effective tools.

A very useful class of tools is capture and replay tools. These can lessen the need for documented test scripts. The quickest way to document tests is to record them as they are performed. A great deal of developer time can be saved through this route. Not only does this eliminate the need for producing ‘paper’ scripts before testing takes place, but the tests can be achieved as evidence of what tests have taken place. Capture and replay tools are also extremely beneficial in building up regression test suites which can be left to run overnight while the developers have a well-earned rest.

Static code analyzers can relieve the effort in code inspection and lessen the need for third-party verification that the code is to the required standard.

If the testing toolset is to be really complete, then dynamic analysis tools will perform tests in the background while demonstrations of a part of the software are taking place. Dynamic analysis includes checking array bounds and detecting memory leakage, etc.; things that should be tested, but which may be difficult to fit into the tight schedule of a project.

Configuration Management Tools

DSDM asks a lot of configuration management. Everything that is produced (analysis models, designs, data, software, tests, test result, etc.) should all be kept in step within another, so that is relatively easy to move back to a known ‘build’ state whenever the development has gone down a blind alley. This requirement means that automated support is essential and that the automated support should allow for many versions used, but this rarely the case. Anyway, given the diversity of products that are under development at any one time, it is probably asking too much to expect all the relevant tools being used in projects to be sufficiently integrated to have every product in step. This means that a specialist configuration management tool should definitely be on the shopping list of an organization that is planning to take DSDM seriously. The ability to baseline everything on a daily basis is the ideal. So the tool should not incur too much of an overhead is its use. There are several excellent configuration management tools available which will do the job perfectly satisfactorily if the procedures governing their use are firmly in place.

Effective Tool Usage

Although there are excellent tools in the market, any tool is inly good as its users. They should not be relied upon as the whole answer. The developers should be confident that they know how to use them properly and that the tools are an asset rather than otherwise. The purchase of a tool environment for agile development should think carefully before buying. It is possible in early DSDM projects to live with what you already have. Indeed it is probably preferable not to introduce too many new things at the same time. Once the developers are used to the process, they will soon see where tool support would be particularly beneficial in their working environment. If tool support is to be bought, the purchaser should read the chapter in the online manual that gives very strong guidance on the characteristics of tools for DSDM. Not least of these is usability. For some reason, software tools are often less usable than their counterparts in the business environment – maybe we just like to make thing hard for ourselves.

Source

  • DSDM Consortium edited by Jennifer Staplenton , 2003.DSDM. In Paul Bocij, Jennifer Staplenton. DSDM Business Focused Development. 2nd ed. The DSDM Consortium. .ISBN 0-321-11224-5

Sort Description:Nine (9) Principles of Dynamic Systems Development

Summary of Nine Principles of DSDM
  1. Active User Involvement is Imperative
    • DSDM – a user-centred approach
    • Active participation through lifecycle
  2. DSDM Teams must be Empowered to Make Decisions
    • DSDM team comprises developers and users
    • Decisions made as requirements refined or changed
    • No need for recourse to higher management
    • Rapid and informed decision-making
  3. The Focus is on Frequent Delivery of Products
    • Team produces agreed products throughout lifecycle
    • Team chooses best approach to achieve objectives
    • Ensures focus on delivery, not just activity
  4. Fitness for Business Purpose is the Essential Criterion for Acceptance of Deliverables
    • Build the right product before you build it right
    • Meeting business need is more important than technical perfection
  5. An Iterative and Incremental Approach is Necessary  to Converge on an Accurate Business Solution
    • DSDM allows solutions to emerge incrementally
    • Developers make full use of user feedback
    • Partial solutions can be delivered to meet immediate needs
  6. All Changes During Development are Reversible
    • All products should be in a known state at all times
    • It should be possible to step backwards, where an approach does not work
    • The team should be willing to embrace change and not be defensive
  7. Requirements are Baselined at a High Level
    • Freezing and agreeing purpose and scope of system
    • Baseline at a level which allows detailed investigation of requirements at a later stage
  8. Testing is Integrated Throughout the Lifecycle
    • Not a separate activity at the end
    • System is tested and reviewed incrementally by developers and users
    • Testing evolves as prototypes mature
    • Aim is to find and fix errors as early as possible
  9. A Collaborative and Co-operative Approach between all Stakeholders is Essential
    • Everyone working together as a team
    • Shared goal of achieving the business objectives
    • Give and take on all sides
    • Involves all parties, not just core team

Nine Principles of DSDM -Detail

Source

  • University of Greenwich,  London, UK

Nine (9) Principles of Dynamic Systems Development Method (DSDM)

Principle 1: Active user involvement is imperative.

DSDM’s strong focus on the business purpose of the system being developed requires that the ultimate users of the system be involved throughout the development project. This is because the system attributes that will make it fit for its purpose cannot be understood well enough in the project’s early stages to commit them to a detailed specification. Therefore, the only way to make appropriate detailed decisions and know that the evolving system is converging on the ideal of “fitness” is to fully involve the users throughout the project.

Principle 2: DSDM teams must be empowered to make decisions.

This principle does not give the team free reign to do whatever they wish. Rather, it advocates that the team be delegated the authority to make most of the day-to-day decisions as the project progresses. With active user involvement, such delegation can result in the team being able to move quickly and steadily toward system delivery. However, when a decision that must be made falls outside the team’s authority (e.g., cost overruns), DSDM recognizes the importance of raising such decisions to the appropriate authority.

Principle 3: The focus is on frequent delivery of products.

This principle means that the project’s progress should be measured by the production of tangible products, rather than by mere activity. The phrase “delivery of products” does not refer only to the incremental delivery of a working system to an end user. Products in this sense include any sort of work product that may be produced as the project moves forward (e.g., a specification, a throwaway prototype, a design document); and delivery could be simply within the project team. DSDM requires that as the project moves forward, it must produce artifacts that prove that progress is being made.

Principle 4: Fitness for business purpose is the essential criterion for acceptance of deliverables.

This principle is the practical manifestation of DSDM’s belief that specifying detailed requirements upfront is not helpful. By placing fitness for purpose above satisfaction of requirements, and by involving users consistently, DSDM zeroes in on the end user as the only one who can say whether or not the system as it is evolving is acceptable.

Principle 5: Iterative and incremental development is necessary to converge on an accurate business solution.

In an environment where it is assumed that the project’s end result cannot be foreseen in great detail, incremental development is the best insurance against the project going terribly awry. Incremental development is essentially an exercise in trial and error, where each new increment is presented to the user who validates (or invalidates) the direction the team has taken. “Converge” is the key word in the principle. It is assumed that the most direct path to the end product is not likely to be known, so DSDM engages in constant checking and correcting of the path to bring the project to a satisfactory end as quickly as is reasonably possible.

Principle 6: All changes during development are reversible.

If we agree that the project is practicing trial and error, then we must expect that there will indeed be errors from time to time. This principle gives us permission to discard erroneous work when necessary. Surely, we will try to salvage the good from a mistake, but we must recognize that there will be times when the most efficient path is to discard some work and try again.

Principle 7: Requirements are baselined at a high level.

The first three words of this principle, “Requirements are baselined,” represent a departure of DSDM from some other Agile methods. DSDM recognizes the importance to the project of stability in scope and direction. By baselining (freezing) the requirements at some level, stakeholders are establishing a stable basis for the team’s work. This does not mean that this baseline will not change; rather, it requires that serious deliberation precede any such change so that all stakeholders understand and agree to what would become the new requirements baseline. The last four words, “at a high level,” is the part of this principle that makes it agile. It leaves the details of what the requirements mean to be worked out between the team and user.

Principle 8: Testing is integrated throughout the life cycle.

Testing does not show up as a step in the DSDM life cycle because, like other Agile methods, DSDM promotes a strong quality-consciousness by all team members. Every task should include an appropriate verification or validation step like a review or test by a team member or user. This principle works together with principles 1, 4, and 5 to continually check the project’s progress toward its goal of a system fit for its business purpose.

Principle 9: A collaborative and cooperative approach between all stakeholders is essential.

This last principle is little more than the sum of the first eight. The only way that principles 1–8 can be applied successfully on a project is if all stakeholders accept DSDM and their roles as DSDM defines them. If any stakeholder does not agree (especially an influential stakeholder), then DSDM cannot work in that environment.

Nine Principles of DSDM -Lite Version

Source

Overview of DSDM : Phases of DSDM life-cycle

5 phases of DSDM lifecycle

phases of DSDM life-cycle

Pre-project

The pre-project phase ensures that only right projects are started and that they are set up correctly. Once it has been determined that a project is to go ahead, funding is available, etc., the initial project planning for the feasibility study is done. Then the project proper begins with the feasibility study.

The feasibility and business studies are done sequentially. They set the ground rules for the rest of development, which is iterative and incremental and therefore they must be completed before any further work is carried out on a given projects

Feasibility study

In this phase the problem is defined and the technical feasibility of the desired application is verified. Apart from these routine tasks, it is also checked whether the application is suitable for Rapid Application Development (RAD) approach or not. Only if the RAD is found as a justified approach for the desired system, the development continues.

Business study

In this phase the overall business study of the desired system is done. The business requirements are specified at a high level and the information requirements out of the system are identified. Once this is done, the basic architectural framework of the desired system is prepared. The team researches the business aspects of the project.

  • Does it make good business sense?
  • Who are the participants and interested parties?
  • What is the best work plan? What is needed to:
    1. Build it
    2. Test it
    3. Deploy it
    4. Support it?
  • What technologies will we be using to build and deploy it?

The systems designed using Rapid Application Development (RAD) should be highly maintainable, as they are based on the incremental development process. The maintainability level of the system is also identified here so as to set the standards for quality control activities throughout the development process.

Functional Model Iteration

This is one of the two iterative phases of the life cycle. The main focus in this phase is on building the prototype iteratively and getting it reviewed from the users to bring out the requirements of the desired system. The prototype is improved through demonstration to the user, taking the feedback and incorporating the changes.Prototyping follows these steps:

  • Investigate
  • Refine
  • Consolidate

This cycle is repeated generally twice or thrice until a part of functional model is agreed upon. The end product of this phase is a functional model consisting of analysis model and some software components containing the major functionality

Design and Build Iteration

This phase stresses upon ensuring that the prototypes are satisfactorily and properly engineered to suit their operational environment. The software components designed during the functional modeling are further refined till they achieve a satisfactory standard. The product of this phase is a tested system ready for implementation.

There is no clear line between these two phases and there may be cases where while some component has flown from the functional modeling to the design and build modeling while the other component has not yet been started. The two phases, as a result, may simultaneously continue.

Implementation

Implementation is the last and final development stage in this methodology. In this phase the users are trained and the system is actually put into the operational environment. At the end of this phase, there are four possibilities, as depicted by figure :

  • Everything was delivered as per the user demand, so no further development required.
  • A new functional area was discovered, so return to business study phase and repeat the whole process
  • A less essential part of the project was missed out due to time constraint and so development returns to the functional model iteration.
  • Some non-functional requirement was not satisfied, so development returns to the design and build iterations phase.

Dynamic System Development Method (DSDM) assumes that all previous steps may be revisited as part of its iterative approach. Therefore, the current step need be completed only enough to move to the next step, since it can be finished in a later iteration. This premise is that the business requirements will probably change anyway as understanding increases, so any further work would have been wasted.

Post-Project – Maintenance

After the product is created, maintenance will inevitably need to be performed. This maintenance is generally done in a cycle similar to the one used to develop the product.

According to this approach, the time is taken as a constraint i.e. the time is fixed, resources are fixed while the requirements are allowed to change. This does not follow the fundamental assumption of making a perfect system the first time, but provides a usable and useful 80% of the desired system in 20% of the total development time. This approach has proved to be very useful under time constraints and varying requirements.

Nine Principles of DSDM -Detail

Nine Principles of DSDM -Lite Version

Source

Running prototype demonstrations in DSDM

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

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

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: