Informatics 43 — 第一周课堂笔记

目录

1. 软件无处不在
2. 什么是软件工程？——定义
3. 三种视角看软件工程
4. 软件工程的三大核心要素
5. 软件工程原则
6. No Silver Bullet — Brooks (1986)
7. 课程核心问题与学习成果
8. 总结与记忆框架

1. 软件无处不在

课程首先通过大量真实案例说明：软件已经渗透到社会的每一个角落，影响深远且不可忽视。

关键总结——软件的双面性：

• ✅ 令人兴奋的、多用途的、可以拯救生命、帮助人们
• ❌ 也可以伤害人们

引出核心问题：既然软件如此重要且无处不在，那么这些软件是如何被制造出来的？→ 这就是软件工程要回答的问题。

2. 什么是软件工程？——定义

2.1 "软件"不仅仅是代码

Software（软件） 包含：

• 代码（Code）
• 文档和用户手册（Documentation, User Manuals）
• 设计和规格说明（Designs, Specifications）
• 测试用例（Test Cases）
• 计划和进度表（Plans and Schedules）

Engineering（工程） 的含义：

• 创造性地应用科学和数学来设计和构建事物
• 涉及权衡取舍（trade-offs）、风险分析、技能和知识

2.2 专家定义对比

2.3 INF 43 课程定义（重点！）

本课程将软件工程定义为三大支柱：

1. 构建软件的过程（The process of constructing software）
2. 编程之外的开发阶段（Phases of development other than programming）
   • 软件开发的主要阶段：
     1. 需求（Requirements）
     2. 设计（Design）
     3. 实现（Implementation）
     4. 验证（Verification）
     5. 维护（Maintenance）
   • 编码（实现）只是其中一环
3. 具有持久价值的原则和质量（Principles and qualities of enduring value）
   • 正确性（Correctness）
   • 可靠性（Reliability）
   • 适应性（Adaptability）
   • 可用性（Usability）
   • 模块化（Modularity）
   • 效率（Efficiency）

次要关注点：团队管理与调度、商业模式、软件对社会的影响、AI

Agile（敏捷开发）

Agile 是一种现代软件开发方法，从多个角度定义：

• 一套能实现快速交付解决方案的实践
• 鼓励频繁检查和调整的项目管理方式
• 将开发与客户需求和公司目标对齐的商业方法
• 鼓励团队协作、自组织和问责的领导方式

3. 三种视角看软件工程

课程通过三个虚构人物展示不同利益相关者如何看待同一款软件：

更多视角：

• 程序员 → 源代码、内部设计
• 电气工程师 → 半导体、晶体管、电源
• 社会 → 影响、输出、趋势、危险
• 设计师 → 产品、结构
• 项目经理 → 团队、预算、时间表
• SE 教授 → 原则、理论、模型
• SE 学生 → 工作量、机遇、挑战、乐趣

核心启示：同一款软件，不同角色的人"看到"的东西完全不同。软件工程需要同时兼顾多方利益相关者的需求。

4. 软件工程的三大核心要素

这是贯穿整个课程的根基概念：

• People：软件是由人构建的，人的能力、沟通和协作是成功的关键
• Processes：需要系统化的流程来组织和管理开发活动
• Tools：工具（IDE、版本控制、测试框架等）提升效率，但工具本身不能替代人和过程

5. 软件工程原则

5.1 不同学者的原则总结

Davis（1994）：

• 质量第一
• 尽早给客户交付产品
• 先理解问题再动手
• 选择合适的过程
• 好的管理比好的技术更重要
• 人是成功的关键

Royce（1998）：

• 遵循架构优先的过程
• 基于组件的开发（Buy vs. Build）减少编码量
• 频繁向客户展示初步版本
• 增量式发布

Wasserman（1996）：

• 模块化（Modularity）
• 抽象（Abstraction）
• 用户界面原型（UI Prototyping）
• 复用（Reuse）
• 度量（Metrics）

5.2 INF 43 课程核心原则（必须掌握！）

Rigor and Formality（严格性与形式化）

软件工程必须以系统化的方式进行实践。严格性是对创造力的必要补充，能提高我们对开发成果的信心。计算机无法像人类一样处理模糊的命令，因此精确的规范至关重要。形式化是最高程度的严格——软件过程由数学法则驱动和评估。

例子：

• 对程序正确性进行数学（形式化）分析
• 系统化（严格）地推导测试数据
• 严格的开发步骤文档记录有助于项目管理和进度评估

Separation of Concerns（关注点分离）

将复杂性分离开来，每次只专注于一个方面——"分而治之"。例如，将产品需求分开考虑：功能性、性能、可用性。这支持了工作的并行化和职责的分离。

Modularity（模块化）

一个复杂系统可以被划分为更简单的部分，称为模块。由模块组成的系统称为模块化系统。模块化支持关注点分离的应用：在处理一个模块时，我们可以忽略其他模块的细节。

Abstraction（抽象）

识别现象的重要方面，忽略其细节。抽象是关注点分离的一个特例。应用哪种类型的抽象取决于目的或角色：

• 用户：关注软件做什么（what），而不关心它怎么做（how）。
• 团队中的设计者：关注自己负责部分的 what 和 how，而对其他团队成员负责的部分只关注 what。
• 当一个模块被充分测试和验证后，其用户只需关注 what 部分。

