项目文档命名规则
编制：日期：____/____/____ 审核：日期：____/____/____ 批准：日期：____/____/____
XXXX公司
二零一五年五月制
历史记录
编号章节名称说明修订日期版本号修订人发布日期
01 全文新建 1.0
02 修订章节 4.1 1.1
目录
1 目的 (4)
2 适用范围 (4)
3 术语和缩略词 (4)
4 规程 (4)
4.1 文档命名规则 (4)
4.2 配置项的版本标识 (8)
4.3 标签的命名 (9)
1 目的
本文的目的是定义各项目所有相关文档和CMM要求的过程文件的格式和规则，以及配置管理中对配置项和版本的标识。
2 适用范围
本规则适用于所有需求、设计等文档和过程文件。
3 术语和缩略词
无
4 规程
4.4文档命名规则
1 组织标准软件过程文档编号
(1) 过程文件格式：XXX-P-××，初始编号为：XXX-P-01，最大编号为：XXX-P-99。
(2) 指南文件编号：XXX-G-××××，前两位××为指南所对应的过程文件编号。
(3) 模板文件编号：XXX-T-××××，前两位××为指南所对应的过程文件编号。
2 产品命名规范
(1) 中文命名规范：中文全称V 产品版本号。英文命名规范：首字母大写V 产品版本号。
3 项目文档编号
(1) 编号规则分三种：
1) 单个文档：首字母大写V产品版本号- 阶段英文缩写- 文档名称英文缩写。
2) 多个子文档：首字母大写V产品版本号- 阶段英文缩写- 文档名称英文缩写—流
水号。
3) 周期性：首字母大写V 产品版本号- 文档名称/ 英文名称- 八位日期。
(2) 项目阶段及文档名称英文缩写，见下表：
阶段序号文档名称英文及缩写
产品调1 产品调研任务书
P IA(Project Investigate
Assignment)
研(PI) 2 产品调研计划PIP(Project Investigate Plan)
3 竞争对手产品对比差异分析报告OPA(Opponent Product
Difference Analyse Report) 4 标准吻合度分析报告SMR(Standard Match Report)
5 产品系统需求P SR(Product System Requirement )
1 XX技术预研计划TSP(Technology Study Plan)
2 XX技术预研报告TSR(Technology Study Report) 技术预
研(TS) 3 技术可行性分析报告
T FA(Technology Feasibility
Analyse Report)
4 产品系统需求
P SR(Product System
Requirement )
1 产品需求规格说明书
S RS(Product Requirement
Specification)
2 项目开发计划PDP(Product Development Plan)
3 风险管理计划RMP(Risk Management Plan)
4 产品系统测试计划PTP(Product Test Plan)
计划与 5 质量保证计划QAP(Quality Assurance Plan)
立项(PP)
6 配置管理计划
C MP(Configuration Management
Plan)
7 项目会议记录meeting
8 产品工程计划与进度跟表PST(Product Schedule Trace)
9 产品界面原型设计UID(User Interface Design)
10 产品任务书无需
11 产品立项申请书PSA(Product Start Apply)
设计(DE) 1 产品总体设计说明书PSD(Product System Design)
2 XX模块概要设计说明书HLD(High Level Design)
3 XX模块详细设计说明书DD(Detail Design)
1 产品单元测试汇总报告UTR(Product Unit Test Report)
编码、单 2 用户手册无需元测试
(CUT) 3 产品集成测试用例
I TC(Product Integerate Test
Case)
4 集成测试计划ITP(Integerate Test Plan)
集成测 1 产品集成测试报告ITR(Integerate Test Report) 试(IT)
2 产品系统测试用例STC(System Test Case)
1 测试入口检查单无需
增量测试和系统测试2 系统测试方案STP(System Test Plan)
3 增量测试方案ATP(Alternate Test Plan)
4 增量测试报告ATR(Alternate Test Report)
(ST)
5 系统测试报告STR(System Test Report)
4 文档版本
(1) 格式：V×××. ×××，初始版本号为V0.1，最大版本号为：V999.999 。其中，
草稿状态的版本均为V0. ×××，例如：V0.1，V0.2 ,, V0.999 ；而经过评审通过
的文档版本均从V1.0 开始，例如：V1.0，V1.1 ，V2.0 等。
5 密级程度
(1) 文档（包括电子文档和纸质文档）的密级分为三级，由低到高分别是：公开级、限
制级、核心级：
1) 公开级的文档使用的范围不受约束，例如研发人员，生产人员、市场人员、行
政人员和产品用户等；包括用户手册、技术白皮书、产品安装说明、宣传资
料等。
2) 限制级的文档使用的范围仅限于研发内部的人员或生产人员；包括研发制度
和规范、计划、产品需求、总体设计、模块设计、详细设计、测试用例、测试
报告、评审文档、生产资料等。
3) 核心级的文档使用的范围仅限于研发开发经理以上的人员。包括产品源码、
产品镜像文件、公司或部门的敏感文件。
(2) 密级标注
密级在密级标识栏中填写，若无标识栏则在文档的右上角标注密级。
6 文档编写格式
文档编写可以从研发模板库中取得相应模板进行编写，也可根据格式要求进行编写，具体格式要求如下：
(1) 封面
1) 页眉、页脚空白
2) 封面上方文档编号表格
属性：文字环绕--无
置顶，上面无空行
中文宋体、英文Arial ，全部加粗，宋体，10.5 号
3) 标题
2 行：第一行：产品中文名称Vx.x ；第二行：文档名称
小一号字体，黑体，Arial ，加粗
段前段后 2.6 磅，单倍行距；无缩进，无悬挂
上方空 2 行，下方空 3 行
4) 签核栏位
四号字体，宋体，Arial ，加粗
签核栏位 4 栏，到部门批准（研发副总）；签核栏位 5 栏，到批准（郭总）。
具体的签核栏位数见《研发过程文档命名及签批流程.xls》
左侧缩进 4 字符，右侧缩进-4.16 字符，无悬挂；段前段后 2.6 磅，单倍行距
5) 模板制度日期
“XXXX 公司”“二零XX 年X 月制”分两行；
小三号字体，黑体，Arial ，加粗；居中
段前段后0 行，单倍行距；无缩进，无悬挂
下方插入分节符“下一页”
(2) 历史记录
1) “历史记录”
小三，黑体，不加粗
段前段后0 行，单倍行距
2) 表格
属性：文字环绕选无；行高，0.6，最小；设置“在各页端以标题行形式重复出现”
表头：五号，宋体，加粗，全部居中
格式：五号，宋体，Arial ，不加粗，全部居中
内容：日期格式为yyyy.mm.dd ，版本号Vx.x
表格下方插入分节符-下一页
3) 页眉、页脚
页眉：
页脚：开始插入页码，页码格式为“第X 页共X 页”，小五号，宋体，Arial ，居中
(3) 目录
2) “目录”
字体：小三，黑体，不加粗
“目录”两个字中间空 2 个字
段前段后0 行，多倍行距，设置选 3
3) 目录内容
来自模板，显示级别 3 级，不加冒号
4) 页眉、页脚
页眉：
页脚：插入页码，页码格式为“第X 页共X 页”，小五号，宋体，Arial ，居中
(4) 正文
1) 标题：字体均采用宋体加黑，标题一为小三号字体，标题二为四号，依次类推。
段落为单倍行距。
2) 标题一段落段前13 磅，段后 6 磅；标题二段落段前段后 6 磅；
3) 页眉页脚：页眉格式：左上角标注“西安交大公司网络科技有限公司”，右上
角标注文档名称；页脚格式：第×页共×页，封面不显示页码。
4) 内容：正文，字体，宋体，Arial ，五号，不加粗，两端对齐，首行缩进 2 字
符，段后0 行，1.5 倍行距。
(5) 表格
1) 表头：字体宋体，Arial ，五号，加粗；上下居中，水平居中；表格底纹设置
为灰度25%
2) 内容：字体宋体，Arial ，五号，不加粗
3) 行高：0.6cm，最小值
4) 宽度：设置为页面宽度
(6) 流程图
均采用Visio 画图，底色均为默认的白色，图中字体均为宋体，大小采用五号字体
或10pt 大小字体。
(7) 页边距：上下 2.54 厘米，左右 3.17 厘米
均采用Visio 画图，底色均为默认的白色，图中字体均为宋体，大小采用五号字体
或10pt 大小字体。
4.5配置项的版本标识
根据产品的需要，软件产品制造过程中的每个配置项和不同阶段的基线发布都需要进行
相应的版本标识，下面分别介绍。
1、配置项版本标识
对于文档、软件和硬件的版本号，项目过程中采用三位编码的原则，格式如下：
Vxxx.xxx.xxxx ，初始版本号为V1.0.0 ，最大版本号为：V999.999.9999.
例如：V1.0.0 ；V82.456.15
在个人工作区如果对文档或编码进行修改，版本号的第三位迭代1，如V1.0.1 。文档、软件和硬件的各配置项的版本号第二位应统一。
从个人工作区提交到开发区时，由项目经理控制版本号的第二位的迭代。建议：如果其中一项的特征进行了较大修改或者增加了新特性，第二位迭代1，第三位恢复为0。如V1.1.0 。
从开发区提交到基线区时，由SCCB控制版本号的第一位的迭代，进行一次变更版本号
的第二位迭代1, 并由SCM去掉版本号的第三位后放入基线区。如：V56.45 。
2、基线版本标识
SCM负责人负责把基线发布给外部客户（如发布运行基线）或内部使用（如为测试而发
布）。
基线的版本号采用两位编号原则，格式如下：
Vxxx.xxx, 初始版本号为V1.0. ，最大版本号为V999.999 。
例如：V1.0 ；V33.99
4.6标签的命名
SCM 人员负责对开发过程中的重要里程碑及基线进行标签的标注。
标签的命名不可随意为之，要让标签名称具有很强的自说明性，并且尽量不要过于复
杂。标签命名分为以下两种情况：
a)正是基线命名
标签名称必须以该项目组产品名称的英文字母开头，格式如下：
产品英文名称_版本号_REL+ 标签版本号，其中“版本号”指的是所开发产品的版本，
初始版本号为v1_0，最大版本号为v999_999；而“标签版本号”指的是每次打标签递增的
序号，范围从01 到99。
b)非正式基线或里程碑命名
标签名称以类型的英文字母开头，格式如下：
类型_版本号_标签版本号，其中“类型”指的是alpha 测试版、beta 测试版等，“版本号”指的是所开发产品的版本，初始版本号为v1_0，最大版本号为v999_999；而“标签版
本号”指的是每次打标签递增的序号，范围从01 到99。
注意：标签名称必须以字母开头，中间可以包含字母、数字、下划线（_）和连字符
（－），不能使用小数点。
□机密文件■管制文件□一般文件 主题： 项目编码规则 文件编码： 版本：V5.2 机种：———— 生效日期：发行日生效PAGE 0 OF 13 （变更历史记录）： 变更次数变更内容变更人变更日期 0 首次发行,第一版1999.12.5 1 物料编码规则维护2000.5.33 2 项目编码规则维护，变更码长和分类、取消延申码，2001.2.9 3 项目编码规则维护, 2001.6.25 4 项目编码规则维护, 2002-4-29 5 项目编码规则维护, 2002-5-16 6 项目编码规则维护,数码产品2002-8-13 7 项目编码规则维护,笔记本2003-3-7 8 项目编码规则维护,笔记本编码2003-12-29 9 根据现有业务流程进行版本升级徐斐2004-2-28 10 项目编码规则维护,PTO编码徐斐2004-5-30 分发部门□研发中心□生产管理□财务□行政部 □采购□市场□品管部□信息管理部□商务□计划物控□ □客服□产品销售□□ 会签部门 （部门长） 批准审核拟稿TCL电脑科技（深圳）有限公司
目录 1 目的. (3) 2 范围. (3) 3 权责. (3) 3.1信息管理部 (3) 3.2研发部 (3) 3.3产品管理部 (3) 3.4其它部门 (3) 3.5 TCL万维科技(深圳)有限公司 .......................................................................... 错误!未定义书签。4定义 . (3) 5 TCL电脑科技有限责任公司项目编码规则 (4) 5.1 成品编码规则 (4) 5.2零部件的编码规则 (6) 5.3 PC主机电脑及外设所用项目的选项类项目编码规则 (10) 5.4 笔记本主机电脑及外设所用项目的选项类项目编码规则 (12) 5.5固定资产编码规则 (17) 5.6办公用品编码规则 (18) 5.7促销品编码规则 (18) 5.8客服的服务用品编码规则 (18) 5.9外协项目的编码规则 (18) 5.9工程物料编码规则 (18) 6 TCL万维科技(深圳)有限公司项目编码规则 (18) 7项目编码规则的维护. (19) 8相关文件. (19)
＜项目名称＞ 软件需求说明书 作者： 完成日期： 签收人： 签收日期： 修改情况记录：
目录 1 引言 (1) 1.1 编写目的 (1) 1.2 范围 (1) 1.3 定义 (1) 1.4 参考资料 (1) 2 项目概述 (2) 2.1 产品描述 (2) 2.2 产品功能 (2) 2.3 用户特点 (2) 2.4 一般约束 (2) 2.5 假设和依据 (3) 3 具体需求 (3) 3.1 功能需求 (3) 3.1.1 功能需求1 (3) 3.1.2 功能需求2 (4) 3.1.n 功能需求n (5) 3.2 外部接口需求 (5) 3.2.1 用户接口 (5) 3.2.2 硬件接口 (5) 3.2.3 软件接口 (5) 3.2.4 通信接口 (6) 3.3 性能需求 (6) 3.4 设计约束 (6) 3.4.1 其他标准的约束 (6) 3.4.2 硬件的限制 (7) 3.5 属性 (7) 3.5.1 可用性 (7) 3.5.2 安全性 (7) 3.5.3 可维护性 (7) 3.5.4 可转移＼转换性 (8) 3.5.5 警告 (8) 3.6 其他需求 (8) 3.6.1 数据库 (8) 3.6.2 操作 (8) 3.6.3 场合适应性需求 (9) 4 附录 (9)
1 引言 1.1 编写目的 说明编写这份软件需求说明书的目的，指出预期的读者范围。 1.2 范围 说明： a．待开发的软件系统的名称； b．说明软件将干什么，如果需要的话，还要说明软件产品不干什么； c．描述所说明的软件的应用。应当： 1）尽可能精确地描述所有相关的利益、目的、以及最终目标。 2）如果有一个较高层次的说明存在，则应该使其和高层次说明中的类似的陈述相一致（例如，系统的需求规格说明）。 1.3 定义 列出本文件中用到的专门术语的定义和缩写词的原词组。 1.4 参考资料 列出要用到的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料，包括所要用到的软件开发标准。 列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
项目开发规范文档修订历史记录
1.简介 目的 1、用于规范指导开发组进行开发 2、便于成员间的沟通与交流。 3、有助于项目质量和稳定。 4、为后期维护提供支持 2. 项目开发流程 项目开发过程归纳分为以下步骤： 1. 建立SVN项目版本控制。包括文档，源码，Lib包等。 2. 了解需求，并对需求文档的书写。(见文档结构规则附录)。 3. 详细设计文档。(见文档结构规则附录)。 功能模块设计，重要模块的算法设计。 数据库设计等。 根据需求定义开发平台及环境。 4. 编码。 搭建开发平台，配置开发环境。 编码。 单元测试案例。 5. 书写软件安装手册文件，数据库脚本文件，以及注意事项(release notes)。 6. 交互测试组测试。根据测试组测试结果是否回归第4步（测试回归最好不要超过2 次）。 7. 测试通过，交付上线使用。 维护手册 使用手册
3. 代码规范 Java 代码规范 3.1.1 Java类名 类名可由：英文字母，数字，下划线组成。（数字，下划线不能够开头） 类名由一个或者多个单词组成。单词通常要求简洁明了达意。能够通过类名能够大致了解此类的作用和用途。 类名要求首字母大写，多个单词组成类名时，单词的首字母要求大写。 建议：类名不要过于简单或者太长。可以对单词采用简化的名称：入： Number 简化为：num 。 3.1.2 Java类结构 类仅作为数据结构，没有行为，他封装了一组或者相似的一些行为方法。所以一个类尽量功能单一，或者功能类似共有行为的。一个类不要过于庞大。 通常情况下： 一般逻辑类中应该有构造方法和main方法，main方法中应该有测试代码。 每个类应该有 toString() 方法。 3.1.2.1 包和引入语句 在多数Java源文件中，第一个非注释行是包语句。在它之后可以跟引入语句。 报名的定义全部是小写字母。具体定义依据项目而定。 引入包时候，同一类型的归纳到一块，用空行隔开。例如： import 3.1.2 类注释 Java类开头应该有相应的注释：类版本描述，作者签名，日期时间，公司备注，类的功能作用相关描述等。（详细查看：注释） 3.1.2.2 类成员变量 a) 类变量要求放在类的开始声明。一行声明一个。 b) 变量名称首字母要求小写。其他命名规则类似与类名。 c) static , final 类型的变量，字母要求全部大写。 d) 尽量在声明局部变量的同时初始化。 e) 避免局部变量和成员变量同名，覆盖了成员变量。 f) 尽量变量私有化，缩小变量的作用域。 3.1.2.3 类成员方法 a) 方法名命名规则类似于成员变量命名规则。 b) 成员方法尽量私有化。
1、目的 本指导书是为软件配置管理而制定。其目的是使公司软件产品配置标识的命名规范化。 2、适用范围 适用于本公司所有软件产品的配置管理。 3、职责 4、控制内容 4.1、软件配置标识的组成 4.1.1、软件提供给用户的阶段产品和最终产品的配置标识由公司代码QW和以下五 部分组成。 a、产品类别代码 b、产品（项目）标识或子系统标识 c、配置项标识 d、版本号 其一般形式为：QWa-bbbb-cc-dd 4.1.2、软件开发过程中产生仅供公司或项目内部使用的配置项，其配置标识的一 般形 式为：bbcccccc-dd，其中，bb为产品（项目）标识缩写，cccccc为配置项标识，dd为版本号。 4.2、部门代码 部门代码按《体系文件编号规定》4.3条的规定控制。 4.3、产品（项目）标识及其缩写 产品（项目）标识由反映产品或项目名称的4~5位拼音字母组成，前2位字母为其缩写。如DHMIS是杭州大和热磁电子有限公司管理信息系统的项目标识，而DH则为其缩写。 4.4、子系统标识 子系统标识由2位产品（项目）标识缩写和2~3位子系统名拼音字母组成，其中第3、4两位为子系统标识缩写。如DHXS是大和项目销售子系统的标识，而XS是其缩写。 4.5、配置项标识 4.5.1、4.1.1所述配置标识中的配置项标示：识（cc）如下表所 配置项标识（cc） 系统规格说明书FB 项目开发计划DP 软件需求规格说明书RS 概要设计说明书PD
详细设计说明书DD 用户手册UM 操作手册OM 源程序SP 4.5.2、4.1.2所述配置标识中的配置项标识（cccccc）有以下情况： a、配置项为数据项：配置标识由2位全局标识SY或子系统标识缩 写（局部数据）和3位数字码组成。 如SY001为001号全局数据的配置项标识 XS031为销售子系统031号数据的配置项标识。 b、配置项为数据流： 配置项标识由2位子系统标识缩写，2位数据流标识DF和2位数字码组成。 如ZCDF02为资财子系统02号数据流的配置项标识。 c、配置项为数据存储结构： 配置项标识由2位子系统标识缩写，2位数据存储标识DB和2位数字码组成。 如ZZDB01为制造子系统01号数据存储结构的配置项标识。 d、配置项为程序模块： 配置项标识由2位子系统标识缩写，程序模块标识M和2~3位数字码组成。 如XSM101为销售子系统101号程序模块的配置项标识。 e、配置项为存储媒体 配置项标识由2位产品（项目）标识缩写或子系统标识缩写，2位存储媒体标识FD（软盘）、HD（硬盘）、CD（光盘）或TY（磁带）和2 位数字码组成。 如ZZFD03为制造子系统的03号软盘。 f、配置项为测试计划 配置项标识由2位产品（项目）标识缩写或子系统标识缩写，2位测试计划类别标识和2位数字码组成，其中，组装测试计划类别标识为 TP，确认测试计划类别标识为VP。 数字码00表示产品（项目）或子系统的测试计划，其它数字则表示某一号分计划。 如DHVP00为大和项目确认测试计划的配置项标识。 XSTP01为销售子系统01号测试计划的配置项标识。 4.6、版本号 版本号由2位数字码组成。
XXXXXXXXXX公司项目命名及管理规范 XXXXXXXXXX公司 二○一○年一月
1.目的 为规范公司内部项目命名，确保项目信息传递顺畅；及时沟通项目各环节进展情况，保证项目整体的有效运行；促进经营和财务工作的有序进行，加强公司管理水平，特制定本规范。 2.范围 本规范适用于公司内部各部门间涉及“费用”及“成本”的沟通和信息传递，包括《借款申请单》、《支出凭单》、《差旅费单》及市场、采购、财务相关单据，不涉及公司及部门对外的说明、汇报等文件。 3.项目命名规则 3.1项目名称结构 1、项目名称一共由五部分组成，其中时间、项目类别、项目属性为必填项，客户、项目名称为可选项（二选一），结构如下： 时间+项目类别+客户+项目名称+项目属性 2、应用范围说明： ●时间：为项目正式立项的年度日期。如2010、2011等。 ●项目类别：公司目前所涉及项目分四类：软件类、工程类、其它类、新业务 类、公司类分别使用A、B、C、N代表。 软件类：指软件类业务 工程类：指工程类业务 其它类：指贸易类业务等 新业务类：除以上三类业务外其余业务均属于新业务类。如新业务形成 一定规模，经公司报批后可单独划分业务类型。
●客户：可选项。合同履行的客户对象。如XXXXXX局、XXXXXX公司等。 ●项目名称：可选项。项目的具体说明。如库房管理、运输管理、视频监控、 代理服务器等。 ●项目属性：分为公司交办和自己承担，分别使用J、Z代表。 ●注意事项 ●2010年之前已立项项目保持原有名称不变。 ●项目名称命名可读性第一，应在充分包含相关信息的条件下，尽量简洁，一 目了然。 ●项目类别的中文名称应当根据系统的类型选择使用常用命名词汇。 ●系统的版本不在命名中体现。 ●名称的全称不宜太长，一般在15个字以内（包括数字）。 ●客户、项目名称等字段过长时，可以使用字面意思明白并约定俗成的简称。 ●相同的项目类别、客户和项目名称在不同的项目命名出现时必须保持一致。 3.2示例 软件类项目示例： 工程类项目示例：
项目团队开发规范
修订历史记录
目录 1引言 (6) 1.1 编写目的 (6) 1.2 预期读者 (6) 1.3 编写背景 (6) 2概述 (7) 2.1 目标 (7) 2.2 修改及完善 (7) 3详细规范 (7) 3.1 使用的工具 (7) 3.2 框架设计 (7) 3.3 包目录 (8) 3.4 编码规范 (10) 3.4.1 目的 (10) 3.4.2 依据 (10) 3.4.3 具体规范 (10) 3.4.3.1 编码风格 (10) 3.4.3.1.1 缩进 (10) 3.4.3.1.2 空格 (11) 3.4.3.1.3 对齐 (12) 3.4.3.1.4 空行 (12)
3.4.3.1.5 代码长度 (13) 3.4.3.1.6 行数 (13) 3.4.3.1.7 注释 (14) 3.4.3.2 代码效率 (17) 3.4.3.2.1 综述 (17) 3.4.3.2.2 具体实现 (17) 3.4.3.3 异常处理 (17) 3.4.3.3.1 处理CHECK 异常与UNCHECK异常 (17) 3.4.3.4 程序调试 (17) 3.4.4 日常交流 (18) 3.4.4.1 互相促进 (18)
1引言 1.1 编写目的 本文档作为项目团队开发规范的说明书，描述了项目开发过程中的使用的工具，框架，代码编写规范及注意问题，作为项目团队建设，开发及测试工作的依据。 1.2 预期读者 本文档的预期读者包括以下几类： ?项目组长 ?项目组全体成员 1.3 编写背景 根据公司现有的开发状况，决定组件稳定的项目开发团队，制定全体团队成员共识的开发规范，有助于提高项目开发的效率、项目团队整体水平的提升。
软件项目版本号的命名规则及格式 版本控制比较普遍的3 种命名格式: 一、GNU 风格的版本号命名格式: 主版本号 . 子版本号[. 修正版本号[. 编译版本号]] Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Nu mber]] 示例: 1.2.1, 2.0, 5.0.0 build-13124 二、Windows 风格的版本号命名格式: 主版本号 . 子版本号[ 修正版本号[. 编译版本号]] Major_Version_Number.Minor_Version_Number[Revision_Number[.Build_Nu mber]] 示例: 1.21, 2.0 三、.Net Framework 风格的版本号命名格式: 主版本号.子版本号[.编译版本号[.修正版本号]] Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Nu mber]] 版本号由二至四个部分组成：主版本号、次版本号、内部版本号和修订号。主版本号和次版本号是必选的；内部版本号和修订号是可选的，但是如果定义了修订号部分，则内部版本号就是必选的。所有定义的部分都必须是大于或等于0 的整数。 应根据下面的约定使用这些部分： Major ：具有相同名称但不同主版本号的程序集不可互换。例如，这适用于对产品的大量重写，这些重写使得无法实现向后兼容性。 Minor ：如果两个程序集的名称和主版本号相同，而次版本号不同，这指示显著增强，但照顾到了向后兼容性。例如，这适用于产品的修正版或完全向后兼容的新版本。 Build ：内部版本号的不同表示对相同源所作的重新编译。这适合于更改处理器、平台或编译器的情况。 Revision ：名称、主版本号和次版本号都相同但修订号不同的程序集应是完全可互换的。这适用于修复以前发布的程序集中的安全漏洞。 程序集的只有内部版本号或修订号不同的后续版本被认为是先前版本的修补程序(Hotfix) 更新。 版本号管理策略 一、GNU 风格的版本号管理策略：
项目文档命名规则 编制：日期：____/____/____审核：日期：____/____/____ 批准：日期：____/____/____ XXXX公司 二零一五年五月制
历史记录
目录 1 目的 (4) 2 适用范围 (4) 3 术语和缩略词 (4) 4 规程 (4) 4.1 文档命名规则 (4) 4.2 配置项的版本标识 (8) 4.3 标签的命名 (9)
1 目的 本文的目的是定义各项目所有相关文档和CMM要求的过程文件的格式和规则，以及配置管理中对配置项和版本的标识。 2 适用范围 本规则适用于所有需求、设计等文档和过程文件。 3 术语和缩略词 无 4 规程 4.1 文档命名规则 1组织标准软件过程文档编号 (1)过程文件格式：XXX-P-××，初始编号为：XXX-P-01，最大编号为：XXX-P-99。 (2)指南文件编号：XXX-G-××××，前两位××为指南所对应的过程文件编号。 (3)模板文件编号：XXX-T-××××，前两位××为指南所对应的过程文件编号。 2产品命名规范 (1)中文命名规范：中文全称V产品版本号。英文命名规范：首字母大写V产品版本号。3项目文档编号 (1)编号规则分三种： 1)单个文档：首字母大写V产品版本号-阶段英文缩写-文档名称英文缩写。 2)多个子文档：首字母大写V产品版本号-阶段英文缩写-文档名称英文缩写—流 水号。 3)周期性：首字母大写V产品版本号-文档名称/英文名称-八位日期。 (2)项目阶段及文档名称英文缩写，见下表：
4文档版本 (1)格式：V×××.×××，初始版本号为V0.1，最大版本号为：V999.999。其中， 草稿状态的版本均为V0.×××，例如：V0.1，V0.2……V0.999；而经过评审通过
word 文档格式规范 类目字体及字符间距段落项目符合 和编号 备注标题二号黑体、加粗居中对齐、3 倍行距、正文文本无无副标题小二号黑体、加粗居中对齐、3 倍行距、正文文本无 目录（二字）三号黑体、加粗 间距 10 磅 居中对齐、单倍行距、正文文本、 段前分页 显示【目 录】二字 无 目录内容五号宋体、不加粗 尽量采用“插入索引和目 录”方式获取目录 如果系统插入索引和目录，则不需 手动设置 无 第一级（章）三号宋体、加粗、标准字 符间距 居中对齐、大纲级别 1 级、3 倍 行距、段前分页、其他保持标准 第Ⅰ章（罗 马字母） 无 第二级（节）四号宋体、加粗、标准字 符间距 两端对齐、悬挂缩进 1 厘米、大 纲级别 2级、单倍行距、与下段同 页、其他保持标准 第Ⅰ节（罗 马字母） 无 第三级（一、）四号宋体、不加粗、标准 字符间距 两端对齐、悬挂缩进 1 厘米、大 纲级别 3级、单倍行距、与下段同 页、其他保持标准 一、无 第四级（1.）四号宋体、不加粗、标准 字符间距 两端对齐、左缩进 0.74 厘米、悬 挂缩进0.74 厘米、大纲级别 4 级、单倍行距、与下段同页、其他 保持标准 4 级以下注 释内容需保 持其该级别 左缩进 无 第五级（自定义项目符合和编号）四号宋体、不加粗、标准 字符间距、清单列表无说 明内容字体用小四号宋体 两端对齐、左缩进 1.48 厘米、悬 挂缩进0.74 厘米、大纲级别 5 级、单倍行距、与下段同页、其他 保持标准 自定义项目 符合和编号 该级注释内 容左缩进 第六级（自定义项目符号和编号）四号宋体、不加粗、标准 字符间距、清单列表无说 明内容，字体用小四宋体 两端对齐、悬挂缩进 2.22 厘米、 大纲级别6 级、单倍行距、与下段 同页、其他保持标准 自定义项目 符合和编号 无 正文四号宋体、不加粗、标准 字符间距、清单列表无说 明内容，字体用小四宋体左对齐、首行缩进 2 字符、大纲 级别正文、单倍行距、其他保持标 准；如果为某级下的正文，其缩进 保持与该级别一致 无无 页眉五号字体默认即可公司名称无 页脚五号字体默认即可公司网址，也可加入当前 日期和页码。页码一般右 对齐页面底部，且首页如 果是封页，就不显示页码 图片标签字体图片及标签段落属性项目符合和编号备注 插图和图片小四号宋体该图片正中下，大纲级别为正文，单倍行距，与该 图片保持同页。图片标签序列1.1.1.1.1..
命名规范 目录 第一章文件命名 (3) 1.1 文件命名 (3) 第二章命名规范 (3) 2.1命名概述 (3) 2.2大小写规则 (4) 2.3缩写 (4) 2.4命名空间 (5) 2.5类 (5) 2.6接口 (5) 2.7自定义属性(A TTRIBUTE) (6) 2.8枚举(E NUM) (6) 2.9参数 (7) 2.10方法 (7) 2.11属性(PROPERTY) (7) 2.12事件 (9) 2.13常量(CONST) (10) 2.14字段 (11) 2.16集合 (11) 2.17措词 (12) 第三章控件命名规则 (13) 3.1命名方法 (13) 3.2主要控件名简写对照表 (13) 第四章SQL命名协定 (18) 4.1数据库命名原则及版本控制 (18) 4.4.1数据库命名原则 (18) 4.1.2 数据库版本控制 (19) 4.2S ERVER/命名实例的命名 (19) 4.3数据库命名 (19) 4.4数据库对象—表，视图，列名，约束，规则，默认值 (21) 4.5缩写规范 (22) 4.6列名 (23)
4.7存储过程命名 (25) 4.8游标命名 (25) 4.9触发器命名 (26) 4.10索引命名 (26) 4.11主键和外键命名 (27) 4.12C HECK约束命名 (27) 4.13源文件命名 (28) 4.14J OB的命名 (28) 4.15用户自定义函数命名 (28) 4.16用户自定义数据类型命名 (28) 4.17复制命名 (29)
术语定义 Pascal 大小写 将标识符的首字母和后面连接的每个单词的首字母都大写。例如：BackColor Camel 大小写 标识符的首字母小写，而每个后面连接的单词的首字母都大写。例如：backColor 第一章文件命名 1.1 文件命名 1、文件名遵从Pascal命名法，无特殊情况，扩展名小写。 2、使用统一而又通用的文件扩展名：如C# 文件“.cs” 第二章命名规范 2.1命名概述 名称应该说明“什么”而不是“如何”。通过避免使用公开基础实现（它们会发生改变）的名称，可以保留简化复杂性的抽象层。例如，可以使用GetNextStudent()，而不是GetNextArrayElement()。 命名原则是： 选择正确名称时的困难可能表明需要进一步分析或定义项的目的。使名称足够长以便有一定的意义，并且足够短以避免冗长。唯一名称在编程上仅用于将各项区分开。表现力强的名称是为了帮助人们阅读；因此，提供人们可以理解的名称是有意义的。不过，请确保选择的名称符合适用语言的规则和标准。 以下几点是推荐的命名方法。 1、避免容易被主观解释的难懂的名称，如方面名AnalyzeThis()，或者属性名xxK8。这样的名称会导 致多义性。 2、在类属性的名称中包含类名是多余的，如Book.BookTitle。而是应该使用Book.Title。 3、只要合适，在变量名的末尾或开头加计算限定符（Avg、Sum、Min、Max、Index）。 4、在变量名中使用互补对，如min/max、begin/end 和open/close。 5、布尔变量名应该包含Is，这意味着Yes/No 或True/False 值，如fileIsFound。 6、在命名状态变量时，避免使用诸如Flag的术语。状态变量不同于布尔变量的地方是它可以具有两 个以上的可能值。不是使用documentFlag，而是使用更具描述性的名称，如documentFormatType。 7、即使对于可能仅出现在几个代码行中的生存期很短的变量，仍然使用有意义的名称。仅对于短循 环索引使用单字母变量名，如i或j。可能的情况下，尽量不要使用原义数字或原义字符串，如
C#项目开发代码规范 命名规制定意义 1 方便代码的交流和维护，便于日后自己的再次阅读。 2 不影响编码的效率，不与大众习惯冲突。 3 使代码更美观、阅读更方便。 4 使代码的逻辑更清晰、更易于理解 命名规制定原则 首要原则 有意义的，描述性的词语来命名。能够一眼看出它作什么。别使用会引起误解的名字。如果名字一目了然，就无需用文档来解释方法的功能了 1. 除约定俗成的，别用缩写。用name, address, salary等代替 nam, addr, sal 2. 除用于循环，别使用单个字母的变量象i, n, x 等. 而要使用 index, temp等。 for ( int i = 0; i < count; i++ ){ ...} 其他习惯 除了界面控件外，不要使用类型前缀。比如：使用名称amount，而不是 intAmount； 类：使用名词、名词短语命名。比如：public class FileStream； 方法：使用动词、动词短语开始。比如：CreateUser(), RemoveAt()等； 接口：以 I 开始，后面加上名词、名词短语、形容词命名。比如：IDisposable； 常量：所有单词大写，多个单词之间用 "_" 隔开。public const string PAGE_TITLE = "Welcome"; 命名空间：基本格式： CompanyName/ProjectName.TechnologyName[.Feature][.Design] a) CompanyName/ProjectName：公司名、项目名称或产品名称； b) TechnologyName：稳定的、公认的技术名称或架构层次名称； c) [.Feature][.Design]：可选的功能与设计； C#命名规 变量方法命名规则 1、用pascal规则来命名方法和类.(第一个单词首字母大写，后面连接的每个单词首字母都大写） public class DataBase ；public void GetDataTable() 2、类：使用名词、名词短语命名。比如：public class FileStream； 2.用camel规则来命名局部变量和方法的参数. (第一个单词不大写，后面连接的单词首字母大写) public void AddUser(string userId, byte[] password) { string userName;}
文档格式规范
目录 1 文档格式规范 (1) 1.1文字性文件或规范性文件的编制要求 (1) 1.1.1 文件的整体要求 (1) 1.1.2 文件编制的具体要求 (1) 1.2表格文件的编制要求 (5) 2 文档命名规范 (5)
1 文档格式规范 1.1 文字性文件或规范性文件的编制要求 1.1.1 文件的整体要求 1.1.1.1 文件编制的基本要求 a)文件均采用A4纸幅面。文件的名称应简明准确，一般不超过20个汉字。 b)文件的内容应表达准确、清楚、简明、严谨。 c)同一文件中术语、符号、代号应统一。表达同一术语的概念应前后一致。 采用的术语尚无标准规定时且容易产生不同理解的，应给出定义或说明。 d)文件中的缩略词(语)应采用有关标准或专业委员会认定的缩略词(语)，自 定缩略词(语)应简明、确切，能反映主题。缩略词(语)在文件中首次出现 时应做说明。 e)文件中引用的标准和文件应是现行有效。 f)文件中应采用国务院正式公布、实施的简化汉字。 1.1.1.2 文件封皮的基本要求 a)文件封面的内容分为标题、编制信息和公司名称三部分。 b)文件标题分为“标题”和“副标题”。“标题”描述项目名称，字体：小 初黑体居中；“副标题”描述文件名称，字体：小一黑体居中。“标 题”和“副标题”空一行。 c)文件编制信息包含三个要素，“编制”、“审核”、“批准”：小四宋体加 粗，书写对应人员姓名，姓名中文采用小四宋体，西文采用小四Times New Roman。“版本号”：小四宋体加粗，书写文件版本号，采用小四 Times New Roman；“日期”：小四宋体加粗，书写文件编制日期，采 用小四Times New Roman。 d)公司名称为公司的全称，在文件编制信息后空一行，三号黑体。 e)所有文字性文件或规范性文件中都必须包含文件修改记录，文件修改记 录放在第二页，目录从第三页开始。 f)封面页、文件修改记录页均不插入页脚页码，目录页的页脚中间对齐插
"\n"。 HTML Tab。 作
遵循下面列出的准则有利于编写更加安全的代码。但是总体来说，这些准则不能对安全性做出任何保证。遵循这些准则可能好的实践，但是即使遵循了这些准则，写出的代码仍然可能是不安全的。风险永远存在，不管在编写代码时是如何的警觉。 这些准则的目标，不是为了保证代码的安全性，而是为了消除若干特定类型攻击带来的风险。遵循这些准则，某些特定类型的攻击将无法实现；但是其它类型的攻击仍然可能成功。因此遵循这些准则仅仅是安全的第一步。当书写可能和非守信链接或混用的代码时，应当仔细的考虑如下准则： ?静态字段 ?缩小作用域 ?公共方法和字段 ?保护包 ?尽可能使对象不可变（immutable） ?序列化 ?清除敏感信息 1) 静态字段 避免使用非final的公共静态变量，应尽可能地避免使用非final公共静态变量，因为无法判断代码有无权限改变这些静态变量的值。 一般地，应谨慎使用可变的静态状态，因为这可能导致设想中应该相互独立的子系统之间发生不曾预期的交互。 2) 缩小作用域 作为一个惯例，尽可能缩小成员方法和成员变量的作用域。检查包访问权限成员（package-private）能否改成私有成员（private），保护访问成员（protected）可否改成包访问权限成员（package-private）/私有成员（private）等等。 3) 公共方法/字段 公共变量应当避免使用，访问这些变量时应当通过getter/setter法。在这种方式下，必要时可以增加集中的安全检查。 任何能够访问或修改任何敏感内部状态的公共方法，务必包含安全检查。 参考如下代码段，该代码段中不可信任代码可能修改TimeZone的值： private static TimeZone defaultZone = null; public static synchronized void setDefault(TimeZone zone) { defaultZone = zone;
项目开发命名规划 一．命名规则： 基本规则是按照驼峰式命名方式来对控件命名(控件的缩写加单词，控件的缩写全部为小写，单词的首字母要大写)，如果和数据库相关的字段控件，在命名的时候用控件的缩写加字段名来命名。 1.在Web程序中常用控件的缩写： 2.在CS程序中常用控件的缩写：
3.对于数据库的命名规则： 3.1如果该项目是2次开发的项目由负责人定义一个总表头加在每一 个表或视图或存储过程前面） 3.2码表以A_开头 3.3数据表中以业务名，相关业务用一个开头，这样同样的东西就在 一起 3.4临时表以Temp_开头 3.5测试的表或者临时使用的表以及只用一次然后就删的表用Delete开 头 3.6视图以V_开头+业务名+自己起的名 3.7日志表以Log_开头 3.8存储过程以up_开头 3.9自定函数以f_开头 3.10权限表以R_开头 3.11字段命名待定 3.12码表的自增ID用表名加ID;Name 也加表名称 二．代码规则：
1.同一个业务放到同一个目录里 2.传参数以object为主，要是简单，直接传值。主要方便修改 3.中间层的传递以DataTable为主 4.分成3层第一层是Object 第二层是业务逻辑层第三层是表现层（就是 UI） 5.由于都是对SQL Server操作，数据访问层用SQL Helper 6.Object的定义以业务为主 7.现有的功能，把不常用的功能做一些隐藏处理，让使用者看到的机会变 少，以后用的会少。 8.写代码时，正常的业务需求和特殊的业务需求的代码分离。 三．常用代码整理： 1.验证代码js 2.日历控件的js 3. Email的发送 4. Excel的处理 5. Pdf的处理 6. 错误处理 7. 跳转的处理 8. 权限模块的整理 9. 报表工具的整理 10. Web编辑框的统一
精心整理软件安全开发编码规范 1. 代码编写 1) 开发人员应保证工程中不存在无用的资源（如代码、图片文件等）。 2) 3) 4) ● ● ● ● ● 5) 6) 7) 8) 9) 13) 在进行log的获取时开发人员应尽量使用isXXXEnabled。 14) log的生成环境上尽量避免输出文件名和行号。 15) 产品中不要包含后门代码，隔离系统中的后门代码，确保其不能出现在产品中。作为一种 特殊的调试代码，后门访问代码是为了使开发者和测试工程师访问一部分终端用户不能访问的程序代码。但是，如果后门代码被留到产品中，对攻击者来说，它就是一条不需要通过正常安全手段来攻陷系统的通路。
2. JAVA安全 遵循下面列出的准则有利于编写更加安全的代码。但是总体来说，这些准则不能对安全性做出任何保证。遵循这些准则可能好的实践，但是即使遵循了这些准则，写出的代码仍然可能是不安全的。风险永远存在，不管在编写代码时是如何的警觉。 这些准则的目标，不是为了保证代码的安全性，而是为了消除若干特定类型攻击带来的风险。遵循这些准则，某些特定类型的攻击将无法实现；但是其它类型的攻击仍然可能成功。因此遵循这些准则仅仅是安全的第一步。当书写可能和非守信链接或混用的代码时，应当仔细的考虑如下准则： ? ? ? ? ? ? ? 1) 2) （ 3) 以增加集中的安全检查。 任何能够访问或修改任何敏感内部状态的公共方法，务必包含安全检查。 参考如下代码段，该代码段中不可信任代码可能修改TimeZone的值： privatestaticTimeZonedefaultZone=null; publicstaticsynchronizedvoidsetDefault(TimeZonezone) { defaultZone=zone;
公司项目命名规则 （一）电网基建项目 包括总部(分部)、省级公司电网建设和扩展性改造项目；新源公司管理的抽水蓄能电站和常规水电站、省级公司管理的常规水电站的建设和扩展性改造项目；独立二次项目（总投资1000万元以上，纳入电网基建程序管理独立于输变电工程一次系统以外的配电自动化、通信、调度自动化新建或整体改造项目）。 1.35千伏及以上电网项目 ◆关键要素 项目所在地、电压等级、建设内容、项目性质。 ◆命名规则 （1）输变电工程 项目所在地+ 站名+电压等级+kV+输变电工程 输变电工程包下一般包括变电站新建和线路单项工程： 变电站新建工程： 站名+电压等级+kV+变电站+新建工程 线路工程： 站名～站名+电压等级+kV +线路工程 其他改造、扩建等单项工程可参考相应的命名规则。 示例：江西红都500kV输变电工程 赣州～红都500kV输电线路工程
红都500kV变电站新建工程 天津南蔡500kV输变电工程 南蔡～北郊500kV输电线路工程 南蔡500kV变电站新建工程 河北西柏坡500kV输变电工程 西柏坡～石西500kV线路工程 西柏坡500kV变电站新建工程 天津滨海新华路220kV输变电工程 海门220kV变电站新华路间隔保护扩建工程 滨海新华路220kV变电站新建工程（2）变电工程 包括改造、扩建（含增容扩建）、开关站新建等。 ①变电站扩建 项目所在地+站名+电压等级+kV+变电站/开关站（×号主变或电压等级+kV间隔名+间隔）+扩建工程 适用于变电站设施的增容、间隔扩建。 示例：安徽文都500kV变电站扩建工程 安徽阜阳徐寨220kV变电站2号主变扩建工程 浙江温州周壤220kV变电站1号主变扩建工程 山东青岛夏堤河110kV变电站主变扩建工程 河南鹿邑赵村220kV变电站110kV间隔扩建工程 福建泉州青山220kV开关站1号主变扩建工程 ②变电站改造
软件开发技术文档编写规范 在项目开发过程中，应该按要求编写好十三种文档，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。 ◇可行性分析报告：说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 ◇项目开发计划：为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 ◇软件需求说明书（软件规格说明书）：对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 ◇概要设计说明书：该说明书是概要实际阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计提供基础。 ◇详细设计说明书：着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 ◇用户操作手册：本手册详细描述软件的功能、性能和用户界面，使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识，特别是操作方法的具体细节。 ◇测试计划：为做好集成测试和验收测试，需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。 ◇测试分析报告：测试工作完成以后，应提交测试计划执行情况的说明，对测试结果加以分析，并提出测试的结论意见。 ◇开发进度月报：该月报系软件人员按月向管理部门提交的项目进展情况报告，报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。 ◇项目开发总结报告：软件项目开发完成以后，应与项目实施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本和投入的人力，此外，还需对开发工作做出评价，总结出经验和教训。 ◇软件维护手册：主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明，便于软件的维护。 ◇软件问题报告：指出软件问题的登记情况，如日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。 ◇软件修改报告：软件产品投入运行以后，发现了需对其进行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影响作出详细的描述，提交审批。 1可行性分析报告 1 引言 1.1 编写目的：阐明编写可行性研究报告的目的，提出读者对象。
关于公司知识文档的命名规范 第一条说明 为了方便知识文档的管理、维护、分享，特制定此知识文档规范的命名方式。 此规范根据网络知识管理工具资料整理，主要适用于文档命名，文件夹命名可供参考，请参照执行。 公司所有人员沟通文档必须以此规范作为依据。 第二条文档基本类别 文档按类别可分为三类： 1. 工作文档：包括与日常工作相关的各类文档，其特点在于工作文档多数属于周期性的内 容，围绕各类业务或职能开展。 2. 项目文档：包括以项目形式开展的工作相关的各类文档，其特点在于项目工作通常是一次 性的，以临时性的项目组织为主体开展。 3. 外部文档：包括通过各种渠道从外界收集、获取，未经过公司内部任何人员整理、加工的 资料，其特点在于种类繁多，没有既定的分类标准，无法使用规范性的方式进行管理。 所以，针对这三类文档的不同特点制定了三种不同的命名规范标准。 第三条文档命名规范 1.工作文档命名规范 结合工作文档的特点，我们在命名时需要体现出开展工作的主体，即各个业务或职能部门，同时也需要体现出工作的周期（时间节点）或者是具体的时间点（日期）。 结合上述内容我们将工作文档命名划分成4个部分，各部分之间通常以下划线连接，这4个部分分别是： ①文档来源: 可以是公司、部门、人员等主体性实体。
如：张三_周工作总结_20160808；或研发部_周工作总结_20160808 ②文档内容说明：直接表明主题 ③文档类别：合同、总结、报告、方案等 ④时间节点、日期或版本说明（手工生成）。 图表 1 工作文档命名规范
表格 1 工作文档命名规范 2.项目文档命名规范 结合项目文档的特点，我们在命名时需要体现文档所属的项目主体，同时也需要体现相应的时间点（日期）。 结合上述内容我们将工作文档命名划分成4个部分，各部分之间通常以下划线连接，这4个部分是： ①具体项目：宏观 ②文档内容说明：主题说明 ③文档类别：计划或方案等 ④间节点、日期或版本说明（手工生成），也可以通过日期表示版本。 下面分别通过图示与表格的方式具体说明项目文档的命名规范： 图表 2项目文档命名规范
目录
第一章概述 1.1 编写目的 为规范FSOP项目的开发实施工作，特制定本规范。 为了提高软件开发质量，降低开发周期，增强代码的可重用性和易读性，使软件便于维护，开发人员间便于交流和协作，特总结出开发规范，以为参考。 1.2面向读者 从事FSOP项目的开发、实施工作的相关人员。 1.3名词解释 本节对手册中涉及到的术语进行简单描述。
第二章程序结构 2.1包结构 项目中的所有代码，必须符合如下的结构： 1、各子系统的模块： 其中subsys是子系统的名称，module是模块的名称，xxServlet和xxHandler是模块下面的Servlet 和Handler，允许有多个Servlet和Handler同时存在，建议同一个模块下，用多套Servlet和Handler处理不同的业务对象；util存放该模块专用的类；package/class可以任意级别的包或者类； 2、子系统之外的模块： sm.{module}.servlet.[xxServlet] https://www.doczj.com/doc/531093903.html,mon.util.[xxUtil] https://www.doczj.com/doc/531093903.html,mon.hander.[xxHander] https://www.doczj.com/doc/531093903.html,mon.sql.[xxSql] https://www.doczj.com/doc/531093903.html,mon.entity.[xxxx] 其中sm是system manage的简写，其他同上； 3、公共的类： 含义同上。 2.2相关类 1、对于Servlet，必须继承ServletBase，必须在Servlet中处理与request和response相关的操作，一般是取参数和设置属性等操作； 2、对于Handler，必须继承HandlerBase，该类的方法中，不能用request和response作为参数，更不能用Servlet作为参数； 3、程序中使用到的SQL，一律在XXXSQLBuilder中进行拼写，该类属于util包，需要继承SQLBuilderBase，其构造函数为私有类型，并且要实现静态方法getSQLBuilder(conn)，根据不用的数据库类型，返回不同的实例。