1 / 19

WinCBAM: From Requirements Negotiation to Software Architecture Decisions

WinCBAM: From Requirements Negotiation to Software Architecture Decisions. Hoh In Rick Kazman David Olson Texas A&M SEI/CMU Texas A&M. From Software Requirements to Architectures (STRAW 2001) May14, 2001. Outline. Why Are We Here? Where Have We Been?

delu
Download Presentation

WinCBAM: From Requirements Negotiation to Software Architecture Decisions

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. WinCBAM: From Requirements Negotiation to Software Architecture Decisions Hoh In Rick Kazman David Olson Texas A&M SEI/CMU Texas A&M From Software Requirements to Architectures (STRAW 2001) May14, 2001

  2. Outline • Why Are We Here? • Where Have We Been? • WinWin, ATAM, CBAM • An Integrated Process • Examples • Where Are We Going?

  3. Why Are We Here? Issues Discussed Requirements • Concurrent process between requirements negotiation and architectural design is inevitable • But the link between all of these is currently vague. Architecture & design Coding Testing Development Phase Architecture & design Requirements Coding Testing * Raymonde Guindon, “Human Factors: Behavioral Science”, 1990

  4. Where Have We Been? WinWin and negotiation support agents • A framework for successful requirements negotiation requirements ??? architecture ATAM CBAM • A method for analyzing architectural decisions • A method for looking at the economic consequences of architectural decisions

  5. WinWin • WinWin assists stakeholders in negotiating their requirements. • They identify their win conditions. • They negotiate the conflicts among their win conditions via a rigorous process.

  6. The ATAM • Presenting: • ATAM Steps/Business Case/Architecture • Analysis: • Architectural Approaches • Testing: • Scenario Brainstorming • Reporting • The ATAM looks at the consequences of architectural decisions in the light of the system’s stated business goals. • It elicits and documents risks, sensitivity points, and tradeoffs among the key architectural decisions.

  7. P A Business Goals Architecture Decisions $ Benefit $ S M $ Cost $ The CBAM • …takes over where the ATAM left off. • It quantifies the costs and benefits of the architectural strategies that the system’s stakeholders are considering and produces a Desirability metric. • It also quantifies the uncertainty surrounding these decisions.

  8. An Integrated Process • We propose WinCBAM: • an integrated process • allows requirements to be negotiated in terms of the Desirability (Benefit/Cost) of their realizations as architectural decisions. • This is more comprehensive than either process on its own. • Requirements negotiation with risk reduction (alleviating uncertainty through architectural decision) • Mutual satisfied (win-win) architecture selection • Faster renegotiation and architecture V&V (by tracesability)

  9. Steps of the Integrated Process WinWin Spiral Model Step 1 Step 2 Elicit Win Conditions Identify Conflict Issues Step 3 Step 8 Explore Options/ Architecture Strategies (ASs) Reach Agreements (requirements) CBAM Steps Step 4. Assess QA Benefits Step 5. Quantify the ASs’ Benefits Step 6. Quantifying the ASs’ Cost and Schedule Implications Step 7. Calculate Desirability

  10. Traceability: WinWin Win Conditions Requirements

  11. Traceability: CBAM Business Goals Scenarios Schedule Architectural Strategies Cost System Responses Benefits

  12. Traceability: WinCBAM Win Conditions Business Goals Requirements/Scenarios Schedule Architectural Strategies Cost System Responses Benefits

  13. User: Manager U2 System must be easily accessible from any location M2 Project to be complete within two months M7 Impossible for unauthorized people to access Example 1 – Conflict Resolved • USC/CSE Repository System • Stakeholders developed requirements and easyWinWin was applied, e.g.

  14. Win Conditions Conflicts with Win Conditions Direct Conflict Potential Conflict Cost Schedule U1 S2 M1, M2 M1 M2 U2 M7 M2, M9, P6 M1 M2 Conflict Identified in Requirement Level • Requirements U2, M7 conflict identified • M2 also identified as a potential conflict

  15. AS Implications Security++ Usability- Security-- Usability++ U2 M7 AS8: Replace sockets with SSL Usability 0.7 Security 0.6 Availability 0.5 ….. Benefit = 73 Cost = 2 p.w. High benefit; low cost/schedule impact => conflict resolved!

  16. Project Manager: P5 Sufficient resources allocated to maintain system. P8 Cross-communication capability of the system. Example 2 – Conflict Identified • Requirements P5 and P8 were not identified as a conflict via easyWinWin

  17. AS Implications Interoperability++ Maintainability++ X P5 P8 AS9: Common message broker Maintainbility -0.8 Interoperability 0.9 Availability -0.3 ….. Benefit = 13 Cost = 6 p.m. Low benefit; high cost/schedule impact => conflict/tradeoff found!

  18. The Pudding • The WinCBAM links Win conditions through to architectural decisions. • We not only know what decision was made, but why: • this “why” is one that meets the stakeholders win conditions and is economically feasible and with an acceptable level of risk/uncertainty. • This is the point of the combined method.

  19. Where Are We Going? • Using Desirability results to influence the choice of Win conditions and feed this back into the negotiation. • Using Portfolio theory to choose sets of architectural strategies, rather than individual ones. • Do a case study! (Volunteers?)

More Related