【计算机类职业资格】系统分析师-软件工程(四)及答案解析.doc

《【计算机类职业资格】系统分析师-软件工程(四)及答案解析.doc》由会员分享，可在线阅读，更多相关《【计算机类职业资格】系统分析师-软件工程(四)及答案解析.doc（25页珍藏版）》请在麦多课文档分享上搜索。

1、系统分析师-软件工程(四)及答案解析(总分：49.00，做题时间：90 分钟)净室软件工程(Cleanroom)是软件开发的一种形式化方法，可以开发较高质量的软件。它使用 (91) 进行分析和建模，并且将 (92) 作为发现和排除错误的主要机制。使用 (93) 测试来获取认证软件可靠性所需要的信息。（分数：3.00）(1).A产生式归约 B移进归约 C盒结构归约 D规范归约（分数：1.00）A.B.C.D.(2).A正确性验证 B黑白盒测试C集成测试 D基本路径测试（分数：1.00）A.B.C.D.(3).A边界值 B统计 C代数 D精确（分数：1.00）A.B.C.D.1.基线是软件生存期各

2、个开发阶段的工作成果，测试阶段的基线是 (140) 。A可提交的软件 B被测试的程序C提交报告 D测试报告（分数：1.00）A.B.C.D.2.使用自动项目管理工具与使用手工方法管理相比有许多优点，但是 (124) 不属于自动项目管理工具的优点。A能对大型项目进行精确跟踪，使项目经理能及时掌握实际工作进展和资源的实际消耗情况B能指导设计人员采用软件生存周期各阶段的适用技术，进行设计和控制工程进度C能辅助开发 PERT、CPM(关键路径方法)和 WBS(工作分解结构)，自动更新活动网络图和 Gantte 图D能自动计算、自动积累数据、自动生成图形和报表来取代人工计算、调度、统计和文档工作，提高管

3、理工作效率。（分数：1.00）A.B.C.D.3.软件的分层式体系结构把软件系统划分为 4 层，这 4 层结构自顶向下分别是 (143) 。A应用软件业务构件中间件系统软件B业务构件应用软件中间件系统软件C应用软件中间件系统软件业务构件D业务构件中间件应用软件系统软件（分数：1.00）A.B.C.D.4.有两种需求定义的方法严格定义和原型定义，在关于这两种方法的描述中，不正确的是 (142) 。A严格定义方法假定所有的需求都可以预先定义B严格定义方法假定软件开发人员与用户之间的沟通存在障碍C原型定义方法认为需求分析中不可避免地要出现很多反复D原型定义方法强调用户在软件开发过程中的参与和决策（分

4、数：1.00）A.B.C.D.5.风险的成本估算完成后，可以针对风险表中的每个风险计算其风险曝光度。某软件小组计划项日中采用50 个可复用的构件，每个构件平均是 100LOC，本地每个 LOC 的成本是 13 元人民币。下面是该小组定义的一个项目风险：1风险识别：预定要复用的软件构件中只有 50%将被集成到应用中，剩余功能必须定制开发；2风险概率：60%；3该项目风险的风险曝光度是 (145) 。A32500 B65000 C1500 D19500（分数：1.00）A.B.C.D.6.为了使构件系统更切合实际、更有效地被复用，构件应当具备 (136) ，以提高其通用性。A可继承性 B可变性C可

5、封装性 D可伸缩性（分数：1.00）A.B.C.D.评价软件的质量通常可以从产品运行、产品修改和产品转移三个不同角度来进行。除了软件应满足产品规格说明的正确性和保证运行效率以外， (52) 和 (53) 也是产品运行期间影响软件质量的两个质量因素，其中 (52) 是指在遇到意外时系统能做出适应反应的程度。可维护性是影响产品修改的一个质量因素，它主要包括可理解性、可修改性和 (54) 。一般认为， (55) 是影响产品转移的一个质量因素。为了保证软件质量，在开发过程的各阶段进行 (56) 是一个重要的手段。（分数：5.00）(1).A灵活性 B可重用性 C适应性D健壮性（分数：1.00）A.B.

6、C.D.(2).A灵活性 B可重用性 C适应性D可用性（分数：1.00）A.B.C.D.(3).A可测试性 B可移植性 C适应性 D健壮性（分数：1.00）A.B.C.D.(4).A灵活性 B可重用性 C完整性 D安全性（分数：1.00）A.B.C.D.(5).A验收测试 B用户培训 C软件评审 D文件修改（分数：1.00）A.B.C.D.对软件开发的看法可有多种观点，敏捷软件开发方法是一种 (118) ，代表性是极限编程 XP，它的核心思想为 (119) 。（分数：2.00）(1).A数学观 B建模观C工程观 D协作游戏（分数：1.00）A.B.C.D.(2).A强调文档和以敏捷性应对变化B

