《软件产品线工程》从一个软件产品线工程框架出发，阐述了与特定领域软件产品开发有关的领域工程和应用工程过程。介绍了过程申产生的各种工件、产品线可变性及其管理，以及两个工程过程之间通过不变与可变性所建立的联系。书申还包括与软件产品线有关的组织、管理及如何向软件产品线转变等內容。书中强调了软件产品线工程的基本原理、实践特点以及与单一系统开发的区别。尤其难得的是，为方便读者理解，书中在各章中使用了同一个产品来讲述具体的实例。
《软件产品线工程》的作者为业內资深专家。全书结构严谨、条理清晰、图文并茂，是介绍软件产品线的优秀著作。《软件产品线工程》的读者为软件开发人员、测试人员、软件产品线研究者与大专院校师生。
1.软件产品线工程
你对以低成本、快速生产出高质量的软件产品或软件密集型的系统感兴趣吗？如果是，那你手里拿的正是这样的一本书。
软件产品线工程已经被证明是以低成本，短时间，生产高质量、多样性的软件产品或软件密集型系统的一种方法。大量的报告显示了软件业在引入软件产品线后所取得的巨大的成就和宝贵经验。本书第21章总结了某些案例。
关于术语，“软件产品家族”和“软件产品线”的意义相同。然而在欧洲，前者使用得更多；在北美，后者用得较多。关于这一点，在两个会议的名称上也得到反映：其一是2000年始于美国的软件产品线年会，另一个是1996年始于欧洲的软件产品家族系列年会（PFE）；后来，于2004年合并为著名的软件产品线（SPLC）年会。
在本书中，我们使用软件产品线这一术语。
2.本书的读者
本书是为对软件产品线工程原则感兴趣的人准备的，它详细阐述了软件产品线工程的基础，提供了基于经验的关于两个主要过程（领域工程、应用工程）的知识，定义了可变性与可变性的管理。
Klaus Pohl教授是杜依斯堡一埃森大学的全职教授，领导着一个软件系统工程研究团队。他从德国亚琛工业大学获得博士学位。他参与了各种各样的技术转让项目和一些关注软件产品线工程各个方面的重要项目。
博士是西门子公司的一位项目经理。他在1976年从斯图加特大 学获得数学博士学位。从1999年开始，他领导了多个软件产品线项目。在此之前，他的 工作经历包括仿真、建模、系统评估、处理器架构与设计、并行、软件工程和系统工程。
Frank van der Linden博士从1999年开始在飞利浦医疗系统公司工作。
Gunter Bockle博士是西门子公司的一位项目经理。他在1976年从斯图加特大学获得数学博士学位。从1999年开始，他领导了多个软件产品线项目。在此之前，他的工作经历包括仿真、建模、系统评估、处理器架构与设计、并行、软件工程和系统工程。
第一部分 引言
第1章 软件产品线工程介绍
1.1 产品线工程的原则
1.1.1 大规模定制
1.1.2 平台
1.1.3 将基于平台的开发和大规模定制相结合
1.2 定制产品的工程化
1.2.1 创建平台
1.2.2 引入灵活性
1.2.3 公司的重新组织
1.3 产品线工程的动机
1.3.1 降低开发成本
1.3.2 提高质量
1.3.3 缩短上市时间
1.3.4 其他动机
1.4 软件产品线工程
1.4.1 定义
1.4.2 软件平台
1.4.3 前提条件
第2章 软件产品线工程框架
2.1 引言
2.2 两个开发过程
2.3 过程框架概述
2.4 领域工程
2.4.1 产品管理
2.4.2 领域需求工程
2.4.3 领域设计
2.4.4 领域实现
2.4.5 领域测试
2.4.6 其他软件质量保证技术
2.5 领域工件
2.5.1 产品路线图
2.5.2 领域变化模型
2.5.3 领域需求
2.5.4 领域架构
2.5.5 领域实现工件
2.5.6 领域测试工件
2.6 应用工程
2.6.1 应用需求工程
2.6.2 宜用设计
2.6 ‘3宜用实现
2.6.4 应用测试
2.7 应用工件
2.7.1 应用变化模型
2.7.2 应用需求
2.7.3 应用架构
2.7.4 应用实现工件
2.7.5 应用测试工件
2.8 在本书中框架的角色
第3章 住宅自动化领域的例子
3.1 智能住宅基础设施
3.1.1 目标
3.1.2 利益相关者
3.1.3 智能住宅和传统住宅的区别
3.2 住宅自动化系统的构建模块
3.2.1 传感器和激励源
3.2.2 智能控制设备
3.2.3 住宅网关
3.2.4 网络
3.2.5 住宅自动化领域的标准
3.3 例子
3.3.1 系统功能
3.3.2 一个简单的系统配置
3.3.3 系统构件交互
3.4 智能住宅应用的软件可变性
3.4.1.变性的例子
3.4.2 可变性的原因
3.5 本书中住宅自动化领域的角色
第二部分 产品线可变性
第4章 可变性原则
4.1 引言
4.2 变化主题和变化对象
4.3 软件产品线工程中的可变性
4.3.1 变化点
4.3.2 变量
4.3.3 定义变化点和变量
4.3.4 软件产品线的可变性
4.4 时间可变性和空间可变性的对比
4.5 内部可变性和外部可变性
4.5.1 存在外部可变性的原因
4.5.2 存在内部可变性的原因
4.5.3 内部可变性和外部可变性的判定
4.5.4 可变性金字塔
4.6 正交变化模型
4.6.1 可变性的清晰描述
4.6.2 正交可变性定义
4.6.3 变化点、变量和可变性依赖
4.6.4 可替代选择
4.6.5 可变性约束
4.6.6 变化模型和其他开发工件之间的追踪关系
4.6.7 图形标记
4.6.8 例子
4.6.9 术语的使用
4.7 处理变化模型中的复杂性
4.8 与单一系统工程的差别
4.9 总结
第5章 需求工件的可变性描述
5.1 引言
5.2 描述需求
5.2.1 基于模型的和文本格式的需求描述
5.2.2 需求工件
5.2.3 目标和特征
5.2.4 用例和场景
5.2.5 传统的需求模型、
5.3 文本格式的需求中的可变性
5.3.1 在文本格式的需求中定义可变性
5.3.2 用XML描述可变性
5.4 需求模型中的可变性
5.4.1 特征模型中的可变性
5.4.2 用例模型中的可变性
5.4.3 传统需求模型中的可变性
5.5 变化模型和需求工件之间的追踪
5.6 与单一系统工程的区别
5.7 总结
第6章 设计工件的可变性描述
6.1 引言
6.2 架构工件
6.3 参考架构
6.4 开发视图中的可变性
6.4.1 子系统和层
6.4.2 构件
6.4.3 接口的作用
6.4.4 配置
6.5 处理视图中的可变性
6.6 代码视图中的可变性
6.7 与单一系统工程的差别
6.8 总结
第7章 实现工件可变性描述
7.1 引言
7.2 详细设计工件
7.3 构件接口可变性
7.3.1 算法和协议的可变性
7.3.2 资源的可变性
7.3.3 应用配置的可变性
7.3.4 多个构件提供接口
7.4 内在的构件可变性，
7.5 与单一系统工程的区別
……
第8章 测试工作的可变性描述
第三部分 领域工程
第9章 产品管理
第10章 领域需求工程
第11章 领域设计
第12章 领域实现
第13章 领域测试
第14章 高层COTS构件选择
第四部分 应用工程
第15章 应用需求工程
第16章 应用设计
第17章 应用实现
第18章 应用测试
……
产品管理的目标是将产品的开发、生产和销售相结合，生产满足客户需求的产品，进而为企业的成功做出重要贡献。产品管理在软件工程全过程中贯彻企业的目标。因此，它对需求工程、设计、实现和测试都会产生影响。与产品管理紧密相关的子过程和工件如图9-1所示中高亮部分所示。
对于软件产品线工程框架来说，产品管理过程产生的主要结果是产品路线图。请注意，在前面出现的框架图中并未标出路线图，这是因为产品管理没有与之对应的常规意义上的开发工件（2.5.1节）。产品路线图是在给定的时间点上，对产品线的未来情况做出尽可能长远的预计。它定义了产品线中所有产品线应用的主要通用和可变特征，以及向客户提供某特定类型应用的进度表和上市时间。产品路线图里定义的特征直接影响着领域需求工程和应用需求工程。
领域需求工程和应用需求工程必须与产品路线图中描述的特征相一致。领域需求工程提供可重用需求工件，应用需求工程为特定应用创建需求工件，而这些应用正是由产品路线图所规划的。下面各节主要描述产品管理和其他相关子过程之间的信息流，如图9-2所示。
书单推荐
