LECTURE 20

RATIONALE MANAGEMENT

Prepared by:
Sundas Shujah
WHAT IS RATIONALE?

Rationale is the reasoning that lead to the system.

Rationale includes:
 Issues that were addressed,
 Alternatives that were considered,
 Decisions that were made to resolve the issues,
 Criteria that were used to guide decisions, and
 Debate developers went through to reach a decision.
RATIONALE HELPS DEAL WITH
CHANGE
 Improve maintenance support
 Provide maintainers with design context

 Improve learning
 New staff can learn the design by replaying the decisions that produced
it

 Improve analysis and design

 Avoid duplicate evaluation of poor alternatives
 Make consistent and explicit trade-off
LEVELS OF RATIONALE
No rationale captured
 Rationale is only present in memos, online communication, developers’ memory

Rationale reconstruction
 Rationale is documented in a document justifying the final design

Rationale capture
 Rationale is documented during design as it is developed

Rationale integration
 Rationale drives the design
CENTRALIZED TRAFFIC CONTROL
Trains

S2 T1291> S3
Track circuits

Signals Switches
SW1 SW2 <T1515

S1 S4

 CTC systems enable dispatchers to monitor and control trains

remotely
 CTC allows the planning of routes and re-planning in case of
problems
CENTRALIZED TRAFFIC CONTROL (2)

CTC systems are ideal examples of rationale capture:

 Long lived systems (some systems include relays installed decades ago)
 Extended maintenance life cycle

 Downtime is expensive (although not safety critical)

 Low tolerance for bugs
 Transition to mature technology

 Initial developers are not available

ISSUES
 Issues are concrete problems which usually do not have a
unique, correct solution.
 Issues are phrased as questions.

ddisplay?:Issue input?:Issue

How should track sections How should the dispatcher

be displayed? input commands?
PROPOSALS
 Proposals are possible alternatives to issues.
 One proposal can be shared across multiple issues.

display?:Issue input?:Issue
addressed by addressed by addressed by

text-based:Proposal point&click:Proposal

The display used by the

dispatcher can be a text only
display with graphic characters
to represent track segments.
The interface for the dispatcher
could be realized with a point &
click interface.
CONSEQUENT ISSUE
 Consequent issues are issues raised by the introduction of a
proposal.

display?:Issue input?:Issue
addressed by addressed by addressed by

text-based:Proposal point&click:Proposal
raises

terminal?:Issue

Which terminal emulation should

be used for the display?
 CRITERIA
 A criteria represent a goodness measure.
 Criteria are often design goals or nonfunctional
requirements.
display?:Issue input?:Issue
addressed by addressed by addressed by

text-based:Proposal point&click:Proposal
raises meets meets

terminal?:Issue

fails fails

usability$:Criterion availability$:Criterion

The time to input commands should The CTC system should have
be less than two seconds. at least a 99% availability.
ARGUMENTS

 Arguments represent the debate developers went through to

arrive to resolve the issue.
 Arguments can support or oppose any other part of the
rationale.
 Arguments constitute the most part of rationale.
ARGUMENTS display?:Issue input?:Issue
addressed by addressed by addressed by

text-based:Proposal point&click:Proposal
raises meets meets

terminal?:Issue

fails is opposed by
fails

usability$:Criterion availability$:Criterion

is supported by

availability-first!:Argument

Point&click interfaces are more complex to implement than text-based

interfaces. Hence, they are also more difficult to test. The
point&click interface risks introducing fatal errors in the system
that would offset any usability benefit the interface would provide.
RESOLUTIONS
 Resolutions represent decisions.
 A resolution summarizes the selected alternative and the
supporting argument.
 A resolved issue is said to be closed.
 A resolved issue can be re-opened if necessary, in which case
the resolution is demoted.
RESOLUTIONS
text-based&keyboard
:Resolution
resolves resolves

display?:Issue input?:Issue
addressed by addressed by addressed by

text-based:Proposal point&click:Proposal
raises meets meets

terminal?:Issue

fails is opposed by
fails

usability$:Criterion availability$:Criterion

is supported by

availability-first!:Argument
REPRESENTING RATIONALE: ISSUE
MODELS
resolves
Resolution. Issue?

is a consequence
responds

Proposal meets + Criterion$

fails -

supports +
supports +
objects to -
objects to -
Argument!
REPRESENTING RATIONALE (CONT’D)

Many issue models have been proposed:

 IBIS, QOC, DRL, WinWin
 Similar in their essences
 Differ in the amount of detail that can be captured

Challenges
 Require tool support for capture and access
 Require integration with CASE and project management tools
 Require integration with methodology
OPEN ISSUES

 Formalizing knowledge is costly.

 Maintaining a consistent design model is expensive.
 Capturing and maintaining its rationale is worse.

 The benefits of rationale are not perceived by current developers.

 If the person who does the work is not the one who benefits from it, the work will have
lower priority.
 40-90% of off-the-shelf software projects are terminated before the product ships.

 Capturing rationale is usually disruptive.

 Current approaches do not scale to real problems

SUMMARY

 Capturing rationale is critical

 Argumentation of alternatives
 Explicit design criteria
 Information relevant for future change

 Issue models provide a good representation

 Offer a structured solution to capture rationale
 Make it easier to browse rationale information

 Rationale needs to be integrated through out the process

 Provide a short term incentive
 Decrease setup cost