软件工程之软件开发模型

软件工程之软件开发模型第一页，共37页软件开发模型：软件开发模型是软件开发的全部过程、活动、任务和管理的结构框架。软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。

选择合适的开发模型是十分重要的软件开发模型与软件工程第二页，共37页软件开发模型是将软件开发中的主要活动细分为：软件开发模型与软件工程系统需求分析程序设计程序编码测试运行维护系统设计人员管理项目管理第三页，共37页常见的开发模型：瀑布模型、演化模型、螺旋模型、XP开发模型、快速开发模型等。由于现在还没有任何一种方法能够解决软件危机中的所有问题，所以在软件开发的各个阶段采用综合治理的方法。软件开发模型直接影响软件开发的周期和软件质量，是软件开发的组织管理形式，是软件工程最重要的内容之一。软件开发模型与软件工程第四页，共37页2.2.1瀑布模型的概念：瀑布模型（WaterfallModel）瀑布模型是将软件生存周期各活动规定为依线性顺序联接的若干阶段的模型。它包括需求分析、概要设计、详细设计、编码、测试和维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水，逐级下落。第五页，共37页2.2.1瀑布模型的概念：瀑布模型（WaterfallModel）需求分析系统设计程序设计编码测试运行及维护瀑布模型（需求说明书）（系统设计书）（程序设计书）（程序清单）（测试报告）（维护报告，改进的系统）第六页，共37页阶段任务、结果及人员阶段基本任务工作结果参加者需求分析理解和表达用户的要求，需求说明书用户、分析人员系统设计建立系统的结构,模块划分系统设计书用户、系统设计人员程序设计程序内的模块设计，数据库的物理设计程序设计书程序员？编程程序编写程序程序员测试发现错误和排除错误测试报告测试人员运行及维护维护维护报告、改进的系统用户、维护人员瀑布模型概念第七页，共37页特征：从上一阶段承接的成果物作为本阶段的工作对象；对上一阶段成果实施本阶段的活动；给出本阶段的成果，作为下一阶段的输入；对本阶段的工作进行评审，若本阶段的工作得到确认，则继续下阶段的工作，否则返回前一阶段或更前一阶段。优点：提供了一个模板，使得分析、设计、编码、测试、运行维护可以在该模板的指导下应用。瀑布模型的特点第八页，共37页缺点：缺乏灵活性，不能适应用户需求的改变开始阶段的小错误被逐级放大，可能导致软件产品报废返回上一级的开发需要十分昂贵的代价随着软件规模和复杂性的增加，对于需求不能完全确定的软件开发项目将产生很大的风险。

通常使用场合：需求分析做得比较好的系统瀑布模型的特点第九页，共37页在项目开发的初始阶段，人们对软件的需求认识往往不够清楚，因而使得开发项目难以做到一次开发成功，出现返工再开发在所难免。原型模型第十页，共37页

在获得用户基本需求说明的基础上，投入少量人力和物力，快速建立一个原始模型，使用户及时运行和看到模型的概貌和使用效果，并对需求说明进行补充和精化，提出改进意见，开发人员进一步修改完善，如此循环迭代，直到得到一个用户满意的模型为止。

从原型法的基本思想中可以看到，用户能及早看到系统模型，在循环迭代修改和完善过程中，使用户的需求日益明确，从而消除了用户需求的不确定性，同时从原型到模型的生成，周期短、见效快，对环境变化的适应能力较强。原型模型的基本思想第十一页，共37页⑴功能选择

要恰当选择原型实现的功能。根据用户基本需求，对系统给出初步定义。用户的基本需求包括各种功能的要求、数据结构、菜单和屏幕、报表内容和格式等要求。这些要求虽是概略的，但是最基本的，易于描述和定义。原型和最终的软件系统不同，两者在功能范围上的区别主要有以下两个方面：原型模型的内容第十二页，共37页第一最终系统是软件需求全部功能的实现，而原型只实现所选择的部分功能。

第二最终系统对每个软件需求都要求详细实现，而原型仅仅是为了试验和演示用的，部分功能需求可以忽略，或者模拟实现。原型模型的内容第十三页，共37页

⑵构造原型

根据用户初步需求，开发出一个可以应用的系统，它应满足上述的由用户提出的基本要求。在构造一个原型时，应当强调着眼于预期的评估，而不是为了正规的长期使用。⑶运行和评价原型

