信息系统项目管理师教程（第4版）第五章_信息系统工程

该文件是信息系统项目管理教程《第4版第五章_信息系统工程》的自制思维导图。包含了软件工程、数据工程、系统集成、信息系统安全工程等内容。根据历年考点重点，标注了重要性，详细的整合了所有内容，可以让最后中复习以及开始学习事半功倍。花了十几个小时将全章节阅读进行整理归纳，全部都是最新版的内容。

信息系统工程

• 1. 软件工程
  • 基本概念
    • 定义
      • 指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程
    • 目的
      • 提高软件生产率、提高软件质量、降低软件成本
    • 组成
      • 方法
        • 技术手段
      • 工具
        • 智力和体力的扩展与延伸
      • 过程
        • 贯穿于软件开发的各个环节
  • 架构设计
    • 软件架构
      • 定义
        • 为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用（连接件）、指导构件集成的模式以及这些模式的约束组成
      • 研究目的
        • 解决好软件的复用、质量和维护问题
    • 核心问题
      • 能否达到架构级的软件复用，即能否在不同的系统中使用同一个软件架构
    • 软件架构风格
      • 定义
        • 软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式（Idiomatic Paradigm）。架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统
      • 分类
        • 1. 数据流风格
          • 包括批处理序列、管道/过滤器两种风格
        • 2. 调用 / 返回风格
          • 包括主程序/子程序、数据抽象、面向对象、层次结构
        • 3. 独立构件风格
          • 包括进程通信、事件驱动的系统
        • 考的比较多，重点掌握
        • 4. 虚拟机风格
          • 包括解释器、基于规则的系统
        • 5. 仓库风格
          • 包括数据库系统、黑板系统、超文本系统
    • 软件架构评估
      • 不重要， 随便看看
      • 基本概念
        • 敏感点（Sensitivity Point）
          • 敏感点是一个或多个构件（或之间的关系）的特性
        • 权衡点（Trade-off Point）
          • 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点
        • 敏感点决策只影响一个软件质量属性，而权衡点则同时影响多个质量属性，有时不同属性间还会互相冲突，比如选择不同的加密方式同时影响性能和安全性，所以需要权衡
      • 评估方式
        • 基于调查问卷（或检查表）的方式
        • 基于度量的方式
        • 基于场景的方式
          • 分类
            • 架构权衡分析法（ATAM）
              • Architecture Trade-ofAnalysis Method
            • 软件架构分析法（SAAM）
              • Software Architecture Analysis Method
            • 成本效益分析法（CBAM）
              • Cost BenefitAnalysis Method
          • 描述方面
            • 刺激（Stimulus）
              • 解释或描述项目干系人怎样引发与系统的交互部分
            • 环境（Environment）
              • 刺激发生时的情况
            • 响应（Response）
              • 系统是如何通过架构对刺激做出反应
          • 分析内容
            • 软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度。
              • 例如，用一系列对软件的修改来反映易修改性方面的需求，用一系列攻击性操作来代表安全性方面的需求等。
          • 特点
            • 不同的系统对同一质量属性的理解可能不同，由于存在这种不一致性，对一个领域适合的场景设计在另一个领域内未必合适，因此，基于场景的评估方式是特定于领域的。
              • 例如，对操作系统来说，可移植性被理解为系统可在不同的硬件平台上运行，而对于普通的应用系统而言，可移植性往往是指该系统可在不同的操作系统上运行。
  • 需求分析
    • 定义
      • 是指用户对新系统在功能、行为、性能、设计约束等方面的期望
    • 需求层次
      • 业务需求（企业或客户对系统高层次的要求）、用户需求、系统需求（包括：功能需求、非功能需求、约束条件）
        • 三个层次，从目标到具体，从整体到局部，从概念到细节
    • 质量功能部署 （Quality Funtion Deployment，QFD）
      • 是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度
      • 需求分类
        • 常规需求、期望需求、意外需求
    • 需求过程
      • 1. 需求获取
        • 定义
          • 是一个确定和理解不同的项目干系人的需求和约束的过程
        • 方式
          • 用户访谈、问卷调查、采样、情节串联板、联合需求计划等
      • 2. 需求分析
        • 目的
          • 把杂乱无章的用户要求和期望转化为用户需求
        • 好的需求应具备的特性
          • 无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等
        • 方式
          • 1. 结构化分析（SA） Structured Analysis
            • 采用功能分解的方式来描述系统功能，在这种表达方式中，系统功能被分解到各个功能模块中，通过描述细分的系统模块的功能来达到描述整个系统功能的目的
            • 模型
              • 核心
                • 数据字典
              • 根据层次划分
                • 1. 数据模型
                  • 实体关系图
                    • E-R 图
                    • 主要描述实体、属性，以及实体之间的关系，用于设计数据库
                • 2. 功能模型
                  • 数据流图
                    • Data flow Diagram，DFD
                    • 从数据传递和加工的角度利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能
                • 3. 行为模型 （状态模型）
                  • 状态转换图
                    • State Transform Diagram，STD
                    • 通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作（例如，处理数据等）
          • 2. 面向对象的分析（OOA） Obiect-Oriented Analysis
            • OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素，这也是OOA和OOD的区别之所在。OOA 的任务是“做什么”，OOD 的任务是“怎么做”
            • 基本任务
              • 运用面向对象的（Object-Oriented，OO）方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系
            • 模型
              • 用例模型
                • 一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模
              • 分析模型
                • 描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统行为（动态模型）
      • 3. 需求规格说明书（SRS） Software Requirement Specification
        • 需求分析阶段的可交付物
        • 定义
          • 是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础
        • 包括
          • 范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录
      • 4. 需求验证与确认
        • 方法
          • 需求评审
            • 对 SRS 进行技术评审
              • 技术评审不是评价技术，是对使用意图的适合性进行评价，评审需求的方式是否正确
          • 需求测试
        • 活动内容
          • SRS 正确地描述了预期的、满足项目千系人需求的系统行为和特征
          • SRS 中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的
          • 需求是完整的和高质量的
          • 需求的表示在所有地方都是一致的
          • 需求为继续进行系统设计、实现和测试提供了足够的基础
    • 统一建模语言（UML） Unified Modeling Language
      • 定义
        • 是一种定义良好、易于表达、功能强大且普遍适用的建模语言，支持从需求分析开始的软件开发的全过程，适用于迭代式开发过程
      • 结构
        • 1. 构造块
          • 事物 （Thing）
            • 结构事物 Structural Things
              • 定义
                • 在模型中属于最静态的部分，代表概念上或物理上的元素
              • 包括
                • 类、接口、协作、用例、活动类、构件和节点
            • 行为事物 / 动作事物 Behavioral Things
              • 定义
                • 模型中的动态部分，代表时间和空间上的动作
              • 行为分类
                • 交互 （内部活动）
                  • 由一组对象之间在特定上下文中，为达到特定目的而进行的一系列消息交换而组成的动作。
                • 状态机
                  • 由一系列对象的状态组成
            • 分组事物 Grouping Things
              • 定义
                • 模型中组织的部分，可以把它们看成是个盒子，模型可以在其中进行分解。UML 只有一种分组事物，称为包，包是一种将有组织的元素分组的机制
            • 注释事物 / 注解事物 AnnotationalThings
              • 定义
                • 模型的解释部分
          • 关系（Relationship）
            • 面向对象分析中有具体解释
            • 依赖（Dependency）、关联（Association）、泛化（Generalization）、实现（Realization）
          • 图（Diagram）
            • 14种图
              • 1. 类图 Class Diagram
                • 描述一组类、接口、协作和它们之间的关系
              • 2. 对象图 Object Diagram
                • 描述一组对象及它们之间的关系
              • 3. 构件图 Component Diagram
                • 描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构
              • 4. 包图 Package Diagram
                • 描述由模型本身分解而成的组织单元，以及它们之间的依赖关系
              • 5. 组合结构图 Composite Structure Diagram
                • 描述结构化类（例如，构件或类）的内部结构，包括结构化类与系统其余部分的交互点
              • 6. 用例图 Use Case Diagram
                • 用例图描述一组用例、参与者及它们之间的关系
              • 7. 顺序图 / 序列图 Sequence Diagram
                • 由一组对象或参与者以及它们之间可能发送的消息构成
                • 强调消息的时间次序
                • 对象由左向右排列
                  • 执行者 → 控制类 → 用户接口 → 业务层 → 后台数据库
              • 8. 通信图 Communication Diagram
                • 和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构（关系）
                • 强调收发消息的对象或参与者的结构组织
              • 9. 定时图 / 计时图 Timing Diagram
                • 强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序
              • 10. 交互概览图 Interaction Overview Diagram
                • 活动图和顺序图的混合物
              • 交互图，描述用户与系统之间的交互过程
              • 11. 状态图 State Diagram
                • 描述一个状态机，它由状态、转移、事件和活动组成
              • 12. 活动图 Activity Diagram
                • 将进程或其他计算结构展示为计算内部一步步的控制流和数据流
              • 13. 部署图 Deployment Diagram
                • 描述对运行时的处理节点及在其中生存的构件的配置
              • 14. 制品图 Artifact Diagram
                • 描述计算机中一个系统的物理结构
            • 系统视图
              • 1. 逻辑视图（设计视图）
                • 表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集
              • 2. 进程视图（过程视图）
                • 是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构
              • 3. 实现视图（构件视图）
                • 对组成基于系统的物理代码的文件和构件进行建模
              • 4. 部署视图
                • 把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构
              • 5. 用例视图
                • 最基本的需求分析模型
        • 2. 规则
        • 3. 公共机制
          • 指达到特定目标的公共 UML 方法，主要包括规格说明（详细说明）、修饰、公共分类（通用划分）和扩展机制四种
    • 面向对象分析
      • 用例模型
        • 基本思想
          • 不关注系统的内部结构和设计，只关心系统所能提供的服务
        • 作用
          • 从用户的角度描述系统的功能
        • 构建的四个阶段
          • 1. 识别参与者
            • 参与者是与系统交互的所有事物；参与者不仅是人，也可以是其他系统或硬件设备；参与者一定在系统之外，不是系统的一部分
          • 2. 合并需求获得用例
            • 仔细地检查参与者，为每一个参与者确定用例，将获取到的需求分配给与其相关的参与者
          • 3. 细化用例描述
            • 书写用例规约（Use Case Specication），其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流和扩展事件流）和后置条件等，还可以包括非功能需求和用例优先级等
          • 必须的
          • 4. 调整用例模型
            • 在建立了初步的用例模型后，还可以利用用例之间的关系来调整用例模型。利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护
            • 用例之间的关系
              • 包含、扩展、泛化
      • 分析模型
        • 作用
          • 描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型），以及它们如何保持通信，实现系统行为（动态模型）
        • 类之间的关系
          • 1. 关联
            • 不同类的对象之间连接的结构关系，如右图：Habitat类作为Animal类的属性
          • 2. 依赖
            • 一个事物发生改变会影响到另一个事物的语义，两个类A和B，B的变化可能会引起A的变化，则称A依赖于B，如右图：Animal类吃什么，依赖于Food类
          • 3. 泛化
            • 泛化是一般性事物 （父类）和它的较为特殊种类（子类）之间的一种关系，描述特殊元素的对象可替换一般元素的对象（李氏替换原则）。继承关系是泛化关系的反关系，子类继承了父类，而父类是子类的泛化
          • 4. 共享聚集 （聚合）
            • 表示类之间整体与部分的关系，其中“部分”可以同时属于多个“整体”，且“部分”和“整体”的生命周期可以不相同，如：汽车和轮胎之间的关系，车坏了，轮胎仍可以继续给别的车使用，轮胎坏了，车可以换一个新的轮胎
          • 5. 组合聚集 （组合）
            • 表示类之间整体与部分的关系，其中“部分”只能属于一个“整体”，“部分”和“整体”的生命周期相同，表现为强关联，如：公司和部门，公司倒闭，部门也没了
          • 6. 实现
            • 其中一个类指定了由另外一个类保证执行的契约
  • 软件设计
    • 主要任务
      • 解决“怎么做”的问题
    • 结构化设计（SD） Structured Design
      • 定义
        • 是一种面向数据流的方法，它以 SRS（需求规格说明书） 和 SA（结构化分析） 阶段所产生的 DFD（数据流图）和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程
      • 基本原则
        • 从功能角度出发，应秉持高内聚，低耦合的原则
          • 内聚表示模块内部各成分之间的联系，一个好的内聚模块应当恰好做目标单一的一件事情
          • 耦合表示模块之间联系的程度，模块之间应互不影响、各司其职
      • 基本思想
        • 将软件设计成由相对独立且具有单一功能的模块组成的结构
      • 阶段
        • 概要设计 / 总体结构设计
          • 主要任务是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图
        • 详细设计
          • 在概要设计中，将系统开发的总任务分解成许多个基本的、具体的任务，而为每个具体任务选择适当的技术手段和处理方法的过程称为详细设计
          • 根据任务分类
            • 1. 输入/输出设计
            • 2. 处理流程设计
            • 3. 数据存储设计
            • 4. 用户界面设计
            • 5. 安全性和可靠性设计
    • 面向对象设计（OOD） Obiect-Oriented Design
      • 优点
        • 更接近现实世界、更自然
      • 基本思想
        • 1. 抽象
          • 现实世界中的事物都可以抽象出对象的集合
        • 2. 封装
          • 数据结构和在数据结构上定义的操作算法封装在一个对象之中
        • 3. 可扩展性
          • 实现方法
            • 继承
              • 父子结构
            • 多态
              • 子类继承父类，并可以有自己的行为（重写从父类那继承来的方法）
        • 面向对象的三大特征： 封装、继承、多态
      • 原则
        • 1. 单职原则
          • 设计功能单一的类，类似 SA 的高内聚
        • 2. 开闭原则
          • 开放扩展，封闭修改
        • 3. 李氏替换原则
          • 子类可以替换父类
        • 4. 依赖倒置原则
          • 要依赖于抽象，而不是具体实现；要针对接口编程，不要针对实现编程（定义接口，引用接口得到具体实现）
        • 5. 接口隔离原则
          • 使用多个专门的接口比使用单一的总接口要好（特定的功能另起一个接口，不要都写在一起再做判断）
        • 6. 组合重用原则
          • 要尽量使用组合，而不是继承关系达到重用目的（继承是一对一的，组合更灵活）
        • 7. 迪米特原则 （最少知识法则）
          • 一个对象应当对其他对象有尽可能少的了解，类似 SA 的低耦合
    • 设计模式
      • 定义
        • 前人经验的总结，它使人们可以方便地复用成功的软件设计，使系统具有更好的可复用性和灵活性
      • 基本要素
        • 模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等
      • 分类
        • 根据处理范围分类
          • 类模式
            • 处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，属于静态关系
          • 对象模式
            • 处理对象之间的关系，这些关系在运行时刻变化，更具动态性
        • 根据目的和用途分类
          • 创建型（Creational）模式
            • 作用
              • 主要用于创建对象
            • 包括
              • 工厂方法模式、抽象工厂模式、原型模式、单例模式和建造者模式等
          • 结构型（Structural）模式
            • 作用
              • 主要用于处理类或对象的组合
            • 包括
              • 适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式和代理模式等
          • 行为型（Behavioral）模式
            • 作用
              • 主要用于描述类或对象的交互以及职责的分配
            • 包括
              • 职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式等
  • 软件实现
    • 软件配置管理
      • 保证软件质量
      • 作用
        • 通过标识产品的组成元素、管理和控制变更、验证、记录和报告配置信息来控制产品的演进和完整性
      • 活动包括
        • 1. 软件配置管理计划
        • 2. 软件配置标识
        • 3. 软件配置控制
        • 4. 软件配置状态记录
        • 5. 软件配置审计
        • 6. 软件发布管理与交付
    • 软件编码
      • 设计的结果
      • 定义
        • 把软件设计的结果翻译成计算机可以“理解和识别”的形式一一用某种程序设计语言书写的程序
      • 程序设计语言
        • 人和计算机通信的最基本工具，编码之前要选择一种恰当的程序设计语言
      • 程序设计风格
        • 源程序文档化
        • 数据说明
        • 语句结构
        • 输入/输出方法
        • 提高代码可读性
      • 程序复杂性度量
        • 定量度量的结构可以用于比较两个不同设计或两种不同算法的优劣；程序的定量的复杂程度可以作为模块规模的精确限度
      • 编码效率
        • 程序效率
          • 程序的执行速度及程序所需占用的内存空间
        • 算法效率
          • 程序的执行速度和存储容量的要求
        • 存储效率
          • 要选择可生成较短目标代码且存储压缩性能优良的编译程序
        • I/O 效率
          • 面向人（操作员）的 输入 / 输出
            • 输入数据简单方便，数据结果直观清晰
          • 面向设备的 输入 / 输出
            • 根据设备本身性能特性判定
    • 软件测试
      • 软件质量和评价的依据
      • 定义
        • 是将软件交付给客户之前所必须完成的重要步骤，是发现软件错误（缺陷）的主要手段
      • 目的
        • 验证软件是否满足软件开发合同或项目开发计划、系统 / 子系统设计文档、SRS、软件设计说明和软件产品说明等规定的软件质量要求
      • 分类
        • 静态测试
          • 被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测
          • 包括
            • 对文档静态测试
              • 检查单
            • 对代码静态测试
              • 桌前检查（Desk Checking）、代码走查、代码审查
                • 也属于白盒测试
        • 动态测试
          • 在计算机上实际运行程序进行软件测试
          • 包括
            • 白盒测试 （结构测试）
              • 定义
                • 测试人员完全清楚程序的结构和处理算法，按照程序内部逻辑结构设计测试用例，检测程序中的主要执行通路是否都能按预定要求正确工作
              • 应用场景
                • 主要用于软件单元测试中
              • 测试方法
                • 控制流测试、数据流测试和程序变异测试等
              • 常用技术
                • 逻辑覆盖
                  • 定义
                    • 使用测试数据运行被测程序，考查对程序逻辑的覆盖程度
                  • 覆盖标准
                    • 语句覆盖、判定覆盖、条件覆盖、条件 / 判定覆盖、条件组合覆盖、修正的条件 / 判定覆盖和路径覆盖等
            • 黑盒测试 （功能测试）
              • 定义
                • 完全不考虑（或不了解）程序的内部结构和处理算法，而只检查程序功能是否能按照 SRS 的要求正常使用，程序是否能适当地结束输入数据并产生正确的输出信息（正确输入输出）
              • 应用场景
                • 主要用于集成测试、确认测试和系统测试中
              • 测试用例
                • 包括等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法等
                  • 不等式：1 < x < 5 1. 等价类划分：x=[2, 3, 4], 数组里的值等价，都是正确值 2. 边界类划分：边界取一个正确值和一个错误值，结果为：1, 2和4, 5
  • 部署交付
    • 软件部署与交付
      • 软件生命周期中的一个重要环节，属于软件开发的后期活动，即通过配置、安装和激活等活动来保障软件制品的后续运行
    • 持续交付
      • 一个完全自动化的过程，当业务开发完成的时候，可以做到一键部署
    • 持续部署
      • 部署目的
        • 不是部署一个可工作的软件，而是部署一套可正常运行的环境
      • 方案
        • 常用方案
          • Kubernetes + Docker
          • Matrix 系统
        • 流行技术
          • 容器技术
      • 原则
      • 层次
        • Build
          • 跟传统的编译类似，将软件编译形成RPM包或者Jar包
        • Ship
          • 将所需的第三方依赖和第三方插件安装到环境中
        • Run
          • 在不同的地方启动整套环境
      • 不可变服务器
        • 是一种部署模式，是指除了更新和安装补丁程序以外，不对服务器进行任何更改
      • 两大部署方式
        • 蓝绿部署
          • 在部署的时候准备新旧两个部署版本，通过域名解析切换的方式将用户使用环境切换到新版本中，当出现问题的时候，可以快速地将用户环境切回旧版本，并对新版本进行修复和调整
            • 两个版本并行，新版本有问题时，及时切换回旧版本，并修改新版本
        • 金丝雀部署
          • 当有新版本发布的时候，先让少量用户使用新版本，并且观察新版本是否存在问题。如果出现问题，就及时处理并重新发布；如果一切正常，就稳步地将新版本适配给所有的用户
            • 少量用户试用新版本，确认无误后开放给所有用户
    • 部署与交付的新趋势表现
      • 工作职责和人员（运维和开发）分工的转变
      • 大数据和云计算基础设施的普及进一步给部署带来新的飞跃
      • 研发运维的融合
  • 过程管理
    • 软件过程能力
      • 定义
        • 是组织基于软件过程、技术、资源和人员能力达成业务目标的综合能力
      • 包括
        • 治理能力、开发与交付能力、管理与支持能力、组织管理能力等方面
      • 软件过程能力成熟度
        • 定义
          • 指组织在提升软件产品开发能力或软件服务能力过程中，各个发展阶段的软件能力成熟度
    • 常见的软件过程管理方法和实践
      • 国际常用的能力成熟度模型集成（Capability MaturityModel Integration，CMMI）
      • 中国电子业标准化技术协会发布的 T / CESA 1159《软件过程能力成熟度模型》（Software Process Capability Maturity Model，CSMM）团体标准
    • CSMM 成熟度模型
      • 作用
        • 为组织提供改进和评估软件过程能力的一个成熟度模型，通过提升组织的软件开发能力帮助顾客提升软件的业务价值
      • 组成
        • 4个能力域
          • 1. 治理
            • 确定组织的战略、产品的方向、组织的业务目标，并确保目标的实现
          • 2. 开发与交付
            • 确保通过软件工程过程交付满足需求的软件，为顾客与利益干系人增加价值
          • 3. 管理与支持
            • 确保软件项目能够按照既定的成本、进度和质量交付，能够满足顾客与利益干系人的要求
          • 4. 组织管理
            • 对软件组织能力进行综合管理
        • 20个能力子域
        • 161个能力要求
    • CSMM成熟度等级
      • 初始级
        • 软件过程和结果具有不确定性
          • 不确定能否实现
      • 项目规范级
        • 项目基本可按计划实现预期的结果
          • 基本可以实现
      • 组织改进级
        • 在组织范围内能够稳定地实现预期的项目目标
          • 稳定实现
      • 量化提升级
        • 在组织范围内能够量化地管理和实现预期的组织和项目目标
          • 不仅实现 还可以量化管理
      • 创新引领级
        • 通过技术和管理的创新，实现组织业务目标的持续提升，引领行业发展
          • 不仅实现 还要引领发展
• 2. 数据工程
  • 数据建模
    • 定义
      • 对现实世界中具体的人、物、活动和概念进行抽象、表示和处理，变成计算机可处理的数据，也就是把现实世界中的数据从现实世界抽象到信息世界和计算机世界
    • 数据模型
      • 1. 概念模型 / 信息模型
        • 定义
          • 按用户的观点来对数据和信息建模，把现实世界中的客观对象抽象为某一种信息结构，这种信息结构不依赖于具体的计算机系统，也不对应某个具体的 DBMS，它是概念级别的模型
        • 基本元素
          • 实体
            • 客观存在的并可以相互区分的事物称为实例，而同一类型实例的抽象称为实体
              • 1. 实体是同一类型实例的共同抽象 2. 实体是抽象的，实例是具体的 3. 一个实体可以实例化多个实例，一个实例只能由一个实体实例化产生（实体和实例，一对多）
          • 属性
            • 实体的特性
          • 域
            • 属性的取值范围称为该属性的域，如：性别的域是{“男”, “女”}
          • 键
            • 能唯一标识每个实例的一个属性或几个属性的组合（键）
          • 关联
            • 在现实世界中，客观事物之间是相互关系的，这种相互关系在数据模型中表现为关联（一对一，一对多，多对多）
      • 2. 逻辑模型
        • 定义
          • 逻辑模型是在概念模型的基础上确定模型的数据结构，目前主要的数据结构有层次模型、网状模型、关系模型、面向对象模型、对象关系模型
        • 最重要的逻辑模型—关系模型
          • 基本元素
            • 关系
              • 概念模型中的实体
            • 属性
              • 概念模型中的属性
            • 关系.外键
              • 概念模型中的联系有可能转换为关系模型的新关系，被参照关系的主键转化为参照关系的外键
            • 视图
              • 按照查询条件从现有关系或视图中抽取若干属性组合而成
          • 数据操作
            • 查询、插入、删除和更新数据（增删改查）
          • 关系的完整性约束
            • 实体完整性
            • 参照完整性
            • 必须满足的约束条件
            • 用户定义的完整性
              • 应用领域需要遵照的约束条件，体现了具体领域中的语义约束
      • 3. 物理模型
        • 定义
          • 物理数据模型是在逻辑数据模型的基础上，考虑各种具体的技术实现因素，进行数据库体系结构设计，真正实现数据在数据库中的存放
        • 目标
          • 如何用数据库模式来实现逻辑数据模型，以及真正地保存数据
        • 基本元素
          • 表、字段、视图、索引、存储过程、触发器等
    • 数据建模过程
      • 可能考排序
      • 1. 数据需求分析
        • 分析用户对数据的需要和要求
      • 2. 概念模型设计
        • 将需求分析得到结果抽象为概念模型，其任务是确定实体和数据及其关联
      • 3. 逻辑模型设计
        • 将概念模型中实体、属性和关联转换为关系模型结构中的关系模式
      • 4. 物理模型设计
        • 将数据模型转换为真正的数据库结构，需要针对具体的 DBMS 进行物理模型设计，使数据模型走向数据存储应用环节
  • 数据标准化
    • 实现数据标准化的基础
    • 元数据标准化
      • 元数据定义
        • 关于数据的数据（Data About Data）
        • 在信息界，元数据被定义为提供关于信息资源或数据的一种结构化数据，是对信息资源的结构化描述（描述信息资源或数据的内容、覆盖范围、质量、管理方式、数据的所有者、数据的提供方式等有关的信息）
      • 信息对象
        • 可以是单一的，也可以是单一资源的集合，亦或是处理资源过程中产生的参数的描述
      • 元数据体系
        • 信息内容
          • 内容元数据
          • 标记数字对象内容及结构的元数据
        • 内容对象
          • 专门元数据
          • 描述单一数字对象的内容、属性及外在特征的元数据
        • 内容对象集合
          • 资源集合元数据
          • 按照科学、主题、资源类型、用户范围、生成过程，使用管理范围形成的信息资源集合的描述
        • 对象的管理与保存
          • 管理元数据
          • 数字对象加工、存档、结构、技术处理、存取、控制、版权管理以及相关系统等方面的信息描述
        • 对象的服务、服务过程、服务系统
          • 服务元数据
          • 数字资源服务的揭示与表现、服务过程、服务系统等方面的相关信息的描述
        • 元数据的管理
          • 元元数据
          • 对元数据的标记语言、格式语言、标识符、扩展机制、转换机制等的描述
    • 数据元标准化
      • 数据元
        • 不可再分的、最小的数据单元
        • 定义
          • 数据库、文件和数据交换的基本数据单元
        • 组成
          • 对象
            • 采集和存储数据的事物
          • 特性
            • 指一个对象类的所有成员所共有的特征
          • 表示
            • 1. 值域
              • 数据元允许值的集合，例：“学生总数”这一数据元的值域是用非负实数集作为它的允许值集合
            • 2. 数据类型
              • 表达数据元不同可选值的集合，例：“学生姓名”的数据类型是“字符”
            • 3. 表示类
              • 表示类型的分类，例：“性别代码”这一值域的表示类是“类别”
            • 4. 计量单位
              • 用于计量相关值的实际单位，例：“学生身高”的计量单位是“厘米”
      • 数据元提取方法
        • 自上而下（Top-Down）提取法
          • 适用于新建系统的数据元提取
            • 根据需求整理数据元
          • 提取数据元
            • 在流程和功能分析的基础上，通过建模分析，确立关心的“对象”。在概念数据模型和逻辑数据模型的基础上，分析提取数据元及其属性
        • 自下而上（Down-Top）提取法 / 逆向工程
          • 适用于已建系统的数据元提取
            • 从已有的数据中提取数据结构
          • 提取数据元
            • 数据元创建者依据数据元标准化方法，对信息系统及相关资源的数据，在分析梳理的基础上，归纳整理出数据元
      • 数据元制定的基本过程
        • 1. 描述
        • 2. 界定业务范围
        • 3. 开展业务流程分析与信息建模
        • 4. 借助于信息模型，提取数据元，并按照一定的规则规范其属性
        • 5. 对于代码型的数据元编制其值域，即代码表
        • 6. 与现有的国家标准或行业标准进行协调
        • 7. 发布实施数据元标准并建立相应的动态维护管理机制
    • 数据模式标准化
      • 数据模式
        • 定义
          • 数据的概念、组成、结构和相互关系的总称
        • 本质
          • 反映了人类对客观世界的主观认知，不同的人群对相同的客观世界的主观认知会有所不同
            • 导致数据共享过程中出现障碍
        • 目的
          • 保证能够顺畅的进行信息共享，对特定领域而言，需要一个统一的数据模式作为数据共享与交换的基础
      • 如何描述
        • 从数据的逻辑层面对数据集的内容、组成及其结构信息，进行合理的、规范的、本质上的说明和描述
      • 描述方式
        • 图描述方法
          • 描述数据集中的实体和实体之间的相互关系
          • IDEFIX 方法和 UML 图
        • 数据字典方法
          • 描述模型中的数据集、单个实体、属性的摘要信息
    • 数据分类与编码标准化
      • 数据分类
        • 定义
          • 根据内容的属性或特征，将数据按一定的原则和方法进行区分和归类，并建立起一定的分类体系和排列顺序
        • 要素
          • 分类对象
            • 由若干个被分类的实体组成
          • 分类依据
            • 取决于分类对象的属性或特征
      • 数据编码
        • 定义
          • 将事物或概念（编码对象）赋予具有一定规律和易于计算机、人识别处理的符号，形成代码元素集合，代码元素就是赋予编码对象的符号（代码值）
      • 作用
        • 用于信息系统的共享和互操作，统一数据的表示法和提高信息处理效率
    • 数据标准化管理四个阶段
      • 1. 确定数据需求
      • 2. 制定数据标准
      • 3. 批准数据标准
      • 4. 实施数据标准
  • 数据运维
    • 数据存储
      • 定义
        • 根据不同的应用环境，通过采取合理、安全、有效的方式将数据保存到物理介质上，并能保证对数据实施有效的访问
      • 存储介质
        • 定义
          • 数据存储的载体，是数据存储的基础
        • 类型
          • 磁带、光盘和磁盘
      • 存储管理
        • 1. 资源调度管理
          • 添加或删除存储节点，编辑存储节点的信息，设定某类型存储资源属于某个节点，或者设定这些资源比较均衡地存储到节点上
        • 2. 存储资源管理
          • 一类应用程序，它们管理和监控物理和逻辑层次上的存储资源，从而简化资源管理，提高数据的可用性
        • 3. 负载均衡管理
          • 为了避免存储资源由于资源类型、服务器访问频率和时间不均衡造成浪费或形成系统瓶颈而平衡负载的技术
        • 4. 安全管理
          • 防止恶意用户攻击系统或窃取数据
    • 数据备份
      • 定义
        • 为了防止由于用户操作失误、系统故障等意外原因导致的数据丢失，而将整个应用系统的数据或一部分关键数据复制到其他存储介质上的过程
      • 目的
        • 保证当应用系统的数据不可用时，可以利用备份的数据进行恢复，尽量减少损失
      • 结构
        • DAS 备份构、基于 LAN 的备份结构、LAN-FREE 备份结构和 SERVER-FREE 备份结构
      • 策略
        • 完全备份、差分备份和增量备份
      • 备份硬件
        • 备份服务器、RAID（磁盘阵列）和磁带机等设备
      • 备份软件
        • 操作系统自带的软件，如麒麟操作系统的“备份”工具，功能较为简单
        • 专业备份软件，功能较为全面
    • 数据容灾
      • 灾难的定义
        • 一切引起系统非正常停机的事件都可以称为灾难，包括不可预料、不可抗拒的自然灾害，系统软硬件故障、人为误操作和恶意攻击等
      • 容灾系统
        • 应用容灾
          • 克服灾难对系统的影响，保证应用服务的完整、可靠和安全等一系列要求，使得用户在任何情况下都能得到正常的服务
        • 数据容灾
          • 保证用户数据的高可用性，在灾难发生时能够保证应用系统中的数据尽量少丢失或不丢失，使得应用系统能不间断地运行或尽快地恢复正常运行
        • 根据容灾系统保护对象划分
      • 从技术上衡量容灾系统的指标
        • RPO（Recovery Point Object）
          • 当灾难发生时允许丢失的数据量
        • RTO（Recovery Time Object）
          • 当灾难发生后系统恢复的时间
      • 数据备份也是容灾的一种手段，但能力有限。数据容灾不是简单备份，也不是一种技术，而是一个在灾难发生时能全面、及时地恢复整个系统的工程，有其完整的流程、规范及其具体措施
    • 数据质量评价与控制
      • 数据质量描述
        • 通过数据质量元素来描述
        • 数据质量元素
          • 数据质量定量元素
          • 数据质量非定量元素
      • 数据质量评价方法
        • 直接评价法
          • 将数据与内部或外部的参照信息，如理论值等进行对比
        • 间接评价法
          • 利用数据相关信息，如数据只对数据源、采集方法等的描述推断或评估数据质量
      • 数据质量控制—按照建库流程划分
        • 前期控制
          • 是在提交成果（即数据入库）之前对所得的原始数据与完成的工作进行检查，进一步发现和改正错误
        • 过程控制
          • 对获得的数据在录入过程中进行属性的数据质量控制
        • 系统检测
          • 在数据入库后进行系统检测，设计检测模板，利用检测程序进行系统自检
        • 精度评价
          • 对入库属性数据用各种精度评价方法进行精度分析，为用户提供可靠的属性数据
      • 数据清理
        • 定义
          • 广义
            • 将数据库精简以除去重复记录，并使剩余部分转换成符合标准的过程
          • 狭义
            • 在构建数据仓库和实现数据挖掘前对数据源进行处理，使数据实现准确性、完整性、一致性、唯一性、适时性、有效性以适应后续操作的过程
        • 步骤
          • 数据分析
            • 从数据中发现控制数据的一般规则，比如字段域、业务规则等，通过对数据的分析，定义出数据清理的规则，并选择合适的清理算法
          • 数据检测
            • 根据预定义的清理规则及相关数据清理算法，检测数据是否正确，比如是否满足字段域、业务规则等，或检测记录是否重复
          • 数据修正
            • 手工或自动地修正检测到的错误数据或重复的记录
  • 数据开发利用
    • 数据集成
      • 定义
        • 将驻留在不同数据源（DBMS）中的数据进行整合，向用户提供统一的数据视图（一般称为全局模式），使得用户能以透明的方式访问数据
      • 目标
        • 充分利用已有数据，在尽量保持其自治性的前提下，维护数据源整体上的一致性，提高数据共享利用效率
      • 数据集成系统
        • 为用户提供了统一的数据源访问接口，用于执行用户对数据源的访问请求
    • 数据挖掘
      • 定义
        • 从大量数据中提取或“挖掘”知识，即从大量的、不完全的、有噪声的、模糊的、随机的实际数据中，提取隐含在其中的、人们不知道的、却是潜在有用的知识
      • 目标
        • 发现隐藏于数据之后的规律或数据间的关系，从而服务于决策
      • 主要任务
        • 数据总结、关联分析、分类和预测、聚类分析和孤立点分析
      • 流程
        • 可能考排序
        • 1. 确定分析对象
        • 2. 数据准备
        • 3. 数据挖掘
        • 4. 结果评估
        • 5. 结果应用
      • 与传统数据分析的区别
        • 1. 分析对象的数据量有差异，数据挖掘所需的数据量更大
        • 2. 运用的分析方法有差异
          • 传统数据分析主要运用统计学
          • 数据挖掘综合运用数据统计、人工智能、可视化等技术
        • 3. 分析侧重有差异
          • 传统数据分析通常是回顾型和验证型的，通常分析已经发生了什么
          • 数据挖掘通常是预测型和发现型的，预测未来的情况，解释发生的原因
        • 4. 成熟度不同
          • 数据分析更成熟，数据挖掘仍在发展阶段
    • 数据服务
      • 目的： 数据共享
      • 1. 数据目录服务
        • 快捷地发现和定位所需数据资源的一种检索服务
      • 2. 数据查询与浏览及下服务
      • 3. 数据分发服务
        • 数据的生产者通过各种方式将数据传送到用户的过程
        • 核心内容
          • 数据发布、数据发现、数据评价和数据获取
    • 数据可视化
      • 发展步骤
        • 可视化技术
          • 定义
            • 指将抽象的事物或过程变成图形图像的表示方法
        • 科学计算可视化
          • Visualizationin Scientifc Computing
          • 定义
            • 运用图形学的原理和方法，将科学与工程计算等产生的大规模数据转换为图形、图像，以直观的形式表示出来
        • 数据可视化
          • Data Visualization
          • 定义
            • 运用计算机图形学和图像处理技术，将数据转换成为图形或图像在屏幕上显示出来，并能进行交互处理
          • 涉及领域
            • 计算机图形学、图像处理、计算机辅助设计、计算机视觉及人机交互技术
      • 表现方式
        • 一维数据可视化
          • 简单的线性数据，如文本或数字表格、程序源代码
        • 二维数据可视化
          • 由两种主要描述属性构成的数据，如一个物体的宽度和高度、一个城市的平面地图、建筑物的楼层平面图等
        • 三维数据可视化
          • 描述立体信息，表示实际的三维物体
        • 多维数据可视化
        • 时态数据可视化
          • 二维数据的一种特例，即二维中有一维是时间轴，它以图形方式显示随着时间变化的数据
        • 层次数据可视化
          • 树形数据
        • 网络数据可视化
          • 指与任意数量的其他节点有关系的节点的数据
    • 信息检索
      • 定义
        • 广义
          • 将信息按一定的方式组织和存储起来，然后根据用户需求查找出特定信息的技术，所以全称是信息存储与检索（Information Storage and Retrieval）
        • 狭义
          • 按照用户的检索需求，利用已有的检索工具或数据库，从中找出特定信息的过程
      • 主要方法
        • 全文检索
        • 字段检索
        • 基于内容的多媒体检索
          • 图像检索、视频检索和声音检索等
        • 数据挖掘
      • 常用技术
        • 布尔逻辑检索技术
        • 截词检索技术
        • 临近检索 / 位置检索技术
        • 限定字段检索技术
        • 限制检索技术
  • 数据库安全
    • 安全对策
      • 防止非法的数据访问
        • 仅允许授权用户访问
      • 防止推导
        • 防止用户通过授权访问的数据，推导得出机密信息
      • 保证数据库的完整性
        • 保护数据库不受非授权的修改
      • 保证数据的操作的完整性
        • 在并发事务中保证数据库中数据的逻辑一致性
      • 保证数据的语义的完整性
        • 修改数据时，保证新值在一定范围内符合逻辑上的完整性
      • 审计和日志
        • 记录所有的数据操作，用于事后调查和分析
      • 标识和认证
        • 用户管理，是授权、审计等的前提条件
      • 机密数据管理
        • 机密数据和公开数据访问控制
      • 多级保护
        • 表示一个安全需求的集合，研究如何赋予多数据项组成的集合一个恰当的密级
      • 限界
        • 防止程序之间出现非授权的信息传递
    • 安全机制
      • 定义
        • 用于实现数据库的各种安全策略的功能集合
      • 目标
        • 保护数据库系统安全
      • 包括
        • 用户的身份认证、存取控制、数据库加密、数据审计、推理控制等
