三种迭代软件开发模型的主要重点

软件是一种灵活的、可延展性的媒介，它在很大程度上促进了迭代分析、设计、构造、验证和确认，这比通常可能用于系统的纯粹物理组件的程度要高。迭代开发模型的每次重复都会向不断增长的软件基础中添加材料(代码);对扩展的代码库进行测试，根据需要重新编写，并进行演示，以满足基线的需求。

软件开发的过程模型支持在不同长度的周期上进行迭代开发。表1列出了三个迭代的软件开发模型，它们在下面更详细地展示，以及这些模型所强调的软件开发的各个方面。

表1。三种迭代软件开发模型的主要重点。

迭代式模型	强调
增量构建	对替代方法的基于风险的迭代分析和结果的敏捷评估
迭代实现-验证-验证-演示循环往复	需求和代码的迭代演进

请注意，下面的信息特别关注软件系统的不同生命周期模型的使用情况。为了更好地理解软件工程(SwE)和系统工程(SE)之间的交互，请参阅第6部分中的系统工程和软件工程。

迭代开发过程模型概述

开发和修改软件涉及到创造性的过程，这些过程受到许多外部和可变力量的影响。长期的经验已经表明，第一次“把它做好”是不可能的，并且迭代开发过程比线性的、顺序的开发过程模型(如著名的瀑布模型)更可取。在迭代开发中，迭代的每个周期都包含前一个迭代的软件，并向演进的产品添加新功能，以创建软件的扩展版本。迭代开发过程提供了以下优点:

v持续集成、验证和演进产品的验证;

v经常展示进步;

v尽早发现缺陷;

v过程问题的预警;

v系统地整合集成软件开发中不可避免的返工;及

v尽早交付子集功能(如果需要的话)。

迭代开发在SwE中有多种形式，包括:

v增量构建，用于产生周期性的(通常是每周的)增加产品能力的构建;

v敏捷开发，用于将原型客户紧密地卷入可能每天重复的迭代过程中;及

v螺旋模型，用于对抗和减轻在开发产品的后续版本中遇到的风险因素。

增量构建模型

增量构建模型是一个迭代周期的构建-测试-演示模型，在该模型中，经常强调进展的演示、验证和对当前工作的验证。该模型基于稳定的需求和软件架构规范。每个构建都向增量增长的产品添加新的功能。当最终版本被客户验证、验证、演示和接受时，过程结束。

表2列出了一些将增量开发划分为(通常)每个日历周的增量构建单元的划分标准。增量和可用于项目的开发人员数量决定了每个增量构建中可以包含的特性数量。这进而决定了整个时间表。

表2。一些增量构建的分区标准。

系统	划分的标准
应用包	优先级的功能
安全-关键系统	安全第一(优先)特性;其他优先级遵循
用户密集系统	用户接口优先;其他优先级遵循
系统软件	内核优先;实用程序遵循

图5演示了增量构建过程中的构建-验证-验证-演示周期的细节。每个构建都包括由开发人员完成的详细设计、编码、集成、评审和测试。在不需要修改就可以复用代码的情况下，增量构建的部分或全部可能包括对使用复用代码扩展的基本代码的评审、集成和测试。重要的是要注意到，开发一个增量可能会导致为集成而重新开发的以前的组件，以修复缺陷。

增量验证、验证和演示，如图5所示，通过以下方法克服了瀑布方法的两个主要问题:

尽早暴露问题，以便在问题发生时予以纠正;及

将次要的范围内变更合并到需求中，这些需求是后续构建中增量演示的结果。

图5还说明了重叠产品的连续构建是可能的。例如，在验证当前版本时，可以开始对下一个版本进行详细设计。

三个因素决定可实现的重叠程度:

图5。增量的构建-验证-验证-演示周期。

Ø人员的可用性;

Ø较前一版本取得足够进展;及

Ø由于对前一个正在进行中的构建的变更，对下一个重叠构建的重大重做的风险。增量构建过程通常在小型团队中工作得很好，但是可以在较大的项目中进行扩展。

增量构建过程的一个显著优势是，首先构建的特性会得到最频繁的验证、验证和演示，因为随后的构建会合并早期迭代的特性。例如，在构建控制核反应堆的软件时，可以首先构建紧急关闭软件，因为它将随后结合每一个后续构建的特点进行验证和确认。

总之，增量构建模型，像所有的迭代模型一样，提供了持续集成和演进产品的验证、频繁的进展演示、问题的早期预警、子集功能的早期交付，以及软件开发中不可避免的返工的系统集成。

原型设计在软件开发中的角色

在SwE中，原型是系统某些部分所需功能的模型。这与物理系统相反，在物理系统中，原型通常是系统的第一个全功能版本。

在过去，将原型软件集成到生产系统中会产生许多问题。原型设计是一种有用的技术，应酌情使用;然而，原型设计不是软件开发的过程模型。在构建软件原型时，通过开发原型获得的知识对程序是有益的;然而，原型代码可能不会在系统的可交付版本中使用。在许多情况下，使用通过原型设计获得的知识从头构建产品代码比重新设计现有代码更有效。

软件的生命周期维护

与所有系统一样，软件需要持续付出来增强功能、适应新环境和纠正缺陷。软件的主要区别在于，维护工作会改变软件;与物理实体不同，软件组件不需要因为物理损耗而被替换。变更软件需要重新验证和重新确认，这可能涉及到广泛的回归测试，以确定变更具有预期的效果，并且没有改变功能或行为的其他方面。

报废的软件

有用的软件很少被淘汰;然而，有用的软件在其生命周期中经常经历多次升级。以后的版本可能与最初的版本没有多少相似之处。在某些情况下，在以前的操作环境中运行的软件在硬件模拟器上执行，这些模拟器在较新的硬件上提供虚拟机。在其他情况下，主要的增强可能会替换并重命名软件的旧版本，但是增强的版本以一种兼容的方式提供了以前软件的所有功能。然而，有时软件的新版本可能无法提供与旧版本的兼容性，这就需要对系统进行其他变更。

主要是演进和并发流程:增量承诺螺旋模型

增量承诺螺旋模型概述

增量承诺螺旋模型(ICSM)的视图如图6所示。

Figure 6.增量承诺螺旋模型(ICSM)

在ICSM中，每个螺旋都同时而不是顺序地处理需求和解决方案，以及产品和过程、硬件、软件、人的因素方面，以及替代产品配置或产品线投资的业务案例分析。利益攸关方考虑风险和风险缓解计划，并决定行动方针。如果风险是可接受的，并且被风险缓解计划所覆盖，那么项目将继续进入下一个螺旋。

在第一次开发承诺评审之后，开发遵循三团队增量开发方法，以实现图2中所示的敏捷性和保证，即系统生命周期过程驱动程序和选择的“演化-并发快速变更处理和高保证”。

原文标题：迭代软件开发过程模型

文章出处：【微信公众号：汽车电子硬件设计】欢迎添加关注！文章转载请注明出处。

责任编辑：haq