中国系统分析员 www.csai.cn 软件工程知识体系指南(2004版) 蒋遂平翻译 蒋遂平，计算机应用专业博士，国家系统分析员，CSAI专业顾问。曾从事过数据库、 虚拟现实和人脸识别等方面的研究工作，先后参与和主持了多个系统的软件开发，主要感兴 趣的领域包括软件工程，图象处理和数据库。 Guide to the Software Engineering Body of Knowledge 2004 Version 软件工程知识体系指南是IEEE计算机学会(IEEE Computer Society)职业实践委员会 (Professional Practices Committee)主持的一个项目。SWEBOK是IEEE的官方服务标记。 http://www.swebok.org 目录 第1章引言 第2章软件需求 第3章软件设计 第4章软件构造 第5章软件测试 第6章软件维护 第7章软件配置管理 第8章软件工程管理 第9章软件工程过程 第10章软件工程工具与方法 第11章软件质量 第12章相关学科知识域 附录A2004年版软件工程知识体系指南的知识域描述规范 附录B指南演化过程 附录C IEEE和ISO软件工程标准到SWEBOK知识域的分配 附录D根据B1oom分类学的主题分类 LL711010111711110111711011111111111777117171111111117717710177
软件工程知识体系指南（2004 版） 蒋遂平 翻译 蒋遂平，计算机应用专业博士，国家系统分析员，CSAI 专业顾问。曾从事过数据库、 虚拟现实和人脸识别等方面的研究工作，先后参与和主持了多个系统的软件开发，主要感兴 趣的领域包括软件工程，图象处理和数据库。 Guide to the Software Engineering Body of Knowledge 2004 Version 软件工程知识体系指南是IEEE计算机学会（IEEE Computer Society）职业实践委员会 （Professional Practices Committee）主持的一个项目。®SWEBOK是IEEE的官方服务标记。 http://www.swebok.org 目录 第1章 引言 第2章 软件需求 第3章 软件设计 第4章 软件构造 第5章 软件测试 第6章 软件维护 第7章 软件配置管理 第8章 软件工程管理 第9章 软件工程过程 第10章 软件工程工具与方法 第11章 软件质量 第12章 相关学科知识域 附录A 2004年版软件工程知识体系指南的知识域描述规范 附录B 指南演化过程 附录C IEEE和ISO软件工程标准到SWEBOK知识域的分配 附录D 根据Bloom分类学的主题分类 ///////////////////////////////////////////////////////////////////
第一章指南简介 尽管全世界有数百万软件开发人员，软件在我们的社会中无处不在，软件工程在最近才 达到了合理的工程学科和被认可的职业的状态。 一个职业在核心知识体系上达成一致，是所有学科的关键里程碑，EEE计算机学会认为 这是软件工程向职业状态演化的关键。本指南是在职业实践委员会的主持赞助下编写成的， 它是一个被设计为达到这个一致的跨越数年的项目的一部分。 什么是“软件工程”？ IEEE计算机学会将“软件工程”定义为：“(1)应用系统化的、学科化的、定量的方 法，来开发、运行和维护软件，即，将工程应用到软件。(2)对(1)中各种方法的研究”。 (参见：IEEE Standard Glossary of Software Engineering Terminology。IEEE,Piscataway, NJ std610.12-1990,1990) 什么是被认可的职业？ 软件工程要成为合理的工程学科和一个被认可的职业，在一个核心知识体系上达成一致 就非常重要。Strr在定义什么将被认为是一个合理的学科和一个被认可的职业时，清楚地 展示了这点。他在获得普利策奖的关于美国医学职业历史的书中，写道： “专业人员威信的合法化涉及3个不同的需要：首先，专业人员的知识和能力能被其同 行所确认：第二，这些被一致确认的知识依靠理性的、科学的基础，第三，专业人员的判断 和建议要面向真实的价值，例如健康。这些合法性的各个方面对应于体现在术语“职业”上 的各类属性：学院的、认知的和道德的。（参见：P.Starr,The Social Transformation of American Medicine:Basic Books,1982.pl5). 什么是一个职业的特征？ Gary Ford和Norman Gibbs研究了几个被认可的职业，包括医学、法律、工程和会计等 (参见：G Ford and N E Gibbs,“A Mature Profession of Software Engineering,” Software Engineering Institute,Carnegie Mellon University,Pittsburgh, Pennsylvania,Technical CMU/SEI-96-TR-004,January1996)。他们的结论是，一个工 程职业由下列几个特征刻画：(1)由团体通过认证而确认的课程表的初始职业教育：(2) 通过自愿认证或强制许可的适应实践的注册：(3)专门的技术培养和继续职业教育：(4) 有职业团体的公共支持：(5)承诺遵从以伦理准则形式形成的规范。 本指南包括了这些成分的前面3个。清晰地指出知识体系是发展一个职业关键的一步， 因为它代表了对于软件工程专业人员应该知道什么的一个广泛的一致意见。没有这样的一 致，就不能确认任何职业许可的考试，就不能为专业人员参与考试准备课程表，也就不能形 成一个认证一个课程表的准则。达成一致也是一个组织中采纳发展连贯技能和继续职业教育 程序的前提。 什么是SWEBOK项目的目标？ 不应当将指南与知识体系本身混淆，知识体系己经存在与发表的文献中，指南的目的是 描述知识体系的哪些部分己经被普遍接受，将这些部分组织起来，提供一个使用它们的主题。 对于“普遍接受”包含的附加信息可以在下面或附录A中找到。 建立软件工程知识体系(SWEB0K)指南有下面5个目的：(1)促进世界范围内对软件工 程的一致观点：(2)阐明软件工程相对其它学科（如计算机科学、项目管理、计算机工程
第一章 指南简介 尽管全世界有数百万软件开发人员，软件在我们的社会中无处不在，软件工程在最近才 达到了合理的工程学科和被认可的职业的状态。 一个职业在核心知识体系上达成一致，是所有学科的关键里程碑，IEEE计算机学会认为 这是软件工程向职业状态演化的关键。本指南是在职业实践委员会的主持赞助下编写成的， 它是一个被设计为达到这个一致的跨越数年的项目的一部分。 什么是“软件工程”？ IEEE计算机学会将“软件工程”定义为：“（1）应用系统化的、学科化的、定量的方 法，来开发、运行和维护软件，即，将工程应用到软件。（2）对（1）中各种方法的研究”。 （参见：IEEE Standard Glossary of Software Engineering Terminology。IEEE, Piscataway, NJ std 610.12-1990, 1990） 什么是被认可的职业？ 软件工程要成为合理的工程学科和一个被认可的职业，在一个核心知识体系上达成一致 就非常重要。Starr在定义什么将被认为是一个合理的学科和一个被认可的职业时，清楚地 展示了这点。他在获得普利策奖的关于美国医学职业历史的书中，写道： “专业人员威信的合法化涉及3个不同的需要：首先，专业人员的知识和能力能被其同 行所确认；第二，这些被一致确认的知识依靠理性的、科学的基础，第三，专业人员的判断 和建议要面向真实的价值，例如健康。这些合法性的各个方面对应于体现在术语“职业”上 的各类属性：学院的、认知的和道德的。（参见：P. Starr, The Social Transformation of American Medicine: Basic Books, 1982. p15）。 什么是一个职业的特征？ Gary Ford和Norman Gibbs研究了几个被认可的职业，包括医学、法律、工程和会计等 （参见：G Ford and N E Gibbs, “A Mature Profession of Software Engineering,” Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, Technical CMU/SEI-96-TR-004, January 1996）。他们的结论是，一个工 程职业由下列几个特征刻画：（1）由团体通过认证而确认的课程表的初始职业教育；（2） 通过自愿认证或强制许可的适应实践的注册；（3）专门的技术培养和继续职业教育；（4） 有职业团体的公共支持；（5）承诺遵从以伦理准则形式形成的规范。 本指南包括了这些成分的前面3个。清晰地指出知识体系是发展一个职业关键的一步， 因为它代表了对于软件工程专业人员应该知道什么的一个广泛的一致意见。没有这样的一 致，就不能确认任何职业许可的考试，就不能为专业人员参与考试准备课程表，也就不能形 成一个认证一个课程表的准则。达成一致也是一个组织中采纳发展连贯技能和继续职业教育 程序的前提。 什么是SWEBOK项目的目标？ 不应当将指南与知识体系本身混淆，知识体系已经存在与发表的文献中，指南的目的是 描述知识体系的哪些部分已经被普遍接受，将这些部分组织起来，提供一个使用它们的主题。 对于“普遍接受”包含的附加信息可以在下面或附录A中找到。 建立软件工程知识体系（SWEBOK）指南有下面5个目的：（1）促进世界范围内对软件工 程的一致观点；（2）阐明软件工程相对其它学科（如计算机科学、项目管理、计算机工程
和数学等)的位置，并确立它们的分界：(3)刻画软件工程学科的内容：(4)提供使用知 识体系的主题：(5)为开发课程表和个人认证与许可材料，提供一个基础。 第一个目标，促进世界范围内对软件工程的一致观点，由指南的开发过程支持，来自42 个国家的大约500名评审人员参与了石人阶段(1998年一2001年)，产生了试用版本，来自 21个国家的120多位评审人员参与了铁人阶段(2003年)，产生了2004年版本。关于指南开 发过程的更多信息可以在前言看到，或者在wwW.swebok.org网站上看到。我们与涉及软件 工程的职业和学术团体、公共机构等进行了接触，向它们告知了本项目，邀请它们参与评审 过程。我们从北美、太平洋周边地区和欧洲，招募了指南的副编辑，在多个国际会议场合， 做了本项目的演示报告，在以后，我们还安排了一些关于本项目的报告。 第二个目标，为软件工程确立边界，激发了本指南的基本组织。被认为是本学科的材料 按照表1，组织为l0个知识域(Knowledge Areas,KA),本指南对每个知识域分别用一章的 篇幅来描述。 表1：SWEBOK知识域 软件需求 Software Requirements 软件设计 Software Design 软件构造 Software Construction 软件测试 Software Testing 软件维护 Software Maintenance 软件配置管理 Software Configuration Management 软件工程管理 Software Engineering Management 软件工程过程 Software Engineering Process 软件工程工具和方法 Software Engineering Tools and Methods 软件质量 Software Quality 在建立边界时，识别哪些学科与软件工程共享边界并有公共的交集，非常重要。最后， 本指南识别出8个相关的学科，如表2所示（参见第12章，软件工程相关学科）。当然，软件 工程具有来自这些学科的知识材料（知识域将参考它们），但是，SWEB0K指南的目标不是刻 画相关学科的知识，而是刻画什么知识被认为对软件工程特别有用。 表2相关学科 计算机工程 Computer Engineering 计算机科学 Computer Science 管理 Management 数学 Mathematics 项目管理 Project Management 质量管理 Quality Management 软件人类工程学 Software Ergonomics 系统工程 Systems Engineering 层次结构组织 知识域描述或章节Z的组织支持项目的第3个目标-一一刻画软件工程的内容。项目编辑组 给各个副编辑提供的关于知识域描述的内容的详细规格说明，可以在附录A中找到。 本指南采用层次组织，将每个知识域分解为具有可识别标签的主题的集合。两级或三级
和数学等）的位置，并确立它们的分界；（3）刻画软件工程学科的内容；（4）提供使用知 识体系的主题；（5）为开发课程表和个人认证与许可材料，提供一个基础。 第一个目标，促进世界范围内对软件工程的一致观点，由指南的开发过程支持，来自42 个国家的大约500名评审人员参与了石人阶段（1998年—2001年），产生了试用版本，来自 21个国家的120多位评审人员参与了铁人阶段（2003年），产生了2004年版本。关于指南开 发过程的更多信息可以在前言看到，或者在www.swebok.org 网站上看到。我们与涉及软件 工程的职业和学术团体、公共机构等进行了接触，向它们告知了本项目，邀请它们参与评审 过程。我们从北美、太平洋周边地区和欧洲，招募了指南的副编辑，在多个国际会议场合， 做了本项目的演示报告，在以后，我们还安排了一些关于本项目的报告。 第二个目标，为软件工程确立边界，激发了本指南的基本组织。被认为是本学科的材料 按照表1，组织为10个知识域（Knowledge Areas，KA），本指南对每个知识域分别用一章的 篇幅来描述。 表1：SWEBOK知识域 软件需求 Software Requirements 软件设计 Software Design 软件构造 Software Construction 软件测试 Software Testing 软件维护 Software Maintenance 软件配置管理 Software Configuration Management 软件工程管理 Software Engineering Management 软件工程过程 Software Engineering Process 软件工程工具和方法 Software Engineering Tools and Methods 软件质量 Software Quality 在建立边界时，识别哪些学科与软件工程共享边界并有公共的交集，非常重要。最后， 本指南识别出8个相关的学科，如表2所示（参见第12章，软件工程相关学科）。当然，软件 工程具有来自这些学科的知识材料（知识域将参考它们），但是，SWEBOK指南的目标不是刻 画相关学科的知识，而是刻画什么知识被认为对软件工程特别有用。 表2 相关学科 计算机工程 Computer Engineering 计算机科学 Computer Science 管理 Management 数学 Mathematics 项目管理 Project Management 质量管理 Quality Management 软件人类工程学 Software Ergonomics 系统工程 Systems Engineering 层次结构组织 知识域描述或章节Z的组织支持项目的第3个目标----刻画软件工程的内容。项目编辑组 给各个副编辑提供的关于知识域描述的内容的详细规格说明，可以在附录A中找到。 本指南采用层次组织，将每个知识域分解为具有可识别标签的主题的集合。两级或三级
的结构分解，为找到感兴趣的主题提供了合理的方法。指南处理主题的方式与主流的思想学 派的结构分解兼容，也与工业界和软件工程文献和标准的结构分解兼容。没有为主题的结构 分解假设特定的应用领域、商业使用、管理哲学、开发方法等。每个主题的描述程度仅仅为 主题的普遍接受特性需要的，并能让读者容易找到参考文献。总之，知识体系可以在参考材 料中，而不是在指南中找到。 参考材料和矩阵 项目的第4个目标是提供按主题使用知识，本指南为每个知识域标明了参考材料，包括 书记章节、论文和其它被认可的权威信息来源。每个知识域的描述也包括一个矩阵，将参考 材料与主题联系起来。引用的文献的总量适合于大学本科毕业、具有4年工作经验的人员掌 握。 在本版指南中，为所有知识域都分配了约500页的参考文献，这是对副编辑的规格说明。 有人指出，一些知识域（如软件设计）需要更多的参考文献。本指南的以后版本将考虑这一 点。 应该指出，指南并不打算在引用时包罗万象，没有包括很多适当的优秀材料，选择材料 部分或主要是由于它覆盖了需要的主题。 处理的深度 从一开始，指南的深度问题就有了。项目组采纳了一个方法，以支持项目的第5个目标： 为开发课程表、认证和许可提供一个基础。编辑组使用“普遍接受”的知识的准则，与高级 研究知识（根据成熟性）和专门知识（基于应用的普遍性）进行区分，如图1所示。这个定 义来自项目管理协会：“普遍接受的知识在大多数时间应用于大多数项目，广泛的一致意见 确认其价值和效力”。（参见：A Guide to the Project Management Body of Knowledge, 2000 Edition,Project Management Institute,Newport Square,PA.www.pmi.org. 但是，术语“普遍接受”并不意味着，指定的知识应该一律地应用于所有软件工程任务 (每个项目需要确定需要的知识)，但它意味着，有能力的软件工程师，为了胜任潜在的应 用，应该具有这些知识。更确切地说，普遍接受的知识应该包括在软件工程师的许可考试的 学习材料中，本这是本科毕业并工作4年后应该参加的考试。尽管这个准则是针对美国风格 的教育的，并不适合于其它国家，但我们认为它很有用。但是，普遍接受的知识的两个定义 应该被视为互补的。 专门的 普遍接受的 许多组织推荐的己经建立的 仅用于某些 传统实践 特定类型软 高级的研究性的 件的实践 被某些组织测试和使用的新 的实践、研究组织正在发展 和测试的概念 图1知识的分类 与本书格式有关的局限
的结构分解，为找到感兴趣的主题提供了合理的方法。指南处理主题的方式与主流的思想学 派的结构分解兼容，也与工业界和软件工程文献和标准的结构分解兼容。没有为主题的结构 分解假设特定的应用领域、商业使用、管理哲学、开发方法等。每个主题的描述程度仅仅为 主题的普遍接受特性需要的，并能让读者容易找到参考文献。总之，知识体系可以在参考材 料中，而不是在指南中找到。 参考材料和矩阵 项目的第4个目标是提供按主题使用知识，本指南为每个知识域标明了参考材料，包括 书记章节、论文和其它被认可的权威信息来源。每个知识域的描述也包括一个矩阵，将参考 材料与主题联系起来。引用的文献的总量适合于大学本科毕业、具有4年工作经验的人员掌 握。 在本版指南中，为所有知识域都分配了约500页的参考文献，这是对副编辑的规格说明。 有人指出，一些知识域（如软件设计）需要更多的参考文献。本指南的以后版本将考虑这一 点。 应该指出，指南并不打算在引用时包罗万象，没有包括很多适当的优秀材料，选择材料 部分或主要是由于它覆盖了需要的主题。 处理的深度 从一开始，指南的深度问题就有了。项目组采纳了一个方法，以支持项目的第5个目标： 为开发课程表、认证和许可提供一个基础。编辑组使用“普遍接受”的知识的准则，与高级 研究知识（根据成熟性）和专门知识（基于应用的普遍性）进行区分，如图1所示。这个定 义来自项目管理协会：“普遍接受的知识在大多数时间应用于大多数项目，广泛的一致意见 确认其价值和效力”。（参见：A Guide to the Project Management Body of Knowledge, 2000 Edition, Project Management Institute, Newport Square, PA. www.pmi.org.） 但是，术语“普遍接受”并不意味着，指定的知识应该一律地应用于所有软件工程任务 （每个项目需要确定需要的知识），但它意味着，有能力的软件工程师，为了胜任潜在的应 用，应该具有这些知识。更确切地说，普遍接受的知识应该包括在软件工程师的许可考试的 学习材料中，本这是本科毕业并工作4年后应该参加的考试。尽管这个准则是针对美国风格 的教育的，并不适合于其它国家，但我们认为它很有用。但是，普遍接受的知识的两个定义 应该被视为互补的。 专门的 仅用于某些 特定类型软 件的实践 普遍接受的 许多组织推荐的已经建立的 传统实践 高级的研究性的 被某些组织测试和使用的新 的实践、研究组织正在发展 和测试的概念 图 1 知识的分类 与本书格式有关的局限
本版本采用的书记格式有其局限。如果采用超文本结构，内容的本质将会更好，因为主 题可以相互链接，而不是按顺序排列。 有时，知识域之间、子知识域之间等的边界多少有些武断。没有过多强调这些边界的重 要性，我们尽可能地在相关或有用的地方，使用指示器和链接。 知识域之间的链接并不是输入/输出类型，知识域是对一个人应该拥有的与知识域有关 的软件工程知识的观点。知识域内的学科结构分解，以及描述知识域的顺序安排，都没有吸 收任何特定的方法和模型。指南中适当的知识域中描述了一些方法，指南本身并不是任何一 种方法。 知识域 图2和图3从总体上描述了11章，以及各章中包括的主题。首先按传统的瀑布生命周期顺 序描述前5个知识域，但是，这并不表示指南采纳或鼓励瀑布方法，或任何其它模型。随后 按字母顺序描述各个知识域，最后一章描述相关的学科。这相当于它们出现在本指南中的顺 序。 软件工程知识体系(SWEB0K)指南2004年版 软件需求 软件设计 软件构造 软件测试 软件维护 ◆软件需求基础 ◆软件设计基础 ◆软件构造基础 ◆软件测试基础 ◆软件维护基础 ◆需求过程 ◆软件设计 ◆管理构造 测试级别 ◆软件维护的 ◆需求获取 关键问题 ◆实际考虑 ◆测试技术 关键问题 需求分析 ◆软件结构与 需求分析 ◆维护过程 体系结构 ◆需求规格说明 ◆与测试相关 ◆维护技术 软件设计质量 ◆需求确认 的分析与评价 的度量 ◆实际考虑 ◆软件设计符号 测试过程 ◆软件设计的 策略与方法 (a) (b) (c) (d) (e) 图2前5个知识域
本版本采用的书记格式有其局限。如果采用超文本结构，内容的本质将会更好，因为主 题可以相互链接，而不是按顺序排列。 有时，知识域之间、子知识域之间等的边界多少有些武断。没有过多强调这些边界的重 要性，我们尽可能地在相关或有用的地方，使用指示器和链接。 知识域之间的链接并不是输入/输出类型，知识域是对一个人应该拥有的与知识域有关 的软件工程知识的观点。知识域内的学科结构分解，以及描述知识域的顺序安排，都没有吸 收任何特定的方法和模型。指南中适当的知识域中描述了一些方法，指南本身并不是任何一 种方法。 知识域 图2和图3从总体上描述了11章，以及各章中包括的主题。首先按传统的瀑布生命周期顺 序描述前5个知识域，但是，这并不表示指南采纳或鼓励瀑布方法，或任何其它模型。随后 按字母顺序描述各个知识域，最后一章描述相关的学科。这相当于它们出现在本指南中的顺 序。 软件工程知识体系（SWEBOK）指南 2004 年版 软件需求 软件设计 软件构造 软件测试 软件维护 软件需求基础 需求获取 需求分析 需求规格说明 需求确认 实际考虑 需求过程 软件设计基础 软件结构与 体系结构 软件设计质量 的分析与评价 软件设计符号 软件设计 关键问题 软件构造基础 实际考虑 管理构造 软件测试基础 测试技术 需求分析 与测试相关 的度量 测试过程 测试级别 软件维护基础 维护过程 维护技术 软件维护的 关键问题 软件设计的 策略与方法 图 2 前 5 个知识域 （a） （b） （c） （d） （e）
软件工程知识体系(SWEB0K)指南2004年版 软件配置 软件工程 软件工程 软件工程 软件质量 相关学科 管理 管理 过程 工具与方法 知识域 ◆软件配置 ◆启动和 ◆过程实施 软件工具 ◆软件质量 →计算机工程 过程管理 范围定义 与改变 广软件需求工具 基础 ◆计算机科学 →软件配置 ◆软件项目 ◆过程定义 计划 广软件设计工具 ◆软件质量 中管理 标识 中过程评定 过程 ◆软件配置 ◆软件项目 软件构造工具 →实际考忠 中数学 控制 实施 ◆过程和 产品度量 广软件测试工具 项目管理 ◆软件配置 中评审与 中软件维护工具 ◆质量管理 状态簿记 评价 广软件配置管理工具 ◆软件人类 ◆软件配置 中关闭 中软件工程过程工具 工程学 审计 ◆软件工程 ◆系统工程 软件发布 代软件质量工具 度量 ◆管理和交付 +其它工具问愿 ◆软件工程方法 中启发式方法 P形式化方法 中原型方法 (f) (g) (h) (i) (j) (k) 图3后6个知识域 知识域描述结构 知识域描述的结构如下所述： 在简介中，给出知识域的简要定义、其范围的总体视图、与其它知识域的关系。 主题的结构分解组成每个知识域描述的核心，它描述了将知识域分解为子域、主题和子 主题。对于每个主题或子主题，给出简要描述，然后是一篇或多篇参考文献。 选择一个参考材料主要是因为认为它构成了与主题相关的知识的最佳表述，并考虑了对 选择参考文献的限制（见前）。我们使用一个矩阵来联系主题和参考材料。 知识域描述的最后一部分是推荐的参考文献列表。每个知识域的附录A为希望了解知识 域主题更多内容的读者，列出了深入读物，附录B列出与知识域最相关的标准。注意，方括 号[门中的引用表示推荐的参考文献，圆括号()中的引用表示对于编写或验证文本有用的参 考文献，前者可以在对应的知识域章节中找到，后者可以在知识域的附录A中找到。 最后给出了知识域描述的简要总结和附录
软件质量 过程 软件工程知识体系（SWEBOK）指南 2004 年版 软件配置 管理 软件工程 软件质量 工具与方法 软件工程 过程 软件工程 管理 软件配置 过程管理 软件项目 计划 软件需求工具 过程和 产品度量 实际考虑 软件发布 管理和交付 软件配置 标识 启动和 范围定义 评审与 评价 软件工程 度量 关闭 软件项目 实施 过程实施 与改变 过程评定 过程定义 软件工具 项目管理 系统工程 软件人类 工程学 质量管理 软件质量 基础 计算机工程 管理 数学 计算机科学 软件工程方法 图 3 后 6 个知识域 （f） （g） （h） （i） （j） 相关学科 知识域 软件配置 控制 软件配置 审计 软件配置 状态簿记 软件设计工具 软件构造工具 软件测试工具 软件维护工具 软件配置管理工具 软件工程管理过程工具 软件质量工具 其它工具问题 启发式方法 形式化方法 原型方法 （k） 知识域描述结构 知识域描述的结构如下所述： 在简介中，给出知识域的简要定义、其范围的总体视图、与其它知识域的关系。 主题的结构分解组成每个知识域描述的核心，它描述了将知识域分解为子域、主题和子 主题。对于每个主题或子主题，给出简要描述，然后是一篇或多篇参考文献。 选择一个参考材料主要是因为认为它构成了与主题相关的知识的最佳表述，并考虑了对 选择参考文献的限制（见前）。我们使用一个矩阵来联系主题和参考材料。 知识域描述的最后一部分是推荐的参考文献列表。每个知识域的附录A为希望了解知识 域主题更多内容的读者，列出了深入读物，附录B列出与知识域最相关的标准。注意，方括 号[]中的引用表示推荐的参考文献，圆括号（）中的引用表示对于编写或验证文本有用的参 考文献，前者可以在对应的知识域章节中找到，后者可以在知识域的附录A中找到。 最后给出了知识域描述的简要总结和附录
软件需求知识域（图2，列a) 需求定义为解决真实世界问题而必须展示的特性。 第一个知识子域是软件需求基础，它包括软件需求本身的定义、主要的需求类型的定义， 如产品与过程、功能与非功能、突发性(emergent)特性等。子域也描述了可量化需求的重 要性，并区分了系统的和软件的需求。 第二个子域是需求过程，它介绍过程本身，面向余下的5个子域，说明需求工程如何与 其它软件工程过程吻合。它描述了过程模型、过程参与者、过程支持与管理、过程质量与改 进。 第三个子域是需求获取，它涉及软件需求来自何方？软件工程师如何收集这些需求，它 包括需求来源和收集技术。 第四个子域是需求分析，涉及分析需求的过程：(1)检测和解决需求之间的冲突；(2) 发现软件的边界，以及软件如何与外界交互：(3)详细描述系统需求和软件需求。需求分 析包括需求分类、概念建模、体系结构设计与需求分配、需求协商。 第五个子域是需求规格说明，一般是指产生一份（电子）文档，这样可以系统地评审、 评价和批准需求。对于复杂系统，特别是涉及大量非软件组件的系统，至少需要产生3类不 同的文档：系统定义、系统需求规格说明、软件需求规格说明。子域描述了这3类文档，以 及产生它们的活动。 第六个子域是需求确认，目标是在分配资源给需求之前，发现任何潜在的问题。需求确 认涉及检查需求文档，以保证它们定义了正确的系统（即，这是用户期望的系统）。这个子 域进一步划分为需求评审的引导、快速原型、模型确认和接收测试的描述。 第七个和最后一个子域是实际考虑，它描述在实践中需要理解的主题。第一个主题是需 求过程的迭代本质，后面3个主题是关于处于实际反映了要建造或己经建造的软件的状态的 需求的变更管理和维护。它包括变更管理、需求属性、需求追踪。最后一个的主题是需求度 量。 软件设计知识域（图2，列6） 根据IEEE的定义[IEEE610.12-90],设计既是“定义一个系统或组件的体系结构、组件、 接口和其它特征的过程”，又是“这个过程的结果”。软件设计的知识域分为6个子域。 第一个子域是软件设计基础，它是理解软件设计作用和范围的基础，这些是：一般的软 件概念、软件设计上下文和软件设计的使能(enabling)技术。 第二个子域将软件设计的关键问题聚集在一起，它们包括：并发性、事件的控制和处理、 组件的分布、错误和异常处理、容错、交互与表现、数据持久性。 第三个子域是软件结构与体系结构，它的主题是体系结构与视点、体系结构风格、设计 模式、程序与构架族。 第四个子域描述软件设计质量的分析与评价。虽然有一个完整的软件质量知识域，这个 子域描述与软件设计质量特别有关的主题。这些方面包括：质量属性、质量分析和评价技术 与度量。 第五个子域是软件设计符号，它分为结构与行为描述两部分。 最后一个子域是软件设计策略与方法。首先描述一般策略，然后是面向功能的设计方法、 面向对象的设计方法、以数据结构为中心的设计、基于组件的设计和其它方法。 软件构造（图2，列c) 软件构造指通过编码、验证、单元测试、集成测试和排错的组合，详细创建一个可以工 作的、有意义的软件，其知识域分为3个子域
软件需求知识域(图2，列a) 需求定义为解决真实世界问题而必须展示的特性。 第一个知识子域是软件需求基础，它包括软件需求本身的定义、主要的需求类型的定义， 如产品与过程、功能与非功能、突发性（emergent）特性等。子域也描述了可量化需求的重 要性，并区分了系统的和软件的需求。 第二个子域是需求过程，它介绍过程本身，面向余下的5个子域，说明需求工程如何与 其它软件工程过程吻合。它描述了过程模型、过程参与者、过程支持与管理、过程质量与改 进。 第三个子域是需求获取，它涉及软件需求来自何方？软件工程师如何收集这些需求，它 包括需求来源和收集技术。 第四个子域是需求分析，涉及分析需求的过程：（1）检测和解决需求之间的冲突；（2） 发现软件的边界，以及软件如何与外界交互；（3）详细描述系统需求和软件需求。需求分 析包括需求分类、概念建模、体系结构设计与需求分配、需求协商。 第五个子域是需求规格说明，一般是指产生一份（电子）文档，这样可以系统地评审、 评价和批准需求。对于复杂系统，特别是涉及大量非软件组件的系统，至少需要产生3类不 同的文档：系统定义、系统需求规格说明、软件需求规格说明。子域描述了这3类文档，以 及产生它们的活动。 第六个子域是需求确认，目标是在分配资源给需求之前，发现任何潜在的问题。需求确 认涉及检查需求文档，以保证它们定义了正确的系统（即，这是用户期望的系统）。这个子 域进一步划分为需求评审的引导、快速原型、模型确认和接收测试的描述。 第七个和最后一个子域是实际考虑，它描述在实践中需要理解的主题。第一个主题是需 求过程的迭代本质，后面3个主题是关于处于实际反映了要建造或已经建造的软件的状态的 需求的变更管理和维护。它包括变更管理、需求属性、需求追踪。最后一个的主题是需求度 量。 软件设计知识域（图2，列b） 根据IEEE的定义[IEEE610.12--90]，设计既是“定义一个系统或组件的体系结构、组件、 接口和其它特征的过程”，又是“这个过程的结果”。软件设计的知识域分为6个子域。 第一个子域是软件设计基础，它是理解软件设计作用和范围的基础，这些是：一般的软 件概念、软件设计上下文和软件设计的使能（enabling）技术。 第二个子域将软件设计的关键问题聚集在一起，它们包括：并发性、事件的控制和处理、 组件的分布、错误和异常处理、容错、交互与表现、数据持久性。 第三个子域是软件结构与体系结构，它的主题是体系结构与视点、体系结构风格、设计 模式、程序与构架族。 第四个子域描述软件设计质量的分析与评价。虽然有一个完整的软件质量知识域，这个 子域描述与软件设计质量特别有关的主题。这些方面包括：质量属性、质量分析和评价技术 与度量。 第五个子域是软件设计符号，它分为结构与行为描述两部分。 最后一个子域是软件设计策略与方法。首先描述一般策略，然后是面向功能的设计方法、 面向对象的设计方法、以数据结构为中心的设计、基于组件的设计和其它方法。 软件构造（图2，列c） 软件构造指通过编码、验证、单元测试、集成测试和排错的组合，详细创建一个可以工 作的、有意义的软件，其知识域分为3个子域
第一个子域是软件构造的基础，前3个主题是：复杂性最小化、变更预见和为验证进行 构造。最后一个主题讨论软件构造的标准。 第二个子域描述构造的管理，主题包括：构造的模型、构造的计划、构造的度量。 第三个子域覆盖实践考虑，主题包括：构造的设计、构造的语言、编码、构造的测试、 复用、构造的质量和集成。 软件测试（图2，列d) 软件测试由在有限测试用例集合上，根据期望的行为，对程序的行为进行的动态验证组 成，测试用例是从实际上是无限的执行域中适当的选择出来的。软件测试包括5个子域。 第一个子域是软件测试基础，首先介绍与测试有关的术语，然后描述测试的关键问题， 最后是测试与其它活动的联系。 第二个子域是测试级别，这些是根据测试对象(target)和测试目标来划分的。 第三个子域是测试技术。第一个范畴包括基于测试人员直觉和经验的测试，第二组是基 于规格说明的技术组成，然后是基于代码的技术、基于错误(fult)的技术、基于使用的 技术和与应用本质有关的技术。最后讨论如何选择和组合适当的技术。 第四个子域是测试相关的度量，度量划分为：与被测试的程序的评价有关的度量、与测 试本身的评价有关的度量。 最后一个子域是测试过程，包括了测试时的实际考虑和测试活动。 软件维护（图2，列e) 软件一旦投入运行，就可能出现异常，运行环境可能发生改变，用户回提出新的需求。 生命周期的维护阶段从软件交付时开始，但维护活动出现得还要早。软件维护知识域划分为 4个子域。 第一个子域是软件维护基础：定义和术语、维护的本质特征、维护的必要性、维护成本 的大份额性、软件的进化、维护的分类。 第二个子域将软件维护中的关键问题聚集在一起，这些是：技术问题、管理问题、维护 成本估算和软件维护度量。 第三个子域是维护过程，其中的主题包括各种维护过程和维护活动。 第四个子域是维护技术，包括程序的理解、再工程和逆向工程。 软件配置管理（图3，列f) 软件配置管理(Software Configuration Management,SCM)是为了系统地控制配置的 变更和维护配置在整个系统的生命周期中的完整性和可追踪性，而标识软件在时间上不同点 的配置的学科。这个知识域包括6个子域。 第一个子域是SCM过程管理，包括的主题有：SCM的组织结构上下文、SCM的约束和指导、 SCM计划、SCM计划本身和SCM的监管。 第二个子域是软件配置标识，它识别要控制的项目，为各个项目及其版本建立标识方案， 确定在获取和管理被控制项目中要使用的工具和技术。子域中第一个主题是识别要控制的项 目和软件库。 第三个子域是软件配置控制，它管理软件生命周期中的变更。其中的主题包括：(1) 软件变更的请求、评价和批准；(2)实现软件变更：(3)偏离和放弃(deviation and waiver)。 第四个子域是软件配置状态簿记，其主题有软件配置状态信息和软件配置状态报告生 成。 第五个子域是软件配置审计，包括：软件功能配置审计、软件物理配置审计、软件基线
第一个子域是软件构造的基础，前3个主题是：复杂性最小化、变更预见和为验证进行 构造。最后一个主题讨论软件构造的标准。 第二个子域描述构造的管理，主题包括：构造的模型、构造的计划、构造的度量。 第三个子域覆盖实践考虑，主题包括：构造的设计、构造的语言、编码、构造的测试、 复用、构造的质量和集成。 软件测试（图2，列d） 软件测试由在有限测试用例集合上，根据期望的行为，对程序的行为进行的动态验证组 成，测试用例是从实际上是无限的执行域中适当的选择出来的。软件测试包括5个子域。 第一个子域是软件测试基础，首先介绍与测试有关的术语，然后描述测试的关键问题， 最后是测试与其它活动的联系。 第二个子域是测试级别，这些是根据测试对象（target）和测试目标来划分的。 第三个子域是测试技术。第一个范畴包括基于测试人员直觉和经验的测试，第二组是基 于规格说明的技术组成，然后是基于代码的技术、基于错误（fault）的技术、基于使用的 技术和与应用本质有关的技术。最后讨论如何选择和组合适当的技术。 第四个子域是测试相关的度量，度量划分为：与被测试的程序的评价有关的度量、与测 试本身的评价有关的度量。 最后一个子域是测试过程，包括了测试时的实际考虑和测试活动。 软件维护（图2，列e） 软件一旦投入运行，就可能出现异常，运行环境可能发生改变，用户回提出新的需求。 生命周期的维护阶段从软件交付时开始，但维护活动出现得还要早。软件维护知识域划分为 4个子域。 第一个子域是软件维护基础：定义和术语、维护的本质特征、维护的必要性、维护成本 的大份额性、软件的进化、维护的分类。 第二个子域将软件维护中的关键问题聚集在一起，这些是：技术问题、管理问题、维护 成本估算和软件维护度量。 第三个子域是维护过程，其中的主题包括各种维护过程和维护活动。 第四个子域是维护技术，包括程序的理解、再工程和逆向工程。 软件配置管理（图3，列f） 软件配置管理（Software Configuration Management，SCM）是为了系统地控制配置的 变更和维护配置在整个系统的生命周期中的完整性和可追踪性，而标识软件在时间上不同点 的配置的学科。这个知识域包括6个子域。 第一个子域是SCM过程管理，包括的主题有：SCM的组织结构上下文、SCM的约束和指导、 SCM计划、SCM计划本身和SCM的监管。 第二个子域是软件配置标识，它识别要控制的项目，为各个项目及其版本建立标识方案， 确定在获取和管理被控制项目中要使用的工具和技术。子域中第一个主题是识别要控制的项 目和软件库。 第三个子域是软件配置控制，它管理软件生命周期中的变更。其中的主题包括：（1） 软件变更的请求、评价和批准；（2）实现软件变更；（3）偏离和放弃（deviation and waiver）。 第四个子域是软件配置状态簿记，其主题有软件配置状态信息和软件配置状态报告生 成。 第五个子域是软件配置审计，包括：软件功能配置审计、软件物理配置审计、软件基线
的过程内部(in-process)审计。 最后一个子域是软件发布管理和交付，覆盖软件建造和软件发布管理。 软件工程管理（图3，列g) 软件工程管理知识域处理软件工程的管理与度量，虽然度量是所有知识域的一个重要方 面，但在这里涉及的是度量程序的主题。软件工程管理游个子域，前5个覆盖软件工程管理， 第六个描述软件度量的程序。 第一个子域是启动和范围定义，它由需求的确定与协商、可行性分析、需求的评审和修 订过程组成。 第二个子域是软件工程计划，包括过程计划、确定可交付成果、工作量、进度与成本估 算、资源分配、风险管理、质量管理、计划本身的管理。 第三个子域是软件项目实施，它的主题是：计划的实现、供应商合同管理、度量过程的 实现、过程的监理、过程的控制、报告生成。 第四个主题是评审与评价，主题有：确定需求的满足程度、评审和评价项目性能。 第五个主题描述项目的关闭：确定关闭项目、关闭涉及的活动。 第六个子域描述软件工程度量，特别是度量本身的程序。产品和过程的度量在软件工程 过程知识域中描述，许多其它知识域也描述其特定的度量。这个子域的主题包括：建立和维 持度量工作、度量过程的计划、进行度量过程和评估度量。 软件工程过程（图3，列h) 软件工程过程的知识域涉及软件工程过程本身的定义、实现、评定、度量、管理、变更 和改进。它分为4个子域。 第一个子域是过程实现与变更，其主题有：构成基础结构、软件过程管理周期、过程实 现与变更的模型、实际考虑。 第二个子域处理多成定义，主题有：软件生命周期模型、软件生命周期过程、过程定义 符号、过程适配(adaptation)和自动化。 第三个子域是过程评定，主题有：过程评定模型和过程评定方法。 第四个子域描述过程与产品度量。软件工程过程覆盖一般的产品度量，以及过程度量。 特定于各知识域的度量在相关的知识域描述。子域的主题有：过程度量、软件产品度量、度 量结果的质量、软件信息模型和过程度量技术。 软件工程工具和方法（图3，列1） 软件工程工具和方法知识域包括软件工程工具、软件工程方法。 软件工程工具子域使用了与指南相同的结构，为其它9个软件工程知识域各分配一个主 题，附加一个主题是其它工具问题，例如工具集成技术，这些问题可能应用于所有类型的工 具。 软件工程方法子域分为4个小节：处理形式化途径的启发式方法、处理基于数学的途径 的形式化方法、处理基于各种原型的软件开发途径的原型方法、？？。 软件质量（图3，列j) 软件质量知识域处理跨越软件生命周期过程的软件质量的考虑，由于软件质量在软件工 程中无处不在，其它知识域也涉及质量问题，读者可以注意到本知识域到其它知识域的指示 器。本知识域覆盖4个子域。 第一个子域描述软件质量基础，例如软件工程文化和伦理学、质量的价值与成本、模型
的过程内部（in-process）审计。 最后一个子域是软件发布管理和交付，覆盖软件建造和软件发布管理。 软件工程管理（图3，列g） 软件工程管理知识域处理软件工程的管理与度量，虽然度量是所有知识域的一个重要方 面，但在这里涉及的是度量程序的主题。软件工程管理游个子域，前5个覆盖软件工程管理， 第六个描述软件度量的程序。 第一个子域是启动和范围定义，它由需求的确定与协商、可行性分析、需求的评审和修 订过程组成。 第二个子域是软件工程计划，包括过程计划、确定可交付成果、工作量、进度与成本估 算、资源分配、风险管理、质量管理、计划本身的管理。 第三个子域是软件项目实施，它的主题是：计划的实现、供应商合同管理、度量过程的 实现、过程的监理、过程的控制、报告生成。 第四个主题是评审与评价，主题有：确定需求的满足程度、评审和评价项目性能。 第五个主题描述项目的关闭：确定关闭项目、关闭涉及的活动。 第六个子域描述软件工程度量，特别是度量本身的程序。产品和过程的度量在软件工程 过程知识域中描述，许多其它知识域也描述其特定的度量。这个子域的主题包括：建立和维 持度量工作、度量过程的计划、进行度量过程和评估度量。 软件工程过程（图3，列h） 软件工程过程的知识域涉及软件工程过程本身的定义、实现、评定、度量、管理、变更 和改进。它分为4个子域。 第一个子域是过程实现与变更，其主题有：构成基础结构、软件过程管理周期、过程实 现与变更的模型、实际考虑。 第二个子域处理多成定义，主题有：软件生命周期模型、软件生命周期过程、过程定义 符号、过程适配（adaptation）和自动化。 第三个子域是过程评定，主题有：过程评定模型和过程评定方法。 第四个子域描述过程与产品度量。软件工程过程覆盖一般的产品度量，以及过程度量。 特定于各知识域的度量在相关的知识域描述。子域的主题有：过程度量、软件产品度量、度 量结果的质量、软件信息模型和过程度量技术。 软件工程工具和方法（图3，列i） 软件工程工具和方法知识域包括软件工程工具、软件工程方法。 软件工程工具子域使用了与指南相同的结构，为其它9个软件工程知识域各分配一个主 题，附加一个主题是其它工具问题，例如工具集成技术，这些问题可能应用于所有类型的工 具。 软件工程方法子域分为4个小节：处理形式化途径的启发式方法、处理基于数学的途径 的形式化方法、处理基于各种原型的软件开发途径的原型方法、？？。 软件质量（图3，列j） 软件质量知识域处理跨越软件生命周期过程的软件质量的考虑，由于软件质量在软件工 程中无处不在，其它知识域也涉及质量问题，读者可以注意到本知识域到其它知识域的指示 器。本知识域覆盖4个子域。 第一个子域描述软件质量基础，例如软件工程文化和伦理学、质量的价值与成本、模型
和质量特征和质量改进。 第二个子域覆盖软件质量管理过程，主题有：软件质量保证、验证和确认、评审和审计。 第三个即最后一个子域描述与软件质量有关的实际考虑，主题包括：软件质量需求、缺 陷特征、软件质量管理技术、软件质量度量。 软件工程相关学科（图3，列业k) 最后一章是软件工程相关学科。为确定软件工程的范围，有必要鉴别与软件工程有公共 边界的学科，这一章按字母顺序，鉴别这些相关学科。对每个相关学科，使用我们找到的基 于一致认可的来源，进行以下内容的鉴别：(1)资料性定义（可行时）：(2)知识域列表。 相关学科包括：计算机工程、计算机科学、管理、数学、项目管理、质量管理、软件人 类工程学、系统工程。 附录 附录A知识域描述规格说明 这个附录描述了编辑组向副编辑提供的规格说明：内容、推荐的参考文献、格式、知识 域的描述风格。 附录B指南的演化 第二个附录描述项目建议的指南进化。2004年版指南只是指南的当前版本，指南将继续 演化，以适应软件工程团体的需要。演化的计划还没有制订，但本指南附录提供了一个完成 暂时的过程轮廓。在本次编写时，这个过程已经被项目的工业界顾问委员会认可，并向IEEE 计算机学会的主管委员会发送了简报，但还没有得到资助或实施。 附录C标准到知识域的分配 第三个附录是大多数相关标准的注释表，这些标准主要来自IEEE和IS0,注释表将标准 分配到SWEBOK指南的各个知识域。 附录DB1oom级别 作为支持项目的第五个目标的辅助手段，特别是对于课程表开发人员（和其它用户）， 第五个附录对每个主题按照一个教育学目录集，划分等级，这个目录主要由Benjamin Bloom 提出。其概念是，教育目标可以分类6类，分别表示递增的深度：知识、理解、应用、分析、 综合和评价。对所有知识域的等级分类结构在附录D中。但是，这个附录不能认为是确定性 的分类，而应该被认为是一个起点。 LLLL111L111111L111111111111111111111111111111 第2章软件需求 术语与缩写 DAG:Directed Acyclic Graph,无环有向图 FSM:Functional Size Measurement,功能规模估算 INCOSE:International Council on Systems Engineering,国际系统工程理事会 SADT:Structured Analysis and Design Technique,结构化分析与设计技术 UML:Unified Modeling Language,统一建模语言
和质量特征和质量改进。 第二个子域覆盖软件质量管理过程，主题有：软件质量保证、验证和确认、评审和审计。 第三个即最后一个子域描述与软件质量有关的实际考虑，主题包括：软件质量需求、缺 陷特征、软件质量管理技术、软件质量度量。 软件工程相关学科（图3，列k） 最后一章是软件工程相关学科。为确定软件工程的范围，有必要鉴别与软件工程有公共 边界的学科，这一章按字母顺序，鉴别这些相关学科。对每个相关学科，使用我们找到的基 于一致认可的来源，进行以下内容的鉴别：（1）资料性定义（可行时）；（2）知识域列表。 相关学科包括：计算机工程、计算机科学、管理、数学、项目管理、质量管理、软件人 类工程学、系统工程。 附录 附录A 知识域描述规格说明 这个附录描述了编辑组向副编辑提供的规格说明：内容、推荐的参考文献、格式、知识 域的描述风格。 附录B 指南的演化 第二个附录描述项目建议的指南进化。2004年版指南只是指南的当前版本，指南将继续 演化，以适应软件工程团体的需要。演化的计划还没有制订，但本指南附录提供了一个完成 暂时的过程轮廓。在本次编写时，这个过程已经被项目的工业界顾问委员会认可，并向IEEE 计算机学会的主管委员会发送了简报，但还没有得到资助或实施。 附录C 标准到知识域的分配 第三个附录是大多数相关标准的注释表，这些标准主要来自IEEE和ISO，注释表将标准 分配到SWEBOK指南的各个知识域。 附录D Bloom级别 作为支持项目的第五个目标的辅助手段，特别是对于课程表开发人员（和其它用户）， 第五个附录对每个主题按照一个教育学目录集，划分等级，这个目录主要由Benjamin Bloom 提出。其概念是，教育目标可以分类6类，分别表示递增的深度：知识、理解、应用、分析、 综合和评价。对所有知识域的等级分类结构在附录D中。但是，这个附录不能认为是确定性 的分类，而应该被认为是一个起点。 ///////////////////////////////////////////////////// 第2章 软件需求 术语与缩写 DAG：Directed Acyclic Graph，无环有向图 FSM：Functional Size Measurement，功能规模估算 INCOSE：International Council on Systems Engineering，国际系统工程理事会 SADT：Structured Analysis and Design Technique，结构化分析与设计技术 UML：Unified Modeling Language，统一建模语言
