The RAD Approach
Rick Nolle, CLU, FLMI/M, MCP
Vice President of Information Technology
RGA Reinsurance
Session 37-TS October 28, 2002
Agenda
tFundamentals of IT Projects
tLearning from History
tRapid Application Development
tKeeping Projects on Track
tTrust but Verify
tSummary
1
How to Build a Computer Application
tChoose a methodology
tEstimate the size of the project
tForm a project team
tDevelop a project plan
tExecute the plan
tImplement the system
When are your development
projects usually finished?
tEarly 0%
tOn time 56%
tLate 43%
How do we change this?
Computerworld poll of CIOs – October 16, 2002
2
Columbus is RAD
Armstrong is SAD
October 28, 2002
Two Projects
Columbus and Armstrong
tTwo pioneers who took mankind to a new place
tTwo missions of very different nature
tColumbus had an vision
tArmstrong has a mission
3
Columbus
tBorn in Genoa, Italy in 1446
tGrew up to be an accomplished sea captain
tShipping in the 1400’s was limited
tMediterranean Sea
tEuropean Coast
tNorthern Africa
tMarco Polo explored the East
Columbus
tColumbus, through study and observation, believed
the world was round
tColumbus calculated the circumference of the earth
at 20,000 miles
tColumbus (mis)calculated that India was 3,000
miles west of Spain
4
Columbus
tSought executive sponsorship
tItaly and Portugal turned him down
tSpain’s Queen Isabella and King Ferdinand stepped up
tProvided three ships and a crew
tUsed new technologies
tThecompass
tDead reckoning
Columbus
tAfter about 30 days of traveling due west, land was
sighted
tCalled the people Indians, declared
mission a success and returned a hero
tReward was even greater than the
original expectation
5
Armstrong
t Began with executive sponsorship
t JFK’s vision in 1961
t Involved tens of thousands of scientists,
engineers and others
t Highly organized, very specialized
t All risks managed or eliminated
Armstrong
t Apollo program cost $25 billion
t Utilized new technology and invented
technology that wasn’t available:
t Computers for calculations
t Rocket science
t Mission was flawless
t Reward was exactly what was envisioned:
landed man on the moon
6
Armstrong
New Technology
First Network Diagram of APRANet c. 1969
Application Development
Methodologies
tStandard methodology is the Waterfall
tSimplest methodology is Code-and-Fix
tRapid application development is the Spiral
tOther methodologies include:
tEvolutionaryDelivery
tDesign to Schedule
tDesign to Tools
7
Software
Concept Waterfall
Requirement
Analysis
Architecture
Design
Detailed
Design
Coding and
Debugging
Unit
Testing
System
Testing
Waterfall
Plusses Minuses
t Works best on complex, t Not flexible
well understood projects t Must know goal at start
t Produces high quality t Difficult to swim upstream
t Provides structure for
weak or inexperienced
staff
8
RAD Methodology
tIt’s
a spiral methodology, like a cinnamon roll
tAnalyst and user work hand in hand
Determine
Objectives
Review & Identify
Test Risks
Develop Evaluate
Deliverables Alternatives
RAD Spiral
Copyright 2000 -Carnegie Mellon University
9
RAD
Plusses Minuses
t Shortest possible timeline t Complicated model
t Risk decreases as project
progresses
t Ultimate flexibility in
defining end product
t High user visibility
Rapid Application Development
tIs applicable to entrepreneurial endeavors where
the business plan isn’t fully developed
tIt’s a joint effort between developers and the client
tIt’s an iterative approach involving prototyping and
incremental building
tIt’s taking a big, monolithic project and breaking it
into many joint efforts
10
When to Use RAD?
tRAD is a good methodology when there’s not an
exact need or precise goal
tRAD involves working together to figure out
where you’re going as you go
tRAD involves uncertainty
Columbus was RAD
Armstrong was SAD
tRAD allows you to change course as you go
tRAD provides for discovery of facts along the way
tRAD builds upon iterative successes
tSAD has detailed up-front planning
tSAD requires specialization and structure
tSAD is more expensive and takes more time
11
General Strategies for RAD
tAvoid classic mistakes
tApply development fundamentals
tManage risks to avoid setbacks
tApply schedule-oriented practices
Classic Mistakes
1. Feature Creep
2. Gold-plating
3. Shortchanged quality
4. Overly optimistic schedules
5. Inadequate design
6. Silver bullet syndrome
7. Weak staff/Contractor failure
8. Friction between developers and customers
9. Imbalanced product, time and resources
12
Classic Mistake
Feature Creep
tAverage project experiences 25% addition in
features
tMust be actively managed through written
requests and project impact analysis
tRAD allows for feature definition at each iteration
tSAD requires a swim up the waterfall
Classic Mistake
Gold Plating
tParkinson’s Law
Work expands to fill available time.
13
Classic Mistake
Quality Assurance
tAn IBM study in the early 1990’s found that
products with the lowest defect counts were also
the products with the shortest schedules
tThe 95% Rule
Finding 95% of the bugs in prerelease is the point
where projects achieve the shortest schedules,
least effort and highest level of user satisfaction
Classic Mistake
Overly Optimistic Schedules
tUnderdeveloped requirements/specifications
tUnderestimation of interdependencies
tOverestimation of individual capabilities
14
Classic Mistake
Inadequate Design
tSingle design cycle isn’t sufficient
tRush to develop – not spending time in
requirements and design
Classic Mistake
Silver Bullet Syndrome
tBeta version of anything
tBrand new hardware that finally makes the
architecture possible
tNew tool/version that handles the
problem that plagues your project
15
Classic Mistake
Weak Staff/Contractor Failure
tRAD demands higher-than-average talent
tBusiness knowledge is imperative
tConsultants infuse knowledge
tContractors are short-term
Classic Mistake
Poor Client Involvement
Customer involvement will:
tImprove efficiency
tReduce rework
tMinimize risk
Managing Expectations
tReality versus perception
16
Classic Mistake
Imbalanced Projects
Pick Two: Software Trade-off Triangle
tGood Schedule
tFast
tCheap
Cost Product
Fundamentals for Speed
tPeople
tProcess
tProduct
tTechnology
17
Manage Risk
tIdentifypotential risks
tRisk analysis
tRisk prioritization
tControlling risks
tMonitor risks
Trust but Verify
18
Algorithms
Testing Time Allocations
tRequirements 20%
tDetailedDesign 25%
tCoding and Debugging 35%
tTesting 20%
Alorithms
Size Estimation
tFunction point estimation
tSize estimation software
tComparative estimations
19
Function Points
Total Function Points
Function Points 3X2= 4X2= 6X 7=
Low Medium High Number of inputs 12 8 42
Number of inputs 3 4 6 4X3= 5X7= 7X2=
Number of outputs 4 5 7 Number of outputs 12 35 14
Processes 3 4 6 3 X 3 =4 X 2 = 6 X 2 =
Internal interfaces 7 10 15 Processes 9 8 12
External interfaces 5 7 10 7 X 5 = 10 X 2 = 15 X 4 =
Count of Each Function Internal interfaces 35 20 60
Number of inputs 4 2 7 5 X 6 = 7 X 1 =10 X 1 =
Number of outputs 3 7 5 External interfaces 30 7 10
Inquiries 3 2 2 Sum of Total Points 335
Internal interfaces 5 2 4 Influence Multiplier X 1.15
External interfaces 6 1 1 385
Algorithms
Teams, Plans and Timelines
tEstimating software schedule
tSchedule in months = 3.0 * person-months ^ (1/3)
tSchedule in months = Function Points ^ k
k = (~0.43)
tTo increase the speed of a project:
tDecrease size of product
tIncrease people on team
20
Conclusion
tRapid Application Development is right for many
projects
tWhen RAD isn’t right, the large project can be
broken down into many smaller RAD efforts
tTime is money
Rapid Application Development
21
Bibliography
Rapid Application Development, Steve McConnell,
Microsoft Press, 1996
Spiral Development: Experience, Principles and
Refinements, Barry Boehm, Software Engineering Institute,
2000
IT / Metrics / Benchmark Resources & Links,
www.metricnet.com, Howard Rubin, 2002
Various articles, www. garynorth.com, Gary North, 1998
Various articles, www.sei.cmu.edu, Carnegie-Mellon
University, 2002
22
