Day23-02｜5.1.2 软件过程模型：按不确定性组织需求、设计、验证与交付

本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.1.2“软件过程模型”。软件过程模型是对软件开发活动、顺序、反馈和交付方式的抽象。它不是项目必须照搬的固定模板，而是帮助团队在需求稳定性、技术风险、质量要求、交付节奏、合规约束和组织能力之间作出选择。系统架构师需要理解模型背后的假设，并根据项目实际情况组合使用。

一、学习目标与考试定位

完成本节后，应能够解释软件过程模型的作用，比较瀑布模型、原型模型、增量模型、迭代模型、螺旋模型、喷泉模型、V 模型和统一过程等常见方法；能够根据需求变化、技术风险和质量要求选择合适模型；能够说明模型的优点、缺点、适用场景和风险控制；能够在案例题中指出“模型与项目特征不匹配”的问题；能够在论文中说明过程模型如何支持架构验证和项目交付。

考试常给出一个项目背景，再问“应采用哪种模型”“为什么”“如何改进”。不要用项目类型直接套模型，例如“所有大型项目都用瀑布”“所有互联网项目都用敏捷”。正确答案应从需求是否稳定、技术是否成熟、系统是否需要快速交付、是否存在高风险、是否需要阶段验收、是否受严格监管等条件推导。

二、什么是软件过程模型

软件过程模型是对软件生命周期中各项活动及其相互关系的抽象描述。它规定或建议需求、分析、设计、实现、测试、部署和维护如何组织，哪些活动先做、哪些活动可以并行、如何获得反馈、何时形成可交付成果以及如何控制变更。

模型的价值在于提供共同语言和管理框架。项目成员可以据此理解当前阶段、输入输出、评审点、责任和风险。但模型只是抽象，实际项目通常需要裁剪。例如高合规项目可能采用阶段性基线和独立验证，同时在每个阶段内部使用迭代开发；大型平台可能先做架构和基础设施，再按业务能力增量交付。

选择模型时可沿着这条决策链思考：

需求稳定性 → 技术成熟度 → 质量与合规约束 → 交付节奏 → 风险类型 → 团队和客户反馈能力

三、瀑布模型

瀑布模型将开发过程划分为需求分析、系统设计、详细设计、编码、测试、运行和维护等阶段，阶段之间按顺序推进，前一阶段产物经过评审后作为下一阶段输入。它强调计划、文档、基线和阶段验收，适合需求相对稳定、技术成熟、合同和合规要求明确的项目。

瀑布模型的优点是职责和阶段清晰，便于计划、成本估算、文档审查和阶段管理；缺点是用户较晚看到可运行产品，需求误解和架构问题可能在后期暴露，变更成本较高，难以适应不确定性强的项目。架构师在瀑布项目中也不能把架构评估拖到设计结束，应在需求阶段识别质量属性，在早期用原型和架构验证降低风险。

四、原型模型

原型模型先快速构造系统的部分可运行表示，让用户和开发者共同澄清需求、交互和技术可行性。原型可以是抛弃式原型，也可以逐步演化成最终系统。抛弃式原型重在学习和沟通，通常不应直接作为生产代码；演化式原型则逐渐完善，但需要严格控制代码质量、架构边界和技术债务。

原型特别适合需求不清、用户难以准确描述、交互复杂或技术可行性未知的项目。风险是用户把演示原型误认为成品，团队为了赶进度直接堆叠原型代码，最终出现性能、安全和可维护性问题。架构师应明确原型目标、验证问题、时间限制、评估指标和是否丢弃，不能把“能展示”误认为“可上线”。

五、增量模型与迭代模型

增量模型把系统功能拆成多个增量，每个增量都经过需求、设计、实现和测试，逐步交付可使用的产品。它强调“分批交付功能”，适合业务可以分解、客户希望尽早获得价值且团队能持续发布的项目。增量顺序应依据业务价值、依赖关系和风险安排，基础能力和核心流程往往先交付。

迭代模型则允许通过多轮循环逐步完善需求、架构和实现。每次迭代可能对已有功能进行修正、扩展和优化，更强调通过反馈降低不确定性。实际项目常把二者结合：以迭代方式学习和改进，以增量方式交付可用能力。

增量和迭代都不是把系统随意切成小块。架构师必须设计稳定的核心模型、接口和数据策略，避免每个增量形成孤立烟囱；要处理跨增量的事务、一致性、权限、观测、部署和回滚；要保留架构演化和兼容机制。

六、螺旋模型

螺旋模型以风险为中心，通常经过目标和约束确定、风险分析与原型验证、开发和验证、计划下一轮等循环。每一轮都识别和处理最重要的风险，逐步逼近目标系统。它适合规模大、复杂度高、技术和需求存在较大不确定性、失败代价高的项目。

螺旋模型的优点是风险前置、反馈及时、能够组合原型和增量；缺点是管理复杂、需要较强风险分析能力和客户参与，成本和周期不容易一次性估算。若团队只是机械地重复循环而没有明确风险目标，就会变成无休止的迭代。架构师应为每轮定义风险假设、验证方法、退出条件和交付物。

七、V 模型

V 模型强调开发阶段与测试阶段的对应关系：需求分析对应验收测试，系统设计对应系统测试，详细设计对应集成测试，编码对应单元测试。它突出验证与确认活动的计划前置，适合安全攸关、质量要求高、需要严格追踪和阶段证据的系统。

V 模型的优势是测试目标和验收依据清晰，能够降低“开发完成后才想测试”的风险；局限是面对频繁需求变化时调整成本较高，若把 V 形理解为完全线性，也可能缺少早期原型和持续反馈。合理做法是将测试设计前置，并在每个阶段增加评审、模拟、原型和自动化验证，而不是等到 V 的右侧才开始质量活动。

