Software is one of the two principle obstacles to economic progress. WSJ

1. �Software is one of the two principle obstacles to economic progress. WSJ �If anything kills us before the Russians, it will be our software.� Former US Pentagon chief

2. Addressing the Software Crisis Reduce software development problems Improve effectiveness of development Provide software on time & to budget Meet vague & uncertain user specifications Reduce the use of paper-based documentation Increase the use of computer-based design

3. RAD Rapid Application Development

4. Outline Overview of RAD Variation Elements Reasons to utilize Methodology 4 Phases Views on RAD What RAD in NOT Dis/advantages Implememtation Un/successful Industry Business Architecture Utlizers Success Stories Future of RAD Conclusion Sterling Software

5. Outline Overview of RAD Variations Philosophy Methodology Buzzwords Structure Elements Reasons to utilize

6. Variations of RAD Philosophy Methodology Buzzword Prototyping RAD-ready CASE tool

7. Variations of RAD Philosophy Focus on Speed & Flexibility Well defined project scope Expected deliverables & delivery date Developers & customers required to participate Negotiate requirements Test deliverables Intense involvement

8. Variations of RAD  Methodology 4 Main Components JAD CASE implementation Data libraries / software re-use Timeboxing

9. Variations of RAD Buzzword Reports of spectacular success Has come to mean anything that assists in building applications quickly Methodology but not a strict definition of it Associated with emerging technologies particularly OO

10. DSDM - 1995 Dynamic Systems Development Method Reaction to increased interest Membership of developers & vendors Produce a standard generic framework Reduce uncertainties

11. What is RAD ? Products developed faster & of higher quality Gathering requirements through workshops or focus groups Prototyping and early, reiterative user testing of designs Re-use of software components A rigidly paced schedule Less formality in team communication Embraces OO programming methodology

12. RAD Structure

13. Essential Elements People Management Methodology Tools UC, Davis

14. Essential ElementsPeople Generally teams of six people Multi-talented analyst, designers, & programmers High-level communication skills Remain together from start to finish Teams must work together from project to project (a new teams often fail)

15. Essential ElementsManagement Developers Need a highly qualified project manger Client Commitment for high-level management

16. Essential Elements Methodology 4 Main Components JAD CASE implementation Data libraries / software re-use Timeboxing

17. Essential ElementsTools Sterling CASE tools Visual Basic Visual C Delphi Visual Foxpro

18. So Why Use RAD?

19. Reasons to Use RAD Limit a project�s exposure to the forces of change Save development time possibility at the expense of economy or product quality Converge early toward a design Acceptable to the customer Feasible for the developers

20. Bad Reasons to Use RAD Prevent cost overruns RAD teams must already be disciplined in cost management Prevent runaway schedules RAD teams must already be disciplined in time management

21. Outline Methodology Waterfall 4 Phases Requirements User Design Construction Cut-over

23. Waterfall - disadvantages Rigidly scheduled phase after phase of requirements collection, design, development Delivery of system sometimes years later

24. Problem with Waterfall Waterfall process is self-defeating �� the business problems are constantly changing. We don�t want to get overly dug into a total solution and not be able to change to take advantage of new situations� John Mittelstadt, Director of Corporate Software, ReliaStar Financial Corp

25.

26. 4 Phases of RAD Requirements Planning Phase User Design Phase Construction Phase Cut-over Phase

27. 4 Phases of RADRequirements Planning Phase 1st phase 1 - 4 weeks Outline of system area Definition of the system scope �Information Repository� Timeboxing UC, Davis

28.  Timeboxing Most innovative aspect of RAD Time limits set for each element of the product must be developed & clearly defined in the project plan. Secondary features are dropped as necessary to stay on schedule Non-extendable

29. Requirements Planning PhaseEssential Components High level or knowledgeable end-users Right users & executives Structured discussion of business problems JRP Joint Requirements Planning workshop

30. 4 Phases of RADRequirements Planning Phase

31. 4 Phases of RADUser Design Phase 2nd phase 3 - 5 weeks Detailed system area model Outline system design Implementation plan UC, Davis

32. 4 Phases of RADUser Design Phase Requires users in non-technical design Guidance of IS professionals JAD sessions Joint Application Design Users & executives play larger role Prototying Aid in requirements specification & design Users sign off a CASE representation

33. User Design PhasePrototyping Non-technical users mold the application in progress Built-in part of db interfile relationships integrity constraints business rules Intermittently test the work-in-progress Morton, Carole ..

34. 4 Phases of RADConstruction Phase 3rd phase User Design Phase is added using I-CASE tools Code optimizers improve generated code End user approves each transaction revision as needed Interim testing throughout Construction Phase

35. 4 Phases of RADCut-over Phase 4th phase Comprehensive testing End user training Organizational changes Parallel implementation with previous system