7、强调建模和以敏捷性应对变化C强调设计和以敏捷性应对变化D强调人和人之间的合作的因素和以敏捷性应对变化（分数：1.00）A.B.C.D.7.软件项目管理中可以使用各种图形工具，在以下关于各种图形工具的论述中正确的是 (117) 。A流程图直观地描述了工作过程的具体步骤，以及这些步骤之间的时序关系，可以用于控制工作过程的完成时间。BPERT 图画出了项目中各个活动之间的时序关系，可用于计算工程项目的关键路径，以便控制项目的进度。C因果分析图能表现出软件过程中各种原因和效果之间的关系，并且表现了它们随时间出现的顺序和重要程度，这些数据可用于改进软件过程的性能。DGantte 图为整个项目建立了一个时

8、间表，反映了项目中的所有任务之间的依赖关系以及各个任务的起止日期，这些信息可用于项目的任务调度。（分数：1.00）A.B.C.D.风险分析和管理是软件开发的一项重要活动。在软件工程领域考虑风险时，主要基于以下三个概念： (82) 以及必须抓住选择机会。实践中存在许多种软件风险，如“潜在的设计、实现、维护等方面的问题”属于 (83) 风险；“开发了一个没有人真正需要的优秀产品”属于 (84) 风险；“开发的产品不再符合公司的整体商业策略”属于 (85) 风险。通常在软件项目开发过程中，我们希望首先实现 (86) 的用例。（分数：5.00）(1).A关心当前，关心变化 B关心当前，关心不变性C关心

9、未来，关心变化 D关心未来，关心不变性（分数：1.00）A.B.C.D.(2).A技术 B过程 C项目 D商业（分数：1.00）A.B.C.D.(3).A技术 B过程 C项目 D商业（分数：1.00）A.B.C.D.(4).A技术 B过程 C项目 D商业（分数：1.00）A.B.C.D.(5).A风险最小 B风险最大 C风险中等 D任意风险（分数：1.00）A.B.C.D.8.结构模板能够帮助分析员建立一个逐层细化的层次结构。结构环境图 (Architecture Context Diagram，ACD)则位于层次结构的顶层。在从 ACD 导出的 (146) 中给出了各个专门子系统和重要(数据

10、与控制)信息流。A系统语境图(SCD) B结构互连图(AID)C结构流程图(AFD) D结构图的规格说明(ADS)（分数：1.00）A.B.C.D.9.系统开发过程的流程如图 9-5 所示， (11) 阶段拟定了系统的目标、范围和要求。（分数：1.00）A.B.C.D.在业务领域分析过程中，通过建立实体关系图，把与业务相关的数据模型化：通过建立 (26) 来表示业务活动的分解过程；两个业务过程之间的相互依赖关系应记录在过程依赖图中；通过建立 (27) 来详细说明整个业务过程的逻辑。（分数：2.00）(1).A数据流图(DFD) B过程层次图(PHD)C过程活动图(PAD) D过程关系图(PRD

11、)（分数：1.00）A.B.C.D.(2).A数据流图(DFD) B过程层次图(PHD)C过程活动图(PAD) D甘特图(Gaotte)（分数：1.00）A.B.C.D.软件测试通常可分为单元测试、集成测试、确认测试和系统测试，其中确认测试主要用于发现 (44) 阶段的错误。在集成测试时，通常可采用自顶向下增殖式集成和自底向上增殖式集成。在自底向上增殖式集成时，对每个被集成的模块 (45) 。对那些为众多用户开发的软件(如操作系统、编译程序)，通常还要进行 测试和 测试，以发现可能只有最终用户才能发现的错误。其中， 测试是指晕终用户在 (46) 的情况下所进行的测试， 测试是指最终用户在 (4

12、7) 的情况下所进行的测试。在软件维护阶段，当修改软件后，除了进行常规的测试外，还应进行 (48) 测试。（分数：5.00）(1).A需求分析 B概要设计 C详细设计 D编码（分数：1.00）A.B.C.D.(2).A不必设计驱动模块和桩(stub)模块B不必设计驱动模块，但要设计桩模块C要设计驱动模块，但不必设计桩模块D要设计驱动模块和桩模块（分数：1.00）A.B.C.D.(3).A开发环境下，开发人员不在场B开发环境下，开发人员在场C用户的实际使用环境下，开发人员不在场D用户的实际使用环境下，开发人员在场（分数：1.00）A.B.C.D.(4).A开发环境下，开发人员不在场B开发环境下，

