《軟件工程理論與實踐》-第二章

第2章軟件過程

【目標】本章的目標是系統介紹軟件過程思想。讀完本章，讀者將了解以下內容。什么是軟件過程，軟件過程模型;軟件過程與軟件工程方法學;幾種基本軟件過程模型及其演化過程;支持軟件過程的CASE技術。下一頁返回第2章軟件過程

軟件工程的目標是以較經濟的手段獲取高質量的軟件，然而這一目標終歸要靠一系列活動來實現。如何組織這些活動，從事活動的開發者應該遵循身什么樣的規范、流程，有哪些工具可以支持他們完成活動中的具體任務?所有這些問題，都推動著軟件工程過程的發展與廣泛應用。上一頁返回2.1軟件過程概述

軟件過程也稱為軟件生存周期過程，是指軟件工程人員為了獲得軟件產品而實施的一系列軟件活動。這些活動可以是順序的、迭代的、并行的、嵌套的，或者是依據條件而發生的。隨著客戶對系統的要求越來越復雜，建立這些系統的軟件過程也越來越復雜，這種復雜性也與工程師的判斷力有關。正是由于需要判斷力和創造力，軟件過程無法實現完全自動化。CASE工具可以幫助支持一些過程活動，但無法完全取代人類在軟件過程中的富含創造性的活動。此外，不同的人、不同的機構、不同的軟件系統有不同的適合的軟件過程，因此軟件過程具有很大的差異性。這種差異性是軟件過程無法實現自動化的另一個原因。雖然存在許多不同的軟件過程，但構成軟件過程的基本活動還是相同的。這些基本活動包括以下幾個方面。下一頁返回2.1軟件過程概述

(1)軟件規格描述，即通俗的需求分析，用來刻畫軟件的功能、性能需求及運行環境約束。(2)軟件開發，包括軟件設計與實現，即按照軟件規格描述的要求實現一個系統。(3)軟件的驗證，即測試環節，用來檢驗開發的軟件是否與規格描述相一致。(4)軟件的進化，即維護，軟件按一定的要求變更。軟件過程本身一直在演化，這種演化源于工程師們用經驗知識來改進軟件工程開發的過程流程，在可以預見的未來，這種演化將會持續下去。軟件的過程模型是軟件過程的一個抽象表示法，也是對這種演化的階段性總結或刻畫。上一頁返回2.2軟件過程模型

軟件過程模型是軟件開發的指導思想和全局性框架，軟件過程模型的提出和發展反映了人們對軟件過程的某種認識觀，體現了人們對軟件過程認識的提高和飛躍。下面介紹一些一般性的軟件過程模型，每個過程模型都從某個特定角度表現一個過程，提供過程的一些信息。需要指出的是，這些過程模型不是某種必須遵循的標準，它只是一種有用的對過程的抽象，在實際的大型項目開發中，需要作必要的裁剪或組合。下一頁返回2.2軟件過程模型

2.2.1瀑布模型

瀑布模型又稱為軟件生命周期模型，是最早提出的模型。如圖2.1所示，它以軟件生命周期的每一個階段作為一個活動，依序逐漸完成這些活動。

采用瀑布模型開發軟件時，前一個階段任務的完成是后一個階段任務開始的基礎和前提，后一階段是前一階段工作的進一步具體化。每一個階段的開始和結束都有嚴格標準。按照該方法，各階段的工作自頂向下從抽象到具體順序進行，就像奔流不息的瀑布，因而稱為瀑布模型。瀑布模型的優點如下。

(1)歷史較長、應用面廣泛、為廣大軟件工作者所熟悉，并且已有與之配套的一組十分成熟的開發方法和豐富的支撐工具。上一頁下一頁返回2.2軟件過程模型

(2)結構簡單明了，反映了工程的實際情況。每個階段必須完成規定的文檔，每個階段結束前完成文檔審查，能及早改正錯誤。

(3)階段具有順序性和依賴性，確定了需求分析的絕對重要性，強調推遲實現的觀點。瀑布模型把軟件過程看成嚴格線性化的過程，適用于需求能在早期階段被完全確定、后期變化很小的情況。然而，瀑布模型的這種假設太過理想化，實際中需求很難在開發初期就明確給定，并且軟件開發流程之間存在大量的交叉和迭代。采用瀑布模型開發軟件時，暴露出的主要問題包括以下幾個方面。

(1)對用戶需求變更的響應較困難，尤其當這種需求是在開發的后期提出時。上一頁下一頁返回2.2軟件過程模型

