2.2 傳統(tǒng)過程模型

傳統(tǒng)過程模型又稱“慣用”過程模型，最早提出是為了改變軟件開發(fā)的混亂狀況，使軟件開發(fā)更加有序。歷史證明，這些傳統(tǒng)模型為軟件工程工作增加了大量有用的結(jié)構(gòu)化設(shè)計，并為軟件團隊提供了有效的路線圖。

傳統(tǒng)過程方法以秩序和一致性作為主要問題，之所以被稱為“傳統(tǒng)”，是因為它規(guī)定了一套過程元素——框架活動、軟件工程動作、任務(wù)、工作產(chǎn)品、質(zhì)量保證，以及每個項目的變更控制機制。每個過程模型還定義了過程流（也稱為工作流，即過程元素相互之間關(guān)聯(lián)的方式。所有的軟件過程模型都支持通用框架活動，但是每一個模型都對框架活動有不同的側(cè)重，并且定義了不同的過程流以不同的方式執(zhí)行每一個框架活動（以及軟件工程動作和任務(wù)）。

2.2.1 軟件生存周期模型

軟件生存周期模型（又稱軟件開發(fā)模型）是軟件工程的一個重要概念，它可以定義為：一個框架，它含有遍歷系統(tǒng)從確定需求到終止使用這一生存周期的軟件產(chǎn)品的開發(fā)、運行和維護中需要實施的過程、活動和任務(wù)。

軟件生存周期模型能清晰、直觀地表達軟件開發(fā)的全過程，明確規(guī)定了開發(fā)工作各階段所要完成的主要活動和任務(wù)，以作為軟件項目開發(fā)工作的基礎(chǔ)。對于不同的軟件系統(tǒng)，可以采用不同的開發(fā)方法、使用不同的程序設(shè)計語言，讓掌握不同技能的人員參與工作、運用不同的管理方法和手段等，并且允許采用不同的軟件工具和不同的軟件工程環(huán)境。軟件生存周期模型是穩(wěn)定有效和普遍適用的。

在軟件生存周期過程中，軟件生存周期模型僅對軟件的開發(fā)、運作和維護過程有意義，在信息技術(shù)國際標(biāo)準(zhǔn)ISO12207和ISO9000—3中都提到了軟件生存周期模型，包括瀑布模型、增量模型、演化模型、協(xié)同模型、噴泉模型和智能模型等。

2.2.2 瀑布模型

瀑布模型（又稱經(jīng)典生命周期）是1970年W.Royce提出的軟件生存周期開發(fā)模型（見圖2-3），它將軟件開發(fā)過程中的各項活動規(guī)定為依固定順序連接的若干階段工作，形同瀑布流水，最終得到軟件系統(tǒng)或軟件產(chǎn)品。換句話說，它將軟件開發(fā)過程劃分成若干個互相區(qū)別而又彼此聯(lián)系的階段，每個階段中的工作都以上一個階段工作的結(jié)果為依據(jù)，同時為下一個階段的工作提供了前提。

圖2-3 軟件生存周期的瀑布模型

瀑布模型的一個變體稱為V模型（見圖2-4），它描述了質(zhì)量保證動作，同溝通、建模相關(guān)動作及早期構(gòu)建相關(guān)的動作之間的關(guān)系。隨著軟件團隊工作沿著V模型左側(cè)步驟向下推進，基本問題需求逐步細化，形成問題及解決方案的技術(shù)描述。一旦編碼結(jié)束，團隊沿著V模型右側(cè)的步驟向上推進工作，其本質(zhì)是執(zhí)行了一系列測試（質(zhì)量保證動作），這些測試驗證了團隊沿著V模型左側(cè)步驟向下推進過程中所生成的每個模型。實際上，經(jīng)典生命周期模型和V模型沒有本質(zhì)區(qū)別，V模型提供了一種將驗證確認動作應(yīng)用于早期軟件工程工作中的方法。

瀑布模型是軟件工程最早的范例，但是，也一直存在著對這一過程模型的批評。在運用瀑布模型的過程中，人們遇到的問題包括以下幾個。

1）實際的項目很少遵守瀑布模型提出的順序。雖然線性模型可以加入迭代，但是它是用間接的方式實現(xiàn)的，結(jié)果是，隨著項目的推進，變更可能造成混亂。

2）客戶通常難以清楚地描述所有的需求。而瀑布模型卻需要客戶明確需求，因此很難適應(yīng)在許多項目開始階段必然存在的不確定性。

3）客戶必須有耐心，因為只有在項目接近尾聲時，他們才能得到可執(zhí)行的程序。對于系統(tǒng)中存在的重大缺陷，如果在可執(zhí)行程序評審之前沒有被發(fā)現(xiàn)，將可能損失慘重。

