5.1 软件工程定义

软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。

  • 软件工程组成
    • 方法：是完成软件项目的技术手段，它支持整个软件生命周期
    • 工具：是人们在开发软件的活动中智力和体力的扩展与延伸，它自动或半自动地支持软件的开发和管理，支持各种软件文档的生成
    • 过程：过程贯穿于软件开发的各个环节，是指为获得软件产品，在软件工具的支持下由软件工程师完成的一系列软件工程活动。管理人员在软件工程过程中，要对软件开发的质量、进度、成本进行评估、管理和控制，包括人员组织、计划跟踪与控制、成本估算、质量保证

5.2 软件需求

软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。根据 IEEE 的软件工程标准词汇表，软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

  • 功能：登录注册、浏览购买、支付分享等
  • 行为：登录行为验证用户的账户密码
  • 性能：1秒内完成搜索、并发请求
  • 设计约束：支持多端运行、密码加密

5.2.1 需求的层次

软件需求就是系统必须完成的事和必须具备的品质。需求是多层次的，包括业务需求、用户需求和系统需求，这 3 个不同层次从目标到具体，从整体到局部，从概念到细节。

  • 业务需求：指反映组织机构或用户对系统、产品高层次的目标要求，从总体上描述了为什么要达到某种效应，组织希望达到什么目标。通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。如 用户要开发一个 购物商城
  • 用户需求：描述的是用户的具体目标，或用户要求系统必须能完成的任务和想要达到的结果，这构成了用户原始需求文档的内容。如 购物商城要包括 商品浏览、购买、分享等
  • 系统需求：是从系统的角度来说明软件的需求，包括功能需求、非功能需求和约束等。
    • 功能需求（行为需求）：规定开发人员必须在系统中实现的软件功能，用户利用这些功能完成业务任务；一组逻辑相关的功能需求称为特性。如 商品的增删改查
    • 非功能需求：系统必须具备的属性 / 品质，分为软件质量属性（易用性、可维护性、效率等）、其他非功能需求，包含产品需遵从的标准、规范、合约。性能方面的要求 如1秒内查询出结果 多语言等
    • 约束：对软件设计、开发的限制，分为设计约束、过程约束；如 必须使用国产数据库、运行在开源操作系统。

5.2.2 质量功能部署 QFD

质量功能部署（Quality Function Deployment, QFD）：将用户要求转化成软件需求的技术，最大化提升用户满意度，将需求分为 3 类：

  • 常规需求：用户默认系统该有的功能，实现越多满意度越高。
  • 期望需求：用户默认必备、但无法清晰描述的需求；未实现会严重降低满意度。
  • 意外需求（兴奋需求）：超出用户预期的功能，实现用户会惊喜，不实现不影响购买决策。

5.2.3 需求获取

需求获取：确定、理解各干系人对系统的需求与约束的过程。
常用方法：用户访谈、问卷调查、采样、情节串联板、联合需求计划。

5.2.4 需求分析

需求分析：把杂乱的用户诉求转化为规范、清晰的用户需求。
合格需求特性：必要性、完整性、确定性、正确性、一致性、无二义性、可跟踪性、可测试性。

一、结构化分析 SA
结构化分析 (StructuredAnalysis,SA)方法给出一组帮助系统分析人员产生功能规约的原理与技术，其建立模型的核心是数据字典。围绕这个核心，有3个层次的模型，分别是数据模型、功能模型和行为模型 (也称方状态模型)。

  • 数据模型：E-R 图（实体关系图），描述实体、属性、实体间关系
  • 功能模型：DFD 数据流图，从数据传递、加工角度，逐层拆解系统功能
  • 行为模型：STD 状态转换图，通过状态、触发事件描述系统运行行为

1）结构化分析步骤

  1. 分析业务，绘制当前物理模型 DFD
  2. 推导等价逻辑模型 DFD
  3. 设计新逻辑系统，生成数据字典、基元描述
  4. 搭建人机接口，输出多套目标系统物理 DFD 方案
  5. 评估各方案成本、风险等级
  6. 选定最优方案
  7. 编制完整需求规约

2）DFD 数据流图建模：又称过程/功能建模，核心是数据流，图形化描述业务数据处理流程。
四大基础元素：数据流、处理/加工、数据存储、外部项。
建立DFD图的目的是描述系统的功能需求。
建模步骤：

  1. 明确项目目标，划定系统边界
  2. 绘制顶层 DFD
  3. 分解绘制第一层 DFD
  4. 搭建分层 DFD 结构图
  5. 校验、确认 DFD 图

