乐于分享
好东西不私藏
夜雨聆风 > > 办公文件 > 07.软件工程开发模型--补充

07.软件工程开发模型--补充

当前时间： 2026-08-12 08:14:26 分类：办公文件 评论(0)
07.软件工程开发模型--补充
大家好！今天我们继续细说软考高级架构知识点。本节我们学习软件工程中的生命周期开发模型的补充内容

一、基于构件的开发模型（CBSD）

1.1概念

CBSE（基于构件的软件工程）是依托构件复用的新型开发模式，用于高效构建高质量软件。它将系统拆分为独立构件，构件功能、接口清晰，可独立完成开发、测试、部署。

核心目标：以软件复用为核心，搭积木式开发，侧重软件构造实现手段，不强制约束完整项目生命周期流程。

把软件拆分为标准化、独立、可复用构件，优先复用构件库成熟模块，缺少的构件再单独开发，通过接口组装集成系统，核心是构件库 + 标准化接口。

流程分为两大工程：领域工程（搭建、维护通用构件库）+ 应用工程（项目组装构件）。

1.2构件的特征

可组装性：所有外部交互必须通过公开定义的接口进行，不允许通过非公开方式访问构件内部。

可部署性：构件必须是自包含的，能作为独立实体在对应平台上运行，且无需部署前编译。

文档化：构件必须提供完整的文档，用户可以根据文档来判断构件是否买满足需求。

独立性：构件应该独立可用，再无特殊情况下进行组装和使用，如果需要其他构件提供服务，应当显式声明。

标准化：构件必须符合某种标准化构件模型，确保不同类型构件可以相互操作。

1.3开发过程

需求概览：对系统需求进行整体梳理

识别候选构件：在需求基础上，寻找可能复用的已有构件。

根据发现的构件修改需求：根据可用的构建实际情况，反复调整需求

架构设计：基于构件设计系统整体架构

构件定制与适配：对选定的构建进行必要的修改和适配

组装构件，创建系统：将构件组装 成完整的系统。

1.4构件的组合方式

概念：将各个独立的构件通过适当的方式集成的过程
直接集成：构件之间通过接口直接对接，无需额外代码
顺序组装：是指多个已经存在的构件创建一个新的构件，新构件按照顺序依次调用这些构件，前一个的输出时候一个的输入，形成一个流水线。

特点：构件之间是串行关系，有明确先后顺序，上有输出是下游的输入

层次组装：是指一个构件调用另一个构件，被调用构件的“提供”接口必须和调用构件的“请求”接口兼容。

特点：构件是调用与被调用之间的关系，存在上下依赖关系。

叠加组装：是指使用两个或两个以上构件创建一个新构件，新构件合并这些构件的功能，对外提供新的接口。原构件之间互不依赖，也不调用。

特点：

  1. 原构件相互独立。
  2. 新构件整合所有原构件的功能。
  3. 对外统一暴露接口。

1.5构建兼容问题

  1. 参数不兼容：操作名相同，但是参数类型、个数不同
  2. 操作不兼容：提供接口和请求接口操作名不同。
  3. 操作不完备：一个构件的提供接口是另一个构件请求接口的子集，只提供了部分所需操作。

1.6.优点

  1. 大量复用成熟构件，编码量、开发成本大幅降低；
  2. 构件经过多项目验证，系统可靠性更高；
  3. 模块化强，后期扩展、替换功能方便；
  4. 适合企业多套同类业务系统批量开发。

1.7缺点

  1. 前期搭建构件库投入大、周期长；
  2. 第三方 / 自研构件接口不兼容，集成难度高；
  3. 通用构件难以适配高度定制化独特业务；
  4. 缺乏标准化构件规范时复用效果极差

1.8适用场景

  1. 企业多产品线、同类业务重复开发（多门店 ERP、多子公司管理系统）；
  2. 大型模块化平台、中间件、政务标准化系统；
  3. 长期持续迭代、需要反复复用通用模块（登录、权限、支付等）； 需求稳定、架构提前规划清晰的大型项目。

（二）快速开发模型（RAD）

RAD 是瀑布模型的高速优化变种，核心依托可复用构件实现提速。

1.四大开发原则

  1. 全程引入用户参与；
  2. 组织需求研讨会议统一对齐需求；
  3. 通过迭代快速完成需求梳理；
  4. 让用户尽早接触可运行的系统版本。