13、开发人员在场C用户的实际使用环境下，开发人员不在场D用户的实际使用环境下，开发人员在场（分数：1.00）A.B.C.D.(5).A恢复 B强度 C安装 D回归（分数：1.00）A.B.C.D.10.COCOMO 模型能够依据待开发软件的规模来估计软件开发的工期。若 COCOMO 模型公式为：MM=3.0(KDSI)其中，KDSI 为预计应交付的源程序千行数，MM 为开发该软件所需的人月数。设软件开发的生产率为每个人月能编写的最终能交付的源程序千行数 (KDSI/MM)，则根据上述 COCOMO 模型可以看出，软件开发的生产率随软件开发规模而变化的趋势如图 (138) 所示。（分数：1.00）A

14、.B.C.D.软件方法学是以软件方法为研究对象的学科。从开发风范上看，可分为 (99) 。从性质上看，可分为 (100) 。从适应范围来看，可分为 (101) 。形式方法的目的是把软件作为数学来重新发现。形式方法被用来避免系统中的 (102) 、不一致性。软件自动化方法是指利用计算机使软件的设计实现自动化的方法和相关的技术。软件自动化的实现途径有四种：过程途径、归纳途径、 (103) 。（分数：5.00）(1).A整体性方法与局部性方法B面向对象开发方法与结构化开发方法C面向对象开发方法与非形式方法D形式方法与非形式方法（分数：1.00）A.B.C.D.(2).A歧义性、不完全性 B歧义性、不

15、安全性C歧义性、不适应性 D歧义性、不可靠性（分数：1.00）A.B.C.D.(3).A演绎途径、编译途径 B转换途径、编译途径C编译途径、解释途径 D演绎途径、转换途径（分数：1.00）A.B.C.D.(4).A面向对象开发方法与自底向上的开发方法B自顶向下的开发方法与结构化开发方法C面向对象开发方法与结构化开发方法D自顶向下的开发方法与自底向上的开发方法（分数：1.00）A.B.C.D.(5).A面向对象开发方法与形式方法B面向对象开发方法与结构化开发方法C形式方法与非形式方法D面向对象开发方法与非形式方法（分数：1.00）A.B.C.D.在下面所列举的逻辑测试覆盖中，测试覆盖最强的是 (

16、38) ，最弱的是 (39) 。软件测试工具有多种，其中 (40) 对源程序的数据流和控制流进行分析，发现语义错误： (41) 通过对程序的执行流进行探测，检查有关变量的逻辑值。在下面的个人所得税程序中满足语句覆盖测试用例的是 (42) ，满足判定覆盖测试的用例是 (43) 。if (income800) taxrate=0；else if (income1500) taxrate0.05；else if (income2000) taxrate0.08：else taxrate0.1；（分数：6.00）(1).A条件覆盖 B条件组合覆盖C语句覆盖 D条件及判定覆盖（分数：1.00）A.B.C

17、.D.(2).A条件覆盖 B条件组合覆盖C语句覆盖 D条件及判定覆盖（分数：1.00）A.B.C.D.(3).A动态分析工具 B静态分析工具C模拟工具 D测试管理工具（分数：1.00）A.B.C.D.(4).A动态分析工具 B静态分析工具C模拟工具 D测试管理工具（分数：1.00）A.B.C.D.(5).Aincome=(800，1500，2000，2001)BIncome=(800，801，1999，2000)Cincome=(799，1499，2000，2001)Dincome=(799，1500，1999，2000)（分数：1.00）A.B.C.D.(6).Aincome=(799，15

18、00，1999，2001)Bincome=(799，1501，2000，2001)Cincome=(800，1500，2000，2001)Dincome=(800，1499，2000，2001)（分数：1.00）A.B.C.D.软件测试是为了发现错误而执行程序的过程。检验软件是否满足用户需求的测试称为 (114) 。 (115) 是维护中常用的方法，其目的是检验修改所引起的副作用。黑盒测试法主要根据 (116) 来设计测试用例。（分数：3.00）(1).A确认测试 B有效性测试C系统测试 D集成测试（分数：1.00）A.B.C.D.(2).A回归测试 B模块测试C功能测试 D结构测试（分数：1

