论信息系统项目的风险管理
摘要：2006年6月，我参加了某国有银行黑龙江省分行城市综合网调帐系统的设计开发工作，并由领导委派担任项目组负责人。

我行城综网业务系统经过了几年的运行与发展，现在已经覆盖了一级分行的各种业务种类及由其衍生的金融创新产品，后台业务数据库越来越庞大，业务量增长迅猛，各种帐务数据的调整业务量也在增加。

所以迫切需要一种方便迅速的维护调帐系统来适应当前业务系统的发展需要。

本文结合作者的经验就项目的风险管理作了详实的论述；并就项目实施过程中采取的措施、方法作了介绍。

最后，列举了该项目风险管理的一些不足与展望。

正文：某国有银行黑龙江省分行城综网业务系统经过几年的运行与发展，现在已经覆盖全行的各种业务种类，后台业务数据库越来越庞大，业务量增长迅猛，各种帐务数据的调整业务量也在增加，所以迫切需要一种方便迅速的维护调帐系统来适应当前业务系统的发展需要。

鉴于以上业务需求的实际情况,省行科技处决定立项开发城综网调帐系统。

本人受领导委派担任项目组负责人,全面负责该项目的开发与管理。

调帐业务系统建设的主要目标如下:
(1)建立统一模式的黑龙江省分行城综网调帐系统，使城综网维护调帐业务实现分布处理，各地市行
的帐务由各地市自己调整，提高处理的响应时间；
(2)充分发挥网络的优势，在实现基本调帐业务功能的同时，可以实现知识管理、信息发布、业务经
验论坛，提高企业的服务效果；
(3)将调帐系统做成一个维护管理综合平台，以便更好的为各部门服务。

根据我行城综网业务系统运行的具体需要，结合计算机技术的发展，我们计划采用Browse/Server 方式来构建调帐业务系统。

Web服务器采用Windows IIS,应用服务器采用TongWeb,安全认证中心采用TongSec。

由于我行已经有了十分完善的计算机网络和运行环境，因此调帐业务系统应该在我行已有的网络环境上进行构建。

除了利用SSL和java自身的安全控制外，为了实现更高的安全级别，我们采用建立认证中心的方式来实现整个调帐系统的安全，可以采用TongSec来实现。

这样设计的优点：开发系统的工作量小，充分利用现有的业务系统，将来系统升级方便，系统移植性好。

在科技处领导的悉心关怀和业务部门的鼎力支持下,经过项目组同志们的艰苦努力,该项目从2006年6月启动,至2006年12月正式通过科技处组织的验收.并在2个月的试运行期间,顺利通过了年终结转的考验,至今,仍稳定运行。

项目风险管理包括进行风险管理计划编制、对项目风险进行识别、分析和应对的过程。

项目风险管理主要包括以下过程：风险管理计划编制、风险识别、定性风险分析、定量风险分析、风险应对计划编制、风险监控。

项目风险管理是项目管理的一部分，目的是保证项目总目标的实现。

在这个项目过程当中，我们对项目风险进行识别、分析，全过程跟踪风险，针对主要风险进行了应对，主要的应对措施有加强变更控制、合理配置人员、权衡质量和进度找最佳平衡点、加强测试，目的是保证实现计划的功能并按时投入运行。

一. 项目全过程有效管理和控制风险因素.
在本系统的开发过程中,科技处提供了风险管理计划的模板和风险事件列表模板．列出所有可能与每一个风险因素有关的问题。

我们从需求变更、人员管理、过程、成本、进度、质量、领导支持程度、系统运行的基础等方面共识别34项风险，并分别制定了风险应对措施。

综合考虑这些风险发生的概率及影响程度，对这些风险进行优先级排序。

为了让项目组在各个阶段保持良好的风险意识，我尝试采用了“十大风险事项跟踪”，把项目中各主要风险事项按照排序张贴在公告栏上．其他的风险放在监视列表中以备继续监视。

每周的项目会议都讨论前10个主要风险，并依据实施阶段绩效分析、财务报表等各方面信息，对残余的风险进行重新排序，随时应对风险的出现和变化。

由于当时有部分未明晰的需求包括：查询统计部分需求、客户方面可能提出的新需求．另外还有需求和范围界定不清、计划不充分、用户参与不足、缺乏领导支持、技术问题等为我们项目计划阶段主要风险事件．事实表明，这种做法效果是非常明显的．特别是业务部门方面，我定期把风险事件列表Email给业务部门的项目需求提供者．为了能尽快落实未明晰的需求部分，我与业务部门经理们进行过多次面对面的沟通。

与之尽快达成悬留部分需求的共识．需求问题很快得到解决．项目组整体信心十足，积极性和责任感增加．科技处领导方面对项目组也表现出特别的关心，特别是，曹处长开始频繁出现在项目组的每周进度评审会议上，他们也开始担心因为对项目支持不够而导致项目的失败。

二．重视需求变化的客观性，加强配置管理，控制变更。

我们采用了软件工程方法，使用渐增式的增量模型，注重满足用户需求和需求的变化。