八、喷泉模型与统一过程思想

喷泉模型适合面向对象开发，允许分析、设计、实现和测试活动交叠进行，体现迭代、并行和对象模型逐步演化的特点。它比严格顺序模型更能适应对象和需求的逐步细化，但需要团队维护模型一致性和版本关系。

统一过程通常具有用例驱动、以架构为中心、迭代和增量式开发等特征，并划分初始、细化、构造和移交等阶段。细化阶段重点解决架构和高风险问题，构造阶段完成主要功能，移交阶段面向用户部署和反馈。统一过程的价值不在于阶段名称，而在于把用例、架构、迭代、风险和交付联系起来。

九、模型比较与选择

十、架构师如何裁剪过程模型

过程模型选择后，还要根据组织、项目和合同进行裁剪。首先明确必须遵守的法规、标准和阶段验收点；其次识别必须前置验证的架构风险，如性能、并发、安全、数据迁移和第三方集成；再次划分增量和迭代边界，保证每个交付物具有可验证的完成标准；最后设计变更控制、配置管理、测试自动化、发布和回滚机制。

在大型项目中，常见组合是“总体架构和关键约束采用阶段化管理，业务功能采用增量迭代，质量验证采用 V 模型思想，重大技术风险采用螺旋式原型验证”。这种组合不是概念混乱，而是不同模型解决不同问题。关键是明确每种方法的适用边界、责任人和证据。

十一、案例分析：监管平台的模型选择

某监管平台需要满足严格审计和阶段验收，但业务部门对报表和操作流程描述不清，平台还要接入多个历史系统。项目经理主张全程瀑布，业务方希望两周看到可运行界面，技术团队担心数据交换和权限模型存在风险。

合理方案不是简单选择一个模型，而是组合使用。对监管要求、数据分类、权限边界、审计和外部接口，建立阶段基线和正式评审，体现瀑布和 V 模型的可追踪性；在早期用抛弃式原型澄清报表、流程和用户交互；对历史系统接入、数据迁移和高并发查询进行螺旋式风险验证；业务功能按价值拆分增量交付，每个增量必须完成开发、测试、文档和验收；对需求变化实行影响分析和配置管理，避免原型和增量随意改变核心数据模型。

架构师还应定义质量场景和验收证据，例如权限越权测试、审计日志完整性、接口失败重试、报表响应时间、迁移数据一致性和灾备恢复结果。这样既满足监管的过程证据，也能通过早期反馈降低需求和技术风险。

十二、常见误区

第一，模型是越先进越好。适合项目约束的模型才是合理选择。第二，敏捷或迭代意味着不需要文档、设计和测试，实际上迭代项目更需要轻量但持续的工程产物。第三，瀑布意味着不能做原型和反馈，实际上可以在阶段内安排验证，只是变更控制更正式。第四，增量意味着每个模块可以独立乱做，实际上必须保持总体架构、数据和接口的一致性。第五，V 模型只有测试阶段才做质量，正确理解应是验证活动前置并与开发活动对应。

十三、课后练习

练习一：单项选择

某项目需求不清、用户难以描述交互方式，且存在一项关键技术可行性风险，最适合优先采用（ ）。

A. 直接全量瀑布开发；B. 原型和风险验证相结合的迭代方式；C. 取消用户参与；D. 只在上线后测试。

答案：B。原型可澄清需求和交互，风险验证可提前处理技术不确定性，再通过迭代逐步完善。

练习二：简答题

请比较增量模型和迭代模型，并说明二者如何结合。

参考答案：增量模型强调把功能拆成多个可交付部分，逐步增加系统能力；迭代模型强调通过多轮循环不断修正和完善需求、设计与实现。项目可以在每个增量内部进行多轮迭代，先验证高风险和核心流程，再逐步完善功能，并通过统一架构、接口、数据模型、测试和发布策略保证各增量集成一致。

练习三：案例分析

某航空控制系统采用快速原型直接演化成生产代码，初期演示效果很好，但上线后出现实时性不足、异常处理不完整和测试证据缺失。请分析原因并提出改进方案。

参考答案：原型的目标是探索需求或技术，不一定具备生产级实时性、容错、安全和可维护性；团队没有区分抛弃式原型与演化式产品，也没有建立质量属性和验证计划。应重新识别实时性、可靠性、安全性和可追踪性要求，对关键技术进行专门原型和性能验证；建立需求—设计—代码—测试追踪，采用适合安全攸关系统的阶段评审和 V 模型验证；补齐异常处理、故障隔离、监控和恢复设计；对原型代码进行重构或重建，不能仅靠增加服务器解决架构问题。

十四、论文素材

论文可写：项目启动时，我没有机械套用单一过程模型，而是根据需求稳定性、技术风险、合规要求和交付节奏进行裁剪。对总体边界、数据安全和审计要求采用阶段基线和正式评审，对交互不清的部分使用抛弃式原型，对高风险接口和性能瓶颈进行早期验证，对业务功能按价值增量交付，并在每个增量中完成设计、编码、测试、文档和发布。通过需求追踪、配置管理、自动化测试、架构复审和风险登记持续控制变更，兼顾了过程可追溯性与业务反馈速度。

十五、今日复盘

软件过程模型是组织活动、反馈、风险和交付的方式。瀑布强调阶段和基线，原型解决需求和技术不确定性，增量强调分批交付，迭代强调持续完善，螺旋强调风险驱动，V 模型强调开发与验证对应，统一过程强调用例、架构和迭代增量。模型选择必须基于项目条件，并允许合理组合和裁剪。下一篇进入 5.1.3 敏捷模型。