Dynamic Systems Development Method and Methodology

There are many methodologies to systems analysis and design. Each methodology differs from the other in many aspects including technical approaches, view of users and system environment, epistemology and ontology, suitability for use, etc. Hence a more structured and formal way of evaluating methodologies is by using the Normative Information Model-based Systems Analysis and Design (NIMSAD).

NIMSAD is well noted to have a “wide scope, not restricted to any particular category of methodologies, practical and considers different use situations” (Koskinen, Lintinen, Sivula and Tilus, 2003). In this paper, two methodologies are compared using the NIMSAD framework, the Structured System Analysis and Design Method (SSADM) from the waterfall approach family and the Dynamic Systems Development Methodology (DSDM) from the agile methodology family.

Structured System Analysis and Design Method (SSADM)

SSADM is a structured waterfall approach to systems analysis and design. It uses three main techniques; logical data modeling, data flow modeling and entity behavior modeling. There are seven stages to this methodology starting from stage 0 to stage 6:

Stage 0: Feasibility Study

In this stage goals and implications of the project are investigated. Four main components are taken into consideration: technical, functional, organizational and ethical components. System requirements are analyzed and business options are identified. The end product of this stage is a feasibility study document. (Wikipedia, 2012)

Stage 1: Investigation of the Current Environment

Data requirements are investigated. A system analyst tries to analyze the current system by means of “interviewing employees, circulating questionnaires, observations and existing documentation” (Wikipedia, 2012). The objectives of this investigation is to find out “ what users do and how they do it, core requirements for the new system, data model construction and to define system boundaries” (Wikipedia, 2012). The end products of this stage are a user catalog, requirements catalog and a first set of data flow diagrams (Wikipedia, 2012).

Stage 2: Business System Options

The analyst may present a set of different business options. These options consider the “degree of automation, boundary between the system and the users, distribution of the system, cost and benefit of the new system and business impact of the new system” (Wikipedia, 2012). In the end, stakeholders and analyst choose a single option.

Stage 3: Requirements Specification

Here, a full logical system specification (description of what the system must do) is developed based on requirements set in stage 1 and chosen business option. Logical models of data flow diagrams and entity relational diagrams are developed. The end product of this stage is a full requirements specifications document (Wikipedia, 2012).

Stage 4: Technical System Options

Technical system options for systems implementation are presented. Areas of consideration are the “hardware architectures, software to use, the cost of the implementation, the staffing required, the physical limitations, the distribution including any networks which that may require and the overall format of the human computer interface” (Wikipedia, 2012). From that, a technical system is chosen.

Stage 5: Logical Design

Here, the logical design is focused on the requirements for human computer interface. The end products are a “data catalog, required logical data structure and logical process model” (Wikipedia, 2012).

Stage 6: Physical Design

All logical requirements are converted to descriptions of system hardware and software (Wikipedia, 2012). “Logical data structure is converted into a physical architecture in terms of database structures” (Wikipedia, 2012).

Dynamic Systems Development Method (DSDM)

DSDM is an agile development method that is based on Rapid Application Development (RAD). It uses an iterative and incremental approach to system development. Its main goals are to accommodate changing requirements and meet business needs on time and in budget.

DSDM implementation includes 9 essential principals: active user involvement, empowered users or teams, focus on frequent delivery, business fitness criterion for accepted deliverables, iterative and incremental development, reversible changes during development, requirements base lined at high level, integrated testing throughout the life cycle and collaborative cooperation (Wikipedia, 2012).

Core techniques deployed in this methodology are time boxing, Moscow rules and prototyping (Wikipedia, 2012). Time boxing is a technique where time intervals are allocated for certain tasks to be completed. This helps to make sure that the project stays on target.

Figure 1: DSDM Development Process (AGILE Methods of Software Development, 2011)

There are five phases to this project structure as shown in Figure 1:

Feasibility Study and Business Study
Suitability of DSDM is assessed in the feasibility study. The end product is a “feasibility report, a feasibility prototype, and a global outline plan which includes a development plan and a risk log” (Wikipedia, 2012). In the business study stage, “a prioritized requirements list, a business area distribution, a system architecture definition, and an outline prototyping plan are developed” (Wikipedia, 2012).

Functional Model Iteration
A functional model is developed according to the requirements set in the business study. From that, a functional prototype is developed and tested with an end user or a review document (Wikipedia, 2012). This phase is done iteratively. At the end of this phase, a functional prototyping review document is presented (Wikipedia, 2012).

Design and Build Iteration
An implementation strategy is developed based on functional and non-functional requirements as well as any available test records from previous iteration testing (Wikipedia). Then, a design prototype is built and tested with end users. Like the former phase, this is done iteratively. At the end of this phase, a user documentation and test record are developed (Wikipedia, 2012).

