软考系规的科目一里，第 5 章「应用系统规划」是个典型的高频考点集中区：九大基本概念、四种基础架构、生命周期模型怎么选、规划五步走、三大常用方法，再到软件工厂 —— 概念又多又像，很容易记混。这一篇帮你把整章知识串成一张清晰的地图，考点、速记、典型习题一次讲透。

这一章概念虽多，抓住一条主线，就能把整章串起来。

一、基础知识：先搞懂这 9 个概念

针对组织的具体需求，应用系统规划设计的内容存在较大差异，覆盖了： ① 应用系统整体规划，即按照组织业务与信息发展战略等，对组织所有应用系统建设进行统筹，形成应用系统集合及应用系统间的关系，并明确每个应用系统的主要内容及发展路径等； ② 应用系统业务条线规划，即针对组织业务发展的条线划分及组织 IT 治理的定义等，对组织业务中某个条线的应用系统进行体系性定义，比如业财体系、仓储物流体系、服务体系等； ③ 应用软件设计，即针对组织业务获得的某项具体职能或业务活动域等进行应用软件模块定义，包括功能与非功能建设、模块划分等。

九个概念看似零散，其实是应用系统规划一以贯之的底层逻辑。

分层体系： 从上至下依次为界面交互层（界面控件）、业务处理层（业务子系统）、数据处理层（基于 SQL 的函数包）、数据存储层（数据表、数据文件等）。

以数据为中心的架构： 适合以数据处理、统计、汇总为业务特征的应用系统；数据驱动是常见设计路线，先规划好数据环境（数据库、数据文件），再按业务应用划分子系统。关键优势：数据一致性、开发效率、灵活扩展、分析能力。

客户机 / 服务器架构： 两层 C/S 将应用系统分为前端程序与后台数据两部分，结构简单、易实现，但管理与维护不便；三层 C/S 将业务处理程序放到专门的应用服务器上，系统业务规则改变时只需更新应用服务器，利于维护，但技术实现难度较大、硬件性能要求更高； B/S 架构用 Web 服务器上的 Web 页替代客户机界面程序，无须专门维护客户机，但数据传输速度、数据安全性、稳定性低于传统 C/S 。

组件分布架构： 组件分布架构需要有组件分布中间层构件提供基础服务，如同软件总线，支持组件插拔与通信协作；主要的组件分布中间层构件有 CORBA （ OMG 定义，通用性与机器无关）、 DCOM （微软概念和程序接口，通用性不如 CORBA ）、 EJB （基于 Java 的分布式组件对象模型）。

应用系统的不同抽象层次中，以下说法错误的是。 A ．业务抽象将复杂业务活动转化为可管控、可表达的业务区块 B ．过程抽象是指具有明确和有限功能的指令序列 C ．数据抽象主要关注系统间通信方式和接口设计 D ．技术抽象描述解决问题所需的可持续开发利用的技术体系。 参考答案： C 。 （数据抽象是描述数据对象的具体数据集合，而非系统间通信方式和接口设计）

关于模块化设计，以下描述是正确的？ A ．高耦合性是模块化设计的理想目标 B ．内聚性表示不同模块之间的依赖程度 C ．信息隐蔽原则要求模块应对其他模块隐藏自己的规划设计决策 D ．功能独立与模块的可维护性没有直接关系。 参考答案： C 。 （ B 错误，内聚性表示模块内部功能关联强度； D 错误，功能独立有助于提高可维护性）

二、主要内容：生命周期、体系结构、接口、数据、软件定义

1. 生命周期模型选择（ ★★★ ）

生命周期模型没有绝对好坏，关键看需求稳不稳定、变化快不快。

瀑布模型： 阶段间具有顺序性和依赖性（前一阶段完成才能开始后一阶段、前一阶段输出是后一阶段输入）；推迟实现的观点（尽量推迟物理实现）；质量保证的观点（每阶段完成规定内容并评审，尽早发现问题）。

V 模型： 瀑布模型的变种，描述测试活动如何与分析设计相关联；编码是 V 模型的顶点，分析和设计在左侧，测试和维护在右侧；单元测试和集成测试验证程序设计、系统测试验证系统设计、由用户主导的验收测试确认需求。