圖2-4 V模型

研究發(fā)現(xiàn)，經(jīng)典生命周期模型的線性特性在某些項目中會導(dǎo)致“阻塞狀態(tài)”，這是由于任務(wù)之間的依賴性，開發(fā)團隊的一些成員要等待另一些成員完成工作。事實上，花在等待上的時間可能超過花在生產(chǎn)性工作上的時間。在線性過程的開始和結(jié)束階段，這種阻塞狀態(tài)更容易發(fā)生。

軟件工作快速進展，經(jīng)常面臨永不停止的特性、功能和信息內(nèi)容等變化流，瀑布模型往往并不適合這類工作。盡管如此，當(dāng)需求確定、工作采用線性的方式完成的時候，瀑布模型是一個很有用的過程模型。

2.2.3 增量模型

在許多情況下，初始的軟件需求有明確的定義，但是整個開發(fā)過程卻不宜單純運用線性模型。同時，可能迫切需要為用戶迅速提供一套功能有限的軟件產(chǎn)品，然后在后續(xù)版本中再進行細化和擴展功能。在這種條件下，需要選用一種以增量的形式生產(chǎn)軟件產(chǎn)品的過程模型。

增量模型（又稱漸增模型）綜合了線性過程流和并行過程流的特征。如圖2-5所示，隨著時間的推移，增量模型在每個階段運用線性序列。每個線性序列以一種演化過程流生產(chǎn)增量類似的方式生產(chǎn)出一個軟件的可交付增量。

圖2-5 增量模型

例如，采用增量模型開發(fā)的文字處理軟件，在第一個增量中提供基本的文件管理、編輯和文檔生成功能；在第二個增量中提供復(fù)雜的編輯和文檔生成功能；在第三個增量中提供拼寫和語法檢查功能；在第四個增量中提供高級頁面排版功能。需要注意的是，任何增量的過程流都可能使用原型模型。運用增量模型時，第一個增量往往是核心產(chǎn)品。也就是說，滿足了基本的需求，但是許多附加的特性（一些是已知的，一些是未知的）沒有提供，客戶使用該核心產(chǎn)品進行仔細評價，并根據(jù)評價結(jié)果制訂下一個增量計劃。這份計劃說明了需要對核心產(chǎn)品進行的修改，以便更好地滿足客戶的要求，也說明了需要增加的特性和功能。每一個增量的交付都會重復(fù)這一過程，直到最終產(chǎn)品的產(chǎn)生。

增量模型側(cè)重于每個增量都提交一個可以運行的產(chǎn)品。早期的增量可以看做是最終產(chǎn)品的片段版本，但是它們確實具備了用戶服務(wù)能力，也為用戶的評價提供了一個平臺。

如果在項目既定的商業(yè)期限之前不可能找到足夠的開發(fā)人員，這種情況下增量模型顯得特別有用。早期的增量可以由少量的人員實現(xiàn)。如果核心產(chǎn)品的口碑不錯，可以為下一個增量投入更多的人力。同時，增量模型可以規(guī)避技術(shù)風(fēng)險。例如，一個系統(tǒng)需要利用某個正在開發(fā)的新硬件，而這個新硬件的交付日期不確定。因此，可以在早期的增量中避免使用這個硬件，這樣可以保證部分功能按時交付給最終用戶，不至于造成過分的延期。

在評價該模型時，需要考慮的風(fēng)險因素有以下幾個。

●需求未被很好地理解。

●突然提出一些功能。

●事先打算采用的技術(shù)迅速發(fā)生變化。

●需求迅速發(fā)生變化。

●長時期內(nèi)僅有有限的資源保證（工作人員/資金）。

2.2.4 演化模型

類似于其他復(fù)雜的系統(tǒng)，軟件會隨著時間的推移而演化。在開發(fā)過程中，商業(yè)和產(chǎn)品需求經(jīng)常發(fā)生變化，直接導(dǎo)致最終產(chǎn)品難以實現(xiàn)；嚴(yán)格的交付時間使得開發(fā)團隊不可能圓滿地完成軟件產(chǎn)品，但是必須交付功能有限的版本以應(yīng)對競爭或商業(yè)壓力；有時很好地理解了核心產(chǎn)品和系統(tǒng)需求，但是產(chǎn)品或系統(tǒng)擴展的細節(jié)問題卻沒有定義。在上述情況和類似情況下，軟件開發(fā)人員需要一種專門應(yīng)對不斷演變的軟件產(chǎn)品的過程模型。

