产品软件及用户指导类手册版本编号规则

软件产品用户手册编写指导规范一、引言软件产品用户手册是为了帮助用户快速了解和使用软件产品而编写的重要文档。

良好的用户手册能够使用户轻松上手，减少用户对技术支持的需求，提升用户满意度。

本文将从整体结构、语言规范、内容要点等方面为编写软件产品用户手册提供指导规范。

二、整体结构1. 标题页在用户手册的开头添加标题页，包括软件名称、版本号、日期和版权信息，以便用户准确标识和识别。

2. 目录为了方便用户查找和快速定位所需信息，编写用户手册时应包含详细的目录，并准确标识每个章节的页码。

3. 简介简介部分应包括软件产品的背景介绍、主要特点和功能以及适用范围等内容，帮助用户快速了解软件产品的概况。

4. 安装与配置在此部分中，需要提供清晰、详细的安装步骤和配置指导，包括软件的系统要求、安装前准备、安装步骤、常见问题解答等相关信息。

5. 使用说明使用说明是用户手册的核心内容，需要通过简洁明了的语言，逐步介绍软件的使用方法、操作步骤和功能说明。

可以结合图文并茂的方式，提供示意图和操作界面截图，以便用户更好地理解和使用。

6. 常见问题与故障排除在用户手册中添加常见问题与故障排除的章节，列举常见问题及解决方法，帮助用户自行排查故障和解决常见问题。

7. 版权和免责声明在用户手册的结尾部分，添加版权和免责声明，明确软件产品的知识产权归属和免责条款，保护软件开发方的合法权益。

三、语言规范1. 使用简洁明了的语言用户手册的语言应尽量简洁明了，避免使用过于专业的术语或太过晦涩的词汇，保持与用户的沟通顺畅。

2. 避免歧义和模棱两可的表述用户手册应尽量避免歧义和模棱两可的表述，确保用户可以准确理解，正确操作软件。

3. 使用一致的术语和格式为了用户能够更好地理解和识别，用户手册中所使用的术语和格式应保持一致，避免混淆和困惑。

四、内容要点1. 首次使用向导提供软件产品的首次使用向导，引导用户进行软件的首次安装和初始化设置。

2. 主要功能说明逐一介绍软件产品的主要功能和使用方法，包括核心模块、操作界面、常用功能操作等。

1、版本命名规范软件版本号有四部分组成，第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号加希腊字母版本号，希腊字母版本号共有五种，分别为base、alpha、beta 、RC 、release。

2、软件版本阶段说明Base：此版本表示该软件仅仅是一个基础功能，通常包括所有将要编写的功能，但是功能都没有做完整的实现，只是做为软件整体的一个基础架构。

Alpha：软件的初级版本，表示该软件在此阶段以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改，是测试版本。

测试人员提交Bug经开发人员修改确认之后，发布到测试xx让测试人员测试，此时可将软件版本标注为alpha版。

Beta：该版本相对于Alpha 版已经有了很大的进步，消除了严重错误，但还需要经过多次测试来进一步消除，此版本主要的修改对象是软件的UI。

修改的的Bug 经测试人员测试确认后可发布到外网上，此时可将软件版本标注为beta版。

RC：该版本已经相当成熟了，基本上不存在导致错误的Bug，与即将发行的正式版本相差无几。

Release：该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式的版本，是最终交付用户使用的一个版本。

该版本有时也称标准版。

3、版本号修改规则（1）主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化。

此版本号由项目决定是否修改。

（2）次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。

此版本号由项目决定是否修改。

（3）修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩充，要经常发布修订版，修复一个严重Bug 即可发布一个修订版。

此版本号由项目经理决定是否修改。

（4）日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。

产品软件及用户指导类手册版本编号规则1 适用范围本规则适用于SP8200产品线发起并维护的所有产品软件及用户指导类手册。

具体包括：2 规则2.1 通用规则：a)版本编号前缀为“V”（大写）；b)版本编号一般由多项数字位组成，数字间以“.”符号分隔；c)特定情况下，最后一位数字末尾后还将添加一位字母位（小写），数字与字母间不添加任何分隔符；【举例】V4.0.1.1版本、V3.3.1.4a版本d)每项数字位均从0开始递增使用，字母位从a开始递增使用。

