第 5 章　信息系统工程

一、考情分析

二、学习目标

三、知识总览：四大板块

信息系统工程建设围绕"软件、数据、集成、安全"四条战线展开，四者关系是：软件工程负责把需求变成可运行的软件产品；数据工程负责让数据被规范地组织、维护与开发利用；系统集成负责把分散的软硬件、网络与数据整合为统一的系统；安全工程则贯穿前三者，保证系统建设满足信息安全要求。四大板块的二级知识结构如下表，学习时应以此为总地图：

四、软件工程

4.1 架构设计：架构风格与分层

软件架构是系统的高层结构设计成果，描述系统的组成构件、构件间的连接方式及其约束。架构设计的核心方法论是架构风格——为特定场景反复验证过的、可复用的架构模式。经典分类将架构风格分为五大类，每类各有代表风格：

分层架构是实际工程中最常用的架构形态（属于调用 / 返回风格中的层次结构）：系统自上而下通常划分为展示层、业务逻辑层、数据访问层与数据库层。分层架构的本质是关注点分离——每层只负责一类职责，层与层之间通过明确定义的接口交互，从而降低耦合、提升可维护性与可复用性；其代价是调用链变长带来的性能开销，层次过多时反而臃肿。

4.2 需求分析：层次、获取与定义

软件需求是系统必须满足的条件与能力。教材将需求划分为三个层次，必须能准确区分：

• 业务需求：反映组织机构或客户对系统高层次的目标要求，回答"为什么要建这个系统"，由最高管理层视角提出。
• 用户需求：描述用户使用系统必须要完成的任务，通常由用户用自己的语言表述。
• 系统需求：从系统角度说明软件的需求，包括功能需求、非功能需求（质量属性）与设计约束，是开发的直接依据。

需求工程活动按「需求获取 → 需求分析 → 需求定义（形成软件需求规格说明书 Software Requirements Specification, SRS）→ 需求验证（评审与需求测试）」展开。需求获取的常用方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划（Joint Requirements Planning, JRP）等，多种方法通常组合使用：访谈深入但成本高，问卷覆盖面广但难以深入，情节串联板（Storyboard）通过场景图帮助用户直观确认交互过程。

4.3 软件设计：结构化设计与面向对象设计

结构化设计以数据流图为基础，将数据流映射为模块结构。映射前先判断数据流类型：变换流——信息沿输入路径进入系统，经内部加工变换后沿输出路径流出，采用变换分析方法设计；事务流——信息根据输入值选择多条加工路径中的一条执行，采用事务分析方法设计。模块设计的黄金准则是高内聚、低耦合：内聚衡量模块内部元素的关联程度，越强越好；耦合衡量模块之间的依赖程度，越弱越好。两者共同决定模块独立性。

面向对象设计以类与对象为基本构件，核心概念是封装、继承与多态：封装把数据与操作捆绑并隐藏内部实现，继承支持类之间复用属性与行为，多态使同一消息在不同对象上产生不同响应。与结构化设计相比，面向对象设计更贴近人对现实业务的认知方式，在需求易变、系统规模大的场景下更具优势；结构化设计则适合数据处理边界清晰、逻辑稳定的系统。两种方法不是新旧淘汰关系，而是适用场景不同的两条技术路线。

4.4 软件实现：编码规范与软件测试

软件实现阶段将设计转化为代码，编码应遵循编码规范以保证可读性与可维护性，并在编码过程中配合单元测试。本节的重头戏是软件测试，可从三个维度建立坐标系：

• 按是否运行程序：静态测试与动态测试。静态测试不运行程序，对文档与代码进行检查，代表方法是桌前检查、代码走查、代码审查；动态测试运行被测程序，通常所说的白盒、黑盒测试都属于动态测试。
• 白盒测试（结构测试）：依据程序内部逻辑结构设计用例，代表方法是逻辑覆盖，覆盖强度由弱到强为：语句覆盖、判定覆盖、条件覆盖、判定 / 条件覆盖、条件组合覆盖，另有独立于强度的路径覆盖（基本路径测试）。语句覆盖是最弱的覆盖标准。
• 黑盒测试（功能测试）：依据软件的功能说明设计用例，不关心内部结构，代表方法是等价类划分、边界值分析、错误推测法、因果图。

