源代码管理规范

代码管理制度TOC\o"1-5"\h\z\u1 总则 22 源代码完整性保障 23 源代码的授权访问 24 代码版本管理 35 源代码复制和传播 46 系统测试验收流程 56.1 系统初验 56.2 试运行 56.3 系统终验 56.4 系统验收标准 66.5 文档评审通过标准 76.6 确认测试通过标准 76.7 系统试运行通过标准 7

总则1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。3、源代码直接控制管理部门为技术开发部。4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。源代码完整性保障1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。源代码的授权访问1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。系统测试验收流程严格执行代码管理流程。对于开发完成的系统进行测试发布。测试发布流程如下：系统初验系统初验由技术开发部进行单项测试，系统进行联调测试无误后，由开发部编制项目测试报告，提交测试报告给汇测试部审核，完成系统初验。试运行本系统集成后上线运行三个月为试运行期。由公司技术人员现场排除系统试运行过程中出现的硬件故障及软件故障，对于易出现问题的设备提供备用件。技术人员随时解答业务人员在使用过程中出现的问题并进行解决。系统终验正式验收主要围绕设备的配置、功能、性能及各项技术参数指标进行，完成用户整体的系统验收。当整个系统进入试运行期，技术开发部提供行之有效的技术支持以确保整个业务的稳定和有效地运营，并确保整个业务能够顺利通过系统验收。在此同时，技术开发部将通过具体的技术支持帮助汇运维操作人员熟悉和掌握这些设备和维护技术。系统试运行期是一个非常重要的时期。在此期间，由于运维技术人员的技术水平、设备管理、设备操作和具体设备维护之间的磨合，将会出现许多意想不到的问题和人为故障。因此在系统试运行期，技术开发人员需配合运维人员提出的要求提供必要的现场技术支持，同时通过定期维护以避免设备故障的发生。在通过系统试运行的情况下，技术开发的项目小组将和业务运营人员以及运维人员进行系统终验。系统调试、验收程序：验收采取过程中定期抽检、全检，最后实行总体验收的方法进行。程序为报告申请验收，各有关单位会同验收，最后会签认同。参见下图：YesYesNoYes施工位自检用户初检报请各有关单位会同验收返工、整改通过申请No通过系统验收将由验收小组进行，验收时做好记录，签署验收证书，并立档、归档。当验收不合格时，技术人员需无条件进行返修。系统的安装验收主要有以下内容：（1）系统设备器材清单明细以及随设备包装的各种附件、资料等是否齐全；（2）各主要设备器材的外观评估与内在技术指标确认；（3）系统安装整体外观效果评估；（3）各系统工程各相关技术文件、现场检查验收记录等是否齐全；（4）系统的安装客观测试；（5）系统的工程安装验收将按用户需求进行。系统验收标准项目的验收工作包括两个方面的活动：文档评审和软件产品包的测试与试运行检验，对于不同的验收活动制定不同的验收通过标准。衡量被评审文档或被测试软件产品质量的一个重要指标是：评审或测试发现的缺陷数。为进一步明确文档或软件产品的质量水平，需要对发现的缺陷按其严重程度进行分类，在本项目中，将对缺陷分为四个等级，如下表所示：严重等级分类的解释严重的缺陷对进度的影响可能是非常致命的，或者可能是一个停止器——即终止用户继续使用系统主要的相同类型的缺陷在很多程序或模块中出现，需要改正每一个缺陷。例如，在任一程序中没有遵守编程标准。或者，缺陷终止了用户按正常方式继续前进，但可以绕行次要的这个缺陷是独立的缺陷，或者不影响用户继续前进，但会带来不便普通的缺陷并不影响软件产品的性能，例如，美观问题和消息中的语法错误等文档评审通过标准按照评审对象的规模（页数），根据评审投入的工作量和发现的缺陷数来确定是否通过评审：评审投入的工作量（评审准备和评审会议的时间）：是否在一个合理的范围内，如果投入的评审时间过低，则不论发现的缺陷数如何，都不能通过评审。发现的陷数：是否在一个合理的范围内，如果发现的缺陷数太多，则不能通过评审。如果发现的缺陷数低于合理的水平，则需要分析评审过程和评审人员，以便确定是否通过评审。确认测试通过标准对软件产品包的确认测试，根据测试用例质量、执行测试用例情况和发现的缺陷数来确定是否通过确认测试：测试用例质量：是否通过评审，如果测试用例没有通过评审，则不能进入确认测试过程。测试用例的执行：确认测试过程必须保证执行了所有的确认测试用例数据，测试结果得到真实记录。发现的陷数：与以前阶段成果评审、软件产品的集成测试和系统测试所发现的缺陷数相比，是否在一个合理的范围内。一般而言，确认测试阶段发现的缺陷数应与确认测试前所有质量控制活动所发现的缺陷总数相比，应在5%至10%之间，并且不应该发现严重的缺陷。系统试运行通过标准对软件产品包的试运行检验，其通过标