COM332 – SA3

RAD Overview

DSDM

• RAD developed as a reaction to the problems of traditional development– Problems of long development lead times– Problems associated with changing and

evolving requirements during the development process

• An Overview of RAD– A complete methodology– Covering systems development

• From business requirements to ongoing development (maintenance)– A ‘tool kit’ methodology– Adaptable to different projects– Can utilise wide range of techniques & tools– Places emphasis on user involvement & responsibility throughout

development– Properties of rapid must be defined– Delivered in anything from 2-6mths– When project too large – split into – Increments

• Each increment implemented separately with frequent delivery of working parts of system

– Aim of development to be cost effective– User quality & speed of delivery paramount– Quality of systems must be maintained– Need effective project management– Need appropriate up to date:

o Documentationo testingo quality assuranceo requirements specs., o designso maintainabilityo reuse

• A RAD approach is more applicable to many organisations for the following reasons:– business operates in increasingly competitive world market

place • right systems at right time provide competitive edge

– business organisations are dynamic & evolving• requirements may change as system being built

– IT now viewed as cost centre as opposed to a resource• Systems delivered early can start saving or earning money

sooner– Systems operate in the social & political environment of

organisation• system jointly developed by users then is more likely to be

accepted

• Characteristics of RAD– Incremental development– Timeboxing– The Pareto principle– MoSCoW rules– JAD workshops– Prototyping – Sponsor and Champion– Toolsets

• Incremental development– Important element of RAD philosophy

• Not all systems requirements can be identified and specified in advance

• Some requirements will only emerge when the users see and experience the system

• Requirements are never seen as complete but evolve and change over time with changing circumstances

• Why waste time?– RAD starts with a high level imprecise list of

requirements• Refines and changed during the process

– RAD identifies the easy, obvious requirements and in conjunction with 80/20 rule just uses this as the starting point, recognising the future iterations or timeboxes can handle the evolving requirements.

• Timeboxing• An agreed period of time in which task (stage) is to

be completed• Sometimes cost or functionality has to be

compromised to meet time deadline• Deadline for each timebox is fixed & cannot be

moved • Project is broken down into series of timeboxes

• Each results in delivery of working functionality• Users can receive their portion of new system when

required• Timeboxing leads to frequent phased delivery of

products to end users

– Feasibility study and requirements gathering

• System then broken down into timeboxes with each functional area occupying a timebox of its own

• JRP workshop decides which phases are critical to launch a system – rest of system has to be in place not later than 1 month after launch

• If functionality not ready for the release – it will go ahead without missing element

• Functional prototyping stage will therefore include its own prioritisation to recognise what is critical & what can be safely deferred to later delivery of software

• The timebox can only work satisfactorily if 2 conditions met– Development team includes a user representative

who is on hand to make & criticise design decisions & test development as it proceeds

– Timebox assumes that time is fixed & functionality is variable

– This is culture change for most users who expect functionality to be fixed & time (within reason) to be variable

• Development team must include a user who recognises this & can explain the concept to other users

• Development conducted using a prototyping tool to support models & convert these models to full working systems

• The Pareto principle– 80/20 rule– Around 80% of the system requirements can be

delivered with around 20% of the effort needed to complete 100% of the requirements.

• MoSCow rule– The Must haves

• without these features the project is not viable– The Should haves

• To gain maximum benefit these features will be delivered, but the project’s success does not rely on them

– The Could haves• If time and resource allow these features could be

delivered– The Won’t haves

• These features will not be delivered

• JAD workshops– Key users, client, developers and scribe produce

system scope & business requirements under direction of a facilitator

– Takes place away from business environment– Must come up with business requirements fully

documented (3-5 working days)– Facilitator has to be skilled in running workshop

(ensure all issues covered)– Need to obtain a common purpose– Facilitator must ensure that client & users are fully

involved & developers do not dominate workshop• This can eliminate months of Analysis in the

traditional development

– The key element is that developers must have powerful software development tools to rapidly develop systems to sufficient software quality

• Structure of RAD projects– Reduced time scales for deriving business

requirements including use of JAD workshops– Iterative development in conjunction with users

involving prototyping & frequent delivery of working products

– Business requirements analysis & systems analysis undertaken in fundamentally different way