36. Lifecycle Comparison Table

37. RAD vs. Waterfall Waterfall methodology �� designed to be more robust, to have an existence to themselves, and you slot people in � � Project Manger

38. Outline Views on RAD What RAD in NOT Dis / advantages Implementation Un / successful Addressing Problems Negotiating the Pace

39. What RAD is not ! A new concept QADAD Quick and Dirty Application Development RAD-lite All-out RAD Just buying case tools

40. What RAD is NotThe Origins of RAD Spiral model (Barry Boehm) Evolutionary life cycle (Tom Gilb) Concept of RAD methodology Dupont (mid-80s) Rapid Iterative Production Prototyping (RIPP) RAD coined by James Martin 1991

41. What RAD is Not QADAD Scenarios of impossible deadlines Management focused only on speed Willingness to sacrifice structure & methodology Used as excuse for eliminating design

42. What RAD is Not QADAD - Problems Focus on speed produces ad hoc development practices Applications with little or no consistency Database design is ignored creation of �data islands� not reusable & do not represent the information needs

43. What RAD is Not QADAD - Results Stresses-out project teams Hacked and untested code 2 out of 10 will be unqualified success Other 5 are considered �challenge� late, less then promised, over budget Need for more user training

44. What RAD is Not Reality of QADAD Low quality Unstable system Buggy application Code is expensive and/or Impossible to maintain

45. What RAD is Not RAD-lite 1. Have a JAD session 2. Develop 1 or 2 prototyping screens 3. Design the system 4. Write code 5. Implement 6. Show it to the user

46. What RAD is Not All-out RAD �Code like hell� Schedule - fast as possible Economy - cheapest tools Product - solve isolated business problem

47. What RAD is Not Just buying CASE tool Concept: buy the coolest tool, & RAD will happen. Equivalent to: �If I buy these sneakers, I�ll get a gold medal in the 100-meter-dash� Hunter, Antares Alliance Group

48. Philosophy of RAD Focus on Speed & Flexibility Well defined project scope Expected deliverables & delivery date Developers & customers required to participate Negotiate requirements Test deliverables Intense involvement

49. Advantages &DisadvantagesofRAD

50. Advantages of RAD Prototyping reduces program size & programmer effort by 40% Reduce manually coding Greater FLEXIBILTY can redesign almost at will Increased user involvement Early visibility

51. Advantages of RAD Development conducted at a higher level of abstraction RAD case tools operate at this level Possibly fewer defective code CASE tool generating code Shorter development cycles Standardized / consistent look and feel

52. Disadvantages of RAD Harder to gauge success no classic milestones Less efficient code Fear of return to the early days of uncontrolled practices More code defects from �code-like-hell� syndrome

53. Disadvantages of RAD Reduced features Prototype may not scale up a B-I-G problem Requirements may not coverage Interest of user & developers may diverge from one iteration to the next

54. Disadvantages of RAD Standardized look and feel (undistinguished, lackluster appearance) Successful efforts difficult to repeat Unwanted features through use of existing components Re-use of software

55. Implementing RAD

56. ImplementingRAD requirements Involvement of the end-user in the design Prototyping to help user visualize adjustments to the system Use of integrated case tool CASE toolkit that generates bug-free code Reuse of well-proven templates, components or system

57. Implementing RAD - mistakes Underestimating the difficulty and complexity of RAD A mainframe shop cannot just buy some tools and �do RAD� Culture change Trying to do QADAD

58. Implementing RAD Employ a flexible approach to methodology Don�t reinvent the wheel reuse code, or class libraries, use an object oriented language Invest is strategic training Do not assign an eager but untrained, inexperienced person in the facilitation role

59. Implementing RAD Right tools - high quality, �best of class� Tools can make the difference between a dynamic, responsive RAD team and struggling, stressed ineffective team Testing throughout the code writing process

60. Components of Successful& UnsuccessfulRAD

61. Successful RAD Application will run standalone Performance is not critical Required technology is more than year old Project scope is contained Strong micro-schedule constraints

62. Successful RAD Several teams working on same project System is split into several modules Product distribution will be narrow in-house or vertical market

63. Unsuccessful RAD Application must interpolate with existing programs Optimal performance is required Cannot use high-end tools Project is mission or life critical

64. Unsuccessful RAD System cannot be modularized Few plug-in components are available Product distribution will be wide horizontal or mass market Trying to build operating system, computer games, etc. performance targets set to high

65. Unsuccessful RAD Technical risks are high due to to use of �bleeding� edge technology No strong support from management RAD becomes QADAD

66. Problems Addressed by RAD

67. Problems Addressed by RAD Conventional methods - long delay before customers gets to see results Development takes so long the business has changed by the time system is ready There is nothing until 100% of the process is finished, then 100% of the software is delivered

