软件工程引论课件

1、软件工程引论高级软件工程高级软件工程软件工程引论Reference Books 软件工程导论（第5版），张海藩，清华大学出版社； 软件工程实践者的研究方法（Software Engineering-A Practitioners Approach）， (美) Roger S. Pressman 著， 机械工业出版社 需求分析与系统设计，Leszek A. Maciaszek， 机械工业出版社。软件工程引论Objective软件工程是软件工程专业的一门专业核心课程。通过本课程的学习，掌握系统的软件开发理论和方法，为今后从事软件开发打下坚实的基础。软件工程引论本课程将涉及的内容 软件工程生命周期

2、软件需求分析 软件系统设计 软件实现与测试 软件维护 软件项目管理 软件建模与UML 软件工程引论本节内容 什么是软件？ 软件危机的产生及消除 软件工程学的诞生 软件生命周期 软件过程 软件工程引论软件无处不在软件工程引论计算机软件已经成为一种驱动力计算机软件已经成为一种驱动力 进行商业活动的引擎 现代科学研究和工程问题解决的基础 区分现代产品的关键因素 现代社会中不可缺少的软件工程引论什么是软件软件(software)是计算机系统中与硬件(hardware)相互依存的另一部分，它包括程序(program)、相关数据(data)及其说明文档(document)。Software = Progr

3、am + Data + Document软件工程引论软件的发展早期早期面向批处理有限的分布自定义软件第二阶段第二阶段多用户实时数据库软件产品第三阶段第三阶段分布式系统嵌入“智能”低成本硬件消费者的影响第四阶段第四阶段强大的桌面系统面向对象技术专家系统人工神经网络并行计算网路计算机19601970198019902000软件工程引论硬件的故障率曲线（浴缸曲线）软件工程引论软件的故障率曲线(理想情况下)软件工程引论软件的故障率曲线(实际情况下)时间故障率理想曲线实际曲线修改由于副作用造成故障率的提高软件工程引论软件危机 个体化软件环境 软件作坊 急剧膨胀软件危机产生软件工程引论软件危机(Cont.

4、) 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题； 不能正确估计软件开发的成本和进度； 对“已完成的”软件系统，用户经常不满意； 软件质量靠不住； 软件常常不能维护； 没有建立适当的文档资料记录软件开发过程中的信息及其变化； 软件费用占计算机系统总费用的比例逐年上升等等。 软件工程引论软件危机介绍 软件危机包含两方面问题：如何开发软件，以满足不断增长，日趋复杂的需求；如何维护数量不断膨胀的软件产品。软件工程引论软件危机的表现 对软件开发成本和进度的估计常常不准确。开发成本超出预算，实际进度比预定计划一再拖延的现象并不罕见。 用户对“已完成”系统不满意的现象经常发生。 软件产

