2014, Vol.25 
2 南京大学 计算机科学与技术系,江苏 南京 210093
2 Department of Computer Science and Technology, Nanjing University, Nanjing 210093, China
嵌入式系统作为专用计算机系统,往往为了特定应用而设计.一般来说,嵌入式系统的开发往往会受到较多的限制,例如嵌入式系统开发往往会受到现有软硬件平台的限制、大部分嵌入式系统往往也有着实时性的要求等,这些限制使得嵌入式开发往往需要消耗更多的资源和成本.在Boehm等人设计的COCOMO[1]模型中,嵌入式系统开发被认为是同等规模下开发成本最高的软件项目[1].随着近年来计算机硬件设备性能的迅速提高,嵌入式系统的应用领域也得以不断拓宽,嵌入式系统软件的规模和复杂性急剧增加.这些现象进一步增加了嵌入式系统开发的难度.特别是伴随着物联网、移动计算、信息物理融合系统等嵌入式系统领域的相关热点不断出现,嵌入式系统的质量、成本及项目周期也日益引起关注.在2011年和2012年嵌入式领域权威调查报告中[2, 3],按时交付、开发高质量过程、管理代码规模和复杂性等问题都获得了业界最为广泛的关注.
敏捷方法自从2001年雪鸟会议之后开始获得各界,特别是实践者的欢迎.时至今日,敏捷方法已经在大量软件项目当中得到了应用,并且获得了成功.实践者通常认为,敏捷方法可以显著降低开发成本、提升生产效率、缩短开发周期、提升最终产品的质量.此外,敏捷方法使得开发团队具有更强的适应需求变更的能力.
我们认为,在很多方面,敏捷方法可以帮助实践者解决嵌入式系统开发中所面临的各类困难.例如,统计表明,尽管有日益扩大的趋势,嵌入式系统的开发往往还是规模较小(大部分持续时间在12个月以内,软件研发团队小于6人)[2, 3],这与敏捷方法适合小型团队的特性比较相符;敏捷方法所具有的适应需求变更的能力也能更好地满足嵌入式系统应用领域不断扩大所带来的需求多样性和多变性.此外,敏捷方法在生产效率和产品质量上的优势,也可以较好地解决嵌入式系统应用趋势所带来的各类挑战.然而,敏捷方法的一些限制也不容忽视,例如,通常认为,敏捷方法不适合大规模项目,而伴随着嵌入式系统日益扩大的应用领域,嵌入式系统软件规模日益增加是必然的趋势,敏捷方法能否适应这种趋势值得研究;再如,敏捷方法在一些关键任务系统(mission-critical systems)的研发当中应用有限,而作为专用计算机系统,嵌入式系统不可避免地成为一些关键任务系统,在这类系统研发过程中能否应用敏捷方法,需要更多的研究和实践.此外,一些常用的敏捷实践在包含硬件开发在内的嵌入式系统开发中可能难以应用,例如自动化测试和持续集成等.
正是基于上述认识,我们拟采用系统评价(systematic review)方法[4],对从2001年(雪鸟会议)至今在相关领域主流期刊和会议中的论文进行完整而系统的概况、分析和评价,试图建立敏捷方法在嵌入式系统开发中的应用状况和研究现状的理解,在此基础之上识别原因(即,嵌入式系统的哪些特性适用敏捷方法)和改进机会(即,敏捷方法和实践该如何扩展和改进,以适应嵌入式系统开发的要求).需要指出的是,一个典型的嵌入式系统往往包括如图 1所示的各个层次[5].因此,在本文论述中,嵌入式系统开发可能发生在图 1所示的各个层次之上.
为了更好地对嵌入式系统开发类型进行区分,我们按照开发内容与硬件平台的关联关系,大致地将嵌入式系统开发分成4种类型,即应用层开发、基于现有硬件的纯软件开发、软硬件协同开发和纯硬件开发.表 1展示了这4种类型和特征描述.
|
Table 1 Categories of embedded system development 表 1 嵌入式系统开发分类 |
本文第1节简单介绍系统评价方法,并在此基础上详细介绍本文所用的系统评价过程.第2节给出敏捷方法在嵌入式系统开发中的应用系统评价结果和相应的分析讨论.第3节将就本文的研究过程和结果的一些限制和不足进行讨论,以便更好地建立起对本文研究课题的理解.本文的研究结论和一些未来可能的研究工作将在第4节给出.
系统评价(systematic literature review,简称SLR,或systematic review)方法是一种基于证据的软件工程(evidence based software engineering,简称EBSE)研究方法[4].原方法在医学领域和社会科学等领域被广泛使用,近几年才应用于软件工程领域,在应用的同时也伴随方法学的不断改进[6].与传统的文献综述方法(narrative or ad hoc review)不同的是,系统评价方法遵循一条严谨的、系统的研究路线[6],使用明确定义的方法来识别、分析所有与研究问题相关的证据(往往是指正式发表的研究成果),通过证据质量评判标准对文献进行筛选,尽可能地消除研究者的主观偏见,在某种程度上可供其他研究者复制研究过程[7].而传统的方式通常是研究人员基于其对某领域的了解,对于相关证据的定性总结,研究过程和结论往往容易受到主观因素的影响而产生偏向性.
(1) 计划阶段:列举研究目标,定义研究规范(protocol),即,为系统评价工作制定计划.在研究计划中应当包括研究背景、研究问题、检索策略(包括检索引擎、关键词等)、文献选择标准、数据抽取策略等一系列执行系统评价过程所需要的信息;一份明确的研究规范可以显著降低研究偏见.
(2) 执行阶段:具体执行系统评价工作,基于先前制定的研究规范,对事先定义的文献数据库进行检索,根据选择和排除标准,确定检索结果中哪些研究需要被排除;并由所有参与系统评价工作的成员对文献进行质量评价,以确定该证据(即检索到的文献)是否能被最终采纳;一旦文献被选定,就需要对文献中的信息进行抽取,为了避免抽取过程的主观作用,该过程一般由多位小组成员共同完成;然后,需要对提取出的数据进行分析总结,可以是定性描述或定量分析,解释结果,回答预先定义的研究问题.
(3) 报告阶段:记录研究结果,完成最终报告.
本文针对敏捷方法在嵌入式系统开发中的应用情况这一主题进行系统的评价,参考上一节所述,定义了如下的研究计划:
经过对研究主题的分析,应用系统评价方法,我们拟尝试解决以下3个问题:
(1) 问题1:不同类型的嵌入式软件开发中,敏捷方法的总体应用情况如何?
(2) 问题2:敏捷方法或实践是如何解决各类嵌入式软件开发中的挑战的?
(3) 问题3:敏捷方法或实践应该如何通过扩展或改进以适用于各类嵌入式软件开发?
(1) 确定关键词
本研究包含了敏捷方法和嵌入式两大部分,因此,设计检索关键词也以这两部分的热点话题为基础.关键词的定义基本上由两个集合组成,即(敏捷方法相关关键词 AND 嵌入式开发相关关键词).检索语句的确定遵循基于QGS的检索方法[8].该方法旨在通过敏感度和精确度两个指标来评价文献检索所定义的关键词质量,从而确保通过关键词可以检索尽可能合适的文献集合.经过反复尝试和评价,本研究最终采纳的检索语句如下:
(Agile OR ASD OR “Adaptive Software Development” OR DSDM OR “Dynamic Systems Development Method” OR (FDD AND software) OR “Feature Driven Development” OR (XP AND software) OR “Extreme Programming” OR (Lean AND software) OR Xbreed OR Scrum OR RUP OR “Rational Unified Process” OR (Crystal AND software) OR EVO OR “Evolutionary Project Management”) AND (Embedded OR mobile OR automotive OR “control system” OR DSP OR “Digital system processing” OR “hardware driver” OR firmware)
根据基于QGS方法,我们对上述检索语句进行了质量评价,评价结果在表 2中给出.根据敏感度和精确度的定义,我们发现,通过人工检索最终确定入选的文献都可以通过自动检索方式发现(敏感度为100%),并且在自动检索的结果内容中,有一半文献最终作为证据使用(精确度为50%).参考文献[8]中建议了检索关键词质量指标,综合考虑之下,我们认为,该检索语句(关键词)的检索性能能满足完成本研究课题的要求,因此可以用作本研究文献检索所用的关键词组合.
|
|
Table 2Assessment of the search string 表 2 检索语句评价 |
(2) 检索结果
基于表 3中给出的检索策略(TI表示标题检索,AB表示摘要检索,KW表示关键词检索,ALL表示全部内容检索),我们对系统评价中常用的10个主要数据库[7]进行了文献检索,检索结果在表 3中给出,“检索结果”一栏表示检索结果的文献数量,共计800余篇(已经去除了同一篇文献被不同的数据库收录的重复现象).
|
|
Table 3 Search approach & results 表 3 检索方法&结果 |
对于上一步的初步检索结果,我们依照以下入选与排除标准,在快速阅读文献内容的基础上,决定是否可将其作为系统评价的证据来源:
(1) 入选标准:必须是有同行评阅的正式发表的会议论文或者期刊论文;论文讲述了敏捷方法或者实践在嵌入式软件开发中的应用过程,或单独使用敏捷,或结合使用其他方法,或对敏捷方法或实践进行了改进;原则上要求包含方法描述和验证的长文;论文没有进行以上的应用过程,但是对其提出了质疑或者作者持反对的态度;同一作者类似的文章如果发表过多篇,我们只选择最具有代表性的一篇.
(2) 排除标准:论文主体内容非英文;论文与应用敏捷方法或者实践以及嵌入式软件开发这一主旨无关;发表于网站上的非正式文章或者技术报告.
为了确保初步筛选的结果质量,研究小组选择若干篇文献进行了试阅读,并对入选文献和排除文献的结果进行了讨论,逐渐形成了对入选和排除标准的统一理解.最终,通过小组成员对检索初步结果的排查,我们获得了76篇文献作为初步筛选的结果.其中,由于部分短文的内容也具有一定的参考价值,我们也将这些短文列入研究范围.具体包括(见表 4):文献S12作为概述论文,较为全面地描述了Mobile开发限制、Mobile-D开发方法、应用以及挑战等内容;文献S14作为一篇案例研究,提出了对Mobile-D方法的改进方案,强调了人这一因素在嵌入式系统开发中的影响;文献S41作为一篇总结性文章,对于敏捷实践在实际项目中的应用情况给出了统计,具有借鉴价值;文献S19则结合一个实际的多媒体项目,分析了项目的困难、改进方案以及实施结果,叙述完整,具有参考价值.
|
|
Table 4 Literature list & quality assessment results 表 4 文献列表&质量评价结果 |
为了进一步保证评价证据的质量以提高结果的可信度,参照文献[6]中给出的质量标准,我们针对本研究定义了如表 5所示的文献质量标准.该质量标准包括4个部分:第1项~第3项与研究报告的质量相关;第4项~第7项体现了研究方法的严格程度,并进一步反映出结果的可信度;第8项、第9项表明研究成果的价值与可信度;最后一项则是对研究相关性的综合考量.在抽取数据的同时,我们对已经入选的文献进行质量评价,从而可以对上述76篇文献进一步进行筛选.为了保证评价结果的公正和客观,这一过程将由5名小组所有成员共同参与.质量评价的最终结果在表 4中给出.需要说明的是,我们原则上要求得分在6分以上的文献才可以列入最终系统评价的范围,但是考虑到部分文献中的内容,尽管描述的信息存在一定的不足,它们对于了解敏捷方法应用情况还是有参考价值,我们设定的第10项质量标准事实上是相对主观的综合评价,并且要求以小组形式对得分偏低的文献进行讨论,如果大家共同认为有价值,那么这部分文献也会被列入最终的评价范围.应用该方法,最终入选的文献数量在表 3的“最终结果”一栏中给出,去除重复的文献,有共计44篇文献纳入最终进行概括和分析的范围.
|
|
Table 5 Quality criteria 表 5 质量标准 |
对于已选定的文献,我们按照已经定义的抽取内容抽取出所有文献中有价值的信息,分析整理之后,用以回答之前所定义的3个研究问题,抽取的内容见表 6.
|
|
Table 6 Data extraction form 表 6 数据抽取表 |
基于抽取的信息进行概括和分析,并完成研究报告.
针对本研究拟回答的3个问题,本节将对抽取的数据内容进行描述、概括和分析,试图给出有参考价值的结果:
对于第1个问题,我们将直接给出相关文献的一些统计数据,以描绘嵌入式开发中敏捷方法的整体应用情况,并且结合表 1所述的不同类型的嵌入式开发,详细阐述敏捷方法在每个类型的开发中的应用情况.
对于第2个问题,我们将按照表 1所述的不同嵌入式开发类型,分别阐述每个类型的嵌入式开发所面临的挑战和敏捷方法应对这些挑战的具体做法.
同样地,对于第3个问题,我们也将结合不同类型的嵌入式开发,描述敏捷方法通常应该如何进行扩展和改进.
我们对最后入选的文献,按照其发表年份进行统计,结果如图 2所示.从图中可以看出:嵌入式开发中的敏捷应用相关研究起始于2002年,并且分布于之后的各个年份;除了2009年以外,相关的研究一直呈上升态势,并在2010年达到峰值.让我们非常感兴趣的是,在2011年和2012年,相关的研究数量显著偏低.可能的原因是敏捷开发相关的研究经过10年的发展,已经日趋成熟,暂时没有新的研究热点出现.相信伴随着物联网、移动计算、信息物理融合系统等新的技术和研究热点的出现,也会带来敏捷开发相关研究的新挑战.如何更好地在与前述新趋势紧密相关的嵌入式开发中应用敏捷方法的相关研究和实践,需要得到加强.
 | Fig. 2 Statistical results of the publish year图 2 出版年份统计图 |
