软件工程 主 讲: 蔡 勇 Emai l : jkx_cy@163.com 主 讲: 蔡 勇 Emai l : jkx_cy@163.com 课件下载:ftp://10.1.58.61 用户名:student-cy 教 材：软件工程导论（第五版） 清华大学出版社 作 者：张海藩

课程概述 一、软件工程学科介绍 二、学习目标 三、部分参考资料 四、课程特点和学习的注意事项 五、教材简介 六、课程考核方式

一、软件工程学科介绍 软件程学科发展历史 三个阶段：概念提出、学科雏形、学科确立 第一阶段：概念提出 1968 年 NATO 会议(北大西洋公约组织的计算机科学家的国际会议）提出“软件工程”概念。 当时对“软件工程”代表性定义：为了经济地获得在真实机器上可靠工作的软件而制定和使用的合理工程原则和方法。 1972 年 IEEE 学会的计算机分会 IEEE 一 CS 第一次出版了“软件工程学报”

第二阶段：学科雏形 上世纪 70 年代末，美国将软件工程教程列入研究生教育计划。 1980 年代末和 1990 年代初，软件工程教育得到卡内基一梅隆大学软件工程研究所（ CMU / SEI ）的支持。 1991 年，“软件工程”被 ACM （美国计算机协会）和 IEEE / CS 列为计算学科的九个知识领域之一。 1993 年， IEEE 一 CS 和ACM 为了把软件工程建设成为一个专业，建立了 IEEE 一 CS / ACM 联合指导委员会。

第三阶段：学科确立 2004 年 8 月，IEEE 一 CS 和 ACM 给出： 软件工程知识体（ SWEBOK , Software Engineering Body of Knowledge ) 软件工程教育知识体（ SEEK ) 最终版，标志着软件工程学科在世界范围正式确 立。 软件工程、计算机科学、计算机工程、信息系统、信息技术并列成为计算学科下的独立学科。 软件工程知识体（ SWEBOK ) ：全面描述了软件工程实践所需的知识。

SWEBOK （软件工程知识体 》 10 个领域 软件需求 软件设计 软件构造 软件测试 软件维护 软件配置管理 软件工程管理 软件工程过程 软件工程工具和方法 软件质量 参考资料： [1 ]白征． SWEBOK ：软件工程知识体，计 算机科学， 2001 年 07 期 ［ 2 万江平．软件工程知识体系指南综述， 计算机应用研究， 2006 年 10 期

SWEBOK详细结构（1）

软件工程与其他学科的关系 1 、软件工程是计算学科 9 个领域之一． 算法和数据结构 计算机系统结构 人工智能和机器人学 数据库和信息检索 人一机交互 操作系统 程序设计语言 软件方法学和软件工程 数字和符号计算

计算学科中12个重复出现的基本概念 绑定． 概念和形式模型 效率 抽象层次 按时间排序 安全性 大问题的复杂性 一致性和完备性 演化 按空间排序 重用 折衷与决策 软件工程是计算学科的分支，这 12 个概念同样将贯穿软件工程学科，是学科的精髓。

2 、 8 个相关学科知识域 计算机工程 计算机科学 数学 管理学 项目管理 质量管理 系统工程学 软件人类工程学 其中：计算机科学、数学是基础工程学科、管理学科也非常重要

软件程是一门什么样的学科？ 是指导计算机软件开发与维护的一门工程学科。 工程：将科学及数学原理运用于实际用途的应用手段，如：设计、制造、机器操纵、构架等。 典型的传统工程：建筑工程、机械工程、电力工程等。 概括的说，软件工程即用工程、科学和数学的原则和方法研制、维护计算机软件的有关技术及方法，其优点是以较小的代价开发高质量的软件并有效地维护它。

二、学习目标(1) 掌握软件工程的基础知识和理论，对软件工程学有一个全貌的了解； 熟悉软件项目开发和维护的一般过程； 熟练掌握软件需求分析、设计、编码和测试等阶段的主要思想和技术方法；

