(论4)CMM在银行软件中的应用

 

我在某银行的软件开发科室工作，长期从事商业银行中间业务应用的开发。在以往的中间业务产品开发过程中，存在需求不明确；开发人员有章不循，依靠个人的智慧，开发处于低水平的重复状态；项目的进度，质量管理难以保证等问题。

我们从2001年底开始着手解决中间业务产品的整合和综合发展问题，经过项目分析和论证，我们提出了要开发一套具有良好扩展性，通用的中间业务平台系统。为了避免在新平太的开发过程中继续出现上述问题，作为该项目的主要负责人，我在中间业务开发团队引入了CMM，并采取了一些有效的策略和方法，主要包括：进行CMM培训和咨询工作，重新制定中间业务开发规范，作好需求管理，加强过程的跟踪和监督等。我们成功实施了银行中间业务软件过程的改进，开发了高质量的中间业务平台。CMM是全面持续的过程改进，笔者从定量过程管理和人员组织管理方面，提出了今后的努力方向。

[正文]

中间业务是指银行利用自己的网点，设备，网络，信息等优势，以中间人的身份接受客户委托，提供各类金融服务并收取相应手续费的业务。作为银行业务新的利润增长点及重要的吸收存款手段，中间业务正日益受到国内各商业银行的重视。近年来，我所在的银行根据业务发展的需要，通过陆续推出代发工资，代收电话费，代收水电费，代收学费，行政事业代收费等一系列代收代付的中间业务，在提高自身服务水平的同时，增强了在同业中的 竞争能力。

一．中间业务开发过程中存在的问题

随着中间业务品种的增多和市场对中间业务要求的提高，中间业务系统越来越庞大和复杂，尽管我们的中间业务开发团队中不乏技术过硬的开发人员，还是经常出现项目不能按时完成；新的中间业务项目上线时，软件的质量不理想的问题，其中包括一些明显的错误，如克服不能交费，重复扣或少扣客户的费用，客户交费后打印不了发票等等。而且文档不齐全，造成维护比较困难，作为中间业务开发团队的主要负责人，我召集了几名技术骨干总结了以往的经验教训，找出了存在的一些主要问题

1． 随意性决策较多

往往软件产品从立项阶段开始就成了“实验田”，软件产品做与不做，什么时候交付等多是凭个人的主观意愿，没有参考以往经验，也没有充分考虑资源的有效投入，导致开发的产品维护成本较高，打补丁现象较多，用户使用不方便。

2． 有章不循

尽管我们科技部门比较注重规章制度的建设，也针对软件开发过程制定了大量的程序性文件，但由于没有严格的后续跟踪与监督机制，使软件开发的质量控制大大责扣。

3． 依赖个人智慧

我们开发团队中不乏一些具有相当才干的项目经理和骨干人员，他们为研发银行软件产品作出了较大贡献。然而，由于他们的经验没有被很好的总结，归纳，并上升为整个开发团队的财富，致使有的项目负责人一走，开发质量就会下降，这说明软件产品的研发依赖与个人而不是团体。

4．“可视性”低

软件开发过程不透明，上级不了解下面做什么，无法实时监控项目的进展，下面的开发人员“报喜不报忧”。由此导致产品缺陷被慢慢积累起来，等看到结果为时已晚。

二．应用CMM改进中间业务平台开发过程

由于传统的中间业务系统产品开发平台多样化，缺少统一规范，产品分散，功能不足，大大影响了开发效率并增加了维护难度。为解决传统中间业务开发模式存在的诸多问题，我们从2001年年底开始着手解决中间业务产品的整合和综合发展问题，经过项目分析和论证，我们提出了要开发一套具有良好扩展性，通用的中间业务平台系统。为了避免在新平台的开发过程中继续出现上述问题，作为该项目的主要负责人，我考虑在中间业务开发团队引入CMM，试图把个人的脑力劳动结果规范为有纪律的智力产品。

1． 培训与开发过程规范的制定

在项目启动前，我们请了一家知名的培训机构，培训了CMM的基础理论，并结合一些软件开发公司实施CMM的案例讲解，加深了团队成员对CMM的认识和对软件过程实行规范管理的理解和支持。

然后，我们分析开发部门已有的规章制度存在的问题和缺陷，重新制定了中间业务开发规范。

