Prototyping and Rapid Contents Application Development (RAD) Definitions 2 steps forward, 1 step back? Anecdotal advantages! Anecdotal problems! Jeremy Reece - School of Computing Survey evidence University of Wolverhampton Our experiences Summary email: [email protected] References Prototyping and Rapid Prototyping and Rapid Application Application Development (RAD) 1 Development (RAD) 2 RAD - Background What is RAD Topical in 1990’s after RAD is Book Rapid Application Development by Martin, J (1991) a complete methodology covering systems development from business requirements to ongoing development (not Became latest buzz phrase maintenance) Further books Support tools to facilitate it a ‘tool kit’ methodology DSDM consortium of leading industrial names Open, can be adapted to projects, individual and organisational philosophy have produced a RAD method Many techniques used have been around for a long time can utilise a wide range of techniques and tools recently brought forward as solutions to IS problems. Prototyping and Rapid Application Prototyping and Rapid Application Development (RAD) 3 Development (RAD) 4 1 RAD - Goals RAD - Quality Radically changes way systems are developed with goals The definition of quality in a RAD environment is put well by of. James Martin High quality systems “meeting the true business (or user) requirements as fast development and delivery effectively as possible at the time the system comes into low costs operation” High High (Martin 1991) These should Speed Quality go hand in hand as opposed to: when the right tools Low and techniques are used Cost “conforming to the written specification as effectively as Martin, J.1991 possible” (Martin 1991) Prototyping and Rapid Application Prototyping and Rapid Application Development (RAD) 5 Development (RAD) 6 RAD - Properties RAD - Cost Does away with the concept of a frozen specification Emphasis placed on low cost All developments should be cost effective though Place emphasis on user involvement and identified as potential expensive option in terms of up front investment (Graham 1995a) responsibility throughout whole development Organisation may pay more for a quality system in a Properties shorter time-scale ⌧Must be delivered in 2 - 6 months ⌧split into increments if too large to enable this, ⌧each increment is implemented separately with frequent delivery of Evidence all goals are achievable including lowering of working parts of system. costs (Goodwin 1993) Prototyping and Rapid Application Prototyping and Rapid Application Development (RAD) 7 Development (RAD) 8 2 Rapid Development RAD - Traditional Methodologies Rapid Development Goals of RAD diametrically opposed to more traditional methodologies which adopt a waterfall model Small Teams Reusable parts Automated tools User Involvement Although quality and speed of delivery are paramount, does not mean what is good in traditional system Lower Cost Higher Meets business development is thrown away. There must be Quality needs better Effective project management testing appropriate up to date documentation quality assurance Lower maintenance requirements specification designs costs appropriate maintainability reuse etc Rapid development, high quality and lower costs go hand in hand if an appropriate development methodology is used, Martin 1991 Prototyping and Rapid Application Prototyping and Rapid Application Development (RAD) 9 Development (RAD) 10 RAD - Traditional Methodologies RAD - Applicability to (Cont’d) Organisations DSDM manual (1995) emphasises systems must be build RAD is more applicable to organisations because on sound s/w engineering principles World market place is competitive, need right system at the right time to get competitive edge Organisations are dynamic and evolving, requirements change Key difference as a system is built, a frozen specifications become outdated these issues are not allowed to dominate business requirements IT now viewed as a cost centre not a resource, once system and speed of delivery delivered it starts earning money must be appropriate to project needs Systems are used by users, if jointly developed by users then e.g. a system with a lifetime of 3 months shouldn’t take 18 more likely to be accepted months to develop Prototyping and Rapid Application Prototyping and Rapid Application Development (RAD) 11 Development (RAD) 12 3 The DSDM View DSDM Principles A product based view of development is more flexible Development teams - consist of developers and users than an activity based view who are empowered to make decisions Business requirements paramount Interactive development is important to developing Developers and users communicate closely through systems rapidly iterative development involving prototypes Change is encouraged and is reversible Rapid application development must involve user All involved must be highly skilled and motivated involvement towards business objectives Testing is done throughout development and reviewed An attempt to provide a framework/method (DSDM 1995) by whole team Prototyping and Rapid Application Prototyping and Rapid Application Development (RAD) 13 Development (RAD) 14 DSDM Principles (Cont’d) RAD - Usage Larger projects - frequent deliverables should be May be based upon tools and techniques found in other scheduled methodologies High level scope and purpose of the system should be Hence can be superimposed on existing skills agreed and fixed early in development although easier for some than others Relationship between vendor and purchaser must be Goals and Principles enforce changes in one of co-operation. project structure project management team organisation and motivation philosophy and working practice All left is modeling tools and some techniques Prototyping and Rapid Application Prototyping and Rapid Application Development (RAD) 15 Development (RAD) 16 4 RAD - Essentials RAD - Project Structure Tools Main changes are Code generators, CASE tools, prototyping tools and 4GLs Rapid Business Analysis Methodology Reduced timescale to identify business requirements making the to use tools as effectively as possible use of JAD workshops People Business requirements and systems analysis are undertaken in a fundamentally different way right skills and talents. Well selected and motivated. End users After feasibility study and appropriate research we have a JAD Management workshop not place obstacles, facilitate fast development Incremental Delivery Infrastructure Iterative development in conjunction with users involving In which fast development can take place prototyping and frequent delivery of working products Prototyping and Rapid Application Prototyping and Rapid Application Development (RAD) 17 Development (RAD) 18 RAD - Rapid Business Analysis JAD Workshop RAPID BUSINESS ANALYSIS Takes place away from business environment Produces business requirements, fully documented after PRODUCTS: PEOPLE: Initial Planning 3 to 5 days Business objective Users Work under the direction of facilitator who must be Project Manager Scope Workshop facilitator Business Requirements Analysis Outline business highly skilled to ensure Modeling expert requirements all issues discovered, refined and reviewed and Scribe Scoping Priorities all political difficulties resolved users and developers have equal influence Joint Application Development Workshop Aim is as much to get common purpose as obtaining system requirements and business objectives Strict Deadline (Timebox) Prototyping and Rapid Application Prototyping and Rapid Application Development (RAD) 19 Development (RAD) 20 5 RAD - Iterative development RAD - Iterative Development INCREMENT The other fundamental change iterative (or Build prototypes Review prototypes evolutionary) development involves prototyping Change management PRODUCTS: Prototyping has been around for a long time (early 80s) PEOPLE: Delivered increment Users Dynamic priorities Research on has identified trends in prototyping towards with all necessary Project Manager Prototype evolves into product documentation to better meeting of requirements Developers (SWAT User documentation user satisfaction cheaper cost of production team) Technical documentation (priorities) Testing ‘Gold plating’ - developer introduced features, which are not asked for Quality assurance ⌧with undergraduate developments, Prototyping Iteration ⌧not found in iterative prototyping were developers in Strict Deadline (Timebox) communication and tune with users and there priorities REPEAT for as many increments as appropriate with strict deadlines Prototyping and Rapid Application Prototyping and Rapid Application Development (RAD) 21 Development (RAD) 22 Prototyping Prototyping However Crinnion states that there are now two “As prototyping has become more widely written about the generally accepted forms: number of definitions of what it actually represents has Throw away substantially increased”. (Crinnion 1992). Incremental (or evolutionary) These definitions seem to have become the de facto standards, although alternatives are still often quoted This is a bit of a problem! We use the definition that prototyping takes place during any activity where clients and developers review and refine systems by use of working software Prototyping and Rapid Application Prototyping and Rapid Application Development (RAD) 23 Development (RAD) 24 6 Prototyping is Essential to RAD Prototyping The characteristics if prototyping can be summarised as Prototyping is not a panacea, Involves