一、概论

什么是通用软件产品(Generic products,to G/to B)和定制化软件产品(Customized/Bespoke software,to C)?

1. 通用软件产品：由软件开发组织开发，在市面上公开销售，可以独立使用。这类软件产品包括移动应用、数据库软件、字处理软件、等。还包括用于特定目的的所谓的“垂直”应用产品，如图书馆信息系统、财务系统等。

2. 定制化软件产品：受特定的客户委托，由软件承包商专门为这类客户设计和实现。这类软件包括电子设备的控制系统、特定业务处理系统等。

3. 区别：在通用软件产品中，软件规格说明由开发者自己确定，这意味着如果在开发过程中遇到问题，那么开发者可以重新思考所开发的东西；而定制化软件产品的软件规格说明通常是由客户给出的，开发者必须按客户要求进行开发。

什么是软件工程(Software engineering)？

软件工程是一门工程学科，涉及软件生产的各个方面，从最初的系统规格说明直到投入使用后的系统维护，都属于其学科范畴，目的是在一定时间内满足用户需求。

软件工程的四项基本活动(four fundamental activities)：

1. 软件规则说明(software specification)

2. 软件开发(software development)

3. 软件确认(software validation)

4. 软件演化(software evolution)

二、软件工程

瀑布模型(the waterfall model)：

1. 内容：该模型包括了基本的过程活动（规格说明、开发、确认、演化），并将它们表示为独立的过程阶段
2. 优点：按照线性顺序，清楚，易于管理，对新手友好
3. 缺点：发现需求中的问题太晚，缺少迭代和反馈
4. 使用：嵌入式系统，关键性系统，大型软件系统

增量式开发(incremental development)：

1. 内容：该方法使得规格说明、开发和确认活动交错进行。系统开发体现为一系列的版本（增量），每个版本在前一个版本的基础上增加一些功能
2. 优点：降低了实现需求变更的成本；在开发过程中更容易得到客户对于已完成的开发工作的反馈意见；即使并未将所有的功能包含其中，也使得在早期向客户交付和部署有用的软件称为可能
3. 缺点：过程不可见；伴随着新的增量的添加，系统结构会逐渐退化

软件规格说明(software specification/requirement engineering)的主要活动：

1. 需求抽取与分析
2. 需求规格说明
3. 需求确认

软件开发(software development/software design and implementation)的主要活动：

1. 体系结构设计
2. 数据库设计
3. 接口设计
4. 构建选取和设计

软件确认(software validation)的主要活动：

1. 构建测试
2. 系统测试
3. 客户测试

验证和确认(Verification and Validation,V&V)：

1. 验证：检查软件是否满足其所声明的功能性和非功能性需求的过程
2. 确认：确保软件满足客户需求

三、敏捷软件开发

计划驱动(plan-drived)过程和敏捷(agile)过程的区别是什么？

1. 计划驱动过程：提前计划好所有的过程活动，按照计划去衡量进度
2. 敏捷过程：计划是在软件开发过程中增量和持续进行的，这样就可以很容易调整过程，反映不断变化的客户或产品需求，允许开发团队关注软件本身而不是它的设计和文档化

什么极限编程(extreme programming,XP)?

将得到的最佳实践推动到“极限”的水平，一个系统的多个不同新版本可以由不同的程序员在一天之中开发、集成和测试

什么是用户故事(user stories)？

每个用户故事是一系统用户可能经历的使用场景

什么是重构(refactoring)？

希望所有的开发者一旦发现潜在的代码改进机会都能持续对代码进行重构。这样可以使代码保持简洁并具有好的可维护性

什么是增量规划(incremental planning)？

需求被记录在“故事卡片”上，一个发布中将要包含的故事取决于可用的时间及它们的相对优先级。开发者将这些故事分解为开发“任务”

什么是测试先行的开发(test-first development)？

在任务实现实践编写测试，测试自动化对于测试先行的开发十分重要

