韓文興 瞿銘君 余波 蔣維

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

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

中圖分類號(hào)：TK08 文獻(xiàn)標(biāo)識(shí)碼： A 文章編號(hào)： 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ā)模型，其固定的階段劃分、嚴(yán)格的過(guò)程控制、詳盡的文檔和記錄在安全級(jí)軟件領(lǐng)域發(fā)揮著巨大的作用。但這種方法由于其本身的局限性，在大規(guī)模安全軟件項(xiàng)目中暴露出估算困難、文檔工作繁重、變更成本高昂、項(xiàng)目成功率不理想等問題。即使后續(xù)基于瀑布模型的線性方法變體模型：增量迭代模型（分段線性）和螺旋模型（彎曲線性），也不能充分解決問題。于是在2001年由17名追求卓越的軟件開發(fā)人員共同與會(huì)并定義了“敏捷”術(shù)語(yǔ)，發(fā)布了敏捷宣言，創(chuàng)建了敏捷聯(lián)盟，并從工作思想層面、項(xiàng)目管理層面、團(tuán)隊(duì)協(xié)作層面等全方位改進(jìn)以瀑布模型為代表的傳統(tǒng)開發(fā)模式。由此衍生出的極限編程、看板、Scrum等一列敏捷流派都在互聯(lián)網(wǎng)行業(yè)引起一陣革命浪潮，其他軟件行業(yè)領(lǐng)域紛紛效仿。與此同時(shí)，對(duì)于敏捷方法的普適意義、方法理念的合理性、工作有效性也一直存在相互對(duì)立觀點(diǎn)的爭(zhēng)論。

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

1 根源上的差異

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

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

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

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

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

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

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

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

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

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

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

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

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

1.5 對(duì)測(cè)試的要求

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

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

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

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

2.1 以講故事方式描述需求

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

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

2.2 結(jié)對(duì)編程

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

2.3 測(cè)試驅(qū)動(dòng)開發(fā)

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

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

3 安全級(jí)軟件的特點(diǎn)

以核電廠安全軟件為代表，安全級(jí)軟件具有以下特點(diǎn)：

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

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

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

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

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

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

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

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

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

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

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

5 結(jié)束語(yǔ)

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

【參考文獻(xiàn)】

[1]Rober C.Martin.敏捷軟件開發(fā)：原則模式與實(shí)踐[M].北京：清華大學(xué)出版社，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].北京：清華大學(xué)出版社，2015.4.

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

[5]曲長(zhǎng)利.測(cè)試驅(qū)動(dòng)開發(fā)的應(yīng)用研究[J].復(fù)旦大學(xué).2010.

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