迭代式软件开发模型研究及应用

2018-05-16 14:12:59

软件开发模型是用于指导软件开发全过程的活 动和任务的框架,软件开发人员需按照其指定的步 骤进行软件开发。但实际上,由于每种开发模型都 有其局限性,很少有开发团队完全遵循开发模型的 规定进行软件开发。开发模型的局限性集中体现在 软件开发活动的不可预测性,如系统需求变更、软件 需求变更、实验结果不理想导致的设计算法变更等。 嵌入式软件对硬件的依赖性较强,在软硬件并行开 发过程中,系统变更在所难免、系统联试过程中软件 本身的变更也不可避免,传统的瀑布模型无法适应 变更需求。软件项目所经历的无数次失败促使研究 人员致力于寻找其他更好的方法,由此产生了迭代 式开发模型。

2 基于变更驱动的软件开发模型

对于军工嵌入式软件来说,其开发阶段一般包 : 系统分析与定义、软件需求分析( 包含软件策 划) 、软件设计、软件实现、软件测试。软件变更类 型有以下几种: 系统需求变更、软件需求变更、软件 设计变更、软件代码变更,在软件开发的各活动中均 可能产生这四种类型的变更。每次变更均会导致后 续需要开展的活动的迭代,变更的原因多种多样,但一般以总体部门下发的技术协调单、测试部门提出 的问题报告单等形式为变更提供依据( 见图 1) 。



使用该模型最重要的是要对所有的变更进行管 理,最好是建立变更管理系统,对每个变更进行标 识,记录变更的重要属性,如变更类型、变更原因,变 更内容,影响域等。该模型的输出一是最初各活动 产生的输出,二是变更,三是由变更带来的各活动输 出的升级版。该模型的特点是能够适应不同类型的 变更,但是,为了适应变更在进行软件策划时需要尽 早考虑对策,如建立变更分配制度,一旦确定有变 更,项目负责人根据变更类型将变更任务分配给在 其影响域范围内的相关活动负责人,并制定计划针 对变更内容对工作产品进行升级。预先对变更进行控制的方法可以参考风险控制的原理,将风险带来 的影响控制在最小范围。

3 统一过程模型

该模型融入了瀑布模型的线性结构和演化模型 的增量和迭代思想。首先建立整个项目的不同阶 段,包括“初始阶段”、“细化阶段”、“构造阶段”、 “移交阶段”,同时每个阶段中又保留了瀑布模型的 活动,这里称之为工作流[1],即从系统分析与定义、 软件需求分析( 包含软件策划) 到设计、实现和测试 这五个活动。所以我们可以理解为一个二维坐标、 工作流是一个纵坐标,阶段构成了横坐标。但是,二 维坐标并不是统一过程的主要思想,它的主要思想 是每个纵坐标制定的活动可能会产生多次迭代,每 个迭代会随着横坐标( 阶段) 的进展而产生变更,最 终逐渐减少直至消失。每个阶段都能构成一个里程 碑,在每个里程碑上捕捉到软件项目生命周期中的 重要决策点,如初始阶段关注的是项目计划和风险 评估,细化阶段关注的是系统总体架构,构造阶段则 关注建立系统等( 见图 2) 。


该模型既能适应变更需求,又能够很好地适应 军工嵌入式软件随硬件进行分阶段管理的情况。

4 其他迭代式软件开发模型

其他迭代式软件开发模型还有螺旋模型、基于 构件的软件开发模型、喷泉模型、原型实现模型、增 量模型、演化模型等。

螺旋模型强调风险分析[2],采用螺旋模型需要 具有相当丰富的风险评估经验和专门知识,在风险 较大的项目开发中,如果未能够及时标识风险,势必 造成重大损失; 基于构件的软件开发模型需要创建 构件库,长期积累可用的构件,且需要精干的有经验 的开发人员分析决策构件的可用性; 喷泉模型是一 种以用户需求为动力,以对象为驱动的模型,主要用 于描述面向对象的软件开发过程; 原型实现模型首 先快速实现一个可实际运行的系统雏形,通过与用 户沟通,再进行下一轮迭代,直到用户满意为止,其 缺点是产品原型在一定程度上限制了开发人员的创 新,没有考虑软件的整体质量和长期的可维护性,由 于达不到质量要求产品可能被抛弃,而采用新的模 型重新设计,因此原型实现模型不适合嵌入式、实时 控制等大型软件系统的开发; 增量模型采用随着日 程时间的进展而交错的线性序列,每一个线性序列 产生软件的一个可发布的“增量”[3],增量模型与原 型实现模型一样本质上是迭代的,但与原型实现不 一样的是其强调每一个增量均发布一个可操作产 品,早期的增量是最终产品的“可拆卸”版本,提供 了为用户服务的功能,并且为用户提供了评估平台, 避免了因质量不过关而重新设计的风险; 演化模型 也是通过构造系统的各个可执行的工作版本来开发 系统的,但是,与增量型生存周期模型的区别是承认 需求不能被完全了解,且不能在初始时就确定,在该 方法中,需求一部分被预先定义,然后在每个相继的 工作版本中逐步完善。 通过以上分析,增量模型和演进模型最适合于 指导嵌入式软件的开发过程。

5 军工嵌入式软件开发模型的选用

增量式模型和演进式模型均引入了迭代思想, 但却是对从系统分析与定义到软件测试整个研制过 程中包含的所有活动的迭代。而迭代不仅仅发生在 系统需求变化时,研制过程中各个阶段都可能发生 变更,一旦变更就需要从变更活动开始往后迭代。 因此,以上两种模型适用于软件需要分阶段进行开 发,对于每个构建版软件需求、设计和实现一旦形成 都比较稳定,较少反复。

基于变更驱动的软件开发模型和统一过程模型 充分运用了迭代原理,可以用于指导软件开发的各 项活动均易产生变更情况,但其缺点是各项活动的 进度难以计划。基于变更驱动的软件开发模型和统 一过程模型适用于在软件开发的各阶段均会产生较 多的变更情况。基于变更驱动的软件开发模型适用 于软件不需要分阶段管理的情况,统一过程模型适 用于软件需要分阶段管理的情况。