Thinking area of the lazy dreamer

Menu

Dynamic System Development Method (DSDM)

What is DSDM?

DSDM is a framework based on best practice and lessons learnt since the early 1990’s by DSDM Consortium members. It is another approach to system development, which, as the name suggests, develops the system dynamically. It is independent of tools, in that it can be used with both structured analysis and design approach or object-oriented approach.

The Dynamic System Development Method (DSDM) is dynamic as it is a Rapid Application Development method that uses incremental prototyping. DSDM is particularly useful for the systems to be developed in short time span and where the requirements cannot be frozen at the start of the application building. Whatever requirements are known at a time, design for them is prepared and design is developed and incorporated into system. In Dynamic System Development Method (DSDM), analysis, design and development phase can overlap. Like at one time some people will be working on some new requirements while some will be developing something for the system. In Dynamic System Development Method (DSDM), requirements evolve with time.

DSDM focuses on delivery of the business solution, rather than just team activity. It makes steps to ensure the feasibility and business sense of a project before it is created. It stresses cooperation and collaboration between all interested parties. DSDM makes heavy use of prototyping to make sure interested parties have a clear picture of all aspects of the system.

Background of DSDM

Business are putting increasing pressure on their IT suppliers to deliver better systems, faster and cheaper. In today’s rapidly changing world, they are no longer able to wait for years for a system to be provided: the business may have changed radically during the years of development. It is imperative to find a different way of building IT systems. The technology that is now available to developers allows for more speedy production of system but the answer lies not only in the use of tools. The whole process needs to change. The classical, waterfall life-cycle does not take full advantage of modern technology and does not facilitate the change that is inherent in all systems development. It has been around for about 40 years and is basically the solution to an old problem -that of not having a full understanding of the problem to be solved and not having a coherent approach to solving the problem before starting to code a solution.

The waterfall approach of a strict sequence of stages has been seen to be flawed for many years now.Several attempts have been made to move away from it. including Barry Boehm’s iterative style of development using a spiral model of planning, risk analysis, engineering, and customer evaluation. Though excellent, the spiral model did not achieve the penetration into IT practices that it deserved. The emergence in recent years of many ‘Agile’ methods proves the need for a different approach. While some, such as Extreme Programming, have gained wide acceptance they do not cover all aspects of a project and can leave an organization confused as to how to integrate the many solution on offer. This provides one explanation for the less than optimal acceptance of agility as the way forward by the majority of IT solution providers. Another could be that, until recently there has been sufficient pressure from their customers.

In the early 1990s, the IT industry had become increasingly aware of Rapid Application Development following James Martin’s book Rapid Application Development, which gave some excellent pointers as to how to make the concept work, but did not provide the total solution, There are many tools on the market, but to use them often meant buying the vendor’s process as well. the founding members of the DSDM Consortium saw this as a block to the growth of successful and fast solution delivery.

The Consortium was inaugurated in January 1994 with the aim of producing a public domain, commonly agreed method which would be tool-independent. Ed Holt who chaired the Consortium for the first two years said that every organization that bought a RAD tool really needed a new process. DSDM aims to provide that process for building and maintaining systems that meet tight time constraints in a controlled project environment. The Consortium had 17 founder who resented a mix of organizations that remains today: large IT vendors, smaller tool vendors, and user organizations of all sizes.The Consortium now has hundreds of members with established regional consortia in North America, Benelux, Sweden , France and Denmark with interest growing in other countries, such as Australia India And China.

During 1994, the Consortium’s Technical Work Group put together the process and produced guidance material based on the experience and best practies of Consortium members. a few components of the framework were original ideas from experts in particular areas, but most of them were tried and tested -but they had never been brought together as a cohesive approach.

Why DSDM more rapid than the Waterfall ?

DSDM produces industrial strength systems that meet users’ need and are fully extendible and maintainable over long periods of time -they are not one-off or throwaway. In business terms, they the exact peer of good system developed by the waterfall approach, but take a lot less time to develop.

