软件产品线的误区

误区一：偶然的小粒度重用 　

　　重用，作为降低开发成本，提高质量的软件策略已经不是新方法，软件产品线肯定涉及到重用，事实上是最高级别的重用。以前的重用主要是指相对较小的代码块的重用，也就是小粒度重用。有些机构已经建成了包含算法、模式、对象和组件的可重用库。软件开发人员写的任何东西几乎都要放到库里，然后鼓励（有时是要求）其他开发人员使用库里所提供的东西而不是创建自己的版本。不幸的是在很多情况下，查找这些小模块以及将其集成到一个系统中所花费的时间比重新开发他们更长。文档，倘若有的话，可以说明模块创建的情况，却不能说明如何对模块进行集成或进行适应性的修改。小粒度的重用的成功依赖于软件工程师是否喜欢使用库里的内容、库中的内容对工程师需要的适应性，以及能够成功将库中内容进行改写并集成到系统的其他部分。如果这些条件都满足，则采取重用，但它具有偶然性，并非总能发生。 　

　　在软件产品线方法中，重用是有计划的、能够实现的和强制的（机会主义的对立面）。资产库包括从一开始就花费大量成本进行开发的各类产品——即需求、领域建模、软件架构、性能模型、测试用例和组件。所有资产都为重用而设计，并且为了能重用与多个系统进行了优化。软件产品线的重用是全面的、有计划的、有经济效益的。

误区二：利用重用的单系统开发 　

　　这种方法和软件产品线方法有两点主要区别。首先，软件产品线重用的资产是明确为重用而设计的。其次，产品线被视为一个整体，而不是可以区别对待和维护的多个产品。在成熟的产品线组织中，多个产品的概念已经消失。每个产品是核心资产的一个简单定制，只有核心资产才被认真的设计并随时间演进，只有核心资产才是组织的杰出智力财产。

误区三：仅仅基于组件的开发

　　软件产品线依赖于基于组件开发的形式，涉及到的要素很多。基于组件开发的典型定义是指从内部库或是市场选择组件来构建产品。尽管软件产品线中的产品确实是由组件组成的，但这些组件都是由产品线架构指定的，且按预定义的方式组装，如在组件中采用内置变体机制，以便将其用于指定的产品。该定义来自于架构和生产计划，而不是标准的基于组件的开发。在产品线中，组件通常是在资产库中进行演进和维护的。而在基于组件的开发中，若有任何变化，一般都是通过编写代码来完成，其变化部分通常都是分别维护的。单独的基于组件的开发常常缺乏技术和组织管理方面的支持，而这点对软件产品的成功非常重要。

误区四：仅有一个可配置的架构

　　设计参考架构和面向对象框架是为了能重用于多个系统，并且必须可以重新配置。重用架构的各种结构是个很好的方法，因为架构对任何系统而言都至关重要，而且构建代价较高。产品线架构的设计必须支持产品线中个产品间的不同（变化），因此它必须是可配置的。但是，即便产品线架构很重要，也只是产品线资产库中的一项资产。

误区五：单个产品的发布和版本

　　组织要定期发布新产品和退出产品的新版本，每个新版本的发布一般都是通过使用以前版本的架构、组件、测试计划和其他要素来构建。为什么软件产品线有所不同呢？首先，在产品线中同时存在多个产品，每个产品都有其自己的发布和版本周期。因此，必须在更广的上下文环境中考虑单个产品的演进——也就是说，产品线是作为一个整体来演进的。其次，在单个产品的上下文环境中，产品一旦被更新，通常不可逆——即认为早期产品生产中的任何东西都不再有价值。但是在产品线中，产品的早期版本仍被认为具有市场潜力，并很容易地作为产品家族中的一个可生存成员保留下来：毕竟它如同其他产品的其他版本一样，是核心资产的一个实例。

误区六：仅有一套技术标准

　　许多组织建立一套标准来限制软件工程师选择集成到系统中的组件的种类和来源。他们审查架构和评审设计以确保遵循了这些标准。例如，开发人员能够从两种确定的数据库和两种确定的网页浏览器中进行选择，但是必须使用一种指定的中间件或电子数据表产品（需要时）。技术标准可提高协同能力，降低商业组件的维护和支持费用。一个正在推行产品线的组织可能也拥有这样的技术标准，产品线架构和组件都需要遵循这些标准，但是这些标准仅仅是输入到软件产品线中的约束条件。