敏捷開發(fā)及測試方法在安全級軟件研制過程中的適用性研究

韓文興 瞿銘君 余波 蔣維

【摘 要】安全級軟件研制過程通常采用發(fā)展成熟的瀑布模式作為一種典型的生命周期模型，隨著行業(yè)發(fā)展，軟件規(guī)模不斷擴大，復雜度不斷加深，瀑布式開發(fā)方法的內(nèi)在風險越來越明顯地影響安全級軟件研制的成本、進度和質(zhì)量。在互聯(lián)網(wǎng)行業(yè)興起的敏捷開發(fā)模式，其新穎的思想維度、快速交付帶來的價值、顯著的效率提升，越來越廣泛地被軟件從業(yè)者接受和推崇。文中從根源上研究敏捷方法的思想，并與安全級軟件領(lǐng)域的核心思想進行對比，探索二者的差異性和共同點，討論敏捷開發(fā)及測試方式在安全級軟件研制過程中的適用性。

【關(guān)鍵詞】敏捷；安全級；瀑布模型；開發(fā)；測試

中圖分類號：TK08 文獻標識碼： A 文章編號： 2095-2457（2018）16-0053-003

DOI：10.19694/j.cnki.issn2095-2457.2018.16.023

【Abstract】In safety software development， its usually fallowing waterfall method as there software life cycle model. With the development of the industry， software becomes lager and more complexity， and make the method of Waterfall Model display its short face clearly， such as more cost， slowly progress and inferior quality. In Internet field， there is a new development method called Agile that accepted by software engineers because its has special point of view and highly valuable of quickly ready to use and efficiently work. This paper briefly introduces the different between this two kinds of development model， and discuss applicability of Agile in safety software developmet.

【Key words】Agile；Safety；Waterfall Model；Development&Test;

0 引言

1970年，溫斯頓.羅伊斯（Winston Royes）在他的論文《管理大型軟件系統(tǒng)的開發(fā)》中描述了瀑布式方法論的階段劃分方法，從此“瀑布模型”因其被人們最容易掌握并熟練應(yīng)用的線性方法成為一種被廣泛采用的軟件開發(fā)模型，其固定的階段劃分、嚴格的過程控制、詳盡的文檔和記錄在安全級軟件領(lǐng)域發(fā)揮著巨大的作用。但這種方法由于其本身的局限性，在大規(guī)模安全軟件項目中暴露出估算困難、文檔工作繁重、變更成本高昂、項目成功率不理想等問題。即使后續(xù)基于瀑布模型的線性方法變體模型：增量迭代模型（分段線性）和螺旋模型（彎曲線性），也不能充分解決問題。于是在2001年由17名追求卓越的軟件開發(fā)人員共同與會并定義了“敏捷”術(shù)語，發(fā)布了敏捷宣言，創(chuàng)建了敏捷聯(lián)盟，并從工作思想層面、項目管理層面、團隊協(xié)作層面等全方位改進以瀑布模型為代表的傳統(tǒng)開發(fā)模式。由此衍生出的極限編程、看板、Scrum等一列敏捷流派都在互聯(lián)網(wǎng)行業(yè)引起一陣革命浪潮，其他軟件行業(yè)領(lǐng)域紛紛效仿。與此同時，對于敏捷方法的普適意義、方法理念的合理性、工作有效性也一直存在相互對立觀點的爭論。

軟件開發(fā)模型決定著軟件研發(fā)過程的各項活動在什么樣時機、以何種形式開展，必然影響最終的產(chǎn)出成果。由于安全級軟件應(yīng)用場景對于人身安全的重要性，將未經(jīng)論證、存在不可控因素或者有風險開發(fā)模型貿(mào)然引入，即使存在較小的可能性會造成嚴重的后果和無法挽回的損失，也是難以讓人接受的。那么，客觀分析來看，敏捷方法究竟是否適用于安全級軟件呢？如果適用，該如何引入？如果不適用，是什么原因?qū)е虏贿m用的？

1 根源上的差異

根據(jù)一些非正式的統(tǒng)計數(shù)據(jù)表明，絕大多的安全級軟件均是按照瀑布模型開發(fā)，由于眾所周知的原因，瀑布模型在開發(fā)過程中體現(xiàn)出良好的可控性、可預見性為軟件開發(fā)管理者提供長效監(jiān)督作用。在敏捷方法體系中，有的專注于實踐，如敏捷建模、極限編程等，有的專注于工作流程如Scrum、看板等，有的支援需求規(guī)范和開發(fā)，例如自適應(yīng)軟件開發(fā)（ASD）、測試驅(qū)動開發(fā)（TDD）等，在核心內(nèi)容上均源自于敏捷宣言及原則，其相關(guān)內(nèi)容任何人都能夠輕易獲得。此處不再贅述，僅通過針對瀑布方法和敏捷方法在思想上的研究，客觀分析其根源上存在的不同及各自的優(yōu)缺點。

