山西光远科技有限公司《软件开发人员手册》.pdf

尸,在GUANGWUAN山西光远科技有限公司软件开发人员手册目录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 模块命名.133.5 例程命名.133.6 变量命名.133.7 常量常名.154 用户界面设计原则.154.1 什么是一个“好的”用户界面设计？.154.2 如何设计用户界面？.164.3 用户界面设计基本原则.174.4 windows界面应用程序设计指南.225 文档编写指南.235.1 引言235.2 文件的编制指导.255.3 各种文件的内容要求.346 附录.456.1 软件问题报告单(SPR).456.2 软件修改报告单(SCR).462开发人员手册1开发方针和开发模式以用户的需求为导向，以严格科学的组织管理为前提，以先进的技术为保 障，注重质量，注重效率。2编程标准2.1 关于标准编程标准是在实际书写项目代码的准则。它们确定诸如程序结构、变量作 用域，语法标准，出错处理和加入注释等事项。在开始编写代码之前，确定编 码标准就能使编码在开发小组成员之间更加标准化，从而简化开发与维护工 作。编程标准能够：（1）帮助你管理软件的复杂性，并且使你的代码组织得 更易于找到你所查找的部分。（2）它提供易于阅读和理解的代码一致的外观,任何熟悉所用标准的程序员将能够找出任何一段代码，并理解所用的基本约 定。在你作代码的初检时，在你的测试小组作代码检查时，以及多个程序员完 成一个项目时，这都是有帮助的。（3）它保证平稳地转换到软件的维护阶段,特别是当维护工作是由另外一些人完成时。我们提出标准的原则是可以遵循的，并有很强的可操作性，建立标准不是 我们的目的，目的是让大家有一种可以相互埋解的“共同语言”。编程标准包括：加注解、基本的代码结构、变量用法、语法标准、出错处 理等。32.2 必须添加注释让程序清晰注释必须在编码的同时加入，它将有助于记住程序的目的。代码变动时，注释也应随之改动，必须保持注释是最新的。2.2.1 模块注释所有模块（窗体，标准模块和类）都应当以一个说明目的和对它所做过的 任何修改的简要注释开始。例如类名：CScoye作者：王大海，开发中心日期：1996/12/1描述：记录联机考试的成绩修改：2.2.2 例程注解所有例程（子程序，函数和属性过程）都应当以说明其功能特点（做什么）的简要注释开始。这一注解还应当包括传给本例程和由本例程返回的参数。这种描述不应当描述实现细节（怎样做？），因为这些细节常常随时间而 变化，因而导致不必要的注解维护工作。或者更坏，导致错误的注释。代码本 身和任何必要的局部注释将描述这种实现过程。例如：准备一个提示信息参数：temp 用户名 i 反映状态返回值：string提示信息Function myFunc(temp As String,i As String)As String2.2.3 模块体注释在模块体中过多的注解有碍于可读性，而不是改进可读性。模块体中的注 释仅用来描述比较复杂的处理，但仍然是提供关于“是什么？”或“为什么？”,而不是提供关于“怎么做？”的信息。2.2.4 变量注释首先应该用一个清楚的命名约定,如果变量名是清楚的，则既不需要注释,也不需要在阅读代码时参看注释。如果变量不能用名称有效表这，则应该加相应的注释。2.3 例程结构2.3.1 缩进书写缩进书写可以获得一个较好的结构为了更容易阅读，要缩进书写。Function myFunc(temp As String,i As Integer)Select Case:Case 1Dim y尸yes+tempmyFunc=yCase 2Dim nn=No+tempmyFunc=nCase 35Dim bb=Close+tempmyFunc=bEnd CaseEnd Function缩进的字符数不能小于2个字符，也不能大于4个字符，建议缩进2个字 符。2.3.2 变量首先说明变量。虽然有些工具允许在任何你希望的地方建立你的变量说 明，但我们建议把变量说明都放在模块的顶部，这样能够比较容易地找到这些 说明。将变量说明放在顶部，还可较容易地确定何时能够在模块内重新使用变 量。2.3.3 一个例程，一个目的每个例程应当有且只有一个目的。使这一方案实现的诀窍是首先对例程进 行注释，应有一、两行注释陈述例程的唯一目的。然后才能写出围绕这个目的 的代码。一个相关的标准是要保持小的例程，大多数例程不应超过在屏幕上能够同 时看到的代码数量。23.4 一个出口点有一个出口点，可使调试一个例程变得容易，因为它总是从顶部开始，并 且在底部结束。这就是说，在例程体内不用Exit Sub或Exit Function语句。不 要怕使用一个GoTo语句来跳转到例程结尾的一个标号。62.3.5 对例程排序为帮助你或程序员找到模块中的代码，有必要规定一个标准的例程顺序。对一个类中的例程按下列顺序排列：*属性过程*初始化和终止事件过程*全局子程序和函数过程（按字母顺序）*局部子程序和函数过程（按字母顺序）2.4 变量使用标准变量使用的标准是使变量作用域最小。作用域用来描述在应用程序中能够 看到的变量范围的术语。如果一个变量可以被一个项目中的全部例程存取，则 该变量具有全局作用域。如果只能被模块中的例程存取，则这个变量具有模块 级的作用域。如果只有定义在其中的例程能存取该变量，则它具有局部作用域。最好使用尽可能小的变量作用域。2.5 语法标准当确定编码标准时，需要确定某些语法标准。这可使应用程序代码更加 一致。我们建议大家都采用Microsoft或开发工具供应商建议的标准。你可以采纳的一些语法标准如下：*在窗体与控件之间使用“”运算符。*不用幻数。幻数是那些在代码中的数，它们只对把它们放在那里的人员具 有某种幻数意义。而其他人可能根本无法了解幻数的真实意义。建议使用开发 工具提供的常数，或者建立自己的常数，而不是使用幻数和试图记住它们，例 如，为替代使用 Screan.MousePointer=11,就使用 Screen.MousePointer=vb Hourglass.*如果有一个Case语句，则应包括一个Case Else语句。代码中产生的许多未 被捕获的程序错误，是因为一个情况语句变量不是能被预期的。如果没有一个 7Case Else语句，就没有代码被执行，所以也没有问题被确定。使用Case Else 语句可以保证有一个缺省情况，即使它只显示一个出错信息，或只把出错信息 记录在出错记录文件中。*.在长的程序行中程序行连续字符数不超过70个。*不要把多个语句置于一行。*要明确说明数据的类型。变量的数据类型应当明确说明。*明确说明作用域。当说明一个模块级变量或一个例程时，应当明确说明该 变量或例程是全局的，还是局部的。*在连接字符串时总要使用“&”，而在使用数字值时点是使用。2.6出错处理在编写能够产生错误的代码时，就加上出错处理，比到“以后”某一时刻 才来增加要好得多。以Visual Basic为例。在Visual Basic内部没有统一的错误处理。因此，例 程本身需要处理错误，有两种错误处理的基本方式：*On Error Go To(标号)。这将转到指定过程中的标号处，通常，它将转到 例程结尾处专门为出错处理而定义的标号。这种方法可使例程的主要处理独立 于处理错误所需的附加代码。*On Error Resume Nexto这将返回到出错行的下一行。*注意：为保证在开发调试过程中暴露尽可能多的问题，应该选择Visual Basic 的选项 Break on All Errors.另外几个选项值得注意：1.需要变量声明检查(OPtion中选中Require Variable Declaration选项)2.数组下标初始值定义(Option Base=l0)3.字符串比较方式(Option Compare BinaryText)82.7组件化的编程思想目前可视化的编程工具：如Delphi,VB,PowerBuilder等都采用组件化的 编程思路，并且都有第三方控件的广泛支持，开发中心在开发过程中也积累了一 些自己的控件或组件。组件化的编程方法可以提高应用的程序的一致性、稳定性。并可以大大提高开发效率。在开发过程中要随时采用组件化的编程思想。在设计阶段应充分分析功能,把类似的功能抽取出来，并形成组件，让开发小组共享，在实现某个功能时首 先要考虑有没有标准的控件，有没有第三方的控件，有没有内部的控件或组件,如果都没有再考虑自己开发。那么在决定采用标准组件，还是自己做时要考虑哪些问题呢？（1）要了解有哪些第三方的组件可以利用Inemet上有广泛的第三方资源，是我们获取信息的主要渠道。要了解内部 有哪些组件,为了让大家都能了解和利用已有资源，开发中心会定期出一些材料。（2）搞清楚你需要什么你是要以电子表格方式处理和显示数据吗？你要提供一个全功能的文本编 辑器吗？如果是这样，那么购买第三方产品比你自己开发容易得多。你需要一个 注册窗口吗？你需要一个About对话框吗？如果内部已有，你为什么要重做一个 呢？（3）灵活性怎么样（4）有什么风险提倡组件化的编程思想，一个基本的出发点是：能不自己做，尽量不自己做,能共享，尽量共享。要理解和接受这一点，大家必须承认我们的开发处在快速应 用型的阶段，所以什么都自己做，是不合适的，也是不可能的。有所为，有所不为，注重效率，追求目标，这是我们的方针。93命名约定3.1 关于名称名称约定提供可读的、可记忆的和无二义的名称，以帮助编程人员（特别 是多个程序员参与的项目中）阅读和维护应用程序。下面是一些变量命名的一般准则*不要太短，变量j对程序员阅读代码没有给出任何信息，除非它是程序中较 明显的循环计数器，否则变量应该富于描述性。*不要太长。长变量很难记忆且容易产生键入错误。*要能表达一些意思。变量应该可读并且能表达出它是什么。iCustomerType 表示它是用户类型的整型变量，无需注释。*一致性。一个变量在代码的几个地方使用，每次都使用不同的名称。这将 会造成许多出错的机会。3.2 对象命名以Visual Basic为例。表2.1列出了一些类似于u Visual Basic4.0程序员指 南”中的名称前缀。控件命名约定使得更容易识别使用了哪个控件。其它开发 工具由各开发组自行定义统一的命名规范，经批准后统一执行.表2.1控件命名约定前缀控件类型说明举例CboCombo box组合框cboTasksDbcData-bound combo box数据连接组合框dbcEntriesChkCheck box复选框chkReadOnlyCmdCommand Button命令按钮cmdOKColCollection 集合colPersonsCtlControl(used when the specific 控件)(ctltype is unknown)10DatData数据datTaskDbDatabase 数据dbContactDirDir list box目录列表框dirSourceDigCommon dialog公用对话框dlgFileDrvDrive list box驱动器列表框drvTargetDsDynaset动态集dsPersonListFilFile list box文件列表框filSourcefrmForm窗体frmToDofraFrame框架fraOptionsgrdGrid网格grdltemsdbgData-bound grid数据连接网格dbgltemshsbHorizontal scroll bar 水平滚动条hsbScrollimgImage图像imglconIblLabel标号IblNamelinLine线条linBlue1stList box列表框lstCorq)aniesdblData-bound list box数据连接列表框dblCodesmnuMenu菜单mnuFileOpenoleOle container OLE 容器oleObejctoptOption button 选项钮optYespicPicture box 图片框picBackgroundpnl3-D panel 3D 调色板pnlGroupshpShape形状shpCirclespnSpin control 微控spnAgetxtText box文本框txtNametmrTimer计时器tmrAlarmvsbVertical scroll bar 垂直滚动框vsbPage对于上表没有列出的新的控件，请用唯一的三字符前缀定义。然而，使它 表达清楚比坚持用三个字符更重要。对于派生的控件，比如一个增强的列表框,请将上表中的前缀加以扩展，从而能识别究竟使用了哪个控件。例如，一个从11Visual Basic3.0 Pro 3-D Frame产生的控件实例使用fra3d前缀，以便确实能够 识别究竟使用了哪一个控件。这里的命名约定是针对VB编程人员的，使用其他开发工具的项目组可以 参照本约定规定自己的命名约定。不论定下什么命名约定,你应该坚持使用它。注释：当创建控件时，你应该定义好控件名称，如果你开始为控件加写代 码，然后再定义名称，则代码将不再与控件相关联。3.3 菜单命名命名菜单和菜单选项的一种方法，是要使用取自主菜单选项的一个字符的 菜单前缀，然后是该菜单选项的名称。这在表3.1的菜单柄(Menu Handler)名一栏示出。另一种办法是将一个菜单的所有选项作为控件数组来定义。这在表3.1的 控件数组名一栏示出。我更喜欢这种方法，因为它把一个菜单的全部代码放在 一个例程里。注意，在表3.1中控件数组的索引值定义为常量而不是幻数。这 样就能在不改变对那个菜单选项的所有引用的情况下，改变其索引值(如果增 加或删去一个菜单选项，就可能需要改变索引值)，因而使行代码更容易阅读。表3.1菜单命名约定菜单标题顺序菜单柄名控件数组名Help.ContentsMnuHContentsmnuHelp(iHELP_CONTENTS)File.OpenMnuFiOpenmnuFile(IFILE_OPEN)Format.CharacterMnuFoCharactermnuFormat(iFORMAT_CHR)File.Send.FaxMnuFSFaxmnuFileSend(iFILE_SEND_FAX)File.Send.EmailMnuFSEmailmnuFileSend(iFILE SEND MAIL)即使有两个通用的菜单选项命名约定，1尔的项目组也应该选择其中一种方法并且坚持用下去。123.4 模块命名模块命名约定因模块类型而异。对于类模块，模块名称要加前缀“c”,然后再接类的名称。例如：CPersono窗体使用三个字符的对象名称“fim”来 命名，所以带有名字、地址和电话号码信息的窗体可以使命名为fiinPerson。Visual Basic3.0里的模块没有前缀。若给它们一个前缀，例如：“M”那 么就和 Visual Basic4.0 一致了。例如：MMain。名称的其余部份应该清楚地规定模块的目的。在许多情况下，它是对象的 名称。例如：CPerson是Person对象的类的名称。这些类名称应在设计阶段就 规定好了。对于OLE服务器，这些命名约定更加重要。因为其它应用程序将引用这 些类，所以它们的名称必须相对清楚而且唯一。3.5 例程命名例程命名在例程的类型而异。事件过程都以对象_动词,这样的语法自动命名。如Class_Terminate或 txtNameClick.*公有的Property过程是类的属性的公共接口。它们应该以逻辑属性名称命 名，不加前、后缀。例如，Visual Basic提供诸如：Top和Caption等属性，你 的属性可以命名为Address、DateofBirth等等。请注意这些名称通常都是名词。*公有的子程序和函数是类的方法的公共接口。它们也应以逻辑动作名称命 名,不加前、后缀。例如,Visual Basic提供诸如Move、Add和SetFocus等方 法。你的方法可命名为Display、WriteFile等等.请注意这些名称通常都是动词。*私有的子程序和方法常常遵循动词对象这样的语法。例如：openFile 或 CalcBeeps.3.6 变量命名确定变量命名约定经常是最困难。它看起来完全是个人选择问题，程序员 13们都固执地使用自己的约定，而不是其他人的约定。规定一个折中的约定和遵 循一套标准，将使参与项目和负责维护的其他人员的工作变得更加容易。一种通用的变量命名的方法是以在C语言中常用的匈牙利人的命名方法 为基础的。它包括前缀和名称主体。前缀描述变量的作用域和数据类型，名称 主体应当使用大小写混合方法，以便于阅读，而且其长度要根据描述其目的的 需要来决定。例如：blsDirty和msUserName。表6.1列出常用的变量前缀。确 定一组标准的前缀，可以改进应用程序中的变量命名。表6.1常用的变量前缀前缀作用域说明g全局变量m模块级变量局部变量(没有附加的前缀)st静态变量续表6.1常用的变量前缀前缀作用域说明b布尔型C贷币型-64位d双精度-64位有符号变量db数据库型ds动态集合(Dynaset)dt日期+时间f浮点/单精度-32位有符号的浮点型1长整型-32位有符号i整型s字符串型14V变体型a数组用户定义类型匈牙利命名法在Visual Basic中就像在C语言中那样有价值，因为单靠 Visual Basic类型后缀，不可能提供有关变量用于什么或它在什么地方可被访 问的标准信息。例如：iSend（它可能是发送消息的次数），bSend（它可能是 决定最后一次发送操作成功与否的布尔变量），cSend（它可有是寄出的钱数）都简略地告诉程序员一些截然不同的含义。当名称减短到Send%时，这种信 息就完全丢失了。在变量名称中带有作用域名称，也有助于保证你正确地使用变量。由于 Visual Basic4.0中的数据强制机制，如果你不注意变量类型，你会得到预料不 到的结果。*关键注释：请使用Option Explicit以强制适当的变量说明，查找键入错误丢掉的时间，比说明变量所需的时间要多得多。3.7常量常名常量遵循与变量相同的基本命名约定。然而常量名称的主体用带下划线（）的大写字母表示。例如：miCONTACT_LIST_MAX代表模块级整型 变量，它规定表内填写联络登记数所允许的最大值。4用户界面设计原则4.1 什么是一个“好的”用户界面设计？一个能够使用户顺利地完成日常工作且能满足业务需求的用户界面才是一 个“好的”界面。相反，一个由于信息过多而分散用户的精力、功能不突出或 其它原因而降低用户完成工作的效率的用户界面被认为是一个“坏的”界面，1J或者说得好听点是一个“难用的”界面。4.2 如何设计用户界面？这里只能说明一些基本的步骤，供大家参考。要设计好的用户界面，一 个重要的条件是不断学习，观摩优秀的软件，并认真体会别人的设计。（1）确定用户目标（2）确定软件功能（3）提供一个与现实世界一致的模型一个应用软件应提供给用户一个内心的模型，一种以用户所熟悉的事物 来思考应用软件的方法，这样才能使应用软件对用户有意义。例如，Microsoft Word在屏幕上提供一张你可在上面打字的纸，它好比打字机上的一张纸。Microsoft Excel则给出一个屏幕上的电子表格，它符合纸质表格内心模型。提供一个好的内心模型，可以使用户凭直觉把熟悉的知识应用于某种不 熟悉的环境中去。当一个初学计算机的人使用Microsoft Word时，他通常可以 接受E的模型并开始键入文字。在你对应用软件的主要功能和次要功能有了明确的概念之后，并在你开 始把这些功能设计到用户界面之前，要考虑一下对你的应用有意义的内心模 型。它不应当是物理上的比喻，而应当是在观察你的应用软件方面具有内在联 系的想象。然后你就可以在设计屏幕的布局方案时着重强调这个内心模型。（4）功能布局所有用来完成主要任务的功能都应当放在手边，而其它的功能则要放在 不碍事的地方。主要功能应放在显著位置，次要的功能应易于访问，要有条理 地放进菜单中。（5）屏幕布局在设计屏幕布局方面，把注意力集中在应用软件的需求上是很重要的。要给组件的适当的强调和均衡。应当让与用户安交互最多的那部分屏幕立即能 显示，并且将它放在标记顺序的最始端。相关信息的集合应被设计成为一可视 群组，以便帮助用户查找并借助这些信息工作。屏幕不能太拥挤或难读。屏幕 16布局要有条理、高效率。这样才能帮助用户迅速找到所需的功能和信息，而忽 略那些不太要紧的东西。（6）增加一些信息在完成功能设计之后，要增加一点信息。这有助于应用软件观看起来有 意思，而且对于一个必须整天盯着屏幕的用户来说特别重要。在应用软件中添加图标以使每个对象形象化，每当访问有关对象时，就 可以使用它的图标。可以用简单的线条来提供细节或用它分离屏幕上的不同部分。也可以用给你的设计加些不突出的背景位图，以使得屏幕更引人注目。4.3用户界面设计基本原则遵循这些基本原则，将帮助你设计出一个满足最一般的用户要求的用户 界面。（1）保持简单当你考虑应用软件的功能并将它们添加到用户界面中去的时候，一定要 使主要功能简单，即使它意味着会使次要功能变得更复杂。不要因为扩大用得 最频繁的功能的范围，以致把次要功能也包括进去,而使主要功能失去简易性。例如，可将“联络管理器”窗口变成一个允许访问各个联络记录、通迅 录或者待完成任务表的标志提示对话框。这样就会使“联络管理器”窗口变得 复杂起来，并且使用户不能同时观看通讯录信息和“联络管理器”窗口。当事情确实需要变得更复杂时，可用一种叫做逐步暴露的技术来帮助用 户处理复杂情况。这一技术就是大量地把用户所看到的信息组织或限制在当时 能适用的范围内。举个简单的例子：当没有联络记录被选择时，就没有东西需 要删除，因此，删除键会是灰色的。将主要性能保持在尽可能简单的程度上，就意味着你在帮助用户更切实 有效地完成他们的主要工作。（2）提供答案，而不是发问当设计组在讨论用户界面的选择方案时，最容易的作法往往是说“让用 17户去决定”，而自己不作出决定。于是，应用软件各个部分变成了一系列的发 问或是一连串需要用户拿主意的选择设置。这看起来好像设计组给用户提供了 很大的灵活性，实际上在许多情况下这只能把用户给搞糊涂了，同时也表明了 设计组没有能力进行决策。例如，联络管理系统的项目组无法决定是用电子数据表格式还是用对话 框来输入联络信息。他们考虑让用户来决定。于是当用户第一次开始使用应用 软件时（或者更糟，在安装过程中），屏幕上会向用户提出一个问题：“是将 联络数据以电子数据表格式出现，还是使用一个对话框？”然而，这时用户对 于这两个答案的含义却一无所知。用户会想：“如果是将联络数据以电子数据 表格形式输入，那么这是不是说我把数据像在Excel中那样输入呢？”“什么 叫使用一个对话框呢？”“如果我作出回答，这个回答是永久性的呢，还 是可以改变的呢？”要给用户提供答案而不是提出这类问题，因为这将使他们的脑子里产生更 多的问题。要仔细思考选项，并给选项一个数据输入机制。如果用户确实需要 选择，那么就挑出一项作为缺省项，当用户需要时可以去改变它。这样一来，用户可以在不用知道有个选择的情况下使用应用软件。但是，如果他们需要选 择的话，也能找到它。对数据输入屏幕中所提出的问题也应使用同样的思路。即确保问题有意 义。尽可能给用户提供一个缺省答案，并允许他们对此进行修改。当你在“联 络管理器”窗口上创建一条新的联络记录时，缺省值将是当前的日期和最近的 联络类型，这就缩短了创建一条新登记录所需要的时间。（3）提供灵活性用户不可能总是按照你所期望的那样去做事情。这并不是说他们这样做 不对，只能说明他们是人。计算机不能强迫用户按照它的固定方式工作，而当 用户偏离此方式时计算机就用啸叫表示“回答错误”。使用应用软件应该没有 正确方法或错误方法之分。关键注释：一天的工作不断被打断并且充满了不可预料的要求。软件应该提供灵活 18性，以使任务与任务之间，一个单项任务的每个步骤之间可以互相转换，而不 会产生模糊的错误信息。它应提供多种的导向方法以使不同的操作之间可以顺 利地互相转换。保证软件能够处理用户必须完成的不同类型的工作。还记得项目组在以目标为中心设计里，为应用软件确定的方案吗？正如 上面所描述的那样，应确保这方案能随机且有效地使用各种功能。它要有在一 组功能步骤中间被中断、然后再回溯到被中断处继续工作的能力。给应用软件 提供这样的灵活性，就使它能更好地适应用户通常完成他们任务的方式。（4）营造一个宽松的环境软件开发人员真正关心的是应用软件所保持的数据的准确性。他们有时 把这一点说成每一个字段都要仔细控制，而用户在每一步操作之前也都要加以 校核以保证它的正确性。让我们再来看看联络管理系统应用软件的设计。当用户正在输入一个新 的电话联络信息时，另一个电话打了进来，这时用户想要在不结束第一个电话 登录的情况下建立一个新记录。请试想一下，如果软件反回信息显示“联络人 地址字段不能是空白的”用户该有多么扫兴！于是用户飞速填好前一个联络地址，然后再试着建立另一个新的记录（所 有这些都是在与新打来电话的客户的交谈中进行的），而软件响应的另一个信 息框却显示：“联络人的类型必需是数字。”用户在恼怒之下敲击删除键，但是由于这个追加项从来没有被完成过，因此软件的响应为“找不到联络人。”这时候，用户会变得非常恼怒，一气之下关掉计算机。所以，应用软件 为了保持数据绝对准确的高标准防碍了用户完成他们的工作。而另有一些情况 显然有必要仔细确认数据，例如你在为一个核电站进行计算时，你就要保证数 据是正确的。关键注释：在大多数情况下，应用软件可以更宽容些。如果用户没填满所有的数据 输入字段，它仍应是一个可被接受的输入。如果用户的一个操作可能导致其它 一些副作用，要使操作结果可见并且可以改回去。这样，用户就可以看到错误 19所在并能很容易地将其纠正过来。例如，校核的错误信息可以在不打断用户工 作以及不影响记录被存储的情况下显示在屏幕上。以组合框或单选钮方式来代替所须数值的输入，你可以使数据错误的概 率减少到最小。例如，你可以用单选钮来代替输入“T”或“F”的要求。这 样你就无须对输入进行校核，也不会在校核结果是“错误”时显示消息框了。如果你确实需要提供一个消息框，应提供对用户有帮助的信息，帮助用 户识别问题并且指导他们解决问题。不要给用户显示太专业化或毫无意义的信 息。便如：“文件索引机制中的致命错误”可改为“你键入的联络人已经存在”。如果需要一个有关错误的技术性信息，就将错误信息添加到系统记录文件中 去。要把你的校核设计得能满足用户的真正目标。将可能出现的错误减到最 小。当用户确实做了一个不期望的登录时，应提供一个明确的方法来纠正它。总之，要让应用软件显得更为宽容。（5）使其自动记忆计算机擅长记忆。如果数据被写入一个永久存储装置，计算机将记住它。应用软件应该利用计算机的记忆功能使用户工作得更切实更有效。你有过这样的经历吗？用一个对话框去找出在一特定路径里的文件，然 后，过一会儿又回到这个对话框去找同一路径里的另一个文件。这时应用软件 是记住你原来所选的路径,还是返回一些无用的默认值呢？重新定义全部路径 是令人失望的事情。下面是你的应用软件应该记住的有关事项：最后打开的文件。最后几个打开的文件，通常是四个，常被列在应用软 件的文件菜单内。这给用户提供了一个快捷地选择和打开某个文件的方法，而 无需记住文件在哪里或叫什么名字。窗口位置。一般来说，用户一天接一天地用相似的方式来运行应用软件。每天用户会打开你的应用软件并将窗口移动到想要的位置。代替这种重复操 作，应用软件可以记住最后的窗口位置，并在缺省状态下把窗口放到这些位置 020分类选择。如果用户为数据选择了一个特殊的分类方法、过滤器或其它 排列方式。那么应用软件应该记住它。当再次访问这一类数据时，它们应该使 用相同的排列方式。让应用软件使用计算机的一些记忆功能，可以显著提高用户的工作效率。（6）使其信任用户应用软件常常不信任用户。试设想如下的情形：让你的秘书将一叠信件 存档，而她问你：“你真要保存这些吗？，当然你想要把它们存储起来，否 则就不会这样要求了！又如，你花了一小时的时间与设计组讨论说明书的变更。在会议结束时，设计组问你：“你真要保持所有这些变更吗？；再如，当你 在一天工作之后走出在大门时，保安员拦住你并问：“你真要走吗？你看这 有多荒唐可笑，但是应用软件总是这样做。在很多应用软件里，每当用户作些变更时就会被问：“数据变更了，你 要保存吗？”。那么，如果用户没有变更数据，它就用不着保存吗？应用软件应该能够 清晰可见地让人看到变更了什么，自动存储这一变更（相信用户是打算做出变 更的），并且假如用户不想进行变更还允许取消它。应用软件应该信任用户。（7）使其适合运行环境你可曾看到过这样一种房间：虽然设备一流，但设计得却不令人舒适或 便于交谈。你走进这样的一个房间，会害怕碰坏了什么东西，这些房间使你感 到不舒服。同样，对于一个未能根据其运行环境正确设计的软件也是如此。为 了使用户用起你的软件时感很舒服，软件必须恰好符合其运行的环境。当开发 一个Windows应用软件时，你的应用软件符合Windows应用软件的准则是很 重要的。DOS程序设计人员们说，他们不想要现有的用户重新学习他们的产品，所 以，他们使用同样的用户界面，并且只是将它移植到Windows环境下。这些 应用软件的用户对他们很不满。为什么那些用户想要一个Windows环境下。那是因为他们有Microsoft Office和其它一些Windows应用软件。从DOS下变 成Windows下的应用软件，F1键一直是用来显示用户窗口的。而当用户按动21Fl键来获得帮助信息时（就像用户拥有的Microsoft Office产品那样），用户 窗口却出现了。显示用户窗口，真讨厌！应用软件必须适合目标平台的能力和期望。（8）有一个好的开始界面在确定和设计完用户界面的每个部件之后，就要仔细考虑让用户从哪里 开始运行你的应用软件。要决定应用软件将如何把自己呈现在用户面前。如果 应用软件只有一个主要功能，就把它作为用户的缺省起始点。不要以空白屏幕 起始，要用完成主要任务所需的工具填充初始屏幕。如果有几个通用的任务，那就要从起始屏幕（Welcome screen）开始。你 也许见过Microsoft PowerPoint那样的产品中的这些屏幕。当你打开应用软件 时，起始屏就会出现。它给你提供最常用的选择列表，并提示你最好从哪里开 始。很多这样的屏幕还会有一个：“不要再给我显示这些”的选取框，所以当 不再需要该屏幕提供的帮助时，用户就可以关掉它。起始窗口需防止出现“空白页故障”，在这种情况下，用户眼看空白页 而不知从何下手。这些起始窗口就像一座大办公楼的前台接待，如果没有它们，你就要花费很多的时间转来转去，才能找到所要去的地方。有一个热情的前台 接待，你就会感到受欢迎的，并且他会有效地指给你想去的地方。4.4 windows界面应用程序设计指南Microsoft出版的windows界面应用程序设计指南，比较系统地讲述了 界面设计的原则和具体设计技术和指导。每个开发人员应该认真学习。225文档编写指南5.1 引言5.1.1 目的一项计算机软件的筹划、研制及实现，构成一个软件开发项目。一个软件开 发项目的进行，一般需要在人力和资源等方面作重大的投资。为了保证项目开发 的成功，最经济地花费这些投资，并且便于运行和维护，在开发工作的每一阶段,都需要编制一定的文件。这些文件连同计算机程序及数据一起，构成为计算机软 件。文件是计算机软件中不可缺少的组成部分，它的作用是：a.作为开发人员在一定阶段内的工作成果和结束标志；b.向管理人员提供软件开发过程中的进展和情况，把软件开发过程中的一些“不可见的”事物转换成“可见的”文字资料。以便管理人员在各个阶段检查开 发计划的实施进展，使之能够判断原定目标是否已达到，还将继续耗用资源的种 类和数量；c.记录开发过程中的技术信息，便于协调以后的软件开发、使用和修改；d.提供对软件有关运行、维护和培训的信息，便于管理人员、开发人员、操 作人员和用户之间相互了解彼此的工作；e.向潜在用户报导软件的功能和性能，使们能判定该软件能否服务于自己需 要。换言之，本指南认为：文件的编制必须适应计算机软件整个生存周期的需要。计算机软件所包含的文件有两类：一类是开发过程中填写的各种图表，可称 之为工作表格；另一类则是应编制的技术资料或技术管理资料，可称之为文件。本指南规定软件文件的编制形式，并提供对这些规定的解释。本指南的目的是使 得所编制的软件文件确实能够起到软件文件应该发挥的作用。235.L2范围本指南是一份指导性文件。本指南建议，在一项计算机软件的开发过程中，一般地说，应该产生九种文件。这九种文件是：可行性研究报告；项目开发计划；软件需求规格说明书；概要要求说明书；详细设计说明书；用户操作手册；测试计划；测试分析报告；项目开发总结报告。本指南将给出开发过程中建议产生的这九种文件的编制指导，同时，本指南 也是这九种文件的编写质量的检验准则。但是，本指南并未涉及软件开发过程中 如何填写工作表格问题。5.1.3文件的使用者对于使用文件的人员而言，他们所关心的文件的种类，随他们所承担的工作 而异。管理人员:可行性研究报告，项目开发计划，项目开发总结报告；开发人员:可行性研究报告，项目开发计划，软件需求说明书，概要设计说明书，详细设计说明书，24测试计划，测试分析报告；维护人员：设计说明书，测试分析报告；用户：用户操作手册5.2文件的编制指导5.2.1 软件生存周期与各种文件的编制一项计算机软件，从出现一个构思之日起，经过这项软件开发成功投入使用，直到最后决定停止使用，并被另一项软件代替之时止，被认为是该软件的一个生 存周期。一般地说这个软件生存周期可以分成以下六个阶段：（1）可行性分析和计划阶段；（2）需求分析；（3）设计阶段；（4）实现阶段（编码和调试）；（5）测试阶段；（6）运行和维护；在可行性研究与计划阶段内，要确定该软件的开发目标和总的要求，要进行 可行性分析、投资一收益分析、制订开发计划，并完成应编制的文件。在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定对 该软件的各项功能、性能需求和设计约束，确定对文件编制的要求，作为本阶段 工作的结果，一般地说，软件需求说明书、数据要求说明书和初步的用户操作手 册应该编写出来。在设计阶段内，系统设计人员和程序设计人员应该在反复理解软件需求的基 础上，提出多个设计，分析每个设计能履行的功能并进行相互比较，最后确定一 个设计，包括该软件的结构、模块的划分、功能的分配以及处理流程。在被设计 25系统比较复杂的情况下,设计阶段应分解成概要设计阶段和详细设计阶段两个步 骤。在一般情况下，应完成的文件包括：概要设计说明书、详细设计说明书和测 试计划初稿。在实现阶段内，要完成源程序的编码、编译（或汇编）和排错调试得到无语 法错的程序清单，要开始编写模块开发卷宗，并且要完成用户操作手册等面向用 户的文件的编写工作，还要完成测试计划的编制。在测试阶段，该程序将被全面地测试，已编制的文件将被检查审阅。一般要 完成测试记录和测试分析报告，作为开发工作的结束，所生产的程序、文件以及 开发工作本身将逐项被评审。在运行和维护阶段，软件将在运行使用中不断地被维护，根据新提出的需求 进行必要而且可能的扩充和删改。在项目结束后，编写项目总结报告。对于一项软件而言，其生存周期各阶段与各种文件编写工作的关系可见表 1.1,其中有些文件的编写工作可能要在若干个阶段中延续进行。表1.1软件生存周期各阶段中的文件编制段文可行性研究与计划阶段需求分析