Software Engineering

1. Software Engineering November 7, 2001 Rationale Management Joseph Conron Computer Science Department New York University jconron@cs.nyu.edu

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. 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. 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. 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. 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. display?:Issue input?: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. display?:Issue input?:Issue addressed by addressed by addressed by text-based:Proposal point&click:Proposal The display used by the dispatcher can be a text only display with graphic characters to represent track segments. The interface for the dispatcher could be realized with a point & click interface. Proposals • Proposals are possible alternatives to issues. • One proposal can be shared across multiple issues.

9. input?:Issue text-based:Proposal raises terminal?:Issue Which terminal emulation should be used for the display? Consequent issue • Consequent issues are issues raised by the introduction of a proposal. display?:Issue addressed by addressed by addressed by point&click:Proposal

10. display?:Issue input?:Issue addressed by addressed by addressed by text-based:Proposal point&click:Proposal raises meets meets terminal?:Issue fails fails usability$:Criterion availability$:Criterion The time to input commands should be less than two seconds. The CTC system should have at least a 99% availability. Criteria • A criteria represent a goodness measure. • Criteria are often design goals or nonfunctional requirements.

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. display?:Issue input?:Issue addressed by addressed by addressed by text-based:Proposal point&click:Proposal raises meets meets terminal?:Issue is opposed by fails fails usability$:Criterion availability$:Criterion is supported by availability-first!:Argument 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. Arguments (2)

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. text-based&keyboard :Resolution resolves resolves display?:Issue input?:Issue addressed by addressed by addressed by text-based:Proposal point&click:Proposal raises meets meets terminal?:Issue is opposed by fails fails usability$:Criterion availability$:Criterion is supported by availability-first!:Argument Resolutions (2)

15. Proposal Criterion$ Representing rationale: issue models resolves Resolution. Issue? is a consequence responds meets + fails - supports + objects to - supports + objects to - Argument!

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. 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. 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