RAD Techniques with Advantage CA-ADS Brock Shaw Torrodon Associates

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

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

…then the Plan Grows

p22 p23

p12 p13

p33 p34

p8 p16

p9 p17 p18

… until the Final Plan

p22 p23

p12 p13

p33 p34

p8 p16

p9p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9p17 p18

Calculating Completion Time

Project Duration

p22 p23

p12 p13

p33 p34

p8 p16

p9 p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9 p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9 p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9 p17 p18

Critical Path

p22 p23

p12 p13

p33 p34

p8 p16

p9 p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9 p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9 p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9 p17 p18

Critical Path Change

p22 p23

p12 p13

p33 p34

p8 p16

p9 p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9 p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9 p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9 p17 p18

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!

p22 p23

p12 p13

p33 p34

p8 p16

p9p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9p17 p18

p22 p23

p12 p13

p33 p34

p8 p16

p9p17 p18

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

Single Development Cycle

Time-box Planning

Strategy

Start End

Analysis and Design

Implement

Time-box

i vi t

Threads Requirements

Strategy

Start End

Analysis and Design

Implement

Time-box

i vi t

Threads Requirements

Strategy

Start End

Design

Implement

Time-box

i vi t

Analysis

Time-box Preparation

Strategy

Start End

Analysis and Design

Implement

Strategy

Start End

Analysis and Design

Implement

Time-box 1

i vi t

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

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

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

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

Objects & Test Beds

Function

Data Access

Function

TB2Screen Forms

OOD Project Compressed

TB1 TB4TB3

Object & Test Beds

FunctionData Access

Function

TB2Screen Forms

Team 1

Team 2Function

RAD Case histories

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

Brochureware

Web Services

Simple Data Access

eBusiness

TB2Data Objects

Projects that End in Tiers

TB5 TB6

Brochureware

Web Services

Simple Data Access eBusiness functions

Customer responsiveness

Data Objects

Client

Server

Backend

RAD Case histories

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

ApplicationStructure & MAPs

Utility &LoadFunctions

Data Entry Components

Key Function #1

TB2DatabaseComponents

TB6Key Function #2

TB7MiscellaneousFunctions

ADSO Project Plan 2

TB1 TB4

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

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 ...

RAD Techniques with Advantage CA-ADS Brock Shaw Torrodon Associates

Documents

Brock Harcourts Blackwood

The Brock Brothers and the Brock Process - ASPRS

Yukon-Brock Presentation

Brock Bank

Brock v. Carrion

Dr. John Brock

Shaw Public School Newsletterschools.peelschools.org/1489/Lists... · 12. They next defeated Mr. Orazem and Sir Isaac Brock by a score of 33-12. The boys are commended on their effort

Brock Less Think

Brock Citizen

Pricing - Shaw Web Studio€¦ · • your banner ads on thousands of websites and facebook • up to 45k ad impressions • analytics to measure roi • banner ads and custom landing

· Moses Moreno Omarr Morgan Kyle Murphy Brock Olivo Tony Parrish Michael Pittman Damien Richardson Adrian Ross Michael Ruhl Joe Salave'a Phil Savoy Bobby Shaw Pat Tillman Ron Warner

Internet 600 Shaw) broadsoft Cisco COMCAST Shaw) viawest c CUS. Freedom mobile QUEBEC Shaw) DBRS Shaw) Shaw) Glow 32 Episodes modern litßian eav Shaw) Shaw) Shaw) 01-2 Author Dylan

Microbiologia de Brock

Arthur Brock

Eddie Brock

brock Felgenprogramm 2010

Post-Election Webinar - Seyfarth Shaw · 2016-11-14 · Seyfarth Shaw LLP “SeyfarthSeyfarth Shaw LLP Shaw” refers to Seyfarth Shaw LLP (an Illinois limited liability partnership)

caratula brock

Brock University 2017 Solid Non-Hazardous Waste Audit · Brock University 2017 Solid Non-Hazardous Waste Audit Prepared for: Brock University 1812 Sir Isaac Brock Way St. Catharines,

Brock University – Welcome to Brock