Being Rapid… - CSC

spinabundantInternet και Εφαρμογές Web

30 Ιουλ 2012 (πριν από 5 χρόνια και 1 μήνα)

348 εμφανίσεις









Rapid Application Development

(RAD)
:

A CSC Point of View


Elangovan Vellaichamy

Gokulvanan Velan

Sreeharsha Karnam

6
-
Mar
-
2012







Abstract

The purpose of this paper is to introduce

Rapid Application D
evelopment
and its use

within one ICT group at Chrysler.
The focus will be on

the Agile Software Development process of RAD and application of

r
e
-
usable software components

t
o develop prototypes and enhance the prototype to create a working application.

T
he paper
will
also sh
are
our experience
s

in applying this process model
for

develop
ing

robus
t applications at a rapid
phase

at Chrysler

and

concludes

on

how CSC could leverage
this experience
.









Contents

Abstract

................................
................................
................................
................................
................................
...................

1

Being Rapid…

................................
................................
................................
................................
................................
...........

3

Our experience with RAD? (CSC, Chrysler and RAD)

................................
................................
................................
..............

7

How can CSC leverage RAD?

................................
................................
................................
................................
.................

14

Summary

................................
................................
................................
................................
................................
...............

15























Being
Rapid


Rapid Application Development

(more commonly known as RAD
), as the name suggests, is one Agile
Software
Development
process designed to be rapid a
nd lean. RAD methodologies are capable of
utilizing minimal planning,
a
dapting to requirement changes

and having a higher focus on building rapid application prototypes to accelerate
software development.



Rapid Application
Development

From Wikipedia, the free encyclopedia

Rapid Application Development (RAD) is a software development
methodology that uses minimal planning in
favo
r

of rapid
prototyping. The "planning" of software developed using RAD is
interleaved with writing the software itself. The lack of extensive
pre
-
planning generally allows software to be written much faste
r,
and makes
it easier to changing requirements
.



As the name suggests “
Rapid
” is the key objective in RAD.

Traditional software development processes are not quick enough to address the
business needs in a timely manner and sometimes the requirements gets changed even
before the system is complete, resul
ting in inadequate or even unusable systems.

One of the critical inputs to establish a Strategic Roadmap for any business function is
the ability to respond quickly to business partner's initiatives, both qualitatively and
quantitatively.


In rapid applica
tion development, structured techniques and prototyping are especially
used to define users' requirements and to design the final system. The development
process starts with the development of preliminary data models and business process
models using struc
tured techniques. In the next stage, requirements are verified using
prototyping, eventually to refine the data and process models. These stages are
repeated iteratively; further development results in "a combined business requirements
and technical design

statement to be used for constructing new systems".










Rapid application
development was a
response to non
-
agile
processes such as the
Structur
ed Systems
Analysis and Design
Method and other
Waterfall models.

-
Source from Wikipedia






Majority of the Fortune
500 companies practice
one or more types of
Rapid Application
Development
methodologies

-
Source from Wikipedia



TRADITIONAL (vs.) RAD







RAD
Advantages




Dynamic Requirements Accommodation

As the business moves faster and tends to change the requirements during
the software development period, RAD processes adapt themselves to their
needs

and accommodate the changes
maintaining high quality
thereby
ensuring that the final product exactly meets the business requi
rements.
This is not the case with

traditional SDLC processes where
some time

it
takes
quantitative time
to
completely build an application and Change in
requirements increment

delay
.




Active Business Partner Participation


RAD processes involve short iterative development cycles with
corresponding prototypes. This facilitates the business users to review the
prototypes and make informed decisions on their requirements and provide
any c
hanges in requirements which they might have not envisaged earlier.




Rapid Turnaround Time

RAD processes involve minimal planning and concentrates more on actual
application development to provide solutions well within the business needs
timeframe. This ap
proach also makes it easier to accommodate any change in
requirements during the development cycle.




Traditional client
-
server
based models are being
replaced by collaborative
models like Web 2.0,
which demands faster
iterations of Software
Development Life Cycles.

-
Source from Wikipedia















Nowadays, the pre
-
built
open source frameworks
and products are being
used in majority of core
commercial software’s
resulting in finding new
rapid ways of software
development.