19、.00）A.B.C.D.(3).A程序数据结构 B程序流程图C程序内部逻辑 D程序外部功能（分数：1.00）A.B.C.D.11.质量控制非常重要，但是进行质量控制也需要一定的成本。 (131) 可以降低质量控制的成本。A使用抽样统计 B进行过程分析C对全程进行监督 D进行质量审计（分数：1.00）A.B.C.D.多个软件工程师合作开发一个项目，各开发者之间需要两两互相通信。假设每一条通信路径的开销为200LOC/年(LOC 为代码行数)。设有 4 名软件工程师，如果单独工作，每个人的生产率是 6000 LOC/年，那么由这 4 名软件工程师组成的项目组的生产率为 (89) 。在这一年期限的最

20、后两个月，又增加了两名工程师，新增成员的个人生产率为 3000 LOC/年，那么这 6 人组成的项目组全年完成的开发工作量为 (90) 。（分数：2.00）(1).A28000LOC/年 B24000LOC/年C22800LOC/年 D21500LOC/年（分数：1.00）A.B.C.D.(2).A21000LOC B23000LOCC23500LOC D24500LOC（分数：1.00）A.B.C.D.系统分析师-软件工程(四)答案解析(总分：49.00，做题时间：90 分钟)净室软件工程(Cleanroom)是软件开发的一种形式化方法，可以开发较高质量的软件。它使用 (91) 进行分析和建

21、模，并且将 (92) 作为发现和排除错误的主要机制。使用 (93) 测试来获取认证软件可靠性所需要的信息。（分数：3.00）(1).A产生式归约 B移进归约 C盒结构归约 D规范归约（分数：1.00）A.B.C. D.解析：(2).A正确性验证 B黑白盒测试C集成测试 D基本路径测试（分数：1.00）A. B.C.D.解析：(3).A边界值 B统计 C代数 D精确（分数：1.00）A.B. C.D.解析：解析 净室软件工程是软件开发的一种形式方法，它可以生成质量非常高的软件。它使用盒结构规约(或形式化方法)进行分析和设计建模，并且强调将正确性验证，而不是测试，作为发现和消除错误的主要机制。使用

22、统计的测试来获取认证被交付软件的可靠性所必需的出错率信息。净室方法从使用盒结构表示的分析和设计模型入手，一个“盒”在某特定的抽象层次上封装系统(或系统的某些方面)。黑盒用于表达系统的对外可观测行为，状态盒封装状态数据和操作，清晰盒用于对某状态盒中的数据和操作所蕴涵的过程设计进行建模。一旦完成了盒结构设计，则运用正确性验证。软件构件的过程设计被划分为一系列子函数，为了证明每个子函数的正确性，要为每个函数定义出口条件并实施一组子证明。如果每个出口条件均被满足，则设计一定是正确的。一旦完成了正确性验证，便开始统计的使用测试。和传统测试不同，净室软件工程并不强调单元或集成测试，而是通过定义一组使用场景

23、、确定对每个场景的使用概率及定义符合概率的随机测试来进行软件测试。将产生的错误记录和取样、构件和认证模型相结合使得可以数学地计算软件构件的可靠性。净室哲学是一种严格的软件工程方法，它是一种强调正确性的数学验证和软件可靠性认证的软件过程模型，其目标和结果是非常低的出错率，这是使用非形式化方法难以或不可能达到的。1.基线是软件生存期各个开发阶段的工作成果，测试阶段的基线是 (140) 。A可提交的软件 B被测试的程序C提交报告 D测试报告（分数：1.00）A.B.C.D. 解析：解析 有关基线的概念，请参考试题 24 的分析。一般来说，软件开发各阶段的配置基线如下。(1)计划阶段：开发计划。(2)

24、需求分析阶段：需求规格说明、用户手册。(3)设计阶段；设计规格说明。(4)编码阶段；程序清单。(5)测试阶段：测试报告。2.使用自动项目管理工具与使用手工方法管理相比有许多优点，但是 (124) 不属于自动项目管理工具的优点。A能对大型项目进行精确跟踪，使项目经理能及时掌握实际工作进展和资源的实际消耗情况B能指导设计人员采用软件生存周期各阶段的适用技术，进行设计和控制工程进度C能辅助开发 PERT、CPM(关键路径方法)和 WBS(工作分解结构)，自动更新活动网络图和 Gantte 图D能自动计算、自动积累数据、自动生成图形和报表来取代人工计算、调度、统计和文档工作，提高管理工作效率。（分数：

