软件工程

软件工程的定义与基础支撑

100 人报名上限，两个学生同时看到最后一个名额。在同一瞬间点击确认，后台如果缺乏正确的并发控制，就可能超额接收报名。项目最初预估为两周完成的小工具，随后因规则变化而延期，交付的功能也可能偏离主办方期望；人员交接缺乏文档，又让维护困难。进度难预测、成本难控制、功能不满足期望、质量难保证、难维护和文档不足，是教材所说软件危机的六种表现。软件工程将系统化、受约束、可量化的工程方法应用于开发、运行和维护，帮助团队处理这些问题。

软件生命周期包含四项基本工程活动：软件规格说明明确系统功能与约束，软件开发产出符合要求的系统，软件确认验证系统符合预期，软件演进负责系统上线后的变更与完善。架构设计和编码实现从属于开发活动内部，并不与四大活动平级。工程中常借用质量管理中的PDCA（计划-执行-检查-处理）辅助理解这四项活动的推进关系，但两者属于不同范畴的方法论，不能直接视为同一模型。支撑这些活动的集成环境包含三项关键机制：环境信息库负责跨阶段数据的集中存储与共享，过程控制与消息服务器负责工具间的事件联动与流程协调，统一界面则提供一致的操作交互。

生命周期模型与演变逻辑

过程模型用于组织各项工程活动的顺序、反馈和衔接。在报名系统早期，如果业务规则较明确，技术方案也已有验证，瀑布模型能提供清晰的阶段边界。前一阶段的产出经过评审，作为后一阶段的输入。若规格遗漏一直未被发现，直到集成或用户试用才暴露，后面的设计、代码和测试就可能一起返工。阶段评审可以提前发现问题，但它对真实使用体验的反馈仍可能较晚。需求稳定是适合条件，并不保证效率最高；实际项目遇到缺陷，也需要受控地回到前面的工作修订。

当活动负责人提出新需求：名额满员后开放候补排队，一旦有人取消，系统自动按序补位并通知学生。面对新增业务，增量与迭代以不同方式参与系统演进。增量关注可用功能的扩充，系统先交付基础报名功能，下一版本补充候补排队表单，再下一版本增加自动补位后台。迭代关注在已有功能范围内改进实现，对于最初简单的数据库读写，开发团队在相同业务功能下重新设计并发检查逻辑，引入事务重试与状态校验以提升并发可靠性。增量提供新的功能切片，迭代在复访中完善实现，两者通常结合运用。

若系统面临高并发性能未知或第三方服务接口不稳定的显著风险，螺旋模型提供了一种可选的风险驱动机制。螺旋模型以循环螺旋的方式推进，每个周期依次展开：确定目标、备选方案与约束条件；评估方案并开展风险分析；执行当前周期的开发与验证；评审并规划下一阶段工作。团队可以在风险分析阶段针对候补排队逻辑编写性能原型进行实测。需要注意的是，风险处理旨在控制和降低不确定性，但系统依然可能存在残余风险；迭代推进也是多数现代模型共有的特征，不宜将螺旋模型理解为某种特殊的运算公式。

组成来源类试题有三个相近空位。教材把螺旋描述为在快速原型基础上扩展、结合生命周期模型与原型模型：生命周期提供阶段产物和评审约束，原型帮助较早取得反馈，显式风险分析决定这一轮如何推进。因此，“瀑布模型与什么结合”题里通常填快速原型；“原型与什么结合”按教材选生命周期模型，选项可能写经典生命周期或瀑布。“迭代”描述反复推进的运行特征，“增量”描述功能扩充，两者都不能自动替代组成来源题所问的模型。这组说法是教材的来源概括，不是给模型做数学加法；风险驱动仍是识别实际机制的重点。

再把视线放到螺旋本身：沿蓝线绕过四个活动区，读的是本轮工作如何推进；从中心向外看距离，读的是累计成本与投入。十字线只分活动区，不是“横轴时间、纵轴风险”的数值坐标。走到轮末，参与方还要决定是否继续；选择继续，才带着评审结果进入下一轮。下面的图专门用来读这个关系，前一张图则保留题干问法的辨析。

