北京航空航天大学  麦中凡/文

2004年6月，美国IEEE协会和ACM的联合网站上公布了软件工程知识体（SWEBOK）2004版全文，这标志着SWEBOK的工作告一段落。软件工程作为一门学科，为取得对其核心的知识体系的共识，已经达到了一个重要的里程碑。SWEBOK的初步成就，无疑对我国亟待快速发展的软件产业界，和已经快速膨胀的软件工程教育调整了方向盘，增添了助推器，因而引起业界广泛重视。本文仅从软件工程教育业者的角度谈谈阅读心得。

一、SWEBOK的背景

“软件工程”在20世纪80年代初引入我国，其基本思想是把工程的方法引入软件生产，不仅要开发出正确的程序，而且要在预算、进度约束之下开发出高质量的软件。基于瀑布模型的开发过程和结构化开发方法，在业界和学术界几乎家喻户晓。然而，对以后技术的发展却打乱了乾坤：原型模型否定瀑布模型，面向对象的分布式系统挤压单主机的结构化程序系统，还有日益壮大的基于构件系统和Web服务应用系统，以体系结构为中心的基于过程的开发……这些逐渐成为应用主流的技术把原有软件工程内容冲击得七零八落，甚至术语概念也在潜移默化，如软件维护从第一个需求文档成为软件配置项就开始了，而不是产品交付之后；软件配置不仅是配齐产品，更重要的是支持追踪变更；编码成为软件构造的一部分；软件复杂性模型在面向对象、基于构件的软件中无能为力……以致在我国业界采用什么开发过程、规范、方法、标准的都有（各大软件公司围绕自己软件产品鼓吹培训自己的技术），教育界总感到学校教育与市场人才要求有差距，出版界于是找到信息技术源头，大量引进美国最新软件技术的书籍，翻译甚至原版影印。然而，软件工程从业者却不得其门而入，一方面，深感学校所教技术落后，另一方面，新华书店浩瀚的计算机书中竟没有几本是适合我的。造成这种迷茫混浊的局面，固然与我国信息技术落后，信息产业不能独立有关，看来源头也未必清晰，在信息技术快速发展的巨大压力下，也在不断地调整，SWEBOK就是在这种背景下产生的。软件工程搞了30年（1968年在德国召开的NATO软件工程会议第一次提出把工程应用于软件生产），才对软件工程核心的知识体系达成共识。

1993年，美国IEEE的计算机协会和ACM组成协调委员会（SWECC），为软件工程职业化制定相应的准则和规范，作为产业决策、职业认证，课程教育的依据。软件工程职业化是软件工程成熟的标志，正如化学工程独立于化学，航空工程独立于航空学一样，软件工程是一门独立的学科，有自己的职业体系和教育课程体系，独立的知识体系和职业实践内容则是该学科的基础，SWEBOK正是这个项目的子项目，其余两个子项目——软件道德规范已于1998年公诸于世，软件工程教育知识体SEEK已于2004年完成。

SWEBOK项目自1994年开始分三阶段完成。稻草人阶段（1994-1996）在充分调查的基础上建立了原型，论证了本项目如何组织，但并没有对外发布结果。接着是石头人阶段（1998—2001）开发完成，并集世界范围内42个国家近500位软件工程专家评审，2001年发布了SWEBOK的试用版“软件工程知识体系指南”。此时正是另一项目（CC2001课程体系）发布之时，并作为四大学科（计算机科学、计算机工程、软件工程、管理信息系统）知识/课程体系之一。紧接着铁人阶段（2003—2004）在Web调查基础上作了修订，按统一风格改写，并重写了不便于使用的三章，又征集21个国家120位专家的评审意见。2004版的发布标志着本子项目的结束。

二、SWEBOK的目的与内容

SWEBOK指南开宗明义提出五个目的：

（1）促进软件工程业界统一看法；

（2）划定学科边界，澄清软件工程的学科地位；

（3）刻画软件工程的学科内容；

（4）提出访问SWEBOK的论题（知识点）；

（5）为个人认证、申请执照、课程体系制定提供基础。

首先，为做到目的的第一条，整个SWEBOK计划，从调研到每阶段评审都要广泛征求业界各方人士意见，特别是发布的版本，从公布的评审者名单来看，各大公司均有，学界居多。其次，目的（2）（3）条写出指南文本，这里有个定义的知识，其深浅程度定位问题，也就是软件工程职业工程师应具有什么样的知识，谈深了（如数学建模），一般人达不到，说浅了，不敷使用。SWEBOK定位在大学毕业后有四年工作经验的人，能看懂并理解的知识。这是本学科工程性使然，你没有参与过程软件系统制作全过程，不了解如何与用户沟通，不理解延误交付期遭受的罚款压力，不理解没完没了的质量纠纷，很难对其中的知识点有深入的了解和体验。正如动物园和野外看到的猛兽是不一样的。该定位无疑对有工作经历的硕士研究生是适宜的，对于“三门”硕士生同样存在理解不深的问题，参加实战的科研项目情况会好得多。

