DSDM

DSDM Public Version 4.2 Manual

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

2002-2008 DSDM Consortium

http://www.dsdm.org/version4/2/public/default.asp [12-1-2008 11:58:39]

DSDM Public Version 4.2 - Introduction

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

DSDM: Enabling Business Agility IntroductionWhat is DSDM?There is increasing pressure on organisations to deliver working systems to business in ever shorter timescales. The processes by which systems are developed need to be agile and deliver what the business needs when it needs it. DSDM is a framework based on best practice and lessons learnt since the early 1990's by DSDM Consortium members. It provides a flexible yet controlled process that can be used to deliver new systems, which combines the most effective use of people's knowledge, tools and techniques such as prototyping to achieve tight project delivery timescales. Typically, a DSDM project will deliver an operational system within six months. Time to market is of the essence in most organisations together with robust systems that do not damage their reputation, whether they operate in the public or private sector, in business, education, or any other sphere. DSDM has primarily been used as an approach for IT projects; however, it is appropriate to business change projects and programmes. Such projects may have a large amount of technology change or no technology element at all. The DSDM framework provides an ideal basis for an even-handed development and implementation process, which encompasses people (e.g. organisation, staff, skills and capabilities), the technology that supports them (e.g. IT, office automation and communications) and the processes that bind them all together (in line with the business strategy). DSDM is an essential tool to effectively:

understand plan communicate control deliver all projects (IT or Business Change).

DSDM and eXtreme Programming (XP)This version of DSDM contains guidance on how to use XP in conjunction with DSDM. Combining XP and DSDM produces a robust and rigorous hybrid that is scalable and sustainable for projects and organisations whether small, medium or large. This combination brings together the energy and invention of XP with the proven maturity and commercial know-how of DSDM. The inclusion of XP confirms the DSDM framework's position as a repository for system development best practice specifically in relation to the Agile Alliance and the Agile Manifesto and, furthermore, demonstrates how the DSDM Framework including the lifecycle is relevant for this type of development approach.

http://www.dsdm.org/version4/2/public/Introduction.asp (1 of 4) [11-1-2008 15:42:45]


Why use DSDM?DSDM is a vendor-independent framework that recognises that more projects fail because of people issues than technology. The focus is on helping people to work effectively together to achieve the business goals. DSDM is also tool and technique independent enabling it to be used in any business and technical environment without tying the method users to any particular vendor. Many system development projects fail to meet the expectations of the end users. Such project failures can be classified into one of five basic types: 1. The system fails to meet the business requirements for which it was developed. The system is either abandoned or expensive adaptive maintenance is undertaken. 2. There are performance shortcomings in the system, which make it inadequate for the users' needs. Again, it is either abandoned or amended incurring extra costs. 3. Errors appear in the developed system causing unexpected problems. Patches have to be applied at extra cost. 4. Users reject the imposition of the system, for political reasons, lack of involvement in its development or lack of commitment to it. 5. Systems are initially accepted but over time become impossible to maintain and so pass into disuse. DSDM aims to prevent all five types of project failure. A fundamental assumption of the DSDM approach is that nothing is built perfectly first time, but that 80% of the solution can be produced in 20% of the time that it would take to produce the total solution. A basic problem with less agile approaches is the expectation that potential system users can predict what all their requirements will be at some distant point in time. This problem is compounded by the fact that the mere existence of a new system affects the users' requirements because the methods of working have changed. In the classical, sequential (or "waterfall") approach, the next step cannot be started until the previous step is completed and fully tested. In practice, a lot of time is spent in getting from the 80% solution to the total solution, with the assumption that no step ever needs to be revisited. This means that considerable time is spent going back to "completed" steps and unravelling the defects from work that has previously been accepted. The result is that projects are delivered late and over budget or they fail to meet the business needs since time is not spent reworking the requirements. DSDM assumes that all previous steps can 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. The premise is that the business requirements are likely to change anyway as understanding increases, so any further work would have been wasted! Systems built using the DSDM approach address the current and imminent needs of the business rather than the traditional approach of attacking all the perceived possibilities. The resulting system is, therefore, expected to better fit to the true business needs, be easier to test and be more likely to be accepted into the users' working practices. Since the development cost of most applications is only a small part of the total lifecycle costs, it makes sense to build simpler systems that are fit for purpose and easier to maintain and modify after their initial development. The latter is possible since maintenance can be treated as a further incremental delivery towards the total solution. DSDM is not only about developing new systems. Enhancements to existing systems can be created using DSDM.



Why use DSDM and XP?There are a number of resistors to change that are experienced by XP practitioners, i.e. reasons why organisations do not immediately embrace the ideas of XP. For example:

XP is perceived as simply JDI (Just Do It) It's just too extreme for us to use here It's not scalable Its not maintainable.

Another reason to use DSDM and XP together is that they are synergistic, for example DSDM focuses on the whole lifecycle whereas XP is stronger on the detailed disciplines of programming. Combining XP with the rigorous yet Agile approach of the DSDM framework addresses the above issues through:

Recognised project governance Fundamental pre-coding activities Project risk management Recognition of technical and business organisational standards Team dynamics Team collaboration Extended roles and responsibilities Quality management above and beyond code quality

DSDM and project successDSDM aims not only to prevent failure but to bring success, by delivering systems that:

satisfy the real requirements of business, in order of importance support the way the business needs to work are delivered on time and within budget are delivered quickly, and yet are robust and right (e.g. the right functionality, performance, security and maintainability)

Systems built with DSDM are not developed quickly at the expense of quality. DSDM focuses on the priorities of the business and delivers what can safely be delivered within the time and cost constraints of the project, in priority order determined by the business needs and the objectives of the project.

Summary of the benefits of using DSDMUsing an iterative process based on prototyping, DSDM involves the end-users throughout the project lifecycle. This has many benefits, for example:

the users are more likely to claim ownership of the system the risk of building the wrong system is greatly reduced the final system is more likely to meet the users' real business requirements the users will be better trained, since their representatives will define and co-ordinate the training required implementation is more likely to go smoothly, because of the co-operation of all parties concerned throughout development.



What is in the Framework?This product provides a framework for development projects that encompasses all aspects for successful delivery: people, process and technology - with the emphasis on people, since more projects fail because of some people-based problem than for any other reason. The framework is based on nine Underlying Principles that enable projects to deliver what the organisation needs when it needs it. The framework defines a set of phases that any new/changing system (IT or business) will pass through - from initial identification of a problem or opportunity to be addressed through the development of the new/changed system to keeping the system operating successfully. These are described in the Process Overview. Various products are produced within each phase. These are defined to a level that enables them to be used in any development environment. As stated above, the people aspects are essential, so DSDM defines key roles and responsibilities for people working inside and alongside the development. Every project will have the need for management techniques to control the process, such as good project planning, risk management, quality management. DSDM provides guidance on management techniques focusing on aspects of control that are specific to fast-moving development work. The Management Techniques section covers all the essentials needed for a controlled and yet flexible approach. Management is not the complete answer, the people within a project will be carrying out various activities from identifying how to create the solution to the business problem or opportunity through building and testing the solution to putting it into operation. DSDM has several core Development Techniques that assist the project workers in these activities. DSDM recognises that every project is unique in some way. Hence, a list of factors to consider when starting a DSDM project are provided in the When to Use DSDM section together with a Suitability Risk/List for ascertaining early in the project what aspects may cause problems later. Moreover, projects come in all sizes and guises, so guidance on Tailoring DSDM for specific projects is also provided. Lastly for those organisations (or parts of organisations) that have never used DSDM before, guidance is provided about Introducing DSDM into an organisation. If you are intending to use DSDM external to your own organisation commercially you must be a Member of the DSDM Consortium and become a Licensed Reseller. Click here to find out about joining the Consortium.



