SDLC – Traditional Waterfall Approach to IS development: Emphasis on sequential activities Pre-defined detailed deliverables Separation of users from IT specialists Criticised for delivering systems that are: Over budget Over schedule Not what users need Exacerbate the ‘culture gap’ DSDM 1997 (Dynamic Systems Development Method - Standard 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 RAD Potential Strengths: Better Client-Developer communication & collaboration Encouraging change of mind by clients allowing systems to evolve through changing business environment/client perspective Encouraging an effective learning environment for both developers & users Increasing client confidence Facilitating earlier & more testing Providing the potential for cost reductions Reducing the deadline effect Facilitating better interfaces Reducing risk Motivating users and developers Potential Weaknesses: Management problems Lack of control Raised user expectations Selecting & motivating the right users & developers Not viewing RAD as a fundamental change in approach, attitude & philosophy Notes from Avison & Fitzgerald (1995) What is prototyping? “A prototype is an approximation of a type that exhibits the essential features of the final version of that type” ‘uses system development tools in bid to improve requirements analysis’ “what the users wants is what they get” Avison & Fitzgerald (1994) prototyping can be seen as improved form of system investigation & analysis & an aid to design Why use prototyping? It addresses some of the problems of traditional Systems Analysis (ie. users only saw IS’s at implementation stage) Is a response to the user dissatisfaction found when using the trad. Approach to IS dev. Allows Analyst to show users something: Tangible Inputs Intermediary stages Outputs Before committing user to new design When to use prototyping? Prototyping can be seen as improved form of systems investigation & analysis & an aid to design Particularly useful when: The application area is not well defined The organisation is not familiar with the technical h/ware, s/ware, communication, design etc. The communications between analysts & users are not good The cost of rejection by users would be v. high & it is essential to ensure that the final version has got users’ needs right There is a requirement to assess the impact of prospective IS’s When to use prototyping? By analysts to examine areas where they are unsure of user requirements or Where they are unsure how to build the system Some analysts recommend that only the most critical aspects of a new system should be prototyped Prototyping could be used as a basis for a methodology of system development in the organisation – this may have: An analysis phase (designed to understand the present system & suggest the functional requirements of an alternative system) A prototyping phase (to construct a prototype for evaluation by users) A set of evaluation & prototype modification stages A phase to design & develop the target system using the prototype as part of the spec. Many prototypes are intended to be discarded – not designed to be used as operational systems as they are likely to be: Inefficient Incomplete Poorly documented Unsuitable for integration with other operational systems Incapable of holding the no. of records necessary Inadequate, being designed for one type of user only Here they are used as a development tool – a learning vehicle An alternative approach – to use final prototype as the basis for the operational system – where IS ‘evolves’ by an iterative process. “one of the necessary components of successful prototyping is management and control so as to ensure that compromises are not made and the process of repeated iteration does not go on too long” (Avison & Wilson, 1991) IS may be developed in stages: At each stage the missing components are those which give the poorest ratio of benefits over costs Problems: Users may question the long time required to develop an operational system – when little time taken to produce prototype Users may argue that time, effort, money used to develop a prototype is ‘wasted’ Analysts tempted to move quickly on to development phase before sufficient analysis carried out Prototyping Was expensive – but changed with availability of software tools Encourages a degree of user participation Enable users & analysts to ‘act out’ the future system Rapid Application Development (RAD) The goal is to speed up the development process Martin, (1991) suggests RAD is an example of an approach that uses prototyping as part of an overall methodology RAD – based on: Evolutionary, prototyping approach Enabled by CASE tools & system repositories Why RAD? As a need to develop IS’s more quickly Driven by ‘changing business requirements’ General environment of business seen as competitive More customer focused & operating in international context Business environment characterised by continuous change IS’s in organisation – need to be created & amended quickly to support these changes RAD – a combination of techniques & tools Not based on trad. Life cycle – but adopts evolutionary/prototyping approach Focuses on identifying important users & involving them in workshops at early development stage Focuses on obtaining commitment from the business users Requires CASE tool with sophisticated repository RAD has 4 phases: Requirements planning User design Construction Cutover Requirements – 2 techniques JRP Joint requirements planning (identify high level mgmt. requirements of system at ‘strategic level’ Participants – senior managers (vision & understanding of overall objectives of system – how can contribute to goals & strategy of organisation) Workshops To identify priorities To eliminate unnecessary functions Joint application design (JAD) Main technique of user design phase (analysis & design) User design achieved by right environment, use of good prototyping tools Prototyping tools allow quick exploration of processes: Interfaces Reports Screens Dialogues User design dev. Using 4 diagramming techniques: entity modelling: Functional decomposition DFD’s Action diagrams RAD uses automated tools reusable parts small teams – user involvement Therefore IS’s implemented at: lower cost higher quality increased speed meeting needs of business leading to lower maintenance costs ‘the emphasis is on getting the requirements as correct as possible & to reflect the business needs’ In UK – RAD users & suppliers group – formed consortium to define standards & framework for RAD ‘Dynamic Systems Development Method’ (DSDM) CASE tools: check internal consistency enable speedy, accurate & effective transfer of results Cutover: comprehensive testing users are trained organisational changes implied by system are implemented running old & new in parallel RAD adopts evolutionary or timebox approach to development & implementation ‘timebox’ approach contrasts with trad. Approach where every conceivable requirement is implemented together & resulting complexity often causes long delays in implementation