原型的维度划分与应用场景

负责人还没想清楚候补按钮应放在哪里。先做可以点选的页面，让他试一次，往往比反复解释文字更容易澄清分歧。若疑问变成“两个取消请求会不会补入同一个人”，就需要运行关键逻辑。两者都叫原型，回答的问题却不同。实现的广度与深度、原型最后的去向，是两条独立分类轴，可以组合：

在工程选择上，需求不清不足以作为唯一决定采用抛弃式原型的依据。即使需求存在模糊，只要核心领域结构相对稳固，团队依然可以采用演化式垂直原型逐步摸索并保留成果。同时，原型同样可以实现真实功能，例如垂直原型可以包含真实的数据库操作与并发控制，只是它是否满足正式发布的质量标准（如异常处理、安全审计、文档完备性）属于另一个维度的考量，不宜将所有原型都视为缺乏真实逻辑的模拟界面。

“迭代、集成、抛弃”放在一起时，先检查它们各在回答什么。迭代说的是反复改进，抛弃式原型也能试过几版才舍弃；增量说的是添加功能；集成说的是把部件组合起来。抛弃与演化则回答原型实现最终怎样处理。它们可以同时出现在一个项目里，不能只凭这些词把软件放进同一组互斥象限。抛弃实现之后，需求理解、设计取舍和验证结果仍然可以留下。

教材的过程分为原型开发、目标软件开发两阶段。取得反馈后，团队先修正理解，确认需求，再开发目标系统。第一阶段可以模拟人机界面和交互、实际开发一个原型，也可以找已有相似软件供用户比较。要验证并发规则时，界面模拟不够；只是讨论候补按钮时，先拿现成报名软件比较，可能已经够用。反复试用也要逐步收敛到目标范围，不能无限扩展原型。

敏捷原则与轻量级协作

面对业务规则的频繁变动，敏捷方法提供了更具弹性的应对手段。敏捷的核心特征在于适应性与面向人。敏捷宣言提倡：个体与交互胜过过程与工具，可工作的软件胜过面面俱到的文档，客户合作胜过合同谈判，响应变化胜过遵循计划。在重视左项的同时，右项依然具备工程价值。敏捷提倡精简冗余的形式化流程，但关键的设计记录、接口定义与运维文档依然在系统维护中发挥作用。

极限编程（XP）以技术实践为核心驱动力。教材口径中XP包含四项核心价值观：交流、朴素、反馈与勇气（现代XP版本扩展了第五项“尊重”）。XP围绕这些价值观确立了一组紧密关联的实践：测试先行（在编码前编写自动化单元测试）、结对编程（双人协同审视代码）、简单设计（仅满足当前已知需求）、重构（保持外部行为不变优化内部结构）、持续集成（频繁合入主干并触发自动化构建）以及小版本发布。在XP实践中，原型代码用于快速探索某项算法的可行性，而小版本发布交付的则是符合生产质量标准的可用系统子集，两者在质量要求上存在明确界限。

Scrum 侧重组织协作。部分案例采用 2–4 周的 Sprint，Scrum Guide 2020 规定一个月或更短。产品负责人维护 Product Backlog（产品待办列表）；Sprint 计划中，团队围绕目标选取本轮条目并形成 Sprint Backlog（目标、选定条目及交付计划），无需把整个产品待办列表都塞进本轮。每日 Scrum 是 15 分钟的开发者活动，检查目标进展并调整计划。Sprint 评审检查产品结果，Sprint 回顾检查团队工作方式。符合完成标准的可用增量提供真实反馈，是否发布还要结合业务决定。

其他敏捷方法各具侧重。水晶方法（Crystal）按人员规模、项目关键程度和协作环境选择方法族。特征驱动开发（Feature Driven Development，FDD）先开发整体对象模型、构造特征列表、计划特征开发，再对选定特征反复设计和构建。前面三项给出整体方向，后两项形成小迭代，不能当成五个一次性阶段。教材列出的六种关键角色是项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家；这是职责分工，人员少时可兼任。

