Daily Archives: November 22, 2011

Sort Description:Nine (9) Principles of Dynamic Systems Development

Posted in Agile Software Development, Information Systems Engineering by
Summary of Nine Principles of DSDM
  1. Active User Involvement is Imperative
    • DSDM – a user-centred approach
    • Active participation through lifecycle
  2. DSDM Teams must be Empowered to Make Decisions
    • DSDM team comprises developers and users
    • Decisions made as requirements refined or changed
    • No need for recourse to higher management
    • Rapid and informed decision-making
  3. The Focus is on Frequent Delivery of Products
    • Team produces agreed products throughout lifecycle
    • Team chooses best approach to achieve objectives
    • Ensures focus on delivery, not just activity
  4. Fitness for Business Purpose is the Essential Criterion for Acceptance of Deliverables
    • Build the right product before you build it right
    • Meeting business need is more important than technical perfection
  5. An Iterative and Incremental Approach is Necessary  to Converge on an Accurate Business Solution
    • DSDM allows solutions to emerge incrementally
    • Developers make full use of user feedback
    • Partial solutions can be delivered to meet immediate needs
  6. All Changes During Development are Reversible
    • All products should be in a known state at all times
    • It should be possible to step backwards, where an approach does not work
    • The team should be willing to embrace change and not be defensive
  7. Requirements are Baselined at a High Level
    • Freezing and agreeing purpose and scope of system
    • Baseline at a level which allows detailed investigation of requirements at a later stage
  8. Testing is Integrated Throughout the Lifecycle
    • Not a separate activity at the end
    • System is tested and reviewed incrementally by developers and users
    • Testing evolves as prototypes mature
    • Aim is to find and fix errors as early as possible
  9. A Collaborative and Co-operative Approach between all Stakeholders is Essential
    • Everyone working together as a team
    • Shared goal of achieving the business objectives
    • Give and take on all sides
    • Involves all parties, not just core team

Nine Principles of DSDM -Detail

Source

  • University of Greenwich,  London, UK

Nine (9) Principles of Dynamic Systems Development Method (DSDM)

Posted in Agile Software Development, Information Systems Engineering by
Principle 1: Active user involvement is imperative.

DSDM’s strong focus on the business purpose of the system being developed requires that the ultimate users of the system be involved throughout the development project. This is because the system attributes that will make it fit for its purpose cannot be understood well enough in the project’s early stages to commit them to a detailed specification. Therefore, the only way to make appropriate detailed decisions and know that the evolving system is converging on the ideal of “fitness” is to fully involve the users throughout the project.

Principle 2: DSDM teams must be empowered to make decisions.

This principle does not give the team free reign to do whatever they wish. Rather, it advocates that the team be delegated the authority to make most of the day-to-day decisions as the project progresses. With active user involvement, such delegation can result in the team being able to move quickly and steadily toward system delivery. However, when a decision that must be made falls outside the team’s authority (e.g., cost overruns), DSDM recognizes the importance of raising such decisions to the appropriate authority.

Principle 3: The focus is on frequent delivery of products.

This principle means that the project’s progress should be measured by the production of tangible products, rather than by mere activity. The phrase “delivery of products” does not refer only to the incremental delivery of a working system to an end user. Products in this sense include any sort of work product that may be produced as the project moves forward (e.g., a specification, a throwaway prototype, a design document); and delivery could be simply within the project team. DSDM requires that as the project moves forward, it must produce artifacts that prove that progress is being made.

Principle 4: Fitness for business purpose is the essential criterion for acceptance of deliverables.

This principle is the practical manifestation of DSDM’s belief that specifying detailed requirements upfront is not helpful. By placing fitness for purpose above satisfaction of requirements, and by involving users consistently, DSDM zeroes in on the end user as the only one who can say whether or not the system as it is evolving is acceptable.

Principle 5: Iterative and incremental development is necessary to converge on an accurate business solution.

In an environment where it is assumed that the project’s end result cannot be foreseen in great detail, incremental development is the best insurance against the project going terribly awry. Incremental development is essentially an exercise in trial and error, where each new increment is presented to the user who validates (or invalidates) the direction the team has taken. “Converge” is the key word in the principle. It is assumed that the most direct path to the end product is not likely to be known, so DSDM engages in constant checking and correcting of the path to bring the project to a satisfactory end as quickly as is reasonably possible.

Principle 6: All changes during development are reversible.

