chapter 12 rationale management
Download
Skip this Video
Download Presentation
Chapter 12: Rationale Management

Loading in 2 Seconds...

play fullscreen
1 / 46

Chapter 12: Rationale Management - PowerPoint PPT Presentation


  • 202 Views
  • Uploaded on

Chapter 12: Rationale Management. Overview: rationale management. What is rationale? Why is it critical in software engineering? Representing rationale Authoring rationale State-of-the-practice Consensus building (WinWin) Consistency with goals (NFR Framework)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Chapter 12: Rationale Management' - roz


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
overview rationale management
Overview: rationale management
  • What is rationale?
  • Why is it critical in software engineering?
  • Representing rationale
  • Authoring rationale
  • State-of-the-practice
    • Consensus building (WinWin)
    • Consistency with goals (NFR Framework)
    • Rapid knowledge construction (Compendium)
  • Summary
what is rationale
What is rationale?

Rationale is the reasoning that led to the system.

Rationale includes:

  • the issues that were addressed,
  • the alternatives that were considered,
  • the decisions that were made to resolve the issues,
  • the criteria that were used to guide decisions, and
  • the debate developers went through to reach a decision.
why is rationale important in software engineering
Why is rationale important in software engineering?

Many software systems result from a large number of decisions taken over an extended period of time.

  • Evolving assumptions
  • Legacy decisions
  • Conflicting criteria

-> high maintenance cost

-> loss & rediscovery of information

uses of rationale in software engineering
Uses of rationale in software engineering
  • Improve design support
    • Avoid duplicate evaluation of poor alternatives
    • Make consistent and explicit trade-offs
  • Improve documentation support
    • Makes it easier for non developers (e.g., managers, lawyers, technical writers) to review the design
  • Improve maintenance support
    • Provide maintainers with design context
  • Improve learning
    • New staff can learn the design by replaying the decisions that produced it
overview rationale management1
Overview: rationale management
  • What is rationale?
  • Why is it critical in software engineering?
  • Representing rationale
  • Authoring rationale
  • State-of-the-practice
    • Consensus building (WinWin)
    • Consistency with goals (NFR Framework)
    • Rapid knowledge construction (Compendium)
  • Summary
representing rationale issue models
Representing rationale: issue models

Argumentation is the most promising approach so far:

  • More information than document: captures trade-offs and discarded alternatives that design documents do not.
  • Less messy than communication records: communication records contain everything.

Issue models represent arguments in a semi-structure form:

  • Nodes represent argument steps
  • Links represent their relationships
issues

input?:Issue

display?:Issue

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

How should the dispatcher input commands?

How should track sections be displayed?

proposals

input?:Issue

display?:Issue

addressed by

addressed by

addressed by

text-based:Proposal

point&click:Proposal

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

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

input?:Issue

display?:Issue

addressed by

addressed by

addressed by

text-based:Proposal

point&click:Proposal

raises

terminal?:Issue

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

Which terminal emulation should be used for the display?

criteria

input?:Issue

display?:Issue

addressed by

addressed by

addressed by

text-based:Proposal

point&click:Proposal

raises

meets

meets

terminal?:Issue

fails

fails

usability$:Criterion

availability$:Criterion

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

The CTC system should have at least a 99% availability.

The time to input commands should be less than two seconds.

arguments
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 2

input?:Issue

display?:Issue

addressed by

addressed by

addressed by

text-based:Proposal

point&click:Proposal

raises

meets

meets

terminal?:Issue

is opposed by

fails

fails

usability$:Criterion

availability$:Criterion

is supported by

availability-first!:Argument

Arguments (2)

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
  • Resolutions represent decisions.
  • A resolution summarizes the chosen alternative and the argument supporting it.
  • 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 2
Resolutions (2)

text-based&keyboard

:Resolution

resolves

resolves

input?:Issue

display?:Issue

addressed by

addressed by

addressed by

text-based:Proposal

point&click:Proposal

raises

meets

meets

terminal?:Issue

is opposed by

fails

fails

usability$:Criterion

availability$:Criterion

is supported by

availability-first!:Argument

overview rationale management2
Overview: rationale management
  • What is rationale?
  • Why is it critical in software engineering?
  • Representing rationale
  • Authoring rationale
  • State-of-the-practice
    • Consensus building (WinWin)
    • Consistency with goals (NFR Framework)
    • Rapid knowledge construction (Compendium)
  • Summary
authoring rationale
Authoring Rationale
  • When to capture rationale
    • In meetings
      • Real-time communications, clarifications, negotiations and resolutions
      • Meeting minutes can be recorded in structured format, based on issue model
    • Asynchronously
      • Contextual information can be added in between meetings
      • Project participants absent during meetings can read the minutes and post additional issues or options, which can be resolved offline
    • When discussing change
      • Change is inevitable – requirements change, assumptions change
      • It is important to record the rationale not only for the original decision, but subsequent changes
      • Rationale for change must be related back to past rationale
    • After the fact
      • Many project discussions are carried out informally
      • The rationale behind the decisions resulting from these discussions should also be reconstructed and recorded.
authoring rationale1
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
record and replay example meeting management
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.
centralized traffic control
Centralized traffic control
  • CTC systems enable dispatchers to monitor and control trains remotely
  • CTC allows the planning of routes and replanning in case of problems
centralized traffic control 2
Centralized traffic control (2)

CTC systems are ideal examples of rationale capture:

  • Long lived systems (some systems include 19th century relays)
    • Extended maintenance life cycle
  • Although not life critical, downtime is expensive
    • Low tolerance for bugs
    • Transition to mature technology needs careful planning
record and replay example database discussion agenda
Record and replay example: database discussion agenda

