源代码管理规范

1、1 源代码管理 21.1 总则 21.2 源代码完整性保障 21.3 源代码的授权访问 31.4 代码版本管理 31.5 源代码复制和传播 51.6 系统测试验收流程 61.6.1 系统初验 61.6.2 试运行 61.6.3 系统终验 71.6.4 应用系统验收标准 91.6.5 文档评审通过标准 91.6.6 确认测试通过标准 101.6.7 系统试运行通过标准 101 代码管理1.1 总则1、为保障公司源代码和开发文档安全不至于泄露，保证源代码 的完整，明确源代码控制管理流程，特制定此管理办法。2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及 部门都必须严格执行本管理办法。3、源

2、代码直接控制管理部门为技术开发部。4、本办法管理重点在于控制管理源代码的完整性，不被非授权 获取，不被非授权复制和传播。5、本办法所指源代码不仅限于公司开发人员自行编写实现功能 的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运 行所必须具备的第三方软件、控件和其它支撑库等文件。1.2 源代码完整性保障1、所有软件的源代码文件及相应的开发设计文档均必须及时加 入到指定的源代码服务器中的指定库中。2、我们研发的产品软件运行所必须的第三方软件、控件和其它 支撑库等文件也必须及时加入源代码服务器中指定的库中。3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行

3、SVNUpdate操作。软件编码或功能调整结 束测试正确无误后，相应的源代码必须进行SVNCommi操作，在最终 进行SVNComm操作之前需要再进行SVNUpdat驛作，查看是否有冲 突产生，如果有冲突产生需要和冲突相关人一并解决冲突。1.3 源代码的授权访问1、源代码服务器对于共享的 SVN库的访问建立操作系统级的， 基于身份和口令的访问授权。第十条 在SVN库中设置用户，并为不同用户分配不同的，适合 工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及 其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可 写权。2、曾经涉及、触及源代码的计算机在转作它用，或者离开研

4、发 部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。 如果不能确定， 必须对计算机中所有硬盘进行全面格式化后方可以转 做它用或离开研发部门。1.4 代码版本管理1 、终端软件的版本标识管理 终端软件版本由终端型号、版本号和内部修订号来进行标识。 终端型号：终端型号是硬件标识号， 也唯一的标识了我们的项目。版本号：由“V主版本号 .V次版本号 .V修订号”三段组 成，中间是点号分开。版本号的目的主要是管理终端软件的对外发布， 终端软件的BUG的记录和统计，主要是针对于版本号的，测试部、 项目部、客户等会记录某个版本号的终端软件存在哪些BUG,BUG会在哪个版本号中得到修正；终端软件一

5、个新的版本号出来后，我 们会统计新的版本号解决了上一个版本号中的哪些BUG,以及增加了哪些新功能，等等。内部修订号：也就是“应用程序的源代码的 svn 修订号”，主要 是由软件部和测试部内部来使用， 内部修订号唯一标识我们的终端软 件，即：通过内部修订号能够唯一的找出我们发布的终端软件所对应 的全部软件源代码，目的是为了软件排错使用。另外，终端软件在发布时， 还会给出发布日期， 以便开发、 测试、 项目、客户等相关人员参考。2、终端软件版本发布管理终端软件主要是以版本号为基准， 对外发布， 目前采用不定时发 布策略，发布的时间由软件部、项目部和客户方根据情况，共同商量 决定。由于目前项目时间紧

6、，终端软件无法得到完整的测试就要发布， 在发布之后，有一些需要紧急需要修复的 BUG软件部需要紧急修复 后就要发布更新包， 以便用户能够使用， 所以，在一个版本号发布后， 需要进行多次修订，对于这些修订的版本，其版本号保持不变，内部 修订发生变化。软件BUG记录、管理和统计软件BUG的记录、管理和统计主要以版本号为基准， 但为了软 件开发人员能够找到BUG的出处， 需要用户、测试人员在报告和验 证BUG时，输入内部修订号。3、软件配置组对版本的记录 软件版本记录的目标有两个： 记录软件版本的发布历史；发布的每一个版本，都要能够唯一的从源代码库（SVN）中找 到对应的全部源代码。测试方案作为软件

7、开发的重要环节， 作为交付成功的优质的产品的重要保证手 段和方法， 软件测试越来越受到项目的重视。 要做好测试首先要做好 测试的组织、管理、计设、实施等工作。系统测试方案概述 测试是指在软件投入运行前， 对软件需求分析、 设计规格说明和编码 的最终复审，是软件质量保证的关键步骤。测试的目标：以较少的用例、 时间和人力找出软件中潜在的各种错误 和缺陷，以确保系统的质量。在实际项目中， 测试作为软件开发生命周期中的一个重要过程， 但从 其具体工作的前后过程来看， 它又是由一系列的不同测试所组成， 这 些测试的步骤分为：单元测试、集成测试（又称组装测试） 、确认测 试和系统测试。软件开发的过程是自顶

8、向下的，测试则正好相反，以 上这些过程就是自底向上，逐步集成的。在项目过程中，我们按以上 的测试步骤完成系统的测试。1.5 源代码复制和传播1、源代码向研发部门以外复制必须获得总经理的书面授权。并 必需记录复制人、批准人、复制时间、复制目的、文件流向、文件版 本或内容。2、源代码以任何介质形式进行存储的备份，必须由专人负责保 管。对于这些介质地借阅， 用于研发部内部使用的必须获得研发部经 理的授权，对于用于研发部以外使用的必须获得总经理的书面授权。3、源代码的借阅、复制必须进行详细的登记，必需记录借阅人、 批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时 间。4、任何纸质材料的借阅

