Week 6 - Chapter 3 - Quality and Reliability: Ensuring Rigorous Professional Standards
本页目录· 15 条
- Overview
- Learning Objectives
- Unit Learning Outcomes 对齐
- 与 Week 5 衔接
- Own-time
- 1 · Measuring quality
- 2 · Impact of poor software quality
- 3 · Testing and quality management
- 4 · Standards and security
- Real-time / Workshop
- Applied / IE Project Application
- Quality / Reliability Measurement Plan
- Check Your Knowledge
- Wrap-up
- Official entry
Overview
本周把 Week 5 的“什么是 quality / reliability”推进到可执行层面：如何衡量软件成功、识别脆弱性、预防 defect，并用 whole-system 与 security 视角证明系统 fit for purpose。
Learning Objectives
- 建立可验证的软件成功指标，而不是只依赖“感觉好用”。
- 判断软件是否适合其目的、目标用户与真实使用情境。
- 识别脆弱区域并规划 prevention、detection、containment 与 recovery。
- 从 people、process、technology 的整体系统分析质量与可靠性。
- 确认 confidentiality、integrity、availability 等 security measures 已纳入方案。
Unit Learning Outcomes 对齐
- 分析 IT 决策对组织与社会的后果，并联系 ethics、ACS 与法律框架。
- 评估并沟通个人/团队进度，用反思实践改进质量。
- 为 IT 专业义务与挑战提出可执行解决方案。
- 比较 IT professional roles，并理解持续 review / change 的必要性。
- 使用 information-gathering 与 problem-solving 方法，批判评估来源与证据。
与 Week 5 衔接
Own-time
1 · Measuring quality
- 收听课程播客，理解 external / structural quality、shift-left、TDD 与 flow。
- 观看 Panopto 视频，掌握 defect、severity / priority、criticality 与 whole-system thinking。
2 · Impact of poor software quality
- 核查 “What Determines Software Quality?” 的 Moodle 链接漂移，并理解 information provenance。
- 阅读 2022 年 US$2.4T 成本估算，区分宏观估算与项目指标。
- 分析测试失败如何导致声誉、收入、反馈、法律与社会后果。
3 · Testing and quality management
- 将 11 个 testing practices 转成可执行的项目 QA 方案。
- 比较 5 Do's / 5 Don'ts，并为 manual + automation 选择平衡。
4 · Standards and security
- 理解 ISO 5055 / CISQ 的四项 structural quality measures 与适用边界。
- 用 ISO/IEC 9126 理解 internal、external 与 quality-in-use，并记住其已被 ISO/IEC 25010 取代。
- 用 ISO/IEC 27001:2022 的 ISMS 思路把 security 纳入可靠性管理。
Real-time / Workshop
- 分析 NASA Mars Climate Orbiter：interface / units / systems engineering failure。
- 分析 Patriot Missile：长时间运行造成 tracking calculation drift。
- 分析 Heathrow Terminal 5：避免把 whole-system failure 简化为一个 baggage software bug。
- 分析 Mt Gox：同时考虑 software、security controls、asset reconciliation 与 governance。
- 每案提出 leading + lagging metric、prevention、containment 与 recovery。
Applied / IE Project Application
Moodle Week 6 未显示单独的 Applied resource 或新增 submission deadline；以下是把本周知识用于 IE Project 的自我准备，不代表新增考核。
Quality / Reliability Measurement Plan
| Outcome / risk | Metric | Target / threshold | Data source | Frequency | Owner / escalation |
|---|---|---|---|---|---|
| 用户关键任务 | Task success / error rate | 待团队定义 | Usability test / analytics | 每 iteration | UX / Product |
| 服务可靠性 | Availability / failure rate / MTTR | 待团队定义 | Logs / monitoring | 持续 | Engineering / Ops |
| 结构质量 | Critical weakness / complexity | Release gate | Static analysis / review | 每次 merge | Developer / Tech lead |
| 信息安全 | Critical vulnerability / access exception | 0 未接受 critical risk | SAST / access review | 每次 release | Security / Project lead |
- 明确一个 client requirement 与一个 target-user outcome。
- 选择一个 leading indicator 和一个 lagging indicator。
- 为最高风险 failure mode 定义 severity、priority 与 escalation。
- 写出一项 prevention、一项 detection、一项 containment、一项 recovery control。
- 明确 security 的 confidentiality、integrity、availability evidence。
- 将至少一条 acceptance criterion 变成可重复测试。
- 记录 residual risk 由谁接受、依据是什么。
Check Your Knowledge
- 为什么 defect 必须相对于 requirement 和 context 定义？
- Severity 与 priority 有何不同？何时 high severity 可能不是最高优先级？
- 为什么测试只能揭露质量问题，不能单独创造质量？
- Leading indicator 与 lagging indicator 各给一个例子。
- V-model 的核心关系是什么？Agile 如何保留同样的早期验证思想？
- safety-critical、mission-critical、business-critical 如何影响可接受风险？
- 为什么 people、process、technology 必须作为一个系统分析？
- ISO 5055、ISO/IEC 9126 / 25010 与 ISO/IEC 27001 分别解决什么问题？
- 为什么自动化 regression testing 不能替代 exploratory testing？
- 如何识别来源 link rot、过度归因与过时标准？
Wrap-up
- 在 Workshop 后补充四个案例的小组结论和 tutor clarification。
- 用本周模板更新 IE Project 的 quality / reliability / security plan。
- 保存一项可审计 learning evidence：metric table、test case、risk decision 或 review note。
- 记录仍需确认的 Moodle link、标准版本或事实来源。