DSDM Public Version 4.2 - What's New

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

How to use this siteIntroductionThe DSDM on-line manual can be read sequentially from start to finish by following the "Next" links on each page (at the top and bottom right). You can also browse each section from the menus at the top, or get to the full site map at any time using the manual logo at the top left. For those who need a different route, this section helps you to find the best path through the manual. The routes are provided from four perspectives:

Someone new to DSDM and needing a broad understanding of what is in DSDM, why it is the way it is and how it works before going into the detail Someone who has just been assigned to a DSDM project, knows the DSDM role that they will hold and wants to know what this means for them Someone familiar with DSDM in previous versions Someone who understands this version of DSDM.

New to DSDM?For quick understanding of the basics of DSDM:

How the Process Works explains some of the important techniques of DSDM projects. The Process Overview describes the phases that a DSDM project goes through. The Underlying Principles show the basic philosophy that guides all DSDM projects. The People Overview covers the DSDM roles and how they work together - in line with the principles.

After reading these, depending on your personal interest, look at the Management Techniques Overview, the Development Techniques Overview and the Products Overview to gain an understanding of what DSDM contains. The When to Use section will be essential reading when you are considering using DSDM on a particular project. If DSDM has not been used in your organisation before, read the guidance on Introducing DSDM into an Organisation.

Just been assigned a DSDM role?Go to the People Overview and select the role from the list. This will take you to a description of the the role and its activities and responsibilities throughout the project. Links to other parts of the DSDM manual are supplied from the role description.

Familiar with DSDM in previous versions?Read What's New in Version 4.2 Use the Site Map to find what you are looking for.

http://www.dsdm.org/version4/2/public/how_to_use_site.asp (1 of 2) [12-1-2008 12:09:27]

DSDM Public Version 4.2 - What's New

Familiar with DSDM Version 4.2?Use the Site Map to find what you are looking for.


http://www.dsdm.org/version4/2/public/how_to_use_site.asp (2 of 2) [12-1-2008 12:09:27]

DSDM Public Versionl 4.2 - Overview

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

Process OverviewIntroductionIn line with the fifth underlying principle, the project lifecycle that DSDM uses is iterative and incremental. So the computer system may not be delivered to the business in one go, but in a series of increments, which increase what it does each time. In this way, urgent business needs can be addressed early while less immediately important functionality is delivered later. The iterative nature of DSDM enables users to see work under construction, comment on it and request changes during the development of an increment. The lifecycle description below is not the whole picture; How the Process Works provides an overview of key techniques used within DSDM to ensure successful delivery on time.

DSDM is more a framework than a method. It does not say how things should be done in detail, but provides a skeleton process and product descriptions that are to be tailored to suit a particular project or a particular organisation. The project process, as shown in the figure above, has five phases: Feasibility Study, Business Study, Functional Model Iteration, Design and Build Iteration and finally Implementation in the working environment. These are preceded by the Pre-Project phase and end with the Post-Project phase. The Feasibility and Business Studies are done sequentially. They set the ground rules for the rest of development that is iterative and incremental and therefore they must be completed before any further work is carried out on a given project. How the three later phases overlap and merge is left to a particular project to decide. This will depend on several things, primarily the nature of the system under construction and the tools being used to develop it. After the project has delivered the solution to the business problem or opportunity, the project team is disbanded and the PostProject phase comes into play: this covers activities such as keeping the solution operating effectively and checking that the expected business benefits have been achieved. Each phase of the process has a minimum set of products emanating from it. Each of the products has a defined purpose and a set of quality criteria by which achievement of that purpose can be assessed. How the products will be produced and what they will contain is left to the individual organisation or project to decide.

http://www.dsdm.org/version4/2/public/Overview_of_DSDM.asp (1 of 4) [11-1-2008 15:45:05]


Pre-ProjectThe Pre-Project phase ensures that only the 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 StudyAn important aspect of the Feasibility Study is the assessment of whether DSDM is the right approach for the project. The normal considerations in a Feasibility Study are also present, such as a definition of the problem to be addressed together with assessments of the likely costs and of the technical feasibility of delivering a computer system to solve the business problem. Given that DSDM is to be used for the development of systems that are needed urgently, the Feasibility Study is necessarily short, and should last no more than a few weeks. This may have an impact on an organisation's standards for an acceptable Feasibility Report. There is not sufficient time in DSDM projects to produce large documents unless they are absolutely necessary. Therefore the Feasibility Report will cover all the usual topics but not in great detail. The DSDM philosophy is to do enough and no more. As well as a Feasibility Report, there are two other products from the Feasibility Study. Both are produced to support the conclusions of the Feasibility Report. The first is an Outline Plan for development, which will add weight to the findings that the desired outcome is achievable and the second is a Feasibility Prototype. The prototype is an optional product to demonstrate that a solution is possible. It may not be a piece of software: it could be document-based.

The Business StudyHaving decided in the Feasibility Study that DSDM is indeed the way to go, the Business Study provides the basis for all subsequent work. Like the Feasibility Study, it is as short as possible (the duration measured in weeks rather than months), while achieving sufficient understanding of the business requirements and technical constraints to move forward with safety. As its name suggests the prime focus of attention is on the business processes affected and their information needs. The short timescales of a DSDM project mean that this activity has to be very strongly collaborative, using a series of facilitated workshops of knowledgeable staff who can quickly pool their knowledge and gain consensus as to the priorities of the development. The result of these workshops will be the Business Area Definition which will not only identify the business processes and associated information but also the classes (or types) of users who will be affected in any way by the introduction of the system. From these user classes, the individuals who will participate in the development will be identified and agreement reached with their management as to their involvement. The key users in a DSDM project are the Ambassador Users. Ambassador Users are so called because they operate in the same way as diplomatic ambassadors. They reside temporarily in the project team and provide a two-way channel of communication between the business and development communities. Their presence is essential to the success of a DSDM project. They are not only responsible for providing information to the project, but also for ensuring that the wider business community is kept up-to-date with progress. All key project roles in DSDM (including the Ambassador User role) have clearly defined responsibilities, since DSDM's strength is in helping people to work effectively together. Each of the requirements identified during the Feasibility and Business Studies has to be prioritised and recorded in the Prioritised Requirements List so that the most important features will be developed in preference to less essential parts that can be added later if required. The prioritisation will principally be led by business need but will also take into account the technical constraints which may drive some requirement to be satisfied first even though it may be less important in business terms. Some nonfunctional requirements, such as security, may also affect the prioritisation. Because parts of the software will begin to be produced in the next phase (the Functional Model Iteration), it is not only important to understand the functionality to be developed but also the system architecture that will be used. So another product from the Business Study is the System Architecture Definition, which describes the development and operational platforms as well as the architecture of the software to be developed in terms of its major components and their interfaces. As with everything else produced during the Business Study, the System Architecture Definition will be refined during later work and may change as the project progresses. Last but not least, the Outline Plan produced as part of the Feasibility Study is refined to produce the Development Plan. This provides the detail of how development will be carried out during the Functional Model Iteration and Design and Build Iteration phases using techniques such as modelling and prototyping. It will also include how the activities and products are checked and controlled as they are developed through timeboxing, risk management, configuration management, quality management and testing.



Functional Model IterationThe focus of Functional Model Iteration is on refining the business-based aspects of the computer system, i.e. building on the highlevel processing and information requirements identified during the Business Study. To this end both standard analysis models and software are produced. Both the Functional Model Iteration and the Design and Build Iteration consist of cycles of four activities: 1. 2. 3. 4. Identify what is to be produced. Agree how and when to do it. Create the product. Check that it has been produced correctly (by reviewing documents, demonstrating a prototype or testing part of the software).