Implementation
This phase includes getting end user approval and developing implementation guidelines, end user training, delivering the system to end users and reviewing the impact of the implemented system on the business (Wikipedia, 2012). The review is documented in a project review document (Wikipedia, 2012).

Normative Information Model-based Systems Analysis and Design (NIMSAD)

NIMSAD is a meta-framework for evaluating methodologies. “Methodology is an explicit way of rationalizing thinking and action through critical and creative thinking” (Jayaratna, 1994, p. xi). NIMSAD evaluates methodologies via four elements; the methodology context, the methodology user, the methodology, and evaluation of the way the methodology evaluates the other three elements (Koskinen, Lintinen, Sivula and Tilus, 2003)

Table 2: NIMSAD Framework (Koskinen, Lintinen, Sivula and Tilus, 2003) NIMSAD elements as represented in (Forsell et al., 1999)| Questions| Methodology Context|

Use situationStart for methodology useCustomers and problem ownersContext descriptionCulture and politics of methodology useRisks in describing contextRisks of methodology| What kind of situations does the methodology suit?Which incidents initiate the use of the methodology?Who are the customers and problem owners?How is the context described?What is the culture and politics of methodology use?What risks does the methodology identify when describing context?What are the risks in using the methodology?| Methodology User|

Users motives and valuesNeeded abstract reasoningNeeded skills| What are the users’ motives and valuesWhat level of abstract reasoning is required from the user of the methodology?What skills does the user of the methodology need to accomplish tasks required in methodology use?| Methodology|

Problem situation and boundariesDiagnosis of situationPrognoses for systemProblem definingDeriving notional systemsDesign (originally: logical and physical design separated)Implementing the design| How does the methodology help in understanding the particular situation and boundary setting?How does the methodology user diagnose what kind of system is needed?How the methodology user makes a prognosis for the system to be built?How the methodology user defines problems that need to be solved?How you get systems that need to be described?Is this phase done? How the methodology user implements this phase?Is this phase described? What is included in it?| Evaluation|

Evaluation (originally: cases before/during/after intervention separated)| How are the other elements (presented by NIMSAD) evaluated?|

Methodology context describes suitable situations where the methodology will be used and what is important in those situations (Koskinen, Lintinen, Sivula and Tilus, 2003). The methodology user is normally the problem solver or decision maker. The methodology describes how it supports the problem solving process. Lastly, evaluation evaluates “how the methodology supports the problem-solving process, that is: problem formulation, possible design of the solution, and actual problem solving” (Koskinen, Lintinen, Sivula and Tilus, 2003).

Methodology Context
Use Situation
SSADM
SSADM is suitable for large projects that have resources in terms of time and money. It is also suitable where requirements are more stable and do not change so much during an ongoing project. It may not be suitable for smaller projects as it is costly and requires a lot of time for implementation and documentation. Typically, this methodology is applied in government sectors.

DSDM
This methodology is suitable for projects that require faster, more flexible and lower cost development of information system. It is suitable for projects which requirements might change ongoing development of the system.

Start of Methodology Use

SSADM
The start of this methodology is a feasibility study. It analyses whether a project is technically possible, financially affordable, compatible with the business’s practices and socially acceptable in the company’s business environment (Wikipedia, 2012). The result of the study is a feasibility study document (Wikipedia, 2012).

DSDM
Like SSADM, the start of this methodology is a feasibility study where risks, project requirements and understanding and suitability of the method to the project are addressed. However, this method also includes a business study.

Customers and Problem Owners

SSADM
The customers and problem owners in SSADM are usually the project managers, information systems manager, software suppliers, stakeholders, etc. However, SSADM does not take into account the mental constructs of users i.e. it does not consider what views each user has on a problem (Sven).

DSDM
All stakeholders are identified in the business study. The business study also describes stakeholder involvement and priority of tasks (UK Essays, 2011). Normally, the customer and problem owners are the project manager, information systems manager, system analyst and other users who are given decision-making rights.

Context Description

SSADM
Problem context is normally described using data flow diagrams and entity relational diagrams. SSADM provides useful tools to project managers and users. These tools such as the ones mentioned before provide description of benefits and cost visibility to Business and IT management as well as users (HKSAR, 2012).

DSDM
An initial problem description may be presented in the feasibility study. However, more specific problems are normally caught and resolved via prototyping where user feedback is essential in making sure that the system satisfies all user requirements.

Culture and Politics of Methodology Use

