Software Engineering 软件工程

1. 概述

软件工程（Software Engineering）是研究如何以系统化（Systematic）、规范化（Disciplined）、可度量（Quantifiable）的方法，将工程原理应用于软件的开发（Development）、运行（Operation）与维护（Maintenance），以及对这些方法的实证研究的学科。

1.1 软件工程 vs 计算机科学

1.2 软件工程的三支柱

• 过程（Process）：把人的活动组织成可重复、可改进的流程，如瀑布、敏捷、DevOps。
• 方法（Methods）：完成每一步活动的具体技术，如需求建模、架构设计、测试策略。
• 工具（Tools）：支撑过程与方法自动化的软件，如 IDE、Git、CI/CD、测试框架。

过程、方法、工具三者共同构成软件工程的"工程性"——它不是一门手艺（craft），而是一门有纪律的工程学科。全球公认的权威知识框架是 IEEE 计算机学会发布的 SWEBOK（Software Engineering Body of Knowledge，软件工程知识体系），其最新 V4.0 定义了 18 个知识领域。

1.3 软件完整分类——规范差异的总纲

软件工程的知识体系（SWEBOK）是"公分母"，但工程规范不能一刀切：软件分很多类型，面向的用户不同，质量属性优先级、生命周期模型、架构设计依据、编码底线都随之不同。因此软件工程实践的第一步是先给软件分类——分类决定规范。按"用户/消费者 + 运行形态"可把软件完整划分为五类：

1.4 业务系统开发的本质

业务系统/应用软件（ERP、电商、OA、行业应用、消费级 App）是五类软件中需求量最大的一类，也是绝大多数工程师真正在做的软件。它的本质决定了工程重心不在"造工具"，而在组织工具与面向用户，这与底层软件、中间件、开发工具、框架/库有本质区别。

这一判断落到工程规范上，业务系统应：优先复用成熟框架（不重复造轮子）、保持技术栈克制、快速迭代响应业务、重可维护性与测试，对应关系见 4.8 约束来源 与 5.4 质量属性优先级 中"业务系统"一列。

2. 生命周期与过程模型

2.1 软件生命周期模型（Process Models）

2.2 过程框架标准：ISO/IEC/IEEE 12207

ISO/IEC/IEEE 12207 是软件生命周期过程国际标准，把软件工程活动组织为 四组过程：

这四组过程的整体结构，详见 7.3 包图。

3. SWEBOK 知识体系

SWEBOK（Software Engineering Body of Knowledge）由 IEEE 计算机学会组织编写，是全球公认的软件工程知识权威框架。V4.0 共 18 个知识领域（Knowledge Area, KA），可分为四类：

4. 架构·设计·编码的定位与参考资源

软件工程中常被混淆的三个概念——架构设计（Architecture）、详细设计（Design）、编码规范与实现（Construction）——在业界是三个独立的研究层面，分别对应 SWEBOK 中的不同知识领域（KA）。本章厘清它们的边界、归属、代码摆放与职责划分的业界流派，并给出完整参考资料清单。

4.1 三个层面的定位对比

4.2 关键判断标准

• 架构 = 系统"怎么拆"：回答模块间关系、边界、技术选型，影响整个系统，后期难改。
• 设计 = 部件"怎么做"：在架构给定的框架内细化单个模块。
• 规范 = 代码"怎么写"：与系统结构无关，追求一致性与可读性。

代码摆放与职责划分是横跨 Design 与 Construction 的过渡地带：包的大结构（按业务域 vs 按技术层）属于架构/设计决策；单个 controller / service / repository 内部的写法属于编码规范。

4.3 业界主流的代码组织与职责划分流派

业界对"代码怎么摆、职责怎么分"的分类，按架构风格划分如下。这些流派既决定了目录摆放，也决定了职责划分方式。

架构·设计·编码 三层定位及知识领域归属（结构图：组件图）

演示：同一功能在三层分别如何呈现

// 架构层（KA2）——系统级边界：模块间只通过接口调用
[订单服务] -->|REST| [支付服务]      // 同步接口
[订单服务] -->|事件|  [库存服务]      // 异步解耦

// 详细设计层（KA3）——单个模块内部的设计
class OrderService {
  private final OrderRepository repo;   // 依赖抽象接口
  public Order create(OrderCmd cmd) {   // 业务编排
    Order o = new Order(cmd);
    repo.save(o);
    eventBus.publish(new OrderCreated(o.getId()));
    return o;
  }
}

