软件工程

1. 软件工程

1.1 软件生命周期

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

1.2 软件系统文档

1. 软件系统的文档可以分为用户文档和系统文档两类
   1. 用户文档：主要描述系统功能和使用方法，并不关系这些功能是怎样实现的；
   2. 系统文档：描述系统设计、实现和测试等各方面的内容。

1.3 软件工程过程

1. 概念：指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动。
2. 软件工程过程包括以下4个方面（PDCA）：
   1. 计划（Plan）——软件规格说明。规定软件的功能及其运行时的限制。
   2. 执行（Do）——软件开发。开发出满足规格说明的软件。
   3. 检查（Check）——软件确认。确认开发的软件能够满足用户的需求。
   4. 处理（Action）——软件演进。软件在运行过程中不断改进以满足客户新的需求。

1.4 软件过程

1. 是制作软件产品的一组活动以及结果，主要由软件人员完成
2. 4 个环节：
   1. 软件描述（需求分析、规格说明）：定义了软件功能以及使用的限制
   2. 软件开发（设计、编码）：指实现阶段的开发性工作
   3. 有效性验证（测试、评审）：
   4. 软件演化（进化、维护、迭代优化）：对软件的修改与维护

2. 逆向工程

2.1 概念

1. 定义：分析现有程序，以更高的抽象形式表现来描述这个程序。
2. 目的：在于理解和分析现有系统的结构与功能。
3. 概念：
   1. 逆向工程：在软件生命周期内，将软件从一种形式转化为 更抽象 形式的活动。
   2. 重构：同一抽象级别 上转化系统描述形式
   3. 设计恢复：从已有程序中抽象出数据设计、总体结构设计和过程设计等信息（提升抽象）
   4. 再工程：基于逆向工程获得的信息，修改或重构 已有系统，产生系统**新版本**

2.2 抽象层次

逆向工程导出的信息分为四个抽象层次，从高到低依次为：

1. 领域级：反映程序在某个领域中的作用和价值，**最宏观**的角度
2. 功能级：体现 程序段 之间的功能关系（具体功能、程序段）
3. 结构级：体现 程序分量 之间的依赖关系，反映程序各部分之间相互依赖关系的信息，表现为各种系统结构图、结构图、调用图
4. 实现级：进一步细化，体现具体代码实现的细节，如 语法树 、符号表

（世仇结分工龄）：实现-抽象，结构-程序分量，功能-程序段，领域-领域

2.3 作用

在逆向工程中，系统源代码或已有工件经过分析、建模和转换，可以逐步恢复出更高层次的设计信息。特别是通过用户指导的搜索与变换方法，常常能够恢复：

1. 实现级（Implementation level）：即原始代码级别的信息，如函数、类、模块等。
2. 结构级（Structural level）：如系统组件之间的调用关系、模块划分、层次结构等架构信息。

3. 净室软件工程（CSE，Cleanroom Software Engineering）

3.1 概念

1. 净室软件工程是一种 应用数学与统计学理论 以经济的方式生产高质量软件的工程技术，力图通过严格的工程化的软件过程达到开发中的零缺陷或接近零缺陷。

3.2 特点

1. 是一种开发成本很高的软件开发方法，是一种形式规格说明设计和正确性验证。
2. 通过设计阶段的 正确性验证，能够在源头上消除缺陷，因此大大提高了软件的质量和可靠性。

3.3 两个核心理论基础

1. 函数理论：用于形式化描述软件系统的行为，强调通过数学函数来构建无错误的软件系统。软件的每个模块都被建模为数学上的函数，保证其行为的可预见性和正确性。
2. 抽样理论：应用在软件的统计测试阶段，通过对输入空间的合理抽样来评估软件的可靠性，而不是全面穷举测试。

3.4 技术手段

1. 统计过程控制下的增量式开发
2. 基于函数的规范与设计
3. 正确性验证（CSE的核心）
4. 统计测试和软件认证

4. 统一过程模型（Retional Unified Process，RUP）

4.1 RUP 软件开发周期

RUP 软件开发周期是一个二维的软件开发模型，横轴为时间，纵轴为工作流，包括 9 个核心工作流，主要分为两类：

