软件产品线工程方法 - 四个主要方法原则

本文已挪至  http://www.zhoujingen.cn/blog/1431.html

 

信息系统存在很多共性,如果作为产品来开发,那么如何能够通过平台来进行重用和扩展,业界中的产品线工程方法就是进行大范围复用的一种方法。 在园子里也住了不短时间,发现关注技术的占多数,而除了技术外,软件工程中还有很多我们需要关注的,如下图,软件架构平台基于产品线工程开发。前一阵子对Scrum进行了介绍,接下来准备写几篇产品线相关的内容,本篇将对产品线中的四个主要概念进行简要的说明(可变性管理、商业驱动、架构驱动、两阶段生命周期) ,希望对不熟悉产品线知识的有所帮助。

在讲解之前先解释两个概念:

产品族:一组使用通用的资源来构建的产品。一个产品族是基于它的成员产品的结构相似性而定义的。产品族成员建立在一个通用平台之上,主要基于产品之间的技术通性而设置的。产品族可以重用于多个产品线。

产品线:一组共享一组公共管理的特征的产品,这些特征满足一个选定市场的特定需要。一个产品线的定义是基于市场策略的,而不是基于它的成员产品之间的技术相似性。为一个产品定义的特征,可能需要完全不同于其它成员产品的解决方案。一个产品线可能是与一个产品族一起提供出来,但是它也可能需要不止一个产品族。

在下面介绍过程中,在谈架构平台时更偏向于产品族的概念。

为什么需要产品线方法

随着软件应用的普及,企业对软件也越来越重视,不断的要求采用软件提高效率,提升技能增强企业竞争力。随着客户的增多,软件企业这时需要 面对更多的客户,处理共性和个性问题。如何保证低成本、高质量、快速上市等要求就成为了企业竞争力的主要表现之一,而产品线工程方法就是支持这种大范围重 用(large-scale reuse)的方法。产品线区别于传统的代码重用就是大量的使用重用(可以达到90%),不仅仅是代码,还包括需求、业务等。在《OpenExpressApp架构-一个信息系统的平台》中我画了一个重用的图,产品线将基于更大范围的重用进行开发。

 

  • 减少成本

大家都知道,软件开发成本是成本的一部分,软件的维护成本也是很大一块,产品线工程除了可以减少开发成本外,维护成本也可以大大降低,不再需要维护大量不同版本不同架构的代码,也没有大量不同的文档需要维护。

  • 快速上市

     

产品基于重用开发,不需要在每个开发环节都重头开始,这样可以大大的缩短上市时间。

  • 减少风险

     

由于产品线除了可以重用框架,对同类型产品也可以重用开发方法,这样对于任务估计、开发计划都可以很好的重用,这样也可以减少项目开发的风险。

  • 提高质量

     

软件基于大量成熟和经过验证的核心资产进行开发,这些组件都已经经过大量使用并得到验证,所以在项目中应用可以保证出现的问题很少。

虽然产品线预计带来的效果很迷人,但是它并不是一开始就可以给企业带来效益的,它必须进行一些前期的投资(核心资产的开发、组织的转变等)才能获得回报,右图是产品线的经济走线图,在第三个项目时才能达到收支平衡。

产品线方法基本原则

  • 产品线方法与传统的单项目开发的主要不同在于关注点的转移:从单独的产品到产品线的项目。这个转移暗示了一个策略:从特定的项目开发到特定业务领域产品的愿景。
  • 产品线工程对开发以重用(development for reuse)使用重用来开发( development with reuse)有 明确的区分。对比传统的重用,产品线基础设施包括产品开发周期的所有资产(框架、业务模块、开发计划,需求到测试阶段),而不只是在代码级的重用。这些重 用资产都包含明确可变性说明的,如需求原型中表明这个功能只在特定子产品中才包括,这对产品业务的理解要求就更高了。 
  • 四个主要原则
    • 可变性管理(Variability management):每个产品都是核心资产的变体,必须系统化的管理产品的可变性,这对业务分析的要求就更高了,由于它在产品开发生命周期的重要性,下面会单独进行说明。
    • 商业驱动(Business-centric):产品线瞄准的是长期的商业战略,而不是仅仅走单。 传统的软件开发基于各个单独的项目进行,产品线开发要求系统全面的对市场进行定位。商业驱动方法需要决定哪些功能应该包括在产品线中,是在领域工程还是应 用工程中进行。这个在产品线中叫做确定范围(scoping)。在《软件产品线实践和模式》中提出一个公司是采用一条产品线还是多条产品线?书中提到大型 产品线只有同时具备以下两个条件时才会起到好的作用:第一, 产品具有足够多的相同点,将它们作为一条产品线是有利可图的,第二,公司有能力控制这样大大型的市场运作、开发以及其他方面。如果暂时不能满足这两个条 件,那么还是分为两个产品线进行,而不能一味的一个公司只要一个产品线。
    • 架构驱动(Architecture-centric):技术上需要支持最大化的重。产品线工程依赖一个通用的参考架构(reference architecture),特定项目架构都基于参考架构进行开发。
    • 两阶段生命周期(Two-life-cycle approach):每个产品基于平台开发,产品和平台有各自的开发团队和开发生命周期。如果条件不允许需要同时做这两种工作时,自己一定要清晰自己所做的工作哪些是领域工程,哪些是应用工程。下图为两阶段图:

      框架分为两个阶段:领域工程应用工程。 领域工程产出平台的公共核心资产,应用工程产出产品。在整个开发生命周期中,存在9个子流程,八个流程互相匹配成四组类似流程,需求、设计、在实现和测试 领域工程和应用工程都存在,每一匹配组的流程都紧密相连。领域工程的子流程目的在于满足通用需求,而在应用工程是为了生产可供使用的产品。应用工程的子流 程可以重用多达90%的领域工程资产,在生产过程中会不断的提供反馈给领域工程,这种循环反馈才能确保平台一直都能有效的生产出最终产品。

可变性管理(Variability management)

产 品线工程是支持一系列有共性的产品,下图比较清楚的表明了产品的主要点,可变性(variability)是很重要的一个概念,在产品开发过程中可变性必 须明确的定义、表达、开发、实现和不断的完善,它必须是被管理的。可变性管理应该在早期范围界定是就开始,它与所有核心资产相关。其实现在很多公司,只要 做的软件是产品性质的,很多都是服务大量不同客户,都需要进行可变性管理,但是因为没有明确提出是在进行产品线开发,所以可变性的概念并没有提出来,所以 自然也得不到重视和研究。可变性管理应该成为产品开发的核心问题之一,这也是我后年的关注点。

可变性类型

上图中显示了可变性的三种主要类型:共性、变化点、基于特定产品。要注意,随着产品的进展,基于特定产品的功能可以会变成变化点,变化点可能会变成共性。

共性和变化点在领域工程中解决,特定产品功能在应用工程解决。

三种基本的实现可变性技术

 

 

可视化可变性

上面简单讲了一下可变性的概念,那么我们如何表达出来并与别人交流呢?业界有通过模型来表达的,

下图展现了一个可变性模型和领域模型的关联。

可供参考资料:

Software Product Lines in Action
 

更多内容:  规模化产品开发方法-产品线工程 100222.pdf

 

欢迎转载,转载请注明:转载自周金根 [ http://zhoujg.cnblogs.com/ ]

posted on 2009-09-27 22:28  周 金根  阅读(9537)  评论(2编辑  收藏  举报

导航