25、1.00）A.B. C.D.解析：解析 请参考试题 43 的分析。3.软件的分层式体系结构把软件系统划分为 4 层，这 4 层结构自顶向下分别是 (143) 。A应用软件业务构件中间件系统软件B业务构件应用软件中间件系统软件C应用软件中间件系统软件业务构件D业务构件中间件应用软件系统软件（分数：1.00）A. B.C.D.解析：解析 软件的分层式体系结构把软件系统划分为 4 层，这 4 层结构自顶向下分别是应用软件、业务构件、中间件和系统软件。4.有两种需求定义的方法严格定义和原型定义，在关于这两种方法的描述中，不正确的是 (142) 。A严格定义方法假定所有的需求都可以预先定义B严格定义方法

26、假定软件开发人员与用户之间的沟通存在障碍C原型定义方法认为需求分析中不可避免地要出现很多反复D原型定义方法强调用户在软件开发过程中的参与和决策（分数：1.00）A.B. C.D.解析：解析 严格定义(预先定义)是目前采用较多的一种需求定义方法。在采用严格定义的传统的结构化开发方法中，各个工作阶段排列成一个理想的线性开发序列，在每一工作阶段中，都用上一阶段所提供的完整、严格的文档作为指导文件，因此它本质上是一种顺序型的开发方法。在传统的结构化开发中，需求的严格定义建立在以下的基本假设上。(1)所有需求都能够被预先定义假设意味着，在没有实际系统运行经验的情况下，全部的系统需求均可通过逻辑推断得到。

27、这对某些规模较小、功能简单的系统是可能的，但对那些功能庞大、复杂且较大的系统显然是困难的。即使事先做了深入细致的调查和分析，当用户见到新系统的实际效果时，也往往会改变原先的看法，会提出修改或更进一步增加系统功能的要求，所以再好的预先定义技术也会经常反复。这是因为人们对新事物的认识与理解将随着直观、实践的过程进一步加深，这是与人类认识世界的客观规律相一致的。所以，能够预先定义出所有需求的假设在许多场合是不能成立的。(2)开发人员与用户之间能够准确而清晰地交流假设认为，用户与开发人员之间，虽然每人都有自己的专业、观点、行话，但在系统开发过程中可以使用图形/文档等通信工具进行交流，进行清晰、有效的沟

28、通，这种沟通是必不可少的。可是，在实际开发中，往往对一些共同的约定，每个人可能都会产生自己的理解和解释。即使采用结构化语言、判定树、判定表等工具，仍然存在精确的、技术上的不严密感。这将导致人们有意无意地带有个人的不同理解而各行其事，所以在多学科、多行业人员之间进行有效的通信交流是有一定困难的。(3)采用图形/文字可以充分体现最终系统在使用严格定义需求的开发过程中，开发人员与用户之间交流、通信的主要工具是定义报告，包括叙述文字、图形、逻辑规则和数据字典等技术工具。它们都是静止的、被动的，不能实际表演，很难在用户头脑中形成一个具体的形象。因此，要用静止的图形/文字描述来体现一个动态的系统是比较困难

29、的。除了所论述的情况外，上述基本假设还将导致严格定义的结构化开发方法存在以下缺陷。首先是文档量大，由于在结构化方法的每个阶段都必须写出规范、严密的各种文档，这些文档虽然有助于开发人员之间、用户与开发人员间的通信交流，有助于开发过程的规范化，但由于编写文档花费大量人力和时间，导致系统开发周期增大。其次是开发过程可见性差，来自用户的反馈太迟。由于在需求定义、系统设计阶段都不能在用户终端显示新系统的实际效果，一直到系统实现阶段结束，用户才有机会通过对新系统的实际操作和体会来提出他们对新系统的看法和意见，但此时整个开发已近尾声，若想修改前几段的工作或修改需求定义，都将付出较大的代价，有时这种修改甚至会

30、导致整个系统的失败。综上所述，需求的严格定义的基本假设在许多情况下并不成立，传统的结构化方法面临着一些难以跨越的障碍。为此，需要探求一种变通的方法。原型方法以一种与严格定义法截然不同的观点看待需求定义问题。原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始，允许用户在开发过程中提出更好的要求，根据用户的要求不断地对系统进行完善，它实质上是一种迭代的循环型的开发方式。采用原型方法时需要注意的几个问题。(1)并非所有的需求都能在系统开发前被准确地说明。事实上，要想严密、准确地定义任何事情都是有一定难度的，更不用说是定义一个庞大系统的全部需求。用户虽然

