Stapleton (1998) claims that during the past decades, developers were constantly struggling, and usually were unable, to deliver their products on time, within budget, or to the exact specifications, when they were designing software using the classic methodologies, such as the Waterfall method. To tackle the problem of inadequacy of classic design methods for today’s software development, a UK-based consortium of businesses decided to put together a modern methodology. They agreed on nine principles.
The Principles
-
Principle 1: User direct and continuous involvement in the development/design process is imperative;
-
Principle 2: The developer team must have authorities to make decisions;
-
Principle 3: The frequent product releases is necessary;
-
Principle 4: Focus on the fitness for purpose;
-
Principle 5: The incremental iteration of development;
-
Principle 6: Reversibility of development;
-
Principle 7: Requirements come first;
-
Principle 8: Testing is an integral part throughout development;
-
Principle 9: Complete collaboration between stakeholders
(Schuh, 2005).
In 1995, they came up with the Dynamic Systems Development Method (DSDM) which describes some of the best practices and controls for designing software. The consortium is known as the DSDM Consortium and can be found online at the following address: www.dsdm.org; and its methodology at: dev1.dsdm.org.
DSDM, what is it?
DSDM is the UK’s de-facto standard for rapid application development. Developing software following this methodology might engage the simultaneous efforts of IT directors, project managers, systems architects, business and systems analysts, and quality managers and auditors to ensure the design fits perfectly the users’ requirements. Five phases come together and interact to compose this dynamic software development system: Feasibility Study, Business Study, Functional Model Iteration, System Design & Build Iteration, and Implementation. They are overtaken iteratively, i.e., the designers can go back and forth from any to any other phase, depending on the client’s feedback, the changing business requirement, and/or the testing results. Each task in DSDM is confined within a fixed Timebox, between 2 to 6 weeks, to ensure keeping up with the schedule. It wouldn’t be possible to commit to today’s shrinking time-scales if not for using the DSDM, specifically for being RAD-based!
DSDM Feasibility & Business Study
Prerequisites
Hoskins, et.al. (2006), states four of the important prerequisites for starting the design of a business multimedia application:
-
Objective: to know the exact objective(s) of the application. This is very essential because if the designer misses the objective(s), the resulting application won’t satisfy the requirements of the users.
-
Target: to know the targeted audience. By knowing the application’s audience, the designer will be able to satisfy the needs more accurately.
-
Resources: to take note of the resources available for designing the application. This will help the designer to plan the project scale and time.
-
Skills: to list the available technical skills. This will help in the technical design of the application, for example, to choose the implementation languages (C#, C++, Java …).
After considering the prerequisites, the designer can move on to the Feasibility study.
Feasibility Study
Questions asked in Feasibility of an application might be: is the application technically achievable? Which design methodology should be used? Many projects are considered feasible, not just for technically being possible to built, but also if they can be completed within the defined time-scale. Note that it is becoming increasingly difficult to commit to today’s shrinking time-scales, so it is very essential to choose the most suitable methodology (Stapleton, 1998)!
Business Study
The Business Study establishes the business awareness for the application. It defines the business functionality that need to be automated and its underlying information. It investigates the users and their roles vis-à-vis the system. All of these can be done through a type of analysis known as the Business Area Definition (Stapleton, 1998).
In DSDM is that the Business Study prioritizes the business functions by business need and technical constraint (or difficulty), usually, following the MoSCoW rule (see definition at the end of this section), so that the most important ones can be automated first and delivered to the customer. Afterward, incrementally, the rest of the functions can be added and delivered.
Functional Model Iteration
The Functional Model Iteration divides into four activities cycles. These activities are done to: firstly, identify functional prototype (what is needed to be done in the application); secondly, agree schedule (how it is going to be done); thirdly, create functional prototype (do it); fourthly, review prototype (test and demonstrate application). Along this iteration, business functions will be prioritized, as described in the Business Area Definition, and they keep getting refined as fits best to the plan. Non-functional requirements will be considered, such as usability. Risk analysis and management are also addressed here.
Design/Build Iteration
The Design and Build Iteration divides to the same four activities cycles as above. After the Functional Model Iteration, current iteration results in the actual application that will be delivered to the users. Still between both iterations, there might be back and forth movement depending on the Review prototype activity, where users’ suggestions and feedback are considered. For example, some issue of functionality and functions priority may need to be revised in the first iteration, the Functional Model, and accordingly, it comes back to the next iteration, the Design and Build, to be refined.
Implementation
The Implementation is the delivery of the complete application and its documentation to the users and has also four activities cycles. It starts with user approval and user guidelines, goes through business review (assessing the product vis-à-vis satisfying the business requirements), then the implementation (installing the product in the business operational environment), and ends with user training with the help of a user manual. Certainly back paths from the Implementation toward the second iteration, the first iteration, or even to the feasibility and business study might be taken, and as usual, depending on the testing, users’ comments, business review, and/or the evolution and the changing of the business itself!
MoSCoW
The MoSCoW rule prioritizes the requirements of the application in the DSDM projects. The letters of MoSCoW, except the o’s which are there to complete the acronym, stand for:
Must Haves: necessary for success
o
Should Haves: important but possible to live without
Could Haves: can be easily discarded if necessary
o
Won’t Have: left out for later versions of the software to consider
(DSDM Consortium, 1995)
The Future
The demand for more complicated software is logically anticipated to grow in the future. This will continuously increase the pressure on the designers to fully satisfy the requirements. To cope with evolving requirements, designers need to evolve as well. They need to keep an eye on the new technologies frequently emerging. They need to update their knowledge with newer techniques and train themselves on newer tools. Most importantly, they need to follow sound design methodologies, like the one mentioned above, the DSDM, to build their software. A design needs to be logical and fully explainable scientifically. Ad-hoc designs should be avoided at all costs. As these are very difficult to comprehend and later to update, scale, or change!