什么是结对编程(pair programming)?

开发者结对工作，相互检查对方的工作并提供支持以确保总是能高质量地完成工作

什么是Scrum？

Scrum是一种敏捷方法，因为它遵循了敏捷宣言(Agile Manifesto)中那些原则，然而该方法关注为敏捷项目组织提供一个框架，并没有指定使用一些特定的开发实践

四、需求工程

什么是需求(requirements)？什么是需求工程(requirments engineering)？

1. 需求：是关于该系统应当提供的服务以及对其运行的约束的描述
2. 需求工程：找出、分析、文档化并且检查这些服务和约束的过程

什么是用户需求(user requirments)和系统需求(system requirments)？

1. 用户需求使用自然语言和图形，陈述系统被期望向系统用户提供什么服务以及系统运行必须满足的约束。用户需求可以是对系统的大概陈述，也可以是关于系统功能的详细和精确的描述
2. 系统需求是对软件系统的功能、服务和运行约束的更详细的描述。系统需求文档（功能规格说明）应该精确定义要实现哪些东西。它可以是系统购买方和软件开发者之间合同的一部分

什么是功能性需求(functional requirements)和非功能性需求(non-functional requirements)？

1. 功能性需求：这些需求是对系统应该提供的服务、如何响应特定的输入、在特定情形中应该如何表现等的陈述。在某些情况下，功能性需求还可以明确地陈述系统不应该做什么
2. 非功能性需求：这些需求是对系统提供的服务或功能的约束，包括时间性约束、对于开发过程的约束、标准规范中所施加的约束等。非功能性需求经常适用于系统整体而不是单个的系统特征或服务（需要量化，用数字表示）

需求抽取技术(requirements elicitation)包括：

1. 访谈
2. 观察或人种学调查

故事(stories)和场景(scenarios)的区别：

1. 故事和场景的区别在于描述的组织方式以及所呈现的抽象层次
2. 故事被描述为叙述性的文本，并且呈现一种关于系统使用的高层描述
3. 场景通常按照所收集的特定信息进行组织

什么是需求规格说明(requirements specification)？

需求规格说明是在需求文档中撰写用户和系统需求的过程

什么是用况(use case)？

是一种使用图形化模型和结构化文本描述用户与系统间交互的方式，是统一建模语言(UML)的一个基本特性

什么是软件需求文档(software requirment specification,SRS)？

软件需求文档，又称软件需求规格说明，是关于系统开发者应当实现的所有东西的正式陈述。需求文档可以同时包括一个系统的用户需求以及对于系统需求的详细规格说明。有时用户和系统需求被集成到同一个描述中，有时用户需求在系统需求规格说明的一个引言章节中描述

需求确认(validation)包括哪些不同的检查(checks)？

1. 正确性检查
2. 一致性检查
3. 完整性检查
4. 现实性检查
5. 可验证性检查

六、体系结构设计

决定体系结构风格（style）和结构(structure)的选择的系统的非功能性需求（Non-Functional Requirement， (NFR)）（P158）

1. 性能：吞吐量，内存占用
2. 信息安全
3. 安全性
4. 可用性
5. 可维护性

4+1软件体系结构视图模型(4+1 view model of software archiecture)4个基本的体系结构视图(Architectural view)

1. 逻辑视图
2. 进程视图
3. 开发视图
4. 物理视图

体系结构模式(Architectural patterns)

是一种复用的解决方案，用于在给定的上下文中解决常见的体系结构问题。它提供了一个通用的模板，可以帮助开发人员设计和实现软件系统的整体结构。体系结构模式通过定义组件的组织方式及其相互关系，来描述系统的高层次结构。

模型-视图-控制器(MVC,Model-View-Controller)

1. 描述:
   将呈现和交互从系统数据中分离出来。系统被组织为3个相互交互的逻辑构件。模型（model）构件管理系统数据以及相关的对这些数据的操作。视图（view）构件定义并管理数据呈现给用户的方式。控制器（controller）构建管理用户界面（例如按键、鼠标点击等）并将这些交互传递给视图和模型。