在前项数字变化时，其后所有数字/字母位全部清零。

【举例】V4系列第一个版本编号是V4.0.0.02.2 软件版本编号规则：a)软件版本编号仅对系统整体软件进行，不针对子软件（各部分子软件以SVN号标记）；b)软件版本号包含4位数字位，每位数字含义如下：i.第一位表示系统硬件形态的变化；ii.第二位表示系统软件功能（不含测试例）的变化；iii.第三位表示测试例支持情况的变化；iv.第四位表示版本迭代修正情况；c)软件版本号末尾可以包含1位字母位，用于版本发布后意外发现重大问题并仅针对该问题进行修正后的补丁版本编号；2.3 产品简介、数据手册版本编号规则：a)产品简介、数据手册版本号均包含3位数字位，数字位含义与软件版本号前3位数字完全一致；b)产品简介、数据手册版本号数字位必须与对应的产品软件版本号的前3位保持一致；c)产品简介、数据手册版本号可以包含1位字母位，用于文档发布后意外发现重大问题并仅针对该问题进行修改后的补丁版本编号；【举例】V4.0.1.2版本作为正式对外发布的版本，包含《SP8200 LTE终端RRM一致性测试系统数据手册》V4.0.12.4 用户手册、系统校准手册版本编号规则：a)用户手册、系统校准手册版本号均包含2位数字位，数字位含义与软件版本号前2位数字完全一致；b)用户手册、系统校准手册版本号数字位必须与对应的产品软件版本号的前2位保持一致；c)用户手册、系统校准手册版本号可以包含1位字母位，用于文档发布后意外发现重大问题并仅针对该问题进行修改后的补丁版本编号；【举例】V4.0.1.2版本作为正式对外发布的版本，包含《SP8200 LTE终端RRM一致性测试系统用户手册》V4.0[完]。

一、产品编码生成规则软件产品编码=产品分类+专业类别+专业+产品流水号+语言+产品属性+产品属性流水号资源产品编码分为父编码和子编码，父编码同软件产品编码，子编码如下：资源产品子编码=产品分类+专业类别+专业+产品流水号+语言+产品属性+产品属性流水号+资源类型产品流水号：指每个产品的编号，编号规则取决于同一专业录入系统的顺序。

产品属性流水号：➢标准产品的产品属性流水号固定为00➢定制产品的产品属性流水号依次为01，02，03……➢DEMO产品的产品属性流水号固定为90➢代理产品的产品属性流水号固定为91➢外购产品的产品属性流水号固定为92➢合作开发产品的产品属性流水号固定为93资源类型说明：✧2D动画 DA✧3D动画 DB✧微课 SA✧宣传片 SB✧课堂实录SC✧课程标准WA✧教学设计WB✧教学大纲WC✧教学课件WD✧教学案例WE✧习题作业WF✧电子教材WG✧试题试卷WH✧教案WI✧实训手册WJ✧实训指导书WK✧教师手册WL✧学生手册WM✧其他文档资源WN✧图片TA●标准产品如国泰安导游全景模拟实训平台软件、国泰安导游英语情景教学实训系统软件、国泰安导游考试系统软件这三款软件的产品编码。

产品分类为软件SD，专业类别为旅游类TR，专业为旅游管理TM，产品流水号分别为001,002,003，语言为中文简体SC，产品属性为标准US，则产品编码依次为SD-TRTM-001-SC-US-00，SD-TRTM-002-SC-US-00，SD-TRTM-003-SC-US-00。

●定制产品如国泰安智慧校园易管理平台软件产品编码：SD-INEM-001-SC-US-00其定制产品有：①开封文化旅游智慧校园易管理平台软件产品编码：SD-INEM-001-SC-UC-01②湖南石油智慧校园易管理平台软件产品编码：SD-INEM-001-SC-UC-02●DEMO（演示产品、预研产品）国泰安ZSpace平台VR产品体验包产品编码：SD-DEDE-001-SC-UD-90●代理产品NewtonsPark产品编码：SD-ABCD-001-EN-UA-91●外购产品YYYY产品编码：SD-ABCD-001-SC-UP-92●合作开发产品XXXX产品编码：SD-ABCD-001-SC-UT-93●资源类产品XXXX父编码：RS-ABCD-001-SC-US-00子编码：动画：RS-ABCD-001-SC-US-00-DA微课：RS-ABCD-001-SC-US-00-SA单独宣传片类的素材：RM-ABCD-002-SC-US-00-SB二、产品编码用途因产品编码是产品的身份证件，则可通过产品编码搜索某一产品有多少版本，有多少个衍生产品（定制产品、DEMO、合作开发等）。

