1. Barry Boehm, USC CS 510, 577a Lectures Fall 2008
Value-Based Software Engineering (VBSE) and the Incremental Commitment Model (ICM)
Barry Boehm, USC
CS 510, 577a Lectures
Fall 2008

2. Outline
Value-based software engineering (VBSE) motivation and definitions
VBSE theory and process framework
Sierra Mountainbikes (SMB-1) case study
VBSE & Incremental Commitment Model (ICM)
Addressing the Cones of Uncertainty
Origins, Principles, and Views
Conclusions and references
04/07/08
©USC-CSE

3. Software Testing Business Case
Vendor proposition
Our test data generator will cut your test costs in half
We’ll provide it to you for 30% of your test costs
After you run all your tests for 50% of your original cost, you are 20% ahead
Any concerns with vendor proposition?
04/07/08
©USC-CSE

4. Software Testing Business Case
Vendor proposition
Our test data generator will cut your test costs in half
We’ll provide it to you for 30% of your test costs
After you run all your tests for 50% of your original cost, you are 20% ahead
Any concerns with vendor proposition?
34 technical and management reasons (Persson 2004)
Automated chaos; inputs only; domain misfit; …
More seriously: Test data generator is value-neutral*
Every test case, defect is equally important
Usually, 20% of test cases cover 80% of business case
* As are most current software engineering methods
04/07/08
©USC-CSE

5. 20% of Features Provide 80% of Value: Focus Testing on These (Bullock, 2000)
100 80
% of
Value
for
Correct
Customer
Billing 60
Automated test
generation tool
- all tests have equal value 40 20 5 10 15
Customer Type
03/27/07
©USC-CSE

6. Value-Based Testing Provides More Net Value60
Value-Based Testing
(30, 58) 40
Net
Value NV
(100, 20) 20 20 40 60 80
100
Percent of tests run
-20
Test Data Generator
% Tests
Test Data Generator
Value-Based Testing
Cost
Value NV 30
-30 10 35
-25 50 40 20
-20 75 55 45
-15 88 58
-10 94 54 ….
100 80
+20
-40
03/27/07
©USC-CSE

7. Value-Based Reading (VBR) Experiment — Keun Lee, ISESE 2005
By Number
P-value
% Gr A higher
By Impact
Average of Concerns
0.202 34
Average Impact of Concerns
0.049 65
Average of Problems
0.056 51
Average Impact of Problems
0.012 89
Average of Concerns per hour
0.026 55
Average Cost Effectiveness of Concerns
0.004
105
Average of Problems per hour
0.023 61
Average Cost Effectiveness of Problems
0.007
108
Group A: 15 IV&V personnel using VBR procedures and checklists
Group B 13 IV&V personnel using previous value-neutral checklists
Significantly higher numbers of trivial typo and grammar faults
Experiment
03/27/07
©USC-CSE

8. Motivation for Value-Based SE
Current SE methods are basically value-neutral
Every requirement, use case, object, test case, and defect is equally important
Object oriented development is a logic exercise
“Earned Value” Systems don’t track business value
Separation of concerns: SE’s job is to turn requirements into verified code
Ethical concerns separated from daily practices
Value – neutral SE methods are increasingly risky
Software decisions increasingly drive system value
Corporate adaptability to change achieved via software decisions
System value-domain problems are the chief sources of software project failures
03/27/07
©USC-CSE

9. The “Separation of Concerns” Legacy
“The notion of ‘user’ cannot be precisely defined, and therefore has no place in CS or SE.”
- Edsger Dijkstra, ICSE 4, 1979
“Analysis and allocation of the system requirements is not the responsibility of the SE group but is a prerequisite for their work”
- Mark Paulk at al., SEI Software CMM* v.1.1, 1993
*Capability Maturity Model
03/27/07
©USC-CSE

10. Resulting Project Social Structure
SOFTWARE
MGMT.
AERO.
ELEC.
G & C
MFG.
COMM
PAYLOAD
I wonder when
they'll give us our
requirements?
03/27/07
©USC-CSE

