软件设计阶段一般又可分为（9)。

免费智能真题库 > 历年试卷 > 软件评测师 > 2010年下半年软件评测师上午试卷综合知识

第9题

知识点：分析设计阶段软件设计软件设计阶段设计阶段

关键词：软件设计设计阶段章/节：软件测试类型

软件设计阶段一般又可分为（9)。

A. 逻辑设计与功能设计

B. 概要设计与详细设计

C. 概念设计与物理设计

D. 模型设计与程序设计

相关试题：软件测试策略

更多>

第65题 2014年下半年

29%

集成测试关注的问题不包括 (65) 。

第7题 2013年下半年

40%

(7)不是单元测试主要检查的内容。

第60题 2012年下半年

33%

以下属于集成测试的是（60)。


知识点讲解
· 分析设计阶段 · 软件设计 · 软件设计阶段 · 设计阶段

分析设计阶段

分析设计阶段的测试工作是评审与测试相结合的过程，主要包括需求说明书评测、概要设计说明书评测、详细设计说明书评测以及软件编码规范评测等。下述章节将详细论述。

需求说明书评测

由于软件应用系统针对的行业广泛，因此在需求分析阶段可能存在着承建单位对业主单位的业务需求理解不全面、不准确的情况，常发生承建单位认为某一个业务功能的实现非常简单，而实际上业主单位业务标准的要求却很复杂的情况。在这种情况下，如果不通过评测进行相关的质量控制，往往造成承建单位按照自己的理解进行开发。如果不进行评测，或者评测之后没有充分发现问题，则给系统造成重大隐患，或者造成返工与延期。

因此，在此阶段评测的工作重点是与承建单位的分析人员、设计人员一起对需求说明书进行审查，并协调业主单位完成需求说明书的评审确认。

什么样的需求说明书是良好的，需求说明书编写应该遵照怎样的框架，针对需求说明书的评测有哪些主要内容等，这些在下述章节将详细论述。

. 编制良好的需求说明书8条原则。

1979年由Balzer和Goldman提出了作出良好规格说明的8条原则。

原则1：功能与实现分离，即描述要“做什么”而不是“怎样实现”。

原则2：要求使用面向处理的规格说明语言，讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规格说明。

原则3：如果目标软件只是一个大系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。描述该目标软件与系统的其他系统元素交互的方式。

原则4：规格说明必须包括系统运行的环境。

原则5：系统规格说明必须是一个认识的模型，而不是设计或实现的模型。

原则6：规格说明必须是可操作的。规格说明必须是充分完全和形式的，以便能够利用它决定对于任意给定的测试用例，已提出的实现方案是否都能满足规格说明。

原则7：规格说明必须容许不完备性并允许扩充。

原则8：规格说明必须局部化和松散的耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规格说明应被松散地构造（即耦合），以便能够很容易地加入和删去一些段落。

尽管Balzer和Goldman提出的这8条原则主要用于基于形式化规格说明语言之上的需求定义的完备性，但这些原则对于其他各种形式的规格说明都适用。当然要结合实际来应用上述的原则。

. 需求说明书的框架。

需求说明书是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。如下表中列出了需求说明书的框架。

需求说明书的框架

. 需求说明书评测内容。

需求说明书评测作为需求分析阶段工作的复查手段，应该对功能的正确性、完整性和清晰性，以及其他需求给予评测。评测的主要内容是：

①系统定义的目标是否与用户的要求一致；

②系统需求分析阶段提供的文档资料是否齐全；

③文档中的所有描述是否完整、清晰，准确地反映用户要求；

④与所有其他系统成份的重要接口是否都已经描述；

⑤被开发项目的数据流与数据结构是否足够、确定；

⑥所有图表是否清楚，在不补充说明时能否理解；

⑦主要功能是否已包括在规定的软件范围之内，是否都已充分说明；

⑧软件的行为和它必须处理的信息、必须完成的功能是否一致；

⑨设计的约束条件或限制条件是否符合实际；

⑩是否考虑了开发的技术风险；

?是否考虑过软件需求的其他方案；

?是否考虑过将来可能会提出的软件需求；

?是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；

?有没有遗漏、重复或不一致的地方；

?用户是否审查了初步的用户手册或原型；

?项目开发计划中的估算是否受到了影响。

