根据CMU/SEI的定义，软件产品线(software product line)是一个产品集合，这些产品共享一个公共的、可管理的特征集，这个特征集能满足选定的市场或任务领域的特定需求。这些系统是遵循一个预描述的方式，在公共的核心资源 (core assets)基础上开发的。
软件产品线主要由两部分组成，分别是核心资源和产品集合。核心资源是领域工程所有结果的集合，是产品线中产品构造的基础。核心资源必定包含产品线中所有产品共享的产品线架构，新设计开发的或者通过对现有系统的再工程得到的、需要在整个产品线中系统化重用的软件构件。与软件构件相关的测试计划、测试实例以及所有设计文档需求说明书、领域模型、领域范围的定义，以及采用 COTS 的构件也属于核心资源。产品线架构和构件是用于软件产品线中的产品构建的最重要的核心资源。
软件产品线开发有4个基本技术特点，即过程驱动、特定领域、技术支持和架构为中心。与其他软件开发方法相比，组织选择软件产品线的宏观上的原因有:对产品线及其实现所需的专家知识领域的清楚界定;对产品线的长期远景进行了战略性规划。
产品线的过程模型
软件产品线的过程模型主要有双生命周期模型、SBI模型和三生命周期模型
- 双生命周期模型
最初的和最简单的软件产品线开发过程的双生命周期模型来自STARS分成两个重叠的生命周期:领域工程和应用工程。两个周期内部都分成分析、设计和实现三个阶段。
领域工程阶段的主要任务有:
(1)领域分析。利用现有系统的设计、架构和需求建立领域模型
(2)领域设计。用领域模型确定领域/产品线的共性和可变性，为产品线设计架构
(3)领域实现。基于领域架开发领域可重用资源(构件、文、代码生成器)
应用工程在领域工程结果的基础上构造新产品。应用工程需要根据每个应用独特的需求，经过以下阶段生成新产品。
(1)需求分析。将系统需求与领域需求比较，划分成领域公共需求和独特需求两部分，得出系统说明书。
(2)系统设计。在领域架构基础上，结合系统独特需求设计应用的软件架构。
(3)系统实现。遵照应用架构，用领域可重用资源实现领域公共需求，用定制开发的构件满足系统独特需求，构建新的系统。
应用工程将产品线资源不能满足的需求返回给领域工程，以检验是否将之合并入产品线的需求中。领域工程从应用工程中获得反馈或结合新产品的需求进入又一次周期性发展，称此为产品线的演化。
双生命周期模型定义了典型的产品线开发过程的基本活动、各活动内容和结果以及产品线的演化方式。这种产品线方法综合了软件架构和软件重用的概念，在模型中定义了一个软件工程化的开发过程，目的是提高软件生产率、可靠性和质量，降低开发成本，缩短开发时间。
2.SEI模型
SEI将产品线的基本活动分为三部分，分别是核心资源开发(即领域工程)、产品开发(即应用工程)和管理。
如图 所示。
从本质上看，产品线开发包括核心资源库的开发和使用核心资源的产品开发，这两者都需要技术和组织的管理。核心资源的开发和产品开发可同时进行，也可交叉进行
例如，新产品的构建以核心资源库为基础，或者核心资源库可从已存在的系统中抽取。有时，也把核心资源库的开发称为领域工程，把产品开发称为应用工程。
每个旋转环代表一个基本活动，三个环连接在一起，不停地运动着。三个基本活动交错连接，可以任何次序发生，且是高度重叠。旋转的箭头表示不但核心资源库被用来开发产品，而且已存在的核心资源的修订甚至新的核心资源常常可以来自产品开发。在核心资源和产品开发之间有一个强的反馈环，当新产品开发时，核心资源库就得到刷新。对核心资源的使用反过来又会促进核心资源的开发活动。另外，核心资源的价值通过使用它们的产品开发来得到体现。
SEI模型的主要特点如下。
(1)循环重复是产品线开发过程的特征，也是核心资源开发、产品线开发以及核心资源和产品之间协作的特征。
(2)核心资源开发和产品开发没有先后之分。
(3)管理活动协调整个产品线开发过程的各个活动，对产品线的成败负责。
(4)核心资源开发和产品开发是两个互动的过程，三个活动和整个产品线开发之间也是双向互动的。
- 三生命周期模型
Fred针对大型软件企业的软件产品线开发对双生命周期模型进行了改进，提出了三生命周期软件工程模型，如图所示
为有多个产品线的大型企业增加企业工程(enterprise engineering)流程，以便在企业范围内对所有资源的创建、设计和重用提供合理规划。为了强调产品线工程在满足市场需求上与一般的系统化重用的区别，在领域工程中增加了产品线确定作为起始阶段，和领域分析阶段、架构开发阶段、基础资源开发阶段组成整个领域工程，还为领域分析阶段增加市场分析的任务;同样，为应用领域增加了商务/市场分析和规划。在领域工程和应用工程之间的双向交互中添加核心资源管理作为桥梁，核心资源管理和领域工程、应用工程之间的支持和交互是双向的，以便于产品线核心资源的管理和演化。以上描述的软件产品线开发过程并没有明确描述如何重用软件组织内遗留资源(legacy assets)。实际上，大多数将要建立软件产品线的软件组织都积累有产品线所在领域的大量应用代码和相关文档，这些代码和文档中包含的知识对领域工程来说是至关重要的。
产品线的组织结构
软件产品线开发过程分为领域工程和应用工程，相应的软件开发组织结构也应该有两个基本组成部分，即负责核心资源的小组和负责产品的小组。这也是产品线开发与独立系统开发的主要区别。
- 独立核心资源小组
设有独立核心资源小组的组织结构通常适合于至少由 50~100 人组成的较大型的软件开发组织，设立独立的核心资源小组可以使小组成员将精力和时间集中在核心资源的认真设计和开发上，得到更通用的资源。但独立的核心资源小组很容易迷失于建立极好的高度抽象、高度可重用的核心资源上，而忽视了这些资源对应用工程中需求的满足程度，因为这样的结构容易抑制应用工程中的反馈，使得所开发的核心资源无法在整个产品线中获得良好的应用。
另外一种典型的组织结构不设立独立的核心资源小组，核心资源的开发融入各系统开发小组中，只是设立专人负责核心资源开发的管理。这种组织结构的重点不在核心资源的开发上，所以比较适合于组成产品线的产品共性相对较少，开发独立产品所需的工作量相对较大的情况。这也是小型软件组织向软件产品线开发过渡时采用的一种方法。
- 组织模型
Jan Bosch在研究了众多采用软件产品线开发方法的公司后，将软件产品线的组织结构归纳为4种组织模型。
(1)开发部门。所有的软件开发集中在一个部门，每个人都可承担领域工程和应用工程中适合的任务，简单、利于沟通，适用于不超过 30人的组织。
(2)商务部门。每个部门负责产品线中一个和多个相似的系统，共性资源由需要使用它的一个和几个部门协作开发，整个团体都可享用。资源更容易共享，适用于30~100人的组织，主要缺点是商务部门更注重自己的产品而将产品线的整体利益放在第二位。(3)领域工程部门。有一个专门的单位一-领域工程部门负责核心资源库的开发和维护，其他商务单位使用这些核心资源来构建产品。这种结构可有效地降低通信的复杂度、保持资源的通用性，适用于超过 100 人的组织。缺点是难以管理领域工程部门和不同产品工程部门之间的需求冲突，以及因此导致的开发周期增长。(4)层次领域工程部门。对于非常巨大和复杂的产品线，可以设立多层(一般为两层)领域工程部门，不同层部门服务的范围不同。这种模型趋向臃肿，对新需求的响应慢。
- 动态组织结构
对于中小型软件开发组织来说，建议采用一种动态的组织结构，根据产品线的建立方式和发展阶段、成熟程度的变化，由一种组织结构向另一种组织结构演变。这种方法的主要依据是在产品线不同发展阶段，领域工程和应用工程在总工作量中所占的比例是不同的。例如，对于从零开始建立的产品线，在其建立初期，核心资源的开发工作量要大大多于产品的开发。此时集中力量组织成专门的小组进行核心资源的开发，当核心资源基本完成时，可以将该小组部分成员逐步转移到产品开发中。而对于已有多个产品的
情况下建立产品线的演变过程，使用相反的方向更为合适。这种动态的组织结构可以使中小型组织采用产品线开发方式造成的在人力资源上的压力得到缓解，使人力资源的需求在产品线的整个开发工程中趋于平稳。人员在两种小组之间的流动可以使流动人员作为小组之间信息交流的一种补充方式，虽然这不是一种最好的、合乎规范的信息交流方式，但毕竟也是一种快速有效的方式。组织结构的变化对产品线来说是一个很重要的问题，需要制定相应的变化规划并要有良好的管理技术的支持来保证整个产品线的成功。
产品线的建立方式
软件产品线的建立通常有 4 种方式，其划分依据有两个，第一个是该组织是用演化方式(evolutionary)还是革命方式(revolutionary)引入产品开发过程，第二个是基于现有产品还是开发全新的产品线。4种方式的基本特征如表所示
(1)将现有产品演化为产品线。在基于现有产品架构设计的产品线架构的基础上，将特定产品的构件逐步地、越来越多地转化为产品线的共用构件，从基于产品的方法“慢慢地”转化为基于产品线的软件开发。这种方法的主要优点是通过对投资回报周期的分解、对现有系统演化的维持，使产品线方法的实施风险降到了最小，但完成产品线核心资源的总周期和总投资都比使用革命方式要大。
(2)用软件产品线替代现有产品集。基本停止现有产品的开发，所有努力直接针对软件产品线的核心资源开发。遗留系统只有在符合架构和构件需求的情况下，才可以和新的构件协作。这种方法的目标是开发一个不受现有产品集存在问题限制的、全新的平台，总周期和总投资较演化方法要少，但因重要需求的变化导致的初始投资报废的风险加大。另外，基于核心资源的第一个产品面世的时间将会推后。现有产品集中软硬件结合的紧密程度，以及不同产品在硬件方面需求的差异，也是产品线开发采用演化还是革命方式的决策依据。对于软硬件结合密切且硬件需求差异大的现有产品集因无法满足产品线方法对软硬件同步的需求，只能采用革命方式替代现有产品集。
(3)全新软件产品线的演化。当一个软件组织进入一个全新的领域，要开发该领域的一系列产品时，同样也有演化和革命两种方式。演化方式将每一个新产品的需求与产品线核心资源进行协调。这种方式的好处是先期投资少，风险较小，第一个产品面世时间早。另外，因为是进入一个全新的领域，演化方法可以减少和简化因经验不足造成的初始阶段错误的修正代价:缺点是已有的产品线核心资源会影响新产品的需求协调，使成本加大。
(4)全新软件产品线的开发。架构设计师和开发工程师首先要得到产品线所有可能的需求，基于这个需求超集来设计和开发产品线核心资源。第一个产品将在产品线核心资源全部完成之后才开始构造。这种方式的优点是一旦产品线核心资源完成后，新产品的开发速度将非常快，总成本也将减少;缺点是对新领域的需求很难做到全面和正确,使得核心资源不能像预期的那样支持新产品的开发。
