常用软件开发模型

精品文档 1欢迎下载 常用软件开发模型比较分析 正如任何事物一样 软件也有其孕育 诞生 成长 成熟和衰亡的生存过程 一般称 其为 软件生命周期 软件生命周期一般分为 6 个阶段 即制定计划 需求分析 设计 编码 测试 运行和维护 软件开发的各个阶段之间的关系不可能是顺序且线性的 而应 该是带有反馈的迭代过程 在软件工程中 这个复杂的过程用软件开发模型来描述和表示 软件开发模型是跨越整个软件生存周期的系统开发 运行和维护所实施的全部工作和 任务的结构框架 它给出了软件开发活动各阶段之间的关系 目前 常见的软件开发模型 大致可分为如下 3 种类型 以软件需求完全确定为前提的瀑布模型 Waterfall Model 在软件开发初始阶段只能提供基本需求时采用的渐进式开发模型 如螺旋模型 Spiral Model 以形式化开发方法为基础的变换模型 Transformational Model 本节将简单地比较并分析瀑布模型 螺旋模型和变换模型等软件开发模型 1 2 1 瀑布模型 瀑布模型即生存周期模型 其核心思想是按工序将问题化简 将功能的实现与设计分 开 便于分工协作 即采用结构化的分析与设计方法将逻辑实现与物理实现分开 瀑布模 型将软件生命周期划分为软件计划 需求分析和定义 软件设计 软件实现 软件测试 软件运行和维护这 6 个阶段 规定了它们自上而下 相互衔接的固定次序 如同瀑布流水 逐级下落 采用瀑布模型的软件过程如图 1 3 所示 图 1 3 采用瀑布模型的软件过程 精品文档 2欢迎下载 瀑布模型是最早出现的软件开发模型 在软件工程中占有重要的地位 它提供了软件 开发的基本框架 瀑布模型的本质是一次通过 即每个活动只执行一次 最后得到软件产 品 也称为 线性顺序模型 或者 传统生命周期 其过程是从上一项活动接收该项活动的工 作对象作为输入 利用这一输入实施该项活动应完成的内容给出该项活动的工作成果 并 作为输出传给下一项活动 同时评审该项活动的实施 若确认 则继续下一项活动 否则 返回前面 甚至更前面的活动 瀑布模型有利于大型软件开发过程中人员的组织及管理 有利于软件开发方法和工具 的研究与使用 从而提高了大型软件项目开发的质量和效率 然而软件开发的实践表明 上述各项活动之间并非完全是自上而下且呈线性图式的 因此瀑布模型存在严重的缺陷 由于开发模型呈线性 所以当开发成果尚未经过测试时 用户无法看到软件的效果 这样软件与用户见面的时间间隔较长 也增加了一定的风险 在软件开发前期末发现的错误传到后面的开发活动中时 可能会扩散 进而可能会 造成整个软件项目开发失败 在软件需求分析阶段 完全确定用户的所有需求是比较困难的 甚至可以说是不太 可能的 1 2 2 螺旋模型 螺旋模型将瀑布和演化模型 Evolution Model 结合起来 它不仅体现了两个模型的 优点 而且还强调了其他模型均忽略了的风险分析 这种模型的每一个周期都包括需求定 义 风险分析 工程实现和评审 4 个阶段 由这 4 个阶段进行迭代 软件开发过程每迭代 一次 软件开发又前进一个层次 采用螺旋模型的软件过程如图 1 4 所示 图 1 4 采用螺旋模型的软件过程 螺旋模型基本做法是在 瀑布模型 的每一个开发阶段前引入一个非常严格的风险识别 风险分析和风险控制 它把软件项目分解成一个个小项目 每个小项目都标识一个或多个 主要风险 直到所有的主要风险因素都被确定 精品文档 3欢迎下载 螺旋模型强调风险分析 使得开发人员和用户对每个演化层出现的风险有所了解 继 而做出应有的反应 因此特别适用于庞大 复杂并具有高风险的系统 对于这些系统 风 险是软件开发不可忽视且潜在的不利因素 它可能在不同程度上损害软件开发过程 影响 软件产品的质量 减小软件风险的目标是在造成危害之前 及时对风险进行识别及分析 决定采取何种对策 进而消除或减少风险的损害 与瀑布模型相比 螺旋模型支持用户需求的动态变化 为用户参与软件开发的所有关 键决策提供了方便 有助于提高目标软件的适应能力 并且为项目管理人员及时调整管理 决策提供了便利 从而降低了软件开发风险 但是 我们不能说螺旋模型绝对比其他模型优越 事实上 这种模型也有其自身的如 下缺点 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识 在风险较大的项目开 发中 如果未能够及时标识风险 势必造成重大损失 过多的迭代次数会增加开发成本 延迟提交时间 1 2 3 变换模型 变换模型是基于形式化规格说明语言及程序变换的软件开发模型 它采用形式化的软 件开发方法对形式化的软件规格说明进行一系列自动或半自动的程序变换 最后映射为计 算机系统能够接受的程序系统 采用变换模型的软件过程如图 1 5 所示 图 1 5 采用变换模型的软件过程 为了确认形式化规格说明与软件需求的一致性 往往以形式化规格说明为基础开发一 个软件原型 用户可以从人机界面 系统主要功能和性能等几个方面对原型进行评审 必 要时 可以修改软件需求 形式化规格说明和原型 直至原型被确认为止 这时软件开发 人员即可对形式化的规格说明进行一系列的程序变换 直至生成计算机系统可以接受的目 标代码 程序变换 是软件开发的另一种方法 其基本思想是把程序设计的过程分为生成阶段 和改进阶段 首先通过对问题的分析制定形式规范并生成一个程序 通常是一种函数型的 递归方程 然后通过一系列保持正确性的源程序到源程序的变换 把函数型风格转换成 过程型风格并进行数据结构和算法的求精 最终得到一个有效的面向过程的程序 这种变 换过程是一种严格的形式推导过程 所以只需对变换前的程序的规范加以验证 变换后的 程序的正确性将由变换法则的正确性来保证 变换模型的优点是解决了代码结构经多次修改而变坏的问题 减少了许多中间步骤 如设计 编码和测试等 但是变换模型仍有较大局限 以形式化开发方法为基础的变 精品文档 4欢迎下载 换模型需要严格的数学理论和一整套开发环境的支持 目前形式化开发方法在理论 实践 和人员培训方面距工程应用尚有一段距离 1 2 4 喷泉模型 喷泉模型是一种以用户需求为动力 以对象为驱动的模型 主要用于描述面向对象的 软件开发过程 该模型认为软件开发过程自下而上周期的各阶段是相互重叠和多次反复的 就像水喷上去又可以落下来 类似一个喷泉 各个开发阶段没有特定的次序要求 并且可 以交互进行 可以在某个开发阶段中随时补充其他任何开发阶段中的遗漏 采用喷泉模型 的软件过程如图 1 6 所示 图 1 6 采用喷泉模型的软件过程 喷泉模型主要用于面向对象的软件项目 软件的某个部分通常被重复多次 相关对象 在每次迭代中随之加入渐进的软件成分 各活动之间无明显边界 例如设计和实现之间没 有明显的边界 这也称为 喷泉模型的无间隙性 由于对象概念的引入 表达分析 设计 及实现等活动只用对象类和关系 从而可以较容易地实现活动的迭代和无间隙 喷泉模型不像瀑布模型那样 需要分析活动结束后才开始设计活动 设计活动结束后 才开始编码活动 该模型的各个阶段没有明显的界限 开发人员可以同步进行开发 其优 点是可以提高软件项目开发效率 节省开发时间 适应于面向对象的软件开发过程 由于 喷泉模型在各个开发阶段是重叠的 因此在开发过程中需要大量的开发人员 因此不利于 项目的管理 此外这种模型要求严格管理文档 使得审核的难度加大 尤其是面对可能随 时加入各种信息 需求与资料的情况 1 2 5 智能模型 智能模型也称为 基于知识的软件开发模型 它把瀑布模型和专家系统结合在一起 利用专家系统来帮助软件开发人员的工作 该模型应用基于规则的系统 采用归纳和推理 机制 使维护在系统规格说明一级进行 这种模型在实施过程中以软件工程知识为基础的 生成规则构成的知识系统与包含应用领域知识规则的专家系统相结合 构成这一应用领域 软件的开发系统 采用智能模型的软件过程如图 1 7 所示 精品文档 5欢迎下载 图 1 7 采用智能模型的软件过程 智能模型所要解决的问题是特定领域的复杂问题 涉及大量的专业知识 而开发人员 一般不是该领域的专家 他们对特定领域的熟悉需要一个过程 所以软件需求在初始阶段 很难定义得很完整 因此 采用原型实现模型需要通过多次迭代来精化软件需求 智能模型以知识作为处理对象 这些知识既有理论知识 也有特定领域的经验 在开 发过程中需要将这些知识从书本中和特定领域的知识库中抽取出来 即知识获取 选择 适当的方法进行编码 即知识表示 建立知识库 将模型 软件工程知识与特定领域的知 识分别存入数据库 在这个过程中需要系统开发人员与领域专家的密切合作 智能模型开发的软件系统强调数据的含义 并试图使用现实世界的语言表达数据的含 义 该模型可以勘探现有的数据 从中发现新的事实方法指导用户以专家的水平解决复杂 的问题 它以瀑布模型为基本框架 在不同开发阶段引入了原型实现方法和面向对象技术 以克服瀑布模型的缺点 适应于特定领域软件和专家决策系统的开发 1 2 6 增量模型 增量模型融合了瀑布模型的基本成分 重复应用 和原型实现的迭代特征 该模型采 用随着日程时间的进展而交错的线性序列 每一个线性序列产生软件的一个可发布的 增量 当使用增量模型时 第 1 个增量往往是核心的产品 即第 1 个增量实现了基本的需求 但很多补充的特征还没有发布 客户对每一个增量的使用和评估都作为下一个增量发布的 新特征和功能 这个过程在每一个增量发布后不断重复 直到产生了最终的完善产品 增 量模型强调每一个增量均发布一个可操作的产品 采用增量模型的软件过程如图 1 8 所示 增量模型与原型实现模型和其他演化方法一样 本质上是迭代的 但与原型实现不一 样的是其强调每一个增量均发布一个可操作产品 早期的增量是最终产品的 可拆卸 版本 但提供了为用户服务的功能 并且为用户提供了评估的平台 增量模型的特点是引进了增 量包的概念 无须等到所有需求都出来 只要某个需求的增量包出来即可进行开发 虽然 精品文档 6欢迎下载 某个增量包可能还需要进一步适应客户的需求并且更改 但只要这个增量包足够小 其影 响对整个项目来说是可以承受的 图 1 8 采用增量模型的软件过程 采用增量模型的优点是人员分配灵活 刚开始不用投入大量人力资源 如果核心产品 很受欢迎 则可增加人力实现下一个增量 当配备的人员不能在设定的期限内完成产品时 它提供了一种先推出核心产品的途径 这样即可先发布部分功能给客户 对客户起到镇静 剂的作用 此外 增量能够有计划地管理技术风险 增量模型的缺点是如果增量包之间存 在相交的情况且未很好处理 则必须做全盘系统分析 这种模型将功能细化后分别开发的 方法较适应于需求经常改变的软件开发过程 1 2 7 WINWIN 模型 WINWIN 模型融合了螺旋模型的基本成分和原型实现的迭代特征 强调风险分析和标识 通过早期谈判使客户和开发者之间达成一致协议 它将变成进展到软件和系统定义的关键 标准 WINWIN 模型引入了 3 个里程碑 称为 抛锚点 它可帮助建立一个生命周期的完全 性 并提供在软件项目向前进展前的决策里程碑 采用 WINWIN 模型的软件过程如图 1 9 所 示 图 1 9 采用 WINWIN 模型的软件过程 本质上 抛锚点表示了项目遍历螺旋时的 3 个不同的进展视图 第 1 个抛锚点称为 生 存周期目标 定义了一组针对每个主要软件工程活动的目标 第 2 个抛锚点称为 生存周 期体系结构 建立了当系统和软件体系结构被定义时必须满足的目标 第 3 个抛锚点称为 初始操作能力 它表示一组目标 这些目标和将要安装 销售软件的安装前场地准备和 将使用该软件的各方所需的帮助相关联 WINWIN 模型强调风险分析和标识 使得开发人员和用户对每个演化层出现的风险有所 了解 继而做出应有的反应 采用 WINWIN 模型的优点是客户和开发者达到一种平衡 实现 双赢 但是需要额外的谈判技巧 螺旋模型提出了强调客户交流的一个框架活动 该活动的目标是从客户处诱导出项目 需求 在理想情况下 开发人员简单地询问客户需要什么 而客户提供足够的细节进行下 去 不幸的是这种情形很少发生 而在 WINWIN 模型中 客户和开发人员进入一个谈判过程 客户被要求在成本和应市之间的约束下平衡功能 性能和其他产品或系统特征 最好的谈 判追求 双赢 结果 即通过谈判客户获得大部分系统的功能 而开发人员则获得现实和可 达到的预算和时限 1 2 8 原型实现模型 精品文档 7欢迎下载 原型实现模型从需求收集开始 开发者和客户在一起定义软件的总体目标 标识出已 知的需求 并规划出需要进一步定义的区域 然后是 快速设计 即集中于软件中那些对 用户 客户可见的部分的表示 这将导致原型的创建 并由用户 客户评估并进一步精化 待开发软件的需求 逐步调整原型使其满足客户的要求 而同时也使开发者对将要做的事 情有更好的理解 这个过程是迭代的 其流程从听取客户意见开始 随后是建造 修改原 型 客户测试运行原型 然后往复循环 直到客户对原型满意为止 采用原型实现模型的 软件过程如图 1 10 所示 图 1 10 采用原型实现模型的软件过程 原型实现模型的最大特点是能够快速实现一个可实际运行的系统初步模型 供开发人 员和用户进行交流和评审 以便较准确地获得用户的需求 该模型采用逐步求精方法使原 型逐步完善 即每次经用户评审后修改 运行 不断重复得到双方认可 这个过程是迭代 过程 它可以避免在瀑布模型冗长的开发过程中看不见产品雏形的现象 其优点一是开发 工具先进 开发效率高 使总的开发费用降低 时间缩短 二是开发人员与用户交流直观 可以澄清模糊需求 调动用户的积极参与 能及早暴露系统实施后潜在的一些问题 三是 原型系统可作为培训环境 有利于用户培训和开发同步 开发过程也是学习过程 原型实现模型的缺点是产品原型在一定程度上限制了开发人员的创新 没有考虑软件 的整体质量和长期的可维护性 由于达不到质量要求产品可能被抛弃 而采用新的模型重 新设计 因此原型实现模型不适合嵌入式 实时控制及科学数值计算等大型软件系统的开 发 增量模型和原型模型都是从概要需求出发开发的 但二者有明显不同 增量模型是从 一些不完整的系统需求出发开始开发 在开发过程中逐渐发现新的需求 然后进一步充实 完善该系统 使之成为实际可用的系统 原型开发的目的是为了发现并建立一个完整并经 过证实的需求规格说明 然后以此作为正式系统的开发基础 因此原型开发阶段的输出是 需求规格说明 这是为了降低整个软件生成期的费用而拉大需求分析阶段的一种方法 大 部分原型是 用完就扔 的类型 1 2 9 RAD 模型 RAD 快速应用开发 模型是一个增量型的软件开发过程模型 强调极短的开发周期 该模型是瀑布模型的一个 高速 变种 通过大量使用可复用构件 采用基于构件的建造方 法赢得了快速开发 如果正确地理解了需求 而且约束了项目的范围 利用这种模型可以 很快创建出功能完善的信息系统 其流程从业务建模开始 随后是数据建模 过程建模 应用生成 测试及反复 采用 RAD 模型的软件过程如图 1 11 所示 精品文档 8欢迎下载 图 1 11 采用 RAD 模型的软件过程 RAD 模型各个活动期所要完成的任务如下 1 业务建模 确定驱动业务过程运作的信息 要生成的信息 如何生成 信息流的去向及其处理等 可以辅之以数据流图 2 数据建模 为支持业务过程的数据流查找数据对象集合 定义数据对象属性 并与其他数据对象 的关系构成数据模型 可辅之以 E R 图 3 过程建模 使数据对象在信息流中完成各业务功能 创建过程以描述数据对象的增加 修改 删 除 查找 即细化数据流图中的处理框 4 应用程序生成 利用第 4 代语言 4GL 写出处理程序 重用已有构件或创建新的可重用构件 利用环 境提供的工具自动生成以构造出整个的应用系统 5 测试与交付 由于大量重用 一般只做总体测试 但新创建的构件还是要测试的 与瀑布模型相比 RAD 模型不采用传统的第 3 代程序设计语言来创建软件 而是采用 基于构件的开发方法复用已有的程序结构 如果可能 或使用可复用构件和或创建可复用 的构件 如果需要 在所有情况下 均使用自动化工具辅助软件创造 很显然 加在一 个 RAD 模型项目上的时间约束需要 一个可伸缩的范围 如果一个业务能够被模块化使得 精品文档 9欢迎下载 其中每一个主要功能均可以在不到 3 个月的时间内完成 则其是 RAD 的一个候选者 每一 个主要功能可由一个单独的 RAD 组来实现 最后集成起来形成一个整体 RAD 模型通过大量使用可复用构件加快了开发速度 对信息系统的开发特别有效 但 是与所有其他软件过程模型一样 RAD 方法有如下缺陷 并非所有应用都适合 RAD RAD 模型对模块化要求比较高 如果有哪一个功能不能 被模块化 那么建造 RAD 所需要的构件就会有问题 如果高性能是一个指标且该指标必须 通过调整接口使其适应系统构件才能赢得 RAD 方法也有可能不能奏效 开发人员和客户必须在很短的时间内完成一系列的需求分析 任何一方配合不当都 会导致 RAD 项目失败 RAD 只能用于信息系统开发 不适合技术风险很高的情况 当一个新应用要采用很 多新技术或当新软件要求与已有的计算机程序的高互操作性时 这种情况就会发生 1 2 10 并发开发模型 并发开发模型也称为 并发工程 它关注于多个任务的并发执行 表示为一系列的主 要技术活动 任务及其相关状态 并发过程模型由客户要求 管理决策 评审结果驱动 不是将软件工程活动限定为一个顺序的事件序列 而是定义一个活动网络 网络上的每一 个活动均可与其他活动同时发生 这种模型可以提供一个项目的当前状态的准确视图 采 用并发开发模型的软件过程中一个活动的示意如图 1 12 所示 图 1 12 并发过程模型的一个活动 并发过程模型定义了一系列事件 对于每一个软件工程活动 它们触发一个状态到另 一个状态的变迁 当它应用于客户机 服务器系统时 并发过程模型在两维上定义活动 即一个系统维和一个构件维 其并发性通过如下两种方式得到 系统维和构件维活动同时发生 并可以使用面向状态的方法进行建模 一个典型的客户 服务器应用通过多个构件实现 其中每个构件均可以并发设计并 实现 精品文档 10欢迎下载 并发开发模型试图根据传统生命周期的主要阶段来追踪项目的状态 项目管理者根本 不可能了解项目的状态 因而需要使用比较简单的模型来追踪非常复杂的项目活动 并发 开发模型使用状态图 表示一个加工状态 来表示与一个特定事件 如在开发后期需求的 一个修改 相关的活动之间存在的并发关系 但它不能捕获到贯穿于一个项目中所有软件 开发和管理活动的大量并发 大多数软件开发过程模型均为时间驱动 越到模型的后端 就越到开发过程的后一阶 段 而一个并发过程模型是由用户要求 管理决策和结果复审驱动的 并发开发模型在软 件开发全过程活动的并行化 打破了传统软件开发的各阶段分割封闭的观念 强调开发人 员团队协作 注重分析和设计等前段开发工作 从而避免了不必要的返工 其优点是可用 于所有类型的软件开发 而对于客户 服务器结构更加有效 可以随时查阅到开发的状态 1 2 11 基于构件的开发模型 基于构件的开发模型利用模块化方法将整个系统模块化 并在一定构件模型的支持下 复用构件库中的一个或多个软件构件 通过组合手段高效率 高质量地构造应用软件系统 的过程 基于构件的开发模型融合了螺旋模型的许多特征 本质上是演化形的 开发过程 是迭代的 基于构件的开发模型由软件的需求分析和定义 体系结构设计 构件库建立 应用软件构建 以及测试和发布 5 个阶段组成 采用这种开发模型的软件过程如图 1 13 所 示 图 1 13 采用基于构件的开发模型的软件过程 构件作为重要的软件技术和工具得到极大的发展 这些新技术和工具有 Microsoft 的 DCOM Sun 的 EJB 以及 OMG 的 CORBA 等 基于构件的开发活动从标识候选构件开始 通过 搜查已有构件库 确认所需要的构件是否已经存在 如果已经存在 则从构件库中提取出 来复用 否则采用面向对象方法开发它 之后利用提取出来的构件通过语法和语义检查后 将这些构件通过胶合代码组装到一起实现系统 这个过程是迭代的 基于构件的开发方法使得软件开发不再一切从头开发 开发的过程就是构件组装的过 程 维护的过程就是构件升级 替换和扩充的过程 其优点是构件组装模型导致了软件的 复用 提高了软件开发的效率 构件可由一方定义其规格说明 被另一方实现 然后供给 第三方使用 构件组装模型允许多个项目同时开发 降低了费用 提高了可维护性 可实 现分步提交软件产品 由于采用自定义的组装结构标准 缺乏通用的组装结构标准 因而引入了较大的风险 可重用性和软件高效性不易协调 需要精干的有经验的分析和开发人员 一般开发人员插 不上手 客户的满意度低 并且由于过分依赖于构件 所以构件库的质量影响着产品质量 精品文档 11欢迎下载 1 2 12 基于体系结构的开发模型 基于体系结构的开发模型是以软件体系结构为核心 以基于构件的开发方法为基础 然后采用迭代增量方式进行分析和设计 将功能设计空间映射到结构设计空间 再由结构 设计空间映射到系统设计空间的过程 该开发模型把软件生命周期分为软件定义 需求分 析和定义 体系结构设计 软件系统设计和软件实现 5 个阶段 采用这种开发模型的软件 过程如图 1 14 所示 图 1 14 采用基于体系结构的开发模型的软件过程 在基于体系结构的开发过程中 首先是基于体系结构的需求获取和分析 将软件体系 结构的概念引入到需求空间 从而为分析阶段到设计阶段的过渡提供更好的支持 在需求 分析结果的基础上 进行体系结构的设计 考虑系统的总体结构及系统的构成元素 根据 构成元素的语法和语义在已确定的构件库中寻找匹配的构件 当不存在符合要求的构件时 则根据具体情况组装合成新构件或者购买新构件或者根据需要开发新构件而得到满足需求 的构件 在经过语法和语义检查后 将这些构件通过胶合代码组装到一起实现整个软件系 统 在实践中 整个开发过程呈现多次迭代性 在传统的软件生命周期中 软件需求分析和定义完成后紧接的是软件系统的设计和实 现 在这种传统的开发方法中 如果软件需求不断变化 最终软件产品可能与初始原型相 差很大 而基于体系结构的开发模型有严格的理论基础和工程原则 是以体系结构为核心 体系结构为软件需求与软件设计之间架起了一座桥梁 解决了软件系统从需求到实现的平 缓过渡 提高了软件分析设计的质量和效率 基于体系结构的开发模型的优点是通过对体系结构的设计 使得软件系统结构框架更 清晰 有利于系统的设计 开发和维护 并且软件复用从代码级的复用提升到构件和体系 结构级的复用 基于体系结构的开发模型和基于构件的开发模型都是在体系结构的基础上进行构件的 组装而得到软件系统 前者主要关注运行级构件及其之间的互操作性 提供了一种自底向 上且基于预先定制好的构件来构造应用系统的途径 后者局限在构件的规范上 缺少系统 化的指导开发过程的方法学 基于体系结构的开发方法从系统的总体结构入手 将一个系 统的体系结构显示化 以在高抽象层次处理诸如全局组织和控制结构 功能到计算元素的 分配 计算元素间的高层交互等设计问题 1 2 13 XP 方法 敏捷方法是近几年兴起的一种轻量级的开发方法 它强调适应性而非预测性 强调以 人为中心 而不以流程为中心 以及对变化的适应和对人性的关注 其特点是轻载 基于 时间 Just Enough 并行并基于构件的软件过程 在所有的敏捷方法中 XP eXtreme Programming 方法是最引人注目的一种轻型开发方法 它规定了一组核心价值和方法 消 精品文档 12欢迎下载 除了大多数重量型过程的不必要产物 建立了一个渐进型开发过程 该方法将开发阶段的 4 个活动 分析 设计 编码和测试 混合在一起 在全过程中采用迭代增量开发 反馈 修正和反复测试 它把软件生命周期划分为用户故事 体系结构 发布计划 交互 接受 测试和小型发布 6 个阶段 采用这种开发模型的软件过程如图 1 15 所示 图 1 15 采用 XP 方法的软件过程 XP 模型通过对传统软件开发的标准方法进行重新审视 提出了由一组规则组成的一些 简便易行的过程 由于这些规则是通过在实践中观察使软件高效或缓慢的因素而得出的 因此它既考虑了保持开发人员的活力和创造性 又考虑了开发过程的有组织 有重点和持 续性 XP 模型是面向客户的开发模型 重点强调用户的满意程度 开发过程中对需求改变 的适应能力较高 即使在开发的后期 也可较高程度地适应用户的改变 XP 开发模型与传统模型相比具有很大的不同 其核心思想是交流 Communication 简单 Simplicity 反馈 Feedback 和进取 Aggressiveness XP 开发小组不仅包 括开发人员 还包括管理人员和客户 该模型强调小组内成员之间要经常进行交流 在尽 量保证质量可以运行的前提下力求过程和代码的简单化 来自客户 开发人员和最终用户 的具体反馈意见可以提供更多的机会来调整设计 保证把握正确的开发方向 进取则包含 于上述 3 个原则中 XP 开发方法中有许多新思路 如采用 用户故事 代替传统模型中的需求分析 用户故 事 由用户用自己领域中的词汇并且不考虑任何技术细节准确地表达自己的需求 XP 模型 的优点如下 采用简单计划策略 不需要长期计划和复杂模型 开发周期短 在全过程采用迭代增量开发 反馈修正和反复测试的方法 软件质量有保证 能够适应用户经常变化的需求 提供用户满意的高质量软件 1 2 14 第 4 代技术 第 4 代技术 4GT 包含一系列软件工具 它们都具有一个共同点 即能使软件工程师 在较高级别上规约软件的某些特征 然后根据开发者的规约自动生成源代码 毫无疑问 软件在越高级别上被规约就能越快速地构造出程序 软件工程的第 4 代技术模型集中于规 约软件的能力 即使用特殊的语言形式或一种采用客户可以理解的术语描述待解决问题的 图形符号体系 与其他模型一样 第 4 代技术也是从需求收集开始的 理想情况下 客户能够描述出 需求 而这些需求能被直接转换成可操作原型 但这是不现实的 客户可能不能完全确定 需要什么 在规约已知的事实时可能出现二义性 因此其他模型中所描述的用户 开发者 对话在第