• 3. 系统集成
  • 集成基础
    • 集成内容
      • 技术环境的集成、数据环境的集成、应用程序的集成
    • 集成原则
      • 开放性
        • 系统硬软件平台、通信接口、软件开发工具、网络结构的选择要遵循工业开放标准
          • 只有开放的系统才能满足可互操作性、可移植性以及可伸缩性的要求
      • 结构化
        • 结构化系统分析设计方法
      • 先进性
        • 目前先进性
          • 系统采用先进的技术
        • 未来先进性
          • 系统设计的先进性
      • 主流化
        • 系统构成的每一个产品应属于该产品发展的主流
  • 网络集成
    • 体系框架
      • 传输子系统
        • 传输是网络心，是网络信息的“公路”和“血管”
      • 交换子系统
        • 网络（局域网、城域网和广域网）交换技术
      • 安全子系统
        • 使用防火墙技术，防止外部的侵犯
        • 使用数据加密技术，防止任何人从通信信道窃取信息
        • 访问控制，主要是通过设置口令、密码和访问权限保护网络资源
      • 网管子系统
        • 网络管理，保证网络的良好运行
      • 服务器子系统
        • 向工作站提供处理器内存、磁盘、打印机、软件数据等资源和服务，并负责协调管理这些资源
      • 网络操作系统
        • 调度和管理网络资源，并为网络用户提供统一、透明使用网络资源的手段
      • 服务子系统
        • 互联网服务、多媒体信息检索、信息点播、信息广播、远程计算和事务处理以及其他信息服务等
  • 数据集成
    • 目的
      • 运用一定的技术手段将系统中各种异构数据库中的数据（处理对象）按一定的规则组织成为一个整体，使得用户能有效地对数据进行操作
      • 是为应用提供统一的访问支持，因此集成后的数据必须保证一定的完整性，包括数据完整性和约束完整性。
    • 关键
      • 数据仓库技术
    • 集成层次
      • 1. 基本数据集成
        • 集成方式
          • 将不同系统源中同一业务实体合并
        • 通用标识符不确定问题解决方法
          • 隔离
            • 保证实体的每次出现都指派一个唯一标识符
          • 调和
            • 确认哪些实体是相同的，并且将该实体的各次出现合并起来
        • 数据丢失问题解决方法
          • 为丢失的数据产生一个非常接近实际的估计值来进行处理
      • 2. 多级视图集成
        • 集成方式
          • 对数据源之间的关系进行集成
        • 表示对应
          • 底层数据表示方式为局部模型的局部格式，如关系和文件
          • 中间数据表示为公共模式格式，如扩展关系模型或对象模型
          • 高级数据表示为综合模型格式
      • 3. 模式集成
        • 集成方式
          • 模型合并
      • 4. 多粒度数据集成
        • 集成方式
          • 数据综合
            • 对各局域中的数据进行综合，提取和归并其主要特征，由高精度数据经过抽象形成精度较低但是粒度较大的数据
          • 数据细化
            • 由一定精度的数据获取精度较高的数据
    • 异构数据集成
      • 方法
        • 过程式方法
          • 根据一组信息需求，采用一种点对点 （Ad-hoc）的设计方法来集成数据，设计一套合适的软件模块存取数据源
        • 声明式方法
          • 是通过一套合适的语言来对多个数据源的数据进行建模，构建一个统一的数据表示
        • 中间件集成
          • 利用中间件集成异构数据库，该方法不需要改变原始数据的存储和管理方式
          • 中间件向下协调各数据库系统，向上为访问集成数据的应用提供统一的数据模式（全局模式）和数据访问的通用接口
      • 原始数据提取
        • 开放式数据库互联 Open Database Connectivity，ODBC
          • 一种用来在数据库系统之间存取数据的标准应用程序接口，使数据库系统具有很好的开放性
        • 嵌入式 C 接口程序
          • 针对不同的数据源编写专用的嵌入式 C 接口程序，这样可提高数据的提取速度
      • 数据交换格式
        • XML
          • 可扩展标记语言（Extensible Markup Language）
        • JSON
          • 随着 AJAX 发展产生的一种轻量级的数据交换格式
  • 软件集成
    • 对象管理组织（OMG） Object Management Group
      • 目的
        • 将对象和分布式系统技术集成为一个可相互操作的统一结构，此结构既支持现有的平台也将支持未来的平台集成
      • 集成实现
        • 以 CORBA 为基础
        • 利用 JINI 技术
        • 结合各类电子产品成为网络上的服务资源，使应用集成走向更广阔的应用领域，同时 Object Web 把 CORBA 的技术带入了 Internet 世界
    • CORBA
      • 公共对象请求代理结构（Common Object Request Broker Architecture，CORBA）
      • 是 OMG 进行标准化分布式对象计算的基础
      • 功能
        • 自动匹配许多公共网络任务，例如对象登记、定位、激活、多路请求、组帧和错误控制、参数编排和反编排、操作分配等
    • COM
      • 特性
        • 面向对象客户机 / 服务器、语言无关性、进程透明性和可重复性
      • 对象
        • 二进制代码对象，其代码形式是 DLL或EXE 执行代码
        • 被直接注册在 Windows 的系统库中，不再是由特定的编程语言其程序设计环境所支持的对象，而是由系统平台直接支持的对象
        • 作为某个应用程序的构成单元，不但可以作为该应用程序中的其他部分，而且还可以单独地为其他应用程序系统提供服务
        • 可能由各种编程语言实现，并为各种编程语言所引用
          • 编程语言无关性：将 COM 对象制作成二进制可执行代码，然后在二进制代码层使用这种标准接口的统一方式，为对象提供标准的互操作接口，并且由系统平台直接对COM对象的管理与使用提供支持
    • DCOM
      • COM 的扩展，针对分布环境还提供了一些新的特性，如位置透明性、网络安全性、跨平台调用等
      • 对用户调用进程外服务的一种改进，通过 RPC 协议，使用户通过网络可以以透明的方式调用远程机器上的远程服务
    • COM+
      • COM 的新发展或更高层次上的应用，底层结构仍以 COM 为基础，把 COM 组件软件提升到应用层而不再是底层的软件结构，使组件对象模型建立在应用层上，把所有组件的底层细节留给操作系统，与操作系统的结合更加紧密
    • .NET
      • 基于一组开放的互联网协议，推出的一系列的产品、技术和服务
      • 开发框架：在通用语言运行环境基础上，给开发人员提供了完善的基础类库、数据库访问技术及网络开发技术，开发者可以使用多种语言快速构建网络应用
    • J2EE
      • 是使用 Java 技术开发组织级应用的一种事实上的工业标准，为搭建具有可伸缩性、灵活性、易维护性的组织系统提供了良好的机制
      • 体系结构
        • 客户端层
        • 服务器端组件层
        • EJB（Enterprise JavaBean）层
        • 信息系统层
      • 核心和基础
        • 一整套的服务、应用编程接口和协议
          • 可用于开发一般的多层应用和基于 Web 的多层应用
  • 应用集成 / 组织应用集成（EAI）
    • 与数据集成的区别： 1. 数据集成的目的是共享数据而非存储数据 2. 应用集成是在功能层面将多个应用直接连接起来，打造动态且具有高度适应性的应用和服务
    • 定义
      • 将独立的软应用连接起来，实现协同工作
    • 系统集成栈
    • 技术要求
      • 具有应用间的互操作性
        • 不同系统间信息的有意义交换
      • 具有分布式环境中应用的可移植性
        • 应用程序在系统中可被迁移且不破坏应用所提供的或正在使用的服务
      • 具有系统中应用分布的透明性
        • 降低应用集成编程的复杂性
      • 实现关键：在独立应用（包括本地应用和云应用）之间实现实时双向通信和业务数据流，借助互联互通的流程和数据交换，组织通常可以基于统一的用户界面或服务，协调所有基础设施和应用的各种功能
    • 组件
      • 应用编程接口（API）
        • 定义不同软件交方式的程序和规则，可以支持应用之间相互通信
      • 事件驱动型操作
        • 当触发器（即事件）启动一个程序或一组操作时，系统就会执行事件驱动型操作
        • 如：在订单提交后，进行计费并向客户开具发票；管理从 ERP 系统到 CRM 系统的“业务机会到订单”工作流
      • 数据映射
        • 将数据从一个系统映射到另一个系统，可以定义数据的交换方式，从而简化后续的数据导出、分组或分析工作
        • 如：用户在一个应用中填写联系信息表，那么这些信息将被映射到相邻应用的相应字段
