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 tOn time tLate

0% 56% 43%

How do we change this?
Computerworld poll of CIOs – October 16, 2002

2

Columbus is RAD Armstrong is SAD
October 28, 2002

Columbus and Armstrong
tTwo

Two Projects

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

tThe

compass 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:

tEvolutionary

Delivery tDesign to Schedule tDesign to Tools

7

Software Concept Requirement Analysis

Waterfall
Architecture Design Detailed Design Coding and Debugging Unit Testing System Testing

Waterfall
Plusses t Works best on complex, well understood projects t Produces high quality t Provides structure for weak or inexperienced staff Minuses t Not flexible t Must know goal at start t Difficult to swim upstream

8

RAD Methodology
tIt’s

a spiral methodology, like a cinnamon roll tAnalyst and user work hand in hand
Determine Objectives Review & Test Identify Risks

Develop Evaluate Deliverables Alternatives

RAD Spiral

Copyright 2000 -Carnegie Mellon University

9

RAD
Plusses t Shortest possible timeline t Risk decreases as project progresses t Ultimate flexibility in defining end product t High user visibility Minuses t Complicated model

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. 2. 3. 4. 5. 6. 7. 8. 9.

Feature Creep Gold-plating Shortchanged quality Overly optimistic schedules Inadequate design Silver bullet syndrome Weak staff/Contractor failure Friction between developers and customers 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

Overly Optimistic Schedules
tUnderdeveloped requirements/specifications tUnderestimation

Classic Mistake

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

Weak Staff/Contractor Failure
tRAD

Classic Mistake

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: tGood tFast tCheap

Software Trade-off Triangle Schedule

Cost

Product

Fundamentals for Speed
tPeople tProcess tProduct tTechnology

17

Manage Risk
tIdentify

potential risks tRisk analysis tRisk prioritization tControlling risks tMonitor risks

Trust but Verify

18

Testing Time Allocations
tRequirements tDetailed

Algorithms

Design tCoding and Debugging tTesting

20% 25% 35% 20%

Alorithms
tFunction

Size Estimation

point estimation tSize estimation software tComparative estimations

19

Function Points
Number of inputs Number of outputs Processes Internal interfaces External interfaces Number of inputs Number of outputs Inquiries Internal interfaces External interfaces Function Points Low Medium High 3 4 6 4 5 7 3 4 6 7 10 15 5 7 10 Count of Each Function 4 2 7 3 7 5 3 2 2 5 2 4 6 1 1

Total Function Points 3X2= 4X2= 6X 7= Number of inputs 12 8 42 4X3= 5X7= 7X2= Number of outputs 12 35 14 3 X 3 =4 X 2 = 6 X 2 = Processes 9 8 12 7 X 5 = 10 X 2 = 15 X 4 = Internal interfaces 35 20 60 5 X 6 = 7 X 1 =10 X 1 = External interfaces 30 7 10 Sum of Total Points 335 Influence Multiplier X 1.15 385

Teams, Plans and Timelines
tEstimating software schedule
tSchedule

Algorithms

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