1. 核心过程工作流（6 个，关注软件交付的过程）：
   1. 业务建模：评估待开发系统
   2. 需求：定义系统功能及用户界面
   3. 分析与设计：将需求分析的结果转化为分析与设计模型
   4. 实现：开发和单元测试
   5. 测试：集成测试
   6. 部署：打包、分发、安装、升级
2. 支持工作流（3 个，保障开发过程）：
   1. 配置与变更管理：跟踪与维护
   2. 项目管理：提供计划、人员分配、监控方面的指导
   3. 环境：提供过程管理和工具的支持

4.2 特点

1. 以用例驱动：使用用例来驱动整个开发过程，贯穿需求分析、设计、实现和测试。用例帮助开发团队理解用户需求，并保持开发工作的业务一致性。
2. 以体系结构为中心：围绕整个体系结构展开，与代码设计无关。RUP 强调在项目早期构建系统的核心架构，架构贯穿于整个开发过程，指导系统设计和实现。
3. 迭代和增量：把整个项目的开发分成多个迭代，每个迭代周期交付可运行的软件版本，不断完善系统。

4.3 优势

1. 允许在早期就实现和验证关键架构，提前发现并处理重大风险，提供架构指导开发，不断适应需求，早期快速得到原型，提高开发效率

4.4 阶段

RUP 将软件开发生命周期划分为多个循环，每个循环生成产品的一个新的版本，每个循环依次由 4 个连续的阶段组成，每个阶段完成确定的任务：

1. 初始：定义最终产品视图和业务模型（确定该迭代的项目范围、业务模型）
2. 细化：确定系统的体系结构，制定详细的计划（建立架构、分析问题）
3. 构造：构造产品并继续演进需求、体系结构、计划直至产品提交（开发实现）
4. 交付/移交：把产品提交给用户使用（测试、交付、确认）

4.5 核心概念

1. 角色（Role）：Who，描述某个人的行为与职责
2. 活动（Activity）：How，有明确目的的独立工作单元
3. 制品（Artifact）：What，是活动生成、创建或修改的一段信息
4. 工作流（Workflow）：When，描述一个有意义的连续活动序列

4.6 采用“4+1”视图模型描述软件系统的体系结构

RUP “4+1” 视图模型

1. 逻辑视图：对应最终用户，描述对象模型，支持功能性需求（描述系统为用户提供哪些服务），常用**类图**、对象图、状态图、协作图表示
2. 实现视图：对应程序员，常用包图、组件图、状态图表示
3. 进程视图：对应系统集成人员，考虑非功能性需求，常用活动图、流程图表示
4. 部署视图：对应系统工程师，考虑如何把软件映射到硬件上，常用部署图表示

5. 软件过程模型

5.1 瀑布模型

1. 特点：严格区分阶段，因果关系紧密相连，上一阶段的输出是下一阶段的输入，不可逆
2. 5 个阶段：
   1. 需求分析和定义
   2. 系统和软件设计
   3. 实现与单元测试
   4. 集成与系统测试
   5. 运行与维护
3. 缺点：需求难以一次确定，变更代价高，严格串行化，很长时间才能看到结果。要求每个阶段一次性完全解决该阶段工作，不现实。
4. 适用于：需求固定、明确 的项目。

5.2 增量模型 / 增量开发

1. 概念：
   1. 将系统分为多个可独立运行的子系统或模块，按照模块完成的顺序逐步实现系统功能，每个迭代周期都会新增一部分功能，最终达到完整系统的目的。
   2. 每个增量都是可交付、可使用的 成品，客户 可以在早期就使用并获得价值，同时降低需求变更的成本。
2. 特点：分批次地交付功能模块，每次在已有的系统上添加一些新功能，可以快速交付核心功能。
3. 适用于：需求部分明确，并且随时可能产生新的需求

快速应用开发（RAD）：

利用基于构件的思想，大量复用现有构件来快速构建系统，特别适合系统模块化程度高的项目，这样可以直接替换或组合现有构件实现功能。

5.3 快速原型模型 / 演化模型

