Day08-06｜3.1.6 信息系统开发方法：按问题特征选择过程与技术路线

教材定位：系统架构设计师教程（第 2 版）第 3 章“信息系统基础知识”第 3.1.6 节。

学习目标：理解信息系统开发方法的基本思想；掌握结构化方法、面向对象方法、原型法、迭代增量方法、敏捷方法、组件化和服务化方法的特点；能够根据需求稳定性、复杂度、团队能力、风险和交付节奏选择开发方法，并在案例和论文中说明理由。

一、开发方法不是项目模板

信息系统开发方法规定如何理解问题、组织人员、分析需求、设计系统、构造产品、验证结果和管理变化。它既包含技术方法，也包含过程、角色、工作产品和反馈机制。没有一种方法适合所有项目，架构师必须根据业务稳定程度、系统规模、质量要求、团队能力和外部约束做选择。

常见误区有两个：一是把“敏捷”理解成不需要文档和设计，二是把“瀑布”理解成完全不能变化。实际项目往往采用混合方法：总体架构和合规基线采用阶段性治理，业务功能采用迭代交付，高风险技术采用原型和实验，关键接口采用契约和自动化测试。

二、结构化方法

结构化方法以功能分解、数据流、数据字典和过程描述为主要工具，强调自顶向下、逐步求精和模块化。系统先被分解为功能和处理过程，再分析输入、输出、数据存储和控制关系，最终形成程序模块和数据库设计。

结构化分析常使用数据流图、数据字典、加工说明和判定表等工具。它适合业务流程稳定、处理逻辑明确、数据结构相对清晰的系统，如批量统计、财务核算和传统管理应用。优点是过程清楚、文档规范、便于分工和审查。

结构化方法的限制在于，它容易把系统看成“输入—处理—输出”的过程集合，对复杂对象、状态、并发、事件和动态变化的表达较弱。当业务规则频繁变化或多个对象长期协作时，单纯按功能分解可能造成数据和功能分散、修改影响范围大。

三、面向对象方法

面向对象方法把系统看成对象及其协作，对象封装状态和行为，通过类、接口、继承、组合和多态组织软件。分析阶段识别领域对象、职责和关系；设计阶段确定类、接口、协作和持久化；实现阶段用面向对象语言构造可复用单元。

面向对象的核心不是“每个名词都建一个类”，而是把变化隔离在职责清晰的边界中。封装隐藏内部实现，接口定义稳定契约，组合支持能力拼装，多态允许替换实现。继承可复用共性，但层次过深会造成隐式耦合，架构设计通常更偏向组合和接口。

面向对象方法适合领域概念丰富、状态和行为复杂、需要长期演化的系统。它要求团队掌握领域建模、职责分配、接口隔离和设计原则。对象模型与数据库、消息和外部接口之间可能存在阻抗失配，需要通过映射、领域模型和契约转换处理。

四、原型法

原型法在需求不清、交互复杂或技术可行性不确定时，先快速构造一个可观察模型，让用户和团队通过体验发现问题。原型可以是纸面流程、低保真界面、可运行技术验证或局部业务闭环。

原型的价值是获得反馈、验证假设、澄清术语和暴露风险，而不是直接替代最终产品。原型通常牺牲性能、安全、异常处理和可维护性，若团队直接在原型上不断加功能，容易形成结构混乱的“原型式生产系统”。

原型分为探索型和演化型。探索型用于回答问题，验证后可以丢弃；演化型在设计初期就考虑逐步完善，但必须建立质量门和重构计划。架构师要明确原型目的、时间、范围、不可复用部分和转正式实现的条件。

五、瀑布、迭代和增量方法

瀑布方法将需求、设计、实现、测试和交付按阶段组织，阶段产物和评审较明确，适合需求稳定、合规严格或交付顺序受约束的项目。它的风险是反馈较晚，需求误解和架构问题可能到后期才发现，因此不能把评审和原型全部推迟。

迭代方法把系统分成若干循环，每轮都经历分析、设计、实现和验证，逐步改善理解和方案。增量方法把系统能力拆成可交付增量，每个增量都能为用户提供部分价值。二者可以结合：每次迭代交付一个或多个增量。

迭代增量要求架构具备演进能力。必须定义最小可行能力、优先级、公共架构、接口基线、数据迁移和兼容策略。只顾每轮功能而不维护整体结构，最终会积累架构债务；只做大而全的架构，又会推迟价值交付。

六、敏捷方法

敏捷强调以人为本、可工作的软件、客户协作和响应变化。常见实践包括短周期迭代、用户故事、产品待办、持续集成、自动化测试、每日沟通、评审和回顾。敏捷通过频繁交付获得真实反馈，降低一次性做错的风险。