3）数据字典：记录系统元数据的查询目录，为 DFD 所有元素提供标准化定义，是需求分析核心工具。 数据字典包含 5 类内容：

  1. 数据项：最小数据单元定义（如学号、姓名）
  2. 数据结构：多个数据项组合结构
  3. 数据流：DFD 中流动数据说明
  4. 数据存储：持久化存储的数据集合说明
  5. 处理过程：DFD 加工模块逻辑说明

二、面向对象分析 OOA
核心思路：基于调研素材归类整理对象，而非梳理业务流程现状。

  1. 五层模型：主题层、对象类层、结构层、属性层、服务层
  2. 两类对象结构
    • 分类结构：一般类 ↔ 特殊类（继承关系）
    • 组装结构：整体 ↔ 部分（聚合 / 组合）

1）OOA 九大基本原则

  1. 抽象：抽取事物共同本质特征
  2. 封装：隐藏对象内部实现细节，仅对外暴露接口
  3. 继承：特殊类复用一般类全部属性与服务
  4. 分类：相同属性、服务的对象归为同一类
  5. 聚合（组装）：复杂对象由多个简单对象组成
  6. 关联：对象之间存在业务联系
  7. 消息通信：对象仅通过消息交互，禁止直接访问内部属性
  8. 粒度控制：分层次关注细节，暂时忽略无关内容
  9. 行为分析：梳理对象之间相互依赖的行为逻辑

2）OOA 五大步骤

  1. 识别对象与类
  2. 识别类之间结构
  3. 定义业务主题
  4. 定义类属性
  5. 定义类方法（服务）

5.2.5 需求规格说明书 SRS

软件需求规格说明书（Software Requirement Specification, SRS） 是在需求分析阶段需要完成的文档，是软件需求分析的最终结果，是确保每个要求得以满足所使用的方法。SRS是软件开发过程中最重要的文档之一，任何规模和性质的软件项目都不应该缺少。
SRS应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。
一般通过需求评审和需求测试工作来对需求进行验证。

5.2.6 需求变更

变更产生原因：需求获取遗漏、需求理解偏差、业务流程发生变化。

1) 变更完整管理流程

  1. 问题分析与变更描述：梳理变更诉求，形成标准化变更申请
  2. 变更分析与成本计算：评估变更影响范围、全流程改动成本，决策是否批准变更
  3. 变更实现：获批后按开发模型落地修改
    • 计划驱动模型：回溯至需求阶段，重新走需求→设计→编码→测试
    • 敏捷模型：变更纳入下一轮迭代开发

2) 通用变更策略

  1. 所有变更必须走标准化变更控制流程
  2. 未审批变更，禁止开展设计、编码工作
  3. 变更由 CCB（变更控制委员会）决策是否落地
  4. 项目所有干系人有权知晓变更内容
  5. 原始变更申请文档不可删除、修改
  6. 每一条落地变更，必须可追溯至已审批变更请求

3) CCB 变更控制委员会

  • 定位：项目决策机构，不负责编写变更方案，仅评审裁定变更
  • 组成：甲方客户、产品、项目、开发、测试、质量、运维、配置管理等多方代表
  • 核心工作：
    1. 制定决策：规定参会人数、投票 / 一致通过等决策规则、主席否决权限
    2. 交流情况：审批结果同步全部相关人员，更新变更申请状态
    3. 重新协商约定：变更落地协商调整工期、人力、优先级、质量标准

5.2.7 需求跟踪

需求跟踪：建立 需求-设计-代码-测试 全链路对应关系，保障交付成果匹配用户需求。
两种跟踪方式：

  1. 正向跟踪：校验 SRS 每条需求，在后序设计/代码/测试中存在对应实现 根据文档核对软件功能
  2. 逆向跟踪：校验设计/代码/测试用例，都能溯源到原始需求 根据软件功能核对是否和文档匹配

不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。
需求跟踪是一个要求手工操作且劳动强度很大的任务，需要组织提供支持。在实际项目中，往往采用专门的配置管理工具来实现需求跟踪。

5.3 软件设计

需求阶段解决「做什么」；
软件设计阶段解决「怎么做」。分为结构化设计、面向对象设计两大体系。

5.3.1 结构化设计 SD