2. 优点:
   允许数据独立于它的呈现方式进行变更，反之亦然。支持以不同的方式呈现同样的数据，在某一个呈现方式中进行修改可以在所有呈现方式中显示。
3. 缺点:
   当数据模型和交互比较简单时，可能包含额外的代码以及代码复杂性。

分层体系结构(layered architecture)

1. 描述:
   将系统组织为多个层次，每个层次与一些相关的功能相联系。每个层次向其上的一层提供服务，因此那些最底层次表示很有可能在整个系统中使用的核心服务。
2. 优点:
   只要接口保持不变，允许对整个层进行替换。可以在每个层次上提供冗余设施以增加系统的可依赖性。
3. 缺点:
   在实践中，将各层之间干净地分离经常很难做到，较高层次上的层可能不得不与较低层次上的层直接交互，而不是通过紧邻着的下一层。性能可能是一个问题，因为当一个服务请求在各个层次上进行处理时需要经过多层的解析

知识库体系结构(repository architecture)

1. 描述:
   一个系统中的所有数据在所有系统构件都能访问的中心知识库中进行管理。构建相互之间并不直接交互，仅通过知识库进行交互。
2. 优点:
   构件可以保持独立，它们不需要知道其他构件的存在；一个构件进行的修改可以被传播到所有构件；所有数据都可以一致地进行管理，因为这些数据都位于一个地方。
3. 缺点:
   知识库可能存在单点失效的问题，因此知识库中的问题会影响整个系统；通过知识库组织所有的通信可能效率不高；将知识库分布到多台计算机上可能比较困难。

客户 - 服务器体系结构(client-server architecture)

1. 描述:
   在客户 - 服务器体系结构中，系统被呈现为一组服务，其中每个服务都由一个独立的服务器提供。客户端是这些服务的用户，通过访问服务器来利用这些服务。
2. 优点:
   这种模型的主要优点是服务器可以分布在网络上。通用的功能可以向所有客户端开放使用，不需要由所有服务实现。
3. 缺点:
   每个服务都存在单点失效的问题，因此容易收到拒绝服务攻击或服务器失效的影响；性能可能不可预测，因为这取决于网络以及系统；如果服务器属于不同的组织，那么还可能会出现管理问题。

管道和过滤器体系结构(pipe and filter architecture)

1. 描述:
   系统中的数据处理通过组织，每个处理构建（过滤器）可以分离开并执行一种数据转换。数据从一个构件流动（就像在管道中一样）到另一个构件进行处理
2. 优点:
   容易理解并且支持变换的复用；这种工作流风格与许多业务过程的结构相匹配；通过增加变换来进行演化是非常直观的；可以被实现为一个顺序或一个并发系统。
3. 缺点:
   针对数据变换的格式必须在相互通信的多个变换之间达成一致；每个变换必须解析它的输入，并将输出转换成所约定的形式，增加了系统的负担，同时可能意味着无法复用使用不兼容的数据结构的体系结构构件。

应用体系结构(application architecture)（了解例子）

1. 事务处理系统：一个数据库事务包含一个操作序列并且该序列作为整体处理。
2. 信息系统：所有包含与一个共享数据库交互的系统都可以认为是基于事务的信息系统。
3. 语言处理系统：语言处理系统将一种语言翻译为该语言的另一种表示方式，对于编程语言还可以执行所产生的代码。

七、设计和实现

什么是设计和实现(design and implementation)？

软件设计和实现是软件工程过程中的一个阶段，在此阶段中会开发一个可执行的软件系统。

复用(reuse)

定义：大多数现代的软件都是通过复用已有的构件或系统来构造的。在开发软件时，应该尽可能多地利用已有的代码。

发生在四个级别上：（看）

