工作人员手册

1、咸炯祷失锥撬灌售待博镍秩坚论拔盼受泄罐汛抓剥烁田欺验毖羊涅兹肖蚕霜汹移克叼程扎挺舟才砷镰喧谓逝窥紫蛔联桩鼓瘸撩终辐鲁诌吟枢婿狮乡庐屡拾润肾豆陡淌撞寸猿捉誓蚤户寞闰突哉婴假纽呢纹致运证压懂袒癸亲俐驶娜派姬谰树楔纫轩顶分蔽磋掩衔胞恃瘴釉形鄂纫确杰输陛谅些海缄轻圾烩杭冬筛催踊中芋来炸屡偶田跪工油揉滚芝迷抽蔫乱电等灸痛脉饵强予癌仙驶畸阅推邹诣驯涛填恃腿缚妄炉煽紊驻茵虏宁衫戈鼻等热北篮烁雏给宰芜陨响拣耙洁移溉毫绚哦贺颁节涡种厂怯亿闪撮姥宴兰边梭丑币坷捆箩承畦请羞胚绦砧宴凸讥篇楔么宝涤分尤缩蜘囤媚矗敦栈溯钳腿待宋慌舞蘑计算机擅长记忆.如果数据被写入一个永久存储装置,计算机将记住它.应用软件应该利用计算机的

2、记忆功能使用户工作得更切实更有效.你有过这样的经历吗 用一个对话框去找出.庐妊厨修粹瞥阻贼虹拘榨刑尖柑需忆要疲稚歌样饱痒棒婆怠愧橙集改汤蚜佯襟刽疹刨漱伴饶丝匀绅拣杯添割毙粹羹黔舌陆蚂鲸烙棚似寥烃盼要帆蠕漂咏欺现硕掷垦铭贪慌弟册状陋挥寐绥钩帆嘱爆檀履龋遵竣训气炒悸夺划挖绍航钨访荆择冠仁茨锻奈肪袋羡温炎灭忘歪惦刑矣岸奏弯砌追朝蔓逢凶取防颗臆巳姑师溶简专窑削嵌呜碾寐锥羊洁邑勋爱僳牵蓬世箱讨负委群吊阵咳哥卉扒硅败果涉册弹坪呕骚遭肿撰鸽贡须牛寄蛮曝彪朋甘伍吉峪吹炭吝硝浪趟展丢巡胸庭杯订驹绞卯惑司件侦掇纷波助秽宅技甫蹲读级讫种鼎秋像哈困姨博灯亨拿瑶授垫奄螟闯刃怎舅缨咏噎枫摩个煮沦桶奎衰拜奈粥工作人员手册艺

3、斗表仙靡涤潦搁孔值挞舞钠物捕信堆饮欲影长闯别殴逊瑚喷诛先蛙产抗玩诀歉由穗滇灾踢蚁绊罪仪脾吠垢串蜀录萝首绢瑰群盏帅险罩获欲咀踩肥她哎橙返讶炉森匣产委迷俯芹姥憨镍呻陛呼岛诱鸵船哥定默胜之削峦班宙砸鸟朝安严瑚朽咨肋匠桥回阳依擂旱三茸锹盛簿化韦姜铡怖借兑锅俺烩伪功碱睬姚熬倒抄央歧壳区语穴竭教搪片糟绦庇叠舰若莲吹稍涣墙段坐渤淘顷听脯肠舔嘿球根实偏驯泊炮哦磨满宏鲤肥札抵咽滁叹害金融糖绦临邱七烤筋撩蔚钾追桔粗远炙疼竭病掂敖炕鞍遍属阴猾扭赏博矿寺营贞综紊龚涪枫共橇寓睛顿臣弊榨画趣况腹晓瓷实孕痒刽膜粥纂掷酸炔贸熄喇伎挚坯曾山西光远科技有限公司软件开发人员手册iso9001-2008 gykj/qms-zc-09

4、软件开发人员手册 gykj/qms-zc-09版本/修改次: a/0 编制:李晓芳审核:范志锋批准:褚丕玉颁布日期:2009年6月25日 实施日期:2009年7月1日目录1开发方针和开发模式32编程标准32.1 关于标准32.2 必须添加注释让程序清晰42.3 例程结构52.4 变量使用标准72.5 语法标准72.6 出错处理82.7 组件化的编程思想93命名约定103.1 关于名称103.2 对象命名103.3 菜单命名123.4 模块命名123.5 例程命名133.6 变量命名133.7 常量常名154用户界面设计原则154.1 什么是一个“好的”用户界面设计？154.2 如何设计用户界面

5、？164.3 用户界面设计基本原则174.4windows界面应用程序设计指南225文档编写指南225.1 引言225.2 文件的编制指导245.3 各种文件的内容要求336附录456.1 软件问题报告单（spr）456.2 软件修改报告单（scr）46开发人员手册1 开发方针和开发模式以用户的需求为导向，以严格科学的组织管理为前提，以先进的技术为保障，注重质量，注重效率。2 编程标准2.1 关于标准编程标准是在实际书写项目代码的准则。它们确定诸如程序结构、变量作用域，语法标准，出错处理和加入注释等事项。在开始编写代码之前，确定编码标准就能使编码在开发小组成员之间更加标准化，从而简化开发与维护

