1 / 31

Chapter 8, Rationale Management

Chapter 8, Rationale Management. An aircraft example. A320 First fly-by-wire passenger aircraft 150 seats, short to medium haul A319 & A321 Derivatives of A320 Same handling as A320 Rationale: Reduce pilot training & maintenance costs Increase flexibility for airline.

peta
Download Presentation

Chapter 8, Rationale Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 8,Rationale Management

  2. An aircraft example A320 • First fly-by-wire passenger aircraft • 150 seats, short to medium haul A319 & A321 • Derivatives of A320 • Same handling as A320 Rationale: • Reduce pilot training & maintenance costs • Increase flexibility for airline

  3. An aircraft example (2) A330 & A340 • Long haul and ultra long haul • 2x seats, 3x range • Similar handling than A320 family Rationale • With minimum cross training, A320 pilots can be certified to fly A330 and A340 airplanes Consequence • Any change in these five airplanes must maintain this similarity

  4. Overview • Rationale: • What is it? • Why should you care? • Rationale methods • Representing rationale • Authoring rationale • Accessing rationale • State of practice & research • Summary

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

  6. Why rationale? Software systems are similar to passenger airplanes: They result from a large number of decisions taken over an extended period of time. • Evolving assumptions • Legacy decisions • Conflicting criteria -> High maintenance cost -> Loss & rediscovery of information

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

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

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

  10. Centralized traffic control (2) CTC systems are ideal examples of rationale capture: • Long lived systems (some systems include relays installed last century) • Extended maintenance life cycle • Downtime is expensive (although not safety critical) • Low tolerance for bugs • Transition to mature technology • Initial developers are not available

  11. display?:Issue input?:Issue Issues • Issues are concrete problem 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?

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

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

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

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

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

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

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

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

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

  21. Authoring rationale Approaches • Reconstruction • Record-and-replay • Byproduct of development methodology • Incremental and semi automated structuring Challenges • Lot of information to capture • Disruptive for developers • Formalizing knowledge is expensive

  22. Record and replay example: meeting management • Facilitator posts an agenda • Discussion items are issues • Participants respond to the agenda • Proposed amendments are proposals or additional issues • Facilitator updates the agenda and facilitates the meeting • The scope of each discussion is a single issue tree • Minute taker records the meeting • The minute taker records discussions in terms of issues, proposals, arguments, and criteria. • The minute taker records decisions as resolutions and action items.

  23. Record and replay example: database discussion agenda 3. Discussion I[1] Which policy for retrieving tracks from the database? I[2] Which encoding for representing tracks in transactions? I[3] Which query language for specifying tracks in the database request?

  24. Record and replay example: database discussion I[1] Which policy for retrieving tracks from the database? Jim: How about we just retrieve the track specified by the query? It is straightforward to implement and we can always revisit it if it is too slow. Ann: Prefetching neighboring tracks would not be much difficult and way faster. Sam: During route planning, we usually need the neighbor tracks anyway. Queries for route planning are the most common queries. Jim: Ok, let’s go for the prefetch solution. We can revert to the simpler solution if it gets too complicated.

  25. Record and replay example: database discussion minutes 3. Discussion I[1] Which policy for retrieving tracks from the database? P[1.1] Single tracks! A- Lower throughput. A+ Simpler. P[1.2] Tracks + neighbors! A+ Overall better performance: during route planning, we need the neighbors anyway. {ref: 1/31 routing meeting} R[1] Implement P[1.2]. However, the prefetch should be implemented in the database layer, allowing use to encapsulate this decision. If all else fails, we will fall back on P[1.1].

  26. Methodology by-product example:the Inquiry-Based Cycle Requirements Change Challenge Question ? D Answer ! Decide Evolution Reason . Discussion

  27. Accessing rationale Browse & search • Full text search allows to identify interesting nodes • Issue model links allow the browsing of related issues quickly Passive & active design critique • Rationale can be used by knowledge based critiques to evaluate a design Challenges • Evolving terminology • Navigation through a large flat space

  28. State of the practice Standalone issue based tools • QuestMap Problem management tools • Work flow application tracking problems and resolutions • Integrated with configuration management • Some tools (e.g., ClearQuest) allow schema to be customized RequisitePro • Requirements management • Integrated with configuration management • Explicitly captures rationale behind change

  29. State of research • Many solutions for representation exist and can be tailored to a specific problem • Progress in natural language search and in hypertext technology make access a less critical issue. • Current challenges • Integration with methodology • Integration with tools • Overhead

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

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

More Related