1 命名及编号
1.1 产品
1.1.1 产品命名
产品名称主要由产品中文名称、产品英文名称、产品中文简称、产品英文简称组成。 产品中文名称：使用行业内通用的，或相关标准规定的中文名称，其应能体现产品的主要功能；产品中文名称应以“系统”或“管理系统”为后缀；产品中文名称不要以“中兴”开头。 产品英文名称：使用行业内通用的，或相关标准规定的英文名称，是对产品中文名称的英文翻译。 产品中文简称：是产品中文名称的缩写。 产品英文简称：产品英文简称是产品英文名称的缩写，由英文单词头字母或整个单词组成，应符合行业内通用的缩写习惯。 1.1.2 产品编码
产品编号以八位数字和字母组成： 产品大类区分号：
1.2 版本
1.2.1 版本编号组成
VX.Y[_xxxxxxxx][_Pmm][Buildnnnn] IT产品的版本编号由大写英文字母“V”和中间以圆点和下划线隔开的五组数字/符号组成。“V”是版本（Version）的英文单词首字母缩写。每组序号的含义及规则如下： 第一组数字X表示大版本（主版本），从1开始顺序递增，如一位数不够时可扩为两位； 第二组数字Y表示小版本（次版本），取值范围为0～9； 第三组数字xxxxxxxx表示8位企业服务号，如中兴通讯服务号为：75501899； 第四组符号Pmm表示维护版本（补丁版本），P为patch（补丁），mm取值为数字01～99依次递增； 第五组符号Buildnnnn表示构建版本号（Build号，需对外隐藏），nnnn取值为数字0001～9999依次递增。 原则上每种产品应有一个与之对应的独立的版本编号，某种产品的版本编号升级应不影响其它产品的版本编号。 产品标识由 产品名称[-定制客户代号] 组成。产品名称的定义以组织备案的产品名称为准；[-定制客户代号]为可选项，只有在客户定制版本的时候，才能使用。 1.2.2 版本的升级规则
版本的初始编号由X=1开始编号。 1.2.2.1 大版本
l 大版本X的升级包含重大的功能增加、一组工作量比较大的中小功能的增加或变更、系统整体性能改进等，通常会涉及系统结构变化，但也有可能因市场的需要而升级大版本； 重大功能增加通常指一个或多个子系统或系统模块的增加，一般会引起系统菜单区的内容变化；重大性能改进通常指为改进系统整体性能而做的架构升级（如系统重构）或技术平台（如数据库平台）的变化。 l 大版本的升级通常对应产品计划书会有A类的需求。 l 大版本X的升级必须重新立项，并在产品计划书中定义； l 大版本X的升级由大项目经理提出，通过产品计划评审会评审； 1.2.2.2 小版本
l 小版本Y的升级包含一组中小功能的增加或局部性能改进；中小功能增加一般是指在现有的子系统或模块下增加一个或多个单元或功能，通常会引起系统导航区的内容变化，不会引起系统菜单区的内容变化；局部性能改进通常指为改善系统的局部新能而做的系统局部架构升级或性能优化。 l 小版本的升级对应产品计划书中有B类或C类的需求。 l 小版本Y的升级应在产品计划书中定义； l 小版本Y的升级由大项目经理提出，通过产品计划评审会评审； 1.2.2.3 补丁版本
l 维护版本Pmm的升级主要是包含一个或多个对原有功能的变更或对当前版本的缺陷修复；维护版本的升级通常不会新增功能，也不会引起系统菜单区或者导航区的内容的变化（仅文字的变化除外）。 l 维护版本Pmm的升级对应产品计划书中有D类的需求。 l 维护版本Pmm的升级应在项目计划中定义；一般为定期发布（推荐每周），但在遇到特殊情况下，也可以随时发布。 l 维护版本Pmm的升级由项目经理定义，大项目经理批准； 1.2.2.4 构建版本
l 构建版本Buildnnnn的升级是在系统构建时进行，该构建一般是当前版本中系统架构、全部功能或部分功能完成开发并交付测试前进行。 l 构建版本的升级一般由项目经理或测试负责人提出。 1.3 项目
1.3.1 项目名称
项目按照类别分为研发类项目与工程类项目。根据特点的不同，命名如下： 1.3.1.1 研发类项目
研发类的项目可分为两类，如下 l 产品型项目，目的是实现产品或者产品的某一个迭代，其特点是该项目最终输出一个完整的产品； l 定制型项目，目的是实现某客户除标准产品外的定制部分，其特点是该项目无法完成一个完整的产品，而需要与其它产品型项目的标准产出集成在一起才能完成一个完整的产品。 两类项目的命名如下：由项目标识、项目类型、客户编号和项目期数组成，项目标识一般使用3个以上的大写的英文字母表示，该英文字母要能代表项目名称。通常在一个项目只开发一个产品的情况下，项目的标识一般用其所开发的产品的英文简称来表示： 产品型项目的命名如下： 如PDM项目可命名为PDM_Q03.01 定制型项目的命名如下： 1.3.1.2 工程类项目
由售后分配客户编号，每个工程项目可对应一个或多个产品。 如天津移动的项目名称为： 天津移动_Q01 1.3.2 项目编号
1.3.2.1 研发类项目
产品大类区分号： 见上产品编号中定义的“产品大类区分号”。 项目系列号： 按照登记的先后顺序从01～99依次编排。 升位规则： 根据立项顺序，在同一产品大类里统一编号，当一个产品大类（如ERP）里项目超过100时，给这个产品大类增加一个大类区分号。当产品大类将要超过100大类时，产品大类区分号将由目前的2位升为3位。升位时在原来的区分号前加“0”。 1.3.2.2 工程类项目
工程类项目的编号规则按照公司统一标准进行，即 年+月+日+当日公司统一工程项目编号+预测编码 其中，预测编码缺省为000 如根据合同号建立的XXX项目，进入ECC系统后自动生成项目编号为20051225010000 1.3.3 项目管理的原则
1.3.3.1 项目与版本关系
产品的研发通常采用递增的版本进行管理，每次递增都包含产品的一系列特性的增强，产品在其产品生命周期中将有多个版本，一个项目可以是实现产品的一个或多个版本，如下图所示： 规则一：大版本的管理 必须重新立项，并且要求作为一个独立的项目；如Ｖ1.0、V2.0等都须作为独立的项目进行重新立项。 规则二：多个小版本的项目管理 l 可以单个小版本一个项目管理，也可以若干个（不大于３）小版本合并为一个项目，如V1.1、V1.2、V1.3可以合并为一个项目，在产品计划书评审时一次将3个小版本的内容和发布时间都确定。 l 在需求不稳定的情况下，定义产品小版本时可以在其前后预留一定数量（不大于2个）的小版本，在临时出现需求变更时可以插入相应的小版本，但一个项目包含的总的小版本数仍然不大于3个，否则就要重新立项。 规则三：单个项目的周期不大于3个月。 规则四：同一个项目中，并行的版本数不大于2。 1.3.3.2 小版本调整规则
项目中，小版本一般来说难以规划，但是也应该尽早进行计划，尽量把有关需求并入邻近的正常版本，减少紧急小版本的数量。
1.3.3.3 版本积分说明
版本的积分原则以产品计划书中该版本的结束时间为准。
如图所示： 1.4 产品结构模型
图4-1 产品结构模型图 1.4.1 系统
系统的命名和编号同产品的命名和编号。 1.4.2 子系统
子系统是完成某一独立职能域业务、并具有独立界面的应用划分；当系统比较小时，可以不划分子系统。子系统是部分系统模块的虚拟逻辑组合。子系统在《产品计划书》中定义。 子系统命名：子系统名称由子系统中文简称和“子系统”组成，例如：设备管理子系统。 子系统编号：子系统编号由一位大写英文字母“S”和两位数字组成，S是Sub-System的简写。例如：S01 1.4.3 系统模块
系统模块是完成相对独立的某一管理业务，是系统的基本组成单位，一个系统由一个或多个系统模块组成；在系统中系统模块与一级菜单存在对应关系，一般地，一级菜单一定可以对应到某系统模块；系统模块在系统的《产品需求说明书》中定义。 系统模块命名：系统模块名称使用中文文字进行描述，例如：人事管理。 系统模块编号：功能模板编号由一位大写英文字母“M”和两位数字组成，M是Module的简写。例如：M01 为需求管理的方便性，将非功能性需求归于一个虚拟的系统模块，该虚拟系统模块编号缺省定义为M00。 1.4.4 业务单元
业务单元是一组相近的业务功能的分类组合；业务单元是在《产品需求说明书》中进行定义，在《软件需求说明书》等中引用。 业务单元命名：业务单元名称使用中文文字进行描述，例如：考核管理。 业务单元编号：业务单元编号由大写英文字母“BU”和两位数字组成，BU是“Business Unit”的简写。业务单元编号一般与系统模块编号同时使用（中间用“_”隔开）来标识业务单元，这里的系统模块编号是该业务单元所在的系统模块的编号，例如：M01_BU01。 1.4.5 业务功能
业务功能是产品特性的最小（不能再拆分）的个体；系统的三级菜单一般将对应到某业务功能；业务功能在《产品需求说明书》中进行定义，在《软件需求说明书》中进行详细描述。 业务功能命名：业务功能名称使用动宾或宾动结构的中文描述，例如：管理干部考核。 业务功能编号：业务功能编号由系统模块编号、业务单元编号和业务功能编号三部分组成，中间分别用“_”隔开；系统模块编号使用该业务功能所在的系统模块的编号，业务单元编号使用该业务功能所在的业务单元的编号，业务功能编号由大写英文字母“BF”和两位数字组成，BF是“Business Feature”的简写。例如：M01_BU01_BF01。 1.4.6 用例
用例是对系统行为需求的分析建模，详细描述了用户将如何使用系统，同时它还提及系统用户接口方面的问题；系统用例在《软件需求说明书》中进行详细描述。 用例命名：用例名称使用动宾结构的中文文字进行描述，例如：增加网元。 用例编号：用例编号由系统模块编号、业务单元编号和用例编号三部分组成，中间分别用“_”隔开，系统模块编号使用该用例所在的系统模块的编号，业务单元编号使用该用例所在的业务单元的编号，用例编号由大写英文字母“UC”和两位数字组成，UC是“Use Case”的简写。例如：M01_BU01_UC01。 限制：该元素仅适用于面向对象的分析设计。 1.4.7 架构层
架构层是从体系结构出发，将系统模块的稳定程度进行分组的一个层次。并极大程度适用产品化的要求。定义为以下四层： L01基础框架，L02领域逻辑，L03通用业务，L04专用业务。 L01基础框架主要是与业务无关，与技术性能、通用机制相关的一些模块集合，属于技术平台范畴。 L02领域逻辑主要是业务领域相关的模块集合，属于业务平台范畴。 L03通用业务主要是不同客户能够通用的业务的模块集合，属于产品范畴。 L04专用业务主要是针对不同的客户定制业务的模块集合，属于项目范畴。 1.4.8 组件
命名：产品英文简称_C+语言种类简称+nnn_组件英文简称 C：Component组件 开发语言种类：
组件编号按以下范围进行设置（编号规则仅为建议，可以顺序进行编号）： L01基础框架：000-199 L02领域逻辑：200-399 L03通用业务：400-699 L04专用业务：700-999 例如：EPS_CJ001_Order，Univ_CN053_XsExamService 1.4.9 逻辑层
逻辑层是由架构设计时对系统划分的逻辑层次，在各系统中所定义的层需要在此进行统一编号，编号由两位大写字母组成，取英文单词的首写字母，如超过两个单词的，需要精简为两个字母。目前登记层如下： UI：User Interface，用户界面层 BL：Business Logic，业务逻辑层 DA：Data Access，数据访问层 1.4.10 设计单元
设计包的最小单位，对系统复杂行为分解为粒度更小、复杂度更小的单元来简化设计，是程序单元的集合。划分时以功能内聚性为指导原则，不跨系统模块。 设计单元命名：CXnnn_DU<序号>_<设计单元英文名称>，DU序号在组件内不重复。 如：CJ401_DU01_ProjectPlan 设计单元编号：同命名一致 1.4.11 程序单元
程序单元是对应于设计包（实施模型的代码目录）、设计结果（UML图及设计类）的集合。划分时以类职责内聚性为指导原则，不跨逻辑层。 程序单元命名：<逻辑层>_PU<编号>_<dir-name>，PU编号在系统内不重复； 编号规则为：三位组件序号＋两位设计单元序号＋两位PU序号。PU序号在设计 单元内不重复，dir-name对应到源代码目录，按源代码目录结构规范，一个程序单 元仅对应到一个目录（除BS结构的UI层的程序单元外）。 如：BL_PU0010201_projectinfo DA_PU0010202_projectinfo 程序单元编号：同命名一致。 1.4.12 类
类是程序单元的基本元素，类在《详细设计说明书》或建模文档中进行定义和详细说明。 类命名：类命名参见相关语言的编码规范。 类编号：类编号由程序单元和类名两部分组成，中间用“_”隔开，程序单元编号使用该类所在程序单元的编号，类名用类的名称。例如：BL_PU0010202_Employee。 限制：该元素仅适用于面向对象的分析设计。 1.5 工作产品命名规范
参见PAL上《IT中心工作产品命名规范.xls》。 1.6 ClearQuest相关命名规范
1.6.1 变更
对项目受控文档或代码文件的修改需要提请变更。 变更命名：C_<系统模块名>_<动宾结构的简要描述> 说明：动宾结构的简要描述要能简单描述清楚变更的主要内容和范围； 一般变更不跨系统模块，对于跨多个系统模块的变更，则根据该变更所影响的主要系统模块确定其归属； <系统模块名>在保存时由系统自动生产。 样例：C_人事管理_增加上级对下级考核的功能。 C_人事管理_修改上级对下级考核功能的考核计算公式。 C_人事管理_删除上级对下级考核功能的企业文化评价。 1.6.2 变更措施
变更措施是变更申请被批准后为完成变更而实施的具体的措施，一条变更对应于一条或多条变更措施。 变更措施命名：C_<系统模块名>_<动宾结构的简要描述>_<处理人员姓名> 说明： 动宾结构的简要描述要将变更措施的主要修改的工件或者范围描述清楚； C、<系统模块名>、<处理人员姓名>在保存时由系统自动生成。（C是变更措施的英文首字母。） 样例：C_手机合同_修改打印OE发货通知单的功能设计文档_wuxiaoguang。 C_手机合同_修改打印OE发货通知单的程序_liutao。 1.6.3 缺陷
缺陷分为代码缺陷和文档缺陷；代码缺陷一般是在测试或用户使用时发现的；文档缺陷一般是在评审时发现的；为方便管理，我们将代码缺陷叫Bug，文档缺陷叫做缺陷。 文档缺陷命名：F_<系统模块名>_<文档缺陷的简单描述>_<处理人员姓名> 说明：文档缺陷的简单描述要将缺陷的主要现象和问题简要描述清楚。 样例：F_人事管理_修改XX文档评审后的缺陷_fanweiqi <处理人员姓名>在保存时由系统自动生成 1.6.4 Bug
Bug命名：B_<系统模块名>_<bug的简单描述>_<处理人员姓名> 说明：缺Bug的简单描述要将Bug的主要现象和问题简要描述清楚。 B、<系统模块名>、<处理人员姓名>在保存时由系统自动生成。（B是Bug的英文首字母。） 样例：B_考核管理_必填项没有打星号_wuzhenyu 1.6.5 日常开发活动
日常开发活动是指对配置管理库中未受控文档或代码的新增、修改和删除活动。 日常开发活动命名：F_<系统模块名>_<动宾结构的简要描述>_<处理人员姓名> 说明：动宾结构的简要描述要将活动的主要设计工件或者范围描述清楚。 跨模块的总体性活动，如编写总体设计，则可以将<系统模块名>用“其他”代替。F、<系统模块名>、<处理人员姓名> 在保存时由系统自动生成。 样例：F_手机合同_新增OE发货通知单功能设计文档_wuxiaoguang。 F_手机合同_修改OE发货通知单功能设计文档_wuxiaoguang。 F_其他_新增融资管理总体方案_wuxiaoguang。（F是日常开发活动的英文首字母） 1.7 ClearCase相关命名规范
1.7.1 PVOB命名
PVOB为项目管理型VOB，按照平台建立。 PVOB命名：平台英文简称_PVOB 说明：如ClearCase中已建立PVOB，则不用再进行建立，只有新平台才需要建立。 样例：ERP_PVOB ECC_PVOB 1.7.2 VOB命名
VOB是ClearCase中存储文件、目录和元数据的永久数据存储池，一般一个产品对应一个VOB. VOB命名：平台英文简称_产品英文简称 样例：ERP_CMS BI_QOL 1.7.3 构件命名
1、对于一个VOB只有一个Component的，Component的名称和VOB名称一致。 2、对于非基于组件开发的，分别包含命名为Docs,SourceCode的两个构件。 3、对于基于组件开发的CC构件命名与 样例：
1.7.4 项目命名
项目命名：平台英文简称_项目英文简称_客户拼音简写 说明：当一个VOB只有一个Component时，项目的名称会和VOB名称冲突，项目可命名为：平台英文简称-项目拼音简称 样例：SEC_SOC_TJYD（天津移动的SOC项目） ERP-CMS 1.7.5 流命名
流命名：产品英文简称_客户拼音简写(若为标准产品则不需要)_流功能简称 流功能简称： 对于文档、代码流没有分开的项目 DEV（开发流）、TST(测试流)、INT(集成流)、BugFix_V*.*（紧急Bug修复流） 对于文档、代码分开的项目 DOC_DEV（文档开发流）、SRC_DEV（代码开发流）、SRC_TST(测试流)、INT(集成流)、BugFix（紧急Bug修复流） 样例：SOC_TJYD_DOC_DEV SOC_TJYD_SRC_DEV SOC_TJYD_SRC_TST SOC_TJYD_BugFix_V1.0 1.7.6 视图命名
视图命名：姓名全拼_流名称 样例：liuqianlong_SOC_TJYD_BugFix_V1.0 1.7.7 基线标签命名
基线标签命名：产品英文简称_基线类型_版本号 基线类型： l PLN－用户需求/产品需求/计划基线 l REQn－软件需求基线/设计基线 //n为选用增量2模型时使用，取值1～9 l TST－系统测试基线 l REL－发布基线 注：系统测试基线的版本号为当前CQ中版本发布的构建版本号。 样例：SOC_PLN_V2.0_27183978 SOC_REQ_V2.0_27183978 SOC_TST_V2.0_27183978Build0001 SOC_REL_V2.0_27183978 1.7.8 VOB目录结构规范（组件开发）
每个VOB根目录下有：Docs和组件1、组件2、组件n的n+1个文件夹： <VOB Tag> |--Docs \\参见 |--Component1 \\参见 |--Component2 \\参见 |--…… |--Componentn \\参见 1.7.8.1 Docs（文档目录）
|--Docs | |---需求 //需求类文档 | | |---用户需求 //存放用户需求文档 | | |---产品需求 //存放项目的产品需求说明书 | | |---总体方案 //存放业务总体方案文档（面向结构专用），存放Rose .mdl文件（面向对象专用） | | |---详细方案 //存放业务详细方案文档（面向结构专用） | | |---软件需求 | | | |---<系统模块名1> //按系统模块存放的该系统模块相关的需求文档 | | | | |---软件需求 //软件需求说明书文档 | | | | |---系统用例 // Rose .cat文件（cat 面向对象专用） | | | |---<系统模块名2> //目录结构同上 | | |---界面原型 //如果是一个系统一个压缩包，则为系统名称（中文）.rar，直接存放在界面原型目录下即可 | | | |---BS //BS架构下用户界面文件 | | | | |---Application //页面文件 | | | | |---<系统模块名1> //按照系统模块存放该系统模块的界面原型, 模块名称（中文）.rar | | | | |---<系统模块名2> //按照系统模块存放该系统模块的界面原型 | | | | |---<系统模块名n> //按照系统模块存放该系统模块的界面原型 | | | | |---CSS //CSS文件集合 | | | | |---Images //图片文件集合 | | | | |---Framework //界面框架文件 | | | | |---JS //javascript文件集合 | | | |---执行文件 //存放CS系统的DEMO编译后的可执行文件 | | |---RP需求管理 //存放RequisitePro需求管理项目的.RQS文件 | |---设计 //总体设计类文档 | |---总体设计 //存放软件架构文档、技术预研性报告文档及论证报告文档 | |---数据库设计 //PowerDesigner数据建模文件（sws） | |----测试 //存放测试的相关文档 | |---单元测试 //单元测试所产出的工件，包括开发人员自己做的自测文件 | |---集成测试 //集成测试所产出的工件，包括开发人员自己做的集成测试文件 | |---每日构造 //集成测试所产出的工件 | | |---测试方案 | | |---V*.* //XXX测试需求分析、软件需求测试分析、每日构造测试方案、性能测试方案 | | |---测试设计 | | |---<系统模块名1> //按系统模块存放的该系统模块相关的测试用例 | | |---测试开发 | | |---V*.* //测试脚本 | | |---测试执行 | | |---V*.* //测试执行记录、测试报告、性能测试报告、测试评估报告、测试基线审核报告、XXX每日构造bug统计表 | | |---其他文档 | | |---V*.* //XXX每日构造方案、XXX功能提交表、XXXBVT报告 | |---系统测试 | | |---测试方案 | | |---V*.* //XXX测试需求分析、软件需求测试分析、系统测试方案、性能测试方案 | | |---测试设计 | | |---<系统模块名1> //按系统模块存放的该系统模块相关的测试用例 | | |---测试开发 | | |---V*.* //测试脚本 | | |---测试执行 | | |---V*.* //测试执行记录、测试报告、性能测试报告、测试评估报告、系统测试审核报告 | | |---其他文档 | |---验收测试 | |----部署 | |---集成 //存放产品集成方案 | | |---V*.* //存放版本集成手册 | |---安装手册 //存放产品的安装手册、升级指导书 | |---版本说明 | | |---V*.* //存放版本说明书 | |---用户手册 //存放用户手册 | |---用户培训文档 //存放用户的培训文档 | |----计划 | |---项目名称 //项目主计划，配置管理、质量保证计划、系统测试计划、估算等计划; 风险问题承诺跟踪表等计划 | |----过程文档 //存放产品的管理文档 | |---项目管理 //项目管理类的文档 | | |---会议 | | | |---CCB会议 //存放CCB的预审报告和会议结果,存档管理 | | | |---项目例会 //周例会会议纪要和相关资料,存档管理 | | | |---其他 //存放其他的一些会议报告,存档管理 | | |---里程碑报告 //项目里程碑报告,存档管理 | |---配置管理 | | |---基线评审 //基线评审的相关报告, 按照版本存放,存档管理 | | |---状态报告 //配置状态报告,存档管理 | | |---审核报告 //配置审核报告,存档管理 | | |---代码行统计 //存放代码行统计结果文件,存档管理 | |---其他 |
|
|
