标签：模型 基础知识 软件工程 原型 增量 构件 软件 Model
文章目录
（一）瀑布模型（Waterfall Model）
瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行和维护。
它规定了由前至后、相互衔接的固定次序，如同瀑布流水逐级下落。
瀑布模型的一个变体是V模型。
优点：
- 容易理解
- 管理成本低
缺点：
- 客户必须能够完整、正确和清晰地表达他们的需求
- 在开始的两个或三个阶段，很难评估正确的进度状态
- 当接近项目结束时，会出现大量的集成和测试工作
- 直到项目结束之前，都不能演示系统的能力
- 需求或设计中的错误往往只有到了项目后期才能被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，研发费用超出预算
（二）增量模型（Incremental Model）
增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。
该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。
客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能。
增量模型强调每个增量均发布一个可操作的产品。
优点：
- 具有瀑布模型的所有优点
- 第一个可交付版本所需要的成本和时间很少
- 开发由增量表示的小系统所承担的风险不大
- 可以减少用户需求的变更
- 在项目开始时，可以仅对一个或两个增量投资
缺点：
- 若没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定
- 如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布
- 管理发生的成本、进度和配置的复杂性可能会超出组织的能力
（三）演化模型（Evolutionary Model）
演化模型是迭代的过程模型，使得软件开发人员能够逐步开放出更完整的软件版本。
该模型适合对软件需求缺乏准确认识的情况。
1.原型模型（Prototype Model）
在开放初期，很难得到一个完整、准确的需求规格说明书，在开发过程中，用户还会不断产生新的需求，因此，原型模型就出现了。
原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。
原型模型始于沟通，目的是定义软件的总体目标，标识需求，然后快速制定原型开发的计划，确定原型的目标和范围，采用快速射击的方式对其进行建模，并构建原型。
原型的分类：
- 探索型原型（弄清目标要求，确定希望的特性，探讨多种方案的可行性）
- 实验型原型（验证方案或算法的合理性）
- 演化型原型（将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化为最终的目标系统）
2.螺旋模型（Spiral Model）
螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补这两种模型的不足。
过程：
- 制定计划
- 风险分析
- 实施工程
- 用户评估
螺旋模型适用于庞大、复杂及具有高风险的系统。
（四）喷泉模型（Water Fountain Model）
喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。
喷泉模型使得开发过程具有迭代性和无间隙性。
喷泉模型的各个阶段没有明显的界线，开发人员可以同步进行。
优点：
- 可以提高软件项目的开发效率
- 节省开发时间
缺点：
- 在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理
- 要求严格管理文档，使得审核的难度加大
（五）基于构件的开发模型（Component-based Development Model）
基于构件的开发是指利用预先包装的构件来构造应用系统。
构件可以是组织内部开发的构件，也可以是商品化成品软件构件。
基于构件的开发模型具有许多螺旋模型的特点，本质上是演化模型，需要以迭代方式构建软件。其不同之处在于，基于构件的开发模型采用预先打包的软件构件开发应用系统。
基于构件的开发模型包括领域工程和应用系统工程两部分：
- 领域工程（构建领域模型、领域基准体系结构和可复用构件库）
- 应用系统工程（使用可复用构件组装应用系统）
（六）形式化方法模型（Formal Methods Model）
形式化方法是建立在严格数学基础上的一种软件开发方法，其主要活动是生存计算机软件形式化的数学规格说明。
形式化方法用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析和推导，易于发现需求的歧义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。
（七）统一过程（UP）模型
统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由UML方法和工具支持。
统一过程定义的四个技术阶段及其制品：
- 起始阶段（生命周期目标）
- 专注于项目的初始活动，
- 主要工作产品：
- 构想文档
- 初始用例模型
- 初始项目术语表
- 初始业务用例
- 初始风险评估
- 项目计划（阶段及迭代）
- 业务模型
- 一个或多个原型
- 精化阶段（生命周期架构）
- 在了解了最初的领域范围后进行需求分析和架构演进
- 主要工作产品
- 用例模型
- 补充需求
- 分析模型
- 软件体系机构描述
- 可执行的软件体系结构原型
- 初步的设计模型
- 修订的风险列表
- 项目计划
- 初始用户手册
- 构建阶段（初始运作功能）
- 关注系统的构建，产生实现模型
- 主要工作产品
- 设计模型
- 软件构件
- 集成的软件增量
- 测试计划及步骤
- 测试用例
- 支持文档（用户手册、安装手册等）
- 移交阶段（产品发布）
- 关注于软件提交方面的工作，产生软件增量
- 主要工作产品
- 提交的软件增量
- 测试报告
- 综合用户反馈
（八）敏捷方法（Agile Development）
目标： 通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。
1.极限编程（XP）
- 四大价值观：沟通、简单性、反馈和勇气
- 五个原则：快速反馈、简单性假设、逐步修改、提高更改和优质工作
- 十二个最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40个小时、现场客户和编码标准
2.水晶法（Crystal）
水晶法认为每个不同的项目都需要一套不同的策略、约定和方法论，认为人对软件质量有重要的影响，因此随着项目质量和开发人员素质的提高，项目和过程的质量也随之提高。通过更好地交流和经常性的交付，软件生产力得到提高。
3.并列争求法（Scrum）
并列争求法使用迭代的方法，按照需求的优先级来实现产品，多个小组并行地递增实现产品。
4.自适应软件开发（ASD）
变化被视为软件开发实际情况的调整；确定的交付实际迫使开发人员认真考虑每个生产的版本的关键需求；风险也包含其中。
5.敏捷统一过程（AUP）
敏捷统一过程采用“在大型上连续”及在“在小型上迭代”的原理来构件软件系统。
- 建模
- 实现
- 测试
- 部署
- 配置及项目管理
- 环境管理
标签：模型,基础知识,软件工程,原型,增量,构件,软件,Model 来源： https://blog.csdn.net/Levi_moon/article/details/110919017
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。