浅谈特征驱动开发方法改进.docVIP

浅谈特征驱动开发方法改进 　　摘要：本文以特征驱动开发方法(FDD)为研究对象，针对相关问题进行了相关的探讨和分析。文章首先介绍了特征驱动开发方法的相关概念和特征，然后提出了现有特征驱动开发方法的不足，最后对特征驱动开发方法的进行了相关的改进。希望本文的研究能够为相关领域提供一些参考和借鉴。 　　关键词：特征驱动开发方法不足改进 　　 　　一、特征驱动开发概述 　　1．FDD特征概述 　　目的陈述、问题陈述、目标清单或者是系统的高层需求描述都可以成为项目中的关键因素之一。常规情况下，目的陈述是首先进行的，然后针对目的陈述可以分解出相关的一些问题并且通过定义一组子系统(或模块)来有针对性的进行逐一解决。然后，对每一个子系统，将它所要解决的问题分解为分层列表的功能需求。当需求分解的足够小后就停止分解，开始实现每一个功能需求。功能驱动和跟踪项???，其进度是可测量的。但这样的一个问题是，在做功能需求时容易将用户界面、数据存储和网络通信功能与业务功能混合在一起。结果是开发人员经常在技术特性收上花费大量的时间，而牺牲了大量的业务特性。解决这个问题的一个好方法就是：只列出对于用户确实是有价值的功能需求，并且确保需求的语言描述能够被用户理解。我们称它们为具有客户价值的功能(client．valued functions)或特征(feature)。特征(feature)在FDD中具有特定的含义。所谓特征就是一个相对较小的单元，同时具有相关的客户价值功能。[1] 　　首先特征是小的：它们小得可以在两个星期之内实现，两个星期是上限，大多数的特征小的可以在几个小时或者几天内实现。然而，特征不仅仅是简单的返回或者设置属性值的存取方法。任何一个过于复杂而且无法在两个星期内实现的功能，进一步被分解为更小的功能，直到每个子问题小到足以被称为一个特征。制定粒度的级别有助于避免经常与用例相关联的问题。使特征小一些也意味着客户能经常看到可测量的进度，从而增强了他们对项目的信心并使他们能够及早作出有价值的反馈。 　　其次特征是具有客户价值的：在业务系统中，一个特征映射到业务过程中某些活动的一个步骤。在其他系统中，特征等同于由用户完成的一项任务中的一个步骤。 　　2． FDD基本过程[2] 　　FDD的核心包括五个过程。 　　过程一：域和开发小组成员在富有经验的对象建模者(主设计师)的指导下一起工作。通过领域走查,最终确定最适合领域中这个区域的模型。整个模型可以根据需要进行调整。 　　过程二：开发小组在初始建模活动所收集的知识的基础上,构造一个尽可能综合而又全面的特征表。特征被组织成特征的集合,一个特征集通常反映一个特定的业务活动。 　　过程三：将特征集或主要特征集排序成一个高层的计划,并将这些特征集分配给主程序员。特征集依据优先级和依赖关系排序。在大型项目中，主要里程碑的时间段被设置为完成许多特征集的时间盒。开发小组同样可以用时间盒里程碑来重新正式地制定计划并获得管理者对这一变更的认可。对较小的项目，一般不需要将这些包括在计划中。 　　过程四和过程五是开发工程室。主程序员将选择一组特征在接下来的几天(不超过两周)进行开发。在这次迭代中，主程序员将确定可能用到的类及类所有者来组成特征小组。特征小组为这些特征设计出详细的顺序圈，并写出类和方法的序言，然后进行设计审查。一旦程序员满意，被完成的特征将提交给总的构造过程，再重复过程四和过程五开发下一组特征。 　　二、现有特征驱动开发方法的不足 　　1．在过程的第二阶段构造一个特征表时，特征、特征集合的构造有领域专家参与其中，但是却并有对领域专家的知识加以系统的利用，没有一个完整的领域分析过程，导致该步骤的输出只是针对某个特定的产品，而不能够提供对于产品家族开发的支持[3]。 　　2．该过程没有提供一个有力的特征模型描述机制，特征的组织零散，以特征包和特征的形式存在，没有一个统一的模型。对于特征之间的约束关系没有进行相应的考量：即使最基本的特征间的依赖和互斥关系都没有提供描述。而这种关系在决定特征的开发顺序时是非常重要的一个因素。 　　3．对于各个特征的开发次序的选取也比较随意，缺乏系统的规划以及特征问的依赖关系的影响。 　　4．特征驱动开发五个过程每一步结束后都有相应的输出，而这些输出以各种图表或者文件的形式存在，缺乏一致的描述。 　　三、对特征驱动开发方法的改进 　　针对以上问题，本文对原来的FDD方法进行了扩充和改进，具体如下： 　　1．在第二个阶段，引入领域工程方法。通过领域分析，得到一个能够支持产品家族开发的输出[4]。 　　2．以层次式的方式来组织特征。各层特征之间以整体．部分关系(whole．Part association，简称WPA)联系在一起。并且引入依赖，