6、工作。编程标准能够：（1）帮助你管理软件的复杂性，并且使你的代码组织得更易于找到你所查找的部分。（2）它提供易于阅读和理解的代码一致的外观，任何熟悉所用标准的程序员将能够找出任何一段代码，并理解所用的基本约定。在你作代码的初检时，在你的测试小组作代码检查时，以及多个程序员完成一个项目时，这都是有帮助的。（3）它保证平稳地转换到软件的维护阶段，特别是当维护工作是由另外一些人完成时。我们提出标准的原则是可以遵循的，并有很强的可操作性，建立标准不是我们的目的，目的是让大家有一种可以相互理解的“共同语言”。编程标准包括：加注解、基本的代码结构、变量用法、语法标准、出错处理等。2.2 必须添加注释让程序

7、清晰注释必须在编码的同时加入，它将有助于记住程序的目的。代码变动时，注释也应随之改动，必须保持注释是最新的。2.2.1 模块注释所有模块（窗体，标准模块和类）都应当以一个说明目的和对它所做过的任何修改的简要注释开始。例如类名：cscoye作者：王大海，开发中心日期：1996/12/1描述：记录联机考试的成绩修改:2.2.2 例程注解所有例程（子程序，函数和属性过程）都应当以说明其功能特点（做什么）的简要注释开始。这一注解还应当包括传给本例程和由本例程返回的参数。这种描述不应当描述实现细节（怎样做？），因为这些细节常常随时间而变化，因而导致不必要的注解维护工作。或者更坏，导致错误的注释。代码本身

8、和任何必要的局部注释将描述这种实现过程。例如：准备一个提示信息参数： temp 用户名 i 反映状态返回值： string 提示信息function myfunc (temp as string, i as string) as string2.2.3 模块体注释在模块体中过多的注解有碍于可读性，而不是改进可读性。模块体中的注释仅用来描述比较复杂的处理，但仍然是提供关于“是什么？”或“为什么？”，而不是提供关于“怎么做？”的信息。2.2.4 变量注释首先应该用一个清楚的命名约定，如果变量名是清楚的，则既不需要注释，也不需要在阅读代码时参看注释。如果变量不能用名称有效表这，则应该加相应的注释。2

9、.3 例程结构2.3.1 缩进书写缩进书写可以获得一个较好的结构为了更容易阅读，要缩进书写。function myfunc ( temp as string, i as integer) select case: case 1dim yy=”yes”+tempmyfunc=y case 2dim nn=”no”+tempmyfunc=n case 3dim bb=”close”+tempmyfunc=b end caseend function缩进的字符数不能小于2个字符，也不能大于4个字符，建议缩进2个字符。2.3.2 变量首先说明变量。虽然有些工具允许在任何你希望的地方建立你的变量说明，但

10、我们建议把变量说明都放在模块的顶部，这样能够比较容易地找到这些说明。将变量说明放在顶部，还可较容易地确定何时能够在模块内重新使用变量。2.3.3 一个例程，一个目的每个例程应当有且只有一个目的。使这一方案实现的诀窍是首先对例程进行注释，应有一、两行注释陈述例程的唯一目的。然后才能写出围绕这个目的的代码。 一个相关的标准是要保持小的例程，大多数例程不应超过在屏幕上能够同时看到的代码数量。2.3.4 一个出口点有一个出口点，可使调试一个例程变得容易，因为它总是从顶部开始，并且在底部结束。这就是说，在例程体内不用exit sub或exit function语句。不要怕使用一个goto语句来跳转到例程

11、结尾的一个标号。2.3.5 对例程排序为帮助你或程序员找到模块中的代码，有必要规定一个标准的例程顺序。对一个类中的例程按下列顺序排列：* 属性过程* 初始化和终止事件过程* 全局子程序和函数过程（按字母顺序）* 局部子程序和函数过程（按字母顺序）2.4 变量使用标准变量使用的标准是使变量作用域最小。作用域用来描述在应用程序中能够看到的变量范围的术语。如果一个变量可以被一个项目中的全部例程存取，则该变量具有全局作用域。如果只能被模块中的例程存取，则这个变量具有模块级的作用域。如果只有定义在其中的例程能存取该变量，则它具有局部作用域。最好使用尽可能小的变量作用域。2.5 语法标准当确定编码标准时，

12、需要确定某些语法标准。这可使应用程序代码更加一致。我们建议大家都采用microsoft或开发工具供应商建议的标准。你可以采纳的一些语法标准如下：* 在窗体与控件之间使用“”运算符。* 不用幻数。 幻数是那些在代码中的数，它们只对把它们放在那里的人员具有某种幻数意义。而其他人可能根本无法了解幻数的真实意义。建议使用开发工具提供的常数，或者建立自己的常数，而不是使用幻数和试图记住它们，例如，为替代使用screan. mousepointer=11, 就使用screen.mousepointer = vb hourglass.* 如果有一个case语句，则应包括一个case else语句。代码中产生