(2)早期引入的錯誤可能在開發后期才發現，這時修改的代價很大，甚至可能導致項目最終失敗。

采用極端的瀑布型開發方法意味著要以嚴格的順序來完成一系列的項目階段:需求分析、設計、實現和測試。實際上，多數的開發團隊使用改進了的瀑布型開發方法，他們將項目分解成為兩個或者更多的部分，這些部分被稱為階段或者時期。這種改良可以幫助簡化集成、使測試人員更早地進行測試工作和提供更早的項目狀態的觀測。這種方法也將代碼分解成了易于管理的片斷并最小化了以存根和驅動程序形式的、被測試需要的代碼集成。此外，這種方法允許使用來自每一個階段的反饋修改設計。然而，使用瀑布型開發方法的執行與想象是相反的:很多設計團隊把在第一階段之后的對設計的修改視為最初設計或者需求過程的失敗。雖然一個改進了的瀑布型開發方法并不排除反饋的使用，但是它并沒有促進、支持和鼓勵反饋的使用。上一頁下一頁返回2.2軟件過程模型

2.2.2原型模型

軟件過程模型一直在演變中，原型過程模型是在瀑布模型基礎上引入局部迭代而得到的。原型模型先快速構建一個可運行的軟件原型，由客戶或未來的用戶試用該原型，并在原型的幫助下確定需求。如圖2.2所示，這一交互過程一直進行，直到開發人員可以將客戶的真實需求完全確定為止。最后，在確定的需求基礎上開發軟件產品。原型法的優點如下。

(1)原型法強化溝通，可以改進需求質量，降低風險，提高項目成功率。

(2)原型雖然投入了較多先期的時間，但可以顯著減少后期變更的時間。上一頁下一頁返回2.2軟件過程模型

(3)原型投入的人力成本代價并不大，還可以節省后期成本。

(4)原型通過充分和客戶交流，還可以提高客戶滿意度。依據對待原型的方式，原型法又分為:拋棄式，即原型只用來獲取需求，在取得的明確需求基礎上重新開始設計與開發;演化式(探索式)，即最后的系統是在原型基礎上繼續開發完成的。無淪拋棄式還是探索式，原型主要用來解決系統描述中不確定的、模糊的部分。對于很小規模的系統或者中型系統，原型法可以快速構建系統原型，明確系統需求，進而克服瀑布模型的缺點。但是，對于大型的、生命周期很長的系統，快速構建系統原型不太可能，這時使用原型法存在諸多問題。具體包括以下幾個方面。上一頁下一頁返回2.2軟件過程模型

(1)原型法強調快速開發，系統開發過程變得不可見。但對于強調工程控制和管理的大型系統來說，這一點顯然無法承受。

(2)軟件原型是通過不斷修改而形成的，因此系統的結構通常較差，這很容易導致大型項目在集成時失敗。

(3)需要采用支持快速構造的開發技術和工具，但這些技術和工具未必與主流技術和工具相容，而且掌握這些特別工具和技術的人較少。軟件生命周期法中并不包括原型，或者說沒有明確提供原型的概念和定義。可以認為原型是需求分析中的一個子部分。另外，應該說原型方法是對生命周期法的有益補充和完善。圖2.3所示為原型(拋棄式)用在軟件工程過程中的圖示。上一頁下一頁返回2.2軟件過程模型

2.2.3增量模型

單純的瀑布模型和原型模型都有優缺點，對于絕大多數大型項目來說，需要對不同的部分采用不同的方法。這就需要研究混合式過程，使其既包括瀑布模型的優點又涵蓋原型模型的優點。增量模型就是在這樣的思想背景下提出的混合式模型。如圖2.4所示，增量模型把軟件視為一個可添加的系統，像堆積木一樣每次通過分析、設計、編碼、測試交付一個模塊或子系統，逐步完成。當然，首先交付的應當是對系統有決定作用的基礎模塊，如系統菜單，其次是業務中心子系統。當用戶對先交付的模塊驗收滿意后再開發后繼模塊。上一頁下一頁返回2.2軟件過程模型

增量模型融合了線性順序模型的基本成分(重復地應用)和原型的迭代特征。增量模型采用隨著口程時間的進展而交錯的線性序列。每一個線性序列產生軟件的一個可發布的“增量”。當使用增量模型時，第一個增量往往是核心產品，即實現了基本的需求，但很多補充的特性(其中一些是已知的，另外一些是未知的)還沒有發布。核心產品交用戶使用(或進行更詳細的復審)，使用和//或評估的結果是下一個增量的開發計劃。該計劃包括對核心產品的修改，使其能更好地滿足用戶的需要，并發布一些新增的特點和功能。這個過程在每一個增量發布后不斷重復，直到產生最終的完善產品。采用增量模型的優點如下。