– After feasibility study & appropriate research & preparation into application a Joint Application Design (JAD) workshop held

DSDM

• Despite the proposed advantages RAD approach has been criticised as “quick but dirty”– Some shortcuts are taken for the sake of speed

• In 1994 group of systems developers interested in RAD formed a consortium

• They believed RAD should not only be rapid but also disciplined and high quality

Av & Fitz’s (2003)

• The consortium defines – RAD as a project delivery framework that actually

works. • It aids the development and delivery of

business solutions in tight timescales and fixed budgets.– First published in 1995– Second version in the same year– Version 3 in 1997– In 2000 eDSDM - tailored version of DSDM for

organisation and projects undertaking e-business initiatives.

– Version 4 is introduced in 2001 described as a frame work for business centred development.

– Most recent version is 4.2

• DSDM– Framework not a methodology

• Details on how things to be done and what the various products will contain is left to the organisation or the individual to decide

• Does not prescribe tools & techniques• Serves as high-level project mgmt.

framework for RAD

• There are nine principles for DSDM, all are critical for the project success – Active user involvement– DSDM teams must be empowered to make

decisions– Focus on frequent delivery of products– Fitness for business purpose is the essential

criteria for acceptance of deliverables– Iterative & incremental development necessary to

converge on an accurate business solution– Changes during development are reversible– Requirements are baselined at a high level– Testing integrated throughout the life cycle– A collaborative & co-operative approach between

all stakeholders is essential

• DSDM defines five phases for the development

• Feasibility study and business study are carried out sequentially and prior to other phases

• The sequence and overlapping for the rest of the phases are left to the organisation– Feasibility study

• Includes the normal feasibility elements, the cost/benefit case etc.

• Also concerned with determining whether DSDM is the right approach

– Business study• Quick and high level• Gaining an understanding of the business

– Functional model iteration• High level functions and information requirements from

business study are refined. • Standards analysis models are produced followed by the

development of prototype and then the software

– System design and build iteration• System is built ready for delivery to the users including

the minimum usable subset of requirements.

– Implementation• Cut over from the existing system or the environment to

the new. Includes training, development and completion of the user manuals and documentation

• Project review document is produced which assesses whether all the requirement have been met or whether further iterations or timeboxes are required.

Classifying and comparing methodologies

• Avison & Fitzgerald’s categories (2003)– Process-oriented methodologies

• Examples: STRADIS, YSM (Yourdon), JS– Blended methodologies

• Examples: SSADM, Merise, IE, Welti ERP– Object-oriented methodologies

• Examples: OOA, RUP– Rapid development methodologies

• Examples: JMRAD (James Martin), DSDM, XP, WiSDM– People-oriented methodologies

• Examples: ETHICS, KADS, CommonKADS– Organisational-oriented methodologies

• Example: SSM, ISAC, PI, PRINCE, Renaissance– Frameworks

• Example: Multiview, SODA, CMM, Euromethod

• Bansler’s “Three theoretical schools” (1989)– Systems-theoretical

• Knowledge interest: Profit maximisation• Organisation: Cybernetic system• Labour force: System components• Labour relations: Common interest

– (characterised by ISAC)– Socio-technical:

• Knowledge interest: Job satisfaction (participation)• Organisation: Socio-technical system• Labour force: Individuals• Labour relations:Common interest

– (characterised by ETHICS)– Critical

• Knowledge interest: Industrial democracy• Organisation: Framework for conflicts• Labour force: Groups• Labour relations:Opposing interests

– (characterised by “Scandinavian approaches” historical examples) 

Comparing Methodologies

• Two main reasons for comparing methodologies– Academic reason – better understanding of

the nature of the methodologies– Practical reason – choosing a

methodology, a part of one or a number of methodology for a particular application 

• Few of the ideal type criteria for assessing methodologies– Rules: methodology should provide formal guidelines to cover

phases, tasks, deliverables etc– Total coverage: methodology should cover the entire system

development process– Understanding the information resource: effective utilisation of data

available and processes which need to make use of the data– Ongoing relevance: methodology should be capable of being

extended so that new techniques and tools can be incorporated– Automated development aids: where possible use software tools to

enhance productivity– Consideration of user goals and objectives: to satisfy the users– Participation: encourage participation through simplicity and ability

