软件与软件工程介绍34383.pptx

《软件与软件工程介绍34383.pptx》由会员分享，可在线阅读，更多相关《软件与软件工程介绍34383.pptx（72页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第1章 软件与软件工程的概念软件的概念、特性和分类软件危机与软件工程系统工程的目标软件生存期软件生存期模型软件工程知识体系及知识域1.1 软件的概念、特性和分类软件的作用具有产品和产品生产载体的双重作用。(1)作为产品，软件显示了由计算机硬件体现的计算能力，扮演着信息转换的角色：产生、管理、查询、修改、显示或者传递各种不同的信息。(2)作为产品生产的载体，软件提供了计算机控制（操作系统）、信息通信（网络），以及应用程序开发和控制的基础平台（软件工具和环境）。1.1 软件的概念、特性和分类软件的概念 虽然软件对于现代的人并不陌生，但很多人对于软件的理解并不准确，“软件就是程序，软件开发就是编程序

2、”的这种错误观点仍然存在。什么是软件？1.1 软件的概念、特性和分类软件软件是计算机系统中与硬件相互依存的另一部分，是计算机系统中与硬件相互依存的另一部分，是计算机系统中与硬件相互依存的另一部分，是计算机系统中与硬件相互依存的另一部分，它是包括程序，数据及其相关文档的完整集合。它是包括程序，数据及其相关文档的完整集合。它是包括程序，数据及其相关文档的完整集合。它是包括程序，数据及其相关文档的完整集合。程序程序是按事先设计的功能和性能要求执行的指令序是按事先设计的功能和性能要求执行的指令序是按事先设计的功能和性能要求执行的指令序是按事先设计的功能和性能要求执行的指令序列。列。列。列。数据数据是使

3、程序能正常操纵信息的数据结构。是使程序能正常操纵信息的数据结构。是使程序能正常操纵信息的数据结构。是使程序能正常操纵信息的数据结构。文档文档是与程序开发，维护和使用有关的图文材料。是与程序开发，维护和使用有关的图文材料。是与程序开发，维护和使用有关的图文材料。是与程序开发，维护和使用有关的图文材料。1.1 软件的概念、特性和分类软件的特性(1)(1)形态特性形态特性:软件是无形的、不可见的逻辑实体。软件是无形的、不可见的逻辑实体。度量常规产品的几何尺寸、物理性质和化学成分度量常规产品的几何尺寸、物理性质和化学成分对它却是毫无意义的。对它却是毫无意义的。(2)(2)智能特性智能特性：软件是复杂的

4、智力产品，它的开发：软件是复杂的智力产品，它的开发凝聚了人们的大量脑力劳动，它本身也体现了知凝聚了人们的大量脑力劳动，它本身也体现了知识实践经验和人类的智慧，具有一定的智能。它识实践经验和人类的智慧，具有一定的智能。它可以帮助我们解决复杂的计算、分析、判断和决可以帮助我们解决复杂的计算、分析、判断和决策问题。策问题。(3)(3)开发特性开发特性:尽管已经有了一些工具（也是软件）尽管已经有了一些工具（也是软件）来辅助软件开发工作，但到目前为止尚未实现自来辅助软件开发工作，但到目前为止尚未实现自动化。软件开发中仍然包含了相当份量的个体劳动化。软件开发中仍然包含了相当份量的个体劳动，使得这一大规模知

5、识型工作充满了个人行为动，使得这一大规模知识型工作充满了个人行为和个人因素。和个人因素。(4)(4)质量特性质量特性：目前还无法得到完全没有缺陷的软：目前还无法得到完全没有缺陷的软件产品件产品 。1.1 软件的概念、特性和分类(5)(5)生产特性生产特性:与硬件或传统的制造业产品的生产与硬件或传统的制造业产品的生产完全不同，软件一旦设计开发出来，如果需要提完全不同，软件一旦设计开发出来，如果需要提供多个用户，它的复制十分简单，其成本也极为供多个用户，它的复制十分简单，其成本也极为有限有限 。(6)(6)管理特性管理特性：由于上述的几个特点，使得软件的：由于上述的几个特点，使得软件的开发管理显得

