軟件是一種靈活的、可延展性的媒介，它在很大程度上促進了迭代分析、設計、構造、驗證和確認，這比通?？赡苡糜谙到y的純粹物理組件的程度要高。迭代開發模型的每次重復都會向不斷增長的軟件基礎中添加材料(代碼);對擴展的代碼庫進行測試，根據需要重新編寫，并進行演示，以滿足基線的需求。

軟件開發的過程模型支持在不同長度的周期上進行迭代開發。表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