1 / 115

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

Addressing the Software Crisis. Reduce software development problemsImprove effectiveness of developmentProvide software on time

love
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    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 Elements People 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 Elements Management 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 Elements Tools 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 RAD Requirements 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 Phase Essential Components High level or knowledgeable end-users Right users & executives Structured discussion of business problems JRP Joint Requirements Planning workshop

    30. 4 Phases of RAD Requirements Planning Phase

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

    32. 4 Phases of RAD User 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 Phase Prototyping 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 RAD Construction 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 RAD Cut-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 Not The 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 & Disadvantages of RAD

    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. Implementing RAD 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 & Unsuccessful RAD

    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 Development Negotiable 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 Development Goals 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. RAD in Industry / 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 Architecture UC, 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 Story Sherwood 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 Story Sherwood 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 Story Government 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 Story Datatimes 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 Changes Associated with RAD 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 Changes Clever 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. RAD CASE 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.

More Related