6、更为重要，也更为独特开发管理显得更为重要，也更为独特 。1.1 软件的概念、特性和分类(7)(7)环境特性环境特性:软件的开发和运行都离不开相关的计软件的开发和运行都离不开相关的计算机系统环境，包括支持它的开发和运行的相关算机系统环境，包括支持它的开发和运行的相关硬件和软件。软件对于计算机系统的环境有着不硬件和软件。软件对于计算机系统的环境有着不可摆脱的依赖性。可摆脱的依赖性。(8)(8)维护特性维护特性：软件投入使用以后需要进行维护，：软件投入使用以后需要进行维护，但这种维护与传统产业产品的维护概念有着很大但这种维护与传统产业产品的维护概念有着很大差别。差别。1.1 软件的概念、特性和分类(

7、9)(9)废弃特性废弃特性:与硬件不同，软件并不是由于被与硬件不同，软件并不是由于被“用用坏坏”而被废弃的而被废弃的 。(10)(10)应用特性应用特性：软件的应用极为广泛，如今它已渗：软件的应用极为广泛，如今它已渗入国民经济和国防的各个领域，现已成为信息产入国民经济和国防的各个领域，现已成为信息产业、先进制造业和现代服务业的核心，占据了无业、先进制造业和现代服务业的核心，占据了无可取代的地位。可取代的地位。1.1 软件的概念、特性和分类1.1 软件的概念、特性和分类软件的分类 按照软件的作用，一般可以将软件做如下分类。(1)系统软件 (2)应用软件 (3)支撑软件 (4)可复用软件 软件危机

8、暴发于上个世纪六十年代末。软件危机暴发于上个世纪六十年代末。主要表现为：软件的发展速度远远滞后于硬件的主要表现为：软件的发展速度远远滞后于硬件的发展速度，不能满足社会日益增长的软件需求。发展速度，不能满足社会日益增长的软件需求。软件开发周期长、成本高、质量差、维护困难。软件开发周期长、成本高、质量差、维护困难。1.2 软件危机与软件工程软件危机典型例子：美国典型例子：美国IBMIBM公司在公司在19631963年至年至19661966年开发的年开发的IBM 360IBM 360机的操作系统。机的操作系统。这个项目的负责人这个项目的负责人F.D.BrooksF.D.Brooks事后总结了他在组事

9、后总结了他在组织开发过程中的沉痛教训时说：织开发过程中的沉痛教训时说：正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深。最后无法逃脱灭顶的灾难，挣扎，陷得越深。最后无法逃脱灭顶的灾难，程序设程序设计工作正像这样一个泥潭，计工作正像这样一个泥潭，一批批程序员被迫在泥潭一批批程序员被迫在泥潭中拼命挣扎，中拼命挣扎，谁也没有料到竟会陷入这样的困境谁也没有料到竟会陷入这样的困境1.2 软件危机与软件工程具体来说，软件危机主要有以下一些典型表现具体来说，软件危机主要有以下一些典型表现:对软件开发成本和进度的估计常常很不准确。对软件开发成本和进度的

10、估计常常很不准确。用户对用户对“已完成的已完成的”软件系统不满意的现象经常发生。软件系统不满意的现象经常发生。软件产品的质量往往靠不住。软件产品的质量往往靠不住。软件常常是不可维护的。软件常常是不可维护的。软件通常没有适当的文档资料。软件通常没有适当的文档资料。软件成本在计算机系统总成本中所占的比例逐年上升。软件成本在计算机系统总成本中所占的比例逐年上升。软件开发生产率提高的速度，既跟不上硬件的发展速度，软件开发生产率提高的速度，既跟不上硬件的发展速度，也远远跟不上计算机应用迅速普及深入的趋势。也远远跟不上计算机应用迅速普及深入的趋势。1.2 软件危机与软件工程除了软件本身的特点，软件危机发生