1. 抽象级：体系结构模式和设计模式
2. 对象级：编程语言库
3. 构件级：构体框架
4. 系统级：应用系统（COTS）

作用

通过已有的软件，可以更快的开发新系统，而且风险和成本更低。由于被复用的软件已经在其他应用中得到了验证，他们应该会比新软件更可靠。

配置管理(configuration management)

1. 定义：配置管理是管理一个不断变化的软件系统的一般过程。
2. 目的：配置管理的目的是支持系统集成过程以使所有的开发者都可以以一种受控的方式访问项目的代码和文档，找出代码和文档做了哪些修改，以及对构件进行编译和链接来创建一个系统。

八、软件测试

测试(testing)的目的是什么？

测试的目的是显示一个程序做了希望做的事情以及在程序投入使用之前发现其中的缺陷。

测试是更广阔的软件验证和确认( Verification and Validation, V & V)过程的一部分

1. 确认（validation）:我们在构造正确的产品吗？（目标）
2. 验证（verification）:我们在以正确的方式构造产品吗？（过程）

一个商业化软件系统(commercial software system)必须经历的3个测试阶段

1. 开发测试
2. 发布测试
3. 用户测试

开发测试(development testing)包括三个阶段（方面）

1. 单元测试
2. 构建测试
3. 系统测试

发布测试(release testing)（看一看）

发布测试是指对一个系统在开发团队以外进行使用的一个特定发布进行测试的过程。
在开发过程中，发布测试和系统测试有两个重要区别：

1. 系统开发团队不应该负责发布测试。
2. 发布测试是一个确认检查的过程，其目的是确保一个系统满足它的需求，并且运行的足够好可以由系统客户进行使用。
3. 开发团队进行的系统测试侧重于关注发现系统中的bug（缺陷测试）。

用户测试(user testing)

用户或客户测试是一个测试过程阶段，其中用户或测试提供他们对于系统测试的输入和建议。

三种类型用户测试(three types of user testing)

1. α测试，一组经挑选的软件用户与开发团队密切配合工作，对软件的早期发布进行测试；（有开发人员引导）
2. β测试，向一组更大规模的用户提供一个软件的发布版本，允许他们在上面进行试验，并将他们所发现的问题报告给系统开发者。（用户独立测试）
3. 验收测试，客户对一个系统进行测试以确定其是否已经就绪，是否可以从系统开发者那里接收过来并且在客户环境中进行部署。

九、软件演化

软件为什么会演化(evolution)？

1. 大型软件系统通常有一个很长的生命周期。
2. 在系统开发完成后，如果要使其继续有用，对它进行修改是不可避免的。
3. 企业必须不断改进他们的软件以确保他们能够持续从中获得价值。

开发和演化的螺旋模型(a spiral model of development and evolution)

每一圈都是一个软件开发生命周期，发布一个版本。
风险驱动的开发过程

• 风险分析：每个螺旋周期都包含详细的风险分析步骤，通过识别和评估项目风险，制定风险管理策略。
• 风险管理：在每个迭代阶段，团队会采取措施减轻或消除风险，确保项目能够顺利进行。

迭代和增量开发

• 渐进式精化：通过多次迭代，每次迭代都在前一次基础上进行改进和扩展，使得系统逐步完善。
• 增量交付：每个迭代结束后可以生成一个可交付的产品版本，用户可以逐步看到系统的演变和功能增加。

灵活性和适应性

• 动态调整：螺旋模型允许在开发过程中动态调整项目计划和目标，以适应变化的需求和环境。
• 适应变化：可以根据需求变化和风险评估结果，对项目进行调整，确保项目始终朝着正确的方向前进。

用户参与和反馈

• 用户评审：每个迭代结束后，用户都会参与评审，提供反馈意见，确保开发团队理解并满足用户需求。
• 反馈循环：通过不断的用户反馈，开发团队可以及时发现问题并进行改进，提高最终产品的质量和用户满意度。

系统性和结构化

