目录
1. 思想来源：产品线
1.1 硬件产品线
1.2. 产品组合
2. 软件产品线
2.1 思想来源：
2.2 为什么使用软件产品线？
2.3 软件产品线是一种软件架构
2.4 软件产品线详解
2.5 软件产品线的双生命周期的模型
2.6 软件产品线建立方式
2.7 软件产品线的组织结构
第3章 软件产品线不是什么
1. 思想来源：产品线
1.1 硬件产品线
产品线(Product Line) 是指一群相关的产品，这类产品可能功能相似，销售给同一顾客群，经过相同的销售途径，或者在同一价格范围内。 如果能够确定产品线的最佳长度，就能为企业带来最大的利润。
1.2. 产品组合
产品组合，通常由若干条产品线组成。
产品线，是指同类产品的系列。一条产品线就是一个产品类别，是由使用功能相同、能满足同类需求而规格、型号、花色等不同的若干个产品项目组成的。一个产品项目，则是指企业产品目录上开列的每一个产品。
产品组合的宽度，是指产品组合中包含的产品线的多少，包含的产品线越多，就越宽；
产品组合的深度，是指每条产品线包含的产品项目的多少，包含的产品项目越多，产品线就越深；产品组合的关联度，是指各类产品线之间在最终用途、生产条件、销售渠道等方面相互关联的程度，不同的产品组合存在着不同的关联程度。
2. 软件产品线
2.1 思想来源：
硬件产品线
2.2 为什么使用软件产品线？
一个公司的业务集聚在某个邻域，通常有经验的积累。那么就希望得到一个通用的方法论。
不需要每次开发类似的产品都要重零开始，而是将系统进行产品化，只要小修小改就可以满足新系统的需求。
而软件产品线就是由软件架构、邻域工程、特定领域架构(DSSA)相结合得到的行业解决方案。
软件产品线是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足特定领域的特定需求。
软产品线是一个十分适合专业的开发组织的软件开发方法，能有效地提高软件生产率和质量，缩短开发时间，降低总开发成本。
如何提高生产的经济效益呢：
- 首先每个产品都由来自公共资产库中的稳定的、可靠的、被反复验证过的、可复用的组件组成。
- 然后按照预先定义的变化机制，如参数化或继承，对这些组件进行必要的裁剪，添加任何必须的新组件，根据一个产品线范围内的公共架构来组装这些组件。于是，构建一个产品（系统）主要工作是组装和繁衍，而不是创造；
- 主要的活动是集成而不是编程。每条软件产品线都有一个预先定义的指南或计划，用来定义确切的产品构建方法。
2.3 软件产品线是一种软件架构
2.4 软件产品线详解
软件产品线是指具有一组可管理的公共特性的软件密集性系统的合集，这些系统满足特定的市场需求或任务需求，并且按预定义的方式从一个公共的核心资产集开发得到。
这个定义和任何产品线的传统定义相一致——满足特定市场或任务需求的、具有一组公共的、可管理特性的系统集合。但是它增加了一些内容，即在软件产品线中增加了系统开发方式上的一些限制。为什么，因为软件产品线的系统，需要按照指定方式进行公共资产集的开发，与独立开发、从零开始开发、随机开发等方式相比较，可以获得显著的生产经济效益。正是由此产生的经济效益，才使软件产品线更具吸引力。
软件产品线针对特定领域中的一系列具有公共特性的软件系统，试图通过对领域（commonality）共性和可变性（var iability）的把握构造一系列领域核心资产，从而使特定的软件产品可以在这些核心资产基础上按照预定义的方式快速、高效地构造出来。
软件产品线工程主要包括领域工程、应用系统工程和产品线管理三个方面。其中，领域工程是其中的核心部分，它是领域核心资产（包括领域模型、领域体系结构、领域构件等）的生产阶段；应用系统工程面向特定应用需求，在领域核心资产的基础上面向特定应用需求实现应用系统的定制和开发；而产品线管理则从技术和组织两个方面为软件产品线的建立和长期发展提供管理支持。
如何提高生产的经济效益呢，首先每个产品都由来自公共资产库中的组件组成，然后按照预先定义的变化机制，如参数化或继承，对这些组件进行必要的裁剪，添加任何必须的新组件，根据一个产品线范围内的公共架构来组装这些组件。于是，构建一个产品（系统）主要工作是组装和繁衍，而不是创造；主要的活动是集成而不是编程。每条软件产品线都有一个预先定义的指南或计划，用来定义确切的产品构建方法。
2.5 软件产品线的双生命周期的模型
和DSSA一样。首先现有系统的需求进行分析，哪些需求是整个行业都可能需要涉及的。将此类需求输入邻域工程。得到了邻域工程的模型。在开发新系统时，分析哪些需求时邻域工程中包含的，将已存在的需求、涉及、实现直接从邻域工程获取。对于有差异的，再进行单独的开发。因此，邻域工程做行业间的共性的东西，应用系统负责实现用户的特有需求。
软件产品线工程主要包括领域工程、应用系统工程和产品线管理三个方面。
其中，领域工程是其中的核心部分，它是领域核心资产（包括领域模型、领域体系结构、领域构件等）的生产阶段；
应用系统工程面向特定应用需求，在领域核心资产的基础上面向特定应用需求实现应用系统的定制和开发；
而产品线管理则从技术和组织两个方面为软件产品线的建立和长期发展提供管理支持。
2.6 软件产品线建立方式
软件产品线的建立方式主要用两种：
一个是演化方式，在迭代中不断完善；
另一种是革命式，直接将目标一步到位地实现。
除此之外，可以基于现有产品，在现有产品中进行改进。而全新产品线指的是，不在旧产品中做修改，直接开发新的产品，当然可以参考旧产品的经验教训。
2.7 软件产品线的组织结构
软件产品线的组织结构有三种类型：
设立独立的核心资源小组
不设立独立的核心资源小组
动态的组织结构
大多数公司的组织结构都是设立独立的核心资源小组,比如分为模型组、应用组、架构组等。而想要将一个系统进行产品化，主要取决于以下因素
对邻域具备长期和深厚的经验
一个用于构件产品的好的核心资源库
好的产品架构
能够对软件资源、人员组织，过程文档很好的管理。
第3章 软件产品线不是什么
有很多种方法初看起来和软件产品线似乎很类似。因此，您可能要问：“软件产品线不就是X的一个新名称吗。”尽管我们很想让您能在以前的知识和经验基础之上有新的发展，但是我们更想从一开始就不要令你错误地把软件产品线等同于一些它们所不是的东西。
描述“它不是什么”往往和描述“它们是什么”一样有意义。
在谈及软件产品线时，我们不是指上下文中所提及的任何一种情况。
误区一：偶然的小粒度重用
重用，作为降低开发成本，提高质量的软件策略已经不是新方法，软件产品线肯定涉及到重用，事实上是最高级别的重用。
那么区别何在呢，以前的重用主要是指相对较小的代码块的重用，也就是小粒度重用。有些机构已经建成了包含算法、模式、对象和组件的可重用库。软件开发人员写的任何东西几乎都要放到库里，然后鼓励（有时是要求）其他开发人员使用库里所提供的东西而不是创建自己的版本。不幸的是在很多情况下，查找这些小模块以及将其集成到一个系统中所花费的时间比重新开发他们更长。文档，倘若有的话，可以说明模块创建的情况，却不能说明如何对模块进行集成或进行适应性的修改。小粒度的重用的成功依赖于软件工程师是否喜欢使用库里的内容、库中的内容对工程师需要的适应性，以及能够成功将库中内容进行改写并集成到系统的其他部分。如果这些条件都满足，则采取重用，但它具有偶然性，并非总能发生。
在软件产品线方法中，重用是有计划的、能够实现的和强制的（机会主义的对立面）。
资产库包括从一开始就花费大量成本进行开发的各类产品——即需求、领域建模、软件架构、性能模型、测试用例和组件。所有资产都为重用而设计，并且为了能重用与多个系统进行了优化。软件产品线的重用是全面的、有计划的、有经济效益的。
误区二：利用重用的单系统开发
您正在开发一个新的系统，它与您以前做过的系统很相似。您可以借助于以前的工作，做一些必要的修改、增加一些内容，形成新的产品。那么您所做的就是所谓的“克隆并拥有”。毫无疑问，您充分利用了以前的工作并取得经济效益；您已经重用了另一个系统的一部分，但是您有两个完全不同的系统，而不是从同一库中构建起两个系统。您需要像维护两个完全分离的实体那样维护这两个系统，这又是一个特别的重用。
这种方法和软件产品线方法有两点主要区别。首先，软件产品线重用的资产是明确为重用而设计的。其次，产品线被视为一个整体，而不是可以区别对待和维护的多个产品。在成熟的产品线组织中，多个产品的概念已经消失。每个产品是核心资产的一个简单定制，只有核心资产才被认真的设计并随时间演进，只有核心资产才是组织的杰出智力财产。
大平台，小产品中的大平台，就是软件产品线概念的体现！！！
误区三：仅仅基于组件的开发
软件产品线依赖于基于组件开发的形式，涉及到的要素很多。基于组件开发的典型定义是指从内部库或是市场选择组件来构建产品。尽管软件产品线中的产品确实是由组件组成的，但这些组件都是由产品线架构指定的，且按预定义的方式组装，如在组件中采用内置变体机制，以便将其用于指定的产品。该定义来自于架构和生产计划，而不是标准的基于组件的开发。
在产品线中，组件通常是在资产库中进行演进和维护的。而在基于组件的开发中，若有任何变化，一般都是通过编写代码来完成，其变化部分通常都是分别维护的。单独的基于组件的开发常常缺乏技术和组织管理方面的支持，而这点对软件产品的成功非常重要。
误区四：仅有一个可配置的架构
设计参考架构和面向对象框架是为了能重用于多个系统，并且必须可以重新配置。重用架构的各种结构是个很好的方法，因为架构对任何系统而言都至关重要，而且构建代价较高。产品线架构的设计必须支持产品线中个产品间的不同（变化），因此它必须是可配置的。但是，即便产品线架构很重要，也只是产品线资产库中的一项资产。
误区五：单个产品的发布和版本
组织要定期发布新产品和退出产品的新版本，每个新版本的发布一般都是通过使用以前版本的架构、组件、测试计划和其他要素来构建。
为什么软件产品线有所不同呢，首先，在产品线中同时存在多个产品，每个产品都有其自己的发布和版本周期。因此，必须在更广的上下文环境中考虑单个产品的演进——也就是说，产品线是作为一个整体来演进的。其次，在单个产品的上下文环境中，产品一旦被更新，通常不可逆——即认为早期产品生产中的任何东西都不再有价值。但是在产品线中，产品的早期版本仍被认为具有市场潜力，并很容易地作为产品家族中的一个可生存成员保留下来：毕竟它如同其他产品的其他版本一样，是核心资产的一个实例。
误区六：仅有一套技术标准
许多组织建立一套标准来限制软件工程师选择集成到系统中的组件的种类和来源。他们审查架构和评审设计以确保遵循了这些标准。例如，开发人员能够从两种确定的数据库和两种确定的网页浏览器中进行选择，但是必须使用一种指定的中间件或电子数据表产品（需要时）。技术标准可提高协同能力，降低商业组件的维护和支持费用。一个正在推行产品线的组织可能也拥有这样的技术标准，产品线架构和组件都需要遵循这些标准，但是这些标准仅仅是输入到软件产品线中的约束条件。