为保证软件需求定义的质量，评测应由专门指定的人员负责，并按规程严格进行。评审结束，应有评审负责人的结论意见及签字。除承建单位分析员之外，业主单位人员和测试单位都应当参加评测工作。需求说明书要经过严格评测，一般，评测的结果都包括了一些修改意见，待修改完成后再经评测，才可进入设计阶段。根据上述讨论的评测内容，可以制定需求说明书评测规范，如下表所示。

填表说明：Y—是，TBD—不确定，N—否，NA—不适用。

需求说明书评测规范

在需求说明书评测结束后，测试单位应将评测意见以专题报告的形式提交业主单位。

概要设计说明书评测

. 设计说明书的框架。如下表所示为软件设计规格说明的大纲。

软件设计规格说明大纲

软件设计的最终目标是要取得最佳方案。“最佳”是指在所有候选方案中，就节省开发费用，降低资源消耗，缩短开发时间的条件，选择能够赢得较高的生产率、较高的可靠性和可维护性的方案。在整个设计的过程中，各个时期的设计结果需要经过一系列设计质量的评测，以便及时发现和解决在软件设计中出现的问题，防止把问题遗留到开发的后期阶段，造成后患。

. 概要设计说明书评测的内容。

①可追溯性：即分析该软件的系统结构、子系统结构，确认该软件设计是否覆盖了所有已确定的软件需求，软件每一成份是否可追溯到某一项需求。

②接口：即分析软件各部分之间的联系，确认该软件的内部接口与外部接口是否已经明确定义。模块是否满足高内聚和低耦合的要求。模块作用范围是否在其控制范围之内。

③风险：即确认该软件设计在现有技术条件下和预算范围内是否能按时实现。

④实用性：即确认该软件设计对于需求的解决方案是否实用。

⑤技术清晰度：即确认该软件设计是否以一种易于翻译成代码的形式表达。

⑥可维护性：从软件维护的角度出发，确认该软件设计是否考虑了方便未来的维护。

⑦质量：即确认该软件设计是否表现出良好的质量特征。

⑧各种选择方案：看是否考虑过其他方案，比较各种选择方案的标准是什么。

⑨限制：评估对该软件的限制是否现实，是否与需求一致。

⑩其他具体问题：对于文档、可测试性、设计过程等进行评估。

在这里需要特别注意：软件系统的一些外部特性的设计，例如软件的功能、一部分性能以及用户的使用特性等，在软件需求分析阶段就已经开始。这些问题的解决，多少带有一些“怎么做”的性质，因此有人称之为软件的外部设计。

为评测设计是否达到目标，必须建立衡量设计的技术标准。如下：

①设计出来的结构应是分层结构，从而建立软件成分之间的控制。

②设计应当模块化，从逻辑上将软件划分为完成特定功能或子功能的构件。

③设计应当既包含数据抽象，也包含过程抽象。

④设计应当建立具有独立功能特征的模块。

⑤设计应当建立能够降低模块与外部环境之间复杂连接的接口。

⑥设计应能根据软件需求分析获取的信息，建立可驱动、可重复的方法。

根据上述讨论的评测内容以及评测标准，可以建立概要设计说明书评测规范，如下表所示。

填表说明：Y—是，TBD—不确定，N—否，NA—不适用。

概要设计说明书评测规范

详细设计说明书评测

详细设计说明书的评测标准和评测内容与概要设计说明书基本相同，这里不再赘述。如下表所示为详细设计说明书评测规范。

填表说明：Y—是，TBD—不确定，N—否，NA—不适用。

详细设计说明书评测规范

软件编码规范评测

程序实际上也是一种供人阅读的文章，有一个文章的风格问题。程序良好的风格表现在源程序文档化、数据说明的方法、语句结构和输入/输出方法这四个方面，软件编码规范评测也是围绕这四个方面展开。下面分别论述评测内容以及相应的评测标准。

. 源程序文档化。

①符号名的命名。符号名即标识符，包括模块名、变量名、常量名、标号名、子程序名、数据区名以及缓冲区名等。这些名字应能反映它所代表的实际东西，应有一定实际意义。例如，表示次数的量用Times，表示总量的用Total，表示平均值的用Average，表示和的量用Sum等。

名字不是越长越好，应当选择精炼的、意义明确的名字。必要时可使用缩写名字，但这时要注意缩写规则要一致，并且要给每一个名字加注释。同时，在一个程序中，一个变量只应用于一种用途。