面向数据流的设计方法，以 需求规划说明书SRS、数据流图DFD、数据字典为输入，自顶向下逐层分解、模块化。
分为两大阶段：

  1. 概要设计（总体结构设计）：划分系统模块，定义模块功能、接口、调用关系，输出系统结构图 SC
  2. 详细设计：定义每个模块内部实现细节，包含 IO、流程、存储、界面、安全设计等

1） 模块结构

  1. 信息隐藏与抽象：模块内部实现细节封装隐藏，外部仅能调用接口，模块为「黑盒」
  2. 模块化：模块是系统最小功能单元，三大属性；设计先定义外部接口，再实现内部逻辑
    • 功能（做什么）
    • 逻辑（怎么做）
    • 状态（该模块使用的环境和条件）
  3. 耦合（模块间关联强度）：耦合度越低越好，从低到高排序：
    • 非直接耦合 ：两个模块之间没有直接关系，它们之间的联系完全是通过上级模块的控制和调用来实现的
    • 数据耦合 ：-组模块借助参数表传递简单数据
    • 标记耦合 ：一组模块通过参数表传递记录等复杂信息（数据结构）
    • 控制耦合 ：模块之间传递的信息中包含用于控制模块内部逻辑的信息
    • 通信耦合 ：一组模块共用了一组输入信息，或者它们的输出需要整合，以形成完整数据，即共享了输入或输出
    • 公共耦合 ：多个模块都访问同一个公共数据环境，公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等
    • 内容耦合 ：个模块直接访问另一个模块的内部数据；一个模块不通过正常入口转到另一个模块的内部；两个模块有一部分程序代码重叠；一个模块有多个入口等
  4. 内聚（模块内部关联性）：内聚度越高越好，从高到低排序：
    • 功能内聚 ：完成一个单一功能，各个部分协同工作，缺一不可
    • 顺序内聚 ：处理元素相关，而且必须顺序执行
    • 通信内聚 ：所有处理元素集中在一个数据结构的区域上
    • 过程内聚 ：处理元素相关，而且必须按特定的次序执行
    • 时间内聚 ：所包含的任务必须在同一时间间隔内执行
    • 逻辑内聚 ：完成逻辑上相关的一组任务
    • 偶然内聚 ：完成一组没有关系或松散关系的任务

2） 系统结构图 SC
系统结构图（Structure Chart），SC 又称为模块结构图，它是软件概要设计阶段的工具，反映系统的功能实现和模块之间的联系与通信，包括各模块之间的层次结构，即反映了系统的总体结构。

详细设计的主要任务是设计每个模块的实现算法、所需的局部数据结构。
详细设计的目标有两个：实现模块功能的算法要逻辑上正确；算法描述要简明易懂。
详细设计必须遵循概要设计来进行。详细设计方案的更改，不得影响到概要设计方案；如果需要更改概要设计，必须经过项目经理的同意。详细设计应该完成详细设计文档，主要是模块的详细设计方案说明。

3） 详细设计表达工具

  • 图形工具
    • 业务流程图：是一种描述管理系统内各单位、人员之间的业务关系、作业顺序和管理信息流向的图表。业务流程图的绘制是按照业务的实际处理步骤和过程进行的，它用一些规定的符号及连线表示某个具体业务的处理过程，帮助分析人员找出业务流中的不合理流向。
    • 程序流程图（框图）：又称为程序框图，是使用最广泛的一种描述程序逻辑结构的工具。它用方框表示一个处理步骤，用菱形表示一个逻辑条件，用箭头表示控制流向。其优点是结构清晰，易于理解，易于修改； 缺点是只能描述执行过程而不能描述有关的数据。
    • NS 流程图（盒图）：也称为盒图或方框图，是一种强制使用结构化构造的图示工具。其具有以下特点：功能域明确，不可能任意转移控制，很容易确定局部和全局数据的作用域，很容易表示嵌套关系及模板的层次关系。
    • PAD 图（问题分析图）：是一种改进的图形描述方式，可以用来取代程序流程图，比程序流程图更直观，结构更清晰。最大的优点是能够反映和描述自顶向下的历史和过程。PAD提供了5种基本控制结构的图示，并允许递归使用。
    • 系统结构图
  • 表格工具：判定表，描述多条件组合对应操作
  • 语言工具：PDL 过程设计语言（伪代码）
    • 优点：可嵌入源代码注释、文本工具编辑、可自动生成代码
    • 缺点：直观性弱，复杂条件逻辑不如判定树清晰
    • 过程设计语言

