Introduction When Lifecycle People Products Management Development Tailoring Other DSDM Consortium. DSDM Public Version 4.

Transcription

1 DSDM Public Version 4.2 Manual Introduction When Lifecycle People Products Management Development Tailoring Other DSDM Consortium [ :58:39]

2 DSDM Public Version Introduction Introduction When Lifecycle People Products Management Development Tailoring Other DSDM: Enabling Business Agility Introduction What 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. (1 of 4) [ :42:45]

3 DSDM Public Version Introduction 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. (2 of 4) [ :42:45]

4 DSDM Public Version Introduction 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 It s 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 success DSDM 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 DSDM Using 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. (3 of 4) [ :42:45]

5 DSDM Public Version Introduction 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 Consortium (4 of 4) [ :42:45]

6 DSDM Public Version What's New Introduction When Lifecycle People Products Management Development Tailoring Other How to use this site Introduction The 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. (1 of 2) [ :09:27]

7 DSDM Public Version What's New Familiar with DSDM Version 4.2? Use the Site Map to find what you are looking for DSDM Consortium (2 of 2) [ :09:27]

8 DSDM Public Versionl Overview Introduction When Lifecycle People Products Management Development Tailoring Other Process Overview Introduction In 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 Post- Project 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. (1 of 4) [ :45:05]

9 DSDM Public Versionl Overview Pre-Project The 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 Study An 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 Study Having 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. (2 of 4) [ :45:05]

10 DSDM Public Versionl Overview Functional Model Iteration The 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. Identify what is to be produced. 2. Agree how and when to do it. 3. Create the product. 4. 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 Iteration The 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. Implementation The 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. (3 of 4) [ :45:05]

11 DSDM Public Versionl Overview 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-Project The 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 Consortium (4 of 4) [ :45:05]

12 DSDM Public Version How the Process Works Introduction When Lifecycle People Products Management Development Tailoring Other How the Process Works Introduction The 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 requirements The 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. (1 of 3) [ :45:40]

13 DSDM Public Version How the Process Works Communication channels DSDM 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 DSDM DSDM 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 Technology The 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. (2 of 3) [ :45:40]

14 DSDM Public Version How the Process Works 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 Consortium (3 of 3) [ :45:40]

15 DSDM Public Version Principles Introduction When Lifecycle People Products Management Development Tailoring Other Underlying Principles The 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. II. III. DSDM teams must be empowered to make decisions The focus is on frequent delivery of products 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. 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. IV. Fitness for business purpose is the essential criterion for acceptance of deliverables Note: Products include interim development products, not just delivered solutions. 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. (1 of 3) [ :46:20]

16 DSDM Public Version Principles 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. VII. Requirements are baselined at a high level 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. 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. (2 of 3) [ :46:20]

17 DSDM Public Version Principles 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 Consortium (3 of 3) [ :46:20]

18 DSDM Public Version When to Use DSDM Introduction When Lifecycle People Products Management Development Tailoring Other When to Use DSDM Assessing the risks The 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 XP This 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 choice In 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. (1 of 3) [ :48:33]

19 DSDM Public Version When to Use DSDM 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. (2 of 3) [ :48:33]

20 DSDM Public Version When to Use DSDM Characteristics of systems where special care is needed in applying DSDM Many 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 Consortium (3 of 3) [ :48:33]