按测试阶段划分，软件测试自内而外依次为：单元测试 → 集成测试 → 确认测试 → 系统测试 → 验收测试：

4.5 部署交付与过程管理

部署交付是把通过测试的软件安装到目标环境并移交给用户的活动：部署前要准备生产环境并完成部署方案，部署时要将软件、数据与环境配置到位，部署后要经过验证再正式切换运行；交付还包括对用户的培训、操作手册等文档的移交以及按验收准则组织的验收。系统上线切换的方式与第 4 章一致：直接切换、并行切换、分段切换，按业务风险容忍度选择。

过程管理关注"用什么过程来开发软件"。教材重点介绍三条主线：

• 敏捷方法：以人为核心、迭代增量地应对变化。典型代表 Scrum 设三类角色——产品负责人（Product Owner，负责管理与排序产品待办列表）、Scrum 主管（Scrum Master，负责推动 Scrum 正确实施、排除障碍）、开发团队（Team）；以固定时长的冲刺（Sprint）迭代交付可用增量。
• DevOps：开发（Development）与运维（Operations）的融合，通过自动化流水线实现持续集成（Continuous Integration, CI）、持续交付（Continuous Delivery, CD），并强调开发、测试、运维的跨职能协作文化，缩短从代码提交到上线的周期。DevOps 不是某个工具，而是"文化 + 流程 + 工具自动化"的综合实践。
• 软件过程改进：参照能力成熟度模型（CMM / CMMI）评估与改进组织的过程能力，成熟度由低到高分五个等级，从无序的初始状态逐步走向制度化、量化与持续优化。

五、数据工程

5.1 数据建模

数据建模按抽象程度分为三个层次，考试常考"某工具对应哪个层次"：

三层次自上而下逐步细化：先画 E-R 图与业务达成共识，再转换为关系模式，最后落地为具体数据库的物理设计。

5.2 数据标准化与数据运维

数据标准化解决"同数不同名、同名不同义"的问题，核心内容是对数据分类与编码、数据元及元数据（描述数据的数据）建立统一标准，使各方对数据的定义、格式与口径达成一致。数据标准是数据质量的前提——口径不统一，报表打架、统计失真随之而来。

数据运维保障数据在生存周期内安全、可用、可控，典型活动包括数据备份与恢复、数据归档与清理等。备份策略通常分为完全备份、增量备份、差分备份：完全备份最全但最耗资源；增量备份只备份上次备份以来变化的数据，速度最快但恢复时链条最长；差分备份备份自上次完全备份以来的全部变化，恢复复杂度居中。恢复演练是备份管理中最容易被忽视、也最能暴露问题的一环——没验证过恢复的备份等于没有备份。

5.3 数据开发利用

数据的价值在于用。数据开发利用通过数据仓库、数据挖掘、数据可视化与数据服务等手段，把数据转化为决策支持与业务创新：数据仓库面向主题、集成历史数据用于分析；数据挖掘从海量数据中发现规律与模式；数据可视化让分析结果可感知；数据服务则把数据能力以接口化方式开放给业务系统。数据开发利用与第 4 章 DCMM 的「数据应用」能力域直接呼应——数据管理是基础，开发利用是价值出口。

5.4 数据库安全

数据库安全是数据安全的最后一道技术防线，常用安全机制包括：用户标识与鉴别（验证"你是谁"）、存取控制（授权决定"你能干什么"，分为自主存取控制与强制存取控制）、视图机制（为不同权限的用户提供不同的数据视图，对无权用户屏蔽敏感数据）、审计（记录访问行为以备追责）、数据加密（存储与传输加密防止窃取后裸读）。这些机制与信息安全三要素的配对关系是：加密主要保保密性，完整性约束与事务机制保完整性，备份与容灾保可用性。