SWEBOK把整个体系分解为10个知识域（Knowledge Area）

软件需求   7/28（10）

软件设计   6/25（14）

软件构造   3/14（7）

软件测试   5/16（9）

软件维护   4/15（16）

软件配置管理   6/17（11）

软件工程管理   6/24（7）

软件工程过程   4/16（20）

软件工程工具与方法   2/12（7）

软件质量   3/11（68）

每个知识域又分若干子域，每个子域分为若干论题（Topic），我国学界称之为知识点，每个知识点还可以再分为下层，或下下层的子知识点。SWEBOK只给出知识域确切的概念和准确的定义，即内涵定义。从知识域到子域到知识点，要完全理解知识域的含义还要靠它的外延，即各种参考文献，而论题（知识点）是向导，知识点可以大到一本书，例如，软件需求的子域需求分析有四个知识点：需求分类、概念模型、体系结构设计和需求分配、需求磋商，其中任三个都可以写成一本书。知识点可以小到一章中的某一小节，如需求分类，不过一般对应为一篇文章（阐明一个论题）。指南中给出的参考文献——知识点矩阵也是本指南的第四个目的：便于读者按知识点索骥。SWEBOK的每个知识域的子知识域、知识点、参考文献数列于上表。共计：知识域10个，子知识域46个，知识点178个，参考文献169篇，应用标准51个。

SWEBOK指南将每个知识域作为一章详细描述，加上导言（第1章）和相关学科（第12章）共12章，此外，还包括四个附录A、B、C、D。指南全文文本都是对上述五个目的的支持。

三、有关知识域的解说

对于了解软件工程的人，这10个知识域除了软件工程管理和软件工程过程不知怎么分工外，其余知识域大体是可理解的。前五个知识域似乎有瀑布模型做背景，单指南也声明，它只是为叙述方便，不限于瀑布模型开发，每个域中尽可能有一个基本概念、术语或基础知识的子域，最后有一个实践的考察子域。这是软件工程的工程性使然，不仅要描述这个域中有什么知识，还要有使用这些知识的知识。例如，软件需求知识域的实践考察是：需求过程的迭代性质、变更管理、需求属性、需求追踪、需求量度。

软件量度和度量既是软件具有的属性，也是软件过程中重要的活动。SWEBOK指南没有把它作为单独的知识域，而是在各相关域的实践考察中分别描述。

“软件工程管理”基本上覆盖了“项目管理”的内容，从定义工程产物的范围、起动，到评审、验收，没有太多的新东西。只是最后一个知识域“软件工程量度”作了些变动，其子域是：

建立和实施量度承诺机构/计划量度过程/执行量度过程/量度评估。

隐含是可与“软件质量”知识域中建立SQA机构合并，要有单独的计划，执行和事后的量度和评估。

工程管理是具体过程的管理、管理计划的过程，而“软件工程过程”知识域是反应近年软件过程技术的成果，即一个产品的开发不是某个固定的过程模型，而是根据产品应用域，开发单位的文化和资产，专门设计——最优过程，不仅要量度产品的质量也要量度过程，但SWEBOK采取较为保守的态度，强调过程的变更和改进过程，而不是设计新过程。这是符合ISO 12207标准的，也是当前可行的。掌握了本知识域的各知识点，即定义表示法量度、评价、管理、设计新过程只有一步之遥。

除此之外，“软件设计”知识域尽可能抹平结构化程序和面向对象程序设计上的差异，只把它们看作不同的策略和方法，表示法不同而已，设计的关键问题：并发性、事件控制，组织分布，错误、异常，交互和表示，数据持久是一样的，也都有质量分析和评价问题，软件的结构和体系结构的不同产生不同的软件工程，Pressman软件工程第六版也收回了他在第四、五版中的“面向对象软件工程”一说。尽管面向对象、基于构件、Web应用在设计上的确存在巨大差异，但目前并未总结出有区别、可执行的规范，在这个意义上，SWEBOK偏保守，而工程往往是保守取胜。

四、软件工程相关学科

软件工程原本是从计算机科学中分离出来的独立学科，然而，它又是为了解决工程实际问题的综合学科，即把别的学科，具有一般意义的成果直接用于软件上，也就是该成果的软件实例，SWEBOK指南给出了以下八个学科，列出知识域82个：

计算机科学 12

计算机工程 21

管理学 10

数学 7

项目管理 9

质量管理 6

软件人类工程学 11

系统工程 6