The Functional Model that is built up in these cycles consists both of analysis models and of software components, which contain the major functionality and will satisfy some of the non-functional requirements, particularly the requirements relating to ease of use. The software parts of the Functional Model are tested as they are produced. This includes technical unit testing, but should also include as many other classes of testing as possible including mini-acceptance tests by the Ambassador Users as soon as new components are available. The focus of testing in the Functional Model is necessarily on what the components do (however limited that is) and whether or not they form the basis of a usable set of functionality. Non-functional aspects such as performance are tested in the Design and Build Iteration. This gives rise to the backwards arrow in the process diagram above from the Design and Build Iteration to the Functional Model Iteration. Any non-functional requirements not captured already should be captured during the Functional Model Iteration ready for the Design and Build Iteration. It will often be easier, and indeed more sensible, to address the detail of an area of functionality together with its non-functional aspects in one chunk before addressing the detail of another area. The extent to which the Functional Model Iteration and Design and Build Iteration merge, overlap and move backwards and forwards between each other will depend largely on how the application being built can be partitioned into smaller functioning areas and the facilities of the development environment. The preconditions for moving from functional modelling to design and build include agreement of a Functional Prototype that may or may not be fully automated. The Functional Prototype may be for only part of the Functional Model. This means that design and build activities may happen concurrently with the functional prototyping activities. Similarly, in a large DSDM project, the subsequent Implementation may be phased, so design and build may be concurrent with some implementation.

Design and Build IterationThe Design and Build Iteration is where the computer system is engineered to a sufficiently high standard to be safely placed in the hands of the users. The major product here is the Tested System. The DSDM process diagram does not show testing as a distinct activity because testing is happening throughout both the Functional Model Iteration and the Design and Build Iteration. Some environments or contractual arrangements will require separate testing phases to be included at the end of the development of the increment, but this should not be the major activity encountered in more traditional approaches to development. Testing is just as important in DSDM and consumes just as much effort, but it is spread throughout development. The Tested System will not necessarily satisfy all the identified requirements, but it will satisfy all the requirements that have been agreed for the current increment. Due to the time constraints, some lesser parts of the system will have been agreed to be left to a later date. However, the core of requirements (what DSDM calls the minimum usable subset) will be contained in the Tested System, with as many other parts as time allows.

ImplementationThe Implementation phase covers the cutover from the development environment to the operational environment. This includes training the users who have not been part of the project team. Iteration of the Implementation phase is applicable when the system is being delivered to a dispersed user population over a period of time. The products of this phase include the Delivered System that contains all the agreed documentation, including the User Documentation. The User Documentation is completed in this phase but must have been started earlier during the Design and Build Iteration. One of the responsibilities of the Ambassador Users is to ensure the correct production of the User Documentation and training, thus ensuring that the correct perspective is present.



The other product of this phase is the Increment Review Document. This is produced immediately the computer system or increment is deemed complete. The Increment Review Document is used to summarise what the project has achieved in terms of its short-term objectives. In particular, it reviews all the requirements that have been identified during development and assesses the position of the system in relation to those requirements. There are four possible outcomes (three of which are shown by returning arrows on the DSDM process diagram above). The four outcomes are:

All requirements have been satisfied. Hence, no further work is currently needed - and no returning arrow. A major area of functionality was discovered during development that had to be ignored for the time being in order to deliver on the required date. This means returning to the Business Study and taking the process on from there. Lower priority functionality, which was known, had to be left out because of the timescale. This is now to be added, so the process returns to the Functional Model Iteration. An area of lesser technical concern was omitted again due to time pressure, but can now be addressed by returning to the Design and Build Iteration.

Post-ProjectThe Post-Project phase keeps the solution operating effectively. The iterative and incremental nature of DSDM means that maintenance can be viewed as continuing development. Maintenance is an expected part of a system's lifecycle, which can be accommodated using much the same approach as the initial development. Non-urgent fixes and enhancements may be batched up and implemented using DSDM techniques. This work should follow the DSDM principles with a high level of user involvement and should be treated as further iterations of the system, going round the DSDM method again starting with a quick pass through the Business Study.



DSDM Public Version 4.2 - How the Process Works

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

How the Process WorksIntroductionThe five most important factors to for a successful DSDM project are strong user participation in the development activities, timeboxing, requirements prioritisation, facilitated workshops and prototyping. How these make the process work are covered in this section.

Flexing requirementsThe four possible outcomes described at the end of description of the Implementation phase in the Process Overview are a clear demonstration of the major difference between DSDM and traditional approaches to software development. Traditionally, requirements are fixed and software is delivered which satisfies all of them. To achieve this, time and resources vary during development. In DSDM, the exact opposite is true, time is fixed for the life of a project, and resources are fixed as far as possible, but the requirements that will be satisfied are allowed to change. Hence there is a need to prioritise requirements as they are elicited during the Business Study and refined during the lifecycle.

The flexibility of requirements to be satisfied has significant impact on the development processes and controls, and on acceptance of the system. One of the nine underlying principles of DSDM is that fitness for business purpose is the essential criterion for the acceptance of deliverables. This moves away from the approach of satisfying all the "bells and whistles" in a requirements specification, while maintaining a qualityoriented approach to development. The basic mechanism for handling flexibility of requirements in DSDM is timeboxing. A timebox is a simple concept: a period of time with a fixed completion date. DSDM refines the concept of timeboxing by nesting shorter timeboxes within the higher-level timebox that delivers an operational solution. It is these nested timeboxes that demonstrate progress and also drive the project forward. Fixing completion dates will not work on its own. Clear but negotiable prioritisation of what must be achieved within the timebox is also required. DSDM applies the MoSCoW rules for prioritising the requirements addressed by each timebox to ensure that what is delivered now will satisfy the immediate business needs. Timeboxing as a milestone-to-milestone process is really key and can work wonders even if when it isn't done very well. No other method exists with such a well-defined process for milestone-to-milestone work.

http://www.dsdm.org/version4/2/public/How_Process_Works.asp (1 of 3) [11-1-2008 15:45:40]


Communication channelsDSDM is above all about improving the communication channels between the various stakeholders and the project team. One of the most effective mechanisms for improving communications is the facilitated workshop. This is used throughout DSDM to ensure that the project works quickly towards the best solution for all concerned. DSDM also achieves delivery to tight timescales through shortening communication lines between users and IT staff within the project, between analysts and designers, between team members, and between differing levels of management. The mechanisms by which these communication lines are shortened differ from one channel to another. In particular, the communication between developers and users is eased by the use of prototyping rather than the production of lengthy documents. This is why DSDM defines a Functional Model rather than a functional specification.

Documents in DSDMDSDM incorporates an approach for defining what the necessary documentation set will be for a given project. Much of the documentation that is traditionally produced is for the transfer of ideas from one developer to another or from the developers to the users. By keeping mixed user/developer teams small and constant throughout development, DSDM renders such documents largely unnecessary. For the management documentation, local practices should be followed but perhaps scaled down to minimise unnecessary barriers to rapid movement through the project. On the technical side, DSDM provides guidance on how to decide what sort of documentation it is necessary to control and why. The basic criterion for deciding to control a technical document is that it is either essential to the developers' progress to implementation or it is required for maintenance purposes. When the documentation that is often required to be delivered is compared with the documentation that is actually useful after delivery, there is quite a wide gap. DSDM's focus on doing the minimum necessary for safety is one of the ways that systems can be delivered faster and yet meet their quality objectives. Some documents may be required for audit purposes. A question that is often asked is "How much documentation is enough?" Enough can be defined as when any extra documentation will not add to the understanding of what is being built. For example, in traditional projects, a lot of effort is devoted to writing, reviewing, agreeing and maintaining a detailed requirements specification, which often has zero value in the longer term.