11、的主要原因有：(1)缺乏软件开发的经验和有关软件开发数据的积累，使得开发工作的计划很难制定。(2)软件人员与用户的交流存在障碍，使得获取的需求不充分或存在错误。(3)软件开发过程不规范。如，没有真正了解用户的需求就开始编程序。(4)随着软件规模的增大，其复杂性往往会呈指数级升高。需要很多人分工协作，不仅涉及技术问题，更重要的是必须有科学严格的管理。(5)缺少有效的软件评测手段，提交用户的软件质量不能完全保证。1.2 软件危机与软件工程彻底消除“软件就是程序”的错误观念。充分认识到软件开发应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。推广和使用在实践中总结出来的开发软件的成

12、功技术、方法和工具。按工程化的原则和方法组织软件开发工作。如何摆脱软件危机如何摆脱软件危机?1.2 软件危机与软件工程1.2 软件危机与软件工程软件工程的概念为了克服软件危机，为了克服软件危机，1968年年10月在北大西洋公约月在北大西洋公约组织（组织（NATO）召开的计算机科学会议上，）召开的计算机科学会议上，Fritz Bauer首次提出首次提出“软件工程软件工程”的概念，试图将工程的概念，试图将工程化方法应用于软件开发。化方法应用于软件开发。在在NATO会议上，会议上，Fritz Bauer对软件工程的定义是：对软件工程的定义是：“软件工程就是为了经济地获得可靠的且能在实软件工程就是为了

13、经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善际机器上有效地运行的软件，而建立和使用完善的工程原理。的工程原理。”1993年年IEEE给出的定义：给出的定义：“软件工程是：软件工程是：把系统的、规范的、可度把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件；也就是把工程应用于软件；研究研究中提中提到的途径。到的途径。”。1.2 软件危机与软件工程软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发和维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好技术

14、结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。1.2 软件危机与软件工程1.3 软件工程的目标软件工程的目标是运用先进的软件开发技术和管理方法来提高软件的质量和生产率，也就是要以较短的周期、较低的成本生产出高质量的软件产品，并最终实现软件的工业化生产。1.3 软件工程的目标软件的质量特性：功能性、可靠性、可使用性、效率、可维护性和可移植性。功能性是指软件所实现的功能达到它的设计规范和满足用户需求的程度；可靠性是指在规定的时间和条件下，软件能够正常维持其工作的能力；可使用性是指为了使用该软件所需要的能力；效率是指在规定的条件下用软件实现某种功能所需要的计算机资源的有效性；可

15、维护性是指当环境改变或软件运行发生故障时，为了使其恢复正常运行所做努力的程度；可移植性是指软件从某一环境转移到另一环境时所做努力的程度。1.3 软件工程的目标质量目标之间的关系(1)关注大型软件的构造(2)中心课题是控制复杂性(3)软件经常变化(4)开发软件的效率非常重要(5)和谐地合作是开发软件的关键(6)软件必须有效地支持它的用户(7)在软件工程领域中是由一种文化背景的人替具有另一种文化背景的人创造产品软件工程的本质特性软件工程的本质特性(1)按软件生存周期分阶段制订计划并认真实施(2)坚持进行阶段评审(3)坚持严格的产品控制(4)使用现代软件开发技术(5)明确责任(6)用人少而精(7)不

16、断改进开发过程 软件工程的基本原理软件工程的基本原理1.4 软件生存期概念 软件也有一个孕育、诞生、成长、成熟和衰亡的生存过程，我们称这个过程为软件生命周期或软件生存期。软件生存期由软件定义、软件开发和运行维护3个时期组成，每个时期又可划分为若干个阶段。1.4 软件生存期软件定义时期 主要任务是解决“做什么”的问题，即确定工程的总目标和可行性；导出实现工程目标应使用的策略及系统必须完成的功能；估计完成工程需要的资源和成本；制订工程进度表。通常又分为3个阶段：问题定义、可行性研究和需求分析。1.4 软件生存期软件开发时期 主要任务是解决“如何做”的问题，即具体设计和实现在前一个时期定义的软件。由

17、概要设计、详细设计、编码和测试4个阶段组成。1.4 软件生存期软件运行维护时期 主要任务是使软件持久地满足用户的需要，通常有4类维护活动：(1)改正性维护，也就是诊断和改正在使用过程中发现的软件错误；(2)适应性维护，即修改软件以适应环境的变化；(3)完善性维护，即根据用户的要求改进或扩充软件，使它更完善；(4)预防性维护，即修改软件为将来的维护活动预先做准备。1.4 软件生存期开发过程中的典型文档 软件需求规格说明书：描述将要开发的软件做什么。项目计划：描述将要完成的任务及其顺序，并估计所需要的时间及工作量。软件测试计划：描述如何测试软件，使之确保软件应实现规定的功能，并达到预期的性能。软件

