| <?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="-SnpZgz5EWgVuChDZCKIjCQ" |
| name="new_supporting_material,_0RZMMFllEdu-hcil0jQ6jA" guid="-SnpZgz5EWgVuChDZCKIjCQ" |
| changeDate="2006-10-27T03:25:13.328-0700" version="1.0.0"> |
| <mainDescription><p>
 |
| <strong>Find out more about DSDM by visiting</strong> <a href="http://www.dsdm.org" target="_blank"><font color="#800080"><strong>www.dsdm.org</strong></font></a>
 |
| </p>
 |
| <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>
 |
| DSDM is published, maintained and continuously improved by the DSDM Consortium (<a href="http://www.dsdm.org/" target="_blank">www.dsdm.org</a>), a not-for-profit organisation dedicated to the promotion of best practice for
 |
| software development and Agile project management.
 |
| </p>
 |
| <p>
 |
| A fundamental assumption of the DSDM approach is that <b>nothing is built perfectly first time</b>, 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, <b>the current step
 |
| need be completed only enough to move to the next step</b>, 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>
 |
| <b>Systems built using the DSDM approach address the current and imminent needs of the business</b> 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.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
