研发中心产品版本管理规范
研发中心产品测试管理规范
目录1 目的 (3)2 范围 (3)3 定义 (3)4 权责 (3)5 管理程序 (4)5.1测试工作的组织 (5)5.2测试相关工作要求 (5)5.3测试工作的执行 (6)6 相关流程 (8)7 相关附件 (8)8 相关表单 (8)9 其它 (8)研发中心产品测试管理规范1目的管理和指导产品测试工作的有序进行，验证产品软件和硬件是否满足产品需求说明书、技术指标和产品设计说明书。
2范围适用于公司研发产品的各个测试阶段，涉及所有产品测试人员及相关人员。
3定义3.1HW测试：产品硬件测试(Hardware)，包括常温测试和高低温测试；3.2FW测试：产品固件测试(Firmware)，包括ISaGRAF、DNP3协议、MODBUS协议等；3.3SW测试：上位机软件测试(Software)，如ESet2010、FlexESet、SuperESet等；3.4压力测试：产品应用程序最大负载测试，结合产品性能测试；3.5系统测试：模拟现场环境测试；3.6机械适应性测试：包括振动测试、冲击测试等；3.7EMC测试：包括静电放电测试、电快速瞬变脉冲群测试和浪涌（冲击）测试等；3.8型批测试：取证产品测试。
4权责4.1研发项目经理4.1.1组织制定测试计划；4.1.2提交测试申请并提供测试样机；4.1.3协调解决产品测试过程中遇到的问题；4.1.4对测试发现的BUG进行组织整改关闭。
4.2产品研发部门4.2.1对测试过程中遇到的问题进行技术支持；4.2.2对测试发现的BUG进行整改解决。
4.3测试部4.3.1编写测试计划、测试大纲、测试用例；4.3.2执行测试用例并记录测试数据；4.3.3分析和总结产品测试情况并出具测试报告，提供产品质量参考数据；4.3.4对不满足测试需求的测试申请，停止测试工作并通知测试申请人。
5管理程序5.1测试工作的组织5.1.1在项目立项后，项目经理组织测试部相关人员参与测试工作。
5.1.2项目经理根据《产品需求说明书》、《技术指标》和相关文档组织制定测试计划，由相关测试工程师负责编写测试大纲和测试用例。
研发中心规章制度汇编模板
研发中心规章制度汇编模板第一章总则第一条为规范研发中心的内部管理，提高研发工作效率，促进团队协作，保障研发成果的保密性和安全性，特制定本规章制度。
第二条研发中心是公司的核心部门，主要负责公司产品研发工作。
研发中心依据公司的战略规划和业务需求，制定相应的研发计划，并组织实施。
第三条所有人员在研发中心工作期间，必须遵守本规章制度的规定，不得违反公司制度和国家法律法规。
第四条研发中心向全体员工提供公平的职业发展机会和良好的工作环境，鼓励员工创新、学习和成长。
第二章组织架构第五条研发中心设立总经理一职，负责中心的日常管理和业务运作。
第六条研发中心设立研发部、技术部、设计部等部门，各部门负责不同的工作内容。
第七条研发中心由各部门负责人组成管理团队，共同参与决策和管理。
第八条研发中心设立项目组，每个项目组由项目负责人领导，负责具体的研发项目。
第三章人员管理第九条研发中心的员工要求具有良好的专业素养和团队合作精神，严格遵守公司规定，保守商业秘密。
第十条研发中心的员工应当按照岗位要求，认真履行职责，努力完成研发任务。
第十一条研发中心的员工应当不断提高自身的技术水平和专业能力，积极参与培训和学习。
第四章工作流程第十二条研发中心依据公司业务需求和研发计划，制定研发工作流程，明确各项工作任务的分工和时间节点。
第十三条研发中心的项目组负责具体的研发项目，项目组成员要积极配合，确保项目按时完成。
第十四条研发中心要加强内部协作，促进各部门之间的沟通和合作，实现项目的无缝衔接。
第五章安全管理第十五条研发中心要加强设备和信息安全管理，做好机密信息的保护工作，防止泄露和丢失。
第十六条研发中心要加强安全教育和培训，提高员工的安全意识和应急能力，确保研发工作的顺利进行。
第六章保密制度第十七条研发中心的员工在工作期间获取的商业机密和公司数据，仅限于工作需要使用，不得私自外泄。
第十八条研发中心的员工在离职后，应当交还所有公司资料和机密信息，不得擅自保留或传播。
BOM管理规定
BOM管理规定1目的1.1BOM是记录研发成果，反映公司产品物料构成关系的数据文件，自下而上反映公司产品从原材料到半成品，再到成品的加工过程，是指导生产、计划、采购、成本核算及技术管理的基础数据，是ERP系统的核心主导文件之一。
BOM的正确与否，直接影响到生产、计划、采购、成本的准确性与可信度。
1.2为明确各部门的职能分工，提高BOM清单的准确性，降低因BOM创建、更改错误而给生产带来的不利影响。
及时反馈、解决生产过程中 BOM异常问题，严肃BOM更改纪律，规范 BOM的更改行为，以确保质量和生产过程的顺利进行，提高工作效率，特制定此管理规定。
2适用范围2.1本规定适用于工程部BOM搭建、BOM表编制过程及其管理要求。
3职责3.1研发中心、机械设计部工程师：提供所承担项目产品的BOM表编制之原始依据并保证其正确性（图纸、部件清单、外协外购清单）。
3.2工程部BOM工程师：BOM搭建、BOM表编制，准确、及时制作BOM以满足生产需求。
3.3计划部计划员：提供本期生产任务资料。
3.4生产、采购、计划等部门：BOM结构、BOM表接收单位，问题及时反馈信息至工程部BOM工程师。
3.5工程部经理负责BOM的审核、评审组织及BOM相关工作的争议协调解决。
4BOM编制及管理流程4.1BOM表编制前的要求：BOM表必须是在有《产品配置表》、《试制图纸》、《装配清单》、《外协外购清单》的情况下，试装完样机及相应软件调试好，有结项目报告之后，核实完配有《下载说明》再搭建。
4.2BOM表编制依据4.2.1B OM制作依据以下文件：1）、《产品配置表》、2）、《试制图纸》、3）、《BOM 清单》、4）、《物料编码表》、5）、《样机装配记录单》及样机试装情况。
4.2.2B OM搭建遵循六大原则：产、供、销、存、虚、委。
4.2.3产：是否要单独下发生产任务对半成品下发生产任务指令，则需考虑对生产任务的半成品进行分层。
4.2.3.1供：半成品是否会直接采购, 如果工厂半成品本身有可能会直接销售，也应考虑将此半成品进行分层，做一个单独 BOM。
软件研发中心管控流程
.................................................................................................................................................................................................1.1 需求分析 (4)1.2 需求评审 (5)1.3 产品设计 (5)1.4 UI 设计 (6)..........................................................................................................2.1 开发评审 (7)2.2 概要设计 (8)2.3 详细设计(非必需) (9)2.4 编码 (9)2.5 单体测试 (10)2.6 集成测试 (10)2.7 提测 (11)2.8 产品验收 (12)........................................................................................................3.1 产品发布 (13)3.2 产品运营 (13)....................................................................................发布阶段通过调研市场、业务部门反馈等渠道获取需求，并进行详细分析。
这一阶段主要目的是从总体上把握产品规划方向和趋势，了解自身产品的业务流程、硬件和软件环境等，并结合同类竞品分析的情况，整理出产品需求的优先级、权重等，以便后续设计和研发工作的实施。
产品设计部需求分析报告对需求进行分类，筛选出可行性需求，根据四“象限定位法”进行需求分位，明确需求优先级。
公司产品研发管理制度范本
公司产品研发管理制度范本一、目的和范围本制度旨在规范公司的产品研发流程，确保研发活动的有效性和效率，以及研发成果的质量和创新程度。
适用于公司内所有涉及产品研发的部门和员工。
二、组织结构和职责（一）研发管理委员会负责制定研发战略，审批重大研发项目，监督研发进度和质量。
（二）研发部负责具体的产品设计、开发、测试等工作，以及与其他部门的协调沟通。
（三）市场部负责市场调研，收集用户需求，为研发提供市场导向。
（四）质量控制部负责产品质量标准的制定和监督，确保产品符合相关标准和法规。
三、研发流程管理（一）需求分析1. 市场部进行市场调研，提出新产品的需求分析报告。
2. 研发管理委员会评审需求报告，决定是否立项。
（二）项目立项1. 研发部根据立项要求，制定详细的研发计划。
2. 研发计划包括目标、预算、时间表、人员分配等。
（三）设计与开发1. 设计团队根据需求进行产品设计，包括原型制作和功能定义。
2. 开发团队按照设计图纸进行产品开发，编写代码并进行初步测试。
（四）测试与改进1. 质量控制部对产品进行全面测试，确保无缺陷。
2. 根据测试结果进行产品改进，直至满足质量标准。
（五）生产与上市1. 确定产品生产计划，准备生产线。
2. 产品上市前进行市场推广，制定销售策略。
四、知识产权管理保护研发过程中产生的知识产权，包括专利申请、商标注册等。
五、风险管理识别研发过程中可能出现的风险，并制定相应的应对措施。
六、绩效评估与激励定期对研发团队的工作进行绩效评估，对优秀团队和个人给予奖励。
七、持续改进鼓励创新思维，持续优化研发流程，提高研发效率和产品质量。
研发规范-版本管理规范
版本管理规范(Version 1.0)XX科技有限公司2014年6月版本管理规范1 目的 (4)2 适用范围 (4)3 版本管理规范 (4)3.1 版本管理工具 (4)3.2 版本库目录结构 (4)3.3 版本命名规范 (5)3.3.1 产品名称 (5)3.3.2 版本号 (5)3.3.3 版本标识 (5)3.4 版本提交规范 (5)1 目的标识、控制和追踪软件开发和实施过程中产生的各种软件产品版本。
2 适用范围适用于研发中心相关项目和产品所有软件文档和源代码版本的管理。
3 版本管理规范3.1 版本管理工具采用Subversion（SVN）进行版本管理。
3.2 版本库目录结构版本库目录结构如下所示：第一层目录为wasu_XXXX(XXXX为项目或产品名称缩写)，每个项目或产品的下层目录结构(第二层目录)如下：trunk 主开发目录branches 分支开发目录release_tags 发布版本存档目录（不允许修改）这三个目录每个目录下层目录结构(第三层目录)统一如下：doc 存放开发过程中的文档src 存放代码一般的，我们的所有的开发都是基于trunk进行开发，当一个版本/release开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码处于冻结状态（人为规定）。
此时应该基于当前冻结的代码库，打tag。
当下一个版本/阶段的开发任务开始，继续在trunk进行开发。
此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing V ersion）无法满足时间要求，这时候就需要在上一个版本上进行修改了。
应该基于发行版对应的tag，做相应的分支（branch）进行开发。
例如，刚刚发布1.0，正在开发2.0，此时要在1.0的基础上进行bug修正。
按照时间的顺序：1. 1.0开发完毕，代码冻结2.基于已经冻结的trunk，为release1.0打tag此时的目录结构为svn://proj/+trunk/? (freeze)+branches/+release_tags/++tag_release_1.0(copy from trunk)3. 2.0开始开发，trunk此时为2.0的开发版4.发现1.0有bug，需要修改，基于1.0的tag做branch此时的目录结构为svn://proj/+trunk/? ( dev 2.0 )+branches/++branch_dev_1.0_bugfix (copy from tag/release_1.0)+release_tags/++tag_release_1.0(copy from old trunk)5.在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发6.在1.0 bugfix 完成之后，基于branch_dev_1.0_bugfix的branch做release等7.根据需要选择性的把branch_dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况）3.3 版本命名规范3.3.1 产品名称新产品立项时，为产品赋予版本库中的产品名称；当已有产品升级时，则沿用前一版本产品的名称。
公司产品研发管理制度
公司产品研发管理制度第一章总则第一条为了规范公司产品研发工作，提高研发效率，确保产品质量，制定本制度。
第二条本制度适用于公司所有产品研发部门和相关人员，包括产品经理、研发工程师、测试工程师等。
第三条公司产品研发工作必须遵循科学、规范和创新的原则，注重团队协作，确保研发工作的顺利进行。
第二章产品研发管理机构和职责第四条公司设立产品研发部门，负责公司所有产品研发工作的组织、协调和管理。
第五条产品研发部门下设产品研发经理、研发工程师、测试工程师等职务，各职务负责具体的研发工作。
第六条产品研发经理负责制定产品研发计划、安排研发任务、监督研发进度等工作。
第七条研发工程师负责具体的产品研发工作，包括需求分析、设计、开发、测试等环节。
第八条测试工程师负责对研发的产品进行全面测试，确保产品的质量和稳定性。
第三章产品研发管理流程第九条产品研发工作必须遵循流程化管理，确保研发工作有条不紊地进行。
第十条产品研发流程包括需求分析、设计、开发、测试、发布等环节。
第十一条需求分析阶段，产品经理负责收集用户需求，制定产品规划，明确产品功能和特性。
第十二条设计阶段，研发工程师根据需求文档进行系统设计，确定技术方案和开发计划。
第十三条开发阶段，研发工程师按照设计方案进行编码和调试工作，确保代码质量和性能。
第十四条测试阶段，测试工程师对产品进行系统测试、性能测试、稳定性测试等，发现并解决bug。
第十五条发布阶段，研发工程师将测试通过的产品发布到线上，确保产品正常使用。
第四章产品研发管理制度执行第十六条产品研发部门负责对本制度的执行进行监督和督促。
第十七条产品研发部门负责组织研发人员进行相关培训，提高研发人员的能力和素质。
第十八条产品研发部门必须定期进行研发工作检查和总结，及时发现问题并进行改进。
第十九条产品研发部门必须加强团队协作，建立良好的工作氛围，提高团队凝聚力和战斗力。
第五章附则第二十条本制度由产品研发部门负责解释和修订。
第二十一条本制度自发布之日起生效。
研发中心管理流程和规范_V1.0
未经允许，文档内容不可全部或者部份发表、复制、使用于任何目的。
作者/参预者修订说明章节号审核者版本日期CAD M1. 目的 (1)2. 合用范围 (1)3. 研发中心组织结构 (1)3.1. 研发中心架构 (1)3.2. 组织结构 (1)3.3. 部门岗位 (3)4. 岗位职责 (4)4.1. 软件部主管岗位职责 (4)4.2. 硬件部主管岗位职责 (4)4.3. 机械结构部主管岗位职责 (5)4.4. 质量部主管岗位职责 (6)4.5. 系统方案部主管岗位职责 (7)4.6. 产品经理(项目经理)岗位职责 (8)5. 项目管理规范 (9)5.1. 项目流程概述 (9)5.2. 项目来源 (10)5.3. 立项 (10)5.4. 设计 (11)5.5. 实现 (11)5.6. 测试 (12)5.7. 发布 (12)5.8. 生产 (13)5.9. 实施细则 (13)6. 资料管理规范 (13)6.1. 日常资料备份 (13)6.2. 资料归档 (14)6.3. 资料安全管理 (14)6.4. 资料服务器管理 (14)6.4.1. 管理方式 (14)6.4.2. 资料目录 (15)6.4.3. 管理权限 (17)7. 例会及报告制度 (17)7.1. 项目例会 (17)7.2. 部门例会 (17)7.3. 个人周报 (17)7.4. 项目周报 (18)8. 员工入职管理流程 (18)8.1. 新员工入职要求 (18)8.2. 新员工入职流程 (18)9. 员工离职管理流程 (19)10. 办公用品使用规范 (19)10.1. 办公用品分类 (19)10.2. 办公用品使用规定 (19)11. 办公场所行为准则 (19)12. 附则 (20)为加强对研发中心的管理、提高研发工作效率、明确研发中心职能及规范开辟工作，特制定本规定。
本文件合用于研发中心全体人员。
研发中心软件开辟部硬件开辟部机械结构部质量管理部系统方案部研发中心采用“平衡矩阵型组织结构”组织项目研发活动。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
××××网络产品版本管理规范[草稿]目录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)1.引言版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。
版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。
1.1. 目的本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。
1.2. 范围本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括：●版本标识方法●软件系统数据的存放●文档的修改控制●文档的备份制度1.3. 术语定义SCM软件配置管理（Software Configuration Management）缩写SVM软件版本管理（Software Version Management）缩写SVN一个开源的版本控制系统Subversion.文档一种数据媒体和其上所记录的数据。
配置管理标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。
软件配置软件的具体形态在某时刻的瞬时影像。
配置项软件配置管理的对象称为配置项，如：系统规格说明书，项目开发计划，用户手册，源码。
基线软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确化，使本来连续的工作在这些点上断开，使之便于检验和肯定阶段成果。
1.4. 参考资料《软件版本管理规范》浪潮集团山东通用软件有限公司《泰豪软件开发软件版本管理制度》《tortoise SVN的使用手册》1.5. 版本控制记录1.6. 版本更新记录2.版本管理2.1. 版本标示方法为了使工作规范化、统一化，研发本部各部门实行的版本标识管理方法。
2.1.1.正式版本软件版本号由四部分组成，X.Y.Z.DATA_希腊字母，X：主版本号，用来表示提供给客户的产品功能的主要增强。
在一个极端的例子中，主版本号的上升用来说明产品现在已经拥有了一个全新的功能类。
从市场和许可权的角度来看，主版本号的升级相当于购买一个完全独立的产品。
从开发者角度来看，一个主版本号的迭代差不多总是反映了一个新的独立分支或是其主干还可以延续主版本的生命期。
Y：特征版本号，用来表示产品新增了一些特征，或者是在原来文档中描述的特征上作了重要的修改。
用来确定特征版本号什么时候需要修改的一个衡量标准就是产品功能说明书。
产品的特征版本升级是在主版本之间保持产品竞争力的一种重要机制。
Z：缺陷修复版本号，用来表示在该版本上所做的缺陷维护行为的等级。
版修复版本是稳定市场和最小化客户技术支持费用负担的一种重要机制。
Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。
该版本有时也称为标准版。
一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(R)。
例如：1.1.1.051021_beta.第一个1为主版本号，第二个1为子版本号，第三个1为阶段版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。
2.2. 目录结构由于各部门的实际情况不同，目录结构很难统一，但为了能更好地管理各部门部文档，建议可将被管理的配置项分为三大类：文档类、源码类及安装盘类，这样存放比较清晰，有利于版本管理。
具体目录如下表格所示：2.3. 文档的存放2.3.1.开发文档的存放文档归档流程：2.3.2.源代码的存放2.3.3.SQL的语句存放各子系统SQL文件放入…..\.......\SQL下，对于不同的数据库，分别建立不同的子目录，如WAT、SYB、MSS、ORC、DB2等。
公共SQL文件直接放入…\SQL 下即可，不同数据库的特殊SQL分别放入对应的子目录下。
2.3.4.发行文档的存放发行文档是指产品交付用户使用所必须的文件。
包括：产品可执行文件，用户使用说明书，联机帮助（HLP）；资源文件（BMP，ICO等），环境配置文件等。
2.4. 配置管理流程流程说明：1.开发人员完成所负责代码模块的编写任务后，提交到项目经理处；2.项目经理向测试部提交测试任务；3.配置管理员准备测试所需环境；4.测试员开始测试并提供实时测试BUG；5.开发人员处理测试人员提供的BUG，并提交测试员进行回归测试，直至BUG 关闭；6.测试完成后，测试人员提供测试报告；7.根据项目情况决定是否发布新版本；8.配置管理员与各成员确定好新版本的各项信息；9.配置管理员发布新版本。
2.5. 权限控制的管理为保障文档的安全性，一致性，以及防止意外修改，必须对不同的文档设置不同的访问权限。
文档权限类别：只读权限，读写权限。
文档类别：DOC，SRD，RELEASE。
用户类别：开发人员、测试人员、分析设计人员、部门经理、配置管理员、安装盘制作人员、问题及需求管理人员、用户文档编写人员等。
为了控制不同的使用权限，根据要求在服务器上分别建立不同的用户，针对不同的配置项所在目录分配不同的权限。
为了便于各部门的管理，应以表格的形式列出人员与管理对象的访问关系（用户权限清单）。
3.更新管理3.1. 源程序的修改当开发小组在开发同一产品时，应能保障：各成员间的修改不会互相覆盖；程序员的修改能及时反映到产品的最新版本中。
建议首先在相应子系统的下一级建一目录，如checkout，存放正在修改的文档及修改登记表。
当某个程序员要修改某一文档时，遵循以下程序：1)接收维护任务；2)查看需要修改的文件（如PBL及SQL等）是否正在被其它人员修改（检查checkout目录下是否存在要修改的文件或后缀已改为该程序员姓名简写）；3)如果有人在修改该文件，等待或与相应的开发员联系，重复2。
否则继续；4)将该文件复制到checkout目录下，在修改登记表中登记；或将该文件的后缀改为本人姓名简写；5)将该文件拷贝到自己的私有目录；6)根据要求修改源文件；7)根据要求测试，并进行相关项的回归测试；8)交测试人员测试，如未通过，重复6，如通过则继续；9)在checkout目录中删除该文件，并在修改登记表中标注修改完成；10)将修改完毕的文件通过电子邮件或其它手段送交版本管理员，版本管理员将文件复制到相应的路径；如遇特殊情况（版本管理员出差），程序员可将修改完毕的文件复制到相应的路径下，或将后缀改回正式。
11)回复下达者，报告维护任务完成。
3.2. 版本升级3.2.1.版本升级原则版本升级应严格纳入版本管理的控制之下。
应当谨慎地控制版本的升级，保障高版本的向下兼容性，或提供严格定义的升级方法。
主版本号(1)：当功能模块有较大的变动，比如增加多个模块或者整体架构发生变化。
此版本号由项目决定是否修改。
子版本号(1)：当功能有一定的增加或变化，比如增加了对权限控制、增加自定义视图等功能。
此版本号由项目决定是否修改。
阶段版本号(1)：一般是Bug 修复或是一些小的变动，要经常发布修订版，时间间隔不限，修复一个严重的bug即可发布一个修订版。
此版本号由项目经理决定是否修改。
日期版本号(140606):用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。
此版本号由开发人员决定是否修改。
希腊字母版本号(beta):此版本号用于标注当前版本的软件处于哪个开发阶段，当软件进入到另一个阶段时需要修改此版本号。
此版本号由项目决定是否修改。
3.2.2.新版本发布新版本的发布包括主版本号和次版本号的升级，一般不包括内部版本号的升级。
流程如下：1)接收新版本发布任务，接收本次发布的版本代号。
2)在指定目录中，根据本次发布的版本号建立相应的子目录，将current下的所有内容拷贝至新建目录下。
3)可在新建目录下建立readme.txt，并加入相应的内容。
3.3. 文档的变更文档变更流程：4.备份管理为了保证文档的最大可恢复性，要随时及定期地进行备份工作。
1)随时备份：①开发人员每天都要将自已当日修改的源文件在本地机器上进行备份。
②开发负责人每天要将所有源文件在本地机备份。
③建议备份采用循环备份。
2)定期备份①备份形式为硬盘备份和光盘备份。
硬盘备份时，要备份在独立的硬盘上；光盘备份时，要将光盘存放在可靠的地方。
②备份周期视各部门的具体情况而定。
如果处于开发阶段，每周应对所有的源程序项进行备份，一般为每周周五；如果处于其它阶段，根据具体情况而定，但周期不能超过两周。
③备份要由版本管理员负责，备份原则应是保证文档的最大可恢复性。