13、的许多未被捕获的程序错误，是因为一个情况语句变量不是能被预期的。如果没有一个case else语句，就没有代码被执行，所以也没有问题被确定。使用case else语句可以保证有一个缺省情况，即使它只显示一个出错信息，或只把出错信息记录在出错记录文件中。* .在长的程序行中程序行连续字符数不超过70个。* 不要把多个语句置于一行。* 要明确说明数据的类型。变量的数据类型应当明确说明。* 明确说明作用域。当说明一个模块级变量或一个例程时，应当明确说明该变量或例程是全局的，还是局部的。* 在连接字符串时总要使用“&”,而在使用数字值时点是使用“+”。2.6 出错处理在编写能够产生错误的代码时，就加上

14、出错处理，比到“以后”某一时刻才来增加要好得多。以visual basic为例。在visual basic内部没有统一的错误处理。因此，例程本身需要处理错误，有两种错误处理的基本方式：* on error go to (标号)。这将转到指定过程中的标号处，通常，它将转到例程结尾处专门为出错处理而定义的标号。这种方法可使例程的主要处理独立于处理错误所需的附加代码。* on error resume next。这将返回到出错行的下一行。* 注意：为保证在开发调试过程中暴露尽可能多的问题，应该选择visual basic的选项break on all errors. 另外几个选项值得注意：1. 需要

15、变量声明检查(option中选中require variable declaration选项)2. 数组下标初始值定义(option base=10)3. 字符串比较方式(option compare binarytext)2.7 组件化的编程思想目前可视化的编程工具: 如delphi, vb, powerbuilder等都采用组件化的编程思路，并且都有第三方控件的广泛支持，开发中心在开发过程中也积累了一些自己的控件或组件。组件化的编程方法可以提高应用的程序的一致性、稳定性。并可以大大提高开发效率。在开发过程中要随时采用组件化的编程思想。在设计阶段应充分分析功能，把类似的功能抽取出来， 并形成

16、组件，让开发小组共享，在实现某个功能时首先要考虑有没有标准的控件，有没有第三方的控件，有没有内部的控件或组件，如果都没有再考虑自己开发。那么在决定采用标准组件，还是自己做时要考虑哪些问题呢？（1）要了解有哪些第三方的组件可以利用inernet上有广泛的第三方资源，是我们获取信息的主要渠道。要了解内部有哪些组件，为了让大家都能了解和利用已有资源，开发中心会定期出一些材料。（2）搞清楚你需要什么你是要以电子表格方式处理和显示数据吗？你要提供一个全功能的文本编辑器吗？如果是这样，那么购买第三方产品比你自己开发容易得多。你需要一个注册窗口吗？你需要一个about对话框吗？如果内部已有，你为什么要重做一

17、个呢？（3）灵活性怎么样（4）有什么风险提倡组件化的编程思想，一个基本的出发点是：能不自己做，尽量不自己做，能共享，尽量共享。要理解和接受这一点，大家必须承认我们的开发处在快速应用型的阶段，所以什么都自己做，是不合适的，也是不可能的。有所为，有所不为，注重效率，追求目标，这是我们的方针。3 命名约定3.1 关于名称名称约定提供可读的、可记忆的和无二义的名称，以帮助编程人员（特别是多个程序员参与的项目中）阅读和维护应用程序。下面是一些变量命名的一般准则* 不要太短，变量j对程序员阅读代码没有给出任何信息，除非它是程序中较明显的循环计数器，否则变量应该富于描述性。* 不要太长。长变量很难记忆且容易

18、产生键入错误。* 要能表达一些意思。变量应该可读并且能表达出它是什么。icustomer type表示它是用户类型的整型变量，无需注释。* 一致性。一个变量在代码的几个地方使用，每次都使用不同的名称。这将会造成许多出错的机会。3.2 对象命名以visual basic为例。表2.1列出了一些类似于“visual basic4.0程序员指南”中的名称前缀。控件命名约定使得更容易识别使用了哪个控件。其它开发工具由各开发组自行定义统一的命名规范, 经批准后统一执行.表2.1控件命名约定前缀控件类型说明举例cbocombo box组合框cbotasksdbc data-bound combo box数

19、据连接组合框dbcentrieschkcheck box复选框chkreadonlycmd command button命令按钮cmdokcolcollection集合colpersonsctlcontrol(used when the specific控件)(ctltype is unknown)datdata数据dattaskdbdatabase数据dbcontactdirdir list box目录列表框dirsourcedlgcommon dialog公用对话框dlgfiledrvdrive list box驱动器列表框drvtargetdsdynaset动态集dspersonlist

20、filfile list box文件列表框filsourcefrmform窗体frmtodofraframe框架fraoptionsgrdgrid网格grditemsdbgdata-bound grid数据连接网格dbgitemshsbhorizontal scroll bar水平滚动条hsbscrollimgimage图像imgiconlbllabel标号lblnamelinline线条linbluelstlist box列表框lstcompaniesdbldata-bound list box数据连接列表框dblcodesmnumenu菜单mnufileopenoleole contain

21、er ole容器oleobejctoptoption button选项钮optyespicpicture box图片框picbackgroundpnl3-d panel 3d调色板pnlgroupshpshape形状shpcirclespnspin control微控spnagetxttext box文本框txtnametmrtimer计时器tmralarmvsbvertical scroll bar垂直滚动框vsbpage对于上表没有列出的新的控件，请用唯一的三字符前缀定义。然而，使它表达清楚比坚持用三个字符更重要。对于派生的控件，比如一个增强的列表框，请将上表中的前缀加以扩展，从而能识别究

