Value-Based Software Engineering (VBSE) CS577a Nupul Kukreja, Barry Boehm August 30, 2013

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

3 VBSE: 7 Key Elements Benefits Analysis Negotiations Business case Analysis Risk & Opportunity Mgmt Concurrency Monitoring & Control Change Software Development Activities (577ab) Principles/Concepts behind VBSE Why VBSE?

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 * 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 * 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: –H–Highly flexible and volatile –H–Heavy dependence on collaboration amongst creative and skilled people –N–Necessitates construction and management approach radically different from traditional engineering –B–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 –I–Impossible to reason about in value neutral setting 8

Who Should Practice VBSE? Just about everyone – CTO/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 and 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 (Engine) Theory-W: SCS Win-Win What values are important? How is success ensured? Dependency Theory Who/What does success depend on? Utility Theory How important are the values? Decision Theory How do values affect decision choices? Control Theory How to adapt to change and control value realization? Results chains; value chains; cost, schedule, performance tradeoffs Multi-attribute utility; Maslow’s need hierarchy Investment theory Game theory Statistical decision theory Feedback control Adaptive control Spiral risk control Enterprise Success Theorem Theory of Justice WinWin Equilibrium & Negotiation Enterprise Success Theorem (Make winners of SCS) Theory of Justice (Being fair to all participants) WinWin Equilibrium & Negotiation (Being in WinWin State)

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

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

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 1.Benefits Realization Analysis 2.Stakeholder Value Proposition Elicitation & Reconciliation 3.Business Case Analysis 4.Continuous Risk and Opportunity Management 5.Concurrent System & Software Engineering 6.Value-Based Monitoring & Control 7.Change as Opportunity 18 VBSE12…

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

Key ‘Benefits’ of Doing BRA/Results Chain Helps identify why the stakeholders want to pursue the said initiative 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 (IRR often used and preferred in practice) – ROI 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 involved you 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 Utility Benefit 0,0 1,1 Risk averse for losses and Risk Seeking for Gains It is possible to have negative utilities  Losses 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!) Risk Probability High Low Check Utility - Loss Estimate Little Risk Low Loss of Utility High Check Probability Estimate Major Risk 26

Tools for Risk Management Risks will be recorded as the Risk Exposure (RE) metric as shown on the previous slide Probability of risk will be between 0 and 1 (or 0% – 100%) and the loss will be a ‘cardinal ranking’ from 1-10 indicating the magnitude of loss (1 being the lowest and 10 the highest) Overall RE scores can be tied for low-probability high-impact risk and high-probability low-impact risk! (and hence ‘misleading’ since prioritization could be ambiguous on RE alone) 27

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 28

Choose Relevant Process Models Lifecycle Objective (LCO) Lifecycle Architecture (LCA) Initial Operational Capability (IOC) For at least one architecture, a system built to that architecture will: For a specific detailed architecture a system built to that architecture will: An implemented architecture, an operational system that has: Support core Operational concept Satisfy core requirements Be faithful to prototype(s) Buildable in budget/schedule in the plan Show a viable Business case Have key SCSs committed to support the ‘next phase’ Support elaborated operational concept Satisfy elaborated requirements Be faithful to prototype(s) Buildable in budget/schedules in the plan Show a viable Business case Have key SCSs committed to support the full lifecycle All Major risks resolved/covered by a risk management plan Realized the operational concept Implemented the initial operational requirements Prepared a system operation & support plan Identified the initial site(s) of deployment for initial transition Identified users, operators & maintainers to assume operational roles Anchor point milestones – of the chosen process model 29

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) 30 There will be a subsequent lecture detailing Feasibility Analysis/Evidence Description

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

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! 32

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 33

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 34

References The VBSE Book: Value Based Software Engineering :  Stefan Biffl, Aybuke Aurum, Barry Boehm, Hakan Erdogmus, Paul Grunbacher 35