SSADM
The organizational context has high priority (Sven). It is bureaucratic in nature, hence this methodology is good for an organization with a hierarchical culture. “The parts of organizational culture that SSADM has effect are control, direction, risk tolerance and communication patterns” (Schumacher, 2001-02). DSDM

This method is less bureaucratic and suitable for dynamic development. It is more adaptable where users are empowered i.e. users have decision making privileges.

Risks in Describing Context

SSADM
Since SSADM mainly uses data flow diagrams to describe problems, any irregular and unchanging patterns are normally left out (Sven). Also, SSADM emphasizes on system analysis and documentation that may lead to “over- analyzing, which can be very time and cost consuming (Schumacher, 2001-02).

DSDM
Since this method takes a reiterative approach in prototype development and getting user feedback, the development time span may increase if users do not actually know what they want. This may increase development costs and cause the developed system to no longer be feasible.

Risks of Methodology

SSADM
With large systems, there may be a danger of incurring high cost for systems analysis. Also, since all data flow diagrams have to be included, the resulted “outline diagram can become very unclear” (Schumacher, 2001-02). Furthermore, SSADM may be time consuming i.e. each stage must be completed before the next. Since it is time consuming, there is a danger that the end result “may not meet business requirements at the time it is delivered” (Schumacher, 2001-02).

DSDM
Risks may increase when using this methodology when users/ teams are not empowered to make decisions. It becomes particularly risky and difficult when users do not know what requirements they want. Users must also be actively involved in order for this method to work (Wikipedia, 2012). Changes that are irreversible may also give an adverse effect in this methodology.

Methodology User
User Motives and Values

SSADM
SSADM does not consider the user’s mental constructs. Example, two different users may create two different data flow diagrams for the same problem. (Sven)

DSDM
This approach is heavily based on user feedback. Therefore, mental constructs of users are taken into consideration. Moreover, users are expected to have decision-making responsibilities.

Needed Abstract Reasoning

SSADM
SSADM is considered to be simple for its users.

DSDM
The methodology itself may also be considered to be simple. However, users of this methodology must have technical IT knowledge in order for this method to work.

Needed Skills

SSADM
SSADM does not require high-level skills and may easily be taught. Users may also be expected to have knowledge is using case tools and other modeling and diagramming tools that are used in this methodology

DSDM
Users or development teams are required to have IT technical skills so that they are able to make timely decisions without having to consult management. These skills include knowledge in using IT development and management tools.

Methodology
Problem Situation and Boundaries

SSADM
The system boundaries are defined through a logical design and expressed using a context diagram. The context diagram also shows the external entities that interact with the system and information flows between entities of the system. However, the “system boundaries construction is trial and error within SSADM” (Sven)

DSDM
This methodology uses Moscow rules to classify user requirements into 4; must have, should have, could have and want to have (Wikipedia, 2012). However, system boundaries may not be clearly defined in the beginning phases of this methodology. Hence, defining system boundaries may also be trial and error and becomes clearer as iterative prototyping takes place.

Diagnosis of the Situation

SSADM
Diagnosis is done via data flow diagrams that provide a clear description of data flows. It starts with a description of physical data flow that is then extracted into a logical data model and a logical data flow model (Sven). However, “only regular and frequent patterns get modeled” (Sven) and unique events may not be described.

DSDM
Diagnosis is done through trial and error via an iterative loop of prototype development in the functional modeling phase.

Prognosis of System

SSADM
Prognosis of system may not be well defined in SSADM although Business System Options are developed and each proposed option is evaluated against implications, benefits and costs (Sven). It is assumed that clients know what they want therefore “the rationale of clients desired states are unclear” (Sven).

DSDM
Prognosis is done ongoing system development and is also not clear in earlier development phases. Prototyping allows users to quickly identify or change requirements during system development. Therefore, the developed system is more likely to meet user requirements.

Problem Defining

SSADM
The problem is defined in the feasibility study. However, the problem at this stage remains vague (Sven). Defining problems may become clearer in the requirements specification phase.

DSDM
Problem is vaguely defined in feasibility study and business study. Problem is further defined and quickly resolved throughout the DSDM development process.

Deriving Notional Systems

SSADM
Requirements are formalized through data flow diagrams where functions, processes and user interfaces are defined. A specification prototype may also be developed assuming that the client knows what they want (Sven).

DSDM
The system is derived from functional model iteration and design and build. The outcomes are prototypes that first implements critical functions to identify problems at an early stage of the project. These prototypes may be of a business prototype, usability prototype, performance prototype and (or) capability prototype (AGILE Methods of Software Development, 2011)

Design

SSADM
Design is broken down into logical design and physical design. The logical design is created with data flow diagrams and modifying a logical diagnosis diagram according to requirements and feasibility study (Sven).

