项目软件版本号管理规范
历史修改记录
一. 目的
1.1软件版本按照一定的规则保存所有版本，避免发生版本丢失或混淆等现象，
并且可以快速准确的查找到任何版本。
1.2软件版本规范有利于公司各部门之间的对接工作，有利于公司内部资料统一
管理。
1.3本文档是为规范研发部软件版本管理而制定的。
二. 范围
2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容，包括：2.2版本标识方法及管理
2.3版本升级
2.4文档及源码的备份制度
2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作，公司内部使
用按照文档及源码存放备份制度。
三. 版本管理
3.1版本号规则
3.1.1每个归档版本都有两个版本号：内部版本号和外部版本号。版本号使用
VP规则，V(Version)是指外部版本号（研发测试版本），P(Patch)是指补丁版本号（可选）。
3.1.2版本号命名：V/B+主版本号+次版本号+修订版本号+日期版本号
3.2版本号修改规则
3.2.1主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生
变化。此版本号由项目决定是否修改。
3.2.2次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变
动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目决定是否修改。
3.2.3修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩
充，要经常发布修订版，修复一个严重Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。
3.2.4日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要
更改日期版本号。此版本号由开发人员决定是否修改。
如： V8.1.0.XXX (上一级版本号有变动时，下级要归零)
3.3版本号修改举例说明
如此时版本号为：V8.1.0.XXX ，此时为内部测试阶段
3.3.1 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为：
V8.1.1.XXXX ，如当前日期跟上一个版本号的日期不一样，版本号可改为：
V8.1.1.XXX。
3.3.2 如果对软件进行了一些功能上的改进或增强，进行了一些局部变动的时候要修改次版本号，如：V8.2.0.XXXX（上一级有变动时，下级要归零）。
3.3.3 当功能模块有较大变动，增加模块或整体架构发生变化时要修改主版本号，如新增加了退款功能，则版本号要改为：V9.0.0.XXXX；
3.4版本控制记录
3.4.1 版本状态变迁要遵守一定的规则，内部先生成一个内部版本，提交测试审批，生成外部版本。（测试人员在测试过程中根据《软件测试规程》检测生成《软件测试报告》再由项目组内部讨论是否能生成新的版本）不通过则为无效版本，需要软件开发人员再进行修改，直至通过。通过后生成表格记录，再和源码一起打包受控形成外部版本。
3.4.2 版本审核记录表如下：每次审核记录添加，审核通过后作为开发文档一起打包受控。
3.5版本更新记录
3.5.1 版本更新软件工程师根据项目内容的变更，优化软件功能的，需要变更内部版本号提交测试审批，通过了则由开发人员进行版本归档，（测试人员在测试过程中根据项目软件变更优化的内容，结合项目软件整体结合进行测试。测试完成根据《测试报告》由项目组内部讨论是否能生成新的版本。不通过则为无效版本，由开发人员再进行优化工作。更新记录过程中生成表格记录，审核通过后和源码一起打包受控形成外部版本。
3.6版本受控说明：
3.6.1 开发人员完成所负责模块的代码编写任务后，提交到项目经理处；
3.6.2 项目经理向测试人员提交测试任务；
3.6.3 测试人员准备测试所需的环境；
3.6.4 测试人员开展测试并根据《软件测试报告》实时提交BUG；
3.6.5 开发人员处理测试过程中所出现的BUG，并提交给测试人员进行回归测试，直至BUG被解决；
3.6.6 测试基本完成后，测试人员提交测试报告；
3.6.7 根据项目市场需求结合实际情况决定是否发布新的版本；
3.6.8 测试人员与各相关人员经讨论后确定好新版本各项信息；
3.6.9 测试人员发布新版本；
四. 版本升级
4.1版本升级原则
4.1.1版本升级应严格纳入版本管理的控制之下。应当谨慎地控制版本的升级，
保障高版本下的兼容性，提供严格定义的升级方法。
4.1.2记录版本升级过程。每次版本升级，都要填写版本升级记录表，记录表
样例如下：（仅供外部版本升级）内部版本和修订版本分别使用版本审核记录表、版本更新记录表。
4.2新版本的发布
4.2.1新版本的发布指对外新版本程序的升级，内部版本程序和变更版本程序
只对研发部内部升级。流程如下：
1)根据项目进展情况，或者根据用户需要、市场需求进行发布准备。
2)将发布所需文件进行打包整理，放在指定目录中，给目录加上标签，标
签中包含将要发布的版本信息。
3)同样对源码文件也要加上与版本信息相关的标签。
五. 文档及源码存放备份制度
5.1开发文档
5.1.1各项目的开发文档根据对外新版本程序的发布做出相对应的变更，内部
版本程序和更新的程序不做变更。
5.1.2根据各项目组自己的情况，将市场需求记录、总体设计文档、详细设计
及数据结构文件、测试记录、用户手册等放入备份文件中与源代码一起打包保存。
5.2版本归入版本库
5.2.1测试和审批通过之后，由CMO（配置管理员）归入版本库，除了源文件，同时归档的有测试报告、版本配套表、升级指导书等相关文档。
5.2.2 需有内部版本FTP空间，仅内部使用；
开发：有上传/下载权限，无修改和删除选项；
测试：只有下载权限；
技术：只有下载权限；
运维/项目专员：内部版本，复制到外部版本；
同意发布后：
技术从外部版本文件夹获取版本，给客户更新；技术：只有下载权限；
XXXXXX有限公司 文件制订（修订、作废）申请单NO.: 表格编码：
1. 目的 为规范公司软件、程序的管理，确保开发、使用、变更等过程得以受控，根据本公司实际情况，特制定本规范。 2. 适用范围 本规范适用于公司所有自主开发、外购、客供软件、程序的管理。（如无特别说明,本规范内“软件”包含软件、程序） 3. 软件分类: 3.1产品源程序: 由研发部软件开发工程师编写，实现产品功能的烧录文件。 3.2 ATE测试软件及测试程序： 是指由信息技术部负责编写的配套ATE硬件使用的产品测试软件平台,及在此平台下针对不同型号产品编写的测试程序。 3.3 设备应用程序: 是指工程部在设备操作系统下针对不同产品型号编写的对应程序（ATE除外）。如：打码程序、贴片程序、SPI检测程序、AOI检测程序、分板程序、回流焊程序、X-Ray 测试程序等。 3.4管理应用软件: 是指企业使用的电子化管理工具或系统平台。如:ERP系统、品质管理系统、SPC系统、生产报表系统、电子看板系统、绩效管理系统、项目管理系统等 3.5办公软件：Windows、office、Coremail、PDM、AutoCAD、杀毒软件等。 4、职责定义: 原则上公司各部门均可依据自身需求提出软件申请，由技术部门进行开发，交由使用部门进行管理，异常无法解决时,可向技术部门寻求技术支援。具体定义如下： 4.1 需求提出部门:依据公司或者部门的实际情况,提出软件需求申请。软件需求多由软
件使用部门提出，但也可以由其它部门提出。 4.2使用/管理部门:对提出的申请进行评估,确定需求后向开发部门发起正式申请;在软件验收合格后负责日常的管理、维护等；当异常时且无法解决时，及时向开发部门反馈,并要求协助处理。 4.3开发部门:对于使用/管理部门提出的申请进行评估,确定执行方案,并最终完成软件开发；开发部门也负责后期的技术支援。 4.4监控部门:负责对软件验收完成后的使用过程进行监控，确保不出现使用错误,维规操作,使用非法软件及机密软件外流等。 4.4软件管理职责对照见下表： 分类开发部门使用/管理部门监控部门 产品源程序研发部工程部品质部 ATE测试软件及测试程序信息技术部工程部品质部 设备应用程序工程部工程部品质部 管理应用软件信息技术部使用部门信息技术部 办公软件信息技术部使用部门信息技术部 5.软件管理规范： 5.1软件申请、开发、使用管理流程图：（如下图）
工程技术部管理制度 工程技术部是公司的技术管理部门，其主要工作是施工技术的学习、应用、推广和各项目施工技术方面配合和监督。作用是保证施工技术工作有目的、有计划、有条理地开展，从而完成技术管理的任务。 一、工程技术部岗位职责 （一）工程技术部岗位职责 1、认真贯彻执行国家有关方针、政策和技术标准、规范、规程及施工技术管理制度；有效指导、监管项目工程技术管理状况，提升工程质量，切实支持好、服务好工程项目建设。 2、组织制定和完善企业标准，并对公司技术工作进行具体组织、指导。 3、负责有关技术规程、规范、标准及法律、法规的购买、学习、管理和发放，并确保项目部所使用的规程、规范和标准的准确性和有效性；并定期组织规程、规范和标准的学习。 4、负责审核工程施工组织设计方案和需要论证的专项方案； 5、负责项目施工技术指导、监督工作，组织解决工程技术上存在的问题。对项目工程关键工程、特殊过程进行技术指导，并对技术实施进行跟踪及实施结果进行总结。 6、负责本部门使用文件和资料（含记录）的收发、登记编目、整理、归档和保管工作； 7、配合质检部、安检部做好工程质量、安全控制及事故处理工作，对工程进度监督； 8、配合计划部完成投标施工组织设计的编制工作； 9、参与分部分项工程的评定及竣工验收等工作； 10、推广和应用工程建设“四新”工艺，加快企业技术进步， （二）工程技术部部长岗位职责
1、负责工程技术部全面工作，落实部门岗位职责。 2、负责对本部门工作人员的工作进行安排、检查和督促，确保本部门工作如期、顺利完成。 3、负责监督检查各项目技术管理和推广等工作。 4、参与有关重大质量事故的处理和工程质量的重大决策等工作。 5、组织对各项目施工技术推广、应用及落实的检查、复查等工作，制定相应的奖罚措施并落实。 6、负责向本科室工作人员传达上级有关文件、指示等工作。 7、负责与上级管理部门、市质监部门等相关科室沟通、协调工作，保证工程技术管理顺利进行。 （三）工程技术部科员岗位职责 1、在科长领导下，做好具体工作。 2、日常工作要积极、主动，及时、准确。 3、负责监督检查各项目施工技术管理和推广等工作。 4、随时掌握各项目工程进展和施工技术情况，解决工程实施过程中存在的各类技术问题，对关键性的重大事件及时向有关领导汇报。 5、做好日常检查和定期检查的日程安排和资料整理工作，并根据有关制度、办法对各项目工程施工技术管理和落实情况进行检查，形成书面材料向有关领导汇报。 6、做好现场的技术服务工作，指导解决施工现场技术问题，跟踪技术方案、措施的实施并验证，实现持续改进；负责施工中遇到的技术问题与监理、设计的联系 二、图纸审查和管理制度： （一）施工图纸会审是施工前的一项重要技术准备工作。会审前要认真熟悉图纸，对图中的疑难问题和差错，要分别作好记录，准备好会审意见，对于较复杂的大型工程，会审前由工程技术部组织各专业进行预审，将问题
软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 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.技术文件内容及编码原则 技术文件是指用于产品实现的相应技术文件；文件类别及编码原则详见《技术文件类别清单》。 4.职责 4.1技术质量部负责技术文件的归口管理。负责内部技术文件的编制、审批、发放、归档和借阅的管理；负责外来技术文件的识别、转换、发放和归档。 4.2各部门负责对技术文件的接收、使用、保管。 4.3操作人员应掌握工艺文件及有关标准要求，严格按工艺文件进行操作，发现问题及时向班组长汇报，有责任保管好自己所用的技术文件。 4.4车间班组长负责保管本班组所用的技术文件，生产作业时将技术文件放置在生产现场指定位置。保证技术件不丢失、不损坏、干净整洁。 5.技术文件管理内容 5.1编制技术文件的基本要求 5.1.1凡用于指导生产作业的技术文件均应履行审批、签署手续，外来文件的审批不是对文件内容的审批，而是对文件的适用性的确认。责任签署手续完备的正式技术文件是指导生产及其管理活动的有效文件。 5.1.2 收到顾客提供的产品图纸、产品规范/标准、技术协议、变更文件等与质量 有关的技术文件后，技术部要在两周内或按照顾客要求的进度进行组织评审，确定以上文件的详细的实施方法、实施日期及实施要求，由技术部长批准，及时将
顾客的相应标准转换为公司内部要求并保存相应记录。顾客提供的质量协议由质量部按上述要求评审，由质量部长批准，并保存记录。 5.1.3 FMEA的编制应参考FMEA库进行编制，每个项目应对其涉及到的所有工序的FMEA组织评审后定版； 5.1.4 CP的编制应将定版后的FMEA中的要求有效的传递至CP中且前后保持一致；CP的编制应参考CP的编制模板。 5.1.5 WI的编制应将CP中的要求关联到WI中(excel公式)，防止产生前后不一致的情况发生。 5.1.6 技术文件编制质量问题纳入技术部人员的绩效考核，具体按《技术部人员绩效考核表》进行考核。 5.2 技术文件的签署人及其职责 5.2.1 设计/编制——由授权职能部门的设计人或编制人签署，并对技术文件的完整性、正确性、统一性、先进性、良好的工艺性和经济性负责。 5.2.2审核——由设计/编制单位负责人或分管负责人对技术文件是否符合国家法律、法规、顾客要求、相关标准和使用要求进行综合审查后签署，对其完整性、正确性、统一性负责。 5.2.3会签——由相关部门委托有经验的专业人员对技术文件是否满足相应专业要求的可行性予以审查并签署。 5.2.4 批准——直接用于产品生产过程的技术文件以及厂内有关部门需共同遵照执行的技术文件由技术部长（或被授权人）签署，并对技术文件负总的责任。文件发布后，使用部门在执行中或相关人员在检查，发现有问题需更改时应及时反馈，技术部接到反馈后应及时更改相应技术文件并再次批准。 5.3受控标识
软件配置管理规范 流程 1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件
的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工 作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。 每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再
上海精佑通信技术有限公司企业标准 （管理标准） Q/HT 0001–2005 软件版本管理规定 V1.04 2005-04-11 发布 2005-04-11实施
上海精佑通信技术有限公司 目录 1范围 (4) 2术语和定义 (4) 2.1软件 (4) 2.2产品软件 (4) 2.3生产支持软件 (4) 3软件版本命名规则 (5) 3.1软件版本命名组成 (5) 3.2手机软件版本命名 (5) 3.3模块软件版本命名 (5) 3.4手机PC侧软件版本命名 (6) 3.5模块PC侧软件版本命名 (7) 3.6手机生产支持软件版本命名 (7) 3.7模块生产支持软件版本命名 (8) 3.8公用于所有手机和模块的软件版本命名 (9) 3.9无线上网卡相关软件版本命名 (9) 3.10无线上网卡驱动软件版本命名 (10) 3.11正式版本号的升级规则 (10) 3.12版本的电子文件命名规则 (11) 4软件版本发布流程 (11) 5禁止条例 (14) 6管理条例 (14) 7附录 (14)
上海精佑通信技术有限公司 文档版本变更记录： 版本号拟制日期拟制人版本描述存档编号 V1.00 2005-4-11 郝军初始版本 V1.01 2005-4-27 郝军1．版本号前增加“V”,用以明显标识版 本号 2．版本号和时间之间以下划线分隔 3．增加生产支持软件种类 4．增加无线上网卡生产支持软件、管理 器软件和驱动软件命名 5．增加版本发布流程的文字说明 V1.02 2005-7-1 郝军增加手机和模块生产支持软件的类型：射 频补丁软件（RFP） V1.03 2005-7-15 郝军更改版本号升级规则，更改资料外发申请 表 V1.04 2005-7-26 郝军增加机卡合一版本的命名规则 注：1）拟制、审核、会签、批准不走电子流程时，必须用钢笔或签字笔填写，不得用铅笔、圆珠笔填写。
软件三库管理规范-标准化文件发布号：（9456-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
1目的范围 规定了公司软件开发库、受控库、产品库（以下简称三库）的管理规范。 2参考文献 《软件三库管理制度》 3术语和定义 GitLab：一个仓库管理系统，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。 Jenkins：基于Java开发的一种持续集成平台，用于监控持续重复的工作。 SPM：公司研发部开发的持续集成工具，用于集成软件部署包。 Releaser：公司研发部开发的基于SPM的软件部署包发布工具。 Kiwi TCMS：公司研发部基于开源代码改进的测试用例管理系统，用于测试计划和测试用例的创建和维护、以及测试执行的记录。 4职责 4.1软件三库管理职责 软件开发库由项目组管理，软件受控库由研发部管理，软件产品库由质量部管理。 4.2软件管理员职责 a)具备软件配置管理知识； b)熟悉研制项目的配置管理； c)熟悉公司结构、软件三库管理规定、标识规定和软件配置管理计划。 5管理内容与方法 5.1建立软件三库 5.1.1 开发库 a)开发库代码部分和说明部分基于GitLab建立，按照软件项目分配仓库。 项目组长任仓库Master，负责需求说明的管理、成员管理、问题跟踪、分支Merge、任务分配、Tag标识等工作。 项目组成员任仓库Developer，负责设计和交付说明的管理、问题调查、分支维护等工作。 测试组成员任仓库Reporter，负责测试说明的管理、报告问题、问题回归等工作。 b)开发库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。
项目软件版本号管理规范
历史修改记录 一. 目的
1.1软件版本按照一定的规则保存所有版本，避免发生版本丢失或混淆等现象， 并且可以快速准确的查找到任何版本。 1.2软件版本规范有利于公司各部门之间的对接工作，有利于公司内部资料统一 管理。 1.3本文档是为规范研发部软件版本管理而制定的。 二. 范围 2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容，包括：2.2版本标识方法及管理 2.3版本升级 2.4文档及源码的备份制度 2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作，公司内部使 用按照文档及源码存放备份制度。 三. 版本管理 3.1版本号规则 3.1.1每个归档版本都有两个版本号：内部版本号和外部版本号。版本号使用 VP规则，V(Version)是指外部版本号（研发测试版本），P(Patch)是指补丁版本号（可选）。 3.1.2版本号命名：V/B+主版本号+次版本号+修订版本号+日期版本号
3.2版本号修改规则 3.2.1主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生 变化。此版本号由项目决定是否修改。 3.2.2次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变 动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目决定是否修改。 3.2.3修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩 充，要经常发布修订版，修复一个严重Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 3.2.4日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要 更改日期版本号。此版本号由开发人员决定是否修改。 如： V8.1.0.XXX (上一级版本号有变动时，下级要归零) 3.3版本号修改举例说明 如此时版本号为：V8.1.0.XXX ，此时为内部测试阶段 3.3.1 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为： V8.1.1.XXXX ，如当前日期跟上一个版本号的日期不一样，版本号可改为： V8.1.1.XXX。
技术质量管理制度 一、总则 为加强咨询设计及施工项目的质量管理，保证交付运行的项目能够符合顾客的要求，不断提升技术人员的设计能力及产品的专业品质，特制定此技术质量管理制度。此制度将保障项目设计标准、质量控制标准及流程的管理严格按照GB/T 50380-2006（工程建设设计企业质量管理规范）、GB/T19001-2008（质量管理体系要求）、GB/T 28001—2001（职业健康安全管理体系规范）和GB/T 24001—2004（环境管理体系）等标准管理体系的要求有效运行。最终达到设计产品和施工服务符合顾客要求和适用的法律法规要求，增强顾客满意。 二、质量方针 质量第一，诚信服务，遵法环保，人本管理，持续改进，追求卓越。 质量第一――坚持“百年大计、质量第一、预防为主、终身负责”的管理理念，严格执行国家有关工程设计、建设方面的法律、法规和强制性标准。加强设计和施工的全过程控制管理，认真做好质量安全控制工作； 诚信服务――坚持以顾客为关注焦点，信守承诺严格履行合同，在合同履约过程中做到沟通及时、以诚相待、服务周到。为工程项目设计建造的全过程提供全方位高品质的服务，努力提高顾客满意度； 遵法环保――坚持“依法治企”，认真履行社会责任。严格遵循国家有关环境保护、节能减排降耗等政策，使设计产品和施工过程满足国家法律法规要求； 人本管理――坚持以人为本的经营理念，重视员工的身心健康和合法权益，严格执行相关法律法规和职业健康安全保障措施，保持良好的职业健康安全绩效； 持续改进――坚持不断完善和改进质量管理体系，在过程管理中发现薄弱环节并严格执行纠正预防措施，使设计产品质量和设计施工全过程处于可控在控状态，保持管理体系的有效性、适宜性和充分性； 追求卓越――逐年提高技术质量管理目标，坚持开展行业对标管理，以行业标杆为学习榜样找差距定措施抓落实。保持设计团队的技术和管理不断创新、工程项目力争创优、企业绩效持续改善。
版本管理规范(草案) 研发部 2009-2-4
目录 文档类别使用对象....................................................... 错误!未定义书签。1．引言................................................................ 错误!未定义书签。 目的 .................................................................. 错误!未定义书签。 范围 .................................................................. 错误!未定义书签。 术语定义 .............................................................. 错误!未定义书签。 版序控制记录 .......................................................... 错误!未定义书签。 版本更新记录 .......................................................... 错误!未定义书签。2．版本管理............................................................ 错误!未定义书签。 2．1版本标识方法...................................................... 错误!未定义书签。 2．1．1正式版本..................................................... 错误!未定义书签。 2．2目录结构.......................................................... 错误!未定义书签。 2．3文档的存放........................................................ 错误!未定义书签。 当前版本和历史版本的存放 ........................................... 错误!未定义书签。 开发文档的存放 ..................................................... 错误!未定义书签。 源代码的存放 ....................................................... 错误!未定义书签。 SQL语句的存放...................................................... 错误!未定义书签。 发行文档的存放 ...................................................... 错误!未定义书签。 2．4权限控制管理...................................................... 错误!未定义书签。3．更新管理（版本升级） ................................................ 错误!未定义书签。 版本升级原则 ........................................................ 错误!未定义书签。 新版本的发布 ....................................................... 错误!未定义书签。4．备份管理............................................................ 错误!未定义书签。5．用户版本管理........................................................ 错误!未定义书签。6．研发部统一管理阶段性版本............................................. 错误!未定义书签。 阶段性版本的提交到研发部............................................... 错误!未定义书签。 阶段性版本的发布到公司网站上........................................... 错误!未定义书签。 各项目组新版本内部及时备份。........................................... 错误!未定义书签。7．版本工具的使用...................................................... 错误!未定义书签。 研发部采用SVN配置管理工具............................................. 错误!未定义书签。8．各项目组提交文档及源码以及规则....................................... 错误!未定义书签。 各项目组需要提交的文档................................................ 错误!未定义书签。 目前所管理的产品列表................................................... 错误!未定义书签。9．周报管理制度........................................................ 错误!未定义书签。10．风险管理制度....................................................... 错误!未定义书签。
软件版本管理规范 第一章目的 本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。 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
企业的生产有多个部门，每个部门都有不同的员工管理制度。以下的为某企业技术部管理制度，仅供参考。 第一章总则 第一条为强化生产管理，建立最佳的生产秩序，使生产管理科学化、标准化、规范化，达到产品质量佳、消耗低、效益好的目的，确保公司的生产活动持续、稳定、可控，特制定本办法。 第二条本办法适用于全公司生产管理，即从计划安排、原料进厂、生产过程到成品出库的生产全过程。 第三条制造管理部是负责全公司生产管理的职能机构。公司生产管理分两级：一级生产管理为制造管理部，二级生产管理为生产厂。二级生产管理必须服从一级生产管理指令，并建立二级生产管理办法。 第四条生产管理的各环节、各工序必须遵循节约能源、保护环境、提高质量、降低成本，围绕企业生产经营总目标，做好各项平衡，使其相互衔接、相互协调、紧密配合，组成一个完整有效的生产管理体系。
第二章管理职能 第五条管理职能 1、制造管理部负责公司原燃料采购、物流运输、生产、成品销售和技术质量、能源管理工作，负责公司总体生产组织、调度、指挥和协调工作，负责牵头公司年度、月度生产作业计划的制订与实施，负责日常停产检修计划审批。 2、工程部负责公司生产设备与备品配件的计划、采购和管理，负责公司检修计划的制订和实施，负责公司安全和计量管理。 3、运输部负责码头生产经营管理和公司运输计划的实施，以及本区域的设备和安环管理等。 4、生产厂负责生产区域的生产、技术质量、设备和安环管理等。 第三章生产、能源计划管理 第六条协调公司日常生产，负责公司总体生产、能源计划管理与跟踪实施、牵头制订与实施公司年度和月度生产经营计划、
生产厂日常生产配比审批下发以及日常检修计划审核，负责原燃料和能源介质总体平衡工作，负责生产和能源数据的统计、分析和归档管理工作。 年度生产经营计划是公司生产的指导性文件，是对公司本年度生产的宏观安排，由制造管理部牵头，运输部、生产厂、财务部等各相关部门和单位共同参与制订，经公司领导批准后下发给全公司各部门实施。 第八条月度生产经营计划（包括三个月的滚动计划）是公司日常生产管理的依据，是公司生产任务的统筹安排和考核依据。月度生产经营计划以公司的年度计划大纲为依据，结合年度大中修安排，由制造管理部负责制订，经公司领导批准后下发给全公司各部门实施。 第九条工程部每月20日前将下月“公司大中修计划”（包括三个月的滚动计划）报制造管理部，作为月度生产经营计划安排的依据；每年11月15日前将下年“公司大中修计划”报制造管理部，作为年度生产经营计划安排的依据。 第十条公司各部门收到公司月度生产经营计划后，要严格按照计划组织实施，并制订出本单位的具体运作计划。
软件版本管理规 V1.0.0 文档版本变更记录：
目录 前言 (3) 1 围 (4) 2 术语和定义 (4) 2.1 软件 (4) 2.2 产品软件 (4) 2.3 演示软件 (4) 3 软件版本命名规则 (4) 3.1 软件版本命名组成 (4) 3.2 产品软件版本命名 (4) 3.3 演示软件版本命名 (5) 3.4 正式版本号的升级规则 (6) 3.4.1 软件版本升级规则 (6) 3.4.2 演示版本升级规则 (6) 3.5 版本的安装文件命名规则及存放路径 (6) 4 软件版本发布流程 (7) 5 管理条例 (7) 6 附录 (7)
前言 为规部门产品软件版本的管理与控制，保证产品版本的有效与质量，制定本标准。本标准由移动金融事业部拟制。 本标准于2015年6月首次发布。
软件版本管理规定 1围 本标准规定了移动银行事业部产品软件版本的控制与管理。 本标准适用于移动银行事业部产品软件版本的控制与管理。 2术语和定义 下列定义适用于本标准。 2.1软件 指与产品相关的所有软件，可以分为产品软件和演示软件。 2.2产品软件 已签订合同，有明确交付日期的产品。 2.3演示软件 处于研发阶段，并未正式投入生产的应用。 3软件版本命名规则 3.1软件版本命名组成 产品的正式软件版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 产品的演示版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 3.2产品软件版本命名 产品软件版本的命名规则如下所示：
技术部管理规章制度 职业素养： 尊重领导，团结同事，胸怀大局，服从调配。 热爱岗位，主动高效，敢于负责，认真细致。 讲求原则，遵规守制，注重方法，诚信共赢。 工作能力： 精通业务，胜任岗位，职责明确，方法得当，结果导向。 思维清晰，善于合作，工作有序，措施得力，讲究实效， 计划严谨可执行，过程可控求结果。 综合能力不断增强，按时保质保量完成各项工作任务。 勤奋精神： 积极探索，刻苦钻研，勇于创新，有新思想、新观念、新举措。 勤奋学习，深入研究，善于总结，学习有心得，调研有成果。 细心观察，勤于思考，主动工作。 工作要求： 按时保质保量完成各项工作任务 1.技术部工作管理制度 为了加强技术部工作秩序，提高工作效率，形成整体高效的合力，更好的完成各项工作计划与任务，现制定技术部内部人员工作制度如下，需内部人员谨记遵守。 1 团结、协作、高效、严谨的作风完成部门各项工作计划与任务。 2 按照工作内容、工作计划、岗位职责，考核目标，按时完成工作任务。
3 部内工作人员要积极配合，团结协作，及时做好相互补位工作。 4 工程技术部每周举行部门例会一次，由部门经理主持，工程师参加。每次例会后，应在下周一内将会议纪要上报公司主管经理。 5每周未提出部门上周工作执行情况及下周工作安排上报主管部门经理或总工程师。 6出现重大质量、服务或客户投诉事故，立刻安排相关人员处理。处理的同时，应上报处理技术方案以及费用分析方案给公司主管经理，以便公司正确决策。 7遵守劳动纪律，有事提前一天请假，向主管交代工作进行情况，保持工作的连续性。 8 保持办公环境安静、整齐、有序，工作时间禁止吃零食。 9 各项对外活动和服务，尊重公司整体形象和服务质量。 10 工作中注意本部门与其他部门的协调、合作，为工作的整体性负责。 11 杜绝工作中的个人利益行为。 12 所有方案设计文件、工艺要求编制实行审批制度，即设计人员自校、自审，审核人审核，批准人审批，保证设计质量，为设计工作的准确性负责。 13执行企业各项管理制度。 2.数据安全及方案图纸保密管理 1 计算机病毒防范 2技术部人员应有较强的病毒防范意识，定期进行病毒检测(特别是邮件服务器)，发现病毒立即处理并通知管理部门或专职人员。 3 数据保密及数据备份
软件配置管理规定 为进一步加强软件配置管理工作，明确软件配置原则，规范软件配置流程，制定本规定。 一、配置原则 1.软件配置遵循安全性、适用性、经济性和正版化的原则，不得配置非正版软件。 2.单位使用的商业软件、OEM软件、免费软件均需纳入配置管理，不得配置与工作无关的各类软件。 3.优先采用场地授权（许可）方式配置软件。 二、配置流程 1.软件使用部门根据本部门各岗位工作需要，编制岗位软件需求清单，填写《软件使用需求申请表》（附件1）。 2.信息化部门统计、汇总软件使用部门报送的《软件使用需求申请表》，对软件使用部门需要的相关软件进行统一测试和试用，综合考虑软件的价格、兼容性、安全性和售后服务等因素，确定软件选型，明确软件名称和版本。涉及使用免费软件的，更新《可使用免费软件清单》（附件2）。 3.信息化部门依据单位软件使用管理台账，梳理单位软件需求与现有软件许可的差异。单位软件许可不足的，编制《软件采购计划表》（附件3）。
4.财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年限、兼容性和售后服务等要求。 5.财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作，重点是软件采购合同、软件授权证书、软件安装序列号等资料的管理工作。 6.信息化部门负责软件使用管理日常工作。 7.单位采购的软件，因以下情况申请报废的，需经过信息化部门鉴定，严格履行资产处置报批手续：（1）已经达到规定的最低使用年限，且无法继续使用的。 （2）未达到规定的最低使用年限，因技术进步等原因无法继续使用的。 （3）未达到规定的最低使用年限，因计算机硬件报废，且无法迁移到其他计算机上继续使用的。 8.信息化部门在单位新采购软件、报废软件和调整可使用免费软件清单后，更新《软件使用情况汇总表》（附件4）。
项目版本管理规范 版本控制 1.1.目的 按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确的查找到配置项的任何版本。 1.2.角色与职责 所有项目成员都必须遵照版本控制规程操作配置库 1.3.配置项状态变迁规则 配置项的状态有3种：“草稿”（Draft）、“正式发布”（Released）和“正在修改”（Changing）。配置项状态变迁如图所示： 配置项刚建立时其状态为“草稿”。配置项通过评审（或审批）后，其状态变为“正式发布”。此后若更改配置项，必须依照“变更控制规程”执行，其状态变为“正在修改”。当配置项修改完毕并重新通过评审（或审批）时，其状态又变为“正式发布”，如此循环。 1.4.配置项版本号规则 配置项的版本号与配置项的状态紧密相关。 ?处于“草稿”状态的配置项的版本号格式为：0.YZ。YZ数字范围为01－99。随着草稿的 不断完善，“YZ”的取值应该递增。“YZ”的初值和增幅由项目组成员自己把握。 ?处于“正式发布”状态的配置项的版本号格式为：X.Y。X为主版本号，取值范围为1－9。 Y为次版本号，取值范围为0－9。配置项第一次“正式发布”时，版本号为1.0。如果配置项的版本升级幅度比较小，一般只增大Y值，X值保持不变。只有当配置项版本升级幅度比较大时，才允许增大X值。
处于“正在修改”状态的配置项版本号格式为：X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态重新成为“正式发布”时，将Z值设置为0，增加X.Y值。 1.5.版本控制的主要步骤 1.5.1.创建配置项 项目成员依据《配置管理计划》，在配置库的开发库中创建属于其任务范围内的配置项。此时配置项的状态为“草稿”，其版本号格式为0.YZ。 1.5. 2.修改处于“草稿”状态的配置项 项目成员使用配置管理软件的Checkout/Checkin功能，可以自由修改处于“草稿”状态的配置项（不受变更控制规程约束），版本号格式为0.YZ。 1.5.3.评审和CCB审批 配置项定稿后要接受评审和CCB审批。 1.5.4.配置项入基线库 配置项通过评审和CCB批准后，由配置管理员纳入基线库，则配置项的状态从“草稿”变迁为“正式发布”，版本号格式为X.Y。 1.5.5.版本发布 基线库里有新的配置项产生，或者基线库里的配置项版本升级时，配置管理人员要做版本发布，通过会议或EMAIL等方式通知项目组内其它人。通知中需要指明配置项在配置管理库中的目录名、文件名、版本号。
技术部管理制度及职责 1目的： 规定技术部的工作范围、职责、制度和考核，为公司生产、经营提供技术保证。 2范围： 公司技术岗位的从业人员。 3职责： 3.1负责公司产品开发的策划与实施，APQP计划的制定； 3.2负责提供产品图纸，保证产品图纸的完整性、准确性和有效性。 3.3负责编制产品工艺文件、检验文件和控制计划。 3.4负责技术改造、工艺改善、工艺验证工作。 3.5负责与客户进行产品技术问题的沟通与协商。 3.6负责对不合格品产生的原因进行调查、分析；为解决产品质量问题提供技术方案。 3.7负责提供产品清单，进行原材料成本核算。 3.8负责产品新技术、新工艺、新材料的应用。 3.9参与合同评审和对合格供方的评价。 3.10负责数据分析管理工作及纠正、预防措施的评审工作。 3.11负责技术方面的培训工作。 3.12负责技术文件的管理、存档、借阅、发放工作。 4制度： 4.1技术部任职人员应遵守法律、法规和公司各项规章制度。
4.2技术部任职人员应工作认真、态度严谨，保证工作的准确性。 4.3技术部任职人员应反应迅速、态度积极，及时为生产提供技术支持。 4.4技术部任职人员应忠于企业、保守秘密，不得向与公司行为无关的单位或者个人透露公司技术信息、技术文件。 4.5技术部任职人员应积极学习，不断进步，不断提高自己的技术水平。 4.6所有技术文件应妥善保存，计算机内的文件应及时备份、存档。未经允许不准将技术文件转借他人或私自带出公司。 5考核 5.1公司对技术部采取项目绩效考核的方法，以激励技术人员工作积极性。技术部对绩效考核奖金实行内部分配的办法，参与项目的人员分配办法另行规定。 5.2技术人员所设计的产品图纸应认真审核，做到正确无误，凡是因设计错误给公司造成经济损失的应当接受处罚。处罚金额如下：a.损失金额在50万元（含50万元）以上的，扣除当月工资的50%和自发生时直到年底的月度奖金、季度奖金、年度奖金； b.损失金额在20万元（含20万元）以上，50万元以下的，扣除当月工资的50%和自发生时当月的月度奖金和季度奖金； c.损失金额在5万元（含5万元）以上，20万元以下的，扣除当月工资的50%和自发生时当月的月度奖金； d. 损失金额在1万元（含1万元）以上，5万元以下的，扣除当月工
1 目的范围 规定了公司软件开发库、受控库、产品库（以下简称三库）的管理规范。 2 参考文献 《软件三库管理制度》 3 术语和定义 GitLab：一个仓库管理系统，使用Git作为代码管理工具，并在此基础上搭建起来的web服务。 Jenkins：基于Java开发的一种持续集成平台，用于监控持续重复的工作。 SPM：公司研发部开发的持续集成工具，用于集成软件部署包。 Releaser：公司研发部开发的基于SPM的软件部署包发布工具。 Kiwi TCMS：公司研发部基于开源代码改进的测试用例管理系统，用于测试计划和测试用例的创建和维护、以及测试执行的记录。 4 职责 4.1软件三库管理职责 软件开发库由项目组管理，软件受控库由研发部管理，软件产品库由质量部管理。 4.2软件管理员职责 a)具备软件配置管理知识； b)熟悉研制项目的配置管理； c)熟悉公司结构、软件三库管理规定、标识规定和软件配置管理计划。 5 管理内容与方法 5.1建立软件三库 5.1.1 开发库 a)开发库代码部分和说明部分基于GitLab建立，按照软件项目分配仓库。 项目组长任仓库Master，负责需求说明的管理、成员管理、问题跟踪、分支Merge、任务分配、Tag标识等工作。 项目组成员任仓库Developer，负责设计和交付说明的管理、问题调查、分支维护等工作。 测试组成员任仓库Reporter，负责测试说明的管理、报告问题、问题回归等工作。 b)开发库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。
项目组成员负责维护自动测试脚本和版本生成脚本。 Jenkins管理员（计算机）任库管理员，负责自动检查代码编译结果，执行版本生成脚本将通过检查的工程生成待测软件部署包，执行自动测试脚本验证软件部署包，将通过验证的软件部署包打上标识，放入仓库。 另任库管理员，负责出入库管理、配置项管理等工作。 5.1.2 受控库 a)受控库代码部分基于GitLab建立，按照软件项目分配仓库。 软件经理任仓库Master，负责将通过完整测试的开发版本打上Tag标识，在GitLab 上作为独立稳定的分支，该分支不接受更改，有效受控。 b)受控库部署包部分基于Jenkins和SPM建立，按照软件项目分配仓库。 Jenkins管理员（计算机）任库管理员，负责将打上Tag标识的代码版本生成软件部署包，打上同样的Tag标识，放入仓库。 该部分目录及目录下文件一旦生成，不可删除或更改，有效受控。 c)受控库说明部分存在于公司内部的公共服务器。 另任库管理员，负责出入库管理、配置项管理等工作。 d)受控库测试用例部分基于Kiwi TCMS建立，按照软件项目分配仓库。 项目组长具有测试计划审核权限，测试组长具有测试用例编辑和测试用例审核权限，测试组成员具有测试用例编辑权限。 5.1.3 产品库 产品库存在于公司内部公共服务器，按照软件项目分配仓库。 另任库管理员，利用Releaser工具将通过申请的打上Tag的受控版本生成软件产品包，负责各产品的出入库管理、配置项管理等工作。 5.2制定三库管理规定 5.2.1 内容要求 软件三库管理规定： a)入库控制 相关人填写入库申请，负责人审批，库管理员操作或检查入库，详见三库管理要求（第5.4、5.5、5.6节）。 b)访问控制 各仓库设置权限管理，一般来说，给予库管理员写权限，给予相关人读权限，详见三库管理要求（第5.4、5.5、5.6节）。