Build the ultimate enterprise data
warehouse using SAP NetWeaver
A look at JAD, RAD, XP, and SDLC
methodologies
Dr. Bjarne Berg
Lenoir Rhyne College
© 2005 Wellesley Information Services. All rights reserved.
What We’ll Cover …
•
Why have a Methodology at all?
•
The SAP ASAP Methodology and NetWeaver
•
Other Methodologies

Joint Application Design (JAD)

Rapid Application Development (RAD)

System Development Life Cycle Methodologies (SDLC)

Extreme Programming (XP)
•
A Framework for Selecting Your Methodology
•
Wrap up
2
Introductory Slide
•
Having the right approach to BW and NetWeaver will increase your
project's success rate.
•
Most people use ASAP as their core NetWeaver methodology, but
also leverage the best from other methods such as Joint
Application Design (JAD), Rapid Application Development (RAD)
and lately Extreme Programming (XP).
•
This session will teach you the core differences between these
methodologies and also show you when and how to pick the right
one for your project.
•
We will keep a fast pace and will not read any manuals (promise!!)
3
What We’ll Cover …
•
Why have a Methodology at all?
•
The SAP ASAP Methodology and NetWeaver
•
Other Methodologies

Joint Application Design (JAD)

Rapid Application Development (RAD)

System Development Life Cycle Methodologies (SDLC)

Extreme Programming (XP)
•
A Framework for Selecting Your Methodology
•
Wrap up
4
Business requirements
One of the fists steps is to gather the right requirements. This is done in a variety of
ways based on the methodology that the company employs. It is a complex process
and involves a period:
1.
2.
3.
4.
Discovery and Education,
Formal communication,
Reviews
Final approvals.
What user wanted
How customer described it
A NetWeaver implementation does not simply
involve a series of black-and-white technical
decisions; just because something is
technically feasible does not mean it is wise
or desirable from a business perspective.
How analyst specified it
How designer implemented it5
What are the old methodologies based on?
Most traditional methodologies are based on the System development
Life Cycle (SDLC) approach.
•Under


this approach, the two key strategic tasks are to:
Completely define applications in the context of business requirements
Select technology based on compatibility and organizational know-how.
Under the SDLC methodologies, defining an enterprise's requirements as
completely as possible is extremely important, because even modest
changes in the applications' functions is assumed to cause dramatically
changes to the resulting tactical choices.
For a SDLC methodology, the longer the project duration, the more
important the methodology is to keep the project on-track.
6
What We’ll Cover …
•
Why have a Methodology at all?
•
The SAP ASAP Methodology and NetWeaver
•
Other Methodologies

Joint Application Design (JAD)

Rapid Application Development (RAD)

System Development Life Cycle Methodologies (SDLC)

Extreme Programming (XP)
•
A Framework for Selecting Your Methodology
•
Wrap up
7
A Brief Look at ASAP
• SAP standard
• Single, pragmatic, and standardized
methodology
• Evolved out of 20 years of experience
• Manageable scope, cost, and common
expectations
• Common language
• Preconfigure documentation and tools
•
•
ASAP for BW is based on many of the same ideas and
approaches that are found in the ASAP methodology for R/3
We will take a look at some core differences….
8
What is ASAP?
Examples for Accelerators:
• Project Plan, Estimating
• Design Strategies, Scope Definition
• Documentation, Issues Db
Fill
Fillin
inthe
theBlank
Blank
Versus
Versus
Start
from
Start fromScratch
Scratch
• Workshop Agenda
• Questionnaires
• End-User Procedures
• Test Plans
• Technical Procedures
• Made Easy guidebooks (printout, data transfer, system
administration…)
9
What We’ll Cover …
•
Why have a Methodology at all?
•
The SAP ASAP Methodology and NetWeaver
•
Other Methodologies

Joint Application Design (JAD)

Rapid Application Development (RAD)

System Development Life Cycle Methodologies (SDLC)