1. 特点：快速地构建原型去验证需求，再根据用户给出反馈去迭代，减少需求变更带来的风险。
2. 适用于：需求变化大、需求不明确，需要探索和创新的项目。
3. 两个阶段：
   1. 原型开发阶段：快速构建、验证和修改原型以明确需求
   2. 目标软件开发阶段：根据确认需求进行系统化开发
4. 两种类型：
   1. 抛弃型原型：原型作为手段，需求确认后抛弃不用，继续用瀑布模型
   2. 演化型原型：需求确认后，不断补充和完善原型，直至形成完整的产品

5.4 螺旋模型

1. 特点：基于 快速原型模型，是一个 迭代 的过程，融入了 增量 的思想。将瀑布模型和客户评估结合起来。
2. 四个阶段：
   1. 计划：目标设定
   2. 风险分析：评价方案、识别风险、消除风险、建造原型
   3. 开发：验证阶段性软件产品
   4. 评估：制定下阶段计划
3. 适用于：大型、复杂项目，面向规格说明、面向过程、面向对象的软件开发方法，强调风险分析

5.5 喷泉模型

1. 概念：
   1. 是一种 以用户需求为动力，以对象为驱动 的模型，主要用于描述面向对象的软件开发过程。
   2. 是一种特别适用于面向对象开发的模型。它强调需求与对象的相互关系，通过持续的需求收集、设计和实现过程，逐步构建系统。
2. 特点：
   1. 以需求驱动，面向对象的迭代开发，没有明确的阶段划分，需求、设计、实现都是重叠进行的。
   2. 各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。

5.6 变换模型

1. 概念：是基于形式化规格说明语言和程序变换的软件开发模型，需要严格的数学理论和一整套开发环境的支持。

5.7 V 模型

1. 特点：强调测试和开发是一一对应的，测试贯穿始终，但开发与测试不是同步进行。

V 模型

验收测试 --> 用户需求

1. 适用于：对可靠性要求高的项目
2. W 模型：开发和测试同时进行，是对 V 模型的补充

5.8 敏捷模型

1. 特点：小步快跑，迭代增量，用户参与响应变化，面向用户。
2. 敏捷宣言：
   1. 个体和交互胜过过程和工具
   2. 可工作的软件胜过大量的文档
   3. 客户合作胜过合同谈判
   4. 响应变化胜过遵循计划
3. 敏捷方法：
   1. 强调 短周期、快速反馈、持续改进，采用 迭代和增量式 开发模式
   2. 以 原型开发思想 为基础，强调快速构建可运行的版本，频繁交付 并获取用户反馈
   3. 强调团队协作、个人价值、沟通与信任，关注开发人员的积极性和创造力，而非过分依赖流程和工具
   4. 是“适应性”而非“预设性”的；是“面向人的”而非“面向过程的”，要求 快速产出原型
4. 开发方法：
   1. 极限编程（XP）：强调高纪律，高效、低风险、测试先行
      1. 核心流程：
         1. 测试驱动开发（TDD）：先写测试用例，再实现对应功能
         2. 持续集成：频繁地集成代码，确保质量
         3. 结对编程：两个人一起协作完成代码，提升质量
         4. 知识共享以及重构
   2. 水晶系列方法（Crystal）：注重平衡、产出、效率和易操作性，不同项目采用不同策略（机动性），根据项目规模和优先级进行开发，注重沟通
   3. 并列争球法（Scrum）：重视可重复的方法过程和环境，侧重项目管理
      1. 角色：
         1. 产品负责人：负责管理产品待办列表，确定优先级
         2. Scrum Master：消除障碍，促进流程执行
         3. 开发团队：自组织、跨职能，负责交付增量
      2. 工件：
         1. 产品待办列表（Product Backlog）：按照优先级排序的需求集合
         2. 冲刺待办列表（Sprint Backlog）：冲刺期内要完成的需求列表
         3. 潜在可交付的增量（PSPI）：每个冲刺完成时必须完成的可用功能
      3. 事件：
         1. 冲刺 Sprint
         2. 冲刺计划会议（冲刺评审会议、冲刺回顾会议）
         3. 每日站会：同步进度，解决阻塞问题
      4. 工具：
         1. 燃尽图：跟踪剩余工作量
         2. Scrum 板：可视化任务状态
   4. 特征驱动开发方法（FDD）：以功能为中心，短迭代开发。强调阶段短、功能模块可见可用
      1. 三要素：人、过程、技术
      2. 将开发人员分类：
         1. 指挥者（首席程序员）：负责整体设计和任务分配
         2. 类程序员：负责具体实现
   5. 开放式源码开发方法（Open source）：高并行性排障
   6. 自适应性软件开发方法（ASD）：分为三个非线性的开发阶段
   7. 动态系统开发方法（DSDM）：强调业务需求的优先级，确保先交付有价值的项目