-
Source from Wikipedia





Software Re
-
Usability


RAD processes stress on code reusability and the different core programming
components are re
-
used across various application developments thereby
facilitating rapid
software development.

Should you

go for RAD
?


The RAD methodology was developed to respond to business needs of developing IT
solutions/systems faster.
Not all RAD

methodolog
ies are suited for all projects.

Their

use

depends
on
factors such as project ty
pe, schedule and corporate culture.

The various types of RAD methodologies each
have

their own

strengths and weaknesses.
Large projects may
benefit most from using RAD and JAD techniques. Agile and Extreme
techniques work best on small projects or when l
arger projects can be broken down into
smaller functional units.




The chart below outlines some of the major types of
RAD
process
:

-
Source from Wikipedia

METHODOLOGY

DESCRIPTION

PROS

CONS

Agile

This methodology helps teams to
respond to the
unpredictability of
building software through
incremental, iterative work
cadences known as sprints.


Minimize scope creep

Little features in each
iteration

Extreme

This methodology involves
simplicity, communication,
feedback and courage to tune
development practices to achieve
better customer satisfaction.


Focus on business value

Stress on programmers

JAD (Joint Application
Development)

This methodology involves the end
user in the design and
development through successive
collaborative
workshops called JAD
sessions.

Faster development time
and greater customer
satisfaction

More dependence on
end users at times might
require some additional
over work or underwork
to the end application


Lean

This methodology involves
maximizing customer
value with
minimal resources

Focuses on optimizing
the flow of products and
services to customers

Might lose some
competitive advantage
for lack of more core
features


RAD (Rapid Application
Development)

This methodology involves building
software
through:



Shorter development
cycle
s



Reduced scalability



Reduced features




RAD Team members are
usually multi
-
talented
and self
-
driven motivated
people who perform
various roles including
analysts, designers and
programmers,
etc. as and
when it is necessary.


-
Source from Wikipedia









Gathering requirements using
workshops and focus groups



Prototyping and iterative
development and testing of
design components



Re
-
use of software
components



Tight schedule



Less formality in project
management functions




Dynamic
requirements
implementation



Increased end user
involvement
throughout the
development process



Greater programmer
flexibility in
incorporating
requirement changes


Scrum

This methodology stresses on:




Individuals and interactions
over processes and tools



Completed functionality over
comprehensive
documentation



Customer collaboration over
contract negotiation



Responding to change over
following a plan




Increased
productivity by
addressing business
requir
ements in
terms of
product/sprint
backlogs




Flexibility and
Adaptation to
changes in
requirements



Highly dependent on
the Scrum Master
who ensures the
team is functional
and productive




Scope creep is highly
possible






Our experience with RAD?

(CSC,
Chrysler and RAD)

Introduction

We

work for Chrys
l
er account at CSC.

The unit is involved in development and maintenance of a number of applications
in Chrysler. The type of project work is categorized under 3 types:

1.

Application Support

a.

Servs

b.

Trouble Ticket
s

2.

RSA

a.

Fixed Price

b.

T&M (RAD)

Application Support

Application support comprises of application maintenance activities. These activities are further sub
-
categorized into
two sub types Time based & Date based activities.

Servs involve minor development work w
hereas Trouble Tickets
involve troubleshooting bugs in the application.

RSA

(Fixed Price)

RSA comprises of development projects. They involve major enhancements

to existing applications
or new applications

being

developed for Chrysler
.

The mode of engageme
nt between CSC and Chrysler
for

the above

two
types involves a fixed process model through
various level
s of approvals, quality gate checks

and documentation.

RAD

(T&M)

The
use of RAD methodologies at Chrysler is

informal at best.
The engagement
involves direct interaction between
developers at CSC and IT managers at Chrysler.

The traditional requirements of approvals, quality gate checks and detail
level estimates (DLE) are reflective of waterfall design and not the iterative processes
required
of RAD. Within these
constraints, the
CSC
-

Chrylser

implementation of RAD methodologies has been limited to RAD and JAD techniques.


Inception of RAD Team


Withi
n the ICT Quality organization

the
Rapid Application Development

