DSDM
Introduction
DSDM development lifecycle is in five phases. These are:
1 Feasibility study
2 Business study
3 Functional model iteration
4 System design and build iteration
5 Implementation.
Key Points 1
1 The DSDM process provides a framework that should be populated according to organisational practices and project needs. 2 The feasibility study investigates whether or not DSDM is the right approach for the project. 3 The business study provides the business and technical foundations for all later development. 4 The functional model iteration cycles produce both analysis documentation and working software. 5 The design and build iteration engineers the system to the required level for operational use.
6 After placing the system in the operational environment during the implementation phase, the scope of what has been delivered and what needs to be delivered next must be assessed.
7 Testing is performed throughout the iterative phases and is not a discrete activity at the end of the development lifecycle. 8 The DSDM products are defined in outline only to allow them to be used in any technical or business environment. 9 The set of products is as minimal as it can be, while ensuring safe progress towards delivery and maintenance.
Key Points 2
1 The nine principles are a cohesive set and should all be applied on a DSDM project 2 The nine principles are:
1 Active user involvement is imperative.
2 DSDM teams must be empowered to make decisions.
3 The focus is on frequent delivery of products.
4 Fitness for business purpose is the essential criterion for acceptance of deliverables.
5 Iterative and incremental development is necessary to converge on an accurate business solution.
6 All changes during development are reversible.
7 Requirements are baselined at a high level.
8 Testing is integrated throughout the lifecycle.
9 A collaborative and cooperative approach between all stakeholders is essential.
Key Points 3
1 DSDM is particularly suited to business applications that demonstrate the following characteristics:
1 are interactive, with the functionality visible at the user interface;
2 have a clearly defined user group;
3 are not computationally complex;
4 if large, possess the capability of being split into smaller functional components;
5 are time constrained;
6 have requirements that are not too detailed or fixed.
2 Iteration is controlled within DSDM through timeboxing and does not run away in an uncontrolled manner.
3 Incremental delivery can deliver business benefit early but it introduces
additional work on deliverables.
4 DSDM does not mandate any set of development techniques.
5 Core models provide the minimum set of documentation necessary for safe
progress through development and for ease of maintenance.
6 The core models and support models for development and maintenance need to be agreed before development begins.
7 Core models need to be reviewed for content and accuracy; support models do not.
Key Points 4
1 Short timeboxes within the overall project timebox are the means of controlling the quality of interim products and avoiding scope creep during development.
2 Keeping timeboxes short facilities effort estimation.
3 Timeboxes have a cycle of investigation, refinement and consolidation.
4 All requirements are prioritised to ensure that the most essential requirements are satisfied first.
5 The deliverables from a timebox are tested and/or reviewed within the timebox, rather then afterwards.
6 Activity within timeboxes should be defined in terms of deliverables rather than tasks.
7 Some development activities cannot be managed using the timebox approach.
Key Points 5
1 Project planning is based around the timebox. 2 Functional and non-functional requirements should be grouped and allocated to timeboxes. 3 The contingency in timeboxes is contained in the lower priority
requirements that may not be satisfied. 4 Estimating the length of timeboxes should involve the team. 5 DSDM defines roles and responsibilities for both users and developers. 6 Key roles that are DSDM-specific include:
1 The visionary (a senior user) to ensure the overall business objectives are adhered to.
2 The ambassador user who brings business knowledge into the team on a day-to-day basis throughout the project.
3 The technical coordinator who ensures that all work fits into the system architecture and meets the required technical standard.
1 DSDM teams should be no more than six people, including the
ambassador user(s). 2 Progress should be monitored daily. 3 The concentration of work for all concerned is greater than on traditional
projects.
Key Points 6
1 Decisions that are not in the control of the immediate project team must be made very quickly.
2 The continuous involvement of Ambassador Users is essential to the success of DSDM.
3 Ambassador users must have sound business knowledge and should be respected by their colleagues, at all levels.
4 “Contracts” shortens communication channels between all parties, both
inside and outside the team.
5 JAD workshops are a powerful means of achieving this.
6 It is advisable to train all the users who will be involved in the project, so
that they understand their roles and responsibilities.
Key Points 7
1 The focus is on building software that is sufficiently robust to be usable
and no more than that.
2 DSDM builds quality controls into the process.
3 Maintainability objectives should be agreed during the business study.
4 Testing is earlier in the lifecycle than traditionally and incorporates all
classes of testing from very early on.
5 Introducing DSDM into an organisation will probably mean that quality control and assurance procedures will have to change.
6 DSDM fits well with both ISO 9000-3 and the CMM.
Key Points 8
1 DSDM is not a home for hackers.
2 The practitioner certificate demonstrates professionalism in RAD.
3 Developers should be “team players” whose focus is not only on
technological problems.
4 DSDM practitioners should be quality conscious and manage their work effectively.
Key Points 9
1 The differences between the languages of the users and developers should not be underestimated.
2 Prototyping helps to break down the language barriers. Prototypes provide a common language.
3 It also ensures that the right system is being build – errors are trapped
early in the process.
4 DSDM prototypes evolve into the deliverable system.
5 Four categories of prototype are defined and are used in particular phases
of development: business usability, performance and capacity, and
capability/design.
6 Evaluation of prototypes through demonstration or user trials needs to be
carefully managed to ensure all feedback from the users is captured.
Key Points 10
1 RAD tool support is not just for producing technical products faster.
2 Wherever possible, tools should be integrated.
3 Tool support is particularly useful in testing, configuration management
and the production of documentation.
4 Do not buy tools specifically for DSDM until the organisation has
achieved a level of maturity in the application of the method.
During 1994, the Consortium’s Technical Work Group put together the process and produced guidance material based on the experiences and best practices of Consortium members. Some components of the method were original ideas from experts in particular areas, although most of them were tried and tested but had not previously been brought together as a cohesive approach.
After version 1 of the method was published in 1995, an early adopter programme was put in place to monitor the use of the method in practice. After feedback from the early adopters and the addition of material that had deliberately been left out of version 1 to get the method visible as soon as possible, version 2 was published in November 1995. The Technical Work Group is still collecting feedback from users of the method and addresses particular needs as they arise through the production of white papers, which supplement the method. For instance, white papers that have been published in 1996 include DSDM in large projects and using the method as a tool during business process change.
To ensure that the method is well understood and applied correctly, the Training and Accreditation Work Group put together a training and examination process that was launched alongside version 1 and which it continues to manage. At the time of writing, over 4500 people have been trained by accredited training providers, and increasing numbers are going through the examination process to become certified DSDM practitioners.
Overview Of The Method
The whole method is based on nine principles, which are discussed in more detail later on, but it is useful to list them here. The first four define the foundations on which the DSDM is built and the other five provide the principles that have guided the structure of the method.
1 Active user involvement is imperative.
2 DSDM teams must be empowered to make decisions.
3 The focus is on the frequent delivery of the products.
4 Fitness for business purpose is the essential criterion for acceptance of
deliverables.
5 Iterative and incremental development is necessary to converge on an accurate business solution.
6 All changes during development are reversible.
7 Requirements are baselined at a high level.
8 Testing is integrated throughout the lifecycle.
9 A collaborative and cooperative approach between all stakeholders is
essential.
All of these principles have been found to be necessary if a quality system is to be supplied in the time-scale required by the business.
1 Development is a team effort. It must combine the users’ knowledge of the
business requirements with the technical skills of the IT professional.
2 High quality demands fitness for purpose as well as technical robustness.
3 Development can be incremental. Not everything can be developed at
once, and delivering something earlier is often more valuable than
delivering everything later.
4 The law of diminishing returns applies – resources must be spent
developing the features of most value to the business.
DSDM is about people, not tools. It is about truly understanding the needs of the business and delivering solutions that work – and delivering them as quickly and as cheaply as possible. The method will not solve every IT problem, but it will do a long way towards ensuring that the business gets the applications systems it needs in the next 40 years.
Some Definitions
The first questions to ask when coming to DSDM are “what is it?” and “why is it different?” I have always found the first question quite difficult to answer. This is mostly because (despite its name) it is not a method in the accepted sense, but a framework of controls for RAD, supplemented by guidance on how to apply those controls. It is a method in as much as it defines a process and a set of products, but these have been deliberately kept at a high level so that they can be tailored for any technical and business environment. There are no prescribed techniques, but suggested paths are supplied for implementers of both structured and object-oriented approaches. It is different because it is possibly the only publicly available method that covers all aspects of system development from project inception through to support and maintenance. It addresses the needs of all participants in RAD: project managers, developers, end users, user management and quality assurance personnel.
DSDM describes project management, estimating, prototyping, timeboxing, configuration management, testing, quality assurance, roles and responsibilities (of both users and IT staff), team structures, tool environments, risk management, building for maintainability, reuse and vendor/purchaser relationships – all in the RAD environment.
Next question: what is RAD? There are many jokes about what RAD stands for rapidly achieving disaster, really awful design – the list goes on. All of them are based on the historical view of RAD as an excuse for bypassing all the best practices in software engineering and starting to code before any real understanding of the proposed system has been reached. My view is that RAD should really stand for responsive application delivery, that is building what the business needs, when it needs it. The two parts to this definition are equally important. If the system is to meet the business needs, then it must be sufficiently robust to be usable in the operational environment. Secondly, the immediate needs of the business can probably be met in the short term and can be functionally be met later on.
A Bit Of History
Businesses are putting increasing pressures on their IT suppliers to deliver better systems, faster and cheaper. In the rapidly changing world of today, they are no longer able to wait for years for a system to be provided: the business may be radically changed 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 speedier production of systems, but the answer lies not only in the use of tools. The whole process needs to change. The classical, waterfall lifecycle does not take full advantage of modern technology and does not facilitate the change that is inherent in all systems development. The classical, waterfall lifecycle has been around for 30 years and is basically the solution to an old problem – that of 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 some years now. Several attempts have been made to move away from it, including Boehm’s (1986) iterative style of development using a spiral model of planning, risk analysis, engineering and customer evaluation. Although excellent, the spiral model did not achieve the penetration in IT practices that it deserved. Gilb (1988) has been propounding evolutionary development for many years now, but he too seems to have been a voice in the wilderness. One explanation for the majority of IT solution providers not changing their development lifecycles could be that, until very recently, there has not been sufficient pressure from their customers.
The IT industry had become increasingly aware of RAD following Martin’s (1991) book, which gave some excellent pointers as to how to make RAD work but did not provide the total solution. There are many RAD tools on the market, but to use them often meant buying the vendor’s process as well. This was seen as a block to the growth of RAD by the founding members of the DSDM Consortium.
The Consortium was inaugurated in 1994 with the aim of producing a public-domain, commonly agreed method that would be tool independent. Ed Holt (now of SELECT Software Tools), who chaired the Consortium for the first two years, said that every organisation that bought a RAD tool really needed a new process. DSDM aims to provide that process for building and maintaining systems which meet tight time constraints in a controlled project environment. The Consortium had 17 founder members, who represented a mix of organisations that holds good today: large IT vendors, smaller tool vendors and user organisations of all sizes. The Consortium now has over 1000 members and is growing internationally.
Welcome back to Kaizenlog.com, you may want to subscribe to my RSS feed , Twitter You can contact us by using the contact form or submitting a comment. You can also share this post with your friends by clicking on the 'ShareThis' button above. Thanks for visiting!
Print This Post
Entries (RSS)