5、品的质量往往靠不住。Bug一大堆，Patch一个接一个。 软件的可维护程度非常之低。 软件通常没有适当的文档资料。 软件的成本不断提高。 软件开发生产率的提高赶不上硬件的发展和人们需求的增长。 软件工程引论软件危机的原因 一方面是与软件本身的特点有关 另一方面是由软件开发和维护的方法不正确有关软件工程引论引入同一变化付出的代价随时间变化的趋势软件工程引论消除软件危机的途径 对计算机软件有一个正确的认识(软件程序） 必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。 推广使用在实践中总结出来的开发软件的成功技术和方法。 开发和

6、使用更好的软件工具。软件工程引论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 simpl

7、icity.软件工程引论“No Silver Bullet” RefiredThere Is a Silver Bullet “重用和交互的构件开发是解决软件根本困难的一种方法。” Broad Cox“复杂性是我们行业的属性，而且复杂性是我们的主要限制。软件开发是一件棘手的事情，前方并不会有魔术般的解决方案。现在是从业者研究和分析革命性进展的时候，而不是等待或希望他的出现“ Frederick Brooks软件工程引论Any questions?软件工程引论软件工程引论软件工程引论软件工程引论工程水利工程水利工程 建筑工程建筑工程 机械工程机械工程传统工程新兴工程气象工程气象工程 生物工程生物

8、工程工程是对技术（或社会）实体的分析、设计、建造、验证和管理。软件工程引论软件工程“软件工程”-Software Engineering 于1968年 NATO 组织在德国召开的一次会议上提出软件工程引论围棋与软件工程的感想围棋 围棋棋谱拿过来的时候,大师问“后面应该走哪里？” 十个初级爱好者选择的落点散布在棋盘各处 十个职业棋手说的落子点都差不多，甚至包括后面的几步 这就是高手和低手的差别软件工程 当一个小程序拿过来的时候,项目经理让大家编写 十个中国软件工程师写出来的程序各有“特色”、千差万别，十个印度软件工程师写出来的程序差不多，以至于怀疑是“抄袭”。 项目经理也不清楚中国软件业和印度软

9、件业的差距是多少年只是觉得差了好远好远思考：软件开发是否需要追求风格一致和代码一致软件开发是否应该抹杀个人的创造性软件工程引论软件工程 范围软件工程引论当前的软件实践 软件直到测试前仅仅是忽略质量的现代技术。典型地说，软件工程师没有计划他们的工作匆匆地走过需求和设计在编码时再进行设计 这些实践引入了大量的缺陷有经验的工程师每7-10行代码就引入一个缺陷平均中等规模的系统存在着上千个缺陷这些缺陷的大多必须靠测试发现通常要花去一半以上的开发时间 目前大多数的工作方式还象30年前一样软件工程引论美国软件工程实践的现状 软件开发仍然很难预测，只有10%的项目能在预定的费用和进度下交付管理规范是软件项目

10、成功或失败的主要因素开发过程的返工是软件过程不成熟的标志软件工程引论软件工程 经典定义 “The establishment and use of sound engineering principles in order to obtain economically software that is reliable and works on real machines.” Fritz Bauer 软件工程就是为了经济地获得可靠的且能在实际机器上高效运行的软件而建立和使用的完善的工程原理。软件工程引论软件工程 经典定义(Cont.)“The application of a systemat

11、ic, disciplined, quantifiable approach to the development, operation, and maintenance of software” IEEE 1990软件工程是将系统的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中，并研究上述提到的途径。软件工程引论软件工程框架开发范型设计方法支持过程管理过程需求设计实现确认支持可用性正确性合算性软件工程活动维软件工程目标维软件工程原则维软件工程的框架是由软件工程目标、软件工程活动和软件工程原则三个方面的内容构成的。软件工程引论软件工程目标 目标目标：生产具有正

12、确性、可用性以及开销适宜的软件产品。 正确性正确性：软件产品达到预期功能的程度。 可用性可用性：软件基本结构、实现及文档为用户 可用的程度。 开销适宜开销适宜：软件开发、运行的整个开销满足 用户要求的程度。 从而决定了从而决定了：软件过程、过程模型和工程方法的选择。软件工程引论软件工程活动活动：生产一个最终满足需求且达到工程目标的软件产品所需要的步骤。 1、需求：需求： 问题分析问题分析：需求获取和定义，又称软件需求规约。 需求分析需求分析：生成软件功能规约。 2、设计：设计： 概要设计概要设计：建立整个软件的体系结构，包括子系统、模 块以及相关层次的说明、每一模块的接口定 义等。 详细设计详

13、细设计：产生程序员可用的模块说明，包括每一模块 中数据结构说明及加工描述。 3、实现实现： 把设计结果转换为可执行的程序代码。 4、确认确认： 贯穿整个开发过程，对完成的结果进行确认，保证产品 满足用户的要求。 5、支持支持： 修改和完善活动。软件工程引论软件工程原则 采取适宜的开发模型：采取适宜的开发模型：控制易变的需求。 采用合适的设计方法：采用合适的设计方法：需要软件模块化、抽象与信息隐藏、局部化、一致性以及适应性等，需要合适的设计方法的支持。 提供高质量的工程支持：提供高质量的工程支持：软件工具和环境对软件过程的支持。 重视开发过程的管理：重视开发过程的管理：有效利用可用的资源、生产满

14、足目标的软件产品、提高软件组织的生产能力等。 软件工程引论软件发展趋势 遗留(legacy)软件将继续发挥作用； 软件应用范围将继续扩大，成为信息社会的基础设施； 网络化软件将是发展重点； 软件的可靠性与安全性日趋重要； 工业化生产是必由之路； 软件工业化生产时代的基础技术：软件过程技术：以软件过程改进为中心面向对象技术构件重用技术软件工程引论软件工程的本质特征 软件工程关注于大型程序的构造 软件工程的中心课题是控制复杂性 软件经常变化 开发软件的效率非常重要 和谐地合作是开发软件的关键 软件必须有效地支持它的用户 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品软件工

15、程引论软件工程 基本原理 用分阶段的生命周期计划严格管理 坚持进行阶段评审 实行严格的产品控制 采用现代程序设计技术 结果应能清楚地审查 承认不断改进软件工程实践的必要性软件工程引论软件工程 方法学 把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学 软件工程方法学包含3个要素：方法、工具和过程方法 完成软件开发的各项任务的技术方法，回答“怎样做”的问题；工具 为运用方法而提供的自动的或半自动的软件工程支撑环境；过程 为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。软件工程引论软件工程 方法学 (cont.) 结构化方法学 面向对象的方法学软件工程引

16、论软件工程 方法学 (cont.) 结构化方法学倾向于按次序以及变换的方式，而不是迭代增量的方式；倾向于提交灵活的解决方案，来满足所确定的、但将来难以扩大规模和扩展业务功能的集合；基本上都是从零开始开发，他不支持以前存在的构建的复用。仍然是使用十分广泛的软件工程方法学；采用结构化技术来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用；从上而下，顺序地完成软件开发的各阶段任务。软件工程引论软件工程 方法学 (cont.) 面向对象的方法学出发点和基本原则是尽量模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识实践解决问题的方法与过程，从而使描述问题的

17、问题空间与实现解法的解空间在结构上尽可能一致。抽象、封装、复用、继承、消息传递、多态；把对象作为融合了数据及在数据上的操作行为的统一软件构件；把所有对象都划分成类；按照父类与子类的关系，把若干个相关类组成一个层次结构的系统；对象彼此间仅能通过发送消息互相联系；迭代增量过程，逐步精化。软件工程引论两种方法比较 从概念方面看从概念方面看结构化软件是功能的集合，通过模块以及模块和模块之间的分层调用关系实现；面向对象软件是事物的集合，通过对象以及对象和对象之间的通信联系实现。 从构成方面看从构成方面看结构化软件过程数据，以过程为中心；面向对象软件（数据相应操作）的封装，以数据为中心。 从开发方面看从开

18、发方面看结构化方法的工作重点是设计；面向对象方法的工作重点是分析。 从发展方面看从发展方面看，面向对象方法是软件开发方法的发展方向软件工程引论走向面向对象是必然的软件工程引论软件工程学 软件工程学 软件开发技术 软件工程管理 软件开发方法学 软件工具 软件工程环境 软件工程管理学 软件经济学 - 软件工程学的范畴 软件工程引论软件工程 软件生命周期 系统需求分析 系统结构设计 详细设计 软件实现与单元测试 集成测试 软件维护软件工程引论软件工程 软件生命周期(Cont.)软件工程引论系统需求分析与结构设计 当我们在着手做任何一件工作以前，必须明确工作的性质、任务，制定完成任务的计划，这是非常必

19、要的。同样对于软件产品的开发 ，显然也应该解决好这样类似的问题，明确该软件产品开发的任务，以及完成任务的价值从而制定出完成任务的计划。那么问题的定义和可性行研究就是制定软件系统的计划的第一步。 所以在软件工程中把这一步称为 计划时期软件工程引论系统需求分析与结构设计工作内容 分析系统需求，分配软件和硬件的功能 分析硬件与软件的关系，定义软件和硬件之间的接口 定义软件研制项目，编制软件可行性分析报告和软件开发计划 (草稿) 评估系统的可行性 编制软件接口说明 (必要时)软件工程引论可行性分析(研究)报告引言引用文档可行性分析的前提可选的方案所建议的系统经济可行性（成本-效益分析）技术可行性（技术

20、风险评价）法律可行性用户使用可行性其他与项目有关的问题注解附录 * GB/T 8567 计算机软件产品开发文件编制指南软件工程引论计划时期的工作流程图开始问题定义可性行研究 可行否？项目实施计划终止项目的建议结束YN软件工程引论软件需求分析 软件需求分析是软件开发早期的一个重要阶段。它在问题定义和可行性研究阶段之后进行。需求分析的基本任务是软件人员和用户一起完全弄清用户对系统的确切要求。这是关系到软件开发成败的关键步骤，也是整个系统开发的基础。 软件需求分析阶段要求用 需求规格说明书（SRS） 来表达用户对系统的要求。规格说明书可用文字方式表示，也可用图形表示。 本章将介绍需求分析的(面向数据

21、流图分析方法、面向对象的分析方法）。软件工程引论需求规格说明书与评审软件工程引论软件需求分析工作内容 编制软件开发计划 确定软件运行环境 确定软件的功能、性能和接口要求 确定软件功能的控制方法或计算方法 编写软件需求规格说明 指定软件确认测试计划 编写软件用户手册概要软件工程引论系统设计 总体设计回答：“应该怎样实现目标系统”设计体系结构 详细设计“应该怎样具体地实现这个系统？”设计出程序的详细规格说明又称为“模块设计” 软件工程引论软件实现和单元测试 写出正确的容易理解、容易维护的程序模块 测试各个功能模块 软件工程引论综合测试 集成测试根据设计的软件结构，把经过单元测试检验的模块按某种策略

22、装配起来，在装配过程中对程序进行必要的测试。 验收测试按照规格说明书的规定，由用户对目标系统进行验收。 软件工程引论软件维护软件维护“指在一软件产品交付之后对其进行修改，以纠正故障” 或 “在一软件产品交付之后对其进行修改，以纠正故障，改进性能和其他属性，或使产品适应改变了的环境。” GB/T11457-1995软件工程术语软件工程引论软件维护分类 国际电工委员会(IEC)根据阮家维护活动的需要，将软件维护分为5类：修复性维护预防性维护完善性维护适应性维护进化性维护 软件工程引论软件维护分类(Cont.) GB/T14079-1993 软件维护指南：完善性维护：扩充功能和改善性能适应性维护：适

23、应软件运行环境的变化改进性维护：为维持系统操作运行 软件工程引论费用分配比例55%70% 软件工程引论 软件过程模型软件过程模型 软件工程引论过程 过程就是针对某一给定目标的一系列运作步骤，IEEE-STD-610 是在过程环境下的一系列有序活动。所谓活动（Activity）就是过程对象一次状态改变，也叫过程步(Step) 。 活动起始态和活动结果态表征了活动的进行。可以说一切事物的发生、发展、消亡都离不开过程，都寓于过程之中。 软件工程引论软件过程 软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 软件过程必须科学、合理，才能开发出高质量 的软件产品

24、。 软件工程引论软件过程(Cont.)软件工程引论软件过程(Cont.) 软件过程又称软件生存周期过程，是软件生存周期内为达到一定目标而必须实施的一系列相关过程的集合。早期： 立项、需求分析、设计、编码、 测试、交付、维护、退役现在又加入了： 管理各种活动、质量保证 环境基础设施配置、文档管理等软件工程引论软件过程模型 瀑布模型（Waterfall） 原型模型（Prototype） 快速应用开发（RAD） 增量模型（Incremental） 螺旋模型（Spiral） 迭代模型（Iterative） 软件工程引论瀑布模型(线性顺序模型) 软件需求分析 设计 代码生成 测试 维护 瀑布模型是软件工

25、程中应用最广泛的过程模型 软件工程引论瀑布模型 传统的瀑布模型需求分析验证规格说明验证设计验证编码测试综合测试维护定义时期开发时期维护时期软件工程引论思考？ 传统瀑布模型存在什么问题？ 软件工程引论传统的瀑布模型 存在什么问题？传统的瀑布模型过于理想化了，事实上，人在工作过程中不可能不犯错误。 在设计阶段可能发生规格说明文档中的错误。 而设计上的缺陷或错误可能在实现过程中显现出来。 在综合测试阶段将发现需求分析、设计或编码阶段的许多错误。软件工程引论瀑布模型 实际的瀑布模型需求分析验证规格说明验证设计验证编码测试综合测试维护变化的需求验证软件工程引论瀑布模型 特点文档驱动文档驱动的模型 阶段间

26、具有顺序性和依赖性 推迟实现的观点 质量保证的观点软件工程引论瀑布模型 问题 实际项目很少按照该模型给出的顺序进行 用户常常难以清楚地给出所有需求 用户必须有耐心 开发者常常被不必要地耽搁软件工程引论瀑布模型 风险 需求未被充分理解 系统太大而不能一次做完所有事 事先打算采用的技术迅速发生变化 需求迅速发生变化 有限的资源 无法利用某一中间产品软件工程引论瀑布模型 时机可使用该方法的时机，即当希望： 所有的系统功能一次交付时 必须同时淘汰全部老系统时软件工程引论瀑布模型优点 定义清楚 易于建模和理解 便于计划和管理 有支持该生存周期模型的多种工具缺点 必须在开始时就知道大多数需求 不便于适应需

27、求的变化 在项目接近完成之前，产品不能投入使用适用情况 待开发的项目与以前的成功项目类似 待开发的项目的需求稳定很好理解 所使用的技术经过验证并且成熟整个项目的开发周期相当短用户不需要任何中间产品软件工程引论主要阶段产品和里程碑评审生存周期阶段主要产品里程碑评审系统需求分析与设计软件开发计划可行性分析（研究）报告系统需求评定软件需求分析软件需求规格说明软件需求评审概要设计软件概要设计说明确认测试计划用户指南概要概要设计评审详细设计详细软件设计说明详细设计评审实现和测试程序代码编制经过单元和组装测试的软件用户指南草案单元和组装测试评审确认测试经过确认测试的软件确认测试报告用户指南确认测试评审软件

28、工程引论原型模型 快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。 软件工程引论原型模型 适用情况 用户定义了一组一般性目标，但不能标识出详细的输入、处理及输出需求； 开发者可能不能确定算法的有效性、操作系统的适应性或人机交互的形式； 原型模型可能是最好的选择 软件工程引论原型模型(Cont.) 原型模型从需求收集开始。 开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。 然后是“快速设计”，快速设计集中于软件那些对用户可见部分的表示。“快速设计”导致原型的建造。 原型由用户评估，并进一步精化待开发软件的需求，逐步调

29、整原型使其满足客户的要求。同时开发者对将要做的事情有更好的理解， 这个过程是迭代的。 软件工程引论原型模型(Cont.)快速原型验证规格说明验证设计验证编码测试综合测试维护变化的需求验证维护过程开发过程软件工程引论原型模型存在的问题 用户似乎看到的是软件的工作版本，其实 开发者常常需要实现上的折衷，以使原型能够尽快工作 软件工程引论原型模型适用情况 项目包含一种新技术，例：新硬件、新的开发语言、新的系统架构等； 需求不很清楚； 存在关于性能、可靠性和可行性方面的主要的、未解决的问题； 用户界面对系统成功是很关键的，但不很清楚。软件工程引论原型+瀑布软件工程引论进化型原型软件工程引论原型模型优点

30、 开始时不必了解所有的需求 尽早强调高风险的问题，以减少风险 产品的中间构件有助于反馈后续构件的变更 用户能参与软件系统的定义和评价 在时间或经费耗尽时，能够提供一定的运行能力缺点 难以估计整个项目的工作量 难于管理 没有用户的参与便不可能取得成功适用情况 待开发的项目需求未定义清楚 需要用户的使用经验来改进或完善软件的需求 使用的技术未经过验证 系统能力要演示，以便不同用户组进行评价 不同用户组具有潜在的、冲突的要求软件工程引论主要阶段产品和里程碑评审软件工程引论快速开发模型(RAD) 快速应用开发模型是一个线性顺序的软件开发模型，强调极短的开发周期。 是线性顺序模型的一个“高速”变种，如果

31、需求理解得很好，且约束了项目范围，就可通过使用基于构件或可重用软件包的建造方法获得快速开发。 适用于信息系统应用软件的开发。 软件工程引论RAD模型软件工程引论RAD模型缺点 对大型的、但可伸缩的项目，RAD需要足够的人力以创建足够的RAD小组。RAD要求开发者和用户在一个很短的时间内完成一个系统，如果双方中的任何一方没完成约定，都会导致RAD项目失败。 软件工程引论RAD模型适用情况 具有可重用的构件库和CASE工具的应用项目、信息系统等。 软件工程引论增量模型 融合了瀑布模型的基本成分和原型的迭代特征。采用随着日程时间的进展而交错的线性序列。 也叫作有计划的产品改进型，它从一组给定的需求开

32、始，通过构造一系列的可执行工作版本来实施开发活动。第一个工作版本纳入一部分需求，下一个工作版本纳入更多的需求，以此类推，直到系统完成。 每个工作版本都要执行必要的过程、活动和任务，如：需求分析和体系结构设计需要执行一次，而软件详细设计、软件编码和测试、软件集成和软件合格性测试在每个工作版本构造过程中都执行。 软件工程引论增量模型(Cont.) 在这种方法中，在开发每个工作版本时，开发过程中的活动和任务顺序地或部分平行地使用。当相继的工作版本在部分并发开发时，开发过程中的活动和任务可以在各工作版本间平行地被采用。在所有的工作版本中，开发过程的活动和任务通常按相同的顺序被重复使用。维护过程和运作过

33、程可以与开发过程平行地使用。获取过程、供应过程、支持过程和组织过程通常与开发过程平行地进行。 软件工程引论增量模型(Cont.)需求分析验证规格说明验证设计验证维护针对每个构件完成详细设计、编码和集成，经测试后交付给用户软件工程引论增量模型(Cont.)分析分析分析分析设计设计设计设计编码编码编码编码测试测试测试测试增量1增量2 增量3增量4 软件工程引论增量模型(Cont.)软件工程引论增量模型(Cont.)增量模型融合了瀑布模型的基本成分和原型的迭代特性。例如，使用增量模型开发字处理软件 基本的文件管理、编辑和文档生成功能。 更完善的编辑和文档生成能力。 实现拼写和文法检查功能。 完成高级

34、的页面布局功能。软件工程引论增量模型(Cont.) 第一个增量往往是核心产品 每一个增量均发布一个可操作产品 早期的增量是最终产品的“可拆卸”版本软件工程引论优点 降低进度拖延、需求变更及验收问题的风险 提高项目开发的可管理性 产品的中期构件有利于反馈在后续构件的变更 中期构件可以在最终版本完成之前交付，用户可以标识需要的变更 将一个时间周期较长的项目分解开发 在产品开发时，允许用户确认产品 对尚不清楚的需求，可将他们的实现推迟到弄清需求后的发行中 可对产品的中期版本进行早期的操作培训 可在早期确认操作过程缺点 必须早期就了解大多数需求 对选择具体构件的开发方法敏感 需要对每次发行进行回归测试

35、，增加软件测试工作量 在生存周期的早期就将产品置于配置控制之下，因而需要正式的更改控 制过程，增加系统开销，尤其是在需求不稳定时适用情况 待开发项目类似于以前的成功项目 大多数需求是稳定和易于理解的 整个项目的周期大于一年，或者用户需要中期发行软件工程引论生存周期阶段主要产品里程碑评审系统需求分析与设计软件开发技术可行性分析（研究）报告系统需求评审软件需求分析软件需求规格说明软件需求评审概要设计软件概要设计说明确认测试计划用户指南概要概要设计评审详细设计软件详细设计说明至少完成第一个构件详细设计评审软件详细设计规格说明至少完成下一个构件构件设计评审实现和测试程序代码编制经过单元和组装测试的软件

36、用户指南草稿单元和组装测试评审确认测试经过确认测试的软件确认测试报告用户指南确认测试评审软件工程引论增量模型 风险 需求未被很好地被理解 一次要求所有功能 事先打算采用的技术迅速发生变化 需求迅速发生变化 长时期内有限的资源的保证(工作人员/资金) 软件工程引论增量模型 时机可使用该方法的时机，即当希望： 需要早期获得功能 中间产品可以提供使用 系统被自然地分割成增量 工作人员/资金可以逐步增加 软件工程引论螺旋模型 使用原型及其他方法来尽量降低风险 将原形的迭代特征与线性顺序模型中的控制和系统化的方面结合起来 软件工程引论螺旋模型(Cont.)需求分析验证规格说明验证设计验证编码测试综合测试

37、维护变化的需求验证风险分析风险分析风险分析风险分析风险分析风险分析软件工程引论螺旋模型(Cont.)软件工程引论螺旋模型(Cont.) 优点对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标；减少了过多测试或测试不足；维护和开发之间并没有本质区别。 特点风险驱动的 主要适用于内部开发的大规模软件项目软件工程引论迭代模型 建立在Barry Boehm 的螺旋模型基础上的。软件工程引论迭代模型(Cont.)软件工程引论迭代模型(Cont.)PlanningRequirementsAnalysis & DesignImplementationDeployme

38、ntTestEvaluationManagementEnvironmentEach iteration results in an executable release.软件工程引论迭代模型(Cont.)软件工程引论Risk ProfileTimeRiskWaterfall RiskIterative Risk软件工程引论迭代模型(Cont.) 这种方法可以在生命周期早期强制性的确定项目中存在的风险。 这种方法是一个连续地发现、创造和实现的过程。 在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动项目开发。 软件工程引论迭代模型(Cont.) 在生命周期的早期，这种方法可以及时地发现

39、一些严重的需求理解错误，此时还可能修正这些错误。 允许并鼓励用户反馈信息，以明确系统的真实需求。 这种方法使开发小组重视项目中最关键的问题，而屏蔽掉那些使他们远离项目真实风险的问题。 不断地迭代测试能够给出项目状况的客观评价。 软件工程引论Agile Development Agile software development uses iterative development as a basis but advocates a lighter and more people-centric viewpoint than traditional approaches. Agile proc

40、esses use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.软件工程引论Agile Development (Cont.) Agile software development contextIndividuals and Interactions in agile development, self-organization and motiv

41、ation 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 develo

42、pment 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.软件工程引论Agile Development (Cont.) Twelve principles underlie the Agile developmentCustomer satisfaction by r

43、apid 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 betwe

44、en 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 软件工程引论Agile Development (Cont.) Twelve principles underlie the Agile developmentContinuous attention to technical excelle

45、nce and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances 软件工程引论软件生存周期模型选择原则 目前，大多数软件开发项目都采用改进的瀑布模型作为规范化开发的基础，主要原因：软件开发单位的软件工程工作尚处于初级阶段，软件开发人员和管理人员既缺乏经验，又无历史数据可供借鉴，因此，需要一种比较简单易行的组织方式；结构化方法学是系统工程中最成熟的方法学，目前大多数软件开发都以结构化开发方法学为基础；在与结构化方法学相适应的生存周期模型中，改进的瀑布模型最为简单实用，行之有效；有关软件开发的现行国家标准和国家军用标准都是以瀑布模型为基础制定的。 软件工程引论软件开发问题的症状 对于最终用户的需要理解得不够精确 对需求的改变束手无策 程序模块不兼容 软件不易维护或不易扩展 对项目严重缺陷发现较晚 软件质量低劣 软件性能令人无法接受 开发组的人员按各自的方式进行开发，如果有人改变可部分软件，将很难进行重组 一个不可靠的构造和发布过程 软件工程引论最佳软件开发实践 Best Practices 迭代地开发软件 Develop Iteratively 管理需求