虽然在项目立项之初，省行科技部面向所有业务部门组织了需求征集活动，并形成了《需求说明书》，但由于业务调整的不断变化，造成调账系统的需求变化频繁。

根据这个情况，为保证软件满足应用需要，我们规定：在整个项目的开发过程中，凡是业务部门提出的、经调查情况属实的、经技术可行性论证可行的，全部予以响应。

同时，采取措施避免需求的反复和无意义、不合理的变更。

对较大的变更和比较关键的变更，要经各方联席会议论证通过，参与人员签字负责，并由提出变更的单位加盖公章确认。

对于不合理或技术上不可行没有通过的需求变更，要提出替代的解决办法，并与业务单位协商，达成一致意见后予以解决。

我们由项目经理、业务代表、质量控制人员、配置管理人员组成变更控制委员会（CCB），按照提出变更、审查变更、批准（否决）变更、实施变更、验证变更、记录变更及原因的程序严格控制配置项变更，使项目的混乱减到最小，使错误达到最少。

另外，我们也深刻体会到：只有和变更控制进行配合，将变更的原因和变更的结果（配置项的某一版本）联系在一起，才能以变更为主线，将所有版本变为“有理由的”，才能形成基线，真正发挥变更控制和版本管理的作用，保证项目的质量。

三、合理配置人员，通过对人员的控制，达到对质量的控制。

通过对角色的质量控制，达到对软件质量的控制。

我们制定了各组的规范及各类人员的职责，作为控制的标准。

对项目组人员进行规划配置，合理分工，明确责任，保证项目各阶段、各方面的工作能够按计划完成。

我们在项目组中配置了以下人员：技术组长一名，负责技术难题攻关，组间沟通协调；需求人员5名，负责将用户需求转换成项目内的功能需求和非功能需求，编制项目需求规格说明书，针对每个迭代集成版本与用户交流获取需求的细化；设计人员5名，根据需求规格说明书，进行
系统设计；开发人员8名，实现设计，完成用户功能；集成人员1名，负责整套系统的编译集成，督促各小组系统功能提交，及时发现各模块集成问题，起到各小组之间沟通的纽带作用；测试人员2名，对集成的版本进行测试，尽可能的发现程序缺陷，以及未满足需求的设计；文档整理人员1名，负责对将各小组内产生的文档进行整合、统一；维护人员1名，系统验收后维护系统，建议维护人员早期进入项目，参与系统测试，以便顺利承担起系统维护责任。

在人员的管理方面，一方面要求项目组成员相对稳定，以保证开发工作的连续性；另一方面，不能够胜任工作的坚决调换，保证项目整体工作不受影响。

通过平常和阶段性的工作考核、评价，对不合格人员进行调换。

有一名需求分析人员因为工作态度不好，与客户单位的业务人员关系恶化，调查属实后，我们立即把他调出项目组。

四、进行风险评估，在进度和质量之间进行权衡，争取最佳平衡点。

由于项目资金已经确定，我就在进度和质量之间找平衡点，力争把风险降到最低。

由于业务流程不是很规范，系统需求也在不断调整、完善，给项目的进度带来一定影响。

由于这个项目涉及到提高服务质量和社会信誉的问题，影响很大，通过与业务部门领导沟通，取得了他们的有力支持，在质量和进度之间优先考虑质量。

同时，考虑到这个项目采用了增量开发模型和模块化的设计方法，我把项目目标进行了分解，涉及到业务经办的部分优先完成，保证系统在规定的时间上线运行，其它不影响业务经办的、辅助性的功能适当延期，这样虽然整体工期有所延长，但没有影响系统及时上线。

这种做法同时照顾到各方的利益，把整体风险降到了最低。

五、强化测试，保证软件功能完整、正确、高效。

质量是软件的生命，软件功能完整、正确、高效是软件质量的重要组成部分，也是用户最关心的内容。

测试是查找软件错误的重要手段，也是让用户直观地了解软件质量和熟悉软件操作的有效途径。

我有计划地强化测试环节，让用户由始至终地参与测试工作。

我们主要采取黑盒法进行测试，把工作重点放在测试用例的准备上，严格定义测试索引、测试环境、测试输入、预期结果、评价标准，尽可能的把各种业务的不同情况都表现出来。

同时，我们选择了一个二级分行进行实际运行测试，让该分行手工调帐和计算机联网调帐同时进行，并有计划地穿插一些测试用例。

通过这些办法，及时发现和解决了许多问题。

不足与展望
调帐系统目前仍稳定运行，对业务系统的正常运行起到了巨大的支持作用，并获得了总行评定的科技进步三等奖。

但回顾过去，确也可以发现许多不足之处。

风险管理关系到项目管理的各个方面，比如沟通管理，如果我们把设计和开发工作合并，由一人来完成，减去了软件开发中最喧嚣的最容易出错的沟通渠道，这样的沟通最完美。

等等都是我们需要汲取经验的地方。

在以后的工作中，我将继续努力学习、总结经验，继续为我国金融业的信息化建设尽自己的绵薄之力。

3800字。