Value-Based Software Engineering
(VBSE)
CS577a
Nupul Kukreja,
Barry Boehm
August 31, 2012
Agenda – Part 1
•
•
•
•
Understanding the “Definition of VBSE”
Why practice VBSE?
Who should practice VBSE?
Part 2:
– VBSE in detail
2
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
3
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
4
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.
5
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
6
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
7
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 
8
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
9
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
10
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.
11
VBSE Theory: 4+1 Structure
Results chains; value chains; cost,
schedule, performance tradeoffs
Multi-attribute utility;
Maslow’s need hierarchy
Dependency
Theory
Utility
Theory
How do dependencies
affect value realization?
What values are important?
How is success ensured?
How important
are the values?
(Engine)
Theory-W:
SCS Win-Win
How to adapt to change and
control value realization?
Control
Enterprise
Theory
Enterprise Success Theorem
Theory of Justice
WinWin Equilibrium
& Negotiation
How do values affect
decision choices?
Decision
Success Theorem (Make winners of SCS)
Theory of Justice (Being fair to all participants)Theory
Feedback
control
Investment
theory
WinWin
Equilibrium & Negotiation (Being in WinWin
State)
Adaptive control
Spiral risk control
Game theory
Statistical decision theory
VBSE Theory: 4+1 (Steps)
Dependency
Theory
2. Identify SCS
3. SCS Value
Propositions
(Win Conditions)
Theory-W:
SCS Win-Win
6, 7c. Refine, execute,
monitor & control plans
Control
Theory
1. Protagonist goals
7. Risk, opportunity,
change management
Utility
Theory
4. SCS expectations
management
5. SCS WinWin
Negotiation
Decision
Theory
VBSE Theory: 4+1 (Steps)
5a, 7b. Options, solution
development & analysis
Dependency
Theory
2a. Results chains
2. Identify SCS
3b, 5a, 7b. Cost/schedule/
performance tradeoffs
3b, 7a. Solution Analysis
6, 7c. Refine, execute,
monitor & control plans
Control
Theory
6a, 7c. State measurement,
prediction correction;
Milestone synchronization
3. SCS Value
Propositions
(Win Conditions)
Theory-W:
SCS Win-Win
1. Protagonist goals
3a. Solution Exploration
7. Risk, opportunity,
change management
Utility
Theory
4. SCS expectations
management
5a, 7b. Prototyping
5. SCS WinWin
Negotiation
Decision
Theory
5a. Investment
analysis, Risk analysis
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
15
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
16
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
17
1. Benefits Realization Analysis
DMR/BRA* Results Chain
Assumption(s):
-Order to delivery time is
an important buying criterion
Accountable
Stakeholder(s)
OUTCOME
INITIATIVE
Contribution
Implement a new order
entry system
OUTCOME
Contribution
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
18
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
19
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
20
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!!
21
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
22
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 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.
23
4. Continuous Risk & Opportunity Management
• Understanding & Addressing People’s Utility
1,1
Functions
Utility
– Risk Averse
– Risk Neutral
– Risk Seeking
It is possible to
have negative
utilities  Losses
Risk averse for
losses and
Risk Seeking for
Benefit
Gains
Implication(s):
0,0
• Very people oriented process
• Continuous and Iterative
• Must have plans/processes in place to identify,
manage and mitigate risks
24
Central Tenet of Risk Management
• Metric Risk Exposure:
RE = Probability (Loss) * Magnitude (Loss)
– Ex.: profits, reputation, quality of life etc.,
High
Low
Risk Probability
• Prioritizing Risks using Risk Exposure (may be misleading!)
Check
Utility Loss Estimate
Major
Risk
Check
Probability
Estimate
Little
Risk
Low
Loss of Utility
High
25
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
Lifecycle Objective
(LCO)
Lifecycle Architecture
(LCA)
Initial Operational
Capability (IOC)
For at least one
For a specific detailed
architecture, a system built architecture a system built to
to that architecture will:
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’
• 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
28
• 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
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
YES
Perform to
plans
Value
being
realized?
NO
Assumptions
still valid?
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
Opportunities can
become risks if nothing
Marketplace
is done about it!
Organizational
Stakeholders’ value propositions and priorities
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,
Hakan Erdogmus, Paul Grunbacher
34