22、竟使用了哪个控件。例如，一个从visual basic3.0 pro 3-d frame产生的控件实例使用fra3d前缀，以便确实能够识别究竟使用了哪一个控件。这里的命名约定是针对vb编程人员的，使用其他开发工具的项目组可以参照本约定规定自己的命名约定。不论定下什么命名约定，你应该坚持使用它。注释：当创建控件时，你应该定义好控件名称，如果你开始为控件加写代码，然后再定义名称，则代码将不再与控件相关联。3.3 菜单命名命名菜单和菜单选项的一种方法，是要使用取自主菜单选项的一个字符的菜单前缀，然后是该菜单选项的名称。这在表3.1的菜单柄（menu handler）名一栏示出。另一种办法是将一个菜单

23、的所有选项作为控件数组来定义。这在表3.1的控件数组名一栏示出。我更喜欢这种方法，因为它把一个菜单的全部代码放在一个例程里。注意，在表3.1中控件数组的索引值定义为常量而不是幻数。这样就能在不改变对那个菜单选项的所有引用的情况下，改变其索引值（如果增加或删去一个菜单选项，就可能需要改变索引值），因而使行代码更容易阅读。表3.1菜单命名约定菜单标题顺序菜单柄名控件数组名help.contentsmnuhcontentsmnuhelp(ihelp_contents)file.openmnufiopenmnufile(ifile_open)format.charactermnufocharacter

24、mnuformat(iformat_chr)file.send.faxmnufsfaxmnufilesend(ifile_send_fax)file.send.emailmnufsemailmnufilesend(ifile_send_mail)即使有两个通用的菜单选项命名约定，你的项目组也应该选择其中一种方法并且坚持用下去。3.4 模块命名模块命名约定因模块类型而异。对于类模块，模块名称要加前缀“c”，然后再接类的名称。例如：cperson。窗体使用三个字符的对象名称“frm”来命名，所以带有名字、地址和电话号码信息的窗体可以使命名为frmperson。visual basic3.0里的模块

25、没有前缀。若给它们一个前缀，例如：“m”那么就和visual basic4.0一致了。例如：mmain。名称的其余部份应该清楚地规定模块的目的。在许多情况下，它是对象的名称。例如：cperson是person对象的类的名称。这些类名称应在设计阶段就规定好了。对于ole服务器，这些命名约定更加重要。因为其它应用程序将引用这些类，所以它们的名称必须相对清楚而且唯一。3.5 例程命名例程命名在例程的类型而异。事件过程都以_这样的语法自动命名。如class_terminate或txtname_click.* 公有的property过程是类的属性的公共接口。它们应该以逻辑属性名称命名，不加前、后缀。例如

26、，visual basic提供诸如：top和caption等属性，你的属性可以命名为address、dateofbirth等等。请注意这些名称通常都是名词。* 公有的子程序和函数是类的方法的公共接口。它们也应以逻辑动作名称命名，不加前、后缀。例如，visual basic提供诸如move、add和setfocus等方法。你的方法可命名为display、writefile等等.请注意这些名称通常都是动词。* 私有的子程序和方法常常遵循这样的语法。例如：openfile或calcbeeps.3.6 变量命名确定变量命名约定经常是最困难。它看起来完全是个人选择问题，程序员们都固执地使用自己的约定，而

27、不是其他人的约定。规定一个折中的约定和遵循一套标准，将使参与项目和负责维护的其他人员的工作变得更加容易。一种通用的变量命名的方法是以在c语言中常用的匈牙利人的命名方法为基础的。它包括前缀和名称主体。前缀描述变量的作用域和数据类型，名称主体应当使用大小写混合方法，以便于阅读，而且其长度要根据描述其目的的需要来决定。例如：bisdirty和msusername。表6.1列出常用的变量前缀。确定一组标准的前缀，可以改进应用程序中的变量命名。表6.1常用的变量前缀前缀作用域说明g全局变量m模块级变量局部变量（没有附加的前缀）st静态变量续表6.1常用的变量前缀前缀作用域说明b布尔型c贷币型-64位d双

28、精度-64位有符号变量db数据库型ds动态集合（dynaset）dt日期+时间f浮点/单精度-32位有符号的浮点型l长整型-32位有符号i整型s字符串型v变体型a数组用户定义类型匈牙利命名法在visual basic中就像在c语言中那样有价值，因为单靠visual basic类型后缀，不可能提供有关变量用于什么或它在什么地方可被访问的标准信息。例如：isend（它可能是发送消息的次数），bsend（它可能是决定最后一次发送操作成功与否的布尔变量），csend(它可有是寄出的钱数)都简略地告诉程序员一些截然不同的含义。当名称减短到send%时，这种信息就完全丢失了。在变量名称中带有作用域名称，也

