1. Oct. 30, 2003CS 509 - WPI1 CS 509 Design of Software Systems Lecture #9 Thursday, Oct. 30, 2003

2. Oct. 30, 2003CS 509 - WPI2 §Review Student Feedback §Term Project administration §Return Quiz #4 §Questions §Review of Chapter 8 §Rationale Management Discussion Class Format for Today

3. Oct. 30, 2003CS 509 - WPI3 Student Feedback §Thanks to all for filling out survey §Some common responses: l Most like the in-class exercises & quizzes l Most like the term project Some would like more time or fewer phases Some request more exercises/examples l Most don’t like the text book l Some would like more focus on SW Design

4. Oct. 30, 2003CS 509 - WPI4 MC Project & Quiz #4 §Turn in Phase 4 documents l Test & Implementation Plans §Hand out Phase 5 Assignment §Return Quiz #4 l Solutions available on course web site

5. Oct. 30, 2003CS 509 - WPI5 Questions? §About Term Project §From last week’s class §From the reading §Anything else?

6. Oct. 30, 2003CS 509 - WPI6 Chapter 8 Rationale Management

7. Oct. 30, 2003CS 509 - WPI7 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.”

8. Oct. 30, 2003CS 509 - WPI8 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

9. Oct. 30, 2003CS 509 - WPI9 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?)

10. Oct. 30, 2003CS 509 - WPI10 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

11. Oct. 30, 2003CS 509 - WPI11 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

12. Oct. 30, 2003CS 509 - WPI12 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

13. Oct. 30, 2003CS 509 - WPI13 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

14. Oct. 30, 2003CS 509 - WPI14 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

15. Oct. 30, 2003CS 509 - WPI15 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.

16. Oct. 30, 2003CS 509 - WPI16 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

17. Oct. 30, 2003CS 509 - WPI17 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

18. Oct. 30, 2003CS 509 - WPI18 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

19. Oct. 30, 2003CS 509 - WPI19 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

20. Oct. 30, 2003CS 509 - WPI20 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

21. Oct. 30, 2003CS 509 - WPI21 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

22. Oct. 30, 2003CS 509 - WPI22 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

23. Oct. 30, 2003CS 509 - WPI23 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

24. Oct. 30, 2003CS 509 - WPI24 Rationale Discussion §What are some issues that arose during your team’s design effort? §Develop a rationale for dealing with those issues: l Come up with some proposals/alternatives l What criteria can be used to guide decisions? l What decisions can resolve issues?

25. Oct. 30, 2003CS 509 - WPI25 For Next Time Chapter 10 Configuration Management