1.1 技術(shù)上的區(qū)別

瀑布要求自頂向下的設(shè)計方法，概要設(shè)計時充分考慮所有需求在后續(xù)工作中如何實現(xiàn)，選擇較為穩(wěn)妥和中庸的設(shè)計方案，這項任務(wù)對設(shè)計工作提出了比較高的要求，否則下一個和一些階段會難以開展或無法開展。這種方法的好處是，在技術(shù)穩(wěn)定和成熟的團隊，前期優(yōu)良的設(shè)計對順利執(zhí)行后續(xù)各個過程提供了極大地便利。同樣問題也在于，對于技術(shù)上不夠成熟的成長型組織，容錯的空間較小，一旦出現(xiàn)難以逾越的障礙將會導致整個軟件重構(gòu)。

敏捷方法要求采用極低耦合度、高擴展性的設(shè)計方法，當前版本迭代周期（敏捷術(shù)語稱之為一個sprint）內(nèi)只設(shè)計一個或少數(shù)幾個需求。剩下的在未來的sprint去設(shè)計和實現(xiàn)，努力做到各個功能和需求間相互不影響或盡可能少的影響。以期望實現(xiàn)sprint間的故障隔離，在某些方法論（如TDD）中，甚至采用至下而上的開發(fā)思路。好處是顯而易見的，每個sprint僅有少量的設(shè)計工作，并不需要充分完全地、充分地考慮未來有哪些需要實現(xiàn)的需求，因為未來的需求可能是會變化的。每次迭代都能提供一個已經(jīng)實現(xiàn)的功能集合，各個sprint之間可以清晰隔離故障原因。但在經(jīng)過了長期迭代之后，可能會發(fā)現(xiàn)，高擴展性可能只是表現(xiàn)在形式上，實際上也許已經(jīng)變成了一個軟件群的組合。

1.2 對待變更的態(tài)度

瀑布模型的本質(zhì)是一種可預見性的工作方法，而變更是不可預見的，都會發(fā)生在已制定的計劃之外，因此是比較抗拒變更的，尤其是在軟件項目后期階段。一旦發(fā)生變更，就必須經(jīng)過一系列的工序獲得準許，并申請額外的資源、修訂原項目計劃來實現(xiàn)變更。羅伊斯博士在他的論文中早已經(jīng)意識到，對于需求經(jīng)常變化的軟件項目來說，瀑布模型是不適用的。

敏捷方法本質(zhì)的擁抱變更的，將變更項列在待辦池中，安排在下一個或更加以后的sprint中實施，并通過短路徑的反饋回路和適應(yīng)周期，迅速修正負面反饋信息，在應(yīng)對較為頻繁變更的軟件項目上，敏捷方法在效率上和用戶滿意度上體現(xiàn)出了其他方法無法比擬的優(yōu)勢。

1.3 對待流程的態(tài)度

瀑布模型強調(diào)流程規(guī)范的重要性，職責分工細致明確，有專職人員如QA來監(jiān)督流程與實際執(zhí)行的一致性，通過定義標準的輸入輸出接口、嚴格的流程執(zhí)行力度，來降低因為個體犯錯而導致某個環(huán)節(jié)活動失敗的概率。強調(diào)以流程為核心的工作理念，因此意味著在一個軟件項目尚未啟動時，就需要預先將一系列的工作活動流程約定成章，工作效率及工作成果的質(zhì)量高度依賴于流程制度的合理程度。

敏捷方法更加重視團隊成員個體間的交流和互動。并把活動過程比作一場Scrum（并列爭球）游戲，所有人以一種自組織的方式圍繞同一目標努力，認為大部分流程和工具上的一切問題都可以通過面對面的、非正式的交流來達成一致，強調(diào)以人為核心的工作理念。但這種做法的問題在于，一方面要維持每個體間相互溝通的成本會隨著個體數(shù)量增加而大幅增加，計算方式是N*（N-1）/2，曾獲得計算機圖靈獎的Brooks教授在他的著作《人月神話》一書中有詳細的論述，尤其是對于分布式工作環(huán)境而言，要向每一個團隊成員更新最新的信息也需要占用很大一部分工作量。另一方面工作成果的質(zhì)量過于依賴于個體，會導致人為因素的錯誤可能會在軟件研制過程中被不斷地放大。因此，在成功實施敏捷方法的組織中，要求每一名團隊成員都是經(jīng)過訓練的，具有相當豐富的工作經(jīng)驗。

