2014年《软件质量与管理》试题 解答与解析¶
试题来源: 综合
assets/exams/软件质量往年题目整理.pdf、assets/exams/软件质量管理-习题-EagleBear.pdf、assets/exams/软质管古老往年卷.pdf中标有【2014】的题目整理。
简答题¶
1. 为何说将"规范方法"、"计划驱动方法"等特征作为敏捷方法的对立面带有很大的误导性质？如何通过多种维度改进这种对各类开发过程的理解？（10分）¶
点击查看答案与解析
解答：
为何带有误导性质：
敏捷的核心是敏捷目的、敏捷价值观和敏捷原则。这些与"规范"和"计划驱动"并不矛盾。
影响敏捷与规范方法选择的维度：
- 如果只有强有力的规范而缺乏敏捷，将导致官僚作风，进而停滞不前。团队将陷入为了测量而测量的处境之中，缺乏创新。
- 缺乏规范的敏捷则如同一个新创公司在盈利之前的不负责任的狂热。
- 计划驱动的开发人员必须敏捷，敏捷开发人员必须规范。
敏捷和规范方法是互补的，而非对立的。过分强调对立会阻碍团队采用适合自身情况的最佳实践组合。
改进理解的方式：
- 从敏捷目的、价值观和原则出发理解敏捷
- 认识五种影响方法选择的维度（人员、文化、规模、关键性、变更率）
- 基于风险分析平衡敏捷与规范
知识点出处：
assets/slides/软件质量与管理.第二讲.pdf和assets/slides/8敏捷概述.pdf。
2. 自主团队有哪些特点？为什么说这样的团队可以满足软件开发对团队的要求？¶
点击查看答案与解析
解答：
自主团队的特点：
- 自行定义项目的目标
- 自行决定团队组成形式以及成员的角色
- 自行决定项目的开发策略
- 自行定义项目的开发过程
- 自行制定项目的开发计划
- 自行度量、管理和控制项目工作
为何满足软件开发要求： 软件开发是一种智力活动，开发者是智力劳动者。对于智力劳动者而言，管理的第一准则就是智力劳动者不能被管理，只能实现自我管理。软件开发需要：
- 处理和讨论非常抽象的概念
- 把不同的部分（不可见）整合成一个可以工作的正确的系统
- 全身心地参与
- 努力做出卓越的工作
自主团队赋予知识工作者必要的自主权，使其能够自我管理，从而充分发挥创造力和专业能力。
知识点出处：
assets/slides/软件质量与管理.第三讲.pdf——自主团队与知识工作管理。
3. 马斯洛的"人的需求层次理论"描述的需求层次有哪几个？这样分层对软件开发有什么启发？（6分）¶
点击查看答案与解析
解答：
马斯洛需求层次（从低到高）：
- 生理需求（Physiological）
- 安全需求（Safety）
- 社交需求（Love/Belonging）
- 尊重需求（Esteem）
- 自我实现需求（Self-actualization）
对软件开发的启发：
- 软件开发是智力工作，开发者通常追求较高层次的需求（尊重和自我实现）
- 激励手段应该对应团队成员当前所处的需求层次
- 低层次需求未满足时，高层次激励手段可能失效（如：薪资问题未解决时，给予更多自主权可能效果不佳）
- 马斯洛晚年修正理论认为高层次需求不一定在低层次需求满足之前实现
- 对软件开发者而言，提供有挑战性的工作、认可其贡献、给予成长空间是有效的激励方式
知识点出处：
assets/slides/软件质量与管理.第三讲.pdf——团队动力学中的激励理论。
4. 应对风险的典型策略有哪些？请举例说明¶
点击查看答案与解析
解答：
典型风险应对策略：
- 规避（Avoidance）：改变项目计划以消除风险。例如，采用成熟技术替代不稳定的新技术。
- 转移（Transfer）：将风险影响转移给第三方。例如，购买保险、外包高风险模块。
- 缓解（Mitigation）：降低风险发生的概率或影响。例如，增加评审环节降低缺陷风险。
- 接受（Acceptance）：有意识地承担风险后果。例如，对于低概率低影响的风险制定应急预案。
知识点出处：
assets/slides/软件质量与管理.第四讲.pdf——风险管理。
5. 为了确保最终软件产品的质量，在项目计划阶段应该注意哪些问题？（4分）¶
点击查看答案与解析
解答：
- 安排充分的质量活动：在计划中明确安排评审活动（个人评审和小组评审），确保评审时间充足
- 设定质量指标目标：按照A/FR、PQI等质量指标要求制定计划
- 重视设计阶段：设计是质量的基础，需要在计划中给予充分的设计时间
- 参考历史数据：利用历史质量数据进行质量规划
知识点出处：
assets/slides/软件质量与管理.第五讲.pdf——质量计划。
6. 请罗列集成测试的典型策略，并且解释各个集成测试策略的优缺点（8分）¶
点击查看答案与解析
解答：
| 策略 | 优点 | 缺点 |
|---|---|---|
| 大爆炸式集成 | 简单直接，适用于组件质量普遍较高的情况 | 问题定位困难，组件质量不高时风险极大 |
| 扁平化集成 | 可尽早发现系统层面缺陷 | 需大量打桩（Stub），不能覆盖所有状态 |
| 集簇式集成 | 有助于复用策略实现，可尽早获取可工作组件 | 缺乏系统整体观，不能早发现系统层面缺陷 |
| 逐一添加（持续集成） | 问题定位容易，持续反馈 | 需要自动化测试支持 |
选择策略需考虑的因素：
- 待集成组件的质量状态
- 待集成组件的获取方式
- 待集成组件的功能和关系
- 待集成组件的数量
知识点出处：
assets/slides/软件质量与管理.第六讲.pdf——集成策略。
7. 请举例说明验证和确认的区别和联系（4分）¶
点击查看答案与解析
解答：
区别：
- 验证（Verification）：确保产品被正确建造——符合产品需求和产品组件需求。例如：代码评审检查代码是否符合设计规格。
- 确认（Validation）：确保建造了正确的产品——满足客户需求。例如：验收测试检查产品是否真正解决了客户的问题。
联系：
- 两者相互依存，都是为了提升最终产品质量
- 验证活动为确认活动提供前提条件——如果产品没有按规格建造，讨论它是否满足客户需求没有意义
- 验证依据来源于确认目标——产品组件需求必须与客户需求一致
知识点出处：
assets/slides/软件质量与管理.第五讲.pdf——V&V。
8. 请解释规模估算和资源估算中估算偏差含义之间的差异，并据此简要列举对软件开发活动的启发¶
点击查看答案与解析
解答：
差异：
- 规模估算偏差：产生原因相对客观（如需求理解偏差、分解粒度不同等），偏差可以用来修正新的估算结果，具有较好的可参考性
- 资源估算偏差（特别是时间估算）：产生原因更复杂，一方面与规模有关，另一方面与人的主观能动性有关。时间估算偏差可能是"自我实现的预言"——估算多少时间就按多少时间完成
启发：
- 规模估算可以更多依赖历史数据和统计方法
- 资源/时间估算需要更谨慎，注意生产效率的个体差异
- 应区分对待规模估算和时间估算的准确性要求
- 建立过程数据收集机制，为未来估算积累高质量历史数据
知识点出处：
assets/slides/软件质量与管理.第四讲.pdf——估算偏差分析。
知识点分布总结¶
| 考查内容 | 对应课件 |
|---|---|
| 敏捷与规范方法的关系 | 第二讲/第八讲 |
| 自主团队特点 | 第三讲 |
| 马斯洛需求层次理论 | 第三讲 |
| 风险管理策略 | 第四讲 |
| 质量计划 | 第五讲 |
| 集成策略 | 第六讲 |
| V&V区别与联系 | 第五讲 |
| 估算偏差分析 | 第四讲 |