Abstract:Recently, agile development has become a preferred development approach in many of world’s leading technology companies. The primary reasons for a shift towards Agile development are accelerating delivery, aligning business and market needs, and continuous improvement in the development methodology to suit customer/supplier requirements. There are a number of methodologies being followed in developing software. Dynamic Systems Development Method (DSDM) is one of the Agile methods for developing software and forms part of the Agile Alliance. DSDM focuses on Information Systems projects that are characterized by tight schedules and budgets. This essay concentrates on DSDM Atern and provides a detailed analysis of the techniques and principles of Atern.
IntroductionThe structure of the essay is as follows. The following section provides information on the DSDM Atern definition and significance. Thereafter you can view the definition of fitness for purpose, information systems, DSDM Atern lifecycle explanation, techniques and principles. The last section includes the how DSDM framework is suitable for development of Information Systems.
Dynamic System Development Method (DSDM) is an iterative and incremental approach development project model used for developing business solutions within tight timeframes. Atern is the latest version of DSDM, the proven Agile Project Delivery Framework. Atern can be implemented for all types of projects. It can be applied to a wide range of projects from small developments all the way up to full scale business process change. The Atern framework concentrates on strategic goals and incremental delivery of real business benefits while keeping control of cost, risk and quality.
Fitness for purpose equates quality with the fulfillment of a specification or states outcomes. Information System: Information System is a combination of people, hardware, software, communication devices, network and data resources that processes the data and information for a specific purpose. (Information System) Let see how DSDM Atern Lifecycle helps to develop an information system. The Atern cycle consists of the following main phases: Pre Project Feasibility Exploration Engineering Deployment Post Project The description of each phase is explained in the following.
Feasibility Phase: The Feasibility phase is used for analyzing the project on the potential solutions, costs and timeframes. The main objectives of the feasibility phase are: To establish whether there is a feasible solution to the business problem described in the terms of reference. To identify the benefits likely to arise from the delivery of the proposed solution. To outline possible approaches for delivery, including solution sourcing and project management strategy.
To state the estimates of timescale and costs for the overall project. To plan and resource the Foundation phase. The Feasibility phase should be kept as short and sharp as possible. This phase is used as the base for the Foundations phase. Foundation Phase: The Foundations phase is aimed at establishing firm and concrete foundations for the project.
In establishing the foundations, the three essential perspectives of business, solution and management must be combined to provide a clear project focus that is both robust and flexible. The main objectives of the foundation phase are: Define a high level requirement for the project with priority and relevance. To identify information used, created and updated by the proposed solution. To start designing the solution architecture and identifying the physical or infrastructural elements of the solution. To describe the solution development lifecycle for the project along with techniques to be applied in managing the project and for demonstrating and communicating progress.
Pre-project Phase The pre project is used for developing a proposal for a project. The pre project objectives are: To describe the business problem to be addressed. To identify a Business Sponsor and Business Visionary. To confirm that the project is in line with business strategy. To scope, plan and resource the Feasibility phase. Exploration: This phase is applicable when different teams are responsible for creating early iterations of the solution and for engineering the finished system.
This may be the case where the bulk of the development is outsourced or completed offshore. The Exploration phase can be merged with the Engineering phase to incrementally deliver the final solution in a single repeated phase. The possible situations where an Exploration phase can be avoided are: Project is too small. Business logic embedded in the solution is simple. Architectural risk associated with development is very low. Developers confident to explore the tools and environments and requirements and can deliver a production ready solution in a single phase.
To elaborate on the requirements base lined in the Prioritised Requirements List. The objectives of the exploration phase are: Provide detailed requirements for the evolving solution. To create a functional solution that meets the needs of the business. Engineering Phase: The Engineering phase focuses on non functional requirements such as performance, capacity, security, supportability and maintainability. The objectives of the Engineering phase are: To refine the Evolving Solution from the Exploration phase to meet the agreed acceptance criteria.
To expand and refine any products required to successfully operate and support the solution in live operation. Deployment phase: Deployment phase is where the end product(s) of the project are to be sold or distributed outside the organization. A secondary purpose is to act as a key review point prior to Deployment or future development work. The main objectives of the deployment phase are: To confirm the ongoing performance and feasibility of the project and re-plan as required. To deploy the solution into the live business environment. Provide required documentation.
To train the users. To assess whether the deployed solution meets the requirements described in the Business Case. Post Project phase: Post Project phase is used for assessing the deployed solution. In many cases, the project will have been closed prior to the start of the Post-Project phase. (The Atern lifecycle.) In some projects where the overall solution is delivered incrementally, it is often appropriate to start the benefits realization process before the final deployment.
Under such circumstances it may be appropriate to feed any proposals for change or enhancement back into the ongoing project. The DSDM framework can be implemented for agile and traditional development processes. To show how DSDM relates to the agile methodology it’s essential to understand how DSDM principles relate to agile development process values. The following nine principles are essential to any DSDM implementation, ignoring one of them will break with the frameworks philosophy and significantly increase project risks.
Focus on the business need: The focus for the DSDM team is to deliver the most important business requirements within the required timeframe. Deliver on time: Frequent deliveries of results ensure that errors are detected quickly, are easily reversed and closer at the source of the error. This applies both to program code as well as to documents like requirements or data models. Collaborate: Collaboration and cooperation between all stakeholders is Essential.
In the beginning of a project the short-term direction must be possible to decide quickly without any changes needed in the planned procedures. Avoiding separation and encouraging collaboration of technical staff and business staff in a project is mandatory during DSDM projects, because co-operation is crucial to succeed in a DSDM project. Never compromise quality: Require to deliver the expected quality as per the business requirement. Build incrementally from firm foundations: Deliver in a defined pattern. Develop iteratively: The system being developed is allowed to grow incrementally, so that the DSDM team can take user views from one iteration and feed it into the next one to steer the solution to better fit the users’ needs.
Communicate continuously and clearly: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Demonstrate control: Teams in DSDM consist of both users and developers, and they must be able to make decisions themselves as requirements change. Atern provides techniques for both Project Management and Development. The following are the different management and development techniques. Facilitated workshops: The idea of workshops is implemented in many development methods, and provides a proven tool to establish user-developer collaboration. However, several problems emerge in large teams and heterogeneous groups; the worst case is a lock-down due to too many participants or due to a knowledge gaps.
DSDM tries to solve this problem by carefully selecting the right people to participate in the workshop. (Facilitated workshops.) Facilitated workshops can provide the following: Example showing a real life work sample. A supportive learning environment, with ground rules for everyone’s behavior Time boxing: Traditional project management uses milestones to agree on a deliverable for a defined project milestone. Even though, milestones work well enough, a time box is a much more powerful tool to achieve the same result.
A time box is an interval, which is usually no longer then 6 weeks, where a given set of tasks must be achieved. Time boxing is defined as the amount of work to be completed in a fixed period. Time is a fixed component the other two constraints scope and cost are adjusted as per requirement. Finally, time boxes is not the only solution for all time slips. In certain cases the management may decide to drop certain features to avoid the cost.
This situation can occur when a new “must have” feature emerges. MoSCoW prioritization: In a timeboxed systems development environment, it is not possible to guarantee delivery of all the scoped requirements within the defined time. However, end-users and those paying for the development need to have some confidence and reasonable expectation of what will be delivered. It is also mandatory to keep a constant watch on which features the user needs most. MoSCoW prioritisation is a technique that provides the stakeholders the confidence. The prioritisation technique is used for different levels of timeboxing.
A requirement may be prioritised in one category for the complete project timebox. But, can contain a lower prioritisation for shorter time timeboxes within the same project. The requirements (functional and non-functional) are classified within one of the following four sections: Must Have: The requirement is essential. Stakeholder needs will not be satisfied if this requirement is not delivered and the timebox will be considered to have failed.
Should have: This is an important requirement. But, if it is not delivered within the current timebox, there is an acceptable workaround until it is delivered during a subsequent timebox. Could have: This is a ‘nice to have’ requirement. This requirement can be delivered on time. But, we may need to de-scope the timelines if we have underestimated.
Want to have but will not have this time round: The full name of this category is ‘Would like to have but would not have during this timebox’. The requirements in this category will not be delivered within the timebox where the prioritization is applicable. This classification system serves as single source of decision on what to implement during the project and timebox iteration. The MoSCoW prioritization technique is an iterative and ongoing one. The following is a list of activities that must be followed: Project Start Each Increment In Increment Timeboxes End of Project Modelling and Prototyping: Endorsing evolutionary prototyping DSDM projects satisfy two of the DSDM principles, frequent delivery and incremental development.
Prototypes are to implement critical functionality fist to discover difficulties early in the development process, they also allow having very early deliverables to get user feedback. Iterative Development: The system being developed is allowed to grow incrementally, so that the DSDM team can take user views from one iteration and feed it into the next one to steer the solution to better fit as per business requirement. The study of the relationship between the evolving role of information systems and the nature of strategic development in organizations is integral to understanding the role and effects of information systems. This includes the rationale and processes by which organizations identify the needs for development and how they assess the business and organizational consequences. The DSDM framework is based on best practices for implementing a project structure.
Its strengths are simplicity, extendibility, and a proven methodology in the past. Authors suggest, the use of DSDM where it does not meet the purpose provides credibility to the concept when compared with the other similar methodologies. The weakness of DSDM is the relatively high entry barrier. Switching to DSDM requires a significant cultural shift in any organization, because deliverables will be replaced with tasks. Project team will have difficult time to deliver the requested functionality.
But, will agree to deliver the project on time and on budget. The flexible Atern lifecycle framework can be used equally for iterative, Agile products using workspace prototypes, and also for traditional waterfall projects that use written functional and design specifications. DSDM is a mature agile development method, while many agile methodologies concentrate on the programming section rather than process models. There are few common methodologies that share common features with DSDM. SCRUM is as well as a DSDM, which promotes team empowerment.
The Crystal Methodologies is a good collection of best practices. But, still DSDM does a much more comprehensive job in showing its evolving character by versioning their framework after every revision by the DSDM consortium. Shell, Loyds Bank Insurance Services, British Telecom, British Airways, Deutsche Bahn, Hewlett-Packard, Renault, the city of Los Angeles. These are the list of companies that has been using DSDM since long. Xansa used DSDM to organize its offshore development in India. ThoughtWorks has been using offshoring to India with agile methods as well, proving that the highly profitable practice of offshore development and onshore engineering works with agile methods, good enough to present a business case.
(Basics and summary) DSDM continues to be a best practice framework. But, still DSDM consortium acknowledges that the environments of many projects change. So the DSM team works to adapt the framework to meet these requirements. The critical success factors for DSDM, and the characteristics of projects that will make DSDM more effective.
Each potential project must be judged individually by using the filter. If the project provides a good match with the filter, then DSDM can be considered as a suitable method. If the criteria results are not satisfied then the method can be modified. In all cases, care should be taken not to overload the project with duplicated or unnecessary processes and products.