②程序的注释。夹在程序中的注释是程序员日后与程序读者之间通信的重要手段。注释绝不是可有可无的。一些正规的程序文本中，注释行的数量占到整个源程序的1/3~1/2，甚至更多。注释分为序言性注释和功能性注释。

序言性注释通常置于每个程序模块的开头部分，它应当给出程序的整体说明，对于理解程序本身具有引导作用。有些软件开发部门对序言性注释做了明确而严格的规定，要求程序编制者逐项列出。有关项目包括：程序标题；有关本模块功能和目的的说明；主要算法；接口说明：包括调用形式，参数描述，子程序清单；有关数据描述：重要的变量及其用途，约束或限制条件，以及其他有关信息；模块位置：在哪一个源文件中，或隶属于哪一个软件包；开发简历：模块设计者，复审者，复审日期，修改日期及有关说明等。

功能性注释嵌在源程序体中，用以描述其后的语句或程序段是在做什么工作，或是执行了下面的语句会怎么样。而不要解释下面怎么做。要点：描述一段程序，而不是每一个语句；用缩进和空行，使程序与注释容易区别；注释要正确。

③标准的书写格式。视觉组织用空格、空行和移行来实现。恰当地利用空格，可以突出运算的优先性，减少编码的错误；自然的程序段之间可用空行隔开；移行也叫做向右缩格。它是指程序中的各行不必都在左端对齐，都从第一格起排列，这样做使程序完全分不清层次关系。对于选择语句和循环语句，把其中的程序段语句向右作阶梯式移行。使程序的逻辑结构更加清晰。

. 数据说明。

在设计阶段已经确定了数据结构的组织及其复杂性。在编写程序时，则需要注意数据说明的风格。为了使程序中数据说明更易于理解和维护，必须注意以下几点。

①数据说明的次序应当规范化。数据说明次序规范化，使数据属性容易查找，也有利于测试，排错和维护。原则上，数据说明的次序与语法无关，其次序是任意的。但出于阅读、理解和维护的需要，最好使其规范化，使说明的先后次序固定。

②说明语句中变量安排有序化。当多个变量名在一个说明语句中说明时，应当对这些变量按字母的顺序排列。带标号的全程数据也应当按字母的顺序排列。

③使用注释说明复杂数据结构。如果设计了一个复杂的数据结构，应当使用注释来说明在程序实现时这个数据结构的固有特点。

. 语句结构。

在设计阶段确定了软件的逻辑流结构，但构造单个语句则是编码阶段的任务。语句构造力求简单、直接，不能为了片面追求效率而使语句复杂化。

比如：在一行内只写一条语句；程序编写首先应当考虑清晰性；程序要能直截了当地说明程序员的用意；除非对效率有特殊的要求，程序编写要做到清晰第一，效率第二，不要为了追求效率而丧失了清晰性；首先要保证程序正确，然后才要求提高速度，反过来说，在使程序高速运行时，首先要保证它是正确的；避免使用临时变量而使可读性下降；对编译程序做简单的优化；尽可能使用库函数；避免不必要的转移；尽量采用基本的控制结构来编写程序；避免采用过于复杂的条件测试；尽量减少使用“否定”条件的条件语句；尽可能用通俗易懂的伪码来描述程序的流程，然后再翻译成必须使用的语言；数据结构要有利于程序的简化；程序要模块化，使模块功能尽可能单一化，模块间的耦合能够清晰可见；利用信息隐蔽，确保每一个模块的独立性；从数据出发去构造程序；不要修补不好的程序，要重新编写。

. 输入和输出

输入和输出信息是与用户的使用直接相关的。输入和输出的方式和格式应当尽可能方便用户的使用。一定要避免因设计不当给用户带来的麻烦。因此，在软件需求分析阶段和设计阶段，就应基本确定输入和输出的风格。系统能否被用户接受，有时就取决于输入和输出的风格。输入/输出风格还受到许多其他因素的影响。如输入/输出设备（终端的类型，图形设备，数字化转换设备等）、用户的熟练程度以及通信环境等。不论是批处理的输入/输出方式，还是交互式的输入/输出方式，在设计和程序编码时都应考虑下列原则。

①对所有的输入数据都要进行检验，识别错误的输入，以保证每个数据的有效性；