(1)人員分配靈活，剛開始不用投入大量人力資源。如果核心產品很受歡迎，則可增加人力實現下一個增量。上一頁下一頁返回2.2軟件過程模型

(2)當配備的人員不能在設定的期限內完成產品時，它提供了一種先推出核心產品的途徑。這樣即可先發布關鍵功能給客戶，對客戶起到鎮靜劑的作用。

(3)客戶可以將早期的增量作為原型，從中獲得對后面增量的需求經驗。

(4)項目總體失敗風險小，即使出現問題，總有一些增量可以交付客戶。

(5)關鍵的服務最早被開發，而后面的增量是不斷被集成進來的，這就使得最重要的增量會接受最多的測試。增量模型在各個階段并不交付一個可運行的完整產品，而是交付滿足客戶需求的一個子集的可運行產品。整個產品被分解成若干個增量，開發人員逐個增量地交付產品，這樣做也存在許多問題。上一頁下一頁返回2.2軟件過程模型

(1)由于各個增量是逐漸并人已有的軟件體系結構中的，所以加人新增量必須不破壞已構造好的系統部分，這需要軟件具備開放式的體系結構。

(2)在開發過程中，需求的變化是不可避免的。增量模型的靈活性可以使其適應這種變化的能力遠遠優于瀑布模型和快速原型模型，但也很容易退化為邊做邊改模型，從而使軟件過程的控制失去整體性。增量過程模型，像原型和其他演化方法一樣，具有迭代的特征。但與原型不一樣，增量模型強調每一個增量均發布一個可操作產品。早期的增量是最終產品的“可拆卸”版本，但它們確實提供了給用戶服務的功能，并且提供了給用戶評估的平臺。上一頁下一頁返回2.2軟件過程模型

增量式方法的一個進化是極限編程，它通過不斷開發和交付非常小的功能增量來實現系統。極限編程強調持續反饋和盡早發現問題，適用于在開發軟件過程中面對模糊或者快速多變的需求。Bcck的文章介紹了使用這種方法的一些成功項目，但這種方法還處于發展過程中。上一頁下一頁返回2.2軟件過程模型

2.2.4螺旋模型

1988年，BarryBochm正式發表了軟件系統開發的螺旋模型，它同樣是一種混合模型，也是將瀑布模型和快速原型模型結合起來，不同之處在于它強調了其他模型所忽視的風險分析，特別適合于大型復雜的系統。如圖2.5所示，螺旋模型將軟件過程劃分為若干個螺旋線。螺旋線的每個回路表示軟件過程的一個階段。因此，最里面的回路可能與可行性有關，接下來的回路與系統需求有關，再下一個回路與系統設計有關，等等。螺旋線的每個回路又被分成4個部分，圖中的4個象限代表了這4個部分。上一頁下一頁返回2.2軟件過程模型

(1)制訂計劃:為項目的這個階段定義目標，規劃可選的實施方案，弄清項目開發的限制條件。

(2)風險分析:分析評估所選方案，考慮如何識別和消除風險。

(3)實施工程:實施軟件開發和驗證。

(4)客戶評估:評價開發工作，提出修正建議，制訂下一步計劃。螺旋模型采用一種周期性的方法來進行系統開發。這會導致開發出眾多的中間版本。早期的版本可以作為原型供客戶使用，或為客戶證實某些概念。采用螺旋模型的過程整體上類似于快速原型法，以進化的開發方式為中心，在每個項目階段使用瀑布模型法。瀑布模型的每一個周期都包括前述4個階段，由這4個階段進行迭代。軟件開發過程每迭代一次，軟件開發又前進一個層次。采用螺旋模型的軟件過程如圖2.6所示。上一頁下一頁返回2.2軟件過程模型

螺旋模型強調風險分析，使得開發人員和用戶對每個演化層出現的風險有所了解，繼而作出應有的反應，因此特別適用于龐大、復雜并具有高風險的系統。對于這些系統，風險是軟件開發不可忽視且潛在的不利因素，它可能在不同程度上損害軟件開發過程，影響軟件產品的質量。減小軟件風險的目標是在造成危害之前，及時對風險進行識別及分析，決定采取何種對策，進而消除或減少風險的損害。螺旋模型由風險驅動、強調可選方案和約束條件，從而有助于將軟件質量作為特殊目標融人產品開發之中。但是，采用螺旋模型開發軟件也存在一些問題和限制條件，具體如下。