5.3.2 面向对象设计 OOD

面向对象设计OOD其基本思想包括抽象、封装、可扩展性，其中可扩展性主要是通过继承和多态来实现。
OOD的主要任务是对类和对象进行设计，这是OOD中最重要的组成部分，也是最复杂和最耗时的部分。其主要包括类的属性、方法，以及类与类之间的关系。
常用的面向对象设计原则包括：

  • 单职原则：一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。
  • 开闭原则：对扩展开放，对修改封闭。
  • 里氏替换原则：子类可以替换父类，即子类可以扩展父类的功能，但不能改变父类原有的功能。
  • 依赖倒置原则：要依赖于抽象，而不是具体实现；要针对接口编程，不要针对实现编程。
  • 接口隔离原则：使用多个专门的接口比使用单一的总接口要好。
  • 组合重用原则：要尽量使用组合，而不是继承关系达到重用目的。
  • 迪米特原则（最少知识法则）：一个对象应当对其他对象有尽可能少的了解。其目的是降低类之间的耦合度，提高模块的相对独立性。

三类核心类

  1. 实体类：映射业务实体，持久化存储数据（学员、订单、商品）
  2. 控制类：管控用例业务流程，动宾结构命名（登录校验器、订单处理器）
  3. 边界类：系统与外部交互接口，包含页面、报表、硬件外设、第三方系统对接接口

5.3.3 统一建模语言 UML

UML 是统一建模语言，非编程语言，用于可视化软件系统模型。
三大组成：构造块、规则、公共机制。

1） UML 四类事物（建模元素）

  1. 结构事物（静态）：类、接口、协作、用例、活动类、构件、节点（7 种）
  2. 行为事物（动态）：交互（对象消息交互）、状态机（对象状态流转）
  3. 分组事物：包，用于归类组织模型元素
  4. 注释事物：模型文字说明、备注

2） UML 四大关系

  1. 依赖：一方变化影响另一方
  2. 关联：对象之间长期业务联系
  3. 泛化：一般类与特殊类（继承）
  4. 实现：类实现接口约定的契约

3） UML的14种标准图

  • 静态结构图
    • 类图：类图描述一组类、接口、协作、和它们之间的关系，类图给出系统静态设计视图，活动类的类图给出了系统的静态进程视图。
    • 对象图：对象图描述一组对象及他们之间的关系。
    • 构件图：构件图描述一个封装的类和它的接口、端口、以及由内嵌的构件和连接件构成的内部结构。
    • 组合结构图：组合结构图描述结构化类的内部结构（例如，构件或类），包括结构化类与系统其余部分的交互点。
    • 制品图：制品图描述计算机中一个系统的物理结构，制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图在一起使用。制品也给出了他们的实现的类和构件。
    • 部署图：部署图描述对运行时的处理节点及在其中生存的构件配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。
    • 包图：包图描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。
  • 需求图
    • 用例图：用例图描述一组用例、参与者及它们之间的关系。
  • 交互图（动态）
    • 顺序图：顺序图是一种交互图，交互图展示了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图关注于系统的动态视图。顺序图是强调消息的时间次序的交互图。
    • 通信图：通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图强调的时序，通信图强调的对象之间的组织机构关系。
    • 定时图：定时图也是一种交互图，他强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序。
    • 交互概览图：交互概览图是活动图和顺序图的混合物。
  • 行为图
    • 状态图：状态图描述一个状态机，它由状态、转移、事件和活动组成，状态图给出了对象的动态视图。
    • 活动图：活动图将进程或其他计算机结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图，它强调对象间的控制流程。

4） UML 五大视图

  1. 逻辑视图（设计视图）：类、子系统、业务架构
  2. 进程视图：并发线程、同步机制
  3. 实现视图：代码文件、软件构件
  4. 部署视图：软件到硬件服务器的物理映射
  5. 用例视图：需求分析核心视图

5.3.4 设计模式

沉淀复用的成熟软件设计方案，分为两类划分维度：

  1. 按范围：类模式、对象模式
  2. 按用途三大类：
    • 创建型模式：负责对象创建（工厂、抽象工厂、单例、原型、建造者）单例、工厂、建造者
    • 结构型模式：类/对象组合组装（适配器、桥接、组合、装饰、外观、享元、代理）组合、代理、适配器
    • 行为型模式：对象交互、职责分配（责任链、命令、解释器、迭代器、中介、备忘录、观察者、状态、策略、模板方法、访问者）策略、状态、观察者

