跳转至

2023年《软件质量与管理》期末试题A卷 解答与解析

试题来源: assets/exams/2023软件质量管理.md(2023年2月21日闭卷考试,2019级)

试卷基本信息

考试科目名称 软件质量与管理(A卷)
考试方式 闭卷
考试日期 2023年2月21日
教师 荣国平
系(专业) 软件学院
年级 2019级
题号 总分
分数 30 6 9 10 10 10 10 15 100

一、不定项选择题(本题满分30,每题2分)

(1)"Measure twice, cut once"描述的是下述哪个软件开发场景

A. 软件设计 B. 代码评审 C. 需求开发 D. 软件测试

点击查看答案与解析

答案:B(代码评审)

知识点出处assets/slides/软件质量与管理.第二讲.pdf——软硬件一体化阶段典型实践。"Measure twice, cut once"强调在应用更改之前仔细检查代码以在问题成为主要问题之前识别和纠正问题,描述的是代码评审场景。

题目来源:本题在历年课堂选择题中反复出现(2022Fall选择题)。

(2)整体来看,我们可以把软件的发展分为三大主要阶段,以下描述中不属于三大主要阶段的是

A. 软硬件一体化 B. 网络化和服务化 C. 云计算化和云原生 D. 软件成为独立产品

点击查看答案与解析

答案:C(云计算化和云原生)

知识点出处assets/slides/软件质量与管理.第二讲.pdf——软件发展三大阶段:①软硬件一体化阶段(50年代~70年代);②软件成为独立的产品(70年代~90年代);③网络化和服务化(90年代中期迄今)。云计算化和云原生是网络化和服务化阶段的子趋势,不是独立的三大阶段之一。

题目来源:本题出自历年课堂选择题(2022Fall选择题)。

(3)以下描述中,不属于软件开发本质困难或者本质挑战的是

A. 质量挑战 B. 复杂性 C. 不可见 D. 一致性

点击查看答案与解析

答案:A(质量挑战)

知识点出处assets/slides/软件质量与管理.第二讲.pdf——Brooks《没有银弹》中提出的软件开发四大本质难题为:复杂性(Complexity)、不可见性(Invisibility)、可变性(Changeability)、一致性(Conformity)。质量挑战不是Brooks定义的四大本质困难之一。

题目来源:本题出自历年课堂选择题(2022Fall选择题),也是2020-mid期中选择题。

(4)以下描述中,哪一种开发实践是软硬件一体化阶段的典型实践

A. Code and Fix B. 迭代式开发 C. 瀑布生命周期模型 D. 成熟度模型

点击查看答案与解析

答案:A(Code and Fix)

知识点出处assets/slides/软件质量与管理.第二讲.pdf——软硬件一体化阶段的典型开发方法包括:"三思而后行"(Measure twice, cut once)、Code and Fix(编码+改错)。迭代式开发是网络化和服务化阶段的实践;瀑布生命周期模型和成熟度模型是软件成为独立产品阶段的实践。

题目来源:本题出自历年课堂选择题(2022Fall选择题)。

(5)下述关于WBS的描述中,哪些说法不正确?

A. WBS应该对应OBS B. WBS提供了范围管理的基础 C. WBS工作分解最底层的要素是实现目标的充分必要条件 D. WBS分解的时候,同一层不能应用不同标准

点击查看答案与解析

答案:A

知识点出处assets/slides/软件质量与管理.第四讲.pdf(估算、计划和跟踪)。 - A(不正确):WBS 和 OBS 关注的角度和目的不同,WBS 不一定对应 OBS。 - B(正确):WBS 提供了范围管理的基础。 - C(正确):WBS 最底层要素是实现目标的充分必要条件(100% 规则)。 - D(正确):WBS 分解时同一层应保持一致的分解标准,这是良好 WBS 的实践原则。

题目来源:本题出自2022Fall选择题,在assets/exams/软件质量管理-习题-EagleBear.pdf中有详细解析。

(6)下述关于EVM的描述中,哪些说法不正确?

A. EVM不适用于质量管理 B. EVM的中级实现中引入成本信息 C. EVM高度依赖估算准确 D. EVM可以适应需求变更

点击查看答案与解析

答案:A、B