1.4 對待文檔的態(tài)度

瀑布模型相當依賴于詳盡的文檔，對于文檔的規(guī)范要求、編寫時機、內(nèi)容細致程度、評審等方面都有嚴格的要求，并作為下一階段工作開展的輸入。文檔一方面用于技術(shù)細節(jié)交流，一方面形成軟件項目的過程記錄，對于安全級軟件而言，監(jiān)管機構(gòu)不能時刻監(jiān)視軟件開發(fā)過程，文檔審查便作為監(jiān)管的重要手段和內(nèi)容。毫無疑問，詳盡的文檔工作必然大幅度降低開發(fā)人員的代碼生產(chǎn)率。

敏捷方法看重的是交付可工作的軟件，弱化文檔的功能，以減少用于消耗在文檔工作上的精力，集中并快速實現(xiàn)一個sprint周期的成果。工作效率顯著提高，但問題在于，軟件雖然是可用的，卻難以提供證據(jù)向團隊外部人員或組織證明軟件是可靠的，尤其是在經(jīng)過了多次迭代周期以后。

1.5 對測試的要求

瀑布模型中按照V字模型對開發(fā)工作的成果開展測試活動，各個階段測試的對象、粒度、覆蓋率均有規(guī)范的要求。對于安全級軟件，執(zhí)行測試的機構(gòu)還有獨立性要求，每個工作階段達不到相應(yīng)的質(zhì)量要求變不允許進入下一個工作階段。測試工作易于按部就班開展，對是否要求實現(xiàn)自動化并不在意。

敏捷方法采用一次次的sprint不停地發(fā)布可用版本，對于每一個版本都全量或增量的測試，因此要求實現(xiàn)持續(xù)集成和測試自動化，否則對于版本發(fā)布及測試工作而言就是地獄般的存在，值得慶幸的是，由于敏捷方法的推動，對持續(xù)集成方法和自動化測試技術(shù)的發(fā)展都有強烈的促進作用，但問題是，對于安全級的嵌入式軟件而言，實現(xiàn)持續(xù)集成和自動化遠沒有其他領(lǐng)域那么容易。

2 一些優(yōu)秀的敏捷實踐

基于敏捷思想的方法和技術(shù)由于敏捷流派不同傾向，呈現(xiàn)出遍地開花的姿態(tài)，如水晶方法、動態(tài)系統(tǒng)開發(fā)方法、精益軟件開發(fā)、測試驅(qū)動開發(fā)、探索性測試等、模型驅(qū)動的敏捷開發(fā)、敏捷建模、自適應(yīng)軟件開發(fā)、極限編程、Scrum等等，各自都聲稱自己是相關(guān)領(lǐng)域的優(yōu)秀實踐。此處無法一一列舉，僅簡單分析幾個常見的方法，分析其核心思想，并探討合理性及必要性。

2.1 以講故事方式描述需求

把每一個需求以用戶故事或場景的方式，簡明扼要地以3行文字（As… I want… So that…）寫到卡片上，這種實例化需求的方法雖然很好的表達了需要什么，但極易隱藏細節(jié)，例如：“作為一個核電廠業(yè)主，我需要一個儀控系統(tǒng)，來控制我的反應(yīng)堆！”隱藏了細節(jié)的需求必然會導致向團隊某個或多個成員解釋真正的需求所隱含的真正內(nèi)容。于是又回到了N*（N-1）/2條溝通路徑的問題上。

在把需求經(jīng)過拆分、變成了既有獨立的，非常小的，具有外部價值的，可測試的用戶故事之后，實際上已經(jīng)完成了傳統(tǒng)的運用格式化的和層級化的需求規(guī)格書所表達的內(nèi)容。

2.2 結(jié)對編程

根據(jù)一些可靠的調(diào)查和研究表明，結(jié)對編程的實際效率雖然比兩個人并行編程工作僅低了35%，但完成了非正式的代碼評審工作，提升了質(zhì)量的同時也加強了結(jié)對成員的交流，但一些觀點認為，當在享受更多的不被打擾的自由空間和隱私空間時，人們才有最好的創(chuàng)意，另外，在安全級軟件領(lǐng)域，即便代碼通過了非正式的代碼評審和單元測試，依然需要開展同行評審進行復審，因為結(jié)對編程雖然解決了兩個人的共同問題，但并不能包含代碼評審需要關(guān)注的所有問題。

2.3 測試驅(qū)動開發(fā)