②检查输入项的各种重要组合的合理性，必要时报告输入状态信息；

③使输入的步骤和操作尽可能简单，并保持简单的输入格式；

④输入数据时，应允许使用自由格式输入；

⑤应允许缺省值；

⑥输入一批数据时，最好使用输入结束标志，而不要由用户指定输入数据数目；

⑦在交互式输入时，要在屏幕上使用提示符，明确提示交互输入的请求，指明可使用选择项的种类和取值范围。同时，在数据输入的过程中和输入结束时，也要在屏幕上给出状态信息；

⑧当程序设计语言对输入/输出格式有严格要求时，应保持输入格式与输入语句要求的一致性；

⑨给所有的输出加注解，并设计输出报表格式。

软件设计

软件设计的任务

在给定系统的需求规格说明书后，需要对软件的结构进行设计，并对设计的过程进行管理。在嵌入式系统的软件设计过程中，需要完成以下一些任务。

准备工作计划

在软件设计之前，首先要制订详细的工作计划，其内容包括：

.过程管理方案：包括软件开发的进度管理、软件规模和所需人年的估算、开发人员的技能培训等；

.开发环境的准备方案：包括开发工具的准备、开发设备的准备、测试装备的准备、分布式开发环境下的开发准则等；

.软硬件联机调试的方案：联调的起始时间、地点、人员和具体的准备工作；

.质量保证方案：包括质量目标计划、质量控制计划等；

.配置控制方案：包括配置控制文档的编写、配置控制规则的制订等。

确定软件的结构

设计软件的各个组成部分，包括：

.任务结构的设计：使用操作系统提供的函数，设计出一个最佳的任务结构；

.线程的设计；

.公共数据结构的设计：在确保系统一致性的基础上，设计出所需的公共数据；

.操作系统资源的定义；

.类的设计；

.模块结构设计：在设计时要充分考虑模块的划分、标准化、可重用和灵活性等；

.内存的分配与布局。

设计评审

对于软件设计的结果，进行一次设计评审，并在必要时对设计进行修正。具体内容包括：

.确认每件工作的执行方法是否恰当，其内容是否完善；

.确认该设计完成了系统需求规格说明书所要求的功能和服务；

.评估任务结构设计、评估类的设计、评估模块结构设计；

.对软件设计的结果进行总结，编写出相应的文档。

维护工作计划

执行软件设计工作控制，在每日、每周和每月的时间粒度上对进度进行控制，确保软件设计能够如期完成。

与硬件部门密切合作、相互协调

根据工作计划中的安排，定期与硬件部门召开会议，协调各自的进展。如果软件规格说明书发生了变化，立即进行调整，重新进行软件设计。

控制工作的结果，把工作记录存档

掌握当前的工作进展情况，尽早地发现和分析问题，并采取相应的措施。对各种事件进行跟踪记录，包括：

.执行过程控制，跟踪进展情况并定期记录、存档。

.执行质量控制，保留质量记录。

.记录产品的配置、版本变化、bug的发现和处理等信息。

软件架构设计

软件架构也称为软件体系结构，需要考虑如何对系统进行分解，对分解后的组件及其之间的关系进行设计，满足系统的功能和非功能需求。软件架构形成过程如下图所示。

架构的形成过程概要

软件架构设计需要从用户业务需求、未来应用环境、需求分析、硬件基础、接口输入、数据处理、运算或控制规律、用户使用等方面进行综合、权衡和分析基础上产生。面向某种问题的架构一旦确定就很难改变，随后的架构设计需要通过一系列的迭代开发完善，使得软件架构日趋成熟、稳定。

软件架构的重要作用也在于控制一个软件系统的使用、成本和风险。好的架构要求是和谐的软件架构，包括与上一级系统架构相互和谐、与系统中同一级的其他组件架构互相和谐，确保系统满足性能、可靠性、安全性、信息安全性和互操作性等方面的关键要求，也具有可扩展、可移植性，从而为一个软件带来长久的生命力。

在大量开发实践中，有很多广泛使用并被普遍接受的软件架构设计原则，这些原则独立于具体的软件开发方法，主要包括抽象、信息隐藏、强内聚和松耦合、关注点分离等。

