ELEC5620 Week 09 软件过程模型讲课总结
ELEC5620 Week 09 讲课总结：Software Process Models
课程：ELEC5620 — Model Based Software Engineering，Semester 2 2026 讲师：Dong Yuan 来源：讲义 PDF
9 Software Process Models.pdf（34 页）+ELEC5620-TUT-09.pdf（24 页）+ELEC5620-Lab-Note-9.pdf（1 页）。本周无转录稿；DevOps 部分讲义多为图片，相关解释用标准教材知识补充并已注明。本周覆盖： 1. 软件过程的定义、历史与基本活动 2. 计划驱动 vs 敏捷；瀑布与螺旋 3. 敏捷宣言与十二原则 4. DevOps 5. Tutorial 9：四种过程对比、LLM agent 组成；Lab 9：回顾/评审 + AI Proxy
相关笔记：Week 08 模型组织与敏捷实践（Scrum 细节）｜Stage 2 要求
一、软件过程是什么
1.1 历史
| 时间 | 事件 |
|---|---|
| 1960s | 软件工程成为 IT 的传统学科 |
| 1970s | 瀑布模型提出 |
| 1987 | L. Osterweil 在 ICSE '87 发表 “Software processes are software too”（软件过程也是软件） |
| 1990s 起 | “software process” 一词被广泛使用 |
别名：software process models、software development process、software development lifecycle（SDLC）等。
“过程也是软件”这一观点和本课的 MBSE 主线一致：过程可以被建模、被执行、被分析——就像程序一样。
1.2 什么是过程
做服务或产品时，我们总是按一系列步骤完成一组任务（你不会在所有原料混合前就烤蛋糕）。一系列活动就构成一个过程。任何过程都有以下特征：
- 规定了所有主要活动
- 使用资源，产出中间产品和最终产品
- 可能包含子过程，有入口和出口准则
- 活动按顺序组织
- 活动可以受约束或控制（预算控制、资源可用性）
1.3 软件过程
Software process：开发软件系统所需的结构化活动集合，包括：
| 活动 | 含义 |
|---|---|
| Specification | 定义系统应该做什么 |
| Design and implementation | 定义系统的组织并实现 |
| Validation | 检查它做的是客户想要的 |
| Evolution | 随客户需求变化而修改系统 |
Software process model：过程的抽象表示，从某个特定视角描述过程。（又一次“模型 = 带目的的抽象”。）
代表性过程模型：Waterfall、Spiral、Agile、DevOps。
二、计划驱动 vs 敏捷
| Plan-driven（重量级，heavy-weight） | Agile（轻量级，light-weight） | |
|---|---|---|
| 计划 | 所有过程活动提前计划，进度对照计划衡量——计划驱动一切 | 计划是增量的 |
| 变化 | 难 | 更容易修改过程以反映变化的客户需求 |
实践中，大多数实用过程都包含两者的元素。没有对错之分的软件过程。
三、瀑布模型（重量级）
3.1 五个阶段（不重叠）
flowchart TD
A[Requirements definition] --> B[System and software design]
B --> C[Implementation and unit testing]
C --> D[Integration and system testing]
D --> E[Operation and maintenance]
B -.feedback.-> A
C -.feedback.-> B
D -.feedback.-> C
E -.feedback.-> D特点：大量文档和计划；容易理解和实施；交付物和里程碑明确。
3.2 瀑布的问题
- 主要缺点：过程开始后难以适应变化——原则上一个阶段必须完成才能进入下一阶段
- 把项目僵硬地划分为不同阶段，难以响应客户需求变化
- ⇒ 只适合需求被充分理解、设计期间变化有限的情况；而很少有业务系统的需求是稳定的
- 瀑布模型主要用于在多个地点开发的大型系统工程项目——此时计划驱动的特性有助于协调工作
四、螺旋模型（重量级）
- 过程表示为螺旋，而不是带回溯的活动序列
- 螺旋的每一圈代表过程中的一个阶段
- 没有固定的阶段（如规格或设计）——每一圈做什么按需要选择
- 在整个过程中显式评估和解决风险——这正是提出螺旋模型的动机：风险
螺旋每一圈的典型四个象限（Boehm 的标准表述，讲义为图片）：
| 象限 | 活动 |
|---|---|
| 1 | 确定目标、备选方案和约束 |
| 2 | 评估备选方案，识别并解决风险（常用原型） |
| 3 | 开发与验证下一层产品 |
| 4 | 规划下一阶段（评审，决定是否继续下一圈） |
用途评价：螺旋模型在帮助人们思考软件过程中的迭代、引入风险驱动开发方面非常有影响力；但实践中很少按原样用于实际开发。
与 Week 1 “Architectural exploration reduces risk” 呼应：螺旋模型把“尽早降低风险”变成了过程本身的组织原则。
五、敏捷软件过程模型
5.1 软件演化与对重量级模型的不满
- 软件天生灵活、可以改变；业务环境变化导致需求变化，支撑业务的软件也必须演化
- 对重量级模型的极大不满：交付延迟、超预算、对变化不敏感、开发团队的人和文化问题
讲义用两组“台词”描述文化问题：
| 问题 | 台词 |
|---|---|
| 缺乏相互尊重 | 开发：“测试是失败的程序员，不该叫工程师”；测试：“开发只会产 bug，世界需要更多测试更少开发”；BA：“我不知道为什么要和测试、开发说话，他们都是白痴” |
| “不是我的责任” | 开发：“在我们的环境里能跑，生产环境让运维去搞”；测试：“UAT 里是好的，肯定是配置问题或少开了防火墙端口”；客户：“喂！这里什么都不工作……” |
第二组台词正是 DevOps 要解决的问题（开发—测试—运维之间的墙）。
5.2 敏捷的触发：项目失败
- 项目失败的主要原因之一是开发周期太长——成本上升、需求变化
- 敏捷方法旨在更快地开发系统，在分析和设计上花有限时间
5.3 敏捷过程是什么
- 关注代码而不是设计
- 基于迭代方法
- 旨在快速交付可工作的软件
- 快速演化以满足变化的需求
- 有观点认为敏捷可能最适合中小型系统
敏捷支持者认为：当前过程太重、太繁琐（做了太多与产品无直接关系的事）；太僵化（难以应对不完整或变化的需求、短开发周期如互联网应用）；需要更积极的客户参与。
敏捷方法被认为是轻量级、以人为本而非以计划为本；没有单一的敏捷方法（XP 最流行；Scrum 见 Week 8）；没有单一定义——敏捷宣言最接近定义（由 Agile Alliance 提出的一组原则）。
5.4 敏捷宣言（必背）
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
更看重 胜过 Individuals and interactions（个体和互动） processes and tools（流程和工具） Working software（可工作的软件） comprehensive documentation（详尽的文档） Customer collaboration（客户合作） contract negotiation（合同谈判） Responding to change（响应变化） following a plan（遵循计划） 也就是说，尽管右项有其价值，我们更重视左项。
⚠️ 易错：宣言不是说右边没有价值——右边仍然有价值，只是左边更重要。
5.5 十二条敏捷原则
| # | 原则 |
|---|---|
| 1 | 最高优先级是通过尽早和持续交付有价值的软件来满足客户 |
| 2 | 欢迎需求变化，即使在开发后期；敏捷过程利用变化为客户创造竞争优势 |
| 3 | 频繁交付可工作的软件，从几周到几个月，倾向于更短的周期 |
| 4 | 业务人员和开发者必须在整个项目中每天一起工作 |
| 5 | 围绕有动力的个人构建项目；给他们需要的环境和支持，信任他们能完成工作 |
| 6 | 团队内外传递信息最有效的方式是面对面交谈 |
| 7 | 可工作的软件是进度的首要度量 |
| 8 | 敏捷过程提倡可持续开发；发起人、开发者和用户应能无限期保持恒定的步调 |
| 9 | 持续关注技术卓越和良好设计能增强敏捷性 |
| 10 | 简单——最大化未完成工作量的艺术——是根本 |
| 11 | 最好的架构、需求和设计出自自组织团队 |
| 12 | 团队定期反思如何变得更有效，并相应调整行为 |
原则 9 和 11 与本课主题直接相关：敏捷并不反对架构和设计，而是认为好的设计应该在持续关注中涌现。
5.6 敏捷只对最好的开发者有效？
- 每个项目至少需要一个有经验、有能力的带头人（关键成功因素）
- 团队中每有一个有经验、有能力的人，可以容纳 4–5 个“普通”或学习中的人
- 在这种技能配比下，敏捷技术多次被证明有效
六、DevOps
6.1 动机：软件交付的问题（IBM 数据）
| 指标 | 数据 |
|---|---|
| 预算用于维护和运维 | > 70% |
| 即使是小改动交付给客户所需时间 | 4–6 周 |
| 客户经历生产延迟 | > 45% |
| 外包项目未达目标 | > 50% |
当前的软件交付方式无法满足利益相关者和业务需要，必须改变。
6.2 什么是 DevOps
讲义中“What is DevOps?”和“Key elements in DevOps”两页为图片。按标准定义补充：DevOps = Development + Operations，是一组打通开发、测试和运维的文化与实践，通过自动化实现持续集成（CI）、持续交付/部署（CD）和持续监控，常用无限循环图表示：
6.3 DevOps 与敏捷
- DevOps 是敏捷的延伸——“Agile on Steroids”（Aniket Deshpande, 2016）
- 开发、QA 和运维角色的重叠增加：开发者编码、测试并部署；QA 调试并配置
- 更高程度的自动化
- 敏捷与 DevOps 协同演化（Coevolution）
七、Tutorial 9 要点
7.1 四种过程方法对比（Tutorial 最后一页，必背）
| 维度 | Waterfall | Spiral | Agile | DevOps |
|---|---|---|---|---|
| 主要关注 | 阶段与可预测性 | 风险与不确定性 | 迭代与反馈 | 交付与运行 |
| 核心问题 | 下一个阶段是什么？ | 我们该解决哪个风险？ | 下一个有用的增量是什么？ | 如何可靠地发布和运行？ |
| 工作流 | 顺序阶段 | 反复的风险驱动循环 | 短迭代周期 | 持续集成、交付和监控 |
| 变化 | 越到后期越昂贵 | 每一圈重新评估 | 预期并通过迭代吸收 | 由生产反馈驱动 |
| 客户反馈 | 通常较晚 | 在评审点 | 整个开发过程中频繁 | 包括线上运行反馈 |
| 风险处理 | 主要靠前期计划 | 显式且核心 | 通过小增量降低 | 通过自动化和监控降低运行与发布风险 |
| 交付模式 | 接近结束时一次大发布 | 每圈一个原型或增量 | 每个 sprint 一个可工作增量 | 频繁或持续发布 |
| 最适合 | 稳定、受监管或可预测的工作 | 复杂或高风险系统 | 需求变化、客户积极参与 | 发布后持续演化的在线服务 |
Waterfall、Spiral 和 Agile 指导开发；DevOps 把工作延伸到发布和运行。
解题思路（给场景选过程模型）：
| 场景特征 | 推荐 |
|---|---|
| 医疗器械软件，需求由法规固定、需要完整文档审计 | Waterfall（或 V 模型） |
| 首次尝试的自动驾驶决策模块，技术风险极高 | Spiral（每圈用原型消除最大风险） |
| 初创公司 MVP，客户反馈频繁、需求常变 | Agile/Scrum |
| 已上线的 SaaS，每天多次发布，需要监控回滚 | DevOps（在敏捷基础上） |
| 本课项目（One-Person AI Company） | Agile（Scrum + Jira），Stage 1 的模型提供架构约束 |
7.2 敏捷宣言与 Scrum 回顾
见上文 5.4 与 Week 08 第八节（三角色/三清单/三会议）。
常用工具：
| 类别 | 工具 |
|---|---|
| 沟通 | Slack、Zoom、Skype、Microsoft Teams |
| 版本控制 | Git（GitHub、GitLab、Bitbucket）、SVN |
| 项目管理 | Jira、Trello、GitHub Project Boards、Azure DevOps |
| CI/CD | Jenkins、Travis CI、CircleCI、Azure DevOps Pipelines |
| 云平台 | AWS、Azure、Google Cloud、Heroku |
7.3 LLM-based agent（为 Stage 2 准备）
三组件（Xi et al., 2023）：Perception（感知）→ Brain（决策）→ Action（执行/用工具）；可以是单模态（文本）或多模态（视觉、听觉、物理输入）。
四种能力（Microsoft 文档的分类）：
| 能力 | 内容 |
|---|---|
| Planning | 规划和排序动作以实现目标；LLM 极大提升了规划能力 |
| Tool usage | 代码执行、搜索、计算等；通常通过 function calling |
| Perception | 处理视觉、听觉等环境信息 |
| Memory | 记住过去的交互和行为，甚至自我反思 |
规划技术（Lilian Weng 的 agent 综述）：
| 类别 | 技术 | 要点 |
|---|---|---|
| 任务分解 | Chain of Thought (CoT) | 逐步推理，提升可解释性和表现 |
| Tree of Thoughts (ToT) | 探索多条推理路径形成树，用 BFS/DFS + 评估 | |
| LLM+P | 借助外部经典规划器（PDDL）做长程规划 | |
| 自我反思 | ReAct | Thought → Action → Observation 循环（Week 5 模式） |
| Reflexion | 动态记忆 + 自我反思 | |
| Chain of Hindsight (CoH) | 用带人类反馈的序列微调，改进输出 |
记忆映射：
| 人类记忆 | AI 对应 |
|---|---|
| Sensory memory | 原始输入的 embedding 表示 |
| Short-term memory | 上下文学习（有限的 context window） |
| Long-term memory | 外部向量库，快速检索 |
工具使用：MRKL（LLM 作路由器，把请求路由到神经或符号的“专家模块”，如计算器、汇率转换、天气 API）；TALM、Toolformer（微调 LM 学会调用 API）；ChatGPT Plugins / function calling；API-Bank 基准（53 个 API、264 段对话、568 次调用）。
框架：LangChain、LlamaIndex、Prompt Flow、Semantic Kernel；高级规划与自主执行：AutoGPT、AutoGen、GPT-engineer、ChatDev、OpenAI Assistants API、LangChain/LlamaIndex Agents。
案例：ChemCrow（LLM + 13 个专家工具做有机合成、药物发现、材料设计，LangChain 实现，ReAct 格式 Thought/Action/Action Input/Observation）；Generative Agents（25 个 LLM 驱动的虚拟角色在类 The Sims 沙盒中生活交互）；AutoGPT（自主执行，但可靠性问题）；GPT-Engineer（从自然语言生成代码仓库）。
7.4 Stage 2 时间节点
- 严格按 marking criteria 做
- 提交截止：Week 12 周日 23:59
- 迟交每天扣 5 分
- Demo 在 Week 13
八、Lab 9 要点
ELEC5620-Lab-Note-9.pdf（文件头 “Week 10: Laboratory
9”）：
Part One：敏捷实践跟进
- 开 Sprint Retrospective 和 Review：反思上一个 sprint 的过程（好的地方、需改进的地方）；lab 结束时评审本 sprint 完成的工作，和 tutor 讨论成果、待办任务和利益相关者反馈
- 继续在 Jira 中管理用户故事，根据反馈和最新认识细化
Part Two：ELEC5620 AI Proxy
- 课程提供 AI API Proxy，可访问 Campus Qwen 模型做 AI 辅助编码和 agent 开发
- Live demo：如何配合 OpenCode 和 AI agent 使用
- 按 ELEC5620 Proxy Connection Guide 配置 API key、VPN 和 OpenCode（Desktop 或 Terminal）
- 用 OpenCode + Campus Qwen 为项目生成、审查或调试代码
结合 Week 8 “敏捷与 vibe coding”：用 agent 写代码时，把 Stage 1 的模型（use case、类图、状态机）作为 agent 的约束输入，并在 retrospective 中记录 AI 在哪里省了力、又在哪里增加了调试和评审工作。
九、本周考点速记 / 易错点
- “Software processes are software too”（Osterweil, 1987）。
- 过程五特征：规定主要活动、用资源产出中间/最终产品、子过程与出入口准则、按顺序组织、受约束控制。
- 软件过程四活动：specification、design & implementation、validation、evolution。
- 计划驱动 vs 敏捷：前者提前计划、对照计划衡量；后者增量计划、易变；实践中混合，没有对错。
- 瀑布：五个不重叠阶段；文档重、易理解、里程碑明确；难以应对变化；适合需求稳定、多地点的大型系统工程。
- 螺旋：每圈一个阶段，无固定阶段，显式风险评估；影响大但很少照搬使用。
- 敏捷触发：开发周期太长导致成本上升、需求变化；敏捷关注代码、迭代、快速交付、快速演化，可能最适合中小系统。
- 敏捷宣言四对价值：个体互动 > 流程工具；可工作软件 > 详尽文档；客户合作 > 合同谈判；响应变化 > 遵循计划（右项仍有价值）。
- 十二原则中最常考：欢迎后期变化、可工作软件是进度首要度量、可持续步调、简单是最大化未做工作、自组织团队产生最好的架构。
- 1 个骨干带 4–5 个普通成员。
- DevOps：>70% 预算用于运维、小改动 4–6 周；DevOps = 敏捷的延伸（“Agile on Steroids”），角色重叠、更高自动化。
- 四模型对比表：关注点（阶段 / 风险 / 迭代 / 交付运行）、变化处理、反馈时机、最适场景。
- LLM agent：Perception–Brain–Action；Planning（CoT/ToT/LLM+P）、Reflection（ReAct/Reflexion/CoH）、Memory（感觉/短期/长期 ↔︎ embedding/上下文/向量库）、Tool use（MRKL、function calling）。