• 阶段划分：螺旋模型将项目分为多个阶段，每个阶段都有明确的目标和交付物，包括计划、分析、设计、实现和测试。
• 文档化：每个阶段的输出文档详细记录了项目的进展和决策，确保项目过程的透明性和可追溯性

遗留系统(lagacy systems)

定义：旧的软件系统仍然还在使用并且在业务的运行中扮演者重要的角色，这些旧软件系统有时候被称为遗留系统。

遗留系统管理(legacy system management)

选择：

1. 废弃
2. 不在大幅修改仅保持常规维护
3. 对系统进行再工程以改善其可维护性
4. 用一个新的系统代替整个或部分系统

高业务价值低质量——再工程或维护
低业务价值低质量——废弃
高业务价值高质量——维护
低业务价值高质量——维护

软件维护(software maintenance)四种类型

1. 纠正性维护：缺陷修补维护
2. 适应性维护：有时是指为适应新环境所做的维护，而有时又是指对新需求的适应性维护
3. 完善性维护：有时是指实现一个新需求来完善软件，而有时又是指保留系统的功能但改善结构和性能
4. 预防性维护：重构

重构(refactoring)和再工程(reengineering)的区别

1. 再工程发生在系统已经维护了一段时间并且维护费用不断上升的情况下，通过使用自动化工具来处理并再工程一个遗留系统，并产生一个更具可维护性的新系统。
2. 重构是要避免导致成本上升和维护困难的结构以及代码的退化问题。

十、可依赖系统

一个系统的可靠性反映了用户对该系统的信任程度，即它将按照用户的期望运行，并且它在正常使用中不会“失败”。

可依赖性(dependability)包含5个维度

1. 可用性(availability)
2. 可靠性(reliability)
3. 安全性(safety)
4. 信息安全性(security)
5. 韧性(resilience)

影响系统可依赖性的系统属性

1. 可维修性(repirability)
2. 可维护性(maintainability)
3. 容错(error tolerance)

什么时候使用冗余(redundancy)、多样性(diversity)

1. 实现和提高可依赖性的策略依赖于冗余和多样性（提高可依赖性的两种方式）。
2. 冗余性意味着系统中包含多余的能力可以在系统失效的时候发挥作用。
3. 多样性意味着冗余的系统构件是属于不同种类的，这样它们就很难以完全一样的方式失效。
4. 在可用性要求高的系统中，冗余的服务常常被使用。

使用冗余的场景

1. 提高系统可靠性
2. 提高系统可用性
3. 提高系统性能
4. 提高数据安全

使用多样性的场景

1. 提高系统安全性
   • 多样性防御：使用不同类型的防御机制来保护系统，减少单一防御机制被攻破的风险。例如，结合使用防火墙、入侵检测系统和反病毒软件。
   • 多样化的加密算法：在数据传输和存储中，使用多种加密算法来增加攻击者破解难度，提升数据安全性。
2. 提高系统可靠性
3. 提高系统灵活性
4. 明确定义的过程就是用已定义的过程模型来驱动软件生产过程（不知道什么东西）
5. 可重复过程是一个不依赖于个别解释和判断的过程（不知道什么东西）

可依赖的过程(dependable process)中可能的活动

1. 需求评审
2. 需求管理
3. 形式化规格说明
4. 系统建模
5. 设计和程序审查
6. 静态分析
7. 测试规划和管理

十一、可靠性工程

1. 人为错误 human error or mistake
2. 系统故障 System fault（过程错误，代码错误）开发人员角度的故障（此处有待矫正）
3. 系统错误 System error（结果错误）
4. 系统失效 System failure（由于错误未能满足用户需求，用户角度）

可靠性（Reliability）

系统在一个特定时间、特定环境中针对一个特定目的而执行的无失效操作的可能性。

可用性（Availability）

系统在一个时刻是可操作的和能执行请求服务的可能性。

可靠性需求（Reliability requirements）

可依赖性(dependability)需求