演化模型（又稱進化模型，見圖2-6）是迭代的過程模型，通過構(gòu)造系統(tǒng)的各個可執(zhí)行的中間版本來開發(fā)系統(tǒng)，但是，與增量模型的區(qū)別是，承認需求不能被完全了解，且不能在初始時就確定。在該模型中，需求一部分被預(yù)先定義，然后在每個相繼的中間版本中逐步完善。在該模型中，每個中間版本在開發(fā)時，開發(fā)過程中的活動和任務(wù)順序地或部分重疊平行地被采用，使得軟件開發(fā)人員能夠逐步開發(fā)出更完整的軟件版本。

對所有的中間版本，開發(fā)過程中的活動和任務(wù)通常按同一順序被重復(fù)使用。維護過程和運作過程可以與開發(fā)過程平行地使用。獲取過程、供應(yīng)過程、支持過程和組織過程通常與開發(fā)過程平行地使用。下面是兩種常用的演化過程模型。

1）原型開發(fā)。很多時候，客戶提出了軟件的一些基本功能，但是沒有詳細定義功能和特性需求。另一種情況下，開發(fā)人員可能對算法的效率、操作系統(tǒng)的兼容性和人機交互的形式等情況并不確定。在類似情況下，采用原型開發(fā)范型是最好的解決辦法。

圖2-6 演化模型示意

雖然原型可以作為一個獨立的過程模型，但是更多的時候是作為一種技術(shù)，在其他過程模型中應(yīng)用。不論人們以什么方式運用它，當(dāng)需求很模糊時，原型開發(fā)模型可幫助軟件開發(fā)人員和干系人更好地理解究竟需要做什么。

原型開發(fā)始于溝通。軟件開發(fā)人員和干系人進行會晤，定義軟件的整體目標(biāo)，明確已知的需求，并大致勾畫出以后進一步定義的東西。然后，迅速策劃一個原型開發(fā)迭代并進行建模（以快速設(shè)計的方式）?？焖僭O(shè)計要集中到那些最終用戶能夠看到的方面，比如人機接口布局或者輸出顯示格式?？焖僭O(shè)計產(chǎn)生了一個原型。對原型進行部署，然后由干系人進行評價。根據(jù)干系人的反饋信息，進一步細化軟件的需求。在原型系統(tǒng)不斷調(diào)整以滿足各種干系人需求的過程中，采用迭代技術(shù)，同時也使開發(fā)者逐步清楚用戶的需求。

理想狀況下，原型系統(tǒng)提供了定義軟件需求的一種機制。當(dāng)需要構(gòu)建可執(zhí)行的原型系統(tǒng)時，軟件開發(fā)人員可以利用已有的程序片段或應(yīng)用工具（如報告生成器和窗口管理器），快速產(chǎn)生可執(zhí)行的程序。

在大多數(shù)項目中，構(gòu)建的第一個系統(tǒng)很少是好用的，可能太慢了，太大了，很難使用，或者同時具備上述三點。除了重新開始，沒有更好的選擇。采用更巧妙的方法是構(gòu)建一個重新設(shè)計的版本，解決上述問題。

盡管許多原型系統(tǒng)是臨時系統(tǒng)，會被廢棄，而其他一些原型系統(tǒng)將會慢慢演化為實際系統(tǒng)。干系人和軟件工程師確實都喜歡原型開發(fā)模型。客戶對實際的系統(tǒng)有了直觀的認識，開發(fā)者也迅速建立了一些東西。但是，原型開發(fā)也存在一些問題，列舉如下。

①干系人看到了軟件的工作版本，卻未察覺到整個軟件是隨意搭成的，也未察覺到為了盡快完成軟件，開發(fā)者沒有考慮整體軟件質(zhì)量和長期的可維護性。當(dāng)開發(fā)者告訴客戶整個系統(tǒng)需要重建以提高軟件質(zhì)量時，干系人會不愿意，并且要求對軟件稍加修改使其變?yōu)橐粋€可運行的產(chǎn)品。因此，軟件開發(fā)管理往往陷入失效。

②軟件開發(fā)人員為了使一個原型快速運行起來，往往在實現(xiàn)過程中采用折中的手段。他們經(jīng)常會使用不合適的操作系統(tǒng)或程序設(shè)計語言，僅僅因為當(dāng)時可用和熟悉。他們也經(jīng)常會采用一種低效的算法，僅為了證明系統(tǒng)的能力。時間長了，軟件開發(fā)人員可能會適應(yīng)這些選擇，而忽略了這些選擇其實并不合適的理由，結(jié)果造成并不完美的選擇變成了系統(tǒng)的組成部分的情況。