5. 敏捷方法的原则：
   1. 欢迎需求的变化
   2. 可工作的软件是进度的首要度量标准
   3. 自组织团队产生最佳架构和设计
   4. 团队定期反思并调整行为
6. 敏捷方法的核心价值：客户合作、响应变化、可工作的软件、个体和互动。强调短周期迭代、快速响应变化、团队协作与客户参与。
7. 典型框架

5.9 软件统一过程（RUP）模型

1. 特点：用例驱动、以架构为中心、迭代和增量
2. 四个阶段：初始、细化、构造、移交
3. 适用于：大型、面向对象的系统，强调风险控制

5.10 基于构件的模型

1. 特点：以可复用的构件为核心，通过构件的选取、组建、实现系统开发，减少开发代码
2. 优点：提高开发效率，降低成本
3. 适用于：有成熟构件库的领域

6. 软件能力成熟度

6.1 软件能力成熟度模型（CMM，Capacity Maturity Model for Software）

1. 概念： CMM 是一种用于评估和改进软件开发过程能力的模型，通过分级的成熟度水平为组织提供过程改进的指导路径。
2. 分为五个成熟度等级：
   1. 初始级：随意且混乱无序，高度依赖程序员的个人能力，并且项目的成功与否有一定的运气成分。流程随意、混乱，依赖个人能力和英雄主义精神。
   2. 可重复级：基本建立项目的管理过程，可以重复借鉴以往项目成功的经验。项目层面的流程被规划、文档化、执行、监控和控制，能满足成本、进度和质量目标。
   3. 已定义级：软件过程被标准化、文档化，形成组织级的基本过程。组织层面形成了标准化、制度化的管理流程，并根据自身特点进行定义；开始收集项目的经验资产，确保过程一致性。
   4. 已管理级（量化级）：对过程和产品进行**量化的管理，通过数据指标**控制过程。建立产品质量、服务质量和过程性能的定量目标，能够预测和控制过程性能。
   5. 优化级：通过持续的增量式和创新式改进，利用多个项目收集的数据优化过程性能，无限进步。

6.2 软件能力成熟度模型集成（CMMI，Capability Maturity Model Integration for Software）

1. 概念：是在 CMM 基础上发展而来的一种软件能力成熟度评估标准，用于指导软件开发过程的演进和进行软件开发能力的评估。
2. 包含 5 个层级，从低到高为：
   1. 初始级（Initial）：流程随意、混乱，依赖个人能力和英雄主义精神。（过程是不可预测、反应式的）
   2. 已管理级（Managed）：项目及流程被规划化、文档化、执行和监控，设定明确的目标，能满足成本、进度和质量目标。（基本项目管理过程得到实施）
   3. 已定义级（Defined）：组织层面形成了标准化、制度化的管理流程，并根据自身特点进行定义；开始收集项目的经验资产，确保过程一致性。（过程被文档化、标准化）
   4. 量化管理级（Quantitatively Managed）：建立产品质量、服务质量和过程性能的**定量目标**，能够预测和控制过程性能。（使用度量控制过程）
   5. 优化级（Optimizing）：可通过增量式和创新式改进，去持续优化过程，并利用多项数据提升组织整体绩效。（持续过程改进）

6.3 CMMI 体系文件层次结构

