摘要
本文覆盖了 2023Fall 课堂习题和目前全部的往年考试题,根据题型做了分类,部分题目提供了参考答案,如对答案有疑问,请联系博主本人探讨。
课程沿革:
- 2023Fall-软件质量管理
- 2022Fall-软件质量与管理
- 2021Fall-软件质量与管理
- 2018Fall-软件过程与管理
客观题
概述-思考和讨论
以下说法是否正确?为什么?
表述 | 原因 | 判定 |
---|---|---|
软件过程管理是软件项目管理应该要实现目标 | 软件过程管理和软件项目管理完全是两回事,项目过程管理应当有专门的人去做,因此并不是实现目标 | × |
【2022Fall】在公司导入敏捷过程是我们今年过程改进的主要目标 | 过程管理和过程改进是类似的,这个说法是合理的,但是操作的时候可能存在问题。 | √ |
XP 与 CMM/CMMI 是对立的两种软件开发方法 | CMM 和 CMMI 并不是软件开发方法,而是软件过程管理和改进,CMM 和 CMMI 是没有较大区别的;XP 的观念确实与严格的 CMM/CMMI 是对立的;XP 是软件开发方法,敏捷的 | × |
【2022Fall】CMM/CMMI 不适合当今互联网环境的项目管理需求 | CMM/CMMI 是用来做过程管理和改进的,根本不是满足项目管理需求的手段 | √ |
【2022Fall】PDCA 和 IDEAL 不适合在敏捷环境中使用 | PDCA,IDEAL 是软件过程改进参考元模型,因此是适合在敏捷环境中使用的 | × |
不同的软件开发过程应该使用不同的生命周期模型,反之亦如此 | 生命周期模型是由人类划分的,不一定 | × |
软件过程的历史演变-课堂练习
题面 | 选项 | 解析 |
---|---|---|
【2022Fall】“Measure twice,cut once”描述的是下述哪个软件开发场景: | A. 软件设计; B. 代码评审; C. 需求开发; D. V&V; E. 软件测试 |
B;这句话强调了在应用更改之前仔细检查代码以在问题成为主要问题之前识别和纠正问题的重要性 |
【2022Fall】整体来看,我们可以把软件的发展分为三大阶段,以下不属于三大主要阶段的是: | A. 软硬件一体化; B. 网络化和服务化; C. 云计算化和云原生; D. 软件成为独立产品; |
C |
【2022Fall】以下描述中,不属于软件开发本质困难或者本质挑战的是: | A. 质量难题; B. 复杂性; C. 不可见; D. 一致性; |
A |
【2022Fall】以下描述中,哪一种实践是软硬件一体化阶段的典型实践: | A. Code and Fix; B. 迭代式开发; C. 瀑布生命周期模型; D. 成熟度模型; |
A |
团队动力学-课堂练习
TSP 和 SCRUM 的团队的组成有哪些共性?这些共性对于高效团队有什么帮助?
题面 | 选项 | 解析 |
---|---|---|
对比 TSP 和 SCRUM ,下列说法不恰当的是: | A. 都是过程框架,需要填补具体实践之后才是一个可以工作的过程; B. 一种是计划驱动方法,另外一种是敏捷方法; C. SCRUM 适合迭代式场景, TSP 适合瀑布场景; D. 两种方法都需要进行度量数据收集、分析,从而支持管理决策。 |
BC;计划驱动和敏捷不是对立的;SCRUM 更适合需要快速迭代和灵活变更的场景,而 TSP 更适合对过程管理和控制要求更高的场景 |
以下特征适用麦克勒格 Y 理论(McGregors Theory Y)激励的场合是 | A. 关注工作环境,薪金等; B. 更喜欢经常的指导,避免承担责任,缺乏主动性 C. 自我中心,对组织需求反应淡漠,反对变革 D. 能够自我约束,自我导向与控制,渴望承担责任 |
D |
以下关于马斯洛的需求层次理论描述不正确的是: | A. 自我实现是寻求自尊(Esteem) B. 激励来自为没有满足的需求而努力奋斗 C. 低层次的需求必须在高层次需求满足之前得到满足 D. 满足高层次的需求的途径比满足低层次的途径更少 |
AD;自我实现是第五层,自尊在第四层;另外,马斯诺晚年对这一理论进行修正,认为高层次的需求不一定要在低层次需求被满足之前实现,因此 C 也不对。 |
以下关于团队动力学的论述, 不恰当的是: | A. 马斯洛的需求层次理论可以用来更好地维持激励水平; B. 智力工作的激励方式中,应该尽可能使用鼓励承诺这种方式; C. 麦克勒格的 X 理论适合用马斯洛底层需求激励; D. 海兹伯格的激励理论区分为内在因素和外在因素两种 |
A;马斯洛的需求层次理论可用于指导激励手段的选择,不是激励维持手段 |
估算、计划和跟踪-课堂练习
题面 | 选项 | 解析 |
---|---|---|
【2022Fall】下述关于 WBS 的描述中哪些说法不正确的 | A. WBS 应该对应 OBS(Organization Breakdown Structure) B. WBS 提供了范围管理的基础 C. WBS 工作分解最底层的要素是实现目标的充分必要条件 D. WBS 分解的时候同一层不能应用不同标准 |
A;WBS 和 OBS 关注的角度和目的不同 |
【2022Fall】下述关于 EVM 的描述中哪些说法不正确的 | A. EVM 不适用于质量管理 B. EVM 的中级实现中引入成本信息 C. EVM 高度依赖估算准确 D. EVM 可以适应需求变更 |
B;EVM 只进行进度和成本管理,与质量无关;高级引入的才是成本信息 |
质量管理-课堂练习
题面 | 选项 | 解析 |
---|---|---|
关于 PSP 质量管理策略,下列说法中正确的是: | A. 用缺陷管理替代质量管理,既有必要性,也有合理性; B. 基本无缺陷的开发是通过开展高质量的评审来实现的; C. 经过训练,评审是所有消除缺陷的手段当中最高效的; D. PSP 质量策略主要解决的是外部质量,而非内部质量; |
ABD;编译是最高效的缺陷消除手段;PSP 使用面向用户的视图,主要解决外部质量 |
【2022Fall】关于 DRL,下列说法中不正确的是: | A. 这是一种模块级开发中质量控制的指标 B. DRL 以单元测试每小时发现缺陷率作为基准,考察上游其他缺陷消除阶段的消除效率; C. DRL 以单元测试发现的缺陷个数作为基准,考察上游其他缺陷消除阶段消除缺陷的效率; D. DRL 只能预测,不能度量 |
CD;缺陷消除效率比 DRL 只能度量,不能预测 |
【2022Fall】关于 PQI,下列说法中不正确的是: | A. PQI 表征模块级别开发中的过程规范化程度 B. PQI 越高越好,可以充分保障质量; C. PQI 越低越好; D. PQI 不能用作质量规划 |
BCD;PQI 大于 0.4 即可,过大成本太高;PQI 可以用作质量规划和过程改进 |
关于 PQI,下列说法中正确的是: | A. PQI 可以辅助判断模块开发质量 B. PQI 可以提供过程改进的依据 C. PQI 确保大于 1,从而确保开发质量; D. PQI 只能预测,不能度量 |
AB |
关于 Yield,下列说法中正确的是: | A. Yield 可以辅助判断模块开发质量 B. Yield 可以提供过程改进的依据 C. Yield 区分为 Process Yield 和 Phase Yield; D. Yield 只能预测,不能度量 |
ABCD |
关于评审速度,下列说法中正确的是: | A. 进行代码评审的时候,控制评审速度不超过每小时 1000LOC 就能实现大部分质量要求; B. 实战中,评审速度应该根据资源水平而定,时间充分就评审慢一些; C. 文档评审速度应该控制每小时不超过 4 页; D. 评审速度与人的技能有关,技能强的人可以突破每小时 1000LOC 代码这个限制; |
C;评审的速度应该基于项目的需求和时间限制 |
【2022Fall】关于 Humphrey 梳理的 Quality Journey,下列说法中正确的是: | A. Quality Journey 中列出的步骤可以在适当的时候更换顺序; B. 由于需求是一切工程活动的基础,因此加强需求开发应该是 Quality Journey 早期的必备步骤; C. Quality Journey 仍然仅仅是在“用缺陷管理替代质量管理”这一基本策略之下进行讨论; D. Quality Journey 中测试应该先于评审得到贯彻和改善; E. 加强团队评审是 QJ 后期的步骤 |
CD;先后顺序不能改变;QJ 并不包括需求开发 |
下述设计模板中用来记录内部动态信息的是: | A. OST; B. SST; C. LST; D. FST; |
B |
下述关于 PSP 四大设计模板和 UML 典型设计图的描述中完全正确的是: | A. OST 在 UML 中没有对应的设计图; B. UML 中的类结构以及类之间的关系,在 PSP 四大设计模板中无法体现; C. LST 在 UML 中可以通过类图来体现; D. FST 在 UML 中可以通过类图来体现; |
B;OST 对应用例图和时序图;LST 无对应体现;FST 体现了方法的行为而类图不能 |
下列关于各种设计验证手段的描述中正确的是: | A. 执行表是唯一一种提供全面设计验证的手段; B. 跟踪表是唯一一种提供全面设计验证的手段; C. 受限于手工方式,都易于出错; D. 符号化执行不适合复杂算法; E. 执行表是跟踪表的扩展 |
C;符号化验证才是唯一一种提供全面设计验证的手段;符号化验证适合复杂的计算过程,不适合复杂的逻辑 |
【2022Fall】一个完全正确的状态机应该满足: | A. 没有死循环和陷阱; B. 状态转化条件满足正交性; C. 状态转化条件满足完整性; D. 状态转化条件满足独立性; E. 符合设计意图 |
ABCE; |
下述关于质量的描述中,哪些说法不正确的? | A. 质量是一种多重属性的组合 B. 最终用户一般不能感知内部质量 C. 安全和保密一般不是质量要素 D. 质量与主观感受有关 |
C; |
下述关于质量控制指标,哪些说法正确? | A. A/FR 应该是越高越好 B. Yield 是一种精确度量模块质量的手段 C. 评审活动应该早于编译或者测试活动而开展 D. PQI 只能事后统计,不能用于指导质量计划 |
C;A/FR 达到 2.0 即可;Yield 是估计度量,不可能精确度量;先评审后编译可以减少编译和测试的时间;PQI 可以预测和度量,可以指导质量计划 |
下述设计验证手段的描述,哪些是正确的? | A. 符号化执行容易引入人为错误 B. 状态机验证是唯一一种提供一般意义的上的正确性检验的验证手段 C. 执行表对设计缺陷的验证能力强于跟踪表 D. 正确性检验是唯一可靠的设计验证手段 |
A; |
关于使用程序正确性证明手段验证 while-do 循环设计的描述中,正确的是: | A.如果设计是正确的,那么应满足的条件之一是循环判断条件最后一定可以变为 false; B.如果设计是正确的,那么应满足的条件之一是循环判断条件为真的时候,单独的循环结构执行结果与循环体再加一个循环结构,其执行结果一致; C.如果设计是正确的,那么应满足的条件之一是循环判断条件为 false 的时候,循环体内所有变量不能被修改; D.该方法并不能保证循环体算法实现设计意图。 |
ABCD |
团队工程开发-课堂练习
题面 | 选项 | 解析 |
---|---|---|
【2022Fall】下面描述属于典型客户需求的是: | A. 客户期望; B. 预算限制; C. 法律法规限制; D. 系统功能描述 |
ABC |
在团队设计活动中,应该注意设计标准,下列属于典型的设计标准应该约定的是: | A. 命名规范; B. 接口标准; C. 出错或者异常处理信息; D. 设计表示方式 |
ABCD |
典型地,在团队设计活动中,应该注意哪些内容: | A. 设计标准的应用; B. 复用的考虑; C. 可测试性支持; D. 可用性支持 |
ABCD |
【2022Fall】关于集成策略,下述描述中正确的是: | A. 当待集成组件质量普遍不高的时候,不可以使用扁平化策略; B. 当需要尽早获取可以工作的组件的时候,应该使用集簇式策略; C. 当待集成组件质量普遍较高的时候,可以使用大爆炸式集成策略; D. 持续集成本质上就是逐一添加策略。 |
BCD |
当考虑集成策略的时候,应该注意如下哪些方面? | A. 待集成组件的质量状态; B. 待集成组件的获取方式; C. 待集成组件的功能和关系; D. 待集成组件的数量; |
ABCD |
关于扁平化集成策略和集簇式集成策略,下述说法中正确的是: | A.扁平化策略可以较早地充分地暴露系统级别的错误; B.扁平化策略对于系统级别错误的暴露能力有限; C.集簇式集成策略有助于复用策略的实现; D.扁平化策略和集簇式策略的优缺点正好相反; |
BC;A 能较早但不能充分;关注点不同,应该不是恰恰相反 |
下述活动是典型的验证(Verification)的是: | A.需求评审; B.详细设计评审; C.单元测试; D.试运行; |
BC; |
下述活动是典型的确认(Validation)的是: | A.验收测试; B.代码评审; C.系统测试; D.持续集成; |
A; |
下述产物中属于典型的确认(Validation)对象的是: | A.接口设计文档; B.源代码; C.用户手册; D.系统使用培训材料(视频、录像等); |
BCD;TODO:B 为什么是对的? |
下述关于需求开发的描述中,哪些是正确的? | A.客户需求是指客户提出的关于软件功能的具体要求 B.工期或者预算往往都是客户需求的一个方面 C.产品需求需要跟客户充分讨论才能获取 D.客户应该在需求开发活动中起到主导作用 |
BC; |
项目支持活动-课堂练习
题面 | 选项 | 解析 |
---|---|---|
下述产物中属于典型的配置项是: | A. 接口设计文档; B. 源代码; C. 用户手册; D. 系统使用培训材料(视频、录像等); |
ABCD |
团队内部的配置审计通常应该关注什么: | A. 物理审计; B. 配置项列表; C. 配置管理记录; D. 基线计划; |
ABCD |
下列关于决策分析的论述中,不恰当的是: | A. 决策分析指南中最关键的是明确需要开展决策分析活动的判定标准,即什么场合之下需要开展正式的决策分析活动; B. 评价方法是体现决策者利益诉求的关键,因此,需要谨慎设计; C. 候选方案的识别应该晚于于评价标准; D. 现实生活中的项目投标就是一个典型的决策分析活动; |
BD;评价标准才是关键;招标才是决策分析过程 |
下列关于根因分析的论述中,不恰当的是: | A. 根因分析必须基于丰富的数据来选择合适的问题; B. 鱼骨图是根因分析的有效手段; C. 典型地,可以从技术、人员、培训以及过程角度开展根因分析; D. 根因分析活动终止的唯一特征就是找到相应的根因的明确解决方案; |
AD;有的时候没有丰富的数据;或者确定没有解决方案 |
2022Fall-选择题
题面 | 选项 | 解析 |
---|---|---|
以下关于规模估算和度量的描述中,正确的是: | A. 功能点是一种可提供精确规模度量结果的方式 B. 规模数据扮演了沟通历史数据的桥梁的角色 C. 规模估算通常不用于质量计划当中 D. PROBE 只用于规模估算 |
B;功能点可以在项目早期提供直观结果,但不能精确度量;规模估算主要关注项目的工作量和资源需求,而质量计划则关注确保项目交付的质量和符合性 |
关于 PSP 缺陷日志,哪些信息是至关重要的 | A.缺陷发现时间 B.缺陷重现方式 C.缺陷根因描述 D.缺陷关联的其他缺陷 |
AC; |
2021Fall-选择题
2020Fall-期中选择题
题面 | 选项 | 解析 |
---|---|---|
关于 Brooks 提及的软件开发本质难题,下列说法中不准确的是: | A. 本质难题总共有四个,分别为复杂、不可见、可变和质量挑战 B. 既然是本质难题,那就说明是根植于软件开发本身,因而是不可能在软件开发当中得到缓解 C. 严格来说,只有不可见才是真正的“本质”难题,其他三个因项目而异 D. 四大本质难题贯穿软件发展的不同历史阶段,但是在不同历史阶段,相互凸显程度不一样 |
AB;质量挑战不是本质难题;本质难题可以缓解,不可消除 |
下列软件应用和开发的典型特征中属于软硬件一体化阶段的是 | A. 可以通过引入操作系统,摆脱了硬件束缚:软件成为独立的产品 B. 几乎不需要考虑 需求变更 C. 缺乏科班的软件工程师 D. 系统兼容对应软件开发的成败非常关键:软件成为独立的产品 |
BC; |
下列名词和术语中不属于软件过程的有哪些 | A. SCRUM B. CMM/CMMI C. GATE 方法 D. IDEAL |
BD; |
下列哪些项不属于管理活动应该包含的要素 | A. 成本 B. 质量 C. 目标 D. 工期 |
ABD;管理活动的要素是目标、状态、纠偏;三大典型目标是成本、质量、工期 |
完成一份完整的项目日程计划,需要下列哪些信息 | A. 任务清单 B. 任务顺序 C. 质量要求 D. 人员资源水平 |
ABD; |
在 TSP 的团队组建过程中,确定软件开发策略的是第几次会议 | A. 第一次 B. 第二次 C. 第三次 D. 第四次 |
C |
下列术语描述的技术或者方法是同类型的是 | A. CMMI SPICE PDCA B. IDEAL XP SCRUM C. Cleanroom Gate TSP D. Waterfall SCRUM XP |
CD;SPICE 是软件过程管理;IDEAL 是软件过程改进,XP 和 SCRUM 是软件过程;C 都是软件过程;D 都是软件实践 |
下列关于挣值管理方法的描述中错误的是 | A. 这是一种可以用来跟踪项目预算消耗的方法 B. 这种方法高度依赖估算准确性 C. 这种方法可以支持质量管理 D. 这种方法可以用来跟踪项目进度 |
C |
下列描述当中,属于过程经理的工作内容有哪些? | A. 建立团队的开发标准 B. 主持项目周例会 C. 记录周例会的会议记录 D. 制定开发计划 |
AC |
更早的选择题
出处 | 题面 | 选项 | 解析 |
---|---|---|---|
2015B | CMM 的创始人是哪位 | A. Boehm B. Juran C. Humphrey D. Crosby |
C |
2015B | XP 规定开发人员每周工作时间不超过___小时,连续加班不可以超过两周,以免降低生产率? | A. 30 B. 40 C. 50 D. 60 |
B |
2015B | 下列不属于看板方法典型实践的是 | A. 可视化工作流 B. 站立式会议 C. 限定 WIP D. 重构 |
BD |
2015B | 下述内容在状态机验证中不用以验证状态机本身是否正确的是 | A. 没有隐藏的陷阱和死循环 B. 状态转换是否完整 C. 状态描述是否完整 D. 状态转换是否正交 |
C |
2015B | 为了制定 Schedule plan,下述描述中,哪一项是不需要的 | A. Task size B. Task Order C. Schedule Hour D. Task hour for each task |
A |
2015B | 在上题中,还需要补充下述哪一项数据就可以定义 Schedule Plan 了 | A. Task List B. Plan Value C. Earned Value D. Nothing |
A |
主观题
2023Fall-预测
- 敏捷宣言的内容、如何理解敏捷宣言
- 挣值管理的三种实现方式
- 估算的要点
- CMMI
- DevOps
- 软件发展的三大阶段,描述不同阶段的典型软件开发方法和实践。
- 生命周期模型、瀑布模型
2022Fall
【2022Fall】结合“软件开发作为一种知识工作,需要领导者而不是一般的经理”,阐述知识工作领导者应该具备的品质或者特点(至少三项)。(9 分)
项目组长的目标和衡量指标:
- 项目组长应当建设和维持高效率的团队。
- 项目组长应当激励团队成员积极工作。
- 项目组长应当合理处理团队成员的问题。
- 项目组长应当向管理层提供项目进度相关的完整信息。
- 项目组长应当充当合格的会议组织者和协调者。
典型 TL 技能:
- 你是天生的领导者
- 你有能力识别问题的关键并且做出客观的决策
- 你不介意偶尔充当“恶人”
- 你尊敬你的团队成员
TL 的工作内容:
- 激励团队成员努力工作
- 主持项目周例会
- 每周汇报项目状态
- 分配工作任务
- 维护项目资料
- 组织项目总结
【2022Fall】【2021Fall】【2020-mid】请完整描述敏捷宣言的内容。我们应该如何正确理解敏捷宣言?(10 分)
- 敏捷软件开发宣言的 4 个简单的价值观:
- 个体和互动 高于 流程和工具
- 工作的软件 高于 详尽的文档
- 客户合作 高于 合同谈判
- 响应变化 高于 遵循计划
- 也就是说,尽管右项有其价值,我们更重视左项的价值
【2022Fall】挣值管理的三种实现方式。分别是简单、中级以及高级。请分别描述上述三种方式的基本要点。(10 分)
- 简单实现:这种方式仅仅关注进度信息。在实现时,首先需要建立 WBS,定义工作范围;其次为 WBS 中每一项工作定义一个价值(PV);最后按照一定的规则将某一数值赋给已经完成的工作或者正在进行的工作。常用规则分别为 0-100 规则和 50-50 规则,前者只有当某项任务完成时,该任务的 PV 值将转化成 EV 值;后者只需要开始某项任务,即可以赋原 PV 值的 50%作为 EV 值,完成时,再加上另外的 50%。而实际完成的工作所需成本 AC 不对 EV 值产生任何影响。
- 中级实现在简单实现的基础上,加入日程偏差的计算。典型计算方式有:
- 日程偏差 SV = EV – PV;
- 日程偏差指数 SPI = EV/PV;
- 高级实现在中级实现的基础上,还需要考察项目的实际成本。
【2022Fall】【2021Fall】软件项目规模估算基本要点有哪些?(10 分)
- 估算要点之一:尽可能划分详细一些
- 估算要点之二:建立对结果的信心
- 估算要点之三:依赖数据
- 估算要点之四:估算要的是过程,而非结果;估算的过程是相关干系人达成一致共识的过程
【2022Fall】CMMI—DEV V1.3 版本五个不同的成熟度等级分别是什么?为什么四级和五级被称为高等级?与普通等级的本质差别是什么?【2020-mid】解释为何 CMMI 模型不应该是敏捷方法的对立面(10 分)
五个等级的特征:
- Initial 原始级别:开发相对混乱,依赖个人英雄主义,没有过程概念,救火文化盛行
- Managed 已管理级别:项目小组体现出项目管理的特征,有项目计划和跟踪、需求管理、配置管理等
- Defined 已定义级别:公司层面有标准流程和相应的规范,每个项目小组可以基于此定义自己的过程,使得优秀的做法可以在公司共享。
- Quantitatively Managed 定量管理级别:构建预测模型,已统计过程控制的手段来管理过程
- Optimizing 优化级:继续应用统计方法识别过程偏差,找到问题根源并消除,避免未来继续发生类似问题。
TODO:为什么四级和五级被称为高等级?与普通等级的本质差别是什么?
原因解释: 1. CMMI 是过程改进模型,刻画了软件组织从不成熟到成熟的路线图。 2. 大部分敏捷方法都是开发方法 3. 因此两者是完全不同性质的事物,将两者对立是不合适的。
【2022Fall】随着 ChatGPT 的横空出世,以大模型为代表的 AI 技术势必对各行各业带来前所未有的影响。具体到软件工程,人工智能技术的应用也日渐常见,请结合这一背景畅想下本课程涉及的若干话题可能在这一波 AI 浪潮中的挑战和机遇。至少应该包括如下话题:项目管理、质量管理、过程改进。(15 分)
2021Fall
【2021Fall】【2020-mid】我们如何理解瀑布模型(6 分)
- 瀑布模型不是单一模型,是一系列模型,覆盖最简单场景(过程元素少)到最复杂的场景(过程元素多)
- 软件项目应该结合实际情况选择合适过程元素的瀑布模型,基本原则是,项目面临困难和挑战越多,选择的模型应该越复杂
- 软件项目团队往往低估项目的挑战,选择了过于简单的不适用的瀑布模型
【2021Fall】解释⾄少 5 个 DevOps 技术、实践、⽅法(10 分)
- 方法论基础是敏捷软件开发、精益思想以及看板 Kanban 方法。
- 以领域驱动设计为指导的微服务架构方式
- 大量虚拟化技术的使用
- 一切皆服务 XaaS(X as a Service)的理念指导
- 构建了强大的工具链,支持高水平自动化
【2021Fall】列出 TSP ⻆⾊并解释 5 个的职责(10 分)【2016】TSP 项目经理、过程经理、计划经理的工作内容、项目总结角度(9 分)
- 项目组长
- 计划经理:开发完整的、准确的团队计划和个人计划;每周准确的报告项目小组状态
- 开发经理:开发优秀的软件产品;充分利用团队成员的技能
- 质量经理:项目团队严格按照质量计划开展工作,开发出高质量的软件产品;所有的小组评审工作都正常开展,并且都形成了评审报告
- 过程经理:所有团队成员准确的记录、报告和跟踪过程数据;所有的团队会议都有相应会议记录。
- 支持经理:项目小组在整个开发过程中都有合适的工具和环境;对于基线产品,不存在非授权的变更;项目小组的风险和问题得到跟踪;项目小组在开发过程中满足复用目标
- 开发人员
【2021Fall】给⼀个挣值管理的表格,项目进度提前还是落后?有可能出现什么⻛险?(10 分)
【2021Fall】设计⼀个 Yield 预测模型。描述如何建模;需要哪些数据,有什么要求;⽤什么⽅法构建模型并预测?(10 分)
2020Fall-mid
【2020-mid】请结合软件发展的三大阶段,描述不同阶段的典型软件开发方法和实践。【2018Fall】软件发展三大阶段的特点和主流开发方法
- 软硬件一体化
- 特点:软件支持硬件完成计算任务、功能单一、复杂度有限、几乎不需要需求变更
- 主流开发方法:三思而后行;Code and Fix;编码 + 改错
- 软件成为独立的产品
- 特点:摆脱了硬件的束缚(操作系统)、功能强大、个人电脑出现、需求多变、兼容性要求、来自市场的压力
- 主流开发方法:形式化方法、结构化程序设计和瀑布模型
- 网络化和服务化
- 特点:功能更复杂、规模更大、用户数量急剧增加、快速演化和需求不确定、分发方式的变化、进一步的服务化和网络化、盛行开源和共享文化
- 主流开发方法:迭代式开发、敏捷开发(XP、Scrum、Kanban)、开源软件开发方式、DevOps
【2018Fall】【2020-mid】生命周期模型与软件过程的区别和联系
- 生命周期模型是对一个软件开发过程的人为划分。
- 生命周期模型是软件开发过程的框架,是对软件开发过程的一种粗粒度划分。
- 生命周期模型往往不包括技术实践。
【2020-mid】请结合软件开发的特点介绍软件项目管理中自主型团队的必要性以及自主团队应该具备的特征?5 分
- 软件开发是一项既复杂又富有创造性的知识工作 (1')
- 软件开发是一种智力劳动 (1')
- 处理和讨论 极其抽象的概念
- 把不同的部分(不可见)整合成一个可以工作的系统
- 自主团队具备如下的特点: (每两点 1 分)
- 自行定义项目的目标
- 自行决定团队组成形式以及成员的角色
- 自行决定项目的开发策略
- 自行定义项目的开发过程
- 自行制定项目的开发计划
- 自行度量、管理和控制项目工作
【2020-mid】请描述一下 PROBE 方法的基本原理(4'):2 点
【2020-mid】【2018Fall】请描述一下 PROBE 方法的过程(4'):流程图
【2020-mid】使用 PROBE 方法估算时间的时候,为什么不使用历史数据中的生产效率数据?(2')在估算资源需求(例如,人时)的时候,生产效率一般在分母上,考虑到个体软件工程师生产效率波动,容易导致估算偏差范围变大。
【2020-mid】请描述 PROBE ABCD 方法在估算规模的时候,对历史数据的质量有什么要求? (10 分):如上估算规模图示
【2020-mid】请简要描述按照通用计划框架,为了开发合理的项目计划,应该要做哪些估算?PROBE 方法充当什么角色。
- 估算框架如上图
- 虚线框即为 PROBE,用来完成规模和资源的评估
2018Fall
【2018Fall】软件项目管理和软件过程管理
- 软件项目管理是应用方法、工具、技术以及人员能力来完成软件项目,实现项目目标的过程。
- 软件过程管理是为了让软件过程在开发效率、质量等方面有着更好性能绩效。
【2018Fall】Devops 的特点,为什么流行?
【2018Fall】什么是云原生?相关的重要的概念
【2018Fall】精益屋的两大支柱?
【2018Fall】JIT 及时生产,价值流和价值拉动的关系
【2018Fall】什么是面向用户的质量观?这对质量管理的策略有什么影响?
更早的参考题目
【2014】马斯洛的“人的需求层次理论”描述的需求层次有哪几个?这样分层对软件开发有什么启发?6'
【2014】应对风险的典型策略有哪些?请举例说明
【2014】为了确保最终软件产品的质量,在项目计划阶段应该注意哪些问题?4 分
【2013】【2014】【2015A】【2015B】【2016】如何制定一份让人无法拒绝的计划,请描述基本步骤和一些注意事项 10'
- 制定任务计划和日程计划:前者描述项目所有的任务清单,任务之间的先后顺序、以及每个任务所需时间资源,后者描述了各个任务在日程上的安排,哪天开始哪天结束;
- 制定资源计划
- 这种日程计划的关键是必须用正推的方式来制订项目计划。一个典型的项目计划框架如下图
- 在这个过程中,除了概要设计和资源估算之外,其他环节尽可能自动化完成。充分参考历史数据进行估算。
【2015B】请解释在质量保障活动中的 V&V 分别是什么含义?两者之间的关系是什么?5 分
【2014】请举例说明验证和确认的区别和联系? 4 分
【2013】【2015A】产品组件集成策略有哪些?请解释这些策略的优缺点。在此基础上,解释如果要实现高质量集成,可能需要注意哪些方面。
【2014】请罗列集成测试的典型策略,并且解释各个集成测试策略的优缺点?8'
【2014】请解释需求开发中客户需求和产品需求的差别,并设计一个流程来完成需求开发工作?6'
【2015B】请给出需求开发的完整过程,并且解释客户需求和产品需求的各自含义以及在需求开发过程中该如何体现客户需求和产品需求?8'
【2015B】【2016】请结合 SCRUM 这种敏捷方法论述敏捷方法应该具备的特征?同时解释为何常见的若干种描述敏捷方法对立面的方法的特征(例如,严格、重型、计划驱动等等)并不合适?10'
- 特征
- 小周期迭代
- 快速响应变更
- 价值交付
- 自动化
- 特征解释:
- 严格:所有优秀的工程方法和实践都是严格的。
- 重型:如上,此外,轻量级和重型其实并没有刻画具体方法,何为重型,并没有严格定义;而且,对于变更这件事情,几乎所有方法都是限制,因此,很难说敏捷方法是轻量级方法。
- 计划驱动:所有正式的项目都是计划驱动的,否则计划的作用无法体现
【2015A】敏捷方法的特征有哪些?哪些关于敏捷特征的说法施加于敏捷方法之上是不合适的?为什么?10'
- 特征:小周期迭代式持续交付、敏捷宣言
- 关于敏捷方法的一些特征表述可能带着一定的误导,例如:
- 轻量级方法:这是对以 XP 为代表的一类方法的误导,事实上,这类方法对工程规范有着极为严格的要求;
- 拥抱变更、变更驱动:仅仅是口号,对待变更,所有软件工程方法都是限制和管理的态度。
- TDD 可以提供更高的开发质量:并没有足够的证据支持。
【2014】为何说将“规范方法”、“计划驱动方法”等特征作为敏捷方法的对立面带有很大的误导性质?如何通过多种维度改进这种对各类开发过程的理解?10'
- 敏捷:敏捷目的、敏捷价值观、敏捷原则
- 影响敏捷与规范方法选择的五个维度
- 如果只有强有力的规范而缺乏敏捷,将导致官僚作风,进而停滞不前。团队将陷入为了测量而测量的处境之中,缺乏创新。
- 缺乏创新的敏捷则如同一个新创公司在盈利之前的不负责任的狂热
- 计划驱动的开发人员必须敏捷,敏捷开发人员必须规范。
【2016】Devops 三个步骤
【2014】解释过程度量项定义时应当注意的方面,并且据此评价 PSP 基本度量元的合理之处?6'
【2014】如何对某个软件产品组件进行产品质量评价?可以选择哪些度量元,这些度量元如何辅助判断产品组件的质量? 8'
【2014】请区分质量管理和缺陷管理之间的联系和差异,并解释为何在软件开发中将质量和生产效率两者进行妥协不合适?6'
【2014】为了追求极高的软件产品的质量目标,可能有的方法和这些方法的先后顺序分别是什么?8'(质量路径)
质量实践和质量管理是不一样的
- 质量实践包括测试等等
- 质量管理是对质量的管理,而不是实践,管理必须有上面所说的三个要素
【2013】【2015A】【2018Fall】谈谈你对项目估算的认识,并简要解释应用 PROBE 方法估算的优缺点
【2014】请解释规模估算和资源估算中估算偏差含义之间的差异,并据此简要列举对软件开发活动的启发?
基于风险分析平衡敏捷与规范 1. 敏捷风险 > 计划驱动风险,启用基于风险的计划驱动方法 2. 计划驱动风险 > 敏捷风险,启用基于风险的敏捷方法 3. 不能判断,则通过架构把敏捷部分封装起来,在敏捷部分使用基于风险的敏捷方法,在其他地方启用基于风险的计划驱动方法。
【2013】基于 Yield 指标构建缺陷预测模型,并列举该模型的可能改进方案
- 总体思想:利用回归技术预测软件开发过程中各阶段的 Inject Rate(缺陷注入率)和 Yield(缺陷消除率)
- Yield 指标只能用来估算,不可以用来度量。结合 Yield 指标和上图,只需要知道如下指标就可以基于 Yield 指标构建一个基本的缺陷预测模型:
- 注入阶段注入多少缺陷
- 缺陷注入的密度(需求每一页注入多少缺陷)
- 缺陷注入的速度(每小时注入多少缺陷)
- 消除阶段的缺陷注入密度和速度。
- 历史数据中的软件规模、文档规模、开发人员规模
- 步骤
- 确定纳入影响因子的数据以及数据度量方法
- 从系统历史库中收集历史数据,并进行整理
- 依照回归技术进行计算
- 在项目进行过程中不断收集数据,与预测数据进行比较,调整回归参数
- 项目过程中依据实际数据与预测数据的误差进行风险的预防、识别和控制
【2015B】请解释 A/FR,PQI 的计算方式,并且解释这两个指标有什么用途?10'
【2015A】请结合 A/FR、PQI、Review Rate、DRL、Yield 尽可能具体描述一个软件项目应该如何从多方面来确保开发的高质量?10'
这些指标既是开发过程中质量管理的一些参考指标,同时也体现在计划安排中应该注意的质量元素。具体如下: 1. 在项目计划过程中应该安排确保高质量开发结果的活动,例如,按照 A/FR、PQI 等指标的要求,安排对各类产物(文档和代码)的个人评审和小组评审; 2. 这些评审活动应该满足一定的要求,特别体现在时间方面。例如,评审时间应该多于测试时间的两倍以上(A/FR);评审时间应该是相应开放时间的 50%以上(PQI);评审速度要求(Review Rate)等 3. 充分借鉴质量指标所体现的开发质量状况,尽早制订相应的质量补救措施。例如,PQI 所体现的缺陷密度、所有上述指标的参考值等等。一旦超标,往往意味着质量方面有偏差,应当及时补救。 4. 利用 yield 等指标,构建质量预测模型,更加积极(Proactive)地判定和控制开发质量; 5. 依据 PQI 和 Yield 指标所体现的信息,通过过程改进来提升开发质量。
【2013】【2015A】如果对质量的追求是无止境的,在不考虑资源和成本的前提下,有哪些可能有效的策略?
- 重视测试,并且将测试过程文档化并且稳定化;
- 重视小组评审,同样定义评审过程,并且使得评审过程的 performance 稳定化
- 重视个人评审,提升评审者技能;
- 重视设计
- 开展设计验证
- 质量策略:参考上面
【2014】请解释设计的层次的概念和意义,并解释如何将 PSP4 个设计模版应用在不同的设计层次之中?8'
【2013】【2018Fall】解释 PQI 指标,如何计算,如何使用
【2013】【2015A】【2016】请结合软件开发特点介绍软件项目管理中自主型团队的必要性
【2014】自主团队有哪些特点?为什么说这样的团队可以满足软件开发对团队的要求
- 自主团队特点如上
- 软件开发一种智力活动,开发者是智力劳动者,而对于智力劳动者而言,管理的第一准则就是智力劳动者不能被管理,只能实现自我管理:
- 处理和讨论非常抽象的概念
- 把不同的部分整合成一个可以工作的正确的系统
- 全身心地参与
- 努力做出卓越的工作
不在 2023Fall 课程范围内的简答题
【2015A】请列出 Capture-recapture 方法进行缺陷预测的假设条件和相应的模型定义
- 常见 CRC 模型定义了两个参数,即评审者发现缺陷能力 t 和缺陷的难度 h,t 是否一致以及 h 是否一致都会影响模型。一边来说,定义如下 4 个基本模型:
- 假设 h 和 t 都一样的 M0 模型
- 假设 h 不等而 t 都一样的 Mh 模型
- 假设 t 不等而 h 都一样的 Mt 模型
- 假设 t 和 h 都不等的 Mth 模型
估算与计划的差异:
- 估算主要用来估算待开发程序的规模和所需资源
- 质量计划用于保证项目的质量
- 包含的活动不同等等
【2018Fall】什么是软件过程的多维视角?这对软件过程的融合和定制有什么启发?
【2013】请结合 GQM 思想解释 PSP 过程的基本度量元有哪几个?
【2015B】请描述一下度量和分析活动在一个软件项目当中的作用,以及应该如何正确开展?10'
- 可以描述度量和分析活动
- 也可以描述 GQM
【2013】请解释配置管理中配置项和产品基线的概念,并设计一个流程对单元测试后已经纳入配置库的代码,修改集成测试中的若干问题后,该如何控制变更
- 配置项和产品基线的概念如上
- 如何控制变更
- 跟踪变更请求:
- 启动变更请求处理程序,将变更情况保存在变更请求数据库中
- 分析变更建议和所需进行的修改将对工作产品、进度、日程等造成的影响
- 如果变更请求影响到其他基线,则与相关的干系人一起审查这些变更请求,并取得他们的同意
- 跟踪变更申请直到结项
- 控制配置项变更:
- 确认这些修订已得授权
- 更新配置项
- 将旧基线归档保存,并获取新基线
- 执行审查,确保该变更没有对基线造成意料外的影响
- 上当记录配置项的变更内容和变更理由
【2015B】【2016】请描述 PDCA 模型的主要步骤(5 分)
简述以下软件质量管理科学家/工程师的贡献
【2013】【2015B】【2016】Deming
- 质量改进:提出质量改进的思想,被称为日本质量管理之父。
- PDCA 循环:提出 PDCA 循环,被称为“戴明环”(Plan、 Do、Check、 Action),为最基本的质量和管理工具
- 14 条原则:
- 树立改进产品和服务的坚定目标,采用新的思维方法
- 停止依赖检验的办法获得质量
- 不再凭价格标签进货
- 坚持不懈地提高产品质量和生产率
- 岗位培训制度化
- 管理者的作用应突出强调
- 排除畏难情绪
- 打破部门和人员之间的障碍
- 不再给操作人员提空洞的口号
- 取消对操作人员规定的工作定额和指标
- 不再采用按年度对人员工件进行评估
- 创建积极的自我提高计划制度
- 让每个员工都投入到提高产品质量的活动中去
【2013】【2015B】【2016】Juran
- 主编质量控制手册:《质量控制手册》为当今世界质量控制科学的“圣经”,奠定了“全面质量管理”TQM”的理论基础(Total Quality Management)
- 提出适用性质量:
- 适用性质量:质量是一种适用性,即产品在使用期间能满足使用者的要求。
- 质量不仅仅要满足明确的需求,还要满足潜在的需求。该思想使得质量管理范围从生产过程中的控制进一步扩大到产品开发和工艺设计阶段,即挖掘用户潜在需求。
- 提出质量三步曲:就是质量计划->质量控制->质量改进
- 提出 Juran 质量螺旋;
- 提出 80/20 原则,认为有 80%的质量问题是由于领导责任引起的。从而将人力与质量管理结合起来。
【2013】【2015B】【2016】Crosby
- 提出零缺陷的概念
- 零缺陷:第一次就把事情做对
- 想要做到这一点,就需要把工作放在预防上而不是质量检验上;
- 提出质量管理的绝对性:
- 质量就是符合要求,而不是“完美”
- 质量来自于预防,而不是检验
- 质量的标准是“零缺陷”,而不是可接受质量水平
- 质量的衡量标准是“不符合要求的代价”
- 提出质量改进的基本要素(6C-变革 管理的六个阶段) :
- 领悟(Comprehension):理解质量真谛
- 承诺(commitment):制定质量策略的决心
- 能力(capability):教育与培训
- 沟通(communication):成功的经验文档化、制度化
- 改正(correction):预防与提高绩效
- 坚持(continuance):强调质量管理成为一种工作方式
- 发展质量成熟度的度量。
【2015B】【2016】Humphrey 软件过程之父
- 采用 Crosby 的成熟度度量,提出了软件能力成熟度模型(CMM) ,对于软件过程管理与改进具有建设性作用。
- 将上述的理论和实践引入软件过程。
概念解释
【2016】CI
【2016】CD/CD
【2016】Pipeline Orchestration
【2016】Container
【2016】Micro Service
【2016】A/B Testing
【2016】GitFlow
描述用途
【2016】Docker
【2016】Jenkins
【2016】JIRA
【2016】SonarQube
【2016】Git