当前位置:文档之家› PLSQL编码规范-细则

PLSQL编码规范-细则

PLSQL编码规范-细则
PLSQL编码规范-细则

PLSQL编码规-细则

文件编号:

版本:1.1

拟制

审核

会签

标准化

批准

XXXXXX公司

XXXIT部

目录

前言 (4)

1范围 (5)

2术语和定义 (5)

2.1原则 (5)

2.2规则 (5)

2.3建议 (5)

2.4说明 (5)

2.5正例 (5)

2.6反例 (5)

3代码布局 (5)

4注释 (9)

5命名规则 (14)

6可读性 (18)

7变量 (19)

8函数与过程 (20)

9程序效率 (22)

10异常处理 (23)

11数据库触发器标准 (24)

12SQL性能优化技术 (24)

版本变更记录

圆珠笔填写,不得涂改。

<本模板中用“< >”括起来的内容包括本段,是编写指导,在最终的文档中应予以删除。其它内容应予以保留。

如果某节内容无需填写,则在该节下写“无”,而不要将本节删除或不填写任何内容(留白将无法判断:是本节内容无需填写还是因为疏忽而忘了填写。)>

前言

编码规范包括总则和细则两部分。总则部分是对编码的总体性规范要求,适用于多种编码语言;细则部分是在总则的规范要求下,针对具体语言的特点而提出的规范要求。本规范是编码规范的细则部分,适用于PLSQL编程语言。

编写本规范的目的是为了进一步规范PLSQL软件编程风格,提高软件源程序的可读性、可靠性和可重用性,确保在开发成员或开发团队之间的工作可以顺利交接,不必花很大的力气便能理解已编写的代码,以便继续维护和改进以前的工作,提高软件源程序的质量和可维护性,减少软件维护成本。

本规范的内容包括:排版、注释、标识符命名、可读性、变量、结构、函数&过程、可测性、程序效率、质量保证、代码编辑&编译&审查、代码测试&维护等。规范最后给出了一个编程实例供软件人员参考。

本规范分成规则性和建议性两种:对于规则性规范,要求所有软件开发人员严格执行;对于建议性规范,各项目编程人员可以根据实际情况选择执行。

自本规范实施之日起,以后新编写的和修改的代码均应执行本规范。

1范围

本标准规定了PLSQL语言的编程规范,主要包括排版、注释、标识符命名、可读性、变量、结构、函数&过程、可测性、程序效率、质量保证、代码编辑&编译&审查、代码测试&维护等。

本规范自生效之日起,对以后新编写的和修改的代码有约束力。

2术语和定义

下列术语和定义适用于本标准。

2.1原则

编程时应该坚持的指导思想。

2.2规则

编程时必须遵守的约定。

2.3建议

编程时必须加以考虑的约定。

2.4说明

对此规则或建议的必要的解释。

2.5正例

对此规则或建议给出的正确例子。

2.6反例

对此规则或建议给出的反面例子。

3代码布局

代码布局的目的是显示出程序良好的逻辑结构,提高程序的准确性、连续性、可读性、可维护性。更重要的是,统一的程序布局和编程风格,有助于提高整个项目的开发质量,提高开发效率,降低开发成本。同时,对于普通程序员来说,养成良好的编程习惯有助于提高自己的编程水平,提高编程效率。因此,统一的、良好的程序布局和编程风格不仅仅是个人主观美学上的或是形式上的问题,而且会涉及到产品质量,涉及到个人编程能力的提高,必须要引起重视。

一般源代码每行的字符数不得超过80,除非只剩下一个单词。如一行源代码超过了80个字符,可在逗号和操作符后面开始换行,并相对第一行缩进2个空格,或相对当前行做调整。正例:

例1: BEGIN

SELECT SUM(quantity)

INTO :zte_rpctq_safe_inventories.quantity FROM zte_rpct_onhand

WHERE subinventory_id = :zte_rpctq_safe_inventories.subinventory_id AND inventory_item_id = :zte_rpctq_safe_inventories.inventory_item_id; EXCEPTION

WHEN NO_DATA_FOUND THEN

:zte_rpctq_safe_inventories.quantity := NULL; END; 例2:

FUNCTION get_prod_config_cost(p_cutoff_date IN DATE, p_product_id IN NUMBER,

p_inventory_item_id IN NUMBER) RETURN NUMBER;

说明:对于由开发工具自动生成的代码可以有不一致。

说明:空行起着分隔程序段落的作用。适当的空行可以使程序的布局更加清晰 正例:

BEGIN

SELECT COUNT (*) INTO NORMAL

FROM fnd_concurrent_requests W HERE status_code = 'C';

SELECT COUNT (*) INTO warning

FROM fnd_concurrent_requests WHERE status_code = 'G';

SELECT COUNT (*) INTO error

FROM fnd_concurrent_requests WHERE status_code = 'E';

END;

反例:如下例子不符合规范。

BEGIN

SELECT COUNT (*) INTO NORMAL

FROM fnd_concurrent_requests W HERE status_code = 'C'; SELECT COUNT (*) INTO warning

FROM fnd_concurrent_requests WHERE status_code = 'G'; SELECT COUNT (*) INTO error

FROM fnd_concurrent_requests WHERE status_code = 'E'; END;

正例:

IF NOT

MRP_GLOBALS .Equal (l_x_flow_schedule_rec .alternate_bom_designator , l_flow_schedule_rec .alternate_bom_designator ) THEN

x_alternate_bom_designator

:= l_x_flow_schedule_rec .alternate_bom_designator ;

END IF;

IF NOT

MRP_GLOBALS .Equal (l_x_flow_schedule_rec .alternate_routing_desig , l_flow_schedule_rec .alternate_routing_desig ) THEN

x_alternate_routing_desig

:= l_x_flow_schedule_rec .alternate_routing_desig ;

END IF;

正例:

PROCEDURE get_next_handle(itemtype IN VARCHAR2, itemkey IN VARCHAR2, actid IN NUMBER, funcmode IN VARCHAR2, resultout OUT VARCHAR2);

l_page NUMBER := 1; l_line NUMBER := 0;

反例:

l_page NUMBER := 1; l_line NUMBER := 0;

正例: DECLARE

…; BEGIN

…; EXCEPTION WHEN OTHERS THEN

NULL; END;

说明:以免用不同的编辑器阅读程序时,因TAB 键所设置的空格数目不同而造成程序布局

不整齐。

正例:

Clear_Block(NO_COMMIT); // 正确 反例:

Clear_Block( NO_COMMIT ); // 错误