11. 20% of Fires Cause 80% of Property Loss: Focus Fire Dispatching on These?
100 80
% of
Property Loss 60 40 20
% of Fires
03/27/07
©USC-CSE

12. Stakeholder Values and Ethics: Fire Dispatching System
Dispatch to minimize value of property loss
Neglect safety, least-advantaged property owners
English-only dispatcher service
Neglect least-advantaged immigrants
Minimal recordkeeping
Reduced accountability
Tight budget; design for nominal case
Neglect reliability, safety, crisis performance
03/27/07
©USC-CSE

13. Why Software Projects Fail
03/27/07
©USC-CSE

14. Outline
Value-based software engineering (VBSE) motivation and definitions
VBSE theory and process framework
Sierra Mountainbikes (SMB-1) case study
VBSE & Incremental Commitment Model (ICM)
Addressing the Cones of Uncertainty
Origins, Principles, and Views
Conclusions and references
04/07/08
©USC-CSE 14 14

15. Theory W: Enterprise Success Theorem – And informal proof
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.
03/27/07
©USC-CSE

16. Theory W: WinWin Achievement Theorem
Making winners of your success-critical stakeholders requires:
Identifying all of the success-critical stakeholders (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.
03/27/07
©USC-CSE

17. Initial VBSE Theory: 4+1 - with Apurva Jain
Engine: Theory W (stakeholder win-win): What values are important?
Enterprise Success Theorem
Theory of Justice
Win-Win Equilibrium and Negotiation
Four Supporting Theories
Dependency Theory: How do dependencies affect value realization?
Results chains; value chains; cost/schedule/performance tradeoffs
Utility Theory: How important are the values?
Multi-attribute utility; Maslow need hierarchy
Decision Theory: How do values determine decisions?
Investment theory; game theory; statistical decision theory
Control Theory: How to monitor and control value realization
Feedback control; adaptive control; spiral risk control
03/27/07
©USC-CSE

18. Initial VBSE Theory: 4+1 Process – With a great deal of concurrency and backtracking
03/27/07
©USC-CSE

19. Example Project: Sierra Mountainbikes
Based on what would have worked on a similar project
Quality leader in specialty area
Competitively priced
Major problems with order processing
Delivery delays and mistakes
Poor synchronization of order entry, confirmation, fulfillment
Disorganized responses to problem situations
Excess costs; low distributor satisfaction
03/27/07
©USC-CSE

20. Frequent Protagonist Classes
Sierra Moutainbikes: Susan Swanson, new CEO
Bicycle champion, MBA, 15 years’ experience
Leads with goals, open agenda
03/27/07
©USC-CSE

21. Order Processing Project Goals
Goals: Improve profits, market share, customer satisfaction via improved order processing
Questions: Current state? Root causes of problems? Keys to improvement?
Metrics: Balanced Scorecard of benefits realized, proxies
Customer satisfaction ratings; key elements (ITV: in-transit visibility)
Overhead cost reduction
Actual vs. expected benefit and cost flows, ROI
03/27/07
©USC-CSE

22. Initial VBSE Theory: 4+1 Process, Steps 1 and 2 – With a great deal of concurrency and backtracking
03/27/07
©USC-CSE

23. DMR/BRA* Results Chain
Order to delivery time is
an important buying criterion
ASSUMPTION
INITIATIVE
OUTCOME
Contribution
Contribution
OUTCOME
Reduced order processing cycle
(intermediate outcome)
Implement a new order
entry system
Reduce time to process order
Increased sales
Reduce time to deliver product
*DMR Consulting Group’s Benefits Realization Approach
03/27/07
©USC-CSE

24. Expanded Order Processing System Benefits Chain
03/27/07
©USC-CSE

25. Initial VBSE Theory: 4+1 Process, Steps 3 and 4 – With a great deal of concurrency and backtracking
03/27/07
©USC-CSE

26. The Model-Clash Spider Web: Master Net
- Stakeholder value propositions (win conditions)
03/27/07
©USC-CSE

27. Project Strategy and Partnerships
Partner with eServices, Inc. for order processing and fulfillment system
Profit sharing using jointly-developed business case
Partner with key distributors to provide user feedback
Evaluate prototypes, beta-test early versions, provide satisfaction ratings
Incremental development using MBASE/RUP anchor points
Life Cycle Objectives; Architecture (LCO; LCA)
Core Capability Drivethrough (CCD)
Initial; Full Operational Capability (IOC; FOC)
Architect for later supply chain extensions
03/27/07
©USC-CSE

28. Business Case Analysis
Estimate costs and schedules
COCOMO II and/or alternative for software
PRICE H or alternative for hardware
COSYSMO for systems engineering
Estimate financial benefits
Increased profits
Reduced operating costs
Compute Return on Investment
ROI = (Benefits – Costs) / Costs
Normalized to present value
Identify quantitative metrics for other goals
Customer satisfaction ratings
Ease of use; In-transit visibility; overall
Late delivery percentage
03/27/07
©USC-CSE

29. Order Processing System Schedules and Budgets
Milestone
Due Date
Budget ($K)
Cumulative Budget ($K)
Inception Readiness
1/1/2004
Life Cycle Objectives
1/31/2004
120
Life Cycle Architecture
3/31/2004
280
400
Core Capability Drivethrough
7/31/2004
650
1050
Initial Oper. Capability: SW
9/30/2004
350
1400
Initial Oper. Capability: HW
2100
3500
Developed IOC
12/31/2004
500
4000
Responsive IOC
3/31/2005
4500
Full Oper. Cap’y CCD
7/31/2005
700
5200
FOC Beta
9/30/2005
5600
FOC Deployed
12/31/2005
6000
Annual Oper. & Maintenance
3800
Annual O&M; Old System
7600
03/27/07
©USC-CSE

30. Order Processing System: Expected Benefits and Business Case
03/27/07
©USC-CSE

31. Initial VBSE Theory: 4+1 Process, Steps 6 and 7 – With a great deal of concurrency and backtracking
03/27/07
©USC-CSE

32. Value-Based Expected/Actual Outcome Tracking Capability
03/27/07
©USC-CSE

33. Outline
Value-based software engineering (VBSE) motivation and definitions
VBSE theory and process framework
Sierra Mountainbikes (SMB-1) case study
VBSE & Incremental Commitment Model (ICM)
Addressing the Cones of Uncertainty
Origins, Principles, and Views
Conclusions and references
04/07/08
©USC-CSE 33 33

34. VBSSE and ICM: Outline Executing the VBSSE
Issues of Scale, Complexity, and Uncertainty
The Cone of Uncertainty - I
Risk-Driven Incremental Definition: ICM Stage I
Buying Information to Reduce Risk
Risk-driven incremental development: ICM Stage II
Achieving both rapid change and high assurance
Multiple views of the ICM
Viewpoints and examples
Evidence of successful use
Implications for system acquisition, career paths

35. Agent-based decision support win condition
Example VBSSE Step 5 Negotiation Uncertainties: Sierra Mountainbikes Case Study
Agent-based decision support win condition
Uncertain multi-agent coordination feasibility
Best-of-breed COTS product interoperability
Architectural mismatch uncertainty
1-second response time feasibility
Uncertain COTS-product scalability
Uncertainties make premature commitment highly risky
Better to reduce option space before negotiating details

36. The Cone of Uncertainty: I
1-Pass VBSSE Needed
Familiar Domain
Proven infrastructure
Well-Jelled team
Multi-Pass VBSSE Needed
New Domain
Immature infrastructure
Non-Jelled team
(c) USC-CSSE 36

37. Using Risk Analysis to Buy COTS Information - Defer Contingent decisions to next phase
Risk Exposure RE = Prob(Loss) *Size(Loss)
Risk Reduction Leverage for each option
RRL= (RE:before – RE:after)/Cost
Basically, expected return on investment
Composite provides good profit for reasonable investment
Option
RE:before
RE:after
Cost
RRL
Reference Check
$500K
$450K 5 10
Analysis Tool
$400K
Full Prototype
$200K 60
Composite
$250K 25

38. Conclusion: Shrinking the Cone of Uncertainty
Total commitment only safe in low-risk situations
If risk is higher, incremental commitment better
Buy information to reduce risk
Need to prioritize information-buying investment
RE, RRL assessments helpful
Composite strategy often most cost-effective

39. There is Another Cone of Uncertainty
(c) USC-CSSE 39

40. ICM Stage II: Increment View

41. ICM Stage II: Increment View

42. The Incremental Commitment Life Cycle Process: Overview
Stage I: Definition
Stage II: Development and Operations
Anchor Point Milestones
The Incremental Commitment Life Cycle Process: Overview
This slide shows how the ICM spans the life cycle process from concept exploration to operations. Each phase culminates with an anchor point milestone review. At each anchor point, there are 4 options, based on the assessed risk of the proposed system. Some options involve go-backs. These options result in many possible process paths.
The life cycle is divided into two stages: Stage I of the ICM (Definition) has 3 decision nodes with 4 options/node, culminating with incremental development in Stage II (Development and Operations). Stage II has an additional 2 decision nodes, again with 4 options/node.
One can use ICM risk patterns to generate frequently-used processes with confidence that they fit the situation. Initial risk patterns can generally be determined in the Exploration phase. One then proceeds with development as a proposed plan with risk-based evidence at the VCR milestone, adjusting in later phases as necessary. For complex systems, a result of the Exploration phase would be the Prototyping and Competition Plan discussed above.
Risks associated with the system drive the life cycle process. Information about the risk(s) (feasibility assessments) supports the decision to proceed, adjust scope or priorities, or cancel the program.
A more detailed description of the activities going on in each phase is provided in chart 78.
Synchronize, stabilize concurrency via FEDs
Risk patterns determine life cycle process
15 July 2008
©USC-CSSE 42 42

43. ICM HSI Levels of Activity for Complex Systems
As mentioned earlier, with the ICM, a number of system aspects are being concurrently engineered at an increasing level of understanding, definition, and development. The most significant of these aspects are shown in this slide, an extension of a similar view of concurrently engineered software projects developed as part of the RUP (shown in a backup slide).
As with the RUP version, it should be emphasized that the magnitude and shape of the levels of effort will be risk-driven and likely to vary from project to project. In particular, they are likely to have mini risk/opportunity-driven peaks and valleys, rather than the smooth curves shown for simplicity in this slide. The main intent of this view is to emphasize the necessary concurrency of the primary success-critical activities shown as rows. Thus, in interpreting the Exploration column, although system scoping is the primary objective of the Exploration phase, doing it well involves a considerable amount of activity in understanding needs, envisioning opportunities, identifying and reconciling stakeholder goals and objectives, architecting solutions, life cycle planning, evaluation of alternatives, and negotiation of stakeholder commitments.
15 July 2008
©USC-CSSE 43 43

44. Anchor Point Feasibility Evidence Description
Evidence provided by developer and validated by independent experts that:
If the system is built to the specified architecture, it will
Satisfy the requirements: capability, interfaces, level of service, and evolution
Support the operational concept
Be buildable within the budgets and schedules in the plan
Generate a viable return on investment
Generate satisfactory outcomes for all of the success-critical stakeholders
All major risks resolved or covered by risk management plans
Serves as basis for stakeholders’ commitment to proceed
Anchor Point Feasibility Evidence Description
To make ICM concurrency work, the anchor point milestone reviews are the mechanism by which the many concurrent activities are synchronized, stabilized, and risk-assessed at the end of each phase. Each of these anchor point milestone reviews is focused on developer-produced evidence, documented in a Feasibility Evidence Description (FED), to help the key stakeholders determine the next level of commitment. At each program milestone/anchor point, feasibility assessments and the associated evidence are reviewed and serve as the basis for the stakeholders’ commitment to proceed.
The FED is not just a document, a set of PowerPoint charts, or Unified Modeling Language (UML) diagrams. It is based on evidence from simulations, models, or experiments with planned technologies and detailed analysis of development approaches and projected productivity rates. The detailed analysis is often based on historical data showing reuse realizations, software size estimation accuracy, and actual developer productivity rates.
It is often not possible to fully resolve all risks at a given point in the development cycle, but known, unresolved risks need to be identified and covered by risk management plans.
Further details on the FED and anchor point milestones are provided in a counterpart presentation on the Workshop Materials web page.
15 July 2008
©USC-CSSE 44 44

45. Example ICM Commercial Application: Symbiq Medical Infusion Pump Winner of 2006 HFES Best New Design Award Described in NRC HSI Report, Chapter 5
Example ICM HCI Application: Symbiq Medical Infusion Pump
The ICM is also a formalization of best commercial practices, as shown in this award-winning and commercially successful example. The next-generation infusion pump is a general-purpose intravenous infusion pump (IV pump) designed primarily for hospital use with secondary, limited-feature use by patients at home. The device is intended to deliver liquid medications, nutrients, blood ,and other solutions at programmed flow rates, volumes, and time intervals via intravenous and other routes to a patient. The marketed name is the Symbiq IV Pump. The device offers medication management features, including medication management safety software through a programmable drug library. The infuser also has sufficient memory to support extensive tracking logs and the ability to communicate and integrate with hospital information systems. The infuser is available as either a single-channel pump or a dual-channel pump. The two configurations can be linked together o form a 3- or 4- channel pump. The infuser includes a large touchscreen color display and can be powered by either A/C power or rechargeable batteries. (adapted from NRC HSI Report, Chapter 5) 45
July 2008
©USC-CSSE 45 45

46. Symbiq IV Pump ICM Process - I
Exploration Phase
Stakeholder needs interviews, field observations
Initial user interface prototypes
Competitive analysis, system scoping
Commitment to proceed
Valuation Phase
Feature analysis and prioritization
Display vendor option prototyping and analysis
Top-level life cycle plan, business case analysis
Safety and business risk assessment
Commitment to proceed while addressing risks
Symbiq IV Pump ICM Process – Exploration and Valuation Phases
This slide summarizes the key activities for the Symbiq IV pump Exploration and Valuation phases. It highlights the need for developing a detailed understanding of the pump capabilities up front by using a combination of field observations and user interface prototypes, then in the valuation phase, prioritizing features and understanding risks going forward.
July 2008
©USC-CSSE 46 46

47. Symbiq IV Pump ICM Process - II
Foundations Phase
Modularity of pumping channels
Safety feature and alarms prototyping and iteration
Programmable therapy types, touchscreen analysis
Failure modes and effects analyses (FMEAs)
Prototype usage in teaching hospital
Commitment to proceed into development
Development Phase
Extensive usability criteria and testing
Iterated FMEAs and safety analyses
Patient-simulator testing; adaptation to concerns
Commitment to production and business plans
Symbiq IV Pump ICM Process – Foundations and Development Phases
This slide summarizes the key activities for the Symbiq IV pump Foundations and Development phases. It highlights the need for continual analyses and feasibility assessments as development proceeds and the decision to go into production is made. At each milestone, risks were assessed and a commitment to go forward was made by the key Abbott Laboratories managers and representatives of their supplier and consumer communities, based on their particular risk/reward ratios.
July 2008
©USC-CSSE 47 47

48. Outline
Value-based software engineering (VBSE) motivation and definitions
VBSE theory and process framework
Sierra Mountainbikes (SMB-1) case study
VBSE & Incremental Commitment Model (ICM)
Addressing the Cones of Uncertainty
Origins, Principles, and Views
Conclusions and references
04/07/08
©USC-CSE 48 48

49. Conclusions VBSE and ICM complement each other
Each primarily concerned with stakeholder value satisficing
VBSE Enterprise Success and Achievement theorems
Fundamental ICM Principle
ICM provides phasing guidance for VBSE
Via Cones of Uncertainty
VBSE provides feasibility priorities for ICM
Via stakeholder value priorities
VBSE and ICM both strongly risk-driven
Shortfalls in feasibility evidence treated as risks
Risk patterns determine common special cases of ICM

50. Common Risk-Driven Special Cases of the ICM
Example
Size, Complexity
Change Rate %
/Month
Criticality
NDI Support
Org, Personnel Capability
Key Stage I Activities : Incremental Definition
Key Stage II Activities: Incremental Development, Operations
Time per Build; per Increment 1
Use NDI
Small Accounting
Complete
Acquire NDI 2
Agile
E-services
Low
1 – 30
Low-Med
Good;
in place
Agile-ready
Med-high
Skip Valuation , Architecting phases
Scrum plus agile methods of choice
<= 1 day;
2-6 weeks 3
Architected Agile
Business data processing
Med
1 – 10
Med-High
most in place
Combine Valuation, Architecting phases. Complete NDI preparation
Architecture-based Scrum of Scrums
2-4 weeks;
2-6 months 4
Formal Methods
Security kernel or safety-critical LSI chip
0.3 – 1
Extra high
None
Strong formal methods experience
Precise formal specification
Formally-based programming language; formal verification
1-5 days;
1-4 weeks 5
HW component with embedded SW
Multi-sensor control device
Med-Very High
In place
Experienced; med-high
Concurrent HW/SW engineering. CDR-level ICM DCR
IOC Development, LRIP, FRP. Concurrent Version N+1 engineering
SW: 1-5 days;
Market-driven 6
Indivisible IOC
Complete vehicle platform
Med – High
High-Very High
Some in place
Determine minimum-IOC likely, conservative cost. Add deferrable SW features as risk reserve
Drop deferrable features to meet conservative cost. Strong award fee for features not dropped
SW: 2-6 weeks;
Platform: 6-18 months 7
NDI- Intensive
Supply Chain Management
0.3 – 3
Med- Very High
NDI-driven architecture
NDI-experienced;
Thorough NDI-suite life cycle cost-benefit analysis, selection, concurrent requirements/ architecture definition
Pro-active NDI evolution influencing, NDI upgrade synchronization
SW: 1-4 weeks;
System: 6-18 months 8
Hybrid agile / plan-driven system
C4ISR
Med – Very High
Mixed parts:
Mixed parts; Med-Very High
Mixed parts
Full ICM; encapsulated agile in high change, low-medium criticality parts (Often HMI, external interfaces)
Full ICM ,three-team incremental development, concurrent V&V, next-increment rebaselining
1-2 months;
9-18 months 9
Multi-owner system of systems
Net-centric military operations
Very High
Many NDIs; some in place
Related experience, med-high
Full ICM; extensive multi-owner team building, negotiation
Full ICM; large ongoing system/software engineering effort
2-4 months; months 10
Family of systems
Medical Device Product Line
1 – 3
Related experience, med – high
Full ICM; Full stakeholder participation in product line scoping. Strong business case
Full ICM. Extra resources for first system, version control, multi-stakeholder support
1-2 months; months
Common Risk-Driven Special Cases of the ICM: Because of its complexity, ICM examples have been developed to show users how to use the framework to create a development process appropriate for their system of interest. These cases cover the very small to the very large as well as the use of commercial off-the-shelf (COTS) software products to the development of a large, complex custom software application or integrated sets of software applications. Each of these situations presents risks at the various stages of development, some risks more critical than others. The goal of the ICM is to identify these risks and then tailor the process to include rigor where necessary to investigate and manage the risks and to streamline the process when risks are negligible, allowing the development team to be more agile when possible. This table contains a list of the special cases of the ICM and an example of each case. Each of the special cases is described in further detail in a companion briefing. In general, a project will be able to identify its special case by the end of the Exploration phase.
Common Risk-Driven Special Cases of the ICM
As mentioned before, as the ICM is used, different risk patterns can be identified, leading to the development of special cases of the ICM to handle these risk patterns. This slide highlights some of the more common risk patterns, describes their characteristics, and explains how the ICM can be most effectively used to develop this type of system.
For each familiar risk pattern, the table identifies the counterpart familiar life cycle process pattern, along with a representative example project type, the project’s key Stage I and Stage II activities, and a rough estimate of the length of its internal builds and deliverable increments. In general, the risk patterns will be well enough established during the ICM Exploration phase to enable the project to determine and switch to the appropriate familiar process without having to go thorough the full generality of the ICM framework.
For example, Row 1 indicates that if a small accounting application can be completely supported by an NDI package, its life cycle process is to acquire and tailor the NDI package. Row 2 corresponds to the agile project described as Example A in chart 22.
The following slides elaborate on two more of these special cases.
C4ISR: Command, Control, Computing, Communications, Intelligence, Surveillance, Reconnaissance. CDR: Critical Design Review.
DCR: Development Commitment Review. FRP: Full-Rate Production. HMI: Human-Machine Interface. HW: Hard ware.
IOC: Initial Operational Capability. LRIP: Low-Rate Initial Production. NDI: Non-Development Item. SW: Software
15 July 2008
©USC-CSSE 50

51. References - I
C. Baldwin & K. Clark, Design Rules: The Power of Modularity, MIT Press, 1999.
S. Biffl, A. Aurum, B. Boehm, H. Erdogmus, and P. Gruenbacher (eds.), Value-Based Software Engineering, Springer, 2005.
B. Boehm, “Value-Based Software Engineering,” ACM Software Engineering Notes, March 2003.
B. Boehm, C. Abts, A.W. Brown, S. Chulani, B. Clark, E. Horowitz, R. Madachy, D. Reifer, and B. Steece, Software Cost Estimation with COCOMO II, Prentice Hall, 2000.
B. Boehm and L. Huang, “Value-Based Software Engineering: A Case Study, Computer, March 2003, pp
B. Boehm & K. Sullivan, “Software Economics: A Roadmap,” The Future of Software Economics, A. Finkelstein (ed.), ACM Press, 2000.
B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed, Addison Wesley, 2003 (to appear).
B. Boehm, L. Huang, A. Jain. R. Madachy, “ The ROI of Software Dependability: The iDAVE Model”, IEEE Software Special Issue on Return on Investment, May/June 2004.
M. Denne and J. Cleland-Huang, Software by Numbers, Prentice Hall, 2004.
03/27/07
©USC-CSE

52. References - II
S. Faulk, D. Harmon, and D. Raffo, “Value-Based Software Engineering (VBSE): A Value-Driven Approach to Product-Line Engineering,” Proceedings, First Intl. Conf. On SW Product Line Engineering, August 2000.
R. Kaplan & D. Norton, The Balanced Scorecard: Translating Strategy into Action, Harvard Business School Press, 1996.
C. Persson, N. Yilmazturk, “Establishment of Automated Regression Testing at ABB: Avoiding the Pitfalls,” Proc., ISESE 2004, IEEE, pp
D. Reifer, Making the Software Business Case, Addison Wesley, 2002.
K. Sullivan, Y. Cai, B. Hallen, and W. Griswold, “The Structure and Value of Modularity in Software Design,” Proceedings, ESEC/FSE, 2001, ACM Press, pp
J. Thorp and DMR, The Information Paradox, McGraw Hill, 1998.
S. Tockey, Return on Software, Addison Wesley, 2004.
Economics-Driven Software Engineering Research (EDSER) web site:
MBASE web site : sunset.usc.edu/research/MBASE
03/27/07
©USC-CSE