明天考试了

明天，对，就是明天，2008年１２月２１日，我就要参加系统分析师考试去了，到现在论文还没谱呢，真是的。
５月份的论文就差５分没过，１２月份还要从头再来，还要考３场，你说气人不？没办法呀，谁让咱是弱势群体来着。
今年我还真参与了一个项目，就是XX市的《住房公积金管理信息系统》，
下面就写一写这个项目，以下的文字是备考的习作，不能认为是事实本身。这一点还请各位看官注意，呵呵。

摘要：

本文介绍了我所在的某商业银行省分行和某市公积金管理中心协作开发的《住房公积金管理信息系统》。在研发该系统的过程中，我作为项目的主要负责人，参与了需求分析，系统设计和部分编码工作。从整体上看，项目从2008年2月开始，历时半年，取得了预期的效果，为我行的对公，对私存款带来了十分积极的影响，同时也提高了我行在当地同业的知名度。

 

正文：
2008年2月，我所在的某商业银行省分行信息科技部受行里委托，同当地的公积金管理中心合作开发了《住房公积金管理信息系统》，为了达到快速开发的目的，双方没有在自己的核心系统上通过升级的方式研发系统，而是在各自的核心系统外围开发了这个系统，实现了客户在银行柜面可以支取自己的公积金贷款，可以进行 还款，银行批量扣款，担保企业还款等功能。系统的开发由北京XX公司和我行科技部门协同开发，各自负责自己的功能，相互之间的通讯则是通过一组定义好的接 口来实现，有些交易是公积金管理中心发起，比如贷款发放等，有些交易是由银行发起的，比如银行请求公积金个人还款明细。在研发过程中遇到的问题主要是：
１。公积金中心的需求变化无常，今天说这个是必须的，明天就说可有可无了，今天说这些就是所有的需求了，明天又增加了好几个新需求。感觉他们自己都没搞清楚想要些什么，就以拍脑袋的方式提起需求来了。深感政府项目的难于把握和处理。
２。 XX公司的测试思路我们很难认同,该公司只派一个人和我们整个开发团队测试，每次只测一个交易，这个交易如果测试不成功，多半是由于该公司的程序问题，我 们整个团队就得等他一个人排错，其他交易一概不测，这样的测试流程和步骤，使测试进度一再拖延，以致整个项目的验收日期一拖再拖。给双方的管理层带来了很 多压力和麻烦。最后迫于公积金管理中心领导的压力，该公司才多派了3个人和我们一起测试，而且是至少3个交易一起测，使大家的工作并行起来，而不是像之前 那样，若干人闲着没事做。
３。公积金中心在数据质量上不过关，造成很多不必要的劳动。数据质量的问题是项目初始研发阶段没有发现的问题，应该算作 一种风险，可怕的是这种风险从一开始就没有被发现，更不用说采取措施规避这个风险了，所以到最后投产了，才暴露出来，那么后果可想而知，当然是带来了巨大 的损失，特别是给银行我行的运维部门增加了大量的无谓劳动，作为研发部门的我们也难逃被责怪的厄运。
４。我部门和公积金中心业务人员在一些概念上 没有形成统一认识。影响了研发的进度。比如联动交易，这个概念在软件开发人员看来意思是一个交易完成后，自动触发另一个交易，但是公积金中心的业务人员却 不是这么认为的，他们的理解是：一个交易发出后，可以立即得到返回的处理后的结果。如果不是我注意到业务人员的很多概念需要和技术人员一一确认的话，很可 能最终的产品不是业务人员需要的软件，而是一个没有任何商业价值的垃圾软件。

当然，针对这些问题，我们也不是坐以待毙，我们结合以前的项目经验，深入分析了这个项目的特点，提出了几个研发原则：
1。搞清楚系统业务需求之前 ，不做系统设计。
2。强化项目的范围管理，和对方就项目的范围做深入，细致，甚至是钻牛角尖一样的讨论，力争给项目的开发画一个完整的圈。
3。明确双方的职责。确保不出现双方都漏掉的需求。