二、学习目标(2) 通过学习，特别是通过课程设计，真正运用和深刻体会软件工程的思想方法，转变对软件开发的认识：从个人的单纯编程活动转移到进行系统分析与设计方面上来 转变思维定式： 程序员 ― 系统工程师（系统分析员）

三、部分参考资料 《 软件工程理论与实践 》许家冶等编著，高等教育出版社， 2005 年 《 软件工程 》 （第二版），齐治昌等，高等教育出版社， 2004 年 《 面向对象的系统分析 》 ，杨芙清等编著，清华大学出版社， 2001 年 《 UML 用户指南 》 G Booch 等著，邵维忠等译，机械工业出版社 2002 年

四、课程特点和学习的注肯事项 1 、知易行难 要将理论知识与实践运用结合，进行对照，以加深理解和掌握。 2 、内容纷杂 软件工程涉及计算机科学、数学、工程科学和管理科学等多个领域。其中： 计算机科学和数学用于构造模型与算法； 工程科学用于制定规范、设计范型、评估成本及确定权衡 管理科学用于计划、资源、质量和成本的管理。

五、教材总目录 第 1 章软件工程学概述 第 2 章可行性研究 第 3 章需求分析 第 4 章形式化说明技术 第 5 章总体设计 第 6 章详细设计 第 7 章实现 第 8 章维护 第9 章面向对象方法学引论 第 10 章面向对象分析 第 11 章面向对象设计 第 12 章面向对象实现 第 13 章软件项目管理 附录 AC + ＋类库管理系统分析与设计 附录 B 汉字行编辑程序设计

课程内容学时安排 章节 课程内容 学时 l 软件工程学概述 4 2 可行性研究 4 3 需求分析 4 5 总体设计 6 6 详细设计 4 章节 课程内容 学时 l 软件工程学概述 4 2 可行性研究 4 3 需求分析 4 5 总体设计 6 6 详细设计 4 7 实现 8 章节 课程内容 学时 8 软件维护 2 9 面向对象方法学引论 4 10 面向对象分析 2 11 面向对象设计 2 12 面向对象实现 2 13 软件项目管理 6 14 总结 2 注： 2 、 3 章内容关联较大，讲授时不拘于课本中章节的安排和划分；第 9 、 10 章也同样。

六、课程考核方式 分数组成： 平时成绩（ 10 % ) ：以理论课课堂表现为主。 作业（ 30 % ) ：书面作业 期末考试（60 % ) ：

课程设计分组要求 3- 5 人一组，自由组合，选出组长。 以小组为单位共同完成“课程实践”和“课程设计”。 课程设计内容、记分方式另外通知． 本周（第 1 周）星期五之前请各班课代表或者学习委员给出分组的详细名单。（电子版和纸张文档）

第 1 章 软件工程学概述 1 . 1 软件危机 1 . 2 软件工程 1 . 3 软件生命周期 1 . 4 软件过程 1 . 5 小结 第 1 章 软件工程学概述 1 . 1 软件危机 1 . 2 软件工程 1 . 3 软件生命周期 1 . 4 软件过程 1 . 5 小结 习题

学习重点 掌握几个基本概念 1、软件危机、软件工程产生的原因 2、软件工程过程和软件生命周期 3、软件生命周期模型 软件危机 软件工程 软件过程 软件生命周期 软件生命周期模型

软件危机与软件工程学 软件工程学的产生要从“软件危机”说起 什么是软件危机？ 软件危机有什么典型表现？ 为什么会产生软件危机？ 1968 年，第一届 NAT0 （北大西洋公约组织的计算机科学家的国际会议）会议，“软件工程”的慨念作为一种有效解决“软件危机”的途径被正式提出。 什么是软件危机？ 软件危机有什么典型表现？ 为什么会产生软件危机？ 怎么解决软件危机？

§1 软件危机 § 1 . 1 . 1 软件危机介绍 什么是软件危机？ 软件危机指在计算机软件的开发和维护过程中，所遇到的一系列严重问题。 软件危机主要包括的问题（两方面） : ① 如何开发软件 ② 如何维护软件