There are two main reasons. Less is actually done. There is much less time spent in briefing people, and bringing them repeatedly up to speed. Little time is lost through task-switching by users or developers. Most importantly of all, only the features that are needed are actually developed.

The second reason is that problems, misunderstanding and false directions are identified and corrected early, so avoiding the massive rewrites often required late in waterfall projects. This has a further benefit. The resultant code developed under DSDM is consistent and of a piece, whereas waterfall code, by the end of the projects, is often already patched and out of synchrony with its documentation. The result is that DSDM=delivered code is also easier to maintain.

When to use DSDM?

DSDM is not the panacea to all project ills that developers are often promised. There are classes of system to which the framework is most easily applied and these are the areas which an organization which is less experienced in agile development should focus on to begin with -unless of course the pressure to deliver is so great that an ‘unsuitable’ project must be tackled before the organization is mature in its use of the an agile approach, and DSDM is particular. The framework has been used in a wide variety of projects in a diverse set of organizations. It is difficult to say that the framework should never be used for a particular sort of application.

The main questions to ask when deciding on the appropriateness of a proposed system to DSDM development are:

Is the functionality going to be reasonably visible at the user interface? :- Of course the use interface includes reports as well as screens or indeed any other way of showing the end-user what is happening inside the system. If users are to be involved throughout the development process, they must be able to verify that the software is performing the right actions through prototyping, without having to understand the technicalities of what is happening behind the user interface.

Can you clearly identify all classes of end-users? :-It is essential to involve users within the project who can represent all of the potential end-user population. This has caused some concern when developing systems for widely disparate or geographically dispersed populations. The important thing is to ensure that you can obtain complete coverage of all relevant user views with on the development team. Otherwise there is a danger of driving the development in a skewed direction. Moreover the review process of sending out documents for a matter of weeks to a wide user group is very often not feasible on a DSDM project. Such reviews limit the chances of delivering on time.

Is the application computationally complex? :-This is possible one of the hardest questions to answer. What is complex for one organization is simple for another. A lot will depend on what is available in terms of the building blocks to the development team. The important thing is not to develop too much complex functionality from scratch. This question is closely linked to the first question about the visibility of functionality. For instance, if the system is performing complex actuarial calculations, this could render the project difficult for DSDM. On the other hand, if the calculation processes have been used in previous systems and are tried and tested, the actuaries will trust what is presented to them.

Is the application potentially large? :- DSDM has been used and is being used to produce very large systems, but in every case it has been possible to develop the functionality in fairly discrete chunks. There are several DSDM projects in progress at the time of writing that have a development period of two to three years. This could be viewed as not being rapid development, but increments will be delivered at regular intervals rather waiting until everything is complete before the system is put into operation. If the system is large and there is no possibility of incremental delivery, i.e. everything has to be delivered in a matter of months for the system to be useful, them it must be possible to break down the work for development by parallel teams.

Is the project really time-constrained? :- It is all too easy for business management to say that a system must be delivered by a certain date when they don’t really mean it. This is potentially disastrous for the project. It means that whole the developers are geared up to follow the DSDM guidance; the end-user participation at all levels is not as forthcoming as it should be. At best this is frustrating. At worst, the project goes in the wrong direction because the drive from users is not there and developers start making assumptions about what is needed in order to keep active.

Are the requirements flexible and only specified at a high level?:-This could be reworded as ‘Do you have complete understanding of everything that must be delivered?’ Whatever the project, the answer is just about always ‘No!’ but, for DSDM to work successfully, the level of detailed understanding at the outset of the project should be lower than is the norm.The use of prototyping with knowledge users to elicit requirements as you go is fundamental to the approach. If everything is understood and all the detailed requirements have been agreed and fixed before the software builders come on the scene, major benefits of DSDM will not be achieved, such as building the right system rather than what was originally requested.Also, if the requirements are inflexible, it will not be easy to negotiate what can be left out if the project deadline is approaching and a great deal of work remains to be done.