欢迎加入

搜索结果

当前位置:首页 > 搜索结果

《软件工程知识体SWEBOK 2004》解读

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

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年的版本,不过资金计划均未落实。