(1)螺旋模型強調風險分析，但要求許多客戶接受和相信這種分析，并作出相關反應是不容易的，因此，這種模型往往適應于內部的大規模軟件開發。上一頁下一頁返回2.2軟件過程模型

(2)如果執行風險分析將極大地影響項目的利潤，那么進行風險分析毫無意義，因此，螺旋模型只適合于大規模軟件項目。(3)采用螺旋模型需要具有相當豐富的風險評估經驗和專門知識，在風險較大的項目開發中，如果未能夠及時標識風險，勢必造成重大損失。

(4)過多的迭代次數會增加開發成本，延遲提交時間。螺旋模型和增量模型都是以某個原型或初始子集為基礎，通過不斷的演化得到滿足用戶需求的軟件產品，兩者之間的區別如下。

(1)螺旋模型是事先定義大部分需求，開發過程中計劃性比較強。而增量模型是事先定義少部分需求，靈活的迭代開發和經常的客戶反饋，減少了項目風險。

(2)螺旋模型在過程級迭代，增量模型在活動級迭代。

(3)螺旋模型每次迭代都提交一個完整的軟件版本，而增量模型每次增量開發是在上次增量的基礎上提交新的一部分軟件。上一頁下一頁返回2.2軟件過程模型

2.2.5形式化系統開發

形式化方法建立在嚴格的數學基礎上，其開發過程基于的是用形式化數學轉換來將系統描述轉換為一個可執行的程序。因此，用形式化開發方法開發的系統具有較高的可信度和正確性，它適用于開發對安全性、可靠性等要求極高的系統。如圖2.7所示，形式化方法類似于瀑布模型的方法。但兩者有著本質的區別:形式化開發方法中將需求用數學符號進行形式化描述;瀑布模型中的設計、實現和單元測試等開發過程被形式化轉換過程代替。在形式化變換過程中，系統形式化的數學表達被轉換成更詳細但仍然正確的數學表達。每轉換一次增加一些細節，直至形式化描述最終被轉換成一個可執行的程序。上一頁下一頁返回2.2軟件過程模型

由于轉換過程的正確性得到數學上的保證，因此轉換的結果程序具有較少的缺陷和較高的安全性。盡管如此，除了一些特殊的系統，形式化方法的應用并不多。原因主要在于以下幾個方面。

(1形式化方法的掌握需要經過特殊的Jil練。

(2)形式化描述和轉換的人力、物力費用很大，采用這種方法開發軟件在成本和質量上并不占優勢。

(3)形式化方法很難描述系統交互，而系統交互是大多現實系統的重要部分。上一頁下一頁返回2.2軟件過程模型

2.2.6基于組件的開發模型

軟件復用被認為是提高軟件開發效率和質量的最有效途徑。最近幾年，一個面向復用的軟件開發方法(基于組件的開發方法)出現了，并且正在逐漸地被廣泛使用。基于組件的開發方法依賴于可獲取的可復用組件及能集成這些組件的框架。基于組件的軟件開發過程模型如圖2.8所示。

基于組件開發方法的需求分析和系統驗證與其他過程類似，不同之處在于中間的幾個階段。在需求確定后，開發人員會搜尋可供使用的組件，并分析得到的組件。通常沒有剛好滿足要求的組件，在分析組件信息基礎上，開發人員可能調整需求以適應組件或者修改現有組件以適應需求。所選的組件可能是從市場上采購或從舊組件中提煉出來上一頁下一頁返回2.2軟件過程模型

的，也可能是新開發的。選完組件后，開發人員要依據所選組件設計系統架構或者復用已有的架構。最后，將所有組件集成起來并完成測試工作。基于組件的開發方法可以減少待開發軟件數量，減低軟件成本，提高軟件質量，相對其他過程具有明顯的優勢。然而，該方法的使用也受到一些因素的制約。為適應組件，需求的修改通常是不可避免的，而這種修改有可能導致系統不符合用戶的需要。此外，系統的進化無法控制，因為可復用組件的新版本不一定是由開發機構控制的。上一頁返回2.3計算機輔助軟件工程

計算機輔助軟件工程(CASE)是幫助進行應用程序開發的軟件，包括:需求分析、設計，程序開發和測試。CASE是一組工具和方法的集合，用來促進軟件過程的自動化，提高軟件開發的效率和軟件的質量。

CASE工具由許多部分組成，一般按軟件開發的不同階段分為上游C