師迎海,何雪慧
(中國空空導彈研究院,洛陽471009)
迭代式軟件開發模型研究及應用
師迎海,何雪慧
(中國空空導彈研究院,洛陽471009)
對各種迭代式軟件開發模型進行了剖析,并論述了在軍工嵌入式軟件開發過程中如何選取、裁剪和運用迭代式軟件開發模型。
迭代;軟件開發模型;嵌入式軟件
軟件開發模型是用于指導軟件開發全過程的活動和任務的框架,軟件開發人員需按照其指定的步驟進行軟件開發。但實際上,由于每種開發模型都有其局限性,很少有開發團隊完全遵循開發模型的規定進行軟件開發。開發模型的局限性集中體現在軟件開發活動的不可預測性,如系統需求變更、軟件需求變更、實驗結果不理想導致的設計算法變更等。嵌入式軟件對硬件的依賴性較強,在軟硬件并行開發過程中,系統變更在所難免、系統聯試過程中軟件本身的變更也不可避免,傳統的瀑布模型無法適應變更需求。軟件項目所經歷的無數次失敗促使研究人員致力于尋找其他更好的方法,由此產生了迭代式開發模型。
對于軍工嵌入式軟件來說,其開發階段一般包括:系統分析與定義、軟件需求分析(包含軟件策劃)、軟件設計、軟件實現、軟件測試。軟件變更類型有以下幾種:系統需求變更、軟件需求變更、軟件設計變更、軟件代碼變更,在軟件開發的各活動中均可能產生這四種類型的變更。每次變更均會導致后續需要開展的活動的迭代,變更的原因多種多樣,但一般以總體部門下發的技術協調單、測試部門提出的問題報告單等形式為變更提供依據(見圖1)。

圖1 基于變更驅動的軟件開發模型
使用該模型最重要的是要對所有的變更進行管理,最好是建立變更管理系統,對每個變更進行標識,記錄變更的重要屬性,如變更類型、變更原因,變更內容,影響域等。該模型的輸出一是最初各活動產生的輸出,二是變更,三是由變更帶來的各活動輸出的升級版。該模型的特點是能夠適應不同類型的變更,但是,為了適應變更在進行軟件策劃時需要盡早考慮對策,如建立變更分配制度,一旦確定有變更,項目負責人根據變更類型將變更任務分配給在其影響域范圍內的相關活動負責人,并制定計劃針對變更內容對工作產品進行升級。預先對變更進行控制的方法可以參考風險控制的原理,將風險帶來的影響控制在最小范圍。
該模型融入了瀑布模型的線性結構和演化模型的增量和迭代思想。首先建立整個項目的不同階段,包括“初始階段”、“細化階段”、“構造階段”、“移交階段”,同時每個階段中又保留了瀑布模型的活動,這里稱之為工作流[1],即從系統分析與定義、軟件需求分析(包含軟件策劃)到設計、實現和測試這五個活動。所以我們可以理解為一個二維坐標、工作流是一個縱坐標,階段構成了橫坐標。但是,二維坐標并不是統一過程的主要思想,它的主要思想是每個縱坐標制定的活動可能會產生多次迭代,每個迭代會隨著橫坐標(階段)的進展而產生變更,最終逐漸減少直至消失。每個階段都能構成一個里程碑,在每個里程碑上捕捉到軟件項目生命周期中的重要決策點,如初始階段關注的是項目計劃和風險評估,細化階段關注的是系統總體架構,構造階段則關注建立系統等(見圖2)。