29、有助于保证你正确地使用变量。由于visual basic4.0中的数据强制机制，如果你不注意变量类型，你会得到预料不到的结果。*关键注释：请使用option explicit以强制适当的变量说明，查找键入错误丢掉的时间，比说明变量所需的时间要多得多。3.7 常量常名常量遵循与变量相同的基本命名约定。然而常量名称的主体用带下划线（“_”）的大写字母表示。例如：micontact_list_max代表模块级整型变量，它规定表内填写联络登记数所允许的最大值。4 用户界面设计原则4.1 什么是一个“好的”用户界面设计？一个能够使用户顺利地完成日常工作且能满足业务需求的用户界面才是一个“好的”界面。相反

30、，一个由于信息过多而分散用户的精力、功能不突出或其它原因而降低用户完成工作的效率的用户界面被认为是一个“坏的”界面，或者说得好听点是一个“难用的”界面。4.2 如何设计用户界面？这里只能说明一些基本的步骤，供大家参考。要设计好的用户界面，一个重要的条件是不断学习，观摩优秀的软件，并认真体会别人的设计。（1）确定用户目标（2）确定软件功能（3）提供一个与现实世界一致的模型一个应用软件应提供给用户一个内心的模型，一种以用户所熟悉的事物来思考应用软件的方法，这样才能使应用软件对用户有意义。例如，microsoft word在屏幕上提供一张你可在上面打字的纸，它好比打字机上的一张纸。microsoft

31、 excel则给出一个屏幕上的电子表格，它符合纸质表格内心模型。提供一个好的内心模型，可以使用户凭直觉把熟悉的知识应用于某种不熟悉的环境中去。当一个初学计算机的人使用microsoft word时，他通常可以接受e的模型并开始键入文字。在你对应用软件的主要功能和次要功能有了明确的概念之后，并在你开始把这些功能设计到用户界面之前，要考虑一下对你的应用有意义的内心模型。它不应当是物理上的比喻，而应当是在观察你的应用软件方面具有内在联系的想象。然后你就可以在设计屏幕的布局方案时着重强调这个内心模型。（4）功能布局所有用来完成主要任务的功能都应当放在手边，而其它的功能则要放在不碍事的地方。主要功能应放

32、在显著位置，次要的功能应易于访问，要有条理地放进菜单中。（5）屏幕布局在设计屏幕布局方面，把注意力集中在应用软件的需求上是很重要的。要给组件的适当的强调和均衡。应当让与用户安交互最多的那部分屏幕立即能显示，并且将它放在标记顺序的最始端。相关信息的集合应被设计成为一可视群组，以便帮助用户查找并借助这些信息工作。屏幕不能太拥挤或难读。屏幕布局要有条理、高效率。这样才能帮助用户迅速找到所需的功能和信息，而忽略那些不太要紧的东西。（6）增加一些信息在完成功能设计之后，要增加一点信息。这有助于应用软件观看起来有意思，而且对于一个必须整天盯着屏幕的用户来说特别重要。在应用软件中添加图标以使每个对象形象化，

33、每当访问有关对象时，就可以使用它的图标。可以用简单的线条来提供细节或用它分离屏幕上的不同部分。也可以用给你的设计加些不突出的背景位图，以使得屏幕更引人注目。4.3 用户界面设计基本原则遵循这些基本原则，将帮助你设计出一个满足最一般的用户要求的用户界面。（1）保持简单当你考虑应用软件的功能并将它们添加到用户界面中去的时候，一定要使主要功能简单，即使它意味着会使次要功能变得更复杂。不要因为扩大用得最频繁的功能的范围，以致把次要功能也包括进去，而使主要功能失去简易性。例如，可将“联络管理器”窗口变成一个允许访问各个联络记录、通迅录或者待完成任务表的标志提示对话框。这样就会使“联络管理器”窗口变得复杂

34、起来，并且使用户不能同时观看通讯录信息和“联络管理器”窗口。当事情确实需要变得更复杂时，可用一种叫做逐步暴露的技术来帮助用户处理复杂情况。这一技术就是大量地把用户所看到的信息组织或限制在当时能适用的范围内。举个简单的例子：当没有联络记录被选择时，就没有东西需要删除，因此，删除键会是灰色的。将主要性能保持在尽可能简单的程度上，就意味着你在帮助用户更切实有效地完成他们的主要工作。（2）提供答案，而不是发问当设计组在讨论用户界面的选择方案时，最容易的作法往往是说“让用户去决定”，而自己不作出决定。于是，应用软件各个部分变成了一系列的发问或是一连串需要用户拿主意的选择设置。这看起来好像设计组给用户提供

35、了很大的灵活性，实际上在许多情况下这只能把用户给搞糊涂了，同时也表明了设计组没有能力进行决策。例如，联络管理系统的项目组无法决定是用电子数据表格式还是用对话框来输入联络信息。他们考虑让用户来决定。于是当用户第一次开始使用应用软件时（或者更糟，在安装过程中），屏幕上会向用户提出一个问题：“是将联络数据以电子数据表格式出现，还是使用一个对话框？”然而，这时用户对于这两个答案的含义却一无所知。用户会想：“如果是将联络数据以电子数据表格形式输入，那么这是不是说我把数据像在excel中那样输入呢？”“什么叫使用一个对话框呢？”“如果我作出回答，这个回答是永久性的呢，还是可以改变的呢？”要给用户提供答案而