9、都必需记录借阅人、批准人、借阅时间、 借阅目的、文件流向、文件版本或内容、归还时间。5、对于因合作需要，需要向外复制、传播、分发源代码的，不 论是全部还是部分代码和资料， 均必需和对方签订技术、 源码的保密 协定，明确对方应当承担的对源码保密的责任和义务。1.6 系统测试验收流程 贵州汇联通公司技术开发部分是外包给上海华腾公司完成， 严格 执行外包管理流程。 对于开发完成的系统进行测试验收。 测试验收流 程如下：1.6.1 系统初验 系统初验由华腾公司技术开发部进行单项测试， 系统进行联调测试无误后， 由华腾公司将编制项目测试报告， 提交测试报告给汇联通 公司审核，完成系统初验。1.6.2 试

10、运行 本系统集成后上线运行三个月为试运行期。 由华腾公司现场排除系统试运行过程中出现的硬件故障及软件 故障，对于易出现问题的设备提供备用件。华腾公司需提供热线电话， 为我公司使用过程中出现的问题进行 解决。华腾公司应我公司技术人员的要求，随时讲解系统的结构及设 计，包括硬件性能、系统软件、备份结构特点。1.6.3 系统终验正式验收主要围绕设备的配置、 功能、性能及各项技术参数指标 进行，完成用户整体的系统验收。当整个系统进入试运行期， 华腾公司需向我公司提供行之有效的 技术支持以确保整个业务的稳定和有效地运营， 并确保整个业务能够 顺利通过系统验收。 在此同时， 华腾公司将通过具体的技术支持帮

11、助 汇联通公司操作人员熟悉和掌握这些设备和维护技术。系统试运行期是一个非常重要的时期。 在此期间， 由于汇联通公 司技术人员的技术水平、 设备管理、 设备操作和具体设备维护之间的 磨合，将会出现许多意想不到的问题和人为故障。 因此在系统试运行 期，华腾公司需配合汇联通公司的要求提供必要的现场技术支持， 同 时通过定期维护以避免设备故障的发生。在通过系统试运行的情况下， 华腾公司项目小组将和汇联通公司 进行系统终验。系统调试、验收程序： 验收采取过程中定期抽检、 全检，最后实行总体验收的方法进行。 程序为报告申请验收，各有关单位会同验收，最后会签认同。参见下 图：验收结果必须交由双方共同确认有效

12、， 方可存档。双方各一份备系统验收将由验收小组进行，验收时做好记录，签署验收证书,并立档、归档。当验收不合格时，华腾公司需无条件进行返修。系统的安装验收主要有以下内容：（1）系统设备器材清单明细以及随设备包装的各种附件、资料 等是否齐全；（2）各主要设备器材的外观评估与内在技术指标确认；（3）系统安装整体外观效果评估；（3）各系统工程各相关技术文件、现场检查验收记录等是否齐 全；（4）系统的安装客观测试；（5）系统的工程安装验收将按用户需求进行。164系统验收标准项目的验收工作包括两个方面的活动： 文档评审和软件产品包的 测试与试运行检验，对于不同的验收活动制定不同的验收通过标准。衡量被评审文

13、档或被测试软件产品质量的一个重要指标是： 评审 或测试发现的缺陷数。为进一步明确文档或软件产品的质量水平，需 要对发现的缺陷按其严重程度进行分类， 在本项目中，将对缺陷分为 四个等级，如下表所示：严重等级分类的解释严重的缺陷对进度的影响可能是非常致命的，或者可能是一个停止器一一即终止用户继续使用系统主要的相同类型的缺陷在很多程序或模块中出现，需要改 正每一个缺陷。例如，在任一程序中没有遵守编程 标准。或者，缺陷终止了用户按正常方式继续前进， 但可以绕行次要的这个缺陷是独立的缺陷，或者不影响用户继续前进，但会带来不便普通的缺陷并不影响软件产品的性能，例如，美观问题和消息中的语法错误等165文档评

14、审通过标准按照评审对象的规模（页数），根据评审投入的工作量和发现的缺陷数来确定是否通过评审：评审投入的工作量（评审准备和评审会议的时间）：是否在一个 合理的范围内，如果投入的评审时间过低， 则不论发现的缺陷数如何， 都不能通过评审。发现的陷数：是否在一个合理的范围内， 如果发现的缺陷数太多， 则不能通过评审。 如果发现的缺陷数低于合理的水平， 则需要分析评 审过程和评审人员，以便确定是否通过评审。1.6.6 确认测试通过标准对软件产品包的确认测试， 根据测试用例质量、 执行测试用例情 况和发现的缺陷数来确定是否通过确认测试：测试用例质量： 是否通过评审，如果测试用例没有通过评审，则 不能进入确认测试过程。测试用例的执行： 确认测试过程必须保证执行了所有的确认测试 用例数据，测试结果得到真实记录。发现的陷数： 与以前阶段成果评审、 软件产品的集成测试和系统 测试所发现的缺陷数相比，是否在一个合理的范围内。一般而言，确 认测试阶段发现的缺陷数应