知识点出处assets/slides/软件质量与管理.第四讲.pdf——挣值管理(EVM)相关知识点: - EVM主要进行进度和成本管理,不直接适用于质量管理(A正确——但表述为"不适用"意味着它确实不能用于质量管理,这在题目中是"不正确"的说法,需要仔细辨析) - EVM的中级实现在简单实现基础上加入日程偏差计算,高级实现才引入成本信息(B不正确) - EVM高度依赖估算准确性(C正确) - EVM可以适应需求变更(D正确)

解析:本题问"不正确"的说法。A项"EVM不适用于质量管理"——EVM确实不适用于质量管理,所以这是正确的说法(选"不正确"时不选)。但根据历年习题解析(EagleBear),A被判定为不正确的说法,含义是EVM与质量管理无关这一论断不正确。B项"中级实现中引入成本信息"是错误的,中级实现仅引入日程偏差,高级实现才引入成本信息。

题目来源:本题出自2022Fall选择题,在assets/exams/软件质量管理-习题-EagleBear.pdfassets/exams/软件质量与管理-课上选择题-含答案.pdf中有解析。

修订答案:A、B(根据课件和习题解析,EVM确实不适用于质量管理是正确的陈述,但选项中说EVM"不适用于质量管理"的说法本身在课堂上被判定为不正确——EVM虽然不直接影响质量,但项目质量与进度、成本相互关联。此处按照课堂选择题答案:A、B为不正确说法。)

(7)下面描述属于典型客户需求的是

A. 客户期望 B. 预算限制 C. 法律法规限制 D. 系统功能描述

点击查看答案与解析

答案:A、B、C

知识点出处assets/slides/软件质量与管理.第四讲.pdf——客户需求描述的是客户的期望。客户需求可能包括客户期望、预算限制、法律法规限制等。系统功能描述属于产品需求范畴。

题目来源:本题出自2022Fall选择题,在EagleBear习题中有解析。

(8)关于集成策略,下述描述中正确的是

A. 当待集成组件质量普遍不高的时候,不可以使用扁平化策略 B. 当需要尽早获取可以工作的组件的时候,应该使用集簇式策略 C. 当待集成组件质量普遍较高的时候,可以使用大爆炸式集成策略 D. 持续集成本质上就是逐一添加策略

点击查看答案与解析

答案:B、C、D

知识点出处assets/slides/软件质量与管理.第六讲.pdf(团队工程开发)。集成策略: - 扁平化策略的核心限制是需要大量打桩(Stub),而非组件质量。质量高低不是扁平化的适用条件——真正对组件质量有要求的是大爆炸策略(A错误) - 集簇式策略可以尽早获取可工作的组件(B正确) - 当组件质量普遍较高时,大爆炸式集成风险可控(C正确) - 持续集成本质上就是逐一添加策略(D正确)

题目来源:本题出自2022Fall选择题,在EagleBear习题中有解析。

(9)以下关于规模估算和度量的描述中,正确的是

A. 功能点是一种可提供精确规模度量结果的方式 B. 规模数据扮演了沟通历史数据的桥梁的角色 C. 规模估算通常不用于质量计划当中 D. PROBE只用于规模估算

点击查看答案与解析

答案:B

知识点出处assets/slides/软件质量与管理.第四讲.pdf——PROBE估算方法。规模数据确实扮演了沟通历史数据的桥梁角色(B正确)。功能点可以在项目早期提供直观结果,但不能精确度量(A错误)。规模估算可以用于质量计划(C错误)。PROBE不仅用于规模估算,也用于资源估算(D错误)。

题目来源:本题出自2022Fall选择题,在EagleBear习题中有解析。

(10)关于PSP缺陷日志,哪些信息是至关重要的?

A. 缺陷发现时间 B. 缺陷重现方式 C. 缺陷根因描述 D. 缺陷关联的其他缺陷

点击查看答案与解析

答案:A、C

知识点出处assets/slides/软件质量与管理.第五讲.pdf——PSP质量管理策略。PSP缺陷日志中至关重要的信息包括缺陷发现时间和缺陷根因描述。

题目来源:本题出自2022Fall选择题,在EagleBear习题中有解析。

(11)关于DRL,下列说法中正确的是