31、可以叙述他们所需最终系统的目标及大致功能，但是对某些细节问题却往往不可能十分清楚。一个系统的开发过程，无论对于开发人员还是用户来说，都是一个学习和实践的过程，为了帮助他们在这个过程中提出更完善的需求，最好的方法就是提供现实世界的实例原型，对原型进行研究、实践，并进行评价。(2)项目参加者之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。用户和开发人员通过屏幕、键盘进行对话和讨论、交流，从他们自身的理解出发来测试原型，一个具体的原型系统，由于直观性、动态性而使得项目参加者之间的交流上的困难得到较好的克服。(3)需要实际的、可供用户参与的系统模型。虽然图形和文字描述是一种较好的通信交流工

32、具，但是，其最大缺陷是缺乏直观的、感性的特征，因而不易理解对象的全部含义。交互式的系统原型能够提供生动的规格说明，用户见到的是一个“活”的、实际运行着的系统。实际使用在计算机上运行的系统，显然比理解纸面上的系统要深刻得多。(4)有合适的系统开发环境。随着计算机硬件，软件技术和软件工具的迅速发展，软件的设计与实现工作越来越方便，对系统进行局部性修改甚至重新开发的代价大大降低。所以，对大系统的原型化已经成为可能。(5)反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。对系统改进的建议来自经验的发展，应该鼓励用户改进他们的系统，只有做必要的改变后，才能使用户和系统间获得更加良好的匹配，所

33、以，从某种意义上说，严格定义需求的方法实际上抑制了用户在需求定义以后再改进的要求，这对提高最终系统的质量是有害的。另一方面，原型方法的使用并不排除严格定义方法的运用，当通过原型并在演示中得到明确的需求定义后，应采用行之有效的结构化方法来完成最终系统的开发。5.风险的成本估算完成后，可以针对风险表中的每个风险计算其风险曝光度。某软件小组计划项日中采用50 个可复用的构件，每个构件平均是 100LOC，本地每个 LOC 的成本是 13 元人民币。下面是该小组定义的一个项目风险：1风险识别：预定要复用的软件构件中只有 50%将被集成到应用中，剩余功能必须定制开发；2风险概率：60%；3该项目风险的风

34、险曝光度是 (145) 。A32500 B65000 C1500 D19500（分数：1.00）A.B.C.D. 解析：解析 风险曝光度(riskexposure)的计算公式如下。风险曝光度；错误出现率(风险出现率)错误造成损失(风险损失)在本题中，风险概率为 60%，风险损失为所有构件价格的 50%，因此，其风险曝光度为：501001350%60%195006.为了使构件系统更切合实际、更有效地被复用，构件应当具备 (136) ，以提高其通用性。A可继承性 B可变性C可封装性 D可伸缩性（分数：1.00）A.B. C.D.解析：解析 请参考试题 18 的分析。评价软件的质量通常可以从产品运行

35、、产品修改和产品转移三个不同角度来进行。除了软件应满足产品规格说明的正确性和保证运行效率以外， (52) 和 (53) 也是产品运行期间影响软件质量的两个质量因素，其中 (52) 是指在遇到意外时系统能做出适应反应的程度。可维护性是影响产品修改的一个质量因素，它主要包括可理解性、可修改性和 (54) 。一般认为， (55) 是影响产品转移的一个质量因素。为了保证软件质量，在开发过程的各阶段进行 (56) 是一个重要的手段。（分数：5.00）(1).A灵活性 B可重用性 C适应性D健壮性（分数：1.00）A.B.C.D. 解析：(2).A灵活性 B可重用性 C适应性D可用性（分数：1.00）A.