將單元測試框架及測試代碼、測試用例優(yōu)先于軟件代碼完成，開發(fā)工作完成以單元測試通過為標準，嚴格來說這更像一種技術(shù)而不是方法，不僅要求開發(fā)和測試人員具有逆向思維的意思形態(tài)，掌握測試和重構(gòu)，也還要懂得設(shè)計方面的知識。這也是所有敏捷實踐中TDD最難實施的原因。根據(jù)一些針對TDD的代表性實踐的研究發(fā)現(xiàn)，TDD確實能夠降低代碼缺陷密度，并提高測試的質(zhì)量，但TDD并不能一直提高設(shè)計質(zhì)量，雖然可以使類級和函數(shù)方法級的復雜度降低，但它給耦合內(nèi)聚帶來了負面影響，直接體現(xiàn)就是包級和項目級為之變得更加復雜，以至于無法有效地處理系統(tǒng)級的可靠性和安全性之類的問題，因為這些問題通常需要更加完善的模型。

更加重要的是，一組很好的測試用例不斷更新并經(jīng)常執(zhí)行，這個與它在代碼前寫好還是代碼后寫好，本質(zhì)上沒有關(guān)系。

3 安全級軟件的特點

以核電廠安全軟件為代表，安全級軟件具有以下特點：

a）標準符合性。軟件研發(fā)過程需要符合IEC 60880以及IEC 61508等安全相關(guān)標準，必要時還需要響監(jiān)管機構(gòu)出具標準符合性分析報告。而標準文件中的雖然沒有明確規(guī)定需要使用哪一種生命周期模型，但是對于研發(fā)過程，實際上是參照了瀑布模型的線性思維，對各階段及活動的每一個環(huán)節(jié)提出具體要求。因此，如果嚴格按照標準要求執(zhí)行，最好的思路仍然是采用線性的瀑布模型。

b）軟件研發(fā)過程需要出具詳盡的文檔。對每一個研發(fā)活動環(huán)節(jié)，都需要向第三方獨立驗證與確認團隊、監(jiān)管機構(gòu)證明軟件是可信的。然而除了測試和鑒定以外，只有提供文檔這一種手段。因此即使會很快過期的文檔，作為一個過程的記錄，對于安全級軟件開發(fā)過程來說，也是不可缺少的?？梢灶A見的是，如果將敏捷思想運用于安全級軟件的研制過程中，文檔工作量仍然不會明顯地減少，屆時，敏捷將失去其快速的意義。

c）具有嚴格要求的配置管理和質(zhì)量保證活動，以監(jiān)督軟件研發(fā)過程完全受到控制。尤其是質(zhì)量保證，由于敏捷方法講究的自組織團隊面對面溝通、弱化文檔，使得軟件工程中QA的評審、檢查、追溯、證明等基于文檔見證件的工作異常困難，幾乎陷于無處入手的境地，即使敏捷方法的原始倡導者，也要求軟件QA需要轉(zhuǎn)變職能及工作方法，至于如何轉(zhuǎn)變，也不能提出更好的方法。根據(jù)一部分調(diào)查報告顯示，部分實踐敏捷項目管理的組織將QA轉(zhuǎn)變?yōu)镾crum Master，讓QA拋棄警察角色而作為教練角色，但如此一來質(zhì)量保證的工作性質(zhì)是否還有擁有其原本存在的意義，可能也值得懷疑。

d）嚴格的變更控制。對軟件的任何修改其本質(zhì)是引入新的缺陷的過程，因此安全級軟件出于對質(zhì)量控制的原則出發(fā)，對變更的控制非常嚴格，對每一項變更不僅需要完成申請工序，還需要詳細地分析變更產(chǎn)生的影響。由于敏捷方法運用持續(xù)集成和自動化測試，通過執(zhí)行全量測試的方法確保沒有引入新的缺陷，有效地隔離了每個sprint的故障源。所以并不在乎如何變更。在這方面，敏捷方法是可行的，前提是每個版本的全量測試能夠切實執(zhí)行。

e）明確的需求。大部分安全級軟件（如核電廠DCS）的需求實際上是非常明確的，會產(chǎn)生變更的內(nèi)容相對較少。因此，敏捷方法講究快速響應(yīng)變化的特點似乎并不能充分的發(fā)揮作用，反而在設(shè)計階段考慮了所有需求如何實現(xiàn)的瀑布模型的開發(fā)方法更能體現(xiàn)有優(yōu)勢。