软件危机有什么典型表现？（1） 开发费用和进度难以估算和控制，大大超过预期的资金和规定日期； 软件需求分析不够充分，用户不满意“已经完成”的软件系统。 软件质量难于保证； 软件维护困难； 难以改正程序中的错误； 难以根据用户的需要在原有程序中增加一些新的功能。

软件危机有什么典型表现？ 通常没有保留适当的文档资料。 文档的作用： 软件开发管理人员：用于管理和评价软件开发工程的进展状况 软件开发人员：用于开发人员对各个阶段的工作都进行周密思考、全盘权衡、从而减少返工。并且可在开发早期发现错误和不一致性，便于及时加以纠正 软件维护人员:软件维护的依据 开发成本逐年上升，软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。

几个软件危机的著名案例 ① 1966年，IBM 360 机的操作系统。花费 5000 人一年的工作量，写了近 1 万行代码。错误百出，每次的新版本就是从前一版本中找 1 000个程序错误而修正的结果。 ② 1963 年，美国用于控制火星探测器的计算机软件中的一个 “ , ”号被误写为“.”，而致使飞往火星的探测器发生爆炸，造成高达数亿美元的损失。 ③ 美国丹佛新国际机场自动化行李系统软件。投资 1. 93 亿美元，计划 1993 年万圣节启用。但开发人员一直为系统错误困扰，屡次推后启用时间，直到 1994 年 6 月，机场计划者承认无法预测何时能启用。 ④ 1996 年，欧洲阿里亚纳 5 型运载火箭坠毁，造成 5 亿美元损失。原因是控制软件中的一个错误。

§1 . 1 . 2 产生软件危机的原因 主要两个原因： 1 、与软件本身的特点有关 2 、与软件开发与维护的方法不正确有关。

一 、软件本身的特点 （ 1） 软件与硬件、一般程序存在很多不同之处。 1 、软件与硬件不同 抽象性。软件生产没有明显的制造过程，难以衡量开发进展，也难以控制软件质量。 问题的隐蔽性。没有硬件的磨损、老化问题，但存在开发早期在分析、设计阶段的错误，修改难度较大。

失效率蜘线

改正一个问题需付出的代价

2 、软件与一般程序不同（1） ① 软件远比一般程序规模庞大，复杂性高 软件所反映的实际问题的复杂性 程序逻辑结构的复杂性。 例 1 : Windows95 , 1000 万行代码； Windows2000， 5000 万行代码 例 2 : Exchange 2000 和 windows 2000 开发人员

软件的规模 软件产品的特殊性和人类智力的局限性，导致人们无力处理“复杂问题”。

2 、软件与一般程序不同（ 2 ) ② 大型软件开发既有技术问题，还有社会问题。 开发团队成员分工合作 技术与管理的矛盾 社会因素：组织机构、体制、管理方式、观念、人的心理素等。 开发团队成员分工合作 技术与管理的矛盾 软件开发人员对软件应用的领域知识的了解

二、软件开发维护方法中存在的问题（1) ① 对用户需求的获取不正确 越是早期产生的错误，付出的代价越大。 用户的原因 分析人员的原因 对分析人员的要求：沟通能力、归纳总结能力、经验 越是早期产生的错误，付出的代价越大。 图：不同时期引入同一变 动 的代价

二、软件开发维护方法中存在的问题( 2 ) ② 软件开发就是编写程序。 ③ 软件开发只要依靠个别编程高手就能完成。 ④ 轻视软件维护 一个完整的软件产品由一整套完整的配置组成，程序只是其中的一个组成部分。 软件开发过程包括多个阶段，每个阶段的产品都是最终的完整的软件产品的一部分。 ③ 软件开发只要依靠个别编程高手就能完成。 ④ 轻视软件维护 软件维护约占软件费用 55 一 75 % ，包括修改软件运行的错误；对软件进行改进和功能扩充。

软件维护在软件费用的比例