1. 基于 CMMI 建立，体系文件的层次结构一般分为四层（从上到低，从抽象到具体）：
   1. 顶层方案：位于体系文件的最高层，用于制定质量管理的总体目标和方向，为下级文件提供指导原则。
   2. 过程文件：位于第二层，描述各个过程域的具体活动、步骤和职责，是体系运行的主要依据。（根据过程文件模板，对流程进行描述）
   3. 规程文件 ：位于第三层，对过程文件中的某些步骤进行细化，提供具体的执行规则和标准。（清晰地描述如何完成这项工作）
   4. 模板类文件：位于最底层，用于规范相关文档和记录的格式，如 Word 模板、Excel 表格等，是实际操作的工具支持。

6.4 数据管理能力成熟度评估模型（DCMM）

1. 是我国首个数据管理领域的国家标准。
2. 该框架将组织数据管理能力划分为 8 个能力域，分别为：
   1. 数据战略
   2. 数据治理
   3. 数据架构
   4. 数据标准
   5. 数据质量
   6. 数据安全
   7. 数据应用
   8. 数据生存周期

7. 软件重用

7.1 概念

1. 指将已有的软件资产（如代码、设计、架构等）在新的软件项目中加以复用，以提高开发效率、降低成本和保证质量。
2. 在软件开发过程中重复使用相同或相似的软件元素通常被称为**软件部件**。

7.2 可重用的软件元素（软件部件）

1. 需求分析文档
2. 设计文档
3. 程序代码
4. 测试用例
5. 领域知识（专业知识）

7.3 软件重用的类型

1. 垂直式重用（纵向）：局限于某一特定领域，更具有针对性（银行系统的核心模块、电力系统）
2. 水平式重用（横向）：适用于不同领域，重用的范围更广（通用的 UI 设计、标准函数库）

7.4 双生命周期模型

在软件复用开发方法中，双生命周期模型是指两个并行且相互关联的开发过程，这两个生命周期分别是：

1. 领域工程（代表复用资产的生产）：主要负责分析并构建可复用的软件资产（如通用组件、框架等）
2. 应用工程（代表复用资产的使用）：基于这些资产快速构建具体应用

8. 软件方法学

8.1 各种开发方法

1. 自顶向下 开发方法：先对最高层次中的问题进行定义、设计、编程和测试，而将其中未解决的问题作为一个子任务放到下一层次中去解决
2. 自底向上 开发方法：根据系统功能要求，从具体的器件、逻辑部件或者相似系统开始，通过对其进行相互连接、修改和扩大，构成所要求的系统
3. 形式化 开发方法：建立在严格数学基础上的软件开发方法
4. 非形式化 开发方法：不强调严格的数学论证，会更灵活一些

8.2 形式化开发方法

1. 开发过程：
   1. 可行性分析：
   2. 需求分析：
   3. 体系结构设计：
   4. 详细设计：
   5. 编码：
   6. 测试发布：

8.3 自顶向下与自底向上开发方法的区别

	自顶向下	自底向上
开发顺序	⬇️	⬆️
测试方法	桩模块，模拟下层对上层的数据	驱动模块，模拟上层对下层调用
构建原型	强（快速搭建整体框架）	弱（客户不易直观感受到）
适用场合	需求要清晰，强调全局性、一致性	顶层需求不清楚，底层技术复杂
团队要求	统一顶层思维	集成难度大（困难），可以并发开发模块

8.4 接口标准化

1. 目的：确保不同系统或构件之间能够一致、可靠地交互，从而实现复用与互操作。
2. 标准化的重点在于 统一消息的模式（message pattern）、消息的结构和数据编码格式，以及消息传输协议，以保证不同构件或系统间能够互通。

9. 系统移植

9.1 概念

1. 指新系统开发完毕，投入运行，取代现有系统的过程，需要考虑多方面的问题，以实现与老系统的交接。
2. 是系统构建的一种实现方法。

9.2 三种转换方法

