软件工程
Software Engineering
课程项目、设计文档与测试，按工业评分习惯对齐：能运行只是起点。
软件工程、信息技术、计算机相关的项目课与工程实践课。
适合谁
适合软件工程、信息技术或跨专业转码、正在做团队项目、设计文档、测试与 CI 的同学。能跑 demo 只是起点，评分人要看需求、权衡、测试和过程证据。
毕业设计 / Capstone、小组项目里负责文档或测试、不知道如何交差的成员也可以约。我们不替整个小组写完仓库，也不伪造贡献记录。
覆盖什么
- 需求、用例、非功能约束怎么写成可测试陈述
- 架构图、接口契约、数据模型与 ADR
- 测试计划、缺陷报告、CI 门禁
- 冲刺节奏、演示稿与答辩问答
- 论文或项目报告与仓库提交记录对齐
- 不覆盖替组交差、刷假 commit、三个方向以外的课
怎么进行
- 01先看项目 brief 和评分表。把“必须失败的不变量”（例如不能超售）标出来，再谈功能清单。
- 02盘点仓库现状：能构建吗、有稳定测试吗、文档是否对得上代码。对不上的先对齐，再加功能。
- 03按冲刺排：本周只交付一个可演示、可测试的增量。期末堆特性是 capstone 最常见的失败模式。
- 04演示前预演问答：一致性、失败处理、若重来会砍掉哪一块。论文章节必须能指回同一系统。
在 CS / SE / AI 里怎么落地
文档与需求
把评分表里的文档项写成可检查清单。用例、类图和状态图要互相一致，交叉对不上会被当成没读自己的设计。
质量与交付
测试、CI、issue 记录是答辩时最常被问的证据。覆盖率截图代替不了“这条测试对准哪条风险”。
架构决策
用负载假设和不能破的不变量解释为什么选这个栈。过早微服务化、缓存与一致性冲突，是设计课高频扣分点。
辅导后应能做到
- 设计文档能对照 rubric 逐条对上
- 测试与 CI 成为分数来源而不是事后补丁
- 演示时能讲清权衡，而不是只放 demo
课程目录
| 课程 | 英文名 | 常见考核 |
|---|---|---|
| 软件工程导论 | Introduction to Software Engineering | 过程比较短文 · 小组过程报告 · 风险登记 |
| 需求分析与 UML | Requirements & UML | 用例规格 · 类图/时序图 · 需求追踪矩阵 |
| 软件测试与质量 | Software Testing & Quality | 测试计划 · 单元/集成测试作业 · 缺陷报告 |
| 系统设计 | System Design | 架构说明书 · 容量估算 · 权衡短文 |
| Web 与后端 | Web & Backend Engineering | REST API 项目 · 数据库接入 · 安全检查表 |
| 移动应用工程 | Mobile Application Engineering | Android/iOS 课程项目 · 可用性短报 · 测试截图 |
| DevOps 与 CI | DevOps & CI | CI 配置 · 容器化 · 发布说明 |
| 毕业设计 / Capstone | Capstone / Final Year Project | 开题 · 中期检查 · 终期报告与演示 |
相关公开导师
这一页常被问到的
队友不干活怎么办？
我们可以帮你划清你负责的模块与可演示边界，并在文档里写清接口，避免最后无法集成。不能代写别人的部分，也不能伪造贡献。
教授只要文档不要代码？
仍然要对得上一个可运行的最小系统，否则文档会显得空。最小系统可以很小，但图上的框要能指回实现或测试。
和 CS 的系统课有何不同？
CS 系统课考并发与协议正确性；软件工程课考需求、质量与交付证据。同一门 Web 课，看 rubric 里 maintainability 和测试权重大不大。