迭代式软件开发模型研究及应用
2015-08-07师迎海何雪慧
师迎海,何雪慧
(中国空空导弹研究院,洛阳471009)
迭代式软件开发模型研究及应用
师迎海,何雪慧
(中国空空导弹研究院,洛阳471009)
对各种迭代式软件开发模型进行了剖析,并论述了在军工嵌入式软件开发过程中如何选取、裁剪和运用迭代式软件开发模型。
迭代;软件开发模型;嵌入式软件
1 引 言
软件开发模型是用于指导软件开发全过程的活动和任务的框架,软件开发人员需按照其指定的步骤进行软件开发。但实际上,由于每种开发模型都有其局限性,很少有开发团队完全遵循开发模型的规定进行软件开发。开发模型的局限性集中体现在软件开发活动的不可预测性,如系统需求变更、软件需求变更、实验结果不理想导致的设计算法变更等。嵌入式软件对硬件的依赖性较强,在软硬件并行开发过程中,系统变更在所难免、系统联试过程中软件本身的变更也不可避免,传统的瀑布模型无法适应变更需求。软件项目所经历的无数次失败促使研究人员致力于寻找其他更好的方法,由此产生了迭代式开发模型。
2 基于变更驱动的软件开发模型
对于军工嵌入式软件来说,其开发阶段一般包括:系统分析与定义、软件需求分析(包含软件策划)、软件设计、软件实现、软件测试。软件变更类型有以下几种:系统需求变更、软件需求变更、软件设计变更、软件代码变更,在软件开发的各活动中均可能产生这四种类型的变更。每次变更均会导致后续需要开展的活动的迭代,变更的原因多种多样,但一般以总体部门下发的技术协调单、测试部门提出的问题报告单等形式为变更提供依据(见图1)。
图1 基于变更驱动的软件开发模型
使用该模型最重要的是要对所有的变更进行管理,最好是建立变更管理系统,对每个变更进行标识,记录变更的重要属性,如变更类型、变更原因,变更内容,影响域等。该模型的输出一是最初各活动产生的输出,二是变更,三是由变更带来的各活动输出的升级版。该模型的特点是能够适应不同类型的变更,但是,为了适应变更在进行软件策划时需要尽早考虑对策,如建立变更分配制度,一旦确定有变更,项目负责人根据变更类型将变更任务分配给在其影响域范围内的相关活动负责人,并制定计划针对变更内容对工作产品进行升级。预先对变更进行控制的方法可以参考风险控制的原理,将风险带来的影响控制在最小范围。
3 统一过程模型
该模型融入了瀑布模型的线性结构和演化模型的增量和迭代思想。首先建立整个项目的不同阶段,包括“初始阶段”、“细化阶段”、“构造阶段”、“移交阶段”,同时每个阶段中又保留了瀑布模型的活动,这里称之为工作流[1],即从系统分析与定义、软件需求分析(包含软件策划)到设计、实现和测试这五个活动。所以我们可以理解为一个二维坐标、工作流是一个纵坐标,阶段构成了横坐标。但是,二维坐标并不是统一过程的主要思想,它的主要思想是每个纵坐标制定的活动可能会产生多次迭代,每个迭代会随着横坐标(阶段)的进展而产生变更,最终逐渐减少直至消失。每个阶段都能构成一个里程碑,在每个里程碑上捕捉到软件项目生命周期中的重要决策点,如初始阶段关注的是项目计划和风险评估,细化阶段关注的是系统总体架构,构造阶段则关注建立系统等(见图2)。
图2 系统的总体框架
该模型既能适应变更需求,又能够很好地适应军工嵌入式软件随硬件进行分阶段管理的情况。
4 其他迭代式软件开发模型
其他迭代式软件开发模型还有螺旋模型、基于构件的软件开发模型、喷泉模型、原型实现模型、增量模型、演化模型等。
螺旋模型强调风险分析[2],采用螺旋模型需要具有相当丰富的风险评估经验和专门知识,在风险较大的项目开发中,如果未能够及时标识风险,势必造成重大损失;基于构件的软件开发模型需要创建构件库,长期积累可用的构件,且需要精干的有经验的开发人员分析决策构件的可用性;喷泉模型是一种以用户需求为动力,以对象为驱动的模型,主要用于描述面向对象的软件开发过程;原型实现模型首先快速实现一个可实际运行的系统雏形,通过与用户沟通,再进行下一轮迭代,直到用户满意为止,其缺点是产品原型在一定程度上限制了开发人员的创新,没有考虑软件的整体质量和长期的可维护性,由于达不到质量要求产品可能被抛弃,而采用新的模型重新设计,因此原型实现模型不适合嵌入式、实时控制等大型软件系统的开发;增量模型采用随着日程时间的进展而交错的线性序列,每一个线性序列产生软件的一个可发布的“增量”[3],增量模型与原型实现模型一样本质上是迭代的,但与原型实现不一样的是其强调每一个增量均发布一个可操作产品,早期的增量是最终产品的“可拆卸”版本,提供了为用户服务的功能,并且为用户提供了评估平台,避免了因质量不过关而重新设计的风险;演化模型也是通过构造系统的各个可执行的工作版本来开发系统的,但是,与增量型生存周期模型的区别是承认需求不能被完全了解,且不能在初始时就确定,在该方法中,需求一部分被预先定义,然后在每个相继的工作版本中逐步完善。
通过以上分析,增量模型和演进模型最适合于指导嵌入式软件的开发过程。
5 军工嵌入式软件开发模型的选用
增量式模型和演进式模型均引入了迭代思想,但却是对从系统分析与定义到软件测试整个研制过程中包含的所有活动的迭代。而迭代不仅仅发生在系统需求变化时,研制过程中各个阶段都可能发生变更,一旦变更就需要从变更活动开始往后迭代。因此,以上两种模型适用于软件需要分阶段进行开发,对于每个构建版软件需求、设计和实现一旦形成都比较稳定,较少反复。
基于变更驱动的软件开发模型和统一过程模型充分运用了迭代原理,可以用于指导软件开发的各项活动均易产生变更情况,但其缺点是各项活动的进度难以计划。基于变更驱动的软件开发模型和统一过程模型适用于在软件开发的各阶段均会产生较多的变更情况。基于变更驱动的软件开发模型适用于软件不需要分阶段管理的情况,统一过程模型适用于软件需要分阶段管理的情况。
对于软件规模小、复杂度低的嵌入式软件,其研制任务不需要分阶段进行管理,如果研制活动中产生变更较少,不需要进行迭代,那么可以直接选取瀑布模型,如果易产生需求、设计变更,那么应选取基于变更驱动的软件开发模型。对于软件规模较大、复杂程度高的软件需要分阶段进行管理,如果在各开发阶段研制任务是不一样的,一旦研制任务确定,其他活动中将会产生较少变更,可以选取增量模型或演化模型,如果变更频繁应选取基于变更驱动的软件开发模型或统一过程模型。
6 军工嵌入式软件开发模型的裁剪和运用
所有的模型都是要为特定的软件项目服务的,不能生搬硬套,可以根据各自项目的特点进行裁剪和运用。下面是研究成果在实际项目中的运用情况。
项目一属于预研类项目,暂时仅对初样阶段有要求。在初样阶段只需要一个软件原型,通过这个原型去试验和验证产品所能达到的技术指标,这样,在本阶段只需要关注软件实现,其他活动的开展均为软件实现活动服务,这种情况下选用了原型实现模型,其输出的工作产品是一个可实际运行的软件雏形。
项目二的软件规模较大且与硬件结合较为紧密。系统研制已经严格划分为F、C、S、D阶段,这样的划分更适合选取以上所述的能够产生多个构建版的迭代式软件开发模型,在每个阶段各输出一个或多个构建版,同时要对每个构建版所包含的活动进行适当裁剪。该项目选取了统一过程模型,将模型中的“初始阶段”、“细化阶段”、“构造阶段”和“移交阶段”规定成军用嵌入式软件开发所采取的“F”、“C”、“S”和“D”这四个阶段。在每个阶段关注不同的活动,仅要求我们关注的活动有正式的输出产品,例如,在F阶段仅关注软件实现,正式的输出产品是能够在系统中正常运行的代码。同时,由于各阶段内所有的活动均可以迭代,各阶段产生构建版的数量由迭代次数决定。
7 结束语
迭代式软件开发模型因其灵活性、对需求变更的适用性,已经渐渐取代了常用的瀑布式模型。通过对各种迭代式软件开发模型的研究,充分论述了如何在军用嵌入式软件中选取、裁剪和运用这些模型,并将文中所述思想应用到了多个型号软件开发活动的策划和指导中,通过实践证明了模型运用的有效性。
[1] Jones C.Estimating software costs:Bring realism to estimating[M].2ed.New York:McGraw-Hill,2007.
[2] 黄绍良.软件开发模型面面观[J].中国计算机用户,2008(31):43-44.
[3] 张友生,李雄.软件开发模型研究综述[J].计算机工程与科学,2006(3):110.
[4] McDermid J,P Rook.Software Engineer’s Reference Book[M].CRC Press,1993.
Research and Application of Iterative Software Developing Model
Shi Yinghai,He Xuehui
(China Air-to-air Missile Academy,Luoyang 471009,China)
All kinds of iterative software developing models are analyzed in this paper,and how to select,cut and use them for developing themilitary industry embedded software is discussed.
Iterative;Software developingmodels;Embedded software
10.3969/j.issn.1002-2279.2015.01.016
TP311
A
1002-2279(2015)01-0055-03
师迎海(1979-),男,河南洛阳人,高级工程师,硕士,主研方向:软件工程。
2014-07-16