Team
was
started on June 1
st

2010

as an
experiment to
facilitate

rapid development of applications
.
The RAD Team follows the agile software development
process. RAD comprises of pure development activities with primary objective of building small scale applications at a
rapid phase
.

The
experiment

was to leverage the advantages of
RAD’s
agile
software development process
es

in order

to avoid the
factors causing delay
in

project execution.

The
RAD Team
has
typically
been
involved

in
building applications from
scratch to fully functi
onal in short span of time.


The
RAD team is primarily involved in
the
development of Web
applications on Java/ J2EE and DB2 platform.

A side benefit of the first year of the RAD team has been the initial development and architecture of a standardized
soft
ware framework used to speed the application development process. This framework, in general, consists of session
management, menuing, the ability to manage and store small tables and user, security and ldap administration.

Team Objective:

The key objecti
ve of Rapid Application Team was to avoid or overcome factors which resulted in delay or slippage in
project time line. Some of the common factors which cause delay in projects were:



C
hanging

business

requirement
s

and the discovery of new requirements

duri
ng Project life cycle.



Approval process, requiring layers of approvals across client and CSC.



Lack of communication between layers of team hierarchy due to the development team not being
engaged until late in the process



Difficulty of documenting extensive

and often changing requirements


Team Structure:

Currently
R
AD team comprises of
five

members,
three

Developers (CSC employees)

in

offshore
,
one

req
uirements
analyst (
Chrysler

)

at
onsite

and
one
Project Manager (Chrysler employee)

onsite
.

The team’s
sole, focused purpose is to
support RAD efforts. This smaller, focused team structure is used to facilitate direct communication between
developers and the client. This allows for replacing strict requirement documents and DLE with ongoing emails, phone

calls and development.

RAD team Process:

There are

regular interactions between RAD team members
onsite and
offshore through

email
s
.

Check point s
tatus calls
occur
once
a week and group discussion conference call occurs
as and when required.

A typical p
roject would kick off
with requirements being

communicated through calls,
emails

and sample documents
, followed by active participation of
all members in discussing and analyzing the requirement
s

;
on
e

module at a time. Every discussion is followed by a li
ne
of action items to each member of the team.

The client specific approval process to create an environment for
the new

application is managed by the onsite
members (Project Manager and Requirements Analyst) and in parallel the offshore developers are in
volved in
developing the base code and prototypes
for

the modules discussed.

Once the environment is up the
base framework architecture and initial prototype
are

used
in
design meetings

and

deployed in
the
test region. Here development and testing occurs
through continuous iterations over the prototype

which would

convert it to a full
-
fledged application. All Team members are invol
ved

in

testing of the application to
ensure stability of the application.

Approval Process:

The traditional process for a proje
ct work in Application Support
or RSA would involve s the following steps

with the
SeRV system. The steps are listed
chronologically
:

1.

Preparation of

Business Requirement Document

2.
Preparation of
Requirement Understanding Document

(QG1 sign
-
off by ICT & Business Partner)

3.
Check for
Impact

Analysis

4.
Provide
Estimation

Document

5.
Provide
Design

Document

6. IPR and ECC

request processing

(Environment Creation)

7
. Construction

of Application

(Coding and Unit Testing)

8.
UAT

of App
lication

9. Deployment

of Application
.

(QG2 sign
-
off by ICT & Business Partner



required by Chrysler CIO
)

10.
Deployment
Approval (
QG3 sign
-
off by ICT & Business Partner)

The RAD team process involves the following step
s chronologically
:

1.

Preparation of Bu
siness Requirement Document

and/or collection of sample reports, spreadsheets, data and
process flow diagrams.

2.

Determine core functionality requirements and general application architecture.


Note
: Chrysler has mandated the SeRV process and the Chrysler CIO requires QG2 sign
-
off before code is moved to
production. The RAD Team uses SeRVs with Rite Sourced = No, Payment Method = N/A, Required HLE/DLE = No. The
Business Partner signs
-
off on a QG1
with minimal documentation. This sign
-
off allows for triggering the process to
request DBA support.

3
.

IPR

and ECC request processing

(
Environment Creation)

4
. Recursive Clarifications,