由于几乎所有文献对处于图 1所示的中间层和系统软件层的开发工作都没有严格区分,我们将这两类应用按照开发内容是否包含软硬件进行分类,分为基于现有硬件的嵌入式系统开发与软硬件协同开发两类,再加上纯硬件开发和纯应用层开发,共计4类典型的嵌入式系统开发类型.每一类开发所对应的文献数量统计如图 3所示.
 | Fig. 3 Statistical results of the literature distribution图 3 文献数量分布图 |
由图 3可以看出:在进行纯硬件开发时,敏捷方法的应用比其他类型开发明显偏少(4%).这可能是因为硬件开发往往属于系统工程范畴,其开发方法与主要应用于软件工程的敏捷方法并不能天然融合.此外,敏捷方法所鼓励的一些实践,例如简单设计、重构等,可能由于硬件返工代价高昂,往往更加适合纯软件项目的开发,在硬件开发中也不能很好地应用.基于现有硬件进行的软件开发和在应用层上的软件开发尽管在嵌入式软硬件平台的限制程度上有一定的差异,但是从某种角度上也可以视作软件开发,相应地,大量研究文献(前者55%,后者34%)也证实了敏捷方法在这两类嵌入式开发当中的应用状况.这其中比较特殊的是软硬件协同开发,但我们并没有发现很多研究文献(7%).然而我们认为,这种类型的嵌入式开发既有硬件开发的特征,限制了比较多的敏捷实践的应用.另一方面,其软件部分的研发又使得大量敏捷实践可以得到应用.而且在实际开发过程中,往往需要软硬件的开发相互协调,软件部分的研发和硬件部分的研发都可以给对方既提供灵活性,又产生了限制.从这个意义上说,在软硬件协同开发这类嵌入式系统开发中,可能更加需要研究和开发适用的敏捷过程和实践.
在远离底层硬件的嵌入式系统开发中,开发工作有着良好的操作系统支持,包括完善的系统调用、便捷的设备驱动等等.相对于传统的软硬件结合的嵌入式系统开发,这些都在很大程度上减少了开发人员的负担,使得他们可以相对轻松地完成开发工作.
由于智能手机的迅速普及和敏捷方法的流行在时间方面有着相当大的重叠,我们在设计检索关键词的时候,将两方面概念进行了“And”操作,这使得在我们检索到的文献中,大部分应用层的嵌入式系统开发都属于手机应用程序开发,因此,我们将着重结合手机应用程序开发的特点来阐述我们的发现.
随着Android和iOS等平台的快速发展与逐渐成熟,诸如游戏、工具、音乐、阅读和摄影之类的手机应用已成为开发者们非常热衷于从事的项目.从这一点上来看,手机平台有着便捷的开发方式和稳定的开发环境,似乎不再像传统的嵌入式系统一样,受到硬件平台等因素的制约.然而我们根据调查发现,在手机应用的开发过程中或多或少仍然有着各种各样的挑战,见表 7.
|
|
Table 7 Challenges of mobile application development 表 7 手机应用开发挑战 |
(1) 基本需求
鉴于大众日常使用手机的需要,一个完善的手机应用产品必须要具备对移动性和便携性的支持,并很可能需要有无线通信等手机平台所不能忽视的功能需求,这是其之所以成为手机应用的关键因素.除此之外,实时性、健壮性和安全性等非功能需求也是开发过程中不可忽视的部分.这些独特的要求形成了这类软件开发的部分挑战.
(2) 多样的标准、协议与技术
计算机科学技术发展迅猛,手机作为其重要的受益者也经历着快速的技术变革.迅速发展的手机应用开发标准、通信协议与编程技术也在不断增加这类嵌入式系统开发的困难.
(3) 设备功能有限
手机的处理器、内存和其他部件的性能都在随着技术的发展而不断增强.尽管如此,手机作为移动设备还是会受到很多硬件方面的限制,比如说屏幕大小、键盘、内存容量和电池电量等等.相应地,手机应用虽然成为一个热门的领域,但是开发人员仍然要仔细考虑硬件的承受能力.
(4) 手机用户的特殊需求
手机用户与终端进行交互时的感受在很大程度上决定了其是否会长期使用一款产品,这对开发者来说至关重要.然而,除了人机交互时带来的体验以外,手机用户还有许多特殊的隐私和自定义需要,也使得开发工作的复杂度上升.另外,考虑到普通用户在计算机相关领域的非专业性,他们常常无法准确描述自己的需求,这与其他因素一起,导致了用户需求的频繁变化.
(5) 严格的上市时间需求
受经济利益的直接推动,大部分公司不会允许开发人员用半年、一年甚至更长的时间开发一款手机应用,快速的开发周期也为开发工作增加了难度和变数.产品推向市场的速度和策略都将成为产品是否盈利、盈利多少的关键因素,只有对市场有充分的认识,才能让产品取得成功.
(6) 开发人员缺乏经验
热门的领域总会不断吸引大量的从业者,手机应用开发亦是如此.然而一开始便具有相关技术才从事这一领域的开发者寥寥无几,大多数人都要在某个实际项目的进展过程中学习新的知识与技术.这些技术不仅局限于陌生的开发框架与各种编码细节,而且也包括将要开发的软件所属的领域,如商务、娱乐和体育等等.软件公司在决定雇佣一名缺乏经验的开发者的同时,也将承担相应的风险.
敏捷方法作为一种应对快速变化的需求的开发方法,更强调开发团队与业务专家之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中人的作用.理论上来讲,敏捷开发中的实践可以让开发人员专注于尽快交付具有高价值和高质量的软件产品,同时,快速而有效地评估技术风险并加以解决,其易实现性也有利于降低开发周期中的开销.这些优势恰好可以在很大程度上应对手机应用开发诸多挑战的需要.
(1) 基本需求
文献S5描述了应该在软件系统开发的早期详细描述嵌入式设备的物理架构,并且强制要求应用原型开发方法来降低技术风险.文献S11则提出了包括简单设计、注重组件复用、在真实设备上进行开发和测试以及监控验收测试中最终用户行为等方式来应对本挑战.
(2) 多样的标准、协议与技术
为了应对该挑战,实践者除了采取类似上述应对基本需求挑战的策略之外,文献S5强调了通过增量和迭代式开发来缓解由标准、协议和技术的多样性带来的开发挑战.文献S12和文献S17都基于XP方法提出了若干改进,包括文献S12融合了XP,Crystal和RUP(rational unified process)而提出的Mobile-D方法,对XP方法在扩展性和生命周期覆盖方面进行了加强.文献S17则强调了在XP中引入领域知识.
(3) 设备功能有限
针对设备功能有限的问题,文献S5所建议的早期理解物理设备架构和原型开发仍然有效.此外,文献S12和文献S17所提出的方法同样可以缓解设备功能有限所带来的挑战.此外值得注意的是,文献S16验证了TDD (test driven development,测试驱动开发)这种敏捷实践的价值.
(4) 手机用户的特殊需求
前文所述的文献S11、文献S12和文献S17中所描述的敏捷实践和改进,有助于缓解这类开发困难.此外,在文献S5中专门提出来一种基于市场的新产品研发过程NPD(new product development),通过研发和市场分析两条并行的路线来完成新产品研发工作.
(5) 严格的上市时间需求
文献S11、文献S12和文献S17都试图在生产效率上做文章,以尽可能地满足严格的上市时间的要求.此外,文献S5提出了应当重视产品线工程;文献S9则提出应该重视架构设计模式的应用,以提升复用程度,从而缩短开发周期.
(6) 开发人员缺乏经验
文献S6提出了代码共同拥有、维护单元测试用例、提供缺陷跟踪系统等来使得开发团队可以相互帮助和支持,从而共享开发经验.文献S8的作者表示,Scrum和其他敏捷元素可以帮助缺乏经验并且分处全球各地的开发人员建立起整个工作的框架、组织和目的,使得他们可以将注意力集中于新技术的学习和产品开发本身.此外,通过加强质量保障活动,特别是审计活动,也可以促成经验共享.文献S9所描述的架构设计模式本身就是经验积累的产物.文献S13则提出在Scrum中特别引入持续两个星期的短周期的方式,以帮助新成员熟悉开发方法和环境.
需要指出的是,尽管我们所检索到的文献中所描述的项目或实验大都取得了成功,并对敏捷方法的使用给出了正面评价,但因为它们之中的大部分在实际开发中结合了其他方法或工具,所以我们认为不应该将其共同产生的效果仅仅归功于单一敏捷方法的使用,实践者还需要对这些敏捷方法进行更多的应用、分析和总结,从而建立起对嵌入式系统开发中敏捷方法的实施效果更加正确的理解.
敏捷方法在实践中也不可避免地碰到一些问题.例如,文献S3描述了XP所希望的最终用户频繁参与测试在手持终端面向个人的应用开发中往往难以实现;文献S11描述了简单设计和重构在手机应用系统开发中可能面临的问题,例如,过多的迭代使得简单设计容易导致系统不完整性,从而在实际项目中反复打补丁;文献S16中描述了构建的测试驱动开发所包含的模拟器与真实设备所导致的测试效率问题;文献S1中描述了缺乏必要的计划驱动实践所带来的项目结果的不确定性;文献S12描述了应用层嵌入式系统开发中,多样化的手持终端给开发人员带来的困难以及手机环境缺乏适用的测试驱动开发工具的支持等所带来的问题;文献S14指出,Mobile-D在实践中与一种假想的用户模型同时使用时,可能会存在基本原则在细节层面的不一致;文献S15的作者认为,Mobile-D中人员相对松散的组织形式,在较大型的嵌入式开发中可能会面临很多问题.
我们也发现,在我们搜集到的文献中,很少有单独讨论某一种敏捷方法原封不动地应用于某个嵌入式系统开发中的效果,更多的是试图提出一种更好的嵌入式开发解决方案.这使得我们研究不同敏捷方法的优点与缺点变得相对较为困难.大体上,我们将各种文献中对敏捷方法的改进措施加以整理,见表 8.
|
|
Table 8 How to improve agile methods in practice 表 8 敏捷方法在实践中的改进措施 |
(1) 对开发周期不同阶段的改进
这一类改进措施通常只关注于项目开发周期中的某一个具体的阶段:
在需求分析阶段,文献S10利用工具来实现需求管理,以便在产品开发过程中追踪所有需求,妥善应对需求变化.
在设计阶段,文献S9采取架构设计模式及其辅助模型来降低代码复杂度,满足敏捷原则中对于简洁性的要求,以提升产品质量.
在编码阶段,文献S6中针对代码质量不高的问题,强调了代码集体所有权的重要性,并实现对软件中发现的故障进行跟踪.
在测试阶段,鉴于手机平台相对于桌面环境可使用的物理资源有限,文献S1在开发中引入了更多的性能测试,反复考量资源的使用情况,以降低技术风险.
除了这些对原有阶段的改进之外,还有一些研究者提出加入新的开发阶段以满足嵌入式系统开发要求:
文献S1提出了在开发周期内引入项目分类的阶段,这样不仅可以使开发人员受益于之前相似项目的开发经验,而且可以帮助他们根据特定的应用类型对开发步骤进行剪裁以减轻工作负担.
文献S15的作者希望通过技术评审检查软件产品是否满足了预期用途.
总体来说,上述的大部分针对开发周期不同阶段的改进措施都在手机应用开发过程中起到了预期的作用,收到了开发人员的正面评价.在对未来工作的思考中,文献S1还提出,下一步可以在项目开发周期内引入市场调研,以使产品真正满足市场用户的实际需要.
(2) 对项目参与人员的改进
敏捷方法对“人”的作用格外强调,重视开发人员与产品使用者之间的交流,是敏捷方法的一大特色.文献S1、文献S3、文献S6和文献S14分别采用各种措施来加强手机终端用户(包括假想的用户)参与项目开发过程中包括设计与测试等在内的各个阶段,有效地识别用户及其需求,并根据用户反馈改进产品,增加产品的易用性,很好地解决了传统开发方法中用户的需求得不到完全实现的问题.文献S8将关注点放在了评审人员身上,通过交流监督开发人员是否按照要求完成任务,他们可以指出设计和编码等开发过程中需要解决的多种问题.同样地,这些针对项目参与人员的改进,也大都在实践中取得了较好的效果.
(3) 对整个开发过程的改进
有别于针对某一个具体开发阶段的改进,我们也发现不少研究人员将着眼点放在对整个敏捷开发过程的改进上.文献S5试图采用一种自上而下的迭代式增量过程来设计满足手机软件开发特点的开发模式.该研究将敏捷开发与其他方法结合,通过NPD[9]方法来强化市场意识,通过ASD(adaptive software development)[10]方法实现基于组件的开发,加强可复用性,提高产品质量.此外,文献S1在手机应用开发中引入生产线的概念来减少开发成本和开发时间,提高产品质量.文献S3以日志的形式记录敏捷方法的使用情况及其反馈中的具体数据,使得日志作者可以更好地记录并理解自己开发项目时使用的开发方法与开发 流程.
值得一提的是,虽然不是都有真实项目的成功经验加以验证,但是文献S1、文献S8、文献S10中都肯定了工具在手机应用开发中的作用.其中,文献S1描述了作者在项目中开发的一款Eclipse的插件,为他们的其他改进措施提供工具支持,文献S8采用如IBM Rational Team Concert (RTC), Rally Software, Redmine等端对端工具简化人员交流和项目管理,文献S10强调了工具应当根据敏捷开发方法的不同而具有适应性.
在这一部分,我们集中研究了远离底层硬件的嵌入式系统,重点是手机应用开发中敏捷方法的使用情况.在我们搜集到的文献中,包括Mobile-D,XP,Scrum等在内的敏捷开发方法较好地应对了手机应用开发中存在的问题,例如终端硬件功能有限、用户需求特殊且多变、开发人员缺乏经验、各种标准与协议不统一以及投放市场时间紧迫等等.另外,我们还展现了各种敏捷方法是如何改进的,这些改进措施包括对项目开发周期不同阶段的改进、对项目人员如何参与的改进以及对整个开发过程的改进.
不同于嵌入式系统应用层的软件开发,相当一部分嵌入式系统的开发要在特定专用设备上进行.通常,这些设备的硬件资源(如处理器、存储器等)非常有限,并且对成本很敏感,实时响应要求很高,这些限制因素往往极大地提高了嵌入式软件开发的复杂度和难度:一方面,它需要满足现有硬件的各种限制条件;另一方面,它又要高质量地实现各类功能.
在现有的硬件上开发,毋庸置疑,硬件设备的物理性能会带来诸多限制.根据我们检索到的文献,基于现有硬件的嵌入式的限制因素大致可以归纳为5类(见表 9).
|
|
Table 9 Restrictions of embedded software development based on existing hardware 表 9 基于现有硬件的嵌入式软件开发的限制因素 |
(1) 开发环境
嵌入式系统的开发环境与传统的软件开发环境有较大的区别,主要体现在测试环境和开发工具的选择上,这也是嵌入式软件开发的特点之一.受限于某些条件,大部分的开发都是通过模拟环境来完成早期的开发和调试工作,而模拟环境本身与实际物理环境往往都有差异,这给嵌入式开发带来了一定的困难.
(2) 资源的限制
嵌入式系统开发通常会受资源的限制(例如内存的大小、安全问题、响应时间等),尤其是在一些航天和交通系统的嵌入式系统开发中,对系统的响应时间有着严格的要求.例如,在文献S24、文献S27、文献S30、文献S34、文献S32、文献S44中的项目都提出了对实时性的需求.文献S29阐述了在新的开发环境中使用已有工具时所面临的内存限制问题,面对这样的情况,已有的系统不得不做进一步的修改,以满足内存的要求.资源的限制是这一层嵌入式软件开发的特点之一.
(3) 动态的环境
在软件开发过程中,需求的不确定性和可变性往往会给嵌入式软件开发带来许多挑战.除了传统的来自用户的需求变更以外,在这一层的嵌入式开发中,硬件和技术的变化也是变更的主要来源之一,这些因素给嵌入式项目的成功带来各种风险.
(4) 开发团队成员
基于现有硬件的嵌入式软件的开发对开发人员提出了更高的要求,除了软件技术以外,往往还要有扎实的硬件知识.
(5) 质量要求
质量要求是软件开发中的普遍要求,尤其是在医疗、交通等领域的嵌入式软件开发更加注重这一点,质量属性一般包括性能、安全、可用性、正确性等方面.从某种角度来说,正是因为这类基于现有硬件的系统往往都应用于质量要求极高的领域(例如医学项目(文献S22)、通信(文献S32)等),这类项目往往将质量要求上升到不能容忍任何错误的地步,这无疑给此类嵌入式开发带来极大的挑战.
基于现有硬件的嵌入式系统开发,在开发的难度、产品的开发周期上都明显大于传统的软件开发.同时,其硬件的限制和实时性的要求都大大提高了系统的开发成本和高质量的困难.基于文献检索的结果,我们结合不同敏捷方法的应用情况,整理敏捷方法在应对本类别嵌入式开发方面的一些具体实践.
(1) 开发环境
文献S22基于XP方法提出了XPI方法,试图构建完整的测试框架,以支持嵌入式系统开发.特别地,通过扩充Simulink工具来支持模拟测试环境的构建.文献S36提出了敏捷模拟来取代硬件回路(hardware-in-the-loop,简称HIL)测试.文献S27、文献S33等都描述了在虚拟环境中是如何进行项目开发的,提及的敏捷实践包括测试驱动、每日构建、持续集成和基于场景的回归模拟测试等.文献S28强调使用Ruby语言在Rake环境下进行开发.文献S34介绍了如何使用IBM Rational系列工具来支持实时嵌入式软件的开发,例如原型构建等等.
(2) 资源的限制
这个问题是这一层嵌入式开发中较为普遍的问题.文献S26介绍了通过重构来优化代码结构,降低内存消耗.文献S27提出通过扩展现有的单元测试工具来支持非功能测试,特别是性能测试.文献S30提出通过原型开发和早期的测试来发现性能方面的风险.文献S34介绍了IBM的Rational工具在支持实时嵌入式开发方面的作用,例如,有助于最终产品的提升质量、可靠性和安全性等.文献S44提出了一系列有助于缓解硬件资源限制所带来的开发困难,例如,将实时性作为优先级最高的需求、应用重构和包含硬件环境在内的持续集成工具 等等.
(3) 动态的环境
文献S24提出了如何在企业传统度量机制下,逐步引入敏捷方法来缓解此类开发挑战.建立在敏捷方法可以更好地应对需求变更和技术演化的假设基础上,该文并没有给出具体的阐述.文献S25强调了快速交付提高了项目成功的机会.此外,该文献还将XP中的Retrospection实践引入FDD方法来提升项目的可伸缩性.
(4) 开发团队成员
文献S30提出应当在产品规划的早期就引入开发人员来识别并且排除技术风险,提前设计可行的技术方案.此外,还应当清晰定义客户(了解领域知识)和开发人员之间的沟通方式.这些手段有助于开发人员建立起对待开发系统的正确理解.文献S33和文献S37同样建议通过紧密的沟通交流来促进知识的传递.
(5) 质量要求
大体而言,对于高质量的要求,各类敏捷方法都建议通过加强测试来实现质量目标.例如,文献S22提出通过构建测试框架来覆盖各个开发阶段,从而确保最终产品质量.文献S29、文献S33、文献S34、文献S40、文献S42等提出通过测试驱动开发、持续集成等确保质量.文献S27和文献S39都提出需要改进现有测试工具,扩展其功能,以满足嵌入式开发的需要.
由于现有硬件的限制,敏捷方法并不能像传统软件开发那样百分之百地适用于这种类型的嵌入式系统开发.我们也发现,直接将敏捷方法不做任何改进就运用到系统开发中的情况极为少见.通常,各类敏捷方法都需要结合一些其他的方法、平台或者进行改进,以适应本类型嵌入式系统开发的要求.基于检索到的文献,我们总结的敏捷方法的改进主要有如下一些:
(1) 有选择地结合使用敏捷方法
文献S21提出了综合使用XP,Scrum和敏捷设计模式的方法.它还提出,要在此基础上稍作一些改变以适应嵌入式开发的特性.文献S25结合了XP,Scrum,FDD和敏捷过程模型的特性,开发了一套专为嵌入式系统开发设计的敏捷开发流程.
(2) 结合测试框架使用敏捷实践
我们在对文献的研读过程中发现,值得注意的一点是:对敏捷在嵌入式系统中的使用方法的研究,更倾向于将重点放在嵌入式的测试领域,几乎所有的文献都提及了测试,其中,文献S22、文献S26、文献S29、文献S34、文献S36、文献S37、文献S39、文献S40、文献S42、文献S32、文献S44都包括了针对测试的实验和结果的讨论.结合上面的分析结果我们了解到,测试驱动开发是嵌入式软件开发中研究较多的一种敏捷方法.这里的测试技术既包括对硬件平台的测试,也包括对嵌入式软件的测试.
(3) 结合Gate Model使用
Gate Model是一种现有的成熟的开发理论,文献S30提出了要结合使用XP和Gate Model的观点,使用Gate Model一方面是考虑到了开发成员的原先的开发习惯;另一方面,它能够很好地与敏捷结合来克服一些硬件限制带来的开发困难.
(4) XPI理论
基于现有的XP方法,为了更好地适应嵌入式软件开发,文献S22和文献S29在敏捷方法XP上做出了一些调整,提出了新的XPI方法论和一个单元测试的框架.
软硬件协同设计,是指对系统中的软硬件部分使用统一的描述和工具进行集成开发,可完成全系统的设计验证并跨越软硬件界面进行系统优化.这种类型的嵌入式系统开发与直接在现有硬件上的嵌入式开发相比,在一定程度上减少了硬件对软件开发的限制.但是同样地,软硬件的开发相互协调,也会在一定程度上增加开发的难度.在我们检索到的文献中,对这种类型的研究并不多,只有3篇文献提及了软硬件协同开发.
文献S18中提到,当软硬件协同开发时,应用Scrum方法时要注意进度协调.作者发现:在一个Sprint周期里,硬件的开发速度往往赶不上软件.文献S27中使用了E-TDD——一个软件测试驱动开发的工具,来辅助开发一个软硬件协同开发的项目.文献S35则是在软硬件协同开发中提出如何使用XP方法,特别是用户故事来分割软件和硬件的部分.
我们的文献检索结果表明,嵌入式系统的硬件开发中运用敏捷方法的非常稀少,最终,一共有2篇文献提及这方面的内容(文献S43和文献S7).
文献S43中描述了一个可编程门阵列电路板的开发,在整个开发过程中,运用了敏捷测试方法通过软件来测试硬件的可用性.此外,还运用到了持续集成的概念来确保硬件的功能开发的完整性和各个模块的匹配性.文献S7中借鉴了敏捷方法中大量的原则和实践来完成一款汽车的设计和生产,具体包括以用户的满意度为核心、变化的需求的应对、缩短迭代周期等在内.尽管文献数量偏少,但我们可以认为,敏捷方法的一些原则和实践对于硬件的开发也有一定的指导意义.然而,由于硬件开发属于系统工程的范畴,与软件工程还是有一定的差异,因此,具体开发实践和使用的开发工具还是存在显著差异的.例如,在硬件开发中用到的可编程逻辑设备开发支持工具Quartus,Finite Element Analysis(FEA)模拟器等,在一般的软件开发中不会用到.而演化式设计等敏捷实践,在硬件开发中往往也难以应用.
从我们收集的文献内容来看,敏捷方法已经或多或少地应用在各类嵌入式软件开发之中.相对而言,在应用层的开发和基于现有硬件的嵌入式软件开发之中,敏捷方法的应用已经较为成功,多篇文献都提及了如何在嵌入式开发中应用敏捷实践.在这些文献之中,XP是嵌入式开发中应用较为广泛的敏捷方法,一方面可能是因为XP包含较多技术实践,这些技术实践单独来看,其应用的限制条件远少于覆盖完整的开发周期的某个开发方法;另一方面,XP也是最早流行的敏捷方法之一,其影响范围较为广泛.XP方法在应用层开发中结合了手机开发特征演化出了Mobile-D方法;在基于硬件的纯软件开发中,XP的一些实践,例如测试驱动开发、重构等都得到了较为广泛的应用.其他敏捷方法,例如Scrum,FDD,RUP等在不同的嵌入式系统开发项目中也得到了部分应用.相对来说,在软硬件协同开发和纯硬件开发类型的嵌入式项目开发中,敏捷方法的应用案例还比较有限.
在我们所收集的文献中,敏捷方法已经在多次在嵌入式开发当中得到验证,有助于解决或者缓解嵌入式开发的多种挑战.例如,敏捷方法中的短周期迭代、早期用户介入、重构等实践都有助于应对伴随着嵌入式系统应用范围日益扩大所带来的需求多变的挑战.敏捷方法所提倡的自动化测试鼓励开发团队在项目早期就开始构建包含硬件在内的测试环境或者模拟环境,尽早识别相当一部分嵌入式开发中的硬件设备的物理性能所带来的各种限制和这些限制可能带来的性能风险,有助于项目的成功.此外,敏捷方法对测试的极为重视,也在很大程度上保证了最终产品的高质量.还需要指出的是,敏捷方法倡导的项目人员之间的紧密沟通,有助于项目相关知识的传递.
同时我们也注意到,一种敏捷方法很难单独在嵌入式项目当中得到应用,往往都需要对原始的敏捷方法进行适当的扩展,才可以适应嵌入式项目开发的要求.这些扩展和改进大致包括如下内容:
首先,在原有的敏捷开发过程中增加新的实践来满足嵌入式开发的要求(例如市场分析、设备模拟测 试等).
其次,对原有的敏捷实践进行增强,如XPI,Mobile-D等.
再次,另一种对敏捷方法的扩展,非常典型地体现在测试工具的改进之上,例如专用的单元测试工具和非功能测试工具等.特别地,很多时候,这些工具都需要嵌入式系统开发团队根据需要自行定制或者 开发.
最后,单一的敏捷方法往往需要借鉴其他敏捷方法的部分实践来扩展其生命周期的覆盖.
我们在试图建立敏捷方法在嵌入式系统开发中的应用状况的整体理解时,尽管通过系统评价方法,尽可能地去避免研究者的主观因素对研究结果所带来的影响,但是,仍然有一些内在的因素使得这类偏向性不可能完全避免:
首先,我们的研究对象仅仅包含英文文献,这样的选择,不可能完全避免一些其他语言写就的高质量论文被忽略的现象.但是,该领域高质量论文比较集中的几个期刊和会议,都要求用英文来撰写论文,因此,这个问题可能不会对最终结果产生根本性影响.
其次,学术界往往倾向于报告成功的案例(例如,本研究所列入的项目几乎都是成功案例).该现象导致我们只能从发表的文献中看到部分敏捷方法在嵌入式开发中应用的好的方面,而看不到敏捷方法对嵌入式系统开发可能造成的负面影响.换句话说,敏捷方法可能对嵌入式开发造成哪些困难,我们暂时无从知晓.我们认为,后者也应当引起研究者和实践者的重视,开展更多的工作,从而更好地在嵌入式系统开发过程中应用敏捷方法.
最后,敏捷方法的工业背景比较浓厚,不是所有使用敏捷方法的嵌入式软件开发都会形成正式发表的论文,并被我们收集到.换句话说,非常有可能有大量实践经验总结性质的资料未被列入我们的研究范围,例如一些项目总结和论坛讨论等.此外,为了确保研究结果的可靠性,我们通过表 3的质量标准,排除了很多文献.从图 2所展示的实际数据上看,列入我们研究范围的文献数量还是有限的,这是为了保证系统评价中证据质量和相关性所做的必要牺牲.因此,我们现阶段关于该研究课题的结论不可避免地带有一定的局限性,我们也打算继续就该课题深入研究,以期获得更多有价值的信息.
我们在研究中发现,几乎每一篇文献都在努力提出所谓全新的解决方案来满足嵌入式系统开发项目的需要.这使得单纯考察某一个敏捷方法的应用情况变得困难;另一方面,来自于实践经验总结的敏捷方法也缺乏严格的方法定义,这也使得现阶段我们往往只能看到某些敏捷实践在一定项目环境(上下文)中对嵌入式系统开发有用.这事实上也在一定程度上限制了我们的研究结果在更加广泛的嵌入式系统开发中的借鉴价值.
在检索文献所用的关键词组合中,主要包含了敏捷与嵌入式两部分的关键词组合.其中:
第1部分包括多种敏捷方法的名称.特别需要说明的是,RUP事实上是否属于敏捷方法还是存在一定的争议,本次检索,我们仍然加入“RUP”作为关键词的一部分.
第2部分与嵌入式系统开发相关,为了平衡敏感度和精确度,关键词“sensor”,“Real-time”,“Medical devices”,“Multimedia”与“Middleware”被排除出搜索范围.此外,通过人工搜索我们发现:只包含“android”或“iOS”但不包含“mobile”的文献量极少,而只包含“mobile”的文献量已经足以支持我们进行结果分析.为了兼顾敏感度与精确度,我们排除了与特定便携式移动平台相关的词语.
此外,正如前文所述,敏捷方法的盛行与智能手机的流行,在时间上有相当大的重叠,这使得我们在分析应用层敏捷方法的应用状况时,手机应用开发较为突出.随着嵌入式方面新的技术和研究热点的出现,从敏捷方法的角度出发,也相应地会有更多的研究,我们也将持续关注这些研究动态.
应用系统评价方法,本文对敏捷方法在嵌入式系统开发中的应用情况进行了概括和分析.应用严格的质量要求对相关领域的文献进行筛选,最后将44篇高质量的文献纳入研究范围.针对3个研究问题,即,应用总体状况、敏捷方法应对嵌入式开发挑战和敏捷方法的改进,我们的研究表明,在嵌入式系统开发中,可以应用敏捷方法来满足嵌入式项目的一些特殊要求.同时,部分敏捷实践也需要进行适当的改进和扩展,以更好地在嵌入式系统开发中应用.本文的主要贡献在于:
第一,敏捷开发和嵌入式开发近年来日益盛行,然而将两个热点结合得较为系统的研究非常少.我们的工作可以为后续这方面的研究打下基础.
第二,对于实践者而言,通过我们的工作所整理和归纳的结果,实践者可以建立如何在嵌入式系统开发中使用敏捷实践来缓解嵌入式系统的一些特征所引起的开发挑战的基本思路,并从别人的工作当中找到改进和扩展已有开发实践的方法.
第三,对于研究者而言,由于我们的研究较为系统地总结了嵌入式开发中的挑战以及目前敏捷实践在应对嵌入式开发的困难的初步尝试,换句话说,仍然需要更多的研究来更好地在嵌入式开发中应用敏捷方法.这从某种意义上说,也可以为研究者提供更多的科研机遇.
基于现阶段的研究结果,我们认为如下一些方面可以作为未来需要深入研究的内容:
第一,就现有的研究结果来看,对于嵌入式开发的哪些特征会显著影响敏捷方法的效果,目前还没有充足的实践和研究.一方面,可能是因为前述的出版偏向性(publication bias,即,大部分文献都描述成功案例),很多嵌入式开发中的经验教训未能在研究论文中体现;另外一方面,现有对于敏捷实践的实证研 究[11]还未能结合具体应用领域(例如嵌入式).因此,我们期待研究者和实践者就该问题开展更多的工作,并报告研究结果.
第二,敏捷方法如何更好地适应嵌入式开发中的新的技术发展趋势.事实上,在本文成文过程中我们也同样发现,从2011年开始的调查报告中,如何集成新的技术和工具已经成为整个嵌入式相关行业普遍关注的问题.因此,我们也期待研究者和实践者结合新的技术发展趋势不断探索适合嵌入式开发特征的开发方法,以满足来自于整个社会日益增加的嵌入式系统应用需求.
| [1] | Boehm BW, Abts C, Brown AW, Chulani S, Clark BK, Horowitz E, Madachy R, Reifer DJ, Steece B. Software Cost Estimation with COCOMO II. Bergen Country: Prentice Hall PTR, 2000. 1-82. |
| [2] | UBM-Electronics embedded.com & EE times the 2011 embedded market study. 2011. http://e.ubmelectronics.com/embeddedstudy/ |
| [3] | UBM-Electronics embedded.com & EE times the 2012 embedded market study. 2012. http://eesage.com/pages/3332259-embedde d-market-study |
| [4] | Babar MA, Zhang H. Systematic literature reviews in software engineering: Preliminary results from interviews with researchers. In: Dybá T, ed. Proc. of the 2009 3rd Int’l Symp. on Empirical Software Engineering and Measurement. New York: IEEE Computer Society, 2009.346-355 . |
| [5] | Kang YM, et al. Embedded System Design. Beijing: China Machine Press, 2007. 1-5 (in Chinese). |
| [6] | Biolchini J, Mian PG, Natali ACC, Travassos GH. Systematic review in software engineering. Technical Report, RT-ES 679/05, Rio de Janeiro: System Engineering and Computer Science Department, PESC-COPPE/UFRJ, 2005. |
| [7] | Kitchenham BA, Charters S. Guidelines for performing systematic literature reviews in software engineering. Technical Report, EBSE-2007-01, 2007. http://www.dur.ac.uk/ebse/ |
| [8] | Zhang H, Babar MA, Tell P. Identifying relevant studies in software engineering. Information and Software Technology, 2011, 53(6):625-637 . |
| [9] | Koen P, Ajamian G, Burkart R, Clamen A, Davidson J, D’Amore R, Elkins C, Herald K, Incorvia M, Johnson A, Karol R, Seibert R, Slavejkov A, Wagner K. Providing clarity and a common language to the ‘fuzzy front end’. Research Technology Management, 2001,44(2):46-55. |
| [10] | Highsmith JA. Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. New York: Dorset House, 2000. 1-331. |
| [11] | Esfahani HC, Yu E. A repository of agile method fragments. In: Proc. of the New Modeling Concepts for Today’s Software Processes. Berlin, Heidelberg: Springer-Verlag, 2010. 163-174. |
| [5] | 康一梅,等.嵌入式软件设计.北京:机械工业出版社,2007.1-5. |