1. 基本概念

1.1 定义

1. 软件可靠性：软件产品在 规定的条件 下和 规定的时间区间 完成 规定功能 的能力。
2. 串并联系统可靠性：无论什么系统，都是由多个设备组成的，协同工作，而这多个设备的组合方式可以是串联、并联，也可以是混合模式
   1. 串联系统：
      1. 一个设备不可靠，整个系统崩溃。
      2. 可靠性公式：$ R_{串联} = R_1 × R_2 × ⋯ × R_n $
   2. 并联系统：
      1. 所有设备都不可靠，整个系统才崩溃。
      2. 可靠性公式：$ R_{并联} = 1 - (1 - R_1)(1 - R_2)...(1 - R_n) $
3. 广义的软件可靠性测试：指为了 最终评价软件系统的可靠性 而运用 建模、统计、试验、分析 和 评价 等一系列手段对软件系统实施的一种测试。
4. 狭义的软件可靠性测试：指为了获取可靠性数据，按预先确定的测试用例，在软件的预期使用环境中，对软件实施的一种测试。它是面向缺陷的测试，以用户将要使用的方式来测试软件。
5. ISO/IEC 25010 软件质量模型中 “可靠性（Reliability）” 的子特性分类：
   1. 无故障性（Faultlessness）：
   2. 可用性（Availability）： 产品在需要使用时可运行且可访问的能力。
   3. 容错性（Fault Tolerance）： 系统在出现故障时仍能维持部分功能的能力。
   4. 可恢复性（Recoverability）： 软件在发生失败后恢复数据和恢复服务的能力。

1. 软件系统质量属性

1.1 概念

1. 软件系统质量：软件系统与明确地和隐含地定义的需求相一致的程度。
2. 软件系统质量属性：是一个系统的可测量或可测试的属性，用来描述系统满足 利益相关者（Stakeholders）需求的程度。

1.2 分类

1. 开发期质量属性
   1. 易理解性：指设计 被开发人员理解 的难易程度。
   2. 可扩展性：软件因 适应新需求 或需求变化而增加新功能的能力，也称为灵活性。
   3. 可重用性：指 重用 软件系统或某一部分的难易程度。
   4. 可测试性：对软件测试以证明其满足需求规范的难易程度。（度量指标有：如果存在缺陷出现故障的概率、测试准备时间、测试环境的准备时间）
      1. 案例题常考，关键词：接口调试，远程调试，测试功能
      2. 与远程调试相关。
   5. 可维护性：当需要修改缺陷、增加功能、提高质量属性时，识别修改点并实施修改的难易程度。
   6. 可移植性：将软件系统从一个运行环境 转移 到另一个不同的运行环境的难易程度。
2. 运行期质量属性
   1. 性能：性能是指软件系统及时提供相应服务的能力，如速度、吞吐量和容量等的要求。
   2. 安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。
   3. 可伸缩性：指当用户数和数据量增加时，软件系统维持高服务质量的能力。例如，通过增加服务器来提高能力。
   4. 互操作性：指本软件系统 与其他系统交换数据和相互调用服务 的难易程度。
   5. 可靠性：软件系统在一定的时间内持续无故障运行的能力。（多长时间不出问题）
   6. 可用性：指系统在一定时间内正常工作的时间所占的比例。可用性会受到系统错误，恶意攻击，高负载等问题的影响。（出了故障多久能够恢复）
   7. 鲁棒性：是指软件系统在非正常情况（如用户进行了非法操作、相关的软硬件系统发生了故障等）下仍能够正常运行的能力，也称 健壮性 或 容错性。

1. 软件架构

1.1 概念（宏观）

1. 软件系统架构是关于软件系统的 结构、行为 和 属性 的高级抽象（宏观层次上）。
2. 在描述阶段，主要描述直接构成系统的抽象组件以及各个组件之间的连接规则，特别是描述组件的 交互关系。
3. 在实现阶段，这些抽象组件被细化为实际的组件，比如具体类或对象。
4. 软件系统架构不仅指定了软件系统的 组织 和 拓扑结构，而且显示了 系统需求 和 组件 之间的对应关系，包括设计决策的 基本方法和基本原理。
5. ANSI/IEEE 1471-2000是对软件密集型系统的架构进行描述的标准。在该标准中，
   1. 视图 主要用于描述 软件架构模型。
   2. 在此基础上，通常采用 视角 描述某个 利益相关人（Stakeholder）所关注架构模型的某一方面。
   3. 架构 则是对所有利益相关人关注点的 响应和回答。

1. 概述

1. 核心目标：重复的体系结构模式（软件复用/重用）
2. 软件体系结构（架构）风格是描述某一特定应用领域中系统组织方式的惯用模式。体系结构风格定义一个系统家族（一类架构所共有的特征），即一个体系结构定义一个词汇表和一组约束。主要包括以下三部分：
   1. 架构定义：
   2. 架构词汇表：包含构件和连接件
   3. 架构约束：约束定义构件和连接件的组合方式
3. 体系结构风格反映了领域中众多系统所 共有的结构和语义特性，强调对 架构设计 的重用，并指导如何将各个模块和子系统有效地组织成一个完整的系统

1. 面向对象的设计原则（SOLID）

1.1 单一职责原则（Single Responsibility Principle, SRP）

1. 简介：一个类只负责一个功能领域中的相应职责（避免混乱）
2. 定义：单一职责原则要求类应该只有一个设计目的

1.2 开闭原则（Open Closed Principle，OCP）

1. 简介：对扩展开放，对修改关闭（提高系统的扩展性、稳定性）
2. 定义：可扩展系统并提供新行为，通过添加抽象层实现，是其他原则的基础。对扩展开放对修改封闭