迭代模型： 分演化建设（先交付完整系统再不断完善）和增量建设（作为一系列增量构件，先交付部分功能子系统再不断增加）。优点：逐步增加功能、用户有充裕时间适应、失败风险较低、最重要的服务先交付并接受最多测试。注意：增量构件集成进体系架构时不能破坏已部署内容、体系架构必须开放。

敏捷方法： 敏捷宣言 4 种核心价值 —— 个体和互动高于流程和工具、工作的软件高于详尽的文档、客户合作高于合同谈判、响应变化高于遵循计划；另有 12 条原则（尽早持续交付高价值软件、欣然面对需求变化、频繁交付可工作软件、业务人员和开发人员每天一起工作、以受激励个体为核心、面对面交谈、可工作软件是衡量进度首要标准、可持续开发、追求技术卓越与良好设计、简单、自组织团队、定期反思）。

每个生命周期模型都会包含通用活动：和用户达成一致的需求、基于需求的规划设计、基于规划设计的构造、基于所有优先级步骤的测试流程的构建、每一阶段的出口和入口标准。

典型习题： 某大型航空公司需要开发飞行安全关键系统，必须符合严格航空安全认证标准，需求变更需多方审批，每阶段需留存详细文档以备审计，最适合的开发模型是？ 答案： B （瀑布模型）。 移动开发团队根据用户反馈立即调整开发优先级、放弃次要功能改进核心功能，最符合哪种开发理念？ 答案： C （响应变化高于遵循计划，为客户创造价值）。

2. 体系结构定义（ ★★★ ）

面向数据流的定义方法： 常用结构化规划设计方法，多在概要阶段使用。变换是把输入数据处理后转变成另外的输出数据；事务是非数据变换的处理，将输入数据流分散成许多数据流形成若干加工，再选择其中一个路径执行。变换型数据流三步：区分输入数据 / 变换中心 / 输出数据并划线、分析得到初始结构图、优化结构图；事务型数据流三步：确定事务中心 / 接收数据 / 处理路径、数据流图转初始结构图、分解细化接收分支和处理分支。

面向数据结构的定义方法： 根据数据结构规划设计程序处理过程，通常在详细设计阶段使用，包括 Jackson 方法和 Wanier 方法（ Wanier 仅考虑输入数据结构， Jackson 还考虑输出数据结构）； Jackson 把数据结构分为顺序型、选择型和循环型三种基本类型。

图形工具： 层次图（矩形框代表模块、连线表示调用关系，带编号的层次图称 HIPO 图）；结构图（箭头表示调用关系，带注释箭头表示传递信息，尾部空心圆表示传递数据、实心圆表示传递控制信息）。

接口定义通常包括：用户接口（向用户提供的命令和语法结构及回答信息）、外部接口（本系统同外界所有接口的安排，含软硬件接口、与各支持系统的接口）、内部接口（本系统内各系统元素之间的接口安排）。

指导用户界面定义的基本原则：置用户于控制之下、减少用户的记忆负担、保持界面一致。

界面定义应考虑 4 个问题：系统响应时间、用户求助机制、出错信息、命令方式。

数据库定义过程 5 步骤：需求分析（弄清数据种类范围数量，形成用户需求规约）、定义概念模型（分类聚集概括建立抽象概念数据模型）、定义逻辑模型（转成特定 DBMS 支持的逻辑数据模式）、定义物理数据库（选定物理存储结构、存取方法和存取路径）、验证（收集数据建立数据库、运行典型应用验证正确性合理性）。

构件定义典型任务：标识出所有与问题域对应的类、确定所有与基础设施域对应的类、细化所有不需要作为可复用构件的类、说明持久数据源并确定管理数据源所需要的类、开发并细化类或构件的行为表示、细化部署图以提供额外的实现细节、考虑每个构件级定义表示及其他可选方案。

从初步调研到系统设计，五步走每一步都有它要回答的问题。

