Table Of ContentTHEORY 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
Description:Apurva Jain kindness and compassion that kept me going. Professor . (2a) the application of science and mathematics by which the properties.
