对象软件项目求生法则（影印版）

.ingrid: success in migrating to c++ 14
manfred: failure in prototyping 15
mentor graphics: trouble migrating to c++ 16
object technology international: success in productivity
and speed 17
reginald: failure with changing rules 18
stanley: too much cutting edge 18
tracy: failure through naivete 19
udall: success by restarting smaller 20
winifred: inattentive but persistent 21
possible benefits of object technology 23
responsiveness to variations on a theme 23
responsiveness to change 23
time-to-market 24
communication between developers, users, and executives 24
maintainability 24
reuse 25
productivity 25
window-based user interfaces 26
morale 26
automated code generation 27
software process 27
oo design, encapsulation, and system evolution (tom morgan) 28
costs 28
are you underestimating? 28
time to get new developers productive 28
immaturity of the oo industry 29
hazards of c++ 29
the difficulty of reuse 29
establishing a software process 29
business modeling versus software design 29
the cost of case modeling tools 30
probable costs 30
nonobject issues checklists 31
chapter 3 33
selecting and setting up an oo project
project suitability 34
variations on a theme 34
simplified program structure 35
memory management features 35
what is not suited? 36
project purpose 36
swat 37
investigative 37
production 40
full-commit 47
other project categories 41
people 42
executive sponsor 42
project manager 43
technical lead 44
technical staff 44
users 45
personality types 46
technology 47
the selection process 47
one person is persuasive or stubborn 48
the team knows a similar technology 48
the technology is safe, popular, or standard 49
the technology is the rational choice 50
programming languages 51
managing smalltalk 52
managing c++ 53
disciplined use of c++ (jeremy raw) 58
managing oo cobol 59
managing java 60
tools 61
upper-case tools 61
using java (sam griffith) 62
the scanner challenge 65
minimum case tool requirements 65
the cutting edge 66
training and getting advice 67
what to teach 68
developers do not know how to think in objects. 68
developers do not know how to make design trade-offs. 69
developers program poorly or use tools badly. 69
different programmers write differently, making the code hard to learn. 69
developers create redundant classes because they do not know what
is in the class library. 70
no one knows how to document a framework well. 70
developers do not understand their role on the project and who depends on them. 71
when to teach 71
getting advice 72
legacy issues 72
mainframes 72
relational databases 73
project setup(c.d.) 74
review 75
chapter 4 77
getting started
methodology 77
big-m methodology 78
a base methodology to tailor 81
discussion of the methodology 82
roles, skills, techniques 84
tools 87
teams 88
ownership 89
deliverables 89
standards 91
activities 92
building consumer understanding of the design(ward cunningham) 94
estimates 95
two weeks per noncommercial class 96
domain classes 96
screen classes 96
utility classes 97
frameworks 97
plans 98
an estimation and planning session(alistair cockburn) 100
milestones 100
measurements 102
take the time to design 104
design, and two smalltalk projects(k.l.)106
making corrections
a study project 109
stage o: the usual ignorance 109
stage 1: disaster 110
stage 2: rebuild 110
stage 3: improve 111
stage 4: functioning 111
stage 5: overconfidence in scaling up 111
lessons from this study project 112
managing precision, accuracy, and scale 112
managing work according to precision
and accuracy 115
increments and iterations 117
increments and v-w staging 118
iterations 123
combining increments and iterations 126
burm some pancakes(luke hohmann) 128
project increments 129
increment 1 129
the architecture team 129
the training team 130
the intentions 130
two stories 131
increment 2 132
pause and learn 132
move on 133
increment n 134
user involvement 134
watching users(k.l.) 136
project teams 136
ownership 137
involve the users(jon marshall) 138
total-ownership teams 138
matrixed teams 138
domain modeling and reuse 140
the domain model 140
hazardous situations 140
the common domain model 141
why are there multiple valid domain models? 143
polybloodyhardreuse 146
conflicting reward systems 148
lack of trust 149
i can write it faster myself 149
further reading 151
chapter 6 153
advice from hindsight
costs and benefits revisited 153
sentences you hope never to hear 154
writing 500 lines of code per day 154
model the world, then code 156
design the screen, then code 157
iterate prototypes 157
classes? 158
reuse is easy 158
more on iterations 159
self-test 160
two increments delivered 160
thirty people 160
analysts, programmers, and tools 161
learning on from the compiler 161
programmers between projects 162
on the cutting edge 162
designers and programmers separated 162
six-month pilot started 163
chapter 7
expand to larger projects
your first big project 165
project charter 166
communication 166
staffing, skill dilution, and project teams 167
methodology 168
increments and iterations 169
the cutting edge 169
domain modeling 169
risk reduction 170
polybloodyharderreuse 170
class duplication 170
training the tidal wave 171
ten lessons the hard way (glenn house) 172
train fewer people 175
train more effectively 175
training 50 or more people 176
set up a full-time classroom program 176
set up 6 to 10 connected projects 176
use a full-time mentor 176
maintain tight standards and review policies 177
rotate people 177
productivity 177
size 177
staff skill mix 179
team structure 180
even mix 180
progress teamfrraining team 180
productivity changes over time 181
lines of code per month 182
frameworks 183
productivity revisited 184
migrating the organization 184
chapter 8 187
rechecking: a case study
winifred revisited 188
summary 188
history 188
stage 1: good start, with experience and support 188
stage 2: no architecture, almost no first delivery 189
stage 3: new increment; add teams, mentors, architecture 190
stage 4: owner per deliverable; new infrastructure 191
analysis 191
relation to book's topics 192
technology is only part of the story 197
organizations(jim coplien) 198
appendix a 201
collected risk-reduction strategies
appendix b 237
crib sheet
index 43