Con
quer
ing
Com
plex
and
Cha
ngin
g S
yste
ms
Ob
ject
-Ori
ente
d S
oftw
are
En
gin
eeri
ng
Rationale Management
Bernd Brügge
Allen Dutoit
Technische Universität München
Applied Software Engineering
July 5, 2005
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2
Announcements
• No exercises tomorrow (July 6, 2005)
• Next week (July 12, 2005)• Guest lecture by Frank Mang, Accenture
• Topic: Writing Project Proposals
• Two weeks from today (July 19, 2005)• Written exam (for students who need it)
• Open book (OOSE, slides, notes, dictionary, etc.)
• No electronic devices (laptops, PDAs, etc.)
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3
Overview: rationale
• What is rationale?• Why is it critical in software engineering?• Centralized traffic control example• Rationale in project management
• Meeting management
• Consensus building
• Consistency with goals
• Summary
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4
What is rationale?
Rationale has nothing to do with…
• Rational, Inc. (now IBM Rational)• Rose, ClearQuest, ClearCase
• Rational thinking• Governed by evidence and logic
• As opposed to emotion or prejudice
• Rationale is • “the reasoning or principle that underlies a particular course of
action”
• Rationale is the answer to the question why
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5
An aircraft example
A320• First fly-by-wire passenger aircraft• 150 seats, short to medium haul
A319 & A321• Derivatives of A320• Same handling as A320
Rationale • Reduce pilot training & maintenance costs• Increase flexibility for airline
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6
Why is rationale important in software engineering?
Many software systems are like aircraft:
They result from a large number of decisions taken over an extended period of time.
• Evolving assumptions• Legacy decisions• Conflicting criteria
Loss of rationale leads to
-> High maintenance cost
-> Reconstruction of information
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7
Uses of rationale
• 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
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8
Representing rationale: issue models
Argumentation is the most promising approach so far:• More information than documents
• Captures trade-offs and discarded alternatives that design documents do not.
• More structure than communication records• Communication records contain everything.
Issue models represent arguments in a semi-structured form:• Nodes represent argument steps• Links represent their relationships
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9
Decision: Smart Card + PIN
ATM Example
Question: Alternative Authentication Mechanisms?
References: Service: Authenticate
Option 1: Account number
Option 2: Finger print reader
Option 3: Smart Card + PIN
Criteria 1:ATM Unit Cost
Criteria 2:Privacy
+ +
+–
+ –
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10
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
T1291>
<T1515
Signals
Track circuits
Switches
Trains
S1
S2 S3
S4
SW1 SW2
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11
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
• Although not life critical, downtime is expensive• Low tolerance for bugs
• Transition to mature technology
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12
display?:Issueinput?: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?
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13
display?:Issue
addressed byaddressed byaddressed by
input?:Issue
text-based:Option point&click:Option
Options
• Options are possible alternatives to issues.• One option can be shared across multiple issues.
The interface for the dispatcher could be realized with a point &
click interface.
The display used by the dispatcher can be a text only
display with graphic characters to represent track segments.
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14
display?:Issue
selection?:Issue
addressed byaddressed byaddressed by
raises
input?:Issue
text-based:Option point&click:Option
Consequent issue
• Consequent issues are issues raised by the introduction of a proposal.
How should trains be selected?
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15
display?:Issue
availability$:Criterionusability$:Criterion
selection?:Issue
addressed byaddressed byaddressed by
raises meets
fails
meets
fails
input?:Issue
text-based:Option point&click:Option
Criteria
• A criteria represent a goodness measure.• Criteria are often design goals or nonfunctional
requirements.
The time to input commands should be less than two seconds.
The CTC system should have at least a 99% availability.
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16
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.
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17
Arguments (2)
display?:Issue
availability$:Criterionusability$:Criterion
selection?:Issue
addressed byaddressed byaddressed by
raises meets
fails
meets
fails
availability-first!:Argument
is supported by
is opposed by
input?:Issue
text-based:Option point&click:Option
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.
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18
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.
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19
Resolutions (2)
display?:Issue
availability$:Criterionusability$:Criterion
selection?:Issue
addressed byaddressed byaddressed by
raises meets
fails
meets
fails
availability-first!:Argument
is supported by
is opposed by
text-based&keyboard:Resolution resolvesresolves
input?:Issue
text-based:Option point&click:Option
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20
Questions, Options, Criteria
• Designed for capturing rationale after the fact (e.g., quality assessment).
• QOC emphasizes criteria
Option ! Criterion $
Question ?
positiveassessment +
negativeassessment -
consequent question
response
Argument .
supports +objects-to -
supports +objects-to -
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21
Other issue models:Decision Representation Language
Decision Problem
Alternative
Goal
AchievesLink
Claim
Claim
QuestionProcedure
is a good alternative for
achieves
supports
denies
is a result of
is an answeringprocedure for
denies
supportspresupposes
raisesanswers
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22
Overview: rationale
• What is rationale?• Why is it critical in software engineering?• Centralized traffic control example• Rationale in project management
• Meeting management
• Consensus building
• Consistency with goals
• Summary
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23
Meeting Management: Goals
• Keep meetings short• Define scope of meeting before hand
• Focus only on issues within scope
• Invite the right participants• Do not invite participants who cannot contribute
• Do invite participants whose agreement is needed
• Record to agreements for closed items• Ensure that all remember the same outcome
• Record context for open items• Shorten follow up discussions on the same theme
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24
Meeting Management: Concepts
Agenda
assigned to
Decisionselected by
Issue
scoped by Participantinvites
Option
addressed by
assessed by
Action Item
realized by
Argument
supportsopposes
Criterion
makes explicit
Minutes
records
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25
Meeting Documents
• Agenda• Defines the scope of the meeting in terms of open issues (from the
Issue Database)
• Invites participants whose agreement is needed to resolve the issues
• A time budget is allocated to each issue before the meeting
• Minutes• For each issue
o Records decisions and their realization, ORo Records the current progress of the discussion in terms of options,
criteria, and arguments
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26
Meeting Roles
• Facilitator• Responsible for keeping the meeting within scope
• Interupts or redirects participants who get side tracked
• Ensures that decisions represent consensus
• Time keeper• Informs the facilitator when an specific issue takes more time than
budgeted
• Minute taker• Records decisions, action items, options, …
• Distributes the meeting minutes to all other participants shortly after the meeting
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27
Participant Minute TakerFacilitator
Meeting Activities
Post Agenda
Review Agenda
Revise Agenda
Initiate Meeting
Facilitate Meeting Discuss &Resolve Issues Record Meeting
Close Meeting
RealizeAction Items Post Minutes
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 28
Example Issue Database
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29
Example Agenda
AGENDA: Integration of access control and notification1. PurposeThe first revisions of the hardware/software mapping and the persistent storage design have been completed. The access control
model needs to be defined and its integration with the current subsystems, such as NotificationService and TrackingSubsystem, needs to be defined.
2. Desired outcomeResolve issues about the integration of access control with notification.
3. Information sharing [Allocated time: 15 minutes]AI[1]: Dave: Investigate the access control model provided by the middleware.
4. Discussion [Allocated time: 35 minutes]I[1]: Can a dispatcher see other dispatchers’ TrackSections?I[2]: Can a dispatcher modify another dispatchers’ TrackSections?I[3]: How should access control be integrated with TrackSections and NotificationService?5. Wrap up [Allocated time: 5 minutes]Review and assign new action items.Meeting critique.
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30
Example Unstructured Minutes
Integration of access control and notification
4. Discussion ...I[3]: How should access control be integrated with TrackSections and NotificationService?
Dave: The TrackSection maintains an access list. The notification service asks the TrackSection about who has access.
Alice: We should probably reverse the dependency between TrackSection and NotificationService. Instead, the UIClient requests subscriptions from the TrackSection, which checks for access and then calls the NotificationService. This way, all protected methods are in one place.
Dave: This way the TrackSection can also more easily unsubscribe dispatchers whentheir access is revoked.
Ed: Hey, no need for access control in NotificationService: Dispatchers can see allTrackSections. As long as the NotificationService is not used for changing the TrackSection state, there is no need to restrict subscriptions.
Alice: But thinking about the access control on notification would be more general.Ed: But more complex. Let’s just separate access control and notification at this point
and revisit the issue if the requirements change.Alice: Ok. I’ll take care of revising the TrackingSubsystem API.
...
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31
Example Structured Minutes
STRUCTURED MINUTES: Integration of access control and notification
4. Discussion ...I[3]: How should access control be integrated with TrackSections and NotificationService?
P[3.1]: TrackSections maintain an access list of who can examine or modify the stateof the TrackSection. To subscribe to events, a subsystem sends a request tothe NotificationService, which in turns sends a request to the corresponding TrackSection to check access.
P[3.2]: TrackSections host all protected operations. The UIClient requestssubscription to TrackSection events by sending a request to the TrackSection,which checks access and sends a request to the NotificationService.A[3.1] for P[3.2]: Access control and protected operations are centralizedinto a single class.
P[3.3]: There is no need to restrict the access to the event subscription. The UIClient requests subscriptions directly from the NotificationService. The NotificationService need not check access.A[3.2] for P[3.3] Dispatchers can see the state of any TrackSections (see
R[1]).A[3.3] for P[3.3]: Simplicity.
R[3]: P[3.3]. See action item AI[2]....
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32
Consensus building
Problem• Any realistic project suffers the tension of conflicting goals
• Stakeholders come from different background
• Stakeholders have different criteria
Example• Requirements engineering
• Client: business process (cost and schedule)
• User: functionality
• Developer: architecture
• Manager: development process (cost and schedule)
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33
Consensus building: WinWin
• Incremental, risk-driven spiral process• Identification of stakeholders
• Identification of win conditions
• Conflict resolution
• Groupware tool• Stakeholders post win conditions
• Facilitator detects conflict
• Stakeholders discuss alternatives
• Stakeholders make agreements
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 34
Consensus building: Model
Win Condition
Issue
Option
Agreement
involves
covers
addresses
adopts
Taxonomy Category
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35
Consensus building: Process
2. Identify stakeholders’win conditions
3. Reconcile win conditions.Establish alternatives.
4. Evaluate & resolve risks.
5. Define solution
6. Validate
7. Review & commit
1. Identify stakeholders
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 36
Consensus building: EasyWinWin tool
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 37
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.
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 38
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
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 39
Consistency with goals: Model
Flexibility Low cost Security
Account+PIN Finger Print Reader SmartCard+PIN
Authentication Confidentiality Integrity
_
++ _
X
OR
AND
x
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 40
Consistency with goals: Process
Elicithigh-level goals
Refine intodetailed goals
Identify goaldependencies
Identifyoperational goals
Evaluate alternatives
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 41
Summary
• Rationale can be used in project management• To manage meetings
• To build consensus (WinWin)
• To ensure quality (NFR Framework)
• Other uses include• Architectural design
• Risk management
• Change management
• Process improvement
• …
• Open issues• Cost
• User acceptance