软件项⽬版本号的命名规则及格式版本控制⽐较普遍的 3 种命名格式 :⼀、GNU 风格的版本号命名格式 :主版本号 . ⼦版本号 [. 修正版本号 [. 编译版本号 ]]Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]⽰例 : 1.2.1, 2.0, 5.0.0 build-13124⼆、Windows 风格的版本号命名格式 :主版本号 . ⼦版本号 [ 修正版本号 [. 编译版本号 ]]Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Number]]⽰例: 1.21, 2.0三、.Net Framework 风格的版本号命名格式:主版本号.⼦版本号[.编译版本号[.修正版本号]]Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]版本号由⼆⾄四个部分组成：主版本号、次版本号、内部版本号和修订号。

主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。

所有定义的部分都必须是⼤于或等于 0 的整数。

应根据下⾯的约定使⽤这些部分：Major ：具有相同名称但不同主版本号的程序集不可互换。

例如，这适⽤于对产品的⼤量重写，这些重写使得⽆法实现向后兼容性。

Minor ：如果两个程序集的名称和主版本号相同，⽽次版本号不同，这指⽰显著增强，但照顾到了向后兼容性。

例如，这适⽤于产品的修正版或完全向后兼容的新版本。

Build ：内部版本号的不同表⽰对相同源所作的重新编译。

这适合于更改处理器、平台或编译器的情况。

Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。

软件版本号规范1. 软件版本阶段说明o Base版: 此版本表⽰该软件仅仅是⼀个假页⾯链接，通常包括所有的功能和页⾯布局，但是页⾯中的功能都没有做完整的实现，只是做为整体⽹站的⼀个基础架构。

o Alpha版: 此版本表⽰该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，⼀般⽽⾔，该版本软件的Bug较多，需要继续修改。

o Beta版: 该版本相对于α版已有了很⼤的改进，消除了严重的错误，但还是存在着⼀些缺陷，需要经过多次测试来进⼀步消除，此版本主要的修改对像是软件的UI。

o RC版: 该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发⾏的正式版相差⽆⼏。

o Release版: 该版本意味“最终版本”，在前⾯版本的⼀系列测试版之后，终归会有⼀个正式版本，是最终交付⽤户使⽤的⼀个版本。

该版本有时也称为标准版。

⼀般情况下，Release不会以单词形式出现在软件封⾯上，取⽽代之的是符号(Ｒ)。

2. 版本命名规范 软件版本号由四部分组成，第⼀个1为主版本号，第⼆个1为⼦版本号，第三个1为阶段版本号，第四部分为⽇期版本号加希腊字母版本号，希腊字母版本号共有5种，分别为：base、alpha、beta、RC、release。

例如：1.1.1.051021_beta。

版本号定修改规则：o 主版本号(1)：当功能模块有较⼤的变动，⽐如增加多个模块或者整体架构发⽣变化。

此版本号由项⽬决定是否修改。

o ⼦版本号(1)：当功能有⼀定的增加或变化，⽐如增加了对权限控制、增加⾃定义视图等功能。

此版本号由项⽬决定是否修改。

o 阶段版本号(1)：⼀般是 Bug 修复或是⼀些⼩的变动，要经常发布修订版，时间间隔不限，修复⼀个严重的bug即可发布⼀个修订版。

此版本号由项⽬经理决定是否修改。

o ⽇期版本号(051021):⽤于记录修改项⽬的当前⽇期，每天对项⽬的修改都需要更改⽇期版本号。

此版本号由开发⼈员决定是否修改。

软件产品版本号命名规范软件产品版本号命名规范1、⽬的规范软件产品版本号，避免软件测试、发布时软件各模块版本不兼容问题。

2、范围C3M平台软件及绿⾊⾏动管理平台。