划定学科边界并不十分容易，以上八个学科的知识域也是交叉的，例如，任何工程都要在时间、资金的约束下做出质量合格的产物（或服务），都必须在分析的基础上拿出一个系统的解决方案，在满足业务过程和运营的前提下，费用-资源-时间综合平衡，达到整体（也是系统的）最优，这恰巧是系统工程研究的，它也讨论建模、生存周期、体系结构、度量与测试，为保证工作产物实现必须有风险、配置、基线、进度管理，所以要用到管理学的一般知识：财会、市场、运营、人力资源、管理策略、法律等，但最重要的还是信息管理和如何从定性到定量的分析。这些系统的知识、管理的知识落实到工程项目上就是项目管理。2000年也有项目管理研究机构发布的国际指南PMBOK，它比一般管理更加具体，有合同、采购、与承包商管理部分，软件工程当然也是按项目做出来的。

同样质量管理是做好每项工程活动的保证：

最难划分界线的是“计算机工程”，按照计算课程体系项目（CC2001），它包揽了现代计算机系统和以计算机控制的设备的软件和硬件，是有关这些软件和硬件设计、构造、实现、维护的科学和技术，共给出21个知识域，除了7个与计算机硬件密切相关的知识域（如电子学、VLSI/ASIC设计、数字逻辑、电路及系统、数字信号处理、计算机系统工程、计算机体系结构和组织），其余14个知识域都和软件有关（如信息管理，编程基础，操作系统，智能系统，嵌入式系统……），特别是其中也有“软件工程”和“社会和职业问题”两个知识域。

在“计算机科学”学科的14个知识域中也有这两个知识域，也有不少和“计算机工程”同名的知识域，如信息管理、编程基础、操作系统、智能系统、算法和复杂性等。

事实上，“软件工程”是从“计算机工程”中分解出来的，它们的基础是“计算机科学”，再往下的基础是“数学”。如果50年前也有知识域和知识点的说法，大概“计算机工程”也只能算“计算机科学与技术”的一个知识域。现在它已成为强大的学科，它的子域、软件工程，也发展成为学科，也就是说，尽管它们都是一脉相承，但父学科的知识域已不足以包容子学科知识域。粗浅地说，“计算机科学”中的“软件工程”侧重科学层面（语言、算法、复杂性、可验证性、可靠性）；“计算机工程”中的“软件工程”除了以上知识内容外，增加了软件构造和工程侧面（体系结构、构造方法、计划、进度、成本）到了“软件工程”学科又增加了系统和管理侧面。反过来说，“计算机科学”中的“软件工程”就不会提到多少系统工程、管理学、项目管理的知识，而“软件工程”学科中计算机科学的知识内容则隐退到构造的软件之中。例如，域理论是属计算机科学的，但工程上要用到指导构件分类。

当前，在新成立的软件工程系和软件学院教学上比较迷茫，往往课程体系和计算机科学与工程系差不多。问题的症结大概就在这里，除了学科偏向系统地、规范地、定量途径外，SWEBOK强调的实践考虑就是工程性。粗浅的解释是让本学科学生有这样的意识：一个问题来了，经分析马上回答以什么解决方案做出它，难点在哪里，工作量多大，大概什么时候做完，要多少钱。此外，值得一提的是，软件人类工程学（Software Engonomics）是软件个性化、人文化最新的发展，从最早的消极人机界面到人机工程学到人类（工程）学，即人们可以使用该软件系统，到软件系统好用，到喜欢用软件来解决所有遇到的问题，这是软件成熟的标志，为此，它研究人的对话、交互通信特性，计算语言获得界面体系结构，并且利用传统的人工智能技术用于认知推理，通过机器学习归难方法，抽取信息，以致影响到开发过程，从静态的人机接口设计到动态的交互式设计，也就是设计者提供了某种业务的解决方案，用户愿意怎样改变使用方式都可以，甚至改变软、硬件形态，例如穿在身上的计算机系统。

如果说SWEBOK只取“广泛共识”的偏保守，稳妥可靠的知识，引入人机工程学的相关知识是最偏先进的，它也许是今后一段时间软件工程技术的成长点。

划分软件工程学科的内容和相关学科的界线，并不意味着我们的教育课程体系制定者不能越雷池一步，恰巧相反，只要在职业认证、执照申请所需知识点严格限定在学科范围内外，教育课程体系，特别是深入一点的研究生课程，直接请相关学科教师开出系统工程、项目管理、认知心理学、概率统计之类的课都可以，只不过一定要落实到软件工程的实例上。当然，引进教材中已有越来越多将两个学科融合得很好的例子。

五、SWEBOK还在发展

鉴于软件技术发展迅速，而SWEBOK指南又坚持“广泛共识”的设计基点，当前已经实现工业应用但未普遍使用的新技术并未纳入，估计两三年之后会变得非纳入不行，即使不增加新知识域，本指南实施中因环境工具、基础设施的进步也会要求更改，加上实践中发现的错误或不恰当之处，都要求更改。为此，SWEBOK指南的附录B已勾画了修改周期的时间框轮廓，初步定为四年一周期，即IEEE计算机协会管理委员会已在筹划2008年的版本，不过资金计划均未落实。