Value-Based Software Engineering (VBSE)

1. Value-Based Software Engineering(VBSE) CS577a Nupul Kukreja, Barry Boehm August 31, 2012

2. Agenda – Part 1 • Understanding the “Definition of VBSE” • Why practice VBSE? • Who should practice VBSE? • Part 2: • VBSE in detail

3. Value-Based Software Engineering • Engineering*: The science, skill, and profession of acquiring and applying scientific, economic, social, and practical knowledge, in order to design and also build structures, machines, devices, systems, materials and processes *http://en.wikipedia.org/wiki/Engineering

4. Value-Based Software Engineering • Software Engineering*: The application of a systematic, disciplined, quantifiable approach to the design, development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software *http://en.wikipedia.org/wiki/Software_engineering

5. Value-Based Software Engineering • Value: (often in the eye of the beholder) • The regard that something is held to deserve; the importance or preciousness of something • Material/monetary-worth of something • The worth of something compared to the price paid or asked for it • The usefulness of something considered in respect of a particular purpose • Etc.

6. Value-Based Software Engineering • Goal of software engineering is to create products, services and processes that add value • VBSE: brings value considerations to the foreground so that software engineering decisions at all levels can be optimized to meet or reconcile explicit objectives of the involved stakeholders

7. Why Should You Care About VBSE? • Software has unique internal and external characteristics: • Highly flexible and volatile • Heavy dependence on collaboration amongst creative and skilled people • Necessitates construction and management approach radically different from traditional engineering • Basic engineering principles of discipline, economy, rigor, quality, utility, repeatability and predictability (to some extent) still apply • Value considerations affect trade-offs with much more subtlety, severity and variety as opposed to engineering of tangible products • Trade-offs ultimately govern the outcome of the project! • VBSE draws attention to these trade-offs • Impossible to reason about in value neutral setting

8. Who Should Practice VBSE? • Just about everyone  • CIOs, Product and Project Managers making high-level (value adding) decisions • Process & measurement experts, requirements engineers, business analysts, QA/usability experts, technical leads etc. • Software Engineering researchers, educators and graduate students teaching or studying software processes, evaluating existing and new practices, technologies, methods or products • Basically all academicians, managers, practitioners and students of software engineering who realize that software isn’t created in a void is involves numerous participants 

9. Agenda – Part 2 • Understanding “Theory W” (VBSE’s engine) • VBSE’s 4+1 Theory • VBSE Agenda • VBSE: 7 Key Elements You WILL practice each of the 7 key elements over the course of 577ab

10. Theory W*: Enterprise Success Theorem “Your enterprise will succeed if and only if it makes winners of your success-critical stakeholders” • Proof of “if”: Everyone that counts is a winner. Nobody significant is left to complain. • Proof of “only if”: Nobody wants to lose. Prospective losers will refuse to participate, or will counterattack. The usual result is lose-lose. *An Initial Theory of VBSE – Barry Boehm & Apurva Jain

11. Theory W: WinWin Achievement Theorem Making winners of your success-critical stakeholders (SCSs) requires: • Identifying all of the SCSs • Understanding how the SCSs want to win • Having the SCSs negotiate a win-win set of product and process plans • Controlling progress toward SCS win-win realization, including adaptation to change.

12. VBSE Theory: 4+1 Structure • Results chains; value chains; cost, schedule, performance tradeoffs • Multi-attribute utility; Maslow’s need hierarchy Dependency Theory Utility Theory What values are important?How is success ensured? How do dependencies affect value realization? How important are the values? (Engine)Theory-W:SCS Win-Win Enterprise Success Theorem (Make winners of SCS)Theory of Justice (Being fair to all participants)WinWin Equilibrium & Negotiation (Being in WinWin State) Enterprise Success TheoremTheory of JusticeWinWin Equilibrium& Negotiation How to adapt to change and control value realization? How do values affect decision choices? ControlTheory DecisionTheory • Feedback control Adaptive control Spiral risk control • Investment theory • Game theory • Statistical decision theory

