1. 软件过程模型

软件过程模型是制作软件产品的一组活动以及结果，这些活动由软件人员开完成，包括软件描述、软件开发、软件有效性验证和软件进化

瀑布模型

模型的形态类似于瀑布的结构

特点

严格区分阶段，每个阶段因果关系紧密相连
只适合需求明确的项目

缺点

软件需求完整性、正确性难确定
严格串行化，需要很长时间才能看到结果
瀑布模型要求每个阶段一次性完成该阶段所有工作，这不现实

原型模型

虚线部分可能不会涉及

原型开发是通过开发一个简易系统来获取需求

特点

适合需求不明确的项目
有两个阶段，是原型开发阶段和目标软件开发阶段

分支

【抛弃型分支】：仅用在需求分析阶段，用后就抛弃
【演化型分支】：目标软件是在原型软件的基础上进行开发

原型及相关模型

演化模型

属于演化型分支

快速原型模型

属于抛弃型分支

增量模型

先做一个核心模块，然后开发一个和核心模块相关的模块，以此类推不断叠加

V 模型

测试贯穿始终
测试分阶段，测试计划工作提前

流程

验收测试看最终完成的应用和用户提出的需求是否一致，所以测试计划在需求分析阶段完成
系统测试强调软硬件环境联合测试，也对应需求分析阶段
集成测试测试不同模块间能否协同工作，对应概要设计
单元测试测试单个模块内部的流程，对应详细设计

W 模型

是 V 模型的调整与改进

上图中蓝色是开发过程，红色是测试过程。

W 模型由两个 V 构成（测试 + 开发），是一个测试和开发并行进行的模型

迭代和增量

增量：一次次增加，一个需求分步完成，比如画一直米老鼠，第一次画耳朵，第二次画眼睛
迭代：一次次改善，一个需求逐步完善，比如画米老鼠，先画米老鼠雏形，再进一步完善

螺旋模型

以快速原型为基础 + 瀑布模型，考虑了风险问题

目标设定

决定目标、方案和限制

风险分析（重要）

评价方案、识别风险、消除风险

开发和有效性验证

开发、验证下一产品

评审

构件组装模型

例子：方舱医院、乐高积木

优点

易拓展、易重用、降低成本、安排任务更灵活

缺点

构件设计要求经验丰富的架构师、设计不好的构件难重用、强调重用可能牺牲其他指标（如性能）、第三方构件质量难控制

基于构件的软件工程（CBSE）

CBSE 体现了 **【购买而不是重新构造】**的哲学

特征

可组装性：所有 外部交互 必须通过 公开定义的接口 进行
可部署性：构件总是二进制形式的，能作为一个 独立实体在平台上运行
文档化：用户根据文档来判断构件是否满足需求
独立性：可以在无其他特殊构件的情况下进行组装和部署
标准化： 符合某种标准化的构件模型

要素

【接口】：构件通过构件接口来定义，构件模型规定应如何定义构件接口以及在接口定义中应该包含的要素，如操作名、参数以及异常等
【使用信息】：为了使构件远程分布和访问，必须给构件一个特定的、全局唯一的名字或句柄。 构件元数据是构件本身相关的数据，比如构件的接口和属性信息。用户可以通过元数据找到构件提供的服务。构件模型的实现通常包括访问构件的元数据的特定方法。 构件是通用实体，在不熟的时候，必须对构件进行配置来适应应用系统
【部署】：构件模型包括一个规格说明，指出应该如何打包构件使其部署成为一个独立的可执行实体。部署信息中包含有关包中内容的相关信息和它的二进制构成信息

组装（要借助胶水代码）

顺序组装：按顺序调用已经存在的构件，可以用连个已经存在的构件来创造一个新的构件
层次组装：被调用构件的“提供”接口必须和调用构件的“请求”接口兼容
叠加组装

组装中的不兼容

参数不兼容：接口每一侧的操作有相同的名字，但参数的类型或参数个数不相同
操作不兼容：提供接口和请求接口的操作名不同
操作不完备：一个构件的提供接口是另一个构件请求接口的子集，或者相反

快速应用开发模型（RAD）

主流程用瀑布，用构件完成别的，构件是能快速的原因

统一过程（UP）

应用广泛，系统有一定的规模

特性

用例驱动
以架构为中心
迭代和增量（每一轮一个循环 - 初始、细化、构造、移交）
- 初始：确定系统范围、定义最终产品视图和业务模型
- 细化：设计及确定系统架构、制定工作计划及资源要求
- 构造：开发生育构建和应用程序功能，把这些构件集成为产品，并进行详细测试
- 移交：确保软件对最终用户是可用的，进行贝塔测试，制作产品发布版本

9 个核心工作流

过程（开发）

业务建模
需求
分析与设计
实现
测试
部署

支持（管理）

配置与变更管理
项目管理（核心）
环境

敏捷方法

晚于其他方法

演进流程

无软件开发方法 -> 传统软件开发方法（如结构法方法瀑布模型） -> 敏捷方法（参考原型开发）