注释的原则是有助于对程序的阅读理解,在该加的地方都加了,注释不宜太多也不能太少,注释语言必须准确、易懂、简洁。

正例:

/*+===========================================================================+ 版权信息:版权所有(C) 2004,XXXX有限公司

文件名称:

版本号:

创建者:

创建日期:

内容摘要:<说明此程序文件完成的主要功能,与其他模块或函数的接口,独立或依赖等关系。>

功能列表:主要函数、过程列表,每条记录应包括函数、过程名及功能简要说明

更新历史:更新历史记录列表,每条修改记录应包括更新日期、更新者及更新内容简述更新者更新日期更新内容

+===========================================================================+*/

正例:

/*+===========================================================================+ 版权信息:版权所有(C) 2004,XXXX有限公司

文件名称:

创建者:

创建日期:

内容摘要:项描述本文件的内容、功能、内部各部分之间的关系及本文件与其它文件关系等功能列表:主要函数、过程列表,每条记录应包括函数、过程名及功能简要说明(包体可忽略)

更新历史:更新历史记录列表,每条修改记录应包括更新日期、更新者及更新内容简述更新者更新日期更新内容

+===========================================================================+*/

正例:

/*+===========================================================================+ 名 称:函数或存储过程名称

内容摘要:函数或存储过程功能、性能等的描述 调 用:被本函数、过程调用的函数清单 被调用 :调用本函数、过程的函数清单 创建者

被访问表:被访问的表(此项仅对于牵扯到数据库操作的程序) 被更新表:被修改的表(此项仅对于牵扯到数据库操作的程序)

输 入:输入参数说明,包括每个参数的作用、取值说明及参数间关系。 输 出:对输出参数的说明 返回值 :返回值的说明 其

它:其它说明

+===========================================================================+*/

说明:

修改代码应同时修改相应的注释,不再有用的注释要删除

说明:错误的注释不但无益反而有害。

说明:在使用缩写时或之前,应对缩写进行必要的说明。

正例: 如下书写比较结构清晰

/* 代码段1注释 */ [ 代码段1 ]

/* 代码段2注释 */ [ 代码段2 ]

反例1:

如下例子注释与描述的代码相隔太远。

/* 代码段注释 */

[ 代码段1 ]

反例2:

如下例子注释不应放在所描述的代码下面。

FUNCTION getQtyOeIssued (p_contract_line_id NUMBER ) RETURN NUMBER ; PRAGMA RESTRICT_REFERENCES (getQtyOeIssued , WNDS ,WNPS ); --获取OE 发运数量

反例3:

如下例子,显得代码与注释过于紧凑。 /* 代码段1注释 */ [ 代码段1 ] /* 代码段2注释 */ [ 代码段2 ]

说明:可使程序排版整齐,并方便注释的阅读与理解。 正例:

如下注释结构比较清晰 int DoSomething(void) {

/* 代码段1注释 */ [ 代码段1 ]

/* 代码段2注释 */

[ 代码段2 ]

}

反例:

如下例子,排版不整齐,阅读不方便;

int DoSomething(void)

{

/* 代码段1注释 */

[ 代码段1 ]

/* 代码段2注释 */

[ 代码段2 ]

}

说明:这些语句往往是程序实现某一特殊功能的关键,对于维护人员来说,良好的注释有助于更好的理解程序,有时甚至优于看设计文档。

正例:

/* 变量作用、含义

变量取值范围

使用方法

*/

:global. g_name = ‘a’;

说明:

注释的目的是解释代码的目的、功能和采用的方法,提供代码以外的信息,帮助读者理解代码,防止没必要的重复注释信息。

正例:如下的注释则给出了额外有用的信息

-- 如果库存组织是中兴通讯

if x_main_flag = 0 then

反例:如下注释意义不大

-- 如果x_main_flag 是0

if x_main_flag = 0 then

说明:

当代码段较长,特别是多重嵌套时,这样做可以使代码更清晰,更便于阅读。 正例:

--循环程序段说明

FOR r_batch IN c_batch LOOP l_batch_date :=

get_origin_abs_date

(x_con_header_id ,r_batch .batch_code ); --外判断说明

IF l_batch_date IS NOT NULL

THEN --内判断说明

IF l_abs_date IS NULL OR l_abs_date < l_batch_date THEN l_abs_date := l_batch_date ; END IF –指明哪个IF 语句结束 END IF; --指明哪个IF 语句结束 END LOOP; --指明循环结束

说明:注释语言不统一,影响程序易读性和外观排版,出于对维护人员的考虑,建议使用中文。

说明:在下列情况下必须有注释:

◆完整的功能模块前;

◆不易理解的代码;

◆对原有代码的修改

◆注释行不得少于程序行的30%。

◆在超过三层以上的嵌套语句中,每一个嵌套后都应该加上注释,以表明和哪层

的逻辑语句块对应。

◆单行注释应用“--”,避免使用“/* */”

5命名规则

好的命名规则能极大地增加可读性和可维护性。同时,对于一个有上百个人共同完成的大项目来说,统一命名约定也是一项必不可少的内容。本章对程序中的所有标识符(包括包名、变量名、常量名、控件名、参数名、属性名、函数名、过程名等)的命名做出约定。

说明:较短的单词可通过去掉“元音”形成缩写,较长的单词可取单词的头几个字母形成缩写,一些单词有大家公认的缩写,常用单词的缩写必须统一。协议中的单词的缩写与协议保持一致。对于某个系统使用的专用缩写应该在某处做统一说明。

正例:如下单词的缩写能够被大家基本认可。

temp 可缩写为 tmp ;

flag 可缩写为 flg ;

statistic 可缩写为 stat ;

increment 可缩写为 inc ;

message 可缩写为 msg ;

规定的常用缩写如下:

说明:个人的命名风格,在符合所在项目组或产品组的命名规则的前提下,才可使用。(即命名规则中没有规定到的地方才可有个人命名风格)。

说明:变量,尤其是局部变量,如果用单个字符表示,很容易出错(如l误写成1),而编译时又检查不出,则有可能增加排错时间。过长的变量名会增加工作量,会使程序的逻辑流程变得模糊,给修改带来困难,所以应当选择精炼、意义明确的名字,才能简化程序语句,改善对程序功能的理解。

对于嵌套的循环,一般最外层循环用i,第二层用j,依此类推

说明:软件开发人员应注意软件用户的一些约定术语,不应当随意的创造术语,这会降低软件的易用性。

说明:下面是一些在软件中常用的反义词组。

add/remove ; begin/end ; create/destroy ; insert/delete ;

first/last ; get/release ; increment/decrement ; put/get ;