People, Process and TechnologyThe DSDM approach views people, process and technology, as the intertwined components of any business solution. Changes to one component will impact the others. A business change project must include and manage all three aspects. The basic approach to providing business solutions should be:

understanding the business objectives re-engineering business processes and aligning people and technology to achieve the objectives.



Whilst the standard DSDM lifecycle does not expressly encompass strategic business planning methods, the approach assumes that a business strategy exists and that it both influences the DSDM project, and is influenced by it. A feedback mechanism should be established to facilitate this.



DSDM Public Version 4.2 - Principles

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

Underlying PrinciplesThe following principles are the foundations on which DSDM is based. Each one of the principles is applied as appropriate in the various parts of the method.

I.

Active user involvement is imperative

DSDM is a user-centred approach. If users are not closely involved throughout the development lifecycle, delays will occur as decisions are made and users may feel that the final solution is imposed by the developers and/or their own management. Users are not outside the development team acting as suppliers of information and reviewers of results but are active participants in the development process.DSDM teams consist of both developers and users. They must be able to make decisions as requirements are refined and possibly changed. They must be able to agree that certain levels of functionality, usability, etc. are acceptable without frequent recourse to higher-level management.

II.

DSDM teams must be empowered to make decisions

III.

The focus is on frequent delivery of products

A product-based approach is more flexible than an activity-based one. The work of a DSDM team is concentrated on products that can be delivered in an agreed period of time. This enables the team to select the best approach to achieving the products required in the time available. By keeping each period of time short, the team can easily decide which activities are necessary and sufficient to achieve the right products. Note: Products include interim development products, not just delivered solutions.

IV.

Fitness for business purpose is the essential criterion for acceptance of deliverables

The focus of DSDM is on delivering the necessary functionality at the required time. The computer system can be more rigorously engineered later if such an approach is acceptable. Traditionally the focus has been on satisfying the contents of a requirements document and conforming to previous deliverables, even though the requirements are often inaccurate, the previous deliverables may be flawed and the business needs may have changed since the start of the project.

http://www.dsdm.org/version4/2/public/Principles.asp (1 of 3) [11-1-2008 15:46:20]


V.

Iterative and incremental development is necessary to converge on an accurate business solution

DSDM allows systems to grow incrementally. Therefore the developers can make full use of feedback from the users. Moreover partial solutions can be delivered to satisfy immediate business needs. Iteration is inherent in all software development. DSDM recognises this and, by making it explicit, uses iteration to continuously improve the system being developed. When rework is not explicitly recognised in a development lifecycle, the return to previously "completed" work is surrounded by controlling procedures that slow development down. Since rework is built into the DSDM process, the development can proceed more quickly during iteration.

VI.

All changes during development are reversible

To control the evolution of all products (documents, software, test products, etc.), everything must be in a known state at all times. This means that configuration management must be all-pervasive. Backtracking is a feature of DSDM. However in some circumstances it may be easier to reconstruct than to backtrack. This depends on the nature of the change and the environment in which it was made. The ability to reverse changes is limited to within the development of an increment.

VII. Requirements are baselined at a high level

Baselining high-level requirements means "freezing" and agreeing the purpose and scope of the system at a level that allows for detailed investigation of what the requirements imply. Further, more detailed baselines can be established later in the development, although the scope should not change significantly. Changing the scope defined in the baselined high-level requirements usually requires escalation.

VIII. Testing is integrated throughout the lifecycle

Testing is not treated as a separate activity. As the system is developed incrementally, it is also tested and reviewed by both developers and users incrementally to ensure that the development is moving forward not only in the right business direction but is technically sound. Early in DSDM, the testing focus is on validation against the business needs and priorities. Towards the end of a project, the focus is on verifying that the whole system operates effectively.



IX. A collaborative and co-operative approach between all stakeholders is essential

The nature of DSDM projects means that low-level requirements are not necessarily fixed when the developers are originally approached to carry out the work. Hence the short-term direction that a project takes must be quickly decided without recourse to restrictive change control procedures. The stakeholders include not only the business and development staff within the project, but also other staff such as Service Delivery or resource managers. When development is procured from an external supplier, both the vendor and the purchaser organisations should aim for as efficient a process as possible while allowing for flexibility during both the precontract phase and when the contracted work is carried out.



DSDM Public Version 4.2 - When to Use DSDM

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

When to Use DSDMAssessing the risksThe decision as to whether or not to use DSDM is an important one to be made at the outset of a development project. Some projects are clearly ideal for DSDM. Others require careful consideration to decide whether the use of DSDM will provide business benefits. To assist management in assessing the risks associated with a given project, DSDM provides a risk identification tool the Suitability/Risk List. The list considers the critical success factors for DSDM and characteristics of projects that are especially effective for DSDM. Each potential project should be judged individually using the risk list. If the project provides a good match against the list, then DSDM can be considered a very appropriate development approach. However inability to satisfy all of the criteria does not automatically prohibit the use of DSDM. However, it will be necessary for risk management strategies to be developed to address any non-compliance. The criteria included within the DSDM Suitability/Risk List are intended as guidance material only and should not be considered exclusive. It is expected that an organisation using DSDM will enhance the list with their own specific factors identified from experience of using the method within their environment. The choice of DSDM as the development method should be carefully monitored during the early stages of the project. If it becomes apparent that the system does not clearly demonstrate all of the expected characteristics and yet the use of DSDM will still provide benefit, then again it is important that risk management strategies are developed to address the problem areas.

When to use DSDM and XPThis version of DSDM incorporates certain Extreme Programming (XP) techniques within the DSDM framework. The Suitability/Risk List has been extended so that it can be used to assess the risks of using DSDM and XP together. This has been done by including new questions specifically aimed at XP. If the project provides a good match against the list, then the combination of DSDM and XP can be considered an appropriate development approach. However failure to satisfy all of the criteria does not automatically prohibit the use of XP with DSDM but it will be necessary for risk management strategies to be developed to address any non-compliance. Further guidance is provided throughout the manual in the form of "Guidance for those looking to use XP with DSDM".

Characteristics of systems where DSDM should be the Framework of choiceIn addition to considering the critical success factors, DSDM will be especially effective for systems that demonstrate the following characteristics:

interactive, where the functionality is clearly demonstrable at the user interface. DSDM is strongly based on incremental prototyping with close user involvement. Therefore users must be able to assess the functionality easily through viewing and operating working prototypes. Hence the need for demonstrable functionality. The user interface includes screens, reports and file-prints (where file-prints may be solely for interim demonstration and verification of the functionality). If the user interface is not highly demonstrable, there must some other way that users can verify that partially built solutions are correct. This characteristic relates in part to Principles I and IV.

has a clearly defined user group. If the user group is not clearly defined, there may be a danger of driving the development from a wrong viewpoint or (worse) ignoring some important aspect of the project entirely. This characteristic relates to Principle I.

http://www.dsdm.org/version4/2/public/When_to_Use.asp (1 of 3) [11-1-2008 15:48:33]


if computationally complex, the complexity can be decomposed or isolated. If the internals of the system are hard to understand via the user interface then there is a risk. The level of computational complexity is often quite difficult to determine in advance and will vary from one project to another. Moreover there can be interactions between different components, which can be difficult to identify up front. DSDM can be used where there is a great deal of computational complexity provided that the application can be decomposed to reduce the complexity. For instance, if an application requires some complex statistical modelling, a project may consider two approaches to development: using existing, well-tested statistical modelling components or developing the models from scratch. The first would be totally acceptable in a DSDM project. The second would require care in the use of the method, unless it is possible either to decompose the complexity into simpler components or to make it transparent at the user interface. If there is complexity but it can be isolated from the rest of the computer system, then it can be handled in a more formal manner and re-integrated later. This characteristic relates in part to Principle V.