Extreme Programming (XP)
•
A Framework for Selecting Your Methodology
•
Wrap up
10
Joint Application Design - JAD
In the late 1970s as a result of these complaints, the first versions of Joint
Application Design (JAD) were developed by Tony Crawford and Chuck Morris at
IBM.
JAD was first limited to user requirements gathering and sometimes designs of the
applications. The JAD workshop was an alternative to the structured interviews
that the SDLC methodologies advocated.
The guiding principles of a JAD sessions are:
1. Keep it very focused
2. Conducted in a dedicated environment
3. Quickly drive major requirements and interface "look & feel"
Remember: "A user sign off is a powerless piece of paper"
when matched against the fury of top management"...
11
Who Participates? - JAD
1. Facilitator – Facilitates discussions, enforces rules
2. End users – 3 to 5, attend all sessions
3. Developers – 2 or 3, question for clarity
4. Tie Breaker – Senior manager. Breaks end user ties, don’t attend
5. Observers – 2 or 3, do not speak
6. SMEs
– A few subject matter experts (SME) for understanding
business & technology
Keep it very focused and explore the interfaces. How do the user want to see the
screen layouts and functionality?
Issue
A study of 60 development projects and found that without
JAD, 35% of the functionality was missed
(Source: Caper Jones)
12
JAD - Benefits
JAD helps to merge business knowledge with information technology
design, to provide useful interaction and thereby improve the quality of
the systems being developed.
JRP, or Joint Requirements Planning, is an approach to focus on the
whole plan and execution of getting the “right” requirements. The JRP is
often a supplement to the JAD sessions that is used for the specific
program components and not a replacement for JAD.
Initially JAD did not include
the realization and the
implementation phase. It was a
set of workshops and not a
comprehensive methodology.
13
JAD - Scalability
The proponents of JAD claims that the advantages of JAD include a
dramatic shortening of the time it takes to complete a project.
It also improves the quality of the final product by focusing on the upfront portion of the development lifecycle, thus reducing the likelihood
of errors that are expensive to correct later on.
The argument was that the
traditional methods have
several built-in delay factors
that get worse as more
people become involved.
As a result, the traditional
methods were not scalable
to larger information
technology projects.
JAD has increased scalability to large
projects and can accommodate
requirements gathering from high number of
users
14
JAD - Today
When JAD first was adapted as a methodology, a major benefit was
proclaimed to be the unity of the team effort. However, as JAD gain
adaptation in the 1990s many started to cut the cost of the sessions
by reducing the travel expenses.
The distribution of the team and the reduced interaction was for
many the reason why JAD became less popular as a methodology
in the late 1990s and is today rather uncommon as the sole
development approach.
You can use JAD for requirements gathering, but also
need a more comprehensive development methodology.
JAD laid the framework for other more radical approaches such as Rapid
Application Development (RAD) and Extreme Programming (XP).
15
What We’ll Cover …
•
Why have a Methodology at all?
•
The SAP ASAP Methodology and NetWeaver
•
Other Methodologies

Joint Application Design (JAD)

Rapid Application Development (RAD)

System Development Life Cycle Methodologies (SDLC)

