代码管理及规范
【网络公开版】
Solvay
2015年8月11日
目录
1.引序 (3)
2.目的 (5)
3.适用范围 (6)
4.svn规范及要求 (6)
4.1 SVN操作流程 (6)
4.2账号 (6)
4.3检出代码 (7)
4.4提交代码 (7)
4.5标注要求 (8)
4.6慎用锁定功能 (9)
4.7传统备份 (9)
4.8 创建个人文件夹 (9)
5.代码规范要求 (9)
5.1 项目层次结构规范 (9)
5.2页面规范 (10)
5.3样式规范 (10)
5.4 JavaScript代码规范 (11)
5.5类规范 (11)
5.6注释规范 (12)
5.7 SQL语名规范 (13)
5.8 排版 (14)
5.8.1 缩进 (14)
5.8.2 空行 (14)
6开发环境及辅助工具 (14)
6.1 jdk版本 (14)
6.2 环境变量 (15)
6.3开发使用IDE (15)
6.4运行容器 (17)
6.5其它工具 (18)
6.6终端环境兼容 (18)
7写在结尾 (19)
1.引序
开始前，举一个故事作为引子，使阅读者从客观上有个大概的了解。未必能准确客观反应，还请谅解。
三国刘备一次攻击曹军计划，诸葛亮【架构师】制定作战方案：刘备【独裁者】率少量人马引曹军深入埋伏；
张飞【程序猿A】刺探前方军情；
关羽【程序猿B】负责正面交战，拼杀一阵则撤退；
赵子龙【程序猿C】则围堵、追杀逃兵。
作战时，发生如下情况，张飞性格粗暴，在刺探军情时顺手斩了几个曹军士兵，惊动了曹军。刘备则想，我一国之君，诸葛小儿狂妄自大，竟令我去诱敌。而且风险很大，则私下交待赵子龙保护其安全。关羽在正面交战时，因为前面惊动了曹军，导致曹军有备而来，虽尽力但没及时撤退，待伤亡很严重时被迫逃窜。此时赵子龙却护送着刘备，围堵、追杀方案根本无法实施。
通过上述例子，能反应出如下：
张飞多写了不属于自己的代码，造成相关功能重复执行，轻者影响系统运行效率真，严重则造成不可逆错误；
刘备没遵循代码管理及版本控制要求，私改方案，并且没有与诸葛亮重新商讨、修改，而造成整体方案在前期就预
示夭折的结果；
关羽虽按方案痛苦的写着代码，但因其他成员的失误而举步维艰，在发现情况不对时，未采取补救措施；
赵子龙则追随刘备，参与了刘备私改方案的编码，造成与整个方案的脱离。
最后结果可想而知，刘备军队大败。
通过上面的故事，希望阅读者对代码管理及版本控制能有一个初步的认识，下面为版本控制的概念，摘录与网络，进行了少量的精简、修改。
所谓版本控制系统(Version Control System)，从狭义上来说，它是软件项目开发过程中用于储存我们所写的代码所有修订版本的软件，但事实上我们可以将任何对项目有帮助的文档交付版本控制系统进行管理。
如果在开发团队中没有使用版本控制，多个开发人员在开发过程中将会引入很多问题，如软件代码的一致性、软件内容的冗余、软件过程的事物性、软件开发过程中的并发性、软件源代码的安全性，以及软件的整合等问题。
版本控制的目的是实现开发团队并行开发、提高开发效率的基础。其目的在于对软件开发进程中文件或目录的发展过程提供有效的追踪手段，保证在需要时可回到旧的版本，避免文件的丢失、修改的丢失和相互覆盖。
版本控制的功能在于跟踪记录整个软件的开发过程，包括软件本身和相关文档，以便对不同阶段的软件及相关文档进行表示并进行差
别分析，对软件代码进行可撤消的修改，便于汇总不同开发人员所做的修改，辅助协调和管理软件开发团队。
版本控制在空间上可以保证完成集中统一管理，解决一致性和冗余问题。在开发工作中，开发人员在提交软件代码的时候一般采用服务器/客户端方式，尽管开发人员可以在自己的本地留有备份，但最终唯一有效的只有服务器端的程序代码；在时间上全程跟踪记录工具将会自动记录开发过程中的每个更改细节，和不同时期的不同版本。这在一定程度上可以解决冗余、事务性处理并发性问题。版本控制工具的使用，可以减轻开发人员的负担，节省时间，同时降低人为错误。
2.目的
为什么要花时间来写此文档？意义何在？会产生什么样的结果等等？一个个问号在我写此文档前期及写文档期间思考的问题，也许上面例子很大程度的阐述了代码管理及版本控制的重要性。
其实在一个无开发团队、萌芽开发团队或者独立编写代码的个体来讲，谈版本控制远远属于形而上学的事情，起初我个人也没意识到处于无代码规范及版本控制状态产生的后果及影响，随着编码时间推移加上之前所服务公司代码管理上的硬性要求，逐渐对版本控制有了阶梯式的认知。就如同在应用系统研发中对相关项目文档的书写一样，从无法下手到被迫了解、书写，再到客户对文档格式、内容质量要求的被动性提升，最后养成了在项目中文档先行的习惯，在提升自己对项目统筹管理的同时，也对自身来说受益匪浅。
首先申明，一个完善、良好的软件在世界上没有一个人打造出来的事情，软件研发世界中，没有一个人的帝国，只有帝国中的英雄。当然在现实软件世界中，存在唯心主义以及伪软件数不胜数，这种现象的存在和行业、国情等等息息相关，这里不做论证。要说明的是，既然团队开发，代码规范、版本管理则必不可缺。
3.适用范围
本规范文档适用于软件研发部门、项目成员、前、后端软件工程师、页面设计师等人员。
4.svn 规范及要求
4.1 SVN 操作流程
4.2账号
开发人员遵循一人一号原则，不得向他人透漏，严禁使用他人账
版本库 本地工作副本
户进行SVN各项操作。
4.3检出代码
不要检出整个代码根目录，除非特别必要情况，不应同时检出过多项目，如果检出多个项目，则应按项目为单位分次检出，并保存在不同目录下。多个项目不应同时存在一个目录或子目录中。
4.4提交代码
提交代码应严格遵守“先更新再提交”原则。
SVN更新的原则是要随时更新（SVN Update），随时提交（SVN Commit）。当完成了一个小功能，能够编译并且通过自己测试之后，谨慎地提交。
如果在修改的期间别人也更改了SVN的对应文件，那么Commit就可能会失败。如果别人和自己更改的是同一个文件，那么Update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。
在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。
不能提交与代码无关的文件及影响他人测试、运行的代码。例如Eclipse中的.classpath文件，Windows生成的缩略图Thumbs.db，
项目编译生成的临时文件.obj、 .class，测试功能的临时本机配置文件等。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文件后，别人在更新后就可能与本地的环境冲突从而影响大家的工作。
不能提交自己不明白的代码，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在自己写代码或引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。
不能别人未知情的情况下，强行替换、删除别人的代码。别人写的代码也是劳动成果，而且有可能与其它代码关联、交互，强行替换、删除会造成系统运行的稳定，同时造成对方迷惑。处于尊重、个人修养方面，也不应该未知情下这样操作。
4.5标注要求
每次提交必须书写明晰的标注。
提交空标注或者不确切的标注将会让项目组其他成员无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交代码时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。
4.6慎用锁定功能
要慎用锁定的功能，当你锁定了一个文件之后别人就无法继续修改提交该文件，虽然可以减少冲突的发生率，但是可能会影响项目组中其他人员的工作。平时只有在编辑那些无法合并的文件（例如图片文件，flash文件等）时，才适当的采用锁定操作。
4.7传统备份
在不能保证自己编写代码的有效性及正确性前，应做好之前的备份工作。虽然SVN可以回退到之前的版本，但为了减少意外，应做到针对性的备份，是一种良好的习惯。
4.8 创建个人文件夹
针对项目，项目参与人员创建以自己名称命名的目录，以统一保存在项目中产生的个人文档信息，如代码修改记录、原型调整说明等信息。其子目录应该日期为基准命名，以便日后查阅及其他人了解项目的变动情况。
5.代码规范要求
5.1 项目层次结构规范
项目层次结构为树形结构，在大中型项目中，相关模块的应独立出来为主根。主根下为项目的类子根、类资源子根、静态资源子根、
页面子根、测试子根、文档子根、SQL子根及其它文件子根等。
根层次顺序为：主根、子根、孙根、曾孙根……耳孙根等，依此类推。
5.2页面规范
此处页面范指视图展现层的所有页面。可以理解为静态页面、动态页面，也可以理解为HTML页面、JSP页面、PHP页面、ASPX页面、ASP页面等。
页面必须保证整洁、干净。整洁指排版格式的缩进层次分明，编码命名（命名规则请参考命名规则文档）一致。原则上页面对样式、脚本等附加文件的引入只允许出现一条，如果有多个文件需引入，则应将其封装在一个引导文件中，页面只需引入引导文件即可。
5.3样式规范
样式命名规范请参考命名规则文档。
使用CSS缩写
明确定义单位，除非值为0
区分大小写
取消class和id前的元素限定
优先级
导入(Import)和隐藏CSS
注释
5.4 JavaScript代码规范
此处脚本单指JavaScript（以下简称为JS）及其衍生产品，如项目中遇到其它脚本时，再做相应的补充、完善。
JS代码同样遵循高内聚、低耦合设计思路，一个功能应尽可以为一个文件形式保存，非独立功能则以功能模块节点、子节点、叶子为依附存在。
JS代码同样应标有详细的注释文字，其注释要求参考类注释规范，其中语言规范不同之处采用本语言规范即可。
5.5类规范
引入文件应分模块、组件，不同模块、组件之间应以空行分隔。
类编写格式排版应统一，命名空间在类文件第一行，引入类在其次，完后是类内容。
类内容中，常量、属性、构造器、方法依次排序，其中静态属性、静态方法优先级高于其它。
实体类应遵守JavaBeans规则。
类文件应尽量不出警告提示信息。
类文件中的内容应尽量单一、独立，不应将不同需求、不同功能等混杂在一个类文件中，应做到高内聚。
对类及其成员的设计及私有、继承、开放特征则严格把控，一切遵循面向对象原则，设计应基于自然学科。如设计一体现猫的类，其应将猫的属性特征，所拥有的功能设计完整，但不要出现不属于猫的
属性特征或功能。比如猫类中出现CPU属性或刹车方法，这是严重不合乎事物特征也不符合逻辑的设计方法。
抽象的精准、完整化。在进行抽象设计时，应精确的抽取共同体特征，切记不要过度抽象，那样失去了抽象的意义。
每个类必须有与之对应的测试类。
5.6注释规范
类或文件注释：
类文件注释要求放在类定义起始行之上，与类定义起始行紧挨。如下图：
属性注释：
属性注释应该对私有自身及GET、SET同样加上注释。自身描述特点，GET、SET则描述其要求性的注释。如下图：
方法注释：
其格式参考code.xml文件，可对文件先进行导入IDE中，再
不影响整体格局的前提下进行调整。如下图：
业务逻辑注释：
业务逻辑注释是在代码片段中描述一个主支或分支的整个流程逻辑思想，其格式为：
过程注释：
5.7 SQL语名规范
每条SQL语句必须标有注释，阐明其功能及相关说明、要求等。
SQL语句杜绝出现N+1情况。
SQL语句原则上保持主键唯一性。
SQL语句中有关联、嵌套、联合时，避免超正常执行情况，造成操作延时及数据不正确性。
SQL语句对外键约束严格把控，没有必要所有表都有外链，应根据需求合理增设外键。
5.8 排版
5.8.1 缩进
使用Tab缩进，而不是空格键--将缩进2，4，8字符的选择权留给阅读者。但整体风格必须一致。
5.8.2 空行
方法与方法之间与一行或多行空行分隔，最大空行长度不超过三行。一个方法实现中，不同区域阶段以一空行分隔，以示区别及方便查阅。
6开发环境及辅助工具
引入《论语·魏灵公》中的“工欲善其事，必先利其器。”来展开本章节的后续内容。
6.1 jdk版本
不是所有最新的版本就是最好的，也不是所有最新的就是通用的。截止写此文档时，我们还是要求使用[jdk1.6.0_43]版本作为我们的
JDK运行开发环境。
6.2 环境变量
在windows这面大旗下，开发、测试、运行等往往需要臣服与它，如注册表、环境变量等，好在java产业链中，绝大多数是支持windows 的，大部分也属于“绿色”、“低碳”的，这点是我个人比较喜欢的。
如戴复古在《寄兴》中说的：“黄金无足色，白璧有微瑕”。世界哪有那么完美的事物，环境变量登拉开了开发过程的序幕JAVA_HOME
CATALINA_BASE
CATALINA_HOME
然而万物皆有其根源，
6.3开发使用IDE
Sun公司这名含义的那么伟岸，更似乎那么高不可攀，永远高悬在人类仰望的宇宙之中。然而，Sun公司也许永远都不会想到，日蚀因太阳才存在的，而且遮挡了它的万丈光芒，我们的主角Eclipse优雅的登场，婀娜多姿的身材完全让身后的那颗太阳黯然失色。因为她不仅仅是免费的，还开源，对你没看错，而且你可以自已开发插件安装到Eclipse中。
项目中开发人员均使用Eclipse Kepler。在运行Eclipse后，进行相关环境的统一配置，下图截取了几个统一配置，仅供参考。
6.4运行容器
程序运行容器目前种类繁多，有些民间高手自己写的也很不错，鄙人仰望之。作为运行容器，在开发中无明确约束、规定，可根据个人喜好自行选择，不过这里须注意版本之间的兼容问题。下面列举几个耳熟能详的运行容器，我们或许可以亲切的这样对其称呼。
（Apache Software Foundation）的Jakarta 项目中的一个
核心项目。最初是由Sun的软件构架师詹姆斯·邓肯·戴维森
开发，后变为免费的开放源代码的Web 应用服务器，属于轻
量级应用服务器。
被贩卖的黑奴【WebLogic】：收费。对业内多种标准的全面支
持，具体请自行度娘吧。
皇宫里的她他它【WebSphere】：收费。IBM的尊贵血统，有钱
者的俱乐部。
6.5其它工具
Rational Rose
MindManager
Aptana Studio
Axure
6.6终端环境兼容
做WEB端系统最头疼的也许就是浏览器的兼容性吧，对于兼容大部分，尤其老版本的IE来说，个人认为是件耗时、耗力的事情，时间和人力都是企业重要的成本。尤其现在WEB端系统正在移动终端火的正浓。所以对于兼容各个终端环境对企业、开发团队都是一个考验。但个人认为一个项目未必都要全部兼容，应依照具体项目具体分析使用人群的情况而制定兼容方案。
对于臭名昭著的IE浏览器来说，IETester是WEB系统前端开发人员测试各老版本IE很不错的工具。
7写在结尾
因为参考了很多书籍及网络文献，再就是对以前项目中文档内容的收集整理，从而形成了本文档，感谢那谢默默奉献的人。
感谢家人的支持与理解，尤其在深夜写文档时，灯光、键盘敲击声等等，影响了家人的休息。
由于时间短缺，专业知识匮乏，思维不够严谨，文笔粗糙等个人因素产生的错误、不足请见谅，欢迎批评、指正。
程序设计综合训练<图书馆管理系统> 设计报告 院系：材料科学与工程学院 专业班级：材料成型一班 姓名：张成智 学号： 20111402128 指导老师：肖老师
一、程序功能简介 图书排序功能 1）按图书编号排序 可以按图书编号的大小排序，显示到屏幕上。（从小到大） 2）按图书出版时间排序 可以按图书出版时间的前后排序，显示到屏幕上。（从近到远） 3）按图书价格排序 可以按图书价格的贵宜排序，显示到屏幕上。（从便宜到贵） 4）按图书书名排序 可以按图书书名字符的大小排序，显示到屏幕上。（从小到大） 5）按图书作者名排序 可以按图书作者名字符的大小排序，显示到屏幕上。（从小到大） 二、本人完成的主要工作 图书排序功能（排序比较简单只要做出来一个，其他都和它雷同。） 三、设计方案 1.设计分析； 1)序功能简介： s 进入系统
|| 2）各个功能流程图 1、按图书编号排序 菜单 1-添加图书 4-图书排序 5-查询图书 6-修改图书 7-录入数据 0-退出系统 2-删除图书 3-图书列表 输入编号、书名、 作者名、出版社、 类别、出版时间、 价格。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行删除。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行列出。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行排列。 按照编号、书名、作者名、出版社、类别、出版时间、 价格进行咨询。 依次录入编号、书名、作者名、出版社、类别、出版时间、 选择编号、书名、作者名、出版社、类别、出版时间、 价格进行修改。 输入0返回原始菜单。
文件编号：RHD-QB-K9967 （管理制度范本系列） 编辑：XXXXXX 查核：XXXXXX 时间：XXXXXX 施工现场技术管理制度 标准版本
施工现场技术管理制度标准版本操作指导：该管理制度文件为日常单位或公司为保证的工作、生产能够安全稳定地有效运转而制定的，并由相关人员在办理业务或操作时必须遵循的程序或步骤。，其中条款可根据自己现实基础上调整，请仔细浏览后进行编辑与保存。 1、制度内容及适用范围 本制度主要内容为：1、图纸自审制度；2、图纸会审制度；3、施工组织设计（方案）的编制与管理；4、施工作业指导书的编制与管理；5、技术交底制度；6、技术核定制度；7、单位工程施工记录制度；8、技术复核制度；9、隐蔽工程验收制度； 10、科技开发和推广应用管理制度；11、施工技术总结；12、技术标准管理制度；13、工程技术档案制度。 本制度适用各项目工程的技术管理。 2、图纸自审制度
2.1图纸自审由项目经理部主任工程师负责组织。 2.2接到图纸后，项目经理部主任工程师应及时安排或组织技术部门有关人员及有经验的老工人进行自审，并提出各专业自审记录。 2.3及时召集有关人员，组织内部会审，针对各专业自审发现的问题及建议进行讨论，弄清设计意图和工程的特点及要求。 2.4图纸自审的主要内容： 2.4.1各专业施工图的张数、编号、与图纸目录是否相符。 2.4.2施工图纸、施工图说明、设计总说明是否齐全，规定是否明确，三者有无矛盾。 2.4.3平面图所标注坐标、绝对标高与总图是否相符。
2.4.4图面上的尺寸、标高、预留孔及预埋件的位置以及构件平、立面配筋与剖面有无错误。 2.4.5建筑施工图与结构施工图，结构施工图与设备基础、水、电、暖、卫、通等专业施工图的轴线、位置（坐标）、标高及交叉点是否矛盾。平面图、大样图之间有无矛盾。 2.4.6图纸上构配件的编号、规格型号及数量与构配件一览表是否相符。 2.5图纸经自审后，应将发现的问题以及有关建议，做好记录，待图纸会审时提交讨论解决。 3、图纸会审制度 3.1图纸会审目的 了解设计意图，明确质量要求，将图纸上存在的问题和错误，专业之间的矛盾等，尽最大可能解决在工程开工之前。
Git源代码管理规范 一、分支管理 使用git进行源代码管理, 一般将某个项目的所有分支分为以下几条主线: 1.Master 顾名思义, 既然名字叫Master, 那么该分支就是主分支的意思。master分支永远是production-ready的状态, 即稳定可产品化发布的状态。 2.Develop 这个分支就是我们平常开发的一个主要分支了, 不论是要做新的feature还是需要做bug fix, 都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本, 即完成了某个feature或者修复了某个bug后的开发稳定版本。 3.Feature branches 这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当功能点开发测试完毕之后, 就会合并到develop分支去。
4.release branches 这个分支系列从develop分支出来, 也就是预发分支。在预发状态下, 我们往往会进行预发环境下的测试, 如果出现缺陷, 那么就在该release分支下进行修复, 修复完毕测试经过后, 即分别并入master分支后develop分支, 随后master分支做正常发布。 5.Hotfix branches 这个分支系列也就是我们常说的紧急线上修复, 当线上出现bug且特别紧急的时候, 就能够从master拉出分支到这里进行 修复, 修复完成后分别并入master和develop分支。 下面这张图将完整展示这一个流程
二、工作原理Git的工作方式:
也就是说, 每次提交版本变动的时候, git会保存一个快照(snapshot)。如果文件没有被更改, git也不会再次保存, 而是提供一个到原来文件的链接。这样一来, git更像是一个小型的文件系统。另外, git的所有操作都能够是本地的, 仅仅在将新版本的内容上传到服务器上时才需要连接网络。 Git目录( repository) 是Git保存元数据和对象数据库的地方。这也是Git最重要的部分。
软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划
上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目部的目录结构： |–projectA |–src （保存该项目的源程序） |–doc （保存项目相关文档） |–000.项目管理（保存项目过程管理相关文档） |–010.项目计划（保存项目计划相关文档） |–020.项目需求（保存项目需求相关文档） |–030.系统设计（保存项目设计相关文档） |–030.系统测试（保存项目代码测试相关文档） |–040.系统实施（保存项目部署实施相关文档） |–050.系统运维（保存项目运维文档，包括培训、用户手册等） |–060.技术资料（保存项目技术文档，包括第三方技术资料等）
技术标准管理制度 一总则 1.目的 为规范公司的技术标准管理工作，遵循国家相关的技术标准规定，提高公司的技术水平，特结合公司的实际情况制定本制度。 2.适用范围 本制度适用于设计部各技术标准审批、执行与管理事宜。 3.责任 设计部负责技术标准的管理，包括识别并确定适宜的各种技术标准；负责技术标准执行情况的监督、检查、考核。 二技术标准的管理内容 1.标准分为国际标准、国家标准、部颁标准、企业标准和国军标。 2.国家标准、行业标准的分类 国家标准、行业标准根据标准的性质分为“强制性”和“推荐性（标准号前带 /T）”两种。 （1）强制性标准一般是有关安全的标准，国家强制要求执行； （2）推荐性标准由国家推荐执行，但是如果在国家有关法律、法规规定需要执行的标准，或者企业在产品的包装等处明示执行的标准，不管其标准性质如何，均相当于强制性标准，需要强制执行。 3.国军标 国军标是为了保证军用元器件的质量，对元器件所制定的一系列的标准与要求，以备对部队等部门提供优质的元器件。
自90年代初期开始的军标认证，是依据国家军用标准的认证。其认证机构是由原国防科工委授权的中国军用电子元器件质量认证委员会，它独立于元器件的生产方和使用方，所以属于第三方认证。 质量认证包括两方面的内容：对于元器件生产单位质量保证能力的评定：对其所生产的元器件进行鉴定或考核，合格者列入合格产品目录(QPL)或合格生产厂目录（QML）。 4.国家标准、行业标准及国军标的发放要定期搜索，及时根据国家规定更新新版本。 三技术标准的执行 1.设计部必须严格贯彻执行相关国家及行业技术标准。任何人在工作执行过程中，不得擅自修改工艺、降低标准。否则，所引起的质量事故将按生产质量管理中的有关条款执行。 2.设计部各种质量验收、检测活动，都必须按照相关的技术标准执行。符合标准的设计样图和技术文件予以审批，不符合标准的设计图样及文件予以返工。 四标准化审查 1.标准化审查是检查核对产品图样及设计文件是否正确、有效的贯彻各级、各类标准的重要手段，在产品的初步设计、技术设计、工作图设计的各个阶段应进行相应的图样及设计文件的标准化审查。对图样及设计文件标准化审查的全部记录将是评价设计质量的依据之一。 2.标准化审查基本任务 （1）检查图样、技术文件是否正确地贯彻了国家现行各级标准及企业有关规定，提出并纠正不符合各级标准及有关规定的缺陷、差错。有效地实施对图样、技术文件质量的技术监督。
变更履历
目录 1总则 (4) 2源代码完整性保障 (4) 3源代码的授权访问 (4) 4代码版本管理 (5) 4.1系统初验 (6) 4.2试运行 (6) 4.3系统终验 (7) 4.4系统验收标准 (7)
1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。 第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小
1源代码管理 (1) 总则 (1) 源代码完整性保障 (1) 源代码的授权访问 (2) 代码版本管理 (2) 源代码复制和传播 (5) 系统测试验收流程 (5) 系统初验 (6) 试运行 (6) 系统终验 (6) 应用系统验收标准 (8) 文档评审通过标准 (9) 确认测试通过标准 (9) 系统试运行通过标准 (10)
1代码管理 总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。
放射科管理与技术规范-放射科管理制度 第一节放射科组织管理制度 一．在院级领导领导下，实行科主任负责制。实施放射科主任对放射科各个部门（包括普通X线诊断、CT、MRI、介入治疗等）的统一领导和管理。科主任一般应当由学科带头人、高年资医生担任。 二．可分设副主任或组长协助科主任工作。 三．住院医师应实行不同影像学方法的轮转学习，力求全面掌握影像学各种方法，以便发挥综合诊断的优势。科室应鼓励高年资主治医师按人体解剖系统分专业深入钻研，以期成某一方面的专家。技术人员实施相对固定，定期轮转；能够掌握放射科各种设备的操作、使用，实现一专多能。 四．全面抓好科室的各项质量管理和优质服务。科主任要全面管理好各岗位人员的工作，有计划地安排好各级人员的专业培养和提高业务水平。 第二节资料存档保管制度 一、X线片、X线检查申请单、报告单、等资料要保存15年。 二．线检查资料要有专门储藏场地，由专人负责，保证资料的完整，不得遗失和破损。 三．如有缺片，应及时查找，明确去向。 四．每天整理，汇总，归类。 五．借取存档片由登记室人员负责，其他人员不得擅自借取。 六．急诊借片。根据急诊室要求，急诊病人拍片后，可先借片，后写报告。 七．平诊借片。借片需由借片医生开具借片条后至登记室借取；外借片须有借片人出具借条，留下借片人身份证复印件及联系电话号码。 第三节X线摄影室管理制度 一．每日上班后应先开机、开空调。检查病人前先作球管预热，不许在未预热状态下检查患者。机器出现故障时，应记录在案，维修情况也应记录。 二．进行x线摄影检查前，应仔细核对病人姓名，性别，年龄，科室，床号，住院号，
摄片部位和会诊单，检查号码是否准确，严防错号、重号和病人重名重姓；应除去病人身上金属、膏药等物品。对检查有不明之处及时请示本科医师或上级技师，或与临床医生取得联系。 三．摄影操作时注意周围有无障碍物及诸附件有无固定。危重病人或怀疑脊椎骨折病人应有临床医生陪同，协助移动病人和摆位，以免因摄影操作而加重病情，发生意外。 四．病人检查结束后，应填写曝光条件、日期；特殊摄影应记录摄影体位，最后签名。 五．非本机操作人员未经许可严禁操作使用。 六．保持机房内整洁，下班前要及时关机、关灯和空调，并在机器复位后进行清洁卫生工作。 第四节暗室管理制度 一．每早清洁暗室、洗片机、打印机，检查自来水、红灯，备足胶片。 二．检查清洁洗片机和打印机各部分结构 ，检查运转状况，包括循环、补液、显影和干燥、温度。 三．洗片机工作前先走废片数张，并记录走片时间是否正常。打印机每天工作前先作，确定情况正常再进行日常工作，并装满胶片。 四．定期检查、清洁暗盒；看看有无破损、污迹，并做好记录。五．暗室工作人员应随时关灯，非暗室人员无特殊情况不得入内。六．下班前进行安全检查，包括电源、水源、空调、洗片机和打印机等，并做好桌面卫生保洁工作。 第五节CT室管理制度 一．非工作人员不得进入机房，工作期间不得在机房内喧哗，保持工作环境安静。 二．机房内严禁吸烟，严禁吃零食，保持机房整洁。 三．工作人员不得擅自使用机器做工作以外的病人。 四．工作人员在工作期间，应注意安全，防止意外情况发生。 五．维持机房温度和湿度恒定，保证机器处于正常工作环境。六．工作人员应爱护公物。托架等。CT室一切附属设备应放在指定位置，不得乱放。
代码管理制度 1总则 (2) 2源代码完整性保障 (2) 3源代码的授权访问 (2) 4代码版本管理 (3) 5源代码复制和传播 (4) 6系统测试验收流程 (5) 6.1 系统初验 (5) 6.2 试运行 (5) 6.3 系统终验 (5) 6.4 系统验收标准 (6) 6.5 文档评审通过标准 (7) 6.6 确认测试通过标准 (7) 6.7 系统试运行通过标准 (7)
1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。 第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小访问权限。要求连接SVN库时必须校验SVN中用户身份及其口令。在SVN库中要求区别对待不同用户的可访问权、可读权、可写权。
中铁二十局集团有限公司沪昆客专贵州段工程指挥部 应用四新技术管理制度 第一章总则 第一条为使科技成果转化为生产力，推动建筑新技术在工程上的广泛应用，及中铁二十局集团有限公司沪昆客专贵州段CKGZTJ-9标段施工技术“四新”技术与推广，充分推行“四新”技术的建设理念，做好新技术应用示范工程的管理工作，根据《建设领域推广应用新技术管理规定》（建设部令第109号），结合本标段的特点，制定本办法。 第二条本制度适用于中铁二十局集团有限公司沪昆客专贵州段CKGZTJ-9标段所有参建单位。 第二章四新技术的应用 第三条工程技术工作主要由工程技术部负责，各专业工程师负责参与各专业工程施工技术“四新”技术和新技术﹑新设备﹑新工艺的推广﹑应用，督促落实新技术﹑新工艺的实施情况；负责各项工程科技信息收集﹑积累﹑开发﹑利用及科技资料的整理；物资设备部、安质环保部和计划财务部配合工作。 第四条工程施工中应充分认识“四新”技术----新技术、新材料、新设备、新工艺的重要性，以市场为导向，以企业为主体、产学研相结合。围绕安全性，降低成本，降低造价，缩短工期，更高的质量，更便于管理为目标，采用自主研发或与以重大工程项目为载体与各大专院校联合开展科技攻关。“四新”技术主要内容包括： 1、新技术：及时参加新技术学习会、培训班、发布会或博览会等，并上网查阅相关资料，工程技术部组织召开研讨会共同学习新技术，
并针对实际工程认真研究可行性方案。 2、新材料：材料员及时了解行业动态，关注新材料的性能和应用范围，并在研讨会上介绍，使工程向更安全，更节能，更环保，更健康，污染（噪音、粉尘等）小，加工废料少，效率高的新型装饰行业迈进。 3、新工艺：组织人员学习、考察国内外的新工艺；组织工人进行学习交流，并使之应用于工程中。 4、新设备：与国内外大型工具生产商建立长期合作关系，及时了解新产品发布，使新设备能早日投入到生产中。 第五条围绕“四新”技术展开各项活动 1、开展岗位技术培训，提高全员技术素质；建立健全各级技术管理“四新”技术体系，完善技术责任制；认真贯彻执行技术标准规程。 2、围绕“四新”技术的引进、开发和技术改造、创新，拟定切实可行的科技“四新”技术工作计划并做试点工程。 3、经常进行“四新”技术的学习和交流，及时进行情报资料的收集、整理、探索研究及报道交流。由基本技术指南出发，进行不断的思考、“四新”技术，最终驾驭规范要求，超越基本技术。 4、通过推广建设领域新技术、新材料、新工艺和新设备，实现工程建设健康、快速、可持续的发展，推进工程快速稳定建设，并使本标段施工由劳动密集型向科技型转变,以“新型、节能、科技、绿色”为目标，提升全行业竞争力，使本标段工程成为“四新”应用的样板工程。 第三章申请立项及遵循原则
XXXXXXXX 代码版本管理规范
历史版本
目录 历史版本 (2) 1引言 (4) 1.1目的 (4) 1.2管理工具 (4) 2现状概述 (5) 3现状分析 (5) 3.1现状详述 (5) 3.2目标细化 (6) 3.3SVN版本管理 (6) 3.3.1概述 (6) 3.3.2使用对比 (7) 4完整的实施方案 (9) 4.1开发阶段 (9) 4.2预发布测试阶段 (9)
1引言 1.1目的 为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，同时明确开发源代码的控制管理流程，特此制定此规范。 1.2管理工具 沿用SVN管理工具来进行开发的版本管理，源代码管理和开发资料归档。
2现状概述 目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。 这样会造成如下两点影响： ●会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库 中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。 ●一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部 分问题是由于其他项目代码引起的。 因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。 3现状分析 3.1现状详述 当前代码版本管理现状如下： 1.所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。 2.提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。 3.测试出bug以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的 代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此bug再做测试。 这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布bug数量。 总体来说，当前工作流程是：预发布出bug，研发修改，再提交测试，然后预发布测试
中建保华建筑有限公司 技术规范管理制度 第 1 页 共 15 页 1、制度内容及适用范围 本制度主要内容为：1、图纸自审制度；2、图纸会审制度；3、施工组织设计（方案）的编制与 管理；4、施工作业指导书的编制与管理；5、技术交底制度；6、技术核定制度；7、单位工程 施工记录制度；8、技术复核制度；9、隐蔽工程验收制度；10、科技开发和推广应用管理制度； 11、施工技术总结；12、技术标准管理制度；13、工程技术档案制度。 2、图纸自审制度 2.1图纸自审由项目经理部主任工程师负责组织。 2.2接到图纸后，项目经理部主任工程师应及时安排或组织技术部门有关人员及有经验的老工 人进行自审，并提出各专业自审记录。 2.3及时召集有关人员，组织内部会审，针对各专业自审发现的问题及建议进行讨论，弄清设 计意图和工程的特点及要求。 2.4图纸自审的主要内容： 2.4.1各专业施工图的张数、编号、与图纸目录是否相符。 2.4.2施工图纸、施工图说明、设计总说明是否齐全，规定是否明确，三者有无矛盾。 2.4.3平面图所标注坐标、绝对标高与总图是否相符。 2.4.4图面上的尺寸、标高、预留孔及预埋件的位置以及构件平、立面配筋与剖面有无错误。 2.4.5建筑施工图与结构施工图，结构施工图与设备基础、水、电、暖、卫、通等专业施工图 的轴线、位置（坐标）、标高及交叉点是否矛盾。平面图、大样图之间有无矛盾。 2.4.6图纸上构配件的编号、规格型号及数量与构配件一览表是否相符。 2.5图纸经自审后，应将发现的问题以及有关建议，做好记录，待图纸会审时提交讨论解决。 3、图纸会审制度 3.1图纸会审目的 了解设计意图，明确质量要求，将图纸上存在的问题和错误，专业之间的矛盾等，尽最大可能 解决在工程开工之前。 3.2会审参加人员
1源代码管理 (1) 1.1总则 (1) 1.2源代码完整性保障 (1) 1.3源代码的授权访问 (2) 1.4代码版本管理 (2) 1.5源代码复制和传播 (5) 1.6系统测试验收流程 (5) 1.6.1系统初验 (6) 1.6.2试运行 (6) 1.6.3系统终验 (6) 1.6.4应用系统验收标准 (8) 1.6.5文档评审通过标准 (9) 1.6.6确认测试通过标准 (9) 1.6.7系统试运行通过标准 (10)
1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。
1.0, Purpose 目的 1.1 保证工程技术的规范，提高工程技术的质量，确保完成符合要求的工程成果。 1.2 鼓励在工程技术中采用先进技术、工艺、设备及新型材料。 1.3 提高工程质量，降低工程造价，加快工程建设进度。 鉴于此，特制定《工程技术管理制度》，现予以发行，望各相关部门和工程项目部遵照执行。 2.0, Scope 范围 本制度仅限于公司内部使用，未经同意，严禁对外传阅。 3.0, Relevant document 相关文件 4.0, Definition 定义 工程技术管理，是对公司及项目中弱电技术活动和技术作业的各种因素、资源进行科学、合理、有效的组织和管理的总称，是公司管理规章制度中的重要组成部分，也是实现工程质量、安全、进度、成本目标的有力保障措施。 5.0, Responsibility 职责 通过充分调动公司各种技术资源，认真贯彻、执行设计文件、合同文本及各种技术规范、规程、标准和相应的法律、法规，运用各种有效的方法和手段，规范技术管理中的各项工作及其具体环节，达到以技术管理工作保证实现弱电工程质量、安全生产责任目标；同时也科学地组织各项技术工作，建立良好的施工技术管理秩序，为高效优质地完成工程施工任务，达到满足顾客要求而提供有利、有力、科学的保障和措施。 6.0, Technology management policy 技术管理方针 技术管理的方针：科学、严谨、创新、精益求精。 7.0, Working instruction 工作指示 7.1 技术管理主要工作内容
根据我公司目前主要经营范围，技术管理工作主要分为两大部分，一部分就是公司技术管理工作，一部分是工程项目部技术管理工作。 7.1.1公司技术管理主要工作有： 7.1.1.1贯彻、执行、传达国家关于弱电智能化建设行业的强制性法律、法规。 7.1.1.2掌握本行业和相关行业的行业技术质量标准。 7.1.1.3掌握国家新行规范、规程、标准的颁布，并在公司内部传达和执行。 7.1.1.4制定公司内部技术管理的有关规章制度。 7.1.1.5对工程的技术管理和质量管理进行监督、指导。 7.1.1.6对公司内所使用的调试、检验设备进行合理的调配、标定、鉴定、维修、贮藏和跟踪服务。 7.1.1.7对公司已竣工项目的竣工资料、施工图纸等技术性文件资料进行规范、保密管理。 7.1.1.8收集、整理已完工程和在建工程的施工组织设计。 7.1.1.9指导编写、收集整理、组织评比各项工程的《工程技术总结》和技术性论文。 7.1.1.10配合人事部门做好技术人员的培训、职称评定、职称晋升等工作。 7.1.1.11根据公司领导安排，配合人事部门对公司内部技术人员进行有效的考核和评比。 7.1.2项目部技术管理主要工作内容有： 7.1.2.1贯彻、执行国家强制性法律、法规和行业标准。 7.1.2.2审查设计文件并进行施工现场勘察。 7.1.2.3编写分项施工技术方案、作业指导书，并进行技术交底。 7.1.2.4对施工过程进行有效、积极地指导、检查、评比、验收。 7.1.2.5认真填写施工日志和质量检查、技术检验记录和其他质量记录。 7.1.2.6负责竣工资料的编制和移交，负责已完成工程的验收和工程保修期间技术服务工作。 7.1.2.7配合合同管理、物资设备、质量、试验等部门，积极完成自己在协作过程应分担的工作任务。 7.1.2.8配合公司做好项目内部岗位技术培训计划。 7.2 工程技术交底 工程技术交底是在工程施工之前，向专业工程师或现场施工负责人明确施工内容、方法、标准的技术作业资料。 7.2.1分类
广西河池汉军龙江·帝景项目工程 工程技术、标准和规程管理制 度
中建四局第一建筑工程有限公司广西河池项目 二一年四月七日O O 工程技术管理制度 第一章总则 为加强项目施工技术管理工作，使技术管理工作规范化、标准化、程序化，第一条 推进企业技术进步，增强企业市场竞争和应变能力，制定本办法。 本办法适用于中建四局汉军龙江·帝景项目经理部施工技术管理工作，内容第二条 包括图纸会审、技术交底、工程测量、施工技术调查、施工作业指导书、技术资料管理、 工程试验和检验、工程施工技术总结及竣工验收、编制竣工文件等工作。 第二章职责 项目总工程师是项目的技术负责人，对项目的施工技术和质量管理负责，并第三条 对施工技术工作负主要责任。 工程部在总工程师的领导下，贯彻执行国家有关技术政策、法规和技术标准、第四条规范及监理规程等，具体实施项目经理部的施工技术管理制度和有关办法，负责项目施工 技术和质量管理的实施工作，对现场施工技术负指导责任。 第五条安质部在总工程师领导下工作，贯彻执行国家有关工程建设的方针、政策和 上级颁发的技术标准、规范、规程等有关文件，熟悉监理程序，与监理人员保持密切联系。 负责对现场进行质量检查，督促自检及自检记录的填写工作，负责对隐蔽工程及分项、分 部工程的检查验收。 第六条试验室在总工程师领导及指导下工作，执行技术标准、技术规范、试验规程 和质量检验评定标准。负责项目部的所有试验、检测工作，配合有关部门调试设备，保证 生产配合比达到设计要求，参与项目部隐蔽工程的检查验收及工程中间交接检验。 第七条测量队执行技术标准、技术规范、质量检验评定标准及施工图设计文件等施 工技术资料。负责项目恢复定线和控制测量工作，负责现场交桩及测量资料的交付工作， 检查、指导架子队队的测量、放样。配合监理做好工程测量检查、报验等事宜，作好工程 质量检查及交工验收中有关测量方面的工作。． 第三章图纸会审
基于Tortoise SVN的软件产品版本管理规范[草稿]
目录 1. 引言 (1) 1.1. 目的 (1) 1.2. 范围 (1) 1.3. 术语定义 (1) 1.4. 参考资料 (2) 1.5. 版本控制记录 (2) 1.6. 版本更新记录 (2) 2. 版本管理 (4) 2.1. 版本标示方法 (4) 2.1.1. 正式版本 (4) 2.2. 目录结构 (5) 2.3. 文档的存放 (6) 2.3.1. 开发文档的存放 (6) 2.3.2. 源代码的存放 (6) 2.3.3. SQL的语句存放 (7) 2.3.4. 发行文档的存放 (7) 2.4. 配置管理流程 (7) 2.5. 权限控制的管理 (8) 3. 更新管理 (9) 3.1. 源程序的修改 (9) 3.2. 版本升级 (10) 3.2.1. 版本升级原则 (10) 3.2.2. 新版本发布 (11) 3.3. 文档的变更 (11) 4. 备份管理 (12) 5. 版本工具Tortoise SVN的使用 (13)
1.引言 版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。 版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。 1.1. 目的 本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。 1.2. 范围 本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括： ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3. 术语定义 SCM 软件配置管理（Software Configuration Management）缩写 SVM 软件版本管理（Software Version Management）缩写 SVN 一个开源的版本控制系统Subversion. 文档 一种数据媒体和其上所记录的数据。
公司技术标准管理办法 第一章总则 第一条为深化公司标准化工作，明确职贵、规范管理，根据《中华人民共和国标 准化法》、《中华人民共和国标准化实施条例》、有关规定，特制定本办法 第二条技术标准是企业组织现代化生产，进行科学管理的重要手段，对促进企 业技术进步，提高企业科学管理水平，提高产品水平起着十分重要的作用，是企业生产经 营和管理的一项基本工作。 第三条技术标准的范圉包括产品标准、技术条件、技术协议、工艺技术规程检验 和试验方法标准和原燃材料采购标准等技术标准。 第四条技术标准分为：国家标准、行业标准、地方标准和企业标准。 第二章组织机构及职责 第五条公司技术部是公司技术标准的主管部门，负责统筹规划公司技术 标准匚
作。 第六条职责 一、组织贯彻国家的标准化方针、政策、法律、法规和规章制度，制定公司 技术标 准的工作规划。 二、配合集团公司组织制（修）订上级卜达的国家标准、行业标准及企业标准。 三、组织实施有关国家标准、行业标准、地方标准和企业标准。 四、组织对公司实施标准情况进行监督检査。 五、参与新产品研制、产品改进、技术改造和技术引进的标准化工作，提出标准化 要求，负责标准化的审査工作。 第三章标准制定的一般程序 第七条制定企业技术标准的一般程序是编制计划一调査研究一起草标准草案一征 求意见一对标准草案进行修改一报集团公司审査一由集团公司组织召开专家审查会，通过 后一报集团公司总经理批准一发布、实施。
第八条申请制定修改企业标准一般应备有以下材料。 1、企业技术标准草案； 2、编制说明： 3、必要的验证报告。 第四章标准的复审和修订 第九条标准的复市：标准实施后，根据科学技术的发展和工艺技术改进的需要适 时进行复审，以确定现行标准继续有效、废止或进行修订，复审周期一般不超过3年。当 有相应的国家标准、行业标准发布实施后，应及时复审，并确定其继续有效、修订或废止。 第十条标准的修订：当生产工艺有较大变化，用户要求有较大改变，技术标准不 能满足生产经营需求时，应进行修订，修订的程序同标准的制定。 第五章标准的实施监督检査 第十一条实施技术标准的基本原则: 一、国家标准、行业标准、地方标准中的強制性标准公司必须严格执行，不符合
源代码管理规范 标准化文件发布号：（9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-
代码管理制度 1总则.................................................................................................. 错误!未定义书签。2源代码完整性保障............................................................................ 错误!未定义书签。3源代码的授权访问............................................................................ 错误!未定义书签。4代码版本管理 ................................................................................... 错误!未定义书签。5源代码复制和传播............................................................................ 错误!未定义书签。6系统测试验收流程............................................................................ 错误!未定义书签。 系统初验........................................................................................... 错误!未定义书签。 试运行............................................................................................... 错误!未定义书签。 系统终验........................................................................................... 错误!未定义书签。 系统验收标准................................................................................... 错误!未定义书签。 文档评审通过标准........................................................................... 错误!未定义书签。 确认测试通过标准........................................................................... 错误!未定义书签。 系统试运行通过标准....................................................................... 错误!未定义书签。
源代码管理文档管理规范 第一章总则 第一条为保障公司源代码和开发文档安全，保证源代码的完整，明确源代码控制管理流程，特制定本源代码管理办法。 第二条本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 第三条源代码直接控制管理部门为产品管理。原代码的内容为我单位万网工程建站的所有相关网站，模板，四川机构网网站代码以及数据库等。 第四条本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 第五条本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 第二章源代码完整性保障 第六条所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 第三章源代码的授权访问 第七条源代码服务器对于共享的TFS库的访问建立操作系统级的，基于身份和口令的访问授权。 第八条在TFS库中设置用户，并为不同用户分配不同的，适合工作的最小访问权限。要求连接TFS库时必须校验TFS中用户身份及其口令。在TFS库中要求区别对待不同用户的可访问权、可读权、可写权。 第九条曾经涉及、触及源代码的计算机在转作它用，或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。 第四章源代码复制和传播 第十条源代码向研发部门以外复制必须获得总经理的书面授权。并必需记录
复制人、批准人、复制时间、复制目的、文件流向、文件版本或内容。 第十一条源代码以任何介质形式进行存储的备份，必须由专人负责保管。对于这些介质地借阅，用于研发部内部使用的必须获得研发部经理的授权，对于用于研发部以外使用的必须获得总经理的书面授权。 第十二条源代码的借阅、复制必须进行详细的登记，必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。 第十三条任何纸质材料的借阅都必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。 第十四条对于因合作需要，需要向外复制、传播、分发源代码的，不论是全部还是部分代码和资料，均必需和对方签订技术、源码的保密协定，明确对方应当承担的对源码保密的责任和义务。 第十五条所有已有的开发文档与当前的代码进行统一管理。 第十六条新开发的项目和系统验收时必须与同相关的开发文档同时进行验收。 第五章开发文档管理规范 第十七条所有已有的开发文档与当前的代码进行统一管理 第十八条本规范执行日之后的所有项目的开发必须按开发的基本规则输出开发文档进行备案。 第十九条开发周期在1-3个月以内的项目开发文档保密时效为6个月，开发周期在3个月以上的为一年，保密时效计时为项目结束成功验收之后开始。 第二十条在项目开发中任何以不得未经授权向外发布、流传开发相当的任何文档。