首先定义出软件开发中的主要过程，参考CMM并针对中间业务开发的实际需要，确定了每个过程的具体工作内容。

其次确定了软件开发的具体方法，我们确立了面向对象的开发方法，并对每个开发过程定义了相应的具体文挡，如系统计划阶段必须提交《系统开发计划》，需求分析阶段必须提交《软件需求规格说明书》。并定义了文挡的格式和必须提交的内容。

最后，对每个过程划分相应的人员职责，即按照工作要求，进行人员分工，并确定具体的工作内容。

2． 努力作好需求管理

在银行的软件研发过程中，需求管理是一个老大难的问题。技术部门抱怨业务部门提出的需求不清晰，甚至提不出需求；业务部门抱怨技术部门对需求的理解有偏差，开发的产品和初衷相去甚远。从CMM的角度来说，业务部门提出的需求只是顾客的需求，而在顾客需求中既有技术层面，也有非技术层面的，即使是技术层面的需求，也并非面面具到都要开发，例如一些技术上不可行的或者资源要求不能满足的需求就必须剔除。只有适合软件产品研发的需求才会被最终制作成规格说明。

在中间业务平台需求的制定过程中，我采取了以下措施：

（1）       组成业务部门与技术部门共同参与的需求组，需求提出后经过上级领导的评审和业务部门确认才实施开发。

（2）       制定技术部门必须和业务部门商定需求变更管理流程和跟踪监督机制，需求变更如何提出，由谁进行评审，由谁决定做还是不做，对项目进度以及对资源的影响如何等都应事先考虑。

3． 加强过程的跟踪和监控

在软件开发过程中，我们按照软件开发过程规范严格实施。在项目启动的初期，开发人员要花很大的一部分时间写文档资料，工作压力比以前大多了。工作流程的改变，也导致一段时间内效率降低。大家逐渐习惯后，感觉文档是研发人员劳动成果最好的记录，工作比以前清晰，规范的文档减少了对个人的依赖，使软件开发过程的上下环节紧密衔接。在整个过程中，我们得到了所有的文档，并根据文档的内容对每个过程进行了检查。在进度控制方面，我首先制定了系统开发计划，要求开发人员填写工作量周报，并根据这个绘制项目进度图，随时了解项目进展，并适当调配人手，整个项目比计划略早完成。

在质量保证方面，银行软件产品质量对业务的开展尤为重要，她涉及银行的资金的安全和自身信誉，因此必须确保软件开发产品质量。现在我国各银行并没有成立单独的质量保证机构，对质量的控制主要掌握在项目研发人员手中，为此CMM建议成立专门的SQA小组，让测试小组兼做SQA工作，对项目组的监督“对事不对人”，并定期公布监督结果。

三．经验和不组之处

经过近一年的工作，我们完成了中间业务的开发，新的中间业务平台运行良好，受到了业务部门和技术部门高层的赞许。在该项目的开发中，由于引进了CMM，加强了软件过程管理，很好的解决了以前存在的4个问题。中间业务产品的开发目标更明确，提高了产品开发过程的可视性和可控性，从而在提高产品开发能力的同时提高了产品的的质量，我的开发管理水平也得到了很大的提升。高层领导尤其对我们的开发流程和开发规范表示认可，并决定在整个开发部门推广。我将这次软件过程改进的成功实践归功于2个原因：一是基于我们在长期中间业务开发基础上总结出来的经验和教训，二是CMM原则与我们团队和项目本身的特点的有效结合。

然而，由于我们初次应用CMM，还有很多需要改进的地方：

1）            我们仅运用了CMM的基本原则，整个软件过程的管理基本是定性的。过程改进的趋势是定量管理，必须采用合适的工具，如采用项目管理工具MICROSOFT PROJECT控制项目进度，使用RATIONAL ROSE对需求分析和系统设计进行辅助设计，可预测和监控整个过程性能和产品质量，及时纠正偏差。

2）            鉴于人手的问题，我们的团队成员往往身兼设计开发测试和SQA数职，组织结构不合理。人员分工不清显然制约了过程改进的实施，我们最近打算成立一个独立与开发部的质量控制部，分清设计测试和质量保证的责任。界限和权限，使其在更高的层次上控制软件质量。

 

软件过程改进是一个很大的课题和实践方向，在今后的工作中，我们将争取向CMM更高的级别努力。