add/delete ; lock/unlock ; open/close ; min/max ;

old/new ; start/stop ; next/previous ; source/target ;

show/hide ; send/receive ;source/destination ; cut/paste ;

up/down

正例:如 DISP_BUF_SIZE、MIN_VALUE、MAX_VALUE 等等。

i_ :INTEGER

n_ :NUMBER

v_ :VARCHAR2

b_:BOOLEAN

以上前缀可以进一步组合成新的类型,自定义的数据类型可以自己规定类型前缀,如果该类型使用较为广泛,可以升级为公司内部的通用前缀

说明:这样做的目的是为了使程序易读。因为 variable_name 和 variable__name 很难区

分,下划线符号‘_’若出现在标识符头或结尾,容易与不带下划线‘_’的标识符

混淆。

说明:标识符应当直观且可以拼读,可望文知义,避免使人产生误解。程序中的英文单词一

般不要太复杂,用词应当准确

正例:

DECLARE

TYPE resulttabtype IS TABLE OF zte_fa_check_results%ROWTYPE

INDEX BY BINARY_INTEGER;

new_tab resulttabtype;

i BINARY_INTEGER := 0;

l_location_id NUMBER;

l_errstr VARCHAR2(2000);

写。

正例:

Go_Item(‘block’);

Set_Block_Property(‘block’,DEFAULT_WHERE,NULL);

正例:

PROCEDURE start_process;

对于用来设置参数值的过程一般以set开头,如:

PROCEDURE set_leader_as_handle;

对于用来取值的函数一般以get开头,如:

PROCEDURE get_next_handle;

6可读性

说明:

在表达式中使用小括号显式地表达运算优先级,以增加程序的可读性,并

减少出错的危险

说明:一个变量只用来表示一个特定功能,不能把一个变量作多种用途,即同一变量取值不

同时,其代表的意义也不同。

说明:复杂的语句阅读起来,难于理解,并容易隐含错误。

说明:便于程序阅读和查找。

正例:若按如下形式书写,清晰。

rect.length = 10;

rect.width = 5; // 矩形的长与宽关系较密切,放在一起。

char_poi = str;

反例:以下布局不太合理

rect.length = 10;

char_poi = str;

rect.width = 5;

说明:高技巧语句不等于高效率的程序,实际上程序的效率关键在于算法。

7变量

说明:不赞成使用全局变量,除非必要,而且全局变量的作用和取值必须有详细的说明。

说明:这样,一方面可以提高程序的可读性,另一方面有利于程序的维护。

说明:明确过程操作变量的关系后,将有利于程序的进一步优化、单元测试、系统联调以及代码维护等。这种关系的说明可在注释或文档中描述。

说明:对公共变量赋值时,若有必要应进行合法性检查,以提高代码的可靠性、稳定性。

说明:降低公共变量耦合度

8函数与过程

华为软件开发规范

软件开发规范 1 排版 11-1:程序块要采用缩进风格编写,缩进的空格数为4个。 说明:对于由开发工具自动生成的代码可以有不一致。 11-2:相对独立的程序块之间、变量说明之后必须加空行。 示例:如下例子不符合规范。 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 应如下书写 if (!valid_ni(ni)) { ... epssn_index; repssn_ni = ssn_data[index].ni; 11-3:较长的语句(>80字符)要分成多行书写,长表达式要在低优先级操作符处划分新行,操作符放在新行之首,划分出的新行要进行适当的缩进,使排版整齐,语句可读。 示例: = NO7_TO_STAT_PERM_COUNT_LEN + STAT_SIZE_PER_FRAM * sizeof( _UL ); act_task_table[frame_id * STAT_TASK_CHECK_NUMBER + index].occupied

= stat_poi[index].occupied; act_task_table[taskno].duration_true_or_false = SYS_get_sccp_statistic_state( stat_item ); report_or_not_flag = ((taskno < MAX_ACT_TASK_NUMBER) && (n7stat_stat_item_valid (stat_item)) && (act_task_table[taskno].result_data != 0));

工程设计图纸编号规定

1 目的 为统一设计各阶段、各专业设计输出文件标识,防止设计、施工、安装过程中混淆和误用设计文件。 2 适用范围 适用于工程项目的各设计阶段,包括: a) 工程设计,包括可行性研究报告、初步设计、施工图设计; b) 通用设计; c) 非标设备设计。 3 相关文件 MDS-03-2010《工程设计设备编号规定》 MDS-04-2010《设备设计图纸编号规定》 MDS-05-2010《设计图标使用规定》 4 职责 设计部负责工程设计图纸编号的确定和修改(需要时)。具体工作为: a) 工程名称、工程代号的确定; b) 子项名称、子项代号的确定和修改(需要时); c) 图纸编号的确定和修改(需要时)。 各设计所负责对工程计图纸编号的正确使用。 5 程序 5.1 设计文件标识管理 5.2 工程项目设计图纸编号 5.2.1 可行性研究图纸编号 K×××— ××— ×× 工程代号 — 专业代号设计阶段代号— 图纸序号 图纸序号由工程总设计师按可行性研究报告各专业的先后顺序排列。 5.2.2 初步设计图纸编号 a) 当某些专业图纸分子项时,其图纸编号为: K×××— ×××— ××— ×× 工程代号 — 子项代号— 专业代号设计阶段代号 — 图纸序号 b) 当某些专业图纸不分子项时,其图纸编号为: K×××— ××— ×× 工程代号 — 专业代号设计阶段代号— 图纸序号 c) 图纸序号由各专业负责人按子项、按顺序排列。 5.2.3 施工图设计图纸编号(非标准件图纸编号见5. 6.2) K×××— ×××— ××— ×× 工程代号 — 子项代号— 专业代号设计阶段代号 — 图纸序号 5.2.4 图纸序号 图纸序号由各设计人按图纸顺序排列(服从国家规定的常规顺序或施工顺序),取二位数,从01开始。 5.3 工程代号、设计阶段代号和专业代号 5.3.1 工程类别和代号 5.3.1.1 工程类别 工程类别分为国内工程和国外工程。 国内工程符号以“K”表示,“K”为“凯盛”的“凯”第一个拼音大写字母。国外工程符号以“KF”表示。 5.3.1.2 工程代号

工程项目编码规则及管理办法