// 编码规范层（KA4）——命名、目录摆放、职责划分
app/order/
├── controller/    OrderController   // 只收请求、转发，不含业务
├── service/       OrderService      // 业务逻辑编排
├── repository/    OrderRepository   // 只管持久化
└── dto/           OrderCreateCmd    // 入参传输对象

4.4 权威标准与知识体系

4.5 经典书籍

4.6 经典论文（按时间）

4.7 历史脉络

4.8 不同软件类型的架构·设计·编码差异

前几节给出的"架构/设计/编码三层"定义是通用骨架。但软件分很多类型——底层/系统软件、中间件、业务系统、开发工具、框架/库，面向的用户完全不同，三层的约束来源也因此不同：架构"怎么拆"的依据、设计"怎么做"的约束、编码"怎么写"的底线，由不同类型软件的决定性因素支配，不可能用同一套规范（分类见 1.3）。

5. 质量保证与度量

5.1 软件质量模型（ISO/IEC 25010）

国际标准 ISO/IEC 25010 定义了软件质量的 8 大特性：

5.2 测试层次（Test Levels）

• 单元测试（Unit Test）：验证单个函数/模块，通常由开发者编写。
• 集成测试（Integration Test）：验证模块之间的接口与协作。
• 系统测试（System Test）：在完整系统上验证功能与非功能需求。
• 验收测试（Acceptance Test / UAT）：由客户/用户确认系统满足业务需求。

5.3 常用度量指标

5.4 不同软件类型的质量属性优先级与规范裁剪

ISO 25010 的 8 大特性对所有软件都适用，但面向的用户不同，特性优先级排序就不同（分类见 1.3）——"哪个质量特性排第一"决定了工程规范的强度与侧重。ISO/IEC/IEEE 12207 本身也明确允许裁剪（Tailoring），即每个组织/项目按自身情况增删过程，这是"规范因软件类型而异"的标准依据。

6. 行为图（系统"做什么"）

行为图描述软件工程中人、团队、流程"做什么"。先以用例图纵览整体行为，再以活动图、时序图、状态机图逐步细化核心主流程。

6.1 用例图——软件工程整体行为

用例图展示软件工程中各方角色参与的活动。客户与产品经理定义需求，架构师设计结构，开发者编码，测试者验证，运维保障上线，管理者统筹全局。

软件工程整体用例图——各角色的职责与活动依赖

演示：用用户故事（User Story）表达一个用例的验收标准

// 用例 UC1 "收集与分析需求" 的用户故事形式
As a 注册用户,
I want 用手机号+验证码登录,
So that 我可以快速安全地访问系统.

验收标准 (Acceptance Criteria):
- 输入正确手机号与验证码后 3 秒内登录成功
- 验证码 5 分钟内有效且只能使用一次
- 连续 5 次输错后锁定 30 分钟

6.2 活动图——软件生命周期完整主流程

活动图用泳道展示从需求提出到上线运营的完整流程：需求分析→架构设计→迭代开发→测试→发布→监控→反馈，形成持续改进的闭环。

软件生命周期活动图（带泳道，含 CI/CD 与迭代闭环）

演示：CI 流水线配置（GitHub Actions）——把活动图中的"构建-测试-发布"自动化

name: CI
on:
  push:
    branches: [main]
jobs:
  build-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - run: npm run build

6.3 时序图——敏捷 Scrum Sprint 迭代

时序图刻画一个典型 Scrum 迭代中，产品负责人、开发者、测试、CI/CD 平台与生产环境之间的消息协作时序。

Scrum Sprint 迭代时序图——从计划会到发布确认

演示：一个 Sprint（2 周）的节奏安排

Sprint 周期节奏（Scrum 仪式）:
  Day 1   : Sprint Planning  计划会（明确目标与待办）
  Daily   : Daily Standup    每日站会（15 分钟同步障碍）
  Day 8   : Backlog Refinement 待办梳理
  Day 10  : Sprint Review    评审会（演示可运行成果）
  Day 10  : Retrospective    回顾会（改进过程）
  Day 10  : Release          通过验收后发布

6.4 状态机图——缺陷（Defect）生命周期

状态机图描述软件工程中最典型的工件之一——缺陷从发现到关闭的状态流转，是配置管理与质量管理的基础。

缺陷（Defect）生命周期状态机图

演示：缺陷实体状态字段（JSON 形态）

{
  "id": "BUG-1042",
  "title": "订单页在 iOS 下白屏",
  "severity": "High",            // Blocker/High/Medium/Low
  "status": "Fixed",             // New/Open/Fixed/Verified/Closed/Reopened
  "steps": ["打开首页", "点击下单", "观察白屏"],
  "reporter": "qa.wang",
  "assignee": "dev.li",
  "foundIn": "v1.4.0-rc1",
  "fixedIn": "v1.4.0-rc2"
}

