March 20, 2001CSci Clark University1 CSci 250 Software Design & Development Lecture #17 Tuesday, March 20, 2001

March 20, 2001CSci Clark University2 Class Format for Today §Collect Design Documents §Questions §Quiz on Chapter 8 §Lecture on Chapter 8

March 20, 2001CSci Clark University3 Questions? §About Chapter 8 §About design assignment §About Content Index §Anything else?

March 20, 2001CSci Clark University4 Chapter 8 Rationale Management

March 20, 2001CSci Clark University5 What is Rationale? §Justification of decisions §Supports the decision making process §Records corporate & developer knowledge “Capturing the justification of decisions effectively models the dependencies between starting assumptions and decisions. When assumptions change, decisions can be revisited.”

March 20, 2001CSci Clark University6 Rationale Models §Represent reasoning that leads to a system: l Why the system is structured the way it is l Why the system behaves the way it does §Models include: l Issues that were addressed l Alternatives that were considered l Decisions made to resolve issues l Criteria used to guide decisions l Debate through which decisions are made

March 20, 2001CSci Clark University7 When is it useful? §Changing the system: (Why?) l Adding new functionality l Removing existing functionality l Fixing an error/bug §New staff joins the project (Why?)

March 20, 2001CSci Clark University8 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

March 20, 2001CSci Clark University9 Issues §Description of a concrete problem under consideration §Often phrased as a question §Can be decomposed into smaller subissues §Can be raised by decisions made on other issues, called consequent issues §Should only focus on the problem, not possible alternatives addressing it

March 20, 2001CSci Clark University10 Proposals or Alternatives §A candidate answer to an issue (doesn’t have to be “good” or “valid”) §Different proposals addressing the same issue can overlap §A proposal can address more than one issue §Proposals can trigger new consequent issues §Should only contain information related to the solution, not its value, advantages or disadvantages

March 20, 2001CSci Clark University11 Criteria §Desirable qualities that the selected solution should satisfy §The “dimensions” against which each proposal needs to be assessed §A 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

March 20, 2001CSci Clark University12 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 decision §Can simultaneously support one entity while opposing another

March 20, 2001CSci Clark University13 Decisions / Resolutions §The alternative selected to close an issue §Can be based on several proposals §Summarizes the justifications of the selection that led to the decision, including the criteria that were used for evaluation.

March 20, 2001CSci Clark University14 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: l Proposals suggested / considered l Criteria agreed upon l Arguments which support or oppose proposals l Decisions are captured as resolutions, and action items that implement resolutions

March 20, 2001CSci Clark University15 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

March 20, 2001CSci Clark University16 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

March 20, 2001CSci Clark University17 Documenting Rationale §Rationale documents should be kept separate from system model documents. (Why?) l Document might focus only on justifying the existing system, or l Document might attempt to capture as much context as possible §Rationale documents should be created at the same time as system model documents

March 20, 2001CSci Clark University18 Rationale Model Maintenance §Roles for model maintenance: l Minute Taker: records rationale in meetings l Rationale Editor: collects and organizes rationale information l Reviewer: examines rationale captured by editor and identifies gaps or omissions §Some roles may overlap §All need access to developers’ information

March 20, 2001CSci Clark University19 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 elements §Manage change using a configuration management systems for rationale documents

March 20, 2001CSci Clark University20 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

March 20, 2001CSci Clark University21 Conflict Resolution Strategies §Majority wins §Owner has last word §Management is always right §Expert is always right §Time decides Discuss the merits/pitfalls of the above

March 20, 2001CSci Clark University22 For Next Time: Bring in some issues that came up in your group during the design phase of development