三、其他产生软件危机的原因 ①软件开发尚未完全摆脱手工艺的开发方式。 ② 软件成本相当昂贵，主要依靠大量复杂的、高强度的脑力劳动 ③ 软件的开发和运行常常受到计算机系统的限制，对计算机系统有着不同程度的依赖性。 软件的“可移植性”就是指的软件对硬件的依赖程度。好的可移植性依赖少。

§1 . 1 . 3 消除软件危机的途径 1 、彻底消除“软件就是程序”的错误观念。 2 、充分认识到软件开发是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目，不是个人独立的劳动。 3 、推广和使用在实践中总结出来的软件开发的成功技术和方法。 4 、开发和使用更好的软件工具

总结：“软件工程”的方法理论是摆脱软件危机的一个主要出路。 计算机和软件科学家为解决软件危机问题，尝试将在其它领域中行之有效的工程学知识运用到软件开发工作中来，经过不断实践和总结，最后得出一个结论；按工程化的原则和方法组织软件开发工作是有效的，是摆脱软件危机的一个主要出路。

思考题（ 1 ) 1 ）只要是编程高手，即使是不懂软件工程，也能编出很好的软件。 软件是服务于大众，却是由个性化的开发人员完成的。如果个性化太强，程序就无法阅读，其他人员也就无法维护。 例：国内 80 年代涌现出来的众多汉字操作系统均是由编程高手完成的。

思考题（ 2 ) 2 ）只要拥有一套讲述如何开发软件的书籍，并了解了书中的标准与示例，就可以解决软件开发中遇到的任何问题。 软件是用来解决现实问题的，现实问题的特殊性对规范提出了挑战（要进行适应）。 软件技术是发展的，没有祖传秘方。 就像拥有食谱并不能成为名厨一样，软件开发需要实践。

思考题（ 3 ) 3 ）只要拥有最好的开发工具、最好的计算机，一定能做出优秀的软件。 硬件环境只是必要条件，人才是充分条件，软件是人在一定的约束条件下创造出来的。因人因事而异。

思考题 (4) 4 ）软件开发时，如果进度慢，落后于计划，可以增加更多的程序员来解决。 增加人力可以减少开发时间吗？ 思考题 (4) 4 ）软件开发时，如果进度慢，落后于计划，可以增加更多的程序员来解决。 增加人力可以减少开发时间吗？ 新手！任务的重新划分！沟通更加复杂！ 必须依靠科学地计划来解决这样的问题。

思考题（5） 5 ）争议：如果软件运行较慢，是换一台更快的计算机，还是设计一种更快的算法？ 软件的性能问题； 应用级别→算法的合理性； 系统级别→操作系统、数据库系统、系统软件等； 硬件级别→机器性能

§1 . 2 软件工程 §1 . 2 . 1 软件工程介绍 一、“软件工程”的典型定义 1 ）1968 年，第一届 NATO 会议 为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。 2 ) IEEE/CS（电气电子工程师协会／计算机科学分会） ① 1993 年，将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件中。 ② 对 ① 中提到的各种方法的研究

3 ） 其他学者的定义 Boehm ：运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。 Fritz Bauer: 建立并使用完善的工程化原则，以较经济的手段获得能在实际机器上有效运行的可靠软件的一系列方法 所有定义都强调在软件开发过程中，应用工程化原则的重要性

几个关于软件工程本质特性和基本原理的问题 问题一： 软件工程适用范围？ 问题二：软件工程如何控制系统开发的复杂性的？ 问题三：以你的经验，举例说明一个成熟的软件通常采用什么方法来适应现实世界的变化的？

几个关于软件工程本质特性和基本原理的问题 问题四：假设某软件公司，能为同一个用户开发两个不同层次的软件：一个层次的软件功能非常强大，在满足用户所有需求的基础上，还能提供大大超过用户需求的其他更多更强的功能；另一个层次的软件仅仅能满足用户需求，但没有提供其他额外的功能。请问如果你是项目负责人，你会选择为客户开发那个层次的软件？ 问题五：协同工作有什么重要性？