盡管問題經(jīng)常發(fā)生，原型開發(fā)對于軟件工程來說仍是一個有效的模型。關(guān)鍵是要在游戲開始的時候制定規(guī)則，也就是說，所有干系人必須承認原型是為定義需求服務(wù)的。然后丟棄原型（至少是部分丟棄），實際的軟件系統(tǒng)是以質(zhì)量第一為目標(biāo)開發(fā)的。

2）螺旋模型。最早由Boehm提出，是一種風(fēng)險驅(qū)動型的演進式軟件過程模型。它結(jié)合了原型的迭代性質(zhì)，以及瀑布模型的系統(tǒng)性和可控性特點，具有快速開發(fā)越來越完善軟件版本的潛力。Boehm這樣描述螺旋模型：對于軟件集中的系統(tǒng)，螺旋模型可以指導(dǎo)多個干系人協(xié)同工作。它有兩個顯著的特點：一是采用循環(huán)的方式逐步加深系統(tǒng)定義和實現(xiàn)的深度，同時降低風(fēng)險；二是確定一系列里程碑，確保干系人都支持可行的和令人滿意的系統(tǒng)解決方案。

運用螺旋模型，把軟件開發(fā)為一系列演進版本。在早期的迭代中，軟件可能是一個理論模型或原型。在后來的迭代中，會產(chǎn)生一系列逐漸完整的系統(tǒng)版本。

螺旋模型被分割成一系列由軟件工程團隊定義的框架活動。如圖2-7所示，每個框架活動代表螺旋上的一個片段。隨著演進過程開始，從圓心開始順時針方向，軟件團隊執(zhí)行螺旋上的一圈表示的活動。在每次演進時，都要考慮風(fēng)險。每個演進過程還要標(biāo)記里程碑——沿著螺旋路徑達到的工作產(chǎn)品和條件的結(jié)合體。

圖2-7 典型的螺旋模型

螺旋的第一圈一般開發(fā)出產(chǎn)品的規(guī)格說明，接下來開發(fā)產(chǎn)品的原型系統(tǒng)，并在每次迭代中逐步完善，開發(fā)不同的軟件版本。螺旋的每一圈都會跨過策劃區(qū)域，此時，需要調(diào)整項目計劃，并根據(jù)交付后用戶的反饋調(diào)整預(yù)算和進度。另外，還需要調(diào)整完成軟件開發(fā)的迭代次數(shù)。

其他過程模型當(dāng)軟件交付后就結(jié)束了，螺旋模型則不同，它應(yīng)用在計算機軟件的整個生命周期。因此，螺旋上的第一圈可能表示“概念開發(fā)項目”，它起始于螺旋的中心，經(jīng)過多個迭代（沿軸指向中心的箭頭區(qū)分開了部署和溝通兩個區(qū)域，表明沿同一個螺旋路徑存在潛在的局部迭代），直到概念開發(fā)的結(jié)束。如果這個概念將被開發(fā)成為實際的產(chǎn)品，過程模型將繼續(xù)沿著螺旋向外伸展，此時稱為“新產(chǎn)品開發(fā)項目”。新產(chǎn)品可能沿著螺旋通過一系列的迭代不斷演進。最后，可以用一圈螺旋表示“產(chǎn)品提高項目”。本質(zhì)上，當(dāng)螺旋模型以這種方式進行下去的時候，它將永遠保持可操作性，直到軟件產(chǎn)品的生命周期結(jié)束。過程經(jīng)常會處于休止?fàn)顟B(tài)，但每當(dāng)有變更時，過程總能夠在合適的入口點啟動（如產(chǎn)品提高）。

螺旋模型是開發(fā)大型系統(tǒng)和軟件的理想方法。由于軟件隨著過程的推進而變化，在每一個演進層次上，開發(fā)者和客戶都可以更好地理解和應(yīng)對風(fēng)險。螺旋模型把原型作為降低風(fēng)險的機制，更重要的是，開發(fā)人員可以在產(chǎn)品演進的任何階段使用原型方法。它保留了經(jīng)典生命周期模型中系統(tǒng)逐步細化的方法，但是把它納入一種迭代框架之中，這種迭代方式與真實世界更加吻合。螺旋模型要求在項目的所有階段始終考慮技術(shù)風(fēng)險，如果適當(dāng)?shù)貞?yīng)用該方法，則能夠在風(fēng)險變?yōu)閱栴}之前化解風(fēng)險。

現(xiàn)代計算機軟件總是在持續(xù)改變，這些變更通常要求在非常短的期限內(nèi)實現(xiàn)，并且要充分滿足用戶的要求。許多情況下，及時投入市場是最重要的管理要求。如果市場時間錯過了，軟件項目自身可能會變得毫無意義。