A. 这是一种模块级开发中的度量模块开发质量的指标 B. 该以单元测试发现的缺陷个数作为基准,考察上游其他缺陷消除阶段消除缺陷的效率 C. DRL只能预测,不能度量 D. DRL期望值是大于2.0

点击查看答案与解析

答案:A、B

知识点出处assets/slides/软件质量与管理.第五讲.pdf——DRL(Defect Removal Leverage,缺陷消除杠杆): - DRL是模块级开发中度量模块开发质量的指标(A正确) - DRL以单元测试发现的缺陷个数作为基准,考察上游其他缺陷消除阶段消除缺陷的效率(B正确) - DRL可以度量,不是只能预测(C错误) - DRL期望值大于2.0的说法不完全准确

题目来源:本题出自课堂选择题,在assets/exams/软件质量与管理-课上选择题-含答案.pdf中有解析。

(12)关于PQI,下列说法中不正确的是

A. PQI表征模块级别开发中的过程规范化程度 B. PQI越高越好 C. PQI越低越好 D. PQI不仅仅可以用作质量规划,也能指导过程改进

点击查看答案与解析

答案:B、C

知识点出处assets/slides/软件质量与管理.第五讲.pdf——PQI(Process Quality Index,过程质量指标): - PQI表征模块级别开发中的过程规范化程度(A正确) - PQI不是越高越好,适当的PQI值(如大于0.4)即可,过高意味着成本过高(B不正确) - PQI也不是越低越好(C不正确) - PQI可以用于质量规划和过程改进(D正确)

题目来源:本题出自2022Fall/历年课堂选择题。

(13)关于Humphrey梳理的Quality Journey,下列说法中不正确的是

A. Quality Journey中列出的步骤可以按需要更换顺序 B. 加强团队形式的评审是Quality Journey后期的步骤 C. Quality Journey仍然仅仅是在"用缺陷管理替代质量管理"这一基本策略之下进行讨论 D. Quality Journey中测试应该先于评审得到贯彻和改善

点击查看答案与解析

答案:A、D

知识点出处assets/slides/软件质量与管理.第五讲.pdf——Quality Journey(质量旅程): - Quality Journey中的步骤有严格的先后顺序,不能随意更换(A不正确) - 加强团队形式的评审是Quality Journey后期的步骤(B正确) - Quality Journey确实是在"用缺陷管理替代质量管理"这一基本策略下讨论(C正确) - Quality Journey中评审应该先于测试得到贯彻和改善,而非测试先于评审(D不正确)

题目来源:本题出自2022Fall选择题。

(14)一个完全正确的状态机应该满足

A. 没有死循环和陷阱 B. 状态转化条件满足正交性 C. 状态转化条件满足完整性 D. 符合设计意图

点击查看答案与解析

答案:A、B、C、D(全选)

知识点出处assets/slides/软件质量与管理.第六讲.pdf——设计验证。一个完全正确的状态机应该满足:没有死循环和陷阱、状态转化条件满足正交性、状态转化条件满足完整性、符合设计意图。

题目来源:本题出自2022Fall选择题,在EagleBear习题中有解析。

(15)下列关于各种设计验证手段的描述中不正确的是

A. 受限于手工方式,都易于出错 B. 跟踪表是唯一一种提供全面设计验证的手段 C. 符号化执行不适合验证复杂的数学计算 D. 执行表是跟踪表的扩展

点击查看答案与解析

答案:A、B、C

知识点出处assets/slides/软件质量与管理.第六讲.pdf——设计验证手段: - 符号化验证才是唯一一种提供全面设计验证的手段,不是跟踪表(B不正确) - 受限于手工方式确实易于出错(A正确,但此处问"不正确"时A是对设计验证手段的误解——设计验证并非全部受限于手工方式) - 符号化执行适合复杂的计算过程,不适合复杂的逻辑(C不正确) - 执行表确实是跟踪表的扩展(D正确)

题目来源:本题出自课堂选择题,在EagleBear习题中有解析。

二、(本题满分6分)

以下说法是否正确?为什么?

(1)"在公司导入敏捷过程是我们今年过程改进的主要目标。"

点击查看答案与解析

解答:这个说法在概念上是合适的,但操作时可能存在问题。