68. Problems Addressed by RAD Business users do not understand what they want, particularly the �what if� Business user understand their needs but are unable to articulate them IT is not able to understand the articulated needs

69. Negotiating the Pace of Development

70. Negotiating Pace of Development Usable 80% solution can be produced in 20% of the time needed to produce a total 100% solution Business requirements for a system can be satisfied even if some of the operational requirements are not satisfied Acceptability of a system can be assessed against the agreed minimum useful set of requirements

71. Negotiating the Pace Efficient Sensible All-out Tradeoffs between schedule, economy & product will determine the pace of development

72. Negotiating Pace of Development Efficient Development Balances economy, schedule & quality schedule - faster than average economy - cost less than average product - better than average

73. Negotiating Pace of Development Sensible RAD Tilts away from economy & quality toward faster schedule schedule - much faster than average economy - cost little less than average product - little better than average

74. Negotiating Pace of Development All-out RAD �Code like hell� schedule - fastest possible economy - cost more than average product - worse than average

75. Negotiating Pace of DevelopmentNegotiable RAD has a fair chance of success if customer will negotiate either economy or quality RAD has a better chance for success if the customer will negotiate economy and quality Negotiating quality does not mean accepting a higher defect rate but a product that is less usable, less fully-features or less efficient

76. Negotiating Pace of DevelopmentGoals that may be Unachievable Fewest possible defects cannot modify some plug-in components Highest level of customer satisfaction secondary requirements may be sacrificed to stay on schedule Lowest development cost buying reusable components may cost more than building

77. Outline Overview of RAD Variation Elements Reasons to utilize Methodology 4 Phases Views on RAD What RAD in NOT Dis/advantages Implememtation Un/successful

78. RADinIndustry / Business

79. Business Architecture Business processes are related to one another Share applications & databases

80. Business Architecture Stand-alone systems Isolated business problems Undisciplined mass of applications Complex & difficult to change Lack flexibility UC, Davis

81. Business Architecture  IT productivity decreases Constant effort to modify existing systems Maintenance cost is 70 - 80% of total IT budgets UC, Davis

82. Business Architecture Need for overall Business Systems Architectures Skillfully designed architecture Modularity Open architecture UC, Davis

83. Business Systems ArchitectureUC, Davis

84. Utilizers of RAD Government / Military Insurance Companies Financial Institutions Airline Industry

85. Government Retanto DiPentima Former Deputy Commissioner for Systems Management at the Social Security Administration �One thing that we stress is the need to go from [business process re-engineering] to a system that actually implements the re-engineering.� �RAD is a perfect match for that.�

86. Government Powersoft (RAD tool) has on average of 75 evaluation copies to government agencies at any given moment (95% are bought within 90 days) PowerBuilder (RAD tool) available on contracts Justice Department Consolidated Office Network

87. Government / Military VB is used at U.S Post Office & Air Force TCSI Corp.s� Object Services Package Developed FAA application Control & Analysis tool from Robbins-Gioia INC Used by the Air Force Program Support System Develop scheduling solution for military depots

88. Insurance Companies Widespread popularity Manager �The issue is not whether we move to client/server, it�s how ... with RAD, that move can be facilitated gradually. The system evolves continually. It is not a throwaway...� Rapid products help to dominate the market

89. Insurance Companies �Developing code with RAD is like building a building with Lego blocks, as opposed to concrete and steel. If you build with concrete and steel, you labor for months about the architecture and structural formation. With Lego, they�re reasonably steady, but if you don�t like what you build, you pull it apart and rebuild� Ratz VP of Information Services General Accident Insurance

90. Financial Institutions Products have short lives in the financial services Short window to hit the product introduction Rapid production can mean market dominance Richard Hunter, Research Director at Stanford, CT-based Gartner Group

91. Financial Institutions �Speed is not the key benefit for some companies �� �You may spend the same amount of time delivering the same amount of work but the chances that you hit the mark for [end-users] are greater. In the end, they get what they want.� John Mittelstadt, Director of Corp. Software Engineering, ReliaStar Financial Corp.

92. Success StorySherwood Life & Pensions Designed with its own implementation methodology based on RAD principles AMARTA C/S environment specifically targeting life, health, & annuities/pensions application Business-driven rather than data-drive Software toolset enables business models to be translated into working software

93. Success StorySherwood Life & Pensions $ million losses due to failed BPR Business Process Reengineering Products vary from state to state country to country Rapidly define & develop products life, health, annuity/pension No need to hard code variances

94. Success StoryGovernment Department of Health & Human Services Original system 8 years to develop Redesign payroll system in 8 months using RAD CASE tools Key Enterprise

95. Success StoryDatatimes Online business information service 1993 had a mainframe service with text-only interface Estimated 33 man-years to design new system Software alone would require 200 new screens done from scratch