If we agree that the project is practicing trial and error, then we must expect that there will indeed be errors from time to time. This principle gives us permission to discard erroneous work when necessary. Surely, we will try to salvage the good from a mistake, but we must recognize that there will be times when the most efficient path is to discard some work and try again.

Principle 7: Requirements are baselined at a high level.

The first three words of this principle, “Requirements are baselined,” represent a departure of DSDM from some other Agile methods. DSDM recognizes the importance to the project of stability in scope and direction. By baselining (freezing) the requirements at some level, stakeholders are establishing a stable basis for the team’s work. This does not mean that this baseline will not change; rather, it requires that serious deliberation precede any such change so that all stakeholders understand and agree to what would become the new requirements baseline. The last four words, “at a high level,” is the part of this principle that makes it agile. It leaves the details of what the requirements mean to be worked out between the team and user.

Principle 8: Testing is integrated throughout the life cycle.

Testing does not show up as a step in the DSDM life cycle because, like other Agile methods, DSDM promotes a strong quality-consciousness by all team members. Every task should include an appropriate verification or validation step like a review or test by a team member or user. This principle works together with principles 1, 4, and 5 to continually check the project’s progress toward its goal of a system fit for its business purpose.

Principle 9: A collaborative and cooperative approach between all stakeholders is essential.

This last principle is little more than the sum of the first eight. The only way that principles 1–8 can be applied successfully on a project is if all stakeholders accept DSDM and their roles as DSDM defines them. If any stakeholder does not agree (especially an influential stakeholder), then DSDM cannot work in that environment.

Nine Principles of DSDM -Lite Version

Source

Overview of DSDM : Phases of DSDM life-cycle

Posted in Agile Software Development, Information Systems Engineering by
5 phases of DSDM lifecycle

phases of DSDM life-cycle

Pre-project

The pre-project phase ensures that only 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 and business studies are done sequentially. They set the ground rules for the rest of development, which is iterative and incremental and therefore they must be completed before any further work is carried out on a given projects

Feasibility study

In this phase the problem is defined and the technical feasibility of the desired application is verified. Apart from these routine tasks, it is also checked whether the application is suitable for Rapid Application Development (RAD) approach or not. Only if the RAD is found as a justified approach for the desired system, the development continues.

Business study

In this phase the overall business study of the desired system is done. The business requirements are specified at a high level and the information requirements out of the system are identified. Once this is done, the basic architectural framework of the desired system is prepared. The team researches the business aspects of the project.

  • Does it make good business sense?
  • Who are the participants and interested parties?
  • What is the best work plan? What is needed to:
    1. Build it
    2. Test it
    3. Deploy it
    4. Support it?
  • What technologies will we be using to build and deploy it?

The systems designed using Rapid Application Development (RAD) should be highly maintainable, as they are based on the incremental development process. The maintainability level of the system is also identified here so as to set the standards for quality control activities throughout the development process.

Functional Model Iteration

This is one of the two iterative phases of the life cycle. The main focus in this phase is on building the prototype iteratively and getting it reviewed from the users to bring out the requirements of the desired system. The prototype is improved through demonstration to the user, taking the feedback and incorporating the changes.Prototyping follows these steps:

  • Investigate
  • Refine
  • Consolidate

This cycle is repeated generally twice or thrice until a part of functional model is agreed upon. The end product of this phase is a functional model consisting of analysis model and some software components containing the major functionality

Design and Build Iteration

This phase stresses upon ensuring that the prototypes are satisfactorily and properly engineered to suit their operational environment. The software components designed during the functional modeling are further refined till they achieve a satisfactory standard. The product of this phase is a tested system ready for implementation.

There is no clear line between these two phases and there may be cases where while some component has flown from the functional modeling to the design and build modeling while the other component has not yet been started. The two phases, as a result, may simultaneously continue.

Implementation

Implementation is the last and final development stage in this methodology. In this phase the users are trained and the system is actually put into the operational environment. At the end of this phase, there are four possibilities, as depicted by figure :

  • Everything was delivered as per the user demand, so no further development required.
  • A new functional area was discovered, so return to business study phase and repeat the whole process
  • A less essential part of the project was missed out due to time constraint and so development returns to the functional model iteration.
  • Some non-functional requirement was not satisfied, so development returns to the design and build iterations phase.