3. Discussion

I[1] Which policy for retrieving tracks from the database?

I[2] Which encoding for representing tracks in transactions?

I[3] Which query language for specifying tracks in the database request?

record and replay example database discussion
Record and replay example: database discussion

I[1] 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, let’s go for the prefetch solution. We can revert to the simpler solution if it gets too complicated.

record and replay example database discussion minutes
Record and replay example: database discussion minutes

3. Discussion

I[1] Which policy for retrieving tracks from the database?

P[1.1] Single tracks!

A- Lower throughput.

A+ Simpler.

P[1.2] Tracks + neighbors!

A+ Overall better performance: during route planning, we need the neighbors anyway.

{ref: 1/31 routing meeting}

R[1] Implement P[1.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 P[1.1].

methodology by product example the inquiry based cycle
Methodology by-product example:the Inquiry-Based Cycle

Requirements

Change

Challenge

Question ?

D

Answer !

Decide

Evolution

Reason .

Discussion

accessing rationale
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
overview rationale management3
Overview: rationale management
  • What is rationale?
  • Why is it critical in software engineering?
  • Representing rationale
  • Authoring rationale
  • State-of-the-practice
    • Consensus building (WinWin)
    • Consistency with goals (NFR Framework)
    • Rapid knowledge construction (Compendium)
  • Summary
consensus building
Consensus building

Problem

  • Any realistic project suffers the tension of conflicting goals
    • Stakeholders come from different background
    • Stakeholders have different criteria

Example

  • Stakeholders in requirements engineering
    • Client: business process (cost and schedule)
    • User: functionality
    • Developer: architecture
    • Manager: development process (cost and schedule)
consensus building winwin
Consensus building: WinWin
  • Philosophy – making winners of key stakeholders is a necessary and sufficient condition for project success
  • Incremental, risk-driven process
    • Identification of stakeholders
    • Identification of win conditions
    • Conflict resolution
  • Asynchronous groupware tool
    • Stakeholders post win conditions
    • Facilitator detects conflict
    • Stakeholders discuss alternatives
    • Stakeholders make agreements
artifacts of negotiation model
Artifacts of Negotiation Model
  • Win conditions – capture stakeholder goals and concerns with respect to a new system
  • Issues – record conflicts among win conditions
  • Options – alternative solutions to address issues
  • Agreements – used to adopt an option, or if there were no conflicts, the win conditions are adopted.
  • Taxonomy – links artifacts, acts as checklist for sufficient coverage
consensus building process
Consensus building: Process

2. Identify stakeholders’

win conditions

1. Identify stakeholders

3. Reconcile win conditions.

Establish alternatives.

7. Review & commit

6. Validate

4. Evaluate & resolve risks.

5. Define solution

winwin tool
WinWin Tool
  • Groupware tool for stakeholders to negotiate mutually satisfactory system specifications.
  • Supports WinWin negotiation model
  • Synchronous and asynchronous negotiations
  • Additional tools support tradeoff analysis and risk identification and resolution
    • A4 (Architecture Attribute Analysis Aid) – Architecture-based analysis of cost, schedule, performance and reliability.
    • Rapide – Architecture tool for modeling and simulating systems and identifying problems (deadlocks, bottlenecks, etc.) in the architecture.
    • COCOMO (Constructive Cost Model) II – Cost/schedule estimation tool.
consistency with goals
Consistency with goals

Problem

  • Once multiple criteria have been acknowledged
    • Find solutions that satisfy all of them
    • Document the trade-offs that were made

Example

  • Authentication should be secure, flexible for the user, and low cost.
consistency with goals nfr framework
Consistency with goals: NFR Framework
  • NFR goal refinement
    • NFRs are represented as goals in a graph
    • Leaf nodes of the graph are operational requirements
    • Relationships represent “help” “hurt” relationships
    • One graph can represent many alternatives
  • NFR evaluation
    • Make and break values are propagated through the graph automatically
    • Developer can evaluate different alternatives and compare them
consistency with goals process

Evaluate

alternatives

Refine into

detailed goals

Identify

operational goals

Identify goal

dependencies

Consistency with goals: Process

Elicit

high-level goals

rapid knowledge construction
Rapid knowledge construction

Problem

  • When a company is large enough, it doesn’t know what it does.
    • Knowledge rarely crosses organizational boundaries
    • Knowledge rarely crosses physical boundaries

Example

  • Identify resources at risk for Y2K and prioritize responses.
rapid knowledge construction compendium
Rapid knowledge construction: Compendium
  • Meeting facilitation
    • Stakeholders from different business units
    • External facilitator
  • Real-time construction of knowledge maps
    • The focus of the meeting is a concept map under construction
    • Map includes the issue model nodes and custom nodes(e.g., process, resource, etc.)
  • Knowledge structuring for long term use
    • Concept map exported as document outline, process model, memos, etc.
nodes in the knowledge map
Nodes in the Knowledge Map
  • Questions
  • Ideas / answers
  • Arguments – pros and cons
  • Decisions
  • Notes
  • References
questions options criteria

Question ?

consequent question

response

positive

assessment +

Option !

Criterion $

negative

assessment -

supports +

objects-to -

supports +

objects-to -

Argument .

Questions, Options, Criteria
  • Designed for capturing rationale after the fact, for long term use (e.g., quality assessment).
  • QOC emphasizes systematic
  • evaluation of options
  • against criteria
summary
Summary
  • Rationale can be used in project management
    • To build consensus (WinWin)
    • To ensure quality (NFR Framework)
    • To elicit knowledge (Compendium)
  • Other applications include
    • Risk management
    • Change management
    • Process improvement
  • Open issues
    • Tool support
    • User acceptance
ad