圖2 系統的總體框架
該模型既能適應變更需求,又能夠很好地適應軍工嵌入式軟件隨硬件進行分階段管理的情況。
其他迭代式軟件開發模型還有螺旋模型、基于構件的軟件開發模型、噴泉模型、原型實現模型、增量模型、演化模型等。
螺旋模型強調風險分析[2],采用螺旋模型需要具有相當豐富的風險評估經驗和專門知識,在風險較大的項目開發中,如果未能夠及時標識風險,勢必造成重大損失;基于構件的軟件開發模型需要創建構件庫,長期積累可用的構件,且需要精干的有經驗的開發人員分析決策構件的可用性;噴泉模型是一種以用戶需求為動力,以對象為驅動的模型,主要用于描述面向對象的軟件開發過程;原型實現模型首先快速實現一個可實際運行的系統雛形,通過與用戶溝通,再進行下一輪迭代,直到用戶滿意為止,其缺點是產品原型在一定程度上限制了開發人員的創新,沒有考慮軟件的整體質量和長期的可維護性,由于達不到質量要求產品可能被拋棄,而采用新的模型重新設計,因此原型實現模型不適合嵌入式、實時控制等大型軟件系統的開發;增量模型采用隨著日程時間的進展而交錯的線性序列,每一個線性序列產生軟件的一個可發布的“增量”[3],增量模型與原型實現模型一樣本質上是迭代的,但與原型實現不一樣的是其強調每一個增量均發布一個可操作產品,早期的增量是最終產品的“可拆卸”版本,提供了為用戶服務的功能,并且為用戶提供了評估平臺,避免了因質量不過關而重新設計的風險;演化模型也是通過構造系統的各個可執行的工作版本來開發系統的,但是,與增量型生存周期模型的區別是承認需求不能被完全了解,且不能在初始時就確定,在該方法中,需求一部分被預先定義,然后在每個相繼的工作版本中逐步完善。
通過以上分析,增量模型和演進模型最適合于指導嵌入式軟件的開發過程。
增量式模型和演進式模型均引入了迭代思想,但卻是對從系統分析與定義到軟件測試整個研制過程中包含的所有活動的迭代。而迭代不僅僅發生在系統需求變化時,研制過程中各個階段都可能發生變更,一旦變更就需要從變更活動開始往后迭代。因此,以上兩種模型適用于軟件需要分階段進行開發,對于每個構建版軟件需求、設計和實現一旦形成都比較穩定,較少反復。
基于變更驅動的軟件開發模型和統一過程模型充分運用了迭代原理,可以用于指導軟件開發的各項活動均易產生變更情況,但其缺點是各項活動的進度難以計劃。基于變更驅動的軟件開發模型和統一過程模型適用于在軟件開發的各階段均會產生較多的變更情況?;谧兏寗拥能浖_發模型適用于軟件不需要分階段管理的情況,統一過程模型適用于軟件需要分階段管理的情況。
對于軟件規模小、復雜度低的嵌入式軟件,其研制任務不需要分階段進行管理,如果研制活動中產生變更較少,不需要進行迭代,那么可以直接選取瀑布模型,如果易產生需求、設計變更,那么應選取基于變更驅動的軟件開發模型。對于軟件規模較大、復雜程度高的軟件需要分階段進行管理,如果在各開發階段研制任務是不一樣的,一旦研制任務確定,其他活動中將會產生較少變更,可以選取增量模型或演化模型,如果變更頻繁應選取基于變更驅動的軟件開發模型或統一過程模型。
所有的模型都是要為特定的軟件項目服務的,不能生搬硬套,可以根據各自項目的特點進行裁剪和運用。下面是研究成果在實際項目中的運用情況。
項目一屬于預研類項目,暫時僅對初樣階段有要求。在初樣階段只需要一個軟件原型,通過這個原型去試驗和驗證產品所能達到的技術指標,這樣,在本階段只需要關注軟件實現,其他活動的開展均為軟件實現活動服務,這種情況下選用了原型實現模型,其輸出的工作產品是一個可實際運行的軟件雛形。
項目二的軟件規模較大且與硬件結合較為緊密。系統研制已經嚴格劃分為F、C、S、D階段,這樣的劃分更適合選取以上所述的能夠產生多個構建版的迭代式軟件開發模型,在每個階段各輸出一個或多個構建版,同時要對每個構建版所包含的活動進行適當裁剪。該項目選取了統一過程模型,將模型中的“初始階段”、“細化階段”、“構造階段”和“移交階段”規定成軍用嵌入式軟件開發所采取的“F”、“C”、“S”和“D”這四個階段。在每個階段關注不同的活動,僅要求我們關注的活動有正式的輸出產品,例如,在F階段僅關注軟件實現,正式的輸出產品是能夠在系統中正常運行的代碼。同時,由于各階段內所有的活動均可以迭代,各階段產生構建版的數量由迭代次數決定。
迭代式軟件開發模型因其靈活性、對需求變更的適用性,已經漸漸取代了常用的瀑布式模型。通過對各種迭代式軟件開發模型的研究,充分論述了如何在軍用嵌入式軟件中選取、裁剪和運用這些模型,并將文中所述思想應用到了多個型號軟件開發活動的策劃和指導中,通過實踐證明了模型運用的有效性。
[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