Oct. 30, 2003 CS 509 - WPI 1

CS 509Design of Software Systems

Lecture #9Thursday, Oct. 30, 2003

Oct. 30, 2003 CS 509 - WPI 2

Review Student FeedbackTerm Project administrationReturn Quiz #4QuestionsReview of Chapter 8Rationale Management Discussion

Class Format for Today

Oct. 30, 2003 CS 509 - WPI 3

Student Feedback

Thanks to all for filling out surveySome common responses:

Most like the in-class exercises & quizzes Most like the term project

• Some would like more time or fewer phases• Some request more exercises/examples

Most don’t like the text book Some would like more focus on SW Design

Oct. 30, 2003 CS 509 - WPI 4

MC Project & Quiz #4

Turn in Phase 4 documents Test & Implementation Plans

Hand out Phase 5 Assignment

Return Quiz #4 Solutions available on course web

site

Oct. 30, 2003 CS 509 - WPI 5

Questions?

About Term ProjectFrom last week’s classFrom the readingAnything else?

Oct. 30, 2003 CS 509 - WPI 6

Chapter 8

Rationale Management

Oct. 30, 2003 CS 509 - WPI 7

What is Rationale?

Justification of decisionsSupports the decision making processRecords corporate & developer

knowledge

“Capturing the justification of decisions effectively models the dependencies between starting assumptions and decisions. When assumptions change, decisions can be revisited.”

Oct. 30, 2003 CS 509 - WPI 8

Rationale ModelsRepresent reasoning that leads to a

system: Why the system is structured the way it is Why the system behaves the way it does

Models include: Issues that were addressed Alternatives that were considered Decisions made to resolve issues Criteria used to guide decisions Debate through which decisions are made

Oct. 30, 2003 CS 509 - WPI 9

When is it useful?

Changing the system: (Why?) Adding new functionality Removing existing functionality Fixing an error/bug

New staff joins the project (Why?)

Oct. 30, 2003 CS 509 - WPI 10

Why is it useful?

When changing the system, developers can easily find which decisions need to be revisited and which alternatives have already been evaluated

When adding new staff members to a project, they can become familiar with past decisions that went into making the system what it is today

Oct. 30, 2003 CS 509 - WPI 11

Issues

Description of a concrete problem under consideration

Often phrased as a questionCan be decomposed into smaller

subissuesCan be raised by decisions made on

other issues, called consequent issuesShould only focus on the problem, not

possible alternatives addressing it

Oct. 30, 2003 CS 509 - WPI 12

Proposals or AlternativesA candidate answer to an issue (doesn’t

have to be “good” or “valid”)Different proposals addressing the same

issue can overlapA proposal can address more than one

issueProposals can trigger new consequent

issuesShould only contain information related

to the solution, not its value, advantages or disadvantages

Oct. 30, 2003 CS 509 - WPI 13

CriteriaDesirable qualities that the selected solution

should satisfyThe “dimensions” against which each

proposal needs to be assessedA proposal that meets a criterion is said to

be assessed positively against that criterion

A proposal that fails to meet a criterion is said to be assessed negatively against that criterion

Criteria may be shared among several issues

Oct. 30, 2003 CS 509 - WPI 14

Argumentation

Someone’s opinion, agreeing or disagreeing with a proposal, criterion or assessment

Describes all aspects of the decision process

Captures the debate that drives the exploration of the solution space

Eventually leads to a decisionCan simultaneously support one entity

while opposing another

Oct. 30, 2003 CS 509 - WPI 15

Decisions / Resolutions

The alternative selected to close an issue

Can be based on several proposalsSummarizes the justifications of

the selection that led to the decision, including the criteria that were used for evaluation.

Oct. 30, 2003 CS 509 - WPI 16

Capturing Rationale in Meetings

Agenda contains issues that need to be addressed

Objective of meeting is to resolve those issues

Minutes record other rationale items: Proposals suggested / considered Criteria agreed upon Arguments which support or oppose proposals Decisions are captured as resolutions, and

action items that implement resolutions

Oct. 30, 2003 CS 509 - WPI 17

Rationale Changes Over Time

Minutes need to be reviewed after the meeting and organized into rationale model

If someone misses a meeting, may have to update rationale model asynchronously

When we revise decisions, or criteria change, need to keep rationale model up to date

Oct. 30, 2003 CS 509 - WPI 18

Reconstructing Rationale

Sometimes it is not possible to capture decisions and their justifications as they occur

Then we need to reconstruct rationale from system models, records of communications, and developers’ memories

Usually focus only on the selected solution, failing to capture discarded alternatives and their discussion

Oct. 30, 2003 CS 509 - WPI 19

Documenting Rationale

Rationale documents should be kept separate from system model documents. (Why?) Document might focus only on justifying the

existing system, or Document might attempt to capture as much

context as possibleRationale documents should be created

at the same time as system model documents

Oct. 30, 2003 CS 509 - WPI 20

Rationale Model Maintenance

Roles for model maintenance: Minute Taker: records rationale in

meetings Rationale Editor: collects and organizes

rationale information Reviewer: examines rationale captured by

editor and identifies gaps or omissionsSome roles may overlapAll need access to developers’

information

Oct. 30, 2003 CS 509 - WPI 21

Communicating about Rationale

Name issues consistently. Issues can have a short name and a number for easy reference

Centralize issues. One place should serve as a central repository, even though issues arise from different contexts

Cross-reference issues and system elementsManage change using a configuration

management systems for rationale documents

Oct. 30, 2003 CS 509 - WPI 22

Negotiating Issues

Separate developers from proposals: criticism of a proposal should not be taken as criticism of the developer

Focus on criteria, not on proposals: arguing the merits of a proposal based on accepted, agreed upon criteria helps eliminate friction

Take into account all criteria rather than focusing on a single one

Oct. 30, 2003 CS 509 - WPI 23

Conflict Resolution Strategies

Majority winsOwner has last wordManagement is always rightExpert is always rightTime decides

Discuss the merits/pitfalls of the above

Oct. 30, 2003 CS 509 - WPI 24

Rationale Discussion

What are some issues that arose during your team’s design effort?

Develop a rationale for dealing with those issues: Come up with some

proposals/alternatives What criteria can be used to guide

decisions? What decisions can resolve issues?

Oct. 30, 2003 CS 509 - WPI 25

For Next Time

Chapter 10Configuration Management