13. VBSE Theory: 4+1 (Steps) Dependency Theory Utility Theory 3. SCS Value Propositions (Win Conditions) 2. Identify SCS 4. SCS expectations management Theory-W:SCS Win-Win 5. SCS WinWin Negotiation 6, 7c. Refine, execute, monitor & control plans 1. Protagonist goals ControlTheory DecisionTheory 7. Risk, opportunity, change management

14. VBSE Theory: 4+1 (Steps) 5a, 7b. Options, solution development & analysis Dependency Theory Utility Theory 3. SCS Value Propositions (Win Conditions) 2a. Results chains 2. Identify SCS 3b, 5a, 7b. Cost/schedule/ performance tradeoffs 4. SCS expectations management Theory-W:SCS Win-Win 3b, 7a. Solution Analysis 5a, 7b. Prototyping 5. SCS WinWin Negotiation 6, 7c. Refine, execute, monitor & control plans 1. Protagonist goals 3a. Solution Exploration ControlTheory DecisionTheory 7. Risk, opportunity, change management 5a. Investment analysis, Risk analysis 6a, 7c. State measurement, prediction correction; Milestone synchronization

15. Documenting What You Know • High concurrency/backtracking when practicing the VBSE 4+1 Model • “Tacit Knowledge” generated amongst team members (Team = clients + other success critical stakeholders + student team) • How do “we” (577 staff) know what it is you know and whether you really know what you claim to know? • By documenting the findings/solutions in the appropriate artifacts as laid down by the ICSM EPG – and validate the same during the ARB Sessions and the periodic grading… …the DEN team members help out with this in their role as IIV&V-ers

16. VBSE Agenda • Objective: Integrating value considerations into the full range of existing & emerging Software Engineering principles in a manner so that they ‘compatibly’ reinforce one another • Major Elements: • VB* Requirements Engineering • VB Architecting • VB Design and Development • VB Verification And Validation • VB Planning and Control • VB Risk Management • VB Quality Management • VB People Management *VB = Value-Based

17. VBSE: Seven Key Elements • Benefits Realization Analysis • Stakeholder Value Proposition Elicitation & Reconciliation • Business Case Analysis • Continuous Risk and Opportunity Management • Concurrent System & Software Engineering • Value-Based Monitoring & Control • Change as Opportunity

18. 1. Benefits Realization Analysis DMR/BRA* Results Chain Assumption(s): -Order to delivery time is an important buying criterion AccountableStakeholder(s) OUTCOME INITIATIVE OUTCOME Contribution Contribution Implement a new order entry system Reduced order processing cycle (intermediate outcome) Increased sales Reduce time to process order Reduce time to deliver product *DMR Consulting Group’s Benefits Realization Approach

19. Key ‘Benefits’ of Doing BRA/Results Chain • Explicitly maps the intended benefits of the system to be acquired along with their causal linkages • Helps identify the initiatives need to be taken to realize the benefits • Helps identify the ‘key stakeholders’ accountable for the above initiatives NOTE: • Refined as more is learnt about the initiatives or an unforeseen benefit is uncovered • Done at multiple levels of granularity and stabilizes earlier into the SDLC than most artifacts • Lays foundation for the relevant metrics required to ‘track’ the benefits There will be a subsequent lecture detailing HOW to perform benefits analysis

20. 2. Stakeholder Value Proposition Elicitation & Reconciliation • Myth: ALL SCSs have readily expressible and compatible value propositions that can be easily turned into a set of objects for each initiative and the overall ‘portfolio’ of initiatives • The following figure is also known as a “Model Clash” Red lines indicate conflicts that can be resolved via successful negotiations Black lines indicate “inherent” conflicts – they are naturally occurring and not much can be done to fix them

21. Techniques • There are a myriad techniques that can be applied for stakeholder value proposition reconciliation: • Expectations Management: Just awareness of potential conflicts could help SCSs relax their less critical levels of desire • Visualization & Trade-off Analysis Techniques: Prototyping, scenarios, estimation models help SCSs to mutually understand most important & achievable aspects of the system • Prioritization: Helps identify which combination of capabilities best satisfies the stakeholders’ most critical needs within available resource constraints • Groupware: Some groupware tools have support for collaborative brainstorming, discussions, prioritization etc., Each of these is practiced in CS577!!