f）軟件升級部署會受到非常嚴格的監(jiān)控，更加注重安全性。一般而言，對于未完成的軟件，是不允許部署在應(yīng)用場景中，對于已經(jīng)部署的軟件，非必要的情況，也不允許任意升級。因此，快速交付可工作的軟件只可能用于向用戶演示功能及宣傳用，在真實使用環(huán)境上只能部署經(jīng)過完整驗證的最終版本軟件，因此敏捷方法中快速試錯并糾正的理念，并不一定能在安全級軟件中得到最終用戶的認同。

g）軟件的規(guī)模大。安全級軟件的規(guī)?；径荚谇f級金額以上，涉及上百人跨多個職能部門的團隊分布式進行研發(fā)，更加注重有依據(jù)的技術(shù)信息傳遞，而技術(shù)文檔就是一種技術(shù)信息的可靠載體。敏捷倡導的面對面的溝通確實能在小范圍中發(fā)揮重要的作用，但對于大規(guī)模的團隊溝通而言，流程和文檔才是不容忽視的力量。

h）軟件需要經(jīng)過技術(shù)和管理完全獨立的第三方團隊嚴格的測試，并提供需求、設(shè)計、實現(xiàn)等工作的完整的追蹤鏈和較高的可測試性，以保證測試的完整性和充分性。敏捷方法中運用大量的非正式化的交流，難以保存完整的跟蹤證據(jù)鏈，使得第三方團隊工作無法充分發(fā)揮作用。

i）服役時間長。一般而言，安全級軟件的服役時間非常長，核電廠安全級DCS系統(tǒng)軟件服役時間都是以10年計，這對軟件的穩(wěn)定性、可靠性和可維護性要求非常高，而完全用敏捷思想開發(fā)的軟件由于其專注于軟件“剛好夠”的可用性及快速意義，便難以同時兼顧軟件的其他特性。

4 開發(fā)模型的本質(zhì)

對于敏捷從業(yè)者而言，敏捷方法不是一種方法或流程，而是一種思維模式。這是有原因的，大多數(shù)試圖用流程的方式向敏捷方法轉(zhuǎn)型的努力基本上都以失敗而告終，要么回到了傳統(tǒng)的瀑布模型，要么回到了無序不受控的工作狀態(tài)。開發(fā)模型或者生命周期模型的作用，是為了使規(guī)模大、結(jié)構(gòu)復雜和管理復雜的軟件開發(fā)變得容易控制。瀑布模型將軟件工程作為一個整體，橫向切分層級；敏捷模型將軟件工程縱向割裂成一次次的小型化的增量迭代，二者擁有各自適用的場景和條件，在各自的領(lǐng)域均能發(fā)揮重要的作用。瀑布模型讓大型軟件工程項目流程清晰過程可控，易于監(jiān)管；敏捷方法讓中小型軟件快速升級迭代，不斷試錯，樂于變更。彼此思想上雖然存在較多的對立面，同時也是互補點。

5 結(jié)束語

軟件的開發(fā)和測試工作是抽象和邏輯的藝術(shù)，正如Brooks教授所言，這個世界上沒有銀彈，敏捷方法也不是，完全套用在安全級軟件的研發(fā)過程中，顯然是不合適的。但這并不妨礙研究融合其中一部分思想和原則，降低一部分瀑布模式的不利因素，例如：在編碼實現(xiàn)階段用迭代方法分批次實現(xiàn)需求，迭代版本不用提交給用戶，但可以提交給測試；測試雖然不用驅(qū)動開發(fā)工作但提前介入的思路卻可以提高測試的充分性與完整性，不僅僅是對單元測試；利用看板展示進度和計劃，既方便團隊成員了解整體進展，有利于識別并合理安排閑置資源；利用燃盡圖評估剩余工作量；以人為本的理念重視個體的創(chuàng)造性等；也許未來會存在一種經(jīng)兩者融合的新型的生命周期模型，即解決了瀑布模式面臨的問題，也滿足于安全級軟件的生產(chǎn)需求。

【參考文獻】

[1]Rober C.Martin.敏捷軟件開發(fā)：原則模式與實踐[M].北京：清華大學出版社，2003.9.

[2]IEC 61508-2.Functional safety of electrical/electronic/progr-ammable electronic safety-related systems [S].2010.

[3]Freder P.Brooks Jr.人月神話[M].北京：清華大學出版社，2015.4.

[4]Mark C.Layton.敏捷項目管理[M].北京：人民郵電出版社，2015.12.

[5]曲長利.測試驅(qū)動開發(fā)的應(yīng)用研究[J].復旦大學.2010.

[6]Paul C.Jorgensen. 軟件測試：一個軟件工藝師的方法[M].北京：機械工業(yè)出版社，2017.11.