if large, possesses the capability of being split into smaller functional components. If the proposed computer system is large it should be possible to break it down into small, manageable chunks, each delivering some clear functionality. These can then be delivered sequentially or in parallel. Indeed, some of the functionality may be delivered using traditional waterfall methods. However, each sub-project must be constantly aware of the overall system architecture. Indeed, all aspects of the project must be controlled and co-ordinated. Note: When DSDM teams are working in parallel on a project, the number of teams should be minimised, without exceeding DSDM's recommended maximum team size. This will aid the overall control of the project and minimise the integration overheads. The task of managing and co-ordinating timeboxes should not be underestimated. This characteristic relates in part to Principles III and IV.

time-constrained. There should be a fixed end date by which the project must be completed. If there is no real case for the end date to be fixed, it will be relatively easy to allow schedules to slip and the fundamental benefits of DSDM will be lost. The time constraint is usually defined by the business objectives but could also be due to the availability of IT staff within a defined timescale, the imminent removal of support for old technologies, etc. This characteristic relates in part to Principle III.

the requirements can be prioritised. The requirements should be prioritised using the MoSCoW rules. Note: If the requirements have already been written before the decision to use DSDM is taken, then it will be necessary to gain acceptance from the "owner" of the project for the requirements to be variable, and to revisit them using the MoSCoW rules. This characteristic relates in part to Principle VII.

the requirements are unclear or subject to frequent change. In periods of rapid change it may be difficult to specify the requirements in detail at the outset of the project. This makes traditional approaches unsuitable. DSDM is designed specifically to deal with requirements that change and evolve during a project. Many applications are difficult to specify in advance because the users do not know exactly what is needed at the outset. Examples include when a business process is being redesigned and when new products and services are being built. DSDM is well suited to building such applications because it enables users to change their minds as development proceeds. This characteristic is really checking whether or not there is anything of significance to discuss with the users during development. If the detail of the requirements for the system is clearly understood, there will be less ability to save time through prototyping with the users for requirements elicitation. If they are all fixed there will be less ability to allow some requirements to be left to later developments in order to meet the timescales required. This characteristic relates to Principles V and VI.



Characteristics of systems where special care is needed in applying DSDMMany systems may appear not to demonstrate compliance with the critical success factors and the required characteristics. However, if the development support environment is strong enough and the development team is experienced in the DSDM approach, benefits can be gained by using DSDM techniques where appropriate. There are some systems where using DSDM will need special care. Such systems will display one or more of the following characteristics.

process control/real-time applications. Much of the processing of process control/real-time applications (e. g. systems that control manufacturing equipment, power plants or weaponry) is not visible at the user interface, is often very complex and cannot be decomposed into smaller components. In addition, extensive validation and verification is frequently needed. For these reasons DSDM would normally be considered unsuitable for such applications. requirements have to be fully specified before any programs are written. In some projects, it may be demanded or considered essential that the requirements be fully specified and approved before programming takes place. The attempted use of DSDM in this situation could be disastrous. DSDM is an iterative approach and the momentum and synergy of the DSDM project team would be seriously affected by defining all requirements in advance. Time delays in the project would inevitably occur while waiting for all the requirements to be defined, the value of business knowledge within the project team will diminish and senior management might seriously question the credibility of DSDM as a rapid development approach. Techniques such as facilitated workshops might still be useful for defining requirements but it is unlikely that full DSDM could be used. safety-critical applications. As well as the need for detailed specifications, the exhaustive validation and verification activities required for safety-critical systems (i.e. systems that can endanger lives) make it unlikely that they will be suitable for the iterative development approach of DSDM. It should be noted that safety-critical systems have been developed using DSDM. In this sort of project, the skill and experience of the Technical Co-ordinator will be a critical factor in ensuring success.

delivering re-usable components. Projects may be required to produce re-usable components. Such components must be exactly right. Generally, the speedy delivery of business benefits and the creation of reusable components are two contradicting goals, with different sponsors. As you cannot have two sponsors, satisfy the business-benefit goal first, then move on to the second. That said, DSDM will be very suitable if the re-usable components are highly modular and can be built incrementally without prejudicing the rest of the application.



DSDM Public Version 4.2 - Critical Success Factors

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

Critical Success FactorsThe critical success factors for DSDM are: 1. acceptance of the DSDM philosophy before starting work. It is important that the sponsor/senior management understands and accepts the DSDM philosophy. This includes the concept that delivering less than everything is agreed by all parties. Furthermore, as work continues ongoing agreement to the DSDM philosophy is essential. This CSF relates to all the underlying principles of DSDM 2. the decision-making powers of the business people and developers in the development team. The senior business management must either agree to delegate decision-making to the business representatives in the development team or to participate in the team themselves, otherwise progress will slow down while awaiting decisions to be made elsewhere. Junior business staff should feel able to make decisions without referral to higher authorities outside the team. Similarly, the developers in the team should also be empowered to make decisions, for example regarding technical feasibility. Checking empowerment involves ensuring that the people concerned are willing to take on the responsibility, as well their managers being willing to delegate it. This CSF relates to Principle II. 3. the commitment of senior business management to provide significant end-user involvement. The business commitment and agreed participation is absolutely key. If this commitment is not achieved by the end of the DSDM Feasibility Study, DSDM should be abandoned in favour of a more traditional approach. This CSF relates to Principle I. 4. incremental delivery. The organisation should be amenable to the delivery of systems in an incremental fashion. This applies to both the business and the development side of the project. For instance, the business areas will need to handle incremental system growth, retraining, etc. and the developers will need good configuration management procedures that will not slow down the process of delivery This CSF relates to Principles III and V. 5. easy access by developers to end-users. Ideally the developers and end-users will be collocated in their own dedicated environment, free from daily interruptions. However, the ideal is not essential as long as contact is continual and frequent throughout the project. This CSF relates to Principle I and IX. 6. the stability of the team. Due to the overlapping development skills required (i.e. strong interaction throughout between business analysts, system designers and programmers) and the speed of development, the project will be put at risk if staff are swapped in and out. Of course, specialists can be called in as required to support a team, but core teams should be constant throughout. In organisations that have specialist groups (e.g. business analysts) responsible for certain areas of the development lifecycle, which then pass their products to the next group in the sequence, the recommended approach is to structure project teams the way DSDM describes. If this is deemed impossible, extra care needs to be taken to ensure smooth transition if the stable team cannot possibly be achieved. This CSF relates in part to Principle IX. 7. the development team skills. The team(s) must contain highly skilled people in terms of both the business area as well as the technical environment. This does not mean that everybody needs to be a multi-skilled expert but that all the core skills for the project must be present in the team. All team members should demonstrate good interpersonal skills. This CSF relates in part to Principle IX 8. the size of the development team. Each DSDM team within the project should be small in order to minimise the overheads of management and communication, while optimising ownership. The team headcount includes both Developers and Ambassador Users. DSDM advises no more than six full-time team members per team.

http://www.dsdm.org/version4/2/public/CSFs.asp (1 of 2) [11-1-2008 15:48:48]

DSDM Public Version 4.2 - Critical Success Factors

Note: One project can have many DSDM teams. 9. a supportive commercial relationship. Where developers and business people are from different organisations and the development is covered by formal contract or where developers are from the same organisation but working within a service level agreement, the relationship must accommodate the evolution of the system's requirements without imposing onerous change management overheads. This CSF relates to Principle IX. 10. the development technology. The development technology should be suitable for the DSDM approach. It needs to allow for iterative development, demonstrable work products, and control of versions. Ideally code construction should be rapid and easily testable.