Dynamic System Development Method (DSDM) assumes that all previous steps may 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. This premise is that the business requirements will probably change anyway as understanding increases, so any further work would have been wasted.

Post-Project – Maintenance

After the product is created, maintenance will inevitably need to be performed. This maintenance is generally done in a cycle similar to the one used to develop the product.

According to this approach, the time is taken as a constraint i.e. the time is fixed, resources are fixed while the requirements are allowed to change. This does not follow the fundamental assumption of making a perfect system the first time, but provides a usable and useful 80% of the desired system in 20% of the total development time. This approach has proved to be very useful under time constraints and varying requirements.

Nine Principles of DSDM -Detail

Nine Principles of DSDM -Lite Version

Source

Dynamic System Development Method (DSDM)

Posted in Agile Software Development, Information Systems Engineering by

What is DSDM?

DSDM is a framework based on best practice and lessons learnt since the early 1990’s by DSDM Consortium members. It is another approach to system development, which, as the name suggests, develops the system dynamically. It is independent of tools, in that it can be used with both structured analysis and design approach or object-oriented approach.

The Dynamic System Development Method (DSDM) is dynamic as it is a Rapid Application Development method that uses incremental prototyping. DSDM is particularly useful for the systems to be developed in short time span and where the requirements cannot be frozen at the start of the application building. Whatever requirements are known at a time, design for them is prepared and design is developed and incorporated into system. In Dynamic System Development Method (DSDM), analysis, design and development phase can overlap. Like at one time some people will be working on some new requirements while some will be developing something for the system. In Dynamic System Development Method (DSDM), requirements evolve with time.

DSDM focuses on delivery of the business solution, rather than just team activity. It makes steps to ensure the feasibility and business sense of a project before it is created. It stresses cooperation and collaboration between all interested parties. DSDM makes heavy use of prototyping to make sure interested parties have a clear picture of all aspects of the system.

Background of DSDM

Business are putting increasing pressure on their IT suppliers to deliver better systems, faster and cheaper. In today’s rapidly changing world, they are no longer able to wait for years for a system to be provided: the business may have changed radically during the years of development. It is imperative to find a different way of building IT systems. The technology that is now available to developers allows for more speedy production of system but the answer lies not only in the use of tools. The whole process needs to change. The classical, waterfall life-cycle does not take full advantage of modern technology and does not facilitate the change that is inherent in all systems development. It has been around for about 40 years and is basically the solution to an old problem -that of not having a full understanding of the problem to be solved and not having a coherent approach to solving the problem before starting to code a solution.

The waterfall approach of a strict sequence of stages has been seen to be flawed for many years now.Several attempts have been made to move away from it. including Barry Boehm’s iterative style of development using a spiral model of planning, risk analysis, engineering, and customer evaluation. Though excellent, the spiral model did not achieve the penetration into IT practices that it deserved. The emergence in recent years of many ‘Agile’ methods proves the need for a different approach. While some, such as Extreme Programming, have gained wide acceptance they do not cover all aspects of a project and can leave an organization confused as to how to integrate the many solution on offer. This provides one explanation for the less than optimal acceptance of agility as the way forward by the majority of IT solution providers. Another could be that, until recently there has been sufficient pressure from their customers.

In the early 1990s, the IT industry had become increasingly aware of Rapid Application Development following James Martin’s book Rapid Application Development, which gave some excellent pointers as to how to make the concept work, but did not provide the total solution, There are many tools on the market, but to use them often meant buying the vendor’s process as well. the founding members of the DSDM Consortium saw this as a block to the growth of successful and fast solution delivery.

The Consortium was inaugurated in January 1994 with the aim of producing a public domain, commonly agreed method which would be tool-independent. Ed Holt who chaired the Consortium for the first two years said that every organization that bought a RAD tool really needed a new process. DSDM aims to provide that process for building and maintaining systems that meet tight time constraints in a controlled project environment. The Consortium had 17 founder who resented a mix of organizations that remains today: large IT vendors, smaller tool vendors, and user organizations of all sizes.The Consortium now has hundreds of members with established regional consortia in North America, Benelux, Sweden , France and Denmark with interest growing in other countries, such as Australia India And China.

During 1994, the Consortium’s Technical Work Group put together the process and produced guidance material based on the experience and best practies of Consortium members. a few components of the framework were original ideas from experts in particular areas, but most of them were tried and tested -but they had never been brought together as a cohesive approach.

Why DSDM more rapid than the Waterfall ?

