第一部分 引言 2
第1章 软件产品线工程介绍 2
1.1 产品线工程的原则 2
1.1.1 大规模定制 2
1.1.2 平台 3
1.1.3 将基于平台的开发和大规模定制相结合 4
1.2 定制产品的工程化 4
1.2.1 创建平台 4
1.2.2 引入灵活性 5
1.2.3 公司的重新组织 5
1.3 产品线工程的动机 6
1.3.1 降低开发成本 6
1.3.2 提高质量 6
1.3.3 缩短上市时间 7
1.3.4 其他动机 7
1.4 软件产品线工程 8
1.4.1 定义 9
1.4.2 软件平台 9
1.4.3 前提条件 10
第2章 软件产品线工程框架 12
2.1 引言 12
2.2 两个开发过程 12
2.3 过程框架概述 13
2.4 领域工程 14
2.4.1 产品管理 15
2.4.2 领域需求工程 16
2.4.3 领域设计 16
2.4.4 领域实现 16
2.4.5 领域测试 17
2.4.6 其他软件质量保证技术 17
2.5 领域工件 17
2.5.1 产品路线图 17
2.5.2 领域变化模型 18
2.5.3 领域需求 18
2.5.4 领域架构 18
2.5.5 领域实现工件 18
2.5.6 领域测试工件 19
2.6 应用工程 19
2.6.1 应用需求工程 20
2.6.2 应用设计 20
2.6.3 应用实现 20
2.6.4 应用测试 21
2.7 应用工件 21
2.7.1 应用变化模型 21
2.7.2 应用需求 22
2.7.3 应用架构 22
2.7.4 应用实现工件 22
2.7.5 应用测试工件 22
2.8 在本书中框架的角色 22
第3章 住宅自动化领域的例子 25
3.1 智能住宅基础设施 25
3.1.1 目标 25
3.1.2 利益相关者 26
3.1.3 智能住宅和传统住宅的区别 26
3.2 住宅自动化系统的构建模块 27
3.2.1 传感器和激励源 27
3.2.2 智能控制设备 27
3.2.3 住宅网关 28
3.2.4 网络 29
3.2.5 住宅自动化领域的标准 29
3.3 例子 29
3.3.1 系统功能 29
3.3.2 一个简单的系统配置 31
3.3.3 系统构件交互 31
3.4 智能住宅应用的软件可变性 32
3.4.1 可变性的例子 32
3.4.2 可变性的原因 33
3.5 本书中住宅自动化领域的角色 33
第二部分 产品线可变性 36
第4章 可变性原则 36
4.1 引言 36
4.2 变化主题和变化对象 37
4.3 软件产品线工程中的可变性 38
4.3.1 变化点 38
4.3.2 变量 39
4.3.3 定义变化点和变量 39
4.3.4 软件产品线的可变性 40
4.4 时间可变性和空间可变性的对比 41
4.5 内部可变性和外部可变性 42
4.5.1 存在外部可变性的原因 43
4.5.2 存在内部可变性的原因 44
4.5.3 内部可变性和外部可变性的判定 44
4.5.4 可变性金字塔 44
4.6 正交变化模型 45
4.6.1 可变性的清晰描述 45
4.6.2 正交可变性定义 46
4.6.3 变化点、变量和可变性依赖 47
4.6.4 可替代选择 48
4.6.5 可变性约束 49
4.6.6 变化模型和其他开发工件之间的追踪关系 52
4.6.7 图形标记 53
4.6.8 例子 53
4.6.9 术语的使用 54
4.7 处理变化模型中的复杂性 55
4.8 与单一系统工程的差别 56
4.9 总结 56
第5章 需求工件的可变性描述 57
5.1 引言 57
5.2 描述需求 58
5.2.1 基于模型的和文本格式的需求描述 58
5.2.2 需求工件 58
5.2.3 目标和特征 59
5.2.4 用例和场景 59
5.2.5 传统的需求模型 60
5.3 文本格式的需求中的可变性 61
5.3.1 在文本格式的需求中定义可变性 61
5.3.2 用XML描述可变性 62
5.4 需求模型中的可变性 63
5.4.1 特征模型中的可变性 63
5.4.2 用例模型中的可变性 66
5.4.3 传统需求模型中的可变性 68
5.5 变化模型和需求工件之间的追踪 71
5.6 与单一系统工程的区别 72
5.7 总结 73
第6章 设计工件的可变性描述 75
6.1 引言 75
6.2 架构工件 76
6.3 参考架构 80
6.4 开发视图中的可变性 80
6.4.1 子系统和层 80
6.4.2 构件 82
6.4.3 接口的作用 83
6.4.4 配置 83
6.5 处理视图中的可变性 84
6.6 代码视图中的可变性 86
6.7 与单一系统工程的差别 87
6.8 总结 87
第7章 实现工件可变性描述 88
7.1 引言 88
7.2 详细设计工件 89
7.3 构件接口可变性 90
7.3.1 算法和协议的可变性 91
7.3.2 资源的可变性 92
7.3.3 应用配置的可变性 92
7.3.4 多个构件提供接口 93
7.4 内在的构件可变性 94
7.5 与单一系统工程的区别 96
7.6 总结 96
第8章 测试工件的可变性描述 97
8.1 引言 97
8.2 测试工件 98
8.3 测试工件中的可变性 99
8.3.1 测试计划 99
8.3.2 测试用例 100
8.3.3 测试用例场景 100
8.3.4 测试用例场景步骤 100
8.3.5 测试总结报告 102
8.4 与单一系统工程的区别 102
8.5 总结 102
第三部分 领域工程 104
第9章 产品管理 104
9.1 引言 104
9.1.1 与领域需求工程的内在联系 104
9.1.2 与应用需求的内在联系 106
9.2 术语 106
9.3 传统的产品管理活动 107
9.4 产品目录管理 107
9.4.1 IT业务类型 108
9.4.2 产品生命周期 108
9.4.3 产品目录分析 109
9.4.4 产品内在依赖 110
9.4.5 产品变体 111
9.5 产品目录的扩展 112
9.5.1 产品改进 113
9.5.2 产品模仿 114
9.5.3 产品创意评估 114
9.5.4 用Kano方案进行产品定义 115
9.5.5 质量功能开发（QFD） 118
9.5.6 目标成本 118
9.6 现有产品管理 118
9.6.1 现有产品的保存和扩展潜力 118
9.6.2 移除产品 119
9.7 产品线的范围界定 119
9.8 与单一系统工程的差别 120
9.8.1 平台的战略角色 120
9.8.2 产品定义 121
9.8.3 输出 121
9.9 总结 121
第10章 领域需求工程 123
10.1 引言 123
10.1.1 与产品管理的关系 123
10.1.2 与领域设计的关系 123
10.1.3 与应用需求工程的关系 125
10.2 传统的需求工程活动 125
10.3 领域需求工程的挑战 126
10.3.1 具体的活动 126
10.3.2 不同视图中的可变性 127
10.4 主要步骤一览 127
10.4.1 定义通用需求 127
10.4.2 定义可变需求 127
10.5 需求来源 128
10.6 通用性分析 128
10.6.1 应用—需求矩阵 129
10.6.2 基于优先级的分析 129
10.6.3 基于清单的分析 130
10.7 可变性分析 130
10.7.1 用应用需求矩阵进行可变性分析 130
10.7.2 基于优先级的可变性分析 130
10.7.3 基于清单的可变性分析 131
10.8 定义需求可变性 131
10.8.1 变化点和变量 132
10.8.2 可变性依赖 132
10.8.3 约束依赖 132
10.8.4 根据产品管理决策调整产品线可变性 133
10.9 例子 133
10.9.1 通用性分析 134
10.9.2 可变性分析 136
10.9.3 定义变化点和变量 136
10.9.4 定义可变性依赖 137
10.9.5 定义约束依赖 137
10.9.6 描述领域需求 138
10.10 与单一系统工程的区别 138
10.11 总结 139
第11章 领域设计 140
11.1 引言 140
11.1.1 与领域需求工程的关系 141
11.1.2 与领域实现的内在关联 141
11.1.3 与应用设计的关联 141
11.2 传统设计活动 142
11.3 质量需求 142
11.4 设计中的通用性和可变性 145
11.4.1 需求优先级 145
11.4.2 需求和设计之间的映射 146
11.4.3 在设计中添加可变性 147
11.5 设计参考架构 149
11.5.1 使用构件框架 149
11.5.2 使用特定应用的插件 150
11.5.3 使用方面 151
11.5.4 架构设计规则的作用 152
11.6 架构验证 152
11.7 与单一系统工程的区别 153
11.8 总结 154
第12章 领域实现 155
12.1 引言 155
12.1.1 与领域设计的关系 155
12.1.2 与领域测试的关系 155
12.1.3 与应用实现的关系 157
12.2 传统的实现活动 157
12.3 实现接口 157
12.3.1 可变和不变接口 158
12.3.2 接口元素 158
12.4 实现可变构件 160
12.4.1 构件的质量 160
12.4.2 将可变性分配到构件中 160
12.5 可变性的绑定时间 161
12.5.1 编译之前 162
12.5.2 编译时 162
12.5.3 链接时 162
12.5.4 加载时 162
12.5.5 运行时 163
12.6 实现可配置性 163
12.7 与单一系统工程的区别 164
12.8 总结 164
第13章 领域测试 165
13.1 引言 165
13.1.1 与领域需求工程的关系 166
13.1.2 与领域设计的关系 167
13.1.3 与领域实现的关系 167
13.1.4 与应用测试的关系 168
13.2 软件测试 168
13.2.1 缺陷 168
13.2.2 测试级别 169
13.3 领域测试和应用测试 170
13.4 在不同测试级别测试可变性 171
13.4.1 领域单元测试 172
13.4.2 领域集成测试 172
13.4.3 领域系统测试 172
13.5 产品线测试策略的准则 173
13.5.1 创建测试工件的时间 173
13.5.2 缺失变量 173
13.5.3 早期验证 173
13.5.4 学习成本 174
13.5.5 开销 174
13.6 产品线测试策略 174
13.6.1 完全的领域测试策略 174
13.6.2 纯应用策略 175
13.6.3 抽样应用策略 177
13.6.4 通用和重用策略 178
13.6.5 策略选择总结 180
13.7 领域测试活动 181
13.7.1 领域测试计划 181
13.7.2 领域测试说明 181
13.7.3 领域测试执行、记录和完成 182
13.8 与单一系统工程的区别 182
13.9 总结 182
第14章 高层COTS构件选择 184
14.1 引言 184
14.1.1 与领域需求之间的内在关联 184
14.1.2 与领域设计之间的内在关联 185
14.2 CoVAR（与可变性、架构关注点和需求相关的构件选择）过程 186
14.2.1 构件筛选 187
14.2.2 构件详细评估 190
14.2.3 构件选择 194
14.3 与单一系统工程的差别 194
14.4 总结 194
第四部分 应用工程 196
第15章 应用需求工程 196
15.1 引言 196
15.1.1 与产品管理的关系 197
15.1.2 与领域需求工程的关系 197
15.1.3 与应用设计的关系 198
15.2 应用需求工程活动 199
15.3 产品线可变性的传递 200
15.3.1 变化点和变量 201
15.3.2 领域需求工件 201
15.3.3 传递活动的结果 202
15.4 需求差异分析 202
15.4.1 变化模型差异 203
15.4.2 对变化模型的影响 203
15.4.3 对需求工件的影响 205
15.4.4 对架构的影响 206
15.5 应用需求文档 208
15.6 与单一系统工程的区别 209
15.7 总结 209
第16章 应用设计 211
16.1 引言 211
16.1.1 与应用需求工程的关系 211
16.1.2 与领域设计的关系 211
16.1.3 与应用实现的关系 212
16.2 开发应用架构 213
16.2.1 特定应用的建模 213
16.2.2 绑定变量 214
16.2.3 确定配置 215
16.2.4 构件变量的一致性选择 216
16.3 应用工件向领域的反馈 217
16.4 变量的成本和工作量 217
16.5 与单一系统工程的差别 218
16.6 总结 218
第17章 应用实现 219
17.1 引言 219
17.1.1 与应用设计的关系 219
17.1.2 与应用测试的关系 219
17.1.3 与领域实现的关系 219
17.2 配置 221
17.3 特定应用构件的实现 222
17.4 创建应用 223
17.5 与单一系统工程的区别 224
17.6 总结 225
第18章 应用测试 226
18.1 引言 226
18.1.1 与应用需求工程的关系 227
18.1.2 与应用设计的关系 227
18.1.3 与应用实现的关系 228
18.1.4 与领域测试的关系 228
18.2 领域测试工件重用 228
18.2.1 处理可变性 229
18.2.2 使用追踪链接 229
18.3 与可变性相关的测试 230
18.4 不同测试级别的可变性测试 231
18.4.1 应用单元测试 232
18.4.2 应用集成测试 232
18.4.3 应用系统测试 232
18.5 应用测试覆盖 233
18.5.1 应用通用性测试 233
18.5.2 应用变量测试 233
18.5.3 特定应用的测试 233
18.6 应用测试活动 234
18.6.1 应用测试计划 234
18.6.2 应用测试说明 234
18.6.3 执行应用测试 235
18.7 与单一系统工程的区别 235
18.8 总结 235
第五部分 组织方面 238
第19章 组织 238
19.1 引言 238
19.2 组织结构的特性 238
19.3 基本的层状组织结构 240
19.3.1 开发部门 240
19.3.2 分布式领域工程 241
19.3.3 集中式领域工程 242
19.3.4 多个领域工程部门 243
19.4 矩阵组织结构 243
19.4.1 领域工程作为功能单元的矩阵组织结构 243
19.4.2 领域工程作为工程单元的矩阵组织结构 245
19.4.3 具有独立的领域工程部门的矩阵组织结构 245
19.5 详细结构 246
19.6 具有交叉职能的团队结构 246
19.7 组织结构理论 247
19.8 与单一系统工程的区别 248
19.9 总结 248
第20章 转变过程 249
20.1 引言 249
20.2 动机和业务目标 249
20.3 转变策略 250
20.3.1 增量式策略 250
20.3.2 战术策略 251
20.3.3 试点项目策略 251
20.3.4 彻底转变策略 251
20.4 各种转变策略的优点和缺点 252
20.4.1 增量式策略的优点 252
20.4.2 增量式策略的缺点 252
20.4.3 战术策略的优点 252
20.4.4 战术策略的缺点 252
20.4.5 试点项目策略优点 252
20.4.6 试点项目策略缺点 253
20.4.7 彻底转变策略的优点 253
20.4.8 彻底转变策略的缺点 253
20.5 成本模型 253
20.6 将成本模型应用到转变策略中 255
20.6.1 增量式转变策略的成本和ROI 255
20.6.2 试点项目转变策略的成本和ROI 256
20.6.3 彻底转变策略的成本和.ROI 257
20.7 转变过程的主要步骤 257
20.7.1 明确利益相关者 257
20.7.2 确定利益相关者的目标 258
20.7.3 创建业务案例 258
20.7.4 制定实施计划 259
20.7.5 开始转变并制定软件产品工程的制度 259
20.8 总结 260
第六部分 经验和下一步的研究 262
第21章 软件产品线工程经验 262
21.1 ABB 262
21.2 波音公司 263
21.3 CelsiusTech Systems AB 264
21.4 Cummins Inc 264
21.5 HP公司 265
21.6 LG公司 266
21.7 朗讯科技公司 267
21.8 MARKET MAKER Software AG 268
21.9 Philips 269
21.9.1 飞利浦消费电子公司 269
21.9.2 飞利浦医疗系统公司 269
21.10 Robert Bosch GmbH 271
21.11 Salion Inc 272
21.12 Siemens AG Medical Solutions HS IM 272
21.13 Testo AG 273
21.14 The National Reconnaissance Office 274
21.15 水下作战中心（The Naval Undersea Warfare Center） 275
第22章 下一步的研究工作 276
22.1 领域具体化 276
22.2 质量保证 276
22.3 模型驱动开发 276
22.4 进化 276
22.5 多条产品线 277
22.6 工具支持 277
22.7 过程改进和评估 277
22.8 经济因素 277
作者简介 278
参考文献 280
术语表 291