http://www.dsdm.org/version4/2/public/CSFs.asp (2 of 2) [11-1-2008 15:48:48]

DSDM Public Version 4.2 - DSDM Suitability/Risk List

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

DSDM Suitability/Risk ListObjectives of the Suitability/Risk ListThe Suitability/Risk List consists of a set of criteria for helping the DSDM practitioner to determine the risks that need to be addressed when applying the DSDM approach. The criteria are based on the DSDM critical success factors and other project situational factors. These are both explained in When to Use DSDM. The criteria are intended as guidance material only and are not considered to be fully comprehensive. Moreover as the experience of using DSDM grows within an organisation, the list should be refined and expanded to fit with local constraints and practices. Note: It is not necessary to be able to provide a positive response to each of the criteria: a negative response identifies a risk to be managed as defined in the section on Risk Management. A table of additional risk-related questions is also provided. Again, there is no right or wrong answer but their impact on the project needs to be assessed.

Suitability/Risk List OutputUpon completion of the Suitability/Risk List, the DSDM practitioner will advise whether the project under consideration should run under full DSDM, and if not, which techniques are appropriate to the project. Where the proposed project team members are inexperienced with the use of DSDM, a very high level of positive answers in the first table is advisable.

Risk Factor1. 2. Does the sponsor/senior management understand and accept the DSDM philosophy? Will the team members be empowered to make decisions on behalf of their communities? Is there senior user commitment to provide end user involvement?

Suitable (Y/N)

CommentsBuy-in to the approach is essential. An essential feature for DSDM.

3.

Identify whether there is a clearly defined and empowered user group and the commitment for them to be fully involved in the development process. Configuration and Release Management procedures are required. The business areas will need to have incremental training, etc. Do they need to collocate or will a lower level of involvement be sufficient? The stability of the team including the user representatives is important. These include technical skills, knowledge of the business area and interpersonal skills. Teams should contain no more than six people including users. Between the IT development staff and the users and between the organisation / project team and third parties. The development platform needs to allow for iterative and where necessary reversible development.

4.

Can the organisation accommodate the frequent delivery of increments? Will it be possible for the developers to have access to the users throughout the project? Will the development team(s) remain the same throughout the project? Will the development team have the appropriate skills? Will the individual development teams consist of six people or less? Is there a supportive commercial relationship?

5. 6. 7. 8. 9.

10. Will the project use technology suitable for prototyping?

http://www.dsdm.org/version4/2/public/Suitability_Risk.asp (1 of 3) [11-1-2008 15:49:01]


11. Is there a highly demonstrable user interface? 12. Is there clear ownership?

Screens, reports, file prints etc. Is there a champion who will progress political issues and ensure resources are provided? Is there a clearly defined user group? The more complex the development the greater the risks involved. 80:20 solution, i.e. releases deliver some benefits early. If large, it possesses the capability of being split into smaller components. Is the solution needed quickly? Is it business critical? Can the MoSCoW rules be applied? Cannot only have "must haves". Will users be able to define requirements interactively?

13. Will the development be computationally noncomplex? 14. Can the solution be developed in increments if required?

15. Has the development a fixed timescale? 16. Can the requirements be prioritised? 17. Are the requirements not too detailed and fixed?

Additional QuestionsConsider and assign a risk level What work has already been done to define the requirements? What is the status of the business case? What resources (e.g. people, accommodation) have been allocated to the project? Who are the likely suppliers of development resource for the project? What is the estimated cost of the project? What are the estimated business benefits for the project? Is there any previous experience in this type of project? Could the project efficiently reuse (e.g. software components, business process, and experience) from other projects? Does the project conform to architectural guidelines (technical and business)? Will the project call for the use of technology that has not been used before? Will the project require changes on interfaces to other systems? Will the project require changes to other systems? Will database design be a substantial part of the project? Will a lot of infrastructure be required? (e.g. hardware and training) Are there any supplier issues e.g. long lead times? Are there any Industrial Relations issues? Is this project part of a larger programme? How onerous are the non-functional requirements?

Risk LevelHigh Medium Low



Additional Questions when considering the use of XP with DSDMRisk Factor1. Does the organisation intend cherry picking certain XP practices?

Suitable (Y/N)

CommentsXP is a synergistic approach and choosing the wrong set of practices can easily create serious problems e.g. refactoring without test driven development. Pair programming has been empirically shown to be more productive that solo programming due to the increase in quality of the solutions. Refactoring is a practice that is an essential programming skill for any development approach but is particularly important to XP. A key consideration is the teams empowerment to refactor as required. User stories are the XP mechanism for capturing user requirements. They can often be derived from other sources e.g. Use Cases. XP is a synergistic approach. Care should be taken when adapting XP to existing organisational standards. Automated testing is key to XP. You may need to plan to build or buy a test framework or harness as part of your project. Continuous integration is vital to creating the development feedback XP needs and also ensuring that there is always a working copy of software ready for the customer. XP creates an emergent design that requires that all teams can evolve the code. The risk brought about by this approach is is mitigated by the use of Test Driven Development and Automated Acceptance tests.

2. Does the organisation accept the concept of Pair Programming?

3. Is refactoring acceptable to the organisation?

4. Is the organisation welcoming to the use of user stories?

5. Does this approach conflict with any of the existing organisation standards? 6. Does this approach require the implementation of automated testing tools/suite?

7. Does testing and/or development support continuous integration?

8. Does the organisation culture support collective code ownership?



DSDM Public Version 4.2 - Lifecycle Introduction

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

Lifecycle OverviewDSDM provides a project lifecycle as well as a system lifecycle. Development projects are not the full story in the life of system. There are activities that occur before a project even starts and after it has completed, i.e. once a system is in use. These are contained in the following DSDM phases:

Pre-Project Post-Project

The project lifecycle is illustrated below.

The project lifecycle is not mandated and is expected be tailored to meet the requirements of a particular project, hence it is called the development process framework. The development process framework is based mainly on Principles I, III, V and VIII. There are five project phases within DSDM:

Feasibility Study Business Study Functional Model Iteration Design and Build Iteration Implementation

The diagram shows an incremental prototyping approach moving anti-clockwise from the top. Dark arrows show the transfer points from one phase of the lifecycle into the next. The light arrows show the points where the development can easily return to an earlier phase. The lifecycle is described in the Overview of DSDM. The formal definitions of the phases together with some hints and tips can be found by following the links above. Note that not all the products defined in the phase definitions are delivered at the end of a phase. Some are necessarily interim deliverables that enable a given project to progress. Moreover some will start being developed in an earlier phase than the one in which they are delivered. The points at which they start being developed and at which they are delivered are decided on a project-by-project basis.A number of alternative paths, including an XP path, through the lifecycle are included in the tailoring DSDM section of the manual.

http://www.dsdm.org/version4/2/public/Lifecycle_Overview.asp (1 of 2) [11-1-2008 15:47:07]

DSDM Public Version 4.2 - Lifecycle Introduction

If you are using XP in conjunction with DSDM the Using DSDM with XP section of the manual describes a combined lifecycle.


http://www.dsdm.org/version4/2/public/Lifecycle_Overview.asp (2 of 2) [11-1-2008 15:47:07]

DSDM Public Version 4.2 - Pre-Project

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

Pre-ProjectIntroductionProjects do not exist in a vacuum: they need to be set up correctly from the outset to ensure success. Pre-project activities will depend on local working practices for the initiation of projects: however some guidance is offered here. The evaluation and prioritisation of projects within an organisation's portfolio is beyond the scope of DSDM.