Construction
and Deployment of prototypes

5.
Deployment of final Ap
plication.

(QG2 sign
-
off by ICT & Business Partner)

Note
: Additional SeRVs are created, as necessary, for on
-
going deployments.















Hence lesser

number of steps results in faster processing and faster development of applications.

Module

Prioritized
Requirement

Prototype

Stake Holder

(ITM)
verification

Customer
Verification

Tackling
Changing requirements

C
ontinuous iterations over the prototype is the key
for

tackling

change in requirements.

Rapid Application Team has

continuous interaction
s

with business partners. Since the business partners are in touch
across all the stages of the
project

lifecycle
. A
ny change in the requirements
can be

addressed
and accommodated

during iteration
. The business
partner also gets
to experience the

working prototype
rather than
ponder over the design
document
. Hence he/she would
be able

to

make better decision on

the

changes if
they need

any.

The RAD team developers comprise of self
-
motivated and tech
and design

savvy individuals who build applications with
the primary objective of reusability.

The code is constructed in generic fashion wi
th the objective

of
reusability for
future applications.

Communication strategy:

Small team size contributes to quicker information flow from business partner to onsite members and

eventually
offshore developers.
RAD team keeps most of its communication

in
formal but

to the point. It’s common to have emails
describing issues/resolutions or draft documents being circulated to and fro to get things moving. All items for a week
are addressed in the status call and action items for each are determined.

A
Status

tracker is maintained by the offshore team to keep track of
all the issues reported through emails to ensure
nothing is missed out during the status call.


Prototyping to Documentation:

The
RAD team emphasi
s is

on building proto
types
rather
than maintaini
ng detailed design documents
,

but it does
maintain a
n

Application Items Tracker

Document

which acts as:



Clarification logger listing out all the application related queries




Status tracker listing out on the components currently
being worked

on.




Issue log
ger for capturing the issues faced in testing phase

Since requirement analysis, construction of prototype and testing happen in parallel
for an
iteration
, a

single Application
Items Tracker works as Clarification logger for requirement analysis, Status tra
cker to track development
s

and issue
logger to log
the
issue
s

raised during testing.

During iteration

on
a

prototype
, RAD team works on

issues logged in the
Application Items Tracker
based on the priority
assigned to each

issue
.

Once
an

issue has been fixed the changes are shown t
o the business partners for
feedback
. If any
suggestions / enhancements

are

pointed
out
,

then those
are

taken
up
for the next iteration immediately.

The
only
other two documents RAD

Team maintains

are Productio
n Support Guide and RAD Hours tracker. The
Production Support Guide is a mandatory document as it facilitates effective transition of an application management
from RAD team to other Application Support Teams. The RAD Hours tracker is
an

internal document
maintained by RAD
offshore

team
. This document catalogs effective hours spent by
a
developer on different activities involved in building
an application.

This is later used in
internal
estimation

for support when application transitions to from RAD team to

Application support team
.


Deployment Periodicity

In
the past
RAD Team deployment
has
happen
ed

on an average once every two days and sometimes it may occur
multiple times on the same day. The objective is to get the
changes/
fixes deployed as soon they are

constructed

and
unit tested by the developer.


As a check point the

changes are validated once
again

by the
onsite team members before

they reach the business partner.


With the mandate in late 2010 from the Chrysler CIO that all production deployments re
quire QG2 sign
-
off, these
deployments will happen less often. Currently iterations are held and combined and/or multiple SeRVs created to
satisfy this requirement.

Statics


The RAD team has been a success, listed

b
elow are the applications

that were

dev
eloped by
RAD team in the last 22
months
. The applications are
listed in

chronological order
:

Application Name

Project Timeline

No of Resources

PQAT

1 year

2

PQAS

6 months

2

CVQS

4 months

2

RHB

1 month

2

RB5

1 month

1

CPA

6 months

3


PQAT was
first
application

and its

development
was

longer
as

it was the first application
to be developed
. This was due
to minimal resources and the start of the development of a basic framework.


It can be observed

that
the next
sequential applications

were

at a faster

phase by advocating
reusable code and
the reusability concept of
Agile
Software
Development.

