COM332 – SA3

1. COM332 – SA3 RAD Overview DSDM

2. 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

3. 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: • Documentation • testing • quality assurance • requirements specs., • designs • maintainability • reuse

4. 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

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

6. 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.

7. 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

8. 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

9. 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

10. 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

11. 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

12. The key element is that developers must have powerful software development toolsto rapidly develop systems to sufficient software quality

13. 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

14. 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)

15. 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

16. 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

17. 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

18. 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

19. 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.

20. 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

21. 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) 

22. 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 

23. 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

24. 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

25. 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

26. 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?

27. 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

28. 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

29. 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.

30. Framework • Comparing methodology is a very difficult task. • This framework is not supposed to be fully comprehensive. • This framework has seven basic elements • Philosophy • Paradigm • Objectives • Domain • Target • Model • Techniques and tools • Scope • Outputs • Practice • Background • User base • Participants • Product

31. 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  

32. 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)

33. 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.

34. 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

35. 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

36. Product • What the purchasers actually get for their money • Software • Written documentation • Training • Telephone help line • Consultancy