同一团队可以用 Scrum 安排迭代，再用 XP 的结对、测试先行与重构落实技术工作。两套方法各有侧重。看到“每天开会”还不够识别敏捷，需看会议能否形成反馈，团队是否据此调整、持续交付可用结果。

统一过程的阶段划分与多维工作流

团队希望把范围、技术风险和交付准备放到同一套框架下，Rational Unified Process（RUP，统一过程）给出了阶段、活动和制品之间的安排。它可按项目裁剪，特点是用例驱动、以体系结构为中心、迭代与增量。一个开发周期在时间轴上分为四个连续阶段：

阶段与工作流构成了相互交叉的两个维度。每个阶段可以包含一轮或多轮迭代。单次迭代根据当前阶段的目标按需执行多种工程活动，不会在单次迭代内部重新完整走一遍初始、细化、构造、移交四个阶段。多轮迭代的产出可以用于内部技术验证，也可以形成对外发布的交付版本。在细化阶段，架构探索是重点工作，其目标是建立稳定可执行的架构基线，后续阶段依然允许对架构进行受控演进。

RUP 包含九大核心工作流：六个过程工作流（业务建模、需求、分析与设计、实现、测试、部署）和三个支持工作流（配置与变更管理、项目管理、环境）。风险管理属于项目管理，环境也是正式支持工作流。工作流可以跨阶段按需开展，并不要求每个阶段九种工作都做一遍：细化阶段可实现和测试架构骨架，构造阶段仍可处理需求变化。RUP 支持裁剪，XP 的测试先行和重构等实践也可以融入具体迭代。

在细化阶段的一次迭代里，学生代表确认候补规则，设计人员调整队列职责，程序员实现并发检查，测试人员制造竞争条件。四个人处在同一阶段，做的是不同工作流。初始阶段也可探索架构，细化的区别在于形成有证据支持的架构基线；后面仍允许受控演进。题干说“建立完善架构”，是在问阶段重点。

再落到一次“评审候补规则”的工作：角色回答 Who，谁负责；活动回答 How，完成哪项有明确目的的工作；制品回答 What，产生或修改了什么信息；工作流回答 When，活动如何衔接。角色可由一个人或小组承担，制品可以是需求文档、模型、代码、测试结果。

4+1架构视图对系统的多角度观察

在设计和理解复杂系统时，单一视角难以覆盖不同干系人的关切。Kruchten提出的4+1视图模型通过五个视角来呈现同一系统：

• 逻辑视图：关注功能需求，以用户和分析人员为视角，描述系统内部的概念实体与对象职责。在报名系统中，它呈现了“活动”、“报名表单”、“候补排队列表”等业务概念及它们之间的约束关系。
• 开发视图（实现视图）：关注软件模块的组织结构，以开发人员和配置管理员为视角，展示源码文件、工程包、构建脚本及依赖关系。
• 进程视图：关注非功能属性与运行时表现，以系统集成人员为视角，分析进程边界、线程分配、并发竞争与通信机制。在早晨高并发报名场景下，它描述了请求如何被工作线程接收，并发排队逻辑如何执行。
• 物理视图（部署视图）：关注软件构件到硬件节点的映射，以运维人员为视角，展示应用服务、数据库实例、网络设备与服务器环境的物理分布。
• 场景视图（用例视图）：居于核心地位的“+1”视图。它通过典型的业务用例把上述四个视图串联起来，验证设计是否能够满足功能与质量要求。

学生提交候补申请：用例视图描述用户目标及与系统的交互；逻辑视图描述报名、候补实体的职责与关系；实现视图展示承载它们的包和模块；进程视图描述请求执行时的并发、通信和同步；部署视图标出软件落在哪些硬件节点。视图是描述，实际执行调用的是软件。它们并行审视同一个系统，不表示四个时间阶段。

过程能力与组织成熟度模型