几个关于软件工程本质特性和基本原理的问题 问题五：怎样理解“在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品”这句话？ 问题六：某软件开发，由于时间和资金都非常紧迫，在需求分析人员非常认真、仔细地做完需求分析之后，说：我们可以保证我们的需求分析正确性，不用花时间检查了，设计人员可以直接拿着这份分析报告，马上开始设计。如果你是项目负责人，你会如何决定？为什么？ 问题七：在需求分析完成并获得了用户的肯定，也通过了评审，进入软件设计阶段之后，用户的想法有了改变，提出了一个新的要求，此时如果你是项目负责人，应该怎样做？

二、软件工程本质特性（2） 1 ）软件工程关注于大型程序的构造。 2 ）软件工程的中心课题是控制复杂性 3 ）软件经常变化 主要考虑：如何分解和集成 为什么要分解： G .Miller, “7士 2 ” 原则 3 ）软件经常变化 4 ）开发软件的效率非常重要 5 ）和谐地合作是开发软件的关键 6 ）软件必须有效地支持它的用户 7 ）在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品 扩展定义：软件=知识＋程序+数据+文档

§1 . 2 . 2 软件工程的基本原理 B.W.Boehm, 1983 年提出： 1 ）用分阶段的生命周期计划严格管理 2 ）坚持进行阶段评审 3 ）实行严格的产品控制基线 基线（baseline）控制 4 ）采用现代程序设计技术 5 ）结果应能清楚地审查 6 ）开发小组的人员应该少而精 7 ）承认不断改进软件工程实践的必要性

§1 . 2 . 3 软件工程方法学 软件工程包括“管理”和“技术”两方面内容： 管理—— 对人、财、物的合理使用和配置； 技术—— 指软件开发中采用的方法、工具和过程。 什么是软件工程方法学？ 通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学（methodology)，也称为范型（paradigm）。

一、软件工程方法学三要素：工具、方法和过程 要素一：软件工程过程 规定了完成各项任务的工作步骤。 要素二：软件工程方法 完成软件开发的各项任务的技术方法，为软件开发提供了“如何做”的技术。 如项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试以及维护等。 要素三：软件工程工具 计算机辅助软件工程 CASE ( computer Aided sottware Engineering ) ，为软件工程方法提供自动或半自动的软件支撑环境。

二、软件工程方法学思想 两种： 1、 传统方法学（生命周期方法学或结构化范型） 2、面向对象方法

1.传统方法学(生命周期方法学或结构化范型） 采用结构化技术（结构化分析、结构化设计和结构化实现）来完成软件开发的各项任务； 把软件生命周期划分为若干个阶段，按顺序完成每个阶段的任务； 每个阶段开始和结束都有严格的标准，对任何两个相邻的阶段而言，前一个阶段的结束标准就是后一阶段的开始标准； 每一个阶段结束之前都必须进行正式严格的技术审查和管理复审

传统方法学的优点： 分解任务，分工合作，降低整个软件开发工程的困难； 采用科学的管理技术和良好的技术方法对每个阶段成果都进行严格的审查。保证了软件的质量。 传统方法学的缺点： 把数据和操作人为地分离成两个独立的部分，增加了软件开发与维护的难度。

2 、面向对象方法学（ OO,Object- oriented ) 模拟人类习惯的思维方式，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程，从而使描述问题的问题空间（也称为问题域）与实现解法的解空间（也称为求解域）在结构上尽可能一致。

面向对象方法学 4 要点 把对象（ object ）作为融合了数据及在数据上的操作行为的统一的软件构件。 把所有对象都划分成类（class ）。 按照父类（或称为基类）与子类（或称为派生类）的关系，把若干个相关类组成一个层次结构的系统（也称为类等级）。 对象彼此间仅能通过发送消息互相联系。

二者区别 传统方法学：强调自顶向下顺序地完成软件开发的各阶段任务。 面向对象方法：是主动地多次反复迭代的演化过程