在进行应用系统规划设计时，主要过程包括： 初步调研、可行性研究、详细调研、系统分析和系统设计 （速记：初行细分设）。

目标：掌握用户概况，对用户提出的各种问题和初始要求进行识别，明确新系统的初步目标，为可行性研究提供基础。内容：组织概况、组织环境、现行系统概况、各方面对新系统的态度、系统研制工作的资源情况。

结果三种情况：可行按计划进行、基本可行对项目要求或方案做必要修改、不可行不立项或终止项目。需从经济、技术、社会、管理四个方面进行综合分析论证（速记：经济社可行）。

可行性研究 8 个步骤： ① 复查系统目标和规模； ② 研究目前正在使用的系统； ③ 导出新系统的高层逻辑模型； ④ 重新定义问题； ⑤ 导出和评价供选择的方案； ⑥ 推荐一个方案并说明理由； ⑦ 草拟开发计划； ⑧ 书写文档并提交审查。

经济可行性： 也叫投资 / 效益分析或成本 / 效益分析，总成本包括建设成本和运行成本，总效益包括直接经济效益和间接社会效益；当总收益大于总成本时项目才值得建设；不能忽视间接社会效益。

技术可行性： 分析特定条件下技术资源的可用性和解决应用系统问题的可能性与现实性；要注意全面考虑技术问题、采用成熟技术、慎重引入先进技术（很多处于实验室阶段）、结合开发环境和人员（技术总体可行但开发队伍无人掌握则不可行）。

社会可行性： 从政策、法律、道德、制度、管理、人员等社会因素论证，还需考虑操作可行性（业务流程对比、业务专业化程度、用户使用要求、界面友好与操作方便性、用户实际能力）。

管理可行性： 从组织管理上分析，包括组织领导、部门主管是否支持，管理人员态度和配合情况，管理基础工作如何，新系统带来的工作变动量及管理人员能否接受。

可行性研究报告： 书写要求含首页、正文、附件、日期；主要内容含建设任务的提出、系统的目标、初步调研概况、初步实施方案与比较、可行性研究、结论。可行性论证会：同意或基本同意报告结论则执行 / 修改目标 / 追加资源或取消项目；对报告持不同意见，若不影响整体结论可留待详细调研解决，若影响则重新调查分析。

目标：完整掌握现行系统（包括手动业务和已采用计算机的应用系统）的现状，查明执行过程，发现问题和薄弱环节，收集资料和数据，为系统分析和提出新系统逻辑设计做准备。

详细调研范围： 组织和功能业务、组织目标和发展战略、工艺流程和产品构成、数据和数据流、业务流程和工作形式、管理方式和具体业务的管理方法、决策方式和决策过程、可用资源和限制条件、现存问题和改进意见。

详细调研原则： 自顶向下全面展开、用户参与、分析系统有无改进可能性、工程化的工作方式、全面与重点相结合、主动沟通和友善的工作方式。

详细调研方法： 收集资料、发调研表征求意见（重点询问 / 全面问卷）、开调研会（职能部门座谈 / 各类人员联合座谈）、访问（会后个别访问）、深入实际的调研方式（参加业务实践）。

任务：系统分析师与用户一起充分了解用户要求，用系统说明书表达双方理解；回答新系统 " 做什么 " 这个关键问题。系统说明书是用户与系统研发人员之间的技术合同，应严谨准确、无二义性、尽可能详尽。

系统分析过程划分为三阶段： 问题分析 （系统分析起点，明确建设背景、解决问题、利益相关方、目标范围、成功标准，详细调查分析业务流程）、 需求分析 （功能性需求和非功能性需求；常用方法：面向过程的结构化方法、面向数据的信息工程方法、基于 UML 的用例驱动方法、基于敏捷过程的用户故事）、 需求定义 （整理建立最终需求模型、详细定义每项需求、确认约束、编写需求规格说明）。

需求引导方法：原型法（快速构建原型供用户修改）、 JAD 会议（集中相关方头脑风暴）、观摩法（参观同类成功系统）。

系统说明书特征： 正确性、完整性、一致性、无二义性、可修改性、可跟踪性；内容包括引言、概述、实施计划。

