软件工程项目开发各阶段的质量保证及软件工程整理版

a、需求分析需求分析是开发人员对系统需要做什么和如何做的定义过程。从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。只有不断地和客户领域专家进行交流确认，方能逐步明了用户的需求。从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍的放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。解决系统分析错误的方法我们公司通常采用邀请用户参与进行需求评定，然后对其用户的意见由质保成员跟踪检测是否纳入需求规格说明书，同时与用户签字确认形成需求基线，交由配置管理员放入配置管理库。虽然尽早的邀请用户参与，仍然避免不了项目进行中用户的需求变更请求。对于开发过程存在的需求变动，我们要求用户填写变更申请单发送给项目配置管理员，在通过配置员转交质保小组，负责组织专家小组和项目组成员一起讨论实施变更的可行性及实施后所带来的影响，小的变更则直接记录入变更记录原因分析项和风险项栏，大的变更则需要形成正式的变更报告，无论那种变更都需要对相应的文档实施同步变更（包括需求规格说明书、详细设计文档、安装手册、操作手册等）。但是对于无法实现或是变更会带来巨大的影响而将导致进度的延期，这时，我们将变更报告提交给用户或邀请用户进行协调会议，讨论变更取舍问题或是项目进度变更问题。决定变更之后，由项目经理组织实施变更，测试人员检测变更结果，而质保小组成员监督变更实施过程并协助配置管理员对变更后的成果物进行版本控制。变更实施完后，上线前还需要指定人员协助用户一同测试并由用户签字后同意方可上线。b、系统设计优良的体系结构应当具备可扩展性和可配置性，而好的体系结构则需要好的设计方法，自然设计选型成为了系统设计首要的工作，究竟是采用哪种设计方法好呢?对于设计选型不能一概而论，需要针对项目的结构、项目的特征和用户的需求来分析，同样也要考虑到参与项目小组成员的素质，如果其中大部分都没有从事过面向对象的设计且项目进对紧迫，这样没有多余的时间来培训小组成员来掌握面向对象的设计方法，尽管众所周知面向对象设计方法的优势，我们还是不如采用面向过程的方式（除用户指定开发设计方式外）可以减少项目承担的技术风险。我们公司有过一个项目，用户指定需要采用面向对象分析、设计和开发，且开发周期短，在无赖的情况下，项目小组只能选用面向对象的软件开发过程，由于项目小组很少从事过面向对象的开发，经验缺乏，导致项目上马后项目进度延误，项目没有达到预期的效果。针对此次开发，我们分析其原因，发现小组成员在开发过程中对于新技术互相交流少，各自有各自的理解和想法，造成理解上的不一致性，导致工作重复性高，滞后项目进度。建议解决方法是项目组成员采用集中办公，分块学习，学习的成果马上向项目相关人员发布，再由配置管理员对其发布的文档进行整理、规类放入配置库以供大家共享。这样方便大家的互相学习，减少重复的工作。在这次开发中我们公司从管理人员、设计人员到开发人员都汲取了很多教训，同时经过此次项目的开发，小组成员也积累了丰富的面向对象的开发经验。除设计选型，还有一个容易被忽视的问题，就是公共类开发。公共类开发可以减少工作中的重复工作，降低开发成本。这要求我们再设计阶段通过对用户需求的仔细研究，尽可能的识别出公共类，并进行定义指定专人负责设计通知其它设计人员，以减少重复工作。对于项目组提供的设计文档，由质保小组组织技术专家、项目组设计人员、开发人员和测试人员对其设计文档的评审，检测设计文档对其下一阶段工作的可行性，及时发现设计中可能存在的错误，降低项目开发风险，同时确保设计文档能为开发人员、测试人员提供切实的指导。对于可复用的设计进行提取作为公共库设计和开发，提供项目组或整个公司重用。最后交由配置管理员进行设计文档的版本控制。c、实现实现也就是代码的生产过程。这里不仅包括代码的产生，同时也包括测试用例的产生。针对上一阶段提供详细设计，程序员开始编码并且调试程序，测试人员则根据设计进行测试用例的设计，设计出来的用例需要得到项目组成员认可由项目经理审核通过才能进入配置库。同时程序员调试完程序提交测试人员进行程序正确性检测。d、文档管理文档维护主要是配置管理小组的工作。文档从用途上分主要分为内部文档和外部文档。内部文档包括：项目开发计划；需求分析；体系结构设计说明；详细设计说明；构件索引；构件成分说明；构件接口及调用说明；组件索引；组件接口及调用说明；类索引；类属性及方法说明；测试报告；测试统计报告；质量监督报告；源代码；文档分类版本索引；软件安装打包文件。外部文档主要包括：软件安装手册；软件操作手册；在线帮助；系统性能指标报告；系统操作索引。如何保证文档的全面性，使其真正为项目的进度提供保证，又不因为文档的写作而耽误项目的进度，这仍然是一个比较难解决的问题。解决此问题，其核心仍然是个"度"的问题。在本项目的开发中，配置管理小组的一个非常重要的任务还是书写文档规范和文档模板。当有文档模板后需要书写文档的人员只剩下"填空"的工作，从某种意义上讲，书写文档的速度会加快。如果书写文档的人员认为文档的更细致的部分可以由他人帮助完成，则该文档即交由他人完成，但此时文档并不算被正式提交，当他人书写完毕之后，必须由文档的初写者进行复审，复审通过后方可以正式提交，进入软件配置管理可以由他人帮助完成，则该文档即交由他人完成，但此时文档并不算被正式提交，当他人书写完毕之后，必须由文档的初写者进行复审，复审通过后方可以正式提交，进入软件配置管理的循环中。配置管理小组真正核心的工作是对文档的组织管理。根据文档的不同，文档的来源也不同，有些是通过质量保证小组经过复审之后转交给配置管理小组，有些则会直接从文档的出处到达配置管理小组。文档的管理是一个非常烦琐的工作，但是长远来看它不仅使项目的开发对单个主要人员的依赖减少，从而减少人员流动给项目的带来的风险，更重要的是在项目进行到后百分之十的时候起到拉动项目的作用。从以往做大项目的经验来看，写作文档在项目开发的早期可能会使项目的进度比起不写文档要稍慢，但随着项目的进展，各个部门需要配合越来越多，开发者越来越需要知道其他人员的开发思路和开发过程，才能使自己的开发向前推进。一个明显的例子就是系统整合，或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确性和高效性。3、系统维护质量保证在我们公司，维护小组的任务一方面是保证对项目客户的跟踪服务，另一方面是确保该项目其它的开发人员从项目中尽快的解脱出来以便投入到下一个项目的开发中。所以通常项目维护小组成员主要由项目组的少部分开发人员承担完成。他们不仅了解软件的核心内容，而且与客户也不陌生，以便能够以最快的速度修正错误。对于一般性的错误，如操作不当等引起的问题，全部由维护小组执行完成，但需要用户测试确认上线。如果较大的修改则需要走变更控制流程，用户或者维护人员填写变更申请，经专家会议讨论分析可行方案在由维护小组实施，通过测试后方可提交用户。维护小组的人员基本上是按项目跟进的。当一个项目刚刚交付用户时，在维护小组有较多的人员进行跟进，随软件的稳定，跟进的人逐步减少，并转移到其它项目中去。软件工程项目开发各阶段的质量保证软件工程基本概念(1)软件:是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合。(2)软件工程:开发、运行、维护和修复软件的系统方法。(3)软件工程方法学:通常把在软件生命周期全过程中使用的一整套技术的集合，称为软件工程方法学。(4)软件开发模型:是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。(5)系统流程图:描绘物理系统的一种传统工具，它的基本思想是用图形符号以黑盒子形式描绘系统里面的每一个部件（程序、文件、数据库、表格、人工过程等）。(6)数据流图(DataFlowDiagram,DFD):描绘系统的一种逻辑模型，图中没有任何具体的物理元素，只是描绘信息在系统中流动和处理的情况。(7)数据字典(DataDictionary,DD):对于数据流图中所出现的所有被命名的图形元素作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。(8)模型:对对象系统的形式化的特征抽象，概括性或近似地表示(9)结构化分析方法(StructuredAnalysis,SA):70年代中期提出的一种面向数据流、自顶向下、逐步求精进行需求分析的方法。(10)模块(module):数据说明和可执行语句等程序对象的集合，每个模块单独命名并且可以通过名字对模块进行访问。(11)模块化设计(modulardesign):把大型软件按照规定的原则划分为一个个较小的、相对独立但又相关的模块的设计方法。(12)深度:软件中指模块的最大层数。(13)扇出:软件中指一个模块直接调用的模块数。(14)扇入:软件中指调用一个给定模块的模块个数。(15)宽度:软件中指同一层最大模块数。(16)信息隐藏(InformationHiding):模块内部的数据与过程，应该对不需要了解这些数据与过程的模块隐藏起来。(17)内聚:用于衡量一个模块内部各个元素间彼此结合的紧密程度。(18)耦合:用于衡量不同模块彼此间互相依赖（连接）的紧密程度。(19)层次图:也称H图，是在总体设计阶段最常使用的图形工具之一，它常用于描绘软件的层次结构。层次图中的每个方框代表一个模块，方框间的连线表示模块间的调用关系。(20)结构化设计:一种设计程序的技术，它采用自顶向下逐步求精的设计方法和单入口、单出口的控制结构。（21)编码：就是把软件设计的结果翻译成计算机可以“理解”的形式——用某种程序设计语言书写的程序。（22)测试:为了发现程序中的错误而执行程序的过程。(23)白盒测试:也称结构测试/开盒测试/玻璃盒测试，是一种基于覆盖的测试方法；根据被测程序的逻辑结构设计测试用例，检验产品内部动作是否按照规规格说明书的规定正常进行。(24)黑盒测试:从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例，是根据程序外部特征进行测试。25)穷尽测试:包含所有可能情况的测试。(26)模块测试:又称单元测试，发现编码和详细设计的错误。(27)验收测试:由用户参与、使用实际数据来发现需求说明书中的错误的测试。(28)平行运行:同时运行新开发出来的系统和将被取代的旧系统，以便比较新旧两个系统的处理结果。(29)Alpha测试:用户在开发者的场所进行，并在开发者的指导下进行；(30)Beta测试:在一个或多个用户场所进行，开发者不在现场。(31)软件维护:为了改正错误或满足新的需要而修改软件的过程。(32)纠错性维护:针对原有错误而进行的维护过程。(33)适应性维护:针对硬件发展而进行的维护过程。(34)完善性维护:针对功能扩展而进行的维护过程。(35)预防性维护:针对未来发展而进行的维护过程。(36)等价类:每类中的一个典型值在测试中的作用与这一类中所有其他值的作用相同。(37)对象:具有相同状态的一组操作的集合。(38)消息:要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明。对象:对问题域中某个东西的抽象，这种抽象反映了系统保存有这个东西的信息或与它交互的能力。对象是对属性值和操作的封装。(39)类:对具有相同属性和行为的一个或多个对象的描述。(40)实例:由某个特定的类所描述的一个具体的对象。(41)消息:要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明。(42)方法:对象所能够执行的操作。也就是类中所定义的服务。(43)属性:类中所定义的数据，它是对客观实践实体所具有的性质的抽象。(44)封装:在面向对象的程序中，把数据和实现操作的代码集中起来放在对象的内部，称之为封装。(45)继承:指能够直接获得已有的性质和特征，而不必重复定义它们。(46)多态性:子类对象可以象父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子类对象。软件工程常用工具与模型(1)瀑布模型：定义：将软件生存周期的各项活动规定为依照固定顺序连接的若干阶段工作，形如瀑布流水，最终得到软件产品。实例：(2)系统流程图定义：系统流程图是描绘物理系统的传统工具，它的基本思想是用图形符号以黑盒子形式描绘系统里面的每一个部件（程序、文件、数据库、表格、人工过程等）。(3)数据流图定义：英文DataFlowDiagram，简称DFD。DFD是一种描述逻辑模型的图形工具，表示数据在系统内的变化。图中没有任何具体的物理元素，只是描绘信息在系统中流动和处理的情况。DFD从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的移动变换过程。它由数据流、加工、文件和数据流的源点和终点构成。(4)数据字典定义：英文DataDictionary，简称DD。是一种描述逻辑模型的工具。它对于数据流图中所出现的所有被命名的图形元素作为一个词条加以定义，使得每一个图形元素的名字都有一个确切的解释。DD的内容包括：图形元素的名字、别名或编号、分类、描述、定义、位置等。实例：《客房管理系统》字典建模预订请求＝客人数据＋住宿期限+客房类别客人数据＝客人姓名+地址+身份证号码+[护照号码]+支付方式身份证号码=十进制15{数字}18护照号码＝字母+8{数字}8字母＝“A”…“Z”十进制数字＝“0”…“9”(5)实体—联系图定义：实体—联系图(ERA，Entity-RelationshipApproach)或实体联系图（ERD，Entity-RelationshipDiagram）。ERD描绘了系统的数据关系。分析实体联系图有助于对业务或系统数据组成的理解和交互，并暗示产品将有必要包含一个数据库。ER模型三要素：数据对象、属性和联系。(6)状态转换图定义：状态转换图简称状态图。通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。它由1个初态/初始状态、0~N个终态/最终状态和若干个中间状态组成。(7)层次方框图定义：用属性结构的一系列多层次的矩形框描述数据的层级结构。(8)IPO图定义：输入、处理、输出图的简称。是IBM公司发展完善的一种图形工具。(9)层次图定义：层次图（也称H图）是在总体设计阶段最常使用的图形工具之一，它常用于描绘软件的层次结构。它矩形代表一个模块，连线表示调用关系，适于在自顶向下设计软件的过程中使用；与层次方框图类似。(10)HIPO图定义：HIPO:是IBM公司发明的“层次图加输入/处理/输出图的缩写；为了能使HIPO图具有可跟踪性，在H图里除了最顶层的方框之外，每个方框都加了编号；和H图中的每个方框相对应，有一张IPO图描述这个方框代表的模块的处理过程。IPO图能够方便地描述数据输入、数据处理和数据输出之间的关系。(12)结构图定义：Yourdon提出的一种软件结构设计工具。一个方框/矩形代表一个模块，箭头连线/直线表示调用关系，带有注释的箭头表示模块调用过程中来回传递的信息。(13)程序流程图定义：也称为程序框图；箭头代表控制流而不是数据流；20世纪70年代的主要工具；趋势是越来越多的人不再使用。它的主要缺点包括：不是逐步求精的好工具；用箭头代表控制流，可以随意转移控制；不宜表示数据结构。(14)盒图（N-S图）定义：由Nassi和Shneiderman提出的一种程序设计方法；其主要特点包括：[1]功能域明确；[2]不可以随意转移；[3]容易确定局部和全程数据的作用域；[4]容易表达嵌套关系。实例：(15)PAD图定义：PAD图是一种问题分析图(ProblemAnalysisDiagram)，1973年由日本日立公司提出。其主要特点包括：[1]必是结构化程序；[2]程序结构清晰；[3]易读、易懂、易记；[4]支持自顶向下，逐步求精的方法；[5]既可以表示程序逻辑，也可以表示数据结构。(16)判定表定义：判定表在某些数据处理中，某数据流图的加工需要依赖于多个逻辑条件的取值，就是说完成这一加工的一组动作是由于某一组条件取值的组合而引发的。这时使用判定表来描述比较合适。判定表通常由四部分组成，即：条件桩、操作桩、条件条目和操作条目。(17)判定树定义：判定树是判定表的变种，它也能清晰地表达复杂的条件组合与所对应的操作之间的关系。判定树的优点在于它无须任何说明，一眼就能看出其含义，易于理解和使用。(18)过程设计语言（PDL）定义：也称“伪码”，用正文形式表示数据和处理的过程的工具。其具有如下特点：[1]具有关键字固定语法；[2]自然语言表述；[3]数据说明；[4]提供接口模式。(19)用例图定义：用例图是被称为参与者的外部用户所能观察到的系统共呢概念的模型图；用例是系统中的一个功能单元，可以被描述为参与者与系统之间的一次交互作用；用例图的用途是列出系统中的用例和参与者，并显示哪个参与者参与了那个用例的执行。(20)活动图定义：活动图描述了活动发生的顺序。其图形表示规则如下：圆角矩形表示方框中的活动；矩形表示工作流影响的对象；实心圆表示工作流开始的开始状态；双层圆表示工作流结束的结束状态；菱形表示决策点；垂直泳道表示工作流中的不同参与者及相关活动。(21)顺序图顺序图表示对象之间传送消息的时间顺序。图形表示法：垂直线，即生命线，表示在整个交互过程中一个对象的生命周期。生命线之间的箭头连线表示消息。箭头连线上的文字表示相关的事件。(22)协作图协作图对在一次交互中有意义的对象和对象间的链建模。图形表示法：直线表示对象之间直接通信关系。附在直线上箭头表示消息传送方向。箭头旁文字表示消息及消息编号。(23)类图以类为中心组织起来的图形，用以表示软件系统中各类之间的相互关系。图形表示法：矩形框表示类图中的类。连线表示类之间的关系。类之间的关系有关联、聚集、泛化和依赖。(24)状态图状态图是一个类对象所经历的所有历程的模型图。状态图有对象的各个状态和连接这些状态的变迁组成。图形表示法：圆角矩形表示状态；带箭头的直线表示对象从一种状态变迁到另一种状态的过程。附在直线上的信息表示触发对象状态变迁的条件。(25)组件图组件图表示了系统中的各种组建。组件可以是源代码、二进制文件或可执行文件。逻辑视图与组件视图之间存在着映射关系。组件可以与公开的任何接口一起显示。(26)部署图用来描述位于节点实例上的运行组件的安排，描述系统的实际物理结构。图形表示法：立方体表示节点，节点可以是一组运行的资源，如计算机、设备或存取器等。直线表示节点之间连接方式。软件工程原理/技术/方法1、软件工程的本质特性(1)软件工程关注于大型程序的构造；(2)软件工程的中心课题是控制复杂性；(3)软件经常变化；(4)开发软件的效率非常重要；(5)和谐地合作是开发软件的关键；(6)软件必须有效地支持它的用户(7)在软件工程领域中是由具有一种文化背景的人代替具有另一种文化背景的人创造产品。2、软件工程的七条基本原理(1)用分阶段的生命周期计划严格管理；(2)坚持进行阶段评审；(3)实行严格的产品控制；(4)采用现代程序设计技术；(5)结果应能够清楚地审查；(6)开发小组的人员应少而精；(7)承认不断改进软件工程实践的必要性；3、软件生存期的阶段划分(1)可行性研究与计划(2)需求分析(3)总体设计(4)详细设计(5)实现(编码)(6)集成测试(7)确认测试(8)使用和维护4、传统方法学(1)传统方法学夜车概念生命周期方法学或结构化范型；(2)采用结构化技术(分析/设计/实现)，来完成软件开发各项任务；(3)把软件生命周期的全过程依次划分为若干阶段。本质是面向过程的开发。(4)每个阶段对立完成，各阶段有严格的开始和结束标准。前一阶段结束，才能开始下一个阶段。(5)在相当长的一段时间内仍有生命力。5、面向对象的方法学面向对象方法以数据为主线，把是数据和对数据的操作紧密地结合起来的方法。(1)把对象作为融合数据机在数据上的操作行为的统一的软件构件。(2)把所有对象划分成类。(3)按照父类与子类的关系，把若干个相关类组成一个层次结构的系统。(4)对象彼此间仅能通过发送消息互相联系。6、可行性研究的主要内容一般来说，至少要从以下三个方面开展研究：(1)技术可行性：使用现有技术能实现这个系统吗？(2)经济可行性：这个系统的经济效益能超过它的开发成本吗？(3)操作可行性：系统的操作方式在这个用户组织内行得通吗？此外，还应从法律、社会效益等更广泛的方面研究每种解法的可行性。7、可行性研究过程(1)复查系统规模和目标；(2)研究目前正在使用的系统；(3)导出新系统的高层逻辑模型；(4)进一步定义问题；(5)导出和评价供选择的解法；(6)推荐行动方针；(7)草拟开发计划；(8)书写文档提交审查。8、成本/效益分析内容(1)成本估计代码行技术任务分解技术自动估计成本技术(2)成本/效益分析的方法货币的时间价值投资回收期纯收入投资回收率9、各种需求分析方法所应遵循的准则(1)必须理解并描述问题的信息域，建立数据模型；(2)必须定义软件应完成的功能，建立功能模型；(3)必须描述作为外部事件结果的软件行为，建立行为模型；(4)必须对描述信息、功能和行为的模型进行分解，用层次的方式展开细节。10、需求分析的具体任务(1)确定软件系统的综合需求；(2)分析系统的数据需求：数据模型/信息模型E-R/层次方框图；(3)导出软件系统的逻辑模型：数据流图/E-R图/状态转换图/数据字典/算法；(4)修正系统开发计划；(5)验证软件需求分析的正确性；(6)编写软件需求规格说明书。11、系统的综合要求/需求(1)功能需求：系统必须提供的服务(2)性能需求：系统必须满足的定时约束或容量约束等。(3)可靠性和可用性需求。(4)出错处理需求：系统对环境错误应该怎样响应。(5)接口需求：系统与它的环境通信格式要求。(6)约束：设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件：精度/工具/语言/设计/标准/平台。12、需求获取的常用方法(1)访谈(2)面向数据流自顶向下求精(3)简易的应用规格说明技术(4)快速建立软件原型13、总体设计过程1.设想供选择的方案2.选取合理的方案3.推荐最佳方案4.功能分解5.设计软件结构6.设计数据库7.制定测试计划8.书写文档9.审查和复审14、软件设计中的常用启发规则(1)改进软件结构提高模块独立性；(2)模块规模应该适中；(3)深度、宽度、扇出、扇入都应适当；(4)模块的作用域应该在控制域之内；(5)力争降低模块接口的复杂程度；(6)设计单入口单出口的模块；(7)模块功能应该可以预测。15、耦合设计原则(1)尽量使用数据耦合(2)少用控制耦合(3)限制公共环境耦合范围(4)完全不用内容耦合16、内聚设计原则(1)力求高内聚；(2)中等内聚也可以采用；(3)低内聚不要用。17、面向数据流的设计方法(1)系统结构特征可归纳为两种典型形式变换型结构事务型结构(2)数据流图可分为两种类型变换型数据流事务型数据流(3)面向数据流设计方法的设计步骤(1)精化DFD。(2)确定DFD类型。(3)把DFD映射到系统模块结构，设计出模块结构的上层。(4)基于DFD，逐步分解高层模块，设计出下层模块。(5)根据模块独立性原理，精化模块结构。(6)模块接口描述18、人机界面设计中经常遇到的4个设计问题(1)系统响应时间(2)用户帮助设施(3)出错信息处理(4)命令交互19、人机界面设计一般交互指南(1)保持一致性(2)提供有意义的反馈(3)在执行有较大破坏型的动作之前，要求用户确认(4)允许取消绝大多数操作(5)减少在两次操作之间必须记忆的信息量(6)提高对话、移动和思考的效率(7)允许犯错误(8)按功能对动作分类，并据此设计屏幕布局(9)提供对用户工作内容敏感的帮助设施(10)用简单动词或动词短语作为命令名20、人机界面设计信息显示指南(1)只显示于当前工作内容有关的信息(2)不要用数据淹没用户(3)使用一致的标记、标准的缩写和可与之的颜色(4)允许用户保持可视化的语境(5)产生有意义的出错信息(6)使用大小写、缩进和文本分组以帮助理解(7)使用窗口分隔不同类型的信息(8)使用模拟显示方式显示信息(9)高效率地使用显示屏21、数据输入指南(1)尽量减少用户的输入动作(2)保持信息显示和数据输入之间的一致性(3)允许用户自定义输入(4)交互应该是灵活的(5)使在当前语境中不适用的命令不起作用(6)让用户控制交互流(7)对所有输入动作都提供帮助(8)消除冗余的输入22、选择一种语言的标准是什么？(1)系统用户的要求：用户知识和用户环境要求；(2)可以使用的编译程序：软件平台要求；(3)可以得到的软件工具：软件条件要求；(4)工程规模：实践要求；(5)程序员的知识：方便性要求；(6)软件可移植性要求：造价要求；(7)软件的应用领域：对象特点要求。23、编码风格应该遵循的规则(1)程序内部的文档化：指编码时适当选择标识符的名字适当安排注释注重程序的整个组织形式(2)数据说明(3)语句构造(4)输入/输出24、软件测试准则(1)所有测试都应该能追溯到用户需求。(2)应该远在测试开始之前就制定出测试计划。(3)把Pareto原理应用到软件测试中。Pareto原理：测试发现的错误中80%很可能是由程序中20%的模块造成的。(4)应该从“小规模”测试开始，并逐步进行“大规模”测试。(5)穷举测试是