1、第1章 软件与软件工程的概念 软件的概念、特性和分类软件的概念、特性和分类 软件危机与软件工程软件危机与软件工程 软件工程的目标软件工程的目标 软件生存期软件生存期 软件生存期模型软件生存期模型 软件工程知识体系及知识域软件工程知识体系及知识域1.1 软件的概念、特性和分类软件的作用软件的作用具有具有产品产品和和产品生产载体产品生产载体的双重作用。的双重作用。(1)作为产品，软件显示了由计算机硬件体现的计作为产品，软件显示了由计算机硬件体现的计算能力，扮演着信息转换的角色：产生、管理、算能力，扮演着信息转换的角色：产生、管理、查询、修改、显示或者传递各种不同的信息。查询、修改、显示或者传递各种
2、不同的信息。(2)作为产品生产的载体，软件提供了计算机控制作为产品生产的载体，软件提供了计算机控制（操作系统）、信息通信（网络），以及应用（操作系统）、信息通信（网络），以及应用程序开发和控制的基础平台（软件工具和环程序开发和控制的基础平台（软件工具和环境）。境）。1.1 软件的概念、特性和分类 软件的概念软件的概念 虽然软件对于现代人并不陌生，但很多人对于软虽然软件对于现代人并不陌生，但很多人对于软件的理解并不准确，件的理解并不准确，“软件就是程序，软件开发软件就是程序，软件开发就是编程序就是编程序”的这种错误观点仍然存在。的这种错误观点仍然存在。什么是软件？1.1 软件的概念、特性和分类1
3、.1 软件的概念、特性和分类 软件的特性软件的特性1.1 软件的概念、特性和分类1.1 软件的概念、特性和分类 1.1 软件的概念、特性和分类1.1 软件的概念、特性和分类1.1 软件的概念、特性和分类 软件的分类软件的分类 按照软件的作用，一般可以将软件做如下按照软件的作用，一般可以将软件做如下分类。分类。(1)(1)系统软件系统软件 (2)(2)应用软件应用软件 (3)(3)支撑软件支撑软件 (4)(4)可复用软件可复用软件 l软件危机暴发于上个世纪六十年代末。l主要表现为：软件的发展速度远远滞后于硬件的发展速度，不能满足社会日益增长的软件需求。软件开发周期长、成本高、质量差、维护困难。1
4、.2 软件危机与软件工程 软件危机软件危机l典型例子：美国IBM公司在1963年至1966年开发的IBM 360机的操作系统。l这个项目的负责人F.D.Brooks事后总结了他在组织开发过程中的沉痛教训时说：正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深。最后无法逃脱灭顶的灾难，程序设计工作正像这样一个泥潭，一批批程序员被迫在泥潭中拼命挣扎，谁也没有料到竟会陷入这样的困境1.2 软件危机与软件工程具体来说，软件危机主要有以下一些典型表现具体来说，软件危机主要有以下一些典型表现:对软件开发成本和进度的估计常常很不准确。对软件开发成本和进度的估计常常很不准确。用户对用户对“已完成的已
5、完成的”软件系统不满意的现象经常发生。软件系统不满意的现象经常发生。软件产品的质量往往靠不住。软件产品的质量往往靠不住。软件常常是不可维护的。软件常常是不可维护的。软件通常没有适当的文档资料。软件通常没有适当的文档资料。软件成本在计算机系统总成本中所占的比例逐年上升。软件成本在计算机系统总成本中所占的比例逐年上升。软件开发生产率提高的速度，既跟不上硬件的发展速度，软件开发生产率提高的速度，既跟不上硬件的发展速度，也远远跟不上计算机应用迅速普及深入的趋势。也远远跟不上计算机应用迅速普及深入的趋势。1.2 软件危机与软件工程除了软件本身的特点，软件危机发生的主要原因有：除了软件本身的特点，软件危机
6、发生的主要原因有：(1)(1)缺乏软件开发的经验和有关软件开发数据的积累，使得开发缺乏软件开发的经验和有关软件开发数据的积累，使得开发工作的计划很难制定。工作的计划很难制定。(2)(2)软件人员与用户的交流存在障碍，使得获取的需求不充分或软件人员与用户的交流存在障碍，使得获取的需求不充分或存在错误存在错误 。(3)(3)软件开发过程不规范。如，没有真正了解用户的需求就开始软件开发过程不规范。如，没有真正了解用户的需求就开始编程序。编程序。(4)(4)随着软件规模的增大，其复杂性往往会呈指数级升高。需要随着软件规模的增大，其复杂性往往会呈指数级升高。需要很多人分工协作，不仅涉及技术问题，更重要的
7、是必须有科很多人分工协作，不仅涉及技术问题，更重要的是必须有科学严格的管理。学严格的管理。(5)(5)缺少有效的软件评测手段，提交用户的软件质量不能完全保缺少有效的软件评测手段，提交用户的软件质量不能完全保证。证。1.2 软件危机与软件工程 彻底消除彻底消除“软件就是程序软件就是程序”的错误观念。的错误观念。充分认识到软件开发应该是一种组织良好、管理充分认识到软件开发应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。严密、各类人员协同配合、共同完成的工程项目。推广和使用在实践中总结出来的开发软件的成功推广和使用在实践中总结出来的开发软件的成功技术、方法和工具。技术、方法和工具
8、。按工程化的原则和方法组织软件开发工作。按工程化的原则和方法组织软件开发工作。如何摆脱软件危机如何摆脱软件危机?1.2 软件危机与软件工程1.2 软件危机与软件工程l软件工程的概念软件工程的概念 为了克服软件危机，1968年10月在北大西洋公约组织（NATO）召开的计算机科学会议上，Fritz Bauer首次提出“软件工程”的概念，试图将工程化方法应用于软件开发。在NATO会议上，Fritz Bauer对软件工程的定义是：“软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。”1993年IEEE给出的定义：“软件工程是：把系统的、规范的、可度量的途径应
9、用于软件开发、运行和维护过程，也就是把工程应用于软件；研究中提到的途径。”。1.2 软件危机与软件工程 软件工程软件工程是指导计算机软件开发和维护的一门是指导计算机软件开发和维护的一门工程学科。工程学科。采用工程的概念、原理、技术和方法来开发和采用工程的概念、原理、技术和方法来开发和维护软件，把经过时间考验而证明正确的管理维护软件，把经过时间考验而证明正确的管理方法和当前能够得到的最好技术结合起来，以方法和当前能够得到的最好技术结合起来，以经济地开发出高质量的软件并有效地维护它，经济地开发出高质量的软件并有效地维护它，这就是软件工程。这就是软件工程。1.2 软件危机与软件工程1.3 软件工程的
10、目标 软件工程的目标软件工程的目标是运用先进的软件开发技术和管是运用先进的软件开发技术和管理方法来提高软件的理方法来提高软件的质量质量和和生产率生产率，也就是要以，也就是要以较短的周期、较低的成本生产出高质量的软件产较短的周期、较低的成本生产出高质量的软件产品，并最终实现软件的工业化生产。品，并最终实现软件的工业化生产。1.3 软件工程的目标 生产率与成本密切相关生产率与成本密切相关，生产率的提高往往意味，生产率的提高往往意味着开发周期的缩短，成本下降。着开发周期的缩短，成本下降。生产率与质量之间也有着内在的联系生产率与质量之间也有着内在的联系，表面上看，表面上看，追求高质量会延长软件开发时间
11、，并因此增加了追求高质量会延长软件开发时间，并因此增加了成本，似乎降低了生产率。但如果生产的软件质成本，似乎降低了生产率。但如果生产的软件质量差，虽然开发的时间可能缩短，但之后可能会量差，虽然开发的时间可能缩短，但之后可能会造成返工，总的开发时间可能会更长。即使不返造成返工，总的开发时间可能会更长。即使不返工，也无疑会增加维护代价。工，也无疑会增加维护代价。1.4 软件生存期 概念概念 软件也有一个孕育、诞生、成长、成熟和衰亡的软件也有一个孕育、诞生、成长、成熟和衰亡的生存过程，我们称这个过程为生存过程，我们称这个过程为软件生命周期软件生命周期或或软软件生存期件生存期。软件生存期由软件生存期由
12、软件定义软件定义、软件开发软件开发和和运行维护运行维护3 3个个时期组成，每个时期又可划分为若干个阶段。时期组成，每个时期又可划分为若干个阶段。1.4 软件生存期 软件定义时期软件定义时期 主要任务是解决主要任务是解决“做什么做什么”的问题，即确定工程的问题，即确定工程的总目标和可行性；导出实现工程目标应使用的的总目标和可行性；导出实现工程目标应使用的策略及系统必须完成的功能；估计完成工程需要策略及系统必须完成的功能；估计完成工程需要的资源和成本；制订工程进度表。的资源和成本；制订工程进度表。通常又分为通常又分为3 3个阶段：个阶段：问题定义问题定义、可行性研究可行性研究和和需需求分析求分析。
13、1.4 软件生存期 软件开发时期软件开发时期 主要任务是解决主要任务是解决“如何做如何做”的问题，即具体设计的问题，即具体设计和实现在前一个时期定义的软件。和实现在前一个时期定义的软件。由由概要设计概要设计、详细设计详细设计、编码编码和和测试测试4 4个阶段组成。个阶段组成。1.4 软件生存期软件运行维护时期软件运行维护时期 主要任务是使软件持久地满足用户的需要，通常主要任务是使软件持久地满足用户的需要，通常有有4 4类维护活动：类维护活动：(1)(1)改正性维护改正性维护，也就是诊断和改正在使用过程中，也就是诊断和改正在使用过程中发现的软件错误；发现的软件错误；(2)(2)适应性维护适应性维
14、护，即修改软件以适应环境的变化；，即修改软件以适应环境的变化；(3)(3)完善性维护完善性维护，即根据用户的要求改进或扩充软，即根据用户的要求改进或扩充软件，使它更完善；件，使它更完善；(4)(4)预防性维护预防性维护，即修改软件为将来的维护活动预，即修改软件为将来的维护活动预先做准备。先做准备。1.4 软件生存期 开发过程中的典型文档开发过程中的典型文档 软件需求规格说明书软件需求规格说明书：描述将要开发的软件做什：描述将要开发的软件做什么。么。项目计划项目计划：描述将要完成的任务及其顺序，并估：描述将要完成的任务及其顺序，并估计所需要的时间及工作量。计所需要的时间及工作量。软件测试计划软件
15、测试计划：描述如何测试软件，使之确保软：描述如何测试软件，使之确保软件应实现规定的功能，并达到预期的性能。件应实现规定的功能，并达到预期的性能。软件设计说明书软件设计说明书：描述软件的结构，包括概要设：描述软件的结构，包括概要设计及详细设计。计及详细设计。用户手册用户手册：描述如何使用软件。：描述如何使用软件。1.4 软件生存期各个阶段所要完成的基本任务各个阶段所要完成的基本任务(1)(1)问题定义与可行性研究问题定义与可行性研究 本阶段要回答的关键问题是本阶段要回答的关键问题是“到底要解决什么问题？在到底要解决什么问题？在成本和时间的限制条件下能否解决问题？是否值得做？成本和时间的限制条件下
16、能否解决问题？是否值得做？”(2)(2)需求分析需求分析 本阶段要回答的关键问题是本阶段要回答的关键问题是“目标系统应当做什么？目标系统应当做什么？”(3)(3)软件设计软件设计 设计是软件工程的技术核心。本阶段要回答的关键问题设计是软件工程的技术核心。本阶段要回答的关键问题是是“如何实现目标系统？如何实现目标系统？”1.4 软件生存期 各个阶段所要完成的基本任务各个阶段所要完成的基本任务(4)(4)程序编码和单元测试程序编码和单元测试 本阶段要解决的问题是本阶段要解决的问题是“正确地实现已做的设计正确地实现已做的设计”，即即“如何编写正确的、可维护的程序代码？如何编写正确的、可维护的程序代码
17、？”(5)(5)集成测试和系统测试集成测试和系统测试 集成测试集成测试的任务是将已测试过的模块按设计规定的的任务是将已测试过的模块按设计规定的顺序组装起来，在组装的过程中检查程序连接中的顺序组装起来，在组装的过程中检查程序连接中的问题。问题。系统测试系统测试的任务是根据需求规格说明的要求，对必的任务是根据需求规格说明的要求，对必须实现的各项需求，逐项进行确认，判定已开发的须实现的各项需求，逐项进行确认，判定已开发的软件是否符合用户需求，能否交付用户使用。软件是否符合用户需求，能否交付用户使用。1.4 软件生存期 各个阶段所要完成的基本任务各个阶段所要完成的基本任务(6)(6)软件运行和维护软件
18、运行和维护 已交付的软件投入正式使用，便进入运行已交付的软件投入正式使用，便进入运行阶段。这一阶段可能持续若干年。软件在阶段。这一阶段可能持续若干年。软件在运行中可能由于多方面的原因，需要对它运行中可能由于多方面的原因，需要对它进行修改。进行修改。1.5 软件生存期模型 瀑布模型瀑布模型 快速原型模型快速原型模型 增量模型增量模型 螺旋模型螺旋模型 喷泉模型喷泉模型 统一过程统一过程 瀑布模型瀑布模型在在2020世纪世纪8080年代之前，瀑年代之前，瀑布模型一直是唯一被广泛布模型一直是唯一被广泛采用的生命周期模型。采用的生命周期模型。传统的瀑布模型如图所示。传统的瀑布模型如图所示。瀑布模型瀑布
19、模型 瀑布模型的特点瀑布模型的特点阶段间具有顺序性和依赖性。其中包含两重含义：阶段间具有顺序性和依赖性。其中包含两重含义：必须等前一阶段的工作完成之后，才能开始后一必须等前一阶段的工作完成之后，才能开始后一阶段的工作；阶段的工作；前一阶段的输出文档就是后一阶段的输入文档。前一阶段的输出文档就是后一阶段的输入文档。瀑布模型瀑布模型 瀑布模型的特点瀑布模型的特点推迟实现的观点推迟实现的观点 瀑布模型在编码之前设置了系统分析和系统设计瀑布模型在编码之前设置了系统分析和系统设计的各个阶段，分析与设计阶段的基本任务规定，的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不
20、在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。涉及软件的物理实现。清楚地区分逻辑设计与物理设计，尽可能推迟程清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。重要的指导思想。瀑布模型瀑布模型 瀑布模型的特点瀑布模型的特点质量保证的观点质量保证的观点 每个阶段都必须完成规定的文档，没有交出合格每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。的文档就是没有完成该阶段的任务。每个阶段结束前都要对所完成的文档进行评审，每个阶段结束前都要对所完成的文档进行评审，以便尽早发
21、现问题，改正错误。以便尽早发现问题，改正错误。瀑布模型瀑布模型 实际的瀑布模型实际的瀑布模型实际的瀑布模型是带实际的瀑布模型是带“反馈环反馈环”的，如图所的，如图所示。示。图中图中实线箭头表示开发实线箭头表示开发过程过程，虚线箭头表示维虚线箭头表示维护过程护过程。瀑布模型瀑布模型 瀑布模型的优点瀑布模型的优点可强迫开发人员采用规范化的方法。可强迫开发人员采用规范化的方法。严格地规定了每个阶段必须提交的文档。严格地规定了每个阶段必须提交的文档。要求每个阶段交出的所有产品都必须是经过验证要求每个阶段交出的所有产品都必须是经过验证的。的。瀑布模型瀑布模型 瀑布模型的缺点瀑布模型的缺点由于瀑布模型几乎
22、完全依赖于书面的规格说明，由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足很可能导致最终开发出的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间用户的需要。如果需求规格说明与用户需求之间有差异，就会发生这种情况。有差异，就会发生这种情况。瀑布模型只适用于项目开始时需求已确定的情况。瀑布模型只适用于项目开始时需求已确定的情况。快速原型模型快速原型模型快速原型是快速建立起来快速原型是快速建立起来的可以在计算机上运行的的可以在计算机上运行的程序，它所能完成的功能程序，它所能完成的功能往往是最终产品能完成的往往是最终产品能完成的功能的一个子集。功能的一
23、个子集。快速原型模型如图所示。快速原型模型如图所示。快速原型模型快速原型模型 快速原型模型的优点快速原型模型的优点(1)(1)有助于满足用户的真实需求。有助于满足用户的真实需求。(2)(2)原型系统已经通过与用户的交互而得到验证，据原型系统已经通过与用户的交互而得到验证，据此产生的规格说明文档能够正确地描述用户需求。此产生的规格说明文档能够正确地描述用户需求。(3)(3)软件产品的开发基本上是按线性顺序进行。软件产品的开发基本上是按线性顺序进行。(4)(4)因为规格说明文档正确地描述了用户需求，因此，因为规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现规格说明文在开发过
24、程的后续阶段不会因为发现规格说明文档的错误而进行较大的返工。档的错误而进行较大的返工。快速原型模型快速原型模型 快速原型模型的优点快速原型模型的优点(5)(5)开发人员通过建立原型系统已经学到了许多东西，开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。段所犯错误的可能性。(6)(6)快速原型的突出特点是快速原型的突出特点是“快速快速”。开发人员应。开发人员应该尽可能快地建造出原型系统，以加速软件开发该尽可能快地建
25、造出原型系统，以加速软件开发过程，节约软件开发成本。过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确原型的用途是获知用户的真正需求，一旦需求确定了，原型可以抛弃，当然也可以在原型的基础定了，原型可以抛弃，当然也可以在原型的基础上进行开发。上进行开发。增量模型增量模型增量模型也称为渐增模型，是增量模型也称为渐增模型，是MillsMills等于等于19801980年提年提出来的。出来的。使用增量模型开发软件时，把软件产品作为一系使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并
26、且能够每个构件由多个相互作用的模块构成，并且能够完成特定的功能。完成特定的功能。增量模型增量模型增量模型如图所示。增量模型如图所示。增量模型增量模型 增量模型的优点增量模型的优点(1)(1)能在较短时间内向用户提交可完成一些有用的工作产品，能在较短时间内向用户提交可完成一些有用的工作产品，即从第即从第1 1个构件交付之日起，用户就能做一些有用的工作。个构件交付之日起，用户就能做一些有用的工作。(2)(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给用户组织带来应新产品，从而减少一个全新的软件可能给用户
27、组织带来的冲击。的冲击。(3)(3)项目失败的风险较低，虽然在某些增量构件中可能遇到一项目失败的风险较低，虽然在某些增量构件中可能遇到一些问题，但其他增量构件将能够成功地交付给客户。些问题，但其他增量构件将能够成功地交付给客户。(4)(4)优先级最高的服务首先交付，然后再将其他增量构件逐次优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来。因此，最重要的系统服务将接受最多的测试。集成进来。因此，最重要的系统服务将接受最多的测试。增量模型增量模型 增量构件开发增量构件开发 每个增量构件应当实现某种系统功能，因此增量构件的开发每个增量构件应当实现某种系统功能，因此增量构件的开发可以采用瀑布
28、模型的方式，如图所示。可以采用瀑布模型的方式，如图所示。增量模型增量模型 采用增量模型需注意的问题采用增量模型需注意的问题(1)(1)在把每个新的增量构件集成到现有软件体系结构在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。中时，必须不破坏原来已经开发出的产品。(2)(2)软件体系结构必须是开放的，即向现有产品中加软件体系结构必须是开放的，即向现有产品中加入新构件的过程必须简单、方便。入新构件的过程必须简单、方便。因此，采用增量模型比采用瀑布模型和快速原型因此，采用增量模型比采用瀑布模型和快速原型模型更需要精心的设计。模型更需要精心的设计。螺旋模型螺旋模型 螺旋
29、模型最初是螺旋模型最初是BoehmBoehm于于19881988年提出来的。年提出来的。该模型将瀑布模型与快速原型模型结合起来，并该模型将瀑布模型与快速原型模型结合起来，并且加入两种模型均忽略了的风险分析。且加入两种模型均忽略了的风险分析。螺旋模型的基本思想是，使用原型及其他方法来螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。尽量降低风险。螺旋模型螺旋模型 理解这种模型的一理解这种模型的一个简便方法，是把个简便方法，是把它看做在每个阶段它看做在每个阶段之前都增加了风险之前都增加了风险分析过程的快速原分析过程的快速原型模型。型模型。螺旋模型螺旋模型 完整的螺旋模型完整的螺旋模型 螺旋模
30、型螺旋模型 完整的螺旋模型完整的螺旋模型 在螺旋模型中，软件过程表示成一个螺线，而不是像以往在螺旋模型中，软件过程表示成一个螺线，而不是像以往的模型那样表示为一个具有回溯的活动序列。的模型那样表示为一个具有回溯的活动序列。在螺线上的每一个循环表示过程的一个阶段。在螺线上的每一个循环表示过程的一个阶段。每个阶段开始时的任务是确定该阶段的目标、为完成这些每个阶段开始时的任务是确定该阶段的目标、为完成这些目标选择方案及设定这些方案的约束条件。接下来的任务目标选择方案及设定这些方案的约束条件。接下来的任务是，从风险角度分析上一步的工作结果，努力排除各种潜是，从风险角度分析上一步的工作结果，努力排除各种
31、潜在的风险，通常用建造原型的方法来排除风险。如果成功在的风险，通常用建造原型的方法来排除风险。如果成功地排除了所有风险，则启动下一步开发步骤，在这个步骤地排除了所有风险，则启动下一步开发步骤，在这个步骤的工作过程相当于纯粹的瀑布模型。最后是评价该阶段的的工作过程相当于纯粹的瀑布模型。最后是评价该阶段的工作成果并计划下一个阶段的工作。工作成果并计划下一个阶段的工作。螺旋模型螺旋模型 螺旋模型的螺旋模型的4项活动项活动 螺线上的每一个循环可划分为螺线上的每一个循环可划分为4 4个象限，分别表达了个象限，分别表达了4 4个方个方面的活动。面的活动。(1)(1)目标设定目标设定定义在该阶段的目标，弄清
32、对过程和产品定义在该阶段的目标，弄清对过程和产品的限制条件，制订详细的管理计划，识别项目风险，可能的限制条件，制订详细的管理计划，识别项目风险，可能还要计划与这些风险有关的对策。还要计划与这些风险有关的对策。(2)(2)风险估计与弱化风险估计与弱化针对每一个风险进行详细分析，设针对每一个风险进行详细分析，设想弱化风险的步骤。想弱化风险的步骤。(3)(3)开发与验证开发与验证评价风险之后选择系统开发模型。评价风险之后选择系统开发模型。(4)(4)计划计划评价开发工作，确定是否继续进行螺线的下一评价开发工作，确定是否继续进行螺线的下一个循环。如果确定要继续，则计划项目的下一个阶段的工个循环。如果确
33、定要继续，则计划项目的下一个阶段的工作。作。螺旋模型螺旋模型 螺旋模型的优点螺旋模型的优点 对可选方案和约束条件的强调有利于已有软件的对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重用，也有助于把软件质量作为软件开发的一个重要目标。重要目标。减少了过多测试或测试不足所带来的风险。减少了过多测试或测试不足所带来的风险。在螺旋模型中维护只是模型的另一个周期，因而在螺旋模型中维护只是模型的另一个周期，因而在维护和开发之间并没有本质区别。在维护和开发之间并没有本质区别。螺旋模型螺旋模型 螺旋模型的缺点螺旋模型的缺点 螺旋模型是风险驱动的，因此要求软件开发人员螺旋模
34、型是风险驱动的，因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知必须具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还以为一切正常。走向灾难时，开发人员可能还以为一切正常。喷泉模型喷泉模型 喷泉模型是典型的面喷泉模型是典型的面向对象生命周期模型。向对象生命周期模型。“喷泉喷泉”一词体现了一词体现了迭代和无间隙特性。迭代和无间隙特性。图中代表不同阶段的图中代表不同阶段的圆圈相互重叠，这明圆圈相互重叠，这明确表示两个活动之间确表示两个活动之间存在重叠。存在重叠。统一过程统一过程 由由Bo
35、ochBooch、JacobsonJacobson及及RumbaughRumbaugh提出，统一过程模型如图提出，统一过程模型如图所示。所示。统一过程统一过程 统一过程的工作流统一过程的工作流 在统一过程中，有在统一过程中，有6 6个核心工作流。个核心工作流。业务建模工作流业务建模工作流。用商业用例为商业过程建立文。用商业用例为商业过程建立文档。档。需求工作流需求工作流。目标是描述系统应该做什么，确保。目标是描述系统应该做什么，确保开发人员构建正确的系统。为此，需明确系统的开发人员构建正确的系统。为此，需明确系统的功能需求和非功能需求（约束）。功能需求和非功能需求（约束）。分析和设计工作流分析
36、和设计工作流。其目标是说明如何做。结果。其目标是说明如何做。结果是分析模型和设计模型。是分析模型和设计模型。统一过程统一过程 实现工作流实现工作流。用分层的方式组织代码的结构，用。用分层的方式组织代码的结构，用构件的形式来实现类，对构件进行单元测试，将构件的形式来实现类，对构件进行单元测试，将构件集成到可执行的系统中。构件集成到可执行的系统中。测试工作流测试工作流。验证对象之间的交互、是否所有的。验证对象之间的交互、是否所有的构件都集成了、是否正确实现了所有需求、查错构件都集成了、是否正确实现了所有需求、查错并改正。并改正。部署工作流部署工作流。制作软件的外部版本、软件打包、。制作软件的外部版
37、本、软件打包、分发、为用户提供帮助和支持。分发、为用户提供帮助和支持。统一过程统一过程 统一过程的阶段统一过程的阶段 统一过程有统一过程有4 4个阶段，分别是初始阶段、细化阶段、个阶段，分别是初始阶段、细化阶段、构造阶段和移交阶段。构造阶段和移交阶段。初始阶段初始阶段。初始阶段主要关注项目计划和风险评。初始阶段主要关注项目计划和风险评估，其目的是确定是否值得开发目标信息系统。估，其目的是确定是否值得开发目标信息系统。细化阶段细化阶段。细化阶段关心定义系统的总体框架，。细化阶段关心定义系统的总体框架，其目标是：细化初始需求（用况）、细化体系结构、其目标是：细化初始需求（用况）、细化体系结构、监控
38、风险并细化它们的优先级、细化业务案例以及监控风险并细化它们的优先级、细化业务案例以及制订项目管理计划。制订项目管理计划。统一过程统一过程 统一过程的阶段统一过程的阶段 构造阶段构造阶段。构造阶段是建立系统，构造信息系统。构造阶段是建立系统，构造信息系统的第的第1 1个具有操作质量的版本，以能够交付给客户个具有操作质量的版本，以能够交付给客户进行进行 测试的版本结束，有时称为测试版本。测试的版本结束，有时称为测试版本。移交阶段移交阶段。移交阶段包含。移交阶段包含 测试时期，以发布完测试时期，以发布完整的系统而终止，其目标是确保信息系统真正满整的系统而终止，其目标是确保信息系统真正满足客户的需求。
39、足客户的需求。1.6 软件工程知识体系及知识域 软件工程知识体软件工程知识体19941994年，美国年，美国Embry-RiddleEmbry-Riddle航空大学计算与数学航空大学计算与数学系系Thomas B.HilburnThomas B.Hilburn教授开始了教授开始了“软件工程知识软件工程知识体系指南体系指南”（Guide to Software Engineering Guide to Software Engineering Body of KnowledgeBody of Knowledge，SWEBOKSWEBOK）研究项目。）研究项目。20012001年年4 4月，发布月
40、，发布SWEBOK0.95SWEBOK0.95版。版。20042004年年6 6月，发布月，发布SWEBOK2004SWEBOK2004版。版。1.6 软件工程知识体系及知识域 软件工程知识体系指南的目标软件工程知识体系指南的目标(1)(1)促使软件工程本体知识成为世界范围的共识。促使软件工程本体知识成为世界范围的共识。(2)(2)澄清软件工程与其他相关学科，如与计算机科澄清软件工程与其他相关学科，如与计算机科学、项目管理、计算机工程以及计算机数学之间学、项目管理、计算机工程以及计算机数学之间的关系，并且确定软件工程学科的范围。的关系，并且确定软件工程学科的范围。(3)(3)反映软件工程学科内
41、容的特征。反映软件工程学科内容的特征。(4)(4)确定软件工程本体知识的各个专题。确定软件工程本体知识的各个专题。(5)(5)为相应的课程和职业资格认证材料的编写奠定为相应的课程和职业资格认证材料的编写奠定基础。基础。1.6 软件工程知识体系及知识域 软件工程知识体系指南的内容软件工程知识体系指南的内容 SWEBOKSWEBOK指南将软件工程知识体系划分为指南将软件工程知识体系划分为1010个知识个知识域（域（knowledge areasknowledge areas，KAKA），分为两类过程。），分为两类过程。一类是一类是开发与维护过程开发与维护过程，包括软件需求、软件设，包括软件需求、软
42、件设计、软件构造、软件测试和软件维护；计、软件构造、软件测试和软件维护；另一类是另一类是支持和组织过程支持和组织过程，包括软件配置管理、，包括软件配置管理、软件工程管理、软件工程过程、软件工程工具与软件工程管理、软件工程过程、软件工程工具与方法和软件质量。每个知识域还可进一步分解为方法和软件质量。每个知识域还可进一步分解为若干论题。若干论题。1.6 软件工程知识体系及知识域 软件工程知识体系指南的内容软件工程知识体系指南的内容1.6 软件工程知识体系及知识域 每个知识域又可分解为若干子知识域，如表所示。每个知识域又可分解为若干子知识域，如表所示。作业 习题习题 P18 1.11.71.1 1.
43、1 举出你所知道的软件应用的例子。举出你所知道的软件应用的例子。1.2 1.2 认为认为“软件就是程序，软件开发就是编程序。软件就是程序，软件开发就是编程序。”这种观这种观点是否正确？为什么？点是否正确？为什么？1.3 1.3 如果将软件开发比作高楼大厦的建造，可以将软件的设如果将软件开发比作高楼大厦的建造，可以将软件的设计比作什么？计比作什么？1.4 1.4 什么是软件危机？它有哪些典型表现？为什么会出现软什么是软件危机？它有哪些典型表现？为什么会出现软件危机？件危机？1.5 1.5 什么是软件工程？什么是软件工程？1.6 1.6 简述软件生存期由哪些主要的阶段组成，每一阶段的主简述软件生存期由哪些主要的阶段组成，每一阶段的主要任务是什么？要任务是什么？1.7 1.7 常见的软件生存期模型主要有哪些？每种模型的优缺点常见的软件生存期模型主要有哪些？每种模型的优缺点是什么？是什么？