系统设计又称物理设计，解决系统 " 如何做 " 的问题，从系统逻辑模型（概念模型）出发，结合实际经济、技术条件及时间要求，设计新系统解决方案。一般分为总体设计（初步设计 / 概要设计，完成总体结构和基本框架设计）和详细设计（将设计方案进一步具体化、条理化和规范化）两个阶段。

系统设计目标实现程度衡量指标： 可靠性（抵御外界干扰及受干扰时的恢复能力）、可变更性（可维护性或可修改性）、效率（响应时间或单位时间处理业务量）、通用性（同一软件系统在不同使用单位的可应用程度）、工作质量（数据处理准确性、输出信息易懂性、操作方便性）。

系统设计原则： 系统性、灵活性、可靠性、经济性、管理可接受原则。

系统设计内容： 总体结构设计、处理流程设计、代码设计、人机界面设计、输出设计、输入设计、数据库设计、安全保密设计、系统物理配置方案设计、编写系统设计说明书（速记：总处代人入出库配保密书）。

典型习题： 信息系统可行性研究的步骤顺序，正确的是？ 答案：复查系统目标和规模 → 研究目前正在使用的系统 → 导出新系统的高层逻辑模型 → 重新定义问题 → 导出和评价供选择的方案 → 推荐一个方案并说明理由 → 草拟开发计划 → 书写文档并提交审查。 （先导出逻辑模型再重新定义问题，不可颠倒）

四、常用方法： APA 、 TOGAF 、 SOA

1. 应用系统组合法（ APA ）（ ★★ ）

APA 的主要目标是帮助组织管理其应用系统组合，确保应用系统与组织业务目标和战略一致，同时降低维护成本和风险；可以帮助组织识别重复、冗余或过时的应用系统，并提供决策支持。总结归纳： APA 就像是给企业的应用系统做 " 体检 " 和 " 健康管理 " 。

APA 过程 6 个步骤： ① 应用系统清单（收集整理系统名称、功能描述、技术平台、使用情况等）； ② 评估应用系统（业务价值、技术健康状况、维护成本、风险等）； ③ 分析应用系统组合（分类分析，识别重复冗余或过时系统，找出问题和瓶颈）； ④ 制定优化策略（根据分析结果制定策略和计划）； ⑤ 实施优化计划（根据策略实施，如整合、替换、保留）； ⑥ 监测和评估（确保优化效果，根据需要进行调整和改进）。

2. TOGAF （ ★★ ）

TOGAF 是一种开放式企业架构框架标准，基于迭代的过程模型，由最佳实践和一套可复用的现有架构资产支持，用于设计、评估并建立适合的企业 IT 架构。优点：让所有用户使用相同语言、避免被锁定到专有解决方案、节省时间和金钱、实现可观的投资回报（ ROI ）。

TOGAF 六个组成部分： 架构开发方法（ ADM ，核心）、 ADM 指南和技术、内容框架、企业连续体和工具、 TOGAF 参考模型、架构能力框架。

架构开发方法（ ADM ）： 对开发企业架构所需执行的各个步骤及关系进行详细定义，是 TOGAF 规范中最核心的内容。全生命周期模型包括：预备阶段、阶段 A 架构愿景、阶段 B 业务架构、阶段 C 信息系统架构（应用和数据）、阶段 D 技术架构、阶段 E 机会和解决方案、阶段 F 迁移规划、阶段 G 实施治理、阶段 H 架构变更治理，以及贯穿始终的需求管理（速记：预备一中心八步一方法）。 ADM 形成三个级别的迭代概念：基于架构开发整体的迭代、多个开发阶段间的迭代、一个阶段内部的迭代。

3. 面向服务的架构（ SOA ）（ ★★ ）

广义 SOA 是一种新的组织应用架构和组织 IT 基础架构，使组织实现跨应用、跨部门、跨组织甚至跨行业之间的离散系统互连；狭义 SOA 是一种软件架构，根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是 SOA 的基础。

设计原则： 明确的接口定义、自包含与模块化、粗粒度、松耦合、互操作性兼容性和策略声明。