演化模型的初衷是采用迭代或者增量的方式開發(fā)高質(zhì)量軟件。可是，用演化模型也可以做到強調(diào)靈活性、可延展性和開發(fā)速度。軟件團隊及其經(jīng)理所面臨的挑戰(zhàn)就是在這些嚴(yán)格的項目和產(chǎn)品參數(shù)與客戶（軟件質(zhì)量的最終仲裁者）滿意度之間找到一個合理的平衡點。

2.2.5 協(xié)同模型

協(xié)同開發(fā)模型有時候也稱為協(xié)同工程，它允許軟件團隊表述任何模型中的迭代和并發(fā)元素。例如，螺旋模型定義的建?；顒佑梢环N或幾種軟件工程動作完成：原型開發(fā)、分析及設(shè)計。

對于協(xié)同模型方法中建?；顒拥哪骋卉浖こ袒顒?，圖2-8給出了一種描述。在某一特定時間，建?；顒涌赡芴幱趫D中所示的任何一種狀態(tài)中。其他活動、動作或任務(wù)（如溝通或構(gòu)建）可以用類似的方式表示。所有的軟件工程活動同時存在并處于不同的狀態(tài)。

圖2-8 協(xié)同過程模型的一種描述

例如，在項目的早期，溝通活動（圖2-8中并未標(biāo)明）完成了第一個迭代，停留在等待變更狀態(tài)。初始溝通完成后，建?；顒右恢蓖Ａ粼诜腔顒訝顟B(tài)，現(xiàn)在轉(zhuǎn)換到正在開發(fā)狀態(tài)。如果客戶要求必須完成需求變更，則建模活動從正在開發(fā)狀態(tài)轉(zhuǎn)換到等待變更狀態(tài)。

協(xié)同模型定義了一系列事件，這些事件將觸發(fā)軟件工程活動、動作或者任務(wù)的狀態(tài)轉(zhuǎn)換。例如，設(shè)計的早期階段（建?；顒悠陂g發(fā)生的主要軟件工程動作）發(fā)現(xiàn)了需求模型中的不一致性，于是產(chǎn)生了分析模型修正事件，該事件將觸發(fā)需求分析動作從完成狀態(tài)轉(zhuǎn)換到等待變更狀態(tài)。

協(xié)同過程模型可用于所有類型的軟件開發(fā)，能夠提供精確的項目當(dāng)前狀態(tài)圖。它不是把軟件工程活動、動作和任務(wù)局限在一個事件的序列，而是定義了一個過程網(wǎng)絡(luò)。網(wǎng)絡(luò)上每個活動、行為和任務(wù)與其他活動、行為和任務(wù)同時存在。過程網(wǎng)絡(luò)中某一點產(chǎn)生的事件可以觸發(fā)狀態(tài)的轉(zhuǎn)換。

2.2.6 噴泉模型

噴泉模型是由B.H.So11ers和J.M.Edwards于1990年提出的一種開發(fā)模型，主要用于采用面向?qū)ο蠹夹g(shù)的軟件開發(fā)項目，“噴泉”一詞本身就體現(xiàn)了迭代和無間隙的特性。軟件的某個部分常常重復(fù)工作多次，相關(guān)對象在每次迭代中隨之加入漸進的軟件成分（見圖2-9）。

圖2-9 噴泉模型

無間隙是指在各項活動之間無明顯邊界，如分析和設(shè)計活動之間沒有明顯的界限。由于對象概念的引入，表達分析、設(shè)計和實現(xiàn)等活動只用對象類和關(guān)系，從而可以較為容易地實現(xiàn)活動的選代和無間隙，使其開發(fā)自然地包括復(fù)用。

2.2.7 智能模型

智能模型也稱為基于知識的軟件開發(fā)模型，它是知識工程與軟件工程在開發(fā)模型上結(jié)合的產(chǎn)物，它有別于上述5種開發(fā)模型。

圖2-10表示了智能模型與其他模型的不同，它的維護并不在程序一級上進行，這樣就大大降低了問題的復(fù)雜性，從而可以把精力更加集中于具體描述的表達上，即維護在功能規(guī)約一級進行。具體描述可以使用形式功能規(guī)約，也可以使用知識處理語言描述等，因而必須將規(guī)則和推理機制應(yīng)用到開發(fā)模型中，所以必須建立知識庫，將模型本身、軟件工程知識和特定領(lǐng)域的知識分別存入知識庫，由此構(gòu)成某一領(lǐng)域的軟件開發(fā)系統(tǒng)。

圖2-10 智能模型