导图社区 信息系统项目管理师第五章信息系统工程
- 165
- 8
- 2
- 举报
信息系统项目管理师第五章信息系统工程
信息系统项目管理师（第四版）第五章信息系统工程，内容包含软件工程、数据工程、系统集成、安全工程，大家可以学起来哦。
提示: 本内容由社区用户上传并分享。平台不对内容的真实性、合法性、知识产权归属及是否侵害第三方权利进行事前审核或保证。本内容可能包含受版权保护的图片、字体或其他第三方素材，使用前请自行确认授权范围。
- 信息系统项目管理师第四版
- 相似推荐
- 大纲
第五章 信息系统工程
软件工程
架构设计
软件架构设计核心问题：能否达到架构级的软件复用
在架构评估过程中，评估人员所关注的是系统质量属性
通用软件架构
数据流风格：批处理序列架构风格和管道/过滤器两种风格【批管】
调用/返回风格：主程序/子程序、数据抽象和面向对象，以及层次结构【主子抽象层面】
虚拟机风格：解释器和基于规则的系统【解释规则】
独立构件风格：进程通信和事件驱动的系统【进程办事】
仓库风格：数据库系统、黑板系统、超文本系统【库超黑】
敏感点是一个或多个构件（和/或构件之间的关系）的特性；权衡点是影响多个质量属性的特性，是多个质量属性的敏感点
基于场景的方式主要包括：架构权衡分析法（ATAM）、软件架构分析法（SAAM）、成本效益分析法（CBAM）
基于场景的方式分析软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度
在架构评估中，一般采用刺激、环境、响应三方面来对场景进行描述。刺激：场景中解释或描述项目干系人怎样引发与系统的交互部分；环境：描述的是刺激发生时的情况；响应：指系统是如何通过架构对刺激作出反应的。
需求分析
需求层次
软件需求是系统必须完成的事及必须具备得品质。包括：业务需求、用户需求、系统需求
质量功能部署QFD：将用户要求转化成软件需求的技术；目的是最大限度提升软件工程过程中用户的满意度。QFD将需求分为：常规需求、期望需求、意外需求
需求过程
需求获取
求获取只有与用户的有效合作才能成功。常见的需求获取方法：用户访谈、问卷调查、采样、情节串联板、联合需求计划
需求分析
一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性。需求分析就是把杂乱无章的用户要求和期望转化为用户需求。
需求分析对已经获取到的需求进行提炼、分析和审查，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足
结构化分析SA方法进行需求分析，建模核心是数据字典，围绕核心有三个层次的模型：
数据模型：实体联系图（E-R图）描述实体、属性，以及实体之间的关系【实数】
功能模型：数据流图（DFD）从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能【能流】
行为模型（也称状态模型）：状态转换图（STD）通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作【形状】
面向对象的分析OOA模型：包括用例模型和分析模型
用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模
分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统（静态模型）,以及如何保持通信，实现系统行为（动态模型）
需求规格说明书的编制
软件需求规格说明书SRS是需求开发活动的产物，目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，成为整个开发工作的基础
需求验证与确认
通过需求评审和需求测试工作来对需求进行验证
需求评审是对SRS进行技术评审:二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。
需求测试:才能及早发现问题，从而在需求开发阶段以较低的代价解决这些问题。
UML 统一建模语言
UML结构:包括构造块、规则和公共机制三个部分
UML中的事物(建模元素)包括：结构事物、行为事物 （动作事物）、分组事物、注释事物（注解事物）
UML中 的关系
1依赖：是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义
2关联：描述一组对象之间连接的结构关系。分为组合和聚合，都是部分和整体的关系，其中组合事物之间关系更强，部分和整体之间有共同的生命周期
3泛化：一般/特殊的关系，子类和父类之间的关系。继承:关系是泛化关系的反关系，也就是说，子类继承了父类，而父类则是子类的泛化
4实现：是类之间的语义关系，一个类元指定了另一个类元保证执行的契约
UML14种图
用例图：描述一组用例、参与者及它们之间的关系。
类图：展现了一组对象、接口、协作和它们之间的关系。是最常见的图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图
对象图：描述一组对象及它们之间的关系。描述了在类图中所建立的事物实例的静态快照
构件图：描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构
组合结构图：描述结构化类（例如，构件或类）的内部结构，包括结构化类与系统其余部分的交互点。用于画出结构化类的内部内容
顺序图（序列图）：一种交互图,交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。 交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图
通信图（协作图）：一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图强调的是时序，通信图强调的是对象之间的组织结构
定时图（计时图）：一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序
状态图：描述一个状态机，它由状态、转移、事件和活动组成。给出了对象的动态视图
活动图：将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图 它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程
部署图：描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图
制品图：描述计算机中一个系统的物理结构
包图：描述由模型本身分解而成的组织单元，以及它们之间的依赖关系
交互概览图：是活动图和顺序图的混合物
UML系统视图 【裸线不用进】
逻辑视图（设计视图）：它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集
实现视图：对组成基于系统的物理代码的文件和构件进行建模
部署视图：把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构
用例视图：是最基本的需求分析模型
进程视图：是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构
面对对象分析
OOA的任务是“做什么”，OOD的任务是“怎么做”，面向对象分析阶段的核心工作是建立系统的用例模型与分析模型
用例模型
OOA方法中，构建用例模型一般需要经历识别参与者、合并需求获得用例、细化用例描述、调整用例模型四个阶段，其中前三个阶段是必须的
用例之间关系
1包含关系：当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们
2扩展关系：是如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰
3泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。父子关系、一般和特殊关系。
分析模型
类之间关系
关联：提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。现的是对象实例之间的关系，而不表示两个类之间的关系
依赖：两个类A和B，如果B的变化可能会引起A的变化，则称类A依赖于类B
泛化：描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，子类继承了父类，而父类则是子类的泛化
共享聚集（聚合关系）：它表示类之间的整体与部分的关系，其含义是“部分”可能同时属于多个“整体“部分”与“整体”的生命周期可以不相同。汽车和车轮就是聚合关系，车子坏了，车轮还可以用。
组合聚集（组合关系）：它也是表示类之间的整体与部分的关系。组合关系中的“部分”只能属于一个“整体”，“部分”与“整体”的生命周期相同，“部分”随着“整体”的创建而创建，也随着“整体”的消亡而消亡。
实现关系：将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。
软件设计
结构化设计SD
一种面向数据流的方法，它以SRS和SA阶段所产生的DFD和数据字典等文档为基础，是一个自顶向下、逐步求精、模块化的过程
SD方法的基本思想是将软件设计成由相对独立且具有单一功能的模块组成的结构，分为概要设计和详细设计两个阶段；
SD需要遵循一个基本的原则:高内聚，低耦合。内聚表示模块内部各成分之间的联系程度；耦合表示模块之间联系的程度
面向对象设计OOD
OOA方法的延续，其基本思想：抽象、封装、可扩展性
常用面向对象设计 OOD 原则
单职原则：设计功能单一的类。本原则与结构化方法的高内聚原则是一致的
开闭原则：对扩展开放，对修改封闭
李氏替换原则：子类可以替换父类
依赖倒置原则：要依赖于抽象，而不是具体实现;要针对接口编程，不要针对实现编程
接口隔离原则：使用多个专门的接口比使用单一的总接口要好
组合重用原则：要尽量使用组合，而不是继承关系达到重用目的
迪米特原则（最少知识法则）：一个对象应当对其他对象有尽可能少的了解。本原则与结构化方法的低耦合原则是一致的
设计模式
前人经验的总结，它使人们可以方便地复用成功的软件设计。设计模式包含模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式等基本要素
根据处理范围不同
类模式：处理类和子类之间的关系，这些关系通过继承建立，在编译时刻就被确定下来，属于静态关系
对象模式：处理对象之间的关系，这些关系在运行时刻变化，更具动态性。
根据目的和用途不同
创建型模式：创建对象，工厂方法/抽象工厂/原型/单例/建造者模式
结构型模式：处理类或对象的组合，适配器/桥接/组合/装饰/外观/享元/代理模式
行为型模式：描述类或对象的交互以及职责的分配，职责链/命令/解释器/迭代器/中介者/备忘录/观察者/状态/策略/模板方法/访问者模式
软件实现
软件配置管理
软件配置管理活动包括软件配置管理计划、软件配置标识、软件配置控制、软件配置状态记录、软件配置审计、软件发布管理与交付【计时制，状态审计不符】
1软件配置管理计划：明确软件配置控制任务
2软件配置标识：识别要控制的配置项
3软件配置控制：管理软件生命周期中的变更
4软件配置状态记录：标识、收集、维护并报告配置管理的配置状态信息
5软件配置审计：独立评价软件产品和过程是否遵从已有的规则、标准、指南、计划和流程而进行的活动
6软件发布管理和交付：需要创建特定的交付版本，完成此任务的关键是软件库
软件编码
把软件设计的结果翻译成计算机可以“理解和识别”的形式—用某种程序设计语言书写的程序
软件测试
目的是验证软件是否满足软件开发合同或项目开发计划、系统/子系统设计文档、SRS、软件设计说明和软件产品说明等规定的软件质量要求。通过测试发现软件缺陷，为软件产品的质量测量和评价提供依据。
测试分类
静态测试 文档：检查单；代码：桌前检查、代码走查和代码审查
动态测试 黑盒：等价类划分、边界值分析等；白盒：逻辑覆盖
部署交付
软件开发完成后，必须部署在最终用户的正式运行环境，交付给最终用户使用，才能为用户创造价值。这些活动包括软件打包、安装、配置、测试、集成和更新等。持续不断的过程
软件部署与交付
软件部署与交付属于软件开发的后期活动，即通过配置、安装和激活等活动来保障软件制品的后续运行。部署技术影响着整个软件过程的运行效率和成本投入，软件系统部署的管理代价占到整个软件管理开销的大部分。
持续交付
主要体现在: 1在需求阶段 : 抛弃了传统的需求文档的方式，使用便于开发人员理解的用户故事； 2在开发测试阶段 : 做到持续集成，让测试人员尽早进入项目开始测试； 3在运维阶段 : 打通开发和运维之间的通路，保持开发环境和运维环境的统一。
持续交付具备的优势：1能够有效缩短提交代码到正式部署上线的时间，降低部署风险;2能够自动、快速地提供反馈，及时发现和修复缺陷;3让软件在整个生命周期内都处于可部署的状态;4能够简化部署步骤，使软件版本更加清晰;5能够让交付过程成为一种可靠的、可预期的、可视化的过程。
持续部署
容器技术目前是部署中最流行的技术，常用持续部署方案Kubemetes+Docker和Matrix系统两种
部署层次:首先要明确部署的目的并不是部署一个可工作的软件，而是部署一套可正常运行的环境。
完整的镜像部署 包括三个环节:Build—Ship—Run。
Build:将软件编译形成RPM包或者Jar包；Ship: 将所需的第三方依赖和第三方插件安装到环境中；Run: 在不同的地方启动整套环境。
制作完成部署包之后，每次需要变更软件或者第三方依赖以及插件升级的时候，不需要重新打包，直接更新部署包即可。
不可变服务器：是一种部署模式，是指除了更新和安装补丁程序以外，不对服务器进行任何更改。
蓝绿部署：指在部署的时候准备新旧两个部署版本，通过域名解析切换的方式将用户使用环境切换到新版本中，当出现问题的时候，可以快速地将用户环境切回旧版本，并对新版本进行修复和调整。
金丝雀部署：指当有新版本发布的时候，先让少量用户使用新版本，并且观察新版本是否存在问题。如果出现问题，就及时处理并重新发布；如果一切正常，就稳步地将新版本适配给所有的用户。
部署与交付新趋势
1工作职责和人员分工的转变:软件开发人员运用自动化开发工具进行持续集成，进一步将交付和部署扩展，而原来的手工运维工作也逐渐被分派到了开发人员的手里。
2大数据和云计算基础设施的普及进一步给部署带来新的飞跃:云计算的出现使得计算机本身也可以进行自动化创建和回收，部署和运维工作可以在远端进行，部署能力和灵活性质的飞跃。
3研发运维的融合:减轻运维的压力，把运维和研发融合在一起
过程管理
软件过程能力是组织基于软件过程、技术、资源、人员能力达成业务目标的综合能力。包括治理能力、开发与交付能力、管理与支持能力、组织管理能力等方面
成熟度模型CSMM模型 由4个能力域、20个能力子域、161个能力要求组成
治理：战略与治理、目标管理
开发与交付：需求、设计、开发、测试、部署、服务、开源应用
管理与支持：项目策划、项目监控、项目结项、质量保证、风险管理、配置管理、供应商管理
组织管理：过程管理、人员能力管理、组织资源管理、过程能力管理
成熟度等级
1级初始级：软件过程和结果具有不确定性
2级项目规范级：项目基本可按计划实现预期的结果
3级组织改进级：在组织范围内能够稳定地实现预期的项目目标
4级量化提升级：在组织范围内能够量化地管理和实现预期的组织和项目目标
5级创新引领级：通过技术和管理的创新，实现组织业务目标的持续提升，引领行业发展
数据工程
数据建模
数据模型
概念模型(信息模型)：它是按用户的观点来对数据和信息建模；把现实世界中的客观对象抽象为某一种信息结构，不依赖于具体的计算机系统，也不对应某个具体DBMS,它是概念级别的模型
逻辑模型：主要的数据结构有层次模型、网状模型、关系模型、面向对象模型、对象关系模型。 1关系模型成为目前最重要的一种逻辑数据模型。2关系数据模型的数据操作主要包括查询、插入、删除、更新数据，这些操作必须满足关系的完整性约束条件。3关系的完整性约束包括三大类型:实体完整性、参照完整性、用户定义的完整性
物理模型：内容：包括确定所有的表和列,定义外键用于确定表之间的关系，基于性能的需求可能进行反规范化处理等内容。 基本元素：包括表、字段、视图、索引、存储过程、触发器等，其中表、字段和视图等元素与逻辑模型中基本元素有一定的对应关系
数据建模过程
数据需求分析：用户需求—数据流图
概念模型设计：将需求分析得到结果抽象为概念模型的过程，其任务是确定实体和数据及其关联，建立逻辑模型,关系模式
逻辑模型设计：建立概念模型，其任务是确定实体和数据及其关联即E-R图
物理模型设计：将数据模型转换为真正的数据库结构，还需要针对具体的DBMS进行物理模型设计，使数据模型走向数据存储应用环节，主要问题包括命名、确定字段类型和编写必要的存储过程与触发器等
数据标准化
数据标准化是实现数据共享的基础。使得数据简单化、结构化、标准化
元数据标准化
1元数据是关于数据的数据。2元数据被定义为提供关于信息资源或数据的一种结构化数据，是对信息资源的结构化描述。 实质是用于描述信息资源或数据的内容、覆盖范围、质量、管理方式、数据的所有者、数据的提供方式等有关的信息
数据元标准化
开放系统互连环境（OSIE）四个基本要素（硬件、软件、通信和数据）中的三个要素（硬件、软件和通信）
1.数据元：是数据库、文件和数据交换的基本数据单元。数据库或文件由记录或元组等组成，而记录或元组则由数据元组成.由对象、特性和表示组成。 2.数据元提取：目前常用的数据元提取方法有两种:自上而下（Top-Down）提取法和自下而上（Down-Top）提取法。对于新建系统的数据元提取，一般适用“自上而下”的提取法。 3.数据元标准：数据元制定的基本过程：描述→界定业务范围→开展业务流程分析与信息建模→借助于信息模型，提取数据元，并按照一定的规则规范其属性→对于代码型的数据元，编制其值域，即代码表→与现有的国家标准或行业标准进行协调→发布实施数据元标准并建立相应的动态维护管理机制
数据模式标准化
本质:规范化处理，减少冗余。数据模式的描述方式主要有图描述方法和数据字典方法。图描述方法常用的有IDEFIX方法、UML图，主要用来描述数据集中的实体和实体之间的相互关系;数据字典形式用来描述模型中的数据集、单个实体、属性的摘要信息。
数据分类和编码标准化
数据标准化管理
四个阶段：确定数据需求、制定数据标准、批准数据标准、实施数据标准
数据运维
数据存储
根据不同的应用环境，通过采取合理、安全、有效的方式将数据保存到物理介质上，并 能保证对数据实施有效的访问
数据备份
1.数据备份是将整个应用系统的数据或一部分关键数据复制到其他存储介质上的过程。目的是保证当应用系统的数据不可用时，可以利用备份的数据进行恢复，尽量减少损失。
2.数据备份结构可分:DAS备份结构、基于LAN的备份结构、LANFREE备份结构和SERVER-FREE备份结构
3.常见的备份策略主要有三种:完全备份、差分备份、增量备份。
数据容灾
1.根据容灾系统保护对象的不同分为
应用容灾：用于克服灾难对系统的影响，保证应用服务的完整、可靠和安全等一系列要求，使得用户在任何情况下都能得到正常的服务
数据容灾：关注于保证用户数据的高可用性，在灾难发生时能够保证应用系统中的数据尽量少丢失或不丢失，使系统能不间断地运行或尽快地恢复正常
2.衡量容灾系统有两个主要指标:RPO和RTO，RPO代表了当灾难发生时允许丢失的数据量；RTO代表系统恢复的时间
数据质量与评价控制
数据质量描述：数据质量可以通过数据质量元素来描述，数据质量元素分为数据质量定量元素和数据质量非定量元素。
2.数据质量评价过程
3.数据质量评价方法:直接评价法、间接评价法
5.数据清理步骤: 数据分析→数据检测→数据修正
4.数据质量控制：前期控制、后期控制。依据建库流程可分为:前期控制、过程控制、系统检测、精度评价
数据开发利用
数据集成
数据集成的目标就是充分利用已有数据，在尽量保持其自治性的前提下，维护数据源整体上的一致性，提高数据共享利用效率。实现数据集成的系统称为数据集成系统，它为用户提供了统一的数据源访问接口，用于执行用户对数据源的访问请求
数据挖掘
常见任务：数据总结、关联分析、分类和预测、聚类分析和孤立点分析。挖掘流程：定分析对象、数据准备、数据挖掘、结果评估与结果应用
数据服务
主要包括数据目录服务、数据查询与浏览及下载服务、数据分发服务
数据可视化
将抽象的事物或过程变成图形图像的表示方法。可视化的表现方式分为7类：一维数据可视化、二维数据可视化、三维数据可视化、多维数据可视化、时态数据可视化、层次数据可视化和网络数据可视化
信息检索
检索方法：全文检索、字段检索、基于内容的多媒体检索、数据挖掘。 常用技术：布尔逻辑检索技术、截词检索技术、临近检索技术、限定字段检索技术、限制检索技术
数据库安全
数据库安全对策
防止非法的数据访问、防止推导、保证数据库的完整性、保证数据的操作完整性、保证数据的语义完整性、审计和日志、标识和认证、机密数据管理、多级保护、限界
数据库安全机制
用户的身份认证、存取控制、数据库加密、数据审计、推理控制
系统集成
集成基础
系统集成通过硬件平台、网络通信平台、数据库平台、工具平台、应用软件平台将各类资源有机、高效地集成到一起，形成一个完整的工作台面。 基本原则:开放性、结构化、先进性和主流化
网络集成
传输子系统（常用的无线传输介质：无线电波、微波、红外线等；常用的有线传输介质：双绞线、同轴电缆、光纤）、交换子系统（按所覆盖的区域分为：局域网、城域网和广域网）、安全子系统、网管子系统、服务器子系统、网络操作系统、服务子系统
数据集成
将参与数据库的有关信息在逻辑上集成为一个属于异构分布式数据库的全局概念模式，以达到信息共享的目的。数据集成可以分为四个层次
基本数据集成：通用标识符问题是数据集成时遇到的最难的问题之一。处理办法：1隔离:保证实体的每次出现都指派一个唯一标识符；2调和:确认哪些实体是相同的，并且将该实体的各次出现合并起来
多级视图集成:有助于对数据源之间的关系进行集成:
1底层数据表示方式为局部模型的局部格式，如关系和文件;中间数据表示为公共模式格式，如扩展关系模型或对象模型;高级数据表示为综合模型格式
2视图的集成化过程为两级映射:①数据从局部数据库中，经过数据翻译、转换并集成为符合公共模型格式的中间视图;②进行语义冲突消除、数据集成和数据导出处理，将中间视图集成为综合视图
模式集成
多粒度数据集成:数据综合集成的过程是特征提取和归并的过程
软件集成
软件构件标准:公共对象请求代理结构（CORBA）、COM、DCOM与COM+、.NET、J2EE应用架构等标准
应用集成
应用集成或组织应用集成（EAI）是指将独立的软件应用连接起来，实现协同工作。借助应用集成，组织可以提高运营效率，实现工作流自动化，并增强部门和团队之间的协作
对应用集成的技术要求有:1具有应用间的互操作性；2具有分布式环境中应用的可移植性；3具有系统中应用分布的透明性
可以帮助协调连接各种应用的组件有: 1应用编程接口（API）；2事件驱动型操作；3数据映射
安全工程
工程概述
信息安全系统工程就是要建造一个信息安全系统，它是整个信息系统工程的一部分，而且最好是与业务应用信息系统工程同步进行，主要围绕“信息安全”内容
信息安全系统三维空间包括安全机制、网络参考模型和安全服务 X轴是“安全机制” 。安全机制可以理解为提供某些安全服务，利用各种安全技术和技巧，所形成的一个较为完善的结构体系； Y轴是“OSI网络参考模型”； Z轴是“安全服务”
由X、Y、Z三个轴形成的信息安全系统三维空间就是信息系统的“安全空间” 。随着网络的逐层扩展，这个空间不仅范围逐步加大，安全的内涵也就更丰富，达到具有认证、权限、完整、加密和不可否认五大要素，也叫作“安全空间”的五大属性
安全系统
安全机制包括：基础设施实体安全、平台安全、数据安全、通信安全、应用安全、运行安全、管理安全、授权和审计安全、安全防范体系
安全服务包括：对等实体认证服务、数据保密服务、数据完整性服务、数据源点认证服务、禁止否认服务和犯罪证据提供服务
安全技术涉及：加密、数字签名技术、防控控制、数据完整性、认证、数据挖掘
工程基础
信息安全系统建设包括：硬件工程、软件工程、通信及网络工程、数据存储与灾备工程、系统工程、测试工程、密码工程和组织信息化工程
信息安全系统建设是遵从组织所制定的安全策略进行的。而安全策略由组织和组织的客户和服务对象、集成商、安全产品开发者、密码研制单位、独立评估者和其他相关组织共同协商建立。信息安全系统工程活动必须要与其他外部实体进行协调。
工程体系架构
信息安全系统工程应该吸纳安全管理的成熟规范部分。 信息安全系统工程能力成熟度模型（ISSE-CMM）是一种衡量信息安全系统工程实施能力的方法，是使用面向工程过程的一种方法。 ISSE-CMM主要适用于工程组织、获取组织、评估组织。ISSE将信息安全系统工程实施过程分解为:工程过程、风险过程、保证过程
ISSE-CMM
Level 1—非正规实施级：执行基本实施
Level 2—规划和跟踪级：规划执行、规范化执行、验证执行、跟踪执行
Level 3—充分定义级：定义标准化过程、执行已定义的过程、协调安全实施
Level 4—量化控制级：建立可测度的质量目标、对执行情况实施客观管理
Level 5—持续改进级：改进组织能力、改进过程的效能