五、信息系统工程

五、信息系统工程

内容来源：信息系统项目管理师教程 (第4版）
文章内容主要为第4版教程的核心重点内容。

5.1 软件工程

5.1.1 架构设计

1. 软件架构风格

• 软件架构设计的一个核心问题是能否达到架构级的软件复用
• Garlan和Shaw对通用软件架构风格进行了分类，他们将软件架构分为：①数据流风格。数 据流风格包括批处理序列和管道/过滤器两种风格。②调用/返回风格。调用/返回风格包括主 程序/子程序、数据抽象和面向对象，以及层次结构。③独立构件风格。独立构件风格包括进 程通信和事件驱动的系统。④虚拟机风格。虚拟机风格包括解释器和基于规则的系统。⑤仓库风格。仓库风格包括数据库系统、黑板系统和超文本系统。

2. 软件架构评估

• 在架构评估过程中，评估人员所关注的是系统的质量属性。
• 从目前已有的软件架构评估技术来看，可以归纳为三类主要的评估方式，分别是基于调查 问卷(或检查表)的方式、基于场景的方式和基于度量的方式。这三种评估方式中，基于场景 的评估方式最为常用。

5.1.2 需求分析

• 软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系 统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条 件或能力的文档说明。

1. 需求的层次

• 需求是多层次的，包括业 务需求、用户需求和系统需求
• 质量功能部署(Quality Function Deployment,QFD)是一种将用户要求转化成软件需求的 技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软 件需求分为三类，分别是常规需求、期望需求和意外需求。

2. 需求过程

• 需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等。

1） 需求获取

需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。

2） 需求分析

• 一个好的需求应该具有无二 义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要 分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
• 需求分析对已经获取到的需求进行提炼、分析和审查，以确保所有的项目干系人都明白其 含义并找出其中的错误、遗漏或其他不足的地方。
• 使用结构化分析(Structured Analysis,SA)方法进行需求分析，其建立的模型的核心是数 据字典。围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型(也称为 状态模型)。在实际工作中，一般使用实体关系图(E-R图)表示数据模型，用数据流图(Data Flow Diagram,DFD)表示功能模型，用状态转换图(State Transform Diagram,STD)表示行 为模型。E-R图主要描述实体、属性，以及实体之间的关系；DFD从数据传递和加工的角度， 利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明 系统所完成的功能；STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为， 指出作为特定事件的结果将执行哪些动作(例如，处理数据等)。

3） 需求规格说明书编制

软件需求规格说明书(Software Requirement Specification,SRS)是需求开发活动的产物， 编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为 整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件 项目都不应该缺少。

4） 需求验证与确认

在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。

3. UML

2） UML中的关系

UML用关系把事物结合在一起，主要有四种关系，分别为：

• 依赖(Dependency):依赖是两个事物之间的语义关系，其中一个事物发生变化会影响 另一个事物的语义。
• 关联(Association):关联描述一组对象之间连接的结构关系。
• 泛化(Generalization):泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一 般元素的对象。
• 实现(Realization):实现是类之间的语义关系，其中的一个类指定了由另一个类保证 执行的契约。

3） UML2.0中的图

UML2.0包括14种图，如表5-3所示。

​

4） UML视图

包括5个系统视图：

• 逻辑视图：逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的 部分，即类、子系统、包和用例实现的子集。
• 进程视图：进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行 实例，描述了并发与同步结构。
• 实现视图：实现视图对组成基于系统的物理代码的文件和构件进行建模。
• 部署视图：部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布 结构。
• 用例视图：用例视图是最基本的需求分析模型。

4. 面向对象分析

1） 用例模型

在OOA方法中，构 建用例模型一般需要经历四个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和 调整用例模型，如表5-4所示。其中前三个阶段是必须的。

​

2） 分析模型

​

​

5.1.3 软件设计

1. 结构化设计

• 结构化设计(Structured Design,SD)是一种面向数据流的方法，它以SRS和SA阶段所产 生的DFD和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。SD方法的 基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细 设计两个阶段，其中概要设计又称为总体结构设计
• 在SD中，需要遵循一个基本的原则：高内聚，低耦合。

2. 面向对象设计

• 面向对象设计(OOD)是OOA方法的延续，其基本思想包括抽象、封装和可扩展性，其 中可扩展性主要通过继承和多态来实现

• 常用的OOD原则包括：

  • 单职原则：设计功能单一的类。本原则与结构化方法的高内聚原则是一致的。
  • 开闭原则：对扩展开放，对修改封闭。
  • 李氏替换原则：子类可以替换父类。
  • 依赖倒置原则：要依赖于抽象，而不是具体实现；要针对接口编程，不要针对实现 编程。
  • 接口隔离原则：使用多个专门的接口比使用单一的总接口要好。
  • 组合重用原则：要尽量使用组合，而不是继承关系达到重用目的。
  • 迪米特原则(最少知识法则):一个对象应当对其他对象有尽可能少的了解。本原则与 结构化方法的低耦合原则是一致的。

3. 设计模式

根据目的和用途不同，设计模式可分为创建型 (Creational)模式、结构型(Structural)模式和行为型(Behavioral)模式三种：①创建型模式 主要用于创建对象，包括工厂方法模式、抽象工厂模式、原型模式、单例模式和建造者模式等； ②结构型模式主要用于处理类或对象的组合，包括适配器模式、桥接模式、组合模式、装饰模 式、外观模式、享元模式和代理模式等；③行为型模式主要用于描述类或对象的交互以及职责 的分配，包括职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式等。

5.1.4 软件实现

1. 软件配置管理

软件配置管理活动包括软件配置管理计划、软件配置标识、软件配置控制、软件配置状态 记录、软件配置审计、软件发布管理与交付等活动。

2. 软件编码

所谓编码就是把 软件设计的结果翻译成计算机可以“理解和识别”的形式——用某种程序设计语言书写的程序。 作为软件工程的一个步骤，编码是设计的自然结果，因此，程序的质量主要取决于软件设计的 质量。但是，程序设计语言的特性和编码途径也会对程序的可靠性、可读性、可测试性和可维 护性产生深远的影响。

3. 软件测试

• 软件测试的目的是验证软件是否满足软件开发合同或项目开发 计划、系统/子系统设计文档、SRS、软件设计说明和软件产品说明等规定的软件质量要求。通 过测试发现软件缺陷，为软件产品的质量测量和评价提供依据。
• 软件测试方法可分为静态测试和动态测试。①静态测试是指被测试程序不在机器上运行， 而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态测试包括对文档的静态测 试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对代码的静态测试一 般采用桌前检查(Desk Checking)、代码走查和代码审查。经验表明，使用这种方法能够有效 地发现30??70??逻辑设计和编码错误。②动态测试是指在计算机上实际运行程序进行软件 测试，一般采用白盒测试和黑盒测试方法。白盒测试也称为结构测试，主要用于软件单元测试 中。它的主要思想是，将程序看作是一个透明的白盒，测试人员完全清楚程序的结构和处理算 法，按照程序内部逻辑结构设计测试用例，检测程序中的主要执行通路是否都能按预定要求正 确工作。白盒测试方法主要有控制流测试、数据流测试和程序变异测试等。另外，使用静态测 试的方法也可以实现白盒测试。例如，使用人工检查代码的方法来检查代码的逻辑问题，也属 于白盒测试的范畴。白盒测试方法中，最常用的技术是逻辑覆盖，即使用测试数据运行被测程序， 考查对程序逻辑的覆盖程度。主要的覆盖标准有语句覆盖、判定覆盖、条件覆盖、条件/判定 覆盖、条件组合覆盖、修正的条件/判定覆盖和路径覆盖等。黑盒测试也称为功能测试，主要 用于集成测试、确认测试和系统测试中。黑盒测试将程序看作是一个不透明的黑盒，完全不考 虑(或不了解)程序的内部结构和处理算法，而只检查程序功能是否能按照SRS的要求正常使 用，程序是否能适当地接收输入数据并产生正确的输出信息，程序运行过程中能否保持外部信 息(例如，文件和数据库等)的完整性等。黑盒测试根据SRS所规定的功能来设计测试用例， 一般包括等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法等。

5.1.5 部署交付

1. 软件部署与交付

软件部署与交付是软件生命周期中的一个重要环节，属于软件开发的后期活动，即通过 配置、安装和激活等活动来保障软件制品的后续运行。

2. 持续交付

持续交付是一系列开发实践方法， 用来确保让代码能够快速、安全地部署到生产环境中。持续交付是一个完全自动化的过程，当 业务开发完成的时候，可以做到一键部署。持续交付提供了一套更为完善的解决传统软件开发 流程的方案，主要体现在：

• 在需求阶段，抛弃了传统的需求文档的方式，使用便于开发人员理解的用户故事；
• 开发测试阶段，做到持续集成，让测试人员尽早进入项目开始测试；
• 在运维阶段，打通开发和运维之间的通路，保持开发环境和运维环境的统一。 持续交付具备的优势主要包括：
• 持续交付能够有效缩短提交代码到正式部署上线的时间，降低部署风险；
• 持续交付能够自动、快速地提供反馈，及时发现和修复缺陷；
• 持续交付让软件在整个生命周期内都处于可部署的状态；
• 持续交付能够简化部署步骤，使软件版本更加清晰；
• 持续交付能够让交付过程成为一种可靠的、可预期的、可视化的过程。

3. 持续部署

1） 持续部署方案

容器技术目前是部署中最流行的技术

2） 部署原则

3） 部署层次

完整的镜像部署包括三个环节：Build-Ship-Run

• uild:跟传统的编译类似，将软件编译形成RPM包或者Jar包：
• Ship:则是将所需的第三方依赖和第三方插件安装到环境中；
• Run:就是在不同的地方启动整套环境。

4） 不可变服务器

不可变服务器师一种部署方式，是指除了更新和安装补丁程序之外，不对服务器进行任何更改。

5） 蓝绿部署和金丝雀部署

在部署原则中提到两大部署方式为蓝绿部署和金丝雀部署。蓝绿部署是指在部署的时候准 备新旧两个部署版本，通过域名解析切换的方式将用户使用环境切换到新版本中，当出现问题 的时候，可以快速地将用户环境切回旧版本，并对新版本进行修复和调整。金丝雀部署是指当 有新版本发布的时候，先让少量用户使用新版本，并且观察新版本是否存在问题。如果出现问 题，就及时处理并重新发布；如果一切正常，就稳步地将新版本适配给所有的用户。

4. 部署与交付的新趋势

5.1.6 过程管理

1. 成熟度模型

​

CSMM模型由4个能力域、20个能力子域、161个能力要求组成：

• 治理：包括战略与治理、目标管理能力子域，用于确定组织的战略、产品的方向、组织 的业务目标，并确保目标的实现。
• 开发与交付：包括需求、设计、开发、测试、部署、服务、开源应用能力子域，这些能 力子域确保通过软件工程过程交付满足需求的软件，为顾客与利益干系人增加价值。
• 管理与支持：包括项目策划、项目监控、项目结项、质量保证、风险管理、配置管理、 供应商管理能力子域，这些能力子域覆盖了软件开发项目的全过程，以确保软件项目能 够按照既定的成本、进度和质量交付，能够满足顾客与利益干系人的要求。
• 组织管理：包括过程管理、人员能力管理、组织资源管理、过程能力管理能力子域，对 软件组织能力进行综合管理。

2. 成熟度等级

成熟度等级的总体特征如表5-6所示。

​

‍

5.2 数据工程

5.2.1 数据建模

1. 数据模型

数据模型应用目的不同，可以将数据模型划分为三类：概念模型、逻辑模型和物理模型。

1） 概念模型

概念模型也称信息模型，它是按用户的观点来对数据和信息建模，也就是说，把现实世界 中的客观对象抽象为某一种信息结构，这种信息结构不依赖于具体的计算机系统，也不对应某 个具体的DBMS,它是概念级别的模型。

2） 逻辑模型

逻辑模型是在概念模型的基础上确定模型的数据结构，目前主要的数据结构有层次模型、 网状模型、关系模型、面向对象模型和对象关系模型。其中，关系模型成为目前最重要的一种 逻辑数据模型。

3） 物理模型

物理数据模型是在逻辑数据模型的基础上，考虑各种具体的技术实现因素，进行数据库体 系结构设计，真正实现数据在数据库中的存放。物理数据模型的内容包括确定所有的表和列， 定义外键用于确定表之间的关系，基于性能的需求可能进行反规范化处理等内容。在物理实现 上的考虑，可能会导致物理数据模型和逻辑数据模型有较大的不同。物理数据模型的目标是如 何用数据库模式来实现逻辑数据模型，以及真正地保存数据。物理模型的基本元素包括表、字 段、视图、索引、存储过程、触发器等，其中表、字段和视图等元素与逻辑模型中基本元素有 一定的对应关系。

2. 数据建模过程

通常来说，数据建模过程包括数据需求分析、概念模型设计、逻辑模型设计和物理模型设计等过程。

(1) 数据需求分析。简单地说，数据需求分析就是分析用户对数据的需要和要求。

(2) 概念模型设计。将需求分析得到结果抽象为概念模型 的过程就是概念模型设计，其任务是确定实体和数据及其关联。

(3) 逻辑模型设计。逻辑模型设计的任务就是将概念模型中实 体、属性和关联转换为关系模型结构中的关系模式。

(4) 物理模型设计。物理模型考虑的主要问题包括命名、确定字段类型和 编写必要的存储过程与触发器等。

5.2.2 数据标准化

数据标准化是实现数据共享的基础。数据标准化主要为复杂的信息表达、分类和定位建立 相应的原则和规范，使其简单化、结构化和标准化，从而实现信息的可理解、可比较和可共享， 为信息在异构系统之间实现语义互操作提供基础支撑。数据标准化的主要内容包括元数据标准 化、数据元标准化、数据模式标准化、数据分类与编码标准化和数据标准化管理。

1. 元数据标准化

元数据最简单的定义是：元数据是关于数据的数据(Data About Data)。

2. 数据元标准化

1） 数据元

数据元是数据库、文件和数据交换的基本数据单元。

2） 数据元提取

数据元提取是数据元标准化的一项重要内容，为了确保数据元具有科学性和互操作性，需 要采用合理的数据元提取方法。目前常用的数据元提取方法有两种：自上而下(Top-Down)提 取法和自下而上(Down-Top)提取法。

3） 数据元标准

一般来说，制定一个数据元标准，应遵循若干个基本过程，如表5-10所示。

​

3. 数据模式标准化

• 数据模式是数据的概念、组成、结构和相互关系的总称。
• 在数据共享过程中，这种差异对人们进行信息的共享与交 换形成了障碍。为了保证能够顺畅进行信息的共享，对特定领域而言，需要一个统一的数据模 式作为数据共享与交换的基础。同时也保证该领域的相关人员对统一的数据模型有准确的、无歧义的理解。

4. 数据分类与编码标准化

所谓数据分类与编码标准化就是把数据分类与编码工作纳入标准化工作的领域，按标准化 的要求和工作程序，将各种数据按照科学的原则进行分类以编码，经有关方面协商一致，由主 管机构批准、注册，以标准的形式发布，作为共同遵守的准则和依据，并在其相应的级别范围 内宣贯和推行。

5. 数据标准化管理

• 数据标准化阶段的具体过程包括确定 数据需求、制定数据标准、批准数据标准和实施数据标准四个阶段。

(1) 确定数据需求。

(2) 制定数据标准。

(3) 批准数据标准。

(4) 实施数据标准。

5.2.3 数据运维管理

1. 数据存储

所谓数据存储就是根据不同的应用环境，通过采取合理、安全、有效的方式将数据保存到 物理介质上，并能保证对数据实施有效的访问。

2. 数据备份

• 数据备份是为了防止由于用户操作失误、系统故障等意外原因导致的数据丢失，而将整个 应用系统的数据或一部分关键数据复制到其他存储介质上的过程。这样做的目的是保证当应用 系统的数据不可用时，可以利用备份的数据进行恢复，尽量减少损失。
• 当前最常见的数据备份结构可以分为四种：DAS备份结构、基于LAN的备份结构、LANFREE备份结构和SERVER-FREE备份结构。常见的备份策略主要有三种：完全备份、差分备 份和增量备份。

3. 数据容灾

• 根据容灾系统保护对象的不同，容灾系统分为应 用容灾和数据容灾两类。应用容灾用于克服灾难对系统的影响，保证应用服务的完整、可靠和安全等一系列要求，使得用户在任何情况下都能得到正常的服务；数据容灾则关注于保证用户 数据的高可用性，在灾难发生时能够保证应用系统中的数据尽量少丢失或不丢失，使得应用系 统能不间断地运行或尽快地恢复正常运行。
• 数据备份是数据容灾的基础。数据备份是数据高可用的最后一道防线，其目的是为了在系 统数据崩溃时能够快速恢复数据。

4. 数据质量评价与控制

1） 数据质量描述

数据质量可以通过数据质量元素来描述，数据质量元素分为数据质量定量元素和数据质量 非定量元素。

2） 数据质量评价过程

3） 数据质量评价方法

数据质量评价程序是通过应用一个或多个数据质量评价方法来完成的。数据质量评价方法 分为直接评价法和间接评价法：

• 直接评价法：通过将数据与内部或外部的参照信息，如理论值等进行对比。确定数据 质量。
• 间接评价法：利用数据相关信息，如数据只对数据源、采集方法等的描述推断或评估数 据质量。

4） 数据质量控制

数据产品的质量控制分成前期控制和后期控制两个大部分。前期控制包括数据录入前的质 量控制、数据录入过程中的实时质量控制；后期控制为数据录入完成后的后处理质量控制与评 价。

5） 数据清洗

数据清理的三个步骤：

• 数据分析：是指从数据中发现控制数据的一般规则，比如字段域、业务规则等，通过对 数据的分析，定义出数据清理的规则，并选择合适的清理算法。
• 数据检测：是指根据预定义的清理规则及相关数据清理算法，检测数据是否正确，比如 是否满足字段域、业务规则等，或检测记录是否重复。
• 数据修正：是指手工或自动地修正检测到的错误数据或重复的记录。

5.2.4 数据开发利用

1. 数据集成

• 数据集成就是将驻留在不同数据源中的数据进行整合，向用户提供统一的数据视图(一般 称为全局模式),使得用户能以透明的方式访问数据。
• 数据集成的目标就是充分利用已有数据，在尽 量保持其自治性的前提下，维护数据源整体上的一 致性，提高数据共享利用效率。

2. 数据挖掘

数据挖掘是指从大量数据中提取或“挖掘”知 识，即从大量的、不完全的、有噪声的、模糊的、随机的实际数据中，提取隐含在其中的、人们不知道的、却是潜在有用的知识。

3. 数据服务

数据服务主要包括数据目录服务、数据查询与浏览及下载服务、数据分发服务。

(1) 数据目录服务。

(2) 数据查询与浏览及下载服务。

(3) 数据分发服务。

4. 数据可视化

数据可视化(Data Visualization)概念来自科学计算可视化。数据可视化(见图5-7)主要 运用计算机图形学和图像处理技术，将数据转换成为图形或图像在屏幕上显示出来，并能进行 交互处理，它涉及计算机图形学、图像处理、计算机辅助设计、计算机视觉及人机交互技术等 多个领域，是一门综合性的学科。

​

5. 信息检索

信息检索(Information Retrieval)有广义和狭义之分。广义的信息检索是指将信息按一定 的方式组织和存储起来，然后根据用户需求查找出特定信息的技术，所以全称是信息存储与检 索(Information Storage and Retrieval)。狭义的信息检索仅指用户查找特定信息这部分，即按照 用户的检索需求，利用已有的检索工具或数据库，从中找出特定信息的过程。

5.2.5 数据库安全

1. 数据库安全威胁

2. 数据库安全对策

3. 数据库安全机制

数据库安全机制是用于实现数据库的各种安全策略的功能集合，正是由这些安全机制来实 现安全模型，进而实现保护数据库系统安全的目标。数据库安全机制包括用户的身份认证、存 取控制、数据库加密、数据审计、推理控制等内容。

5.3 系统集成

5.3.1 集成基础

系统集成的内容包括技术环境的集成、数据环境的集成和应用程序的集成。

5.3.2 网络集成

(1) 传输子系统。传输是网络的核心，是网络信息的“公路”和“血管”。传输线路带宽的 高低不仅体现了网络的通信能力，也体现了网络的现代化水平。并且，传输介质在很大程度上 也决定了通信的质量，从而直接影响到网络协议。目前主要的传输介质分为无线传输介质和有 线传输介质两大类。常用的无线传输介质主要包括无线电波、微波、红外线等，常用的有线传 输介质主要包括双绞线、同轴电缆、光纤等。

(2) 交换子系统。网络按所覆盖的区域可分为局域网、城域网和广域网，由此网络交换也 可以分为局域网交换技术、城域网交换技术和广域网交换技术。

5.3.3 数据集成

1. 数据集成层次

• 数据集成可以分为基本数据集成、多级视图集成、模式集成 和多粒度数据集成四个层次。

(1)基本数据集成。

(2)多级视图集成。

(3)模式集成。

(4)多粒度数据集成。

2. 异构数据集成

数据集成的目的是为应用提供统一的访问支持，因此集成后的数据必须保证一定的完整性， 包括数据完整性和约束完整性。

5.3.4 软件集成

• 在这一背景下出现了有 代表性的软件构件标准：公共对象请求代理结构(Common Object Request Broker Architecture, CORBA)、COM、DCOM与COM+、.NET、J2EE应用架构等标准。

1. CORBA

OMG的目的则是为了将对象和分布式系统技术集成为一 个可相互操作的统一结构，此结构既支持现有的平台也将支持未来的平台集成

2. COM

COM技术要达到的基本目标是：即使对象是由不同的开发人员用不同的编程语言实现的， 在开发软件系统时，仍能够有效地利用已经存在于其他已有软件系统中的对象；同时，也要使 当前所开发的对象便于今后开发其他软件系统时进行重用。

3. DCOM 与 COM+

COM+为COM的新发展或COM更高层次上的应用，其底层结构仍然以COM为基础，几 乎包容了COM的所有内容。COM+倡导了一种新的概念，它把COM组件软件提升到应用层而 不再是底层的软件结构，通过操作系统的各种支持，使组件对象模型建立在应用层上，把所有 组件的底层细节留给操作系统。因此，COM+与操作系统的结合更加紧密。

4. .NET
5. J2EE

J2EE为搭建具有可伸缩性、灵活性、易维护性的组织系统提供了良好的机制。J2EE的体系结构可以分为客户端层、服务器端组件层、 EJB层和信息系统层。

5.3.5 应用集成(P169)

• 从信息系统集成技术的角度看，在集成的堆栈上，应用集成在 最上层，主要解决应用的互操作性的问题，如图5-10所示。

​

• 应用集成或组织应用集成(EAI)是指将独立的软件应用连接起来，实现协同工作。借助 应用集成，组织可以提高运营效率，实现工作流自动化，并增强不同部门和团队之间的协作。 对应用集成的技术要求大致有：

  • 具有应用间的互操作性：
  • 具有分布式环境中应用的可移植性：
  • 具有系统中应用分布的透明性：

• 可以帮助协调连接各种应用的组件有：

  • 应用编程接口(API):
  • 事件驱动型操作：
  • 数据映射：

5.4 安全工程

5.4.1 工程概述

信息安全系统工程就是要建造一个信息安全系统，它是整个信息系统工程的一部分，而且 最好是与业务应用信息系统工程同步进行

5.4.2 安全系统

​

(1) X轴是“安全机制”。安全机制可以理解为提供某些安全服务，利用各种安全技术和技 巧，所形成的一个较为完善的结构体系。如“平台安全”机制，实际上就是指安全操作系统、 安全数据库、应用开发运营的安全平台以及网络安全管理监控系统等。

(2) Y轴是“OSI网络参考模型”。信息安全系统的许多技术、技巧都是在网络的各个层面 上实施的，离开网络信息系统的安全也就失去意义。

(3) Z轴是“安全服务”。安全服务就是从网络中的各个层次提供给信息应用系统所需要的 安全服务支持。如对等实体认证服务、访问控制服务、数据保密服务等。

由X、Y、Z三个轴形成的信息安全系统三维空间就是信息系统的“安全空间”。随着网络 的逐层扩展，这个空间不仅范围逐步加大，安全的内涵也就更丰富，达到具有认证、权限、完 整、加密和不可否认五大要素，也叫作“安全空间”的五大属性。

1. 安全机制
2. 安全服务

安全服务包括对等实体认证服务、数据保密服务、数据完整性服务、数据源点认证服务、 禁止否认服务和犯罪证据提供服务等。

（1）对等实体认证服务。对等实体认证服务用于两个开放系统同等层中的实体建立链接或 数据传输时，对对方实体的合法性、真实性进行确认，以防假冒。

（2）数据保密服务。数据保密服务包括多种保密服务，为了防止网络中各系统之间的数据 被截获或被非法存取而泄密，提供密码加密保护。数据保密服务可提供链接方式和无链接方式 两种数据保密，同时也可对用户可选字段的数据进行保护。

（3）数据完整性服务。数据完整性服务用以防止非法实体对交换数据的修改、插入、删除 以及在数据交换过程中的数据丢失。

（4）数据源点认证服务。数据源点认证服务用于确保数据发自真正的源点，防止假冒。

（5）禁止否认服务。禁止否认服务用以防止发送方在发送数据后否认自己发送过此数据， 接收方在收到数据后否认自己收到过此数据或伪造接收数据，由两种服务组成：不得否认发送 和不得否认接收

（6）犯罪证据提供服务。指为违反国内外法律法规的行为或活动，提供各类数字证据、信 息线索等。

3. 安全技术

5.4.3 工程基础

5.4.4 工程体系架构

1. ISSE-CMM基础

• 信息安全系统工程能力成熟度模型(ISSE Capability Maturity Model,ISSE-CMM)是一种 衡量信息安全系统工程实施能力的方法
• ISSE-CMM主要适用于工程组织(Engineering Organizations)、获取组织(Acquiring Organizations)和评估组织(Evaluation Organizations)

2. ISSE过程

ISSE将信息安全系统工程实施过程分解为：工程过程(Engineering Process)、风险过程(Risk Process)和保证过程(Assurance Process)三个基本的部分

3. ISSE-CMM体系结构

​

‍

‍欢迎关注我的CSDN、个人博客、知乎