PowerBuild软件开发标准规范
PowerBuild软件开发标准规范
*编程对象的分类
以PowerBuilder作为前台开发工具，进行软件开发的过程中，所涉及的编程对象如下所示
序号类别
1 源代码
2 可执行代码
3 资源文件（如pbr，bmp，ico文件）
4 配置文件（如ini文件）
5 其他
*编程对象的组织
使用PowerBuilder开发工具产生的对象，可以按照设计（正在编写和调试）和运行（调试、编译结束，可以接受测试和运行）中的状态进行编程对象的组织规划，重点是目录结构的划分，具体目录的相对关系如下所示
类别目录说明
源代码 SrcCode 可按子系统再划分子目录（如pbl等文件夹）
可执行代码 Program或项目名称可按子系统再划分子目录
图片文件 Images或pic等包含应用图标ICO文件、BMP/JPG/GIF文件
配置文件 Ini
其他 Other
**版本说明
a. 软件版本号标准为A . B，其中A和B为0到99之间的数字。
b. 当A大于1并且B为奇数时，表示当前版本为处于开发、测试阶段的版本，定义为“开发版”；当B为偶数时，表示当前版本为稳定的、可实际运行的版本，定义为“稳定版”。
c. 当软件开始开发时，确定版本号为0.1；随着软件开发的进度，版本号随着每一次主要功能的完善而变化，最高达到0.99。
d. 软件初步开发完成后，经过软件开发小组内部测试，初步能够完成软件需求提出的业务规范和技术要求，软件基本能正常运行，此时，确定该软件版本号为1.0 Beta X ，这意味着软件可以投入实际应用测试，其中X代表测试的次数。
e. 当软件的1.0 Beta X 版本推出并经过用户实际应用或者试运行测试后，此时，确定该软件版本号为1.0 RC。这意味着软件可以投入实际应用运行。
f. 当软件的1.0 RC 版本投入实际应用运行达到某一时限后，则认为该版本已经稳定，可以完全正常地使用了，这时，确定软件的版本号为1.0，这意味着软件开发完成，可以投入实际应用和推广。
g. 当软件进行升级时，如果功能变化不大，则次版本号变化；如果软件功能发生重大变化时，主版本号变化。
**对象命名规范
*命名约定
a.部件名称可以达到40个字符，组成方式为A_B。
b.A部分表示前缀，表示部件的类型。
c.紧跟着一条下划线“_”。
d.B部分描述此部件的名称。可以根据情况具体决定B的构成。推荐将B部分分解成两部分：功能代码_功能描述。
e.在重要变量后面写注解表示此变量的用途。
比如，常用的几种对象命名是
窗口的命名：w_功能代码_功能描述。
数据窗口控件的命名：dw_功能代码_功能描述。
数据窗口对象的命名：d_功能代码_功能描述。
菜单命名：m_功能代码_功能描述。
用户对象：uo_功能代码_功能描述。
*具体命名规则
1. 函数的命名规则
函数名=‘函数适用范围代码’ +‘f’+‘_’+‘函数功能描述’，其中函数的
适用范围代码和意义如下：
g 全局函数；
w 窗口函数；
m 菜单函数；
u 用户对象函数。
例：检查SQL语句执行结果的全局用户函数命名如下：gf_checksql()。
2. 应用
应用的命名应使用与该应用的意义相关联的英文字母，例如，app_si表示社会保险应用系统。
3. PBL库
PBL库组织的好坏很重要，它会影响应用开发和维护的容易程度以及应用的性能。Library的组织应遵循以下原则：
a. Library的大小。PowerBuilder对Library的大小没有限制，但最好使之小于1MB，Library太大，PowerBuilder要花更多的时间去打开和存储对象，这会影响开发的效率。
b. Library的数量。尽量用最少的Library数量。应在Library的数量和每个Library 中对象数量之间找到平衡点，如果Library数量太多而每个Library中对象数量太少，搜索路径会太长，影响运行效率。
c. Library的优化。要在Library画笔中经常对Library进行优化。随着时间的推移，Library会被分段，会使Library的存储变得不连续，影响运行效率。
d. Library的分类组织。PBL库可按子系统或功能组织，一般应用都包含公共PBL库。每个PBL库文件命名应该与该文件作用相关联，例如报表PBL库文件命名为report.pbl。
每个PBL库文件应该包含详细注释，列出该PBL文件包含哪些对象，对应哪个子系统，与其他PBL（调用）关系等信息。
为了有效地进行团队开发，实现对PB源码的管理，要求基于对各方因素（如应用代码的执行效率和所占存储空间）和维护上的全面考虑，对PB源码实行分类的原则。PowerBuilder的Library的分类原则有两种方式：
（1）制定对象分类法
根据所制定的不同类的对象进行分类。
例：将所有的窗口放在一个Library中。
（2）功能模块分类法
根据系统的功能模块的不同，将属于不同类的制定对象放在一个Library中。这是一种更为有效的方式。
4. 初始化配置文件
初始化配置文件的命名必须与应用的名称一致，扩展名为.ini，例如：si.ini。用户的可变环境信息都应该保存在该文件中，关键信息加密保存，并且提供管理工具，而不是手工修改该文件。
5. 资源文件
资源文件的命名必须与应用的名称一致，扩展名为.pbr，例如：si.pbr。
6. 窗口
窗口的命名必须以w（Window的首字符）开头，加下划线（_），其后紧接与窗口意义相关联的英文字母（总长不得超过PowerBuilder的40个字符限制），并且在注释（Comments）框内写出该窗口的作用（中文或英文），如下所示。
序号窗口名称 Comments
1 w_about 关于本系统的版权信息
2 w_system_error 系统出错提示
3 w_main 系统主界面
4 w_report_sheet 报表输出
7. 数据窗口
普通数据窗口的命名必须以dW（DataWindow缩写）开头，代码表下拉式子数据窗口必须以dddw（DropDownDataWindow缩写）开头，加下划线（_），其后紧接与数据窗口意义相关联的英文字母（总长不得超过PowerBuilder的40个字符限制），并且在Comments 框内写出该数据窗口的作用（中文或英文），如下所示。
序号数据窗口名称 Comments
1 d_system_error 显示系统错误，被w_System_Error窗口调用
2 d_categories 对产品分类，被w_Report_Sheet窗口调用
3 d_detail_parts Parts of Products Described in Detail
4 d_detail_function Products Function Described in Detail
5 dddw_sex 性别代码表
8. 菜单
菜单的命名必须以 m（Menu缩写）开头，加下划线（_），其后紧接与菜单意义相关联
的英文字母（总长不得超过PowerBuilder的40个字符限制），并且在Comments 框内写出该菜单的作用（中文或英文），如下所示。
序号菜单名称 Comments
1 m_main Front End Main Menu
2 m_report Report Subsystem Menu
3 m_main_pop 主界面的弹出菜单
9. 函数
函数的命名必须符合<类型>f_subsystemname_detailname或 lf_detailname格式，其中gf表示是全局函数，subsystemname是子系统的英文缩写，detailname是与函数意义相关联的英文字母（总长不得超过PowerBuilder的40个字符限制），对于全局函数应该在Comments 框内简短写出该函数的作用（中文或英文），如下所示。
序号函数名称 Comments
1 gf_help_index 帮助子系统索引全局函数
2 lf_get_user_info 获取用户信息局部函数
3 gf_query_sortbyname 查询子系统名排序全局函数
10. 用户对象
用户对象的命名必须以uo（UserObject缩写）开头，加下划线（_），其后紧接与用户对象意义相关联的英文字母（总长不得超过PowerBuilder的40个字符限制），并且在Comments框内写出该用户对象的作用（中文或英文），如下所示
序号用户对象名称 Comments
1 uo_external_function Cross platform user object ancestor
2 uo_report_structure User Object as a structure For report
11. 控件
控件的命名必须以控件名称缩写开头，加下划线（_），其后紧接与控件作用相关联的英文字母（总长不得超过PowerBuilder的40个字符限制），如下所示
序号控件名称控件缩写控件命名范例
1 CommandButton cb cb_ok
2 PictureButton pb pb_thank_info
3 CheckBox cbx cbx_age_show
4 RadioButton rb rb_typical_setup
5 StaticText st st_user_id
6 Picture p p_user_photo
7 GroupBox gb gb_detail_info
8 Line ln ln_h_separator
9 Oval oval oval_used_flag
10 Rectangle r r_photo_frame
11 RoundRectangle rr rr_companyflag
12 SingleLineEdit sle sle_user_name
13 MultiLineEdit mle mle_book_comments
14 RichTextEdit rte rte_student_answer
15 EditMask em em_telephone_no
16 HScrollBar hsb hsb_time_set
17 VScrollBar vsb vsb_money_set
18 DropDownListBox ddlb ddlb_your_favourite
19 DropDownPictureListBox ddplb ddplb_photo_preview
20 ListBox lb lb_department_name
21 PictureListBox plb plb_user_identification
22 ListView lv lv_all_user
23 TreeView tv tv_customers
24 TabPage tpg tpg_ordinary_super
25 Tab tab tab_super
26 DataWindow dw dw_user_info_detail
27 Graph gr gr_month_report
28 Ole ole ole_word_doc
**变量命名规范
变量取名应遵守命名规范，对使用频繁的或关键变量，为了便于阅读和修改，在定义时应加上注释标明其含义。例如：
String ls_name // 参保人员姓名
变量命名规则为：变量范围 + 变量数据类型 + '_' + 含义代码
*变量数据类型约定
数据类型前缀
Any a_
Blob bb_
Boolean b_
Character c_
Date d_
DateTime dt_
Decimal dec_
Double db_
Integer i_
Long l_
String s_
Time t_
UnsignedInteger ui_
UnsignedLong ul_
DataWindow dw_
DataWindowChild dwc_
MailSession ms_
Menu m_
Structure str_
Transacttion trans_
Window w_
UserObject uo_
*变量范围命名约定
范围字首描述
Global g?_ 全局变量将在整个应用中有效。它们可能从
其他对象面板中定义，但它们将在整个应用中有效
Shared s?_ 共享变量在一个对象及其实例中有效
Instance i?_ 实例变量仅在一个对象的实例中有效。相应对象
的不同实例中的变量保存各自的值
Local l?_ 局部变量仅在一段子程序或在script开始和结束时生效
由值传递的变量 v?_ 在定义函数时，参数仅传递值，不会被函数
(仅适用于函数变量) 改变，定义为value,例：vdw_datawindow
由引用传递的变量 r?_ 在定义函数时，参数将被此函数改变，
(仅适用于函数变量) 定义为reference，例：rl_long
注意：？表示相应数据类型，如i,c,l,s等数据类型前缀。
对于上述的内容做如下说明。
a. 全局变量的命名必须符合gT_subsystemname_detailname格式，其中g表示是全局变量（Globe），T是数据类型（DataType）的简写。subsystename是子系统的英文简写。detailname是有具体意义的英文字母。例如：gs_query_user_info ，即为查询子系统定义了一个字符串型全局变量。
b. 局部变量的命名必须符合lT_detailname格式，其中l表示是局部变量（Local），T是数据类型（DataType）的简写。例如：li_user_salary ，即定义了一个整数型局部变量。
c. 实例变量的命名必须符合iT_detailname格式，其中i表示是实例变量（Instance），T是数据类型（DataType）的简写。Detailname是有具体意义的英文字母。例如：
is_product_name ，即定义了一个字符串型实例变量。
**编程规范
*书写格式
a.用分层缩进的写法显示嵌套结构的层次。
b.在注释段与程序段，以及不同逻辑的程序段之间插入空行。
c.每行只写一条语句，当需要滚动显示时应该分行书写。
*流控制
流控制首先应遵守PowerBuilder语法规范，且用分层缩进的写法突出显示嵌套的层次结构，例如：
For i = 1 To 100
For j = 1 To 50
For k = 1 To 200
Matrix[i，j，k]=1
Next
Next
Next
*注释及格式要求
注释总是加在程序中需要概括性说明或不易令人理解或容易令人理解错的地方。注释语言应简练、易懂而又准确，所采用的语种首选是中文，如有输入困难或特殊需求也可采用英文。
注释原则：
a.函数或过程的注释
(1)在函数头部必须说明函数的功能和参数（值参、变参）；
(2)在函数的主体部分，如算法复杂时，应以注释的方式对其算法结构做出说明；
(3)函数申请过全局资源且有可能导致资源紧张应加以注明(如内存和文件柄等)；
(4)函数有副作用一定以十分醒目的方式(如加!号等)注明。
b.语句的注释
(1)应对不易理解的分支条件表达式加注释；
(2)不易理解的循环，应说明出口条件(有GOTO的程序还应说明入口条件)；
(3)过长的函数实现，应将其语句按实现的功能分段加以概括性说明。
c.常量和变量的注释
在常量名声明后应对该名做适当的注释，注释说明的要点是：
(1)被保存值的含义(必须) ；
(2)合法取值的范围(可选)；
(3)全局量需要对以上逐点做充分的说明。
d.制定对象的注释
每个开发人员针对自己所制定的窗口、菜单、数据窗口、数据管道和用户对象等添加注释，要点是：
(1)标注对象的用途；
(2)标注对象的制定人员；
(3)标注时间或者修改时间。
具体格式要求如下：
1. 在窗口Open事件前应说明
/* ======================================================= */
// 窗口中英文名称：
// 窗口作用：
// 作者：
// 日期：
/* ======================================================= */
2. 在事件脚本(Script)之前应说明
/* ======================================================= */
// 脚本作用：
// 输入参数及数据类型：
// 返回参数及数据类型：
// 全局函数及其用途：
// 全局变量及其用途：
// 作者：
// 日期：
// 修改人的姓名：
// 修改日期：
// 修改原因：
/* ===================================================== */
若有多人修改，每个人均加上自己的注释，而不能改他人的姓名、日期、原因，对要修改的脚本，只能注释不能删除，并且在修改的地方加上修改人名、日期和"Beginning Modification... "，"Ending Modification"字样。
3. 脚本中的注释
单行脚本程序注释：
// 注释文本
脚本的程序段注释：
/* ================================== */
//
// 注释文本
//
/* ================================== */
变量的注释如下：
数据类型变量名 //注释
4. 在函数、存储过程等脚本(Script)之前应说明
/* ======================================================= */
// 函数名称：
// 参数解释：
// 功能描述：
// 调用举例：
// 最初作者：
// 编写日期：
// 返回值：
// 变量情况：
// 修改人：
// 修改日期：
// 修改原因：
/* ======================================================== */
*Powerbuilder脚本编程规范
1. Powerbuilder编程注意事项
a.不要在子应用中声明全局变量！如必须声明全局变量，则应事先向项目负责人申请。
b.供别的文件或函数调用的函数，绝不应使用全局变量交换数据。
c.所有SQL语句均需判断返回结果(包括SELECT，COMMIT语句)。
例：
If sqlca.sqlcode = -1 Then
错误处理程序
跳出
Else
正常
End If
d.缺省SQLCA的连接语句connect，在应用Open事件中完成，其disconnect在主应用的Close事件中完成，其余任何pbl中均不能有disconnect语句。
e. 由于要连接多个数据库，需要用Create创建对象，比如：SQLSYB，则用 connect using SQLSYB，处理完毕后用 disconnect using SQLSYB，并且用 destroy SQLSYB释放资源。
2. 编码标准
（1）在代码块前后留一个空行。例子如下：
If
End If
For
Next
（2）把单行注释与当前script程序的缩进位置对齐：
//This is a comment For condition1
If
//This is a comment For condition2
If
//This is a comment For action1
End If
End If
（3）缩进应以Tab键实现，不得采用空格。
（4）变量采用小写格式。注意：
① 变量全部用小写；
② 一个变量一行，每个变量必须注释；
③ 通常情况下，变量的后半部分尽量用数据库字段名；
④ 变量声明全部在脚本之前声明完毕；
⑤ 所有变量声明时按代码功能段 + 变量类型进行排序。例如：
Long ll_quantity
String ls_name
对象名采用小写，属性、关键字、保留字和内置函数均用首字母大写格式：
w_cont_de.Visible = True
m_mdi.m_file.m_print.Enabled = False
数据窗口控制的函数加上修饰，而不以数据窗口对象作为参数：
dw_main.SetTransObject(sqlca)
dw_main.SetRowFocusIndicator(Hand!)
dw_main.Retrieve()
（5）当连接起来的字符串超过了两行的长度时，使用 + 符作为下行的第一个字符，每次均采用缩进格式。字符串的随后部分应该再次缩进。例如：
ls_msg = "连接数据库失败！错误信息为：~r~n" &
+ Sqlca.SqlErrText &
+ "请与系统管理员联系"
（6）PowerBuilder保留字(关键字)首字母大写其余小写，这样看起来层次清晰，如：This，Parent，ParentWindow，True，False，Return，Halt与Close。
（7）PowerBuilder内部函数及属性每个字首字母大写其余小写，这样看起来层次清晰，如：sle_user.Text，dw_1.SetTransObject(Sqlca)，Sqlca.SqlErrText。
（8）SQL语句按如下格式书写：
SELECT name，sex，dept_id
INTO ：ls_name，：ls_sex，：ls_dept_id
FROM employee
WHERE emp_id = ：ls_emp_id ；
（9）程序中应避免出现 goto 跳转语句。
3. 脚本中一些常用功能模块的编程约定
（1）光标操作过程的编程约定如下：
Declare Cursorname Cursor for
Select语句
Open Cursorname；
fetch Cursorname into
Do While Sqlca.Sqlcode = 0
fetch Cursorname into
Loop
Close Cursorname
光标命名规则：“Cur” + “_” + 名称。
（2）调用数据库存储过程的编程约定如下：
declare Procedurename procedure For StoredProcedureName
：Value1，：Value2......；
execute Procedurename；
fetch Procedurename into
close Procedurename；
commit；
存储过程命名规则：“Pro” + “_” + 名称。
有些系统存储过程（例如：sp_droplogin）不能当做一个事务提交，为了执行它，就必须先置事物对象的AutoCommit属性为True，当存储过程执行完毕后再将事务对象的AutoCommit属性置为False。
（3）在每一个SQL语句之后必须判断SQL语句执行成功与否，成功则继续，不成功则做相应处理并给出一条提示信息。
If Sqlca.SqlCode <> 0 Then
Rollback ；
MessageBox("错误信息"，"操作失败！")
Else
Commit；
MessageBox("提示信息"，"操作成功！")
End If
（4）所有操作符（包括等号）前后应留一空格，使程序看起来更清晰。例如：
ls_msg = ls_title + ls_error
（5）仅当绝对需要时才在循环结构体中使用函数调用，也就是说，仅当函数的返回值依赖于循环迭代的值时才使用函数调用。
使用如下方法:
Long ll_num_selected
ll_num_selected = lb_devctg.TotalSelected()
For i = 1 To num_selected
……
Next
不使用下述方法：
For i = 1 To lb_1.TotalSelected()
……
Next
4. PB中的任何一个窗口都要有注释说明
一般在窗口的Open事件中对窗口的功能进行全面的介绍，以便维护人员可以很清楚地知道窗口的功能和维护要点。其格式可参见前面的说明。
5. 表的操作
在程序中涉及多个表的操作时，需严格按照各项目组“表操作顺序一览表”规定的顺序对表进行操作，以防发生锁表现象。
**控件编程规范
*公共部分
a.应尽量为所有控件使用有意义的名称，重要控件不允许使用 pb_1 之类无明确意义的名称。
b.大号字体：各窗口控件字体为Arial，字号为12号，字色为黑色。小号字体：各窗口控件字体为宋体，字号为9号，字色为黑色。
c.显示控件和输入控件底色分开，显示控件为灰色(窗口颜色)，输入控件为白色。
d.输入区和显示区分别放置。
e.按钮排列紧凑，在窗口右侧纵向排列时靠上放置；在窗口下方排列时靠右放置，因为左撇子操作者毕竟是少数。
f.各字符类控件对齐方式为左对齐；数字类控件为右对齐，且必须按所需格式设置Format 属性；日期控件必须保证能完整显示所需日期格式，应用yyyy-mm-dd风格。及有前导0的形式（避免2000年问题），可采用左对齐或中对齐。
https://www.docsj.com/doc/9d9899147.html,mandButton控件的推荐高度为104。
*控件细则
1. 静态文本框
静态文本框命名规则：st + '_' + 名称（若为label可不改名）。
外观规定如下：
背景色：buttonface；
前景色：黑色；
边框：无；
高度：72。
建议在其后加上全角冒号（：）。
2. 单行编辑框
单行编辑框命名规则：sle + '_' + 名称。
（1）外观
背景色：白色；
前景色：黑色；
边框：3D Lowered；
高度：72。
（2）程序说明
a.响应事件建议自定义 Keydown 事件，尽量不要用 Modify 事件。
b.当获得焦点时控件背景变为深蓝色，字体颜色变为黄色，失去焦点时还原缺省颜色。
3. 命令按钮
命令按钮命名规则：cb + '_' + 名称
（1）外观
高度：对于小号字体（宋体9号）为92；
对于大号字体（Arial 12号）为108。
宽度：对于小号字体（宋体9号）为325；
对于大号字体（Arial 12号）为402。
（2）说明
命令按钮控件不要使用 cb_1 之类无明确意义的名称(尤其在窗口中这类控件比较多时，可能令人分不清各个控件的作用)。
4. 图像按钮
尽量不用图形按钮，而用命令按钮。
图像按钮命名规则： pb + '_' + 名称。
外观规定如下：
尺寸：用图像原始尺寸；
图像：按钮的有效与无效采用不同的bmp图像以示区别。
5. 复选框
复选框命名规则：cbx + '_' + 名称
外观规定如下：
背景色：buttonface；
前景色：黑色；
边框：3D Lowered；
高度：92；
位置：标签在右。
6. 单选按钮
单选按钮命名规则：rb + '_' + 名称。
（1）外观
背景色：buttonface；
前景色：黑色；
边框：3D Lowered；
高度：92；
位置：标签在右。
（2）程序说明
单选按钮最好与组框配合使用。
7. 组框
组框命名规则：gb + '_' + 名称。
外观规定如下：
背景色：buttonface；
前景色：黑色；
边框：3D Lowered。
8. 屏蔽编辑框
屏蔽编辑框命名规则：em + '_' + 名称。
（1）外观
背景色：白色；
前景色：黑色；
边框：3D Lowered。
（2）程序说明
a.响应事件建议用自定义 Keydown 事件，尽量不要用 Modify 事件。
b.当获得焦点时控件背景变为深蓝色，字体颜色变为黄色，失去焦点时还原缺省颜色。
9. 下拉列表框
下拉列表框命名规则：ddlb + '_' + 名称。
外观规定如下：
背景色：白色；
前景色：黑色；
边框：3D Lowered。
10. 应用
应用命名规则：app + '_' + 应用名。
为应用选择一个图标，以便在运行时标识应用。
在 Open 事件中声明 SQLCA 全局变量和打开应用主窗口。
在 Closequery 事件中编写退出应用之前的处理程序。
在 SystemError 事件中编写系统出错的处理程序。
11. 窗口
窗口命名规则： w + '_' + 窗口名。
主窗口采用 main 窗口类型，子窗口一般采用 Popup 窗口类型，无控制菜单，无最大化最小化按钮，不可改变大小。若为一般性提示窗口，用 response 窗口类型。
窗口以 buttonface 颜色为背景颜色。
重要的菜单选项设置 Toolbar 功能。
窗口上下左右四周应至少留出两个网格，而不得将对象填满整个窗口！
12. 菜单
菜单命名规则： m + '_' + 菜单名。
菜单项 MenuItem 的名称以该菜单项在整个菜单中的物理位置分层次命名。
例：若 MenuItem 位于整个菜单的第三列第二行，则命名为 m_32。
或文件菜单下的“关闭”菜单项，则命名为 m_file_close。
13. 数据窗口对象
数据窗口对象命名规则：d + '_' + 功能含义。
打印用数据窗口背景色为白色，题目为16号字，内容为11号字，显示比例为75%。
显示用数据窗口背景色原则上为 buttonface，可视窗口制作是否美观的实际情况使用白色数据窗口各列显示框高度为 72。
Tabular和Grid风格数据窗口，无表头时列名文本边框为3D Raised。Detail区为3D Lowered，背景色原则上为白色。Grid风格数据窗口一般不出现线条。
14. 数据窗口控件
数据窗口控件命名规则：dw + '_'+ 功能含义。
数据窗口边框原则上为 3D Lowered，也可酌情使用 none 外加 group。
15. 用户对象命名
用户对象命名规则：uo + '_'+ 功能含义。
公共对象对应以上各控件规范制作。
**用户反馈
在系统中对用户的操作及时地提供反馈信息是十分重要的，这些反馈信息也许只是像警告铃或将鼠标显示成沙漏等一样不起眼的反应，但是却能使用户树立信心，使他感到仍在控制软件而没有死机。
*使用反馈的场合
在客户/服务器环境下用户最不能忍受的是系统反应速度慢，而在实际的应用中却会经常遇到计算机需要比较长的时间执行一个或一批操作。在这种情况下，应加入反馈，让用户了解应用正在做什么。比如：
a.在需等待时间较短(0~10秒)的情况下应将鼠标显示成为沙漏，为此可调用函数SetPointer(HourGlass!)来实现这一功能；
b.在处理时间需10~18秒时，由微帮助来显示处理进度；
c.当处理时间需18秒以上时，要显示这个处理窗口或显示进度条；
d.当一个长时间的处理完成后应发出一个提示警告声如Beep(1)，这样用户就不必总看着屏幕。
*提供反馈的几种技术手段
1. 微帮助
微帮助是MDI(多文档界面)框下面的状态条中的文字。窗口底部的微帮助一般有两个作用：一是在用户选择菜单项或其他窗口控件时，显示更多的文字信息来解释或提示用户所要进行的操作是什么；另一个用途是系统在处理过程中显示正在进行的工作状态，以使用户了解系统的处理进度，从而免去对死机的担心。
2. 工具条的帮助
当鼠标停留在某一个工具条上时，会出现一个弹出式信息框，在PowerBuilder 4.0以上的版本中，缺省显示的是工具条文字。也可以用菜单画笔在工具条文字之后加一个逗号，加入一段更长的文字来定义一个不同的工具条说明。例如，键入“退出，关闭应用”，将看到在带文字的工具条图标上显示的文字是“退出”，而弹出的信息框显示的是“关闭应用”。
3. 声音提示
在用户可能进行破坏性操作时，用声音及时提出警告是必要的，但是不能滥用，因为当用户无法正确操作软件或做了不希望做的事情时，听到警告声反而会更加烦恼，因此要慎重使用这种反馈方法。此外，在一个长处理结束时使用声音反馈 ( 如警告声或小段悦音)也是必要的。
**提高程序的健壮性
统一的外观；
引用对象前的有效性检验；
使用正确的数据窗口列名；
使用适当的GUI控件来使得用户输入有效；
需要时对数据窗口的列做保护；
提交前对数据窗口列做约束检验；
避免用户进入危险地带；
对用户不经意的操作做出提示。
**文档标准
文档不仅包括应用系统的设计文档，还包括源程序的相关注释及帮助文档等
**错误处理标准
对错误的处理和状态监测程序实行标准化
以下几个方面的检查可以考虑用标准的方法处理：
联结错误；
数据库存取错误；
数据录入错误；
程序执行错误。
**其他
应用开发中尽量使用过去已经开发好的模块。
使用面向对象编程中的继承特性。
使用PowerBuilder之外的辅助开发工具：设计工具；版本控制工具；测试工具。
华为软件开发规范
软件开发规范 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));
软件设计文档国家标准GB8567
软件设计文档国家标准GB8567-88 一、文档编写标准化 在整个项目开发及使用过程中，应该有完备的文档支持，文档编制要求具有针对性、精确性、清晰性、完整性、灵活性和可追溯性。 完备的文档对软件的开发及使用起了很大的作用。一般要求编写好十三种文档。 1、可行性分析报告 说明该软件开发项目的实现在技术上、经济上和社会因素上的可行性，评述为了合理地达到开发目标可供选择的各种可能实施方案，说明并论证所选定实施方案的理由。 2、项目开发计划 为软件项目实施方案制订出具体计划，应该包括各部分工作的负责人员、开发的进度、开发经费的预算、所需的硬件及软件资源等。 3、软件需求说明书（软件规格说明书） 对所开发软件的功能、性能、用户界面及运行环境等作出详细的说明。它是在用户与开发人员双方对软件需求取得共同理解并达成协议的条件下编写的，也是实施开发工作的基础。该说明书应给出数据逻辑和数据采集的各项要求，为生成和维护系统数据文件做好准备。 4、概要设计说明书 是概要设计阶段的工作总结。主要包括功能分配、模块划分、程序总体结构、输入输出以及接口设计、运行设计、数据结构设计和出错处理等，为详细设计作好准备。 5、详细设计说明书 着重描述每一模块是怎样实现的，包括实现算法、逻辑流程等。 6、用户操作手册 详细描述了该软件的功能、性能和用户界面，使用该软件的具体方法等。 7、测试计划 包括测试内容、进度、条件、人员、测试用例的选取原则、测试结果允许的偏差范围等。8、测试分析报告 测试计划的执行情况，对测试结果的分析，提出测试结论。 9、开发进度月报 按月提交的项目进展情况报告。包括计划与实际执行情况的对比、阶段成果、遇到的问题、解决的方法以及下一步的打算。 10、项目开发总结报告 项目完成以后，总结实际执行情况。如进度、成果、资源利用、成本和投入的人力，对项目开发作出评价，总结经验与教训。 11、软件维护手册 主要包括软件系统说明、程序模块说明、操作环境、支持软件说明、维护过程说明等。12、软件问题报告 记录软件出现问题的日期、发现人、状态、问题所属模块等，为软件修改提供准备文档。13、软件修改报告 软件产品投入使用后，发现了需修改、更正的问题，要将出现的问题、修改意见、修改可能出现影响作出详细描述，提交审批。 二、可行性分析报告的撰写要求 可行性研究报告的编写内容要求如下： 1 引言
软件开发规范标准整体规范标准
软件开发规范 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
软件工程国家标准
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. 控制精度或生产能力的提高。
国家标准软件开发主要编写规范
国家标准(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. 控制精度或生产能力的提高。
软件开发技术标准
系统中涉及的所有规范、标准或材料规格（包括一切有效的补充或附录）均采用最新版本，即以招标方与投标方签订供货合同之日作为采用最新版本的截止日期。若发现本规范书与参照的文献之间有不一致之处，我方向贵方书面指明，并由贵方确定采用哪一个规范。 我方所有设备的设计，制造，检查，试验及特性除木规范中规定的特别标准外，都遵照适用的最新版中国国家标准（GB）以及国际单位制（SI） O 我方提出的等同标准应不低于贵方要求的标准并征得贵方的认可，我方应遵循的标准至少包括： 《中华人民共和国计算机信息系统安全保护条例》 GB2887-89 计算站场地技术条件 GB/T 9361-1988 计算机场地安全要求 GB4943 —90 信息技术设备（包扌舌电气事务设备）的安全 GB/T -1995 中华人民共和国计算机信息安全保护条例 GB18030-2000 信息交换用汉字编码字符集基本集的扩充 GB1526-89信息处理一数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文字编制符及约定
GB8566计算机软件开发规范 GB9385计算机软件需求说明编制指南 GB9386计算机软件测试文件编制规范 GB/T13502信息处理、程序构造及其表示法的约定 GB/T14085信息处理系统计算机系统配置图符号及约定GB10112确立术语的一般原则与方法 GB/T13725确立术语数据库的一般原则与方法 SJ/T11293企业信息化技术规范 GB/T12504-90计算机软件配置管理计划规范 GB/T13702-92计算机软件分类与代码 GB/T14079-93软件工程术语 GB/T15532-1995计算机软件单元测试 GB/T 14394-1993《计算机软件可靠性和可维护性规范》GB/T 2887-1989《计算机软件质量保证规范》 GB/T 8566-2000《信息技术软件生成期过程》
软件开发标准化工作流程V10
目录 软件开发标准化工作流程 1引言 1.1编写目的 说明编写这份软件开发标准化工作流程的目的，指出预期的读者。 1.2适用范围 互联网开发中心所有项目。 1.3定义 列出本文件中用到的专门术语的定义、外文首字母组词的原词组。
1.4流程图 2需求调研 2.1概述 需求调研对于一个应用软件开发来说，是一个系统开发的开始阶段，需求调研的质量对于一个应用软件来说，是一个极其重要的阶段，它的质量在一定程度上来说决定了一个软件的交付结果。怎样从客户中听取用户需求、分析用户需求就成为调研人员最重要的任务。
2.2需求调研 总体而言，需求调研可按照业务流程、业务规则、表单数据、贯穿系统的关系四个方向来进行调研。 ●业务规则 各个流程、功能点等事项的办理，都会有相关约束或条件，那么需要对其前置条件、后置条件、数据验证、条件判断等进行分析调研。调研对象一般为操作员。 ●表单数据 对各个功能点的业务数据、数据项、表单格式、查询条件以及其它相关数据进行明确的分析调研。调研对象一般为操作员。 ●贯穿系统的关系 各个模块或科室之间的数据交换、传递以及数据共享等，需要我们调研人员与各个模块或科室的相关负责人进行多方沟通，确定一个多方满意的需求调研结果。 2.3注意事项 ●调研过程中，用户说的很快，不可能等我们全部记录之后， 再讲下一个问题。因此，只能在笔记本上速记，有时只能记录1、2个关键字。因此，每天调研结束之后，当天晚上必须整理当天的调研情况，写成一份调研日记。整理当天的调研记录时，还要整理出待明确的问题，下一次再找机会与用户再沟通、确认。
●调研的各个阶段，必须出具相关文档或文件，比如调研计划、 流程图、表单样式、报表格式、背景图片、数据项列表、讨论记录、问题列表等。 ●所有疑问必须等到明确的答复，不能出现相互矛盾、似是而 非的需求。需准确理解客户的讲解，如果有问题的先做记录，之后将整理的问题向客户询问，得到明确的结果。需求必须是客户接受和确认的，不能有臆测的需求。 ●要合理安排好时间和进度。有时候客户还有自己要做的事情， 不一定能及时相应。所以必须提前预约好时间，保证整个需求调研的进度。 ●能积极引导客户。当客户出现疑虑，而调研人员能明白且能 做好客户想要的东西的时候，调研人员能及时积极引导客户，详细讲解我们所知道的东西，并能让客户接受与确认。 ●如遇公司有相关原型或产品，调研人员需先详细了解公司的 相关原型和产品，根据成品，找出本地化的差异化需求。 3可行性分析 这个阶段要回答的关键问题：“对于上一个阶段所确定的问题有行得通的解决办法吗？”为了回答这个问题，系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程，也就是在较抽象的高层次上进行的分析和设计的过程。 可行性研究应该比较简短，这个阶段的任务不是具体解决
软件开发文档规范标准[详]
附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）本报告引用的其他资料、采用的开发标准或开发规范。）
软件工程国家标准、行业标准一览
软件工程国家标准、行业标准一览摘自计算机软件工程规范国家标准汇编2003DZ/T 0169-1997 物探化探计算机软件开发规范 GB 17917-1999 商场管理信息系统基本功能要 求 GB 8566-1988 计算机软件开发规范(已为GB/T8566-1995替代) GB/T 11457-1995 软 件工程术语 GB/T 12504-1990 计算机软件质量保证计划规范 GB/T 12505-1990 计算机软 件配置管理计划规范 GB/T 14079-1993 软件维护指南 GB/T 14085-1993 信息处理系统计 算机系统配置图符号及约定 GB/T 15532-1995 计算机软件单元测试 GB/T 15538-1995 软 件工程标准分类法 GB/T 15853-1995 软件支持环境 GB/T 16260-1996 信息技术软件产品 评价质量特性及其使用指南 GB/T 16680-1996 软件文档管理指南 GB/T 17544-1998 信息技术软件包质量要求和测试 GB/T 17917-1999 商场管理信息系统基本功能要求 GB/T 18234-2000 信息技术C ASE工具地评价与选择指南 GB/T 18491.1-2001 信息技术软件 测量功能规模测量第1部分：概念定义 GB/T 18492-2001 信息技术系统及软件完整性级 别 GB/T 18905.1-2002 软件工程产品评价第1部分: 概述 GB/T 18905.2-2002 软件工程 产品评价第2部分: 策划和管理 GB/T 18905.3-2002 软件工程产品评价第3部分: 开发者用地过程 GB/T 18905.4-2002 软件工程产品评价第4部分: 需方用地过程 GB/T 18905.5-2002 软件工程产品评价第5部分: 评价者用地过程 GB/T 18905.6-2002 软件工 程产品评价第6部分: 评价模块地文档编制★GB/T 8566-1995 信息技术软件生存期过程(已为GB/T8566-2001替代) GB/T 8566-2001 信息技术软件生存周期过程 GB/T 9385-1988 计算机软件需求说明编制指南 GB/T 9386-1988 计算机软件测试文件编制规 范 GB/Z 18493-2001 信息技术软件生存周期过程指南 GB/Z 18914-2002 信息技术软件工 程CASE工具地采用指南 GJB 1091-1991 军用软件需求分析 GJB 1419-1992 军用计算 机软件摘要 GJB 2115-1994 军用软件工程管理规程 GJB 2255-1994 军用软件产品 GJB 3181-1998 军用软件支持环境选用要求 GJB 437-1988 军用软件开发规范 GJB 438-1988 军用软件文档编制规范 GJB 438A-1997 武器系统软件开发文档 GJB 439-1988 军用软件 质量保证规范 GJB/Z 102-1997 软件可靠性和安全性设计准则 GJB/Z 115-1998 GJB 2786《武器系统软件开发》剪裁指南 GJB/Z 117-1999 军用软件验证和确认计划指南 GJB/Z 68-1994 武器装备柔性制造系统软件工程手册 HB 6464-1990 软件开发规范 HB 6465-1990 软件文档编制规范 HB 6466-1990 软件质量保证计划编制规定 HB 6467-1990 软件配置管理计划编制规定 HB 6468-1990 软件需求分析阶段基本要求 HB 6469-1990 软件需求规格说明编制规定 HB 6698-1993 软件工具评价与选择地分类特性体系 HB/Z 177-1990 软件工程管理基本要求 HB/Z 178-1990 软件验收基本要求 HB/Z 179-1990 软 件维护基本要求 HB/Z 180-1990 软件质量特性与评价方法 HB/Z 182-1990 状态机软件开 发方法 JB/T 6987-1993 制造资源计划MRPⅡ系统原型法软件开发规范 SB/T 10264-1996 餐饮业计算机管理软件开发设计基本规范 SB/T 10265-1996 饭店业计算机管理软件开发设计基本规范 SJ 20681-1998 地空导弹指挥自动化系统软件模块通用规范 SJ 20778-2000 软件开发与文档编制 SJ/T 10367-1993 计算机过程控制软件开发规程 SJ/T 11234-2001 软件过程能力评估模型 SJ/T 11235-2001 软件能力成熟度模型 版权申明 本文部分内容，包括文字、图片、以及设计等在网上搜集整理。版权为潘宏亮个人所有 This article includes some parts, including text, pictures,
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.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)《业务架构文档》其附件包括：《业务规则》《业务用例规
计算机软件产品开发标准与规范
引言 1 目的 一项计算机软件的筹划、研制及实现，构成一个软件开发项目。一个软件开发项目的进行，一般需要在人力和自动化资源等方面作重大的投资。为了保证项目开发的成功，最经济地花费这些投资，并且便于运行和维护，在开发工作的每一阶段，都需要编制二定的文件。这些文件连同计算机程序及数据一起，构成为计算机软件。文件是计算机软件中不可缺少的组成部分，它的作用是：a．作为开发人员在一定阶段内的工作成果和结束标志； b．向管理人员提供软件开发过程中的进展和情况，把软件开发过程中的一些“不可见的”事物转换成“可见的”文字资料。以便管理人员在各个阶段检查开发计划的实施进展，使之能够判断原定目标是否已达到，还将继续耗用资源的种类和数量； C．记录开发过程中的技术信息，便于协调以后的软件开发、使用和修改； d．提供对软件的有关运行、维护和培训的信息，便于管理人员、开发人员、操作人员和用户之间相互了解彼此的工作； e．向潜在用户报导软件的功能和性能，使他们能判定该软件能否服务于自己的需要。 换言之，本指南认为：文件的编制必须适应计算机软件整个生存周期的需要。 计算机软件所包含的文件有两类：一类是开发过程中填写的各种图表，可称之为工作表格；另一类则是应编制的技术资料或技术管理资料，可称之为文件。本指南规定软件文件的编制形式，并提供对这些规定的解释。本指南的目的是使得所编制的软件文件确实能够起到软件文件应该发挥的作用。 2 范围 本指南是一份指导性文件。本指甫建议，在一项计算机软件的开发过程中，一般地说，应该产生十四种文件。这十四种文件是： 可行性研究报告； 项目开发计划； 软件需求说明书；
数据要求说明书； 概要设计说明书； 详细设计说明书； 数据库设计说明书； 用户手册； 操作手册； 模块开发卷宗； 测试计划； 测试分析报告； 开发进度月报； 项目开发总结报告。 本指南将给出开发过程中建议产生的这十四种文件的编制指导，同时，本指南也是这十四种文件的编写质量的检验准则。但是，本指南并未涉及软件开发过程中如何填写工作表格的问题。 一般地说，一个软件总是一个计算机系统（包括硬件、固件和软件）的组成部分。鉴于计算机系统的多样性，本指南一般不涉及整个系统开发中的文件编制问题，本指南仅仅是软件开发过程中的文件编制指南。 3 文件的使用者 对于使用文件的人员而言，他们所关心的文件的种类，随他们所承担的工作而异。 管理人员：可行性研究报告， 项目开发计划， 模块开发卷宗， 开发进度月报， 项目开发总结报告； 开发人员：可行性研究报告， 项目开发计划， 软件需求说明书， 数据要求说明书， 概要设计说明书， 详细设计说明书， 数据库设计说明书， 测试计划，
软件项目开发和管理规范V1.0
软件项目开发和管理规范 版本V1.0 2010年1月15日
目录 1.软件项目管理概述 (3) 2.软件项目管理过程 (3) 3.软件项目管理内容 (5) 3.1.需求阶段管理 (5) 3.2.设计阶段管理 (7) 3.3.开发阶段管理 (7) 3.4.测试阶段管理 (8) 3.5.维护阶段管理 (8) 3.6.工具管理 (8) 3.7.软件项目估算与进度管理 (9) 3.7.1.软件项目估算 (9) 3.7.2.进度安排 (10)
1.软件项目管理概述 软件项目管理是软件工程和项目管理的交叉学科，软件项目管理的概念涵盖了管理软件产品开发所必须的知识、技术及工具。根据美国项目管理协会PMI 对项目管理的定义可以将软件项目管理定义为：在软件项目活动中运用一系列知识、技能、工具和技术，以满足软件需求方的整体要求。 软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展。 软件生存周期包括可行性分析与项目开发计划、需求分析、设计（概要设计和详细设计）、编码、测试、维护等活动，所有这些活动都必须进行管理，在每个阶段都存在着权限角色控制、文档管理、版本控制、管理工具等，软件项目管理贯穿于软件生命的演化过程之中。 2.软件项目管理过程 为保证软件项目获得成功，必须对软件开发项目的工作范围、要完成的任务、需要的资源、需要的工作量、进度的安排、可能遇到的风险等做到心中有数。软件项目的管理工作开始于技术工作开始之前，在软件从概念到实现的过程中持续进行，最后终止于软件开发工作结束。 根据公司的实际情况，结合软件工程及软件过程标准等，特制定我公司软件项目管理流程如下：
软件开发合同标准样本
合同编号：WU-PO-9183-607 软件开发合同标准样本 In Order T o Protect The Legitimate Rights And Interests Of Each Party, The Cooperative Parties Reach An Agreement Through Common Consultation And Fix The Responsibilities Of Each Party, So As T o Achieve The Effect Of Restricting All Parties 甲方：_________________________ 乙方：_________________________ 时间：________年_____月_____日 A4打印/ 新修订/ 完整/ 内容可编辑
软件开发合同标准样本 使用说明：本合同资料适用于协作的当事人为保障各自的合法权益，经过共同协商达成一致意见并把各方所承担的责任固定下来，从而实现制约各方的效果。资料内容可按真实状况进行条款调整，套用时请仔细阅读。 软件开发合同 合同编号：____________ 甲方：__________ 法定住址：_____________ 法定代表人：___________ 职务：__________ 委托代理人：___________ 身份证号码：___________ 通讯地址：_____________ 邮政编码：_____________ 联系人：_______________
电话：__________ 电挂：__________ 传真：__________ 帐号：__________ 电子信箱：_____________ 乙方：__________ 法定住址：_____________ 法定代表人：___________ 职务：__________ 委托代理人：___________ 身份证号码：___________ 通讯地址：_____________ 邮政编码：_____________ 联系人：_______________ 电话：__________
软件开发过程文档规范标准
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输入输出的要求 解释各输入输出的数据类型，并逐项说明其媒体、格式、数值范围、精度等。 对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报
软件开发软件产品开发文件编制指南
附录五国家标准《计算机软件产品开发文件编制指南》国家标准《计算机软件产品开发文件编制指南》（GB 8567—88）是一份指导性文件。它建议在软件的开发过程申编下述14个文件：可行性研究报告、项目开发计划、软件需求说明书、数据要求说明书、总体设计说明书、详细设计说明、数据库设计说明书、用户手册、操作手册、模块开发卷、测试计划、测试分析报告、开发进度表、项目开发总结。该指南给出了这14个文件的编制提示，它同时也是这14个文件编写质量的检验准则。下面详细介绍这14种文件的编写目的与内容要求。 l、可行性研究报告 可行性研究报告的目的是：说明该软件开发项目的实现在技术上、经济上和社会条上的可行性，论述为了合理地达到开发目标而可能选择的各种方案，说明并论证所选定的方案。可行性研究报告的编写内容见表l。 表l 可行性研究报告 2、项目开发计划 编制项目开发计划的目的是用文件的形式，并在开发过程中各项工作的
负责人员、开发进度、经费预算、所需软硬件条件等问题做出的安排记录下来，以便根据本计划开展和检查项目的开发工作。编制内容要求如表2所示。 表 2 项目开发计划 3、软件需求说明书 软件需求说明书的编制是为了使用户和软件开发人员双方对该软件的初始规定有一个共同的理解，使 之成为整个软件开发工作的基础。其内容要求见表3。 表3 软件需求说明书 4、数据要求说明书 数据要求说明书的编制目的是为了向整个软件开发时期提供关于被处理数据的描述和数据采集要求的技术信息，其内容要求列于表4中。 表4 数据要求说明书
5、概要设计说明书 概要设计说明书又称为总体设计说明书，编制目的是说明对项目系统的设计考虑，包括基本处理流程、组织结构、模块结构、功能配置、接口设计、运行设计、系统配置、数据结构设计和出错处理设计等，为程序的详细设计提供基础。其内容要求见表5。 表5 概要设计说明书 6、详细设计说明书 详细设计说明书又称为程序设计说明，编制目的是说明一个软件系统各个层次中的每一个程序（模块）的设计考虑。如果软件系统比较简 单，层次少，本文件可以不单独编写，有关内容可并入概要设计说明书。详细设计说明书的内容要求见表6。 表6 详细设计说明书 7、数据库设计说明书
华为软件开发规范
软件开发行为规范 第一版 深圳市华为技术有限公司 版权所有不得复制
软件开发行为规范 (第一版） 为了把公司已经发布的软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐步形成工程师的作业规范”，特制定本软件开发行为规范，以达到过程控制的目的。 与软件开发相关的所有人员，包括各级经理和工程师都必须遵守本软件开发行为规范。对违反规范的开发行为，必须按照有关管理规定进行处罚。 本软件开发行为规范的内容包括：软件需求分析、软件项目计划、概要设计、详细设计、编码、需求管理、配置管理、软件质量保证、数据度量和分析等。 本软件开发行为规范，采用以下的术语描述： ★规则：在软件开发过程中强制必须遵守的行为规范。 ★建议：软件开发过程中必须加以考虑的行为规范。 ★说明：对此规则或建议进行必要的解释。 ★示例：对此规则或建议从正或反两个方面给出例子。 本软件开发过程行为规范由研究技术管理处负责解释和维护。 研究技术管理处
目录 1 软件需求分析 5 2 软件项目计划9 3 概要设计11 4 详细设计14 5 编码18 6 需求管理19 7 软件配置管理21 8 软件质量保证23 9 数据度量和分析25
1 软件需求分析 1-1：软件需求分析必须在产品需求规格的基础上进行，并保证完全实现产品需求规格的定义。 1-2：当产品的需求规格发生变更时，必须修订软件需求规格文档。软件需求规格的变更必须经过评审，并保存评审记录。 1-3：必须对软件需求规格文档进行正规检视。 1-4：软件需求分析过程活动结束前，必须经过评审，并保存评审记录。 1-5：在对软件需求规格文档的正规检视或评审时，必须检查软件需求规格文档中需求的清晰性、完备性、兼容性、一致性、正确性、可行性、易修改性、健壮性、易追溯性、易理解性、易测试性和可验证性、性能、功能、接口、数据、可维护性等内容。 说明：参考建议1-1到1-16。 1-1：采用以下检查表检查软件需求规格文档中需求的清晰性。 1-2：采用以下检查表检查软件需求规格文档中需求的完备性。
软件开发过程规范标准
软件开发过程规范 第一部分软件需求分析规范 1、引言 本标准规定了软件需求分析阶段的任务、过程和相关要求，以及需求分析阶段的完成标志。它是软件开发规范的组成部分。 本标准适用于软件需求分析阶段的所有任务和相关人员，包括项目管理人员、软件需求分析人员、文档编制人员和质量审核人员。 2、参考文献 2.1GB8566-88 计算机软件开发规范 2.2ISO/IEC 12207:1995 信息技术——软件生存周期过程 2.3GXB 02-001 软件开发规范：第一部分软件生存周期 2.4GXB 01-001 软件工程术语 2.5GXB 02-007 软件测试规范 3、术语 本标准的术语的定义与GXB 01-001软件工程术语中的定义相一致。 4、需求分析的任务和过程 4.1需求分析任务 确定被开发软件的运行环境、功能、性能和数据需求，建立确认测试准则，编写用户手册，为概要设计提供需求说明书。 4.2需求分析过程 需求分析过程由下列步骤组成： 1）确定需求分析方法和工具； 2）人员培训； 3）确定需求分析输入；
4）需求分析； 5）制定确定测试计划； 6）修改开发计划； 7）编制文档； 8）需求分析审查； 9）需求分析文档存档。 5、总体要求 5.1用户参与 软件需求分析应该有客户指定的人员参加。 5.2用户确认 需求说明必须明确，经过客户同意，并用合同的方式予以确认。 5.3面向用户描述需求 应以用户能够理解的形式和术语描述需求，以利于与用户沟通。 6、需求分析流程 6.1确定需求分析方法和工具 选定合适的需求分析方法，在一个软件项目内所用的分析方法应该保持一致性。候选分析方法： 1）结构分析方法，包括面向数据流的分析方法和面向数据结构的分析方法。 2）面向对象的分析方法。 在需求分析方法选定后，应确定支持该方法的工具。在一个软件项目内，需求建模语言和工具应该保持一致性和规范化。 6.2人员培训 针对所选定的设计方法和工具，以及相关的标准对需求人员进行相应的培训。这是一个可选项，但对于新的方法和工具，或新的分析人员，培训是必需的。