THEORY OF VALUE-BASED SOFTWARE ENGINEERING by

188 Pages·2007·0.88 MB·English

by  Apurva Jain

THEORY OF VALUE‐BASED SOFTWARE ENGINEERING 

by 
Apurva Jain 

A Dissertation Presented to the  
FACULTY OF THE GRADUATE SCHOOL  
UNIVERSITY OF SOUTHERN CALIFORNIA  
In Partial Fulfillment of the  
Requirements for the Degree  
DOCTOR OF PHILOSOPHY 
(COMPUTER SCIENCE) 

December 2007 

Copyright 2007                                                                                                               Apurva Jain
Acknowledgements

How far that little candle throws his beams! Make that three candles, 
follow the beam, and you have a dissertation. I have been most fortunate to have 
such three distinct guides that have carried me through in times of need, and lead 
me towards success. Professors Barry Boehm, Stan Rifkin and Paul Adler, without 
you I would not have been sitting today, writing this final page in concluding a 
degree that only few can dream, and fewer actually achieve. 
Professor Barry Boehm,  the ways and things an individual can learn from 
you is no less than the number of times “risk” has been used in the literature of 
software engineering. Having been your student, I have found a new identity that 
outshines all others, and I pride in it. It goes “Apurva is a Boehm student” period. 
Professor Stan Rifkin, the intersection at which engineering and social 
sciences meet, I thought was a place not known to any until you helped me find it. 
The journey was very rough, but I would not have seen the end if not for your 
kindness and compassion that kept me going. 
Professor Paul Adler, when its about organization theory, there’s Marx and 
Weber, there’s you, and then there’s the rest. If there’s one class that I would like 
to enroll in year and again, it would be 602. From you I have learnt to uncover 
knowledge at its finest granularity. 
ii
My Family, your are my family what more can I say. I had once felt that I 
have been extremely lucky in being with the right people. Now I know it had 
nothing to with luck, it was you all along. You taught me right for wrong. Luck was 
actually in having you as family. 
Friends, you have brought unparellel happiness and excitement in almost 
all the things I have done in life, including this dissertation. Alex, Jesal, Nikunj, 
Shamik, Steve – I thank you for your friendship and for the various forms in which 
you have supported me. 
Thank you all. 

iii
Table of Contents 

1.  INTRODUCTION  1 
SOFTWARE SYSTEMS – STATE OF AFFAIRS  3 
OVERVIEW OF THE PROBLEM  5 
Context Disconnect  5 
Stakeholder Value Disconnect  8 
A CASE FOR VALUE‐BASED ENGINEERING OF SOFTWARE SYSTEMS  10 
CONCEPTUAL FRAMEWORK  15 
The 4+1 Value‐Based Theories  16 
The Process Framework  18 
SIGNIFICANCE OF RESEARCH  19 
LIMITATIONS  21 
Validation Approach  21 
RESEARCH SCOPE  23 
2.  LITERATURE REVIEW  24 
PART I: THEORIES OF SOFTWARE SYSTEMS  25 
The Code‐and‐Fix Model  26 
The Waterfall Model  28 
The Spiral Model  31 
Rapid Prototyping Models  34 
PART II: CANDIDATE THEORIES FOR VBSE  36 
Dependency Theory  40 
Utility, Decision, and Dependencies  50 
Control Theory  57 
3.  TO THEORY  60 
DEFINITIONS AND CONTEXT  60 
Success  60 
Theory  62 
CHOICE RATIONALE  63 
Historical Context  64 
Theory W  65 
A VALUE‐BASED THEORY FOR DEVELOPING SOFTWARE SYSTEMS  70 
Dependency theory  71 
Utility Theory  81 
Decision Theory  82 
Control Theory  82 
4.  TO PRACTICE  84 
STEP 1  84 
STEP 2  85 
STEP 3  86 
STEPS 4, 5 AND 6  86 
5.  RESULTS  89 
CASE 1: UNIWORD  93 
Background  93 
iv
Analysis Summary  94 
CASE 2: BOFA MASTERNET  95 
Background  95 
Analysis Summary  96 
CASE 3: MS WORD FOR WINDOWS  97 
Background  97 
Analysis Summary  98 
CASE 4: LONDON AMBULANCE SERVICE  99 
Background  99 
Analysis Summary  100 
CASE 5: CMU SURFACE ASSESSMENT ROBOT  101 
Background  101 
Analysis Summary  102 
INSIGHTS  102 
Preferences, risk and maturity  102 
CASE 6: SMB WITH VBSE  103 
Sierra Mountainbikes Opportunities and Problems  104 
Step 2: Identifying the Success‐Critical Stakeholders (SCSs)  105 
Step 3: Understanding SCS Value Propositions  107 
Step 4: Managing Expectations; SCSs Negotiate a WinWin Decision  108 
Steps 5 and 6: Planning, Executing, Monitoring, Adapting, and Controlling  112 
6.  CONCLUSIONS AND RECOMMENDATIONS  119 
REVIEW OF PROBLEM  119 
REVIEW OF PURPOSE  120 
REVIEW OF RESULTS  120 
Relations to Criteria for a Good Theory  122 
IMPLICATIONS  127 
FUTURE WORK  128 
Challenges  128 
A Case for Future Work  129 
Low Hanging Opportunities  130 
REFERENCES  134 
APPENDIX A: ANALYSIS OF UNIWORD  151 
BACKGROUND  151 
VBSE THEORY ANALYSIS  152 
Did the project prioritize requirements?  152 
APPENDIX B: ANALYSIS OF MASTERNET  159 
BACKGROUND  159 
VBSE THEORY ANALYSIS  160 
APPENDIX C: ANALYSIS OF WINDOWS FOR WORD  168 
BACKGROUND  168 
VBSE THEORY ANALYSIS  168 
APPENDIX D: LONDON AMBULANCE SERVICE  174 
BACKGROUND  174 
VBSE THEORY ANALYSIS  175 
v
List of Tables 

