软件产品线
出自 MBA智库百科(https://wiki.mbalib.com/)
软件产品线（Software Product Line）
目录 |
软件产品线是指具有一组可管理的公共特性的软件密集性系统的合集，这些系统满足特定的市场需求或任务需求，并且按预定义的方式从一个公共的核心资产集开发得到。
因为软件产品线的系统，需要按照指定方式进行公共资产集的开发，与独立开发、从零开始开发、随机开发等方式相比较，可以获得显著的生产经济效益。正是由此产生的经济效益，才使软件产品线更具吸引力。
首先每个产品都由来自公共资产库中的组件组成，然后按照预先定义的变化机制，如参数化或继承，对这些组件进行必要的裁剪，添加任何必须的新组件，根据一个产品线范围内的公共架构来组装这些组件。于是，构建一个产品（系统）主要工作是组装和繁衍，而不是创造；主要的活动是集成而不是编程。每条软件产品线都有一个预先定义的指南或计划，用来定义确切的产品构建方法。
软件产品线依赖于基于组件开发的形式，涉及到的要素很多。基于组件开发的典型定义是指从内部库或是市场选择组件来构建产品。尽管软件产品线中的产品确实是由组件组成的，但这些组件都是由产品线架构指定的，且按预定义的方式组装，如在组件中采用内置变体机制，以便将其用于指定的产品。该定义来自于架构和生产计划，而不是标准的基于组件的开发。在产品线中，组件通常是在资产库中进行演进和维护的。而在基于组件的开发中，若有任何变化，一般都是通过编写代码来完成，其变化部分通常都是分别维护的。单独的基于组件的开发常常缺乏技术和组织管理方面的支持，而这点对软件产品的成功非常重要。
软件产品线工程能够在开发成本和产品上市时间方面极大地改善软件开发过程。在软件复用方面达到了空前未有的高水平。产品线工程基于四个主要概念：可变性管理是产品线工程最核心的概念。产品线工程最核心的思想就是可变性管理，正是基于可变性模型来确定需求、建模并实现产品线工程中的公共与变化量；产品线与一般性产品最大的差别就是它把战略视角从单个合同转到整个业务领域的长期策略上来，要使产品线工程与商务策略达成一致；参考架构在产品线工程中有着关键的作用。人们已经意识到，复用若想取得真正的成功就必须对不同的产品采用一种公共的架构；产品线工程划分成领域工程与应用工程二部分，这就把为复用的开发与复用着的开发分离开来。
1）可变性管理（Variability management）。软件产品线工程致力于支持一系列的产品。这些产品会支持不同的、个性化的用户或者侧重点完全不同的市场划分。可变性是软件产品线工程中最关键的概念。软件产品线工程并不是去理解每个单个系统而是关注整体及在这些单个系统中的变化。在整个软件产品线工程中要定义、表示、探索、实现、演进可变性，也就是管理可变性。
2）商业中心（Business-centric）。传统的软件开发关注的是单个系统，而产品线工程总是强调的是整个市场。只有当产品线基础能够长期提供充分的手段支持新产品有效地投放到市场，产品线工程才能够获得功。因而，要以经济的观点考虑单个产品与产品线的关系，对单个产品的决策要与更大的产品线联系在一起。这种强大的联系表明，最重要的是要理解产品线启动的业务目标。通常业务目标是降低人力/成本，加快上市速度；或者与质量相关，如提高可靠性或者改善可用性。这些特定目标给我们提供了产品线工作决策的基础，以确定需求是否要实现、是作为整个产品线的需求或作为特定产品的来实现。这些目标同时帮助我们明确投入的平衡点在那里。
3）架构中心（Architecture-centric）。从技术上来讲，软件开发必须利用单个系统间的相似性。软件产品线工程是以公共的产品线架构（或者称参考实现）为基础的，因而经常称之为以架构为中心。与其它重用方法相比，公共架构的中心角色是产品线工程成功的主要因素。为给不同组件提供一个一致的描述，以通用的接口开发、装配并应用于不同的产品，就要在领域工程中设计参考架构。通用的架构对所有在不同的产品中使用的组件定义了单一的环境，这就保证了对相类似的功能不需要开发多个组件只需要考虑它们的工作环境。
4）两个生命周期（Two-life-cycle approach）。软件产品线工程是由领域工程和应用工程构成。这二种工程，在理想的情况下，只是基于平台松耦合和同步。因而，形成了完全不同的生命周期模型。领域工程与应用工程的区别是产品线工程的一个关键特性。
- 误区一：偶然的小粒度重用
重用，作为降低开发成本，提高质量的软件策略已经不是新方法，软件产品线肯定涉及到重用，事实上是最高级别的重用。以前的重用主要是指相对较小的代码块的重用，也就是小粒度重用。有些机构已经建成了包含算法、模式、对象和组件的可重用库。软件开发人员写的任何东西几乎都要放到库里，然后鼓励（有时是要求）其他开发人员使用库里所提供的东西而不是创建自己的版本。不幸的是在很多情况下，查找这些小模块以及将其集成到一个系统中所花费的时间比重新开发他们更长。文档，倘若有的话，可以说明模块创建的情况，却不能说明如何对模块进行集成或进行适应性的修改。小粒度的重用的成功依赖于软件工程师是否喜欢使用库里的内容、库中的内容对工程师需要的适应性，以及能够成功将库中内容进行改写并集成到系统的其他部分。如果这些条件都满足，则采取重用，但它具有偶然性，并非总能发生。
在软件产品线方法中，重用是有计划的、能够实现的和强制的（机会主义的对立面）。资产库包括从一开始就花费大量成本进行开发的各类产品——即需求、领域建模、软件架构、性能模型、测试用例和组件。所有资产都为重用而设计，并且为了能重用与多个系统进行了优化。软件产品线的重用是全面的、有计划的、有经济效益的。
- 误区二：利用重用的单系统开发
这种方法和软件产品线方法有两点主要区别。首先，软件产品线重用的资产是明确为重用而设计的。其次，产品线被视为一个整体，而不是可以区别对待和维护的多个产品。在成熟的产品线组织中，多个产品的概念已经消失。每个产品是核心资产的一个简单定制，只有核心资产才被认真的设计并随时间演进，只有核心资产才是组织的杰出智力财产。
- 误区三：仅仅基于组件的开发
软件产品线依赖于基于组件开发的形式，涉及到的要素很多。基于组件开发的典型定义是指从内部库或是市场选择组件来构建产品。尽管软件产品线中的产品确实是由组件组成的，但这些组件都是由产品线架构指定的，且按预定义的方式组装，如在组件中采用内置变体机制，以便将其用于指定的产品。该定义来自于架构和生产计划，而不是标准的基于组件的开发。在产品线中，组件通常是在资产库中进行演进和维护的。而在基于组件的开发中，若有任何变化，一般都是通过编写代码来完成，其变化部分通常都是分别维护的。单独的基于组件的开发常常缺乏技术和组织管理方面的支持，而这点对软件产品的成功非常重要。
- 误区四：仅有一个可配置的架构
设计参考架构和面向对象框架是为了能重用于多个系统，并且必须可以重新配置。重用架构的各种结构是个很好的方法，因为架构对任何系统而言都至关重要，而且构建代价较高。产品线架构的设计必须支持产品线中个产品间的不同（变化），因此它必须是可配置的。但是，即便产品线架构很重要，也只是产品线资产库中的一项资产。
- 误区五：单个产品的发布和版本
组织要定期发布新产品和退出产品的新版本，每个新版本的发布一般都是通过使用以前版本的架构、组件、测试计划和其他要素来构建。为什么软件产品线有所不同呢？首先，在产品线中同时存在多个产品，每个产品都有其自己的发布和版本周期。因此，必须在更广的上下文环境中考虑单个产品的演进——也就是说，产品线是作为一个整体来演进的。其次，在单个产品的上下文环境中，产品一旦被更新，通常不可逆——即认为早期产品生产中的任何东西都不再有价值。但是在产品线中，产品的早期版本仍被认为具有市场潜力，并很容易地作为产品家族中的一个可生存成员保留下来：毕竟它如同其他产品的其他版本一样，是核心资产的一个实例。
- 误区六：仅有一套技术标准
许多组织建立一套标准来限制软件工程师选择集成到系统中的组件的种类和来源。他们审查架构和评审设计以确保遵循了这些标准。例如，开发人员能够从两种确定的数据库和两种确定的网页浏览器中进行选择，但是必须使用一种指定的中间件或电子数据表产品（需要时）。技术标准可提高协同能力，降低商业组件的维护和支持费用。一个正在推行产品线的组织可能也拥有这样的技术标准，产品线架构和组件都需要遵循这些标准，但是这些标准仅仅是输入到软件产品线中的约束条件。
