Understanding DSDM - Dynamic Systems Development Methodology
The methodological analysis system known as Dynamic Systems Development Methodology (DSDM) is used by professionals working with information systems for developing various types of software and for completing many types of software-related projects. The method itself has its origins the RAD (Rapid Application Development) Methodology. DSDM is aptly explained in a 1997 statement by Stapleton who says that DSDM covers – all within the RAD environment - building maintainable systems, buyer/vendor relationships, configuration management, estimating, managing risk, managing projects, prototyping, QA (quality assurance), reuse, roles/responsibilities (concerning IT personnel and users), team composition/structures, testing, time boxing, and tool building environments. Using nine principles as its base, DSDM is classed as an agile project management method that delivers software projects without going over time or budget. It is a methodology that many large businesses use and has the capability to produce, for instance, customer-based ordering systems with features for capturing customer information, order information, and stock information, as well as stock control functionality. Even in cases where a lot of a company’s functions are still paper-based, it is possible to use DSDM to computerize parts of its operations, especially essential operations.
For anyone who is considering computerizing their business, the first step is to carry out a quick analysis to develop the project’s scope. Usually, any system that is then proposed would be implemented across a LAN (local area network) with a centralized server/database. Usually, the people involved in such a project are a project manager, system analyst, programmers, and a project facilitator. The following outlines a project plan showing every stage, phase, and task in a DSDM project in the context of a case study (concerning a business referred to as Company X).
DSDM Project Phases:
Begin by undertaking a feasibility/viability study
Analysis of business needs
Iteration of functional model
Design and building of system
Feasibility or Viability Study:
This phase concerns the method being proposed and whether or not it can be applied. It involves undertaking a detailed research to establish what the current problems are. In the case of Company X, a feasibility study has been undertaken already and transcripts of interviews provided. The study shows there is currently no integrated software system so there is a requirement to produce an efficient system.
Analysis of Business Needs
This phase is concerned with getting a clear picture or understanding of the business operation and flow and how various processes are interrelated. This means identifying all stakeholders and anyone with an interest in a specific project. This phase is comprised of two distinct stages.
Setting up a JAD (Joint Application Design) workshop: This means arranging times and locations to hold meetings involving all project stakeholders. JAD workshop activities include discussing the project requirements with relevant managers and directors (e.g. in this case the finance director, managing director, sales manager and the warehouse manager at Company X). The next step is analyzing the business requirements, identifying the system’s boundaries and secondary (sub) systems according to the requirements specification in order to produce the end picture and the CATWOE (a checklist system created by Peter Checkland) Analysis, which is a task the system analyst undertakes. There are three secondary (or sub) systems in Company X, which are Purchasing and Importing, Stock Management and Stock Delivery, and Sales and Marketing. The last activity in this stage is producing a finalized project plan where resources and a completion timeframe are identified.
Producing a report based on the business study: The initial activity in this stage is identifying key business activities/processes and producing a data/information flow diagram. This diagram includes context, document flow, logical and physical requirements. Then it is necessary to produce a business relationship diagram or model for implementation in the database’s logical design. The activity that comes next is defining the system’s architecture, which sets out how the proposed platform will be developed, identifies the system’s main components, and prioritizes the system’s requirements using the MoSCoW prioritization principle (which is an acronym for Must have, Should have, Could have and Won’t have). The last activity in this stage is outlining the plan for prototyping i.e. defining the strategy to be used for prototyping in the following phase and deciding on a plan for configuration management.
Iteration of Functional Model
This involves refining the business’s high-level information needs and the system functions identified in the business study stage. It is also necessary to identify potential risks during this phase and devise a plan for managing risk in future development projects. Producing a standard analysis model of the proposed software is usually the product of this phase, which has five separate stages in total. These are:
Rectifying aspects of the business: This stage involves refining the business’s high-level information and functional requirements.
Identifying a functional model/prototype: The first step here is analyzing the data flow diagram’s requirements, listing the current iteration’s requirements, recognizing any requirements of a non-functional nature as identified previously, and creating a functional model identifying the key functionality of the component parts of the proposed system.
Agreeing the project plan: This stage determines the timeframe for developing the system’s design and agreeing the finalized prototype with stakeholders/clients.
Creation of functional model/prototype: This process is an iterative one that continues until the required result is forthcoming. The plan is first implemented by producing a functional model or prototype that adequately represents the system’s final functionality. Then individual functional prototypes are created, merged, and refined according to end-user comments and feedback. Any required changes will be taken into account in the following iteration.
System prototype review: This stage involves testing the system’s functionality and undertaking a review of the functional model or prototype according to comments and feedback from users. Then the final functional prototype or model can be delivered.
Design and Building of the System
This important phase involves the building of the system according to the non-functional system requirements identified earlier on. Once testing is complete, the newly built system is ready for the implementation phase, which comes next.
Identification of design-phase prototypes: The primary activities during this stage are identifying requirements of the non-functional type and implementing the agreed plan.
Agreeing the design-phase prototype: This involves prioritizing the requirements of the system in order to agree the prototype’s design.
Creation of the design-phase prototype: During this stage, the design prototype is created and the system’s must-have components are built and reviewed. Finally, the design prototype is tested before the system is delivered to the client/end users.
Review of the design-phase prototype: The final step in this phase is testing the system in its entirety rather than testing by unit. This stage also involves testing system performance and dealing with system failure – in the event any aspect fails.
This phase is the methodology’s final one and it is where the newly built system is moved from the development environment into the production or “live” environment. In the case of Company X, the central database system that has just been created will be installed on the company’s server and checks will be made to ensure every related system can access this central database and that all parts of the system are linked to each other across the LAN.
Implementation of Completed System: This means implementing all the system’s software and hardware on site and handing the system over to the client or purchasing company.
Business Review: This activity takes place during the development phase and it is where achievements are reviewed against business requirements.
Client Approval and User Guidelines: The client and/or end users approve the system and user manuals with precise instructions on how to use and maintain the system are issued. End users can then refer to this manual if they need any type of help.
Training of End Users: This involves providing end users with system training so that they can interact effectively with the newly built system once it is on site.
Benefits of the Dynamic System Development Methodology (Advantages)
Offers a process that is independent of specific techniques
Offers flexibility as requirements continue to evolve
Adheres strictly to agreed timelines and budget
Involves all stakeholders in a system’s design and development
Strong emphasis on system testing, stipulating that each project team includes a minimum of one tester
Systems designed from the ground up by people within the business, which means business needs and values are identified and given top priority in terms of deliverables.
Uses a unique approach to determine the importance of each individual requirement in iteration cycles
Sets realistic expectations for stakeholders early on i.e. makes clear that not every requirement can or will be included in the end product
Downsides of the Dynamic Systems Development Methodology (Disadvantages)
Requirements developed progressively
High levels of commitment to the methodology required
Significant levels of user input required
RAD focus can reduce the robustness of code
Possibly more of a heavyweight/involved method than others
Skilled developers/development teams required from both the business and the technical sides
On-going user involvement expected
Consortium control over access to resources and materials, with the possibility of fee-charging for access to reference materials
Numerous work products and artefacts defined for each project phase; heavy commitment in terms of documentation.