Chapter 12 rationale management
Download
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


Rapid knowledge construction generating document templates
Rapid knowledge construction: Generating Document Templates


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


Other issue models decision representation language
Other issue models:Decision Representation Language


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