PreconditionsA project has been proposed

ProductsInitial definition of the business problem to be addressed An outline scope for the investigation to take place during the Feasibility Study Decision to proceed with the project Visionary and Project Manager assigned to the project Initial plans for the Feasibility Study Confirmation of alignment of the project with the appropriate strategy Budget and resources allocated for the Feasibility Study at least and preferably the Business Study as well - with outline budget/resources approval for the development phases. The initial project governance in place, e.g. Project Board or Steering Committee

Points to ConsiderProjects get started in many different ways that determine which pre-project activities are appropriate. These include:

How the need for the project was identified: r business and/or IT strategic planning: budget will need to be allocated and resource availability will need to be checked before the project can proceed r business reaction to a problem or opportunity: alignment to business and/or IT strategies will need to be confirmed before any funding application or planning and resourcing activities take place r the project is part of an overall programme: the budget will already have been allocated, the Business Case approved, strategy alignment will have been checked - it remains to plan the early part of the project and obtain the resources Who proposes the need for the project: r Some one in a position of power within the organisation can direct that the project takes place r Others will need to spend time in order to gain approval for the project from key decision-makers.

http://www.dsdm.org/version4/2/public/Pre-Project.asp (1 of 2) [11-1-2008 15:48:03]

DSDM Public Version 4.2 - Pre-Project

Often lots of work needs to be done before it becomes a project. Particularly important is obtaining the resources for the Feasibility and Business Studies and gaining outline approval for resources thereafter. Many projects falter in the early stages due to the right people not being available and consequently lose both credibility and buy-in from all relevant areas (both customer and supplier). Getting a project started is often a difficult task. Moreover, there is usually no specific budget for pre-project work. This can result in it being done around the edges of normal management responsibilities, which can only cause delays that might otherwise be avoided. Sometimes the pre-project requirements and plans come together naturally: other times a lot of force is needed to make them stick. Finding the people with the right level of authority is important here. For organisations planning to outsource a project, the pre-project work is often done in isolation of a particular supplier. This means that much of it will need to be revisited once the contract has been awarded. The pre-project work should be minimal, just enough to get the project off the ground and to ensure that all key stakeholders can be involved from the start of the Feasibility Study and thereby avoid the need for later rework.


http://www.dsdm.org/version4/2/public/Pre-Project.asp (2 of 2) [11-1-2008 15:48:03]

DSDM Public Version 4.2 - Feasibility Study

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

Feasibility StudyIntroductionThe Overview of DSDM provides a description of the Feasibility Study phase. The Feasibility Study should only go to the level of detail required to assess whether a feasible solution exists or to select the most appropriate one. The detail of the requirements, risks, plans, costs, etc. for the solution will be developed in the later phases.

ObjectivesTo establish whether a proposed development can meet the business requirements of the organisation To assess the suitability of the application to DSDM development To outline possible technical solutions to the business problem To obtain first-cut estimates of timescale and costs

PreconditionsAgreement of the scope of investigation Initial agreement of the definition of the business problem to be addressed

ProductsFeasibility Report Feasibility Prototype (optional) Outline Plan Risk Log

Points to ConsiderThe best way to start a DSDM project is with a kick-off Facilitated Workshop to ensure that key stakeholders buy in to the project and everybody understands their respective responsibilities at least for the early stages. This could include agreeing the problem definition, allocating project roles, agreeing that the risks identified by examining the Suitability/ Risk List are acceptable, early requirements definition, etc. as defined in the Facilitated Workshop for the Feasibility Report.

http://www.dsdm.org/version4/2/public/Feasibility_Study.asp (1 of 2) [11-1-2008 15:49:17]

DSDM Public Version 4.2 - Feasibility Study

The Feasibility Study phase must be kept short and sharp. Having a fixed end-date will ensure that the detailed consideration of what will be done is correctly left until the Business Study phase.


http://www.dsdm.org/version4/2/public/Feasibility_Study.asp (2 of 2) [11-1-2008 15:49:17]

DSDM Public Version 4.2 - Business Study

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

Business StudyIntroductionThe Overview of DSDM provides a description of the Business Study phase.

ObjectivesTo scope the business processes to be supported To outline the future development in terms of prototyping deliverables (defining which are incremental and which, if any, are throwaway) and prototyping controls To identify representatives of the user classes for prototyping activities To prioritise the requirements of the proposed system To reassess the risks of the project To provide a firm basis for technical development to proceed To scope the non-functional requirements, in particular to decide the maintainability requirements

PreconditionsAgreement of the Feasibility Report, including agreement of the feasibility of both the development and the applicability of the DSDM approach

ProductsBusiness Area Definition Prioritised Requirements List Development Plan System Architecture Definition Updated Risk Log

Points to ConsiderSignificant business input will be required during the Business Study phase. The relevant business representatives must be identified early and their managers must allow them sufficient time to provide effective input to the project.

http://www.dsdm.org/version4/2/public/Business_Study.asp (1 of 2) [11-1-2008 15:49:29]

DSDM Public Version 4.2 - Business Study

Facilitated Workshops are the best technique for developing Business Study products and gaining agreement to their content as quickly as possible. Set a time limit to the Business Study and stick to it. The aim of this phase is to create a high-level but sound view of the business and technical basis for the project. Only produce the Business Study products to the level that allows the project to move into Functional Model Iteration with a realistic approach to the evolution of the Business Area Definition, Prioritised Requirements List and System Architecture Definition. The Business Case for the project must be assessed and a conscious decision taken to continue with the work beyond this phase: stopping a project with a poor Business Case (too risky, too costly, low benefits, etc.) should be considered a success. Always assess the risks of the project using the Suitability/Risk List. Later maintenance activities have a direct impact on determining the appropriate level of quality that is built into all business and technical products - and hence the level of quality control and assurance activities needed. The guidance on maintenance explains what needs to be considered during the Business Study. Either all the necessary procedures and controls should be in place before leaving the Business Study or it should be clear how they will be ready when required. The Project Manager and the Technical Co-ordinator are the roles that are respectively responsible for setting up the management and technical controls.


http://www.dsdm.org/version4/2/public/Business_Study.asp (2 of 2) [11-1-2008 15:49:29]

DSDM Public Version 4.2 - Functional Model Iteration

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

Functional Model IterationIntroductionThe Overview of DSDM provides a description of the Functional Model Iteration phase.

ObjectivesTo demonstrate the required functionality using a functional model consisting of both working software prototypes and static models (e.g. class models and data models) To record the non-functional requirements which may not be demonstrated by the working prototype.

PreconditionsAgreement of the Business Area Definition and the Development Plan Prototyping environment in place Commitment by senior user management of end-user time for prototype development

ProductsFunctional Model including Functional Prototypes Non-functional Requirements List Functional Model Review Records Implementation Plan Timebox Plans Updated Risk Log

Points to ConsiderThis phase may be merged with Design and Build Iteration for several reasons, e.g.:

The project is too small to warrant separation of the phases. The tools used for development generate good quality code from models.

Also, the phase may overlap with Design and Build Iteration, since full engineering of parts of the solution can begin before all the business functionality has been prototyped. This will be determined by the prototyping, modelling and testing approaches chosen for the project.

http://www.dsdm.org/version4/2/public/FMI.asp (1 of 2) [11-1-2008 15:49:40]

DSDM Public Version 4.2 - Functional Model Iteration

As the Functional Model evolves through prototyping activities, record the detail of hardware and software interfaces in the System Architecture Definition - rather than in the Functional Model.


http://www.dsdm.org/version4/2/public/FMI.asp (2 of 2) [11-1-2008 15:49:40]

DSDM Public Version 4.2 - Design and Build Iteration

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