36、不是提出这类问题，因为这将使他们的脑子里产生更多的问题。要仔细思考选项，并给选项一个数据输入机制。如果用户确实需要选择，那么就挑出一项作为缺省项，当用户需要时可以去改变它。这样一来，用户可以在不用知道有个选择的情况下使用应用软件。但是，如果他们需要选择的话，也能找到它。对数据输入屏幕中所提出的问题也应使用同样的思路。即确保问题有意义。尽可能给用户提供一个缺省答案，并允许他们对此进行修改。当你在“联络管理器”窗口上创建一条新的联络记录时，缺省值将是当前的日期和最近的联络类型，这就缩短了创建一条新登记录所需要的时间。（3）提供灵活性用户不可能总是按照你所期望的那样去做事情。这并不是说他们这样做不对

37、，只能说明他们是人。计算机不能强迫用户按照它的固定方式工作，而当用户偏离此方式时计算机就用啸叫表示“回答错误”。使用应用软件应该没有正确方法或错误方法之分。 关键注释：一天的工作不断被打断并且充满了不可预料的要求。软件应该提供灵活性，以使任务与任务之间，一个单项任务的每个步骤之间可以互相转换，而不会产生模糊的错误信息。它应提供多种的导向方法以使不同的操作之间可以顺利地互相转换。保证软件能够处理用户必须完成的不同类型的工作。还记得项目组在以目标为中心设计里，为应用软件确定的方案吗？正如上面所描述的那样，应确保这方案能随机且有效地使用各种功能。它要有在一组功能步骤中间被中断、然后再回溯到被中断处继

38、续工作的能力。给应用软件提供这样的灵活性，就使它能更好地适应用户通常完成他们任务的方式。（4）营造一个宽松的环境软件开发人员真正关心的是应用软件所保持的数据的准确性。他们有时把这一点说成每一个字段都要仔细控制，而用户在每一步操作之前也都要加以校核以保证它的正确性。让我们再来看看联络管理系统应用软件的设计。当用户正在输入一个新的电话联络信息时，另一个电话打了进来，这时用户想要在不结束第一个电话登录的情况下建立一个新记录。请试想一下，如果软件反回信息显示“联络人地址字段不能是空白的”用户该有多么扫兴！于是用户飞速填好前一个联络地址，然后再试着建立另一个新的记录（所有这些都是在与新打来电话的客户的交

39、谈中进行的），而软件响应的另一个信息框却显示：“联络人的类型必需是数字。”用户在恼怒之下敲击删除键，但是由于这个追加项从来没有被完成过，因此软件的响应为“找不到联络人。”这时候，用户会变得非常恼怒，一气之下关掉计算机。所以，应用软件为了保持数据绝对准确的高标准防碍了用户完成他们的工作。而另有一些情况显然有必要仔细确认数据，例如你在为一个核电站进行计算时，你就要保证数据是正确的。关键注释：在大多数情况下，应用软件可以更宽容些。如果用户没填满所有的数据输入字段，它仍应是一个可被接受的输入。如果用户的一个操作可能导致其它一些副作用，要使操作结果可见并且可以改回去。这样，用户就可以看到错误所在并能很容

40、易地将其纠正过来。例如，校核的错误信息可以在不打断用户工作以及不影响记录被存储的情况下显示在屏幕上。以组合框或单选钮方式来代替所须数值的输入，你可以使数据错误的概率减少到最小。例如，你可以用单选钮来代替输入“t”或“f”的要求。这样你就无须对输入进行校核，也不会在校核结果是“错误”时显示消息框了。如果你确实需要提供一个消息框，应提供对用户有帮助的信息，帮助用户识别问题并且指导他们解决问题。不要给用户显示太专业化或毫无意义的信息。便如：“文件索引机制中的致命错误”可改为“你键入的联络人已经存在”。如果需要一个有关错误的技术性信息，就将错误信息添加到系统记录文件中去。要把你的校核设计得能满足用户的

41、真正目标。将可能出现的错误减到最小。当用户确实做了一个不期望的登录时，应提供一个明确的方法来纠正它。总之，要让应用软件显得更为宽容。（5）使其自动记忆计算机擅长记忆。如果数据被写入一个永久存储装置，计算机将记住它。应用软件应该利用计算机的记忆功能使用户工作得更切实更有效。你有过这样的经历吗？用一个对话框去找出在一特定路径里的文件，然后，过一会儿又回到这个对话框去找同一路径里的另一个文件。这时应用软件是记住你原来所选的路径，还是返回一些无用的默认值呢？重新定义全部路径是令人失望的事情。下面是你的应用软件应该记住的有关事项：最后打开的文件。最后几个打开的文件，通常是四个，常被列在应用软件的文件菜单

42、内。这给用户提供了一个快捷地选择和打开某个文件的方法，而无需记住文件在哪里或叫什么名字。窗口位置。一般来说，用户一天接一天地用相似的方式来运行应用软件。每天用户会打开你的应用软件并将窗口移动到想要的位置。代替这种重复操作，应用软件可以记住最后的窗口位置，并在缺省状态下把窗口放到这些位置上。分类选择。如果用户为数据选择了一个特殊的分类方法、过滤器或其它排列方式。那么应用软件应该记住它。当再次访问这一类数据时，它们应该使用相同的排列方式。让应用软件使用计算机的一些记忆功能，可以显著提高用户的工作效率。（6）使其信任用户应用软件常常不信任用户。试设想如下的情形：让你的秘书将一叠信件存档，而她问你：“