5.4 软件实现

5.4.1 软件配置管理 SCM

软件配置管理是一种标识、组织、控制修改的技术，贯穿全生命周期；解决变更带来的开发混乱。
核心目标：标识变更、控制变更、保障变更正确落地、同步变更信息。
两大核心：版本控制、变更控制。

  • 版本控制：追踪程序代码、配置文件及说明文档全生命周期修改记录，记录修改人、修改时间、修改内容。
  • 变更控制：不禁止变更，规范变更流程，保障变更有序落地。
  • SCM全套活动：配置管理计划、配置标识、配置控制、配置状态记录、配置审计、发布交付管理。

5.4.2 软件编码

软件编码：使用编程语言实现设计方案，代码质量根源取决于软件设计质量。

  1. 程序设计语言：根据业务场景、性能、生态选择语言 C、C++、Java
  2. 程序设计风格：源程序文档化、数据说明、语句结构、输入/输出方法
  3. 程序复杂性度量：量化代码复杂度，预估缺陷数量、开发工作量，作为模块规模上限
  4. 四大效率指标
    • 程序效率：执行速度、内存占用
    • 算法效率：运算耗时、存储开销
    • 存储效率：简化程序降低内存占用
    • IO 效率：区分人机交互 IO、硬件设备 IO 优化

5.4.3 软件测试

1） 测试方法

  • 静态测试：程序不运行，人工/工具分析代码、文档；无执行过程。
    • 文档测试：检查单评审需求、设计文档
    • 代码测试：桌前检查、代码走查、代码审查（同行评审）
  • 动态测试：运行程序执行测试用例，分为白盒、黑盒：
    • 白盒测试（结构测试）：透明查看代码内部逻辑，多用于单元测试；白盒测试方法主要有控制流测试、数据流测试和程序变异测试等。核心技术：逻辑覆盖（语句、判定、条件、判定条件、条件组合、修正判定条件、路径覆盖）
    • 黑盒测试（功能测试）：不关注内部代码，仅校验输入输出；用于集成测试、确认测试、系统测试；方法：等价类、边界值、判定表、因果图、场景法、随机测试、错误推测

2） 测试类型

  1. 单元测试：针对单个模块，依据详细设计文档，白盒为主
  2. 集成测试：模块组装测试，校验接口交互问题；黑白盒结合，所有单元测试通过后开展
  3. 确认测试：确认测试主要用于验证软件的功能、性能和其他特性是否与用户需求一致
  4. 配置项测试：独立软件配置项完整测试，依据 SRS，前置单元 + 集成测试
  5. 系统测试：完整软件在真实硬件环境整体测试，功能、性能、安全、可靠性等全维度校验
  6. 回归测试：代码变更后，重测原有功能，保证修改不破坏原有业务逻辑

3） 面向对象测试
测试核心从「模块」转为「类」，覆盖分析、设计模型；重点针对封装、继承、多态三大特性设计用例。

4） 软件调试
测试发现缺陷后，定位、修复错误；三大调试策略：蛮力法、回溯法、原因排除法。

5.5 部署交付

5.5.1 软件部署

软件生命周期后期环节，通过配置、安装、激活保障软件稳定运行；配置错误是部署故障主要来源。

5.5.2 软件交付

传统的软件交付过程是指在编程序改代码之后，直到将软件发布给用户使用之前的一系列活动，如提交、集成、构建、部署、测试等。

5.5.3 持续交付

持续交付是一系列开发实践方法，用来确保代码能够快速、安全地部署到生产环境中。持续交付是一个完全自动化的过程，当业务开发完成的时候，可以做到一键部署。
持续交付提供了一套更完善的解决传统软件开发流程的方案，主要体现在：

  • 在需求阶段，抛弃了传统的需求文档的方式，使用便于开发人员理解的用户故事；
  • 在开发测试阶段，做到持续集成，让测试人员尽早进入项目开始测试；
  • 在运维阶段，打通开发和运维之间的通路，保持开发环境和运维环境的统

核心优势：

  1. 缩短代码提交至生产上线周期，降低发布风险
  2. 自动化快速反馈缺陷，提前修复
  3. 软件随时处于可发布状态
  4. 部署流程标准化，版本清晰
  5. 交付全过程可视化、可预期