在试用中能亲自参加和面对一个实在的模型，能较为直观和明确地进一步提出需求，提出修改意见。通过运行原型对软件需求规格说明进行评价和确认。评价要有用户参与，注意来自用户的反馈信息。

原型模型的内容第十四页，共37页⑷修改和完善原型

根据修改意见进行修改，以得到新的系统原型，然后再进行试用和评价，这样经过有限次的循环反复，逐步提高和完善，直到得到一个用户满意的系统模型为止。根据原型实现的特点和环境，可以把原型作为试验的工具，用完就丢弃之（大部分原型都废弃不用，主要因为原型太慢、太大、结构不合理等原因）；也可以使原型全部或部分地成为最终系统的组成部分。

原型开发与原型运行评价两者需反复进行多次，才能最后得到经过确认的需求规格说明，并以此作为进一步的软件设计和实现的基础。原型模型的内容第十五页，共37页需求分析原型开发最终系统设计原型评价最终系统实现用户反馈图2.3快速原型模型原型模型的内容第十六页，共37页原型模型（快速原型模型）原型范型用户测试运行原型建造/修改原型

听取用户意见原型模型的内容第十七页，共37页采用原型模型的软件生存周期分析定义系统需求生成原型系统设计程序设计编码测试运行和维护原型化含原型化的软件生存期原型模型的内容第十八页，共37页优点：开发者与用户充分交流，可以澄清模糊需求，需求定义比其他模型好得多为用户需求的改变提供了充分的余地缺点：开发者为了使一个原型快速运行起来，往往在实现过程中采用折衷的手段。软件系统的组成部分可能会打折扣；资源规划和管理较为困难，随时更新文档也带来麻烦。一般使用场合：开发者在不了解的应用领域开发客户不清楚其所开发软件项目的最终目标

原型模型的特点第十九页，共37页2.4增量模型1.阶段式开发：增量模型

系统设计时分片交付，可使用户在使用某些基本功能的同时，开发剩余的功能。这样通常会并行地存在两个系统：生产系统和开发系统。运行或生产系统是当前被客户或用户所使用的系统。而开发系统是准备用于替代当前生产系统的下一个版本。增量模型是一种非整体开发的模型。是瀑布模型的顺序特征和快速原型模型的迭代特征相结合的产物。该模型具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目。第二十页，共37页创建版本1创建版本2创建版本3使用版本1使用版本2使用版本3开发者使用者阶段式开发：增量和迭代模型2.4增量模型第二十一页，共37页规格说明设计实现和集成交付客户规格说明设计实现和集成交付客户规格说明设计实现和集成交付客户规格说明设计实现和集成交付客户增量1增量2增量3增量n2.4增量模型第二十二页，共37页特点：

在前面增量的基础上开发后面的增量

每个增量的开发可用瀑布或快速原型模型

迭代的思路优点：

如果在项目既定的商业要求期限不可能找到足够的开发人员，这种情况下增量模型显得特别有用。早期的增量可以有少量的人员实现。同时，增量模型可以规避技术风险。2.4增量模型第二十三页，共37页

软件开发几乎总要冒一定的风险，例如，产品交付给用户之后用户可能对产品不满意，到了预定的交付日期软件可能还未开发出来，实际的开发成本可能超过了预算，产品完成之前一些关键的开发人员可能“跳槽”了，产品投入市场之前竞争对手发布了一个功能相近、价格更低的软件等等。软件风险是任何软件开发项目中都普遍存在的实际问题，项目越大，软件产品越复杂，承担该项目所冒的风险也越大。软件风险可能在不同程度上损害软件开发过程和软件产品质量。因此，在软件开发过程中必须及时识别和分析风险，并且采取适当措施以消除或减少风险的危害。构建原型是一种能使某些类型的风险降至最低的方法。于是在1988年B.boehm提出了螺旋模型。2.5螺旋模型第二十四页，共37页

螺旋模型的基本思想是，使用原型及其他方法以尽可能地降低风险。理解这种模型的一个简易方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型，如右图所示。简化的螺旋模型图2.5螺旋模型第二十五页，共37页螺旋模型将瀑布模型与原型模型结合起来，加入了两种模型均忽略了的风险分析，弥补了这两种模型的不足。螺旋模型是一种风险驱动的模型。螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合。螺旋模型适合于大型软件的开发。2.5螺旋模型第二十六页，共37页

