软件工程是上午题的第一大户:2009 到 2021 年,本章累计考了 227 道题,平均每年 17 道上下,是所有章节里题量最大、考点最稳定的一片。
它的考点结构也非常友好——几乎全部落在几张固定的清单和两套公式上:五种过程模型的适用场景、CMM 五级、维护四类型、测试覆盖准则、McCabe 环形复杂度、关键路径与松弛时间、ISO 9126 的子特性归属。把这些清单背准,再把活动图的两条计算规则练熟,这一章的 200 多道题就退化成了“对号入座”。
本章 14 个小节按知识点组织:每节先用两三句话把方法论说透,再逐题给出答案与解析。解析中所有计算题(关键路径、松弛时间、McCabe)都列出了完整步骤;带图的题目(流程图、活动图、程序图)已把图中的关键信息用文字复述。文末附全 227 题的答案速查表,适合考前快速过一遍。
软件能力成熟度模型:CMM 与 CMMI
CMM 是上午题里回报率最高的送分点:五级顺序、每级的核心特征、CMMI 的两种表示方法,翻来覆去只考这三件事。五级口诀“1 初始、2 可重复、3 已定义、4 已管理、5 优化”必须倒背如流——2014 与 2019 两年原题重复出现,说明出题人对这套清单的执念很深。CMMI 部分再叠加连续式 6 个能力等级(CL0〜CL5),记住 CL1 能执行、CL2 已管理、CL3 已定义、CL4 定量管理、CL5 优化即可通吃本节。
软件能力成熟度模型(CMM)将软件能力成熟度自低到高依次划分为5级。目前,达到CMM第3级(已定义级)是许多组织努力的目标,该级的核心是 (29) 。
查看答案与解析收起答案与解析
本题考查 CMM 五级各自的核心特征。CMM 将软件能力成熟度由低到高分为初始级、可重复级、已定义级、已管理级、优化级 5 级。第 3 级“已定义级”的核心是整个组织的软件开发与维护过程已实现标准化和文档化,即使用标准开发过程(或方法论)构建(或集成)系统,B 正确。A“建立基本的项目管理和实践来跟踪项目费用、进度和功能特性”是第 2 级可重复级的核心;C“管理层寻求更主动地应对系统的开发问题”是第 1 级初始级的特点;D“连续地监督和改进标准化的系统开发过程”是第 5 级优化级的核心。记住“2 可重复、3 已定义、4 已管理、5 优化”即可秒杀此类题。
软件能力成熟度模型(CMM)的第4级(已管理级)的核心是 (29) 。
查看答案与解析收起答案与解析
本题考查 CMM 第 4 级“已管理级”的核心。第 4 级的特点是组织对软件过程和产品都建立了定量的质量目标,通过度量与统计分析实现对过程和产品的定量理解和控制,过程能力可以预测,C 正确。A“建立基本的项目管理和实践来跟踪项目费用、进度和功能特性”是第 2 级可重复级的核心;B“组织具有标准软件过程”是第 3 级已定义级的核心;D“先进的新思想和新技术促进过程不断改进”是第 5 级优化级的核心。五级核心口诀:1 初始无序、2 重复有纪律、3 定义有标准、4 管理有定量、5 优化有改进。
SEI能力成熟度模型(SEI CMM)把软件开发企业分为5个成熟度级别,其中(32) 重点关注产品和过程质量。
查看答案与解析收起答案与解析
本题考查 CMM 各级别的名称与关注点。SEI CMM 把软件开发企业分为 5 个成熟度级别:级别 1 初始级、级别 2 可重复级、级别 3 确定级(已定义级)、级别 4 管理级(已管理级)、级别 5 优化级。其中重点关注产品和过程质量的是级别 4 管理级——该级对软件过程和产品建立了定量的质量目标,实现了定量的理解与控制,C 正确。A 级别 2 可重复级关注项目管理的纪律性(跟踪费用、进度);B 级别 3 确定级关注过程标准化、文档化;D 级别 5 优化级关注利用新技术实现过程持续改进。“定量管质量在第 4 级、持续改进在第 5 级”是常见辨析点。
以下关于CMM的叙述中,不正确的是 (30) 。
查看答案与解析收起答案与解析
本题考查 CMM 的基本概念,选不正确项。B 错误:CMM 划分的 5 个等级中,1 级是初始级、成熟度最低,5 级是优化级、成熟度最高,选项恰好把方向说反了。A 正确,CMM 即软件过程能力成熟度模型;C 正确,CMMI(能力成熟度模型集成)的任务就是将已有的几个 CMM 模型结合在一起,构造成为“集成模型”;D 正确,采用更成熟的过程模型一般能够提高最终产品的质量。本题是典型的“说法反向”题,只要牢记“1 级最低、5 级最高”,即可一眼锁定答案。
以下关于CMM的叙述中,不正确的是 (30) 。
查看答案与解析收起答案与解析
本题与 2014 年下半年真题几乎完全相同,考查 CMM 等级顺序。B 错误:CMM 的 5 个等级中 1 级为初始级、成熟度最低,5 级为优化级、成熟度最高,选项表述正好颠倒,故选 B。A 正确,CMM 指软件过程能力成熟度模型;C 正确,CMMI 的任务是把已有的几个 CMM 模型结合在一起构成“集成模型”;D 正确,采用更成熟的 CMM 模型一般来说可以提高最终产品的质量。同一考点在 2014、2019 两年原题重现,说明“CMM 五级由低到高的顺序及 1 级最低、5 级最高”是必背考点,遇到“1 级最高”类表述直接判错。
能力成熟度集成模型CMMI是CMM模型的最新版本,它有连续式和阶段式两种表示方式。基于连续式表示的CMMI共有6个(0〜5)能力等级,每个能力等级对应到一个一般目标以及一组一般执行方法和特定方法,其中能力等级 (31) 主要关注过程的组织标准化和部署。
查看答案与解析收起答案与解析
本题考查 CMMI 连续式表示的能力等级。基于连续式表示的 CMMI 共有 6 个(0〜5)能力等级:CL0 未完成的、CL1 已执行的、CL2 已管理的、CL3 已定义的、CL4 定量管理的、CL5 优化的。其中能力等级 3“已定义级”主要关注过程的组织标准化和部署——把过程在组织层面标准化并向各项目部署,C 正确。A 的 CL1 只要求过程“能够执行”;B 的 CL2 关注对过程进行计划、跟踪等管理;D 的 CL4 关注用定量指标管理和控制过程。注意区分:连续式按过程域逐一评级,阶段式则给出组织整体成熟度等级。
关于过程改进,以下叙述中不正确的是 (30) 。
查看答案与解析收起答案与解析
本题考查 CMMI 与过程改进的关系,选不正确项。D 错误:CMMI 提供阶段式和连续式两种表示方法,既支持阶段性过程改进,也支持连续性过程改进,“仅支持阶段性而不支持连续性”与事实相反,故选 D。A 正确,软件质量依赖于软件开发过程的质量,其中个人因素占主导作用;B 正确,要使过程改进有效,必须先制定明确的过程改进目标;C 正确,培训是过程改进得以有效实施的必要手段。CMMI 的两种表示方式是高频考点:阶段式给出组织成熟度等级(1〜5 级),连续式给出各过程域的能力等级(CL0〜CL5)。
能力成熟模型集成(CMMI)是若干过程模型的综合和改进。连续式模型和阶段式模型是CMMI提供的两种表示方法。连续式模型包括6个过程域能力等级(Capability Level,CL)其中 (30) 的共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品,以实现支持过程域的特定目标。
查看答案与解析收起答案与解析
本题考查 CMMI 连续式模型中 CL1 的共性目标。连续式模型包括 6 个过程域能力等级,其中 CL1“已执行的”(Performed)的共性目标是:过程将可标识的输入工作产品转换成可标识的输出工作产品,以实现支持过程域的特定目标——通俗地说就是“这件事能做出来、有输入有产出”,A 正确。B 的 CL2(已管理的)要求过程经过计划、跟踪并受管理;C 的 CL3(已定义的)要求过程按组织标准过程裁剪后执行;D 的 CL4(定量管理的)要求用定量指标控制过程。能力等级越高要求越多,CL1 是最基本的“能执行”。
能力成熟度模型集成(CMMI)是若干过程模型的综合和改进。连续式模型和阶段式模型是CMMI提供的两种表示方法,而连续式模型包括6个过程域能力等级,其中 (30) 使用量化(统计学)手段改变和优化过程域,以应对客户要求的改变和持续改进计划中的过程域的功效。
查看答案与解析收起答案与解析
本题考查 CMMI 连续式模型的最高能力等级。CL5“优化的”(Optimizing)强调使用量化(统计学)手段改变和优化过程域,以应对客户要求的改变和持续改进计划中的过程域的功效——即在 CL4 定量管理的基础上,主动地、持续地优化过程,D 正确。A 的 CL2(已管理的)只做到过程受计划和管理;B 的 CL3(已定义级的)做到过程标准化;C 的 CL4(定量管理的)用统计手段控制过程,但尚未主动改变和优化过程。记忆线索:CL4 是“定量控制”,CL5 是“定量优化”,优化的目的是应对变化、持续改进。
软件过程模型:瀑布、原型、增量、螺旋、喷泉
过程模型是软件工程章题量最大的知识点,考法固定:给一段项目场景(需求清晰度、风险高低、上市压力、技术风险),问选哪个模型。判断链只有一条——需求明确且经验丰富选瀑布;需求模糊选原型;要尽快上市分批交付选增量;高风险大规模选螺旋;面向对象选喷泉。反向题(“最不适宜”“不是优点”)也全靠这套对应关系反推,把五个模型的“性格”记住,本节 22 道题基本变成送分题。
某项目组拟开发一个大规模系统,且具备了相关领域及类似规模系统的开发经验。下列过程模型中, (15) 最适合开发此项目。
查看答案与解析收起答案与解析
本题考查过程模型的选择。瀑布模型适用于需求明确、开发经验丰富的项目。本项目规模较大,且开发组具备相关领域及类似规模系统的开发经验,需求可以被准确理解和定义,最适合采用瀑布模型,B 正确。A 原型模型适合需求不清晰、需要与用户反复确认的场合;C V 模型是瀑布模型的变体,强调测试贯穿开发全程,但题干强调的“需求明确+经验丰富”正是瀑布模型的教科书式场景;D 螺旋模型适合大规模、高风险、需求不明确的项目。选模型的三个判据——需求清晰度、风险高低、团队经验,本题三项都指向瀑布。
若全面采用新技术开发一个大学记账系统,以替换原有的系统,则宜选择采用 (30)进行开发。
查看答案与解析收起答案与解析
本题考查过程模型的选择。关键信息是“替换原有的系统”——原有系统的功能与流程是现成的参照物,新系统需求相对明确;同时“全面采用新技术”要求严格的阶段划分和文档管理来控制质量与进度,因此宜采用瀑布模型,A 正确。B 演化模型适合需求需要逐步细化的场合;C 螺旋模型适合高风险、需求不明确的项目,强调每轮迭代的风险分析;D 原型模型适合需求模糊、需借助原型与用户确认需求的场合。记住:有旧系统做参照、需求清晰的项目,标准答案通常是瀑布模型。
假设某软件公司与客户签订合同开发一个软件系统,系统的功能有较清晰的定义,且客户对交付时间有严格要求,则该系统的开发最适宜采用 (30) 。
查看答案与解析收起答案与解析
本题考查过程模型的选择。系统功能有较清晰的定义,且客户对交付时间有严格要求——需求明确是瀑布模型的典型适用场景,各阶段顺序推进、里程碑清晰,便于严格控制进度和交付时间,A 正确。B 原型模型适合需求不清晰时通过原型与用户交互确认需求,迭代周期不可控;C V 模型虽然同样要求需求明确,但其特点是测试与开发阶段一一对应,题干强调的是需求清晰与交付时间,标准答案是瀑布模型;D 螺旋模型引入风险分析、迭代轮次不固定,不利于严格按期交付。
某开发小组欲开发一个规模较大、需求较明确的项目。开发小组对项目领域熟悉且该项目与小组开发过的某一项目相似,则适宜采用 (29) 开发过程模型。
查看答案与解析收起答案与解析
本题考查瀑布模型的适用场景。项目规模较大、需求较明确,开发小组对项目领域熟悉且与开发过的某一项目相似——这是教科书式的瀑布模型场景:需求明确则各阶段可以顺序推进,经验丰富则文档、评审有保障,A 正确。B 演化模型适合需求需逐步细化明确的项目;C 螺旋模型适合规模大、风险高的项目,要求较强的风险评估能力;D 喷泉模型适合面向对象的迭代无缝开发。判断口诀:“需求明确+经验丰富=瀑布;需求不清=原型/演化;高风险=螺旋;面向对象=喷泉”。
(29) 开发过程模型最不适用于开发初期对软件需求缺乏准确全面认识的情况。
查看答案与解析收起答案与解析
本题考瀑布模型的局限,选最不适用的模型。瀑布模型要求在开发初期就准确、完整地获取需求,然后按阶段线性推进,越到后期回溯代价越大。因此当“开发初期对软件需求缺乏准确全面的认识”时,最不适用瀑布模型,A 正确。B 演化模型、C 螺旋模型、D 增量模型都支持多轮迭代,允许需求在开发过程中逐步明确和完善,恰好适用于需求认识不清的场合。此题反过来表述就是“瀑布模型适用于需求明确的项目”,正反两个方向都可能出现,务必同时掌握。
某公司要开发一个软件产品,产品的某些需求是明确的,而某些需求则需要进一步细化。由于市场竞争的压力,产品需要尽快上市,则开发该软件产品最不适合采用 (30) 模型。
查看答案与解析收起答案与解析
本题考瀑布模型的局限。产品需求部分明确、部分需进一步细化,且由于市场竞争压力需要尽快上市——这要求边开发边细化需求、分批尽早交付,而瀑布模型必须等全部需求明确后线性走完各阶段、最后一次性交付,最不适合本题场景,A 正确。B 原型模型可快速构造原型澄清需求;C 增量模型分批交付、核心功能先行,利于抢占市场;D 螺旋模型通过多轮迭代逐步完善产品。记忆技巧:题干出现“尽快上市”“需求逐步细化”时,答案一定不是瀑布模型。
某开发小组欲为一公司开发一个产品控制软件,监控产品的生产和销售过程,从购买各种材料开始,到产品的加工和销售进行全程跟踪。购买材料的流程、产品的加工过程以及销售过程可能会发生变化。该软件的开发最不适宜采用 (29) 模型,主要是因为这种模型 (30) 。
查看答案与解析收起答案与解析
本题两空考查瀑布模型的适用判断及原因。购买材料流程、产品加工过程、销售过程都可能发生变化,即需求变化频繁;瀑布模型要求需求一次性明确后线性推进,对变化的需求适应性差,因此最不适宜采用瀑布模型,(29)选 A。(30)问主要原因:瀑布模型按固定阶段顺序推进,难以适应变化的需求,C 正确。A“不能解决风险”是螺旋模型要解决的问题;B“不能快速提交软件”是增量模型针对的短板;D“不能理解用户的需求”说法过于绝对,瀑布模型并非不能理解需求,而是难以应对需求变更。凡题干出现“需求会变化”,瀑布模型必被排除。
软件开发的增量模型 (29) 。
查看答案与解析收起答案与解析
本题考查增量模型的特点。增量模型把软件分解成一系列增量构件,分批进行设计、编码、集成和测试,核心产品先行,能够快速构造可运行产品并逐步完善,是快速构造可运行产品的好方法,B 正确。A 错误,“需求被清晰定义”是瀑布模型的适用前提,增量模型恰恰常用于需求不完全明确的情况;C 错误,增量模型通常适合规模较小、沟通方便的团队,不适合大规模团队开发;D 错误,增量模型非常适合商业产品的创新开发,能尽早把可运行产品投放市场。关键词“核心产品先交付、逐步扩充”是增量模型的标志。
(30) 不是增量式开发的优势。
查看答案与解析收起答案与解析
本题考增量式开发的优势,选不是优势的项。D 不是优势:把客户需求划分成多个增量并不容易——需求之间往往相互关联、难以严格切割,增量划分恰恰是增量开发的难点所在,故选 D。A 正确,软件可以快速地交付(第一个增量完成后即可使用);B 正确,早期的增量可以作为原型,从而加强对系统后续开发需求的理解;C 正确,具有最高优先级的功能首先交付,随着后续增量不断加入,更重要的功能得到更多的测试。增量模型的三大优点(快速交付、原型启发、重点功能多测试)反复出现,而“容易划分增量”“有利于模块划分”都是反面干扰项。
以下关于增量模型的叙述中,正确的是 (29) 。
查看答案与解析收起答案与解析
本题考查增量模型的正确叙述。B 正确:增量模型首先开发核心产品,随后按增量逐个加入次要构件,可以快速构造核心产品交付使用。A 错误,“需求被清晰定义”是瀑布模型的前提,增量模型一般用于需求不完全明确的情况;C 错误,“每个增量必须进行风险评估”是螺旋模型的要求——螺旋模型以风险驱动,每轮都做风险分析;D 错误,增量模型适宜商业产品的开发,能尽早提供可运行产品抢占市场。出题人常把瀑布模型的前提、螺旋模型的要求安到增量模型头上,识别这些“张冠李戴”是解题关键。
以下关于增量开发模型的叙述中,不正确的是 (30) 。
查看答案与解析收起答案与解析
本题考增量开发模型的叙述,选不正确项。D 不正确:如何把系统合理地划分为若干增量恰恰是增量模型的难点,而非其优点,“有利于进行好的模块划分”与事实相反,故选 D。A 正确,不必等到整个系统开发完成,交付的增量即可投入使用;B 正确,可以使用较早的增量构件作为原型,从而获得稍后增量构件的需求;C 正确,优先级最高的服务最先交付,这样最重要的服务接受最多的测试。本题与 2013 年下半年“不是增量式开发优势”的真题同源,注意“增量划分是难点”这一固定表述。
以下关于增量模型的叙述中,不正确的是 (29) 。
查看答案与解析收起答案与解析
本题考增量模型的叙述,选不正确项。D 不正确:如果一开始用户需求就不清晰,会直接影响增量划分的合理性,进而影响开发进度和质量,增量模型并非对需求不清免疫,故选 D。A 正确,增量模型把系统分解为小构件逐个开发,容易理解、管理成本低;B 正确,核心的产品往往首先开发,因此经历最充分的“测试”;C 正确,第一个可交付版本所需要的成本低、时间少。与 2016 年上半年真题(“有利于进行好的模块划分”为错误说法)互为变形,增量模型的“需求不清也无影响”“有利于模块划分”都是典型错误选项。
以下关于增量模型优点的叙述中,不正确的是 (29) 。
查看答案与解析收起答案与解析
本题考增量模型的优点,选不正确项。D 不正确:随着增量的不断叠加,系统集成、配置管理和回归测试的工作量会持续上升,增量模型的系统管理成本并不低,“管理成本低、效率高、配置简单”不符合实际,故选 D。A 正确,增量模型强调开发阶段性早期的计划;B 正确,第一个可交付版本所需要的时间少和成本低;C 正确,开发由增量表示的小系统所承担的风险小。总结增量模型的优点:早交付、低成本、小风险、重点功能多测试;对应的弱点:增量划分难、后期集成管理并不轻松。
为了有效地捕获系统需求,应采用 (29) 。
查看答案与解析收起答案与解析
本题考查原型模型的适用场景。为了有效地捕获系统需求,应采用原型模型:开发方快速构造一个可运行的原型,让用户在真实操作中直观感受系统并提出修改意见,从而澄清、确认和完善需求,C 正确。A 瀑布模型和 B V 模型都要求需求先行明确再进入后续阶段,本身并不擅长需求的探索与捕获;D 螺旋模型虽然每圈都包含需求分析,但其核心是风险驱动、成本较高。凡题干出现“捕获需求”“需求不清晰需与用户确认”等字眼,首选原型模型。
某开发小组欲开发一个超大规模软件:使用通信卫星,在订阅者中提供、监视和控制移动电话通信,则最不适宜采用 (29) 过程模型。
查看答案与解析收起答案与解析
本题考原型模型的局限,选最不适宜的模型。该软件是使用通信卫星、在订阅者中提供/监视/控制移动电话通信的超大规模软件,性能与可靠性要求极高、系统结构极其复杂;原型模型以快速构造、粗略实现为手段,主要作为需求澄清的工具,无法支撑如此大规模系统的高性能要求,最不适宜采用,B 正确。A 瀑布模型适合需求明确的超大型项目;C 螺旋模型适合大型、复杂、高风险项目;D 喷泉模型适合面向对象开发的大型项目。原型的定位是“需求工具”而非“交付产品”,这是本题的题眼。
某企业拟开发一个企业信息管理系统,系统功能与多个部门的业务相关。现希望该系统能够尽快投入使用,系统功能可以在使用过程中不断改善。则最适宜采用的软件过程模型为 (29) 。
查看答案与解析收起答案与解析
本题考查演化(迭代)模型的适用场景。企业信息管理系统功能与多个部门业务相关,希望尽快投入使用且功能可以在使用过程中不断改善——演化模型先开发出核心系统投入使用,再通过多轮迭代逐步演化、完善系统,恰好匹配该需求,C 正确。A 瀑布模型要求需求一次明确、最后一次性交付,无法“尽快投入使用”;B 原型模型主要用于澄清需求,原型通常被抛弃而非持续演化;D 螺旋模型强调风险分析,适合高风险项目。演化模型与增量模型的区别:演化强调反复迭代逐步演化出完整系统,增量强调把功能拆成分批叠加的构件。
某公司计划开发一种产品,技术含量很高,与客户相关的风险也很多,则最适于采用 (29) 开发过程模型。
查看答案与解析收起答案与解析
本题考查螺旋模型。产品技术含量很高,与客户相关的风险也很多——螺旋模型是风险驱动的模型,每一圈螺旋都包含风险分析环节,通过反复的风险评估降低高风险项目失败的概率,最适合本项目,D 正确。A 瀑布模型没有风险分析环节;B 原型模型用于需求澄清,不针对项目风险;C 增量模型强调分批交付,同样缺乏系统的风险分析机制。螺旋模型四象限活动:制定计划、风险分析、实施工程、客户评估。做题经验:题干只要出现“风险”二字,答案基本都是螺旋模型。
以下关于螺旋模型的叙述中,不正确的是 (29) 。
查看答案与解析收起答案与解析
本题考螺旋模型的叙述,选不正确项。D 不正确:螺旋模型正是适用于大规模、复杂且具有高风险的软件开发项目,“不适用于大型软件开发”与事实相反,故选 D。A 正确,螺旋模型是风险驱动的,要求开发人员必须具有丰富的风险评估知识和经验;B 正确,每圈迭代都做风险分析,可以降低过多测试或测试不足带来的风险;C 正确,螺旋模型包含维护周期,因此维护和开发之间没有本质区别。螺旋模型三大关键词——风险驱动、迭代循环、适合大型复杂项目,记住它们即可识别反向表述。
关于螺旋模型,下列陈述中不正确的是 (29) , (30) 。
查看答案与解析收起答案与解析
本题两空考查螺旋模型的特性辨析。(29)选 D:“可以快速地提供一个初始版本让用户测试”是原型模型/增量模型的特点;螺旋模型每圈都要经历完整的计划、风险分析、工程和评审,迭代多轮后才逐步形成可运行版本,并不追求快速提供初始版本。A 正确,螺旋模型是在瀑布模型基础上加入风险分析形成的;B 正确,每个螺旋周期大致与瀑布模型相符;C 正确,适合大规模、复杂且高风险的项目。(30)选 C:螺旋模型增加了风险分析环节、迭代轮次多,人力成本高,“基于该模型开发成本低”错误。A 正确,支持用户需求的动态变化;B 正确,要求开发人员具有风险分析能力;D 正确,过多的迭代次数会增加成本、延迟提交时间。
以下关于喷泉模型的叙述中,不正确的是 (29) 。
查看答案与解析收起答案与解析
本题考喷泉模型的叙述,选不正确项。D 不正确:喷泉模型各开发活动(分析、设计、编码)之间没有明显的界限,是无缝的迭代过程,“存在明显的边界”与事实相反,故选 D。A 正确,喷泉模型以对象作为驱动的模型,适合于面向对象的开发方法;B 正确,它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性;C 正确,模型中的开发活动常常需要重复多次,在迭代过程中不断地完善软件系统。“喷泉”之名即指活动像泉水般循环往复、无缝衔接,无缝性是它区别于瀑布模型的本质特征。
(30) 开发过程模型以用户需求为动力,以对象为驱动,适合于面向对象的开发方法。
查看答案与解析收起答案与解析
本题考查喷泉模型的定位。以用户需求为动力、以对象为驱动、适合面向对象开发方法的开发过程模型是喷泉模型,D 正确。A 瀑布模型以文档为驱动、阶段线性推进;B 原型模型以用户需求为动力,但驱动核心是“原型”而非对象,且其定位是需求澄清;C 螺旋模型以风险为驱动。四个过程模型按“驱动力”区分是秒杀技巧:文档驱动是瀑布、风险驱动是螺旋、对象驱动是喷泉、需求(原型)驱动是原型。喷泉模型的迭代性、无缝性、支持重用三大特征也常作为配套考点出现。
喷泉模型是一种适合于面向 (29) 开发方法的软件过程模型。该过程模型的特点不包括 (30) 。
查看答案与解析收起答案与解析
本题两空考查喷泉模型。(29)选 A:喷泉模型是一种适合于面向对象开发方法的软件过程模型,以对象为驱动,B/C/D 的数据、数据流、事件均不是其驱动核心。(30)选 D:喷泉模型的特点不包括“开发活动之间存在明显的界限”——喷泉模型是无缝模型,分析、设计、编码等活动没有明显界限,可以重叠、迭代进行,这正是它区别于瀑布模型之处。A 正确,以用户需求为动力;B 正确,支持软件重用;C 正确,具有迭代性。喷泉模型“迭代、无缝、重用”三大特征加“面向对象”一个定位,构成本考点全部内容。
统一过程(UP/RUP)与敏捷方法
UP 考三件事:四个核心概念(角色=谁做、活动=做什么、制品=做出什么、工作流=什么时候做)、四个阶段及里程碑(初启→生命周期目标、精化→生命周期架构、构建→集成产品、移交→产品发布)。敏捷考流派识别:XP 的价值观与 12 个最佳实践、Scrum 的冲刺与 Backlog、水晶法的“因项目而异”、ASD 的自适应。每个流派记一两个标志性关键词,见到关键词对号入座。
一个软件开发过程描述了“谁做”、“做什么”、“怎么做”和“什么时候做”,RUP用 (16)来表述“谁做”。
查看答案与解析收起答案与解析
本题考查 RUP 的四个核心概念。一个软件开发过程描述了“谁做”“做什么”“怎么做”和“什么时候做”,RUP 中:角色(Role)表述“谁做”,定义个人或协同工作的团队的行为与职责;活动(Activity)表述“做什么”,是角色执行的工作单元;制品(Artifact)是活动生成或修改的产物,表述“做出什么”;工作流(Workflow)把活动按时间与逻辑组织起来,表述“什么时候做”。本题问“谁做”,答案为角色,A 正确。B 活动对应“做什么”;C 制品对应产物;D 工作流对应流程组织。四个概念与四个问题的对应关系是必背考点。
RUP在每个阶段都有主要目标,并在结束时产生一些制品。在 (30) 结束时产生“在适当的平台上集成的软件产品”。
查看答案与解析收起答案与解析
本题考查 RUP 各阶段的产出。构建阶段(Construction)结束时产生“在适当的平台上集成的软件产品”,即初始可运行的 β 版本系统,C 正确。A 初启阶段结束时产出用例模型、业务用例和项目计划,里程碑是生命周期目标;B 精化阶段结束时产出补充的需求分析和可执行的架构原型,里程碑是生命周期架构;D 移交阶段关注把产品交付给用户,包括试运行、培训和验收。RUP 四阶段与产出的对应:初启→目标与范围、精化→架构基线、构建→集成产品、移交→正式发布,这一对应关系几乎每年变换角度考一次。
统一过程(UP)定义了初启阶段、精化阶段、构建阶段、移交阶段和产生阶段,每个阶段以达到某个里程碑时结束,其中 (32) 的里程碑是生命周期架构。
查看答案与解析收起答案与解析
本题考查 UP 各阶段的里程碑。精化阶段(Elaboration)的里程碑是“生命周期架构”(Lifecycle Architecture)——该阶段完成需求分析和架构演进,建立稳定的架构基线,证明架构可以支撑系统,B 正确。A 初启阶段的里程碑是“生命周期目标”(LCO),确认项目值得做;C 构建阶段的里程碑是“初始运行能力”(IOC),即 Beta 版本;D 移交阶段的里程碑是“产品发布”(PR),系统正式交付。另注意题干中“产生阶段”为干扰项,UP 标准阶段为初启、精化、构建、移交四个。阶段与里程碑一一对应,必须背熟。
统一过程模型是一种“用例和风险驱动,以架构为中心,迭代并且增量”的开发过程,定义了不同阶段及其制品,其中精化阶段关注 (15) 。
查看答案与解析收起答案与解析
本题考查 UP 精化阶段的活动内容。统一过程是“用例和风险驱动,以架构为中心,迭代并且增量”的开发过程,其中精化阶段关注需求分析和架构演进:细化用例、捕获非功能需求、建立稳定的架构基线,B 正确。A“项目的初始活动”(确定范围、可行性、业务用例)属于初启阶段;C“系统的构建,产生实现模型”属于构建阶段;D“软件提交方面的工作,产生软件增量”属于移交阶段。UP 四阶段的任务划分口诀:初启定范围、精化定架构、构建做实现、移交做交付,考题只是把这句口诀换着说法考。
以下关于统一过程UP的叙述中,不正确的是 (29) 。
查看答案与解析收起答案与解析
本题考 UP 的叙述,选不正确项。B 不正确:UP 定义的四个阶段是初始(初启)、精化、构建、移交,不存在“确认阶段”,故选 B。A 正确,UP 是以用例和风险为驱动、以架构为中心、迭代并且增量的开发过程;C 正确,每次迭代都包含计划、分析、设计、构造、集成、测试以及内部和外部发布;D 正确(按教材口径),每个迭代有五个核心工作流。注意 UP 的“阶段”是迭代周期概念,与瀑布模型“需求—设计—编码”的线性阶段含义不同,这是理解 UP 叙述题的基础。
极限编程(XP)由价值观、原则、实践和行为四个部分组成,其中价值观包括沟通、简单性、 (36) 。
查看答案与解析收起答案与解析
本题考查 XP 的价值观组成。极限编程(XP)由价值观、原则、实践和行为四个部分组成,其中价值观包括沟通、简单性、反馈和勇气,C 正确。A“好的计划”不属于 XP 价值观,XP 恰恰强调简单设计而反对过度计划;B“不断的发布”和 D“持续集成”属于 XP 的 12 个最佳实践(实践层面),不是价值观层面。记忆技巧:四个价值观中“勇气”最具辨识度——敢于重构、敢于抛弃代码,看到选项含“反馈和勇气”即可确定是考价值观。
敏捷开发方法XP是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方法,其特性包含在12个最佳实践中。系统的设计要能够尽可能早交付,属于 (18) 最佳实践。
查看答案与解析收起答案与解析
本题考查 XP 12 个最佳实践的对应关系。“系统的设计要能够尽可能早交付”对应小型发布(Small Releases):XP 强调系统尽可能早、以小周期向用户交付可运行的版本,使用户尽早使用并反馈,C 正确。A 隐喻是通过类比比喻帮助团队理解系统模型;B 重构是在不改变功能的前提下重新组织和简化设计,对应“简化构件设计”类描述;D 持续集成指每天多次把代码集成、构建和测试,对应“频繁合并代码”类描述。12 个最佳实践与一句描述的对号入座是 XP 的主要考法,“尽早交付=小型发布”最常考。
敏捷开发方法中, (30) 认为毎一种不同的项目都需要一套不同的策略、约定和方法论。
查看答案与解析收起答案与解析
本题考查敏捷方法流派的观点区分。认为“每一种不同的项目都需要一套不同的策略、约定和方法论”的是水晶法(Crystal):水晶家族按项目规模与关键程度分为水晶橙、水晶黄等多种“颜色”变体,体现了“因项目而异”的思想,B 正确。A 极限编程(XP)强调沟通、简单、反馈、勇气四大价值观和 12 个最佳实践;C 并列争球法(Scrum)强调 30 天一次的冲刺迭代和自组织小组;D 自适应软件开发(ASD)强调在混沌与变化中自适应调整。四大流派的标志性关键词是判断依据,本题的“不同项目不同方法论”锁定水晶法。
在敏捷过程的方法中 (30) 认为每一个不同的项目都需要一套不同的策略、约定和方法论。
查看答案与解析收起答案与解析
本题与 2012 年下半年真题完全相同:敏捷方法中认为每一个不同的项目都需要一套不同的策略、约定和方法论的是水晶法(Crystal),B 正确。水晶法按项目参与人数、风险高低分为多种“颜色”变体(如水晶橙、水晶黄),正是“一套方法论打天下”的反面,强调为不同类型的项目定制不同的策略与约定。A XP 强调统一的价值观与最佳实践;C Scrum 强调固定的冲刺节奏与角色分工;D ASD 强调自适应循环 speculate-collaborate-learn。同一考点 2012、2015 两次原题重现,务必记住“水晶法=定制方法论”。
在敏捷过程的开发方法中, (16) 使用了迭代的方法,其中,把每段时间(30天)一次的迭代称为一个“冲刺”,并按需求的优先级别来实现产品,多个自组织和自治的小组并行地递增实现产品。
查看答案与解析收起答案与解析
本题考查并列争球法(Scrum)。Scrum 使用迭代的方法,把每段时间(30 天)一次的迭代称为一个“冲刺”(Sprint),并按需求的优先级别来实现产品,多个自组织和自治的小组并行地递增实现产品,C 正确。A 极限编程的迭代周期更短,以结对编程、测试先行、持续集成等实践为标志;B 水晶法强调因项目定制方法论;D 自适应软件开发强调以混沌理论为基础的自适应循环。“冲刺(Sprint)”是 Scrum 最具辨识度的关键词,见到“30 天迭代”“冲刺”直接选 Scrum。
以下关于极限编程(XP)中结对编程的叙述中,不正确的是 (30) 。
查看答案与解析收起答案与解析
本题考结对编程的叙述,选不正确项。D 不正确:结对编程由两人共用一台机器,一人编码、一人实时审查,能够提高代码质量,但编码速度并不会更快——XP 的主要目标是解决代码质量问题,而非提高编码速度,故选 D。A 正确,结对编程支持共同代码拥有和共同对系统负责;B 正确,一人编写一人观察,实际上承担了非正式的代码审查过程;C 正确,实时评审使代码缺陷更早暴露,代码质量更高。“质量更高、速度不变”是结对编程的标准结论,出题人常把“速度更快”设为错误项。
极限编程(XP)的十二个最佳实践不包括 (32) 。
查看答案与解析收起答案与解析
本题考查 XP 的 12 个最佳实践清单,选不包括项。D“精心设计”不属于:XP 提倡的是简单设计(Simple Design)——只处理当前的需求、保持设计尽可能简单,与“精心设计”精神相悖,故选 D。A 小的发布(小型发布)、B 结对编程、C 持续集成都是 12 个最佳实践的内容。12 个最佳实践代表:计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、代码集体所有、每周工作 40 小时、持续集成、现场客户、编码标准。“精心设计”是本题的经典干扰项,务必与“简单设计”区分。
以下关于极限编程(XP)的最佳实践的叙述中,不正确的是 (30) 。
查看答案与解析收起答案与解析
本题考 XP 最佳实践的叙述,选不正确项。B 不正确:XP 提倡“测试先行”(Test-First),即先编写测试代码、再编写程序代码,用测试驱动开发;“编写完程序之后编写测试代码”把顺序说反了,故选 B。A 正确,只处理当前的需求,使设计保持简单(简单设计);C 正确,借助小型发布与持续集成,可以按日甚至按小时为客户提供可运行的版本;D 正确,现场客户(On-site Customer)要求系统最终用户代表全程配合 XP 团队。测试先行的方向性是本考点的陷阱所在,方向颠倒即错。
敏捷开发方法Scrum的步骤不包括 (29) 。
查看答案与解析收起答案与解析
本题考查 Scrum 的基本步骤。Scrum 的标准流程是:Product Backlog(产品待办列表,按优先级排列的需求清单)→ Sprint Backlog(冲刺待办列表,本轮冲刺要完成的任务)→ Sprint(30 天左右的冲刺迭代,结束时交付可用增量)。Refactoring(重构)是极限编程(XP)的最佳实践,不属于 Scrum 的步骤,B 当选。A、C、D 均为 Scrum 的标准环节。区分技巧:见到“重构、结对编程、测试先行、简单设计”想 XP;见到“Backlog、Sprint、冲刺、产品负责人”想 Scrum。
以下关于敏捷统一过程(AUP)的叙述中,不正确的是 (30) 。
查看答案与解析收起答案与解析
本题考敏捷统一过程(AUP)的叙述,选不正确项。C 不正确:“每一个不同的系统都需要一套不同的策略、约定和方法论”是水晶法(Crystal)的观点,不是 AUP 的主张,故选 C。A 正确,AUP 在大型任务上连续(按阶段连续推进);B 正确,在小型活动上迭代;D 正确,AUP 采用经典的 UP 阶段性活动,即初始化、精化、构建和转换(移交)。AUP 可以理解为 UP 的敏捷化简化版:保留 UP 的阶段骨架,裁剪重量级的中间产物,以轻量迭代方式实施。
需求分析:功能需求与非功能需求
需求分析部分题量不大,只考一个分类:功能需求回答“系统必须做什么”,非功能需求回答“做得怎么样”(性能、可靠性、并发等质量属性),设计约束则是对方案的外部限制。判断口诀:动词加业务动作是功能,“3 秒内响应”“允许 100 人并发”这类形容词短语全部归非功能需求。
“软件产品必须能够在3秒内对用户请求作出响应”属于软件需求中的 (18) 。
查看答案与解析收起答案与解析
本题考查软件需求的分类。“软件产品必须能够在 3 秒内对用户请求作出响应”是对响应时间(性能指标)的要求,而性能属于质量属性,归入非功能需求,B 正确。A 功能需求描述系统“必须做什么”,例如工资发放、查询统计等业务功能;C 设计约束是对系统设计方案的限制,如必须采用某硬件平台、某数据库或遵循某标准;D 逻辑需求不是标准的需求分类术语。判断口诀:描述“做什么”的是功能需求,描述“做多快、多稳、多安全”的是非功能需求,响应时间、吞吐量、并发数都是典型非功能需求。
某企业财务系统的需求中,属于功能需求的是 (19) 。
查看答案与解析收起答案与解析
本题考查功能需求的识别。“每个月特定的时间发放员工工资”描述了系统必须完成的一项业务功能(在什么时间、做什么事),属于功能需求,A 正确。B“系统的响应时间不超过 3 秒”是性能类非功能需求;C“系统的计算精度符合财务规则的要求”是质量属性类非功能需求(正确性/可靠性);D“系统可以允许 100 个用户同时查询自己的工资”是并发容量类非功能需求。判断口诀:动词+业务动作=功能需求;形容“多快、多稳、多准、可容纳多少”=非功能需求。此题与 2013 年上半年的“3 秒响应”题正好构成正反两面。
软件设计:概要设计与详细设计
设计部分只考一条分界线:概要设计管“模块间”,详细设计管“模块内”。模块划分、调用关系、体系结构、模块间接口属于概要设计;模块内算法、局部数据结构、数据库物理设计属于详细设计。概要设计文档里出现“模块内算法”必错,详细设计任务里出现“模块间接口”必错,两道真题互为镜像,记住这条线即可双杀。
确定软件的模块划分及模块之间的调用关系是 (15) 阶段的任务。
查看答案与解析收起答案与解析
本题考查设计阶段的任务划分。确定软件的模块划分及模块之间的调用关系是概要设计(总体设计)阶段的核心任务——概要设计把系统分解为若干模块,定义模块的层次结构与调用接口,B 正确。A 需求分析回答“做什么”,产出数据流图、数据字典等;C 详细设计确定每个模块内部采用的算法和局部数据结构,是“模块内”的设计;D 编码阶段用程序设计语言实现设计结果。记忆主线:概要设计管“模块间”(划分与调用关系),详细设计管“模块内”(算法与局部数据),这条分界线是本考点全部题目共享的答案依据。
在 (16) 设计阶段选择适当的解决方案,将系统分解为若干个子系统,建立整个系统的体系结构。
查看答案与解析收起答案与解析
本题考查概要设计的定义。在概要设计阶段选择适当的解决方案,将系统分解为若干个子系统,建立整个系统的体系结构,A 正确。B 详细设计针对模块内部的算法与数据结构展开,不负责系统级的分解;C 结构化、D 面向对象是开发方法(方法论),不是设计阶段的名称,属于干扰项。概要设计的主要工作包括:体系结构设计、模块划分、模块间接口设计、全局数据结构设计等;它与详细设计的分界线仍然是“模块间 vs 模块内”,凡是出现“分解”“体系结构”“子系统”字眼,答案都是概要设计。
概要设计文档的内容不包括 (32) 。
查看答案与解析收起答案与解析
本题考概要设计文档的内容,选不包括项。模块内算法设计属于详细设计阶段的任务——概要设计只关心模块的划分与模块间的关系,模块内部“用什么算法实现”留给详细设计,C 当选。A 体系结构设计、B 数据库设计(概念结构设计)、D 逻辑数据结构设计都是概要设计阶段的任务产物。判据依然是那条分界线:概要设计回答“系统由哪些模块组成、模块如何联系、数据如何组织”,详细设计回答“每个模块内部用什么算法、什么局部数据结构来实现”。
软件详细设计阶段的主要任务不包括 (32) 。
查看答案与解析收起答案与解析
本题考详细设计阶段的任务,选不包括项。模块之间的接口设计是概要设计阶段的任务——接口描述的是“模块间”的关系,在系统分解时就应确定,不属于详细设计,C 当选。A 数据结构设计(模块内部使用的数据结构)、B 算法设计、D 数据库的物理设计(表、索引、存储结构)都属于详细设计的内容。与 2018 年上半年“概要设计文档不包括模块内算法设计”正好互补成对:概要不管模块内算法,详细不管模块间接口,两题放在一起记忆最牢固。
软件测试基础与黑盒测试
测试基础的概念题全部围绕 Myers 的两句名言展开:测试的目的是发现错误,成功的测试是发现了至今未发现的错误的测试;测试只能证明错误存在,不能证明错误不存在。再加 V 模型的阶段对应(需求→系统测试、概要→集成、详细→单元)和“改代码后再测=回归测试”两条规则。黑盒部分考等价类划分的黄金原则:一个用例可以覆盖多个有效等价类,但只能覆盖一个无效等价类——三道真题全部以此设错。
以下关于软件测试的叙述中,正确的是 (35) 。
查看答案与解析收起答案与解析
本题考查软件测试的基本原理。C 正确:测试的目的是发现错误,一个成功的测试能发现至今未发现的错误——这是测试领域经典定义(Myers)。A 错误,测试只能证明程序中存在错误,不能证明程序中不存在错误;B 错误,测试应尽早进行,测试计划在需求分析阶段即可制定,测试活动贯穿开发全程,并非从编码阶段才开始;D 错误,经验表明错误具有群集性,已发现错误越多的程序段残存错误通常也越多,而不是越少。“成功测试=发现新错误”与“错误群集性”是两个高频结论。
在设计测试用例时,应遵循 (35) 原则。
查看答案与解析收起答案与解析
本题考查测试用例的设计原则。C 正确:设计测试用例时不仅要设计有效合理的输入,也要包含不合理、失效的输入——意外的非法输入往往更能暴露程序的健壮性缺陷。A 错误,测试用例必须同时包含输入数据和预期输出结果,缺少预期输出就无法判定执行是否正确;B 错误,程序做了不该做的(多余)功能也是错误,需要检验程序是否“做了多余的功能”;D 错误,测试用例应当简单明确、便于执行和判定,刻意复杂化没有意义。测试用例三要素:输入、执行条件、预期输出。
在软件开发过程中,系统测试阶段的测试目标来自于 (32) 阶段。
查看答案与解析收起答案与解析
本题考查 V 模型的阶段对应关系。系统测试针对整个系统,验证系统是否满足需求规格说明书的规定,其测试目标来自需求分析阶段,A 正确。B 概要设计对应集成测试(检验模块间接口与体系结构);C 详细设计对应单元测试(检验模块内部逻辑);D 软件实现对应编码与单元验证。V 模型左半边自上而下(需求分析→概要设计→详细设计→编码),右半边自下而上(单元测试→集成测试→系统测试→验收测试),左右一一对应,这一对应关系是上午题反复出现的考点。
以下关于软件测试的叙述中,不正确的是 (35) 。
查看答案与解析收起答案与解析
本题考软件测试的叙述,选不正确项。B 不正确:软件测试的目的是发现软件中的错误,而不是证明软件的正确性——测试只能证伪、不能证真,即使全部用例通过也不能说明程序无错,故选 B。A 正确,在设计测试用例时应同时考虑输入数据和预期输出结果;C、D 正确,设计测试用例时既要包括合理的输入条件,也要包括不合理的输入条件,以检验程序对非法输入的处理能力。与 2010 年下半年“一个成功的测试能发现至今未发现的错误”对照复习,两题共同强调测试的证伪本质。
以下关于测试的叙述中,正确的是 (34) 。
查看答案与解析收起答案与解析
本题考查测试相关叙述的正误判断。D 正确:白盒测试技术中,路径覆盖要求覆盖程序中所有可能的执行路径,其覆盖强度高于语句覆盖,往往能发现更多的错误。A 错误,穷举测试是不可能实现的——输入域可能无穷、路径数随分支数指数增长;B 错误,错误具有群集性,错误很多的程序段在修改后仍可能残存较多错误;C 错误,测试不能证明软件没有错误。白盒覆盖强度由弱到强:语句覆盖<判定覆盖<条件覆盖<判定/条件覆盖<条件组合覆盖<路径覆盖,该排序是本考点的基础。
在软件开发过程中,系统测试阶段的测试目标来自于 (32) 阶段。
查看答案与解析收起答案与解析
本题与 2014 年下半年真题完全相同:系统测试阶段的测试目标来自需求分析阶段。系统测试站在整个系统的高度,验证系统是否实现了需求规格说明书规定的功能与性能,因此其目标与依据均来自需求分析,A 正确。B 概要设计对应集成测试;C 详细设计对应单元测试;D 软件实现对应编码与单元验证。V 模型的左右对应关系(需求→系统测试、概要→集成、详细→单元)两年一考,题目可以正着问“系统测试目标来自哪”,也可以反着问“详细设计对应什么测试”,都要会答。
单元测试中,检查模块接口时,不需要考虑 (36) 。
查看答案与解析收起答案与解析
本题考单元测试中模块接口的检查内容。接口检查关注:模块的输入参数与形式参数的个数、属性、单位上是否一致;全局变量在各模块中的定义和用法是否一致;输入是否改变了形式参数;调用其他模块时实际参数与形式参数是否匹配等。D“输入参数是否使用了尚未赋值或者尚未初始化的变量”属于局部数据结构检查或执行路径检查的内容,不属于接口检查,故选 D。单元测试的五大检查内容:模块接口、局部数据结构、重要的执行路径、边界条件、错误处理,各检查点的内容要能对号入座。
(36) 不是单元测试主要检查的内容。
查看答案与解析收起答案与解析
本题考单元测试的主要检查内容,选不是的项。单元测试集中在单个模块内部,检查:模块接口、局部数据结构、重要的执行路径、边界条件和错误处理。全局数据结构涉及多个模块共同使用的数据,其一致性在模块集成后才能完整检验,属于集成测试关注的内容,不是单元测试的主要检查内容,C 当选。A 模块接口、B 局部数据结构、D 重要的执行路径均在单元测试的检查范围内。单元测试一般由开发人员完成,需要设计驱动模块(模拟上级调用)和桩模块(模拟下级被调用)。
一个项目为了修正一个错误而进行了变更。但这个错误被修正后,却引起以前可以正确运行的代码出错。 (18) 最可能发现这一问题。
查看答案与解析收起答案与解析
本题考查回归测试的定义。项目为修正一个错误而进行了变更,但修正后引起以前可以正确运行的代码出错——发现这类问题正是回归测试的职责:在代码修改(错误修复、功能扩充、环境变化)之后重新执行测试,验证修改没有引入新缺陷、原有功能依然正确,C 正确。A 单元测试只针对被修改模块自身;B 接受(验收)测试是交付前由用户确认系统满足合同;D 安装测试验证系统在各环境的安装过程。识别标志:题干出现“修改后”“变更后”“怕影响原来正确的功能”,答案都是回归测试。
在改正当前故障的同时可能会引入新的故障,这时需要进行 (36) 。
查看答案与解析收起答案与解析
本题考查回归测试。在改正当前故障的同时可能会引入新的故障,这时需要进行回归测试:重新执行受修改影响部分的已有测试用例,确认新修改没有破坏原有功能,C 正确。A 功能测试验证系统功能是否符合需求规格;B 性能测试验证响应时间、吞吐量等性能指标;D 验收测试由用户主导,确认系统可以交付。回归测试是维护阶段和集成阶段使用最频繁的测试类型,其本质是“改了代码之后的重复验证”,与 2009 年、2013 年的同类真题一起记忆。
某项目为了修正一个错误而进行了修改。错误修正后,还需要进行 (19) 以发现这一修正是否引起原本正确运行的代码出错。
查看答案与解析收起答案与解析
本题考查回归测试。错误修正后,还需要进行回归测试,以发现“这一修正是否引起原本正确运行的代码出错”——回归测试通过重新执行此前建立的测试用例集,覆盖被修改代码及其所有调用路径,D 正确。A 单元测试只验证修改模块本身的功能,无法发现修改对其他模块的波及影响;B 接受测试是交付前的用户确认活动;C 安装测试检验系统安装部署的正确性。2009、2011、2013 年三年各考一次回归测试,出题模式固定:题干描述“修正了错误→担心影响其他部分”,答案永远是回归测试。
自底向上的集成测试策略的优点包括 (34) 。
查看答案与解析收起答案与解析
本题考查自底向上集成测试策略的优点。自底向上集成从最底层的叶子模块开始测试,下层模块是真实的模块,因此不需要写桩程序(桩程序用于模拟被调用而尚未集成的下层模块),只需为上层编写驱动模块,C 正确。A 错误,主要的设计问题(顶层架构问题)要到测试后期才能发现,这恰恰是自底向上的缺点,自顶向下才能较早处理主要设计问题;B 错误,自底向上需要编写驱动模块;D 错误,无论哪种集成策略,集成后都需要进行回归测试。对比记忆:自顶向下要桩不要驱动、早发现架构问题;自底向上要驱动不要桩、早验证底层模块。
某系统重用了第三方组件(但无法获得其源代码),则应采用 (35) 对组件进行测试。
查看答案与解析收起答案与解析
本题考查黑盒测试的适用场景。某系统重用了第三方组件但无法获得其源代码——白盒测试的各种技术(基本路径覆盖、分支覆盖、环路覆盖等)都以程序内部逻辑结构为基础设计用例,源代码不可得则无法实施;只能把组件当作黑箱,从功能规格出发检验输入输出关系,即采用黑盒测试,D 正确。A 基本路径覆盖、B 分支覆盖、C 环路覆盖均为白盒技术,全部排除。此题判断依据只有一句话:“没有源代码→白盒不可用→只能黑盒”,是黑盒/白盒适用边界最直白的考法。
不属于黑盒测试技术的是 (36) 。
查看答案与解析收起答案与解析
本题考查黑盒/白盒技术的分类,选不属于黑盒的项。逻辑覆盖(语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖)依据程序内部的逻辑结构设计测试用例,属于白盒测试技术,B 当选。A 错误猜测、C 边界值分析、D 等价类划分都是黑盒测试技术——它们只依据需求规格说明和输入输出域设计用例,不关心程序内部结构。黑盒技术清单:等价类划分、边界值分析、错误猜测、因果图;白盒技术清单:各种逻辑覆盖+基本路径测试。两个清单背熟,分类题零失误。
在某班级管理系统中,班级的班委有班长、副班长、学习委员和生活委员,且学生年龄在15〜25岁。若用等价类划分来进行相关测试,则 (35) 不是好的测试用例。
查看答案与解析收起答案与解析
本题考查等价类划分的用例设计原则。班委取值{班长、副班长、学习委员、生活委员},学生年龄在 15〜25 岁之间。等价类划分的经典原则:一个用例可以覆盖多个有效等价类,但每个用例只能覆盖一个无效等价类,否则出错时无法定位原因。D(队长,12)中“队长”不是合法班委(无效)、年龄 12 也不在 [15,25] 内(又一个无效),一个用例同时覆盖两个无效等价类,不是好的测试用例,D 当选。A(队长,15)只覆盖职务非法这一个无效等价类;B(班长,20)为两个有效等价类的组合;C(班长,15)为有效职务+边界年龄,均符合原则。
一个程序根据输入的年份和月份计算该年中该月的天数,输入参数包括年份(正整数)、月份(用1〜12表示)。若用等价类划分测试方法进行测试,则 (35) 不是一个合适的测试用例(分号后表示测试的输出)。
查看答案与解析收起答案与解析
本题考查等价类划分。输入年份(正整数)、月份(1〜12),程序计算该月天数。C(0, 13; '错误'):年份 0 非法(无效等价类一)、月份 13 非法(无效等价类二),一个用例同时覆盖了两个无效等价类——即使程序输出“错误”,也无法判断是哪个非法输入触发的处理逻辑,不符合“每个用例只覆盖一个无效等价类”的原则,不是合适的测试用例,C 当选。A(2013, 1; 31)是年份、月份两个有效等价类的组合,合法;B(0, 1; '错误')只覆盖年份无效一个无效类;D(2000, -1; '错误')只覆盖月份无效一个无效类。
招聘系统要求求职的人年龄在20岁到60岁之间(含),学历为本科、硕士或者博士,专业为计算机科学与技术、通信工程或者电子工程。其中 (35) 不是好的测试用例。
查看答案与解析收起答案与解析
本题考查等价类划分。招聘要求:年龄 20〜60 岁(含)、学历为本科/硕士/博士、专业为计算机/通信/电子。C(18, 大专, 电子工程):年龄 18 无效、学历大专无效,一个用例同时覆盖两个无效等价类,违反等价类划分原则,不是好的测试用例,C 当选。A(20, 本科, 电子工程)为三个有效等价类组合,且 20 恰为年龄下边界,是好用例;B(18, 本科, 通信工程)只覆盖年龄无效一个无效类;D(25, 硕士, 生物学)只覆盖专业无效一个无效类。原则再强调一遍:有效等价类可多个共用一例,无效等价类必须一例一个。
白盒覆盖与 McCabe 度量
白盒部分一半考覆盖准则的强弱与用例数(语句最弱、路径最强;分支覆盖要求每个判定的真假各执行一次),一半考 McCabe 环形复杂度计算。计算三公式任选其一:V(G)=m−n+2(弧数−节点数+2)、V(G)=封闭区域数+1、V(G)=判定节点数+1,数弧时按“顺序边→分支边→回边/自环”三遍清点,再用区域法交叉验证。近年McCabe 题常与代码/伪代码结合,复合条件(while j>0 and A[j]>key)按判定节点法拆开计数。
McCabe度量法是通过定义环路复杂度,建立程序复杂性的度量,它基于一个程序模块的程序图中环路的个数。计算有向图G的环路复杂性的公式为:V(G)=m-n+2,其中V(G)是有向图G中的环路个数,m是G中的有向弧数,n是G中的节点数。下图所示程序图的程序复杂度是 (32) 。
查看答案与解析收起答案与解析
本题考查 McCabe 度量法的计算(图中为带 while 循环与分支的程序图,节点 A〜G)。计算公式 V(G)=m−n+2,其中 m 为有向弧数、n 为节点数。数得节点 n=7,有向弧 m=8:A→B、B→C、C→D(z<t)、C→E(z≥t)、D→G(cond==true)、E→F(p>5)、F→B(回边)以及 while 循环的自环,V(G)=8−7+2=3,B 正确。也可用区域法验证:程序图为连通平面图,封闭区域 2 个,V=封闭区域数+1=3。A 的 2、C 的 4、D 的 5 分别对应漏数回边或自环、多数边的情形。三公式任选其一:V=m−n+2、V=封闭区域+1、V=判定节点数+1。
某程序的程序图如下所示,运用McCabe度量法对其进行度量,其环路复杂度是 (32) 。
查看答案与解析收起答案与解析
本题考查 McCabe 度量法。该程序图节点 n=7(A〜G),有向弧 m=10:A→B、B→C、C→D(z<t)、C→E(z≥t)、D→F(cond==false)、D→G(cond==true)、E→F(p>5)、F→B(回边)、E 的 while(t<count) 自环、G 的 while(x<y) 自环,V(G)=10−7+2=5,D 正确。也可用区域法:封闭区域 4 个,V=4+1=5。数弧时的技巧:按“顺序边→分支边→循环回边/自环”的顺序清点,本题的两个自环(两个 while 循环)和一条回边最容易漏数,漏掉一个就会错选 4。
某程序的程序图如下图所示,运用McCabe度量法对其进行度量,其环路复杂度是(36) 。
查看答案与解析收起答案与解析
本题考查 McCabe 度量法。该程序图节点 n=7、有向弧 m=11:主体为一条顺序链,链上存在多条前跳弧与回退弧,V(G)=11−7+2=6,C 正确。也可用区域法验证:封闭区域 5 个,V=5+1=6。选项 A 的 4、B 的 5 通常是漏数了跨接弧或回边的结果,D 的 8 则是多把无向连线计入。数弧要点:每条有向弧只数一次、方向不必区分进出,自环算一条弧。McCabe 三公式(m−n+2、封闭区域+1、判定节点+1)中,图结构复杂时用区域数最快。
根据McCabe度量法,以下程序图的复杂性度量值为 (32) 。
查看答案与解析收起答案与解析
本题考查 McCabe 度量法。该程序图节点 n=7(a〜g),有向弧 m=9:a→b、b→c、b→d、c→e、d→e、d→f、f→e、e→g 以及 a 到 g 的前跳弧,V(G)=9−7+2=4,A 正确。也可用区域法验证:图中存在 3 个封闭区域——菱形 b→c→e 与 b→d→e 构成的区域、d→f→e 与 d→e 构成的区域、外环 a→b→…→e→g→a 构成的区域,V=封闭区域+1=3+1=4。B 的 5、C 的 6、D 的 7 均为对弧数或区域数清点有误的结果。建议用区域法复核弧数法的结果,两者一致才算数对。
采用McCabe度量法计算下列程序图的环路复杂性为 (33) 。
查看答案与解析收起答案与解析
本题考查 McCabe 度量法。该程序图节点 n=9(A〜I),有向弧 m=10:A→B、B→C、C→D、D→E、E→F、F→G、G→H、E→I、I→G、H→D(回边),V(G)=10−9+2=3,B 正确。也可用区域法验证:封闭区域 2 个(E→I→G 与 E→F→G 之间、主体链与 H→D 回边构成的外环),V=2+1=3。选项 A 的 2 是漏数了 H→D 回边或 E→I 分支的结果,C 的 4、D 的 5 是多数了弧。主链 7 条边+分支 1 条+回边 2 条的分段清点方式最不易出错。
采用McCabe度量法计算下图的环路复杂件为 (31) 。
查看答案与解析收起答案与解析
本题考查 McCabe 度量法应用于流程图。将流程图转化为程序图:节点为判定框和语句框共 n=6(判定 i>0、语句组 1、i=0、判定 n=0、语句组 3、语句组 2),有向弧 m=8:判定1→语句1(Y)、判定1→汇合点(N)、语句1→i=0、i=0→判定2、判定2→语句3(N)、判定2→语句2(Y)、语句3→判定1(回边)、语句2→判定1(回边),V(G)=8−6+2=4,C 正确。也可按“判定节点数+1”估算:两个判定框各贡献 1 个复杂度,再加 2 个循环回边修正后与弧数法结果一致。两条回边(语句2、语句3 的循环)是本题计数的关键。
软件的复杂性主要体现在程序的复杂性。 (30) 是度量软件复杂性的一个主要参数。若采用McCabe度量法计算环路复杂性,则对于下图所示的程序图,其环路复杂度为 (31) 。
查看答案与解析收起答案与解析
本题两空考查软件复杂性与 McCabe 度量法。第(30)空:软件复杂性主要体现在程序的复杂性,度量软件复杂性的主要参数包括规模(代码行数)、难度(操作数数量)和结构(程序结构相关的度量),其中规模通常用代码行数衡量,A 正确;B 常量的数量、C 变量的数量、D 调用库函数的数量都不是软件复杂性度量的主要参数。第(31)空:该流程图与上题结构相同,转化后 n=6、m=8,V(G)=8−6+2=4,C 正确。软件复杂性度量参数“规模、难度、结构”三要素要与“开发小组规模”区分——后者是团队属性而非程序复杂性。
采用McCabe度量法计算下列程序图的环路复杂性为 (32) 。
查看答案与解析收起答案与解析
本题考查 McCabe 度量法。该程序图节点 n=9(A〜I),有向弧 m=11:A→B、B→C、B→G、C→D、C→E、D→F、E→F、F→H、G→H、H→A(回边)、A→I,V(G)=11−9+2=4,C 正确。用区域法验证:从 A→B 出发经 C 的两条支路(经 D 或经 E)汇于 F,再经 H 回到 A,加上经 G 的支路,共形成 3 个封闭区域,V=3+1=4。A 的 2、B 的 3 通常是漏数了 H→A 回边或某条分支弧,D 的 5 是多数。两条并行支路(C→D、C→E)与三条汇聚支路(D→F、E→F、G→H)是计数易错点。
采用McCabe度量法计算下列程序图的环路复杂性为 (35) 。
查看答案与解析收起答案与解析
本题考查 McCabe 度量法。按官方解析口径,该程序图结点 n=8、有向弧 m=10(含一条从末节点回到首节点的回边和若干分支弧),V(G)=10−8+2=4,C 正确。用区域法验证:图中封闭区域 3 个(左侧链与中部支路围成两个、右侧大回边与主体围成一个),V=3+1=4。A 的 2、B 的 3 分别对应漏数分支弧和漏数回边,D 的 5 是多数了弧。数弧建议分三遍:第一遍数顺序连接的边,第二遍数分支引出的边,第三遍专数回边与自环,三遍相加即为 m。
采用McCabe度量法计算下图所示程序的环路复杂性为 (36) 。
查看答案与解析收起答案与解析
本题考查 McCabe 度量法。该程序图节点 n=10(编号 1〜10),有向弧 m=11:1→2、2→3、3→4、4→5、5→6、6→7、7→8、4→10、5→9、9→7、8→4(回边),V(G)=11−10+2=3,C 正确。用区域法验证:封闭区域 2 个——5→9→7 与 5→6→7 之间围成一个、主体链与 8→4 回边围成一个,V=2+1=3。A 的 1、B 的 2 分别对应漏数 9→7 回边或 8→4 回边,D 的 4 是多数了弧。本题节点数多但结构规整,主链 7 条+2 条引出+2 条回边的分段计数最稳妥。
当用分支覆盖法对以下流程图进行测试时,至少需要设计 (35) 个测试用例。
查看答案与解析收起答案与解析
本题考查分支(判定)覆盖。分支覆盖要求程序中每个判定的真分支和假分支都至少执行一次。该流程图为冒泡排序,含三个判定框:② i<n−1、③ j<n、④ a[i]>a[j],每个判定取真、取假各需一个用例覆盖,按官方口径共需 2×3=6 个测试用例,C 正确。A 的 4 只覆盖了“判定数+1”的路径覆盖下界;B 的 5、D 的 8 无对应计算依据。注意区分:判定覆盖以“判定”为单位(每个判定真假各一次),语句覆盖以“语句”为单位,路径覆盖以“全部执行路径”为单位,三种覆盖的用例数口径不同。
使用白盒测试方法时,应根据 (17) 和指定的覆盖标准确定测试数据。
查看答案与解析收起答案与解析
本题考查白盒测试的基本概念。白盒测试把程序看成透明的盒子,依据程序的内部逻辑结构和指定的覆盖标准(语句覆盖、判定覆盖、条件覆盖、路径覆盖等)设计测试数据,A 正确。B 程序结构的复杂性是 McCabe 度量法度量的对象,不是设计测试数据的依据;C 使用说明书是黑盒测试(功能测试)的依据;D 程序的功能同样是黑盒测试的关注点。一句话区分:白盒看代码结构,黑盒看功能规格;白盒用例=内部逻辑+覆盖标准,这正是本题题干的完整表述。
下图所示的逻辑流,最少需要 (35) 个测试用例可实现语句覆盖。
查看答案与解析收起答案与解析
本题考查语句覆盖的最少用例数。该逻辑流中,第一个判定 (x≤15 且 x>0) 为 N 时进入 (x>15) 判定,为 Y 时执行语句组 1;语句组 3 执行后汇合回主流程,再依次执行语句组 1、i=0、循环中的语句组 2。因此取一个测试用例(如 x=20):先走 N→x>15 为 Y→执行语句组 3→汇合后执行语句组 1→循环执行语句组 2,一条路径即可覆盖全部语句,最少需要 1 个测试用例,A 正确。B 的 2、C 的 3 是把语句组 3 误认为互斥分支(汇合点看错)导致的高估。语句覆盖只要求“每条语句至少执行一次”,与分支组合无关。
下图所示的逻辑流实现折半查找功能,最少需要 (34) 个测试用例可以覆盖所有的可能路径。
查看答案与解析收起答案与解析
本题考查折半查找流程图的路径覆盖。该流程图带有循环,循环体内每次迭代可在 a[mid]>num(取 max=mid)与 a[mid]<num(取 min=mid)两个分支间任意组合,严格枚举的完整路径有无穷多条,因此本题按出口归类:程序的执行结果只有两类——查找成功 return mid 与 查找失败 return −1。设计一个查找成功的测试用例,可覆盖除 return −1 之外的所有语句和路径;设计一个查找失败的测试用例,可覆盖除 return mid 之外的所有语句和路径,两个用例合并即可覆盖所有可能的路径,最少需要 2 个测试用例,B 正确。
在白盒测试法中, (34) 是最弱的覆盖准则。下图至少需要 (35) 个测试用例,才可以完成路径覆盖,语句组2不对变量i进行操作。
查看答案与解析收起答案与解析
本题两空考查覆盖准则的强弱与路径覆盖用例数。第(34)空:白盒测试中,语句覆盖是最弱的覆盖准则——它只要求每条可执行语句至少执行一次,不考虑分支组合,A 正确;条件、判定、路径覆盖的强度都高于语句覆盖。第(35)空:该流程图的完整路径有三条——① x≤0(第一个判定为 N、x>15 也为 N)直接结束;② 0<x≤15:语句组 1→i 循环(语句组 2×3)→结束;③ x>15:语句组 3→汇合→语句组 1→循环→结束,路径覆盖需 3 个测试用例,C 正确。口诀:语句最弱、路径最强,路径数=数“从入口到出口的所有走法”。
测试用例①②实现了 (35) 覆盖;若要完成路径覆盖,则可用测试用例 (36) 。
查看答案与解析收起答案与解析
本题两空考查覆盖类型判定。流程图含两个判定:(x=0) 且 (y>2) 为 Y 走语句 A,为 N 进入第二判定 (x<1) 或 (y=1),为 Y 走语句 B。第(35)空:测试用例①、②执行后,程序中所有语句都至少被执行了一遍(①覆盖语句 A,②覆盖语句 B 所在支路),达到了语句覆盖,A 正确;条件覆盖要求每个条件的真假取值都出现,判定覆盖要求每个判定的真假都出现,①②未达到。第(36)空:要完成路径覆盖需覆盖全部执行路径——语句 A 路径、语句 B 路径、两判定皆假路径,用例 ①②③(或①②④)组合恰好覆盖三条路径,C 正确。
采用白盒测试方法对下图进行测试,设计了4个测试用例:<br/>①(x=0, y=3), ②(x=1, y=2), ③(x=-1, y=2), ④(x=3, y=1)。至少需要测试用例①②才能完成 (35) 覆盖,至少需要测试用例①②③或①②④才能完成 (36) 覆盖。
查看答案与解析收起答案与解析
本题两空考查覆盖类型。两个判定:(x=0) 且 (y>2) 与 (x<1) 或 (y=1)。第(35)空:用例①(x=0, y=3)使第一判定为真,执行语句 A;用例②(x=1, y=2)使第一判定为假、第二判定为假,执行语句 B 一侧的输出支路;①②合起来使每条可执行语句都执行过,完成语句覆盖,A 正确。第(36)空:程序共有三条路径——语句 A 路径、两判定皆假路径、语句 B 路径,需要路径覆盖;用例①②③(③ x=−1 使第二判定为真)或①②④(④ y=1 使第二判定为真)均能覆盖全部三条路径,D 正确。
用白盒测试方法对如下图所示的流程图进行测试。若要满足分支覆盖,则至少要 (29) 个测试用例,正确的测试用例对是 (30) (测试用例的格式为(A, B, X; X))。
查看答案与解析收起答案与解析
本题两空考查分支覆盖。流程图含两个判定:A>2 或 B=3(真则 X=X/A)、A=5 且 X>3(真则 X=X+5)。第(29)空:分支覆盖要求两个判定的真假分支各执行一次,用例一走 N→N,用例二走 Y→Y,两个用例即可覆盖全部分支,B(2 个)正确。第(30)空:要使第二判定为真,须 A=5 且执行 X=X/A 后 X>3(X 为整型),推出 X≥20;验证选项 B:用例 (1,1,5;5) 两判定均为假,输出 5;用例 (5,2,20;9) 第一判定 A>2 为真,X=20/5=4,第二判定 A=5 且 4>3 为真,X=4+5=9,输出 9,与预期一致,B 正确。A、C、D 的用例对要么无法覆盖第二判定的真分支,要么预期输出计算错误。
用白盒测试技术对下面流程图进行测试,设计的测试用例如下表所示。至少采用测试用例 (35) 才可以实现语句覆盖;至少采用测试用例 (36) 才可以实现路径覆盖。测试用例表:① A=2, B=0, X=4;② A=1, B=1, X=1;③ A=2, B=1, X=1;④ A=4, B=0, X=2。
查看答案与解析收起答案与解析
本题两空考查语句覆盖与路径覆盖(图中表格用例:① A=2,B=0,X=4;② A=1,B=1,X=1;③ A=2,B=1,X=1;④ A=4,B=0,X=2;判定一 A>1 AND B=0,真则 X=X/A;判定二 A=2 OR X>1,真则 X=X+1)。第(35)空:两个语句为 X=X/A 和 X=X+1,用例①使判定一为真(执行 X=X/A),且 A=2 使判定二为真(执行 X=X+1),一个用例①即可执行全部语句,实现语句覆盖,A 正确。第(36)空:程序有四条路径——判定一真判定二真(①)、判定一假判定二假(② A=1 使判定一假,X=1 不满足 X>1)、判定一假判定二真(③ B=1 使判定一假,A=2 使判定二真)、判定一真判定二假(④ X 变换后为 0.5,X>1 不成立),需用例 ①②③④ 全部覆盖,D 正确。
用白盒测试技术对下面流程图进行测试,至少采用 (34) 个测试用力才可以实现路径覆盖。
查看答案与解析收起答案与解析
本题考查路径覆盖的用例数。流程图两个判定:(x=0) 且 (y>2) 为 Y 执行语句 A,为 N 进入第二判定 (x<1) 且 (y=1),为 Y 直接汇合(不执行语句),为 N 执行语句 B。全部完整路径有三条:①第一判定真→语句 A;②第一判定假、第二判定真→不执行语句直接输出;③第一判定假、第二判定假→语句 B。路径覆盖需 3 个测试用例,A 正确。B 的 4、C 的 6 是把循环或条件组合重复计入的结果,D 的 8 无依据。数路径的要领:以“判定分支的组合”为主线,从入口到出口一条条列出,不重不漏。
下图所示的程序流程图中有 (34) 条不同的简单路径。采用McCabe度量法计算该程序图的环路复杂性为 (35) 。
查看答案与解析收起答案与解析
本题两空考查简单路径与 McCabe 度量。流程图:判定一 y=n−1(真则输出 A 结束),假则判定二 A[i]>A[i+1](真则交换,假则直接跳过),随后 i=i+1、y=y−1 回到判定一。简单路径指不重复经过节点的路径,共 3 条:①判定一真→输出结束;②判定一假→判定二真→交换→更新→回到判定一后输出;③判定一假→判定二假→更新→回到判定一后输出,(34)选 A(3 条)。第(35)空:V(G)=E−N+2=10−9+2=3,A 正确;也可由“3 条简单路径对应 3 个独立区域”直接得出。注意简单路径不要求覆盖所有边的组合,一条走到底即算一条。
对下图所示流程图采用白盒测试方法进行测试,若要满足路径覆盖,则至少需要 (32) 个测试用例。采用McCabe度量法计算该程序的环路复杂性为 (33) 。
查看答案与解析收起答案与解析
本题两空考查路径覆盖与 McCabe 度量。流程图三个判定:a!=0(假则跳过前两个语句直达语句 3 之后的判定)、a>0(真则执行语句 2)、i>0(真则执行语句 4)。第(32)空:路径覆盖需覆盖全部执行路径——a!=0 假时 i>0 真/假 2 条;a!=0 真且 a>0 真(执行语句 2)后 i>0 真/假 2 条;a!=0 真且 a>0 假(执行语句 3)后 i>0 真/假 2 条,共 6 条路径,需 6 个测试用例,C 正确。第(33)空:V(G)=E−N+2,数得边 13、节点 11(官方口径为 10−8+2 亦可),V(G)=13−11+2=4,D 正确;也可按“3 个判定节点+1”验证:3+1=4。
对下图所示的程序流程图进行语句覆盖测试和路径覆盖测试,至少需要 (35) 个测试用例。采用McCabe度量法计算其环路复杂度为 (36) 。
查看答案与解析收起答案与解析
本题两空考查语句/路径覆盖与 McCabe 度量。流程图:判定一(X>0 或 Y>0,真走语句 1、假走语句 2)→判定二 Z>5(真走语句 4 后输出结束,假走语句 3 后回到判定一)。第(35)空:语句覆盖需覆盖语句 1/2(互斥)与语句 3/4(互斥),2 个用例即可——用例一(X=1, Z=6)覆盖语句 1、4,用例二(X=0,Y=0, Z=1)覆盖语句 2、3;路径覆盖需覆盖全部 4 条路径(语句 1→语句 4、语句 1→语句 3 循环、语句 2→语句 4、语句 2→语句 3 循环),共“2 和 4”个用例,B 正确。第(36)空:V(G)=E−N+2,节点 11、边 13(官方口径 16−14+2 亦可),V(G)=13−11+2=4,D 正确。
对下图所示的程序流程图进行判定覆盖测试,则至少需要 (34) 个测试用例。采用McCabe度量法计算其环路复杂度为 (35) 。
查看答案与解析收起答案与解析
本题两空考查判定覆盖与 McCabe 度量。第(34)空:判定覆盖要求判断 1、2、3 的真假分支各至少执行一次。利用循环内多次迭代,2 个测试用例即可:用例一取判断 1 真、判断 2 真、判断 3 真(覆盖三个真分支);用例二取判断 1 真、判断 2 假(走语句 3、语句 6 后回判断 1),第二遍迭代时取判断 1 假(结束),同时使判断 3 的假分支也得到覆盖,故最少 2 个用例,A 正确。第(35)空:数得该程序图有向弧 m=13、节点 n=12(官方口径 11−10+2 亦可),V(G)=m−n+2=3,B 正确;封闭区域 2 个,V=2+1=3 验证一致。
下图用白盒测试方法进行测试,图中有 (34) 条路径。采用McCabe度量计算该程序图的环路复杂性为 (35) 。
查看答案与解析收起答案与解析
本题两空考查路径计数与 McCabe 度量。第(34)空:图中完整路径共 4 条——①判断 1 假→结束;②判断 1 真、判断 2 真、判断 3 真→语句 5→语句 6→循环后结束;③判断 1 真、判断 2 真、判断 3 假→语句 4→语句 5→语句 6→循环后结束;④判断 1 真、判断 2 假→语句 3→语句 6→循环后结束,B(4 条)正确。第(35)空:数得有向弧 m=16、节点 n=14,V(G)=16−14+2=4,B 正确;也可按“3 个判定节点+1”验证 3+1=4。注意第(34)空数的是“路径”不是“简单路径”,带循环的路径按分支组合归类计数。
若用白盒测试方法测试以下代码,并满足条件覆盖,则至少需 (35) 个测试用例。采用McCabe度量法算出该程序的环路复杂性为 (36) 。
代码如下:
int find_max(int i, int j, int k){
int max;
if (i > j) then
if (i > k) then max = i;
else max = k;
else if (j > k) max = j;
else max = k;
return max;
}
查看答案与解析收起答案与解析
本题两空考查条件覆盖与 McCabe 度量(代码为 find_max:if(i>j){ if(i>k) max=i; else max=k; } else if(j>k) max=j; else max=k;)。第(35)空:条件覆盖要求每个条件的真假取值至少出现一次。三个条件 i>j、i>k、j>k 中,i>k 只有在 i>j 为真时才判断,j>k 只有在 i>j 为假时才判断,两层条件无法在一次执行中同时取遍,因此需分别覆盖两层:用例 (1,0,−1)、(1,0,2) 覆盖 i>j 真、i>k 真/假,用例 (0,1,−1)、(0,1,2) 覆盖 i>j 假、j>k 真/假,共 4 个用例,B 正确。第(36)空:数得节点 n=9、边 m=11,V(G)=11−9+2=4,D 正确;亦可用“3 个判定+1”验证。
对以下的程序伪代码(用缩进表示程序块)进行路径覆盖测试,至少需要 (34) 个测试用例。采用McCabe度量法计算其环路复杂度为 (35) 。
伪代码如下(用缩进表示程序块):
输入 x,y,z
语句1
If x > 0
语句2
If y > 0
语句3
Else
语句4
Else
语句5
If z > 0
语句6
Else
语句7
输出语句
查看答案与解析收起答案与解析
本题两空考查路径覆盖与 McCabe 度量(代码:If x>0 { 语句 2; If y>0 语句 3; Else 语句 4; } Else { 语句 5; If z>0 语句 6; Else 语句 7; })。第(34)空:完整路径共 4 条——x>0 且 y>0(语句 1,2,3)、x>0 且 y≤0(语句 1,2,4)、x≤0 且 z>0(语句 1,5,6)、x≤0 且 z≤0(语句 1,5,7),路径覆盖需 4 个测试用例,如 (1,1,0)、(1,−1,0)、(−1,0,1)、(−1,0,−1),B 正确。第(35)空:3 个判定节点 x>0、y>0、z>0,V(G)=判定节点数+1=3+1=4,C 正确;用 V(G)=m−n+2(m=15, n=13)验证同为 4。
如下所示代码(用缩进表示程序块),要实现语句覆盖,至少需要 (34) 个测试用例。采用McCabe度量法计算该代码对应的程序流图的环路复杂性为 (35) 。
代码如下:
input A,n
for i=2 to n
key=A[i]
j=i-1
while j>0 and A[j]>key
A[j+1]=A[j]
j=j-1
A[j+1]=key
查看答案与解析收起答案与解析
本题两空考查语句覆盖与 McCabe 度量(代码为插入排序:input A,n; for i=2 to n { key=A[i]; j=i−1; while j>0 and A[j]>key { A[j+1]=A[j]; j=j−1; } A[j+1]=key; })。第(34)空:语句覆盖只要求每条语句至少执行一次。取一个足够长的乱序数组(如 A={3,2,1})作为唯一测试用例,for 循环多轮迭代中 while 条件会先后出现真假两种取值,全部语句(含两个循环体)都被执行到,故最少 1 个测试用例,A 正确。第(35)空:转化为程序流图后有两个循环(for 与 while),形成两个闭环,V(G)=闭环个数+1=2+1=3,C 正确;若把 while 的复合条件拆成两个判定再算弧点,结果仍为 3〜4 之间,官方口径为 3。
可维护性与软件文档
可维护性只考一张清单:可理解性、可测试性、可修改性(再加可靠性、可移植性等补充项),凡“可扩展性”“一致性”“可移植性”混进来的都是干扰项。文档部分考常识判断,抓住一个原则:文档贯穿开发与维护全程、能提高(而不是降低)效率与可见度——凡出现“仅仅”“只”“不能提高效率”这类绝对化表述的选项,基本就是答案。
软件系统的可维护性评价指标不包括 (33) 。
查看答案与解析收起答案与解析
本题考软件系统的可维护性评价指标,选不包括项。可维护性是指维护人员理解、改正、改动和改进软件系统的难易程度,其评价指标包括:可理解性、可测试性、可修改性(以及可靠性、可移植性、可使用性和效率等)。“可扩展性”不在此标准清单中,C 当选。A 可理解性指他人理解系统的结构、界面、功能和内部过程的难易程度;B 可测试性指诊断和测试的容易程度;D 可修改性指修改系统的难易程度。注意区分:可扩展性常与可修改性混谈,但教材口径的评价指标中不含“可扩展性”,它是本题的固定干扰项。
系统可维护性的评价指标不包括 (33) 。
查看答案与解析收起答案与解析
本题与 2010 年下半年真题同源,考系统可维护性的评价指标,选不包括项。评价指标为:可理解性、可测试性、可修改性、可靠性、可移植性、可使用性和效率。可移植性描述的是软件从一个环境迁移到另一个环境的难易程度,属于 ISO/IEC 9126 质量模型中的独立质量特性,不属于可维护性的评价指标,C 当选。A 可理解性、B 可测试性、D 可修改性是可维护性最核心的三个评价维度。此考点三年两考(2010、2013),把“三性+若干补充”背下来即可稳拿分。
系统可维护性是指维护人员理解、改正、改动和改进软件系统的难易程度,其评价指标不包括 (36) 。
查看答案与解析收起答案与解析
本题考系统可维护性的评价指标,选不包括项。系统可维护性评价指标包括可理解性、可测试性、可修改性,一致性不属于其中——一致性通常与文档、数据或设计风格相关,归入可移植性范畴的考量,D 当选。A 可理解性指维护人员读懂系统结构与逻辑的难易程度;B 可测试性指定位和验证缺陷的难易程度;C 可修改性指实施修改并保证正确性的难易程度。本题再次验证该考点只认“可理解性、可测试性、可修改性”三张面孔,其余名词一律视为干扰项。
以下关于软件维护和可维护性的叙述中,不正确的是 (36) 。
查看答案与解析收起答案与解析
本题考软件维护与可维护性的叙述,选不正确项。D 不正确:提高可维护性不能等到维护阶段才考虑——可维护性必须在需求、设计、编码、测试各开发阶段持续关注(如模块化、详细文档、结构化设计),“是在软件维护阶段考虑的问题”与事实相反,故选 D。A 正确,软件维护要解决软件产品交付用户之后运行中发生的各种问题;B 正确,维护期通常比开发期长得多,投入也大得多(约占生命周期成本的 60% 以上);C 正确,进行质量保证审查可以提高软件产品的可维护性。
以下关于软件可维护性的叙述中,不正确的是“可维护性 (36) ”。
查看答案与解析收起答案与解析
本题考软件可维护性的叙述,选不正确项。B 不正确:可维护性受开发文档的显著影响——完整、准确、可读的文档是维护人员理解系统的基础,没有文档的维护几乎无从下手,“不受软件开发文档的影响”与事实相反,故选 B。A 正确,可维护性是衡量软件质量的一个重要特性;C 正确,可维护性是软件开发阶段各个时期的关键目标;D 正确(按选项表述),可维护性可以从可理解性、可靠性、可测试性、可行性、可移植性等方面进行度量。文档与维护的关系是本考点的核心逻辑。
以下关于软件维护的叙述中,不正确的是 (36) 。
查看答案与解析收起答案与解析
本题考软件维护的叙述,选不正确项。D 不正确:软件维护工作并不比开发简单——维护人员要在不完整的旧文档和他人代码上定位问题、评估影响、安全修改,还要经受系统长期演进带来的复杂性,难度和代价都很高,“维护工作要简单得多”与事实相反,故选 D。A 正确,软件维护解决产品交付之后运行中发生的各种问题;B 正确,维护期通常比开发期长得多,投入也大得多;C 正确,可维护性是软件开发各阶段都要关注的关键目标。此题与 2014 年下半年真题第 36 题高度相似,可对照复习。
以下关于软件系统文档的叙述中,错误的是 (34) 。
查看答案与解析收起答案与解析
本题考软件系统文档的叙述,选错误项。C 错误:软件系统文档能提高软件开发的效率——文档是开发人员之间、开发人员与用户之间交流的工具,是维护人员的指南,能减少沟通成本、降低理解偏差,从而提高开发与维护效率,“不能提高开发效率”与事实相反,故选 C。A 正确,软件系统文档既包括有一定格式要求的规范文档,又包括系统建设过程中的各种来往文件、会议纪要、会计单据等资料形成的不规范文档;B 正确,文档可以提高软件开发的可见度(各阶段进展可检查);D 正确,文档便于用户理解软件的功能、性能等各项指标。
以下关于文档的叙述中,不正确的是 (33) 。
查看答案与解析收起答案与解析
本题考文档的叙述,选不正确项。A 不正确:文档不仅仅描述和规定软件的使用范围及相关的操作命令——文档贯穿整个生命周期,包括需求规格说明书、设计文档、测试文档、管理文档等,作用远超“使用范围和操作命令”,A 的表述过于狭隘,故选 A。B 正确,文档是软件产品的一部分,没有文档的软件不能称之为软件产品;C 正确,软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量;D 正确,高质量文档对于发挥软件产品的效益有着重要的意义。此题在 2012、2014 年上半年两次出现,选项几乎原样。
以下关于文档的叙述中,不正确的是 (33) 。
查看答案与解析收起答案与解析
本题与 2012 年下半年真题完全相同,考文档的叙述,选不正确项。A 不正确:文档仅仅描述和规定了软件的使用范围及相关操作命令——这一表述以偏概全,文档还包括开发过程各阶段的需求、设计、测试、管理等文档,作用远不止用户操作说明,故选 A。B 正确,文档是软件产品的一部分,没有文档的软件不能称之为软件产品;C 正确,软件文档的编制占有突出的地位和相当大的工作量;D 正确,高质量文档对发挥软件产品效益有重要意义。见到“仅仅”“只”“不能”等绝对化限定词,要第一时间警惕。
以下关于文档的叙述中,不正确的是 (33) 。
查看答案与解析收起答案与解析
本题考文档的叙述,选不正确项。B 不正确:编写文档并不会降低软件开发的效率——高质量文档促进团队沟通、减少理解偏差、为维护提供依据,从整个生命周期看是提高效率的手段;“编写文档会降低开发效率”是只看眼前工作量的短视结论,故选 B。A 正确,项目相关人员可以通过文档进行沟通;C 正确,编写高质量文档可以提高软件开发的质量;D 正确,文档是软件不可或缺的部分。本题与 2012 年下半年、2014 年上半年的文档题构成同一考点的三连考,绝对化表述仍是解题线索。
以下关于文档的叙述中,不正确的是 (33) 。
查看答案与解析收起答案与解析
本题考文档的叙述,选不正确项。B 不正确:文档对开发活动和维护活动都有重要作用——需求文档、设计文档指导开发,测试文档保证质量,而维护阶段更是高度依赖文档来理解系统;“文档只对软件维护活动有用,对开发活动意义不大”与事实相反,故选 B。A 正确,文档也是软件产品的一部分,没有文档的软件就不能称之为软件;C 正确,软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量;D 正确,高质量文档对于软件产品的效益有着重要的意义。2021 年再度考文档,说明该考点长盛不衰。
软件维护的四种类型
维护类型是维护部分的核心考点,13 道题全部共用一套判断口诀:改错=正确性维护;环境变(外部系统、数据格式、硬件平台变化)=适应性维护;用户要求加功能、提性能=完善性维护;为将来打基础提前改=预防性维护。注意两组易混:功能算错是正确性,功能正确但太慢是完善性;用户主动求新是完善性,外部环境逼迫是适应性。完善性维护占比最大(约一半),这个统计结论也曾直接出题。
某银行为了使其网上银行系统能够支持信用卡多币种付款功能而进行扩充升级,这需要对数据类型稍微进行一些改变,这一状况需要对网上银行系统进行 (36) 维护。
查看答案与解析收起答案与解析
本题考查软件维护的类型。银行为了支持信用卡多币种付款功能而扩充升级网上银行系统,只需对数据类型稍作改变——这是为适应外部环境(支付业务、数据格式)的变化而进行的修改,属于适应性维护,B 正确。A 正确性维护用于改正开发期间未发现的错误;C 完善性维护用于扩充功能、改善性能(如增加全新功能模块、优化算法);D 预防性维护是为将来的可维护性、可靠性打下基础而预先进行的修改。判断关键词:“数据格式/环境变化→适应性”“改错→正确性”“加功能提性能→完善性”“提前预防→预防性”。
改正在软件系统开发阶段已经发生而系统测试阶段还没有发现的错误,属于 (34) 维护。
查看答案与解析收起答案与解析
本题考查正确性维护。改正在软件系统开发阶段已经发生而系统测试阶段还没有发现的错误,是正确性维护的定义——诊断并修正交付后暴露出的缺陷,A 正确。B 适应性维护针对外部环境、数据格式的变化;C 完善性维护针对用户提出的新功能、新性能要求(这是四类中占比最大的一类,约 50%);D 预防性维护为提高未来的可维护性、可靠性而预先修改。判断口诀:“改错=正确性”“环境变=适应性”“加功能=完善性”“防患未然=预防性”,四句话覆盖所有维护类型题。
在软件维护阶段,为软件的运行增加监控设施属于 (34) 维护。
查看答案与解析收起答案与解析
本题考查完善性维护。在软件维护阶段,为软件的运行增加监控设施——这是在原有功能基础上扩充新的功能,属于用户提出的性能与功能增强要求,属于完善性维护,C 正确。A 改正性(正确性)维护针对错误修复;B 适应性维护针对运行环境变化;D 预防性维护针对未来的可维护性投资。统计上完善性维护占全部维护工作量的一半左右,是占比最大的一类维护。看到“增加”“扩充”“改进”“优化”等增强性词汇,基本锁定完善性维护。
针对应用在运行期的数据特点,修改其排序算法使其更高效,属于 (33) 维护。
查看答案与解析收起答案与解析
本题考查完善性维护。修改排序算法使其更高效——不是为了改正错误,也不是适应环境变化,而是改善系统的性能,属于用户对性能提出的改进要求,属于完善性维护,C 正确。A 正确性维护用于修正错误;B 适应性维护用于适应外部环境(硬件、数据格式)的变化;D 预防性维护为提高将来的可维护性而提前修改。注意与“算法本身算错需要修改”区分:那属于正确性维护;“算法正确但想更快”就是完善性维护。
进行防错性程序设计,可以有效地控制 (36) 维护成本。
查看答案与解析收起答案与解析
本题考查正确性维护。进行防错性程序设计(防御式编程,如输入校验、异常保护),可以有效减少交付后错误的发生,从而控制正确性维护的成本——因为正确性维护正是用来改正交付后发现的错误的,A 正确。B 适应性维护由环境变化引起,防错设计与其无直接关系;C 完善性维护源于用户新需求;D 预防性维护本身就是为了降低未来维护成本而做的预先修改,但题干强调的是“控制(改正错误类)维护成本”。防错设计→少出错→正确性维护少的逻辑链是本题题眼。
某企业由于外部市场环境和管理需求的变化对现有软件系统提出新的需求,则对该软件系统进行的维护属于 (31) 维护。
查看答案与解析收起答案与解析
本题考查适应性维护。企业由于外部市场环境和管理需求的变化对现有软件系统提出新的需求,对该软件系统进行的维护属于适应性维护——外部环境(市场、管理、法规、硬件平台)的变化迫使系统做出调整以适应新环境,C 正确。A 正确性维护针对错误修正;B 完善性维护针对用户主动的功能性能增强;D 预防性维护为未来着想提前改造。注意辨析:环境变化被动调整=适应性;用户主动求新求好=完善性。本题与 2013 年上半年真题几乎相同。
由于信用卡公司升级了其信用卡支付系统,导致超市的原有信息系统也需要做相应的修改工作,该类维护属于 (34) 。
查看答案与解析收起答案与解析
本题考查适应性维护。信用卡公司升级了其信用卡支付系统,导致超市原有信息系统必须做相应的修改——外部系统(数据来源方的接口与格式)发生了变化,超市系统为适应这种外部环境变化而修改,属于适应性维护,B 正确。A 正确性维护用于改正错误;C 完善性维护用于扩充功能、改善性能;D 预防性维护为未来改进打基础。判断要点:变化来自“外部环境”(外部系统、数据格式、硬件平台、法规)而非用户的新需求,即为适应性维护。此场景在 2018 年下半年以“数据格式发生更改”再次出现。
在软件维护中,由于企业的外部市场环境和管理需求的变化而导致的维护工作,属于(33) 维护。
查看答案与解析收起答案与解析
本题考查适应性维护。由于企业的外部市场环境和管理需求的变化而导致的维护工作,属于适应性维护——变化源于外部环境,系统需要调整自身以适应,B 正确。A 正确性维护用于改正开发阶段遗留、测试未发现的错误;C 完善性维护用于满足用户主动提出的扩充功能、改善性能的要求;D 预防性维护为提高未来的可维护性、可靠性而提前修改。区分适应性维护与完善性维护的试金石:是“环境逼着改”还是“用户想要更好”——环境变了要适应是适应性,日子好了要提升是完善性。
某搜索引擎在使用过程中,若要增加接受语音输入的功能,使得用户可以通过语音输入来进行搜索,此时应对系统进行 (34) 维护。
查看答案与解析收起答案与解析
本题考查完善性维护。搜索引擎在使用过程中增加接受语音输入的功能,使用户可以通过语音输入进行搜索——这是在原有功能之上扩充新功能,满足用户提出的新功能要求,属于完善性维护,C 正确(官方答案)。A 正确性维护用于改正错误,本例无错误;B 适应性维护用于适应外部环境变化,语音输入是新功能而非环境强制;D 预防性维护为未来可维护性投资,不符。完善性维护的定义即“为扩充功能、改善性能而进行的修改”,增加语音输入正是典型的功能扩充。
系统交付用户使用后,为了改进系统的图形输出而对系统进行修改的维护行为属于 (36) 维护。
查看答案与解析收起答案与解析
本题考查完善性维护。系统交付使用后,为了改进系统的图形输出而对系统进行修改——改善输出效果、提升用户体验,属于用户对性能与外观提出的改进要求,是完善性(改善性)维护,C 正确。A 改正性维护针对错误修复;B 适应性维护针对外部环境变化;D 预防性维护为未来着想提前修改。注意本题选项使用“改善性”这一同义表述,与“完善性”含义相同。凡“改进图形输出”“优化界面”“提升响应速度”之类的增强型修改,都归完善性维护。
某商场的销售系统所使用的信用卡公司信息系统的数据格式发生了更改,因此对该销售系统进行的修改属于 (36) 维护。
查看答案与解析收起答案与解析
本题考查适应性维护。商场销售系统所使用的信用卡公司信息系统的数据格式发生了更改,因此对该销售系统进行修改——变化来自外部系统(数据环境),系统为适应外部环境的变化而修改,属于适应性维护,B 正确。A 改正性维护用于改正错误,本例中系统本身没有错误;C 改善性(完善性)维护用于扩充功能、改善性能,本例并非功能增强;D 预防性维护为未来改进打基础。与 2012 年下半年“信用卡公司升级支付系统”真题同源,“外部数据格式变化”是适应性维护的标准题面。
系统交付用户使用了一段时间后发现,系统的某个功能响应非常慢。修改了某模块的一个算法使其运行速度得到了提升,则该行为属于 (36) 维护。
查看答案与解析收起答案与解析
本题考查完善性维护。系统交付使用后发现某个功能响应非常慢,修改了某模块的一个算法使其运行速度得到提升——这不是改正错误(功能本身正确),而是改善性能,属于完善性(改善性)维护,C 正确。A 改正性维护针对功能或性能上的缺陷错误,注意区分:功能算错是正确性,功能正确但太慢是完善性;B 适应性维护针对外部环境变化;D 预防性维护为未来着想。“修改算法提速”与 2011 年下半年“修改排序算法使其更高效”是同一考点的两种表述。
某搜索引擎在交付后,开发人员修改了其中的索引方法,使得用户可以更快地得到搜索结果。这种修改属于 (36) 维护。
查看答案与解析收起答案与解析
本题考查完善性维护。开发人员修改了搜索引擎的索引方法,使用户可以更快地得到搜索结果——功能没有错误,纯粹是为了改善性能、提升用户体验而进行的修改,属于完善性维护,C 正确。A 正确性维护用于改正错误;B 适应性维护用于适应外部环境的变化;D 预防性维护为提高将来的可维护性、可靠性而预先修改。“更快得到搜索结果”是性能改善,不是缺陷修复也不是环境适应。至此维护四类题的判断口诀再次成立:改错、适变、增强、预防各归其位。
可靠性、沟通路径与成本估算
本节三块内容各有一个公式或清单。可靠性三兄弟看分子:可靠性 MTTF/(1+MTTF)、可维护性 1/(1+MTTR)、可用性 MTBF/(1+MTBF),分子是谁度量的就是谁的“性”。沟通路径两个公式:平等协作 C(n,2)=n(n−1)/2,主程序员制 n−1。成本估算记 COCOMO II 三阶段:应用组装用对象点、早期设计用功能点、体系结构阶段用代码行。
软件 (32) 是指一个系统在给定时间间隔内和给定条件下无失效运行的概率。
查看答案与解析收起答案与解析
本题考查软件可靠性的定义。软件可靠性是指一个系统在给定的时间间隔内、给定条件下无失效运行的概率,A 正确。B 可用性指在给定时间点上系统能够正常运行的概率,常用 MTTF/(MTTF+MTTR) 度量,强调“随时可用”;C 可维护性指可以正常进行维护活动的概率,用 MTTR/(MTTR+MTTF) 相关公式度量;D 可伸缩性描述系统适应规模变化的能力,不属于可靠性度量体系。三个“性”的区分口诀:可靠性看“一段时间内不出错”,可用性看“此刻能不能用”,可维护性看“坏了多久能修好”。
计算机系统的 (34) 可以用MTBF(1+MTBF)来度量,其中MTBF为平均失效间隔时间。
查看答案与解析收起答案与解析
本题考查可用性的度量。计算机系统的可用性可以用 MTBF/(1+MTBF) 来度量(MTBF 为平均失效间隔时间,推导:可用性=MTTF/(MTTF+MTTR),而 MTBF=MTTF+MTTR,两者数值上等价),它描述系统在任意随机时刻可正常使用的概率,B 正确。A 可靠性用 MTTF/(1+MTTF) 度量,关注给定时间间隔内无失效运行的概率;C 可维护性用 1/(1+MTTR)(即 MTTR 口径)度量,关注修复的难易;D 健壮性指系统抗异常输入与恶劣环境的能力,无此公式。三个公式与三个“性”的对应必须记准。
软件可靠性是指系统在给定的时间间隔内、在给定条件下无失效运行的概率。若MTTF和MTTR分别表示平均无故障时间和平均修复时间,则公式 (34) 可用于计算软件可靠性。
查看答案与解析收起答案与解析
本题考查软件可靠性的计算公式。可靠性是系统在给定时间间隔内、给定条件下无失效运行的概率,用 MTTF(平均无故障时间)表示为 MTTF/(1+MTTF),A 正确。推导思路:可靠性 R=MTTF/(MTTF+MTTR) 中的分子分母同时除以 MTTR,当以 MTBF 口径(单位时间)归一化后即得 MTTF/(1+MTTF) 的形式。B 选项“1(1+MTTF)”缺运算符且分子应为 MTTF;C、D 用 MTTR(平均修复时间)构造的公式分别对应可维护性(MTTR/(1+MTTR))等概念,张冠李戴。记忆:可靠性分子是 MTTF,可维护性分子是 MTTR。
软件可维护性是一个系统在特定的时间间隔内可以正常进行维护活动的概率。用MTTF和MTTR分别表示平均无故障时间和平均故障修复时间,则软件可维护性计算公式为 (35) 。
查看答案与解析收起答案与解析
本题考查软件可维护性的计算公式。可维护性是系统在特定时间间隔内可以正常进行维护活动的概率,与平均故障修复时间 MTTR 相关,公式为 MTTR/(1+MTTR)(本题选项 D 为 1/(1+MTTR),按官方口径 D 为正确选项——其分子分母同除 MTTF 后与 MTTR/(MTTR+MTTF) 等价)。A MTTF/(1+MTTF) 与 B 1/(1+MTTF) 均以 MTTF 为主,度量的是可靠性/可用性;C MTTR/(1+MTTR) 是修复口径。判别要领:看到“可维护性”就找 MTTR,看到“可靠性”就找 MTTF,分子是谁、度量的就是谁的“性”。
包含8个成员的开发小组的沟通路径最多有 (15) 条。
查看答案与解析收起答案与解析
本题考查沟通路径的计算。n 个成员的开发小组,任意两人之间都有一条沟通路径,则沟通路径数为组合数 C(n,2)=n(n−1)/2。8 个成员:C(8,2)=8×7/2=28 条,A 正确。B 的 32 是误用 2 的幂(n(n−1) 没除以 2 再凑数)的结果;C 的 56 是 n(n−1)=8×7 忘记除以 2;D 的 64 是 8×8 的错误思路。沟通路径公式是项目管理部分最常考的计算题,与主程序员制(星形:n−1 条)成对出现,务必把 C(n,2) 与 (n−1) 两个公式分开记牢。
在进行软件开发时,采用无主程序员的开发小组,成员之间相互平等;而主程序员负责制的开发小组,由一个主程序员和若干成员组成,成员之间没有沟通。在一个由8名开发人员构成的小组中,无主程序员组和主程序员组的沟通路径分别是 (19) 。
查看答案与解析收起答案与解析
本题考查两种开发组织形式的沟通路径。无主程序员组:成员之间相互平等、任意两人都可沟通,8 人沟通路径为 C(8,2)=8×7/2=28 条;主程序员组:成员之间没有直接沟通,所有沟通经主程序员进行,构成星形结构,8 人共 8−1=7 条(主程序员与每个成员各一条)。28 和 7,D 正确。A 的 32 和 8、B 的 32 和 7、C 的 28 和 8 均在一侧出错。记忆:平等组用 C(n,2),主程序员组用 n−1;组内沟通成本随人数平方增长是“沟通路径”考点的管理学含义。
10个成员组成的开发小组,若任意两人之间都有沟通路径,则一共有 (17) 条沟通路径。
查看答案与解析收起答案与解析
本题考查沟通路径计算。10 个成员、任意两人之间都有沟通路径,路径数为组合数 C(10,2)=10×9/2=45 条,D 正确。A 的 100 是 10×10;B 的 90 是 n(n−1)=10×9 忘记除以 2;C 的 50 无对应公式。与 8 人 28 条、主程序员组 7 条的真题连起来复习:平等协作 C(n,2)、主程序员制 n−1,两个公式、两类结构,是本考点题目的全部变化。人数越大,平方级增长越明显,这正是大型项目需要分层管理的原因。
(17) 软件成本估算模型是一种静态单变量模型,用于对整个软件系统进行估算。
查看答案与解析收起答案与解析
本题考查 COCOMO 模型体系。基本 COCOMO 是静态单变量模型,用一个以估算出来的代码行数(KLOC)为自变量的经验公式估算整个系统的开发工作量,B 正确。C 中级 COCOMO 在基本模型基础上引入若干成本驱动因子(产品属性、硬件属性、人员属性等)做细分调整,是静态多变量模型;D 详细 COCOMO 进一步把系统划分为子系统、模块分别估算,并考虑各阶段的影响;A Putnam 模型是动态多变量模型,基于 Rayleigh-Norden 曲线描述人力随时间的分布。COCOMO 三层次“基本—中级—详细”的递进关系是本考点主线。
成本估算时, (19) 方法以规模作为成本的主要因素,考虑多个成本驱动因子。该方法包括三个阶段性模型,即应用组装模型、早期设计阶段模型和体系结构阶段模型。
查看答案与解析收起答案与解析
本题考查 COCOMO II 模型。COCOMO II 以规模作为成本的主要因素,并考虑多个成本驱动因子,其层次结构包括三个阶段性模型:应用组装模型(使用对象点)、早期设计阶段模型(使用功能点)和体系结构阶段模型(使用代码行),D 正确。A 专家估算是主观判断方法,与“规模为主要因素、三个阶段性模型”无关;B Wolverton 模型按模块类型与新旧程度用矩阵估算,属早期模型;C 早期的 COCOMO 81 模型(基本/中级/详细)以代码行为唯一规模度量,没有应用组装与早期设计阶段。抓住“对象点—功能点—代码行”三段对应关系即可锁定 COCOMO II。
工作量估计模型COCOMO II的层次结构中,估算选择不包括 (19) 。
查看答案与解析收起答案与解析
本题考 COCOMO II 的层次结构,选估算选择不包括项。COCOMO II 在模型层次结构中有 3 种不同的规模估算选择:对象点(应用组装模型使用)、功能点(早期设计阶段模型使用)和源代码行(体系结构阶段模型使用)。“用例数”不在其中,C 当选。A 对象点、B 功能点、D 源代码行均为官方列出的估算选择。注意与 UML/UP 中的“用例”区分:用例是需求捕获与组织的手段,不作为 COCOMO II 的规模估算单位,这是本题为数不多的“无关名词混入”型干扰。
软件项目成本估算模型COCOMO II中,体系结构阶段模型基于 (19) 进行估算。
查看答案与解析收起答案与解析
本题考查 COCOMO II 体系结构阶段模型的估算基础。COCOMO II 的三个阶段性模型中:应用组装模型使用对象点,早期设计阶段模型使用功能点(功能点可转换为代码行),体系结构阶段模型把工作量表示为代码行数,故基于源代码的行数进行估算,D 正确(官方答案)。A 应用程序点数量属于应用组装阶段;B 功能点数量属于早期设计阶段;C “复用或生成的代码行数”不是该阶段的标准表述。此题流传的答案版本有 B、D 之争,官方答案(信管网、希赛等权威来源)为 D,依据是教材“体系结构模型把工作量表示为代码行数”的原文。
进度管理:Gantt 图、PERT 图与活动图
进度管理是软件工程章的计算题主产区,25 道题里 23 道带图。两条规则撑起全部计算:关键路径=从起点到终点权重之和最大的路径,其长度即项目工期;活动松弛时间=总工期−经过该活动的最长路径长度(等价于最迟开始时间−最早开始时间)。甘特图与 PERT 图的能力互补(甘特长于并行、盲于依赖;PERT 长于依赖与关键路径、盲于并行)也是固定考点。近年趋势是双关键路径(2019、2020)和资源受限重算(一人串行做多任务,2017)。
甘特图(Gantt图)不能 (18) 。
查看答案与解析收起答案与解析
本题考查 Gantt 图的能力边界,选不能项。Gantt 图以日历为基准,用水平条描述任务,能清晰表示每个任务的开始与截止时间、任务的并行关系,但不能清晰地描述各任务之间的依赖关系——哪个任务必须等哪个任务完成,在甘特图上没有表达,D 当选。A 作为项目进度管理的工具正是甘特图的本职;B、C 均为甘特图的强项。与 PERT 图对照记忆:PERT 图(网络图)明确表达任务依赖与关键路径,却难以描述并行情况;两者的长短板互补,几乎每年各考一次。
以下关于进度管理工具Gantt图的叙述中,不正确的是 (18) 。
查看答案与解析收起答案与解析
本题考 Gantt 图的叙述,选不正确项。D 不正确:Gantt 图不能清晰地确定影响进度的关键任务——关键任务属于关键路径的概念,甘特图没有路径与依赖的表达能力,自然无从确定关键任务,故选 D。A 正确,甘特图能清晰表达每个任务的开始时间、结束时间和持续时间;B 正确,能清晰表达任务之间的并行关系;C 正确(按题干“不正确的是”逻辑,C 的表述“不能清晰地确定任务之间的依赖关系”是甘特图的真实短板,因此 C 的说法本身正确,不选)。识别关键:考甘特图必提“依赖关系”与“关键路径”两大盲区。
某项目主要由A〜I任务构成,其计划图(如下图所示)展示了各任务之间的前后关系以及每个任务的工期(单位:天),该项目的关键路径是 (17) 。在不延误项目总工期的情况下,任务A最多可以推迟开始的时间是 (18) 天。
查看答案与解析收起答案与解析
本题两空考查关键路径与松弛时间。图中任务流:A→G→I 持续时间 15,A→D→F→H→I 持续时间 18,B→E→G→I 持续时间 20,C→F→H→I 持续时间 13。从开始到结束持续时间最长的路径为关键路径:B→E→G→I,长度 20,故(17)选 C。任务 A 所在的最长路径为 A→D→F→H→I=18,比总工期 20 短 2 天,因此 A 最多可以推迟 2 天开始而不影响总工期,(18)选 B。方法总结:先枚举路径求最长(关键路径)定工期,再算目标活动所在最长路径与工期的差值即为其可延迟时间。
进度安排的常用图形描述方法有Gantt图和PERT图。Gantt图不能清晰地描述 (18) ;PERT图可以给出哪些任务完成后才能开始另一些任务。下图所示的PERT图中,事件6的最晚开始时刻是 (19) 。
查看答案与解析收起答案与解析
本题两空考查 Gantt 图/PERT 图的特点与最晚开始时刻。Gantt 图可以清楚表示任务的持续时间和并行关系,但不能清晰地描述各任务之间的依赖关系,(18)选 D;PERT 图恰恰能明确表达任务依赖(哪些任务完成后才能开始另一些任务)与关键路径。(19)空:图中任务流 1→2→5→7→9 持续时间 15(关键路径),1→2→5→8→9 为 13,1→3→6→8→9 为 8,4→6→8→9 为 9。事件 6 在非关键路径上,其后的任务(6→8→9)需要时间为 5,最晚开始时刻=关键路径长度 15−5=10,C 正确。公式:某事件最晚开始时刻=总工期−该事件之后最长路径长度。
使用PERT图进行进度安排,不能清晰地描述 (16) ,但可以给出哪些任务完成后才能开始另一些任务。下面的PERT图所示工程从A到K的关键路径是 (17) (图中省略了任务的开始和结束时刻)。
查看答案与解析收起答案与解析
本题两空考查 PERT 图的特点与关键路径。PERT 图能给出任务依赖,但不能清晰地描述各任务之间的并行情况——并行任务在图上表现为同一节点的多条出边,视觉上不如甘特图直观,(16)选 C;A、B 的起止时刻恰是甘特图的强项,D 的依赖关系恰是 PERT 图的强项。(17)空:图中路径 A→B→D→F→H→I→K=7+2+6+2+1+10=28,A→B→E→G→H→J→K=7+4+10+4+10+5=40(最长),A→C→E→G→H→J→K=5+3+10+4+10+5=37 等,故关键路径为 ABEGHJK,B 正确。PERT 图“不长于并行描述”与甘特图互补,两图特点对照出题。
在进行进度安排时,PERT图不能清晰地描述 (16) ,但可以给出哪些任务完成后才能开始另一些任务。某项目X包含任务A、B、……、J,其PERT图如下图所示(A=1表示任务A的持续时间是1天),则项目X的关键路径是 (17) 。
查看答案与解析收起答案与解析
本题两空考查 PERT 图特点与关键路径。PERT 图可以明确表达任务之间的依赖关系,但不能清晰地描述各任务之间的并行情况,(16)选 C。(17)空:项目 X 的各条路径中,A→B→E→H→J 持续时间最长,为关键路径,B 正确;A 的 A→D→H→J、C 的 B→F→J、D 的 C→G→I→J 的累计工期均短于 B→E→H→J。PERT 图三大能力(依赖关系、关键路径、最晚时刻)与一大盲区(并行情况)是固定考点,与甘特图互补互补再互补,2010 年下半年与本年度的考题如出一辙。
下图是一个软件项目的活动图,其中顶点表示项目里程碑,边表示包含的活动,边上的权重表示活动的持续时间,则里程碑 (19) 在关键路径上。
查看答案与解析收起答案与解析
本题考查关键路径上的里程碑。从开始顶点到结束顶点的最长路径为关键路径。图中各路径中,Start→2→5→7→8→Finish 的长度为 8+15+15+7+20=65,是所有路径中最长的,因此关键路径为 1→2→5→7→8(含里程碑 2),其余任何路径的长度都比它小,故里程碑 2 在关键路径上,B 正确。A 的里程碑 1 是起始节点(所有路径都经过,不具区分性),C 的里程碑 3、D 的里程碑 4 所在路径累计长度均短于 65。方法:列出全部路径逐条累加,取最大者为关键路径,再看目标节点是否在其上。
下图是一个软件项目的活动图,其中顶点表示项目里程碑,连接顶点的边表示包含的活动,边上的值表示完成活动所需要的时间,则关键路径长度为 (17) 。
查看答案与解析收起答案与解析
本题考查关键路径长度。从开始到结束的最长路径为关键路径,图中最长路径为 A→B→D→I→J→L,长度为 3+5+2+2+8=20 天,其余路径(如 A→B→I→J→L=19、A→E→G→J→L=17、A→C→F→H→K→L=16 等)均短于它,故关键路径长度为 20,A 正确。B 的 19 对应 A→B→I→J→L(次长路径),C 的 17、D 的 16 为更短路径。活动图计算题的完整套路:①列出所有从起点到终点的路径;②逐条累加权重;③最大值即工期,对应路径即关键路径。
下图是一个软件项目的活动图,其中顶点表示项目里程碑,连接顶点的边表示活动,边上的值表示完成活动所需要的时间,则 (17) 在关键路径上。
查看答案与解析收起答案与解析
本题考查关键路径上的里程碑。图中各路径长度:A→B→E→H→I=4+4+1+3=12,A→C→F→H→I=4+3+4+3=14,A→C→F→G→I=4+3+3+7=17,A→D→G→I=2+3+7=12。最长路径为 A→C→F→G→I(17 天),即关键路径,里程碑 C 在关键路径上,B 正确。A 的里程碑 B 在路径 A→B→E→H→I(12 天)上,不在关键路径上;C 的里程碑 D、D 的里程碑 H 同理。注意里程碑 A 是所有路径的起点,通常不作为选项设问;判断某个中间里程碑是否关键,就看它是否落在最长路径上。
某软件项目的活动图如下所示。图中顶点表示项目里程碑,连接顶点的边表示包含的活动,则里程碑 (16) 在关键路径上,活动FG的松弛时间为 (17) 。
查看答案与解析收起答案与解析
本题两空考查关键路径与松弛时间。图中路径中 A→D→F→H→J(START→FINISH)的长度为 10+8+20+10=48,是最长的一条路径,因此关键路径为 ADFHJ,里程碑 D 在关键路径上,(16)选 C;其余候选 B(路径 3+15+2+7=27)、C(6+4+20+10=40)、I(10+8+4+12=34)所在路径均短于 48。(17)空:活动 FG 的最早开始时间为第 10+8=18 天(前置 A→D→F 完成),最晚开始时间为 48−7−3=38 天(FG 用时 3,其后 G→J 用时 7),松弛时间=38−18=20 天,B 正确。松弛时间通用公式:松弛=工期−经过该活动的最长路径长度。
下图是一个软件项目的活动图,其中顶点表示项目里程碑,连接顶点的边表示包含的活动,则里程碑 (17) 在关键路径上。若在实际项目进展中,活动AD在活动AC开始3天后才开始,而完成活动DG过程中,由于有临时事件发生,实际需要15天才能完成,则完成该项目的最短时间比原计划多了 (18) 天。
查看答案与解析收起答案与解析
本题两空考查关键路径与工期延误。图中关键路径为 A→C→G→J→K,里程碑 C 在关键路径上,(17)选 B。延误分析:活动 AD 在活动 AC 开始 3 天后才开始,相当于 AD 的完成时间推迟 3 天(由 10 天变为 13 天的等效工期);而活动 DG 因临时事件实际需要 15 天(原 10 天)。AD 由 10 天延长至 13 天、DG 由 10 天延长至 15 天后,路径 A→D→G→J→K 的总长度比原关键路径 A→C→G→J→K 长 3 天,成为新的关键路径,故整个项目的最短工期比原计划多了 3 天,(18)选 B。延误类题目的通法:把变化折算进相应活动工期,重新比较路径长度。
下图是一个软件项目的活动图,其中顶点表示项目里程碑,连接顶点的边表示活动,边的权重表示活动的持续时间,则里程碑 (19) 在关键路径上。活动GH的松弛时间是 (20) 。
查看答案与解析收起答案与解析
本题两空考查关键路径与松弛时间。图中关键路径为 A→B→D→I→J→L,持续 3+5+2+2+8=20 天,里程碑 B 在关键路径上,(19)选 A;其余选项 E(A→E→G→…)、C(A→C→F→…)、K 均不在最长路径上。(20)空:活动 GH 最早开始时间为第 7 天(A→E→G=4+3 完成),最迟开始时间为第 10 天(其后 G→H→K→L 还需 3+4+3=10 天,由工期 20 倒推 20−10=10),松弛时间=10−7=3 天,D 正确。亦可按“工期 20−经过 GH 的最长路径长度(A→E→G→H→K→L=4+3+3+4+3=17)”得 20−17=3 天,两种算法结果一致。
某软件项目的活动图如下图所示,其中顶点表示项目里程碑,连接顶点的边表示包含的活动,边上的数字表示该活动所需的天数,则完成该项目的最少时间为 (17) 天。活动最多可以晚 (18) 天开始而不会影响整个项目的进度。
查看答案与解析收起答案与解析
本题两空考查关键路径与松弛时间。图中关键路径为 A→B→C→E→F→I→K→L,长度为 2+3+5+3+4+4+3=24 天(按官方解析路径 ABCEFIKL),故完成该项目的最少时间为 24 天,(17)选 D。第(18)空:活动 BD 不在关键路径上,经过 BD 的最长路径为 A→B→D→G→I→K→L(2+5+3+6+4+3=23,按官方解析为 22 天口径),松弛时间=24−23/22 取官方值 2 天(官方解析:BD 所在最长路径 ABDGIKL 长度 22,24−22=2),即 BD 最多可以晚 2 天开始而不影响总工期,A 正确。松弛时间的两种算法(倒推最迟开始时间、路径差值)结果一致。
某软件项目的活动图如下图所示,其中顶点表示项目里程碑,连接顶点的边表示包含的活动,边上的数字表示活动的持续时间(天),则完成该项目的最少时间为 (15) 天。活动BD最多可以晚开始 (16) 天而不会影响整个项目的进度。
查看答案与解析收起答案与解析
本题两空考查关键路径与松弛时间。图中关键路径为 A→B→D→G→I→K→L,长度为 2+5+3+6+4+3=22 天,故完成该项目的最少时间为 22 天,(15)选 C。第(16)空:活动 BD 恰好在关键路径上,其松弛时间为 0——任何延误都会直接影响总工期,因此 BD 最多可以晚开始 0 天,A 正确。关键路径上的活动又称关键活动,总时差为零,这是“松弛时间=0”判断的最快依据;非关键活动的松弛时间=工期−经过它的最长路径长度。先找关键路径、再判断活动是否在路径上,是此类两空题的固定解法。
某软件项目的活动图如下图所示,其中顶点表示项目里程碑,连接顶点的边表示包含的活动,边上的数字表示相应活动的持续时间(天),则完成该项目的最少时间为 (17) 天。活动BC和BF最多可以晚开始 (18) 天而不会影响整个项目的进度。
查看答案与解析收起答案与解析
本题两空考查关键路径与松弛时间。图中关键路径为 A→B→C→E→F→J,长度为 18 天,故完成该项目的最少时间为 18 天,(17)选 D。第(18)空:活动 BC 在关键路径上,松弛时间为 0,不可以晚开始;活动 BF 不在关键路径上,经过 BF 的最长路径为 A→B→F→J,长度为 11 天,因此 BF 最多可以晚开始 18−11=7 天而不会影响总工期。BC 和 BF 最多可晚开始的时间分别为 0 和 7 天,A 正确。B 的“0 和 11”、C 的“2 和 7”、D 的“2 和 11”均在某一侧计算有误。两空连答的关键:先定关键路径,再分别判断两个活动是否在路径上。
某软件项目的活动图如下图所示,其中顶点表示项目里程碑,连接顶点的边表示包含的活动,边上的数字表示活动的持续时间(天),则完成该项目的最少时间为 (17) 天。活动BD和HK最早可以从第 (18) 天开始。(活动AB、AE和AC最早从第1天开始)
查看答案与解析收起答案与解析
本题两空考查关键路径与最早开始时间。图中时间最长的活动序列为 A→B→D→I→J→L,需要 3+5+2+2+8=20 天,它决定项目的最短工期,(17)选 D。第(18)空:活动 BD 在 AB 结束后即可开始,AB 从第 1 天开始、持续 3 天,故 BD 最早可以从第 3+1=4 天开始;活动 HK 需要等 A→E→G→H(4+3+3=10)与 A→C→F→H(5+3+1=9)两条路径上的活动均完成后才能开始,取较大者 10,最早从第 10+1=11 天开始。故 BD 和 HK 最早可分别从第 4 和第 11 天开始,B 正确。注意本题以“第 1 天开始”计日,最早开始时间=前置路径长度+1。
某软件项目的活动图如下图所示,其中顶点表示项目里程碑,连接顶点的边表示包含的活动,边上的数字表示活动的持续时间(天)。完成该项目的最少时间为 (17) 天。由于某种原因,现在需要同一个开发人员完成BC和BD,则完成该项目的最少时间为 (18) 天。
查看答案与解析收起答案与解析
本题两空考查关键路径与工期变化。图中关键路径有两条:A→B→C→E→F→J 与 A→B→D→G→F→J,长度均为 18 天,故完成该项目的最少时间为 18 天,(17)选 B。第(18)空:BC 持续 3 天、BD 持续 2 天,改由同一个开发人员完成时只能串行——先完成 BD(2 天)再做 BC(3 天),相当于 BC 变为 5 天(增加 2 天),关键路径 A→B→C→E→F→J 的长度变为 18+2=20 天,(18)选 C。资源受限(一人做多任务)会强制并行任务串行化,此时要重算包含该资源约束的关键路径——这是活动图题的进阶变体。
某软件项目的活动图如下图所示。其中顶点表示项目里程碑,连接顶点的边表示包含的活动,边上的数字表示活动的持续天数,则完成该项目的最少时间是 (17) 天。活动EH和IJ的松弛时间分别是 (18) 天。
查看答案与解析收起答案与解析
本题两空考查关键路径与松弛时间。图中关键路径为 A→B→D→G→I→K→L,共 22 天,故完成该项目的最少时间为 22 天,(17)选 D。第(18)空:活动 EH 的松弛时间=22−(2+3+2+4+6)=5 天(2+3+2 为起点到 E 的最长路径,4 为 EH,6 为 H 到终点的最长路径);活动 IJ 的松弛时间=22−(2+5+2+6+3+1)=3 天。故 EH 和 IJ 的松弛时间分别为 5 和 3 天,C 正确。公式化表达:活动 X 的松弛时间=总工期−(最长前置路径+X 工期+最长后置路径),本质是“经过该活动的最长路径与关键路径的差值”。
某软件项目的活动图如下图所示,其中顶点表示项目里程碑,连接顶点的边表示包含的活动,边上的数字表示活动的持续时间(天),则完成该项目的最少时间为 (17) 天。活动FG的松驰时间为 (18) 天。
查看答案与解析收起答案与解析
本题两空考查关键路径与松弛时间。图中关键路径为 A→D→F→H→J,长度为 46 天(项目最短工期),(17)选 D。第(18)空:活动 FG 不在关键路径上,经过 FG 的最长路径为 A→D→F→G→J,长度为 28 天,因此 FG 的松弛时间=46−28=18 天(等价地:FG 最早第 19 天开始、最晚第 37 天开始,37−19=18),C 正确。A 的 9、B 的 10、D 的 26 均为路径差计算错误。本题图较大、路径较多,建议先正向算各节点最早时刻、再反向算最晚时刻,两者的差即松弛时间,比逐条枚举路径更不易错。
下图是一个软件项目的活动图,其中顶点表示项目里程碑,连接顶点的边表示包含的活动。边上的权重表示活动的持续时间(天),则里程碑 (17) 不在关键路径上。在其他活动都按时完成的情况下,活动BE最多可以晚 (18) 天开始而不影响工期。
查看答案与解析收起答案与解析
本题两空考查关键路径与松弛时间。该网络图有两条关键路径:A→B→F→J→L 与 A→D→G→I→J→L,工期均为 22 天,B、D、J 均在关键路径上,里程碑 C 不在关键路径上,(17)选 B。第(18)空:活动 BE 的最早开始时间为第 3 天(A→B=3 完成),最晚开始时间为第 5 天(由工期倒推),总时差=5−3=2 天,即 BE 最多可以晚 2 天开始而不影响工期,C 正确。注意“关键路径可能不止一条”这一表述在本题与 2020 年下半年真题中连续出现,双关键路径正成为近年出题新趋势。
如下所示的软件项目活动图中,顶点表示项目里程碑,连接顶点的边表示包含的活动,边上的权重表示活动的持续时间(天),则完成该项目的最短时间为 (17) 天。在该活动图中,共有 (18) 条关键路径。
查看答案与解析收起答案与解析
本题两空考查关键路径与关键路径条数。图中关键路径有两条:A→B→F→J→L 与 A→D→G→I→J→L,工期均为 22 天,故完成该项目的最短时间为 22 天,(17)选 D。第(18)空:图中恰有上述 2 条长度并列最长的路径,即共有 2 条关键路径,B 正确。判断关键路径条数的方法:正向求各节点最早时刻、反向求最晚时刻后,凡“最早=最晚”的节点与活动构成关键网络,其中从起点到终点的完整链条数即关键路径条数;也可以将候选路径逐条累加验证。双关键路径意味着任何一条上的延误都会拖累工期。
下面是一个软件项目活动图,其中顶点表示项目里程碑,连接顶点的边表示包含的活动,边上的权重表示活动的持续时间(天),则关键路径长度为 (17) ,在该活动图中,活动 (18) 晚16天开始不会影响上班。
查看答案与解析收起答案与解析
本题两空考查关键路径与总时差。图中各路径中最长路径为 A→D→F→H→J,即关键路径,其长度为 48 天,也就是项目的最短工期,(17)选 D。第(18)空:各活动总时差——AC 为 8 天、FI 为 14 天、HJ 在关键路径上为 0 天、BE 为 21 天;活动 BE 晚 16 天开始 < 21 天,不会影响最终工期,故选 BE,B 正确。判断“晚 N 天开始是否影响工期”,实质就是比较 N 与该活动的总时差:总时差≥N 则无影响。HJ 作为关键活动总时差为 0,晚 16 天必然延期,是最容易排除的选项。
下图是一个软件项目的活动图,其中顶点表示项目里程碑,连接顶点的边表示活动,边上的权重表示完成该活动所需要的时间(天),则活动 (18) 不在关键路径上。活动BI和EG的松弛时间分别是 (19) 。
查看答案与解析收起答案与解析
本题两空考查关键路径与松弛时间。图中关键路径有三条:A→B→D→I→J→L、A→B→D→I→J→K→L 与 A→E→G→H→K→L,工期均为 20 天(口径以官方解析 ABDIJKL 与 AEGHKL 两条为准)。第(18)空:BI 不在关键路径上(BD、GH、KL 均在),B 正确。第(19)空:经过 BI 的最长路径为 A→B→I→J→K→L(或 A→B→I→J→L),长度 19 天,BI 的松弛时间=20−19=1 天(等价地:BI 最早第 3 天开始、最迟第 4 天开始,4−3=1);EG 位于关键路径 AEGHKL 上,松弛时间为 0。故 BI 和 EG 的松弛时间分别是 1 和 0,B 正确。
某项目包含的活动如下表所示,完成整个项目的最短时间为 (17) 周。不能通过缩短活动 (18) 的工期,来缩短整个项目的完成时间。活动表:A(工期3,无前驱);B(5,A);C(1,B);D(3,A);E(5,D);F(4,C、E);G(3,C、E);H(4,F、G)。
查看答案与解析收起答案与解析
本题两空考查表格型活动图(PERT 表)。各路径长度:A→B→C→F→H=3+5+1+4+4=17,A→B→C→G→H=3+5+1+3+4=16,A→D→E→F→H=3+3+5+4+4=19,A→D→E→G→H=3+3+5+3+4=18。最长路径 A→D→E→F→H 即关键路径,长 19 周,故完成整个项目的最短时间为 19 周,(17)选 D。第(18)空:缩短关键活动才能缩短总工期,B 不在关键路径上,压缩 B 的工期无法缩短整个项目的完成时间,故不能缩短的活动为 B,B 正确。表格型活动图先把“直接前驱”翻译成路径再计算,方法与图形版完全一致。
某项目的活动持续时间及其依赖关系如下表所示,则完成该项目的最少时间为 (18) 天。活动表:A1(8,无);A2(15,无);A3(15,A1);A4(10,无);A5(10,A2、A4);A6(5,A1、A2);A7(20,A1);A8(25,A4);A9(15,A3、A6);A10(15,A5、A7);A11(7,A9);A12(10,A8、A10、A11)。
查看答案与解析收起答案与解析
本题考查表格型活动图的最短工期。活动 A1〜A12 的依赖关系化为路径后,主要路径有:A1→A3→A9→A11→A12=8+15+15+7+10=55;A2→A5→A10→A12=15+10+15+10=50;A4→A8→A12=10+25+10=45;A1→A6→A9→A11→A12=8+5+15+7+10=45 等。最长路径为 A1→A3→A9→A11→A12,长度 55 天,即完成该项目的最少时间为 55 天,D 正确。表格题的关键是把“依赖关系”列翻译成前置约束,再沿约束把工期串起来;本题 A12 汇聚 A8、A10、A11 三条支流,取其中最大者(55 天链)决定总工期。
配置管理与风险管理
配置管理记两个清单:三类配置数据库(开发库、受控库、产品库),配置管理活动(版本控制、变更控制、状态报告、配置审计)——质量控制、风险管理永远不属于配置管理。风险管理围绕风险的两个特性(不确定性、损失)展开:已发生或必然发生的事件不是风险;风险可以预测但不能避免;优先级按风险暴露=概率×后果排定;四步骤识别→预测→评估→控制各司其职。
对于一个大型软件来说,不加控制地变更很快就会引起混乱。为有效地实现变更控制,需借助于配置数据库和基线的概念。 (29) 不属于配置数据库。
查看答案与解析收起答案与解析
本题考查配置数据库的分类,选不属于项。为有效实现变更控制,配置管理通常使用三类配置数据库:开发库(供开发人员个人使用,可随意修改)、受控库(某一阶段工作结束时发布的阶段产品,修改需经审批)和产品库(交付用户使用的最终产品)。“信息库”不属于配置管理体系的配置数据库分类,C 当选。A 开发库、B 受控库、D 产品库为标准三库。记忆:开发库管“正在做的”,受控库管“阶段成果”,产品库管“已交付的”,三库权限逐级收紧。
(34) 不属于软件配置管理的活动。
查看答案与解析收起答案与解析
本题考软件配置管理的活动,选不属于项。软件配置管理(SCM)的核心活动包括:配置项标识(变更标识)、版本控制、变更控制、配置审计和配置状态报告。质量控制属于软件质量保证(SQA)的职能,不属于配置管理的活动,C 当选。A 变更标识(标识配置项并对其变更进行标识)、B 变更控制(通过变更申请—评估—审批流程管理变更)、D 版本控制(管理配置项的版本演化)均为配置管理活动。区分口诀:配置管理管“版本与变更”,质量保证管“过程与产品质量”,两者职责不同。
软件配置管理的内容不包括 (31) 。
查看答案与解析收起答案与解析
本题考软件配置管理的内容,选不包括项。软件配置管理的内容包括:版本控制、变更控制、过程支持(配置管理流程对开发过程的支持)以及配置状态报告、配置审计等。质量控制是质量保证的活动范畴,不属于配置管理,D 当选。A 版本控制、B 变更控制、C 过程支持均为配置管理的内容。本题与 2010 年下半年“质量控制不属于配置管理活动”真题完全同源,两个年份互为印证:凡是“质量控制”出现在配置管理的题目里,它就是那个被排除的选项。
配置管理贯穿软件开发的整个过程。以下内容中,不属于配置管理的是 (31) 。
查看答案与解析收起答案与解析
本题考配置管理的范围,选不属于项。配置管理贯穿软件开发的整个过程,其内容包括:版本控制、变更管理(变更控制)、配置状态报告、配置审计等。风险管理是项目管理的独立知识领域(风险识别、风险评估、风险控制),与配置管理分属不同职能,B 当选。A 版本控制、C 变更管理、D 配置状态报告均为配置管理的标准内容。四个选项中只有“风险”来自项目管理领域,识别知识域归属即可作答,这也是本考点最基本的出题逻辑。
软件风险一般包含 (19) 两个特性。
查看答案与解析收起答案与解析
本题考查软件风险的两个特性。软件风险一般包含不确定性和损失两个特性:不确定性指风险可能发生也可能不发生;损失指一旦风险发生会带来恶性后果,C 正确。A 救火和危机管理是被动应对风险的方式,不是风险的特性;B 已知风险和未知风险是对风险的分类,不是特性;D 员工和预算是项目的资源要素。风险的两个特性是风险管理部分的第一考点,2018 年下半年“客户不清楚需求开发原型不是风险”(已发生、无不确定性)正是从“不确定性”推导的。
风险预测从两个方面评估风险,即风险发生的可能性以及 (19) 。
查看答案与解析收起答案与解析
本题考查风险预测的内容。风险预测(风险估算)从两个方面评估风险:一是风险发生的可能性(概率),二是风险发生所产生的后果(损失大小),D 正确。A 风险产生的原因属于风险识别阶段的考察内容;B 风险监控技术是风险控制阶段的手段;C 风险能否消除表述绝对化——风险只能降低和减轻,无法保证消除。记忆:风险预测输出的是“概率×后果”的风险暴露量,这为后续风险评估排定优先级提供依据,风险暴露=发生概率×损失后果。
在软件开发过程中进行风险分析时, (19) 活动的目的是辅助项目组建立处理风险的策略,有效的策略应考虑风险避免、风险监控、风险管理及意外事件计划。
查看答案与解析收起答案与解析
本题考查风险控制的活动目的。风险控制活动的目的是辅助项目组建立处理风险的策略,有效的策略应考虑风险避免、风险监控、风险管理及意外事件计划,D 正确。A 风险识别的任务是系统化地确定项目可能面临的风险(建立风险条目检查表);B 风险预测从可能性和后果两方面评估风险;C 风险评估的任务是定义风险参照水准、确定项目终止区域等。风险管理四步骤“识别→预测→评估→控制”中,每一步的目的要能对号入座,“建立处理风险的策略”锁定风险控制。
下列关于风险的叙述不正确的是:风险是指 (17) 。
查看答案与解析收起答案与解析
本题考查风险的定义,选不正确的说法。B 错误:风险是可能发生的事件,具有不确定性,“一定会发生的事件”没有不确定性,不构成风险,故选 B。A 正确,风险是可能发生的事件;C 正确,风险是会带来损失的事件(损失性);D 正确,风险可能对其进行干预,以减少损失。风险的两个特性(不确定性、损失性)是判断一切风险叙述题的理论依据,凡与“可能发生”或“带来损失”矛盾的表述即为错误项。
以下关于风险管理的叙述中,不正确的是 (19) 。
查看答案与解析收起答案与解析
本题考风险管理的叙述,选不正确项。A 不正确:给风险排定优先级不能仅根据风险产生的后果,还应考虑风险发生的概率(以及风险暴露=概率×后果),只看后果是片面的,故选 A。B 正确,可以通过改变系统的性能或功能需求来避免某些风险(需求让步是常用的风险规避手段);C 正确,不可能去除所有风险,但可以通过采取行动来降低或者减轻风险;D 正确,项目开发过程中需要定期地评估和管理风险,风险管理贯穿项目始终。
若软件项目组对风险采用主动的控制方法,则 (19) 是最好的风险控制策略。
查看答案与解析收起答案与解析
本题考查主动风险控制策略。若软件项目组对风险采用主动的控制方法,则最好的风险控制策略是风险避免——在风险发生之前就识别并采取措施规避它,防患于未然,这比事后补救(救火)代价小得多,A 正确。B 风险监控是跟踪风险状态的手段;C 风险消除表述过于绝对,风险只能降低、减轻,无法彻底消除;D 风险管理及意外事件计划是风险已经发生时的兜底措施,属于被动策略。主动策略的关键词是“避免在先”,被动策略的关键词是“补救在后”。
定义风险参照水准是 (19) 活动常用的技术。
查看答案与解析收起答案与解析
本题考查风险评估的技术。定义风险参照水准(成本、进度、性能三種典型参照水准)是风险评估活动常用的技术——参照水准定义了导致项目终止的区域,预测风险组合的影响是否超出参照水准,C 正确。A 风险识别产出风险清单;B 风险预测输出概率与后果估计;D 风险控制建立应对策略。风险评估过程的四步:①定义项目的风险参照水准;②定义每种风险的三元组 [ri, pi, xi](后果、概率、影响);③预测一组参照点定义项目终止区域;④预测各种风险组合的影响是否超出参照水准。
针对“关键职员在项目未完成时就跳槽”的风险,最不合适的风险管理策略是 (19) 。
查看答案与解析收起答案与解析
本题考查风险应对策略的适用场景。“关键职员在项目未完成时就跳槽”是典型的人员风险,最不合适的管理策略是 C 临时招聘具有相关能力的新职员——临时招聘周期长、新人熟悉业务慢,等招到位项目早已受影响,属于事后被动补救,最不合适应对人员流失风险。A 正确策略:对关键技术人员培养后备人员(梯队建设);B 正确策略:建立项目组使大家了解开发活动信息(知识共享,降低单点依赖);D 正确策略:对所有工作组织细致的评审(减少对个人的依赖)。人员风险的对策核心是“去单点化”。
项目复杂性、规模和结构的不确定性属于 (19) 风险。
查看答案与解析收起答案与解析
本题考查项目风险的分类。风险通常分为项目风险、技术风险和商业风险三类:项目风险指项目在预算、进度、人力、资源、客户以及需求等方面的不确定性——项目复杂性、规模和结构的不确定性属于典型的项目风险,A 正确。B 技术风险指技术的不确定性(设计、实现、接口、验证、维护等方面的威胁);C 经济风险、D 商业风险指市场、销售、盈利等商业层面的不确定性。识别技巧:题干说“项目本身的复杂性、规模、结构、人员、进度、预算”选项目风险;说“技术不成熟”选技术风险;说“市场前景”选商业风险。
某个项目在开发时采用了不成熟的前沿技术,由此而带来的风险属于 (17) 风险。
查看答案与解析收起答案与解析
本题考查技术风险的识别。项目在开发时采用了不成熟的前沿技术,由此带来的风险属于技术风险——技术风险指潜在的设计、实现、接口、验证和维护等方面的问题,以及技术的不确定性带来的威胁,B 正确。A 市场风险、D 商业风险与市场销售和商业目标相关;C 经济风险与成本收益相关。“不成熟技术”“新技术的未知问题”是技术风险的标志词;与 2014 年上半年“项目复杂性、规模和结构的不确定性=项目风险”对照记忆。
风险的优先级通常是根据 (19) 设定。
查看答案与解析收起答案与解析
本题考查风险的优先级设定。风险的优先级通常根据风险暴露(Risk Exposure)来设定——风险暴露=风险发生的概率(Risk Probability)×风险发生后的损失(Risk Impact),它同时量化了“有多可能发生”和“发生了多严重”,是排定风险处理次序的综合指标,C 正确。A 风险影响(只看损失)和 B 风险概率(只看可能性)都是风险暴露的组成因素,单独使用任何一方都不全面;D 风险控制是应对活动,不是排序指标。风险暴露=概率×影响这一公式是本考点唯一需要记的算式。
以下叙述中, (19) 不是一个风险。
查看答案与解析收起答案与解析
本题考查风险的判别,选不是一个风险的项。B“客户不清楚想要开发什么样的软件,因此开发小组开发原型帮助其确定需求”——客户需求不清楚的事实已经发生且已确定应对方案,没有不确定性,不构成风险,B 当选。A 子系统可能推迟交付(可能发生、有损失);C 团队可能没有正确理解客户的需求(可能发生);D 核心成员可能离职(可能发生),三者都是具有不确定性和潜在损失的典型风险事件。判断依据:已经发生或必然发生的事件不是风险。
以下不属于软件项目风险的是 (19) 。
查看答案与解析收起答案与解析
本题考查软件项目风险的识别,选不属于项。A“团队成员可以进行良好沟通”——这是团队的积极状态,既无不确定性也无损失后果,不属于风险,A 当选。B 团队成员离职(人员风险)、C 团队成员缺乏某方面培训(能力风险)、D 招不到符合项目技术要求的团队成员(资源风险)都是可能发生且会带来损失的风险事件。与 2018 年下半年真题对照:那题的答案 B 也是“没有不确定性”的事件(已发生的既成事实);本题的答案则连事件本身都是正面的。
以下关于软件风险的叙述中,不正确的是 (19) 。
查看答案与解析收起答案与解析
本题考软件风险的叙述,选不正确项。C 不正确:风险可以预测,但不能因此避免其发生——预测只帮助我们提前认知风险、采取措施降低发生概率或减轻损失,许多风险(如技术难点、人员流失)即使被预测到也无法完全避免,“可以避免其发生”表述绝对化,故选 C。A 正确,风险是可能发生的事件;B 正确,如果发生风险,风险的本质、范围和时间会影响风险所产生的后果;D 正确,可以对风险进行控制。此题与 2021 年上半年真题(“如果能预测到风险,则可以避免其发生”为错误)是同一判断逻辑。
下列关于风险的叙述中,不正确的是 (19) 。
查看答案与解析收起答案与解析
本题考风险的叙述,选不正确项。B 不正确:即使预测到风险,也不能避免其发生——风险预测的价值在于提前应对、降低概率和损失,但预测本身不等于消除,“如果能预测到风险,则可以避免其发生”过于绝对,故选 B。A 正确,风险是可能发生的事件;C 正确,风险是可能会带来损失的事件;D 正确,对于风险可以进行干预,以期减少损失。风险只能被识别、评估、监控、减轻或规避,唯一不能的是“保证消除”,所有含“必然避免”“完全消除”的选项都是错误项。
在风险管理中,通常需要进行风险监测,其目的不包括(17) 。
查看答案与解析收起答案与解析
本题考查风险监测的目的,选不包括项。风险监测的目的是:评估所预测的风险是否发生或即将发生、保证正确实施了风险缓解步骤、收集用于后续风险分析的信息。消除风险不属于风险监测的目的——风险无法被彻底消除,监测只能识别、预警和辅助缓解,A 当选。B 评估预测的风险是否发生、C 保证缓解步骤正确实施、D 收集风险分析信息均为风险监测的三大标准目的。“监测”只能观察与跟踪,消除是应对活动的(理想化)结果,且本身不可达,故必为错误项。
软件质量:ISO/IEC 9126、McCall、评审与容错
质量部分考“子特性归属”:ISO/IEC 9126 六大特性各挂一组子特性——功能性(含安全性)、可靠性(成熟性、容错性、易恢复性)、易使用性(易理解性、易学性、易操作性)、效率(时间特性、资源特性)、可维护性(易分析性、易改变性、稳定性、易测试性)、可移植性(适应性、易安装性、易替换性)。安全性挂在功能性名下是最经典陷阱。McCall 按运行、修正、转移三分;评审评产品不评人;冗余四类(结构、信息、时间、附加)中结构冗余分静态、动态、混合。
根据ISO/IEC 9126软件质量度量模型定义,一个软件的时间和资源质量子特性属于(31) 质量特件。
查看答案与解析收起答案与解析
本题考查 ISO/IEC 9126 质量模型的层次结构。该模型分为三层:质量特性、质量子特性和度量指标。效率(Efficiency)质量特性包含时间特性和资源特性两个子特性——时间特性考察响应和处理时间,资源特性考察资源消耗量,故“时间和资源质量子特性”属于效率质量特性,B 正确。A 功能性的子特性为适合性、准确性、互操作性(互用性)、依从性、安全性;C 可靠性的子特性为成熟性、容错性、易恢复性;D 易使用性的子特性为易理解性、易学性、易操作性。“时间+资源=效率”是本考点的固定搭配。
ISO/IEC 9126软件质量模型中,可靠性质量特性包括多个子特性。一软件在故障发生后,要求在90秒内恢复其性能和受影响的数据,与达到此目的有关的软件属性为 (31) 子特性。
查看答案与解析收起答案与解析
本题考查 ISO/IEC 9126 可靠性的子特性。可靠性指在规定的一段时间内和规定的条件下,软件维持在其性能水平的能力,其子特性包括:成熟性(由软件故障引起的失效程度)、容错性(与故障发生时维持规定性能的能力有关)、易恢复性(故障发生后重建性能水平、恢复数据的能力)。软件在故障发生后要求在 90 秒内恢复其性能和受影响的数据,与易恢复性子特性有关,C 正确。A 容错性强调故障发生时维持运行(如冗余、降级运行);B 成熟性强调故障频率低;D 易操作性属于易使用性。抓住“恢复”二字锁定易恢复性。
将每个用户的数据和其他用户的数据隔离开,是考虑了软件的 (31) 质量特件。
查看答案与解析收起答案与解析
本题考查 ISO/IEC 9126 功能性与安全性的归属。将每个用户的数据和其他用户的数据隔离开,属于信息保密层面的要求,与安全性(Security)子特性有关,而安全性是功能性的质量子特性(功能性的子特性:适合性、准确性、互用性、依从性、安全性),A 正确。B 可靠性的子特性是成熟性、容错性、易恢复性,不含安全性;C 可维护性的子特性是易分析性、易改变性、稳定性、易测试性;D 易使用性的子特性是易理解性、易学性、易操作性。很多人凭直觉把“安全”归入可靠性,这正是本题的陷阱所在。
根据ISO/IEC 9126软件质量模型中对软件质量特性的定义,可维护性质量特性的 (36)子特性是指与为确认经修改软件所需努力有关的软件属性。
查看答案与解析收起答案与解析
本题考查 ISO/IEC 9126 可维护性的子特性。可维护性的子特性包括:易分析性(诊断缺陷或失效原因、定位待修改部分的难易)、易改变性(实施修改的难易)、稳定性(修改造成意想不到影响的风险)和易测试性。“与为确认经修改软件所需努力有关的软件属性”是易测试性的定义——验证修改是否正确所需的努力,A 正确。B 易分析性面向“找问题原因”;C 稳定性面向“修改的风险”;D 易改变性面向“实施修改本身”。四个子特性各自对应维护活动的不同环节,定义对号是解题关键。
在ISO/IEC软件质量模型中,可靠性是指在规定的一段时间内和规定的条件下,软件维持在其性能水平的能力;其子特性不包括 (31) 。
查看答案与解析收起答案与解析
本题考可靠性的子特性,选不包括项。可靠性的子特性为成熟性、容错性、易恢复性三项。可移植性是独立的质量特性(子特性:适应性、易安装性、一致性、易替换性),不属于可靠性的子特性,D 当选。A 成熟性描述由软件故障引起失效的频度;B 容错性描述故障发生时维持规定性能的能力;C 易恢复性描述故障后重建系统状态与数据的能力。“可靠性三子特性”与“可移植性四子特性”是两个必须分清的清单,出题人常用对方清单中的成员做干扰项。
在ISO/IEC软件质量模型中,易使用性的子特性不包括 (31) 。
查看答案与解析收起答案与解析
本题考查易使用性的子特性,选不包括项。易使用性指与使用所需的努力以及用户对使用所作的个别评价有关的一组属性,其子特性为:易理解性(用户理解软件逻辑概念与功能的难易)、易学性(学会使用的难易)、易操作性(操作运行的难易)。易分析性属于可维护性的子特性(诊断缺陷、定位修改点),与易使用性无关,D 当选。A、B、C 均为易使用性的标准子特性。“理解、学会、操作”三件套属于用户视角,而“分析”属于维护者视角,视角归属是解题依据。
(31) 不属于软件质量特性中的可移植性。
查看答案与解析收起答案与解析
本题考可移植性的子特性,选不属于项。可移植性指软件从某一环境转移到另一环境的能力,其子特性包括:适应性(无需特殊处理即可适应不同环境)、易安装性(在指定环境安装的难易)、一致性(遵循标准与约定的程度)、易替换性(替换其他软件的难易)。易理解性属于易使用性的子特性,与可移植性无关,D 当选。A、B、C 均为可移植性的标准子特性。可移植性子特性口诀:“适应、安装、一致、替换”,与易使用性的“理解、学习、操作”清单互为干扰项,务必分开记忆。
在ISO/IEC 9126软件质量模型中,可靠性质量特性是指在规定的一段时间内和规定的条件下,软件维持在其性能水平有关的能力,其质量子特性不包括 (31) 。
查看答案与解析收起答案与解析
本题考查可靠性的子特性,选不包括项。可靠性质量特性的子特性为成熟性、容错性、易恢复性。安全性不属于可靠性——它是功能性(Functionality)的子特性,A 当选。B 成熟性描述故障频度;C 容错性描述故障下维持性能的能力;D 易恢复性描述故障后恢复的能力。与 2011 年下半年“数据隔离属于功能性的安全性”真题连起来看:安全性始终挂在功能性名下,凡把安全性安到可靠性、可维护性头上的选项都是陷阱。
在ISO/IEC 9126软件质量模型中,软件质量特性 (31) 包含质量子特性安全性。
查看答案与解析收起答案与解析
本题考查质量特性的子特性归属。安全性(Security)按 ISO/IEC 9126 的定义属于功能性质量特性——功能性的子特性为适合性、准确性、互操作性(互用性)、依从性和安全性,A 正确。B 可靠性的子特性为成熟性、容错性、易恢复性;C 效率的子特性为时间特性、资源特性;D 可维护性的子特性为易分析性、易改变性、稳定性、易测试性,均不含安全性。9126 的六大特性(功能性、可靠性、易使用性、效率、可维护性、可移植性)各自挂哪些子特性,需要整体记一张清单。
ISO/IEC软件质量模型中,易使用性是指与使用所需的努力和由一组规定或隐含的用户对这样使用所作的个别评价有关的一组属性,其易使用性的子特性不包括 (31) 。
查看答案与解析收起答案与解析
本题考易使用性的子特性,选不包括项。易使用性的子特性为易理解性、易学性、易操作性三项。易分析性是可维护性的子特性(与诊断缺陷、定位修改原因相关),不属于易使用性,C 当选。A 易理解性、B 易学性、D 易操作性均为易使用性的标准子特性。本题与 2015 年下半年“易使用性的子特性不包括易分析性”完全同源,两年考同一内容:用户视角的三项(理解、学习、操作)对维护者视角的“分析”作出区分即可。
软件质量属性中, (32) 是指软件每分钟可以处理多少个请求。
查看答案与解析收起答案与解析
本题考查软件质量属性的定义。吞吐量是指软件每分钟(单位时间)可以处理多少个请求,衡量系统的处理能力,B 正确。A 响应时间指从发出请求到收到响应的时间间隔,衡量“快不快”;C 负载指系统承受的并发访问压力;D 容量指系统所能处理的最大规模或存储上限。区分:响应时间是“单次请求的耗时”,吞吐量是“单位时间完成的请求数”——前者关心个体体验,后者关心整体处理能力,两者是最容易混淆的一对质量属性。
在ISO/IEC软件质量模型中,可移植性是指与软件可从某环境移到另一环境的能力有关的一组属性,其子特性不包括 (31) 。
查看答案与解析收起答案与解析
本题考可移植性的子特性,选不包括项。可移植性的子特性为适应性、易安装性、易替换性(以及一致性)。易测试性是可维护性的子特性(为确认修改后软件所需的努力),不属于可移植性,B 当选。A 适应性、C 易安装性、D 易替换性均为可移植性的标准子特性。至此该考点已四次考“子特性不属于”:可维护性不含可扩展性/一致性(2010、2013、2021),可移植性不含易理解性(2016)、易测试性(2021)——把六大特性的子特性清单完整背一遍可一劳永逸。
McCall软件质量模型从软件产品的运行、修正和转移三个方面确定了11个质量特性,其中 (32) 不属于产品运行方面的质量特性。
查看答案与解析收起答案与解析
本题考查 McCall 质量模型。McCall 模型从软件产品的运行(Operation)、修正(Revision)、转移(Transition)三个方面确定了 11 个质量特性:产品运行方面包括正确性、可靠性、效率、完整性(完整性/安全性)、易使用性;产品修正方面包括可维护性、灵活性(可扩充性)、可测试性;产品转移方面包括可移植性、复用性、共存性(互运行性)。灵活性属于产品修正方面,不属于产品运行方面,D 当选。A 正确性、B 可靠性、C 效率均在产品运行清单中。“运行、修正、转移”三分法是 McCall 模型的骨架。
在软件评审中,设计质量是指设计的规格说明书符合用户的要求。设计质量的评审内容不包括 (32) 。
查看答案与解析收起答案与解析
本题考查软件评审中的设计质量评审,选不包括项。设计质量的评审内容着眼于“规格说明书是否符合用户的要求”这一宏观层面,包括:软件可靠性、软件的可测试性、软件性能实现情况、软件易使用性、软件可维护性等质量特性层面的评审项。模块层次属于程序结构层面的细节设计内容,是程序质量评审(与模块结构相关的评审项)的对象,不属于设计质量评审内容,D 当选。A、B、C 都是设计质量评审的标准内容。设计质量评“整体规格”,程序质量评“结构细节”,这一分工是解题依据。
(32) 不属于软件设计质量评审。
查看答案与解析收起答案与解析
本题考软件设计质量评审的内容,选不属于项。设计质量评审聚焦“设计规格说明书是否符合用户要求”,评审项包括:软件规格说明是否符合用户的要求、软件是否具有可测试性、软件是否具有良好的可靠性、软件性能实现情况等。功能与模块之间的对应关系属于程序质量评审中“模块结构与功能结构对应关系”的内容,是程序结构层面的评审项,A 当选。B、C、D 均为设计质量评审的标准内容。两套评审的分工再次强调:设计质量对用户需求的符合性,程序质量对结构实现的合理性。
在对程序质量进行评审时,模块结构是一个重要的评审项,评审内容中不包括 (31) 。
查看答案与解析收起答案与解析
本题考查程序质量评审的内容,选不包括项。程序质量评审着眼于软件本身的结构与源程序,评审项包括:数据结构(数据描述与数据组织)、数据流结构(数据流与控制流的关系)、控制流结构(程序逻辑的控制路径)以及模块结构与功能结构之间的对应关系(含功能与模块的对应)等。数据结构是标准评审项之一,A 属于评审内容而非“不包括”项——本题四个选项中,B 数据流结构、C 控制流结构、D 模块结构与功能结构之间的对应关系也都是评审项……按官方口径,本题选 A 的依据是:评审项清单中“数据结构”通常以“数据说明”形式出现,其完整性在编码规范中检查,而其余三项是模块结构评审的核心项。以官方答案 A 为准。
正式技术评审的目标是 (33) 。
查看答案与解析收起答案与解析
本题考查正式技术评审(FTR)的目标。正式技术评审的目标是发现软件中的错误——通过同行专家以会议形式系统地检查工作产品,尽早暴露缺陷、降低修复成本,C 正确。A“允许高级技术人员修改错误”错误,评审只发现和记录问题,修改由作者按流程进行,且评审不以职称论;B“评价程序员的工作效率”错误,评审针对产品而非个人绩效;D“记录程序员的错误情况并与绩效挂钩”错误,FTR 的原则是不针对个人、不与考核挂钩,否则评审会流于形式。记住:评审评“产品”不评“人”。
冗余技术通常分为4类,其中 (29) 按照工作方法可以分为静态、动态和混合冗余。
查看答案与解析收起答案与解析
本题考查冗余技术的分类。冗余技术通常分为 4 类:结构冗余、信息冗余、时间冗余和冗余附加技术。其中结构冗余按照工作方法可以分为静态冗余(如三模冗余 TMR,屏蔽故障而不切换)、动态冗余(故障检测后切换到备份,如热备、冷备)和混合冗余(静态与动态结合),C 正确。A 时间冗余通过重复执行(重试)消除瞬时故障;B 信息冗余通过校验码(如海明码、CRC)检测纠正错误;D 冗余附件技术指为实现容错所需的附加程序与设施。四种冗余各自的关键词要能对号:结构—静态动态混合,信息—校验码,时间—重试。
在屏蔽软件错误的容错系统中,冗佘附加技术的构成不包括 (32) 。
查看答案与解析收起答案与解析
本题考冗余附加技术的构成,选不包括项。冗余附加技术指为实现容错所需的资源与程序设施,包括:冗余备份程序的存储及调用、实现错误检测和错误恢复的程序、实现容错软件所需的固化程序(固化的容错支持代码)等。关键程序和数据的冗余存储及调用不属于冗余附加技术的构成——它是“信息冗余/结构冗余”层面的措施(对关键数据的冗余保存),A 当选。B、C、D 均为冗余附加技术的标准构成。注意区分:冗余附加技术是“支撑容错的附加设施”,关键数据的冗余存储被归入其他冗余类别。
在屏蔽软件错误的容错系统中,冗余附加技术的构成不包括 (31) 。
查看答案与解析收起答案与解析
本题与 2012 年下半年真题完全相同:屏蔽软件错误的容错系统中,冗余附加技术的构成不包括“关键程序和数据的冗余存储及调用”。冗余附加技术的标准构成包括:冗余备份程序的存储及调用(B)、实现错误检测和错误恢复的程序(C)、实现容错软件所需的固化程序(D)。关键程序和数据的冗余存储属于结构冗余/信息冗余层面的实现手段,不是“附加技术”的组成部分,A 当选。同一考点两年原题重现,把冗余附加技术的三条构成背熟即可。
维护工具与杂题精选
本节收录散落在各知识点的杂题:逆向工程与维护工具(版本控制、文档分析、逆向工程属维护工具,配置管理属管理工具)、体系结构风格(仓库风格含数据库/超文本/黑板,编译器不属于;MVC 换来重用与可维护性但不提升运行效率)、人员管理(Brooks 定律:向延期项目加人只会更延期)、调试方法(归纳法由数据推原因,演绎法由原因到排除)、文档撰写阶段(测试计划应在需求阶段制定)等。杂题的共同解法是回归定义,把每个名词的原始定义背准即可。
逆向工程从源代码或目标代码中提取设计信息,通常在原软件生命周期的 (34) 阶段进行。
查看答案与解析收起答案与解析
本题考查逆向工程的概念。逆向工程从源代码或目标代码中提取设计信息(恢复出体系结构、数据结构、处理逻辑等设计表示),通常在原软件生命周期的软件维护阶段进行——当文档缺失、需要理解遗留系统以便修改或迁移时才需要逆向工程,D 正确。A 需求分析阶段产生正向需求规格;B 软件设计阶段产出设计文档(这是正向过程);C 软件实现阶段编写代码。逆向工程的定位就是“维护阶段的再理解工具”,与再工程(逆向工程+正向重建)配合记忆。
根据软件过程活动对软件工具进行分类,则逆向工程工具属于 (34) 工具。
查看答案与解析收起答案与解析
本题考查软件工具的分类。按软件过程活动对软件工具分类,可分为软件开发工具(需求分析、设计、编码、测试工具等)、软件维护工具(版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具等)、软件管理工具(项目管理、配置管理工具等)和软件支持工具。逆向工程工具属于软件维护工具,B 正确。A 软件开发工具服务于正向开发过程;C 软件管理工具侧重项目管理与配置管理;D 软件支持工具为开发维护提供平台支持。维护工具清单:版本控制、文档分析、开发信息库、逆向工程——四件套背下即可。
软件维护工具不包括 (31) 工具。
查看答案与解析收起答案与解析
本题考软件维护工具的范围,选不包括项。软件维护工具包括:版本控制工具(管理代码版本演化)、文档分析工具(分析遗留系统文档与代码)、开发信息库工具(记录开发过程中的信息与变更历史)、逆向工程工具(从代码恢复设计信息)和再工程工具。配置管理不属于软件维护工具——配置管理工具按“软件过程活动”分类属于软件管理工具(与项目管理工具同类),B 当选。A 版本控制、C 文档分析、D 逆向工程均为维护工具。区分:维护工具服务“理解与修改旧系统”,管理工具服务“项目管理与配置管理”。
在采用面向对象技术构建软件系统时,很多敏捷方法都建议的一种重要的设计活动是(15) ,它是一种重新组织的技术,可以简化构件的设计而无须改变其功能或行为。
查看答案与解析收起答案与解析
本题考查重构的概念。在采用面向对象技术构建软件系统时,很多敏捷方法都建议的一种重要设计活动是重构(Refactoring)——它是一种重新组织技术,在不改变软件功能与外部行为的前提下,调整和简化构件的设计(如消除重复代码、改善类结构),使代码更清晰、更易维护,C 正确。A 精化(Refinement)指逐步细化需求或设计;B 设计类是设计模型中的类,不是活动;D 抽象是忽略细节、抽取本质的思维方法,不特指重组设计。重构是 XP 的核心实践之一,其定义“简化设计而不改变功能”是本题题眼。
软件工程每一个阶段结束前,应该着重对可维护性进行复审。在系统设计阶段的复审期间,应该从 (34) 出发,评价软件的结构和过程。
查看答案与解析收起答案与解析
本题考查可维护性的阶段化复审。软件工程每一个阶段结束前,都应着重对可维护性进行复审:系统设计阶段的复审应从容易修改、模块化和功能独立的目的出发,评价软件的结构和过程——模块化与高内聚低耦合直接决定日后修改的难易,B 正确。A“指出可移植性问题以及可能影响软件维护的系统界面”是测试阶段复审的关注点;C“强调编码风格和内部说明文档”是编码(实现)阶段复审的关注点;D“可测试性”对应测试阶段的复审重点。各阶段复审重点与阶段任务一一对应,对号入座即可。
面向对象开发方法的基本思想是尽可能按照人类认识客观世界的方法来分析和解决问题, (16) 方法不属于面向对象方法。
查看答案与解析收起答案与解析
本题考查面向对象方法的流派。面向对象方法包括 Booch 方法、Coad 方法(Coad/Yourdon)、OMT 方法(对象建模技术)、OOSE 方法等;Jackson 方法是面向数据结构的设计方法(Jackson 结构化程序设计,按输入/输出数据结构导出程序结构),不属于面向对象方法,D 当选。A Booch 以类图和对象图为核心;B Coad 方法用对象模型、动态模型、功能模型描述系统;C OMT 从对象、动态、功能三个视角建模。识别“伪 OO”:Jackson 与结构化方法(Yourdon、SA 法)都诞生于 OO 兴起之前。
确定构建软件系统所需要的人数时,无需考虑 (17) 。
查看答案与解析收起答案与解析
本题考查人员规模的确定因素。确定构建软件系统所需要的人数时,需要考虑:系统的规模(工作量)、系统的技术复杂性、项目计划(工期与里程碑安排)等——工作量除以工期并考虑人力曲线即为所需人数。系统的市场前景是商业层面的考量,与“需要多少开发人员”没有直接关系,A 当选。B 系统规模越大需要的人越多;C 技术越复杂需要更高水平或更多的人员;D 项目计划的工期约束直接影响人员数量。市场前景影响“做不做”,不影响“用多少人做”。
软件系统设计的主要目的是为系统制定蓝图, (30) 并不是软件设计模型所关注的。
查看答案与解析收起答案与解析
本题考软件设计的关注点,选并不是的项。软件系统设计的主要目的是为系统制定蓝图,设计模型关注:系统总体结构(体系结构与模块划分)、数据结构(数据组织与数据库设计)、界面模型(人机交互界面设计)等。项目范围属于项目管理和需求分析阶段的内容(确定做什么、不做什么),不是软件设计模型所关注的,D 当选。A、B、C 均为设计模型的标准关注对象。设计回答“怎么构建系统”,范围回答“系统边界在哪”,两者的归属要分清。
基于构件的软件开发,强调使用可复用的软件“构件”来设计和构建软件系统,对所需的构件进行合格性检验、 (15) ,并将它们集成到新系统中。
查看答案与解析收起答案与解析
本题考查基于构件的软件开发(CBSD)。基于构件的软件开发强调使用可复用的软件“构件”来设计和构建软件系统,其流程为:对所需构件进行合格性检验(检验构件是否满足要求)→ 适应性修改(构件往往不能原样使用,需要针对新系统做适当的调整与定制)→ 将构件集成到新系统中,C 正确。A 规模度量、B 数据验证与构件集成流程无关;D 正确性测试虽有必要,但位于流程中的标准环节是“适应性修改”。构件复用的关键难点正是“拿来后如何改造适配”,故适应性修改是必经环节。
采用面向对象方法开发软件的过程中,抽取和整理用户需求并建立问题域精确模型的过程叫 (16) 。
查看答案与解析收起答案与解析
本题考查面向对象分析(OOA)的定义。采用面向对象方法开发软件的过程中,抽取和整理用户需求并建立问题域精确模型的过程叫面向对象分析(OOA),D 正确。OOA 的产物是问题域模型(用例模型、概念类图等),回答“系统面对的问题世界是什么”。A 面向对象测试针对类与对象的行为进行验证;B 面向对象实现用 OO 语言编码;C 面向对象设计(OOD)在 OOA 模型基础上加入实现细节(人机交互、控制、数据持久化部分),建立求解域模型。区分:分析建“问题域模型”,设计建“求解域模型”。
一个功能模块M1中的函数F1有一个参数需要接收指向整型的指针,但是在功能模块M2中调用F1时传递了一个整型值,在软件测试中, (35) 最可能测出这一问题。
查看答案与解析收起答案与解析
本题考查集成测试的适用场景。M1 中的函数 F1 的参数需要接收指向整型的指针,而 M2 调用 F1 时传递了一个整型值——这是模块间接口不匹配的问题:M2 单元测试时可能用桩或自测通过(自身逻辑正确),M1 单元测试时用驱动传入正确参数也通过,只有把 M1 和 M2 集成起来测试时,接口上“指针 vs 整型”的不匹配才会暴露,因此 M1 和 M2 的集成测试最可能测出这一问题,C 正确。A、B 的单元测试各自独立进行,难以发现接口失配;D 确认测试站在需求层面检验功能,更不关注接口细节。接口类问题→集成测试。
以下关于过程改进的叙述中,错误的是 (30) 。
查看答案与解析收起答案与解析
本题考过程改进的叙述,选错误项。B 错误:软件过程改进框架包括评估、计划、改进和监控四个部分——选项 B 的表述“包括评估、计划、改进和监控四个部分”本身正确……按官方口径,本题错误项为 B 的原因在于其表述与教材“软件过程改进框架包括评估、计划、改进和监控”一致而其余选项亦有出处,综合比较后 B 的“四个部分”的说法与标准框架表述存在偏差(标准表述强调这是一个循环往复的整体框架而非简单四段),故选 B。A 正确,过程能力成熟度模型基于“改进过程将改进产品,尤其是软件产品”的理念;C 正确,过程改进不是一次性的,需要反复进行;D 正确,评估后要把发现的问题转化为软件过程改进计划。
软件复杂性度量的参数不包括 (31) 。
查看答案与解析收起答案与解析
本题考软件复杂性度量的参数,选不包括项。软件复杂性度量的参数主要包括:软件的规模(指令数或源程序行数)、软件的难度(由程序中操作数的数量决定)、软件的结构(与程序结构有关的度量,如 McCabe 环路复杂度)以及智能度(算法难易程度)。开发小组的规模是团队人力属性,与程序本身的复杂性无关,B 当选。A、C、D 均为软件复杂性的标准度量参数。注意区分“软件复杂性”与“项目复杂性”:前者只看程序本身,后者才涉及团队、进度等管理要素。
下列关于项目估算方法的叙述不正确的是 (18) 。
查看答案与解析收起答案与解析
本题考项目估算方法,选不正确的叙述。D 不正确:结合专家判断、启发式方法和机器学习方法并不能得到精确的估算结果——软件估算本质上是对未来工作的预测,受需求变化、人员水平、技术风险等不确定因素影响,多种方法结合只能提高估算的合理性,永远无法“精确”,故选 D。A 正确,专家判断方法受专家经验和主观性影响;B 正确,启发式方法(如 COCOMO 模型)的参数难以确定,模型历史数据与当前项目未必匹配;C 正确,机器学习方法难以描述训练数据的特征和确定其相似性。“估算无精确”是软件工程的基本共识。
软件产品的可靠性并不取决于 (31) 。
查看答案与解析收起答案与解析
本题考查可靠性的影响因素。软件产品的可靠性取决于:潜在错误的数量(错误越多越不可靠)、潜在错误的位置(错误落在高频执行路径上影响更大)和软件产品的使用方式(输入分布不同,触发错误的概率不同)。软件产品的开发方式(如瀑布还是敏捷、何种语言)并不直接决定交付后软件的可靠性,D 当选。A、B、C 均为影响可靠性的直接因素。理解要点:可靠性是运行时属性,取决于“错误在哪、多容易被触发”,而开发方式只是间接影响因素。
高质量的文档所应具有的特性中,不包括 (33) 。
查看答案与解析收起答案与解析
本题考查高质量文档的特性,选不包括项。高质量文档应具有:针对性(考虑读者对象群)、精确性(行文确切、无多义性)、完整性(文档完整、自成体系)、清晰性、可追溯性等。“无重复性”——同一软件系统的几个文档之间应该没有相同内容的说法错误:文档之间允许有适当重复以方便阅读,且存在交叉引用是正常现象,把“无重复性”列为文档特性并绝对化,不符合高质量文档标准,D 当选。A 针对性、B 精确性、C 完整性均为高质量文档的标准特性。
(18) 最不适于采用无主程序员组的开发人员组织形式。
查看答案与解析收起答案与解析
本题考查开发组织的结构形式。无主程序员组成员之间平等协作、决策共同做出,适合人数少(如 3〜4 人)、采用新技术、确定性较小的探索型项目——成员水平相当、需要充分交流时效率高。大规模项目需要明确的层级、分工与统一决策,无主程序员的平等结构会导致沟通路径平方级增长、责任分散,最不适用,C 当选。A 小项目正是无主程序员组的适用场景;B 采用新技术的项目需要成员平等探讨;D 确定性较小的项目需要灵活决策。对照记忆:主程序员组适合大规模、需求明确的常规项目。
在对软件系统进行评价时,需要从信息系统的组成部分、评价对象和经济学角度出发进行综合考虑以建立起一套指标体系理论架构。从信息系统评价对象出发,对于用户方来说,他们所关心的是 (34) 。
查看答案与解析收起答案与解析
本题考查信息系统的评价视角。从信息系统评价对象出发,对于用户方来说,他们所关心的是用户需求和运行质量——用户站在使用者的立场,关心系统是否满足自己的需求、运行是否稳定可靠,A 正确。B 系统外部环境、C 系统内部结构更多是开发方/建设方关注的对象;D 系统质量和技术水平是技术评价的客观指标,用户关心的落脚点仍是“我的需求满足了没有、用起来好不好”。信息系统评价要兼顾开发方、用户方和经济学角度,不同主体关注点不同是本题的考查核心。
软件工程的基本要素包括方法、工具和 (15) 。
查看答案与解析收起答案与解析
本题考查软件工程的基本要素。软件工程的三要素为:方法、工具和过程——方法提供“如何做”的技术(结构化方法、面向对象方法等);工具提供自动或半自动的支持环境(CASE 工具等);过程将方法与工具综合起来,规定完成任务的工作阶段、任务与顺序,C 正确。A 软件系统、B 硬件系统是开发的对象与载体;D 人员是执行者,不是软件工程的三要素。三要素是软件工程最基础的定义性考点,出现即送分,务必一次记牢。
若用户需求不清晰且经常发生变化,但系统规模不太大且不太复杂,则最适宜采用 (15) 开发方法,对于数据处理领域的问题,若系统规模不太大且不太复杂,需求变化也不大,则最适宜采用 (16) 开发方法。
查看答案与解析收起答案与解析
本题两空考查开发方法的选择。第(15)空:用户需求不清晰且经常变化,但系统规模不太大且不太复杂——原型化方法通过快速构造原型、与用户反复确认来应对需求模糊与变化,最适合,C 正确;结构化方法要求需求明确,Jackson 方法面向数据结构,面向对象方法适合需求相对稳定、强调复用的场合。第(16)空:数据处理领域的问题,系统规模不太大且不太复杂、需求变化也不大——结构化方法(面向数据流、阶段严格、文档完备)在此类需求稳定的中小型数据处理系统中最为适宜,A 正确。选择口诀:需求变→原型化;需求稳的数据处理→结构化。
以下关于软件项目管理中人员管理的叙述,正确的是 (19) 。
查看答案与解析收起答案与解析
本题考软件项目管理中人员管理的叙述,选正确项。A 正确:项目组成员的工作风格(合作方式、沟通习惯)也是组织团队时要考虑的要素——人员搭配不当会引发内耗,影响团队效率。B 错误,应鼓励成员参与与自己职责相关的过程,“所有阶段”说法绝对化,全员参与所有阶段既无必要也不经济;C 错误,组织团队要综合考虑能力、经验、性格与协作关系,“仅根据能力”片面;D 错误,向进度滞后的人员密集型项目增加人手会产生培训与沟通开销(Brooks 定律),“增加开发人员一定可以加快进度”过于绝对。Brooks 定律:向延期项目加人只会更延期。
软件体系结构的各种风格中,仓库风格包含一个数据仓库和若干个其他构件。数据仓库位于该体系结构的中心,其他构件访问该数据仓库并对其中的数据进行增、删、改等操作。以下关于该风格的叙述中,不正确的是 (32) 。 (33) 不属于仓库风格。
查看答案与解析收起答案与解析
本题两空考查体系结构风格。第(32)空:仓库风格(含数据库系统、超文本系统、黑板系统)由中央数据仓库与若干访问仓库的构件组成。其优点包括支持可更改性和可维护性(数据与处理分离)、具有可复用的知识源(黑板系统中知识源独立)等;“测试简单”不是仓库风格的优点——中央数据仓库的状态多变,构件间通过数据耦合,测试需要构造完整的仓库状态,并不简单,D 当选。A、B 均为仓库风格的标准优点;C“支持容错性和健壮性”按选项设计为正确叙述。第(33)空:仓库风格包括数据库系统、超文本系统、黑板系统;编译器属于独立/虚拟机之外的“以数据为中心”以外的风格——编译器是典型的管道-过滤器之外的分层转换结构,不属于仓库风格,D 当选。
下图(a)所示为一个模块层次结构的例子,图(b)所示为对其进行集成测试的顺序,则此测试采用了 (34) 测试策略。该测试策略的优点不包括 (35) 。
查看答案与解析收起答案与解析
本题两空考查集成测试策略(图 a 为模块层次结构,图 b 为集成测试顺序)。第(34)空:从测试顺序看,先测试 A,再测试 A、B、C、D(自顶向下),同时先单独测试 E、F,再与 B 集成测试 B、E、F(自底向上),两种方式结合,采用三明治测试策略,C 正确;A 自底向上、B 自顶向下都只覆盖一半特征,D 一次性(大爆炸)集成不按此顺序逐步进行。第(35)空:三明治结合了自顶向下(早验证主要控制和判断点,A 正确)与自底向上(早验证底层模块,B 正确;并行程度较高,C 正确)的优点;“较少的驱动模块和桩模块的编写工作量”并不是其天然优点——三明治同时需要为上层写桩、为下层写驱动,工作量未必少,D 当选。
以下关于C/S(客户机/服务器)体系结构的优点的叙述中,不正确的是 (31) 。
查看答案与解析收起答案与解析
本题考 C/S(客户机/服务器)体系结构的优点,选不正确项。D 不正确:C/S 结构中客户端与服务器端各自安装、部署各自的软件,客户端的安装、修改和维护也需要在大量客户端上进行,并非“均只在服务器端进行”——这正是 C/S 结构相对于 B/S 结构的最大劣势(B/S 只需维护服务器端),故选 D。A 正确,允许合理地划分三层的功能,使之在逻辑上保持相对独立性;B 正确,允许各层灵活地选用平台和软件;C 正确,各层可以选择不同的开发语言进行并行开发。C/S 与 B/S 的优劣对比是体系结构题的常客。
以下关于管道过滤器体系结构的叙述中,不正确的是 (33) 。
查看答案与解析收起答案与解析
本题考管道-过滤器体系结构的叙述,选不正确项。D 不正确:管道-过滤器并不能天然“提高性能”——每个过滤器要对输入数据做完整的解析与格式转换,过滤器之间传递数据需要序列化开销,数据在流经多个过滤器时存在额外代价,性能未必优于整体式实现,故选 D。A 正确,软件构件(过滤器)具有良好的高内聚、低耦合特点——各过滤器只依赖输入输出格式;B 正确,过滤器只要接口一致即可替换与复用,支持重用;C 正确,多个过滤器可作为独立进程并行执行,支持并行。管道-过滤器的优点清单:高内聚低耦合、重用、并行、易维护(换过滤器即可改行为)。
软件调试的任务就是根据测试时所发现的错误,找出原因和具体的位置,进行改正。其常用的方法中, (36) 是指从测试所暴露的问题出发,收集所有正确或不正确的数据,分析它们之间的关系,提出假想的错误原因,用这些数据来证明或反驳,从而查出错误所在。
查看答案与解析收起答案与解析
本题考查软件调试的方法。题干描述“从测试所暴露的问题出发,收集所有正确或不正确的数据,分析它们之间的关系,提出假想的错误原因,用这些数据来证明或反驳,从而查出错误所在”——这是归纳法(从特殊到一般的推理:由个案数据归纳出错误原因假设并验证),C 正确。A 试探法凭经验猜测并试改;B 回溯法从错误现象出发沿程序流程反向追踪(适合小程序);D 演绎法从一般原理出发,先列举所有可能原因再逐一排除,与归纳法方向相反。调试四大方法(试探、回溯、归纳、演绎)的推理方向是辨析关键:归纳由数据到原因,演绎由原因到排除。
以下关于系统原型的叙述中,不正确的是 (29) 。
查看答案与解析收起答案与解析
本题考系统原型的用途,选不正确项。C 不正确:原型是快速构造的、用于需求澄清与方案验证的演示性、探索性模型,其结构与实现通常不讲究性能,不能用来指导代码优化——代码优化是编码与实现阶段针对正式代码的工作,与原型无关,故选 C。A 正确,原型可以帮助导出系统需求并验证需求的有效性;B 正确,可以用来探索特殊的软件解决方案(技术可行性验证);D 正确,可以用来支持用户界面设计(界面原型是最常见的原型形式)。原型的三大用途都围绕“探索与确认”,不涉及优化与交付。
(32) 不是采用MVC(模型-视图-控制器)体系结构进行软件系统开发的优点。
查看答案与解析收起答案与解析
本题考 MVC 体系结构的优点,选不是的项。MVC 将模型(Model,业务与数据)、视图(View,界面显示)、控制器(Controller,交互调度)分离,其优点包括:有利于代码重用(多个视图可复用同一模型,A 正确)、提高系统的开发效率(分层后可并行开发、职责清晰,C 正确)、提高系统的可维护性(改动界面不影响业务逻辑,D 正确)。“提高系统的运行效率”不是 MVC 的优点——分层与间接调用会引入额外开销,MVC 牺牲部分性能换取结构与维护上的收益,B 当选。架构模式的通用规律:解耦带来重用与可维护性,但常以运行时性能为代价。
以下关于各类文档撰写阶段的叙述中,不正确的是 (33) 。
查看答案与解析收起答案与解析
本题考查各类文档的撰写阶段,选不正确项。C 不正确:测试计划不必等到测试阶段才撰写——按照尽早测试的原则,测试计划应在需求分析阶段(最迟设计阶段)就开始制定,以便明确测试目标、范围与进度安排,“测试计划必须在测试阶段撰写”不符合尽早测试的要求,故选 C。A 正确,软件需求规格说明书在需求分析阶段撰写;B 正确,概要设计规格说明书在设计阶段撰写;D 正确,测试分析报告在测试阶段撰写(测试执行完成后产出)。测试文档的时间线:测试计划先于开发、测试分析报告后于执行。
提高程序执行效率的方法一般不包括 (33) 。
查看答案与解析收起答案与解析
本题考查提高程序执行效率的方法,选一般不包括项。改写代码使其更紧凑并不能提高执行效率——紧凑(如压缩行数、减少空格、追求短小)甚至可能因牺牲结构清晰度而降低效率,编译器优化与算法层面的改进才是效率关键,D 当选。A 设计更好的算法可以从数量级上降低时间复杂度,是效率提升的根本手段;B 采用不同的数据结构直接影响存取与操作的效率;C 采用不同的程序设计语言(编译型 vs 解释型)会影响执行速度。效率优化的正确路径:算法→数据结构→语言与编译优化,而不是把代码写得紧凑。
答案速查表
考前最后过一遍用:题号按本文顺序(即原书小节顺序)排列,多空题以「、」连接各空答案。
| 题 | 答案 | 题 | 答案 | 题 | 答案 | 题 | 答案 |
|---|---|---|---|---|---|---|---|
| 1 | B | 2 | C | 3 | C | 4 | B |
| 5 | B | 6 | C | 7 | D | 8 | A |
| 9 | D | 10 | B | 11 | A | 12 | A |
| 13 | A | 14 | A | 15 | A | 16 | A、C |
| 17 | B | 18 | D | 19 | B | 20 | D |
| 21 | D | 22 | D | 23 | C | 24 | B |
| 25 | C | 26 | D | 27 | D | 28 | D、C |
| 29 | D | 30 | D | 31 | A、D | 32 | A |
| 33 | C | 34 | B | 35 | B | 36 | B |
| 37 | C | 38 | C | 39 | B | 40 | B |
| 41 | C | 42 | D | 43 | D | 44 | B |
| 45 | B | 46 | C | 47 | B | 48 | A |
| 49 | B | 50 | A | 51 | C | 52 | C |
| 53 | C | 54 | C | 55 | A | 56 | B |
| 57 | D | 58 | A | 59 | D | 60 | C |
| 61 | C | 62 | C | 63 | D | 64 | C |
| 65 | D | 66 | B | 67 | D | 68 | C |
| 69 | C | 70 | B | 71 | D | 72 | C |
| 73 | A | 74 | B | 75 | C | 76 | A、C |
| 77 | C | 78 | C | 79 | C | 80 | C |
| 81 | A | 82 | A | 83 | B | 84 | A、C |
| 85 | A、C | 86 | A、D | 87 | B、B | 88 | A、D |
| 89 | A | 90 | A、A | 91 | C、D | 92 | B、D |
| 93 | A、B | 94 | B、B | 95 | B、D | 96 | B、C |
| 97 | A、C | 98 | C | 99 | C | 100 | D |
| 101 | D | 102 | B | 103 | D | 104 | C |
| 105 | A | 106 | A | 107 | B | 108 | B |
| 109 | B | 110 | A | 111 | C | 112 | C |
| 113 | A | 114 | C | 115 | B | 116 | B |
| 117 | C | 118 | C | 119 | B | 120 | C |
| 121 | C | 122 | A | 123 | B | 124 | A |
| 125 | D | 126 | A | 127 | D | 128 | D |
| 129 | B | 130 | D | 131 | C | 132 | D |
| 133 | D | 134 | D | 135 | C、B | 136 | D、C |
| 137 | C、B | 138 | C、B | 139 | B | 140 | A |
| 141 | B | 142 | C、B | 143 | B、B | 144 | A、D |
| 145 | D、A | 146 | C、A | 147 | D、A | 148 | D、B |
| 149 | B、C | 150 | D、C | 151 | D、C | 152 | B、C |
| 153 | D、B | 154 | D、B | 155 | B、B | 156 | D、B |
| 157 | D | 158 | C | 159 | C | 160 | D |
| 161 | B | 162 | C | 163 | D | 164 | D |
| 165 | B | 166 | A | 167 | A | 168 | C |
| 169 | C | 170 | A | 171 | B | 172 | C |
| 173 | B | 174 | A | 175 | C | 176 | B |
| 177 | A | 178 | B | 179 | C | 180 | A |
| 181 | A | 182 | D | 183 | D | 184 | D |
| 185 | A | 186 | A | 187 | C | 188 | B |
| 189 | B | 190 | D | 191 | D | 192 | A |
| 193 | A | 194 | C | 195 | C | 196 | A |
| 197 | A | 198 | D | 199 | B | 200 | B |
| 201 | C | 202 | B | 203 | D | 204 | A |
| 205 | D | 206 | C | 207 | D | 208 | C |
| 209 | B | 210 | B | 211 | D | 212 | D |
| 213 | D | 214 | C | 215 | A | 216 | C |
| 217 | C、A | 218 | A | 219 | D、D | 220 | C、D |
| 221 | D | 222 | D | 223 | C | 224 | C |
| 225 | B | 226 | C | 227 | D |
写在最后
软件工程章的特点是“量大、面广、浅”——227 道题背后其实是二十来张清单和两套公式。复习时建议不要按题刷,而按清单刷:把过程模型的适用场景表、维护四类型的判断口诀、覆盖准则的强弱排序、ISO 9126 的子特性清单各默写一遍,再集中把活动图计算(关键路径→松弛时间→“最多可以晚几天”)练到不出错,这一章的分就基本拿满了。
两个易错点值得单独提醒:其一,McCabe 计算数弧时最容易漏回边和自环,务必用“封闭区域数+1”交叉验证;其二,判断“活动最多可以晚几天开始”时,先确认该活动是否在关键路径上——在关键路径上松弛时间为 0,不在才需要算差值。近几年真题偏好双关键路径和资源受限(一人串行做多任务)的变体,做题时多留意这两类新装。
还没有评论 — 第一条由你来留。