知识点出处assets/slides/软件质量与管理.第二讲.pdfassets/slides/软件质量与管理.第七讲.pdf——过程管理和过程改进的关系。过程改进的目标可以是导入新的开发过程(如敏捷过程),这在概念层面是合理的。但"导入敏捷过程"本身过于笼统,过程改进需要具体的目标和度量方式。

题目来源:本题在历年中反复出现(2022Fall、EagleBear习题),参考答案判定为"正确(概念上合理)"。

(2)CMM/CMMI不适合当今互联网环境之下的项目管理。

点击查看答案与解析

解答:这个说法是正确的。

理由:CMM/CMMI是用来做过程管理和改进的模型,刻画了软件组织从不成熟到成熟的路线图,它们本身并不是满足项目管理需求的手段。因此说CMM/CMMI"不适合当今互联网环境之下的项目管理"是正确的——因为CMM/CMMI的本质目的就不是项目管理,而是过程改进。

知识点出处assets/slides/软件质量与管理.第七讲.pdf——CMMI是过程改进模型,不是项目管理工具。assets/slides/课程总结.pdf——CMMI的本质是过程管理和改进。

题目来源:本题在历年中反复出现(2022Fall、2020-mid、EagleBear习题)。

(3)PDCA和IDEAL不适合在敏捷环境中使用。

点击查看答案与解析

解答:这个说法是错误的。

理由:PDCA(Plan-Do-Check-Act)和IDEAL(Initiating-Diagnosing-Establishing-Acting-Leveraging)是软件过程改进的参考元模型,它们是通用的过程改进框架,适用于各种开发环境,包括敏捷环境。敏捷团队同样需要持续改进,PDCA和IDEAL提供的框架完全可以服务于敏捷环境中的过程改进。

知识点出处assets/slides/软件质量与管理.第七讲.pdf——PDCA和IDEAL模型是通用的过程改进参考元模型,assets/slides/课程总结.pdf——过程改进元模型适用于各类开发环境。

题目来源:本题在历年中反复出现(2022Fall、EagleBear习题)。

三、(本题满分9分)

结合"软件开发作为一种知识工作,需要领导者而不是一般的经理",阐述知识工作领导者应该具备的品质或者特点(至少三项)。

点击查看答案与解析

解答:

软件开发是一项既复杂又富有创造性的知识工作。开发者是智力劳动者,而对于智力劳动者而言,管理的第一准则就是智力劳动者不能被管理,只能实现自我管理。因此,软件项目需要的是领导者(Leader)而非一般的经理(Manager)。

知识工作领导者应该具备的品质或特点:

  1. 善于倾听团队成员的想法,并加以分析和改进——知识工作者需要被理解和尊重,领导者应当充分听取团队成员的意见。

  2. 善于通过询问来诱导团队成员向着正确的方向前进——不是直接命令,而是通过提问引导团队找到正确的解决方案。

  3. 善于通过激励以及设定挑战目标等方式吸引团队成员努力表现——根据期望理论(Motivation = Valence × Expectancy),设定有挑战性但可达成的目标来激励团队。

  4. 当出现不一致意见的时候,善于提供各种沟通方式,促成团队达成一致意见——知识工作团队中意见分歧是常态,领导者需要协调各方达成共识。

  5. 培养团队成员技能——投资于团队成员的能力成长。

  6. 鼓励建立起合理的授权机制——知识工作者需要自主权,领导者应建立授权机制,让团队实现自我管理。

  7. 通过挑战建立目标,确定团队努力方向——为团队设定明确且有吸引力的愿景。

知识点出处assets/slides/软件质量与管理.第三讲.pdf——团队动力学,知识工作管理与领导力。自主团队的特点以及知识工作领导者品质。

题目来源:本题为2022Fall、2023年考题,在EagleBear习题中有完整答案参考。

四、(本题满分10分)

敏捷宣言有哪些内容?我们该如何正确理解敏捷宣言?

点击查看答案与解析

解答:

敏捷宣言的四条核心价值观

  1. 个体和互动 胜过 流程和工具
  2. 可以工作的软件 胜过 详尽的文档
  3. 客户合作 胜过 合同谈判
  4. 响应变化 胜过 遵循计划