SSADM provides generic guidelines for physical design of the system. Design decisions are based on technical issues specific to a chosen environment that is chosen in the Technical System Option phase (Sven).

DSDM
Design is described in a design and build phase. Here, the non-functional requirements are also addressed. A design prototype is identified and developed iteratively, getting user feedback every time. The design prototype is tested against the functional and non-functional requirements (UK Essays, 2011)

Implementation

SSADM
Implementation is not described in SSADM

DSDM
Implementation is described in an implementation phase. The system is tested for user approval and guidelines. After which, users of the system are trained then the system is implemented for end users. Finally, business aspects of the system are reviewed (Wikipedia, 2012).

Evaluation

SSADM
Evaluation is also not described in SSADM

DSDM
Evaluation and testing is done continuously throughout the project. Project viability is evaluated based on business objectives (Wikipedia, 2012). After the DSDM development life cycle, there is a post-project phase that consists of system maintenance, fixes and enhancement. This phase is carried out according to DSDM principles.

More on NIMSAD…

NIMSAD points out that effective problem solving depends on the method being used, the situation the method is applied to and the user of the method (Bielkowicz, Patel, Than Tun, 2002). The evaluation of the method is “treated as a dynamic activity that is carried out before, during and after the application of the method” (Bielkowicz, Patel, Than Tun, 2002).

The framework assumes that a method is a problem-solving process. Methodology user is separated from the methodology context therefore is assumes that the problem description is taken from an external view i.e. the methodology user is not in the problem. “It does not define what constitutes a method and how to compare elements of a method” (Bielkowicz, Patel, Than Tun, 2002). Hence, the “framework may not be suitable for technical and theoretical evaluation of all types of methods e.g. Component-based Development methods” (Bielkowicz, Patel, Than Tun, 2002).

Conclusion

SSADM is more suitable for organizations that are bureaucratic, structured and have resources to keep up to cost and time that the methodology presents. DSDM is more suitable for organizations that empower the methodology users, where the development environment is dynamic and the project requires faster development time and lower costs.

NIMSAD provides a mechanism for a structured and critical evaluation of a method. It takes on a “problem based” evaluation approach and helps to critically analyze the structure, forms and steps of a methodology. However, this framework may not work for all kinds of methods.

References

UK Essays. (2012). A DSDM Outline Plan. Available: http://www.ukessays.com/essays/information-technology/a-dsdm-outline-plan.php. Last accessed 21st November 2012.

AGILE Methods of Software Development. (2011). Dynamic Systems Development Method (DSDM). Available: http://dsdmofagilemethodology.wikidot.com/. Last
accessed 21st November 2012.

UK Essays. (2011). Dynamic Systems Development Method (DSDM).Available: http://www.ukessays.co.uk/essays/information-system/dynamic-system-development-method.php. Last accessed 22nd November 2012.

Marion Schumacher. (2002). The Use of SSADM as a Standard Methodology on Information Systems Projects. Available: http://www.grin.com/en/e-book/106034/the-use-of-ssadm-structured-systems-analysis-and-design-methodology-as#inside. Last accessed 21st November 2012.

Haravtar. (2011). SSADM for Compiled SAAD. Available: http://www.scribd.com/doc/51400525/12/SSADM-Structured-Systems-Analysis-and-Design-Method. Last accessed 21st November 2012.

Diane Strode. (2006). Agile methods: a comparative analysis. Available: http://www.citrenz.ac.nz/conferences/2006/papers/257.pdf. Last accessed 21st November 2012.

Wikipedia. (2012). Dynamic Systems Development Method (DSDM). Available: http://en.wikipedia.org/wiki/Dynamic_systems_development_method. Last accessed 21st November 2012.

Jussi Koskinen, Heikki Lintinen, Henna Sivula, Tero Tilus. (2003). Evaluation of Software Modernization Estimation Methods Using NIMSAD Meta Framework. Eltis Project. 1.0 (1), p1-12.

Sven. (2012). Comparison of Methodologies. Available: https://docs.google.com/viewer?a=v&q=cache:Ow7z1CY5bXcJ:www.dcs.bbk.ac.uk/~sven/cdm07/cdm13.pdf+comparison+of+methodologies&hl=en&gl=ae&pid=bl&srcid=ADGEESjFro1qaU-pBM73gtHVTB7qWQXhtWmuXxhXK3CNqwQj5Ey. Last accessed 21st November 2012.

Peter Bielkowicz, Preeti Patel and Thein Than Tun. (2002). Evaluating Information Systems Development Methods: A New Framework. Available: