常用软件开发模型比较分析
软件开发几种模式
软件开发的几种模式2015-05-27彭波模模搭模模搭开发日志057软件开发的几种模式归类1.边做边改模型（Build-and-Fix Model）好吧，其实现在许多产品实际都是使用的“边做边改”模型来开发的，特别是很多小公司产品周期压缩的太短。
在这种模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。
在这个模型中，开发人员拿到项目立即根据需求编写程序，调试通过后生成软件的第一个版本。
在提供给用户使用后，如果程序出现错误，或者用户提出新的要求，开发人员重新修改代码，直到用户和测试等等满意为止。
这是一种类似作坊的开发方式，边做边改模型的优点毫无疑问就是前期出成效快。
对编写逻辑不需要太严谨的小程序来说还可以对付得过去，但这种方法对任何规模的开发来说都是不能令人满意的，其主要问题在于：1）缺少规划和设计环节，软件的结构随着不断的修改越来越糟，导致无法继续修改；2）忽略需求环节，给软件开发带来很大的风险；3）没有考虑测试和程序的可维护性，也没有任何文档，软件的维护十分困难。
2. 瀑布模型（Waterfall Model）瀑布模型是一种比较老旧的软件开发模型，1970年温斯顿·罗伊斯提出了著名的“瀑布模型”，直到80年代都还是一直被广泛采用的模型。
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。
当前活动的工作结果需要进行验证，如验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
瀑布模型优点是严格遵循预先计划的步骤顺序进行，一切按部就班比较严谨。
瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。
但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，其主要问题在于：1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
软件工程中的迭代模型与瀑布模型比较
软件工程中的迭代模型与瀑布模型比较一、引言在软件开发过程中，选择合适的开发模型对于保证项目的质量和进度具有至关重要的作用。
目前常用的软件开发模型有迭代模型和瀑布模型。
本文将从5个方面对两种模型进行比较。
二、开发流程1.瀑布模型瀑布模型是一种经典的软件开发模型，其开发流程分为需求分析、设计、编码、测试和维护五个阶段，各个阶段顺序执行，下一阶段只能在上一阶段完成之后开始。
由于需求的变更只能在一开始阶段进行，所以瀑布模型适用于需求明确且稳定的软件项目。
2.迭代模型迭代模型是一种基于迭代和递增开发的软件开发模型。
与瀑布模型相比，迭代模型将整个开发过程分为多个迭代阶段。
每个迭代阶段包含需求分析、设计、编码、测试和交付五个阶段。
根据用户反馈和实际情况，修改开发方案、调整需求、复审需求等在每个迭代中都可以进行，保证了项目的灵活性和可扩展性。
三、优缺点比较1.瀑布模型瀑布模型的优点在于开发工作步骤严谨，流程清晰，便于管理。
但其缺点在于对于变更迭代以及需求变更处理比较低效，会影响产品上市时间和开发团队的士气。
2.迭代模型迭代模型的优点在于其灵活性和可扩展性高，与客户的沟通反馈及时有效，更加符合产品的应用需求。
同时也更有利于开发团队的持续改进，提高开发效率。
其缺点在于开发工作需要逐步细化，需要花费更多的人工和物力资源。
四、应用场景分析1.瀑布模型由于瀑布模型的开发流程要求非常严格，适用于需求相对稳定和清晰的软件项目开发，例如公共事业、社交平台等信息系统的开发。
2.迭代模型迭代模型更适用于用户需求不断变化、产品需求随时调整的场景，例如游戏、云计算等软件项目，可以快速调整产品的各种特性以更符合用户的需求。
五、团队反馈1.瀑布模型在瀑布模型中，由于团队成员需要按照工作步骤一步步顺序进行开发，导致需要轮流等待其他团队成员完成前一阶段的开发工作才能开始自己的工作。
因此会影响开发工程效率。
2.迭代模型在迭代模型中，团队成员能够在不同的迭代中分配任务，每个迭代之间没有直接依赖关系，更容易发挥团队成员的专业能力和高效利用开发资源从而提高开发效率。
常用软件开发模型比较分析
常用软件开发模型比较分析1.瀑布模型：瀑布模型是一种线性的软件开发模型，包括需求分析、系统设计、编码、测试和运维等阶段，每个阶段的输出作为下一个阶段的输入。
瀑布模型适用于项目需求稳定，技术风险较低的情况。
优点是开发流程清晰，可控性强，适合大型项目。
缺点是客户不能及时参与，需求变更困难，开发周期长。
2.原型模型：原型模型是通过快速制作可演示的原型反馈给用户，收集用户的需求和意见，然后根据用户反馈进行迭代修改。
原型模型适用于需求不稳定，对用户参与度较高的项目。
优点是增加了用户参与度，减少了开发风险，缺点是迭代次数较多，迭代周期较长。
3.增量模型：增量模型将软件项目划分为多个可交付的增量，在每个增量中完成一部分功能的开发。
每个增量都是通过类似瀑布模型的开发流程完成的。
增量模型适用于需求变化频繁，紧急需求较多的项目。
优点是快速交付部分功能，缺点是需求变更对后续增量开发影响较大，需求变更困难。
4.螺旋模型：螺旋模型是一种迭代、增量的风险驱动软件开发模型，将每个迭代的输出进行风险评估，根据评估结果调整开发计划。
螺旋模型适用于需求变更频繁，风险较高的项目。
优点是在项目开始时就考虑风险，迭代周期较短，缺点是较难确定项目的总体进度和成本。
5.敏捷开发模型：敏捷开发模型是一种迭代、增量的软件开发模型，强调团队合作，反馈及时，持续交付。
敏捷开发模型适用于团队规模较小，需求变化频繁的项目。
优点是迭代周期较短，灵活应对需求变化，缺点是对团队要求较高，需要高度的沟通和协作。
综上所述，不同的软件开发模型适用于不同的项目场景。
瀑布模型适合需求稳定的大型项目，原型模型适合需求不稳定、用户参与度高的项目。
增量模型适合需求变化频繁的项目，螺旋模型适合需求变化频繁、风险较高的项目。
敏捷开发模型适用于团队规模小、需求变化频繁的项目。
在选择开发模型时，需要考虑项目的特点和需求变化的频率，以及团队的能力和合作能力。
各种模型特点
常用软件开发过程模型比较比较几种常见的软件开发过程模型的特点、优缺点、和适用情况：一、瀑布模型瀑布模型的特点：1、简单、直观、易用2、开发进程比较严格，一个阶段接着一个阶段顺序进行3、模型中没有反馈，上一阶段任务完成，进入下一个阶段以后，下一个阶段不会对上一个阶段的工作作出反馈4、模型执行过程中需要严格控制5、允许基线和配置早期接受控制6、一个新的项目不适合瀑布模型，除非处于项目的后期7、用户直到项目结束才能看到产品的质量；用户不是渐渐地熟悉系统8、不允许变更或者限制变更早期的需求9、瀑布模型整体上比较理想化瀑布模型的优点：有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率。
瀑布模型的缺点：（1）开发过程一般不能逆转，否则代价太大；（2）实际的项目开发很难严格按该模型进行；（3）客户往往很难清楚地给出所有的需求，而该模型却要求如此。
（4）软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。
瀑布模型的使用范围：（1）用户的需求非常清楚全面，且在开发过程中没有或很少变化；（2）开发人员对软件的应用领域很熟悉；（3）用户的使用环境非常稳定；（4）开发工作对用户参与的要求很低。
二、原型模型原型模型的特点：1、需求定义时，需要快速构建一个原型系统2、用户根据快速构建的原型系统的优缺点，给开发人员提出反馈意见3、根据反馈意见修改软件需求规格说明，以便系统可以更正确地反应用户的需求4、可以减少项目的各种假设以及风险等。
原型模型的优点：（1）可以得到比较良好的需求定义，容易适应需求的变化；（2）有利于开发与培训的同步；（3）开发费用低、开发周期短且对用户更友好。
原型模型的缺点：（1）客户与开发者对原型理解不同；（2）准确的原型设计比较困难；（3）不利于开发人员的创新。
原型模型的使用范围：（1）对所开发的领域比较熟悉而且有快速的原型开发工具；（2）项目招投标时，可以以原型模型作为软件的开发模型；（3）进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型是非常适合的。
软件需求工程中的模型及分析方法
软件需求工程中的模型及分析方法在软件开发中，软件需求工程是非常重要的一环，因为在这个阶段确定的需求将直接影响后续的软件设计和开发。
而模型及分析方法是软件需求工程的重要工具，它们可以帮助开发人员深入了解用户需求，更好地完成软件开发任务。
本文将围绕软件需求工程中的模型及分析方法展开讨论。
一、模型及其类型模型是对实际系统或过程的一种抽象表示，它可以帮助开发人员更好地理解和分析软件需求，在需求工程中常用的模型包括以下几种：1.1 静态模型静态模型是对系统或过程中的元素及其关系的表示，它们的变化不随时间而定。
在需求工程中常用的静态模型包括数据流图、结构图、实体关系图等。
数据流图可以表示系统中的数据输入、输出以及数据处理过程，它可以帮助开发人员更好地理解数据流动的过程。
结构图可以表示系统中的模块和模块之间的关系，它可以帮助开发人员更好地理解模块之间的交互。
实体关系图可以表示系统中不同实体之间的关系，它可以帮助开发人员更好地理解实体之间的交互。
1.2 动态模型动态模型是对系统或过程中的操作及其变化的表示，它们的变化随时间而定。
在需求工程中常用的动态模型包括状态图、活动图、时序图等。
状态图可以表示系统中不同状态之间的转换，它可以帮助开发人员更好地理解系统状态的变化。
活动图可以表示系统中各种活动的执行过程，它可以帮助开发人员更好地理解系统中不同活动之间的关系。
时序图可以表示系统中事件之间的时间顺序，它可以帮助开发人员更好地理解系统中不同事件的执行顺序。
1.3 物理模型物理模型是对系统或过程中的物理组件及其关系的表示，它们通常与硬件和软件的配合使用。
在需求工程中常用的物理模型包括部署图、机房图等。
部署图可以表示不同硬件之间的连接和通信，它可以帮助开发人员更好地理解系统中不同硬件之间的配合。
机房图可以表示不同设备在机房内的位置和连接方式，它可以帮助开发人员更好地理解机房中各种设备的位置关系。
二、分析方法及其应用分析方法是针对需求进行深入分析的方法，通过分析可以更好地理解用户需求并确定需求的可行性。
软件工程中主要开发模型的比较分析
第 ８卷
第１ 期
鸡 西 大 学 学 报
Ｊ ＯＵＲＮ Ｉ ＡＬ ＯＦ ＪＸＩＵＮＩ Ｒ Ｉ Ｙ ＶＥ Ｓ Ｔ
Ｖ０ ． Ｎｏ １ １８ ．
Ｆ ｂ． ｏ ８ ｅ ２ ｏ
２０ ０ ８年 ２月
文 章 编号 ：６２— ７ ８ ２０ ） ｌ ０ ８ １７ ６ ５ （０ ８ Ｏ 一 ０ ６—３
能预先知道需求 功能 ； 需求 可能变更 ； 以处 理随时发生 难 的变化 ； 多个软件系统 ； 的系统一定兼容现有 的系统 。 新
１２瀑 布模 型 。 ．
目信息所需要 的任务 。③风险分析——评估技 术及管理 的风险所需要 的任务。④工程—— 建立应用 的一个或多 个表示所需要 的任务 。⑤建造及 发布—— 建造 、 试 、 测 安 装和提供用 户 支持 （ 文档及 培训 ） 如 所需要 的 任务 。⑥
用 户 评 估 — — 基 于 在 工 程 阶 段 产 生 的 或 在 安 装 阶 段 实 现
瀑布模 型在 １７ ９０年被首次提 出， 它强调在开发过程 中的各 项任务应 当按 照顺序进行 。而事实上 在开发过程 中的早 期阶段 ， 经常会对前一阶段的工作进行返工 。 瀑布模 型强 调一个阶段 的完成 ， 调早 期 的规划 ， 强 客 户输入和设计 ， 调测试是生命周期 的主要组成部分 ， 强 在
软 件 工 程 中主要 开 发 模 型 的 比较 分 析
杨 萍 周 云 郭 丹 朴在 林
摘 要： 软件开发是软件 工程研 究 中的核心 内容。在软件工程发展 完善 的过 程 中， 成 了许 多种软件开 形 发模 型， 对于不 同的软件 系统， 以选用不 同的软件 过程模 型。文 中简要 介绍 了软 件 工程学的一般 概念 ， 可 详 细描述 了软件 工程 中几个主要的开发模型 ， 同时对这 些模 型的优 势、 存在的不足 以及适 用范 围进行 了列表分 析 ． 过 对 比 给 出 了建议 应 用 的模 型 ， 而 达 到 软 件 开 发 的 高 效 率 和 最 佳 应 用 的 效 果 。 通 从 关键 词 ： 件 工 程 ； 发 模 型 ； 软 开 比较 ； 析 ； 用 范 围 分 适 中图分类号 ：Ｐ １ ．２ Ｔ ３ １５ 文献标识码 ： Ａ 前面的东西 ， 次一 个进 程 ；容易检 查 等等。瀑布 模 型 一 也存 在一 些问题 ， 同的用户需求不 同的内容 ， 不 当后 面的 开发阶段正在运行 ， 面的 阶段发 现错误 ，开发一 定要 前 返回前一阶段 ， 因此 ， 软件开发是 反复 的 ， 同时， 系统发展 也 是 一 个 非 线 性行 为 。 瀑布模型是最早 ， 也是应 用最 广泛 的软件工 程过程 模型。在使用 瀑布模型 过程 中， 时也会 遇到 如下一些 有 问题 。例 如 ： 际 开 发 项 目时 很 少 按 照 该 模 型 给 出 的顺 实 序进行 ； 用户常常难以清楚地给出所有的需求 ， 而瀑布模 型却 要求 如此 ， 它还不 能接受 在许 多项 目开始 阶段 存在 不确定性 。不管怎 样 ， 瀑布模 型在 软件工程 中仍 占据重 要的位置 ， 它提供 一个模板 ， 使得 分析 、 设计 、 编码 、 测试 和 维 护 的 方 法 可 以 在该 模 板 的指 导 下 展 开 。 １３编码一 修复模型。 ． 编码一修复模 型有 以下特征 ： 没有设计阶段 ； 在发展 阶段 没有说 明书， 导致 维护 的困难 ； 是最 昂贵 的方法 ； 不 适于大 型的开发计划 。 １４ 螺旋 形模 型 。 ． 将原 型化模 型的迭代特征和线性模型 中控 制的和系 统化 的方 面结合起来 的一种 模 型， 它包 括下 面六大 任务 区： ①用户通信——建立 开发者 和用 户之间 有效通 信所 需要 的任 务。② 计划——定 义资源 、 进度 及其 他相 关项
数据库设计中的实体关系模型与ER模型比较分析
数据库设计中的实体关系模型与ER模型比较分析数据库设计是任何软件开发项目中的重要环节。
在设计数据库时，实体关系模型（Entity-Relationship Model，简称ER模型）和实体关系模型（Relational Model）是最常用的两种建模方法。
本文将对实体关系模型和ER模型进行比较分析。
实体关系模型是一种基于二维表格的模型，它使用关系型数据库来存储和管理数据。
在实体关系模型中，数据被组织成多个二维表格（也称为关系），每个关系由一组字段组成。
字段是表格中的列，用来描述实体的特征或属性。
关系中的行表示具体的实体实例，也就是存储的数据。
相比之下，ER模型更注重实体之间的关系。
ER模型使用实体、关系和属性等元素来描述现实世界的概念和关系。
在ER模型中，实体表示具有独立存在和唯一标识的现实世界对象，如人、物、地点等。
关系表示实体之间的联系，如一对一、一对多、多对多关系。
属性表示实体或关系的特征或属性。
在实体关系模型中，数据的结构是由多个关系（即表格）之间的链接关系来决定的。
每个关系都有一个主键，用来唯一标识关系中的每一行。
主键可以由一个或多个字段组成。
为了满足数据的一致性和完整性，实体关系模型还可以使用外键来连接多个关系。
在ER模型中，实体和关系之间的连接是通过关系型数据库的外键来实现的。
实体之间的关系通过关系型数据库中外键的引用来建立。
这样可以提高数据的一致性和完整性，同时也方便了数据的检索和查询。
实体关系模型和ER模型各有优势和劣势。
实体关系模型相对简单，易于理解和实现。
它适用于管理大量数据和复杂查询的场景，例如企业级应用、电子商务系统等。
实体关系模型还具有良好的标准化和规范化，能够提高数据的完整性和一致性。
相比之下，ER模型更加抽象和灵活。
它能够更好地反映现实世界的关系和概念。
ER模型适用于需求需求频繁变化的场景，如创业公司的项目、研发实验项目等。
ER模型也能够将复杂的关系和约束转化为可视化的图形模型，更容易与业务人员进行沟通和理解。
熟悉常用的软件开发生命周期模型
熟悉常用的软件开发生命周期模型软件开发生命周期模型是指在软件开发过程中，按照一定的步骤和阶段进行开发的方法论。
不同的生命周期模型适用于不同的开发需求和开发团队，但它们都以确保软件质量和满足用户需求为目标。
本文将介绍几种常用的软件开发生命周期模型，帮助读者更好地理解和应用于实际开发项目中。
瀑布模型瀑布模型是最经典的开发生命周期模型之一，它被认为是一种线性顺序模型。
瀑布模型将软件开发过程划分为几个阶段，如需求分析、系统设计、编码、测试和维护等。
每个阶段的输出会成为下一个阶段的输入，确保整个开发过程的连续性和一致性。
该模型适用于需求稳定、并能够明确详细的项目。
迭代模型迭代模型将软件开发过程划分为多个迭代周期，每个周期都包含需求分析、设计、编码、测试和发布等阶段。
每个迭代都会获得一个可用的软件产品，并在之后的迭代中不断完善和扩展。
迭代模型适用于需求变化频繁或团队缺乏明确的需求文档的情况。
通过快速迭代和反馈，开发团队能够更快地适应需求变化和改进软件质量。
螺旋模型螺旋模型将软件开发过程看作一系列的螺旋，每个螺旋代表一个开发周期。
在每个周期的开始，开发团队会进行风险评估和需求分析，并根据评估结果制定相应的开发策略。
然后，团队按照该策略进行设计、编码、测试和发布等工作。
螺旋模型适用于需要高风险控制和迭代开发的项目。
通过周期性的风险评估和调整，开发团队能够及时应对风险并提高软件质量。
敏捷模型敏捷模型是一种轻量级和迭代的开发方法论，强调快速适应需求变化和团队合作。
敏捷模型将开发过程划分为多个迭代周期，每个周期通常持续2到4周。
每个周期都包含需求分析、设计、编码、测试和部署等工作。
开发团队和客户之间的高效沟通和合作是敏捷模型的核心。
敏捷模型适用于团队追求快速交付、灵活适应需求变化的项目。
总之，软件开发生命周期模型是指导软件开发过程的重要方法论。
熟悉常用的软件开发生命周期模型有助于开发团队更好地组织和管理开发项目，确保软件质量和满足用户需求。
软件对比分析
COSMOS官方称为“设计校验”，意思是偏重对设计缺陷的检验。
实际操作起来，参数设定环境的加载都更倾向于模拟现实情况。
而网络划分、几何修正等环节基本上是可以让它自动完成的。
当然也可以更改而ansys则是一款老牌的CAE软件，工程分析。
更偏向于专业的工程应用，需要获得精确的分析结果。
操作起来也十分专业，包括网络划分，几何修正、几何体的物理模型等都给与使用者更多的选择，以便达到更加精确的效果。
所以总的说来，COSMOS更适合设计人员使用，来初步检验设计缺陷。
而Ansys则更加偏重专业分析人员来做工程分析。
各种流行软件比较：目前流行的CAE分析软件主要有NASTRAN、ADINA 、ANSYS、ABAQUS、MARC、MAGSOFT、COSMOS等。
以下为对这些常用的软件进行的比较和评价：1. LSTC公司的LS-DYNA 系列软件LSDYNA长于冲击、接触等非线性动力分析。
LS-DYNA是一个通用显式非线性动力分析有限元程序，最初是1976年在美国劳伦斯利弗莫尔国家实验室(Lawrence Livermore National Lab.)由J.O.Hallquist 主持开发完成的，主要目的是为核武器的弹头设计提供分析工具，后经多次扩充和改进，计算功能更为强大。
虽然该软件声称可以求解各种三维非线性结构的高速碰撞、爆炸和金属成型等接触非线性、冲击载荷非线性和材料非线性问题，但实际上它在爆炸冲击方面，功能相对较弱，其欧拉混合单元中目前最多只能容许三种物质，边界处理很粗糙，在拉格朗日——欧拉结合方面不如DYTRAN灵活。
2. MSC.software公司的 DYTRAN软件 在同类软件中，DYTRAN在高度非线性、流固耦合方面有独特之处。
MSC.DYTRAN程序是在LS-DYNA3D的框架下，在程序中增加荷兰PISCES INTERNATIONAL公司开发的PICSES的高级流体动力学和流体结构相互作用功能，还在PISCES的欧拉模式算法基础上，开发了物质流动算法和流固耦合算法发展而来的。
常用结构软件比较
常用结构软件比较本文仅限于混凝土结构计算程序。
目前的结构计算程序主要有：PKPM系列 TAT、SATWE 、TBSA系列 TBSA、TBWE、TBSAP 、BSCW、GSCAD、 SAP系列。
其他一些结构计算程序如ETABS等,虽然功能强大,且在国外也相当流行,但国内实际上使用的不多,故不做详细讨论。
一、结构计算程序的分析与比较1、结构主体计算程序的模型与优缺点从主体计算程序所采用的模型单元来说:TAT和TBSA属于结构空间分析的第一代程序,其构件均采用空间杆系单元,其中梁、柱均采用简化的空间杆单元,剪力墙则采用空间薄壁杆单元。
在形成单刚后再加入刚性楼板的位移协调矩阵,引入了楼板无限刚性假设,大大减少了结构自由度。
SATWE、TBWE和TBSAP在此基础上加入了墙元,SATWE和TBSAP还加入了楼板分块刚性假设与弹性楼板假设,更能适应复杂的结构。
SATWE提供了梁元、等截面圆弧形曲梁单元、柱元、杆元、墙元、弹性楼板单元包括三角形和矩形薄壳单元、四节点等参薄壳单元和厚板单元包括三角形厚板单元和四节点等参厚板单元。
另外,通过与JCCAD 的联合,还能实现基础-上部结构的整体协同计算。
TBSAP提供的单元除了常用的杆单元、梁柱单元外,还提供了用以计算板的四边形或三角形壳元、墙元、用以计算厚板转换层的八节点四十八自由度三维元、广义单元包括罚单元与集中单元 ,以及进行基础计算用的弹性地基梁单元、弹性地基柱单元桩元、三角形或四边形弹性地基板单元和地基土元。
TBSAP可以对结构进行基础-上部结构-楼板的整体联算。
从计算准确性的角度来说:SAP84是最为精确的,其单元类型非常丰富,而且能够对结构进行静力、动力等多种计算。
最为关键的是,使用SAP84时能根据结构的实际情况进行单元划分,其计算模型是最为接近实际结构。
BSCW和GSCAD 的情况比较特殊,严格说来这两个程序均是前后处理工具,其开发者并没有进行结构计算程序的开发。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
常用软件开发模型比较分析2007-09-26 20:21正如任何事物一样，软件也有其孕育、诞生、成长、成熟和衰亡的生存过程，一般称其为“软件生命周期”。
软件生命周期一般分为6个阶段，即制定计划、需求分析、设计、编码、测试、运行和维护。
软件开发的各个阶段之间的关系不可能是顺序且线性的，而应该是带有反馈的迭代过程。
在软件工程中，这个复杂的过程用软件开发模型来描述和表示。
软件开发模型是跨越整个软件生存周期的系统开发、运行和维护所实施的全部工作和任务的结构框架，它给出了软件开发活动各阶段之间的关系。
目前，常见的软件开发模型大致可分为如下3种类型。
① 以软件需求完全确定为前提的瀑布模型（Waterfall Model）。
② 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型，如螺旋模型（Spiral Model）。
③ 以形式化开发方法为基础的变换模型（T ransformational Model）。
本节将简单地比较并分析瀑布模型、螺旋模型和变换模型等软件开发模型。
1.2.1 瀑布模型瀑布模型即生存周期模型，其核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。
瀑布模型将软件生命周期划分为软件计划、需求分析和定义、软件设计、软件实现、软件测试、软件运行和维护这6个阶段，规定了它们自上而下、相互衔接的固定次序，如同瀑布流水逐级下落。
采用瀑布模型的软件过程如图1-3所示。
图1-3 采用瀑布模型的软件过程瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本框架。
瀑布模型的本质是一次通过，即每个活动只执行一次，最后得到软件产品，也称为“线性顺序模型”或者“传统生命周期”。
其过程是从上一项活动接收该项活动的工作对象作为输入，利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，并作为输出传给下一项活动。
同时评审该项活动的实施，若确认，则继续下一项活动；否则返回前面，甚至更前面的活动。
瀑布模型有利于大型软件开发过程中人员的组织及管理，有利于软件开发方法和工具的研究与使用，从而提高了大型软件项目开发的质量和效率。
然而软件开发的实践表明，上述各项活动之间并非完全是自上而下且呈线性图式的，因此瀑布模型存在严重的缺陷。
① 由于开发模型呈线性，所以当开发成果尚未经过测试时，用户无法看到软件的效果。
这样软件与用户见面的时间间隔较长，也增加了一定的风险。
② 在软件开发前期末发现的错误传到后面的开发活动中时，可能会扩散，进而可能会造成整个软件项目开发失败。
③ 在软件需求分析阶段，完全确定用户的所有需求是比较困难的，甚至可以说是不太可能的。
1.2.2 螺旋模型螺旋模型将瀑布和演化模型（Evolution Model）结合起来，它不仅体现了两个模型的优点，而且还强调了其他模型均忽略了的风险分析。
这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。
软件开发过程每迭代一次，软件开发又前进一个层次。
采用螺旋模型的软件过程如图1-4所示。
图1-4 采用螺旋模型的软件过程螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。
每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。
螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。
对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。
减小软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而消除或减少风险的损害。
与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高目标软件的适应能力。
并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发风险。
但是，我们不能说螺旋模型绝对比其他模型优越，事实上，这种模型也有其自身的如下缺点。
① 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。
② 过多的迭代次数会增加开发成本，延迟提交时间。
1.2.3 变换模型变换模型是基于形式化规格说明语言及程序变换的软件开发模型，它采用形式化的软件开发方法对形式化的软件规格说明进行一系列自动或半自动的程序变换，最后映射为计算机系统能够接受的程序系统。
采用变换模型的软件过程如图1-5所示。
图1-5 采用变换模型的软件过程为了确认形式化规格说明与软件需求的一致性，往往以形式化规格说明为基础开发一个软件原型，用户可以从人机界面、系统主要功能和性能等几个方面对原型进行评审。
必要时，可以修改软件需求、形式化规格说明和原型，直至原型被确认为止。
这时软件开发人员即可对形式化的规格说明进行一系列的程序变换，直至生成计算机系统可以接受的目标代码。
“程序变换”是软件开发的另一种方法，其基本思想是把程序设计的过程分为生成阶段和改进阶段。
首先通过对问题的分析制定形式规范并生成一个程序，通常是一种函数型的“递归方程”。
然后通过一系列保持正确性的源程序到源程序的变换，把函数型风格转换成过程型风格并进行数据结构和算法的求精，最终得到一个有效的面向过程的程序。
这种变换过程是一种严格的形式推导过程，所以只需对变换前的程序的规范加以验证，变换后的程序的正确性将由变换法则的正确性来保证。
变换模型的优点是解决了代码结构经多次修改而变坏的问题，减少了许多中间步骤（如设计、编码和测试等）。
但是变换模型仍有较大局限，以形式化开发方法为基础的变换模型需要严格的数学理论和一整套开发环境的支持，目前形式化开发方法在理论、实践和人员培训方面距工程应用尚有一段距离。
1.2.4 喷泉模型喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。
该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的，就像水喷上去又可以落下来，类似一个喷泉。
各个开发阶段没有特定的次序要求，并且可以交互进行，可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏。
采用喷泉模型的软件过程如图1-6所示。
图1-6 采用喷泉模型的软件过程喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。
各活动之间无明显边界，例如设计和实现之间没有明显的边界，这也称为“喷泉模型的无间隙性”。
由于对象概念的引入，表达分析、设计及实现等活动只用对象类和关系，从而可以较容易地实现活动的迭代和无间隙。
喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。
该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。
其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程。
由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。
此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。
1.2.5 智能模型智能模型也称为“基于知识的软件开发模型”，它把瀑布模型和专家系统结合在一起，利用专家系统来帮助软件开发人员的工作。
该模型应用基于规则的系统，采用归纳和推理机制，使维护在系统规格说明一级进行。
这种模型在实施过程中以软件工程知识为基础的生成规则构成的知识系统与包含应用领域知识规则的专家系统相结合，构成这一应用领域软件的开发系统。
采用智能模型的软件过程如图1-7所示。
图1-7 采用智能模型的软件过程智能模型所要解决的问题是特定领域的复杂问题，涉及大量的专业知识，而开发人员一般不是该领域的专家，他们对特定领域的熟悉需要一个过程，所以软件需求在初始阶段很难定义得很完整。
因此，采用原型实现模型需要通过多次迭代来精化软件需求。
智能模型以知识作为处理对象，这些知识既有理论知识，也有特定领域的经验。
在开发过程中需要将这些知识从书本中和特定领域的知识库中抽取出来（即知识获取），选择适当的方法进行编码（即知识表示）建立知识库。
将模型、软件工程知识与特定领域的知识分别存入数据库，在这个过程中需要系统开发人员与领域专家的密切合作。
智能模型开发的软件系统强调数据的含义，并试图使用现实世界的语言表达数据的含义。
该模型可以勘探现有的数据，从中发现新的事实方法指导用户以专家的水平解决复杂的问题。
它以瀑布模型为基本框架，在不同开发阶段引入了原型实现方法和面向对象技术以克服瀑布模型的缺点，适应于特定领域软件和专家决策系统的开发。
1.2.6 增量模型增量模型融合了瀑布模型的基本成分（重复应用）和原型实现的迭代特征，该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”。
当使用增量模型时，第1个增量往往是核心的产品，即第1个增量实现了基本的需求，但很多补充的特征还没有发布。
客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。
增量模型强调每一个增量均发布一个可操作的产品。
采用增量模型的软件过程如图1-8所示。
增量模型与原型实现模型和其他演化方法一样，本质上是迭代的，但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。
早期的增量是最终产品的“可拆卸”版本，但提供了为用户服务的功能，并且为用户提供了评估的平台。
增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。
虽然某个增量包可能还需要进一步适应客户的需求并且更改，但只要这个增量包足够小，其影响对整个项目来说是可以承受的。
图1-8 采用增量模型的软件过程采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源。
如果核心产品很受欢迎，则可增加人力实现下一个增量。
当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。
这样即可先发布部分功能给客户，对客户起到镇静剂的作用。
此外，增量能够有计划地管理技术风险。
增量模型的缺点是如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。
1.2.7 WINWIN模型WINWIN模型融合了螺旋模型的基本成分和原型实现的迭代特征，强调风险分析和标识。
通过早期谈判使客户和开发者之间达成一致协议，它将变成进展到软件和系统定义的关键标准。
WINWIN模型引入了3个里程碑，称为“抛锚点”。