软件工程判断题分.doc

1. 软件开发与运行常常受到硬件限制和制约。(√) 
2. 模块内高内聚往往意味着模块间松耦合。(√ )
3. 软件质量好坏关键由验收人员负责, 其她开发人员无须关心。(X ) 
4. 判定覆盖不一定包含条件覆盖, 条件覆盖也不一定包含判定覆盖。(√) 
5. 应该尽可能使用机器语言编写代码, 提升程序运行效率, 而降低高级语言使用。(X) 
6. UML只能应用于软件系统模型建立。(X) 
7. 软件测试目是为了无一遗漏找出全部错误。(X) 
8. 用户对软件需求描述不正确, 往往是产生软件危机原因之一。（√）
9. 现在, 软件项目进度安排两种比较常见方法是程序评定与审查技术（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. 测试只能证实程序有错误, 不能证实程序没有错误。 （√）