也就是说,尽管右项有其价值,我们更重视左项的价值。

如何正确理解敏捷宣言

  1. 不是否定右项:敏捷宣言并不是说流程和工具、文档、合同谈判、计划不重要,而是强调左项(个体互动、可工作软件、客户合作、响应变化)具有更高的优先级。

  2. "胜过"而非"替代":关键词是"胜过"(over),而非"替代"。敏捷团队仍然需要流程、文档、合同和计划,只是这些不应该是核心关注点。

  3. 价值观导向:敏捷宣言是价值观层面的宣言,不是具体的操作方法。它指导团队在各种决策中做出符合敏捷精神的选择。

  4. 实践服务于价值观:具体的敏捷实践(如Scrum、XP等)都是为了实现这些价值观而设计的,不应本末倒置地将实践本身当作目标。

  5. 与规范方法的关系:计划驱动的开发人员必须敏捷,敏捷开发人员必须规范。敏捷和规范不是对立的两极,而是软件开发中需要平衡的两个维度。

知识点出处assets/slides/软件质量与管理.第二讲.pdf——敏捷运动与敏捷宣言。assets/slides/8敏捷概述.pdf——敏捷宣言的完整内容和理解。assets/slides/课程总结.pdf——敏捷方法的价值观。

题目来源:本题在2020-mid、2022Fall、2023年均以简答题形式出现,在assets/exams/软件质量往年题目整理.pdfassets/exams/软件质量管理-习题-EagleBear.pdf中有完整参考。

五、(本题满分10分)

挣值管理(EVM)前三种解决模式分别是简单、中级以及高级。请分别阐述每种模式的主要特点。

点击查看答案与解析

解答:

简单实现:仅关注进度信息

  • 实现方式
  • 首先需要建立WBS(工作分解结构),定义工作范围
  • 其次为WBS中每一项工作定义一个计划价值(PV, Planned Value)
  • 最后按照一定的规则将某一数值赋给已经完成的工作或正在进行的工作,该值称为挣值(EV, Earned Value)

  • 常用规则

  • 0-100原则:只有当某项任务完成时,该任务的PV值将转化成EV值
  • 50-50原则:只需要开始某项任务,即可以赋原PV值的50%作为EV值,完成时,再加上另外的50%
  • 实际完成的工作所需成本(AC)不对EV值产生任何影响

中级实现:加入日程偏差的计算

  • 在简单实现的基础上,加入日程偏差的计算
  • 典型计算方式有:
  • 日程偏差 SV = EV − PV(Schedule Variance)
  • 日程偏差指数 SPI = EV / PV(Schedule Performance Index)

高级实现:引入成本信息和预测

  • 在中级实现的基础上,加入了成本线(AC, Actual Cost)
  • 添加预测线(BAC, Budget at Completion)
  • 当任务足够多时,可以让预测线尽可能平直
  • 延伸挣值(EV),找到与预测线(BAC)的交点,可以明确项目的落后时间
  • 可以计算:
  • 成本偏差 CV = EV − AC(Cost Variance)
  • 成本偏差指数 CPI = EV / AC(Cost Performance Index)

EVM的好处:可以很好地适应项目的动态变化。

知识点出处assets/slides/软件质量与管理.第四讲.pdf——挣值管理(EVM)的三种实现模式。assets/slides/课程总结.pdf——项目管理中的挣值管理方法。

题目来源:本题为2022Fall、2023年简答题,在assets/exams/软件质量往年题目整理.pdf第28题和assets/exams/软件质量管理-习题-EagleBear.pdf中有完整参考。

六、(本题满分10分)

软件项目规模估算基本要点有哪些?

点击查看答案与解析

解答:

软件项目规模估算的基本要点包括以下四个方面:

1. 尽可能划分详细一些(分解估算)

  • 估算多个部件的时候,总的误差会比各个部件的误差的总和小
  • 将大型任务分解为更小的、可管理的组件进行独立估算,可以提高整体估算的准确性
  • 这是统计学上的基本原理:独立估算的误差会相互抵消

2. 建立对结果的信心

  • 估算本质上是一种猜测,追求的目标应该是一致性
  • 估算结果的使用者需要对估算结果有信心
  • 通过定义好的估算过程和数据收集使用的框架,使估算结果尽可能一致