18、设计说明书：描述软件的结构，包括概要设计及详细设计。用户手册：描述如何使用软件。1.4 软件生存期各个阶段所要完成的基本任务(1)问题定义与可行性研究 本阶段要回答的关键问题是“到底要解决什么问题？在成本和时间的限制条件下能否解决问题？是否值得做？”(2)需求分析 本阶段要回答的关键问题是“目标系统应当做什么？”(3)软件设计 设计是软件工程的技术核心。本阶段要回答的关键问题是“如何实现目标系统？”1.4 软件生存期各个阶段所要完成的基本任务(4)程序编码和单元测试 本阶段要解决的问题是“正确地实现已做的设计”，即“如何编写正确的、可维护的程序代码？”(5)集成和系统测试 测试是控制软件质量的

19、重要手段，本阶段的主要任务是做集成测试和系统测试。(6)软件运行和维护 已交付的软件投入正式使用，便进入运行阶段。这一阶段可能持续若干年。软件在运行中可能由于多方面的原因，需要对它进行修改。1.5 软件生存期模型瀑布模型快速原型模型增量模型螺旋模型喷泉模型统一过程 瀑布模型瀑布模型在20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生命周期模型。传统的瀑布模型如图所示。瀑布模型瀑布模型瀑布模型的特点阶段间具有顺序性和依赖性。其中包含两重含义：必须等前一阶段的工作完成之后，才能开始后一阶段的工作；前一阶段的输出文档就是后一阶段的输入文档。瀑布模型瀑布模型瀑布模型的特点推迟实现的观点 瀑布模型在

20、编码之前设置了系统分析和系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想。瀑布模型瀑布模型瀑布模型的特点质量保证的观点 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。瀑布模型瀑布模型实际的瀑布模型实际的瀑布模型是带“反馈环”的，如图所示。图中实线箭头表示开发过程，虚线箭头表示维护过程。瀑布模型瀑布模型瀑布模型的优点可强迫开发人员采用规范化

21、的方法。严格地规定了每个阶段必须提交的文档。要求每个阶段交出的所有产品都必须是经过验证的。瀑布模型瀑布模型瀑布模型的缺点由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间有差异，就会发生这种情况。瀑布模型只适用于项目开始时需求已确定的情况。快速原型模型快速原型模型快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。快速原型模型如图所示。快速原型模型快速原型模型快速原型模型的优点(1)有助于满足用户的真实需求。(2)原型系统已经通过与用户的交互而得到验证，据此产生的规格

22、说明文档能够正确地描述用户需求。(3)软件产品的开发基本上是按线性顺序进行。(4)因为规格说明文档正确地描述了用户需求，因此，在开发过程的后续阶段不会因为发现规格说明文档的错误而进行较大的返工。快速原型模型快速原型模型快速原型模型的优点(5)开发人员通过建立原型系统已经学到了许多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。(6)快速原型的突出特点是“快速”。开发人员应该尽可能快地建造出原型系统，以加速软件开发过程，节约软件开发成本。原型的用途是获知用户的真正需求，一旦需求确定了，原型可以抛弃，当然也可以在原型的基础上进行开发。增