36、B.C.D. 解析：(3).A可测试性 B可移植性 C适应性 D健壮性（分数：1.00）A. B.C.D.解析：(4).A灵活性 B可重用性 C完整性 D安全性（分数：1.00）A.B. C.D.解析：(5).A验收测试 B用户培训 C软件评审 D文件修改（分数：1.00）A.B.C. D.解析：解析 软件质量保证是指为保证软件系统或软件产品最大限度地满足用户要求而进行的有计划、有组织的活动，其目的是生产高质量的软件。有多种软件质量模型来描述软件质量特性，著名的有ISO/IEC 9126 软件质量模型和 McCall 软件质量模型。软件系统主要的软件质量属性有：(1)性能(performanc

37、e) 系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理事件的个数。经常用单位时间内所处理事务的数量或系统完成某个事务处理所需的时间来对性能进行定量的表示。性能测试经常要使用基准测试程序。(2)可靠性(reliability) 软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统功能特性的基本能力。可靠性通常用平均失效等待时间 MTTF(Mean Time To Failure)和平均失效间隔时间MTBF(Mean Time Between Failure)来衡量。可靠性可以分为两个方面：容错性(fault-tolerant)和健壮性(robus

38、tness)。其中：容错性是在错误发生时确保系统正确的行为，并进行内部“修复”。例如，在一个分布式软件系统中失去了一个与远程构件的连接，接下来恢复了连接。在修复这样的错误之后，软件系统可以重新或重复执行进程间的操作直到错误再次发生。健壮性是指保护应用程序不受错误使用和错误输入的影响，在遇到意外错误事件时确保应用系统处于已经定义好的状态。和容错性相比，健壮性并不是说在错误发生时软件可以继续运行，它只能保证软件按照某种已经定义好的方式终止执行。(3)有效性(availability) 系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。(4)安全性(

39、security) 指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性是根据系统可能受到安全威胁的类型来分类的。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。其中：机密性 保证信息不泄露给未授权的用户、实体或过程；完整性 保证信息的完整和准确，防止信息被非法修改；可控性 保证对信息的传播及内容具有控制的能力，防止为非法者所用。(5)可修改性(modifiability) 指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。可修改性包含 4 个方面：可维护性、可扩展性、结构重组、可移植性

40、。其中可维护性(maintainability) 表明在软件中纠正一个缺陷或做一次更改的难易程度。主要体现在问题的修复上：在错误发生后“修复”软件系统。可扩展性(extendibility) 关注的是使用新特性来扩展软件系统，以及使用改进版本来替换构件并删除不需要或不必要的特性和构件。为了实现可扩展性，软件系统需要松散耦合的构件。其目标是实现一种体系结构，它能使开发人员在不影响构件客户的情况下替换构件。支持把新构件集成到现有的体系结构中也是必要的。结构重组(reassemble) 重新组织软件系统的构件及构件间的关系。例如，通过将构件移动到一个不同的子系统而改变它的位置。为了支持结构重组，软件

41、系统需要精心设计构件之间的关系。理想情况下，它们允许开发人员在不影响实现主体部分的情况下灵活地配置构件。可移植性(portability) 把软件系统从一个系统平台移到另一个平台的难易程度。(6)功能性(functionality) 系统完成所期望工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。(7)互操作性(interoperability) 指系统能与其他系统协作的程度。软件质量保证环节包括的主要功能有：制定和展开质量方针；制定质量保证方针和质量保证标准；建立和管理质量保证体系；明确各阶段的质量保证业务；坚持各阶段的质量评审；确保设计质量；提出与分析重要的质量问题；总结实现

42、阶段的质量保证活动；整理面向用户的文档、说明书等；鉴定产品质量，鉴定质量保证体系：收集、分析和整理质量信息。根据 ISO/IEC 9126，软件质量由三个层次组成，第一层是质量特性，第二层是质量子特性，第三层是度量指标。 质量属性分为功能性、可靠性、可维护性、效率、易使用性和可移植性 6 个，21 个质量子特性如下。(1)功能性 包括适合性、准确性、互用性、依从性、安全性：(2)可靠性 包括成熟性、容错性、易恢复性；(3)易使用性 包括易理解性、易学性、易操作性；(4)效率 包括时间特性、资源特性；(5)可维护性 包括易分析性、易改变性、稳定性、易测试性。(6)可移植性 包括适应性、易安装性、

43、一致性、易替换性。软件质量特性度量有两类：预测度量和验收度量。预测度量是利用定量或定性的方法，估算软件质量的评价值，以得到软件质量比较精确的估算值。验收度量是在软件开发各阶段的检查点，对开发过程中的预测进行评价得到软件的要求和质量进行确认性检查的具体评价值。预测度量有两种，第一种叫做尺度度量，这是一种定量度量。它适用于一些能够直接度量的特性，例如，出错率定义为：错误数/KLOC/单位时间。第二种叫做二元度量，这是一种定性度量。它适用于一些只能间接度量的特性，例如，可使用性、灵活性等。评价软件的质量通常可以从产品运行、产品修改和产品转移三个不同角度来进行。如图 9-12 所示。软件的可维护性通常

