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

CASE Tools Sterling Software
Catherine Chauvin Dan Schwartz
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

• Methodology
• 4 Phases
• Views on RAD
• What RAD in NOT
• Dis/advantages
• Implememtation
• Un/successful
• Industry
• Business Architecture
• Utilizers
• Success Stories
• Future of RAD
• Conclusion
• Sterling CASE Tool

• 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 projects 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

• Views on RAD
• What RAD in NOT
• Dis/advantages
• Implememtation
• Un/successful
• Industry
• Business Architecture
• Utilizers
• Success Stories
• Future of RAD
• Conclusion
• Sterling CASE Tool

• Overview of RAD
• Variation
• Elements
• Reasons to utilize

• Methodology
• Waterfall
• 4 Phases
• Requirements
• User Design
• Construction
• Cut-over

22
(No Transcript)
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 dont 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
(No Transcript)
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
UC, Davis
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
Waterfall Fair Poor Poor Poor
RAD Excellent Excellent Good Good
Encourage customer interaction Development
speed Promotes feedback learning Ability to
handle risks uncertainty
37
RAD vs. Waterfall

• Reliance on individuals if one person
  goes under a bus or leaves the company or decides
  to do something else the project will suffer ...
  Project Manager

• Waterfall methodology designed to be more
  robust, to have an existence to themselves, and
  you slot people in Project Manger

38
Outline
Overview of RAD Variation Elements Reasons to
utilize Methodology 4 Phases

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

Industry Business Architecture Utilizers
Success Stories Future of RAD Conclusion Sterling
CASE Tool
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, Ill 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
• Dont 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
A Balancing Act of economy, schedule quality
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

• Industry
• Business Architecture
• Utilizers
• Government
• Insurance
• Financial
• Airline
• Success Stories
• Cultural Changes
• Future of RAD
• Conclusion
• Sterling CASE Tool

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, its 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, theyre
  reasonably steady, but if you dont 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

• Managers 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

• Future of RAD

• Conclusion
• Sterling CASE Tool

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

• Overview of RAD
• Methodology
• Waterfall vs. RAD
• Implementing RAD
• Industry
• Future of RAD

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.h
  tm
• University of California, Davis
• http//sysdev.ucdavis.edu/WEBADM/document/rad-arch
  plan.htm
• Morton, Carol Life After RAD
• President of Sterling Software, Dylkor Systems
  Division, Chatswoth, CA
• Schwartz, Susan. RAD Principles behind
  Sherwoods 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.htm1
• Software Tech News
• http//www.dacs.dtic.mil/awareness/newsletters/tec
  hnews2-1/toc.html
• Successful Path to Client/Server Applications
  Through Rapid Application Development Methodology
  With a Self-Directed Work Team

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.
  shtmlneeds
• 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-1
  997/nw-06-rad.html
• A Web developer's guide rapid application
  development' tools techniques
• http//www.sei.cmu.edu/products/publications/publi
  cations.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