【备战软考架构师系列笔记 · 002】软件工程篇 —— 软件开发模型(上篇：经典开发模型) ⭐⭐⭐⭐⭐...

软件开发模型笔记(上篇)—— 经典的几个软件开发模型

# 常见软件开发模型

## 原型模型⭐

### 特点

- 适用于需求不明确的场景，可以帮助用户明确需求

## 瀑布模型⭐

### 特点

- 软件开发阶段划分明确，每个阶段有明显界限，一旦发生错误，需要推倒重来

    - 1、需求分析

    - 2、总体设计

    - 3、详细设计

    - 4、编码与调试

    - 5、集成测试与系统测试

- 容易理解，管理成本低，每个阶段有对应的成果产物

- 适用于需求明确的项目，一般表述为需求明确、二次开发或者对于数据处理类型的项目

- 瀑布模型会产生一大堆文档，大部分对客户无意义，完成文档需要花费大量人力，是一种重载的过程

## (瀑布)V模型

### 特点

- V模型是瀑布模型的变体，更强调测试

- 更强调测试，测试贯穿项目始终

    - 设计阶段

        - 1、需求分析

        - 2、概要(总体)设计

        - 3、详细设计

        - 4、编码与调试

    - 测试阶段

        - 5、单元测试

        - 6、集成测试

        - 7、系统测试/验收测试

- 保持了瀑布模型阶段式文档驱动的特点

## 演化模型

### 可以看作是若干次瀑布模型的迭代，根据不同的迭代特点，可以演化为螺旋模型、增量模型

## 螺旋模型⭐

### 特点

- 结合瀑布模型和演化模型的优点

- 每个周期都包括四个阶段

    - 1、需求定义/制定计划

    - 2、风险分析(典型特点)

    - 3、工程实现/实施

    - 4、评审/客户评估

- 适用于庞大而复杂、具有高风险的系统

- 支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便

- 有助于提高目标软件的适应能力

- 在风险较大的系统中，如果不能及时识别风险，会造成重大损失

- 过多的迭代次数，会增加成本，延迟提交时间

## 增量模型

### 特点

- 融合瀑布模型的基本成分和原型实现的迭代特征

- 可以有多个可用版本的发布，每个版本都是一个完整的系统

- 版本间的增量比较均匀，并且后一版本以前一个版本为基础进行开发，扩充核心功能

    - 第一个版本往往是系统的核心功能，可以满足用户基本的需求

    - 用户可以短时间内获得系统初始版本的试用，问题可以很快进行反馈到后续开发中

### 增量与迭代(UP模型 / 敏捷开发模型)

- 增量：每次实现一部分局部的功能

- 迭代：先绘制整体轮廓，每次实现轮廓内的一部分

## 喷泉模型

### 特点

- 典型的面向对象模型

- 迭代、无间隙

- 将软件开发划分为多个阶段，每个阶段无明显界限，并且可以交叉迭代

## 快速应用开发(RAD)

### 概念

- 瀑布模型的一个高速变种，适用比传统生命周期快得多的开发方法

- 强调极短的开发周期

- 通常适用于基于构建的开发方法获得快速开发

### 过程

- 业务建模

- 数据建模

- 过程建模

- 应用生成

- 测试与交付

### 适用性

- 对模块化要求比较高

- 如果有高性能指标，且必须通过调整结构使其适应系统构件才能获取该指标的情况，RAP不适用

-  开发者和客户必须在很短时间内完成一系列需求分析，任何一方配合不当都会导致失败

- 只能适用于管理信息系统的开发，不适用于技术风险很高的场景

## 构件组装模型

### 概念

- 利用构件进行搭积木式的开发

- 构件是独立的、自包容的，架构开发也是独立的，构件之间通过接口进行交互协作

### 模型

- 1、需求分析和定义

- 2、软件架构设计/设计构件组装

- 3、建立构件库

    - 构件标准

        - CORBA

        - COM/DCOM

        - EJB

    - 构件库

        - 构件获取

        - 构件管理

- 4、构建应用软件

- 5、测试与发布

### 特点

- 构件的自包容性，系统拓展更容易

- 设计良好的构件更容易被重用，降低软件开发成本

- 构件粒度小，安排开发更灵活，可以并行独立开发构件

- 构件设计需要经验丰富，设计不良的构件会降低组装模型的重用度

- 考虑软件重用度，往往需要对其他方面做出让步，例如性能

- 需要程序员熟练掌握构件，增加学习成本

- 第三方构件库的质量会影响软件的质量，第三方的构件库质量难以保证

## 统一过程(UP/RUP)⭐

### 特点

- 用例驱动

- 以架构为中心

    - 同需求和项目管理人员密切协作

    - 细化软件架构

    - 保持整个架构的概念完整性，包括设计系统架构、定义设计方案、设计指南、编码指南、评审设计等

- 迭代和增量

    - 但不属于敏捷方法，未经裁剪的UP是一个重载过程

### 四个阶段

- 构思(初始)

    - 界定系统范围，确定系统架构，明确系统目的

    - 制定工作计划及资源要求

    - 业务建模和需求工作是重头戏，强调定义和细化用例

- 细化

    - 抽象出软件的逻辑模型

    - 设计出软件架构

    - 分析和设计模型是最主要的工作，强调类的定义和体系结构的表示

- 构建

    - 将设计转化为实现，并进行集成和测试

    - 需要基本完成系统的构建，该阶段的重点是实施和测试

- 交付(转移阶段)

    - 系统需求已经完全成熟或产品化

    - 该阶段会存在对软件系统的重构、修改、测试和部署

### 九个核心工作流

- 1、业务建模

- 2、需求

- 3、分析设计

- 4、实施

- 5、测试

- 6、部署

- 7、配置与变更管理

- 8、项目管理

- 9、环境(管理)