1. 系统设计

1.1 概念

1. 设计工程是指在整个软件开发过程中，通过对需求工程的结果进行分析和设计，制定出系统的整体设计方案，包括概要设计、详细设计、应用设计等多个部分。
2. 主要目的：为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方法。

1.2 设计方法

1. 结构化设计方法
2. 面向对象设计方法

1. 软件需求

1.1 概念

1. 软件需求：指 用户对系统 在功能、行为、性能、设计约束等方面的 期望。

1.2 软件需求的层次

1. 业务需求：
   1. 整体全局视角，反映 企业 或 客户 对系统高层次的目标要求
   2. 通常来自 项目投资人、客户、市场营销部门 或 产品策划部门
   3. 通过业务需求可以确定 项目视图 和 范围。
2. 用户需求：
   1. 用户视角，描述用户的具体目标，或用户要求系统必须能完成的任务
   2. 通常采取 用户访谈 和 问卷调查 等方式，对用户使用的场景进行整理，从而建立用户需求。

1. 软件开发环境

1. 软件开发环境（Software Development Environment，SDE），应支持多种集成机制
2. 定义：是支持软件工程化开发和维护的一组软件工具和 环境集成机制
3. 要求：需要支持 平台、数据、界面、控制 和 过程集成，且支持小组工作方式，提供配置管理
4. 主要功能：
   1. 维护软件开发的一致性与完整性
   2. 实现配置管理及版本控制
   3. 支持数据的多种表示形式及自动转换
   4. 实现信息的自动检索与更新
   5. 提供项目控制和管理功能
   6. 支持开发方法学
5. 集成机制组成：
   1. 环境信息库：存储 与系统开发相关 的信息，是 SDE 的核心部分，支持多工具间的 信息交流与共享
   2. 过程控制与消息服务器：实现 过程集成和控制集成 的基础，通过控制流程、调度工具及传递消息来协调各个开发活动
   3. 环境用户界面：包括环境总界面以及各部件各工具的界面。具有一致的用户界面，可以发挥环境的优越性，提高工具的使用效率，减轻用户的学习负担

1. 概念

1. 定义：使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。
2. 目的：
   1. 确保软件的质量
   2. 确认软件以正确的方式做了用户所期望的事情
3. 主要工作：
   1. 发现软件的错误
   2. 有效定义和实现软件成分由底层至高层的组装过程
   3. 验证软件是否满足任务书和系统定义文档所规定的技术要求
   4. 为软件质量模型的建立提供依据
4. 基本原则：
   1. 测试能发现缺陷，但无法证明软件 “无缺陷” 或绝对正确
   2. 每个测试用例都必须定义预期的输出或结果
   3. 测试用例中不仅要说明合法有效的输入条件，还应该描述那些不期望的、非法的输入条件
   4. 缺陷的群集效应：80% 的软件错误都可以在大概 20% 的模块中找到根源（也称为二八原则）

1. 概念

1. 基于构件的软件工程（Component-Based Software Engineering，CBSE）是一种新型的软件开发模式，旨在通过 复用可重用的软件构件 来构造高质量、高效率的应用软件系统。这种模式强调 将软件系统分解为独立的构件，每个构件都 具有明确定义的功能和接口，可以 独立开发、测试和部署。
2. 是一种基于 分布对象技术、强调通过 可复用构件与构造软件系统 的软件复用途径（体现了购买而不是重新构造）。
3. 用于 CBSE 的构件应该具备以下特征：
   1. 可组装性：对于可组装的构件，所有外部交互必须通过公开定义的接口进行。同时它还必须提供对自身信息的外部访问。
   2. 可部署性：软件必须是 自包含 的，必须能作为一个独立实体在提供其构件模型实现的构件平台上运行。构件总是 二进制形式，无须在部署前编译。如果一个构件实现为一项服务，它不必由用户来部署，而是由服务的提供者来部署。
   3. 文档化：构件必须是 完全文档化 的，用户根据文档来判断构件是否满足需求。
   4. 独立性：构件应该是 独立 的，应该可以在无其他特殊构件的情况下进行组装和部署，如确实需要其他构件提供服务，则应显示声明。
   5. 标准化：构件标准化意味着在CBSE过程中使用的构件必须符合某种标准化的构件模型。此模型会定义构件接口、构件元数据、文档管理、组成以及部署。
   6. 可见性：没有（外部的）可见状态。构件本身不直接暴露外部可见状态，但可以通过运行时 容器（如应用服务器、框架等）管理状态并对外提供可见性。
4. CSBE 过程的主要活动：
   1. 面向复用的开发：
      1. 开发将被复用在其他应用程序中的构件或服务。它通常是对已存在的构件进行通用化处理。
   2. 基于复用的开发 （主要）：
      1. 复用已存在的构件和服务来开发新的应用程序。
      2. 开发过程：
         1. 系统需求概览
         2. 识别候选构件
         3. 根据发现的构件修改需求
         4. 体系结构设计
         5. 识别候选构件（构件定制与适配）
         6. 组装构件创建系统

1. 软件工程

1.1 软件生命周期

1. 软件定义时期：包括 可行性研究 和 详细需求分析 过程，任务是确定系统的功能需求与目标，具体可分成问题定义、可行性研究、需求分析等。
2. 软件开发时期：就是软件的设计与实现，将需求转化为可运行的软件系统，可分成 概要设计、详细设计、编码、测试 等。
3. 软件运行和维护：就是把软件产品移交给用户使用，对其进行运行管理、错误修复，功能改进和性能优化等。