六、系统集成

6.1 集成基础与网络集成

集成基础：系统集成是根据用户需求，将计算机软件、硬件、网络通信、数据等分散的资源与技术和产品，合理地选择、组合与整合，形成一体化系统的过程。其要义有三：以满足用户需求为根本出发点、以整体性能最优而非单项技术最优为目标、交付的是完整的解决方案而非零散产品。

网络集成是系统集成的基础层：包括网络需求分析与方案设计、网络设备选型、结构化综合布线与网络管理等。结构化综合布线通常划分为工作区、水平布线、垂直干线、管理间、设备间、建筑群等子系统，将楼宇内的网络、语音等弱电布线统一规划、标准施工，做到一次布线、长期复用。

6.2 数据集成与软件集成

数据集成旨在打破"信息孤岛"，让分散在各系统中的数据互联互通，常用手段包括数据抽取—转换—加载（Extract-Transform-Load, ETL）、建立数据仓库 / 数据集市汇聚分析数据、通过数据复制同步保持多库一致等。数据集成通常伴随数据标准化工作，否则"集成了但口径不一致"，反而制造新的混乱。

软件集成（企业应用集成）按集成深度由浅入深分为四个层次，这是本章高频考点：

6.3 应用集成

应用集成关注如何让异构应用互联互通、协同工作，技术路径以面向服务的架构（Service-Oriented Architecture, SOA）为代表：把应用能力封装为标准化的服务，通过服务接口松耦合地组合业务；Web 服务、企业服务总线（Enterprise Service Bus, ESB）、消息中间件等是典型支撑技术；随着云原生发展，微服务与 API 网关成为新一代应用集成的主流形态。应用集成与软件集成四层次的关系可以理解为：软件集成给出了"集成到多深"的层次模型，应用集成给出了"用什么架构实现深层次集成"的技术方案。

七、安全工程

7.1 工程概述与安全系统

信息安全工程是用系统工程的思想和工程化的方法，建设满足安全需求的信息安全系统的过程。它与软件工程的根本区别在于视角：软件工程关注"功能如何建成"，安全工程关注"在建设过程中如何把安全属性构建进去"，要求安全与信息系统同步规划、同步建设、同步使用，而不是系统建成后再"打补丁"。

安全系统（信息安全系统）是一个技术与管理并重的体系：技术上覆盖物理环境、网络、主机、应用、数据等层面的防护；管理上包括安全策略、组织与职责、制度流程与人员安全等。系统的安全属性以第 4 章的三要素为核心——保密性、完整性、可用性，所有安全机制最终都服务于这三者。脱离管理谈技术，再强的设备堆叠也不构成安全系统，这是安全工程反复强调的基本观念。

7.2 工程基础

安全工程的实施依托信息系统安全工程（Information System Security Engineering, ISSE）方法，其过程与系统工程阶段对应：先从业务与威胁分析中发掘信息保护需求，再将需求转化为系统的安全功能定义，进而完成安全结构与机制设计，经过工程实施后对安全有效性进行验证。这一"需求 → 功能 → 设计 → 实施 → 验证"的推进逻辑，与第 4 章等级保护"定级、备案、建设整改、等级测评、监督检查"的工作环节在思想上同源：前者是工程视角的安全建设方法，后者是制度视角的合规要求，两者在真实项目中互相配合。

7.3 工程体系架构：一个中心、三重防护

等级保护 2.0 的技术体系架构概括为「一个中心、三重防护」，这是本章必须原文级记忆的结论：

三重防护由外而内构成纵深防御：网络是通道、边界是关口、计算环境是内核，管理中心居中统一指挥。加上安全物理环境的要求，共同构成等保 2.0 基本要求中的技术要求类别。此外，等保 2.0 在通用要求之外，针对云计算、移动互联、物联网、工业控制系统等新应用场景提出了扩展要求，实现"新老场景全覆盖"。

八、典型案例分析

九、考点速记卡