1. 功能性需求：定义了系统应该包含的检查和修复措施，以及防止系统失效和外部攻击的保护性特征
2. 非功能性需求：定义了系统需要的可靠性和可用性

刻画可靠性(reliability)和可用性(availability)的度量（metrics）

1. 请求失效概率,POFOD，要用的时候故障概率
2. 失效发生率,ROCOF，使用中故障概率
3. 可用性,AVAIL，平均故障时间，与修复时间有关，可用时/（可用时+修复时）

非功能性可靠性需求(non-functional reliability requirements)

非功能性的可靠性需求是对系统可靠性和可用性的要求做出的规格说明，使用前面讲述的度量（POFOD,ROCOF,AVAIL）之一来描述。

定量(quantitative)的可靠性规格说明的作用

1. 决定可靠性需求级别的过程对弄清利益相关者真正的需求是有帮助的。
2. 它提供了一个用来评估何时停止测试系统的基准。
3. 定量的可靠性规格说明是一种评估不同设计策略的方式，它的目的是提高系统的可靠性
4. 如果一个系统再投入使用之前已经通过了监管人员的审批，那么证明该系统必需的可靠性目标得到满足对系统认证有着重要意义。

刻画可靠性需求的准则(guidelines)

1. 针对不同类型的失效定义可用性和可靠性需求
2. 针对不同类型的服务定义可用性和可靠性需求
3. 考虑是否真的需要高可靠性

功能性可靠性规格说明

4类功能性可靠性需求

1. 检查需求
2. 恢复需求
3. 冗余性需求
4. 过程性需求

容错体系结构(fault-tolerant architectures)

容错机制是一种确保运行时可靠性的方法，它定义了系统发生错误后的运行机制，即使发生软件或硬件故障，也能保整系统正常工作。

保护性系统(protection systems)

保护性系统是一种与其他系统相关联的专用系统。

自监控系统体系结构(self-monitoring architectures)

系统设计成监视其自身的操作，并在探测到问题的时候采取某些行动。

N版本编程(N-version programming)

自监控系统体系结构是采用多版本编程提供软件冗余和多样性的系统的例子。这个多版本编程的概念源自硬件系统中的三重模块冗余（TMR）的概念。

软件多样性(software diversity)

所有以上的容错体系结构都依赖于软件的多样性以获得容错功能。

可靠性编程(programming for reliability)

可依赖性编程指南（准则），背几条

1. 限制程序中信息的可见性。
2. 检查所有输入的有效性
3. 为所有的异常提供处理程序
4. 尽可能不使用容易出错的结构
5. 提供重启功能
6. 检查数组边界
7. 调用外部构件时加入超时处理功能
8. 为每一个表示现实世界值得常量命名

可靠性度量(reliability measurement)

评估系统可靠性的数据需求

（测试可靠性只在乎错几个）

1. 对给定数量的系统服务请求统计系统失效的次数
2. 系统失效间隔时间（或事物处理的数目）
3. 系统失效导致不能提供服务之后的维修和重启所需的时间

可靠性测试是度量系统可靠性的一个测试过程。
统计测试过程适用于可靠性测量而不是故障查找。

十二、安全工程

什么是安全性(safety)？

安全性是主要的可依赖性属性之一。如果系统在没有灾难性失效的情况下运行，即没有导致或可能导致人员死亡或受伤的失效，则可以认为该系统是安全的。因为环境损害可能导致后续的人身伤害或死亡，所以那些自身失效可能导致环境损害的系统也是安全关键的。

可靠的软件系统可能不安全的四个原因

1. 我们不能百分百地确定软件系统是无故障的和能容错的。
2. 需求规格说明可能是不完备的，因为它可能没有描述在一些关键时刻的必要的系统行为。
3. 硬件故障可能会导致传感器和执行器行为发生异常
4. 系统的操作者给出的一些输入单独看起来可能是正确的。

安全关键系统（Safety-critical System）