（1）抽象：这是软件架构的核心原则，也是人们认识复杂客观世界的基本方法。抽象的实质是提取主要特征和属性，从具体的事务中通过封装来忽略细节，并且运用这些特征和属性，描述一个具有普遍意义的客观世界。软件架构设计中需要对流程、数据、行为等进行抽象。复杂系统含有多层抽象，从而有多个不同层次架构。

（2）信息隐藏：包括局部化设计和封装设计。局部化设计就是将一个处理所涉及到的信息和操作尽可能地限制在局部的一个组件中，减少与其他组件的接口。而封装设计是将组件的外部访问形式尽可能简单、统一。

（3）强内聚和松耦合：强内聚是指软件组件内的特性，即组件内所有处理都高度相关，所有处理组合在一起才能组成一个相对完整的功能。而松耦合是指软件组件之间的特性，软件组件之间应尽量做到没有或极少的直接关系，使其保持相对独立，这样使得未来的修改、复用简单，修改之后带来的影响最小。

（4）关注点分离：所谓关注点是软件系统中可能会遇到的多变的部分。如为适应不同运行接口条件，需要进行适应性的参数调整和驱动配置。关注点分离设计是将这部分组件设计成为相对独立的部分，使未来的系统容易配置和修改。而核心的部分可以保持一个相对独立的稳定状态。如果功能分配使得单独的关注点组件足够简单，那么就更容易理解和实现。但“展示某些关注点得到满足时，可能会影响到其他方面的关注点，但架构师必须能够说明所有关注点都已得到满足”。

以上的原则中，删除需求细节或对细节进行抽象是最重要的工作，为用户的需求创建抽象模型，通过抽象将特殊问题映射为更普遍的问题类别，并识别各种模式。

软件架构设计使用纵向分解和横向分解两种方式。纵向分解就是分层，横向分解就是将每一个层面分成相对独立的部分。经过分解之后，可以将一个完整的问题分解成多个模块来解决。模块是其中可分解、可组装，功能独立、功能高度内聚、之间低耦合的一个组件。

类似于建筑架构，软件架构也决定了软件产品的好用、易用、可靠、信息安全、可扩展、可重用等特性，好的软件架构也给人完整、明确、清晰等赏心悦目的感觉，具有较长的生命力。

架构设计是围绕业务需求带来的问题空间到系统解决空间第一个顶层设计方案。按照抽象原则，在这个阶段进行的架构设计关注软件设计环节抽象出来的重要元素，而不是所有的设计元素。在架构设计时将软件这些要素看作是黑盒，架构设计需要满足黑盒的外部功能和非功能需求的目标。一个软件的架构设计首先为软件产品的后续开发过程提供基础，在此基础上可将一个大规模的软件分解为若干子问题和公共子问题。而一般意义的软件设计是软件的底层设计，开发人员需要关注各子问题或要素的进一步分解和实现，是根据架构设计所定义的每个要素的功能、接口，进一步实现要素组件内部的配置、处理和结构。在遵守组件外部属性前提下，考虑实现组件内部的细节及其实现方法。对于其中的公共子问题，形成公共类和工具类，从而可以达到重用的目的。

一般的软件构架是根据需求自上而下方式来设计，即首先掌握和研究利益相关方的关键需求，基本思路是首先进行系统级的软件架构设计，需要将软件组件与其外部环境属性绑定在一起，关注软件系统与外部环境的交联设计；其次将一个大的系统划分成各组成部分，这些部分可以按照架构设计的不同方法，分为层次或成为模块；之后再开始研究所涉及到的要素，再实现这些要素以及定义这些要素之间的关系。

在实际工作中，软件构架也可采用自底向上的方法，前提是已经建立了一个成熟稳定的软件架构，也可以称之为“模式”。模式是组织一级设计某一类具体问题的顶层思路，是为了解决共有问题解的方案模板，但并不是一个问题的设计或设计算法。

模式常常整合在一起使用，提供解决更大、更复杂问题的解决方案，而组成一个解决问题的通用框架。框架往往提供统一平台和开发工具，而且已经高效地利用了已经经过验证的模式、技术和组件。在新软件系统的设计中指定沿用或重用这种架构框架，这时其他重要元素可以在这个架构基础上针对新的需求进行扩展，有时是针对性地进行参数化设计。所以在架构设计中可以借用模式的概念进行设计，采用成熟的先进的设计框架和工具提高开发的效率，保证设计正确性。

