银行业务需求分析模式及路径初探.docx

《银行业务需求分析模式及路径初探.docx》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、随着近年来各大商业银行信息系统建设的持续推进，IT治理和管理分析水平不断提高，组织成熟度上升，作为整个信息系统建设的上游——需求分析和管理这一环节也取得了长足的进步，但是随着业务的不断发展，由于新的业务品种、新的产品功能的出现以及监管的日益精细化，需求的分析和管理遇到了新的挑战。本文旨在通过梳理目前典型需求的管理的现状，探索改变粗放管理和静态管理的方式，从不连续的阶段管理向全生命周期管理，从分散式管理向集中式管理，从定性管理向定量分析管理(成本和工作量)，从宏观指导到技术分析操作等方面的可能的管理方式。以此为后续

2、的需求编写、规格分析、计划制定、需求规模评估、变更影响评估等方面提供参考依据，并通过建立软件规模评估体系，为外包项目的商务采购提供估价依据。需求分析和管理远期目标更是建立全行需求库，提高需求复用和配置的质量，需求管理流程从非工厂模式向工厂模式方向转变，形成需求立体视图，构建需求提出部门、需求管理和分析部门与需求实施部门的高效合作关系，有力支持业务部门快速推出产品和服务。　　一、需求的分析和管理现状梳理　　需求的分析和管理遇到的新挑战主要表现在以下几方面。　　首先，各大商业银行基本都已经有组织级的项目计划，但是没有

3、与之匹配的企业级年度需求计划，需求在评审、需求说明书编写模板等方面已经有比较完善的流程和电子化管理方法，而且这些方法和项目管理方法已经很好地进行了整合，满足项目实施的生命周期的跟踪等管理要求。但是目前尚缺乏需求跟踪、需求量化评估、需求精细颗粒度管理的成本评估，还没有从需求实体视角下的需求全生命周期管理的完整规范、规格以及需求管理信息化管理工具，无法从需求本身的视角上来审视需求本身进化和各控制节点。其次，从需求全生命周期管理的组织职能配备上来看，还没有需求专业化管理的专人和职能团队配备，需求的管理在职能上分布在不同

4、的项目管理角色中，存在职责定义粗放，参考规范缺乏，或者规范本身有待完善等问题;需求本身也没有进行分层，目前业界理解的Kano模型中的基本需求、满意需求、吸引力需求没有在需求编写中进行识别和区分，从开发层面理解的系统需求和组件需求也没有在后续的分析过程中体现。　　再次，从组织过程资产的角度来看，当前大量的需求(含总部历年形成的各种开发类的需求)并没有形成统一规范的需求库，需求质量在形成和积累的过程中没有大幅提高，规范性也没有获得很好的提升，在需求复用、检索、查询以及信息化支持上缺乏与其他系统很好整合的需求管理系统，

5、依然存在大量的手工操作，效率低下，错误率高。从上游的需求提出部门来说，需求编写、形成、涉众分析、需求横向整合、需求和实施部门的有效沟通和效率提升还没有形成有效的共识和工作方法。　　最后，从需求工程的结构上看，各行在需求确认(评审)、需求调查(已规划)、需求变更(变更流程已覆盖)、需求定义(需求模板、规格书模板等)已达到了相当的成熟度(见图1绿色边框部分)，但是在需求分析(含定性和定量分析)、需求跟踪(多维度的跟踪矩阵、建立与维护“需求文档-设计文档-代码-测试案例”)方面还比较欠缺，需求是不连续的平面，而不是立体

6、的。　　随着各行各项目(群)的推进，目前遇到最为迫切的问题是需求的规模、复杂程度、影响范围、成本估算、厂商报价的合理性等诸多和需求评估相关的问题需要解决，来保障新一代项目的顺利推进。而这些问题的解决都需要一个共同的前提基础，需求必须进行细颗粒度的量化管理，才会形成对计划、预算、商务以及后续组织过程资产的有效支撑。　　二、分析模式初探　　1.类比法　　类比估算方法是一种通用的需求估算方法，这种方法操作起来比较简单，但是适用范围有限，且对估算人员的个人经验有很高的要求，从本质上来说是项目管理理论中的专家评估方法的衍生

7、应用。类比估算方法需要估算的标的需求拥有类似的参照对象，相似度越高，则类比估算的结果越准确。类比方法的理论也有一些进步，例如有人引入欧几里德距离来计算项目的相似度，并且产生了ESTOR、ANGEL、AQUA等估算辅助工具。类比估算法方法操作成本低，参考值更多地参考实际操作的数值，是广泛使用的需求估算方法之一，但是难以通过流程来标准化，存在偏差也难以进行可续的更正，偏差值难以估量，只能事后补救，所以又被称为是“换人拍脑袋”法。估算人员又有不同的个性化的方法，颗粒度理解不一，随意性比较大，有的人自顶向下，有的人自下向

8、上，因为没有模型支持，很容易有遗漏掉的内容，加之不可能存在完全相同的两个参照标的，所以这种估算方法只能作为整体估算中的部分估算的方法。　　2.模型法　　在软件工程和系统工程中，用例被定义为是一种通过用户定义的外部执行者和系统之间相互交互来实现的业务目标。这里执行者可能是一个实际的操作员，也可能是一个虚拟的操作员，例如一个系统或者就是另外一个用例。由此可见，在实际的业务环境