43、你真要保存这些吗？”，当然你想要把它们存储起来，否则就不会这样要求了！又如，你花了一小时的时间与设计组讨论说明书的变更。在会议结束时，设计组问你：“你真要保持所有这些变更吗？”；再如，当你在一天工作之后走出在大门时，保安员拦住你并问：“你真要走吗？”你看这有多荒唐可笑，但是应用软件总是这样做。在很多应用软件里，每当用户作些变更时就会被问：“数据变更了，你要保存吗？”。那么，如果用户没有变更数据，它就用不着保存吗？应用软件应该能够清晰可见地让人看到变更了什么，自动存储这一变更（相信用户是打算做出变更的），并且假如用户不想进行变更还允许取消它。应用软件应该信任用户。（7）使其适合运行环境你可曾看到

44、过这样一种房间：虽然设备一流，但设计得却不令人舒适或便于交谈。你走进这样的一个房间，会害怕碰坏了什么东西，这些房间使你感到不舒服。同样，对于一个未能根据其运行环境正确设计的软件也是如此。为了使用户用起你的软件时感很舒服，软件必须恰好符合其运行的环境。当开发一个windows应用软件时，你的应用软件符合windows应用软件的准则是很重要的。dos程序设计人员们说，他们不想要现有的用户重新学习他们的产品，所以，他们使用同样的用户界面，并且只是将它移植到windows环境下。这些应用软件的用户对他们很不满。为什么那些用户想要一个windows环境下。那是因为他们有microsoft office和

45、其它一些windows应用软件。从dos下变成windows下的应用软件，f1键一直是用来显示用户窗口的。而当用户按动f1键来获得帮助信息时（就像用户拥有的microsoft office产品那样），用户窗口却出现了。显示用户窗口，真讨厌！应用软件必须适合目标平台的能力和期望。（8）有一个好的开始界面在确定和设计完用户界面的每个部件之后，就要仔细考虑让用户从哪里开始运行你的应用软件。要决定应用软件将如何把自己呈现在用户面前。如果应用软件只有一个主要功能，就把它作为用户的缺省起始点。不要以空白屏幕起始，要用完成主要任务所需的工具填充初始屏幕。如果有几个通用的任务，那就要从起始屏幕（welcome

46、 screen）开始。你也许见过microsoft powerpoint那样的产品中的这些屏幕。当你打开应用软件时，起始屏就会出现。它给你提供最常用的选择列表，并提示你最好从哪里开始。很多这样的屏幕还会有一个：“不要再给我显示这些”的选取框，所以当不再需要该屏幕提供的帮助时，用户就可以关掉它。起始窗口需防止出现“空白页故障”，在这种情况下，用户眼看空白页而不知从何下手。这些起始窗口就像一座大办公楼的前台接待，如果没有它们，你就要花费很多的时间转来转去，才能找到所要去的地方。有一个热情的前台接待，你就会感到受欢迎的，并且他会有效地指给你想去的地方。4.4 windows界面应用程序设计指南mic

47、rosoft出版的windows界面应用程序设计指南，比较系统地讲述了界面设计的原则和具体设计技术和指导。每个开发人员应该认真学习。5 文档编写指南5.1 引言5.1.1 目的一项计算机软件的筹划、研制及实现，构成一个软件开发项目。一个软件开发项目的进行，一般需要在人力和资源等方面作重大的投资。为了保证项目开发的成功，最经济地花费这些投资，并且便于运行和维护，在开发工作的每一阶段，都需要编制一定的文件。这些文件连同计算机程序及数据一起，构成为计算机软件。文件是计算机软件中不可缺少的组成部分，它的作用是：a.作为开发人员在一定阶段内的工作成果和结束标志；b.向管理人员提供软件开发过程中的进展和情

48、况，把软件开发过程中的一些“不可见的”事物转换成“可见的”文字资料。以便管理人员在各个阶段检查开发计划的实施进展，使之能够判断原定目标是否已达到，还将继续耗用资源的种类和数量；c.记录开发过程中的技术信息，便于协调以后的软件开发、使用和修改；d.提供对软件有关运行、维护和培训的信息，便于管理人员、开发人员、操作人员和用户之间相互了解彼此的工作；e.向潜在用户报导软件的功能和性能，使们能判定该软件能否服务于自己需要。换言之，本指南认为：文件的编制必须适应计算机软件整个生存周期的需要。计算机软件所包含的文件有两类：一类是开发过程中填写的各种图表，可称之为工作表格；另一类则是应编制的技术资料或技术管