1. 直接转换：现有系统被新系统直接取代了，风险很大，适用于新系统不复杂，或者现有系统已经不能使用的情况。优点是节省成本。
2. 并行转换：新系统和老系统并行工作一段时间，新系统经过试运行后再取代，若新系统在试运行过程中有问题，也不影响现有系统的运行，风险极小，在试运行过程中还可以比较新老系统的性能，适用于大型系统。缺点是耗费人力和时间资源，难以控制两个系统间的数据转换。
3. 分段转换：分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统，依次试运行每个子系统，成熟一个子系统，就转换一个子系统。同样适用于大型项目，只是更耗时，而且现有系统和新系统间混合使用，需要协调好接口等问题。

9.3 五个阶段

1. 计划：**调查**和整理现有系统，明确移植的目标，评估移植的可行性，并确定移植方法（定大方向）
2. 准备：开展移植研究，准备所需的资料
3. 转换：将程序设计和数据，转换为新机器可运行的形式来提高工作精度
4. 测试：对整个程序进行单元测试，核实在新的系统下的正常工作能力
5. 验证：核实整个系统的工作情况，准备正式运行

9.4 数据转换与迁移的方法

1. 系统切换前通过工具迁移
2. 系统切换前采用手工录入
3. 系统切换后通过新系统生成

10. 系统维护

10.1 定义

1. 维护人员理解、改正、改动和改进这个软件的难易程度。

10.2 评价指标

1. 易分析性：软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。
2. 易改变性：软件产品使指定的修改可以被实现的能力，实现包括编码、设计和文档的更改。
3. 稳定性：软件产品避免由于软件修改而造成意外结果的能力。
4. 易测试性：软件产品使已修改软件能被确认的能力。
5. 维护性的依从性：软件产品遵循与维护性相关的标准或约定的能力。

10.3 系统维护类型

1. 硬件维护
2. 软件维护，具体类型如下：
   1. 改正性 维护：有 bug，改错
   2. 适应性 维护：适应环境（适应原生鸿蒙）
   3. 完善性 维护：改善体验，做得更好（新的功能、性能要求）
   4. 预防性 维护：潜在问题，预防将来（修复 xxx 安全补丁）
3. 数据维护

11. 模型驱动体系结构

1. 以模型为核心，分为不同抽象层次：
   1. 计算无关模型（CIM）：描述业务领域的高层抽象，与系统实现细节无关，主要用于领域分析阶段。
   2. 平台无关模型（PIM）：描述系统的结构和行为，对系统进行详细建模，但不涉及具体平台实现，能够通过转换生成不同平台的模型。
   3. 平台相关模型（PSM）：在 PIM 基础上增加特定平台的实现细节，可直接生成目标平台的代码。

12. DO-178 中的适航要求核心要素

12.1 三大核心元素

1. 适航目标（Objectives）：
   1. 适航目标是软件必须达成的最终状态或结果，是整个体系的起点和核心。其本质是“基于风险的安全性要求”
2. 完成这些目标所需的活动（Activities）：
   1. 活动是为实现适航目标而开展的具体过程和操作，是连接目标与结果的桥梁。其特点是“针对性”和“可操作性”
3. 用于证明目标达成的数据（Software Life Cycle Data）：
   1. SLCD 是活动执行的可追溯记录，是向适航当局证明“目标已达成”的唯一依据。其核心作用是“可验证性”和“可重现性”

12.2 三者的闭环关系

1. 关系：目标→活动→数据→目标验证
2. 目标驱动活动：先明确“要达成什么”（目标），再规划“怎么做”（活动）；
3. 活动产生数据：活动的每一步都留下记录（SLCD），证明“做了什么”；
4. 数据验证目标：通过审查SLCD，确认活动是否按要求执行、是否达成目标，最终形成“目标是否满足”的结论。

13. 其他

1. 发现系统性能方面的问题需要实机运行，一般在系统集成、运行阶段。
2. 工作流 用于表示业务过程模型，强调业务活动的顺序、条件、并发与同步等，通常采用图形化符号进行描述。常见的业务流程建模方法包括：
   1. 流程图（Flowchart）
   2. 角色活动图与角色交互图
   3. IDEF0 与 IDEF3
   4. 高级 Petri 网（High-level Petri Net）
   5. UML 活动图（Activity Diagram）
   6. 业务流程建模标注（BPMN）