3 软件生命周期 一、什么是软件生命周期（ life cycle） 指软件孕育、诞生、成长、成熟、衰亡的生存过程 GB 一 8567 中将软件生命周期分为 7 个阶段： 可行性研究和项目开发计划；需求分析；慨要设计；详细设计；编码；测试；维护 其他分法， 5 个阶段： 需求定义、设计、编码、测试及维护； 需求定义阶段包括可行性研究和项目开发计划、需求分析； 设计阶段包括慨要设计和详细设计。

本教材对软件生命周期的划分

1 、软件定义时期 任务： 确定软件开发工程必须完成的总目标； 确定工程的可行性； 导出实现工程目标应该采用的策略及系统必须完成的功能； 估计完成该项工程需要的资源和成本，并且制定工程进度表。 通常分为问题定义、可行性研究和需求分析三个阶段。

软件定义时期的三个阶段 ① 问题定义阶段回答： 回答：“要解决的问题是什么？” ② 可行性研究阶段 回答：“对于上一个阶段所确定的问题有行得通的解决办法吗？ ③需求分析（Requirement Analysis） 回答“为了解决这个问题，目标系统必须做什么 ? 用正式文档准确地记录对目标系统的需求，这份文档通常称为规格说明书（ specification ）。

2 、软件开发时期 具体设计和实现前一个时期定义的软件，通常分为四个阶段： ① 总体设计（概要设计） 回答：“概括地说，应该怎样实现目标系统？ ” 根据需求分析，设计软件的体系结构；定义结构中的组成模块。 ② 详细设计（模块设计） 回答：“应该怎样具体地实现这个系统呢？ ” 对每个模块要完成的工作进行具体的描述，为源程序编写打下基础。编写设计说明书，提交评审。 二者统称系统设计

软件开发时期四个阶段 ③ 程序编写（ Coding, Programming ) ：把软件设计转换成计算机可以接受的程序代码。 ④ 软件测试（Testing ) : 按规定的各项需求，逐项进行有效性测试，决定已开发的软件是否合格，能否交付用户使用，包括单元测试和组装测试。 二者统称系统实现

3、运行维护（软件维护）时期（ Running/Maintenance ) 使软件持久的满足用户的需要。包括： 改正性维护：运行中发现了软件中的错误需要修正。 适应性维护：为了适应变化了的软件工作环境，需做适当变更。 完善性维护：当用户有新的要求时，应该及时改进软件以满足用户的要求。 预防性维护: 即修改软件为将来的维护活动预先做准备。

几个关干软件生命周期阶段的问题 问题一：开发一个软件大概需要多少资金、时间，将获得什么效益一般是在哪个阶段确定？相对而言，在哪个阶段与用户交流最多？ 问题二：系统分析员主要工作在哪个时期？程序员主要工作在哪个时期？ 问题三：软件定义时期的三个阶段，各自回答什么关键问题？ 问题四：软件开发时期有几个阶段？各自回答什么关键问题？

问题五：软件体系结构最早是在哪个阶段决定的？ 问题六：详细设计与程序编写阶段有什么样的密切联系？ 问题七：“软件测试是为了验证系统的正确性”这句话对吗？ 问题八：软件维护有那几种？各有什么功能？

§1.4 软件过程（ Software Process ) 1 、什么是软件过程 为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。 ISO 9000的定义： 使用资源将输入转化为输出的活动所构成的系统。 “系统”是相互关联或相互作用的一组要素。 过程是软件工程三要素之一。 通常用软件生命周期模型来描述。

2 、什么是软件生命周期模型 又称：软件开发模型／软件过程模型／软件工程范型。 指软件项目从需求定义直至软件经使用后废弃为止，跨越整个生存周期的系统开发、运作和维护所实施的全部过程、活动和任务的结构框架。 常见的有：瀑布模型、演化模型、螺旋模型、喷泉模型、智能模型

§ 1.4.1瀑布模型(waterfall model) 1970年,由W.Royce提出 一、瀑布模型的过程 1 、传统的瀑布模型 从上一阶段接受本阶段 的工作对象，作为输 入； 利用输入，完成本阶段活 动的内容． 本阶段的工作成果作为输出 传入下一阶段。