3、命名规范软件产品版本号命名规范参考 .Net Framework风格的版本号命名格式，以：主版本号.次版本号.内部版本号.修订号四位表⽰。

软件初版时，版本号为：1.0.0.0。

主版本号：标识软件架构、设计思想，主版本号不同的程序集不可互换，即使具有相同名称也不可互换。

软件架构、设计思想改变或⼤量重写，主版本号加1。

主版本号改变，不⽀持向后兼容性，次版本号、内部版本号及修订号复位为0。

次版本号：当在原有基础上增加了部分功能，涉及数据库的改动，次版本号加1，内部版本号及修订号复位为0。

内部版本号：当软件各模块间接⼝变更时，内部版本号加1，修订号复位为0。

只要有某个或某⼏个模块的接⼝发⽣变动，所有模块的内部版本号统⼀增加1。

修订号：名称、主版本号、次版本号、内部版本号都相同，但修订号不相同的程序集可以完全互换。

以软件编译⽇期（⽉⽇）4位数字作为修订号，如10⽉5号，则为1005。

当天发布的多次软件，⽤后编译的软件程序完全替换前边编译的软件程序。

主版本号、次版号及内部版本号，其中任何⼀个如果需要变更，需要向软件负责⼈申请，由软件负责⼈确定。

软件负责⼈将统⼀修改软件产品版本号，并通知所有相关开发⼈员。

开发⼈员每次的改动必须写开发⽇志，注明改动了哪些东西，修正了哪些BUG，是否对其它模块有影响，是否对数据库有改动。

软件产品所需要的主版本号、次版本号、内部版本号，出现任何⼀个变更，软件产品需要整体升级。

4、软件模块版本号软件各模块需要独⽴的主版本号、次版本号、内部版本号，其中对公共模块或公共组件的版本号，为完全独⽴的版本号，与软件产品版本号的主版本号，次版本号，内部版本号⽆关。

对业务模块的版本号，其主版本号与软件产品的版本号⼀致，次版本号，内部版本号为独⽴版本号。

1.总则软件产品的用户手册是软件产品开发的重要结果，也是用户学习使用软件产品的主要工具。

因此用户手册作为软件产品的组成部分，应当及时完成，并且能全面、详细地说明软件产品的功能、使用方法以及其它用户为使用、维护软件产品需知晓的事项。

2.目的对用户手册的编写时机、职责、内容及格式要求作出规定，以保证用户手册能满足用户正确使用软件产品的要求。

3.职责3.1.需求分析小组与项目组是用户手册的编写责任者;3.2.支持经理是用户手册编写的组织者;3.3.方正系统公司培训部负责用户手册的审核和印制。

4.工作程序4.1.用户手册的编写时机用户手册的编写应当从需求分析阶段开始进行。

在需求分析小组编写出需求规格说明书的同时，应完成用户手册的初稿。

该初稿应包括软件产品主要的功能描述以及界面描述。

在设计和实现（编码）阶段，项目组应随着软件产品的逐步细化以及变更的情况，同步完成用户手册的修改和细化。

当软件产品在项目组内完成集成测试时，用户手册的编写工作应基本完成，即此时用户手册的内容部分除因系统测试中发现错误而需进行部分改动外，不需要在内容方面进行增加。

但手册的格式可以暂时达不到要求。

软件产品提交系统测试时，用户手册达不到以上要求的，测试部门将不受理其测试申请。

4.2.用户手册的审定用户手册内容的审定，由项目组支持经理负责，同时应征求开发中心项目负责人的意见。

用户手册形式的审核由测试部门负责。

4.3.用户手册编写工作的组织在项目组建立后，用户手册的编写工作由支持经理负责组织。

具体的编写工作可以由项目组的成员共同完成，但支持经理负责用户手册编写工作的组织以及监督检查，并对其质量负责。

4.4.用户手册编写的格式要求见《方正用户手册排版要求》4.5.用户手册的内容要求4.5.1.封面用户手册的封面应包括以下内容：软件产品的名称、版本号以及版权单位信息。

其中软件产品的名称须使用软件产品的正式名称，并可以注明其简称。

版本号是指本次一同发行的软件产品的版本号而不是指手册的版本号。