44、包括可理解性、可修改性和可测试性。为了保证软件质量，在开发过程的各阶段进行软件评审是一个重要的手段。对软件开发的看法可有多种观点，敏捷软件开发方法是一种 (118) ，代表性是极限编程 XP，它的核心思想为 (119) 。（分数：2.00）(1).A数学观 B建模观C工程观 D协作游戏（分数：1.00）A.B.C.D. 解析：(2).A强调文档和以敏捷性应对变化B强调建模和以敏捷性应对变化C强调设计和以敏捷性应对变化D强调人和人之间的合作的因素和以敏捷性应对变化（分数：1.00）A.B.C.D. 解析：解析 在我们面临“软件危机”所带来的挑战之时，曾经通过采用严格的规范、详尽的文档来约束开发过

45、程，以保证开发的质量与效果，获得了突出的成就。但是随着时代的进一步发展，商业周期越来越短，变化越来越快，甚至在软件开发的过程中，商业逻辑和需求已经悄然变化，这给本来还不成熟的软件产业带来了新的挑战。正在这种情况下，敏捷方法论应运而生。2001 年这些方法论的创始人走到一起，成立了敏捷联盟，发表了颇具影响力的敏捷宣言：个体和交互胜过过程和工具，可工作的软件胜过面面俱到的文档，客户合作胜过合同谈判，响应变化胜过遵循计划。比较有影响力的敏捷方法论包括 XP(极限编程)、FDD(特征驱动开发)、Crystal Method(水晶方法)、 DSDM(动态系统开发方法)、ASD(自适应开发)、Scrum

46、等。XP 的核心是其总结的沟通、简单、反馈、勇气四大价值观。它包括 12 种最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作 40 小时、现场客户以及编码标准。7.软件项目管理中可以使用各种图形工具，在以下关于各种图形工具的论述中正确的是 (117) 。A流程图直观地描述了工作过程的具体步骤，以及这些步骤之间的时序关系，可以用于控制工作过程的完成时间。BPERT 图画出了项目中各个活动之间的时序关系，可用于计算工程项目的关键路径，以便控制项目的进度。C因果分析图能表现出软件过程中各种原因和效果之间的关系，并且表现了它们随时间出现的顺序和

47、重要程度，这些数据可用于改进软件过程的性能。DGantte 图为整个项目建立了一个时间表，反映了项目中的所有任务之间的依赖关系以及各个任务的起止日期，这些信息可用于项目的任务调度。（分数：1.00）A.B. C.D.解析：解析 软件项目管理中可以使用各种图形工具，例如流程图，PERT 图、Gantte 图、因果分析图等。流程图可以直观地描述工作过程的具体步骤，以及这些步骤之间的关系，帮助我们预测在何处可能发生何种质量问题，并由此帮助开发处理他们的办法。但流程图不能用于控制工作过程的完成时间。PERT 技术(计划评审技术)是安排开发进度，制定软件开发计划的最常用的方法。PERT 图采用网络图来描

48、述一个项目的任务网络，也就是从一个项目的开始到结束，把应当完成的任务用图或表的形式表示出来。通常用两张表来定义网络图。一张表给出与特定软件项目有关的所有任务(也称为任务分解结构)，另一张表给出应当按照什么样的次序来完成这些任务(也称为限制表)，在项目的早期阶段，PERT 图对于组织任务、建立时间框架，反映项目中的所有任务之间的依赖关系十分有用。PERT 技术为项目计划人员提供了一些定量的工具。(1)确定关键路径，即决定项目开发时间的任务链。(2)应用统计模型，对每一个单独的任务确定最可能的开发持续时间的估算值。(3)计算边界时间，以便为具体的任务定义时间窗口。边界时间的计算对于软件项目的计划调度是非常有用的。因果分析图又称特性要因图，因其形状像树枝或鱼骨，故又称鱼骨图、鱼刺图、树枝图，是分析质量问题产生原因的有效工具。因果分析图描述相关的各种原因和子原因如何产生潜在问题或影响，但不能表现它们随时间出现的顺序和重要程度。因果图的做法是将要分析的问题放在图形的右侧，用一条带箭头的主干指向要解决的质量问题，一般从人、设备、材料、方法、环境五个方面进行分析。对具体问题来讲，这五个方面的原因不一定同时存在，要找到解决问题的方法，还需要对上述五个方面进一步分解。它们之间的关系也用带箭头的箭线表示。Gantte 图(甘特图)用水平线段表示任务的工