1.
2.
3.
4.
5.
6.
7.
8.
9. 软件的开发与运行经常受到硬件的限制和制约。(√) 模块内的高内聚往往意味着模块间的松耦合。(√ ) 软件的质量好坏主要由验收人员负责，其他开发人员不必关心。(X ) 判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖。(√) 应该尽量使用机器语言编写代码，提高程序运行效率，而减少高级语言的使用。(X) UML只能应用于软件系统模型的建立。(X) 软件测试的目的是为了无一遗漏的找出所有的错误。(X) 用户对软件需求的描述不精确，往往是产生软件危机的原因之一。（√） 目前，软件项目的进度安排的两种比较常用的方法是程序评估与审查技术（PERT）
和关键路径法（CPM）。（√）
10. 一个好的开发人员应具备的素质和能力包括善于与周围人员团结协作，建立良好的
人际关系，善于听取别人的意见。（√）
11. 目前的绝大多数软件都不适合于快速原型技术。（X）
12. 面向数据的设计方法适用场合是具有明显的层次信息结构的应用如：企事业的信息
管理系统；系统软件（如操作系统）等。（√）
13. 缺乏处理大型软件项目的经验。是产生软件危机的唯一原因。（X）
14. 测试计划、测试用例、出错统计和有关的分析报告一般不用长期保存。（X）
15. 软件也会磨损和老化。（X）
16. 完善性维护是提高或完善软件的性能。（√）
17. 缺乏有力的方法学的指导和有效的开发工具的支持， 这往往是产生软件危机的原
因之一。（√）
18. 一个好的开发人员应具备的素质和能力不包括具有良好的书面和口头表达能力。（X）
19. 在用户需求分析时观察用户手工操作过程不是为了模拟手工操作过程，而是为了获
取第一手资料，并从中提取出有价值的需求。（√）
20. 快速原型技术适用于软件产品要求大量的用户交互、或产生大量的可视输出、或设
计一些复杂的算法等场合。（√）
21. 流程图也称为程序（框图）是最常用的一种表示法。（√）
22. 面向数据设计方法一般都包括下列任务：确定数据结构特征；用顺序、选择和重复
三种基本形式表示数据等步骤。（√）
23. 理想的人机界面应针对具有典型个性的特定的一类用户设计。（√）
24. 数据输入的一般准则中包括尽量（增加）用户输入的动作。（X）
25. 用穷举测试是较现实的测试方法。（X）
26. 编码时应尽可能使用全局变量（X）
27. 重视程序结构的设计，能使程序具有较好的层次结构（√）
28. 程序中的注解越少越好（ X ）。
29. 文档可用于专业人员和用户之间的通信和交流；软件开发过程的管理； 运行阶段
的维护。（√）
30. 软件开发、设计几乎都是从头开始，成本和进度很难估计。（√）
31. 适应性维护是改进软件未来的可维护性和可靠性。（X）
32. 由于软件是逻辑产品，软件质量较容易直接度量。（X）
33. 按照功能，软部件可划分为系统软件和应用软件两类。（√）
34. 如果某子功能可以用一段简洁、精确的文字描述清楚，就无需进一步分解，是创建
用户需求的数据流模型应遵循的规则。（√）
35. 耦合度是对软件结构中模块间关联程度的一种度量。在设计软件时应追求尽可能紧
密的耦合的系统。（X）
36. 在面向对象设计阶段则着重完成“如何做”的问题，也就是着重考虑对象的实现细节。
（√）
37. 随着软件复杂性的不断提高，软件的维护难度越来越大。（√）
38. 软件的可维护性差是软件维护工作量和费用激增的直接原因。（√）
39. 纠错性维护是改正运行期间发现的潜伏错误。（√）
40. 软件可移植性（portability），是指软件从一个计算机系统或（环境）移植到另
一个上去的难易程度。（√）
41. 软件复杂性不能反映出软件的可理解性、模块化、简单性等属性。（X）
42. 当程序内的分支数和循环数增加时，V（G）值将随之增加，即程序的复杂性增大。
（√）
43. 一般来说，设计软件时应尽量使用数据耦合，减少控制耦合，限制外部环境耦合和
公共数据耦合，杜绝内容耦合。（√）
44. 编码的依据是详细设计说明书。（√）
45. 程序文档应该包括代码的功能、代码的完成者等内容。（√）
46. 预防性维护是修改软件，以适应软硬件环境的变化。（X）
47. 开发大型软件易产生疏漏和错误，往往是产生软件危机的原因之一。（√）
48. 据统计，软件维护人员为了分析和理解原软件系统所花费的工作量约占整个维护工
作量的60%以下。（X）
49. 最高耦合度是数据耦合。（X）
50. 人机界面（Human-Computer Interface，简称HCI）又称人- 机接口或用户界面。
（√）
51. 在同一用户界面中，所有的菜单选择、命令输入、数据显示和其他功能应采用不同
的形式和风格。（X）
52. 判定覆盖必然满足语句覆盖。（√）
53. 为提高可交互性一般对大多数操作动作应允许用户恢复。同时应尽量减少用户记忆
的信息量。（√）
54. 编程中应采用统一的标准和约定，降低程序的复杂性。（√）
55. 软件在使用过程中维护不十分复杂。(X)
56. 软件可重用性（reusability），是指软部件可以在多种场合使用的程度。(√)
57. 软件工程学只有理论意义，没有实际用途。 （×）
58. 软件工程的方法只适用于大型软件的开发，对小型软件的开发没有帮助。（×）
59. 可行性研究进一步研究问题分析阶段所确定的问题是否有可行的解。（√）
60. 代码审查方法没有计算机测试方法好 （×）
61. 验证软件需求的方法主要靠人工审查的方法。 （√）
62. 并发系统中遇到的一个主要问题是定时问题。 （√）
63. 编码风格由个人喜好决定，没有固定格式。 （×）
64. 面向对象建模得到的模型包含系统的3个要素，即静态结构、交互次序和数据变换。
（√）
65. 软件重用是提高软件开发生产率和目标系统质量的重要途径。
（√）
66. 判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖。 （√）
67. Power Designer是一个CASE工具。 （√）
68. 软件是指用程序设计语言（如Pascal，C，Visual Basic等）编写的程序，软件开
发实际上就是编写程序代码。（×）
69. 在进行需求分析时需同时考虑维护问题。 （×）
70. UML是一种面向对象的分析设计方法，即OOA/OOD方法。 （×）
71. 在面向对象的软件开发方法中，每个类都存在其相应的对象，对象是类的实例，类
是生成对象的模板。（√）
72. 在可行性研究中最难决断和最关键的问题是经济可行性.(×)
73. 耦合是指一个模块内各个元素彼此结合的紧密程度.(×)
74. 一笔交易,一个动作,甚至操作人员按一个按钮都可以看做是一次事物.(√)
75. 概要设计阶段完成的主要文档是概要设计说明书.(√)
76. 过大的模块可能是由于分解不充分造成的,即使降低模块独立性也必须继续分
解.(×)
77. 程序设计语言中应绝对禁止使用GOTO语句.(×)
78. 类是关于对象性质的描述,由方法和数据组成.(√)
79. 随着软件技术的发展,人们逐渐认识到阅读程序的重要性,编码不仅要强调效率还
要强调清晰.(√)
80. 为保证程序的安全,必须做到程序中没有任何错误存在,即容错.(×)
81. 如果把软件开发所需的资源画成一个金字塔,人是最基本的资源.(√)
82. 软件生存周期是从软件开始开发到开发结束的整个时期。（×）
83. 系统流程图是一个典型的描述逻辑系统的传统工具。（×）
84. 数据流图和数据字典共同构成系统的逻辑模型。（√）
85. 扇出是一个模块直接调用的模块数目，一般推荐的扇出为3或4。（√）
86. 耦合用于衡量一个模块内部的各个元素彼此结合的紧密程度。（×）
87. 程序运行过程中出现错误叫做容错。（×）
88. 软件测试的目的是证明程序没有错误。（×）
89. 白盒测试法是将程序看成一个透明的盒子，不需要了解程序的内部结构和处理过程。
（×）
90. 面向对象设计中的主题相当于子系统。 （×）
91. 模块间的联系越大越好，说明系统各模块间结合的好。 （×）
92. 系统的外部项越少越好，外部项多说明系统独立性差。 （√）
93. 对象中的服务可通过分析属性值的变化情况发现。 （×）
94. 模块的内聚度应尽可能地小。 （×）
95. 通常用数据流图、数据库字典和简明算法描述表示系统的逻辑模型。 （√）
96. Halstead方法是先画出程序图,然后计算程序的环形复杂度。 （√）
97. 在完成测试作业之后，为缩短源程序长度，应删去源程序中的注释。 （√）
98. 测试一般情况下是以白盒法为主黑盒法作为补充。 （×）
99. 概要设计也称总体设计，其过程由确定设计方案和结构设计两个阶段组成。 （√）
1. Halstead方法是先画出程序图,然后计算程序的环形复杂度。 （√）
2. 系统分析阶段和系统设计阶段产生的文档，有的能直接在计算机上执行。 （×）
3. 程序编码在系统分析阶段就可以开始了。 （×）
4. 结构化程序设计SP强调模块采用自上而下逐步求精设计方法，单入口、单出口标准
结构。 （√）
5. 黑盒测试法可有效的检查模块的内部逻辑结构的正确性。 （×）
6. 需求规格说明书是在计划时期可行性研究阶段产生的文档。 （×）
7. 模块间的联系越大越好，说明系统各模块间结合的好。 （×）
8. 测试最终是为了证明程序无错误。 （×）
9. 在完成测试作业之后，为缩短源程序长度，应删去源程序中的注释。 （√）
10. 结构化程序设计SP强调模块采用自上而下逐步求精设计方法，单入口、单出口标准
结构。 （√）
11. 通常用数据流图、数据库字典和简明算法描述表示系统的逻辑模型。 （√）
12. 用于表示模块间调用关系的图是SD。 （×）
13. 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。 （√）
14. 因果图法可以用来系统地设计测试用例。 （√）
15. 结构化程序设计SP强调模块采用自上而下逐步求精设计方法，单入口、单出口标准
结构。 （√）
16. Halstead方法是先画出程序图,然后计算程序的环形复杂度。 （√）
17. 因果图法可以用来系统地设计测试用例。 （√）
18. 概要设计也称总体设计，其过程由确定设计方案和结构设计两个阶段组成。 （√）
19. 用于表示模块间调用关系的图是SD。 （×）
20. 模块的内聚度应尽可能地小，模块间联系尽可能大。 （×）
21. 模块间的联系越大越好，说明系统各模块间结合的好。 （×）
22. 黑盒测试法可有效的检查模块的内部逻辑结构的正确性。 （×）
23. 概要设计也称总体设计，其过程由确定设计方案和结构设计两个阶段组成。 （√）
24. 一个软件系统中可能会出现所有模块之间没有任何联系的情况。 （×）
25. 测试最终是为了证明程序无错误。 （×）
26. 需求规格说明书是在计划时期可行性研究阶段产生的文档。 （×）
27. 对象表示中的服务可通过状态模型对其属性值的分析来发现。 （×）
28. 模块的内聚度应尽可能地小。 （×）
29. Halstead方法是先画出程序图,然后计算程序的环形复杂度。 （√）
30. 为了确认用户的需求，先做出系统的主要部分，提交用户试用的软件开发方法是原
型法。 （√）
31. 程序编码在系统分析阶段就可以开始了。 （×）
32. 用于表示模块间调用关系的图是SD。 （×）
33. 为了确认用户的需求，先做出系统的主要部分，提交用户试用的软件开发方法是原
型法。 （√）
34. 系统的外部项越少越好，外部项多说明系统独立性差。 （√）
35. 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。 （√）
36. 结构化程序设计SP强调模块采用自上而下逐步求精设计方法，单入口、单出口标准
结构。 （√）
37. 对象中的服务可通过分析属性值的变化情况发现。 （×）
38. 需求规格说明书是在计划时期可行性研究阶段产生的文档。 （×）
39. 开发软件就是编写程序。（×）
40. 系统测试的主要方法是白盒法，主要进行功能测试、性能测试、安全性测试及可靠
性等 测试。 （×）
41. 编程序时应尽可能利用硬件特点以提高程序效率. （×）
42. 软件需求分析的任务是建立软件模块结构图。 （×）
43. 尽可能使用高级语言编写程序（√）
44. 以结构化分析方法建立的系统模型就是数据流图。 （×）
45. 进行总体设计时加强模块间的联系。 （×）
46. 编码时尽量多用全局变量.（×）
47. 用CASE环境或程序自动生成工具来自动生成一部分程序.（√）
48. 软件测试是要发现软件中的所有错误。（×）
49. 质量保证是为了保证产品和服务充分满足消费者要求的质量而进行的有计划,有组
织的活动. （√）
50. C语言是一种系统实现语言，也是一种结构化程序设计语言。（√）
51. 功能性注释嵌在源程序体中，用以解释下面的程序语句怎么做。（√）
52. 好的测试是用少量的测试用例运行程序，发现被测程序尽可能多的错误。（√）
53. 在程序调试时，找出错误的位置和性质比改正该错误更难。（√）
54. 黑盒测试仅与程序的内部结构有关，完全可以不考虑程序的功能要求。（×）
55. 模块越小，模块化的优点越明显。一般来说，模块的大小都在10行以下。（√）
56. 输入/输出风格是在软件需求分析和设计阶段建立的，而不是在编码阶段建立的。
（√）
57. 需求是变化的，因为软件是灵活的，总可以满足需求。（×）
58. 测试只能证明程序有错误，不能证明程序没有错误。（√）
1.
2.
3.
4.
5.
6.
7.
8.
9. 软件的开发与运行经常受到硬件的限制和制约。(√) 模块内的高内聚往往意味着模块间的松耦合。(√ ) 软件的质量好坏主要由验收人员负责，其他开发人员不必关心。(X ) 判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖。(√) 应该尽量使用机器语言编写代码，提高程序运行效率，而减少高级语言的使用。(X) UML只能应用于软件系统模型的建立。(X) 软件测试的目的是为了无一遗漏的找出所有的错误。(X) 用户对软件需求的描述不精确，往往是产生软件危机的原因之一。（√） 目前，软件项目的进度安排的两种比较常用的方法是程序评估与审查技术（PERT）
和关键路径法（CPM）。（√）
10. 一个好的开发人员应具备的素质和能力包括善于与周围人员团结协作，建立良好的
人际关系，善于听取别人的意见。（√）
11. 目前的绝大多数软件都不适合于快速原型技术。（X）
12. 面向数据的设计方法适用场合是具有明显的层次信息结构的应用如：企事业的信息
管理系统；系统软件（如操作系统）等。（√）
13. 缺乏处理大型软件项目的经验。是产生软件危机的唯一原因。（X）
14. 测试计划、测试用例、出错统计和有关的分析报告一般不用长期保存。（X）
15. 软件也会磨损和老化。（X）
16. 完善性维护是提高或完善软件的性能。（√）
17. 缺乏有力的方法学的指导和有效的开发工具的支持， 这往往是产生软件危机的原
因之一。（√）
18. 一个好的开发人员应具备的素质和能力不包括具有良好的书面和口头表达能力。（X）
19. 在用户需求分析时观察用户手工操作过程不是为了模拟手工操作过程，而是为了获
取第一手资料，并从中提取出有价值的需求。（√）
20. 快速原型技术适用于软件产品要求大量的用户交互、或产生大量的可视输出、或设
计一些复杂的算法等场合。（√）
21. 流程图也称为程序（框图）是最常用的一种表示法。（√）
22. 面向数据设计方法一般都包括下列任务：确定数据结构特征；用顺序、选择和重复
三种基本形式表示数据等步骤。（√）
23. 理想的人机界面应针对具有典型个性的特定的一类用户设计。（√）
24. 数据输入的一般准则中包括尽量（增加）用户输入的动作。（X）
25. 用穷举测试是较现实的测试方法。（X）
26. 编码时应尽可能使用全局变量（X）
27. 重视程序结构的设计，能使程序具有较好的层次结构（√）
28. 程序中的注解越少越好（ X ）。
29. 文档可用于专业人员和用户之间的通信和交流；软件开发过程的管理； 运行阶段
的维护。（√）
30. 软件开发、设计几乎都是从头开始，成本和进度很难估计。（√）
31. 适应性维护是改进软件未来的可维护性和可靠性。（X）
32. 由于软件是逻辑产品，软件质量较容易直接度量。（X）
33. 按照功能，软部件可划分为系统软件和应用软件两类。（√）
34. 如果某子功能可以用一段简洁、精确的文字描述清楚，就无需进一步分解，是创建
用户需求的数据流模型应遵循的规则。（√）
35. 耦合度是对软件结构中模块间关联程度的一种度量。在设计软件时应追求尽可能紧
密的耦合的系统。（X）
36. 在面向对象设计阶段则着重完成“如何做”的问题，也就是着重考虑对象的实现细节。
（√）
37. 随着软件复杂性的不断提高，软件的维护难度越来越大。（√）
38. 软件的可维护性差是软件维护工作量和费用激增的直接原因。（√）
39. 纠错性维护是改正运行期间发现的潜伏错误。（√）
40. 软件可移植性（portability），是指软件从一个计算机系统或（环境）移植到另
一个上去的难易程度。（√）
41. 软件复杂性不能反映出软件的可理解性、模块化、简单性等属性。（X）
42. 当程序内的分支数和循环数增加时，V（G）值将随之增加，即程序的复杂性增大。
（√）
43. 一般来说，设计软件时应尽量使用数据耦合，减少控制耦合，限制外部环境耦合和
公共数据耦合，杜绝内容耦合。（√）
44. 编码的依据是详细设计说明书。（√）
45. 程序文档应该包括代码的功能、代码的完成者等内容。（√）
46. 预防性维护是修改软件，以适应软硬件环境的变化。（X）
47. 开发大型软件易产生疏漏和错误，往往是产生软件危机的原因之一。（√）
48. 据统计，软件维护人员为了分析和理解原软件系统所花费的工作量约占整个维护工
作量的60%以下。（X）
49. 最高耦合度是数据耦合。（X）
50. 人机界面（Human-Computer Interface，简称HCI）又称人- 机接口或用户界面。
（√）
51. 在同一用户界面中，所有的菜单选择、命令输入、数据显示和其他功能应采用不同
的形式和风格。（X）
52. 判定覆盖必然满足语句覆盖。（√）
53. 为提高可交互性一般对大多数操作动作应允许用户恢复。同时应尽量减少用户记忆
的信息量。（√）
54. 编程中应采用统一的标准和约定，降低程序的复杂性。（√）
55. 软件在使用过程中维护不十分复杂。(X)
56. 软件可重用性（reusability），是指软部件可以在多种场合使用的程度。(√)
57. 软件工程学只有理论意义，没有实际用途。 （×）
58. 软件工程的方法只适用于大型软件的开发，对小型软件的开发没有帮助。（×）
59. 可行性研究进一步研究问题分析阶段所确定的问题是否有可行的解。（√）
60. 代码审查方法没有计算机测试方法好 （×）
61. 验证软件需求的方法主要靠人工审查的方法。 （√）
62. 并发系统中遇到的一个主要问题是定时问题。 （√）
63. 编码风格由个人喜好决定，没有固定格式。 （×）
64. 面向对象建模得到的模型包含系统的3个要素，即静态结构、交互次序和数据变换。
（√）
65. 软件重用是提高软件开发生产率和目标系统质量的重要途径。
（√）
66. 判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖。 （√）
67. Power Designer是一个CASE工具。 （√）
68. 软件是指用程序设计语言（如Pascal，C，Visual Basic等）编写的程序，软件开
发实际上就是编写程序代码。（×）
69. 在进行需求分析时需同时考虑维护问题。 （×）
70. UML是一种面向对象的分析设计方法，即OOA/OOD方法。 （×）
71. 在面向对象的软件开发方法中，每个类都存在其相应的对象，对象是类的实例，类
是生成对象的模板。（√）
72. 在可行性研究中最难决断和最关键的问题是经济可行性.(×)
73. 耦合是指一个模块内各个元素彼此结合的紧密程度.(×)
74. 一笔交易,一个动作,甚至操作人员按一个按钮都可以看做是一次事物.(√)
75. 概要设计阶段完成的主要文档是概要设计说明书.(√)
76. 过大的模块可能是由于分解不充分造成的,即使降低模块独立性也必须继续分
解.(×)
77. 程序设计语言中应绝对禁止使用GOTO语句.(×)
78. 类是关于对象性质的描述,由方法和数据组成.(√)
79. 随着软件技术的发展,人们逐渐认识到阅读程序的重要性,编码不仅要强调效率还
要强调清晰.(√)
80. 为保证程序的安全,必须做到程序中没有任何错误存在,即容错.(×)
81. 如果把软件开发所需的资源画成一个金字塔,人是最基本的资源.(√)
82. 软件生存周期是从软件开始开发到开发结束的整个时期。（×）
83. 系统流程图是一个典型的描述逻辑系统的传统工具。（×）
84. 数据流图和数据字典共同构成系统的逻辑模型。（√）
85. 扇出是一个模块直接调用的模块数目，一般推荐的扇出为3或4。（√）
86. 耦合用于衡量一个模块内部的各个元素彼此结合的紧密程度。（×）
87. 程序运行过程中出现错误叫做容错。（×）
88. 软件测试的目的是证明程序没有错误。（×）
89. 白盒测试法是将程序看成一个透明的盒子，不需要了解程序的内部结构和处理过程。
（×）
90. 面向对象设计中的主题相当于子系统。 （×）
91. 模块间的联系越大越好，说明系统各模块间结合的好。 （×）
92. 系统的外部项越少越好，外部项多说明系统独立性差。 （√）
93. 对象中的服务可通过分析属性值的变化情况发现。 （×）
94. 模块的内聚度应尽可能地小。 （×）
95. 通常用数据流图、数据库字典和简明算法描述表示系统的逻辑模型。 （√）
96. Halstead方法是先画出程序图,然后计算程序的环形复杂度。 （√）
97. 在完成测试作业之后，为缩短源程序长度，应删去源程序中的注释。 （√）
98. 测试一般情况下是以白盒法为主黑盒法作为补充。 （×）
99. 概要设计也称总体设计，其过程由确定设计方案和结构设计两个阶段组成。 （√）
1. Halstead方法是先画出程序图,然后计算程序的环形复杂度。 （√）
2. 系统分析阶段和系统设计阶段产生的文档，有的能直接在计算机上执行。 （×）
3. 程序编码在系统分析阶段就可以开始了。 （×）
4. 结构化程序设计SP强调模块采用自上而下逐步求精设计方法，单入口、单出口标准
结构。 （√）
5. 黑盒测试法可有效的检查模块的内部逻辑结构的正确性。 （×）
6. 需求规格说明书是在计划时期可行性研究阶段产生的文档。 （×）
7. 模块间的联系越大越好，说明系统各模块间结合的好。 （×）
8. 测试最终是为了证明程序无错误。 （×）
9. 在完成测试作业之后，为缩短源程序长度，应删去源程序中的注释。 （√）
10. 结构化程序设计SP强调模块采用自上而下逐步求精设计方法，单入口、单出口标准
结构。 （√）
11. 通常用数据流图、数据库字典和简明算法描述表示系统的逻辑模型。 （√）
12. 用于表示模块间调用关系的图是SD。 （×）
13. 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。 （√）
14. 因果图法可以用来系统地设计测试用例。 （√）
15. 结构化程序设计SP强调模块采用自上而下逐步求精设计方法，单入口、单出口标准
结构。 （√）
16. Halstead方法是先画出程序图,然后计算程序的环形复杂度。 （√）
17. 因果图法可以用来系统地设计测试用例。 （√）
18. 概要设计也称总体设计，其过程由确定设计方案和结构设计两个阶段组成。 （√）
19. 用于表示模块间调用关系的图是SD。 （×）
20. 模块的内聚度应尽可能地小，模块间联系尽可能大。 （×）
21. 模块间的联系越大越好，说明系统各模块间结合的好。 （×）
22. 黑盒测试法可有效的检查模块的内部逻辑结构的正确性。 （×）
23. 概要设计也称总体设计，其过程由确定设计方案和结构设计两个阶段组成。 （√）
24. 一个软件系统中可能会出现所有模块之间没有任何联系的情况。 （×）
25. 测试最终是为了证明程序无错误。 （×）
26. 需求规格说明书是在计划时期可行性研究阶段产生的文档。 （×）
27. 对象表示中的服务可通过状态模型对其属性值的分析来发现。 （×）
28. 模块的内聚度应尽可能地小。 （×）
29. Halstead方法是先画出程序图,然后计算程序的环形复杂度。 （√）
30. 为了确认用户的需求，先做出系统的主要部分，提交用户试用的软件开发方法是原
型法。 （√）
31. 程序编码在系统分析阶段就可以开始了。 （×）
32. 用于表示模块间调用关系的图是SD。 （×）
33. 为了确认用户的需求，先做出系统的主要部分，提交用户试用的软件开发方法是原
型法。 （√）
34. 系统的外部项越少越好，外部项多说明系统独立性差。 （√）
35. 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。 （√）
36. 结构化程序设计SP强调模块采用自上而下逐步求精设计方法，单入口、单出口标准
结构。 （√）
37. 对象中的服务可通过分析属性值的变化情况发现。 （×）
38. 需求规格说明书是在计划时期可行性研究阶段产生的文档。 （×）
39. 开发软件就是编写程序。（×）
40. 系统测试的主要方法是白盒法，主要进行功能测试、性能测试、安全性测试及可靠
性等 测试。 （×）
41. 编程序时应尽可能利用硬件特点以提高程序效率. （×）
42. 软件需求分析的任务是建立软件模块结构图。 （×）
43. 尽可能使用高级语言编写程序（√）
44. 以结构化分析方法建立的系统模型就是数据流图。 （×）
45. 进行总体设计时加强模块间的联系。 （×）
46. 编码时尽量多用全局变量.（×）
47. 用CASE环境或程序自动生成工具来自动生成一部分程序.（√）
48. 软件测试是要发现软件中的所有错误。（×）
49. 质量保证是为了保证产品和服务充分满足消费者要求的质量而进行的有计划,有组
织的活动. （√）
50. C语言是一种系统实现语言，也是一种结构化程序设计语言。（√）
51. 功能性注释嵌在源程序体中，用以解释下面的程序语句怎么做。（√）
52. 好的测试是用少量的测试用例运行程序，发现被测程序尽可能多的错误。（√）
53. 在程序调试时，找出错误的位置和性质比改正该错误更难。（√）
54. 黑盒测试仅与程序的内部结构有关，完全可以不考虑程序的功能要求。（×）
55. 模块越小，模块化的优点越明显。一般来说，模块的大小都在10行以下。（√）
56. 输入/输出风格是在软件需求分析和设计阶段建立的，而不是在编码阶段建立的。
（√）
57. 需求是变化的，因为软件是灵活的，总可以满足需求。（×）
58. 测试只能证明程序有错误，不能证明程序没有错误。（√）