【备战软考架构师系列笔记 · 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、环境(管理)


1995789-20220109190050258-610321535.png

目录
相关文章
|
SQL 前端开发 关系型数据库
如何开发一套研发项目管理系统?(附架构图+流程图+代码参考)
研发项目管理系统助力企业实现需求、缺陷与变更的全流程管理,支持看板可视化、数据化决策与成本优化。系统以MVP模式快速上线,核心功能包括需求看板、缺陷闭环、自动日报及关键指标分析,助力中小企业提升交付效率与协作质量。
1062 29
|
前端开发 JavaScript BI
如何开发车辆管理系统中的车务管理板块(附架构图+流程图+代码参考)
本文介绍了中小企业如何通过车务管理模块提升车辆管理效率。许多企业在管理车辆时仍依赖人工流程,导致违章处理延误、年检过期、维修费用虚高等问题频发。将这些流程数字化,可显著降低合规风险、提升维修追溯性、优化调度与资产利用率。文章详细介绍了车务管理模块的功能清单、数据模型、系统架构、API与前端设计、开发技巧与落地建议,以及实现效果与验收标准。同时提供了数据库建表SQL、后端Node.js/TypeScript代码示例与前端React表单设计参考,帮助企业快速搭建并上线系统,实现合规与成本控制的双重优化。
|
运维 监控 安全
公链开发中的高可用架构设计要点
本指南提供公链高可用架构的可复用流程与模板,涵盖目标拆解、先决条件、分步执行、故障排查及验收标准,结合跨链DApp与量化机器人案例,提升落地效率与系统稳定性。
|
消息中间件 运维 监控
交易所开发核心架构拆解与流程图
本文系统解析交易所架构核心要素,从接入层到清算结算,结合系统流程图拆解各模块职责与协作机制。深入剖析撮合引擎、账本设计与风控逻辑,建立性能、可用性、安全性等多维评估标准,并提供可落地的流程图绘制、压测优化与进阶学习路径,助力构建高效、安全、可扩展的交易系统。(238字)
|
设计模式 人工智能 API
AI智能体开发实战:17种核心架构模式详解与Python代码实现
本文系统解析17种智能体架构设计模式,涵盖多智能体协作、思维树、反思优化与工具调用等核心范式,结合LangChain与LangGraph实现代码工作流,并通过真实案例验证效果,助力构建高效AI系统。
1233 7
|
机器学习/深度学习 存储 缓存
115_LLM基础模型架构设计:从Transformer到稀疏注意力
大型语言模型(LLM)的架构设计是其性能的核心决定因素。从2017年Transformer架构的提出,到如今的稀疏注意力和混合专家模型,LLM架构经历了快速的演进。本文将全面探讨LLM基础架构的设计原理,深入分析Transformer的核心机制,详细介绍稀疏注意力、MoE等创新架构,并展望未来架构发展方向。通过数学推导和实践案例,为构建高效、强大的LLM提供全面指导。
1379 0
|
机器学习/深度学习 自然语言处理 算法
48_动态架构模型:NAS在LLM中的应用
大型语言模型(LLM)在自然语言处理领域的突破性进展,很大程度上归功于其庞大的参数量和复杂的网络架构。然而,随着模型规模的不断增长,计算资源消耗、推理延迟和部署成本等问题日益凸显。如何在保持模型性能的同时,优化模型架构以提高效率,成为2025年大模型研究的核心方向之一。神经架构搜索(Neural Architecture Search, NAS)作为一种自动化的网络设计方法,正在为这一挑战提供创新性解决方案。本文将深入探讨NAS技术如何应用于LLM的架构优化,特别是在层数与维度调整方面的最新进展,并通过代码实现展示简单的NAS实验。
605 0
|
Cloud Native Serverless API
微服务架构实战指南:从单体应用到云原生的蜕变之路
🌟蒋星熠Jaxonic,代码为舟的星际旅人。深耕微服务架构,擅以DDD拆分服务、构建高可用通信与治理体系。分享从单体到云原生的实战经验,探索技术演进的无限可能。
1136 4
微服务架构实战指南:从单体应用到云原生的蜕变之路
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。