两种方法在商业银行软件需求管理中的实践分析

开篇：润墨网以专业的文秘视角，为您筛选了一篇两种方法在商业银行软件需求管理中的实践分析范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！

摘要：　软件需求管理是一项针对软件开发的管理方法，其要求管理方法既能保证软件开发的完善性与安全，也可保证开发的效率，因此应从需求出发将两种管理方法有机的结合起来，从而保证需求管理的有效性。

关键词：　需求管理；RUP方法；XP方法；合理选择

中图分类号：F830 文献标识码：A 文章编号：1671-7597（2012）1020169－01

1　需求管理简述

需求管理是软件项目中常见的一种管理方式，是根据软件工程中的词汇表的定义而得来的，需求管理就是为了解决用户对软件的某种需求而进行的相应的分析，为了满足各种条件而进行的多种工作的总和。需求管理就是为了一个系统的需求而进行启发、组织、建档的系统方法，其目标就是让软件开发的方向与功能满足客户需求，以此建立一个满足客户与项目团队之间需求，并最终达到一致的过程。在许多的项目中，需求问题往往是满足客户软件开发目标的基本问题，而软件需求管理往往也成为软件开发项目成败的关键。所以在银行业软件管理中，为了满足客户的需求应借助于需求管理来进行项目目标的实现。

2　两种方法的解析

2.1　RUP需求管理

1）基本概念

RUP的本质是统一过程，即以思想集合与方法集合为核心思路，是一种过程模式。从软件建立过程的角度来分析需求，其以迭代增量、驱动开发为主要特征，其中用例驱动始终贯穿开发的全过程，其核心目标就是制定经济性目标并满足高质量需求。

2）管理模式

首先是需求分析，其中包括了三个部分的管理流程，即分析系统、需求理解、定义系统，分析系统是对目标的前景进行分析确定初步的需求，构成前景文件，确定系统的高级用户与客户视图，定义系统的基本功能与分工性技术需求；需求理解，则是主要采集公共信息，即对普遍的需求进行分析，确定优先级别，以此修改前景文件加深对需求的理解；定义系统，则是分析问题和需求理解的相关成果，改进前面所定义的文件，添加或者改善相应的用例或者约定等，创建补充问题，完善高级需求。

其次，需求确立。在此过程中有管理系统规模与改进定义两个部分组成，系统规模主要是描述大多数的系统需求的主角与用例等，收集相关属性并精确划分，使得相关人员确定系统有很好的理解，明确认可重要用例；改进系统定义则是双方人员对用例或者补充规定进行细化。

第三，需求变更。在此管理过程中，RUP中这个过程的主要活动是，出现变更双方的团队应和基础对象进行交流，通过对需求变更的性质与原理的审核，对变更进行准确的修订，确定其性质，同时将变更传递给需求的直接受益者，进行相关的前景、用例等改变。需求复审的人员应审查相关的历史资料对其变更的活动进行分析，以保证其修改合理。

最后，版本控制，RUP中的需求版本通常是利用定义版本三线的方式进行对版本的控制，但是在RUP的需求管理中并没提及此项目。

2.2　XP的需求管理方法

2.2.1　XP需求管理的概念

XP方法是一种极限编程的方式，是被认可的敏捷型开发方式，是对以往的传统开发方式的改进，在总结经验后提出了改进开发的四个要素，即良好沟通、简化模式、反馈意见、勇气，这就是XP开发的核心价值。其极限编程也是一种高度动态化的过程，利用较短的迭代周期来适应需求的改变，是一种轻量级的开发方法论。

2.2.2　XP管理方法

首先，需求分析过程，在XP中需求分析与需求确认是同步进行的，需求分析中客户提出相应的流程需求，描述相关的系统性能与用途，以及使用方法等，项目开发人员不断的提出问题加以完善，最终保留需求的核心。其核心内容也可看做是“故事”的两个部分，一个是开发中的基本需求，即主题；一个则是需求分析中的重要节点，需要保存在附带的文档中，以备设计应用。用户会按照程序员给出的优先级别，从记录中提取需求，项目组与客户对每一个需求进行分析，分析完成后程序员会根据情节进行问题发现并进行修改。最终需求确认则是根据上述流程所定义需求来进行。