过程模型指引了开发活动的推进节奏，而组织交付质量的稳定性则取决于过程能力的成熟程度。CMM与CMMI用于评估组织的过程能力与成熟度，它们属于评价体系，不能视作开发过程模型，也不是RUP之后的延伸阶段。

早期软件CMM定义了五个阶梯等级：1级初始级、2级可重复级、3级已定义级、4级已管理级、5级优化级。而在CMMI的阶段式模型中，五个等级的官方命名具有明确区分：1级初始级、2级已管理级、3级已定义级、4级量化管理级、5级优化级。在概念辨析中，切勿将2级与4级的名称混淆，更不能出现“4级已定义”的错误表述。

各个级别反映了不同的管理控制深度：

• 1级 初始级：开发过程随意，缺乏正规规范，项目的完成主要依赖个别骨干的经验投入。
• 2级 已管理级：在项目级别建立了基础管理纪律，包括需求跟踪、项目计划与监控，确保项目内部受控。
• 3级 已定义级：在组织层面建立了标准软件过程资产库，项目团队可以依据统一指南对组织级标准过程进行剪裁使用。在此级别之前，个别项目也可以存在局部规范，但3级标志着规范上升为组织级的统一资产。
• 4级 量化管理级：组织使用统计与度量技术对选定的关键子过程进行精确定量控制，使过程质量与执行表现具有统计可预测性。
• 5级 优化级：基于长远业务目标，运用量化数据开展根本原因因果分析，通过技术与过程改进实现持续演进。

判断4级与5级的核心差异，在于4级侧重利用统计数据控制过程波动的可预测性，5级侧重围绕业务目标通过因果分析与技术创新驱动持续改进。组织历史数据在4级构建性能基线时即已被广泛使用，不能仅凭使用了多个项目的数据就将其判定为5级。

教材语境下，CMMI 有阶段式与连续式表示。阶段式对一组过程域给出组织成熟度，五级为 1–5；连续式看选定过程域的能力，v1.2 为 0–5，v1.3 为 0–3。版本变了，不能把旧能力级数照搬。五级成熟度也不意味着每个项目一定成功。

相关试题另考“方针→过程→规程→模板”文件层次：方针规定方向，过程规定活动，规程细化复杂活动，模板支持执行。排序轴是抽象到具体，模板能复用也仍在具体层。这是题库采用的体系文件组织口径，CMMI 没有强制所有组织只采用这一种四层结构。教材转录中的“3168 种关键时间”等数字有明显疑点，本册不采用。

工程术语在业务变更中的协同落地

当回到校园活动报名系统面对的“满员后候补排队与自动补位”需求变更时，前面讨论的各项概念在实际研发中展现出各自的分工：

• 在开发组织层面，团队可以采用Scrum形式，将“候补排队”与“自动补位”拆解为产品待办条目，纳入Sprint待办列表，在每日例会中围绕Sprint目标协同调整代码实现，并在迭代周期末向活动主办方演示增量。
• 在生命周期管理层面，若系统基于RUP体系推进，候补逻辑中涉及的高并发数据一致性问题被作为核心技术风险，安排在细化阶段的迭代中通过构建架构基线加以验证，需求、设计、实现与测试工作流在各个阶段按需协同展开。
• 在系统设计层面，4+1视图为该变更提供了清晰的解耦表达：用例视图定义了补位场景，逻辑视图补充了排队队列实体，进程视图规划了并发检查与通知派发线程，开发视图建立了新增业务模块，物理视图指明了服务部署的硬件位置。
• 在组织能力层面，CMMI提供了检验工程过程的度量坐标。一个规范的团队无需宣称获得了高级别认证，只要遵循既定流程管理需求变更、落实代码评审并根据历史缺陷数据改进补位逻辑的健壮性，工程方法便已在实际系统中发挥作用。

再换一个条件：负责人一次确认全部规则，技术路径成熟，阶段交接成本较低，瀑布安排会更容易管理；若用户只有“想看一个候补效果”，原型先帮助澄清；若关键困难是并发一致性未知，风险分析要先决定下一轮投入。判断跟着条件走。下一节把那句候补要求变成可批准、可追踪的需求变化。