螺旋模型完整的螺旋模型图制定计划风险分析客户评估工程实施第二十七页，共37页

螺旋模型是一种迭代模型，每迭代一次，螺旋线就前进一周。当项目按照顺时针方向沿螺旋移动时，每一个螺旋周期包含了风险分析，并且按以下4个步骤来进行：（1）确定目标，选定方案，设定约束条件，选定完成本周期所定目标的策略。（2）分析该策略可能存在的风险。必要时通过建立一个原型来确定风险的大小，然后据此决定是按原定目标执行，还是修改目标或终止项目。（3）在排除风险之后，实现本螺旋周期的目标，例如，第一圈可能产生产品的规格说明，第二圈可能产生实现产品设计等。（4）最后一步是评价前一步的结果，并且计划下一轮的工作。2.5螺旋模型第二十八页，共37页优点：结合瀑布模型和原型模型的优点风险分析可使一些极端困难的问题和可能导致费用过高的问题被更改或取消缺点：螺旋模型开发的成败，很大程度上依赖于风险评估的成败。需要开发人员具有相当丰富的风险评估经验和专门知识一般使用场合：需求不能完全确定，同时又存在技术、资金或开发时间等风险因素的大型开发项目。2.5螺旋模型第二十九页，共37页2.6XP开发模型2.6.1

XP开发模型概要XP极限编程(eXtremeProgramming)是一种敏捷（Agile）开发方法，以编码为核心任务的，供中小型小组用于开发需求快速变化的软件。敏捷是什么？敏捷已经成为当今描述现代软件过程的时髦用词。每个人都是敏捷的，敏捷团队是能够适当响应变化的灵活团队。变化就是软件开发本身，软件构建有变化，团队成员在变化、使用新技术带来变化，各种变化都会对开发的软件产品以及项目本身造成影响。我们必须接受“支持变化”的思想，它应当根植于软件开发中的每一件事中，因为这是软件的心脏与灵魂。敏捷团队意识到软件是团队中所有人共同开发完成的，这些人的个人技能和合作能力是项目成功的关键所在。敏捷方法是为了克服传统软件工程中认识和实践的弱点开发而成的（JimHighsmith说：“传统方法学家陷入了误区，乐于生完美的文档而不是满足业务需要的可运行系统”）。敏捷开发可以带来多方面的好处，但它并不使用于所有的项目、所有的方面、所有的人和所有的情况，它并不完全对立于传统的软件工程实践。第三十页，共37页XP有四部分组成：价值、原则、活动和实践XP的4种价值观：交流：侧重口头交流，而不是文档、报表和计划。因而，人际关系显得尤为重要。简化：在管用的前提下，做最简单的事。目标放在客户当前的需求上，摒弃了过多的文档。反馈：通过及时地单元测试和功能测试获得快速反馈。快速地编写软件，然后向客户演示。为确保准确性和高质量，获取客户关于到目前为止的进度的反馈是至关重要的。勇气：提倡积极面对现实和处理问题的勇气快速工作并在必要时重新进行开发的勇气。2.6.1XP开发模型概要第三十一页，共37页XP的指导原则：快速反馈：开发人员通过简短的反馈循环迅速了解其当前产品是否满足了客户的需求。简单性假设：将每个问题都视为很容易解决。只需为当前迭代打算，而无需洞察未来可能需要什么。逐步修改：通过一系列细微的修改来解决问题。拥抱变化：包容变化，提倡变化。高质量的工作：工作质量决不可打折扣。XP采用测试先行的编程方式，强调编码和测试的重要性。2.6XP开发模型概要第三十二页，共37页XP活动：倾听：积极倾听。测试：非“马后炮”式的测试。编码之前编写测试用例。编码：编写代码是一种工艺，通过重构、结对编程和代码复核等实践得以改进。设计：设计是不断演化的，并非固定的，不能赋予它单个职责，而是基于小组的，动态的。2.6.1XP开发模型概要第三十三页，共37页XP实践：实践描述

规则游戏

规则游戏的职责是快速制定下一次发布或迭代的高级规划

小型发布

XP周期提供业务价值的频繁发布组成

隐喻

隐喻是用于描述项目的通用观点、术语和语言

简单设计