96. Success Story Datatimes Using RAD techniques 6 weeks for design 26 weeks for construction 18 weeks for testing & implementation 6 major components were built simultaneously Project completed in 56 weeks

97. Success Story  British Airways Engineering project engine flight data Lounge benefits for business customers Employee scheduling in-flight personnel

98. Cultural ChangesAssociated withRAD Implementation

99. Cultural Changes �The organizational context has an impact on the manner in which a development approach will be used. [It] must be taken into consideration.� www.cs.ucl.ac.uk

100. Cultural Changes Manager�s right to manage Structures of inquiry & decision making Peer to peer communication Self-directed work teams Resistance to change

101. Cultural ChangesClever Users Peer to peer communication encourages close interaction between users & developers. Users become more clever, making last minute demands. Non-technical users develop �shopping lists� of additional enhancements, increasing pressures toward the end.

102. Cultural Changes �The further systems� designers move � to plan for the possible social, cultural, & organizational impact of these technologies, the more tentative & incomplete relevant theories & techniques inevitably prove to be.� www.cs.ucl.ac.uk

103. Outline Overview of RAD Variation Elements Reasons to utilize Methodology 4 Phases Views on RAD What RAD in NOT Dis/advantages Implememtation Un/successful Industry Business Architecture Utilizers Success Stories

104. The Future of RAD

105. Driving the future New business practices, mergers and acquisitions, and deregulation Rapid advancement in technology Application systems are means by which a company differentiates itself from its competitors

106. Future of RAD Component-Based Development (CBD) Software engineer rarely starts with a completely blank piece of paper Reuse pieces created in previous projects requirements documents, designs, code, management processes, and so on.

107. Future of RAD A well-defined application architecture Adaptability to new business practices and new technologies; Assembly of pre-developed components

108. Future of RAD RAD is not yet ready to be scalable to high-transaction volumes Not for complex applications with stringent performance requirements with multiple interfaces with external systems

109. Conclusion

110. RADCASE Tool

111. RAD CASE Tool Case tool is a computer-based product aimed at supporting one or more software engineering activities within a software development process

112. History of CASE CASE I-CASE developed a bad RAP 4GL not a model tool Enterprise Application Development EAD

113. RAD CASE tool needs Prototyping Graphics computer aided modeling & design Repository of design information and reusable components Integrated code generation, testing tools Thorough end-user interaction, aided by tools

114. Benefits of CASE diagrams Show objets and associations among objects (objects - entity type, a data store, goal) pert charts are used aid in clear thinking non-case diagrams are hand drawn, contains errors, inconsistencies, and omissions

115. Source Documents Sterling Software http://www.cool.sterling.com/company/white_paper.htm University of California, Davis http://sysdev.ucdavis.edu/WEBADM/document/rad-archplan.htm Morton, Carol �Life After RAD� President of Sterling Software, Dylkor Systems Division, Chatswoth, CA Schwartz, Susan. �RAD Principles behind Sherwood�s foray into �� Insurance & Technology; New York, Feb 1998 Adams, Charlote. �CASE takes on RAD� http://www.few.com April 15, 1996 Way, Paul. �Totally RAD� Insurance & Technology; New York, July 1996 Application Development Strategies, Cutter Corporation http://www.cutter.com/ RAPID APPLICATION DEVELOPMENT http://web.cs.bgsu.edu/maner/domains/RAD.htm#1� Software Tech News http://www.dacs.dtic.mil/awareness/newsletters/technews2-1/toc.html Successful Path to Client/Server Applications Through Rapid Application Development Methodology With a Self-Directed Work Team http://causewww.colorado.edu/information-resources/ir-library/text/cnc9520.txt Agencies take a RAD approach to development http://www.few.com

116. Recommended Web sites http://www.sterling.com/ This is the CASE tool we will be demonstrationing, See COOL http://sunset.usc.edu/classes/cs510_97/index.html course syllabus for Software Management and Economics Special Focus on Rapid Application Development http://www.multi-soft.com/COMRADAppTypes.htm scroll down to the 12 Development Steps http://www.petronio.com/training/Client/Server/pb.shtml#needs PowerBuilder course information http://www.bluemtn.com/radvend.html outlines SDLC and how this particular RAD tool applies http://www.netscapeworld.com/netscapeworld/nw-06-1997/nw-06-rad.html A Web developer's guide `rapid application development' tools & techniques http://www.sei.cmu.edu/products/publications/publications.html Carnegie Mellon University http://www.cdt.luth.se/pvt/courses/smd095/lectures/models/slide1.html What are models? http://www.whatis.com/rad.htm What is RAD http://www.dsdm.org DSDM Consortium Suggested Reading Martin, James. Rapid Application Development, McMillan, 1991.