Date post: | 26-Mar-2015 |
Category: |
Documents |
Upload: | claire-hutchinson |
View: | 217 times |
Download: | 2 times |
RAD Techniques with Advantage CA-ADS
Brock ShawTorrodon Associates
Abstract
Examine some of the Rapid Application Development techniques which can be used while developing Advantage CA-ADS and Advantage CA-IDMS applications. These techniques apply particularly well to 4GLs such as ADS. The technique described makes use of familiar RAD concepts of JRD and JAD workshops but more fundamentally to the use of development cycles based on the concept of Time-box. Examples of this approach are given.
Speaker Bio
Brock Shaw
Torridon Associates
Brock has worked with IDMS since 1973 and has been involved with the product throughout the subsequent years. First working for Sperry Univac, then Cullinane, Cullinet and as an independent consultant, he has worked on most aspects of the CA-IDMS environment and in most roles.
Topics for Session
What is RAD? Software development issues What is a Time-box? What RAD models are there? Single development cycle. Case histories. Advantage CA-ADS and RAD
What is RAD?
For development of software systems RAD is essentially a set of:
Techniques to minimise elapsed timeTechniques to maximise user involvementTechniques to maximise user ownershipTechniques to handle business changeTechniques to make PM easier
Specific RAD Techniques
User involvement and ownership Workshop techniques (JRD, JAD) Prototyping (incomplete end-products) Time planning and project management Iterative development Frequent release of “products”
Traditional Development
Older development methodologies are based on: Performing a sequence of tasks in a fixed order Getting signoff at each significant stage Following the sequence of the methodology
Problems with these are: For large systems implies long periods without
usable products. They do not respond well to change
The Waterfall Model
Stage 0
Stage 1
Stage 2
Stage 3
Stage 4
Stage 5
Stage 6
FeasibilityStudy
RequirementsAnalysis
RequirementsSpecification
Logical SystemSpecification
Investigate CurrentEnvironment
BusinessSystemsOptions
TechnicalSystemsOptions
LogicalDesign
PhysicalDesign
SSADM
Project Planning and the Waterfall
How does it work?
Start with a list of tasks to be done to complete the project.
Establish the dependencies of the jobs on other jobs in the list.
Work out how long the whole project will take to complete
Starting the Planning Process
p0 p2 p5
p1p4
p3
p7
p6
…then the Plan Grows
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9 p17 p18
p27
… until the Final Plan
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9p17 p18
p27
Calculating Completion Time
Project Duration
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9 p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9 p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9 p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9 p17 p18
p27
Critical Path
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9 p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9 p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9 p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9 p17 p18
p27
Critical Path Change
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9 p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9 p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9 p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9 p17 p18
p27
Problem 1: Size of Project
For a large project:– difficult to visualise the project as a whole– difficult to know status at any time– difficult to predict impact of slippage– difficult to predict impact of change
These are limits of the human ability This is comparable to reasons for structure in
programming Not possible without PM aids
Project Creep
Slow accumulation of slippageEssential business changes requiredPM cannot easily grasp the impact of eventsFailure to realise the shift in CP
Project Creep is the most common cause of the failure of large high visibility projects.
The Waterfall & Change
Stage 0
Stage 1
Stage 2
Stage 3
Stage 4
Stage 5
Stage 6
FeasibilityStudy
RequirementsAnalysis
RequirementsSpecification
Logical SystemSpecification
Investigate CurrentEnvironment
BusinessSystemsOptions
TechnicalSystemsOptions
LogicalDesign
PhysicalDesign
Changing such a Plan!
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9p17 p18
p27
p0
p1
p2
p3
p4
p5 p6
p7
p20
p19
p21
p25
p24
p22 p23
p26
p10
p11
p2
p15
p14
p12 p13
p14
p29
p30
p32
p36
p31
p33 p34
p35
p99
p8 p16
p28
p9p17 p18
p27
Problem 2: Handling Change
“Life is change.” Modern business needs flexibility and
responsiveness To do this, development must be iterative Large CP project planning becomes very
cumbersome as complexity increases.
The Planning Paradigm
Basic formula:
t=F(f,r)
(f= product features; r= resources available) Traditional techniques hold features and
resources constant and calculate end time There is another alternative:
– Hold time constant and respond to change by adjusting product features or resources
How can this Work?
Make a big project into a collection of small ones Each sub-project has real deliverables Not all functions of a system are of the same
importance A given function may if necessary be deferred Such functions are simply planned for a later sub-
project If a function must be “bumped” from one sub-project
there will be another one along in a little while We use the concept of a Time-box, a mini-project that
has a fixed duration
A Time-box
A period of time is defined, usually 1 to 2 months. THIS IS FIXED.
Planning determines what features are anticipated to be accomplished in the time
Planning determines what arrangement of resource will achieve the work
Features classified as “must have”, etc. PM responds to slippage by bumping lower
priority features not by delivering late!
Time-box Advantages
Smaller project is easer to control Limited commitment (less to lose) User change easier (Time-box like a bus!) Business change handled (iteration) EACH TIME-BOX HAS A PRODUCT Frequent appearance of products pleases users
and management
Time-box Driven Projects
Overall project must have a general plan Plan is broken into time-boxes Detailed schedule only current time-box(es) Time-box is a short time so low cost of change
allows risks to be taken Each feature may be revisited if necessary in
each time-box of the overall plan
Responding to Slippage
Three alternative strategies:
– 1. Eliminate functionality from the time-box products
– 2. Assign more resources to the project
– 3. Plan an additional mini time-box
RAD Objectives and Time-box
Techniques to minimise elapsed time Techniques to maximise user involvement Techniques to maximise user ownership Techniques to handle business change Techniques to make PM easier
Development Methodologies
Waterfall Waterfall with iteration RAD
Development cycles
FunctionalIteration
Design and BuildIteration
ImplementationIteration
Feasibility Study
Business Study
DSDM
Single Development Cycle
Time-box Planning
Strategy
Start End
Analysis and Design
Build
Test
Implement
Time-box
Th
rea d
s of
ac t
i vi t
y
Threads Requirements
Strategy
Start End
Analysis and Design
Build
Test
Implement
Time-box
Th
rea d
s of
ac t
i vi t
y
Threads Requirements
Strategy
Start End
Design
Build
Test
Implement
Time-box
Th
rea d
s of
ac t
i vi t
y
Analysis
Time-box Preparation
Strategy
Start End
Analysis and Design
Build
Test
Implement
Strategy
Start End
Analysis and Design
Build
Test
Implement
Time-box 1
Th
rea d
s of
ac t
i vi t
y
Time-box 2
REVIEW
When Time-boxes are most effective.
When programming environment is supportive When components are amenable to iterative
development When application framework can iterate When minimal input will build starter component When even initial prototypes are products When there is good repository support
RAD Case histories
Mainframe OO Environments Web ADS/O General PM
A Business Opportunity
COBOL environment Unanticipated and hence unplanned Competitive pricing paradigm change Industry regulator involvement Necessary to start in 30 days Could survive reduced service for 60 days Traditional methods would require 90+ days
Mainframe Model
TB1
TB2
Pricing s/r buildSimple Batch vehicleFocused VV&TSimple implementation
0 30 60 90
Pricing s/r refinementOn-line vehicleFull-scale VV&TFull-scale implementation
Compressing the Project
TB1
TB2
Pricing s/rSimple Batch vehicleFocused VV&TSimple implementation
0 30 60 90
Pricing s/r refinementOn-line vehicleFull-scale VV&TFull-scale implementation
RAD Case histories
Mainframe OO Environments Web ADS/O General PM
Object Orientation
Encapsulation means data and business entities are developed independently of use
Solutions are immediately shareable Easier to stage data implementations
The New IDEs
Enhanced editors and languages Object orientation Application templates Live debugging Source controls Implementation/deployment aids
OOD Project
TB1
TB4
TB3
TB5
Objects & Test Beds
Function
Data Access
Function
TB2Screen Forms
OOD Project Compressed
TB1 TB4TB3
TB5
Object & Test Beds
FunctionData Access
Function
TB2Screen Forms
Team 1
Team 2Function
RAD Case histories
Mainframe OO Environments Web ADS/O General PM
Easing into Web
The stages of a web application– Brochureware– Web intelligence– Simple business functions– Full eBusiness
Stages can become basis for time-boxes Needs overall plan, documentation framework Flexible project teams
Simple Web Project
TB1
TB4
TB3
TB5
Brochureware
Web Services
Simple Data Access
eBusiness
TB2Data Objects
Projects that End in Tiers
TB1
TB4
TB5 TB6
Brochureware
Web Services
Simple Data Access eBusiness functions
TB2
Customer responsiveness
TB3
Data Objects
Client
Server
Backend
RAD Case histories
Mainframe OO Environments Web ADS/O General PM
Advantage CA-ADSO
Dialogs, Mapping, IDD all support process Dialogs are amenable to iteration ADSA provides flexible application framework Minimum dialog requires only a map IDD provides repository for data structures, code,
appl. structure, etc. Prototyping can build final product
CA-ADS Application Components
Data structure Utility subroutines Application Structure Maps Basic (minimum logic) Dialogs Functional areas Data load
ADSO Project Plan 1
TB1
TB4
TB3
TB5
ApplicationStructure & MAPs
Utility &LoadFunctions
Data Entry Components
Key Function #1
TB2DatabaseComponents
TB6Key Function #2
TB7MiscellaneousFunctions
ADSO Project Plan 2
TB1 TB4
TB3
TB5ApplicationStructure & MAPs
Utility &LoadFunctions
Data Entry Components
Key Function #1
TB2DatabaseComponents
TB6Key Function #2
TB7MiscellaneousFunctions
Team 1
Team 2
Team 3
Other Factors for Success
More flexible project structures Designing components for segmentation “Object”-isation – imitating OOP Importance of Overall Plan Focus on segmentation of product and on what is
releasable
Maximising User Input
Techniques to maximise user involvementTechniques to maximise user ownershipJoint Requirements Development Joint Application Development
These techniques are important and effective but not the focus of this session.
RAD Case histories
Mainframe OO Environments Web ADS/O General PM
General Applications
The Time-box technique:– is not restricted to IT projects– is principally an attitude of mind
Review of Topics
What is RAD? Software development issues What is a Time-box? What RAD models are there? Single development cycle. Case histories. CA/ADSO and RAD
Questions & Answers
Session Evaluation Form
... please place it in the basket at the back of the room.
After completing your session evaluation form ...