下图所示是针对架构设计中非功能需求的多维度分析，从中可知任何一个因素的变化都会带来对其他因素的影响。实际上软件架构设计属于软件设计过程的一部分，但超越了系统内部的算法和数据结构的详细设计。

架构的多维度分析

在架构设计阶段，需要定义边界条件、描述系统组织结构、对系统的定量属性进行约束、帮助对模型进行描述并基本构造早期的原型、更准确地描述费用和时间的评估。

软件设计方法

在将系统分解为各个组件的过程中，需要采取不同的策略，而每个策略则关注不同的设计概念。根据分解过程中所采用的不同策略，设计方法有基于功能分解的设计方法、基于信息隐藏的设计方法和基于模型驱动开发的设计方法等分类。

（1）基于功能分解的设计方法。实时结构化分析与设计采用了功能分解，系统被分解为多个函数，并且以数据流或控制流的形式定义函数之间的接口；基于并发任务结构化的设计（Design Approach for Real-Time Systems，DARTS）提供了任务结构化标准，辅助人员确定系统中的并发任务，并指导定义任务接口。

（2）基于信息隐藏的设计方法。面向对象（Object Oriented，OO）设计方法将数据和数据上操作封装在对象实体中，对象外界不能够直接对对象内部进行访问和操作，只能通过消息间接访问对象，符合人类思维方式，提高软件的扩展性、维护性和重用性。

（3）基于模型驱动开发的设计方法。通过借助有效的（Model Driven Development，MDD）工具，构建和维护复杂系统的设计模型，直接产生高质量的代码，将开发的重心从编码转移到设计。当前使用较为广泛的MDD工具有IBM公司的Rhapsody。

软件设计阶段

从工程管理角度来看，软件设计可分为概要设计和详细设计两个阶段。

概要设计

概要设计也称为高层设计，即将软件需求转化为数据结构和软件的系统结构。例如，如果采用结构化设计，则从宏观的角度将软件划分成各个组成模块，并确定模块的功能及模块之间的调用关系。

概要设计主要包括设计软件的结构、确定系统由哪些模块组成，以及每个模块之间的关系。它采用的是结构图（包括模块、调用和数据）来描述程序的结构，还可以使用层次图和HIPO（层次图加输入／处理／输出图）。整个过程主要包括复查基本系统模型、复查并精化数据流图、确定数据流图的信息流类型（包括交换流和事务流）、根据流类型分别实施变换分析或事务分析，以及根据软件设计原则对得到的软件结构图进一步进行优化。

详细设计

详细设计也称为低层设计，即对结构图进行细化，得到详细的数据结构与算法。同样，如果采用结构化设计，则详细设计的任务就是为每个模块进行设计。

详细设计确定应该如何具体地实现所要求的系统，得出对目标系统的精确描述。它采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构。经常使用的工具包括程序流程图、盒图、PAD图（问题分析图）及PDL（伪码）。

总的来说，在整个软件设计过程中，需完成以下工作任务。

（1）制定规范，作为设计的共同标准。

（2）完成软件系统结构的总体设计，将复杂系统按功能划分为模块的层次结构，然后确定模块的功能，以及模块间的调用关系和组成关系。

（3）设计处理方式，包括算法、性能、周转时间、响应时间、吞吐量和精度等。

（4）设计数据结构。

（5）可靠性设计。

（6）编写设计文档，包括概要设计说明书、详细设计说明书、数据库设计说明书、用户手册和初步的测试计划等。

（7）设计评审，主要是对设计文档进行评审。

在设计阶段，必须根据要解决的问题做出设计的选择。例如，半结构化决策问题就适合由交互式计算机软件来解决。

设计阶段

设计阶段监理进行质量控制的要点如下。

（1）了解建设单位的建设需求和对信息系统安全性的要求，协助建设单位制定项目质量目标规划和安全目标规划。

（2）对各种设计文件提出设计质量标准。

（3）进行设计过程跟踪，及时发现质量问题，并及时与承建单位协调解决。审查阶段性成果，并提出监理意见。审查承建单位提交的总体设计方案，审查承建单位对关键部位的测试方案。

（4）协助承建单位建立质量保障体系。

（5）协助承建单位完善现场质量管理制度。

（6）组织设计文件及设计方案交底会，制定质量要求标准。

题号导航 2010年下半年软件评测师上午试卷综合知识

本试卷我的完整做题情况



	第9题在手机中做本题