Design and Build IterationIntroductionThe Overview of DSDM provides a description of the Design and Build Iteration phase.

ObjectivesTo refine the Functional Prototypes to meet the non-functional requirements To engineer the application so that it demonstrably satisfies user requirements

PreconditionsAgreement of (part of) the Functional Model including its associated non-functional requirements Agreement of any findings and changes of scope in the Functional Model Review Records Design and build environment in place

ProductsTimebox Plans Design Prototypes Design Prototyping Review Records Tested System Test Records

Points to ConsiderA pass through the Design and Build Iteration can begin as soon as a part of the Functional Model is agreed. This could consist of a set of paper models, some textual definitions of the processes, working Functional Prototypes. What must be known before moving into Design and Build is the non-functional requirements that apply to this part of the Functional Model, e.g. performance and security. The Tested System and its associated Test Records grow incrementally and are checked as they grow during this phase. They are delivered at the end of the last pass through Design and Build Iteration. Guidance is provided on Testing in DSDM.

http://www.dsdm.org/version4/2/public/DBI.asp (1 of 2) [11-1-2008 15:49:50]

DSDM Public Version 4.2 - Design and Build Iteration

While the technical people on the team are working to create the Tested System, the users should be producing the User Documentation, so that both parts are available for user training at the same time. Do not allow too many new ideas at this stage: they will endanger the delivery date. However, keep them in mind for later increments if they are considered of value.


http://www.dsdm.org/version4/2/public/DBI.asp (2 of 2) [11-1-2008 15:49:50]

DSDM Public Version 4.2 - Implementation

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

ImplementationIntroductionThe Overview of DSDM provides a description of the Implementation phase.

ObjectivesTo place the Tested System in the users' working environment To train the users of the new system To determine the future development requirements To train operators and support staff

PreconditionsAgreement of the Tested System by all interested parties, e.g. senior user management and technical support Training time available for users Target environment in place

ProductsUser Documentation Trained User Population Delivered System Increment Review Document

Points to ConsiderThe review of the increment must be run as soon as possible after delivery of the solution so that the next phase of development can be planned and kicked off with as little delay as possible. If the current increment was not originally planned to be the final increment, the project must not assume that the next increment will happen. The end of Implementation is a go/no go point for the project.

http://www.dsdm.org/version4/2/public/Implementation.asp (1 of 2) [11-1-2008 15:50:00]

DSDM Public Version 4.2 - Implementation

Both of the above points mean that the project's governing body must evaluate as quickly as possible the Business Case for continuing the project. An operational system includes not only the computer system but also the people who interact with it and the business processes they use. All of these must be successfully migrated for the solution to be considered to be delivered. Users of the system who may require training include not only the business end-users but also people working in support functions. If this is the final increment and a Post-Implementation Review is planned, get the date agreed and in people's schedules now.


http://www.dsdm.org/version4/2/public/Implementation.asp (2 of 2) [11-1-2008 15:50:00]

DSDM Public Version 4.2 - Post-Project

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

Post-ProjectIntroductionThe Post-Project phase contains the activities that occur once the project team have disbanded. These include support and maintenance activities and (optionally) a Post-Implementation Review to assess the system in use.

ObjectivesTo keep the Delivered System operational. To assess whether or not the proposed benefits of the project as stated during its initial phases have been achieved. To enable development processes to improve. To review the Delivered System in use.

PreconditionsThe Delivered System is signed off.

ProductsPost-Implementation Review Report Change Requests New releases of the Delivered System in response to Change Requests

Points to ConsiderOnce the Delivered System is in place, celebrate success, e.g. reward the project team for their efforts and publicise what has been achieved. Conduct a Post-Implementation Review only if it is appropriate for the size of the project. Maintenance guidance is provided.

http://www.dsdm.org/version4/2/public/Post-Project.asp (1 of 2) [11-1-2008 15:50:29]

DSDM Public Version 4.2 - Post-Project

A DSDM-based process is provided for developing and releasing Delivered System changes.


http://www.dsdm.org/version4/2/public/Post-Project.asp (2 of 2) [11-1-2008 15:50:29]

DSDM Public Version 4.2 - Maintenance

Introduction

When

Lifecycle

People

Products

Management

Development

Tailoring

Other

MaintenanceIntroductionThis section discusses not only maintenance but also the consideration that should be given to maintainability as early as possible in a development project. One possible approach to changes to the system is to rewrite the area requiring change rather than amending it. Producing a maintainable system is not incompatible with this approach. Each change to the system will have to be reviewed on its own merits for cost and timescale of amendment and for rewriting. It is essential to be pragmatic about this when deciding the best approach for changes. It is important during maintenance that there is still an Executive Sponsor: there should be an Executive Sponsor for both development and maintenance. There should also be an IT sponsor for maintainability. All maintenance work should be prioritised with the users so that only high priority and value for money needs of the business are met. This then saves the maintenance budget and resource capacity for the real requirements to meet business objectives. A DSDM-based Delivered System Change Process for use in such maintenance activities is provided.

The need to consider maintainability issues earlyMaintenance is a fact of life since the business needs change, so although maintenance is necessarily in the PostProject phase, it has to be considered from the very beginning of the project. Computer systems with poor maintainability:

take more resources in maintenance take longer to change are more likely to introduce further errors with change and be unreliable will cost more to maintain.

Computer systems with poor maintainability are a real risk to the business. In the extreme case, a new system could rapidly become a problematic, unmaintainable legacy system so triggering user requests to replace it. Future systems developed using DSDM must not add to the already existing and considerable industry-wide burden. One of the principles of DSDM is particularly relevant to maintenance and maintainability: namely, fitness for business purpose is the essential criterion for acceptance of deliverables. In other words, delivering to the business goals is what is required. Therefore if one of the business goals is a maintainable computer system delivering good cost benefits, then nothing is compromised by building in maintainability. Components with poor maintainability can slow the development of future increments. Maintainability and the ability to deliver quickly therefore go hand in hand

http://www.dsdm.org/version4/2/public/Maintenance.asp (1 of 2) [11-1-2008 15:50:45]

DSDM Public Version 4.2 - Maintenance

Maintainability in DSDMDSDM does not ensure maintainability by itself. Maintainability is made possible by a combination of four factors: tools, people, documentation and good practice guidelines. Good practice guidelines cover aspects such as standards, style guides, etc.: in fact everything that would probably be done automatically for a waterfall project and should not be forgotten in DSDM projects. If all of these aspects are considered early in the project lifecycle, maintainability becomes a natural attribute of all computer systems delivered and is not an overhead. Indeed they should be considered on an installation-wide basis prior to project work so that the cost and time of setting up guidelines, etc. is not borne by the projects.

Maintainability objectives (requirements)In a DSDM project, there are three possible choices of maintainability objectives (requirements). The decision as to which of them applies in a given project is mandatory in the Business Study. The three levels are:

maintainability is a required attribute of the initial delivered computer system. Here the criterion for deployment is not just to provide the required functionality in a robust way, but that the design and code meet a maintainability standard before the system is accepted and released to the business. deliver first, re-engineer later. The business priority is to elicit and implement the required functionality quickly. The system needs a long life and to be maintainable, but the business is prepared to pay for subsequent (behind the scenes) re-engineering after implementation. This means a greater development cost than engineering for maintainability first time, but gives a quicker initial delivery, and may produce a lower lifetime ownership cost than struggling for years with maintenance problems. (This is often the case where time to market is critical - either in software for sale into a fast moving market or in so

DSDM

Documents

dsdm approach

dsdm project

use dsdm

dsdm public version

dsdm consortium http

dsdm consortium members

dsdm frameworks position

commercial knowhow of