瀑布模型 — 实际的瀑布模型 需求分析 变化的需求 验证 增加了一个评审活动，评审每个阶段完成的活动，若得到确认，则进行下一阶段的活动；否则返回前一阶段，甚至更前阶段返工； 验证 规格说明 验证 设计 验证 编码 测试 综合测试 维护

二、瀑布模型特点 阶段间具有顺序性和依赖性 推迟实现的观点 质量保证的观点

三、瀑布模型优缺点 优点： 可强迫开发人员采用规范的方法； 严格地规定了每个阶段必须提交的文档； 要求每个阶段的所有产品都必须经过质量保证小组的仔细验证； 缺点： 无法解决软件需求不明确或不准确的问题；可能导致最终开发的产品不能真正满足用户需要。 瀑布模型比较适合开发需求明确的软件。

§ 1 . 4 . 2 快速原型模型 1 、什么是“原型” ? 原型是快速实现和运行的早期版本，反映最终系统部分重要特性。 常见的原型实例：人机界面；系统主要功能。 优点： 1 、通常能反映用户真实需求； 2 、软件产品的开发基本上是线性顺序进行的。

2 、快速原型的过程 如右图。 获得用户的基本需求说明，据此快速建立一个小型软件系统． 用户试用，对其评价； 开发人员按照用户的意见快速地修改原型系统，获得新的原型版本，再请用户试用，如此反复，直到满足用户的要求； 用户确认原型系统之后，开发人员据此书写规格说明文档，进行下一步开发。

1.4.3 增量（渐增）模型 把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。 使用增量模型时，第一个阶段的增量构件往往实现软件的基本需求，提供最核心的功能；后面的增量构架逐渐添加系统的功能。

图：增量（渐增）模型 需求分析 验证 规格说明 验证 设计 验证 针对每个构件完成详细设计、编码和集成，经测试后交付给用户 维护

增量模型注意事项 增量构件规模适中； 分解的约束条件是当把新构件集成到现有软件中时，所形成的产品必须是可测试的； 软件体系必须是开放的，即在对现有系统添加新增量构件时，不能破坏系统原有功能。

增量模型优缺点 优点： 能在较短的时间内，提供可完成部分工作的初步产品给用户； 用户有较为充裕的时间学习和适应新产品。 缺点： 对开发人员技术能力要求较高，要求能从系统整体出发正确划分增量构件，并进行分别开发，最后能很好地集成这些构件。

一种风险更大的增量模型 有可能提高开发速度，但需要密切地监控整个开发过程，否则将冒构件无法集成到一起的风险，。 分析 设计 编码 测试 分析 构件1 分析 设计 编码 测试 构件2 分析 设计 编码 测试 构件3 分析 设计 编码 测试 构件4 有可能提高开发速度，但需要密切地监控整个开发过程，否则将冒构件无法集成到一起的风险，。

§1.4 .4 螺旋模型（spiral model ) 大型软件开发面临的重要问题：软件风险 构建原型能使某些类型的风险降到最低. 如：产品交付给用户之后，用户不满意； 开发进度落后，开发成本超出预算; 产品完成前关键的开发人员跳槽; 在产品投人市场前，竞争对手发布了一个功能相近，价格更低的软件……… 构建原型能使某些类型的风险降到最低.

一、简单的螺旋模型 螺旋模型改进了原型模型，在每个阶段都加入风险分析。 图1.7简化的螺旋模型 图1.7简化的螺旋模型

二、完整的螺旋模型

螺旋模型的优缺点 优点： 强调可选方案和约束条件，有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标； 减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险； 维护是一个周期，与开发并没有本质区别 缺点： 需要开发人员具有相当丰富的风险评估经验和专门知识； 进行风险分析的费用可能较大。 适合大型软件开发

各种模型的比较 模型 优点 缺点 瀑布模型 快速原型 增量模型 螺旋模型 规范，文档驱动 系统可能不满足客户真正的需求 克服了瀑布型的缺点 开发早期回报明确，易于维护 要求开放的软件体系结构 螺旋模型 风险驱动，适用于大型项目开发 风险分析人员需要有经验且经过充分训练

第一章 小结