to facilitate good communication– Relevance to practitioner: appropriate to the practitioner using it, in

terms of level of knowledge, experience with computer, and social and communication skills

– Relevance to application: must be appropriate to the type of the system being developed

• Comparison frame works– Bjorn-Andersen (1984) checklist includes criteria

relating to values and society– Jayaratna’s comparative framework (NIMSAD)

(1994)• Jayaratna’s framework is based on the models and the

epistemology of system thinking. • The evaluation has three elements

• The problem situation or methodology context• The intended problem-solver or methodology user• The problem-solving process - the methodology itself

• the problem situation– Because

• effectiveness of systems measured against contribution to information users in org

• developers need to interact with members of org• this is the area where methodology users are introduced

to the problem as seen by the client• and where interpersonal relationships are formed.

– Ask how does the methodology helps

• intended problem–solver – Ask

• why does the ips select some elements of action world as relevant/significant/useful, regard others as irrelevant/insignificant/useless

• how do they select or abstract elements of the action world

• what are the implications of this selection?

• the problem-solving process– Phase 1 Problem formulation

• Stage 1 understanding the situation of concern• Stage 2 performing the diagnosis (where are we now?)• Stage 3 defining the prognosis outline (where do we

want to be and why?)• Stage 4 defining problems• Stage 5 deriving notional systems

– Phase 2 Solution design• Stage 6 performing conceptual/logical design• Stage 7 performing physical design

– Phase 3 Design implementation• Stage 8 implementing the designs

• One feature of this frame work is it recommends the evaluation conducted at three stages– before intervention- before a methodology

is adopted– during intervention - during use– after intervention – assessment of success

• The best methodology cannot be find in isolation, the search for an appropriate methodology should be done in the context of the problem being addressed, the application and the organisation and its culture.

• Practical problems in comparing methodologies– Methodologies are not stable, they are continuing to develop

and evolve– Commercial reason – the documents are not always

published or readily available to the public– The practice of methodology in sometimes significantly

different form what is prescribed by the documentation– The consultants or the developers using the methodology

interpret the concepts in different way.

• Framework– Comparing methodology is a very difficult task. – This framework is not supposed to be fully comprehensive.

– This framework has seven basic elements

1. Philosophy a. Paradigm b. Objectivesc. Domaind. Target

2. Model3. Techniques and tools4. Scope5. Outputs6. Practice

a. Backgroundb. User basec. Participants

7. Product

• Philosophy– Philosophy distinguishes methodology from a

method. – The choice of the area covered by the

methodology, the systems, data or people orientation, the bias towards purely IT based solution are made on the basis of philosophy of the methodology.

– Philosophy is the principle or the set of principles that underlie the methodology

– There are four factors to the philosophy• Paradigm• Objectives• Domain• Target  

• Paradigm – “A specific way of thinking about problems,

encompassing a set of achievements which are acknowledged as the foundation of further practice”. Kuhn (1962)

– Science paradigm – characterised by the hard scientific development

– Consists of• Reductionalism• Repeatability• Refutation

– System paradigm – characterised b y the holistic approach

• Human activity system.• Characterised by the emergent properties (whole is

greater than the sum of the parts)

• Objectives– One direct clue to the methodology philosophy is

stated objective or objectives.– Build a computerised information system– Discover whether there is a need for an

information system– Determine the boundaries of the area of

interests. • Domain

– Domain of situations that the methodology addresses.  

• Target – Applicability of the methodology. – Some are specially targeted for specific problems

while others are general purpose.

• Model– Model is the basis of the methodologies view of

the world– Abstraction and representation of the importance

factors of information system or organisation.– The model works at number of different levels

• The means of communication – pictorial, iconic or schematic

• As a way of capturing the essence of the problem or design

• Representation which provides and insight to the problem area

• Techniques and tools– Identify the techniques and tools used in a

methodology

• Scope – Scope is the indication of the stages of the life

cycle of system development which the methodology covers.

• Outputs– What the methodology is producing in terms of

deliverables

• Practise– Methodology background

• Commercial• Academic

– The user base• The participants in the methodology and their skill

levels

• Product– What the purchasers actually get for their

money• Software• Written documentation• Training• Telephone help line• Consultancy