3. 依赖数据(基于历史数据)

  • 规模估算往往可以依据历史数据来完成
  • 规模估算结果的偏差产生原因相对客观,偏差可以用来修正新的估算结果
  • 高质量的历史数据是准确估算的基础
  • PROBE方法就是充分利用历史数据进行估算的典型方法

4. 估算要的是过程,而非结果

  • 估算的过程是相关干系人达成一致共识的过程
  • 通过估算过程,团队成员对项目范围、复杂度和风险形成共同理解
  • 估算结果本身只是这个过程的一个产出物

知识点出处assets/slides/软件质量与管理.第四讲.pdf——软件项目估算基本要点与PROBE估算方法。规模估算在通用计划框架中的位置和作用。

题目来源:本题为2021Fall、2022Fall、2023年简答题,在assets/exams/软件质量往年题目整理.pdf第15题和assets/exams/软件质量管理-习题-EagleBear.pdf中有完整参考。

七、(本题满分10分)

CMMI-DEV V1.3版本五个不同的成熟度等级分别是什么?为什么四级和五级被称为高等级?与普通等级的本质差别是什么?

点击查看答案与解析

解答:

CMMI-DEV V1.3 五个成熟度等级

等级 名称 特征
1 Initial(原始级) 开发相对混乱,依赖个人英雄主义,没有过程概念,救火文化盛行
2 Managed(已管理级) 项目小组体现出项目管理的特征,有项目计划和跟踪、需求管理、配置管理等
3 Defined(已定义级) 公司层面有标准流程和相应的规范,每个项目小组可以基于此定义自己的过程,使得优秀的做法可以在公司共享
4 Quantitatively Managed(定量管理级) 构建预测模型,以统计过程控制的手段来管理过程
5 Optimizing(优化级) 继续应用统计方法识别过程偏差,找到问题根源并消除,避免未来继续发生类似问题

为什么四级和五级被称为高等级?

四级和五级被称为"高成熟度等级",是因为:

  1. 管理方式的根本转变:四级和五级从被动的、反应式的管理转向主动的、预测式的管理。
  2. 数据驱动:四级和五级依赖统计过程控制(SPC)和量化数据来管理过程,而不是仅凭经验或感觉。

与普通等级(二级和三级)的本质差别

等级2和3关注的是当前状态("我们现在做得怎么样")

  • 等级2确保项目被管理
  • 等级3确保过程被定义和标准化

等级4和5根据结果(未来)进行管理("我们将来会做得怎么样")

  • 等级4通过量化数据预测过程表现
  • 等级5通过统计分析持续优化过程,预防问题发生

本质差别在于:低等级关注"按规范做事",高等级关注"用数据驱动改进,预测并优化未来表现"。

补充:为什么CMMI不应该被视为敏捷方法的对立面

CMMI是过程管理/改进模型,刻画了软件组织从不成熟到成熟的路线图,而大部分敏捷方法(如Scrum、XP)都是开发方法。两者是完全不同性质的事物,将两者对立是不合适的。

知识点出处assets/slides/软件质量与管理.第七讲.pdf——CMMI模型的成熟度等级。assets/slides/课程总结.pdf——CMMI五级特征及高低等级的本质区别。

题目来源:本题在2020-mid、2022Fall、2023年均以简答题形式出现,在assets/exams/软件质量往年题目整理.pdf第7题和assets/exams/软件质量管理-习题-EagleBear.pdf中有完整参考。

八、(本题满分15分)

随着ChatGPT的横空出世,以大模型为代表的AI技术势必对各行各业带来前所未有的影响。具体到软件工程,人工智能技术的应用也日渐常见,请结合这一背景畅想下本课程涉及的若干话题可能在这一波AI浪潮中的挑战和机遇。至少应该包括如下话题:项目管理、质量管理、过程改进。

点击查看答案与解析

解答:

一、项目管理方面的挑战与机遇