敏捷并不取消架构。架构师要在迭代节奏中处理架构愿景、质量属性、技术风险、公共能力、接口和演化路线。可以使用架构跑道、技术故事、架构决策记录、持续重构和架构评审，把架构工作纳入待办和验收。

大型或高合规项目需要适配敏捷治理。需求、代码、测试和部署要保持追踪；安全、性能和可靠性不能只在最后验证；跨团队依赖需要统一接口和集成节奏；重要决策要留痕。敏捷的速度来自快速反馈和自动化，而不是减少必要的工程活动。

七、组件化与服务化方法

组件化开发通过可复用、可替换和可组装的组件构造系统。组件应有明确接口、上下文、依赖、质量属性、版本和部署方式。复用前要评估适配成本、许可证、性能、安全和维护责任，不能因为“已有组件”就忽略集成风险。

服务化把业务能力封装为可独立访问的服务，通过接口或消息协作。它适合跨系统集成、团队自治、独立扩展和多渠道复用，但会引入网络延迟、部分失败、数据一致性、服务发现、监控和版本治理。

组件和服务的边界应由职责、数据所有权、变化方向和故障隔离决定，而不是按代码文件数量拆分。服务拆分前要确认组织和运维能力，建立契约测试、链路追踪、配置、发布、限流、熔断和回滚能力。

八、开发方法的选择框架

选择开发方法可以从六个维度判断：需求是否稳定，用户能否持续参与，技术和业务风险是否高，系统是否需要分期交付，合规和文档要求是否强，团队是否具备自动化和持续集成能力。

真实项目可以组合方法，但要明确每种方法解决什么问题。例如采用敏捷开发业务功能，采用架构评审管理质量属性，采用原型验证高风险技术，采用契约测试管理服务接口，采用阶段验收满足合规要求。

九、案例：政务审批系统开发方法选择

某政务审批系统涉及法规流程，核心审批规则相对稳定，但移动端交互、跨部门协同和数据共享需求仍在探索。项目要求一年内上线首批事项，后续持续增加新事项。

适合采用混合方法：核心法规、权限、审计和数据标准采用阶段化分析与评审，保证合规和可追溯；移动端和用户体验采用原型与短周期迭代，持续让窗口人员和群众反馈；事项能力采用增量交付，先上线高频事项；跨部门接口采用服务化和契约测试；平台公共能力先形成最小架构基线，再随业务迭代扩展。

验收要覆盖功能、办理时长、数据准确性、权限、审计、峰值性能和异常流程。每次迭代都要更新需求追踪、架构决策和接口文档，防止快速交付变成无序堆叠。

十、练习与详细答案

1. 结构化方法和面向对象方法的主要区别是什么？
2. 原型为什么不能直接作为生产系统？
3. 敏捷是否意味着不需要架构设计和文档？
4. 迭代增量开发需要重点控制什么？
5. 组件化和服务化为什么会增加治理要求？

答案：1. 结构化方法以功能、数据流和处理过程为核心，面向对象方法以对象、职责、状态和协作为核心；2. 原型常牺牲安全、性能、异常处理和可维护性，直接生产化会形成结构债务；3. 不需要的是无价值的厚重文档，不是架构决策、质量属性、接口和追踪，敏捷仍需适度架构和持续文档；4. 控制整体架构一致性、接口基线、数据演进、公共能力、技术债务和跨增量集成；5. 多组件和服务形成版本、依赖、网络、故障、一致性、监控、权限和发布问题，需要统一治理。

案例题：某团队声称采用敏捷开发，因此先不做架构设计，半年后服务数量暴增、接口互不兼容、性能无法达标。请分析并提出改进。

参考答案：把敏捷误解为拒绝前期思考，导致质量属性、领域边界、公共能力和接口契约没有基线；每个迭代只优化局部功能，跨服务调用、数据所有权、性能和运维问题被推迟。应建立轻量架构愿景和质量目标，先识别高风险场景和领域边界；将架构任务纳入待办，通过技术原型、契约测试和持续集成验证；控制服务拆分依据，统一认证、配置、日志、追踪和发布治理；持续重构并记录决策，按 P95、吞吐、错误率、部署频率和故障恢复时间复测。

十一、论文素材与复盘

论文中可以写“因地制宜的开发方法”：需求稳定和合规部分采用阶段化基线，交互不确定部分采用原型，业务能力按增量迭代交付，高风险技术先做验证，跨系统能力采用组件化或服务化；通过持续集成、自动化测试、架构评审、需求追踪和生产反馈保证快速交付不牺牲质量。

今日核心记忆句：开发方法选择取决于需求、风险、交付、合规和团队能力；结构化适合流程清晰，面向对象适合复杂领域，原型适合探索，迭代增量适合持续交付，敏捷适合快速反馈，组件/服务化适合复用和集成；方法可以组合，但每种方法都必须有明确目标、产物和验证。