银保通项目顺利结束了。我们项目管理科参与了项目的需求分析和质量保证工作，虽然在项目过程中遇到了一些挫折，比如需求的变更、蔓延，软件缺陷的跟踪等等，但是也有很多宝贵的经验值得我们学习。现将我的个人感受总结如下。
一、需求的提出。
需求是一切系统设计开发工作的出发点和落脚点。虽然需求分析是一个反复迭代的过程，但是，最起码应该分为两个阶段。第一个阶段应该是由业务部门主导提出业务需求，即根据业务上的需要，在结合本组织的业务流程和机构设置，提出的需求。业务需求是完全从业务的角度出发的，很少设计系统技术方面的知识，这个阶段主要是明确“想要做什么”，应该是由业务部门主导来完成的，系统分析师主要工作是配合、引导业务人员，明确业务的显性需求，挖掘业务的隐性需求。第二个阶段是由业务部门与系统分析师共同理解业务需求，明确软件需求。业务人员通过第一阶段提出“想要做什么”，明确了业务范围，分析师结合本组织IT系统框架，首先把超出系统范围的需求点剔除。接着，在系统功能范围内，根据需求点的优先级和项目的成本进度，与业务部门一起协商，将优先级较低、成本进度影响较大的需求点做相应的变更处理。最后，双方达成共识，将所有的业务需求点映射到系统功能需求点，形成软件需求规格说明书。总的来讲，系统分析师不应主导业务需求，但有否决业务需求点的权力。
二、项目管理科在业务测试的时候应该发挥主动。
从某种意义来讲，业务测试是把软件质量的最后一关，对软件的质量负有直接责任，理应由业务部门来主导，技术部门配合。但是，由于业务部门对新系统的理解程度有限，测试案例存在不规范，覆盖面不够的现象。从软件质量保证的角度出发，技术部门应该审核测试案例的规范和覆盖程度，定位软件缺陷的性质，跟踪软件缺陷的解决情况，保证测试流程按照规范进行，评估软件的质量。这就决定了技术部门不应被动的配合业务部门测试。只有主动的规范测试流程，才能从根本上保证软件质量。再者，由于软件缺陷是必然存在的，在项目成本和进度的前提下，应该主动的对某些低优先级、高成本、影响进度的缺陷进行拒绝修改或推迟修改。
三、需求变更的控制
需求总是在变化。在测试过程中，业务人员往往会发现某些方面跟他当初想的有些出入，或者受到某些启发而萌生一些新的想法，于是要求需求变更，这是必然的，无法避免，只能加以引导和控制。需求的变更，一定会对系统的质量带来影响，首先我们要分析本次变更对系统设计、编码、测试各个方面的影响，接着评估影响的程度和修改的工作量以及本次变更带来的成本与进度的变更。然后将变更提交给变更委员会或上级领导审批。
四、源代码控制
如果程序员可以随意的修改测试版本的源代码，那么就像是在软件质量下面埋了一个地雷，随时都可以让前期所做的一切质量保证工作毁于一旦。要保证软件的质量，必须把软件的开发版本、测试版本与受控版本分离开来。每一次源代码的修改都只能在开发版本，修改之后提交测试版本进行测试，测试不通过打回开发版本修改，测试通过则提交受控版本，纳入基线管理。
