Issue

1
Issue Rationale ManagementandDesign Decision
MakingCS 6300 Fall, 2001
2
Overview

• Rationale
• What is it?
• Why should you care?
• Rationale and issue management methods
• Representing rationale
• Authoring rationale
• Accessing rationale
• State of practice research
• Design decision making
• Summary

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

4
Why rationale?

• Software systems are similar to passenger
  airplanes
• They result from a large number of decisions
  taken over an extended period of time.
• Evolving assumptions
• Legacy decisions
• Conflicting criteria
• -gt High maintenance cost
• -gt Loss rediscovery of information

5
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

6
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

7
Centralized traffic control

• CTC systems enable dispatchers to monitor and
  control trains remotely
• CTC allows the planning of routes and re-planning
  in case of problems

8
Centralized traffic control (2)

• CTC systems are ideal examples of rationale
  capture
• Long lived systems (some systems include relays
  installed last century)
• Extended maintenance life cycle
• Downtime is expensive (although not safety
  critical)
• Low tolerance for bugs
• Transition to mature technology
• Initial developers are not available

9
Issues

• Issues are concrete problem which usually do not
  have a unique, correct solution.
• Issues are phrased as questions.

How should track sections be displayed?
How should the dispatcher input commands?
10
Proposals

• Proposals are possible alternatives to issues.
• One proposal can be shared across multiple issues.

11
Consequent issue

• Consequent issues are issues raised by the
  introduction of a proposal.

display?Issue
addressed by
addressed by
addressed by
pointclickProposal
12
Criteria

• A criteria represent a goodness measure.
• Criteria are often design goals or nonfunctional
  requirements.

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

14
Arguments (2)
15
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.

16
Resolutions (2)
17
Overview

• Rationale
• What is it?
• Why should you care?
• Rationale and issue management methods
• Representing rationale
• Authoring rationale
• Accessing rationale
• State of practice research
• Design decision making
• Summary

18
Representing rationale issue models
resolves
Issue?
Resolution.
is a consequence
responds
meets
fails -
supports objects to -
supports objects to -
Argument!
19
Representing rationale (contd)

• Many issue models have been proposed
• IBIS, QOC, DRL, WinWin
• Similar in their essence
• 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

20
Authoring rationale

• Approaches
• Reconstruction
• Record-and-replay
• Byproduct of development methodology
• Incremental and semi automated structuring
• Challenges
• Lot of information to capture
• Disruptive for developers
• Formalizing knowledge is expensive

21
Record and replay example meeting management

• Facilitator posts an agenda
• Discussion items are issues
• Participants respond to the agenda
• Proposed amendments are proposals or additional
  issues
• Facilitator updates the agenda and facilitates
  the meeting
• The scope of each discussion is a single issue
  tree
• Minute taker records the meeting
• The minute taker records discussions in terms of
  issues, proposals, arguments, and criteria.
• The minute taker records decisions as resolutions
  and action items.

22
Record and replay example database discussion
agenda

• 3. Discussion
• I1 Which policy for retrieving tracks from the
  database?
• I2 Which encoding for representing tracks in
  transactions?
• I3 Which query language for specifying tracks
  in the database request?

23
Record and replay example database discussion

• I1 Which policy for retrieving tracks from the
  database?
• Jim How about we just retrieve the track
  specified by the query? It is straightforward to
  implement and we can always revisit it if it is
  too slow.
• Ann Prefetching neighboring tracks would not be
  much difficult and way faster.
• Sam During route planning, we usually need the
  neighbor tracks anyway. Queries for route
  planning are the most common queries.
• Jim Ok, lets go for the prefetch solution. We
  can revert to the simpler solution if it gets too
  complicated.

24
Record and replay example database discussion
minutes

• 3. Discussion
• I1 Which policy for retrieving tracks from the
  database?
• P1.1 Single tracks!
• A- Lower throughput.
• A Simpler.
• P1.2 Tracks neighbors!
• A Overall better performance during route
  planning, we need the neighbors anyway.
• ref 1/31 routing meeting
• R1 Implement P1.2. However, the prefetch
  should be implemented in the database layer,
  allowing use to encapsulate this decision. If all
  else fails, we will fall back on P1.1.

25
Methodology by-product examplethe Inquiry-Based
Cycle
Requirements
Change
Challenge
Question ?
D
Answer !
Decide
Evolution
Reason .
Discussion
26
Accessing rationale

• Browse search
• Full text search allows to identify interesting
  nodes
• Issue model links allow the browsing of related
  issues quickly
• Passive active design critique
• Rationale can be used by knowledge based
  critiques to evaluate a design
• Challenges
• Evolving terminology
• Navigation through a large flat space

27
Overview

• Rationale
• What is it?
• Why should you care?
• Rationale and issue management methods
• Representing rationale
• Authoring rationale
• Accessing rationale
• State of practice research
• Design decision making
• Summary

28
State of the practice

• Standalone issue based tools
• QuestMap
• Problem management tools
• Work flow application tracking problems and
  resolutions
• Integrated with configuration management
• Some tools (e.g., ClearQuest) allow schema to be
  customized
• RequisitePro
• Requirements management
• Integrated with configuration management
• Explicitly captures rationale behind change

29
State of research

• Many solutions for representation exist and can
  be tailored to a specific problem
• Progress in natural language search and in
  hypertext technology make access a less critical
  issue.
• Current challenges
• Integration with methodology
• Integration with tools
• Overhead

30
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

31
Overview

• Rationale
• What is it?
• Why should you care?
• Rationale and issue management methods
• Representing rationale
• Authoring rationale
• Accessing rationale
• State of practice research
• Design decision making
• Summary

32
Requirements priorities

• Not all requirements are equal
• Even contractual requirements are often
  renegotiated
• Product requirements are often assigned
  priorities
• low priority reqts. may be jettisoned to reduce
  time-to-market
• Priorities may be 1, 3, 9 or possible,
  deferred, rejected, etc.
• Priorities depend on stakeholders
• Different stake value reqts. differently

33
Case ExampleRequirements priorities
34
QFD

• Highly structured approach for tabulating
  reqts./design interactions evaluating
  alternatives
• Used for trade-offs and balancing of requirements
  and easy-to-implement features

• Requires that you can predict reliably how
  design decisions affect requirements
• Japanese technique for design manufacturing
• Principal tool is the house of quality
• Complex matrix showing dependencies trade-offs

35
Case ExampleDesign/Requirements trade-offs
36
Future Requirements
Future opportunity is like a risk opportunity
prob. of wanting priority
37
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
• Integrate with formal decision making models, if
  possible
• Decrease setup cost