Anticipation of Change（对变化的预见）

支持软件演化的能力要求我们预见潜在的未来变更。目标是最小化对现有模块的修改，并在程序中预留未来功能的接入点。这是软件可演化性的基础。

例子：

• 基于固定长度数组的排序程序 vs. 基于动态长度链表的排序程序——后者预见了数据增长的需求。

Generality（通用性）

发现一个问题是否是更一般问题的实例，其解决方案是否可以在其他情况下复用。这提高了可复用性，但通用性必须与性能和成本仔细权衡——通用问题的解决方案通常比特定问题的解决方案更昂贵。

例子：

• 能处理两个通用矩阵乘法的程序 vs. 专门设计来处理两个稀疏矩阵乘法的程序——通用版本可复用但在特定场景下更慢。

Incrementality（增量性）

过程以逐步的方式（增量）推进。尽早向预期用户交付系统的子集（原型）以获取早期反馈，然后增量地添加新功能。先处理功能性，再关注性能：第一步是快速粗糙的方案，第二步是更高效（更精致）的设计。

例子（游戏设计）：

• 先发布 2D 版本，再开发 3D 设计。
• 先使用粗粒度纹理，再细化为精细纹理。

5.3 软件失败的主要原因

当这些原则没有被遵循时，项目就会失败。最常见的原因包括：

• 缺乏用户输入（Lack of user input）
• 需求和规格不完整（Incomplete requirements and specifications）
• 需求和规格频繁变更（Changing requirements and specifications）
• 开发过程缺乏纪律（Lack of discipline in dev process）
• 缺乏系统化的度量方法（Lack of methodical usage of metrics）
• 资源不足（Lack of resources）

6. No Silver Bullet — Brooks (1986)

6.1 文章背景

• 作者：Frederick Brooks，图灵奖得主
• 发表：1986 年
• 地位：软件工程领域的奠基性文章（seminal article），至今几乎每位软件工程师都知道
• 核心论点：不存在能使软件开发生产力在十年内提升一个数量级的"银弹"（单一技术或方法）

6.2 软件的四大本质属性（Essential Properties）

这是 Brooks 论证"没有银弹"的基础——软件的困难来自其本质（essence），而非偶然因素（accidents）：

6.3 "虚假的"银弹（False Silver Bullets）

Brooks 逐一分析了当时被寄予厚望的技术，认为它们有帮助但都不能从根本上解决问题：

• 高级语言（High-level languages）
• 分时系统（Time-sharing）
• 统一编程环境（Unified programming environments）
• 面向对象编程（OOP）
• 人工智能（AI）
• 专家系统（Expert systems）
• 自动/图形化编程（Automatic/graphical programming）
• 程序验证（Program verification）
• 环境/工具（Environments/tools）
• 工作站（Workstations）

这些技术解决的是软件的偶然困难（accidental difficulties），而非本质困难（essential difficulties）。这是文章标题中 "Essence and Accidents" 的核心含义。

6.4 "潜在的"银弹（可能大有帮助的方向）

虽然也不是真正的银弹，但 Brooks 认为以下方向最有可能显著改善软件开发：

7. 课程核心问题与学习成果

7.1 贯穿课程的"大问题"

7.2 学习成果

完成课程后应能做到：

• 描述 SE 基本原则
• 创建需求文档和用例模型
• 描述软件架构及不同架构风格
• 创建 UML 类图
• 创建黑盒测试计划和白盒测试（不同覆盖标准）
• 描述不同软件过程模型
• 识别良好用户导向的原则与实践

8. 总结与记忆框架

Week 1 核心知识结构
│
├─ 软件无处不在 → 汽车/医疗/政治/军事/太空/灾害/游戏/执法
│   └─ 软件有益也有害 → 引出"如何制造好的软件？"
│
├─ SE 定义
│   ├─ 专家定义：广泛性(Tsui) / 规模+团队(Ghezzi) / 多人多版本(Parnas) / 质量+时间+成本(Schach)
│   └─ INF43 定义：过程 + 编程之外的阶段 + 持久原则与质量
│
├─ 三种视角 → 商业(Shawna) / 工程(Andy) / 用户(Clara)
│
├─ 三大要素 → People + Processes + Tools
│
├─ INF43 核心原则
│   ├─ 严格性与形式化（Rigor & Formality）
│   ├─ 关注点分离（Separation of Concerns）
│   │   ├─ 模块化（Modularity）
│   │   ├─ 分而治之（Divide & Conquer）
│   │   └─ 抽象（Abstraction）
│   ├─ 对变化的预见（Anticipation of Change）
│   ├─ 通用性（Generality）
│   └─ 增量性（Incrementality）
│
└─ No Silver Bullet（Brooks 1986）
    ├─ 核心论点：没有万能解决方案
    ├─ 本质 vs. 偶然困难（Essence vs. Accidents）
    ├─ 四大本质困难 → Complexity / Conformity / Changeability / Invisibility
    ├─ 虚假银弹 → 高级语言、OOP、AI 等（只解决偶然困难）
    └─ 潜在银弹 → Buy vs. Build / 需求细化+快速原型 / 增量开发 / 优秀设计师

一句话总结

软件工程不仅仅是编程——它是人、过程和工具的结合，通过系统化的原则来应对软件固有的复杂性、一致性、可变性和不可见性，从而在多方利益相关者的视角下构建高质量软件。