Going Forward
… (
Consequential
I
nnovations
)
:

The n
eed to develop applications at rapid phase

led RAD team to find innovative solutions
such that this could be
acco
mplished with lesser effort
.
One such innovation was focused at drilling down the concept of reusability at all levels.
The idea was to “
Build once
, Build
smart

and
Reu
se everywhere

.

The common functionalities observed among most of the a
pplications

buil
t by RAD team
involve
d Tabular
representation of data
,

Graphical representation of Data,

CRUD operations, Workflow
,

Role Access,
Reporting
, and
Application Administration
.

The high level idea was to build these functionalities once and customize them for each new
application.




Reusable
component at
each layer

Distributed
Components

Distributed
functional
modules

Centralization
of Tables

The Idea (Reusability at All Levels):

The idea of reusability is quite common in the programing world. The RAD team
just took this concept further.

RAD
team is primary involved in development of Web Applications on Java stacks with DB2 as Database. The Architecture of
Web Application can be described in 3 layers.


o

Presentation Layer
: Comprises of the Front end Application screens (HTML). This is usually maintained in
java script

and sometimes driven by server
-
side JSTL (Java Code).

o

Business Layer
: Comprises on the Server side Java code. This layer involves the specific business logi
c unique
to each application.

o

Database
: Comprises of the storage (DB2) to persist data used in the application.

The first level of the idea is to reuse componen
ts

at each of these layers

by:





Develop
ing

c
ustom
Java

s
cript

library files along with custom j
ars to provide

a

standard presentation
logic that could be used by any RAD
or non
-
RAD

application.

(Presentation Layer)



Develop
ing

al
l the c
ommon
business logic

such as Re
porting, Workflow, Role Access, Mail

etc.
as
pluggable jars such that they could be
plugged into any new application built.
(Business Layer)



Develop
ing

a

centralized d
atabase for maintaining common functiona
lities across
the
applications
, i.e.
common tables for specific data such as

application startup data
which would

facilitate e
asier
ma
intenance of
different applications maintained by RAD team.(Database Layer)

This
would

result in increased productivity as the amount of effort spent by developer to develop a screen or apply the
business logic would reduce drastically when most of the too
ls to the job

are available as custom jars that had to be
plugged into the application.


The second level of the idea is to avoid copying
the jars files for each

application.

The centralized Database approach achieved this in the database layer but the s
ame
can

be achieved in the presentation
layer and business layer by using shared libraries that were offered by the application server.

Most of the Web Applications in Chrysler
are

deployed on Websphere Application
S
erver. Placing the common custom
jars

b
uilt for presentation logic (
such as rendering tables
)or business logic (such as role access control) in the shared
library
enables

these functionalities to be available across all applications

not just RAD applications

that are
built and
deployed in the n
etworked
Web sphere

Application
S
erver.

This
would result in lesser code hence cleaner code that is easier to maintain by a developer. This would give RAD Team
the ability to provide patch updates or fixes for all applications using the shared jar. A fix i
n one application would
transcend to all the other applications

resulting

in easier maintenance and quicker bug fixes.

The third level of the idea is to
take this
reusability
and apply it to

centralizing

common
framework

modules in
different

applications i
.e. reuse functional modules across applications.

This level of the idea is still in ideation. The essential aspect here is to reuse the functionality including the screens b
uilt
for one application in other applications.

This
can be capitalized for
the

application administration modules. Most of the web applications developed by RAD team

worked on data driven logic which relied
on startup data. One of the common administration functionality built for the
application was to maintain these startup

codes. Other common administration modules to most of the applications
built by RAD Team were
maintaining users,
and
role access

control.

The objective was to develop these modules once for
an

application and make the other application
s

to
communicate
wit
h

this application in displ
aying these modules
.

The design is such that t
he
re would be

one common base application
hosting the common modules
and this would interface

to a centralized database as shown in the figure below. The
common base application would

intuitively respond to different application request
s

by retrieving the correct data for
each application during display of screens.

The diagram below illustrates all the complete reusable architecture.


Once the above architecture is put
in
to practice,

Applications could be developed at much faster phase than

they were

built earlier. The following data below provides a comparison of timelines involved in developing an application with the
new architecture
in comparison to the old one

o

Application Tracea
bility will be increased by 20%.This feature will also log any deviation from happy
path.

o

Productivity will be increased by 40% since all the components are designed as reusable interfaces and it
reduces the effort for customization.

o

It will reduc
e the ma
intenance cost by 25% as pluggable jars are

distributed among different
applications.

The RAD methodology of building applications

has been a success and the constant pursue to develop faster was
consequence for this new
innovation
.



How can CSC leverage
RAD?




It’s a known fact
that the impact of
recession has

affected the once flourishing IT

Service industry. The primary
focus on all
IT service industry has been in sustainable development. There is a constant pressure from the clients for
service cost r
eduction. In fact for our project Chrysler, The target set for 2012 is on finding innovative solutions for cost
reduction and improve performance of
Applications. The

need of the hour for IT service industries is to find innovative
strategies
in

building a
nd maintaining applications with lesser effort and Agile Software development happens to be the
best and feasible solution.

A note of caution; Agile works efficiently only when the project scope is small.

Or a larger
project broken down into smaller functional design prototypes and modules

Currently all the maintenance projects follow the SDLC process where
the e
mphasis is more on requirement
gathering
and

documents this leading to the consumption of time

and dela
y in project timeline, In Agile Software Development
process the e
mphasis is on prototype
.

T
his helps us in
building

the
applications

at rapid phase there by reducing the cost

to a good extent
. Business
partners’

involvement is throughout the proj
ect phase helps in getting the
lesser chances for
major changes at last stage of the application development.

Following Agile
Software Development

drives developers to focus on reusability as that enables them to save
time and effort in application develop
ment. In
our experience following Agile
Software Development process

lead us to
three significant innovations

1.

Building reusable jars. This helped reducing development time.

2.

Shared

library

Concept, where

multiple applications use the same jar.

This reduce
d unnecessary copy of
code to the server and hence better performance and centralized maintenance.

3.

Centralized database Concept, where multiple applications sharing the same table structure

and
eventually
,
sharing the common module screens.

For the reason
s states above,
CSC

being a major player in IT service segment, could leverage the benefits of Agile
software development and take the drive down innovations in effort reduction to the next level.

Summary

In order to have competitive edge in business funct
ions, “high responsiveness to business needs” is
one of

the key
factors. And to achieve the same, projects are nowadays required to follow rigid timelines even at the cost of

architecture and design
, if necessary. This enables the development team to foc
us on
business processes which have

the highest business value and deliver the same rapidly.

“Change” is regarded mostly as the primary reason for slippage in project schedule. In traditional development process,
changes in functional requirements causes
significant costs in redesigning and redevelopment of applications.

And,
Agile Software Development confronts

these dynamic requirement changes by limiting the project’s requirement
to change by iterative shortened development cycles, and reducing the cos
t of incorporating the changes by
implementing them well before the final phase of development.
























Worldwide CSC Headquarters


The Americas

3170 Fairview Park Drive

Falls Church, Virginia 22042

United States

+1.703.876.1000


Europe, Middle East, Africa

Royal Pavilion

Wellesley Road

Aldershot, Hampshire GU11 1PZ

United Kingdom

+44(0)1252.534000


Australia

26 Talavera Road

Macquarie Park, NSW 2113

Australia

+61(0)2.9034.3000


Asia

20 Anson Road #11
-
01

Twenty Anson

Singapore
079912

Republic of Singapore

+65.6221.9095


About CSC

CSC is a global leader in providing technology
-
enabled solutions and services through three primary lines of business.
These include Business Solutions and Services, the Managed Services Sector and the
North American Public Sector. CSC’s
advanced capabilities include system design and integration, information technology and business process outsourcing,
applications software development, Web and application hosting, mission support and management consult
ing. The
company has been recognized as a leader in the industry, including being named by FORTUNE Magazine as one of the
World’s Most Admired Companies for Information Technology Services (2010). Headquartered in Falls Church, Va., CSC
has approximately 9
3,000 employees and reported revenue of $16.2 billion for the 12 months ended December 31,
2010. For more information, visit the company’s website at
www.csc.com
.