7. 结构图（系统"由什么组成"）

结构图描述软件工程"由什么组成"：从部署环境的物理拓扑（部署图），到软件产品内部组件（组件图），再到学科层面的过程包结构（包图），最后到核心概念实体关系（类图），由宏观到细节逐层细化。

7.1 部署图——软件交付部署拓扑

部署图展示软件从代码提交到生产上线的物理节点：开发者工作站→代码托管→CI/CD 服务器→制品仓库→测试环境→生产环境，及监控观测。

软件交付部署图——开发到生产的制品流转

演示：生产环境部署清单（Docker Compose 片段）

version: "3.8"
services:
  gateway:   { image: myapp/gateway:1.4.0, ports: ["80:8080"] }
  app:       { image: myapp/app:1.4.0,   depends_on: [db, cache] }
  cache:     { image: redis:7 }
  db:        { image: postgres:16, volumes: ["pgdata:/var/lib/postgresql/data"] }
  monitor:   { image: prom/prometheus, ports: ["9090:9090"] }

7.2 组件图——现代软件系统组件

组件图展示典型现代软件系统（如微服务应用）的内部组成与依赖关系：前端、网关、业务服务、数据存储、缓存、消息、可观测性与安全。

现代软件系统组件架构图

演示：服务间依赖的接口声明（REST 风格）

# 订单服务提供的接口
GET    /orders?user={uid}         查询订单列表
POST   /orders                    创建订单
POST   /orders/{id}/pay           发起支付

# 订单服务消费的接口
POST   /payments/{orderId}        调用支付服务
GET    /inventory/{sku}           查询库存服务
PUB    /order/created             发布订单创建事件

7.3 包图——软件工程过程体系（ISO 12207）

包图用国际标准 ISO/IEC/IEEE 12207 的四组过程展示软件工程"由哪些过程构成"，以及技术过程的递进依赖关系。

软件工程过程体系包图（ISO/IEC/IEEE 12207）

演示：一个典型项目的工程目录（对应包图中的过程产物）

my-service/
├── docs/
│   ├── srs.md                 # 需求规格 (Requirements)
│   ├── architecture.md        # 架构设计 (Architecture Design)
│   └── design.md              # 详细设计 (Design)
├── src/                       # 实现 (Implementation)
├── test/                      # 测试 (Verification)
├── ci/                        # 流水线定义 (Engineering Operations)
├── scripts/                   # 部署脚本 (Operations)
└── CHANGELOG.md               # 配置与发布管理 (SCM)

7.4 类图——软件工程核心概念模型

类图刻画软件工程领域内的核心实体及其关系：项目、干系人、需求、用例、设计文档、代码模块、测试用例、缺陷、构建、发布。

软件工程核心概念类图

演示：核心实体示例（TypeScript 接口形态）

interface Requirement {
  id: string;
  description: string;
  priority: 'P0' | 'P1' | 'P2';
  acceptanceCriteria: string[];
}

interface Defect {
  id: string;
  requirementId: string;   // 关联需求 (traced to)
  testCaseId?: string;     // 关联测试用例 (finds)
  severity: 'High' | 'Medium' | 'Low';
  status: 'New' | 'Open' | 'Fixed' | 'Closed' | 'Reopened';
}

interface Release {
  version: string;         // 语义化版本, 如 "1.4.0"
  buildNumber: number;     // 关联构建
  requirements: string[];  // 满足的需求 (satisfies)
  releaseDate: Date;
}

8. 实战速查手册

8.1 生命周期模型选择速查

8.2 各阶段核心交付物速查

8.3 常用工具速查

8.4 质量指标速查

8.5 研发最佳实践 Checklist

1. 先写测试再写代码（TDD）或至少保证核心逻辑有自动化测试。
2. 小步提交、频繁合并到主干，避免长分支。
3. 每次提交触发 CI，编译、测试、静态检查全自动。
4. 代码评审作为合并硬性门槛。
5. 需求可追踪：从用户故事到代码到测试到发布的链条完整。
6. 语义化版本（SemVer：MAJOR.MINOR.PATCH）管理发布。
7. 发布有回滚预案，配置与代码分离。
8. 监控告警前置：上线即有日志、指标、告警。
9. 定期回顾改进过程（Retrospective）。
10. 安全左移（Shift-Left）：依赖扫描、安全测试在 CI 中尽早执行。