DSDM is about people, not tools. It is about truly understanding the needs of a business, delivering software solutions that work and delivering them as quickly and as cheaply as possible. The Dynamic Systems Development Method provides a framework of controls and best practice for Rapid Application Development. It was created by a consortium of organisations and it has been proved, since its publication in January 1995, to be extremely effective in delivering maintainable systems which match the needs of the business better than those produced using traditional lifecycles. This book, commissioned by the DSDM Consortium and written by the chairman of the Technical Committee which developed the method, explores the day-to-day realities of implementing the method. It is a practitioner's guide, dealing with issues such as how to get people from different disciplines to work together as a team, how to gain commitment and how to manage projects within normal business constraints. Do you want to cut the development time and increase the fitness-for-use of screen based business applications, by orders of magnitude? This book will enable those in organisations which develop or purchase tailored IT systems, to gain a clear understanding of the benefits of the incremental and iterative approach embodied in the DSDM.
"synopsis" may belong to another edition of this title.
Jennifer Stapleton, the editor of the book, has been Technical Director of the DSDM Consortium since its inception, and is also Director of Consulting at Empower Dynamics Limited. She is a Fellow of the British Computer Society and was its Technical Vice-President from 1996-2002. She became an independent consultant in 1996, and focuses on helping organisations to improve their processes in project delivery -- always with an eye to delivering real satisfaction for the end-user.
For 40 years the business community has looked to the automation of clerical processes both for efficiency and to gain elusive competitive advantage. In that period, information technology practitioners have consistently failed to deliver the necessary solutions on time, within budget, or to provide the functionality needed by the business.
It has taken us this amount of time to understand that business requirements change rapidly and are difficult to define, and that the people who understand business processes best are the people who use them day-by-day. We have seen that development projects can gain a life of their own, and become enmeshed in their own complexity, but we have learned that applications development is not a black art, and is amenable to structure and discipline.
During the last two decades of the twentieth century, a number of serious attempts have been made to understand the application development process and to codify ways in which these failures can be overcome. In 1994, information systems professionals in the UK from large and small organizations in a wide variety of industries, came together with consultants and project managers from some of the largest companies in the IT industry to form a not-for-profit consortium. This consortium is dedicated to understanding the best practice in application development and codifying it in a way that can be widely taught and implemented.
The result is DSDM (Dynamic Systems Development Method), a project delivery framework that truly serves the need of the business: DSDM projects deliver on time, to budget, and they don’t cut important corners. Everything in the published framework has resulted from practical experience and successful application by the membership. This strongly practical approach leads many people to view the framework as being ‘just common sense’, but it is apparent to anyone trying to control agile developments just how uncommon ‘common sense’ can be.
Today, the framework is being used on a wide variety of projects, small and large, simple and complex, IT and non-IT, in many countries, and the consortium continues its work to refine the content of the framework. For instance, in June 2001, the consortium issued a version of DSDM specifically aimed at e-business projects where all the reasons for delivering quality systems quickly are possibly even more important. The basic framework underwent a significant update in the summer of 2001 and an incremental improvement was made in January 2002.
Given that we are predominantly building business systems with some IT content, the philosophy behind DSDM is simple:
u Development is a team effort. It must combine the customers’ knowledge of the business requirements with the technical skills of IT professionals.
u High quality demands fitness for purpose as well technical robustness.
u Development can be incremental — not everything has to be delivered at once, and delivering something earlier is often more valuable than delivering everything later.
u 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 framework will not solve every project’s problems, but it will go a long way towards ensuring that the business gets the systems it needs in the twenty-first century.
What is DSDM?
The first questions to ask when coming to DSDM are what is it and why is it different? Despite its full name it is not a method in the accepted sense, but a framework of controls focused on delivering quickly, 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 approach that covers all aspects of system development from the first idea for a project up to the final removal of the project’s solution. It addresses the needs of all project participants: business management, project managers, solution architects, solution developers, solution users, 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 a fast-moving, business-centered environment.
The purpose of the framework is to achieve rapid time to market: building what the business needs, when it needs it. 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 allow for delivery of additional functionality later on.
A bit of history
Businesses are putting increasing pressures 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 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. 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 solutions 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 not 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 members who represented 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 experiences and best practices 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.
After Version 1 of the framework was published early in 1995, an Early Adopter Programme was put in place to monitor the use of the framework in practice. After feedback from the Early Adopters and the addition of material that had been deliberately left out of Version 1 to get the framework visible as soon as possible, Version 2 was published in November 1995. Following feedback from the wider use of the framework, Version 3 was published in August 1997. Up until 2001 additions to the framework came via UK government White Papers on topics as diverse as using DSDM in data warehousing, component-based development and prototyping business processes. In 2000, it became clear that there was a need for a version of DSDM that was less generic in its definitions and specifically aimed at e-business projects. The technical work of the consortium continues: it is still collecting feedback from users of the framework, and addresses particular needs as they arise through the production of White Papers. A recent White Paper covers the use of UML in DSDM projects.
To ensure that the framework is well understood and applied correctly, a training and examination process was launched alongside Version 1 and continues to evolve. At the time of writing, over 20,000 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 framework
The whole framework 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 DSDM is built and the other five provide the principles that have guided the structure of the framework.
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 co-operative 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 timescales required by the business.
The iterative and incremental process embodied in the fifth principle consists of five development phases. (There are two non-development phases: pre-project, which ensures that the project is set up on a sound basis, and post-project, which includes keeping the delivered solution operational.) The first two development phases are sequential: feasibility to assess the suitability of the system to the approach and to provide an initial view of the costs, etc., followed by the business study which builds the business and technical foundations of the rest of the project. After the business study, the first of the iterative phases is the functional model iteration in which the analysis started in the business study is done in more detail. The analysis is supported by evolutionary prototyping of functionality inside the system architecture that is also defined at a high level in the business study. When an area of functionality is well enough understood, the design and build iteration engineers the system component to sufficient quality to be delivered in the implementation phase. Implementation covers not only moving the system to the production environment but also training the users. At the end of implementation, the increment is reviewed and a business decision is made about what further work (if any) needs to be done in subsequent increments.
No process is complete without the people to enact it. The first principle states that the solution’s users must be closely involved throughout development: their regular input and feedback are essential to the framework. DSDM defines roles for the people involved in a DSDM project. These include both users and development staff. For example, one user role is that of Visionary. This is usually taken by the person who is responsible for getting the project started through their vision for IT support in the business area. A key IT role is that of Technical Co-ordinator, who is basically the system architect and keeper of the technical vision. The combination of these two roles ensures the business and technical foundations of the project are secure, but there are many more roles defined in both areas of specialism.
The aim of DSDM is to deliver systems to timescales that would be impossible using the waterfall approach. The impact is that the work processes have to be managed in a different way and the techniques used within those processes need to be honed down to reduce overheads as much as possible. The major instrument for controlling work is the timebox. The timebox in DSDM is a short period of time (a matter of days or a few weeks) within a project when something is produced to defined quality objectives, so satisfying the third, fourth, and eighth principles. By taking a product-based view rather...
"About this title" may belong to another edition of this title.
Book Description Addison-Wesley Professional, 1997. Hardcover. Book Condition: New. Never used!. Bookseller Inventory # P110201178893