Joint Application Development

Presentation
CSSE591
Summer 01
Tony Thai
 Today’s Agenda
■ Introduction
– My Experience on JAD
– Background and Motivation
– JAD Philosophy
■ Why JAD?
■ What is JAD?
– Overview of Meeting Room Layout and Participants
■ Overview on Planning and Conducting JAD
■ Things can make JAD go bad
■ Tips from Experts
■ Summary
■ References
My Experience on JAD
 Background and Motivation

■ Collecting requirements is an inherently

difficult problems.

■ IBM developed the JAD technique in the late

1970's. It is considered as the best method
for collecting requirements.

■ A typical JAD project is from 3 to 6 months.

For large-scale project, it is broken down into
sections with separate JAD’s for each.
 JAD Philosophy
JAD concept is based on 4 ideas:
■ The users who do the job have the best
understanding of that job.
■ The developers have the best understanding
of how technology works.
■ The business process and the software
development process work the same basic
way.
■ The best software comes out of a process
that all groups work as equals and as one
team with a single goal that all agree on.
 So, what is JAD?

■ JAD is a technique that allows the

developments, management, and customer
groups to work together to build a product.

■ It is a series of highly structured interviewed

sessions aimed at reaching consensus on a
project’s goal and scope.

■ A typical JAD project is from 3 to 6 months.

 Why JAD?
Because JAD helps to correct some common people
and process mistakes in software development.

■ Problems: Friction between developers and users; lack of user

inputs; and lack of sponsorship.
■ Solution: JAD actively involves users and
management in the development project

■ Problems: Requirement Gold-Plating and Feature Creep

■ Solution:JAD reduces function creep by defining it
early from the beginning. It helps designer's delay
their typical "solution fixation" until they understand
the requirements better.
 Why JAD? (continue)

■ Problems: Inadequate requirement and design

■ Solution: JAD helps to avoid the requirements from
being too specific and too vague, both of which cause
trouble during implementation and acceptance.

■ JAD reduces the amount of time required to develop

systems since it eliminates process delays and
misunderstandings and improves system quality.

■ By properly using transition managers, and the

appropriate users, the typical cultural risk is mitigated
while cutting implementation time by 50%.
 Typical JAD Meeting Room
41' - 0"

F o o d & R e fre sh m e n ts

Flipchart

B la ckb o a rd
O ve rh e a d P ro je cto r

IS
Users

30' - 0"
Professionals C o m p u te r
& and P ro je ctio n
D e vice Facilitator
O ther M anagers
O bservers

Scribe

W o rk s ta tio n P rin te r

Source: Systems Analysis and Design Methods, 4th

Edition
 JAD Participants

Typically include:
– Sponsor
– Facilitator
– End users: 3 to 5
– Managers
– Scribes: 1 or more
– Observers: 2 to 3
– Domain Experts
 JAD Participant - Sponsor

■ Role:
– to give full support to the systems project by
encouraging designated users to willingly and
actively participate in the JAD session(s).

■ Decision maker:
– Sponsor makes final decisions regarding go or no-
go direction of the project.
 JAD Participant - Facilitator

■ Role: plan the JAD session, conduct the

session, and to follow through on the results.
– Keep executive sponsors involved and
participants working together
– Lead the discussion of issues, encourage the
attendees to actively participate, resolve issue
conflicts that may arise, and ensure the goals and
objectives of the meeting are fulfilled.
– Establish the “ground rules” that will be followed
during the meeting and ensure that the
participants abide by these rules.
 JAD Participants - Users and
Managers
■ These participants are normally chosen by
the project sponsor.
■ Users’ role:
– Effectively communicate business rules and
requirements, review design prototypes, and make
acceptance decisions.
■ Managers’ role
– Approve project objectives and establish priorities,
– Approve schedules and costs, and approve
identified training needs and implementation
plans.
 JAD Participant - Scribes

■ Role:
– Scribe is responsible for keeping records
pertaining to everything discussed in the meeting.

– These records are published and disseminated to

the attendees immediately following the meeting in
order to maintain the momentum that has been
established by the JAD session and its members.

■ One or more scribes for a JAD sessions

 JAD Participants - IS Staff

■ Role:
– IS personnel listen and take notes regarding
issues and requirements voiced by the users and
managers.
– Normally, IS personnel do not speak up unless
invited to do so.
– Any questions or concerns that they have are
usually directed to the JAD leader immediately
after or prior to the JAD session.
■ The makeup of the IS staff usually consists of
members of the project team.
 Overview on Planning and
Conducting JAD Sessions
■ Planning
– Most JAD sessions span a three- to five-day time
period and occasionally last up to two weeks.
– The success of any JAD session is dependent
upon proper planning and effectively carrying out
that plan.
 Overview on Planning and
Conducting JAD Sessions
■ Conducting a JAD Session
– To successfully conduct the session, the leader
should follow these guidelines:
■ Avoid the use of technical jargon.
■ Apply conflict resolution skills.
■ Allow for ample breaks.
■ Encourage group consensus.
■ Encourage user and management participation without
allowing individuals to dominate the session.
■ Make sure that attendees abide by the established
ground rules for the session.
 Overview on Planning and
Conducting JAD Sessions
■ Conducting a JAD Session
– The end product of a JAD session is typically a
formal written document.
■ This document is essential in confirming the
specifications agreed upon during the session(s) to all
participants.
■ The content and organization of the specification is
obviously dependent on the objectives of the JAD
session.
■ The analyst may choose to provide a different set of
specifications to different participants based upon their
role.
 Things can make JAD go bad

■ People aren’t up-front or have hidden

agendas

■ Slow communication and long feedback time

■ Weak or no support from upper management

■ Bad documentation
 Tips from JAD experts
■ Lighten the load
– Handouts, one-hour interviews and review
transcript. The results can become the basic of
JAD sessions.
■ Park it!
– Write offending issues down and address them at
a more appropriate time
■ Get it in writing
– Document as much of the project as you can
■ Do it together
– Set time frames and deadlines jointly
 Summary
■ JAD is task force of users, managers and
developers. It can be costly, but highly
effective.
■ Objectives
– Gather / define requirements
– Discuss business need
■ Methods
– Team usually meets at specific location
– Team has project leaders and recorder(s)
– Key users participate in intense development
effort
 References and Associated
Reading
■ Jane Wood, Denise Silver, “Joint Application
Development”, John Wiley & Associates.
■ Jeffrey Whitten, Lonnie Bentley, “Systems
Analysis and Design Methods.”
■ Alan Cline, “Joint Application Development
(JAD) for Requirements Collection and
Management”, www. Carolla.com