敏捷方法-极限编程 XP

4 大价值观

沟通【加强面对面的沟通】
简单【不过度设计】
反馈【及时反馈】
勇气【接受变更的勇气】

12 条过程实践规则

简单设计
测试驱动
代码重构
结对编程：两人组成一对，一人写代码一人在电脑旁审核
持续集成：不断去集成
现场客户
发型版本小型化
系统隐喻：举例、打比方的方式让大家认可
代码集体所有制
规划策略
规范代码
40 小时工作机制

敏捷方法-Scrum

不强调一次性完成整个系统，而是每次从产品代办列表中抽取需求迭代

一个迭代 1-4 周

敏捷方法 - 水晶方法

提倡机动性的方法，拥有对不同类型项目非常有效的敏捷过程

敏捷方法 - 特征驱动开发方法（FDD）

认为有效的软件开发需要 3 要素【人、过程、技术】定义了 6 种关键的项目角色：项目经理、首席软件架构师、开发经理、主程序猿、程序员和领域专家

逆向工程

按正向工程反其道行之

净室软件工程【把软件工程放到一个尽量干净的地方】

强调以合理的成本开发出高质量的软件
理论基础主要是函数理论和抽样理论
它提倡开发者不需要进行单元测试（还是需要传统的模块测试），而是进行正确性验证和统计质量控制
因为高质量改进管理，降低风险及成本，满足用户需求，提供竞争优势。

【技术手段】

统计过程控制下的增量式开发：控制迭代
基于函数的规范和设计：盒子结构定义 3 种抽象层次：行为视图（黑盒） -> 有限状态机视图（状态盒） -> 过程视图（明盒）
正确性验证：净室工程的核心，使软件的质量有了极大程度的提高
统计测试盒软件认证：使用统计学原理，总体太大时必须使用抽样方法

【缺点】

太理论化，正确性验证的步骤比较困难且耗时
开发小组不进行传统的模块测试，这是不现实的
脱胎于传统软件工程，不可避免带有传统软件工程的一些弊端

需求工程

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

主要活动的阶段划分

（以下是需求开发）

需求获取

需求获取的方法

用户面谈：1 对 1-3，有代表性的用户，了解主观想法，交互好。成本高，要有领域知识支撑
需求专题讨论会（JRP）：高度组织的群体会议，各方参与，了解想法，消除分歧，交互好，成本高
问卷调查：用户多，无法一一访谈，成本低。
现场观察：针对较为复杂的流程和操作
原型化方法：构造简易需求版本解决早期需求不确定的问题
头脑风暴法：一群人围绕信业务，发散思维，不产生新的观点

分层

业务需求（整体全局）：偏向企业整体全局，主要是老板的预期
用户需求（用户视角）：
功能（系统）需求（计算机化） - 包括功能需求、性能需求（非功能）、设计约束（是否使用国产数据库等）

项目管理维度

基本需求（明示，常规需求）
期望需求（隐含）
兴奋需求（多余）

需求分析

结构化开发需求分析

建立

功能模型（数据流、加工、数据存储、外部实体 - 使用数据流图，对功能进行建模）、
行为模型（状态（初态、终态）、事件 - 使用状态转换图）、
数据模型（使用 ER（实体联系）图，）

三者融合为数据字典

面向对象开发需求分析

形成需求规格【形成 SRS】（SRS 是软件需求规格说明书）
需求确认与验证【形成 需求基线（经过评审的 SRS）】
需求管理【变更控制、版本控制、需求跟踪、需求状态跟踪】（对需求基线进行管理）

1. 软件过程模型 ​

瀑布模型 ​

特点 ​

缺点 ​

原型模型 ​

特点 ​

分支 ​

原型及相关模型 ​

演化模型 ​

快速原型模型 ​

增量模型 ​

V 模型 ​

流程 ​

W 模型 ​

迭代和增量 ​

螺旋模型 ​

目标设定 ​

风险分析（重要） ​

开发和有效性验证 ​

评审 ​

构件组装模型 ​

优点 ​

缺点 ​

基于构件的软件工程（CBSE） ​

特征 ​

要素 ​

组装（要借助胶水代码） ​

组装中的不兼容 ​

快速应用开发模型（RAD） ​

统一过程（UP） ​

特性 ​

9 个核心工作流 ​

过程（开发） ​

支持（管理） ​

敏捷方法 ​

演进流程 ​

敏捷方法-极限编程 XP ​

4 大价值观 ​

12 条过程实践规则 ​

敏捷方法-Scrum ​

敏捷方法 - 水晶方法 ​

敏捷方法 - 特征驱动开发方法（FDD） ​

逆向工程 ​

相关概念 ​

净室软件工程【把软件工程放到一个尽量干净的地方】 ​

【技术手段】 ​

【缺点】 ​

需求工程 ​

主要活动的阶段划分 ​

需求获取 ​

需求获取的方法 ​

分层 ​

项目管理维度 ​

需求分析 ​

结构化开发需求分析 ​

面向对象开发需求分析 ​