Table 1. Top Software System Risks  4 
Table 2. Win‐lose Generally Becomes Lose‐Lose  66 
Table 3. Frequent Protagonist Classes  85 
Table 4. Analysis Framework  89 
Table 5. Summary of Results  92 
Table 6. Expected Benefits and Business Case  111 
Table 7. Value‐Based Expected/Actual Outcome Tracking  113 

vi
List of Figures 
Figure 1. Benefits Chain as a Software System's Context  7 
Figure 2. Value‐Based vs. Value‐Neutral  11 
Figure 3. Effect of Software Reliability and Market Share Erosion on Risk  13 
Figure 4. Organization Context  14 
Figure 5. The 4+1 Theory – Key Constructs  17 
Figure 6. The Process Framework  18 
Figure 7. The Code‐and‐Fix Model  27 
Figure 8. The Waterfall Model  29 
Figure 9. The Spiral Model  33 
Figure 10. The Rapid Prototyping Model  34 
Figure 11. Stakeholer Utility Functions  51 
Figure 12. Maslow's Hierarchy of Needs  52 
Figure 13. A Feedback Control System  59 
Figure 14. The 4+1 Theory ‐‐ Key Constructs  70 
Figure 15. A Combined Dependency Model  74 
Figure 16. Stakeholder Value Conflicts  77 
Figure 17. The Process Framework  84 
Figure 18. Benefits Chain for Sierra Supply Chain Management  106 

vii
1. Introduction 
What is the primary thesis of this research? 
The activity of developing software systems is not an end, but a means to 
an end for the people who directly or indirectly depend on them. Taking such a 
view thus implies that software systems must be engineered such that they help 
people meet their ends. The primary focus of this study is to show how decisions 
about software systems can be made such that they are better aligned to realize 
the values (ends) of its stakeholders (people). 

Note that this is consistent with Webster’s definition of “engineering:”
(1)   the activities or function of an engineer 
(2a)  the application of science and mathematics by which the properties 
of matter and the sources of energy in nature are made useful to 
people 
(2b)  the design and manufacture of complex products <software 
engineering> 
The main definition (2a) puts making things useful to people (i.e., satisfying 
their value propositions at the center of what an engineering discipline should do. 
  Research on software systems has been roughly split into two aspects – 
process and product. Product research is mainly focused on the “what is 
produced” – generally technology focused, and addresses problems mostly within 
1
the ambit of computer science. These may include inventing technologies to 
improve a software system’s quality attributes, such as performance and security, 
or identifying better approaches to implementing existing or new technologies. 
For example, Web Services was invented in response to the growing 
interoperability needs among software systems. 
  Process research instead addresses “how the product is being produced” – 
in particular, the managerial and administrative aspects of developing software 
systems.  The focus is on the practices that guide the development of a software 
system from its conceptualization through its evolution to a possibly much larger 
system such as the kind that serves an enterprise. Examples of research within the 
process area may include methods for decision making, life cycle choice, cost and 
schedule estimation, design and analysis, and risk management. 
This study integrates product and process research.  It goes beyond both in 
addressing why the product is being produced, and how well it needs to perform.  
It makes an inquiry into the current practices related to decision making in 
thinking about and constructing or acquiring software systems. With a few 
exceptions, it shows how most current practices fall short in addressing the full set 
of stakeholder values (disconnected from stakeholder values), and how current 
practices use an insufficient unit of analysis that does not include the context in 
which the software has to transition (disconnected from context). Some of these 
2
practices are discussed next to show how value‐based and context‐connected 
approaches are better. Others will be described in Chapter 2 – Literature review. 
In addressing these issues, this study describes a proof of concept theory 
for developing software systems that uses stakeholder values as its unit of 
analysis. A significant contribution of this study is the explanation of the 
theoretical constructs used in creating a new theory, and a process framework 
that helped in making an initial assessment of its sufficiency and fitness with 
respect to a set of criteria.  
Since this research deals with imprecise and situation‐varying human 
values, a combination of analytic and qualitative approaches was chosen for 
assessment of its findings. Future work to strengthen this research should include 
quantitative assessments and further extensions for each of the key theoretical 
constructs. 
Software Systems – State of Affairs

What is the motivation for this study? 
The low rate of successful software systems (Standish Group, 2004); its outcomes 
such as loss of life (Finkelstein and Dowell, 1996; Leveson and Turner, 1993); loss 
of revenue (NIST, 2002; Flowers, 1996; Babcock, 1985; Carr 2002) corporate 
embarrassment (LA Times, 1987; WS Journal, 1989) has been both – a reflection of 
the field’s lack of understanding of how best to develop software systems, and an 
inspiration for this research to uncover better ways. 
3