22. 3. Business Case Analysis (BCA) • Helps determine where is the best bang for the buck – i.e., capabilities providing the best ROI (Return on Investment) • Can directly influence capability prioritization • TWO Major factors influencing BCA (i.e. making life difficult) • Unquantifiable benefits (a.k.a. intangibles) • Uncertainties & risk

23. Techniques • ROI – most commonly used to justify a business case • Used and practiced in 577 • ROI calculations will be on ‘time saved’ if no money is involved (may convert time to $ money $) • If money is involvedyou should do both forms of ROI analyses. Ex.: Hiring a maintainer, cost of hosting etc., No development costs since you are NOT being paid for development (you are paying ) • Examples of how to perform ROI analysis is explained in the ICSM EPG and will be taught in class, in a later lecture.

24. 4. Continuous Risk & Opportunity Management • Understanding & Addressing People’s Utility Functions • Risk Averse • Risk Neutral • Risk Seeking Implication(s): • Very people oriented process • Continuous and Iterative • Must have plans/processes in place to identify, manage and mitigate risks 1,1 Utility It is possible to have negative utilities  Losses Risk averse for losses and Risk Seeking for Gains 0,0 Benefit

25. Central Tenet of Risk Management • Metric Risk Exposure: • RE = Probability (Loss) * Magnitude(Loss) • Ex.:profits, reputation, quality of life etc., • Prioritizing Risks using Risk Exposure (may be misleading!) Check Utility - Loss Estimate High Major Risk Risk Probability Check Probability Estimate Little Risk Low Loss of Utility Low High

26. 5. Concurrent System & Software Engineering • Increasing pace of change in IT marketplace  traditional sequential approach to software development (i.e., Waterfall model) is increasingly risky to use! • Preferable: Concurrently engineer the product’s operational concept, requirements, architecture, life cycle plans and key sections of code

27. Choose Relevant Process Models Anchor point milestones – of the chosen process model

28. Techniques • There are a myriad software process models – choose the one that best fits your organization • We use ICSM (Incremental Commitment Spiral Model) in 577ab • Feasibility evidence MUST be provided at each milestone to support the claims as shown on the previous slide • That is what we expect during your ARB (Architecture Review Board) sessions, held twice in 577a  FCR (Foundation Commitment Review) and DCR (Development Commitment Review) There will be a subsequent lecture detailing Feasibility Analysis/Evidence Description

29. 6. Value-Based Monitoring & Control • Use project’s business case for monitoring the actual business value of the capabilities to be delivered YES Develop/update business case; time phased cost; benefit flows; plans Value being realized? YES Perform to plans Assumptions still valid? NO NO Determine Corrective Actions

30. 7. Change as Opportunity • Today’s world – a not so good Present: • Expending resources to adapt to change is often stated as “rework costs” • Changes are treated as defects in change tracking systems • The real world: • Continuous ongoing changes in • Technology • Marketplace • Organizational • Stakeholders’ value propositions and priorities Opportunities can become risks if nothing is done about it!

31. A Brave New World • Organizations that can adapt to change more rapidly will succeed better in the their mission • Developing change anticipatory modular design can be considered a good investment to enhance system value in the future • Two techniques for enhancing adaptability to change: • Architecture based • Refactoring based • Example of “Change as Opportunity” • Internet and the Web and their effect on ecommerce

32. Conclusions • The notion and definition of value is getting increasingly important… … that is, of more value  • Directly capturing ‘value’ in measurable terms is hard… …but probing questions and good estimation techniques can help understand the dimensions on which to measure ‘value’ • Practicing VBSE is getting increasingly more important… …the tools/techniques in 577 are preparing you for that 

33. References • The VBSE Book: Value Based Software Engineering : • Stefan Biffl, Aybuke Aurum, Barry Boehm, HakanErdogmus, Paul Grunbacher