Home Page      Quality consultancy

 Services  Descriptions

  DSDM Quality  DSDM 



  dsdmlifecycle

The 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.

 

Principles

Comments

I. Active user involvement is imperative.

DSDM is a user-centred approach. If users are not closely involved throughout the development life-cycle, 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. DSDM teams must be empowered to make decisions.

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.

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 systems.

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.

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 life-cycle, 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 which 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.

VIII. Testing is integrated throughout the life-cycle.

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 pre-contract phase and when the contracted work is carried out.



  Rational Test  TEST 


 
 Rational Test Suite

Rational suite:

Rational LoadTest makes comprehensive system performance testing simple and effective.

Rational PerformanceArchitect unifies analysts and testers, giving analysts the information needed to confidently make architectural decisions early in the project life cycle.

Rational Robot provides thorough functional testing of your entire application.

Rational Rose enables team members to define and communicate a software architecture.

Rational TestFactory automatically detects run-time errors without user assistance and generates optimal scripts for regression testing.

Rational Purify locates hard-to-find run-time errors that cause program crashes.

Rational Quantify pinpoints performance bottlenecks in your applications.

Rational PureCoverage identifies untested code and provides code-coverage analysis.

Rational Unified Process lets you enhance team productivity through its Web-enabled, searchable knowledge base. It's easy to benefit from the software industry's best practices with these guidelines, templates, and tool mentors.

Rational SoDA gives you an easy-to-use interface for reporting and documentation. It can automatically generate documentation from Rational Rose, RequisitePro, and ClearQuest data.

Rational RequisitePro, the market-leading, team-based requirements management tool that facilitates the documentation, organization, and tracking of your requirements, while making that vital information available to all cross-functional team members.

Rational ClearQuest lets you easily colllect, manage, and assign software change requests. It provides a common interface to all software team members — analysts, developers, and testers — so everyone remains in synch.

The justification of implementing such a structure

 The difference in the software between the state of the project as planned and the actual state that has been verified as operating correctly, is called the quality gap.
The advantages of closing the quality gap early in the development cycle are apparent. The first step is to measure the gap consistently. To do so, an organisation needs the relevant data, tools, methods and metrics. Practically, software failures can be classified into four dimansions, which correspond to four aspects of the quality gap:

Reliability: Does the application operate without crashing, hanging or leaking memory or other resources?
Functionality: Does the application meet the business requirements established for it?
Application performance: Does the application respond in a timely manner?
System performance: Does the application continue to perform correctly and in a timely manner when it is subjected to production load?