主要技术内容： 服务封装、服务注册与发现、服务治理（ SOA 核心内容之一）、服务安全、服务可靠性和可用性。

应用场景： 组织级应用集成、业务流程管理、系统扩展和重用、云计算和微服务架构、跨平台集成。

典型习题： 某电商系统将支付功能设计为独立服务，无需了解用户服务和订单服务的内部实现细节，只通过标准接口交互；当订单服务从关系型数据库迁移到 NoSQL 时支付服务无需修改。最能体现 SOA 的设计原则？ 答案： D （松耦合）。 松耦合强调减少各服务间相互依赖和影响，使各服务实现技术、内部状态和私有数据对请求者不可见。

软件工厂核心思想是将软件开发视为工业化的生产过程，类似传统制造业生产线；强调规模化和标准化，通过制定统一开发流程、规范编码标准和代码复用，实现高度可重复性和一致性。

软件工厂的构成： 专业人员（核心资源）、基础设施和硬件（运行基石）、工具和技术（辅助工具和支持系统）、流程规范和方法论（运作指南）、质量管理（保证交付质量的一套保证机制）（速记：人工硬留滞）。

2. 与传统开发对比（ ★★ ）

敏捷交付： 敏捷开发方法、用户需求和产品回溯日志、迭代开发、自动化测试、持续集成和持续交付（ CI/CD ）、产品质量和用户反馈、团队协作和沟通、可视化和透明度。

流水线作业： 环节划分（将开发过程划分为多个环节，各环节有明确输入输出，如需求分析 → 设计 → 编码 → 测试 → 发布）、任务定义、流转规则、并行处理、自动化支持、监控和优化。

协同开发： 团队协作和沟通（日常站会、迭代评审会、冲刺回顾会）、共享知识和经验（文档和知识库、代码审查、技术分享会）、协同工具和平台（即时通信、在线文档协作、代码托管和协作平台、数字协同平台）。

组织建设： 确定组织结构、制定明确的岗位和职责、设计有效的流程和规范、优化沟通渠道和协作工具、培养领导力和团队文化、定期评估和改进。

资源部署： 项目规划和优先级、人员分配和技能匹配、工作量估计和调整、工具和设备支持、项目管理和协调、优先级和变更管理。

业务管理： 由项目管理模块、资源管理模块、质量管理模块、绩效管理模块、沟通与协作模块、数据分析与报告模块构成；实现步骤为确定需求和目标、选取合适的软件解决方案、进行系统定制和开发、进行系统测试和验证、系统部署和培训、监控和维护。

体系保障： 建立质量管理体系（质量策略、质量目标、质量标准及质量管理流程和程序）、制定和实施流程规范、建立完善的文档和记录体系（记录和追溯关键信息）。

软件开发组织： 建立规范化开发流程和标准化开发规范、用版本控制系统管理源代码和配置文件、建立自动化构建和测试环境、模块化设计和开发、自动化部署和配置管理、引入持续集成和持续交付理念、利用适合的嵌入式软件工具和框架。

软件项目交付： 发布管理、安全性检查、事件响应计划；软件发布后运营阶段含安全监控、安全运营、风险评估、应急响应、升级与变更管理、服务与技术支持、运营反馈。

典型习题： 关于软件开发流水线作业的关键要素，下列说法错误的是？ 答案： D 。 （自动化支持的目的是辅助开发过程，提供自动化工具和流程支持，而不是完全取代人工监控和决策；人工监控和决策仍然是必要的）

写在最后：这一章，这样记才不会乱

应用系统规划一章的知识点看起来多而散，其实有一条清晰的记忆主线： 先懂 9 个概念（底层逻辑），再会选架构（分层 / 数据 / 客户机服务器 / 组件分布），然后按五步走流程走一遍（初行细分设），关键时刻能选对生命周期模型、会用三种常用方法，最后理解软件工厂怎么把开发 " 工业化 " 。 把这条主线串起来，概念、模型、方法、过程就不再是一堆孤立的考点，而是能互相呼应的完整知识体系。