5.5.4 持续部署

1） 持续部署方案
容器技术目前是部署中最流行的技术，常用的持续部署方案有 Kubernetes+Docker 和 Matrix 系统两种。

2） 部署原则

  • 部署包全部来自统一的存储库；
  • 所有的环境使用相同的部署方式；
  • 所有的环境使用相同的部署脚本；
  • 部署流程编排阶梯式晋级，即在部署过程中需要设置多个检查点，一旦发生问题可以有序地进行回滚操作；
  • 整体部署由运维人员执行；
  • 仅通过流水线改变生产环境，防止配置漂移；
  • 不可变服务器；
  • 部署方式采用蓝绿部署或金丝雀部署。

3） 部署层次 首先要明确部署的目的并不是部署一个可工作的软件，而是部署一套可正常运行的环境。
完整的镜像部署包括三个环节：Build—Ship—Run。

  • Build：跟传统的编译类似，将软件编译形成RPM包或者Jar包；
  • Ship：则是将所需的第三方依赖和第三方插件安装到环境中；
  • Run：就是在不同的地方启动整套环境。

4） 不可变服务器
现阶段使用容器部署不但继承和优化了虚拟机部署的优点，而且很好地解决了第三方依赖库的重构问题，容器部署就像一个集装箱，直接把所有需要的内容全部打包进行复制和部署。

5） 蓝绿部署和金丝雀部署

  • 蓝绿部署是指在部署的时候准备新旧两个部署版本，通过域名解析切换的方式将用户使用环境切换到新版本中，当出现问题的时候，可以快速地将用户环境切回I日版本，并对新版本进行修复和调整。
  • 金丝雀部署是指当有新版本发布的时候，先让少量用户使用新版本，并且观察新版本是否存在问题。如果出现问题，就及时处理并重新发布；如果一切正常，就稳步地将新版本适配给所有的用户。

5.6 软件质量管理

软件质量定义：软件满足显性、隐性需求的完整程度；包含功能性能需求、开发规范、行业隐含标准。

1） 软件质量三大维度（三角模型）

  1. 产品运行（使用时）：正确性、健壮性、效率、完整性、可用性、风险
  2. 产品修改（维护迭代）：可理解性、可维修性、灵活性、可测试性
  3. 产品转移（移植复用）：可移植性、可复用性、互运行性

2） 软件质量保证 SQA
软件质量保证（Software Quality Assurance, SQA）是建立一套有计划、有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。
软件质量保证的关注点集中在一开始就避免缺陷的产生。
软件质量保证的目标是以独立审查的方式，从第三方的角度监控软件开发任务的执行，就软件项目是否正确遵循己制订的计划、标准和规程给开发人员和管理层提供反映产品和过程质量的信息和数据，提高项目透明度，同时辅助软件工程取得高质量的软件产品。
软件质量保证的主要作用是给管理者提供预定义的软件过程的保证 软件质量保证的主要任务包括：SQA审计与评审、SQA报告、处理不合格问题。

5.7 软件过程能力成熟度 CSMM

软件过程能力：组织依靠标准化流程、技术、人员达成业务目标的综合能力。国内标准《软件过程能力成熟度模型》简称 CSMM （Chinese Software Capability Maturity Model）。

5.7.1 CSMM 四大能力域

  1. 治理域：战略与治理、目标管理；定义组织业务方向与目标
  2. 开发与交付域：需求、设计、开发、测试、部署、服务、开源管理；交付符合需求的软件
  3. 管理与支持域：项目策划、项目监控、项目结项、质量保证、风险管理、配置管理、供应商管理；保障项目成本、进度、质量可控
  4. 组织管理域：过程管理、人员能力管理、组织资源管理、过程能力管理；整体提升组织研发能力

5.7.2 CSMM 五级成熟度

  • 1级 初始级：流程无规范，交付结果不可控，完全依赖开发人员个人能力
  • 2级 项目规范级：单项目建立基础管理流程，项目可按计划交付，有基础保障
  • 3级 组织改进级：全组织统一标准流程，项目复用组织过程资产，持续优化流程
  • 4级 量化提升级：全流程量化管理，使用统计数据分析预测项目绩效，建立基线模型
  • 5级 创新引领级：通过技术、管理创新持续提升业务价值，行业标杆流程输出