机遇

  • 更高级别的自动化和智能决策:AI可以在项目规划和进度管理方面提供更准确的预测,帮助项目经理更好地分配资源、识别风险并制定更有效的计划。
  • 智能化的估算支持:AI可以基于海量历史项目数据,提供比PROBE等传统方法更精准的规模和资源估算。
  • 自动化跟踪与报告:AI可以自动收集和分析项目数据,生成项目状态报告,减少人工跟踪的工作量。
  • 风险预警:AI可以通过模式识别,提前发现项目偏离计划的信号。

挑战

  • 团队需要适应与AI系统的集成,确保人机合作的高效性。
  • 大规模AI模型的训练和部署需要更多的计算资源和时间,项目进度和资源分配成为关键问题。
  • AI项目通常较为复杂,需求可能在开发过程中频繁变化。

二、质量管理方面的挑战与机遇

机遇

  • 自动化测试:AI可以通过自动化测试、静态代码分析和缺陷预测等技术提高软件质量。
  • 智能缺陷预测:基于Yield指标的缺陷预测模型可以借助AI技术大幅提升预测精度,从传统的回归分析升级为基于深度学习的多维预测。
  • 智能代码评审:AI可以辅助甚至部分替代人工代码评审,提高评审效率和覆盖度。
  • 质量指标智能监控:PQI、A/FR、DRL等质量指标可以通过AI实时监控和预警。

挑战

  • AI模型的不透明性和复杂性可能使得测试变得更加困难,难以预测模型在真实场景中的表现。
  • 质量管理需要不断更新,以适应新的测试方法和工具。
  • 需要创新性的测试方法和工具来确保AI系统的可靠性和稳定性。

三、过程改进方面的挑战与机遇

机遇

  • 智能过程分析与优化:AI可以帮助发现效率低下的环节、优化流程,并提供个性化的过程改进指导。
  • 数据驱动的持续改进:结合CMMI高成熟度等级的理念,AI可以更高效地实现统计过程控制。
  • 自动化最佳实践推荐:AI可以基于组织的历史数据,自动推荐适合当前项目的最佳过程元素组合。
  • 知识沉淀与复用:AI可以将团队经验转化为可复用的知识库,加速组织从CMMI Level 1到更高等级的演进。

挑战

  • 团队需要对新技术的接受和应用进行适应,同时保持对人的关怀,确保人机协同工作的顺畅。
  • 引入新技术可能需要更新现有的开发流程和规范(如PDCA、IDEAL等过程改进模型需要纳入AI元素)。
  • 关注数据质量和模型可解释性将成为过程改进的重要方向,以确保AI系统的可解释性和可信度。
  • 过程改进不能完全依赖AI——软件开发本质上是知识工作,人的创造性和判断力不可替代。

知识点出处:本题为开放性论述题,需综合运用本课程各讲内容。项目管理对应第四讲(估算、计划、跟踪、EVM);质量管理对应第五讲(PSP质量策略、A/FR、PQI、Yield等);过程改进对应第七讲(CMMI、PDCA、IDEAL、DevOps)。

题目来源:本题为2022Fall、2023年A卷开放性论述题。在assets/exams/软件质量往年题目整理.pdf第32题和assets/exams/软件质量管理-习题-EagleBear.pdf中有参考答案框架。

知识点分布总结

题号 考查内容 对应课件
一(1) 代码评审(Measure twice, cut once) 第二讲
一(2) 软件发展三大阶段 第二讲
一(3) Brooks本质困难 第二讲
一(4) 软硬件一体化阶段实践 第二讲
一(5) WBS工作分解结构 第四讲
一(6) EVM挣值管理 第四讲
一(7) 客户需求 vs 产品需求 第四讲
一(8) 集成策略 第六讲
一(9) 规模估算与度量 第四讲
一(10) PSP缺陷日志 第五讲
一(11) DRL缺陷消除杠杆 第五讲
一(12) PQI过程质量指标 第五讲
一(13) Quality Journey质量旅程 第五讲
一(14) 状态机验证 第六讲
一(15) 设计验证手段 第六讲
敏捷、CMM/CMMI、PDCA/IDEAL辨析 第二讲、第七讲
知识工作与领导力 第三讲
敏捷宣言 第二讲、第八讲(敏捷概述)
EVM三种实现模式 第四讲
规模估算要点 第四讲
CMMI成熟度等级 第七讲
AI与软件工程(综合论述) 全课程综合