基于CMM的银行软件外包.docx
《基于CMM的银行软件外包.docx》由会员分享，可在线阅读，更多相关《基于CMM的银行软件外包.docx（7页珍藏版）》请在冰豆网上搜索。
基于CMM的银行软件外包
基于ＣＭＭ的银行软件外包
[摘要]随着国民经济的不断进展，银行业务与外部企业的联系愈来愈紧密。
为了节约本钱，解决人力资源窘境，提高核心竞争力，许多银行把软件项目慢慢由原先的自主开发转变成直接外包开发的方式，银行本身的技术人员也慢慢由开发转向项目治理。
本文从商业银行软件外包方面的状况动身，探讨了目前软件外包短处产生的缘故，分析了CMM和软件外包之间的联系，论述了构建基于CMM的银行软件外包方式，包括风险治理打算、研发人员培育、外包商选择与沟通、软件需求的标准性、项目进度监控、合同治理、系统平安治理等，以真正在风险可控的情形下取得外包收益。
[关键词]CMM；商业银行；软件外包
一、引言
随着我国金融市场的全面开放，银行业和刚进入中国的外资银行要博得竞争和必要的进展空间，必需要大力进展电子银行业务，而电子银行业务对信息技术及网络平安都有着极高要求，自行购买和搭建先进的IT系统，需要银行一次性投入巨额资金及人力，并承担高额的后续保护费用，因此，在以最小本钱追求最大收益的商业规那么下，银行往往选择将电子银行业务中的软件开发、信息处置、硬件保护等部份或全数外包给更为专业的第三方公司去做。
因此，将非核心业务进行外包便成为金融业提高竞争力的武器和宝贝。
IT外包将是金融行业的趋势，在新的市场划分之下，银行需要明确什么是银行的核心业务，非核心业务和不阻碍银行竞争力的东西要尽可能外包出去，这将会变成一种趋势。
专业机构预测显示，到2020年，中国银行业IT解决方案市场规模将达到亿人民币，2007-2020年的年复合增加率达到%。
而核心银行系统仍将是整个应用解决方案市场中最大的细分市场，2020年将占整体市场的%，规模超过24亿人民币，中国银行业IT外包效劳快速增加的市场契机将会显现。
二、银行软件外包实际存在的问题
目前，银行业软件项目外包模式由于缺乏专门部门进行治理，在治理上缺乏标准性，没有一套标准的外包治理流程，各个项目都是各自为政，标准不统一，容易造成治理上的混乱。
在项目招标、合同治理、项目治理、工程实施、测试和交付保护等活动中缺乏一套稳固、成熟的工作流程，对外包项目的治理缺少有效监控和治理，因此在外包项目的进度操纵、质量操纵、本钱操纵等方面存在较多问题，致使外包项目在投产后项目实际与预期存在较大差距。
在外包进程中，暴露出一些比较突出的问题。
1.对需求了解得不够充分。
不管是银行仍是软件公司，在项目的初期，常常存在需求分析不够完全、对项目的明白得不够全面、对开发进程中的困难估量不足等问题，从而引发对工作量的低估。
而银行方那么急于把产品开发出来或太高地估量了软件公司的开发能力，这些都会致使在项目开发的进程中不断地补充人员或造成项目的延期。
2.人员配备的问题，通常银行的技术人员相对不足。
由于负责项目开发的是软件公司，银行方往往会尽可能节省人力，操纵本方技术人员的参与。
如在某银行与C公司合作的中间业务项目中，软件公司共有7个人，而银行方的开发人员只有3个，除忙于应付软件公司的业务支持及本身需求的完善外，全然无暇顾及软件公司平台工具的开发，更不要说真正深切地向他们学习。
因此，若是条件许诺，银行方应该多安排人员参与，才可能在开发进程中更多地跟踪软件公司的开发工作，方便以后的二次开发及保护，即便条件有限，至少也要达到软件公司人员的70%。
3.公司开发人员的流动。
就目前来看，那个问题几乎是不可幸免的。
一方面软件公司本身人员的流动性就比较大，而且为了培育人员通常会在项目组中安排一些新人，这些新人业务比较生疏，不稳固性也较大；另一方面，软件公司可能同时做多个项目，因此，其人员往往也会常常发生变更，而每次变更都会对项目造成必然阻碍。
笔者从某银行与某软件公司的一次合作中发觉，公司参与项目的开发人员共有12个之多，其实正常情形下只有7个人维持常驻，由此可见公司的人员流动相对来讲仍是比较大的。
与此相反，银行方那么除因人员不足而增加人员外，相对仍是比较稳固。
因此，在人员流动上银行方面只有事前做出估量，并在合同上注明，才能在往后的合作中争取主动。
4.银行技术人员在技术上预备不够充分。
长期以来银行技术人员适应于独立开发，利用传统的开发工具，因此，不可能专门快地适应最新的开发方式与开发工具。
这就要求银行应该按时地对开发人员进行知识更新，银行技术人员也要不断地踊跃自我更新，以适应不断进展的技术要求。
5.过量地把注意力集中在价钱上。
在商务谈判进程中，很多软件公司为了能够拿到项目、介入银行领域，会开出很多优惠条件或想方设法地降低价钱，却轻忽了其他方面的因素，这往往会给以后项目的实施带来许多困难。
因此，良好的效劳、丰硕的体会、成熟的技术、保质保量按时地完成任务，应该成为银行选择软件公司优先考虑的因素。
6.不断的需求变更。
由于银行本身的业务在不断地进展，若是开发周期太长那么不断地会有新的业务需求增加，或是原先业务需求上的缺点，造成在项目开发的进程中不断地变更需求。
这关于由银行自己的开发人员完成的项目来讲问题不是太大，可是关于外包项目来讲，就存在与软件公司如何进行沟通，如何协商解决的问题。
银行方面最好是在商务谈判时进行必要的约定，以避免造成开发中的不愉快或被动。
7.治理方面的问题。
一样说来，软件公司在开发方面是比较自由的，一样是给定任务在规定的时刻内完成即可。
而在银行方面那么有比较严格的作息要求，这就会造成工作时刻的不同步，严峻的话会阻碍项目的进度。
因此，银行方面最好是在合同中要求把软件公司的治理纳入银行项目的统一治理，如此才能有效地保证项目的进度。
8.轻忽业务人员的作用。
由于银行的技术人员一样都对业务比较熟悉，他们对业务人员的业务支持要求不是很高，只是作为一个必要补充。
在实际开发中，若是安排熟悉业务的骨干业务成员参与整个开发进程，直接参与同软件公司的讨论，那么会补充银行本身的技术人员的不足，并可大大提高开发效率。
9.项目后期对保密及系统平安的限制的松懈。
安满是银行取信于客户的关键，除资产平安，信息平安日趋成为银行风险治理不可或缺的重要环节。
软件研发外包后，外部人员参与了银行技术平台的搭建，可能会致使银行应用系统平安性的降低。
银行在与软件公司合作的进程中必然要注意平安保密。
10.技术文档不齐或不标准。
由于银行在商务谈判时一样无法界定所有文档的明细，专门是关于那些只有利用权的软件的开发工具代码和业务代码，在开发的前期都难以确信，以至于在产品交付时部份代码无法有效地交付，无益于以后的二次开发和保护。
因此，产品选择时银行应尽可能寻觅成熟的产品或有良好信誉的软件公司。
11.目前，国内IT外包市场尚不成熟。
Gartner信息技术效劳首席分析师RolfJester在亚太IT效劳高级研讨会上指出，中国的IT效劳市场仍不够成熟，大约50%的1T效劳合同是以不能让用户中意的方式提交的。
国内IT外包市场的不成熟要紧体此刻：
缺乏对产品、价钱、效劳方式和效劳水平的行业标准；尚未建设起完善的信誉治理体系；相关法律、法规不完善；当IT外包中显现效劳不到位，效劳质量、数据平安无法保证等问题时，在追究外包商的责任方面缺乏合理的依据。
这些都将阻碍银行软件研发外包的进程。
还有许多因素会阻碍合作项目的进度，如公司的技术核心集中在一两个骨干身上，许多情形都必需通过这些人来处置，这也会成为项目开发进度的瓶颈；业务需求不完善或不明确，技术人员不能不在开发进程中花大量的精力来完善业务需求；商务谈判时刻太长，拖延软件公司技术人员对项目的介入；软件公司技术人员对业务的介入太晚，阻碍公司优势的发挥；银行方新手太多，业务不熟，对合作项目中的困难估量不足等等，均会阻碍项目进度，银行可依照不同的情形具体进行处置。
三、CMM与软件外包之间的关系
CMM，即能力成熟度模型，指一个软件开发组织或某开发项目有效地概念、执行、治理、测量和操纵其各类软件进程的综合能力高低的一种气宇尺度。
这种综合能力通过测量该组织各类软件进程能力来进行气宇，是一种软件进程操纵和评估框架，它列出了每一个级别需要完成的目标和判定条件，但并无表达如何实现这些目标。
软件开发进程框架工具的目标确实是为开发团队成立一个清楚的、可重复执行的流程，以帮忙团队成员按时完成项目各时期的工作。
CMM是由美国卡内基—梅隆软件工程学院所确立的针对软件开发、系统工程、软件采购等软件工程方面的一套专门的质量治理体系，在国外各军用、大型民用软件工程、项目治理中被普遍应用。
模型的成熟度理论要紧涉及对软件进程的概念治理和如何气宇、治理、改良这些进程，和对软件组织和各类资源的治理，同时还包括对软件进程中利用的开发工具和技术的治理。
CMM将软件开发机构的能力按其软件开发进程完善程度分为五个成熟度级别来表示，从一级到五级水平慢慢提高。
该模型描述了每一个品级软件开发进程的大体特点，并明确说明二级以上各个级别不同的关键进程域，仅当一个级别的相应关键实践都取得适当的实施，才算达到了该级水平。
将每一个成熟度级别分为多个关键进程域，将每一个关键进程域分为五个一起特点。
一起特点包括关键实践，当这些关键实践取得实现时，就完成了该关键进程域的目标。
其中第2级可重复级成立了大体的项目治理进程来跟踪费用、进度和软件项目特性。
制定了必要的软件项目监督进程纪律，能重复早先软件合同治理应用项目取得的成功。
CMM2中的“软件子合同治理”KPA涉及了软件外包治理问题，它规定了企业应如何治理软件开发业务和软件开发子合同。
可是，软件外包治理事实上涵盖了软件生命周期中的各个进程，任何一个软件外包进程都会涉及到需求治理、软件打算、质量治理、项目追踪、配置治理等内容，因此，不能孤立地看待CMM的软件子合同治理，而应该将其视为能将其他软件开发进程从公司内部部份或全数延伸到公司外部的治理标准与治理技术。
通过软件子合同治理进程的实施，软件开发机构能够有效地治理与操纵他们的业务分包进程。
外包（Outsourcing）是一个舶来词，亦可译为“资源外包”或“业务外包”。
外包思想始于20世纪80年代末期的美国。
严格地说，外包是一种治理策略，它是指企业专注核心业务能力而把部份业务，专门是把与信息技术的相关业务承包给外部专业的、高效的信息技术效劳商。
软件外包的推动力一方面来自企业减少信息技术风险取得经济效益的要求，另一方面那么来自于企业利用信息技术改造业务流程，进行组织创新，制造更多利润的要求。
从CMM的“软件子合同治理”KPA开始实施软件外包治理是比较好的方法。
CMM模型概念了软件子合同治理要达到的目标、实施时必需履行的许诺和需要具有的能力，概念了进行软件子合同治理应该进行的活动。
CMM软件能力成熟度模型对软件项目外包进行治理能够使银行将更多的精力专著于项目进程中的关键进程域，通过对关键进程域的分析，找出在项目治理进程中存在的差距，然后对项目进程进行改良，将项目进程标准化、程序化，更有利于组织重复过去的成功体会，不断提高企业的项目治理水平。
通过CMM软件能力成熟度模型对银行业软件外包项目的治理流程进行优化后，能够使银行尽快摆脱目前掉队的治理模式，加倍注重软件外包项目的流程治理，通过制定适合于银行的软件外包项目标准，有效提升银行业对软件项目外包的治理水平，更好的与软件外包公司进行合作，提高软件外包项目的产品质量。
四、构建基于CMM的银行软件外包治理方式
银行要想在风险可控的情形下取得外包收益，必需强化自身外包治理能力，提高自己的项目治理水平，重点做好以下几个方面的工作。
1.制订一个包括风险治理的治理打算。
外包就仿佛自行开发一样，一样需要制订一个治理打算。
在打算中应该包括：
供给商选择、合同洽谈、开发需求、操纵需求转变、跟踪供给商进度、监督质量、已审核交付的产品是不是知足需求等。
能够与所选择的供给商一路制订这些治理打算。
2.要增强研发人员职业生涯打算与人材培育。
对研发人员进行项目治理、外包治理、系统架构、信息打算、信息平安等方面具有针对性的培训，使研发人员适应职位角色的转变，从软件设计人员转变成项目领导、系统架构师、系统分析师、关系领导等，同时，引进项目完全外包所急需的法律人材。
将软件系统外包开发，银行往往会以为负责项目开发的是软件公司，于是尽可能节省人力，降低本钱，操纵本方技术、业务人员的参与。
而事实上，作为建设单位，银行不能对开发工程放任自流，漠不关心，而要踊跃参与到项目的开发进程中，对软件工程进行进程化治理，才能保证软件的质量。
若是条件许诺，银行应该多安排人员参与，才可能在开发进程中更多地跟踪软件公司的开发工作，方便以后的二次开发及保护。
同时，软件外包开发后，银行本身的技术人员慢慢由开发转向开发与项目治理并重。
银行技术人员不但要学习最新的开发方式与开发工具，同时要把握必然的项目治理知识。
而长期以来，银行技术人员适应于独立开发和利用传统的开发工具，这就要求银行必需按时对开发人员进行知识更新。
银行技术人员也应不断地更新知识，以适应不断进展的技术要求。
3.依照项目复杂程度与内部能力，将研发项目通过外包、主题专家、顾问、自主研发等方式展开。
成立专门的技术研究团队，从事新技术与银行业务有效结合的研究工作，增强与咨询公司的合作。
4.选择适合的外包商，增强对外包商的治理与沟通。
谨慎选择外包效劳商能够降低部份风险，但不同的运行机制和企业文化也会增加整个外包进程的风险。
对这些风险的治理除要求银行与IT厂商间有专门好的合作机制、彼此信任之外，银行必需保证对整个外包项目具有决策和操纵权，确立“以银行为主”的方针。
同时，应付IT厂商进行整体评判，不仅看其现有产品，而且要通过对厂商的整体实力、资信品级的评估，确认厂商具有良好的进展前景，要有适当的评判和监测手腕，商业利益分派也应尽可能合理。
在项目招标中，尽可能选择实力壮大、信誉良好的公司。
在项目外包的进程中要主动与供给商进行沟通，即便感觉与供给商没什么能够沟通时也要按期地与他们沟通。
一些IT项目采纳“走动的方式”进行治理，当采纳外包时，就应该考虑采纳打或互换电子邮件的方式来治理。
5.软件的需求必需标准明确，避免频繁变更。
软件需求是软件产品开发的依据，也是整个开发进程各项活动的基础。
在实际开发中，往往由于软件需求的不明确和频繁的变更，给项目开发带来没必要要的麻烦，造成人、财、物的浪费，最后致使项目的失败。
在明确软件需求之前，银行必需先对项目的需求、资源、工期、质量等要素及彼此之间的平稳关系有整体的把握。
需求规定了系统的范围和规模，资源决定了项目的投入，工期概念了项目的交付日期，质量概念了完成系统的好坏。
这四个要素之间是有平稳制约关系的，作为银行的项目治理人员，必需统筹考虑，抓住重点。
第二，系统的业务需求多数来源于业务人员，其对需求的描述往往含糊不清，加上业务部门和相关人员对需求分析的熟悉超级浅薄，需求既不标准又不具体，而外包开发商往往对银行的具体业务缺乏足够的了解，因此在项目初期，银行项目治理人员需要主动和谐业务部门、外包商及各方面的关系，通过需求分析等形式为外包商成立信息交流、沟通的渠道，保证对话渠道的畅通，促使外包商深切了解银行的业务需求。
理想的方法是由银行方面熟悉业务的技术骨干会同公司方面体会丰硕的项目骨干一起完成对需求的分析，并有适当的业务人员参与，如此就能够对整个工作量做出相对照较准确的估量，即便多花点时刻也是值得的，需求分析越完全越好。
另外，还要完成软件需求分析书，它是软件项目各方对项目的一起熟悉，是软件开发的基础，应该做到完整性、正确性、可行性、必要性和无二义性。
6.银行项目治理人员必需强化项目进度的监督操纵。
项目进度操纵的要紧方式是依据项目打算书中的开发进度表，检查工作功效和进展进度，确保项目里程碑的达到。
因此，里程碑的设置要尽可能符合实际，而且不轻易改变里程碑的时刻。
但在实际项目开发中，常常会显现项目的实施方案与打算相偏离的情形，破坏了原先的工作打算，致使时刻进度和工作质量都很难把握。
这时必然要和软件开发商及时沟通，了解变更的缘故，同时催促软件开发商调整打算，加大时刻和人力的投人，修正各项工作目标和任务，从头制定打算，赶上工作进度，并及时向各级领导汇报沟通。
项目的范围变更和业务需求的变更是阻碍项目进度的要紧因素，因此要严格操纵变更。
在项目开发进程中，会碰到业务需求不断增加和变更的情形，需要成立需求变更处置进程。
碰到需求变更情形，要及时召集业务人员、开发商和有关人员，对项目的需求变更所带来的潜在阻碍和可能的本钱费用进行评估。
在项目的后期和项目完成时刻不可更改时，要冻结需求，并取得业务部门的明白得，以保证项目按已确信的需求和确信的时刻完成，而需要新增的功能那么能够留待后一个版本。
7.增强合同治理。
外包合同是外包治理中最为重要的文档之一，是对外包效劳商进行有效操纵、降低外包风险的要紧手腕。
外包合同治理要紧涉及选择外包效劳商、制定外包合同、签署外包合同、更新或终止外包合一样事项。
银行与外包效劳商签定协议，通过监控和合规治理，爱惜自身利益。
8.做好外包软件的系统平安治理和文档编写工作。
在所有的外包合同中都应该包括保密条款。
风险治理的思想应体此刻所有的应用系统中。
在签定外包合同时，条款中也应明确与平安相关的责任与义务，明确规定保密条款、系统可用性指标，并要求外包效劳商制定灾备、应急处置等一系列方案。
银行的软件系统具有必然的特殊性，在与软件公司合作的进程中必然要注意平安保密。
例如，只提供与所开发的业务有关的文档；尽可能幸免利用真实的客户数据；对机械用户、网络路由进行严格操纵；当用软件公司的机械进行登录后，要及时地退出等等。
关于这些平安方法，合作两边往往在项目开始的时候都很容易遵守，可是，随着项目的进行或进展到项目的测试时期，由于彼此之间的熟悉及要处置的问题增多，对这方面的要求会有所松懈，银行要专门引发注意。
在项目开发的最后时期，银行的项目治理人员还需要催促开发商提供详细的、必需的文档资料，并组织对有关报告和文档资料进行评审，以确信产品的质量是不是达到了要求。
软件投入利用后，还需要对用户的反馈意见进行有效地跟踪治理和及时地答复，并及时改良。
五、终止语
总之，我国商业银行要想在竞争日趋猛烈的环境中生存下去，并利用信息技术采购更大的竞争优势，外包模式是我国商业银行信息系统开发的必然趋势。
软件外包是一种新兴的系统建设方式，其壮大的生命力不言而喻，商业银行作为信息技术的重要应用者必需踊跃利用它。
软件外包项目成功与否，外包治理能力相当重要，与软件企业相较，银行业在软件项目治理方面还存在一些差距。
目前，有些国内的软件企业已经通过CMM三级的认证，个别企业已经通过品级认证，这些企业在软件开发方面已经具有较高的项目治理水平。
银行尽管在项目实施进程中对软件开发只是起辅助作用，可是，作为成熟的企业应该在项目治理水平上成立一套标准的流程，因此，通过CMM软件能力成熟度模型提高银行业的软件治理水平，对银行外包软件项目的治理具有专门好的推动作用，从而不断向更高层次的能力成熟度进展。
参考文献：
——我国商业银行信息系统开发的新模式[J].中国金融电脑，2000，（4）.
[2]严咎.外包：
银行信息系统进展的必然[J].中国城乡金融报，2004，（4）.
[3]王铁山，郭根龙，冯宗宪.金融效劳外包的进展趋势与承接策略[J].国际经济合作，2007，（8）.
[4]邢彬彬，姚郑.CMM/CMMI与软件生命周期模型关系的研究[J].运算机应用研究，2007，（11）.
[5]霍英，陈志刚.面向小型软件企业/小型软件项目的CMM应用研究[J].运算机应用研究，2007，
（2）.
升级会员 