DSDM produces industrial strength systems that meet users’ need and are fully extendible and maintainable over long periods of time -they are not one-off or throwaway. In business  terms, they the exact peer of good system developed by the waterfall approach, but take a lot less time to develop.

There are two main reasons. Less is actually done. There is much less time spent in briefing people, and bringing them repeatedly up to speed. Little time is lost through task-switching by users or developers. Most importantly of all, only the features that are needed are actually developed.

The second reason is that problems, misunderstanding and false directions are identified and corrected early, so avoiding the massive rewrites often required late in waterfall projects. This has a further benefit. The resultant code developed under DSDM is consistent and of a piece, whereas waterfall code, by the end of the projects, is often already patched and out of synchrony with its documentation. The result is that DSDM=delivered code is also easier to maintain.

 When to use DSDM?

DSDM is not the panacea to all project ills that developers are often promised. There are classes of system to which the framework is most easily applied and these are the areas which an organization which is less experienced in agile development should focus on to begin with -unless of course the pressure to deliver is so great that an ‘unsuitable’ project must be tackled before the organization is mature in its use of the an agile approach, and DSDM is particular. The framework has been used in a wide variety of projects in a diverse set of organizations. It is difficult to say that the framework should never be used for a particular sort of application.

The main questions to ask when deciding on the appropriateness of a proposed system to DSDM development are:

  1. Is the functionality going to be reasonably visible at the user interface? :- Of course the use interface includes reports as well as screens or indeed any other way of showing the end-user what is happening inside the system. If users are to be involved throughout the development process, they must be able to verify that the software is performing the right actions through prototyping, without having to understand the technicalities of what is happening behind the user interface.
  2. Can you clearly identify all classes of end-users? :-It is essential to involve users within the project who can represent all of the potential end-user population. This has caused some concern when developing systems for widely disparate or geographically dispersed populations. The important thing is to ensure that you can obtain complete coverage of all relevant user views with on the development team. Otherwise there is a danger of driving the development in a skewed direction. Moreover the review process of sending out documents for a matter of weeks to a wide user group is very often not feasible on a DSDM project. Such reviews limit the chances of delivering on time.
  3. Is the application computationally complex? :-This is possible one of the hardest questions to answer. What is complex for one organization is simple for another. A lot will depend on what is available in terms of the building blocks to the development team. The important thing is not to develop too much complex functionality from scratch. This question is closely linked to the first question about the visibility of functionality. For instance, if the system is performing complex actuarial calculations, this could render the project difficult for DSDM. On the other hand, if the calculation processes have been used in previous systems and are tried and tested, the actuaries will trust what is presented to them.
  4. Is the application potentially large? :- DSDM has been used and is being used to produce very large systems, but in every case it has been possible to develop the functionality in fairly discrete chunks. There are several DSDM projects in progress at the time of writing that have a development period of two to three years. This could be viewed as not being rapid development, but increments will be delivered at regular intervals rather waiting until everything is complete before the system is put into operation. If the system is large and there is no possibility of incremental delivery, i.e. everything has to be delivered in a matter of months for the system to be useful, them it must be possible to break down the work for development by parallel teams.
  5. Is the project really time-constrained? :- It is all too easy for business management to say that a system must be delivered by a certain date when they don’t really mean it. This is potentially disastrous for the project. It means that whole the developers are geared up to follow the DSDM guidance; the end-user participation at all levels is not as forthcoming as it should be. At best this is frustrating. At worst, the project goes in the wrong direction because the drive from users is not there and developers start making assumptions about what is needed in order to keep active.
  6. Are the requirements flexible and only specified at a high level?:-This could be reworded as ‘Do you have complete understanding of everything that must be delivered?’ Whatever the project, the answer is just about always ‘No!’ but, for DSDM to work successfully, the level of detailed understanding at the outset of the project should be lower than is the norm.The use of prototyping with knowledge users to elicit requirements as you go is fundamental to the approach. If everything is understood and all the detailed requirements have been agreed and fixed before the software builders come on the scene, major benefits of DSDM will not be achieved, such as building the right system rather than what was originally requested.Also, if the requirements are inflexible, it will not be easy to negotiate what can be left out if the project deadline is approaching and a great deal of work remains to be done.

Sort description of phases of DSDM life-cycle

Nine Principles of DSDM -Detail

Nine Principles of DSDM -Lite Version

 

Source