23、量模型增量模型增量模型也称为渐增模型，是Mills等于1980年提出来的。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。增量模型增量模型增量模型如图所示。增量模型增量模型增量模型的优点(1)能在较短时间内向用户提交可完成一些有用的工作产品，即从第1个构件交付之日起，用户就能做一些有用的工作。(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给用户组织带来的冲击。(3)项目失败的风险较低，虽然在某些增量构件中可能遇到一些问题，但其他增量构件将能够成功地交付给客户。

24、(4)优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来。因此，最重要的系统服务将接受最多的测试。增量模型增量模型增量构件开发 每个增量构件应当实现某种系统功能，因此增量构件的开发可以采用瀑布模型的方式，如图所示。增量模型增量模型采用增量模型需注意的问题(1)在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。(2)软件体系结构必须是开放的，即向现有产品中加入新构件的过程必须简单、方便。因此，采用增量模型比采用瀑布模型和快速原型模型更需要精心的设计。螺旋模型螺旋模型螺旋模型最初是Boehm于1988年提出来的。该模型将瀑布模型与快速原型模型结合起来，并且加入

25、两种模型均忽略了的风险分析。螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。螺旋模型螺旋模型理解这种模型的一个简便方法，是把它看做在每个阶段之前都增加了风险分析过程的快速原型模型。螺旋模型螺旋模型完整的螺旋模型 螺旋模型螺旋模型完整的螺旋模型 在螺旋模型中，软件过程表示成一个螺线，而不是像以往的模型那样表示为一个具有回溯的活动序列。在螺线上的每一个循环表示过程的一个阶段。每个阶段开始时的任务是确定该阶段的目标、为完成这些目标选择方案及设定这些方案的约束条件。接下来的任务是，从风险角度分析上一步的工作结果，努力排除各种潜在的风险，通常用建造原型的方法来排除风险。如果成功地排除了所有风险，

26、则启动下一步开发步骤，在这个步骤的工作过程相当于纯粹的瀑布模型。最后是评价该阶段的工作成果并计划下一个阶段的工作。螺旋模型螺旋模型螺旋模型的4项活动 螺线上的每一个循环可划分为4个象限，分别表达了4个方面的活动。(1)目标设定定义在该阶段的目标，弄清对过程和产品的限制条件，制订详细的管理计划，识别项目风险，可能还要计划与这些风险有关的对策。(2)风险估计与弱化针对每一个风险进行详细分析，设想弱化风险的步骤。(3)开发与验证评价风险之后选择系统开发模型。(4)计划评价开发工作，确定是否继续进行螺线的下一个循环。如果确定要继续，则计划项目的下一个阶段的工作。螺旋模型螺旋模型螺旋模型的优点 对可选方

27、案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。减少了过多测试或测试不足所带来的风险。在螺旋模型中维护只是模型的另一个周期，因而在维护和开发之间并没有本质区别。螺旋模型螺旋模型螺旋模型的缺点 螺旋模型是风险驱动的，因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还以为一切正常。喷泉模型喷泉模型喷泉模型是典型的面向对象生命周期模型。“喷泉”一词体现了迭代和无间隙特性。图中代表不同阶段的圆圈相互重叠，这明确表示两个活动之间存在重叠。基于构件的开发模型基于构件的开发模型基于构件的软件

28、工程（component-based software engineering，CBSE）是强调使用可复用的软件“构件”来设计和构造基于计算机的系统的过程。基于构件的开发模型基于构件的开发模型Clements对CBSE给出了如下描述。CBSE正在改变大型软件系统的开发方式。CBSE体现了Frod Brooks和其他人支持的“购买，而非构造”的思想。就如同早期的子程序将程序员从考虑编程细节中解脱出来一样，CBSE将考虑的重点从编码转移到组装软件系统。考虑的焦点是“集成”，而不再是“实现”。这样做的基础是假定在很多大型软件系统中存在足够多的共性，使得开发可复用的构件来满足这些共性是可行的。基于构件

29、的开发模型基于构件的开发模型当软件团队使用传统的需求获取技术确定了待开发软件的系统需求时，该过程开始。体系结构设计完成后，并不立即进行详细设计任务，而是针对每一系统需求考虑以下问题:(1)现有的商品化构件（commercial off-the-shelf，COTS）是否能够实现该需求？(2)内部开发的可复用构件是否能够实现该需求？(3)可用构件的接口与待构造系统的体系结构是否相容？基于构件的开发模型基于构件的开发模型基于构件的开发模型如下图。基于构件的开发模型基于构件的开发模型开发步骤 不考虑构件的开发技术，基于构件的开发模型由以下步骤组成：(1)对于该问题领域的基于构件的可用产品进行研究和评

30、估。(2)考虑构件集成的问题。(3)设计软件架构以容纳这些构件。(4)将构件集成到架构中。(5)进行充分的测试以保证功能正常。基于构件的开发模型基于构件的开发模型典型的构件模型 (1)OMG/CORBA。对象管理组织发布了公共对象请求代理体系结构（OMG/CORBA），一个对象请求代理提供了多种服务，使得可复用构件（对象）可以与其他构件通信。(2)Microsoft COM/DCOM/.NET。微软公司开发了构件对象模型（COM），此模型提供了构件的规格说明,在Windows操作系统，一个应用系统中可以使用不同厂商生产的构件。(3)Sun JavaBean构件。JavaBean构件系统是一个可

31、移植的、平台独立的、使用Java程序设计语言开发的CBSE基础设施。统一过程统一过程由Booch、Jacobson及Rumbaugh提出，统一过程模型如图所示。统一过程统一过程统一过程的工作流 在统一过程中，有6个核心工作流。业务建模工作流。用商业用例为商业过程建立文档。需求工作流。目标是描述系统应该做什么，确保开发人员构建正确的系统。为此，需明确系统的功能需求和非功能需求（约束）。分析和设计工作流。其目标是说明如何做。结果是分析模型和设计模型。统一过程统一过程 实现工作流。用分层的方式组织代码的结构，用构件的形式来实现类，对构件进行单元测试，将构件集成到可执行的系统中。测试工作流。验证对象之

32、间的交互、是否所有的构件都集成了、是否正确实现了所有需求、查错并改正。部署工作流。制作软件的外部版本、软件打包、分发、为用户提供帮助和支持。统一过程统一过程统一过程的阶段 统一过程有4个阶段，分别是初始阶段、细化阶段、构造阶段和移交阶段。初始阶段。初始阶段主要关注项目计划和风险评估，其目的是确定是否值得开发目标信息系统。细化阶段。细化阶段关心定义系统的总体框架，其目标是：细化初始需求（用况）、细化体系结构、监控风险并细化它们的优先级、细化业务案例以及制订项目管理计划。统一过程统一过程统一过程的阶段 构造阶段。构造阶段是建立系统，构造信息系统的第1个具有操作质量的版本，以能够交付给客户进行测试的

33、版本结束，有时称为测试版本。移交阶段。移交阶段包含测试时期，以发布完整的系统而终止，其目标是确保信息系统真正满足客户的需求。1.6 软件工程知识体系及知识域软件工程教育(3个历史时期)(1)1978年以前：软件工程教育以计算机专业的一门孤立的课程形式存在。(2)19781988年期间：早期的研究生学位教育，开始建立软件工程专业的研究生学位教育项目。(3)1988年以后：快速发展的研究生学科教育，使软件工程的理论快速发展，其中，卡内基梅隆大学软件工程研究所（SEI）的影响不可忽视。1.6 软件工程知识体系及知识域软件工程知识体软件工程已从计算机科学与技术中脱离出来，逐渐形成了一门独立的学科。对其

34、知识体系的研究从20世纪90年代初就开始了。标志是美国Embry-Riddle航空大学计算与数学系Thomas B.Hilburn教授的“软件工程知识体系指南”（Guide to Software Engineering Body of Knowledge，SWEBOK）研究项目。1.6 软件工程知识体系及知识域软件工程知识体系指南的目标(1)促使软件工程本体知识成为世界范围的共识。(2)澄清软件工程与其他相关学科，如与计算机科学、项目管理、计算机工程以及计算机数学之间的关系，并且确定软件工程学科的范围。(3)反映软件工程学科内容的特征。(4)确定软件工程本体知识的各个专题。(5)为相应的课程和职业资格认证材料的编写奠定基础。1.6 软件工程知识体系及知识域软件工程知识体系指南的内容 SWEBOK指南将软件工程知识体系划分为10个知识域（knowledge areas，KA），分为两类过程。一类是开发与维护过程，包括软件需求、软件设计、软件构造、软件测试和软件维护；另一类是支持和组织过程，包括软件配置管理、软件工程管理、软件工程过程、软件工程工具与方法和软件质量。每个知识域还可进一步分解为若干论题。1.6 软件工程知识体系及知识域软件工程知识体系指南的内容1.6 软件工程知识体系及知识域每个知识域又可分解为若干子知识域，如表所示。