安全关键系统（Safety-Critical Systems）是指那些如果发生故障或失效，可能会导致严重后果的系统。(来自gpt)

安全关键软件分为两类

1. 主要(primary)的安全关键软件，嵌入在系统控制器中的软件（直接）
2. 次要(secondary)的安全关键软件，可以间接引起人员伤害（间接）

考虑可能发生的潜在系统事故，危险驱动技术(hazard-driven techiques)

1. 危险避免
2. 危险检测和排除
3. 限制损失

安全关键系统中使用的其他术语(了解)

事故（意外）(accident(or mishap))：未预计到的事件和事件后果，它导致人员伤亡、财产损失或环境破坏。

损失(damage)：关于意外所造成结果的一个度量

危险(hazard)：潜在能引起或造成事故的情况

危险概率(hazard probability)：发生危险的可能性。

危险严重性(hazard severity)：因特定的危险所导致的最坏可能损失的评估。

风险（risk）：这是系统会发生事故的概率的度量

安全需求（Safety requirements）

安全需求是功能性需求，功能性需求定义了系统应该包含的检查和修复措施，以及防止系统失效和外部攻击的保护性特征。

它们是高级别的需求，最好用“不应该”需求来描述。

危险驱动的安全规格说明过程（hazard-driven safety specification）的四个活动

1. 危险识别
2. 危险评估
3. 危险分析
4. 风险降低

可以使用危险日志（hazard register）记录所识别的危险。

危险分析（hazard analysis）

归纳行的自底向上的技术从一个所提出的系统失效出发，识别该失效可能会导致什么样的危险。

形式化验证（Formal verification）

软件开发的形式化方法是基于作为系统规格说明的形式化模型的。

确保安全关键系统的安全性一直是软件形式化开发方法的主要驱动力。

十三、信息安全性

信息安全系统工程(secure systems engineering)必须考虑的三个维度？

1. 机密性
2. 完整性
3. 可用性

从组织角度来看，信息安全考虑的3个层次(form an organizational perspective,security has to be considered at three levels)

1. 基础设施信息安全
2. 应用信息安全
3. 操作信息安全

信息安全管理(system security management)包括什么？

1. 用户和权限管理
2. 系统软件部署和维护
3. 攻击监控、检测和恢复

四种信息安全威胁(security threats)：

1. 拦截威胁
2. 中断威胁
3. 修改威胁
4. 伪造威胁

增强信息安全性的控制手段基于规避、检测、恢复这三种基本思想(availabillity,safety,resilience)

1. 漏洞规避
2. 攻击检测和压制
3. 暴漏限制与恢复

风险驱动(risk-driven)的信息安全需求过程

1. 资产识别
2. 资产价值评估
3. 暴露评估
4. 威胁识别
5. 攻击评估
6. 控制识别
7. 可行性评估
8. 信息安全需求定义

在设计能维护信息安全性的系统体系结构(a system architecture that maintains security)时，需要考虑两个基本问题：

1. 保护：如何组织系统使其关键资产能在外部攻击时得到保护
2. 分布：如何对系统资产进行分布使得逞的攻击数减到最少

设计准则(design guidelines)

1. 将信息安全决策建立在明确的信息安全策略之上
2. 避免单点失效
3. 可恢复性失效
4. 寻求信息安全和可用性间的均衡
5. 记录用户行为
6. 通过冗余性和多样性降低风险
7. 验证所有输入
8. 划分资产
9. 部署设计
10. 可恢复性设计

十四、韧性工程

什么是系统的韧性(resilience)？

系统的韧性是指系统在出现破坏性事件的情况下能够保持系统关键性服务的连续性的程度

四个相关的韧性活动：

1. 发现
2. 防御
3. 恢复
4. 复原

韧性系统设计包括两个密切相关的工作流(streams of work)

1. 识别关键性服务和资产
2. 设计支持问题发现、防御、恢复和复原的系统构件