其次，需求达成，即需求实施的阶段，程序员根据细节会不断的与客户进行沟通，并将其最终需求写入代码。功能需求此时还是记录，虽然可以提供某些细节，但是主体细节还要通过交流加以完善。随着项目开展，细节问题逐步增加，需求也就愈发贴近客户需求。在XP中需求状态会用故事卡片来体现，其卡片的位置也就是需求状态的体现。

第三，XP版本控制，在需求管理中版本是由客户确定的，需求的改变程序员实施的客户需求都是最新的，集成测试的过程代码也共享在公共的服务器上，组内的程序员可以获得最新版本。

最后，需求变更的管理，在XP方法中，变更也是建立在客户“故事”上，对于实现需求修改与添加的情况，都会以添加新故事的方式出现，此时需求相应的被获准进行审核。当某个客户的新需求被测试并通过后，则被转移到一个指定位置被存放，设置为验证。对没有实施的需求直接撤销卡片，在某个迭代周期内需求都应被测试，XP建议客户在制定的小版本内，以此来加速信息反馈与变更的过程。

3　两种方法在银行软件需求管理中的选择与应用

国内的银行经过不断的升级与发展，逐渐建立起完整的商业银行的IT架构，按照国际上的最佳方式，IT总体架构包括了

业务、数据、应用、技术这四个关键的内容，应用架构是最为核心的功能之一，其可以分为不同的层次，如渠道层、管理层、产品层、操作层等，不同的应用架构对不同的银行而言有共同点也有差异，且技术需求也有不同，使之产生了不同的软件架构，不同的软件结构对需求管理的要求也就不同，通常而言商业银行按照交易特征来分，可以划定为交易类系统和分析管理类系统应用两种。

此时需求管理中RUP可以贯穿整个生命周期，开发活动以架构核心展开，流程初期迭代的重点在于生产与验证架构的可行性。在最初的开发过程中先执行一个架构的原始模型，然后在今后的迭代中逐步对系统进行演化与更新，最终形成完善的系统。利用这个架构模式可以降低性能、吞吐量、容量等方面的基本风险，从而使得构件过程在一个相对稳定的基础上完成，不用担心系统遭到破坏。所以在软件项目的实施中，可以在整体架构上利用RUP模式来分阶段完成逐步演进，针对交易系统的应用架构采用RUP的需求管理方式进行管理，而在分析类管理系统中也可利用RUP管理为主线，采用XP的需求管理方式完成对软件需求的细化管理，从而建立一个根据软件需求而进行组织与管理的复合性管理模式，即选择RUP为主体思路与框架，而XP管理则可满足提高工作效率的目标，这样即保证了需求管理的稳定与安全，也提高了需求达成与变更的效率。

4　结束语

从上面的分析不难看出，RUP与XP的需求管理方式对用户需求的满足路线不同，一个是严格遵循系统化的方式，一个则是力求提高效率，因此在银行软件需求管理中应借助于二者的优势，将其有机的结合起来，进而保证系统构建的安全性，也提高其效率。

参考文献：

[1]周晶平，金融软件需求管理方法的改进[J].中南民族大学学报（自然科学版），2008（03）.

[2]华佳林、谢国强、廖雁，软件需求管理重要性浅析[J].科教文汇，2008（11）.

[3]郑子洲，金融行业软件需求管理探讨[J].项目管理技术，2009（S1）.

[4]吴艳艳、周长伦等，软件项目管理中的需求管理[J].济南：信息技术与信息化，2008，2.

[5]刘述忠，金融软件需求管理的一般问题[T].中国金融电脑，2002（9）