210 likes | 454 Views
RAD and Prototyping. Trends in Systems Development. Workers have found many new ways to use the computer to perform jobs in a more efficient manner. The information systems (IS) departments in many organizations were overwhelmed by users' demands for additional services.
E N D
Trends in Systems Development • Workers have found many new ways to use the computer to perform jobs in a more efficient manner. • The information systems (IS) departments in many organizations were overwhelmed by users' demands for additional services. • A backlog of jobs that were awaiting action from the IS department was created, with some jobs waiting for over a year to be complete. • Projects were often out of date by the time they were completed. • An invisible backlog of jobs that were not even submitted to the IS department was created
Problems with SAD • SAD Methods were inadequate in terms of both speed and capability to creating newer types of information systems • In terms of speed, SAD could not keep up with demand for new systems • Dupont stated that: "It is speed that is the determining factor in most competitive situations." • If it takes Corporation A 3 years to create a competitive IS and Corporation B 6 months to do the same thing, Corp B is going to WIN!
Creating New Types of ISs • In term of new types of IS, SAD methods were not always adequate for creating DSS, EIS, Expert Systems and electronic commerce systems. • This was precipitated by the SAD requirement that users clearly define their needs before the beginning of the development process. • However, in the case of DSS, EIS, ES, and EComm users may not be able to clearly define their needs prior to the beginning of the project.
User Problems with IS • Users cannot obtain apps when they need them. Often a delay of several years. • Difficult or impossible to obtain needed changes in reasonable amount of time. • IS Development is bottleneck the prevents increased competiveness • Programs are buggy or do not work • Systems do not meet true user requirements • Requirements often change after specifications have been frozen • Systems cost more to develop and maintain than anticpated • Development process is not dynamic
Rapid Application Development • RAD refers to a systems development process designed to provide much faster development and high quality results at a lower cost than SAD. • RAD = Speed + Quality + Lower Cost • Quality in system development means meeting the true business requirements as effectively as possible at the time the system comes into operation • Types of RAD • I-CASE (Martin) • Code generators • 4GLs (OASIS) • Prototyping tools (VB and Access) • In all cases, small teams are an important feature
RAD Goals High Speed High Quality Low Cost
Features of RAD • Fleixble: Fully adaptable to circumstances • Computerized: Minimizes manual work • Non-bureaucratic: assumes developers are intelligent and creative • Understandable: Makes good sense to developers and users alike • Involves learning: both developers and users are constantly learning during development process • Quote: "The last act of a dying regime is to create a vast, unchangeable procedures manual!"
RAD Lifecycle (Martin) • Requirements Planning Phase • users determine functions of system • User Design Phase • users participate strongly in nontechnical design of system (JAD teams) • Construction Phase • system is interactively developed by design team • Cutover Phase • system is implemented in parallel with some parts of construction
Prototyping • Prototyping is a technique for building a quick and rough version of a desired system or parts of a system • Allows users to try out the system and detect problems or flaws • Prototypes are very useful when the information requirements are not fully understood • Prototype can be used to explore and solidify the functions and design
Features of Prototyping 1. Users learning about information requirements is built into the design process 2. Development is an iterative process with short intervals between system versions and rapid feedback from the user. The emphasis is on speed. 3. The user is closely involved in the development process. 4. The initial prototype has a low cost that does not require justification. 5. With the iterative nature of prototyping and the feedback it provides, management develops information requirements while seeing what a new system can do.
Types of Prototypes 1. Mockup or demo prototype (See User-Interface Prototyping) 2. Interactive prototype (See Throwaway prototyping) 3. Working model prototype (See Evolutionary Prototyping) 4. Production model prototype
Prototyping Process 1. Developer identifies user's problem through discussions with user and determines if a system that solves the problems is possible and feasible. 2. Working prototyping is developed for a key element of system. 3. User works with prototype, learns more about information requirements, and provides feedback to developer, who refines and enhances the prototype until it meets user's information requirements. 4. The prototype is either implemented or used as a model for the implementation phase of the structured process. 5. Information system is maintained.
Advantages of Prototyping • Users understand and react to prototypes far better than with paper specifications • Usually quicker to build prototype than paper specs. • Reality testing is introduced into project at early stage. • Prototyping can help avoid systems with inadequate or wrong features. • It encourages creative input from users • It enables errors and weaknesses to be caught before expensive design and programming are done.
Dangers with Prototyping • Quick, rough design may replace well-thoughout design • Prototype may encourage users to change minds about requirements--prototype may never converge! • Users expectations may be too high • Users may not want to go from prototype to production system--may want to keep prototype • User may not work hard enough to identify flaws in prototype
Evolutionary Prototyping • Trades a reduction in project control for increased end-user and customer feedback and for better progress visibility • Can be combined with User-Interface Prototyping and Throwaway prototyping • Can serve as basis for further design • Start at most visible or most risky part--usually user interface • For technical projects, start at database • Best for business systems in which developer has interaction with end user
Problems with Evolutionary Prototyping • Unrealistic schedule and budget expectations • Diminished project control • Poor end-user or customer feed back • Poor product performance • Unrealistic expectations • Poor design or maintainability • Feature creep • Inefficient use of prototyping time
Keys to Success of Evolutionary Prototyping • Decide early whether to evolve or throwaway • Closely manage customer or end user expectations and the prototyping activity • Limit end-user interaction to controlled settings • Use design checklists to ensure quality • Consider performance early
Throw Away Prototyping • Develop code to explore factors critical to the system’s success and then throw it away! • Use languages or practices that are much faster than target languages and practices • User interface is commonly prototyped • Use as a systems specification aid to speed waterfall method • Has great use for risk reduction!!! • Good for training inexperienced programmers since code is thrown away!
Risks of Throwaway Prototyping • Keeping the throwaway • Inefficient use of prototyping time • Unrealistic schedule and budget expectations
User-Interface Prototyping • User-interface is developed quickly to explore its design and systems requirements • Can use special prototyping languages or target language • Prototype can be developed or thrown away • Can use user-interface programming in proposal phase • Same as Demo Prototype discussed earlier