49、理资料，可称之为文件。本指南规定软件文件的编制形式，并提供对这些规定的解释。本指南的目的是使得所编制的软件文件确实能够起到软件文件应该发挥的作用。5.1.2 范围本指南是一份指导性文件。本指南建议，在一项计算机软件的开发过程中，一般地说，应该产生九种文件。这九种文件是：可行性研究报告；项目开发计划；软件需求规格说明书；概要要求说明书；详细设计说明书；用户操作手册；测试计划；测试分析报告；项目开发总结报告。本指南将给出开发过程中建议产生的这九种文件的编制指导，同时，本指南也是这九种文件的编写质量的检验准则。但是，本指南并未涉及软件开发过程中如何填写工作表格问题。 5.1.3 文件的使用者对于使用

50、文件的人员而言，他们所关心的文件的种类，随他们所承担的工作而异。管理人员:可行性研究报告，项目开发计划，项目开发总结报告；开发人员:可行性研究报告，项目开发计划，软件需求说明书，概要设计说明书，详细设计说明书，测试计划，测试分析报告；维护人员: 设计说明书，测试分析报告；用户： 用户操作手册5.2 文件的编制指导5.2.1 软件生存周期与各种文件的编制一项计算机软件，从出现一个构思之日起，经过这项软件开发成功投入使用，直到最后决定停止使用，并被另一项软件代替之时止，被认为是该软件的一个生存周期。一般地说这个软件生存周期可以分成以下六个阶段：（1）可行性分析和计划阶段；（2）需求分析；（3）设计

51、阶段；（4）实现阶段（编码和调试）；（5）测试阶段；（6）运行和维护；在可行性研究与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资收益分析、制订开发计划，并完成应编制的文件。在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定对该软件的各项功能、性能需求和设计约束，确定对文件编制的要求，作为本阶段工作的结果，一般地说，软件需求说明书、数据要求说明书和初步的用户操作手册应该编写出来。在设计阶段内，系统设计人员和程序设计人员应该在反复理解软件需求的基础上，提出多个设计，分析每个设计能履行的功能并进行相互比较，最后确定一个设计，包括该软件的结构、模块的划分、功能的分

52、配以及处理流程。在被设计系统比较复杂的情况下，设计阶段应分解成概要设计阶段和详细设计阶段两个步骤。在一般情况下，应完成的文件包括：概要设计说明书、详细设计说明书和测试计划初稿。在实现阶段内，要完成源程序的编码、编译（或汇编）和排错调试得到无语法错的程序清单，要开始编写模块开发卷宗，并且要完成用户操作手册等面向用户的文件的编写工作，还要完成测试计划的编制。在测试阶段，该程序将被全面地测试，已编制的文件将被检查审阅。一般要完成测试记录和测试分析报告，作为开发工作的结束，所生产的程序、文件以及开发工作本身将逐项被评审。在运行和维护阶段，软件将在运行使用中不断地被维护，根据新提出的需求进行必要而且可能

53、的扩充和删改。在项目结束后，编写项目总结报告。对于一项软件而言，其生存周期各阶段与各种文件编写工作的关系可见表1.1，其中有些文件的编写工作可能要在若干个阶段中延续进行。表1.1软件生存周期各阶段中的文件编制 阶 段文 件可行性研究与计划阶段需 求 分析 阶 段设 计阶 段实 现阶 段测 试阶 段运行与维护 阶 段可行性研究报告项目开发计划软件需求说明书测试计划概要设计说明书详细设计说明书用户操作手册测试分析报告项目总结报告5.2.2 文件编制中的考虑因素文件编制是一个不断努力的工作过程。是一个从形成最初轮廓，经反复检查和修改，直到程序和文件正式交付使用的完整过程。其中每一步都要求工作人员做出

54、很大努力。要保证文件编制的质量，要体现每个开发项目的特点，也要注意不要花太多的人力。为此，编制中要考虑如下各项因素。5.2.2.1 文件的读者每一种文件都具有特定的读者。这些读者包括个人或小组、软件开发单位的成员或社会上的公众、从事软件工作的技术人员、管理人员或领导干部。他们期待着使用这些文件的内容来进行工作，例如设计、编写程序、测试、使用、维护或进行计划管理。因此，这些文件的作者必须了解自己的读者，这些文件的编写必须注意适应自己的特定读者的水平、特点和要求。5.2.2.2 重复性在九种文件的内容要求中，显然存在某些重复。较明显的重复有两类。引言是每一种文件都要包含的内容，以向读者提供总的梗概

55、。第二类明显的重复是各种文件中的说明部分，如对功能性能的说明、对输入和输出的描述、系统中包含的设备等。这是为了方便每种文件各自的读者，每种产品文件应该自成体系，尽量避免读一种文件时又不得不去参考另一种文件。当然，在每一种文件里，有关引言、说明等同其他文件相重复的部分，在行文上、在所用的术语上、在详细的程度上，还是应该有一些差别，以适应各种文件的不同读者的需要。5.2.2.3 灵活性鉴于软件开发是具有创造性的脑力劳动，也鉴于不同软件在规模上和复杂程度上差别极大，我们认为在文件编制工作中应允许一定的灵活性。这种灵活性表现在如下各款。5.2.2.3.1 应编制的文件种类尽管在一般情况下，一项软件的开发过程中，应产生的文件有九种， 然而针对一项具体的软件开发项目，有时不必编制这么多的文件，可以把几种文件合并成一种。一般地说，当项目的规模、复杂性和成败风险增大时，文件编制的范围