《软件工程引论》PPT课件.ppt

1 高级软件工程 2 Reference Books 软件工程导论（第5版），张海藩，清华大学出版 社； 软件工程实践者的研究方法（Software Engineering-A Practitioners Approach）， (美) Roger S. Pressman 著， 机械工业出版社 需求分析与系统设计，Leszek A. Maciaszek， 机械工业出版社。 3 Objective 软件工程是软件工程专业的一门 专业核心课程。通过本课程的学 习，掌握系统的软件开发理论和 方法，为今后从事软件开发打下 坚实的基础。 4 本课程将涉及的内容 软件工程生命周期 软件需求分析 软件系统设计 软件实现与测试 软件维护 软件项目管理 软件建模与UML 5 本节内容 什么是软件？ 软件危机的产生及消除 软件工程学的诞生 软件生命周期 软件过程 6 软件无处不在 7 计算机软件已经成为一种驱动力 进行商业活动的引擎 现代科学研究和工程问题解决的基础 区分现代产品的关键因素 现代社会中不可缺少的 8 什么是软件 软件(software)是计算机系统中与硬件 (hardware)相互依存的另一部分，它包括程 序(program)、相关数据(data)及其说明文档 (document)。 Software = Program + Data + Document 9 软件的发展 早期 面向批处理 有限的分布 自定义软件 第二阶段 多用户 实时 数据库 软件产品 第三阶段 分布式系统 嵌入“智能” 低成本硬件 消费者的影响 第四阶段 强大的桌面系统 面向对象技术 专家系统 人工神经网络 并行计算 网路计算机 19601970198019902000 10 硬件的故障率曲线（浴缸曲线） 11 软件的故障率曲线(理想情况下) 12 软件的故障率曲线(实际情况下) 时间 故障率 理想曲线 实际曲线 修改 由于副作用造成故障 率的提高 13 软件危机 个体化软件环境 软件作坊 急剧膨胀 14 软件危机(Cont.) 软件危机是指在计算机软件的开发和维护 过程中所遇到的一系列严重问题； 不能正确估计软件开发的成本和进度； 对“已完成的”软件系统，用户经常不满意 ； 软件质量靠不住； 软件常常不能维护； 没有建立适当的文档资料记录软件开发过 程中的信息及其变化； 软件费用占计算机系统总费用的比例逐年 上升等等。 15 软件危机介绍 软件危机包含两方面问题： 如何开发软件，以满足不断增长，日趋 复杂的需求； 如何维护数量不断膨胀的软件产品。 16 软件危机的表现 对软件开发成本和进度的估计常常不准确。开发成 本超出预算，实际进度比预定计划一再拖延的现象 并不罕见。 用户对“已完成”系统不满意的现象经常发生。 软件产品的质量往往靠不住。Bug一大堆，Patch一 个接一个。 软件的可维护程度非常之低。 软件通常没有适当的文档资料。 软件的成本不断提高。 软件开发生产率的提高赶不上硬件的发展和人们需 求的增长。 17 软件危机的原因 一方面是与软件本身的特点有关 另一方面是由软件开发和维护的方法 不正确有关 18 引入同一变化付出的代价随时间变化的趋势 19 消除软件危机的途径 对计算机软件有一个正确的认识 (软件程序） 必须充分认识到软件开发不是某种个体劳动 的神秘技巧，而应该是一种组织良好、管理 严密、各类人员协同配合、共同完成的工程 项目。 推广使用在实践中总结出来的开发软件的成 功技术和方法。 开发和使用更好的软件工具。 20 No Silver Bullet？ 在未来的十年内，无论是在技术还是管理方法上 ，都看不出有任何突破性的进步，能够独自保证 在十年内大幅度地提高软件的生产率、可靠性和 简洁性。 There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity. 21 “No Silver Bullet” Refired There Is a Silver Bullet “重用和交互的构件开发 是解决软件根本困难的 一种方法。” Broad Cox “复杂性是我们行业的属性 ，而且复杂性是我们的主 要限制。 软件开发是一件棘手的事 情，前方并不会有魔术般 的解决方案。现在是从业 者研究和分析革命性进展 的时候，而不是等待或希 望他的出现“ Frederick Brooks 22 Any questions? 23 软件工程引论 24 工程 水利工程 建筑工程 机械工程 软件工程软件工程 传统工程 新兴工程 气象工程 生物工程 工程是对技术（或社会）实体的分析、设计、建造 、验证和管理。 25 软件工程 “软件工程” -Software Engineering 于1968年 NATO 组织在 德国召开的一次会议上提出 是把软件当作一种工业产品，要求是把软件当作一种工业产品，要求 “ “采用工程化的采用工程化的 原理与方法对软件进行计划、开发和维护原理与方法对软件进行计划、开发和维护 ” ”。 26 围棋与软件工程的感想 围棋 围棋棋谱拿过来的时候, 大师问“后面应该走哪里？ ” 十个初级爱好者选择的 落点散布在棋盘各处 十个职业棋手说的落 子点都差不多，甚至包括后 面的几步 这就是高手和低手的差 别 软件工程 当一个小程序拿过来的时候 ,项目经理让大家编写 十个中国软件工程师写出来 的程序各有“特色”、千差万别 ，十个印度软件工程师写出来的 程序差不多，以至于怀疑是“抄 袭”。 项目经理也不清楚中国软件 业和印度软件业的差距是多少年 只是觉得差了好远好远 思考： 软件开发是否需要追求风格一致和代码一致 软件开发是否应该抹杀个人的创造性 27 软件工程 范围 28 当前的软件实践 软件直到测试前仅仅是忽略质量的现代技术 。典型地说，软件工程师 没有计划他们的工作 匆匆地走过需求和设计 在编码时再进行设计 这些实践引入了大量的缺陷 有经验的工程师每7-10行代码就引入一个缺陷 平均中等规模的系统存在着上千个缺陷 这些缺陷的大多必须靠测试发现 通常要花去一半以上的开发时间 目前大多数的工作方式还象30年前一样 29 美国软件工程实践的现状 软件开发仍然很难预测，只有10%的项 目能在预定的费用和进度下交付 管理规范是软件项目成功或失败的主要因素 开发过程的返工是软件过程不成熟的标志 30 软件工程 经典定义 “The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works on real machines.” Fritz Bauer 软件工程就是为了经济地获得可靠的且能 在实际机器上高效运行的软件而建立和使用的 完善的工程原理。 31 软件工程 经典定义(Cont.) “The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software” IEEE 1990 软件工程是将系统的、规范的、可度量 的方法应用于软件的开发、运行和维护的 过程，即将工程化应用于软件中，并研究 上述提到的途径。 32 软件工程框架 开发范型 设计方法 支持过程 管理过程 需 求 设 计 实 现 确 认 支 持 可用性 正确性 合算性 软件工程 活动维 软件工程 目标维 软件工程 原则维 软件工程的框架是由软件工程目标、软件工程活动和软件工程原则 三个方面的内容构成的。 33 软件工程目标 目标：生产具有正确性、可用性以及开销适宜的 软件产品。 正确性：软件产品达到预期功能的程度。 可用性：软件基本结构、实现及文档为用户 可用的程度。 开销适宜：软件开发、运行的整个开销满足 用户要求的程度。 从而决定了：软件过程、过程模型和工程方法的 选择。 34 软件工程活动 活动：生产一个最终满足需求且达到工程目标的软件产品所需要的 步骤。 1、需求： 问题分析：需求获取和定义，又称软件需求规约。 需求分析：生成软件功能规约。 2、设计： 概要设计：建立整个软件的体系结构，包括子系统、模 块以及相关层次的说明、每一模块的接口定 义等。 详细设计：产生程序员可用的模块说明，包括每一模块 中数据结构说明及加工描述。 3、实现： 把设计结果转换为可执行的程序代码。 4、确认： 贯穿整个开发过程，对完成的结果进行确认，保证产品 满足用户的要求。 5、支持： 修改和完善活动。 35 软件工程原则 采取适宜的开发模型：控制易变的需求。 采用合适的设计方法：需要软件模块化、抽象与 信息隐藏、局部化、一致性以及适应性等，需要 合适的设计方法的支持。 提供高质量的工程支持：软件工具和环境对软件 过程的支持。 重视开发过程的管理：有效利用可用的资源、生 产满足目标的软件产品、提高软件组织的生产能 力等。 36 软件发展趋势 遗留(legacy)软件将继续发挥作用； 软件应用范围将继续扩大，成为信息社会 的基础设施； 网络化软件将是发展重点； 软件的可靠性与安全性日趋重要； 工业化生产是必由之路； 软件工业化生产时代的基础技术： 软件过程技术：以软件过程改进为中心 面向对象技术 构件重用技术 37 软件工程的本质特征 软件工程关注于大型程序的构造 软件工程的中心课题是控制复杂性 软件经常变化 开发软件的效率非常重要 和谐地合作是开发软件的关键 软件必须有效地支持它的用户 在软件工程领域中是由具有一种文化背景 的人替具有另一种文化背景的人创造产品 38 软件工程 基本原理 用分阶段的生命周期计划严格管理 坚持进行阶段评审 实行严格的产品控制 采用现代程序设计技术 结果应能清楚地审查 承认不断改进软件工程实践的必要性 39 软件工程 方法学 把在软件生命周期全过程中使用的一整套技术方法 的集合称为方法学 软件工程方法学包含3个要素：方法、工具和过程 方法 完成软件开发的各项任务的技术方法，回答“怎 样做”的问题； 工具 为运用方法而提供的自动的或半自动的软件工程 支撑环境； 过程 为了获得高质量的软件所需要完成的一系列任务 的框架，它规定了完成各项任务的工作步骤。 40 软件工程 方法学 (cont.) 结构化方法学 面向对象的方法学 41 软件工程 方法学 (cont.) 结构化方法学 倾向于按次序以及变换的方式，而不是迭代增量的方式 ； 倾向于提交灵活的解决方案，来满足所确定的、但将来 难以扩大规模和扩展业务功能的集合； 基本上都是从零开始开发，他不支持以前存在的构建的 复用。 仍然是使用十分广泛的软件工程方法学； 采用结构化技术来完成软件开发的各项任务，并使用适 当的软件工具或软件工程环境来支持结构化技术的运用 ； 从上而下，顺序地完成软件开发的各阶段任务。 42 软件工程 方法学 (cont.) 面向对象的方法学 出发点和基本原则是尽量模拟人类习惯的思维 方式，使开发软件的方法与过程尽可能接近人 类认识实践解决问题的方法与过程，从而使描 述问题的问题空间与实现解法的解空间在结构 上尽可能一致。 抽象、封装、复用、继承、消息传递、多态； 把对象作为融合了数据及在数据上的操作行为 的统一软件构件； 把所有对象都划分成类； 按照父类与子类的关系，把若干个相关类组成 一个层次结构的系统； 对象彼此间仅能通过发送消息互相联系； 迭代增量过程，逐步精化。 43 两种方法比较 从概念方面看 结构化软件是功能的集合，通过模块以及模块和模块之 间的分层调用关系实现； 面向对象软件是事物的集合，通过对象以及对象和对象 之间的通信联系实现。 从构成方面看 结构化软件过程数据，以过程为中心； 面向对象软件（数据相应操作）的封装，以数据为 中心。 从开发方面看 结构化方法的工作重点是设计； 面向对象方法的工作重点是分析。 从发展方面看，面向对象方法是软件开发方法的发 展方向 44 走向面向对象是必然的 45 软件工程学 软件工程学 软件开发技术 软件工程管理 软件开发方法学 软件工具 软件工程环境 软件工程管理学 软件经济学 - 软件工程学的范畴 46 软件工程 软件生命周期 系统需求分析 系统结构设计 详细设计 软件实现与单元测试 集成测试 软件维护 47 软件工程 软件生命周期(Cont.) 48 系统需求分析与结构设计 当我们在着手做任何一件工作以前，必须明确 工作的性质、任务，制定完成任务的计划，这是非 常必要的。同样对于软件产品的开发 ，显然也应该 解决好这样类似的问题，明确该软件产品开发的任 务，以及完成任务的价值从而制定出完成任务的计 划。那么问题的定义和可性行研究就是制定软件系 统的计划的第一步。 所以在软件工程中把这一步称为 计划时期 49 系统需求分析与结构设计工作内容 分析系统需求，分配软件和硬件的功能 分析硬件与软件的关系，定义软件和硬件之间的接 口 定义软件研制项目，编制软件可行性分析报告和软 件开发计划 (草稿) 评估系统的可行性 编制软件接口说明 (必要时) 50 可行性分析(研究)报告 引言 引用文档 可行性分析的前提 可选的方案 所建议的系统 经济可行性（成本-效益分析） 技术可行性（技术风险评价） 法律可行性 用户使用可行性 其他与项目有关的问题 注解 附录 * GB/T 8567 计算机软件产品开发文件编制指南 51 计划时期的工作流程图 开始 问题定义 可性行研究 可行否？ 项目实施计划终止项目的建议 结束 Y N 52 软件需求分析 软件需求分析是软件开发早期的一个重要阶段。它 在问题定义和可行性研究阶段之后进行。需求分析的基 本任务是软件人员和用户一起完全弄清用户对系统的确 切要求。这是关系到软件开发成败的关键步骤，也是整 个系统开发的基础。 软件需求分析阶段要求用 需求规格说明书（SRS） 来表达用户对系统的要求。规格说明书可用文字方式表 示，也可用图形表示。 本章将介绍需求分析的任务、步骤、需求分析方法任务、步骤、需求分析方法 (面向数据流图分析方法、面向对象的分析方法）。 53 需求规格说明书与评审 软件需求说明书软件需求说明书 - - SRS(Software Requirement Specification) SRS(Software Requirement Specification) 主要包括以下的内容主要包括以下的内容: : SRSSRS 引言引言 数据描述数据描述 数据流图数据流图 数据字典数据字典 功能描述功能描述 性能描述性能描述 特殊需求特殊需求 54 软件需求分析工作内容 编制软件开发计划 确定软件运行环境 确定软件的功能、性能和接口要求 确定软件功能的控制方法或计算方法 编写软件需求规格说明 指定软件确认测试计划 编写软件用户手册概要 55 系统设计 总体设计 回答：“应该怎样实现目标系统” 设计体系结构 详细设计 “应该怎样具体地实现这个系统？” 设计出程序的详细规格说明 又称为“模块设计” 56 软件实现和单元测试 写出正确的容易理解、容易维护的程序模 块 测试各个功能模块 57 综合测试 集成测试 根据设计的软件结构，把经过单元测试 检验的模块按某种策略装配起来，在装 配过程中对程序进行必要的测试。 验收测试 按照规格说明书的规定，由用户对目标 系统进行验收。 58 软件维护 软件维护 “指在一软件产品交付之后对其进行修改， 以纠正故障” 或 “在一软件产品交付之后对 其进行修改，以纠正故障，改进性能和其 他属性，或使产品适应改变了的环境。” GB/T11457-1995软件工程术语 59 软件维护分类 国际电工委员会(IEC)根据阮家维护活动的 需要，将软件维护分为5类： 修复性维护 预防性维护 完善性维护 适应性维护 进化性维护 60 软件维护分类(Cont.) GB/T14079-1993 软件维护指南： 完善性维护：扩充功能和改善性能 适应性维护：适应软件运行环境的变化 改进性维护：为维持系统操作运行 61 费用分配比例 55%70% 62 软件过程模型 63 过程 过程就是针对某一给定目标的一系列运作 步骤，IEEE-STD-610 是在过程环境下的 一系列有序活动。所谓活动（Activity） 就是过程对象一次状态改变，也叫过程步 (Step) 。 活动起始态和活动结果态表征了活动的进 行。可以说一切事物的发生、发展、消亡 都离不开过程，都寓于过程之中。 64 软件过程 软件过程是为了获得高质量软件所需要完 成的一系列任务的框架，它规定了完成各 项任务的工作步骤。 软件过程必须科学、合理，才能开发出高 质量 的软件产品。 65 软件过程(Cont.) 66 软件过程(Cont.) 软件过程又称软件生存周期过程，是软件生存 周期内为达到一定目标而必须实施的一系列相 关过程的集合。 早期： 立项、需求分析、设计、编码、 测试、交付、维护、退役 现在又加入了： 管理各种活动、质量保证 环境基础设施配置、文档管理等 67 软件过程模型 瀑布模型（Waterfall） 原型模型（Prototype） 快速应用开发（RAD） 增量模型（Incremental） 螺旋模型（Spiral） 迭代模型（Iterative） 68 瀑布模型(线性顺序模型) 软件需求分析 设计 代码生成 测试 维护 瀑布模型是软件工程中应用最广泛的 过程模型 69 瀑布模型 传统的瀑布模型 需求分析 验证 规格说明 验证 设计 验证 编码 测试 综合测试 维护 定义时期 开发时期 维护时期 70 思考？ 传统瀑布模型存在什么问题？ 71 传统的瀑布模型 存在什么问题？ 传统的瀑布模型过于理想化了，事实上，人在工 作过程中不可能不犯错误。 在设计阶段可能发生规格说明文档中的错误。 而设计上的缺陷或错误可能在实现过程中显现 出来。 在综合测试阶段将发现需求分析、设计或编码 阶段的许多错误。 72 瀑布模型 实际的瀑布模型 需求分析 验证 规格说明 验证 设计 验证 编码 测试 综合测试 维护 变化的需求 验证 73 瀑布模型 特点 文档驱动的模型 阶段间具有顺序性和依赖性 推迟实现的观点 质量保证的观点 74 瀑布模型 问题 实际项目很少按照该模型给出的顺序进 行 用户常常难以清楚地给出所有需求 用户必须有耐心 开发者常常被不必要地耽搁 75 瀑布模型 风险 需求未被充分理解 系统太大而不能一次做完所有事 事先打算采用的技术迅速发生变化 需求迅速发生变化 有限的资源 无法利用某一中间产品 76 瀑布模型 时机 可使用该方法的时机，即当希望： 所有的系统功能一次交付时 必须同时淘汰全部老系统时 77 瀑布模型 优点 定义清楚 易于建模和理解 便于计划和管理 有支持该生存周期模型的多种工具 缺点 必须在开始时就知道大多数需求 不便于适应需求的变化 在项目接近完成之前，产品不能投入使用 适用 情况 待开发的项目与以前的成功项目类似 待开发的项目的需求稳定很好理解 所使用的技术经过验证并且成熟 整个项目的开发周期相当短 用户不需要任何中间产品 78 主要阶段产品和里程碑评审 生存周期阶段主要产品里程碑评审 系统需求分析与设计软件开发计划 可行性分析（研究）报告 系统需求评定 软件需求分析软件需求规格说明软件需求评审 概要设计软件概要设计说明 确认测试计划 用户指南概要 概要设计评审 详细设计详细软件设计说明详细设计评审 实现和测试程序代码编制 经过单元和组装测试的软件 用户指南草案 单元和组装测试 评审 确认测试经过确认测试的软件 确认测试报告 用户指南 确认测试评审 79 原型模型 快速建立起来的可以在计算机上运行的程 序，它所能完成的功能往往是最终产品能 完成的功能的一个子集。 80 原型模型 适用情况 用户定义了一组一般性目标，但不能标识 出详细的输入、处理及输出需求； 开发者可能不能确定算法的有效性、操作 系统的适应性或人机交互的形式； 原型模型可能是最好的选择 81 原型模型(Cont.) 原型模型从需求收集开始。 开发者和用户 在一起定义软件的总体目标，标识出已知 的需求，并规划出进一步定义的区域。 然后是“快速设计”，快速设计集中于软件 那些对用户可见部分的表示。“快速设计” 导致原型的建造。 原型由用户评估，并进一步精化待开发软 件的需求，逐步调整原型使其满足客户的 要求。同时开发者对将要做的事情有更好 的理解， 这个过程是迭代的。 82 原型模型(Cont.) 快速原型 验证 规格说明 验证 设计 验证 编码 测试 综合测试 维护 变化的需求 验证 维护过程 开发过程 83 原型模型存在的问题 用户似乎看到的是软件的工作版本，其实 开发者常常需要实现上的折衷，以使原型 能够尽快工作 84 原型模型适用情况 项目包含一种新技术，例：新硬件、新的开 发语言、新的系统架构等； 需求不很清楚； 存在关于性能、可靠性和可行性方面的主要 的、未解决的问题； 用户界面对系统成功是很关键的，但不很清 楚。 85 原型+瀑布 86 进化型原型 87 原型模型 优点 开始时不必了解所有的需求 尽早强调高风险的问题，以减少风险 产品的中间构件有助于反馈后续构件的变更 用户能参与软件系统的定义和评价 在时间或经费耗尽时，能够提供一定的运行能力 缺点 难以估计整个项目的工作量 难于管理 没有用户的参与便不可能取得成功 适用 情况 待开发的项目需求未定义清楚 需要用户的使用经验来改进或完善软件的需求 使用的技术未经过验证 系统能力要演示，以便不同用户组进行评价 不同用户组具有潜在的、冲突的要求 88 主要阶段产品和里程碑评审 89 快速开发模型(RAD) 快速应用开发模型是一个线性顺序的软件 开发模型，强调极短的开发周期。 是线性顺序模型的一个“高速”变种，如果 需求理解得很好，且约束了项目范围，就 可通过使用基于构件或可重用软件包的建 造方法获得快速开发。 适用于信息系统应用软件的开发。 90 RAD模型 91 RAD模型缺点 对大型的、但可伸缩的项目，RAD需 要足够的人力以创建足够的RAD小组 。RAD要求开发者和用户在一个很短 的时间内完成一个系统，如果双方中 的任何一方没完成约定，都会导致 RAD项目失败。 92 RAD模型适用情况 具有可重用的构件库和CASE工具的 应用项目、信息系统等。 93 增量模型 融合了瀑布模型的基本成分和原型的迭代特征。采 用随着日程时间的进展而交错的线性序列。 也叫作有计划的产品改进型，它从一组给定的需求 开始，通过构造一系列的可执行工作版本来实施开 发活动。第一个工作版本纳入一部分需求，下一个 工作版本纳入更多的需求，以此类推，直到系统完 成。 每个工作版本都要执行必要的过程、活动和任务， 如：需求分析和体系结构设计需要执行一次，而软 件详细设计、软件编码和测试、软件集成和软件合 格性测试在每个工作版本构造过程中都执行。 94 增量模型(Cont.) 在这种方法中，在开发每个工作版本时， 开发过程中的活动和任务顺序地或部分平 行地使用。当相继的工作版本在部分并发 开发时，开发过程中的活动和任务可以在 各工作版本间平行地被采用。在所有的工 作版本中，开发过程的活动和任务通常按 相同的顺序被重复使用。维护过程和运作 过程可以与开发过程平行地使用。获取过 程、供应过程、支持过程和组织过程通常 与开发过程平行地进行。 95 增量模型(Cont.) 需求分析 验证 规格说明 验证 设计 验证 维护 针对每个构件完成 详细设计、编码和 集成，经测试后交 付给用户 96 增量模型(Cont.) 分析 分析 分析 分析 设计 设计 设计 设计 编码 编码 编码 编码 测试 测试 测试 测试 增量 1 增量 2 增量 3 增量 4 97 增量模型(Cont.) 98 增量模型(Cont.) 增量模型融合了瀑布模型的基本成分和 原型的迭代特性。 例如，使用增量模型开发字处理软件 1. 基本的文件管理、编辑和文档生成功能 。 2. 更完善的编辑和文档生成能力。 3. 实现拼写和文法检查功能。 4. 完成高级的页面布局功能。 99 增量模型(Cont.) 第一个增量往往是核心产品 每一个增量均发布一个可操作产品 早期的增量是最终产品的“可拆卸”版本 100 优点 降低进度拖延、需求变更及验收问题的风险 提高项目开发的可管理性 产品的中期构件有利于反馈在后续构件的变更 中期构件可以在最终版本完成之前交付，用户可以标识需要的变更 将一个时间周期较长的项目分解开发 在产品开发时，允许用户确认产品 对尚不清楚的需求，可将他们的实现推迟到弄清需求后的发行中 可对产品的中期版本进行早期的操作培训 可在早期确认操作过程 缺点 必须早期就了解大多数需求 对选择具体构件的开发方法敏感 需要对每次发行进行回归测试，增加软件测试工作量 在生存周期的早期就将产品置于配置控制之下，因而需要正式的更改控 制过程，增加系统开销，尤其是在需求不稳定时 适用 情况 待开发项目类似于以前的成功项目 大多数需求是稳定和易于理解的 整个项目的周期大于一年，或者用户需要中期发行 101 生存周期阶段主要产品里程碑评审 系统需求分析与设计软件开发技术 可行性分析（研究）报告 系统需求评审 软件需求分析软件需求规格说明软件需求评审 概要设计软件概要设计说明 确认测试计划 用户指南概要 概要设计评审 详细设计 软件详细设计说明 至少完成第一个构件 详细设计评审 软件详细设计规格说明 至少完成下一个构件 构件设计评审 实现和测试程序代码编制 经过单元和组装测试的软件 用户指南草稿 单元和组装测试 评审 确认测试经过确认测试的软件 确认测试报告 用户指南 确认测试评审 102 增量模型 风险 需求未被很好地被理解 一次要求所有功能 事先打算采用的技术迅速发生变化 需求迅速发生变化 长时期内有限的资源的保证(工作人员/资金 ) 103 增量模型 时机 可使用该方法的时机，即当希望： 需要早期获得功能 中间产品可以提供使用 系统被自然地分割成增量 工作人员/资金可以逐步增加 104 螺旋模型 使用原型及其他方法来尽量降低风险 将原形的迭代特征与线性顺序模型中的控 制和系统化的方面结合起来 105 螺旋模型(Cont.) 需求分析 验证 规格说明 验证 设计 验证 编码 测试 综合测试 维护 变化的需求 验证 风险分析 风险分析 风险分析 风险分析 风险分析 风险分析 106 螺旋模型(Cont.) 107 螺旋模型(Cont.) 优点 对可选方案和约束条件的强调有利于已有软件的 重用，也有助于把软件质量作为软件开发的一个 重要目标； 减少了过多测试或测试不足； 维护和开发之间并没有本质区别。 特点 风险驱动的 主要适用于内部开发的大规模软件项目 108 迭代模型 建立在Barry Boehm 的螺旋模型基础上 的。 109 迭代模型(Cont.) 110 迭代模型(Cont.) Planning Requirements Analysis & Design Implementation Deployment Test Evaluation Management Environment Each iteration results in an executable release. 111 迭代模型(Cont.) 112 Risk Profile Risk ReductionRisk Reduction Time Risk Waterfall Risk Iterative Risk 113 迭代模型(Cont.) 这种方法可以在生命周期早期强制性的确 定项目中存在的风险。 这种方法是一个连续地发现、创造和实现 的过程。 在每个迭代过程中，促使开发小组以一种 循环的、可预测的方式驱动项目开发。 114 迭代模型(Cont.) 在生命周期的早期，这种方法可以及时地 发现一些严重的需求理解错误，此时还可 能修正这些错误。 允许并鼓励用户反馈信息，以明确系统的 真实需求。 这种方法使开发小组重视项目中最关键的 问题，而屏蔽掉那些使他们远离项目真实 风险的问题。 不断地迭代测试能够给出项目状况的客观 评价。 115 Agile Development Agile software development uses iterative development as a basis but advocates a lighter and more people- centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software. 116 Agile Development (Cont.) Agile software development context Individuals and Interactions in agile development, self- organization and motivation are important, as are interactions like co-location and pair programming. Working software working software will be more useful and welcome than just presenting documents to clients in meetings. Customer collaboration requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important. Responding to change agile development is focused on quick responses to change and continuous development. 117 Agile Development (Cont.) Twelve principles underlie the Agile development Customer satisfaction by rapid delivery of useful software Welcome changing requirements, even late in development Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Sustainable development, able to maintain a constant pace Close, daily co-operation between business people and developers Face-to-face conversation is the best form of communication (co-location) Projects are built around motivated individuals, who should be trusted 118 Agile Development (Cont.) Twelve principles underlie the Agile development Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances 119 软件生存周期模型选择原则 目前，大多数软件开发项目都采用改进的瀑布模型 作为规范化开发的基础，主要原因： 软件开发单位的软件工程工作尚处于初级阶段，软件 开发人员和管理人员既缺乏经验，又无历史数据可供 借鉴，因此，需要一种比较简单易行的组织方式； 结构化方法学是系统工程中最成熟的方法学，目前大 多数软件开发都以结构化开发方法学为基础； 在与结构化方法学相适应的生存周期模型中，改进的 瀑布模型最为简单实用，行之有效； 有关软件开发的现行国家标准和国家军用标准都是以 瀑布模型为基础制定的。 120 软件开发问题的症状 对于最终用户的需要理解得不够精确 对需求的改变束手无策 程序模块不兼容 软件不易维护或不易扩展 对项目严重缺陷发现较晚 软件质量低劣 软件性能令人无法接受 开发组的人员按各自的方式进行开发，如果有人改 变可部分软件，将很难进行重组 一个不可靠的构造和发布过程 121 最佳软件开发实践 Best Practices 迭代地开发软件 Develop Iteratively 管理需求 Manage Requirements 应用基于构件的构架 Use Component Architectures 为软件建立可视化的模型 Model Visually (UML) 不断地验证软件质量 Continuously Verify Quality 控制软件的变更 Manage Change 122 RUP Rati