• 4. 信息系统安全工程
  • 工程概述
    • 定义
      • 信息系统安全工程（Information Security System Engineering，ISSE）是一门系统工程学，它的主要内容是确定系统和过程的安全风险，并且使安全风险降到最低或使其得到有效控制。
      • 信息安全系统工程就是要建造一个信息安全系统，它是整个信息系统工程的一部分，而且最好是与业务应用信息系统工程同步进行
    • 术语
      • 业务应用信息系统
        • 是支撑业务运营的计算机应用信息系统
      • 信息安全系统
        • 服务于业务应用信息系统并与之密不可分，无法脱离存在，如：国税信息系统、公安信息系统、社保信息系统等
      • 统称：信息系统
      • 信息系统工程
        • 定义
          • 建造信息系统的工程
        • 包括
          • 业务应用信 息系统工程
            • 为了达到建设好业务应用信息系统所组织实施的工程，一般称为信息系统集成项目工程
          • 信息安全系统工程
            • 强调信息安全
  • 信息安全系统
    • 定义
      • 是“信息系统”的一个部分，用于保证“业务应用信息系统”正常运营；是客观的、独立于业务应用信息系统而存在的信息系统
    • 安全空间
      • 体系架构
        • X 轴是“安全机制”
          • 提供某些安全服务，利用各种安全技术和技巧，所形成的一个较为完善的结构体系
          • 如“平台安全”机制，实际上就是指安全操作系统、安全数据库、应用开发运营的安全平台以及网络安全管理监控系统等
        • Y 轴是“OSI 网络参考模型”
          • 信息安全系统的许多技术、技巧都是在网络的各个层面上实施的，离开网络信息系统的安全也就失去意义
        • Z 轴是“安全服务”
          • 从网络中的各个层次提供给信息应用系统所需要的安全服务支持
          • 如对等实体认证服务、访问控制服务、数据保密服务等
      • 五大要素（属性）
        • 认证、权限、完整、加密、不可否认
    • 安全机制
      • 基础设施实体安全、平台安全、数据安全、通信安全、应用安全、运行安全、管理安全、授权和审计安全
      • 安全防范体系
        • 使得组织具有较强的应急事件处理能力，其核心是实现组织信息安全资源的综合管理
        • WPDRRC 能力模型
          • 预警（Warn）
          • 保护（Protect）
          • 检测（Detect)
          • 反应（Response）
          • 恢复（Recover）
          • 反击（Counter-attack）
    • 安全服务
      • 对等实体认证服务
        • 两个开放系统同等层中的实体建立链接或数据传输时，对对方实体的合法性、真实性进行确认
      • 数据保密服务
        • 防止网络中各系统之间的数据被截获或被非法存取而泄密，提供密码加密保护
      • 数据完整性服务
        • 防止非法实体对交换数据进行增刪改以及在数据交换过程中数据丢失
      • 数据源点认证服务
        • 确保数据发自真正的源点，防止假冒
      • 禁止否认服务
        • 不得否认发送
          • 发送方在发送数据后否认自已发送过此数据
        • 不得否认接收
          • 接收方在收到数据后否认自己收到过此数据或伪造接收数据
      • 犯罪证据提供服务
    • 安全技术
      • 加密、数字签名技术、防控控制、数据完整性、认证、数据挖掘等（2.1.4小节）
  • 工程基础
    • 信息安全系统工程活动离不开其他相关工程
    • 信息安全系统建设是遵从组织所制定的安全策略进行的
    • 信息安全系统工程活动必须要与其他外部实体进行协调
    • 信息安全系统工程应该吸纳安全管理的成熟规范部分
  • 工程体系架构
    • ISSE-CMM
      • 定义
        • 信息安全系统工程能力成熟度模型（ISSE Capability Maturity Model，ISSE-CMM）是一种衡量信息安全系统工程实施能力的方法（度量标准），是使用面向工程过程的一种方法
      • 基础
        • 统计过程控制理论
          • 所有成功组织的共同特点是它们都具有一整套严格定义、管理完善、可测可控的有效业务过程
      • 作用
        • 指导信息安全系统工程的完善和改进，使信息安全系统工程成为一个清晰定义的、成熟的、可管理的、可控制的、有效的和可度量的学科
      • 适用于
        • 工程组织 Engineering Organizations
          • 包含系统集成商、应用开发商、产品提供商和服务提供商等
          • 使用 ISSE-CMM 对工程能力进行自我评估
        • 获取组织 Acquiring Organizations
          • 包含采购系统、产品以及从外部 / 内部资源和最终用户处获取服务的组织
          • 使用 ISSE-CMM 来判别一个供应者组织的信息安全系统工程能力，识别该组织供应的产品和系统的可信任性，以及完成一个工程的可信任性
        • 评估组织 Evaluation Organizations
          • 包含认证组织、系统授权组织、系统和产品评估组织等
          • 使用 ISSE-CMM 作为工作基础，以建立被评组织整体能力的信任度
    • ISSE 过程
      • 定义
        • 为了使信息安全系统具有可实现性并有效力，必须把信息安全系统集成在信息系统生命周期的工程实施过程中，这种集成过程将产生一个信息安全系统工程 （ISSE）过程
      • 目的
        • 使信息安全系统成为系统工程和系统获取过程整体的必要部分，从而有力地保证用户目标的实现，提供有效的安全措施以满足客户和服务对象的需求
      • 实施过程分解
        • 1. 工程过程 Engineering Process
          • 作用
            • 与其他工程一起确定安全策略和实施解决方案
          • 强调
            • 工程的实施必须紧密地与其他的系统工程组进行合作
        • 2. 风险过程 Risk Process
          • 定义
            • 调查和量化风险的过程并建立组织对风险的承受级别
          • 作用
            • 识别出所开发的产品或系统风险，并对这些危险进行优先级排序
          • 目标
            • 降低信息系统运行的风险
          • 风险
            • 定义
              • 有害事件发生的可能性及其危害后果
            • 有害事件组成
              • 威胁、脆弱性和影响
            • 具有不确定性
        • 3. 保证过程 Assurance Process
          • 定义
            • 安全需求得到满足的可信程度
          • 作用
            • 建立起解决方案的可信性并向用户转达这种安全可信性
          • 安全保证并不能增加任何额外的对安全相关风险的抗拒能力，但它能为减少预期安全风险提供信心
    • ISSE-CMM 体系结构
      • 目标
        • 落实安全策略，而从管理和制度化突出信息安全工程的基本特征
      • 两维设计
        • “域”（Domain）
          • 定义
            • 汇集了定义信息安全工程的所有实施活动（公共特性），这些实施活动称为过程域
          • 划分方法
            • 典型的做法之一就是将实际的信息安全工程服务模型化，即原型法，以此创建与信息安全工程服务相一致的过程域
        • “能力”（Capability）
          • 定义
            • 代表组织能力，它由过程管理能力和制度化能力构成
          • 组织能力标志
            • 执行一个公共特性
          • 公共特性
            • 逻辑域组成
              • 通用实施（Generic Practices，GP）
            • 成熟度等级
              • 非正规实施级
                • 执行基本实施
              • 规划和跟踪级
                • 规划执行
                • 规范化执行
                • 验证执行
                • 跟踪执行
              • 充分定义级
                • 定义准化过程
                • 执行已定义的过程
                • 协调安全实施
              • 量化控制级
                • 建立可测度的质量目标
                • 对执行情况实施客观管理
              • 持续改进级
                • 改进组织能力
                • 改进过程的效能
              • 依次表示增强的组织能力
      • 能力级别
        • 将通用实施划分为公共特性，将公共特性划分为能力级别
        • 公共特性和能力级别无论在评估一个组织过程能力还是改进组织过程能力时都是重要的