1. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1 Software Engineering November 7, 2001 Rationale Management Joseph Conron Computer Science Department New York University jconron@cs.nyu.edu

2. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2 What is rationale? Rationale is the reasoning that lead to the system. Rationale includes:  Issues that were addressed,  Alternatives that were considered,  Decisions that were made to resolve the issues,  Criteria that were used to guide decisions, and  Debate developers went through to reach a decision.

3. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 Rationale helps deal with change  Improve maintenance support  Provide maintainers with design context  Improve learning  New staff can learn the design by replaying the decisions that produced it  Improve analysis and design  Avoid duplicate evaluation of poor alternatives  Make consistent and explicit trade-off

4. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 Levels of rationale No rationale captured  Rationale is only present in memos, online communication, developers’ memory Rationale reconstruction  Rationale is documented in a document justifying the final design Rationale capture  Rationale is documented during design as it is developed Rationale integration  Rationale drives the design

5. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 Centralized traffic control  CTC systems enable dispatchers to monitor and control trains remotely  CTC allows the planning of routes and re-planning in case of problems

6. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 Centralized traffic control (2) CTC systems are ideal examples of rationale capture:  Long lived systems (some systems include relays installed decades ago)  Extended maintenance life cycle  Downtime is expensive (although not safety critical)  Low tolerance for bugs  Transition to mature technology  Initial developers are not available

7. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 input?:Issuedisplay?:Issue Issues  Issues are concrete problems which usually do not have a unique, correct solution.  Issues are phrased as questions. How should track sections be displayed? How should the dispatcher input commands?

8. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 Proposals  Proposals are possible alternatives to issues.  One proposal can be shared across multiple issues. input?:Issue addressed by display?:Issue text-based:Proposalpoint&click:Proposal 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.

9. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 input?:Issue addressed by display?:Issue point&click:Proposal Consequent issue  Consequent issues are issues raised by the introduction of a proposal. terminal?:Issue raises Which terminal emulation should be used for the display? text-based:Proposal

10. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 Criteria  A criteria represent a goodness measure.  Criteria are often design goals or nonfunctional requirements. input?:Issue availability$:Criterionusability$:Criterion terminal?:Issue addressed by raisesmeets fails meets fails display?:Issue point&click:Proposal The time to input commands should be less than two seconds. The CTC system should have at least a 99% availability. text-based:Proposal

11. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 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.

12. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 Arguments (2) input?:Issue availability$:Criterionusability$:Criterion terminal?:Issue addressed by raisesmeets fails meets fails availability-first!:Argument is supported by is opposed by display?:Issue point&click:Proposal 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. text-based:Proposal

13. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 Resolutions  Resolutions represent decisions.  A resolution summarizes the selected alternative and the supporting argument.  A resolved issue is said to be closed.  A resolved issue can be re-opened if necessary, in which case the resolution is demoted.

14. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14 Resolutions (2) input?:Issue availability$:Criterionusability$:Criterion terminal?:Issue addressed by raisesmeets fails meets fails availability-first!:Argument is supported by is opposed by text-based&keyboard :Resolution resolves display?:Issue point&click:Proposaltext-based:Proposal

15. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 Representing rationale: issue models ProposalCriterion$ Issue? meets + fails - is a consequence responds Argument! supports + objects to - supports + objects to - Resolution. resolves

16. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16 Representing rationale (cont’d) Many issue models have been proposed:  IBIS, QOC, DRL, WinWin  Similar in their essence  Differ in the amount of detail that can be captured Challenges  Require tool support for capture and access  Require integration with CASE and project management tools  Require integration with methodology

17. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17 Open issues  Formalizing knowledge is costly.  Maintaining a consistent design model is expensive.  Capturing and maintaining its rationale is worse.  The benefits of rationale are not perceived by current developers.  If the person who does the work is not the one who benefits from it, the work will have lower priority.  40-90% of off-the-shelf software projects are terminated before the product ships.  Capturing rationale is usually disruptive.  Current approaches do not scale to real problems

18. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 Summary  Capturing rationale is critical  Argumentation of alternatives  Explicit design criteria  Information relevant for future change  Issue models provide a good representation  Offer a structured solution to capture rationale  Make it easier to browse rationale information  Rationale needs to be integrated through out the process  Provide a short term incentive  Decrease setup cost