文档编写规范

文档编写规范
文档编写规范

密级:内部公开

版本号:V0.1

文档编写规范

测试部

文档修订记录

目录

1.文档目的 (4)

2.适用范围 (4)

3.正文规范 (4)

3.1.规范总则 (4)

3.2.产品说明书规范 (4)

3.2.1.封面 (4)

3.2.2.页面 (6)

3.2.3.页眉页脚 (6)

3.2.4.文档修订记录 (6)

3.2.5.目录 (6)

3.2.6.标题 (7)

3.2.7.正文 (7)

3.2.8.表格 (8)

3.2.9.图片 (8)

3.2.10.注 (8)

3.3.产品参数表文档 (9)

1.文档目的

本文档用于规范文档编写工作,重在规范和统一文档风格。

2.适用范围

本规范适用于测试部发布的产品文档,包括产品说明书、产品操作说明、产品参数表等用户文档。若无特殊情况(如客户对文档有特定格式的要求),必须严格按照本规范要求进行编写。

3.正文规范

3.1.规范总则

1.编写文档要使用统一的模板,切勿自行修改模块。

2.文档中的语言要正式、规范、简洁明了,尽量避免使用口语化的语言。

3.文档中尽可能避免使用错别字。现在常见错别字类型有使用简体字的繁体、输入法导致的笔误、易混

字的乱用等。

4.文档描述系统功能一定要完整、详细、准确。

5.文档维护过程中尽量前后统一。新增加部分的语言尽力向原有语言风格靠拢,避免前后相差太大给人

不规范的感觉。

6.文档的维护要跟上系统维护的版本。系统升级新的版本后,相应的文档也要做更新。特别是系统做了

变更后,文档中所有涉及到的内容都要做更新。

7.建议一篇文档中的字体颜色不要超过三种。

3.2.产品说明书规范

3.2.1.封面

1.封页为文档的第一页,需包含公司logo、文档标题、公司名称等信息,示例图如下所示:

2.封底为文档的最后一页,需包含公司地址、执行标准编号、公司网址等信息,示例图如下所示:

3.2.2.页面

1.页面、版式原则上使用模版中的默认设置,纸张大小:A4,纸张方向:纵向。

2.页边距:上下各2.54cm,左右各1.91cm,装订线0cm;距边界:页眉1.5cm,页脚1.75cm。

3.2.3.页眉页脚

1.封面不显示页眉与页脚。

2.页眉编辑格式:左边为文档名称,右边为自动更新的日期(年-月-日):宋体(中文)/Times New Roman

(英文和数字)、小五、居中。

3.页脚编辑格式:页码从正文开始,按格式为:第1页,共x页(宋体(中文)/Times New Roman(英

文和数字)、小五、居中)连续编排。

3.2.

4.文档修订记录

文档修订记录内容建议包括:版本号、修改日期、作者(修改人)、修订说明等,如下表所示,可以根据实际情况添加内容。修订页中的版本和作者要与封面的版本和编制一致。

3.2.5.目录

1.文档编写完成后都必须生成目录,目录一般显示到三级。

2.“目录”两字:宋体、三号、加粗、居中对齐,且“目”与“录”之间空两格。

3.目录内容:宋体(中文)/Times New Roman(英文和数字)、五号、常规、两端对齐。

4.一级目录左对齐不缩进,字体使用:宋体(中文)/Times New Roman(英文和数字)、五号;页码右对

齐,标题与页码间使用“…”连接;

5.二级目录左对齐缩进2个字符,字体使用:宋体(中文)/Times New Roman(英文和数字)、五号;页

码右对齐,标题与页码间使用“…”连接;

6.三级目录左对齐缩进4个字符,字体使用:宋体(中文)/Times New Roman(英文和数字)、五号;页

码右对齐,标题与页码间使用“…”连接。

3.2.6.标题

1.正文的章节标题须采用多级编号,且标题级数不要超过4级,其格式如下所示:

一级标题:1.标题1

二级标题:1.1.标题2

三级标题:1.1.1标题3

四级标题:1.1.1.1标题4

2.标题1:宋体(中文)/Times New Roman(英文和数字)、二号、加粗、左对齐;段前17磅、段后16.5

磅、2.4多倍行距、段前分页;标号与标题文字间制表位1.02字符;标号选择样式:标题1。

3.标题2:黑体(中文)/Times New Roman(英文和数字)、三号、加粗、左对齐;段前段后各13磅、1.72

多倍行距;标号与标题文字间制表位2.74字符;标号选择样式:标题2。

4.标题3:宋体(中文)/Times New Roman(英文和数字)、三号、加粗、左对齐;段前段后各13磅、1.72

多倍行距;标号与标题文字间制表位3.43字符;标号选择样式:标题3。

5.标题4:黑体(中文)/Times New Roman(英文和数字)、四号、加粗、左对齐;段前14磅、段后14.5

磅、1.55多倍行距;标号与标题文字间制表位4.11字符;标号选择样式:标题4。

3.2.7.正文

1.正文内容的字体为:宋体、五号,行间距为:段前0.5行、段后0.5行、固定值18磅。

2.除列表内容外,每一段落首行缩进2个字符,从第2行起顶格。

3.正文中需重点突出的部分可以使用加粗的方式区分。

4.正文中将关系有序或并列的相关内容以列表形式组织。列表一般分为表格列表和内容项列表。根据内

容层次,建议最多为两层,且采用以下编号方式:

1第一层:用1.,2.,3.,…表示;

2第二层:用○1,○2,○3,…”表示。

5.当正文内容需要编序号时,须采用统一的自动序号编码,切勿一部分自动序号,一部分手动序号,造

成排版格式的不一致。

3.2.8.表格

1.表格的绘制应遵循简洁、整齐的原则,避免使用复杂的格式。

2.表格都要有表头,表头字体:宋体(中文)/Times New Roman(英文和数字)、小四、居中、18磅固定

行距、底纹填充色为:R:79、G:129、B:189。

3.表内文字:宋体(中文)/Times New Roman(英文和数字)、五号,垂直居中左对齐、18磅固定行距、

底纹填充色为:淡蓝色(R:233、G:237、B:244)与白色(R:255、G:255、B:255)相间的条纹表格。

4.表格总宽度不应超出文档页面界面。

5.当表格跨页时,需拆分表格,并在拆分的表格添加表头,在表格的右上方写“续上表”。字体使用:宋

体、五号、加粗、与表格右边框对齐。

6.表格中不推荐使用斜线表头,具体的替代方式如下图所示:

3.2.9.图片

1.文档中使用的与产品相关的图片均为线构图。

2.若文档中截取的图片为软件操作界面,尤其是手机操作界面或其它边框不明显的操作界面图片时,需

设置边框线:黑色、0.75磅粗细。

3.图片必须居中,左右空隙至少保持2个字符。

4.图片必须被引用,放在段落的下面,例如:“如下图所示:”。

5.单张图片不可以独占一张页面。

6.在整个文档内,图的大小和比例要协调,同一类的图片大小要保持一致,图片中的文字大小不能超过5

号。

3.2.10.注

1.注意部分的文字字体:宋体(中文)/Times New Roman(英文和数字)、五号、行间距为:段前0.5行、

段后0.5行、固定值18磅。

2.注意的文字颜色为:R:51、G:102、B:255。

3.若注意部分的内容为多项时,须采用项目符号“●”表示,且悬挂缩进0.74cm。

3.3.产品参数表文档

1.产品参数表文档为Excel格式,且一个产品线只维护一个参数表文档,不同系列的产品参数在Excel文

档中为一个单独的工作表,按产品发布由新到旧的顺序排列产品系列;同系列不同型号的产品在一个工作表中,按视频路数由低到高的顺序排列产品型号,范例如下图所示:

同系列不同型号的产品参数

表在同一个工作表中,且遵

循从低到高的顺序排列。

不同系列的产品参数表独自

为一个工作表,且遵循从新

到旧的顺序排列。

2.表格为不显示网格线的蓝色风格,表头采用蓝底白字,表体采用白色与淡蓝色相间的底色黑字。在WPS

Excel中使用的表格样式名称为:中度样式1-强调1,范例如下图所示:

3.表格中的字体为宋体,表头字号为:14号,加粗;表体参数分类的字号为:12号,加粗;参数规格的

字号为:12号;参数内容的字号为:11号,范例如上图所示。

4.当表格内容不能一屏显示完整时,鼠标单击选中C2表格,并单击“冻结窗口”功能,将表头与参数规

格项冻结显示,以便方便查看参数表的详细内容,范例如下图所示:参数规格的字体为:宋

体、12号、加粗

表头为蓝底白字,字体

为:宋体、14号、加粗表体参数分类的字体

为:宋体、12号表体为白色与淡蓝

色相间表格样式

不显示网格线

5.IPC产品的参数表文档中需插入对应产品型号的外观图。

6.产品参数表保存的文件类型为:Microsoft Excel97/2000/XP2003文件(*.xls)。

7.产品参数表的命名规则为:产品线名称+产品参数表-最新更新文档的日期,范例如下图所示:

代码编写规范

知识管理系统代码编写规范 一、介绍 本文档为《知识管理系统》代码编写规范,为保证代码风格的一致性和后期的可维护性,文档讲述的内容要求所有开发人员必须遵守。 本规范主要参考了Google Java Style,包括了其他一些业界约定俗成的公约和普遍采用的标准。本规范并非最终标准,一些规定还需再做商讨。 1.1 术语说明 本文档除非特殊说明,否则: 1. 类(class)统指普通类、枚举类、接口和注解类型。 2. 注释(comment)只用来指实现注释(implementation comments)。我们不使用“文 档注释”这样的说法,而会直接说Javadoc。 其他“术语说明”,将在文档中需要说明的地方单独说明。 1.2 文档说明 本文档中的代码并不一定符合所有规范。即使这些代码遵循本规范,但这不是唯一的代码方式。例子中可选的格式风格也不应该作为强制执行的规范。

二、源码文件基础 2.1 文件名 源文件以其最顶层的类名来命名,大小写敏感,文件扩展名为.java。 2.2 文件编码:UTF-8 源码文件使用UTF-8编码。 2.3 特殊字符 2.3.1 空格字符 除了换行符外,ASCII 水平空白字符(0x20)是源码文件中唯一支持的空格字符。这意味着: 1. 其他空白字符将被转义。 2. Tab字符不被用作缩进控制。 2.3.2 特殊转义字符串 任何需要转义字符串表示的字符(例如\b, \t, \n, \f, \r, \", \'和\\等),采用这种转义字符串的方式表示,而不采用对应字符的八进制数(例如\012)或Unicode 码(例如\u000a)表示。 2.3.3 非ASCII 字符 对于其余非ASCII字符,直接使用Unicode字符(例如∞),或者对应的Unicode 码(例如\u221e)转义都是允许的。唯一需要考虑的是,何种方式更能使代码容易阅读和理解。

程序流程图编写规范_(终极整理版)

程序流程图规范 1.引言 国际通用的流程图形态和程序: 开始(六角菱型)、过程(四方型)、决策(菱型)、终止(椭圆型)。在作管理业务流程图时,国际通用的形态:方框是流程的描述;菱形是检查、审批、审核(一般要有回路的);椭圆一般用作一个流程的终结;小圆是表示按顺序数据的流程;竖文件框式的一般是表示原定的程序;两边文件框式的一般是表示留下来的资料数据的存储。 2.符号用法 程序流程图用于描述程序内部各种问题的解决方法、思路或算法。 图1-1 标准程序流程图符号 1)数据:平行四边形表示数据,其中可注明数据名、来源、用途或其 它的文字说明。此符号并不限定数据的媒体。 2)处理:矩形表示各种处理功能。例如,执行一个或一组特定的操作,

从而使信息的值,信息形式或所在位置发生变化,或是确定对某一流向的选择。矩形内可注明处理名或其简要功能。 3)特定处理:带有双纵边线的矩形表示已命名的特定处理。该处理为 在另外地方已得到详细说明的一个操作或一组操作,便如子例行程序,模块。矩形内可注明特定处理名或其简要功能。 4)准备:六边形符号表示准备。它表示修改一条指令或一组指令以影 响随后的活动。例如,设置开关,修改变址寄存器,初始化例行程序。 5)判断:菱形表示判断或开关。菱形内可注明判断的条件。它只有一 个入口,但可以有若干个可供选择的出口,在对符号内定义各条件求值后,有一个且仅有一个出口被激活,求值结果可在表示出口路径的流线附近写出。 6)循环界限:循环界限为去上角矩形或去下角矩形,分别表示循环的 开始和循环的结束。一对符号内应注明同一循环标识符。可根据检验终止循环条件在循环的开始还是在循环的末尾,将其条件分别在上界限符内注明(如:当A>B)或在下界限符内注明(如:直到C

程序代码注释编写规范

程序代码注释编写规范 为提高控制程序的阅读性与可理解性,现制定相关代码程序代码注释编写的编写规范。 一般情况下,源程序有效注释量必须在20%以上,注释的原则是有助于对程序的阅读理解,在该加的地方都加了,注释不宜太多也不能太少,注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"//"符号开始,任何位于该符号之后的本行文字都视为注释。 多行:以"/*"符号开始,以"*/"结束。任何介于这对符号之间的文字都视为注释。 一、说明性文件 说明性文件(如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等)头部应进行注释,注释必须列出:版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等,头文件的注释中还应有函数功能简要说明。 示例:下面这段头文件的头注释比较标准,当然,并不局限于此格式,但上述信息建议要包含在内。 /************************************************* COPYRIGHT (C), MicTiVo International. Co., Ltd. File NAME: // 文件 Author: Version: Date: // 作者、版本及完成日期 DESCRIPTION: // 用于详细说明此程序文件完成的主要功能,与其他模块 // 或函数的接口,输出值、取值范围、含义及参数间的控 // 制、顺序、独立或依赖等关系 Others: // 其它内容的说明 Function List: // 主要函数列表,每条记录应包括函数名及功能简要说明 1.... History: // 修改历史记录列表,每条修改记录应包括修改日期、修改 // 者及修改内容简述 1. Date: Author: Modification: 2. .. *************************************************/ 二、源文件头 源文件头部应进行注释,列出:版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例:下面这段源文件的头注释比较标准,当然,并不局限于此格式,但上述信息建议要包含在内。 /************************************************************ COPYRIGHT (C), MicTiVo International. Co., Ltd. FileName: Author:

产品说明书和用户文档集撰写要求概论

附件4:产品说明的提交要求 说明:红字条款可根据软件产品实际情况进行剪裁,黑字条款为标准要求必须说明的项目。斜体字是对国家标准条款的解读或举例,仅供使用者参考。 一、产品说明: 【定义】 陈述软件各种性质的文档,目的是帮助潜在的需方在采购前对该软件进行适用性评价。 解读:产品说明为供方在进行产品销售时对产品性质的宣传资料,目的是让采购方获得产品概况,判断该产品是否能够满足自己的需求,进而决定是否采购该产品。 【要求】 产品说明对于需求方是可用的,包含潜在需方所需的信息,信息内容应排除内部的不一致,且与用户文档集和软件实际情况一致,产品说明的内容应该是可以验证或测试的,产品说明应有唯一性标识,当产品说明内容超出一页文档时,要有封面和目录,方便使用者进行内容查找。 【内容】 1、软件产品应以其名称、版本和日期指称; 解读:软件产品要用名称+版本或名称+日期命名。 例如:城市水资源管理系统软件V1.0或城市水资源管理系统软件2011。 2、产品说明应显示唯一的标识; 解读:产品说明在封面或卡片的显著位置显示唯一的产品标识。 例如:城市水资源管理系统软件V1.0产品说明。 3、产品说明应包含供方和至少一家销售商(当适用时)电子商务销售商或分销商的名称和地址(邮政的或网络的)。 解读:产品说明在封面或卡片的显著位置显示供方和销售商信息一般包括名称和地址,且供方和销售商可以为同一企业或个人。 4、产品说明应标识该软件能够完成的预期的工作任务和服务; 解读:此项描述软件的销售方向,适用的行业,潜在的客户群,概要介绍软件的用途。

例如:本软件为水务行业管理软件,适用于各供水公司、净水厂、水污染处理企业、政府水资源行业管理部门,可完成水资源相关业务的管理及实施对水资源处理装置的动态监控和实时处理。 5、供方想要声称软件产品符合由法律或行政机构界定的要求时,产品说明应标识出这些法律或行政机构界定的要求的需求文档; 解读:供方为加大产品的宣传力度,增强产品竞争力,更好的销售其软件产品,可表明其产品符合法律或行政机构界定的要求。但必须将符合的内容在产品说明中进行详细说明。 例如:本软件符合中华人民共和国水利行业标准SL475-2010水利信息公用数据元标准,该标准的详细信息参见附录一 6、产品说明应以适当的引用文档指名产品在何处依赖于特定软件和(或)硬件;解读:当产品在某些情况下需要依赖于特定的软件和(或)硬件才能实现其生成的产品性质时,要对这些特定的软件和(或)硬件进行描述,以便采购方在采购产品时能够合理评价采购成本。 例如:本软件在对水资源处理装置进行远程动态监控及实时处理时如传输距离超过50米需要信号放大器或无线信号发射器与无线信号接收器 7、产品说明引证已知的对其他软件的用户可调用的接口时,应标识出这些接口或软件; 解读:如果软件再使用过程中需要调用其他软件许可的接口时,应说明这些接口或软件从而使采购方在选择该产品时,明确还需购买其他接口许可或软件。 例如:本软件运行时需要调用水资源信息实时处理业务系统V1.0 8、产品说明应指明产品期望在单一系统上供多个并发最终用户使用或供一个最终用户使用,并且应说明在所要求的系统的所陈述的性能级别上可行的最大并发最终用户数; 例如:当软件支持并发时,此处可进行如下类似描述:本软件在单一系统上可供多个并发最终用户使用,在服务器主频大于3.0GHZ、内存大于2GB、响应时间小于5秒的情况下最大100并发最终用户。 当软件不支持并发时,此处可进行如下类似描述:本软件在单一系统上只供一个最终用户使用,不支持并发操作。

程序代码注释编写规范

百度文库- 让每个人平等地提升自我 1 程序代码注释编写规范 为提高控制程序的阅读性与可理解性,现制定相关代码程序代码注释编写的编写规范。 一般情况下,源程序有效注释量必须在20%以上,注释的原则是有助于对程序的阅读理解,在该加的地方都加了,注释不宜太多也不能太少,注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"文件、.inc文件、.def文件、编译说明文件.cfg等)头部应进行注释,注释必须列出:版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等,头文件的注释中还应有函数功能简要说明。 示例:下面这段头文件的头注释比较标准,当然,并不局限于此格式,但上述信息建议要包含在内。 /************************************************* (C), MicTiVo International. Co., Ltd. 1.File : . History: Date: Author: Modification: 2. .. *************************************************/ 一、源文件头 源文件头部应进行注释,列出:版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例:下面这段源文件的头注释比较标准,当然,并不局限于此格式,但上述信息建议要包含在内。 /************************************************************ (C), MicTiVo International. Co., Ltd. FileName: Author: Version : Date: : / /*receive _process() */ 意:与溢出中断写初值不同}

软件开发过程文档规范

1.1需求规格说明书 需求规格相当于软件开发的图纸,一般说,软件需求规格说明书的格式可以根 据项目的具体情况采用不同的格式,没有统一的标准。下面是一个可以参照的 软件需求规格说明书的模板。 1.导言 1.1目的 [说明编写这份项目需求规格的目的,指出预期的读者] 1.2背景 说明: a)待开发的产品名称; b)本项目的任务提出者、开发者、用户及实现该产品的单位; c)该系统同其他系统的相互来往关系。 1.3缩写说明 [缩写] [缩写说明] 列出本文件中用到的外文首字母组词的原词组。 1.4术语定义 [术语] [术语定义] 列出本文件中用到的专门术语的定义。 1.5参考资料 [编号]《参考资料》[版本号] 列出相关的参考资料。 1.6版本更新信息 具体版本更新记录如表所列。 表版本更新记录 2.任务概述 2.1 系统定义 本节描述内容包括: ●项目来源及背景; ●项目要达到的目标,如市场目标、技术目标等; ●系统整体结构,如系统框架、系统提供的主要功能,涉及的接口等; ●各组成部分结构,如果所定义的产品是一个更大的系统的一个组成部分, 则应说明本产品与该系统中其他各组成部分之间的关系,为此可使用一张 方框图来说明该系统的组成和本产品同其他各部分的联系和接口。 2.2 应用环境 本节应根据用户的要求对系统的运行环境进行定义,描述内容包括: ●设备环境; ●系统运行硬件环境;

●系统运行软件环境; ●系统运行网络环境; ●用户操作模式; ●当前应用环境。 2.3 假定和约束 列出进行本产品开发工作的假定和约束,例如经费限制、开发期限等。列出本产品的最终用户的特点,充分说明操作人员、维护人员的教育水平和技术专长以及本产品的预期使用频度等重要约束。 3.需求规定 1.1对功能的规定 本节依据合同中定义的系统组成部分分别描述其功能,描述应包括: ●功能编号; ●所属产品编号; ●优先级; ●功能定义; ●功能描述。 1.2对性能的规定 本节描述用户对系统的性能需求,可能的系统性能需求有: ●系统响应时间需求; ●系统开放性需求; ●系统可靠性需求; ●系统可移植性和可扩展性需求; ●系统安全性需求; ●现有资源利用性需求。 1.2.1精度 说明对该产品的输入、输出数据精度的要求,可能包括传输过程中的精度。 1.2.2时间特性要求 说明对于该产品的时间特性要求,如对: a)响应时间; b)更新处理时间; c)数据的转换和传送时间; d)计算时间等的要求。 1.2.3灵活性 说明对该产品的灵活性的要求,即当需求发生某些变化时,该产品对这些变化的适应能力,如: a)操作方式上的变化; b)运行环境的变化; c)同其他系统的接口的变化; d)精度和有效时限的变化; e)计划的变化或改进。 对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。 1.3输入输出的要求 解释各输入输出的数据类型,并逐项说明其媒体、格式、数值范围、精度等。 对软件的数据输出及必须标明的控制输出量进行解释并举例,包括对硬拷贝报

PHP代码编写规范

QC 质量管理体系文件 代码编写规范 受控状态:■受控□非受控 发布日期:2006年02月20日 实施日期:2006年02月24日

1. 引言 1.1. 目的 制定本规范是为了能达到以下目的: ●提高程序员工作效率和代码的利用性 ●程序员可以了解任何代码,弄清程序的状况 ●新人可以很快的适应环境 ●防止新接触php的人出于节省时间的需要,自创一套风格并养成终生的习惯 ●防止新接触php的人一次次的犯同样的错误 ●在一致的环境下,人们可以减少犯错的机会 1.2. 适用范围 适用于本公司的所有开发人员,包括数据库、网页及应用程序开发人员,及有关的程序测试人员。 1.3. 引用标准 GB/T 8566-1995 信息技术软件生存期过程 GB/T 8567-1988 计算机软件产品开发文件编写指南 1.4. 术语 GB/T 11457-1995中所使用的术语适用于本规范。

2. 代码编写规则 2.1. 注释 (1)编写代码期间注释要求占程序总量15%以上。 (2)每个模块顶部必须说明模块名称、功能描述、作者等。 (3)每个过程、函数、方法等开头部分必须说明功能、参数、返回值、原数据和目标数据数据结构等等。 (4)变量定义的行末应当对变量给出注释。 (5)程序在实现关键算法的地方应当给出注释 2.2. 变量、函数、过程、控件等命名规则 (1)变量命名采用[作用范围][数据类型][自定义名称]规则定义,要求看到变量名就能直观的看出其范围和数据类型。 (2)函数、过程、方法、事件等命名应尽量做到观其名知其义。 (3)控件的命名采用[控件类型][自定义名]规则定义,要求通过名字能直观看出控件类型。 (4)自定义命名空间规则,要求能顾名思义 2.3. 源代码规则 风格约定:采用缩进的格式保存程序的层次结构。要求能直观的看出循环、判断等层次结构。

文档编写规范-模板

XXX有限公司文档编写规范

*变化状态:A——增加,M——修改,D——删除

目录 前言................................................................................................................................................................ - 4 -第1章(居中/二号/宋体/TIMES NEW ROMAN/加粗/另起一页)................................................... - 5 - 1.1 (偏左/三号/黑体/Arial/加粗) ............................................................................................ - 5 - 1.1.1 (偏左/三号/宋体/Times New Roman/加粗)........................................................... - 5 - 1.1.1.1 (偏左/四号/黑体/Arial/加粗) ...................................................................... - 5 -

前言【本部分可以有,也可以没有,根据实际情况自定】时间:2010-12-15

第1章(居中/二号/宋体/Times New Roman/ 加粗/另起一页) 1.1 (偏左/三号/黑体/Arial/加粗) 【具体内容】 1.1.1 (偏左/三号/宋体/Times New Roman/加粗) 【具体内容】 1.1.1.1 (偏左/四号/黑体/Arial/加粗) 【具体内容】 贴图格式(居中) 序号格式 1. ● ● ● 2. 3.

软件开发技术文档编写规范

软件开发技术文档编写规范 在项目开发过程中,应该按要求编写好十三种文档,文档编制要求具有针对性、精确性、清晰性、完整性、灵活性、可追溯性。 ◇可行性分析报告:说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性,评述为了合理地达到开发目标可供选择的各种可能实施方案,说明并论证所选定实施方案的理由。 ◇项目开发计划:为软件项目实施方案制订出具体计划,应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 ◇软件需求说明书(软件规格说明书):对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的,也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求,为生成和维护系统数据文件做好准备。 ◇概要设计说明书:该说明书是概要实际阶段的工作成果,它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理设计等,为详细设计提供基础。 ◇详细设计说明书:着重描述每一模块是怎样实现的,包括实现算法、逻辑流程等。 ◇用户操作手册:本手册详细描述软件的功能、性能和用户界面,使用户对如何使用该软件得到具体的了解,为操作人员提供该软件各种运行情况的有关知识,特别是操作方法的具体细节。 ◇测试计划:为做好集成测试和验收测试,需为如何组织测试制订实施计划。计划应包括测试的内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。 ◇测试分析报告:测试工作完成以后,应提交测试计划执行情况的说明,对测试结果加以分析,并提出测试的结论意见。 ◇开发进度月报:该月报系软件人员按月向管理部门提交的项目进展情况报告,报告应包括进度计划与实际执行情况的比较、阶段成果、遇到的问题和解决的办法以及下个月的打算等。 ◇项目开发总结报告:软件项目开发完成以后,应与项目实施计划对照,总结实际执行的情况,如进度、成果、资源利用、成本和投入的人力,此外,还需对开发工作做出评价,总结出经验和教训。 ◇软件维护手册:主要包括软件系统说明、程序模块说明、操作环境、支持软件的说明、维护过程的说明,便于软件的维护。 ◇软件问题报告:指出软件问题的登记情况,如日期、发现人、状态、问题所属模块等,为软件修改提供准备文档。 ◇软件修改报告:软件产品投入运行以后,发现了需对其进行修正、更改等问题,应将存在的问题、修改的考虑以及修改的影响作出详细的描述,提交审批。 1可行性分析报告 1 引言 1.1 编写目的:阐明编写可行性研究报告的目的,提出读者对象。

程序代码注释编写规范

程序代码注释编写规范 XXX份公司

为提高控制程序的阅读性与可理解性,现制定相关代码程序代码注释编写的编写规范。 一般情况下,源程序有效注释量必须在20%以上,注释的原则是有助于对程序的阅读理解,在该加的地方都加了,注释不宜太多也不能太少,注释语言必须准确、易懂、简洁。 常规注释有以下两种方式。 单行:以"//"符号开始,任何位于该符号之后的本行文字都视为注释。 多行:以"/*"符号开始,以"*/"结束。任何介于这对符号之间的文字都视为注释。 一、说明性文件 说明性文件(如头文件.h文件、.inc文件、.def文件、编译说明文件.cfg等)头部应进行注释,注释必须列出:版权说明、版本号、生成日期、作者、内容、功能、与其它文件的关系、修改日志等,头文件的注释中还应有函数功能简要说明。 示例:下面这段头文件的头注释比较标准,当然,并不局限于此格式,但上述信息建议要包含在内。 /************************************************* COPYRIGHT (C), MicTiVo International. Co., Ltd. File NAME: // 文件 Author: Version: Date: // 作者、版本及完成日期 DESCRIPTION: // 用于详细说明此程序文件完成的主要功能,与其他模块 // 或函数的接口,输出值、取值范围、含义及参数间的控 // 制、顺序、独立或依赖等关系 Others: // 其它内容的说明 Function List: // 主要函数列表,每条记录应包括函数名及功能简要说明 1.... History: // 修改历史记录列表,每条修改记录应包括修改日期、修改 // 者及修改内容简述 1. Date: Author: Modification: 2. .. *************************************************/ 二、源文件头 源文件头部应进行注释,列出:版权说明、版本号、生成日期、作者、模块目的/功能、主要函数及其功能、修改日志等。 示例:下面这段源文件的头注释比较标准,当然,并不局限于此格式,但上述信息建议要包含在内。 /************************************************************

文件编写规范

密级:内部公开 文档编号: 版本号:V1.0 分册名称:第1册/共1册 文件编写规范 xxx科技有限公司 编制:生效日期: 审核:批准:

文件更改摘要 日期版本号修订说明修订人审核人批准人

目录 1.目的和范围 (4) 2.目标 (4) 3.术语表 (4) 4.文档编号规则 (5) 5.文档命名规范 (5) 6.文件结构规定 (6) 7.封面 (7) 8.修订页 (8) 9.正文内容格式 (8) 10.文件版本号和文件命名规定 (9) 10.1.文件版本号规定 (9) 10.2.文件命名规定 (9)

1.目的和范围 ●背景说明:本文件作为公司内部文档管理文件,所有公司内编写的文档,均应遵 守本规定,作为公司的所有文档编写统一要求。 ●范围:所有的CMMI执行过程中产生的文档,均应当执行本文件要求作为基础的要 求,如果该部分的体系文件存在明确的要求的,按照体系文件要求执行,没有的则按照本文件执行。 2.目标 规范和统一公司管理体系中所有相关文件的风格和样式,指导公司程序文件、模版文件以及各种记录文件的编写。 3.术语表 ●文件标识:文件的属性标志,包括文件名称、文件编号、版本、生效日期、 审批状态、密级等。 ●程序文件:描述为完成管理体系中所有主要活动提供方法和指导,分配具体的职责 和任务而定义的文件。 ●模版文件:为了使管理体系有效运行,组织统一设计的一些实用的表格和给出活动 结果的报告,规范记录组织的管理体系运行情况。 ●记录文件:简称记录,是组织根据设计的模版和体系要求,填写的表格或者给出活 动结果的报告,作为管理体系运行的证据。 ●修订页:记录文件的修订历史,所有程序文件、除了表格以外的模版和记录都需要 有变更履历,一般位于程序文件的第二页。 ●文档密级:指本文档的保密程度,共分绝密、机密、秘密、内部公开、公开五级制 度。 ●绝密:涉及公司与客户或上游供应商,下游分销商所签订相关的文档资料。仅 限于公司最高管理层及各资料所涉及的经过相应管理人员授权的相关人员查 阅。 ●机密:公司内部所相关的规章制度及技术规范,开发手册等;还有各项目开发 文档、管理文档及软件产品等仅供相关部门高级领导以及经过授权后相关人员 查阅。 ●秘密:需交付用户或与客户进行交流的文档与产品,可供相关项目客户查阅。 ●内部公开:内部不限制,公司内部任何可以任何形式获得文档的信息并阅读、 保存、修改后自用等等,但是不允许向外传播的文件。 ●公开:项目组开发过程中的自用文档或面向售前工作的部分项目介绍材料等。 ●版本标识:作为文档的版本区分。所有发布版本之前不得大于1.0,发布版本作为 1.0,而其后只有重大修改可以调整小数点前的版本号,局部修改调整小数点后版

Java代码编写规范(参考)

命名规范: 1.所有的标识都只能使用ASCII字母(A-Z或a-z)、数字(0-9)和 下划线”_”。 2.一个唯一包名的前缀总是用全部小写的字母。 3.类名是一个名词,采用大小写混合的方式,每个单词的首字母大 写。 4.接口的大小写规则与类名相似。 5.方法名是一个动词或是动词词组,采用大小写混合的方式,第一 个单词的首字母小写,其后单词的首字母大写。 6.变量名的第一个字母小写,任何中间单词的首字母大写,变量名 应简短且可以顾名思义,易于记忆。避免单个字符的变量名,除非是一次性的临时变量。 7.常量的声明应该全部大写,每个单词之间用”_”连接。 注释规范: 1.注释尽可能使用”//”,对于所有的Javadoc的注释使用/***/,而 临时对代码块进行注释应尽量使用/**/。 2.所有的源文件都应该在开头有一个注释,其中列出文件名、日期 和类的功能概述。每个方法必须添加文档注释(main除外)。 3.每个属性必须加注释。 4.代码中至少包含15%的注释。 5.注释使用中文。

缩进排版规范: 1.避免一行的长度超过60个字符。 2.使用Eclipse源代码的格式化功能完成代码的缩进排版。 文件名规范: 1.一个Java源文件只能储存一个Java类。 2.文件名与Java类相同。 3.一个类文件不超过200行。 声明规范: 1.一行声明一个变量。 2.不要将不同类型变量的声明放在同一行。 3.只在代块的开始处声明变量。 4.所有的变量必须在声明时初始化。 5.避免声明的局部变量覆盖上一级声明的变量。 6.方法与方法直接以空行分隔。 语句规范: 1.每行至少包含一条简单语句。 2.在return语句中,返回值不使用小括号”()”括起来。 3.If月总是用{和}括起来。 4.在for语句的初始化或者更新子句中,避免因使用3个以上变量, 而导致复杂度提高。 5.当switch的一个case顺着往下执行时(因为没有break),通常 应在break语句的位置添加注释。

软件过程规范示例

编者说明: 软件过程管理中的一个很重要的工作就是制定项目、组织的过程规范,它是软件开发组织行动的准则与指南。该文档就是一个实际的过程规范的实例,通过该实例,相信对大家根据自身情况制定符合要求的项目过程规范、组织过程规范有很好的借鉴作用。 1.总则 最大限度提高Q&P(质量与生产率),提高Q&P的可预见性,是每一个软件开发机构的最大目标。而Q&P依赖于三个因素:过程、人和技术,因此要实现Q&P的提高,除了加强技术能力,引进、培育更多优质技术人才之外,规范、改进机构的过程是一个十分重要的手段。我们希望通过在制定软件过程规范标准,并在软件开发实践中不断地完善、修订,提高Q&P和Q&P的可预见性。 本规范采用CMM(软件过程成熟度模型)的指导,吸收RUP、XP、MSF、PSP、TSP等过程规范指南的思想、方法及实践,充分结合xxx 技术开发部的实际情况,引入先进的技术、方法、工具,为公司的软件开发工作提供一部详细、可操作的过程指南。在本规范的第一版本中,主要包括管理过程和开发过程两个部分,管理过程中包括项目管理过程、需求变更管理过程、配置管理过程。对于软件开发项目中的其它的一些过程将在实践中逐步补充、完善。

2.项目管理过程规范 项目管理过程主要包括三个阶段:项目立项与计划、项目实施、项目关闭。 项目立项与计划 参与人员:技术开发部指定的项目负责人(包括前期负责人、正式的项目经理)、立项申请人、[相关最终客户]以及实施该项目的开发组队成员; 入口准则:接到经公司总经理或副总经理批准的市场部门的《软件开发立项申请表》; 出口准则:立项申请人签字确认了经修订正后的正式《软件项目计划》,并通过《工作任务卡》下达了开发任务,开发工作正式开始;输入:经审批的《软件开发立项申请表》、与需求相关的业务资料;输出:《软件项目计划》、《软件需求规格说明书》、《开发任务卡》;活动: 接到《软件开发立项申请表》后,技术开发部经理指定前期负责人,并告知立项申请人; 前期负责人阅读《软件开发立项申请表》后,通过与立项申请人的沟通、阅读立项申请人提交的材料、通过立项申请人与客户直接交流

需求分析规范——附加说明1用例描述文档编写规范

百度文库 - 让每个人平等地提升自我 需求分析规范 用例描述文档编写规范(精要) 版本 <> 文档编号:001-0002-2

版本历史 日期版本描述作者2006-07-01 <> 初稿整理吕春秋

目录 1.前言5 1.1目的5 1.2范围5 1.3本文档说明5 2.基本要求6 3.用例事件流的描述6 3.1基本事件流的要求7 3.2子事件流的要求7 3.3备选事件流的要求8 3.4事件流中的序号标号9 3.5事件流中“确认”与“执行”操作描述的建议9 4.业务规则的描述9 4.1业务规则的种类9 4.1.1业务规则的抽取及编号10 4.1.2公共业务规则的抽取及编号10 4.2业务规则描述结构10 4.2.1要点说明式10 4.2.2顺序结构11 4.2.3分支结构11 4.2.4循环结构12 4.2.5混合结构13 4.2.6注意事项13 4.3业务规则描述中的缩进规则13 4.4业务规则描述中的标号13 5.子用例的定义与描述13 5.1子用例的设计方法13 5.2子用例中判断上级调用用例的方法13 6.用例描述中的其它规范14 6.1类、属性、参数、值的书写规则14 6.1.1类名的书写规则14 6.1.2属性名的书写规则14 6.1.3参数名的书写规则14 6.1.4各种值的书写规则14 6.2用例描述中的注释信息15 6.2.1注释要求15 6.2.2注释信息的描述15 6.3描述一致性15 7.接口15 8.新一代ERP系统中的几个公共机制15

8.1删除完整性检查15 8.2消息机制16 8.3编号管理16 9.用例描述中用词规范16 9.1范围值的描述16

软件测试文件编制规范

计算机软件测试文件编制规范 1 引言 1.1 目的和作用 本规范规定一组软件测试文件。测试是软件生存周期中一个独立的、关键的阶段,也是保证软件质量的重要手段。为了提高检测出错误的几率,使测试能有计划地、有条不紊地进行地进行,就必须要编制测试文件。而标准化的测试文件就如同一种通用的参照体系,可达到便于交流的目的。文件中所规定的内容可以作为对测试过程完备性的对照检查表,故采用这些文件将会提高测试过程的每个阶段的能见度,极大地提高测试工作的可管理性。 1.2 适用对象及范围 本规范是为软件管理人员、软件开发人员和软件维护人员、软件质量保证人员、审计人员、客户及用户制定的。 本规范用于描述一组测试文件,这些测试文件描述测试行为。本规范定义每一种基本文件的目的、格式和内容。所描述的文件着重于动态测试过程,但有些文件仍适用其它种类的测试活动。 本规范可应用于数字计算机上运行的软件。它的应用范围不受软件大小、复杂度或重要性的限制,本规范既适用于初始开发的软件测试文件编制,也适用于其后的软件产品更新版本的测试文件编制。 本规范并不要求采用特定的测试方法学、技术及设备或工具。对文件控制、配置管理或质量保证既不指明也不强制特定的方法学。根据所用的方法学,可能需要增加别的文件(如“质量保证计划”)。 本规范既适用于纸张上的文件,也适用于其它媒体上的文件。如果电子文件编制系统不具有安全的批准注册机制,则批准签字的文件必须使用纸张。 2 引用标准 GB/T 11457 软件工程术语 GB 8566 计算机软件开发规范 GB 8567 计算机软件产品开发文件编制指南 3 定义 本章定义本规范中使用的关键术语。 3.1 设计层design level 软件项的设计分解(如系统、子系统、程序或模块)。 3.2 通过准则pass criteria 判断一个软件项或软件特性的测试是否通过的判别依据。 3.3 软件特性software feature 软件项的显著特性。(如功能、性能或可移植性等)。 3.4 软件项software item 源代码、目标代码、作业控制代码、控制数据或这些项的集合。 3.5 测试项test item 作为测试对象的软件项。 4 概述

程序员代码编写标准指南汇总

Delphi 6 程序员代码编写标准指南 一、序言 二、通用源代码格式规则 2.1 缩格 2.2 页边空格 2.3 Begin…End 配对 2.4 代码文件中通用符号含义 三、Object Pascal 3.1 括号 3.2 保留字和关键字 3.3 过程和函数(例程) 3.3.1 命名/格式化 3.3.2 形式参数 3.3.2.1 格式化 3.3.2.2 命名 3.3.2.3 参数的排序 3.3.2.4 常量参数 3.3.2.5 名称的冲突 3.4 变量 3.4.1 变量的命名和格式 3.4.2 局部变量 3.4.3 全局变量的使用 3.5 类型 3.5.1 大写约定 3.5.1.1 浮点指针类型 3.5.1.2 枚举类型 3.5.1.3 变数和ole变数类型 3.5.2 结构类型 3.5.2.1 数组类型 3.5.2.2 记录类型 3.6 语句 3.6.1 if 语句 3.6.2 case 语句 3.6.2.1 一般性话题 3.6.2.2 格式 3.6.3 while 语句 3.6.4 for 语句 3.6.5 repeat 语句

3.6.6 with 语句 3.6.6.1 一般话题 3.6.6.2 格式 3.7 结构异常处理 3.7.1 一般话题 3.7.2 try…finally的使用 3.7.3 try…except的使用 3.7.4 try…except…else的使用 3.8 类类型 3.8.1 命名和格式 3.8.2 域 3.8.2.1 命名/格式 3.8.2.2 可视化 3.8.3 方法 3.8.3.1 命名/格式 3.8.3.2 使用静态的方法 3.8.3.3 使用虚拟/动态的方法 3.8.3.4 使用抽象的方法 3.8.3.5 属性存取方法 3.8.4 属性 3.8. 4.1 命名/格式 3.8. 4.2 使用存取的方法 四、文件 4.1 工程文件 4.1.1 命名 4.2 窗体文件 4.2.1 命名 4.3 数据模板文件 4.3.1 命名 4.4 远端数据模板文件 4.4.1 命名 4.5 Unit文件 4.5.1 通用Unit结构 4.5.1.1 unit的名字 4.5.1.2 uses子句 4.5.1.3 interface部分 4.5.1.4 implementation部分 4.5.1.5 initialization部分 4.5.1.6 finalization部分 4.5.2 窗体单元

软件需求说明书编写规范

{产品名称} 软件需求规格说明书 编写人: 编写日期:年月日

目录 1.产品描述 (3) 1.1.编写目的 (3) 1.2.产品名称 (3) 1.3.名词定义(可选) (3) 2.产品需求概述 (3) 2.1.功能简介 (3) 2.2.运行环境 (3) 2.3.条件与限制(可选) (3) 3.功能需求 (3) 3.1.功能划分(可选) (3) 3.2.功能1 (4) 3.3.功能N (4) 3.4.不支持的功能 (4) 4.数据描述 (4) 5.性能需求(可选) (4) 6.运行需求(可选) (4) 6.1.用户界面 (4) 6.2.硬件接口 (4) 6.3.软件接口 (5) 6.4.通信接口 (5) 7.其它需求(可选) (5) 8.特殊需求(可选) (5) 9.不确定的问题(可选) (5) 10.编写人员及编写日期 (5) 11.附录 (5) 11.1.引用文件 (5) 11.2.参考资料 (5)

1.产品描述 1.1.编写目的 【说明编写本软件需求规格说明书的目的,指出预期的读者。】 1.2.产品名称 【本项目的名称,包括项目的全名、简称、代号、版本号。】 1.3.名词定义(可选) 【对重要的或是具有特殊意义的名词(包括词头和缩写)进行定义,以便读者可以正确地解释软件需求说明。】 2.产品需求概述 2.1.功能简介 【对产品的基本功能做一个简介,包括: 1.本产品的开发意图、应用目标及作用范围。 2.概略介绍了产品所具有的主要功能。可以用列表的方法给出,也可以用图形表示主要的需求分组以及它们之间的联系,例如数据流程图的顶层图或类图等。 3.说明本产品与其他相关产品的关系,是独立产品还是一个较大产品的组成部分。 可以用表示外部接口和数据流的系统高层次图,或者方框图说明。】 2.2.运行环境 1.硬件环境: 【详细列出本软件运行时所必须的最低硬件配置、推荐硬件配置(如主机、显示器、外部设备等)以及其它特殊设备。】 2.软件环境: 【如操作系统、网络软件、数据库系统以及其它特殊软件要求。】 2.3.条件与限制(可选) 【说明本软件在实现时所必须满足的条件和所受的限制,并给出相应的原因。 必须满足的条件包括输入数据的范围以及格式。 所受的限制包括软件环境、硬件环境等方面的内容。例如:必须使用或者避免的特定技术、工具、编程语言和数据库;企业策略、政府法规或工业标准;硬件限制,例如定时需求或存储器限制;经费限制、开发期限;项目对外部因素存在的依赖。例如其它项目开发的组件。等等】 3.功能需求 【功能需求描述系统特性,即产品所提供的主要服务。可以通过使用实例、运行模式、用户类、对象类或功能等级等不同方法来描述,还可以把它们组合起来使用。 功能需求的表述形式可以参见《需求分析和管理指南》第8.2节。】 3.1.功能划分(可选) 【此部分从用户的角度描述将软件划分成不同的部分,并给出总体功能结构。对于复杂

安全代码编写规范

安全代码编写规范 一、编写目的 为加强武汉楚烟信息技术有限公司在软件开发中的安全规范要求,减少应用上线后带来潜在的安全风险,特拟定安全代码编写规范。二、使用范围 本规范适用于武汉楚烟信息技术有限公司承建的各类开发类的软件类项目。 三、应用安全设计 在总体架构设计阶段,需明确与客户方沟通确认甲方对于软件安全的相关要求,对于有明确安全要求的(例如授权管理要求、用户认证要求、日志审计要求等),须在设计文档中予以详细说明。对于互联网应用,务必明确网络安全、应用安全、数据安全相关的安全防护手段。 在技术架构上,应采用表现层、服务层、持久层分类的架构,实现对底层业务逻辑进行有效隔离,避免将底层实现细节暴露给最终用户。 在部署架构上,应采用应用服务器、数据库服务器的分离部署模式,在应用服务器被攻击时,不会导致核心应用数据的丢失。如软件产品具备有条件时,应优先采用加密数据传输方式(例如https协议)。 在外部接口设计方面,应采用最小接口暴露的原则,避免开发不必要的服务方法带来相关安全隐患,同时对于第三方接口,应共同商定第三方接入的身份认证方式和手段。

四、应用安全编码 4.1. 输入验证 对于用户输入项进行数据验证,除常见的数据格式、数据长度外,还需要对特殊的危险字符进行处理。特殊字符包括<> " ' % ( ) & + \ \' \"等 对于核心业务功能,除在客户端或浏览器进行数据验证外,还必须在服务器端对数据进行合法性检验,规避用户跳过客户端校验,直接将不合规的数据保存到应用中。 对于浏览器重定向地址的数据,需要进行验证核实,确认重定向地址是否在可信,并且需要对换行符(\r或\n)进行移除或者替换。 4.2. 数据输出 对需要输出到用户浏览器的任何由用户创造的内容,应在输出到浏览器之前或持久化存储之前进行转义(至少对<>转义为< >)以防止跨站攻击脚本(XSS)。对于无法规避的HTML片段提交,需对