January 11 2021 12:36 PM
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 to develop various software types and complete many software-related projects. The method originates in 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 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 can 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 considering computerizing their business, the first step is to conduct 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 project managers, system analysts, programmers, and project facilitators. 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 the functional model
- Design and building of the system
- Deployment/implementation
Feasibility or Viability Study:
This phase concerns the proposed method and whether it can be applied. It involves undertaking detailed research to establish the current problems. In the case of Company X, a feasibility study has already been undertaken, and transcripts of interviews have been provided. The study shows that there is currently no integrated software system, so an efficient system is required.
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 interested in a specific project. This phase is comprised of two distinct stages.
- Setting up a JAD (Joint Application Design) workshop 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 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 to produce the end picture, and the CATWOE (a checklist system created by Peter Checkland) Analysis, a task the system analyst undertakes. Company X has three secondary (or sub) systems: 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, and 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. 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 is analyzing the data flow diagram’s requirements, listing the current iteration’s requirements, recognizing any non-functional requirements as identified previously, and creating a functional model identifying the key functionality of the proposed system's parts.
- Agreeing on the project plan: This stage determines the timeframe for developing the system’s design and agreeing on the finalized prototype with stakeholders/clients.
- Creation of functional model/prototype: This process is iterative and 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 reviewing the functional model or prototype according to user comments and feedback. Then the final functional prototype or model can be delivered.
FREE Extras:
We guarantee:
Page Format:
Design and Building of the System
This important phase involves building the system according to the non-functional system requirements identified earlier. 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 on the design-phase prototype: This involves prioritizing the system's requirements to agree on 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 the unit. This stage also involves testing system performance and dealing with system failure – in the event any aspect fails.
System Implementation:
This phase is the methodology’s final one, where the newly built system is moved from the development environment into the production or “live” environment. In the case of Company X, the newly created central database system will be installed on the company’s server, and checks will be made to ensure that 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, 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 it are issued. End users can then refer to this manual if they need any help.
- Training of End Users: This involves providing end-users with system training to 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 are designed from the ground up by people within the business, which means business needs and values are identified and prioritized in terms of deliverables.
- Uses a unique approach to determine the importance of each 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 are required
- RAD focus can reduce the robustness of code
- Possibly more of a heavyweight/involved method than others
- Skilled developers/development teams are required from both the business and the technical sides
- On-going user involvement is expected
- Consortium control over access to resources and materials, with the possibility of fee-charging for access to reference materials
- Numerous work products and artifacts are defined for each project phase; heavy commitment in terms of documentation.
