| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-oDZcGvl7ovoAHxXACLRdww" |
| name="new_supporting_material,_O2SrYFlfEdul8L-IGeA7TA" guid="-oDZcGvl7ovoAHxXACLRdww" |
| changeDate="2006-10-27T03:11:14.200-0700" version="1.0.0"> |
| <mainDescription><p>
 |
| DSDM is a vendor-independent method 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.
 |
| </p>
 |
| <p>
 |
| 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:
 |
| </p>
 |
| <ol>
 |
| <li>
 |
| The system fails to meet the business requirements for which it was developed. The system is either abandoned or
 |
| expensive adaptive maintenance is undertaken.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| <li>
 |
| Errors appear in the developed system causing unexpected problems. Patches have to be applied at extra cost.
 |
| </li>
 |
| <li>
 |
| Users reject the imposition of the system, for political reasons, lack of involvement in its development or lack of
 |
| commitment to it.
 |
| </li>
 |
| <li>
 |
| Systems are initially accepted but over time become impossible to maintain and so pass into disuse.
 |
| </li>
 |
| </ol>
 |
| <p>
 |
| DSDM aims to prevent all five types of project failure.
 |
| </p>
 |
| <p>
 |
| A fundamental assumption of the DSDM approach is that <strong>nothing is built perfectly first time</strong>, 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| DSDM assumes that all previous steps can be revisited as part of its iterative approach. Therefore, <strong>the current
 |
| step need be completed only enough to move to the next step</strong>, 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!
 |
| </p>
 |
| <p>
 |
| <strong>Systems built using the DSDM approach address the current and imminent needs of the business</strong> rather
 |
| than the traditional approach of attacking all the perceived possibilities. The resulting system is, therefore,
 |
| expected to be a 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.
 |
| </p>
 |
| <p>
 |
| <strong>DSDM is not only about developing new systems</strong>. Enhancements to existing systems can be created using
 |
| DSDM.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |