软件工程概述1.ppt

第1章 软件工程概述 1 第1章 软件工程概述 1.1 软件的概念、特点和分类 2 第1章 软件工程概述 软件的概念 l程序、软件与软件产品 独唱 小合唱合唱万人大合唱 | | | 简单程序 较复杂程序 软件 l软件是计算机系统中与硬件相互依存的 另一部分,它包括程序 、数据、相关文 档的完整集合以及完善的售后服务。 软件=程序+数据+文档+服务 3 第1章 软件工程概述 软件的特点 1.软件是一种逻辑实体，而不是具体的物 理实体。 2.软件的生产于硬件不同。 3.在软件的运行和使用期间，没有硬件那 样的机械磨损，老化问题。 失效率 时间 磨合 调整 磨损 用坏 硬件失效曲线 失效率 时间 软件失效曲线 理想曲线 实际曲线 4 第1章 软件工程概述 软件的特点 4.软件的开发和运行常常受到计算机系统 的限制，对计算机系统有着不同程度的 依赖。 5.软件的开发至今尚未完全摆脱手工业的 开发方法。 6.软件是复杂的，人类能够创造的最复杂 的产物是计算机软件。 7.软件成本相当昂贵。 8.相当多的软件工作涉及到社会因素。 5 第1章 软件工程概述 软件的分类 1.按软件的功能划分 系统软件 支撑软件 应用软件 2.按软件规模划分 微型软件 小型软件 中型软件 大型软件 甚大型软件 极大型软件 6 第1章 软件工程概述 软件的分类 3.按软件工作方式划分 实时处理软件 交互式软件 分时软件 批处理软件 4.按软件服务对象的范围划分 项目软件 产品软件 7 第1章 软件工程概述 软件的分类 5.按软件使用的频度划分 仅供一次使用的软件 频繁使用的软件 6.按软件的失效 可靠性等质量要求高。 常与完成重要功能的大系统的处理部 件相联. 含有可能对以下各项造成影响的程序 8 第1章 软件工程概述 1.2 软件的发展和软件危机 9 第1章 软件工程概述 软件的发展 软件的发展大体经历了如下三个阶段： 程序设计阶段，约为50至60年代 程序系统阶段，约为60至70年代 软件工程阶段，约为70年代以后 10 第1章 软件工程概述 计算机软件发展的三个时期及特点 时间 特点 程 序 设 计 程 序 系 统软 件 工 程 软件所指程序程序及说明书程序、文档、数据 主要程序设计语 言汇编及机器语言高级语言软件语言 软件工作范围程序编写包括设计和测试软件生存期 需求者程序设计本人少数用户市场用户 开发软件的组织个人开发小组开发小组及大中型开发机 构 软件规模小型中小型大中小型 决定质量的因素个人程序技术小组技术水平管理水平 11 第1章 软件工程概述 计算机软件发展的三个时期及特点 时间 特点程 序 设 计 程 序 系 统软 件 工 程 开发子程序 程序库 结构化程序设计数据库、开发工具、开发 环境、工程化开发方法、 标准和规范、网络和分布 式开发、面向对象技术 维护责 任者程序设计者开发小组专职维护 人员 硬件特征价格高 存储容量小 工作可靠性差 降价、速度、容量及工 作可靠性有明显提高 向超高速、大容量、微型化 及网络化方向发展 软件特征完全不受重视软件技术的发展不能满 足需要，出现软件危机 开发技术有进步，但未获 突破性进展，价高，未完 全摆脱软件危机 12 第1章 软件工程概述 软件工程的发展的四个重要阶段 1、第一代软件工程 传统的软件工程 2、第二代软件工程 对象工程 3、第三代软件工程 过程工程 4、第四代软件工程 构件工程 60年代末到70年代为了 克服“软件危机” (Software crisis)提出“ 软件工程”的名词, 将软件 开发纳入工程化的轨道，基 本形成软件工程的概念、框 架、技术和方法。称为传统 的软件工程。 13 第1章 软件工程概述 软件工程的发展的四个重要阶段 1、第一代软件工程 传统的软件工程 2、第二代软件工程 对象工程 3、第三代软件工程 过程工程 4、第四代软件工程 构件工程 80年代中到90年代，面向对象 的方法与技术得到发展，研究的重 点转移到面向对象的分析与设计， 演化为一种完整的软件开发方法和 系统的技术体系，称为对象工程。 14 第1章 软件工程概述 软件工程的发展的四个重要阶段 1、第一代软件工程 传统的软件工程 2、第二代软件工程 对象工程 3、第三代软件工程 过程工程 4、第四代软件工程 构件工程 80年代中开始，人们在软件开发 的实践过程中认识到：提高软件生产 率，保证软件质量的关键是“软件过 程”，是软件开发和维护中的管理和 支持能力，逐步形成软件过程工程。 15 第1章 软件工程概述 软件工程的发展的四个重要阶段 1、第一代软件工程 传统的软件工程 2、第二代软件工程 对象工程 3、第三代软件工程 过程工程 4、第四代软件工程 构件工程 90起年代，基于构件（Component） 的开发方法取得重要进展，软件系统的 开发可通过使用现成的可复用构件组装 完成，而无需从头开始构造，以此达到 提高效率和质量，降低成本的目的。称 为构件工程。 16 第1章 软件工程概述 软件开发方法的模型 随意编程 面向过程 面向对象 面向组件 面向配置组件面向Web Service 17 第1章 软件工程概述 什么是软件危机? l定义：软件危机是计算机软件在它的开 发和维护过程中所遇到的一系列严重问 题。 主要包含两方面的问题： 如何开发软件，怎样满足对软件日益 增长的需求； 如何维护数量不断膨胀的已有软件。 18 第1章 软件工程概述 软件危机的现象有哪些? 对软件开发成本和进度的估计常常 很不准确。 用户对“已完成的”软件系统不满意 的现象经常发生。 软件产品的质量往往靠不住。 软件常常是不可维护的。 19 第1章 软件工程概述 软件危机的现象有哪些? 软件通常没有适当的文档资料。计算机 软件不仅仅是程序，还应该有一整套文 档资料。 软件成本在计算机系统总成本中所占的 比例逐年上升。 软件开发生产率提高的速度，远远跟不 上计算机应用迅速普及深入的趋势。 20 第1章 软件工程概述 软件危机的原因 客观：软件本身特点 软件的规模庞大、复杂性高。 主观：不正确的开发方法，软件开发和 维护有许多错误的认识和作法。 忽视需求分析 软件开发=程序编写 轻视软件维护 21 第1章 软件工程概述 软件的神话管理者的神话 l负责软件的管理者像大多数其他管理者一 样，都有巨大的压力，要维持预算，保持 进度和提高质量。 神话1：我们已经有了关于建造软件的标准 和规程的书籍，难道它们不能给人们提供 所有其需要知道的信息吗？ 事实：不错，关于标准的书籍已经存在，但 真正用到了它们吗？软件实践者知道它们 存在吗？它们是否反映了现代软件开发的 过程？它们完整吗？很多情况下对于这些 问题的答案是“否”。 22 第1章 软件工程概述 软件的神话管理者的神话 神话2：我们已经有了很多很好的软件开发 工具，而且，我们为它们买了最新的计算 机。 事实：为了使用最新型号的计算机、工作站 和PC机去开发高质量的软件，我们已经投 入了太多的费用。实际上，计算机辅助软 件工程（CASE）工具比起硬件而言，对 于获得高质量和高生产率更为重要，但大 多数软件开发者并未使用它们。 23 第1章 软件工程概述 软件的神话管理者的神话 神话3：如果我们已落后于计划，可以增加 更多的程序员来赶上进度。 事实：软件开发并非像制造一样是一个机 械过程。用Brooks的话来说，“给一个已 经延迟的软件项目增加人手只会使其更 加延迟”。看起来，这句话与人的直觉正 好相反。但实际上，增加新人，原来正 在工作的开发者必须花时间来培训新人 ，这样就减少了他们花在项目开发上的 时间。人手可以增加，但只能在计划周 密、协调良好的情况下。 24 第1章 软件工程概述 软件的神话用户的神话 l需要计算机软件的用户可能就是邻桌，或是另一 个技术组，也可能是市场销售部门，或另一个 公司。在许多情况下，用户相信关于软件的神话 ，因为负责软件的管理者和开发者很少去纠正用 户的错误理解。神话导致了用户过高的期望值， 并引起对开发者的极端不满。 神话4：有了对目标的一般描述就足以开始写程序了 我们可以以后补充细节。 事实：不完善的系统定义是软件项目失败的主要原 因。关于待开发项目的应用领域、功能、性能、 接口、设计约束及确认标准的形式化的、详细的 描述是必需要的。这些内容只有通过用户和开发 者之间的通信交流才能确定。 25 第1章 软件工程概述 软件的神话用户的神话 神话5：项目需求总是在不断变化，但这些变化能够很容易地 满足，因为软件是灵活的。 事实：软件需求确实是经常变化的，但这些变化产生的影 响会随着其引入的时间不同而不同。如果我们很注重 早期的系统定义，这时需求变化就可很容易地适应。 用户能够复审需求，并提出对修改建议，这时对成本 的影响会相对较小。当在软件设计过程中才要求修改 时，对成本的影响就会提高的很快。资源已经消耗了 ，设计框架已经建立了，这时的变化可能会引起大的 改动，需要额外的资源和大量的设计修改：如额外的 花费。实现阶段（编码和测试阶段）功能、性能、接 口及其它方面的改变对成本会产生更大的影响。当软 件已投入使用后再要求修改，这时所花费的代价比起 较早阶段做同样修改所花的代价可能是几何级数级的 增长。 26 第1章 软件工程概述 例子 某公园有一游船码头，负责人请一位软件开发人员实现计 算机系统辅助游船管理系统，要求如下： 当游客向租船处租船时，向租船处查询是否有可租用的船 只，如果租船处有空船，管理员就准备好船只，帮助游客 上船，并在联机终端上打入一个信息“S”，表示租船周期开 始。计算机自动把当时时钟值送入信息域。当游客还船时 ，管理员打入另一个信息“E”，表示租船周期结束。由管理 员向游客结算租船时间及费用。一天结束时，管理员要用 一些管理信息总结每天工作状况，要求系统打印出 租船次数=NNN 平均租船时间=MMM 显然，这样一个系统的功能包括二个部分： 计算输入流的信息 打印输出 27 第1章 软件工程概述 确定算法 我们知道平均租船时间就是总的时间除以租 船次数 总的时间=第一条船结束时间 - 第一条 船开始时间 + 第二条船结束时间 - 第二条 船开始时间 + 或 总的时间=（第一条船结束时间 +第二 条船结束时间 + ）-（第一条船开始时间 + 第二条船开始时间 + ） 28 第1章 软件工程概述 编写系统程序 BEGIN OPEN MESSAGE_STREAM NUMBER=0 TOTALTIME=0 GET MESSAGE DO WHILE NOT END_OF_STREAM IF CODE=S THEN NUMBER=NUMBER+1 TOTAL_TIME=TOTAL_TIME-START_TIME ELSE TOTAL_TIME=TOTAL_TIME+END_TIME ENDIF PRINT “NUMBER OF SESSION =”NUMBER IF NUMBER0 THEN PRINT “AVERAGE SESSION TIME =”TOTAL_TIME/NUMBER ENDIF CLOSE MASSAGE_STREAM END; 29 第1章 软件工程概述 系统提出修改 找出一天中最长租用时间： LONGGEST_SESSION_TIME = PPP 要求把每天的报告分成两个，一个是上午情况，另一 个是下午情况 。 通信线路出了毛病，丢掉了一些信息。要求修改系统 从计算报告中删除一切不完整的租船信息。 对于上述的修改，除了把原系统废弃之外。实在无法对 其作什么修改来满足这一新的要求。而时间及经费都 不允许他这么做了。 结论：并不是任意设计出来的软件都能够适应在软件寿 命期内变化的要求，即软件的灵活性不是绝对的。 30 第1章 软件工程概述 软件的神话开发者的神话 那些至今仍被软件开发者相信的神话是 由几十年的程序设计文化培植起来的。 而这种旧的观念和方式是很难改变的。 神话6：一旦我们写出了程序并使其正常运 行，我们的工作就结束了。 事实：有人说过：“越早开始写程序，就要 花越长的时间完成它”，大量的数据表明 在一个程序上所投入的50%到70%的努 力是花在第一次将程序交给用户之后。 31 第1章 软件工程概述 软件的神话开发者的神话 神话7：在程序真正运行之前，没有办法评估其 质量。 事实：从项目一开始就可以应用的最有效的软件 质量保证机制之一是正式的技术复审。软件复 审是“质量的过滤器”，比起通过测试找到某类 软件错误要有效的多。 神话：一个成功的项目唯一应该提交的就是运行 程序。 事实：运行程序仅是仍软件配置的一部分，软件 配置包括：程序、文档和数据。文档是成功开 发的基础，更重要的是，文档为软件维护提供 了指导。 32 第1章 软件工程概述 软件危机解决途径 l组织管理 工程项目管理方法 l技术措施 软件开发技术与方法 软件工具 33 第1章 软件工程概述 1.3 软件工程 34 第1章 软件工程概述 软件工程的提出 l“软件工程”一词是1968年北大西洋公约 组织（NATO）在联邦德国召开的一次 会议上首次提出的，这个会议专门讨论 了软件危机问题。它反映了软件人员认 识到软件危机的出现及谋求解决这一危 机的努力，因此，这次会议被看作是软 件发展史上一个重要的里程碑。 35 第1章 软件工程概述 软件工程定义 l采用工程的概念、原理、技术和方法来 计划、开发与维护软件，把经过时间考 验而证明正确的管理技术和当前能够得 到的最好的技术方法结合起来，以较经 济的手段获得能在实际机器上运行的可 靠软件的一系列方法。 简言之： 工程方法+管理技术+技术方法 36 第1章 软件工程概述 软件工程原理 l著名的软件工程专家B.W.Boehm提出了软件工 程的七条基本原理。这七条原理是确保软件产 品质量和开发效率的原理的最小集合。这七条 原理是互相独立的，其中任意六条原理的组合 都不能代替另一条原理，因此，它们是缺一不 可的最小集合，然而这七条原理又是相当完备 的，人们虽然不能用数学方法严格证明它们是 一个完备的集合，但是，可以证明在此之前已 经提出的100多条软件工程原理都可以由这七 条原理的任意组合蕴含或派生。 37 第1章 软件工程概述 软件工程原理 用分阶段的生命周期计划严格管理 不成功的软件项目中有一半左右是由于计划不周造成 的 。 坚持进行阶段评审 软件的质量保证工作不能等到编码阶段结束之后再进 行。 实行严格的产品控制 在软件开发过程中不应随意改变需求，因为改变一项 需求往往需要付出较高的代价。 采用现代程序设计技术 采用先进的技术既可提高软件开发的效率，又可提高 软件维护的效率。 38 第1章 软件工程概述 软件工程原理 结果应能清楚地审查 根据软件开发项目的总目标及完成期限，规定 开发组织的责任和产品标准，从而使得所得到 的结果能够清楚地审查。 开发小组的人员应该少而精 承认不断改进软件工程实践的必要性 不仅要积极主动地采纳新的软件技术，而且要 注意不断总结经验。 39 第1章 软件工程概述 软件工程学的范畴 软件工程学 软件工程技术 软件工程管理 软件开发方法学 软件工具 软件工程环境 软件经济学 软件管理学 40 第1章 软件工程概述 软件工程三要素 l软件工程包括三要素：方法、工具和过 程。 软件工程方法为软件开发提供了“如何 做”的技术。 软件工具为软件工程方法提供了自动的 或半自动的软件支撑环境。 软件工程的过程则是将软件工程的方法 和工具综合起来以达到合理、及时地进 行计算机软件开发的目的。 41 第1章 软件工程概述 什么是软件工程过程 l定义：软件工程过程是为获得软件产品 ，在软件工具的支持下由软件工程师完 成的一系列软件工程活动。 u针对不同类型的软件产品，同一软件开 发机构也可能采用多个不同的软件工程 过程。 42 第1章 软件工程概述 软件工程过程的基本活动 软件规格说明：规定软件的功能及其运 行的限制； 软件开发：产生满足规格说明的软件； 软件确认：确认软件能够完成客户提出 的要求； 软件改进：为满足客户的变更要求，软 件必须在使用的过程中改进。 43 第1章 软件工程概述 软件工程过程的特性 易理解性。 可见性：每个过程活动均能以明确的结 果告终，使过程的进展对外可见。 可支持性：易得到计算机辅助软件工程 （CASE）工具的支持。 可接受性：易于为软件工程师接受和使 用。 44 第1章 软件工程概述 可靠性：不会出现过程错误，或发现在 产品出现故障之前。 健壮性：不受意外发生的问题干扰。 可维护性：过程可随软件机构需求的变 更或随认定的过程改进而演进。 速度：从规格说明起，就能较快地完成 开发而交付。 45 第1章 软件工程概述 软件工程项目的基本目标 付出较低的成本； 达到要求的软件功能； 取得较好的软件性能； 开发的软件易于移植； 需要较低的维护费用； 能按时完成开发工作，及时交付使用。 46 第1章 软件工程概述 软件工程目标之间的关系 47 第1章 软件工程概述 软件工程框架及原则 1选取适宜的开发模型；2采用合适设计方法； 3提供高质量工程支持；4重视开发过程管理。 48 第1章 软件工程概述 软件工程面临的问题 (1)软件费用 (2)软件可靠性 (3)软件维护 (4)软件生产率 (5)软件重用 49 第1章 软件工程概述 1.4 软件生命周期 50 第1章 软件工程概述 软件生命周期的定义 l定义：软件生命周期是指软件产品从考 虑其概念开始到该软件产品不再能使用 为止的整个时期。 软件生命周期可分为三个阶段：即定义 阶段、开发阶段和运行维护阶段，每个 阶段需完成几个任务。 51 第1章 软件工程概述 划分软件生命周期的目的和实质 便于控制开发工作的复杂性。 通过有限的步骤，把用户的需求从抽象 的逻辑概念逐步转化为具体的物理实现 。 52 第1章 软件工程概述 软件生命周期各阶段的基本任务定义阶 段 定义阶段主要集中于“做什么”，即在定 义过程中，软件开发人员试图弄清楚要 处理什么信息，预期完成什么样的功能 和性能，希望有什么样的系统行为，建 立什么样界面，有什么设计约束，以及 定义一个成功系统的确认标准是什么。 在本阶段需完成三项任务： 53 第1章 软件工程概述 系统定义 系统定义必须回答的关键问题是：“要解 决的问题是什么？”如果不知道问题是什 么就试图解决这个问题，显然是盲目的 ，只会白白浪费时间和金钱，最终得出 的结果很可能是毫无意义的。尽管确切 地定义问题的必要性是十分明显的，但 是在实践中它却可能是最容易被忽视的 一个步骤。 系统定义是软件生命周期中最简短的任 务，一般只需要一天甚至更少的时间。 54 第1章 软件工程概述 可行性研究 可行性研究要回答的关键问题是：“对于 上一个阶段所确定的问题有行得通的解 决办法吗？”为了回答这个问题，系统分 析员需要进行一次大大压缩和简化了的 系统分析和设计的过程，也就是在较抽 象的高层次上进行的分析和设计的过程 。可行性研究应该比较简短，这个阶段 的任务不是具体解决问题，而是研究问 题的范围，探索这个问题是否值得去解 ，是否有可行的解决办法。 55 第1章 软件工程概述 需求分析 需求分析的任务仍然不是具体地解决问 题，而是准确地确定“为了解决这个问题 ，目标系统必须做什么”，主要是确定目 标系统必须具备哪些功能。 系统分析员在需求分析阶段必须和用户 密切配合，充分交流信息，以得出经过 用户确认的系统逻辑模型。通常用数据 流图、数据字典和简要的算法表示系统 的逻辑模型。 56 第1章 软件工程概述 软件生命周期各阶段的基本任务开 发阶段 开发阶段集中于“如何做”。即在开发 过程中，软件工程师试图定义数据如 何结构化，功能如何转换为软件体系 结构，过程细节如何实现，界面如何 表示，设计如何转换成程序设计语言 ，测试如何运行。在本阶段需完成四 项任务： 57 第1章 软件工程概述 总体设计 总体设计必须回答的关键问题是：“概括地说，应 该如何解决这个问题？” 通常至少应该考虑下述几类可能的方案： 低成本的解决方案。系统只能完成最必要的工作 ，不能多做一点额外的工作。 中等成本的解决方案。这样的系统不仅能够很好 地完成预定的任务，使用起来很方便，而且可能 还具有用户没有具体指定的某些功能和特点。虽 然用户没有提出这些具体要求，但是系统分析员 根据自己的知识和经验断定，这些附加的能力在 实践中将证明是很有价值的。 高成本的“十全十美”的系统。这样的系统具有用 户可能希望有的所有功能和特点。 58 第1章 软件工程概述 详细设计 总体设计以比较抽象概括的方式提出了 解决问题的办法。详细设计的任务就是 把解法具体化，也就是回答下面这个关 键问题：“应该怎样具体地实现这个系统 呢？” 通常用HIPO图（层次图加输入处理 输出图）、PAD图或PDL语言（过程设 计语言）描述详细设计的结果。 59 第1章 软件工程概述 编码和单元测试 编码和单元测试的关键任务是写出正确 的容易理解、容易维护的程序模块。 60 第1章 软件工程概述 综合测试 综合测试的关键任务是通过各种类型的测试（及相应 的调试），使软件达到预定的要求。 最基本的测试是集成测试和验收测试。所谓集成测试 是根据设计的软件结构，把经过单元测试检验的模块 按某种选定的策略装配起来，在装配过程中对程序进 行必要的测试。所谓验收测试则是按照规格说明书的 规定（通常在需求分析阶段确定），由用户（或在用 户积极参加下）对目标系统进行验收。 必要时还可以再通过现场测试或平行运行等方法对目 标系统进一步测试检验。 为了使用户能够积极参加验收测试，并且在系统投入 生产性运行以后能够正确有效地使用这个系统，通常 需要以正式的或非正式的方式对用户进行培训。 61 第1章 软件工程概述 软件生命周期各阶段的基本任务软 件维护 维护阶段的关键任务是，通过各种必要的维护 活动使系统持久地满足用户的需要。 通常有四类维护活动：改正性维护，也就是诊 断和改正在使用过程中发现的软件错误；适应 性维护，即修改软件以适应环境的变化；完善 性维护，即根据用户的要求改进或扩充软件使 它更完善；预防性维护，即修改软件为将来的 维护活动预先做准备。 每一项维护活动都应该准确地记录下来，作为 正式的文档资料加以保存。 62 第1章 软件工程概述 软件生命周期各阶段任务一览表 阶段 关键问题 结束标准 系统定义问题 是什么？关于规模和目标的报告书 可行性研究有可行的解吗？系统的高级逻辑 模型；数据流图 成本效益分析 需求分析系统必须做什么？系统的逻辑 模型；数据流图；数据字典 ；算法描述 总体设计概括地说，应该 如 何解决这个问题 ？ 可能的解法：系统流程图；成本效益分 析；推荐的系统结 构；层次图或结构图 详细设计怎样具体地实现这 个系统？ 编码规 格说明：HIPO图或PDL 编码 和单元测试正确的程序模块源程序清单；单元测试 方案和结果 综合测试符号要求的软件综合测试 方案和结果；完整一致的软件 配置 维护持久地满足用户需求 的软件 完整准确的维护记录 63 第1章 软件工程概述 1.5 软件开发模型 64 第1章 软件工程概述 软件开发模型 在整个软件开发的发展过程中，为了要 从宏观上管理软件的开发和维护，就必 须对仍旧的发展过程有总体的认识和描 述，即要对软件过程建模。几十年来， 软件开发生命周期模型的发展有了很大 的变化，提出了一系列的模型以适应软 件开发发展的需要。 65 第1章 软件工程概述 编码-修正模型 l在软件开发早期，开发只有两个阶段， 被简单的分成编写程序代码和修改程序 代码。拿到项目，马上就根据需要，开 始编写程序。编完代码，调试通过，就 算基本完成任务，拿给用户用。如果应 用中有什么错误，或有什么新的要求， 要重新修改代码。 66 第1章 软件工程概述 编码-修正模型的弊端 1代码缺少统一规划，低估了设计的重要 性，使得代码结构随着修改的次数增加 变得越来越坏。以至错误越来越难改， 甚至无法改。 2即使有的软件计划很好，但往往其结果 并非用户所需要的。造成软件开发的风 险非常大。这主要是没有重视需求而造 成的。 3由于对测试、维护修改方面考虑不周， 使得代码维护修改非常困难。 67 第1章 软件工程概述 瀑布模型 l由于吸取了开发早期的教训，人们开始 将软件开发视为工程来管理。类似于其 他的工程管理，软件开发也具有一定的 工序。“软件生命周期”这一概念真正被 提了出来，并将软件生命周期划分成： 制定计划，需求分析、软件设计、程序 编写、软件测试、运行与维护等六个部 分。 68 第1章 软件工程概述 瀑布模型 69 第1章 软件工程概述 瀑布模型的特点 从上一项开发活动接受该项活动的工作对象， 作为输入。 利用这一输入，实施该项活动应完成的工作内 容。 给出该项活动的工作成果，作为输出传给下一 项活动。 对该项目活动实施的工作成果进行评审。若工 作得到确认，则继续进行下一次开发活动，否 则返回前一项，甚至更前项的活动。 70 第1章 软件工程概述 瀑布模型优点 消除非结构化软件。 降低软件的复杂度。 促进软件开发工程化。 71 第1章 软件工程概述 瀑布模型存在的问题 阶段与阶段划分完全固定，阶段间产生 的大量文档，极大地增加了工作量。 由于开发模型呈线性，所以当开发成果 尚未经过测试时，用户无法看到软件的 效果。这样，软件与用户见面的时间较 长，也增加了一定的风险。 前面未发现的错误传到后面的开发活动 中，可能会扩散，进而可能会造成更不 理想的效果。 72 第1章 软件工程概述 平行瀑布模型 考虑对瀑布模型的进一步改进。对瀑布模型的 各阶段之间的转换时，不一定要求完全按顺序 进行。而是以适当的并行开展各阶段的工作。 在上一阶段尚未完成结束前，就可以开设后一 阶段的工作。 根据不同的情况可有不同的并行度： 用户想法不稳定，如：每天都变换想法，要求 不太清楚的话，则增加并行度。 短期显示成果的压力大，则可增加并行度。 如果可靠性要求高；要求各方面控制和配合很 严格；资源及预算严密；技术错误的后果严重 时，则需减少并行度。 73 第1章 软件工程概述 原型模型 常有这种情况，用户定义了软件的一组 一般性目标，但不能标识出详细的输入 、处理及输出需求；还有一情况，开发 者可能不能确定算法的有效性、操作系 统的适应性或人机交换的形状。在这些 及很多情况下，原型模型可能是最好的 选择。 74 第1章 软件工程概