2.核心思想

能复用现有构件就不重复开发。

3.优点

大幅缩短开发周期；复用经过验证的成熟构件，软件基础质量更有保障。

4.缺点

高度依赖现成可复用构件，无配套构件时无法发挥优势；
不适合技术门槛高、大量定制化开发的项目；
需要用户持续投入时间参与评审，若用户配合度不足，开发效果大打折扣。

（三）喷泉模型

喷泉模型是面向对象软件开发专属迭代模型，依托面向对象封装、继承、多态特性，以用户真实需求为驱动，以对象、类作为全流程开发核心。模型命名源于喷泉形态：开发活动像喷泉水流，向上、向下往复循环，无固化工序边界，专门适配面向对象项目。

1.核心特点

  1. 阶段无严格串行先后，分析、设计、编码、测试可交叉并行推进；
  2. 支持随时回溯迭代，开发中途可返回补充需求、完善设计、修复缺陷；
  3. 各阶段边界模糊，分析产出可直接复用至设计，设计成果无缝对接编码；
  4. 持续增量迭代，不断新增对象、完善类结构，适配需求持续变更场景；
  5. 开发、维护一体化，上线后维护修改可直接融入开发循环。

2.优点

  1. 迭代灵活性极强，适配需求频繁调整的软件项目；
  2. 面向对象高度贴合，类、对象贯穿全流程，复用性高；
  3. 并行开发缩短整体工期，可同步开展多模块工作；
  4. 维护成本低，后期修改可回流至前期阶段统一优化。

3. 缺点

  1. 无清晰阶段划分，项目管控难度大，进度、里程碑难以量化；
  2. 迭代次数无上限，若缺少需求管控极易陷入无限迭代；
  3. 文档产出零散，各阶段文档易缺失，后期追溯困难；
  4. 对开发人员统筹、需求把控能力要求高。

4. 适用场景

  1. 需求持续迭代、需求前期不明确的面向对象项目；
  2. 中小型互联网软件、移动端 APP、交互式系统；
  3. 需快速迭代、持续更新的业务系统；
  4. 采用 Java、Python、C++ 等面向对象语言开发的项目。

（四）V 模型

V 模型是瀑布模型的改良拓展模型，并非由 RAD 快速应用开发演变（纠正原表述误差），核心思想是测试活动与开发阶段一一镜像对应，左侧自上而下为开发流程，右侧自下而上为配套测试流程，整体呈 V 字形，明确每个开发阶段专属验证手段，将测试前置规划，解决传统瀑布测试后置、缺陷发现晚的问题。左侧开发流程：需求分析→概要设计→详细设计→编码右侧对应测试：验收测试→系统测试→集成测试→单元测试

解题注意事项：

1.如果题目问的是单元测试对应的的是哪个阶段，对应的是编码阶段，那就是直线对应；
2.如果题目问的是单元测试依据的的是哪个阶段，对应的是详细设计阶段，那就是斜上方对应；

1. 优点

  1. 开发与测试强绑定，各阶段测试提前规划，缺陷可在对应阶段及时发现；
  2. 流程清晰、阶段划分明确，便于项目进度管控、文档标准化；
  3. 打通设计、编码、全层级验证流程，测试覆盖完整，减少上线重大故障；
  4. 分工清晰，开发、测试职责分离，便于标准化团队流程落地；
  5. 交付物规范，需求、设计、测试用例一一对应，便于项目复盘维护。

2. 缺点

  1. 本质仍为线性串行模型，灵活性差，不支持需求中途大幅变更；
  2. 不支持迭代，前期需求错误会传导至全部下游阶段，修复成本极高；
  3. 仅聚焦测试分层，未覆盖持续迭代、增量开发场景；
  4. 测试方案需在开发初期全部定义，前期需求模糊时难以设计完整用例。

3. 适用场景

  1. 需求前期稳定、变更极少的标准化项目；
  2. 政务、金融、通信等合规要求高、需要完整测试文档的企业级系统；
  3. 嵌入式硬件配套软件、大型工业管控程序；
  4. 对测试流程、交付文档有强制规范要求的工程项目；
  5. 不适用：需求频繁改动、快速试错的互联网产品。

二、思维导图

非常感谢大家一直以来的支持与陪伴！如果这期内容对你有收获、有帮助，欢迎点赞、关注，持续解锁更多IT架构干货，我们下期再见！