Extreme Programming (XP)
•
A Framework for Selecting Your Methodology
•
Wrap up
16
Rapid Application Development - A Short History
An early critic of SDLC, Barry Boehm introduced the “Spiral Model” to
reduce the risk of the projects through heavy prototyping. Each project
was divided into critical parts and high risk areas was prototyped to
drive the requirements and refine the deliverables with the users.
In the late 1970s a method known as the Evolutionary Life Cycle (ELC)
had been developed by Tom Gilb. Under this approach there were no
formal phase of a project, but each parts of the project was developed
with the users in sessions where prototypes were demonstrated and
feedback was sought.
In the 1980s Scott Shultz merged the Spiral Methodology and ELC and
create Rapid Iterative Production Prototyping (RIPP)
1. RIPP = Spiral Model (SM), + Evolutionary Life Cycle (ELC) methodologies.
2. RAD = RIPP + SDLC methodologies.
17
What is RAD?
In 1991, James Martin merged of
best of RIPP and SDLC methods
into a formal RAD methodology.
What does RAD do?
RAD compresses the phases of a
SDLC and introduces an interactive
approach for each of these phases.
It also combines the design and
construction stages into a single
phase where the development
process is interactive and not
sequential.
Each cycle of RAD is 1-21 days cycles
and not phases
18
RAD as an Engine for NetWeaver Development
The RAD core idea:
Traditional methodologies are
too slow and rigid to meet the
business demands of today’s
economy.
Developers chosen for RAD
teams should be multitalented "renaissance"
people who are analysts,
designers and programmers
all rolled into one
Source: Dr T.H. Tse
& Dr. Bjarne Berg
Prototypes
Small integrated teams - focus on small parts
of the NetWeaver system (i.e. a set of
infoCubes, web reports or functional area).
Your RAD teams should
consist of about 6 people,
including both developers
and full-time users of the
system plus anyone else has
a stake in the requirements
(Walter Maner)
19
The First Session of RAD - How?
Remember, RAD has an abbreviated blueprinting phase where meetings are executed in
short succession to get the requirements. Most of the blueprinting and realization phase
of the project are combined.
The first meeting: a one or two days meeting with uninterrupted time
Who: Power users, casual users, people who today interact with the current system and
managers who have a stake in the outcome of the information system development.
How many: A rapid pace is kept in these meetings and the number of attendees is kept at
a manageable level, with typically no more than twenty people in attendance.
Different Needs: The coordinators and business analysts will focus on shared information
needs and conduct multiple sessions if needed.
Note
Why RAD?.. Increase involvement, less business disruption, less
opinions, more consensus, information sharing and an education event.
20
RAD - The Instruments and Approach
The RAD sessions can use a "information request form" to gather the relevant information
about reports, processes and information availability being requested. It standardizes
requirements and are consolidated, prioritized and used in follow-up discussions.
Post such a form
on the intranet
and provide
an easy way to
communicate
with the team.
RAD is a spiral process that
develops a set of prototypes
Source: Dr T.H. Tse
21
RAD and Tools
The key idea of RAD with NetWeaver is the creation quick reports/ queries that users
are asked to jointly develop. In the beginning these are simply "mock-ups" with data
that can be loaded from spreadsheet in a sandbox environment.
As the sessions progresses, tools such as the SAP Query designer and the Web
Application Designer is introduced and prototyping is done in each session with the
users.
Each RAD session is a working session, NOT a presentation session. Therefore, each
session should therefore be at least 2-4 hours long (not at someone's cubicle). There
should be at least 2-3 sessions each week to keep the work going forward….
Many critics of the SDLC methodologies have started to use
Computer Aided Software engineering (CASE) and
development tools such as the SAP query designer and the
SAP web application designer to do interactive prototyping
with the users.
22
What We’ll Cover …
•
Why have a Methodology at all?
•
The SAP ASAP Methodology and NetWeaver
•
Other Methodologies

Joint Application Design (JAD)

Rapid Application Development (RAD)

System Development Life Cycle Methodologies (SDLC)

Extreme Programming (XP)
•
A Framework for Selecting Your Methodology
•
Wrap up
23
System development lifecycle methodologies - SDLC
This traditional methodologies from the 1970s, and still widely used today. In general, they
are all based upon this structured step-by-step approach to developing systems. This
rigid sequence of steps forces a user to “sign-off” after the completion of each
specification before development can proceed.
With such conventional methods, there is a long delay before the customer gets to see
any results and the development process can take so long that the customer’s business
could fundamentally change before the system is ready for use. This has been the area of
highest contention among the critics of the SDLC methodologies.
Define
Goal
Plan
Project
Execute
Plan
Close
Project
Evaluate
System Development Life Cycle (SDLC)
Plan
Analyze
Design`
Develop
Implement
Maintenance
& Support
The SDLC methodologies structures
the work into a project preparation,
an analysis, a design, a
development, a testing phase, and an
implementation phase. However, SAP
and each vendor refers to these
phases by different names.
24
The "Waterfall Methodologies"- SDLC
Source: Dr T.H. Tse
What do you do when you find
new critical requirements 2
weeks before go-live?
The SDLC methodologies are known collectively as
"waterfall methodologies".
The waterfall
It gives a false sense of clear cut stages and does
not address changes during development.
It is hard to fix mistakes or missing functionality
during integration test.
25
Getting the NetWeaver requirements - SDLC
Avoid creating a total inventory of all reports in the organization. The "top-5"
(most used) sales, distribution, inventory etc. reports from each department will
cover the vast majority of the reporting needs.
Create structured interviews with individuals that have a stake in the outcome
A single BW "report" may satisfy dozens of today's static reports. It is therefore
impossible to map each individual legacy report to a single BW report.
Avoid attempting to replicate each report based on what you might
have in place today. Accept new ways of accessing data.
26
The SAP NetWeaver Workflow - SDLC / ASAP
Integration
Testing
Create Technical
specs
No
Create Functional
specs
System Testing
Complete?
No
Yes
Unit Testing
Complete?
Yes
Configuration
Yes
Peer Review
No
Approved?
Peer Review
Yes
No
Complete?
Yes
Approved?
Structured
walkthrough
No
No
Complete?
Yes
Structured
walkthrough
27
What We’ll Cover …
•
Why have a Methodology at all?
•
The SAP ASAP Methodology and NetWeaver
•
Other Methodologies

Joint Application Design (JAD)

Rapid Application Development (RAD)

System Development Life Cycle Methodologies (SDLC)

Extreme Programming (XP)
•
A Framework for Selecting Your Methodology
•
Wrap up
28
Extreme Programming - XP
XP started in the 1990s by programmers decided that the SDLC and JAD/RAD requirements
gathering sessions took too much time and often just verified what they already knew.
The argument for XP is that traditional methodologies were developed to build software for
low levels of change and reasonably predictable outcomes.
But, the business world is no longer very predictable, and software requirements
change at extremely high rates.
Development can be completed faster with collaborative efforts of
teamed programmers.
The phases still exists, but development is highly interactive and work done in the design
phase is subject to change during the construction phase. The project is not following a
“waterfall” methodology since phases are revisited until the final solution is done.
The core premise of XP is that you can only pick 3 out of these 4
dimensions: cost, quality, scope, time.
29
XP and The Release Plan and Refactoring
The best way to understand XP is to review its approach to
work. The first piece of work is the planning. In this stage
user stories are written from a user interaction standpoint.
This is followed by determining the project development
schedule which is a result of the software release plan.
In XP, the release plan consist of many smaller go-lives.
Also, the momentum of the project, known as the “project
velocity” is measured and the project is divided into
smaller iterations.
People on the project may be reassigned to different work
in the various iterations.
Finally, from an execution standpoint, a stand-up meeting
starts each day and re-planning occurs based on
yesterday’s work progress .
30
XP and the Blueprinting
The next phase is the blueprinting phase. The guiding principle
of the blueprint is simplicity and meetings are held through
short interactive design sessions.
During the design work, stand-alone simple solutions are
encouraged to reduce risk and no value added functionality is
included during the blueprinting phase. This is done later, based
on available time during the realization phase.
The key to a successful design under XP is to refactor the work
whenever and wherever possible.
The trick is to keep on schedule and focus on what is really needed. The
"nice-to-have" items are included in the realization phase if time allows.
31
XP - The Realization Phase
During the realization phase, the customer has to be present. To assure quality, all BW
extensions must adhere to previous agreed to standards and developers are responsible
for unit testing all configuration.
A unique feature of XP is that all configuration is done in pairs and only one pair of
programmers can integrate their config into the production box at any given time.
The system is collectively owned by the developers and
final performance optimization is done after all the
configuration is integrated.
Whenever a bug is discovered, a test case is created (not before!) to verify the
extent of the error and possible impact. The testing stage relies heavily on
acceptance testing and multiple sessions are created for each iteration and for each
software release.
The XP results from the acceptance testing is scored and published to the team.
32
XP - The Critics
Many critics have raised concerns with the XP approaches:
1. Reliance on verbal communication which may lead to “finger pointing” when
things go wrong.
2. It is based on intuition-based decision making and a high degree of
dependency on individual skills.
3. Insufficient planning and does not contain any sound approach to system
verification and validation.
Some claims that XP leads to rework as a norm,
error prone systems and non-maintainable systems
that finally leads to frustrated staff, and few heroes.
33
XP - Limitations
XP does not work in “Dilbertesque” companies (companies with high degree of
control for the sake of control).
XP does not work easily in groups of more than about 20 programmers.
It is hard to implement in environment where there is a high degree of commitment to
existing data warehouses or reporting systems.
XP is hard to implement in outsourced development environment when programmers
are separated by space
XP is extremely popular among web developers, DSS communities and among
programmers. It is often used to retain and motivate the IT staff.
34
XP - How to make it Work
First you need open, honest communication among programmers and between
programmers and customers.
Programmers must enjoy their jobs, and as motivators there are no project mangers, but
rather project coaches (they may still be called “managers”).
A major issue is that collaboration is really hard and normally not rewarded in business
where winners are typically selected as individuals and not as teams.
Despite these critics XP has a strong following in the programming community.
While some see XP as a result of programmers
rebelling against the structure enforced by
companies, other sees this as a path back to “sanity”
without artificial non-value-add paper work.
35
What We’ll Cover …
•
Why have a Methodology at all?
•
The SAP ASAP Methodology and NetWeaver
•
Other Methodologies

Joint Application Design (JAD)

Rapid Application Development (RAD)

System Development Life Cycle Methodologies (SDLC)

Extreme Programming (XP)
•
A Framework for Selecting Your Methodology
•
Wrap up
36
Framework for picking your "poison"
When to Select Different Methodologies
High
Joint Application Design
(JAD)
System development Life-Cycle
based methodologies
(SDLC)
Extreme Programming
(EP)
Rapid Application Development
(RAD)
Time to
Delivery
Low
Low
High
Impact of Failure
37
The Gray areas of Methodologies
While presented as clearly delineated areas of selection, there are in
fact several dimensions when multiple methodologies can be
employed. I.e. when time to delivery is moderate, or when the impact
of failure is moderate.
When to Select Different Methodologies
High
Joint Application Design
(JAD)
System development Life-Cycle
based methodologies
(SDLC)
Time to
Delivery
Extreme Programming
(EP)
Rapid Application Development
(RAD)
Low
Low
The framework is intended
to illustrate the differences
among the appropriateness
of each methodology.
This decision is clearer in
the extreme. However, in
reality there may be “gray
zones” where more than
one answer may be correct.
High
Impact of Failure
38
What We’ll Cover …
•
Why have a Methodology at all?
•
The SAP ASAP Methodology and NetWeaver
•
Other Methodologies

Joint Application Design (JAD)

Rapid Application Development (RAD)

System Development Life Cycle Methodologies (SDLC)

Extreme Programming (XP)
•
A Framework for Selecting Your Methodology
•
Wrap up
39
7 Key Points to Take Home
SDLC is the appropriate technique when the impact of failure is high and the time to “get it
right” is available. It is a rigid structure that follows clearly defined deliverables and formal
checkpoints in form of “structured walkthroughs” of deliverables and a formal approval
process. This is why these methodologies are favored method among mission critical
application development.
RAD is the preferred methodology if the time to delivery is compressed while the impact
of failure remains high. Since RAD relies heavily on prototyping, the application is
developed faster and the end outcome is better known earlier in the process.
Extreme programming (XP) is a highly preferred method when developing web pages and
stand-alone applications. This is due to the rapid development cycle and the fact that
most web and stand-alone applications can rapidly be rewritten with minimal disruption to
the organization (the impact of failure is typically low).
Your need more
than one tool in
your shed !!
40
7 Key Points to Take Home
JAD is the appropriate technique when the delivery time is relatively high as compared
with XP and RAD. At the same time the impact of failure is low and group consensus can
be achieved since more time is available relatively to RAD and XP.
Limitations of JAD: Since the requirements are gathered by group sessions, it is unlikely
that JAD will lead to the optimal requirements for applications, but rather the consensus
of the community. When the impact of failure is high, a better approach might be to
prototype or to have structured interviews as proposed by the RAD and SDLC
methodologies.
ASAP is a great start for complex large projects where impact of failure is high.
Consider more than one approach if time to delivery is constrained or your analytical
application is not operational needed (business can work for a few days without it).
If your organization is to thrive, software development must mature to a level,
where there are many tools available to the managers, and to a level where the
“hammer” does not continuously argue that it is better than the “saw”…
41
Your Turn!
Questions?
How to contact me:
Dr. Bjarne Berg
bergb@lrc.edu
42
Resources
Five Core Metrics: The Intelligence Behind Successful Software
Management – by Lawrence H. Putnam & Ware Myers
Enterprise Architecture Planning : Developing a Blueprint for Data,
Applications, and Technology; by Steven H. Spewak ISBN:
0471599859 Publisher: Wiley
Rapid Development by Steve McConnell Paperback: 680 pages ;
Publisher: Microsoft Press; ISBN: 1556159005
Start to Finish Guide to IT Project Management by Jeremy Kadlec,
Digital: 109 pages. Publisher: NetImpress; ISBN: B0000W86H2
43
More Resources
Beck, Kent (1997) “Chrysler Comprehensive Compensation with XP”., published Feb. 2001:
The Agile Software Development Alliance
Beck, Kent (2000)., Extreme Programming Explained: embrace change., Addison Wesley
Longman, Inc., 2000
Berg, Bjarne (1997) “Introduction to Data Warehousing”., module 2., pp.88-107. New York.,
NY., Price Waterhouse LLP. October 1997.
Berg, Bjarne (2004) “Managing BW projects – part-2”., SAP project management conference,
Las Vegas, NV, WIS publishing, November.
Boehm, Barry (1986) "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT
Software Engineering Notes, August.
Boehm, Barry (1988) "A Spiral Model of Software Development and Enhancement"
IEEE Computer, vol.21, #5, May, pp 61-72.
44
More Resources
Botkin, John (1998)., "Customer Involved Participation as Part of the Application Development
Process." University of Maine.
Caristi, James (2002) “Extreme Programming: Theory & Practices”., Valparaiso University.,
SIGSEE 2002 conference tutorial.
Damian, Adrian., Hong Danfeng., Li, Holly., Pan, Dong (1999) "Joint Application Development
and Participatory Design". University of Calgary, Dept. of Computer Science.
Dennis, Alan R., Hayes, Glenda S., Daniels, Robert M. Jr. (1990) "Business process modeling
with group support systems". Journal of Management Information Systems. 115-142. Spring.
Gilb, Tom (1989)., “Principles of Software Engineering Management”., Addison-Wesley Longman.
Jennerich, Bill (1990)., "Joint Application Design -- Business Requirements Analysis for
Successful Re- Engineering." UniSphere Ltd., November.
Journal of Systems Management (1995)., "JAD basics"., Sept./Oct. ed.
Keefer, Gerold (2003)., “Extreme Programming Considered Harmful for Reliable Software
Development”., AVOCA GmbH., September ed.
45
More Resources
Kettemborough, Clifford (1999)., “The Prototyping Methodology“., Whitehead College,
University of Redlands
Larman , CraigVictor R. Basili (2003)., Iterative and Incremental Development: A Brief
History”., IEEE Computer, pp. 47-56
Martin, James (1990)., “Information Engineering Planning & Analysis, Book II”., Prentice-Hall, Inc.
Nobuhiro, Kataoka., Hisao, Koizumi., Kinya, Takasaki., & Norio Shiratori (1998). "Remote
Joint Application Design Process Using Package Software". 13th International Conference on
Information Networking (ICOIN '98)., January., pp. 0495
Soltys, Roman., Crawford, Anthony (1998) "JAD for business plans and designs"., The Process
Improvement Institute., October 1998.
Univerity of California (1996) ., “Application Development Methodology”., UCD., on-line
at http://sysdev.ucdavis.edu/WEBADM/document/toc.html
46
More Resources
The University of Texas at Austin (2004) "Joint Application Development (JAD) What do you
really want?" http://www.utexas.edu/admin/ohr/is/pubs/jad.html. Accessed on October 24.
Yatco, Mei (1999) “Joint Application Design/Development”., School of Business, University of
Missouri-St. Louis.
Wood, J. and D. Silver (1995),. “ Joint Application Development”., 2nd ed., New York : Wiley.
Wetherbe, James C. (1991)., "Executive Information Requirements: Getting It Right", MIS
Quarterly, March., p. 51.
47