中船重工船业有限公司工程项目编码规则及管理办法 1. 范围 本办法规定公司各种工程编码分类和编码实施规则及其管理办法。 本规则适用于公司内部所有工程项目的编码计划编制、领发料、财务核算、计算机信息处理等。 2. 工程编码类别及其编制规则说明 2.1工程编码类别分为船舶产品工程、非船产品工程、基建工程、自营工程、设备大修、设备维修、设备技改、安全设施及其它工程。 2.2产品工程编码的编制方法 2.2.1 大吨位运输船舶(千吨位以上)工程号的编制方法 2.2.1.1 编码共6 位。前两位为船舶产品载重吨位或承载体积前两位数;第三位为同载重吨位船舶型号,无型号用0 表示,有型号时分为Ⅰ型、Ⅱ型、Ⅲ型等,分别用1、2、3表示,以此类推;第四、五、六位为公司大吨位运输船舶接单顺序号。 2.2.1.2 图示

例如:公司接单第31 艘70000 吨散货船工程编码为:700031 。 公司接单第18 艘33000 吨散货Ⅰ型船工程编码为:331018 。 2.2.2 商务船工程号的编制办法 2.2.2.1 编码共6位。前两位统一名称为SW(商务);第三、四两位为商务船的长度,五、六两位为商务船接单顺序号。 2.2.2.2 图示 例如:公司接单第1 艘35 米长的商务船,工程号为:SW3501 2.2.3 小吨位(百吨位)运输船工程号的编制办法 2.2. 3.1 编码共6 位。前两位统一名称为YS(运输);第三、四两位为运输船的吨位前两位,五、六两位为公司小吨位运输船接单顺序号。 2.2. 3.2 图示 例如:公司接单第1 艘载重吨为20 吨的运输船,工程号:YS2001

软件开发规范标准整体规范标准

软件开发规范 Software Development Specification Version: V1.0 Date: 2010-06-22 Prepared by

Document Revision History文档修订记录

Table of Contents目录 1Introduction 简介5 1.1Purpose 目标5 1.2Scope 范围6 1.3Definitions, Acronyms, and Abbreviations. 术语,缩略词6 1.4References 引用7 1.5Overview 文档组织7 2The Overall Description 概述8 2.1Software Development Organizing 开发团队组织结构8 2.2Project Base Process 项目基本流程9 2.3CMM Base Process CMM基本过程10 2.3.1SCM软件配置管理10 2.3.2SPP 计划策划12 2.3.3SPTO项目追踪16 2.3.4PR同行评审18 2.3.5SQA质量保证19 2.4SDLC 生命周期选择20 2.5Development Process 开发过程21 2.5.1Development Phase 开发阶段21 2.5.2Phase Product 阶段制品22 2.6Role Duty 角色职责23 2.7Constraints 限制24 3Specific Requirements 详细描述25 3.1Precondition 前提25 3.1.1SCM配置库25 3.1.2Test Environment 测试环境26 3.2Development Control Process 开发控制流程26 3.2.1项目启动和策划阶段27 3.2.2需求分析、设计、编码阶段27 3.2.3提交测试阶段27 3.2.4生产发布、终测28 3.2.5发布后问题反馈修改过程28 3.3TSP 团队软件过程30 3.3.1会议组织30 3.3.2沟通问题30 3.3.3代码走查30

项目编码规范

项目代码编程规范 1.应用范围 本规范应用于采用J2EE规范的项目中,所有项目中的JAVA代码(含JSP,SERVLET,JAVABEAN,EJB)JS代码、HTML代码及数据库设计均应遵守这个规范。同时,也可作为其它项目的参考。 2.设计类和方法 2.1. 创建具有很强内聚力的类 方法的重要性往往比类的重要性更容易理解,方法是指执行一个独立逻辑的一段代码。类常被错误的视为是一个仅仅用于存放方法的容器。有些开发人员甚至把这种思路作了进一步的发挥,将他们的所有方法放入单个类之中。 之所以不能正确的认识类的功能,原因之一是类的实现实际上并不影响程序的执行。当一个工程被编译时,如果所有方法都放在单个类中或者放在几十个类中,这没有任何关系。虽然类的数量对代码的执行并无太大的影响,但是当创建便于调试和维护的代码时,类的数量有时会带来很大的影响。 类应该用来将相关的方法组织在一起。 当类包含一组紧密关联的方法时,该类可以说具有强大的内聚力。当类包含许多互不相关的方法时,该类便具有较弱的内聚力。应该努力创建内聚力比较强的类。 大多数工程都包含许多并不十分适合与其他方法组合在一起的方法。在这种情况下,可以为这些不合群的方法创建一个综合性收容类。 创建类时,应知道“模块化”这个术语的含义是什么。类的基本目的是创建相当独立的程序单元。 2.2. 创建松散连接和高度专用的方法 2.2.1.使所有方法都执行专门的任务 每个方法都应执行一项特定的任务,它应出色的完成这项任务。应避免创建执行许多不同任务的方法。 创建专用方法有许多好处。首先调试将变得更加容易。 2.2.2.尽量使方法成为自成一体的独立方法 当一个方法依赖于其他方法的调用时,称为与其他方法紧密连接的方法。紧密连接的方法

国家标准软件开发主要编写规范

国家标准(GB 8567-88)软件开发主要文档编写规范 本附录中列出了《计算机软件产品开发文件编制指南》GB 8567-88中主要软件文档的编写说明,供编写时参考。这些文档主要是:可行性研究报告、项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、模块开发卷宗、测试计划、测试分析报告、项目开发总结报告。 一、可行性研究报告 l 引言 1.1 编写目的 说明:说明本可行性研究报告的编写目的,指出预期的读者。 1.2 背景 说明: a.所建议开发的软件系统的名称。 b.本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。 c.该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4 参考资料 列出用得着的参考资料,如: a.本项目的经核准的计划任务书或合同、上级机关的批文。 b.属干本项目的其他已发表的文件。 c. 本文件中各处引用的文件、资料,包括所需用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位,说明能够得到这些文件资料的来源。 2 可行性研究的前提 说明对建议开发项目进行可行性研究的前提,如要求、目标、条件、假定和限制等。 2.1 要求 说明对所建议开发软件的基本要求,如: a.功能。 b.性能。 c.输出如报告、文件或数据,对每项输出要说明其特征,如用途、产生频度、接口以及分发对象。 d. 输入说明。系统的输入包括数据的来源、类型、数量、数据的组织以及提供的频度。 e.处理流程和数据流程。用图表的方式表示出最基本的数据流程和处理流程,并输之以叙述。 f. 在安全与保密方面的要求。 g. 同本系统相连接的其他系统。 h. 完成期限。 2.2 目标 说明所建议系统的主要开发目标,如: a. 人力与设备费用的减少。 b. 处理速度的提高。 c. 控制精度或生产能力的提高。

项目编码规则

□机密文件■管制文件□一般文件 主题: 项目编码规则 文件编码: 版本: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)

软件开发标准化工作流程V10

目录 软件开发标准化工作流程 1引言 1.1编写目的 说明编写这份软件开发标准化工作流程的目的,指出预期的读者。 1.2适用范围 互联网开发中心所有项目。 1.3定义 列出本文件中用到的专门术语的定义、外文首字母组词的原词组。

1.4流程图 2需求调研 2.1概述 需求调研对于一个应用软件开发来说,是一个系统开发的开始阶段,需求调研的质量对于一个应用软件来说,是一个极其重要的阶段,它的质量在一定程度上来说决定了一个软件的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。

2.2需求调研 总体而言,需求调研可按照业务流程、业务规则、表单数据、贯穿系统的关系四个方向来进行调研。 ●业务规则 各个流程、功能点等事项的办理,都会有相关约束或条件,那么需要对其前置条件、后置条件、数据验证、条件判断等进行分析调研。调研对象一般为操作员。 ●表单数据 对各个功能点的业务数据、数据项、表单格式、查询条件以及其它相关数据进行明确的分析调研。调研对象一般为操作员。 ●贯穿系统的关系 各个模块或科室之间的数据交换、传递以及数据共享等,需要我们调研人员与各个模块或科室的相关负责人进行多方沟通,确定一个多方满意的需求调研结果。 2.3注意事项 ●调研过程中,用户说的很快,不可能等我们全部记录之后, 再讲下一个问题。因此,只能在笔记本上速记,有时只能记录1、2个关键字。因此,每天调研结束之后,当天晚上必须整理当天的调研情况,写成一份调研日记。整理当天的调研记录时,还要整理出待明确的问题,下一次再找机会与用户再沟通、确认。

●调研的各个阶段,必须出具相关文档或文件,比如调研计划、 流程图、表单样式、报表格式、背景图片、数据项列表、讨论记录、问题列表等。 ●所有疑问必须等到明确的答复,不能出现相互矛盾、似是而 非的需求。需准确理解客户的讲解,如果有问题的先做记录,之后将整理的问题向客户询问,得到明确的结果。需求必须是客户接受和确认的,不能有臆测的需求。 ●要合理安排好时间和进度。有时候客户还有自己要做的事情, 不一定能及时相应。所以必须提前预约好时间,保证整个需求调研的进度。 ●能积极引导客户。当客户出现疑虑,而调研人员能明白且能 做好客户想要的东西的时候,调研人员能及时积极引导客户,详细讲解我们所知道的东西,并能让客户接受与确认。 ●如遇公司有相关原型或产品,调研人员需先详细了解公司的 相关原型和产品,根据成品,找出本地化的差异化需求。 3可行性分析 这个阶段要回答的关键问题:“对于上一个阶段所确定的问题有行得通的解决办法吗?”为了回答这个问题,系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程,也就是在较抽象的高层次上进行的分析和设计的过程。 可行性研究应该比较简短,这个阶段的任务不是具体解决

【编号规则】工程信息编码标准

QB ****公司企业标准 信息分类和编码 第3分册工程信息分类和编码 (初稿) 20XX-XX-XX 发布 20XX -XX -XX 发行 *****有限责任公司 发 布 ICS XXX 备案号XXX

目次 前言 (3) 引言 (4) 1范围 (5) 2规范性引用文件 (5) 3术语和定义 (5) 4分类原则和方法 (6) 4.1基本原则 (6) 4.2分类对象的层面划分 (6) 4.3工程信息分类 (7) 4.4工程信息整体框架 (8) 5编码方法 (9) 5.1基本原则 (9) 5.2码值 (9) 5.3代码组结构和层次 (10) 5.3.1交互定位码 (10) 5.3.2项目编码 (10) 5.3.3管理属性编码 (11) 5.3.4设计属性编码 (11) 5.3.5合同属性编码 (12) 5.3.6档案属性编码 (12) 5.3.7采购、财务、招标信息属性编码 (13) 5.3.8非项目信息编码 (13) 6分类与代码表 (14) 6.1非项目信息分类标识码(30301) (14) 6.2省电网公司及直属单位编码(30302) (14) 6.3工程项目建设管理单位代码(30303) (15) 6.4项目属性代码(30304) (18) 6.5综合指标(30305) (19) 6.6立项时间(30306) (20) 6.7批次项目标识码(30307) (21) 6.8信息属性码分类(30308) (21) 6.9项目阶段代码((30309) (22) 6.10工作分解代码(30310) (22) 6.11信息创建部门代码(30311) (23) 6.12设计资料分类代码(30314) (24) 6.13设计阶段代码(30315) (24) 6.14类目代码(30316) (25)

软件开发文档规范标准[详]

附2: 软件文档编写向导 文档分类 项目包括如下几类文档: 项目管理文档。包括:《软件项目计划》、《项目进度报告》、《项目开发总结报告》 软件开发文档。包括:《需求规格说明》、《概要设计说明》、《详细设计说明》、《测试计划》、《软件测试分析报告》。 产品文档。包括:《用户操作手册》《演示文件》。 软件项目计划 (Software Project Plan) 一.引言 1.编写目的(阐明编写软件计划的目的,指出读者对象。) 2.项目背景(可包括:(1)项目委托单位、开发单位和主管部门;(2)该软件系统与其他系统的关系。) 3.定义(列出本文档中用到的专门术语的定义和缩略词的原文。) 4.参考资料(可包括:文档所引用的资料、规范等;列出资料的作者、标题、编号、发表日期、出版单位或资料来源。) 二.项目概述 1. 工作内容(简要说明项目的各项主要工作,介绍所开发软件的功能性能等. 若不编写可行性研究报告,则应在本节给出较详细的介绍。) 2. 条件与限制(阐明为完成项目应具备的条件开发单位已具备的条件以及尚需创造的条件. 必要时还应说明用户及分合同承包者承担的工作完成期限及其它条件与限制。) 3. 产品 (1)程序(列出应交付的程序名称使用的语言及存储形式。) (2)文档(列出应交付的文档。) (3)运行环境(应包括硬件环境软件环境。) 4.服务(阐明开发单位可向用户提供的服务. 如人员培训安装保修维护和其他运行支持。)5.验收标准

三.实施计划 1.任务分解(任务的划分及各项任务的负责人。) 2.进度(按阶段完成的项目,用图表说明开始时间完成时间。) 3.预算 4.关键问题(说明可能影响项目的关键问题,如设备条件技术难点或其他风险因素,并说明对策。) 四.人员组织及分工 五.交付期限 六.专题计划要点(如测试计划等。) 项目开发进度报告 一.报告时间及所处的开发阶段 二.给出进度 1.本周的主要活动 2.实际进展与计划比较 三.所用工时(按不同层次人员分别计时。) 四.所有机时 五.工作遇到的问题及采取的对策 六.本周完成的成果 七.下周的工作计划 八.特殊问题 项目开发总结报告 一.引言 1.编写目的(阐明编写总结报告的目的,指明读者对象。) 2.项目背景(说明项目的来源、委托单位、开发单位及主管部门。) 3.定义(列出报告中用到的专门术语定义和缩写词的原意。) 4.参考资料(列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源,可包括:(1)项目开发计划;(2)需求规格说明书;(3)概要设计说明书;(4)详细设计说明书;(5)用户操作手册;(6)测试计划;(7)测试分析报告(8)本报告引用的其他资料、采用的开发标准或开发规范。)

技术图纸编号规则及原理图绘制规范

技术图纸编号规则: Elementary Diagram 原理图 W00056200-999401 Interconnection Table 相互接线表 W00056200-999601 System Configuration 系统配制图(通讯回路)W00056200-999101 Single Line Diagram 单线图 W00056200-999111 Outline Diagram 盘柜外形图 101 Terminal Arrangement 端子图 301 arrangement drawing 布置图 201 Structural Drawings 盘柜结构图 111 Part Drawing 零件图 121 Part List 零件列表 131 总共的页数 第几页 盘柜外形图 柜号(小数点用0代替,如73.1柜代号为7301) 项目号 柜盘柜结构图 柜盘柜零部件清单 细分类(自定义)可不用 零件图 盘柜结构件分类号(如太多可不用) 盘柜结构件分类编号规定: 001-普通安装板/梁 002-承重结构件(承重侧板,承重竖梁) 003-门支撑相关(支撑架,支撑轴) 004-加热器相关(加热器罩) 005-照明灯支架 006-端子相关支架 007-开关电源、变压器、整流模块相关支架 008-门限位支架 009-绑线用支架 010-母线用相关安装、防护结构件 011-开关按钮安装相关结构件 012-触摸屏、多功能表、CMS相关结构件 013-通风、过滤系统相关结构件

原理图、外形图绘制的一些规范: 1.英文、数字全部使用ISOCP字体 2.汉字使用宋体 3.字体大小一般使用1.5,空开、主要回路等需要增加注释说明的地方字高使用2.5 4.人名使用中文,日期采用2008-01-02格式 5.继电器绘制注意: ----1,5,9 ----2,6,10 ----3,7,11 ----4,8,12 继电器开关点注释表格需按要求使用开关点 以MY4N为例: 第一格对应1,5,9点 继电器开关点绘制注意考虑接线方式第二格对应2,6,10点 第三格对应3,7,11点 第四格对应4,8,12点 6.盘柜外形图要求按照1:1绘制 7.一般情况下盘柜板材厚度为2.5 8.注意标注盘柜材质是否为不锈钢 .

GB8567-88软件开发主要文档编写规范

GB8567-88软件开发主要文档编写规范

GB8567-88软件开发主要文档编写规范

233 GB 8567-88软件开发主要文档编写规范 本附录中列出了《计算机软件产品开发文件 编制指南》GB 8567-88中主要软件文档的编写说明,供编写时参考。这些文档主要是:可行性研究报告、项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、模块开发卷宗、测试计划、测试分析报告、项目开发总结报告。 一、 可行性研究报告 l 引言 1.1 编写目的 说明:说明本可行性研究报告的编写目的,指出预期的读者。 1.2 背景 说明: a .所建议开发的软件系统的名称。 b .本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。 c .该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3 定义 列出本文件中用到的专门术语的定义和 外文首字母组词的原词组。

234 1.4 参考资料 列出用得着的参考资料,如: a .本项目的经核准的计划任务书或合同、上级机关的批文。 b .属干本项目的其他已发表的文件。 c. 本文件中各处引用的文件、资料,包括所需用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表 日期和出版单位,说明能够得到这些文件资料的来源。 2 可行性研究的前提 说明对建议开发项目进行可行性研究的前 提,如要求、目标、条件、假定和限制等。 2.1 要求 说明对所建议开发软件的基本要求,如: a .功能。 b .性能。 c .输出如报告、文件或数据,对每项输 出要说明其特征,如用途、产生频度、接口以及分发对象。 d. 输入说明。系统的输入包括数据 的来源、类型、数量、数据的组织以及提供的频

项目管理的编码规则

附录 1项目管理编码方案 1.1项目分类 1.1.1编码规则 项目分类采用两层两位字符组合码,1~9加上A~Z(E、I、O及特殊字符除外)。 1.1.2代码表

1.1.3编制说明

项目分类参考了现行的项目分类代码标准。同时在大修、科技项目分类中还参考了《国家电网公司设备大修工作管理办法(试行)》、《国家电网公司技术改造工作管理办法(试行)》相关项目类型的定义及规定。 目前国家电网公司以及各网省公司还保留着部分抽水蓄能电厂以及用于调峰调频、调峰填谷的电厂,为满足这些电力工程的管理需要,在项目分类“基建项目”类中保留了“电源项目”类。 1.2项目编号 1.2.1基建、技改类项目编码规则 1.2.1.1编码规则 项目编号采用4层10位代码结构。 表中: ?N标识该位为数字代码;X标识该位为数字+字母的混合代码。 ?项目类别引用项目类型列表中的2位分类代码。 ?第3、4位代表项目申请单位所属的网省公司,用两位数字标识,直接 引用《国家电网公司直属单位代码》(《国家电网公司直属单位代码》 见人力资源管理编码方案5.1 国家电网公司直属单位代码。)。 ?第5、6位代表项目申请单位,以两位字符标识,由各省自行定义。 ?第7、8、9、10位代表项目编号,以四位字符标识。项目编号流水号允 许实施过程中增加自定义属性信息。 ?项目编号中,当前面代码元素中的一个层次发生变化时,项目编号需重 新开始编号。 1.2.1.2编制说明 基建、技改类项目的项目代码结构包括“项目小类”、“网省公司代码”、“申请单位代码”和“项目编号”四个部分。 与大修、科技、营销类项目编码方案相比,本方案中不包含“立项申请年度”。关于年度问题,编码组讨论了“项目申请年度”、“立项批准年度”等不同的时间点,若采用“项目申请年度”,则从做项目滚动规划到项目申请这之间的时间内,就不能赋予项目相应的编号;若采用“项目申请书编制年度”或“项目开工时间”,也存在同样的问题;采用“立项批准年度”,因有些项目有时会在开

项目编码规范编写指南

项目编码规范 1 命名规范 1).包名采用域后缀倒置的加上自定义的包名,采用小写字母。 在部门内部应该规划好包名的范围,防止产生冲突。部门内部产品使用部门的名称加上模块名称。产品线的产品使用产品的名称加上模块的名称。 格式: com.huawei.产品名.模块名称 com.huawei.部门名称. 项目名称 示例: Relay模块包名 com.huawei.msg.relay 通用日志模块包名 com.huawei.msg.log 2). 类名和接口使用类意义完整的英文描述,每个英文单词的首字母使用大写、其余字母使用小写的大小写混合法。 示例: OrderInformation, CustomerList, LogManager, LogConfig 3). 方法名使用类意义完整的英文描述:第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。 示例: private void calculateRate(); public void addNewOrder(); 4). 方法中,存取属性的方法采用setter 和 getter方法,动作方法采用动词和动宾结构。格式: get + 非布尔属性名() is + 布尔属性名() set + 属性名() 动词() 动词 + 宾语() 示例: public String getType(); public boolean isFinished(); public void setVisible(boolean); public void show();

public void addKeyListener(Listener); 5).属性名使用意义完整的英文描述:第一个单词的字母使用小写、剩余单词首字母大写其余字母小写的大小写混合法。属性名不能与方法名相同。 示例: private customerName; private orderNumber; private smpSession; 6). 常量名使用全大写的英文描述,英文单词之间用下划线分隔开,并且使用 final static 修饰。 示例: public final static int MAX_VALUE = 1000; public final static String DEFAULT_START_DATE = "2001-12-08"; 7). 属性名可以和公有方法参数相同,不能和局部变量相同,引用非静态成员变量时使用 this 引用,引用静态成员变量时使用类名引用。 示例: public class Person { private String name; private static List properties; public void setName (String name) { https://www.doczj.com/doc/9112786857.html, = name; } public void setProperties (List properties) { Person.properties = properties; } } 8).如果函数名超过15 个字母,可采用以去掉元音字母的方法或者以行业内约定俗成的缩写方式缩写函数名。 示例: getCustomerInformation() 改为 getCustomerInfo() 2 程序注释规范 1)、基本注释(必须加)

软件开发过程规范范文

软件开发过程规范范文 1. 前言 1.1 目的 本规范的目的是使整个软件产品开发及项目工程阶段清晰,要求明确,任务具体,便于规范化、系统化及工程化。有利于提高软件生命周期的控制及管理,提高所开发软件的质量,缩短开发时间,减少开发和维护费用,使软件开发活动更科学、更有成效。 1.2 对象 本规范面向产品生命周期的所有相关人员,包括管理人员、开发人员、质管人员。 1.3 要求 具有软件开发管理职能的人员要求熟知项目开发的各阶段过程和各阶段过程相应的规范。 1.4 适用范围 适用于产品开发生命周期中的除产品提交外的其他全部过程;规范分为两部分:技术过程规范和管理过程规范,分别适用于软件开发过程中的技术性活动和管理性活动。 1.5 软件开发过程模型 本规范所采用的软件开发过程模型为简化的RUP开发过程模型;软件开发过程是体系结构为中心,用例驱动和风险驱动相结合的过程迭代。 1.6 开发过程划分 开发过程包括多次迭代,每次迭代的目标和侧重点不同;较早的迭代侧重于业务建模和需求建模;而后的迭代则侧重于分析设计和编码。 2. 技术过程规范部分 2.1 概述 本规范中将软件开发的整个技术过程分为四个顺序实施的阶段,分别为业务建模阶段、需求阶段、分析设计阶段和实现阶段。在对技术过程规范的描述,按阶段内部的活动和产物对四个阶段分别说明。 在本规范中对阶段内活动的说明,是按顺序性活动和持续性活动两类分别进行说明。

对于顺序性活动是按该阶段中活动的总体顺序进行的描述,而在实际工作中,从各活动的具体实施的细节来看,各活动之间的顺序是不断交叉变化的。对于持续性活动主要是对贯穿该阶段过程始终的技术活动进行说明。 规范中所提到的可选文档是指在其所属阶段,可根据具体情况灵活掌握,开发团队自主决定是否开发的文档产物。而提交文档则是指在项目开发过程中必须开发的文档产物,但可根据具体项目情况,在软件开发计划中明确规定是否要形成正式文档并提交。 规范中各阶段提到的技术评审,具体参见《评审规范》中所对应技术性评审的详细描述。 2.2 业务建模阶段 2.2.1 顺序性活动描述 1)开始初步调研,获取初始业务需求,进行问题定义,形成《业 务概览》并建立《术语表》; 2)制定《调研记录表册》,实施详细的业务调研,建立初始的 业务用例模型和《业务用例规格》; 3)分析业务过程,取出可以实现自动化的用例,分析业务部门 和实体对象,形成初始的业务对象模型; 4)根据初始业务对象模型和初始业务用例模型,分析并提取与 系统实现相关的用例和模型,建立系统域模型; 5)精化域模型中的初始用例,详细描述业务流程,分析业务规 则,建立精化的业务用例模型,形成《业务规则》和《业务 用例规格》; 6)精化域模型中的初始对象,进行详细的对象描述,分析对象 职责和对象间关系,建立精化的业务对象模型,形成《业务 对象纵览》; 7)分析业务上的非功能性需求,形成《增补业务规格》; 8)应用业务对象,实现业务用例,制定《业务用例实现规格》, 以验证业务对象与业务用例的正确性,根据验证结果,修正 业务对象、业务用例及相关文档; 9)汇总《业务规则》《业务用例规格》《业务对象纵览》《增 补业务规格》和《业务用例实现规格》形成《业务架构文档》。 2.2.2 持续性活动描述 1)《业务概览》在业务建模阶段,根据对项目理解的不断加深, 随时进行改进; 2)《术语表》的更新维护; 2.2.3 提交文档 1)《业务概览》 2)《术语表》 3)《调研记录表册》 4)《业务架构文档》其附件包括:《业务规则》《业务用例规

图纸编号规则

Pony Technologies 小马技术ENGINEERING DOCUMENT NUMBERING STANDARD 工程文档编号标准 A-001 Revision2 06December,2007

Table of Contents SECTION1-DRAWING MUMBERING3 Dra win g Nu mb erin g Stru cture3 Pla nt Co de3 En gin eering Dis ciplin e3 Area Num ber4 Seq uence Nu mb er5 Deta il Numb er5 Sheet Numb er5 Revis ion Nu mb er5 CAD Filen am e fo r Dra win gs6 SECTION2-DATA SHEET NU MBERING7 Data Sh eet Nu mb erin g Stru cture7 CAD Filen am e fo r Data S heets7 SECTION3-FILE CONTR OL PR OCEDUR ES8 Pro ject Na m e8 W orkin g Do cum en ts8 Serv er Archiv es8

Section1-DRAWING NUMBERING Drawing Number Structure All drawings developed for International projects shall utilize the following numbering structure. The drawing number format will be: 国际项目开发的所有图纸应采用以下编号的结构。绘图数字格式将是: 1016-50-R-1001-00 Detail Number(2digits) Sequence Number(3digits) Area Number Engineering Discipline Plant Code Project Code For example,a drawing may have a drawing number https://www.doczj.com/doc/9112786857.html,ing the codes listed below,this drawing would be for Saratov(Project Code1016),Tin Bath(Plant Code50), Refractory (Discipline R),Canal(Area1),Sequence Number001,and Detail Number00.The Sheet Number and Revision Number will be indicated in the Drawing Title Block. Plant Code 00Civil/General 10Services/Utilities 20Buildings 30Raw Materials 40Furnace 50Float Bath 60Atmosphere Systems 70Lehr 80Cutting Line 85Warehouse Equipment 90Auxiliary Equipment Engineering Discipline The Engineering Disciplines are listed below.The Engineering Discipline for the drawing number example(1016-50-R-1001)is Refractory. A Arrangement/General B Buildings C Civil E Electrical

工程项目编码规则及管理办法

中船重工船业有限公司工程项目编码规则及管理办法 1. 范围 本办法规定公司各种工程编码分类和编码实施规则及其管理办法。 本规则适用于公司内部所有工程项目的编码计划编制、领发料、财务核 算、计算机信息处理等。 2. 工程编码类别及其编制规则说明 2.1工程编码类别分为船舶产品工程、非船产品工程、基建工程、自营工程、 设备大修、设备维修、设备技改、安全设施及其它工程。 2.2产品工程编码的编制方法 221大吨位运输船舶(千吨位以上)工程号的编制方法 221.1编码共6位。前两位为船舶产品载重吨位或承载体积前两位数;第三 位为同载重吨位船舶型号,无型号用 0表示,有型号时分为I 型、H 型、皿 型等,分别用1、2、3表示,以此类推;第四、五、六位为公司大吨位运输 船舶接单顺序号。 2.2.1.2 图示 人吨位运输船接单顺序号 T 一无型号 1- ]型 2- II 型 一3—山甩 载重吨位询闲位数 例如:公司接单第31艘70000吨散货船工程编码为:700031 公司接单第18艘33000吨散货I 型船工程编码为:331018

222商务船工程号的编制办法 222.1编码共6位。前两位统一名称为 SW (商务);第三、四两位为商务船 的长度,五、六两位为商务船接单顺序号。 222.2图示 SW ------------------------------------------ 船舶长度 ------------------------------------------------------- 船舶性质 例如:公司接单第1艘35米长的商务船,工程号为:SW3501 2.2.3小吨位(百吨位)运输船工程号的编制办法 2.2. 3.1编码共6位。前两位统一名称为 YS (运输);第三、四两位为运输 船的吨位前两位,五、六两位为公司小吨位运输船接单顺序号。 例如:公司接单第1艘载重吨为20吨的运输船,工程号:YS2001 运输驸接单嗽序号 船舶吨位

公司图纸编号规范(终板)

DIG图纸、资料的编号管理要求 为规范公司技术出图,方便图纸管理,并适应今后三维制图的出图的要求,特将公司图纸编号方式要求如下。 1、编号构成: 项目编号+图纸类别编号+图纸编号 2、编号说明 编号共七位,用字母和数字表示: ○1、项目编号:公司每一个出图项目都有一个唯一的项目编号,项目编号由技术 部向公司申请。项目编号由三位数组成,第一位采用字母表示,后两位采用数字表示,按顺序编号排序, 即;A01-A99, B01-B99 …… Z01-Z99; 按26位英文字母顺序排列。 ○2、图纸类别编号:该栏定义图纸的类别,采用英文大写字母按顺序标注。具体规定如下: A—机械图纸 B—电气图纸 C—液压、气动图纸 D—设计方案图纸 E—设备地基图纸 F—工装 G—设备说明书、图纸资料 H—操作规程图纸资料 I—包装、运输图纸资料 J---备品备件 …… ○3、图纸编号:该号码是项目中的图纸的零件编号,由3位到4位数字组成。 即:1000张以内项目。从000-999;3位数字组成; 10000张以内项目。0000-9999;4位数字组成 为了适应SolidWorks三维出图零件编号不得重复要求,出图可按顺序编

制零件编号。 特别规定:000和0000作为总装图专用,零件图和部件图编号不得占用; 3、编号示例: 如公司摩擦搅拌焊项目,技术部想公司申请的项目号为A01。 则: 机械图纸编号为A01A000—A01A999 电气图纸编号为A01B000—A01B999 方案图纸编号为A01D000—A01D999 …… 备品备件编号为A01J000—A01J999 其余依此类推; 4、图纸编号使用和图纸存档规范: (1)编号使用规范: 每个项目开始,技术部都将申请一个项目号,并将此号交给项目的主管设计者,再由主管设计者酌情为每位设计者进行分配号段;为避免重号,每一位设计者的编号都不得超出主管设计者给定的范围;如分配的号段不够用,则要告知主管设计者,并由主设计另行再给空白号段进行编号。 为适应SolidWorks三维制图习惯,应每出一张图纸就给图纸规定一个图号;出图时,在装配图中,要求零件序号的引线按照顺时针方向顺序排布,明细表中“序号”一栏从下往上递增,“代号”栏中的图号可以无序排列。 为看图和查阅的方便,每个项目图纸完成后,设计者必须给出一张图纸清单,该清单要求显示出图纸的从属关系。 (2)、图纸存档规范: 技术部所有图纸都要求按照规定进行存档,要求文件目录明确,路径清晰。其存档文件名采用统一的“代号+名称”的格式进行存档。 例如:代号为A01A008的零件,零件名为:传动轴。 则存档的模型的文件名为:A01A008传动轴.sldprt CAD二维图纸为:A01A008传动轴.dwg DIG自动化工程(武汉)有限公司技术部 2013.5.10

相关主题
文本预览
相关文档 最新文档