軟件工程過程模型課件

第2章軟件工程過程模型2.1軟件工程的技術基礎2.2軟件工程過程2.3軟件過程模型2.4線性順序模型2.5原型模型2.6快速應用開發(fā)模型2.7演化軟件過程模型2.8軟件過程技術2.9軟件重用技術2.10小結第2章軟件工程過程模型2.1軟件工程的技術基礎12.1軟件工程的技術基礎圖2.1軟件工程過程層次圖2.1軟件工程的技術基礎圖2.1軟件工程過程層次圖2正如其他工程方法一樣，軟件工程必須以有組織的軟件質量保證為基礎。因此說，對質量的關注構成了軟件工程的根基。軟件工程過程是將技術層(包括工程技術與管理技術)結合在一起的凝聚力。過程層是軟件工程的基層。軟件工程過程定義了一組關鍵過程域(KPAs)，這對于軟件工程技術的有效應用是必需的。這些關鍵過程區(qū)域是對軟件工程項目進行管理與控制的基礎，并且確定了上、下各區(qū)域之間的關系。其中，對于技術方法的采用、階段產品的產生、工程里程碑的建立、質量監(jiān)控與保證、變更控制等方面都進行了規(guī)定。除各個開發(fā)組織可以定義自己的軟件工程過程之外，目前流行比較廣泛的軟件工程過程包括有RUP過程、極限(XP)過程、敏捷軟件過程(AgileS.P)等等。正如其他工程方法一樣，軟件工程必須以有組織的軟件質量3軟件工程方法涵蓋了需求分析、設計、編程、測試、維護等各個環(huán)節(jié)，它給出了完成這些任務在技術上應當“如何做”的方法。它依賴于一組基本原則，這些原則控制了每一個技術區(qū)域，涉及到建模活動和其他描述技術。工具層對過程和方法提供支持，使得工程活動、管理活動得以自動、半自動的進行。例如，目前廣為使用的數據庫建模工具Erwin、面向對象的建模工具RationnalRose、配置管理工具等等。如果把一系列的工具集成起來使用，使得一個工具產生的信息可以被另一個工具使用時，就形成了一個支持軟件開發(fā)的系統。這種集成了軟件、硬件和一個軟件工程數據庫的軟件工程環(huán)境，稱為計算機輔助軟件工程(CASE)。軟件工程方法涵蓋了需求分析、設計、編程、測試、維護等42.2軟件工程過程如前所述，軟件工程過程是開發(fā)或維護軟件及其相關產品的一系列活動。軟件工程過程是過去十年中人們關注的焦點。軟件工程和軟件工程過程之間是強相關的。軟件工程過程通常包括四種基本的過程活動：(1)軟件規(guī)格說明：規(guī)定軟件的功能、性能及其運行限制。(2)軟件開發(fā)：產生滿足規(guī)格說明的軟件，包括設計與編碼等工作。(3)軟件確認：確認軟件能夠滿足客戶提出的要求，對應于軟件測試。(4)軟件演進：為滿足客戶的變更要求，軟件必須在使用的過程中演進，以求盡量延長軟件的生命周期。2.2軟件工程過程如前所述，軟件工程過程是開發(fā)或5在一個良好的軟件過程中，還應當包括一些“保護性”的活動，包括軟件項目的跟蹤監(jiān)控、正式的技術審核、軟件配置管理活動、軟件質量保證活動、文檔的準備和產生、軟件測試、風險管理等等。這些保護性活動貫穿于整個工程過程之中。在具體的工程過程中，可以根據實際需要，采用不同的過程模型來實現上述的基本活動和保護活動。事實上，軟件工程過程是一個軟件開發(fā)組織針對某一類軟件產品為自己規(guī)定的工作步驟，它應當是科學的、合理的，否則必將影響到軟件產品的質量。一個良好的軟件工程過程應當具備如下特點：在一個良好的軟件過程中，還應當包括一些“保護性”的活6(1)易理解性。(2)可見性：每個過程活動都以得到明確的結果而告終，保證過程的進展對外可見。(3)可支持性：容易得到CASE工具的支持。(4)可接受性：比較容易被軟件工程師接受和使用。(5)可靠性：不會出現過程錯誤，或者出現的過程錯誤能夠在產品出錯之前被發(fā)現。(6)健壯性：不受意外發(fā)生問題的干擾。(7)可維護性：過程可以根據開發(fā)組織的需求的改變而改進。(8)高效率：從給出軟件規(guī)格說明起，就能夠較快地完成開發(fā)而交付使用。(1)易理解性。7一個軟件過程可以表示成如圖2.2所示的形式。其中，公共過程框架是通過定義若干適合于所有軟件項目的框架活動而建立的；若干任務集合中，每一個集合都由軟件工程工作任務、軟件項目里程碑、軟件工作產品和交付物以及質量保證點組成；保護性活動獨立于任何一個框架，貫穿于整個過程。一個軟件過程可以表示成如圖2.2所示的形式。其中，公8圖2.2軟件工程過程圖2.2軟件工程過程92.3軟件過程模型在一個具體的實際工程活動中，軟件工程師必須設計、提煉出一個工程開發(fā)策略，用以覆蓋軟件過程中的基本階段，確定所涉及的過程、方法、工具。這種策略常被稱為“軟件工程過程模型”。這一模型的選擇應當是根據組織定義的標準軟件過程，參考具體工程項目的特點和資源狀況進行裁剪來進行的。2.3軟件過程模型在一個具體的實際工程活動中，軟10從宏觀上來看，所有的軟件開發(fā)過程都可以看成是一個循環(huán)解決問題的過程。其中包括四個截然不同的階段：狀態(tài)描述、問題定義、技術開發(fā)和方案綜述，如圖2.3所示。狀態(tài)描述表示了事物的當前狀態(tài)；問題定義標識了要解決的特定問題；技術開發(fā)通過應用某些技術來解決問題；方案綜述提交解決結果(如文檔、程序、數據、新的商業(yè)功能、新產品)給那些從一開始就需要方案的人。前面定義的軟件工程的一般階段和步驟很容易映射到這些階段上。

從宏觀上來看，所有的軟件開發(fā)過程都可以看成是一個循環(huán)11圖2.3問題循環(huán)解決的各個階段圖2.3問題循環(huán)解決的各個階段12上述的問題循環(huán)解決過程可以應用于軟件工程的多個不同開發(fā)級別(階段)上，包括考慮整個系統開發(fā)的宏觀階段，開發(fā)程序構件的中間階段，甚至是代碼編制階段，因此可以采用分級集合表示?？梢远x一個模式，然后在連續(xù)的、更小的規(guī)模上遞歸地應用它，這樣來提供一個關于過程的理想化的視圖。問題循環(huán)解決過程的每一個階段又包含一個相同的問題循環(huán)解決過程，如圖2.4所示。可以認為，軟件開發(fā)是從用戶到開發(fā)者再到技術的一個連續(xù)的過程。隨著向一個完整系統的逐步進展，上述的階段遞歸地應用于用戶的需求和開發(fā)者的軟件技術說明中。

上述的問題循環(huán)解決過程可以應用于軟件工程的多個不同開13圖2.4問題循環(huán)解決階段中的階段圖2.4問題循環(huán)解決階段中的階段14要想像圖2.3那樣清楚地劃分階段活動是很困難的，因為階段內部和階段之間的活動往往是交叉的。但是對于任何一個軟件項目而言，不管選擇了什么樣的具體的軟件工程過程模型，所有四個活動階段在某個細節(jié)的級別上都是同時存在的。圖2.4描述了實際過程的遞歸性質。在后面的討論中，我們將會看到，每一種具體的軟件工程過程模型實際上都代表了一種將本質上無序的活動有序化的企圖。每一種模型都具有能夠幫助實際軟件項目的控制及協調的特征，但在它們的核心中，這些模型又表現了無序模型的特點。要想像圖2.3那樣清楚地劃分階段活動是很困難的，因為15在軟件工程實踐中，有許多專家治力于過程模型的研究。像瀑布模型、原型模型、快速應用開發(fā)模型、增量模型、螺旋模型、形式化方法模型、RUP模型、敏捷過程模型、構件組裝模型、并發(fā)開發(fā)模型等等都先后得到了有效的應用。目前，關于軟件工程過程模型的研究仍然在積極地進行之中，將不斷取得新的進展與成就。在軟件工程實踐中，有許多專家治力于過程模型的研究。像162.4線性順序模型圖2.5線性順序模型2.4線性順序模型圖2.5線性順序模型17線性順序模型有時也稱為“瀑布模型”。它表示了軟件開發(fā)系統的、順序的方法。雖然瀑布模型支持帶反饋的循環(huán)，但大多數使用者均把它視為是嚴格線性的。從系統級開始，隨后是分析、設計、編碼、測試和維護。借鑒傳統的工程周期，線性順序模型的活動如圖2.5所示。

線性順序模型有時也稱為“瀑布模型”。它表示了軟件開18線性順序模型是最早，也曾經是應用最廣泛的軟件工程過程模型，但是這種模型不適應需求經常發(fā)生變更的環(huán)境。實際的項目很少能夠嚴格地按照該模型給出的順序進行。需求的變更、設計的變更、編碼的變更幾乎是不可避免的。雖然線性順序模型能夠允許迭代，但卻是間接的迭代。在項目的開發(fā)過程中，變更可能會引起混亂。所以，有人形象地把采用線性模型進行商業(yè)軟件工程稱之為“在沙灘上蓋樓房”?？紤]到用戶對于需求的理解有一個漸進漸深的過程，一開始用戶往往難以明確地提出所有的需求，這樣，線性順序模型的第一步輸入就得不到滿足。線性順序模型是最早，也曾經是應用最廣泛的軟件工程過程19同時，線性順序模型也經常不能接受項目開始階段自然存在的不確定性。在采用線性順序模型的時候，用戶只有到項目的開發(fā)晚期才能夠得到程序的可運行版本。大的錯誤如果到這時才被發(fā)現，那么造成的后果往往是災難性的。同時，因為線性順序模型每一步的工作都必須以前一階段的輸出為輸入，這種特征會導致工作中發(fā)生“阻塞”狀態(tài)。某些項目組成員不得不等待組內其他成員先完成前驅任務才可能展開自己的工作。有時這種等待時間可能會超過實際花在工作上的時間。這種阻塞狀態(tài)在線性順序過程的開始和結束時經常會發(fā)生。同時，線性順序模型也經常不能接受項目開始階段自然存在20雖然存在著上述的種種問題，但是線性順序模型仍然有其值得肯定之處。它提供了一個模板，使得分析、設計、編碼、測試與維護工作可以在該模板的指導下有序地展開，避免了軟件開發(fā)、維護過程中的隨意狀態(tài)。采用這種模型，曾經成功地進行過許多大型軟件工程的開發(fā)。直至目前，對于需求確定、變更相對較少的項目，線性順序模型仍然是一種可以考慮采取的過程模型。但在“用戶驅動”的商業(yè)軟件開發(fā)中，采用線性順序模型并不是一個好的選擇。雖然存在著上述的種種問題，但是線性順序模型仍然有其值212.5原型模型大型建筑在施工之前，常常按照圖紙制造一個縮小的模型來驗證工程完成后可能的效果；新的工業(yè)設計在充分證明其正確性之前，也往往利用在縮小規(guī)模的前提下制造少量成品進行檢驗的方法來驗證設計正確與否。同樣的，如果在開發(fā)一項軟件工程的時候，用戶不能準確、全面地描述其需求，或者開發(fā)者還不能確定所選用算法的有效性或人機交互界面的形式時，同樣也可以建立一個簡化了的樣品程序并使之運行，引導用戶通過對樣品運行情況的觀察，進一步明確需求或驗證算法的正確性。這種開發(fā)模式就稱之為“原型模型”，如圖2.6所示。2.5原型模型大型建筑在施工之前，常常按照22圖2.6原型模型圖2.6原型模型23原型模型從需求收集開始，開發(fā)者和用戶在一起定義軟件的總體目標，標識出已知的需求，并規(guī)劃出進一步定義的區(qū)域。然后進行快速設計并進行編碼實現，進行原型的建造。這種快速設計和建造通常集中在那些對用戶可見的部分(如輸入方式、輸出界面)。原型建造好之后，運行原型程序，由用戶和開發(fā)者進行評估、驗證。接著進一步精化待開發(fā)軟件的需求，逐步調整原型以使其逐漸滿足用戶的真正需求，同時也使開發(fā)者對將要完成的開發(fā)任務有更深入的理解。這一過程是多次迭代進行的。原型模型從需求收集開始，開發(fā)者和用戶在一起定義軟件的24使用原型模型必須有兩個前提。其一是用戶必須積極參與原型的建造，同時開發(fā)者和用戶必須有共識：建造原型僅僅是為了定義需求，之后就必須被全部拋棄(至少是部分拋棄)，實際的軟件必須在充分考慮到軟件質量和可維護性之后才被開發(fā)。從這個意義上說，原型模型又往往被稱為“拋棄原型模型”。其二是必須有快速開發(fā)工具可供使用。使用原型模型必須有兩個前提。其一是用戶必須積極參與原252.6快速應用開發(fā)模型快速應用開發(fā)(RAD)模型是線性順序模型的一個“高速”變種，強調極端的開發(fā)周期。RAD模型通過使用基于構件的建造方法達到快速開發(fā)的效果。在需求得到很好理解、項目的范圍約束明晰的前提下(通常不容易保證這樣的條件)，采用RAD過程能夠使項目組在很短的時間內(如60～90)天創(chuàng)建出功能完善的系統。RAD過程主要用于信息應用軟件的開發(fā)，如圖2.7所示，它包含如下幾個開發(fā)階段：2.6快速應用開發(fā)模型快速應用開發(fā)(RAD)模型是26圖2.7RAD模型圖2.7RAD模型27業(yè)務建模：業(yè)務活動中的信息流被模型化。此階段說明什么信息驅動業(yè)務流程、生成什么信息、誰負責生成該信息、該信息流向何處、誰處理它等。數據建模：業(yè)務建模階段定義的一部分信息流被精化，形成一組支持該業(yè)務所需的數據對象。此階段標識出每個數據對象的特征屬性，定義這些對象之間的關系。處理建模：數據建模階段定義的數據對象變換成為要完成一項業(yè)務功能所需的信息流。此階段創(chuàng)建處理描述以便增加、修改、刪除或獲取某個數據對象。業(yè)務建模：業(yè)務活動中的信息流被模型化。此階段說明什么28應用生成：RAD過程不是采用傳統的第三代程序設計語言來創(chuàng)建軟件，而主要是復用已有的程序構件或是創(chuàng)建可復用的構件。在所有情況下，均使用自動化工具輔助軟件建造。測試及反復：RAD過程強調復用，許多構件是已經測試過的，減少了測試工作量。但是所有的新創(chuàng)建構件、所有的接口都必須測試到。采用RAD模型時，系統的每一個主要功能部件可以由一個單獨的RAD工作組完成，最后再將所有的部件集成起來形成完整的軟件。應用生成：RAD過程不是采用傳統的第三代程序設計語言29RAD模型強調可復用程序構件的開發(fā)，支持多小組并行工作以縮短整體工期。但是如果一個系統難以被適當地模塊化，構件的復用和建造就會出現問題。作為線性順序模型的一個變種，它具有線性順序模型所具有的種種特性。同時，RAD模型依賴于構件復用，它不適用于技術風險很高的、要采用很多新技術的項目。對于具有高性能需求的軟件，如果這種高性能必須通過對接口的反復調整才能實現，那么采用RAD模型也就有可能失敗。RAD模型強調可復用程序構件的開發(fā)，支持多小組并行工302.7演化軟件過程模型軟件就象其他復雜系統一樣，需要經過一段時間的演化改進，才能夠最終滿足用戶需求。業(yè)務和產品需求隨著開發(fā)的進展常常發(fā)生變更，因而難以一步到位地完成最終的軟件產品，但是，緊迫的市場期限又不允許軟件工程師過多地延長開發(fā)周期。為了應對市場競爭或商業(yè)目標的壓力，構造了“演化軟件模型”。它的基本思想是“分期完成、分步提交”?？梢韵忍峤灰粋€有限功能的版本，再逐步地使其完善。2.7演化軟件過程模型軟件就象其他復雜系統一樣，需31演化模型的主要特點是利用“迭代”方法，使工程師們漸進地開發(fā)，生產出逐步完善的軟件版本。在商業(yè)軟件開發(fā)實踐中，演化模型日益得到廣泛的應用。用戶的支持、理解和全程參與是成功采用演化模型的重要前提。演化模型兼有線性順序模型和原型模型的一些特點。但線性順序模型本質上是假設當線性開發(fā)序列完成之后就能夠交付一個完整的系統；原型模型的目的是引導用戶明確需求、幫助工程師驗證算法，總體上講它并不交付一個最終的產品系統。它們都沒有考慮到軟件的“演化”過程。根據開發(fā)策略的不同，演化模型又可以細分為“增量”模型和“螺旋”模型兩種。演化模型的主要特點是利用“迭代”方法，使工程師們漸進322.7.1增量模型增量模型融合了線性順序模型的基本成分(重復的應用這些成分)和原型模型的迭代特征，如圖2.8所示。增量模型實際上是一個隨著日程/時間的進展而交錯的線性序列集合。每一個線性序列產生一個軟件的可發(fā)布的“增量”，所有的增量都能夠結合到原型模型中去。2.7.1增量模型33圖2.8增量模型圖2.8增量模型34當使用增量模型時，第一個增量模型往往是核心部分的產品，它實現了軟件的基本需求，但很多已經明晰或者尚不明晰的補充特性還沒有發(fā)布。核心產品交由用戶使用或進行詳細復審。使用或復審評估的結果是制定下一個增量開發(fā)計劃。該計劃包括對核心產品的修改及增加一些新的功能與特性。這個過程在每一個增量發(fā)布后迭代地進行，直到產生最終的完善產品。和原型模型不一樣的是，增量模型雖然也具有“迭代”特征，但是每一個增量都發(fā)布一個可操作的產品，不妨稱之為“產品擴充迭代”。它的早期產品是最終產品的可拆卸版本，每一個版本都能夠提供給用戶實際使用。當使用增量模型時，第一個增量模型往往是核心部分的產品35在實際開發(fā)過程中，增量模型是十分有用的一種模型。對于防范技術風險、縮短產品提交時間都能夠起到良好的作用。應當再次強調的是，用戶在開發(fā)軟件的過程中，往往有“一步到位”的思想，因而增量式的工程開發(fā)必須取得用戶的全面理解與支持，否則是難以成功的。在實際開發(fā)過程中，增量模型是十分有用的一種模型。對于362.7.2螺旋模型螺旋模型也是屬于演化軟件過程模型。它將原型的迭代特征與線性順序模型中控制的和系統化的方面結合起來，使得能夠快速開發(fā)軟件的增量版本。在螺旋模型中，軟件開發(fā)是一系列的增量發(fā)布。和增量模型不同，它并不要求每一個增量都是可以運行的程序。在早期的迭代中，發(fā)布的增量可以是一個紙上的模型或原型；在以后的迭代中產生更加完善的版本。螺旋模型被劃分為若干個框架活動，如圖2.9所示?；顒右卜Q為任務區(qū)域，一般包括：2.7.2螺旋模型37(1)用戶通信：建立開發(fā)者和用戶之間有效通信所需要的任務。(2)計劃：定義資源、進度和其他項目相關信息所需要的任務。(3)風險分析：評估技術的及管理的風險所需要的任務。(4)工程：建立應用的一個或多個表示所需要的任務。(5)建造及發(fā)布：建造、測試、安裝和提供用戶支持所需要的任務。(6)用戶評估：基于在工程階段產生的或在安裝階段實現的軟件表示的評估，是獲得用戶反饋所必需的任務。(1)用戶通信：建立開發(fā)者和用戶之間有效通信所需要38圖2.9一個典型的螺旋模型圖2.9一個典型的螺旋模型39每一個框架活動(任務區(qū)域)均含有一系列的適應待開發(fā)項目特點的工作任務(活動)。在所有的情況下，都需要應用諸如軟件配置管理、軟件品質保證等保護性活動。隨著演化過程的開始，軟件工程項目組按照順時針方向沿螺旋移動。從核心開始，第一圈可能產生軟件規(guī)格說明書，第二圈可能開發(fā)出一個原型，隨后可能是軟件更完善的版本。經過計劃區(qū)域的每一圈都會對計劃進行調整，基于從用戶處得到的反饋，調整進度和費用以及版本的內容。項目管理者可以根據項目的具體情況調整所需要的迭代次數。

每一個框架活動(任務區(qū)域)均含有一系列的適應待開發(fā)項40和傳統的過程模型不同，螺旋模型能夠適應于計算機軟件產品的整個生命周期，而不是當軟件交付后就結束過程。對于大型系統及軟件的開發(fā)工作來說，螺旋模型是一種很好的模型方法。采用這種模型，隨著過程的發(fā)展演化，開發(fā)者和用戶能夠更好地理解和對待每一個演化級別上的風險。它使開發(fā)者在產品演化的任何階段上都能夠使用原型方法，保持了傳統生命周期模型中的階段化的工作方式，但同時又引入了迭代的框架，更加真實地反映了現實世界。同時也有利于防范技術風險。螺旋模型的應用同樣有賴于用戶的充分理解和積極參與。同時，它需要使用專門的風險評估技術以便識別風險、防范風險。和傳統的過程模型不同，螺旋模型能夠適應于計算機軟件產412.8軟件過程技術前面討論的過程模型必須適合于軟件項目組的使用。為滿足這一要求，先后開發(fā)出了許多過程管理工具以幫助軟件組織分析他們當前的過程，協調組織工作任務，控制和監(jiān)管進度以及管理技術質量。例如，利用配置管理工具來進行配置管理和缺陷管理；利用自動測試工具進行測試；利用統一建模語言UML來進行對象建模、分析與設計；利用Project制訂和監(jiān)測項目計劃及其進展；利用第四代技術，通過開發(fā)者在較高的層次上說明軟件的某些特征，之后工具就能夠自動的根據說明生成源代碼等等。計算機輔助軟件工程已經在軟件領域中發(fā)揮著重要的作用。2.8軟件過程技術前面討論的過程模型必須適合于軟件42采用合適的過程技術工具，使得軟件開發(fā)組織能夠建造一個自動模型，該模型包括通用的過程框架、任務集合及保護性活動。該模型一般表示成一個網絡，對其加以分析，就能夠確定典型的工作流程，考察可能導致降低開發(fā)時間和成本的可供選擇的過程結構。一旦創(chuàng)建了一個可接受的過程，就可以使用其他過程工具來分配、監(jiān)管，甚至控制過程模型中所定義的所有軟件工程任務。軟件項目組的每一個成員均能夠使用這些工具產生一個清單，包括：要完成的任務、要開發(fā)的工作產品以及要實現的質量控制活動等等。采用合適的過程技術工具，使得軟件開發(fā)組織能夠建造一個432.9軟件重用技術“重用”是提升軟件財富價值的有效途徑。一般來說，這里所指的重用可以包括知識重用、方法重用、軟件成分重用三個層次。例如，軟件工程知識的重用使我們能夠高效率的開發(fā)、維護一個又一個的軟件項目；行之有效的軟件工程方法的重用幫助我們有章可循的解決各類工程問題；軟件成分的重用則使我們在需求分析、系統設計和編碼事項的過程中能夠事半功倍2.9軟件重用技術“重用”是提升軟件財富價值的有效44對于軟件工程師來說，軟件成分的重用是我們最為關注的問題。介紹RAD模型時，我們已經了解了構件重用的重要作用。沒有構件重用，RAD模型就只能是紙上談兵。再具體一點地說，軟件成分重用又可以分為分析結果重用、設計結果重用和代碼重用三個層次。需求分析在軟件工程中的地位舉足輕重。一個完善的需求分析將指導我們走上成功之路，反之，錯誤的分析必將導致項目的徹底失敗。在大部或局部雷同的項目中重復地使用已經被前驅項目證明是正確的部分分析結果，是提高分析工作效率、保證分析成功的一種有效方法。對于軟件工程師來說，軟件成分的重用是我們最為關注的45設計重用在開發(fā)類同項目的軟件，尤其是在軟件移植過程中能夠極大地減少工作量，提高工作效率。設計結果重用包括體系結構設計重用和詳細設計重用兩重內涵。代碼重用是最直接的重用。包括基于“宏”的重用、基于函數庫的重用和基于繼承的重用三種不同的方法。目前，基于函數庫的重用(例如C語言)和基于繼承(VB、JAVA等)的重用代表著代碼重用的主流。尤其是基于繼承的代碼重用，隨著面向對象方法的成熟，越來越受到重視。設計重用在開發(fā)類同項目的軟件，尤其是在軟件移植過程中46基于軟件重用思想的框架(Framework)開發(fā)模式近年來備受關注。業(yè)界認為，軟件構件化是21世紀軟件工業(yè)發(fā)展的大趨勢。工業(yè)化的軟件復用已經從通用類庫進化到了面向領域的應用框架。GartnerGroup(美國一家著名的IT咨詢公司)認為：“到2003年，至少70%的新應用將主要建立在如軟件構件和應用框架這類'構造塊'之上；應用開發(fā)的未來就在于提供一個開放體系結構，以方便框架和構件的選擇、組裝和集成”?？蚣艿闹赜靡殉蔀檐浖a中最有效的重用方式之一。框架是整個或部分系統的可重用設計，表現為一組抽象構件及構件實例間交互的方法。另一種定義認為，框架是可被應用開發(fā)者定制的應用骨架。前者是從應用方面而后者是從目的方面給出的定義?；谲浖赜盟枷氲目蚣?Framework)開發(fā)模式47可以說，一個框架是一個可復用的設計構件，它規(guī)定了應用的體系結構，闡明了整個設計、協作構件之間的依賴關系、責任分配和控制流程，表現為一組抽象類以及其實例之間協作的方法，它為構件復用提供了上/下文(Context)關系。因此，構件庫的大規(guī)模重用也需要框架?？蚣艿淖畲蠛锰幘褪侵赜谩Ｃ嫦驅ο笙到y獲得的最大的復用方式就是框架，一個大的應用系統往往可能由多層互相協作的框架組成。由于框架能重用代碼，因此從一已有構件庫中建立應用變得非常容易，因為構件都采用框架統一定義的接口，所以使構件間的通信趨于簡單。可以說，一個框架是一個可復用的設計構件，它規(guī)定了應用48框架能夠重用設計。它提供可重用的抽象算法及高層設計，并能將大系統分解成更小的構件，而且能描述構件間的內部接口。這些標準接口使在已有的構件基礎上通過組裝建立各種各樣的系統成為可能。只要符合接口定義，新的構件就能插入框架中，構件設計者就能重用構件的設計?？蚣苓€能重用分析。所有的人員若都按照框架的思想來分析事務，那么就能將它劃分為同樣的構件。采用相似的解決方法，從而使采用同一框架的分析人員之間能進行溝通?？蚣苣軌蛑赜迷O計。它提供可重用的抽象算法及高層設計，49采用框架技術進行軟件開發(fā)的主要特點包括：(1)領域內的軟件結構一致性好。(2)建立了更加開放的系統。(3)重用代碼大大增加，軟件生產效率和質量也得到了提高。(4)軟件設計人員要專注于對領域的了解，使需求分析更充分。(5)存儲了經驗，可以讓那些經驗豐富的人員去設計框架和領域構件，而不必限于低層編程。采用框架技術進行軟件開發(fā)的主要特點包括：50(6)允許采用快速原型技術。(7)有利于在一個項目內多人協同工作。(8)大粒度的重用使得平均開發(fā)費用降低，開發(fā)速度加快，開發(fā)人員減少，維護費用降低，而參數化框架使得適應性、靈活性增強。在現代軟件工程領域中，“重用”軟件成分的價值越來越為人們所認知。而為了重用財富，必須持續(xù)不斷地積累財富。在工程實踐中建立軟件開發(fā)組織的財富數據庫已經成為這些組織的共識。SEI(軟件工程研究所)已經將建立與使用軟件財富庫作為提高開發(fā)組織軟件過程成熟度的一個目標，有關這方面的具體內容可參見有關CMM3級的相關資料。(6)允許采用快速原型技術。512.10小結本章講述了軟件過程的基本概念和常用軟件過程的構造與特點。我們已經知道，軟件工程在計算機軟件的開發(fā)中集成了過程、方法和工具。工程過程是用以開發(fā)或維護軟件及其相關產品的一系列活動，包括軟件工程活動和軟件管理活動。從最傳統的線性順序過程開始，本章對原型模型、演化模型、RAD模型的結構、特點作了具體的介紹。通過對本章的學習，我們應當了解到如何根據具體項目的特點和開發(fā)環(huán)境，選擇正確的過程模型，達到最佳的開發(fā)效果。2.10小結本章講述了軟件過程的基本概念和常用52第2章軟件工程過程模型2.1軟件工程的技術基礎2.2軟件工程過程2.3軟件過程模型2.4線性順序模型2.5原型模型2.6快速應用開發(fā)模型2.7演化軟件過程模型2.8軟件過程技術2.9軟件重用技術2.10小結第2章軟件工程過程模型2.1軟件工程的技術基礎532.1軟件工程的技術基礎圖2.1軟件工程過程層次圖2.1軟件工程的技術基礎圖2.1軟件工程過程層次圖54正如其他工程方法一樣，軟件工程必須以有組織的軟件質量保證為基礎。因此說，對質量的關注構成了軟件工程的根基。軟件工程過程是將技術層(包括工程技術與管理技術)結合在一起的凝聚力。過程層是軟件工程的基層。軟件工程過程定義了一組關鍵過程域(KPAs)，這對于軟件工程技術的有效應用是必需的。這些關鍵過程區(qū)域是對軟件工程項目進行管理與控制的基礎，并且確定了上、下各區(qū)域之間的關系。其中，對于技術方法的采用、階段產品的產生、工程里程碑的建立、質量監(jiān)控與保證、變更控制等方面都進行了規(guī)定。除各個開發(fā)組織可以定義自己的軟件工程過程之外，目前流行比較廣泛的軟件工程過程包括有RUP過程、極限(XP)過程、敏捷軟件過程(AgileS.P)等等。正如其他工程方法一樣，軟件工程必須以有組織的軟件質量55軟件工程方法涵蓋了需求分析、設計、編程、測試、維護等各個環(huán)節(jié)，它給出了完成這些任務在技術上應當“如何做”的方法。它依賴于一組基本原則，這些原則控制了每一個技術區(qū)域，涉及到建?；顒雍推渌枋黾夹g。工具層對過程和方法提供支持，使得工程活動、管理活動得以自動、半自動的進行。例如，目前廣為使用的數據庫建模工具Erwin、面向對象的建模工具RationnalRose、配置管理工具等等。如果把一系列的工具集成起來使用，使得一個工具產生的信息可以被另一個工具使用時，就形成了一個支持軟件開發(fā)的系統。這種集成了軟件、硬件和一個軟件工程數據庫的軟件工程環(huán)境，稱為計算機輔助軟件工程(CASE)。軟件工程方法涵蓋了需求分析、設計、編程、測試、維護等562.2軟件工程過程如前所述，軟件工程過程是開發(fā)或維護軟件及其相關產品的一系列活動。軟件工程過程是過去十年中人們關注的焦點。軟件工程和軟件工程過程之間是強相關的。軟件工程過程通常包括四種基本的過程活動：(1)軟件規(guī)格說明：規(guī)定軟件的功能、性能及其運行限制。(2)軟件開發(fā)：產生滿足規(guī)格說明的軟件，包括設計與編碼等工作。(3)軟件確認：確認軟件能夠滿足客戶提出的要求，對應于軟件測試。(4)軟件演進：為滿足客戶的變更要求，軟件必須在使用的過程中演進，以求盡量延長軟件的生命周期。2.2軟件工程過程如前所述，軟件工程過程是開發(fā)或57在一個良好的軟件過程中，還應當包括一些“保護性”的活動，包括軟件項目的跟蹤監(jiān)控、正式的技術審核、軟件配置管理活動、軟件質量保證活動、文檔的準備和產生、軟件測試、風險管理等等。這些保護性活動貫穿于整個工程過程之中。在具體的工程過程中，可以根據實際需要，采用不同的過程模型來實現上述的基本活動和保護活動。事實上，軟件工程過程是一個軟件開發(fā)組織針對某一類軟件產品為自己規(guī)定的工作步驟，它應當是科學的、合理的，否則必將影響到軟件產品的質量。一個良好的軟件工程過程應當具備如下特點：在一個良好的軟件過程中，還應當包括一些“保護性”的活58(1)易理解性。(2)可見性：每個過程活動都以得到明確的結果而告終，保證過程的進展對外可見。(3)可支持性：容易得到CASE工具的支持。(4)可接受性：比較容易被軟件工程師接受和使用。(5)可靠性：不會出現過程錯誤，或者出現的過程錯誤能夠在產品出錯之前被發(fā)現。(6)健壯性：不受意外發(fā)生問題的干擾。(7)可維護性：過程可以根據開發(fā)組織的需求的改變而改進。(8)高效率：從給出軟件規(guī)格說明起，就能夠較快地完成開發(fā)而交付使用。(1)易理解性。59一個軟件過程可以表示成如圖2.2所示的形式。其中，公共過程框架是通過定義若干適合于所有軟件項目的框架活動而建立的；若干任務集合中，每一個集合都由軟件工程工作任務、軟件項目里程碑、軟件工作產品和交付物以及質量保證點組成；保護性活動獨立于任何一個框架，貫穿于整個過程。一個軟件過程可以表示成如圖2.2所示的形式。其中，公60圖2.2軟件工程過程圖2.2軟件工程過程612.3軟件過程模型在一個具體的實際工程活動中，軟件工程師必須設計、提煉出一個工程開發(fā)策略，用以覆蓋軟件過程中的基本階段，確定所涉及的過程、方法、工具。這種策略常被稱為“軟件工程過程模型”。這一模型的選擇應當是根據組織定義的標準軟件過程，參考具體工程項目的特點和資源狀況進行裁剪來進行的。2.3軟件過程模型在一個具體的實際工程活動中，軟62從宏觀上來看，所有的軟件開發(fā)過程都可以看成是一個循環(huán)解決問題的過程。其中包括四個截然不同的階段：狀態(tài)描述、問題定義、技術開發(fā)和方案綜述，如圖2.3所示。狀態(tài)描述表示了事物的當前狀態(tài)；問題定義標識了要解決的特定問題；技術開發(fā)通過應用某些技術來解決問題；方案綜述提交解決結果(如文檔、程序、數據、新的商業(yè)功能、新產品)給那些從一開始就需要方案的人。前面定義的軟件工程的一般階段和步驟很容易映射到這些階段上。

從宏觀上來看，所有的軟件開發(fā)過程都可以看成是一個循環(huán)63圖2.3問題循環(huán)解決的各個階段圖2.3問題循環(huán)解決的各個階段64上述的問題循環(huán)解決過程可以應用于軟件工程的多個不同開發(fā)級別(階段)上，包括考慮整個系統開發(fā)的宏觀階段，開發(fā)程序構件的中間階段，甚至是代碼編制階段，因此可以采用分級集合表示?？梢远x一個模式，然后在連續(xù)的、更小的規(guī)模上遞歸地應用它，這樣來提供一個關于過程的理想化的視圖。問題循環(huán)解決過程的每一個階段又包含一個相同的問題循環(huán)解決過程，如圖2.4所示。可以認為，軟件開發(fā)是從用戶到開發(fā)者再到技術的一個連續(xù)的過程。隨著向一個完整系統的逐步進展，上述的階段遞歸地應用于用戶的需求和開發(fā)者的軟件技術說明中。

上述的問題循環(huán)解決過程可以應用于軟件工程的多個不同開65圖2.4問題循環(huán)解決階段中的階段圖2.4問題循環(huán)解決階段中的階段66要想像圖2.3那樣清楚地劃分階段活動是很困難的，因為階段內部和階段之間的活動往往是交叉的。但是對于任何一個軟件項目而言，不管選擇了什么樣的具體的軟件工程過程模型，所有四個活動階段在某個細節(jié)的級別上都是同時存在的。圖2.4描述了實際過程的遞歸性質。在后面的討論中，我們將會看到，每一種具體的軟件工程過程模型實際上都代表了一種將本質上無序的活動有序化的企圖。每一種模型都具有能夠幫助實際軟件項目的控制及協調的特征，但在它們的核心中，這些模型又表現了無序模型的特點。要想像圖2.3那樣清楚地劃分階段活動是很困難的，因為67在軟件工程實踐中，有許多專家治力于過程模型的研究。像瀑布模型、原型模型、快速應用開發(fā)模型、增量模型、螺旋模型、形式化方法模型、RUP模型、敏捷過程模型、構件組裝模型、并發(fā)開發(fā)模型等等都先后得到了有效的應用。目前，關于軟件工程過程模型的研究仍然在積極地進行之中，將不斷取得新的進展與成就。在軟件工程實踐中，有許多專家治力于過程模型的研究。像682.4線性順序模型圖2.5線性順序模型2.4線性順序模型圖2.5線性順序模型69線性順序模型有時也稱為“瀑布模型”。它表示了軟件開發(fā)系統的、順序的方法。雖然瀑布模型支持帶反饋的循環(huán)，但大多數使用者均把它視為是嚴格線性的。從系統級開始，隨后是分析、設計、編碼、測試和維護。借鑒傳統的工程周期，線性順序模型的活動如圖2.5所示。

線性順序模型有時也稱為“瀑布模型”。它表示了軟件開70線性順序模型是最早，也曾經是應用最廣泛的軟件工程過程模型，但是這種模型不適應需求經常發(fā)生變更的環(huán)境。實際的項目很少能夠嚴格地按照該模型給出的順序進行。需求的變更、設計的變更、編碼的變更幾乎是不可避免的。雖然線性順序模型能夠允許迭代，但卻是間接的迭代。在項目的開發(fā)過程中，變更可能會引起混亂。所以，有人形象地把采用線性模型進行商業(yè)軟件工程稱之為“在沙灘上蓋樓房”。考慮到用戶對于需求的理解有一個漸進漸深的過程，一開始用戶往往難以明確地提出所有的需求，這樣，線性順序模型的第一步輸入就得不到滿足。線性順序模型是最早，也曾經是應用最廣泛的軟件工程過程71同時，線性順序模型也經常不能接受項目開始階段自然存在的不確定性。在采用線性順序模型的時候，用戶只有到項目的開發(fā)晚期才能夠得到程序的可運行版本。大的錯誤如果到這時才被發(fā)現，那么造成的后果往往是災難性的。同時，因為線性順序模型每一步的工作都必須以前一階段的輸出為輸入，這種特征會導致工作中發(fā)生“阻塞”狀態(tài)。某些項目組成員不得不等待組內其他成員先完成前驅任務才可能展開自己的工作。有時這種等待時間可能會超過實際花在工作上的時間。這種阻塞狀態(tài)在線性順序過程的開始和結束時經常會發(fā)生。同時，線性順序模型也經常不能接受項目開始階段自然存在72雖然存在著上述的種種問題，但是線性順序模型仍然有其值得肯定之處。它提供了一個模板，使得分析、設計、編碼、測試與維護工作可以在該模板的指導下有序地展開，避免了軟件開發(fā)、維護過程中的隨意狀態(tài)。采用這種模型，曾經成功地進行過許多大型軟件工程的開發(fā)。直至目前，對于需求確定、變更相對較少的項目，線性順序模型仍然是一種可以考慮采取的過程模型。但在“用戶驅動”的商業(yè)軟件開發(fā)中，采用線性順序模型并不是一個好的選擇。雖然存在著上述的種種問題，但是線性順序模型仍然有其值732.5原型模型大型建筑在施工之前，常常按照圖紙制造一個縮小的模型來驗證工程完成后可能的效果；新的工業(yè)設計在充分證明其正確性之前，也往往利用在縮小規(guī)模的前提下制造少量成品進行檢驗的方法來驗證設計正確與否。同樣的，如果在開發(fā)一項軟件工程的時候，用戶不能準確、全面地描述其需求，或者開發(fā)者還不能確定所選用算法的有效性或人機交互界面的形式時，同樣也可以建立一個簡化了的樣品程序并使之運行，引導用戶通過對樣品運行情況的觀察，進一步明確需求或驗證算法的正確性。這種開發(fā)模式就稱之為“原型模型”，如圖2.6所示。2.5原型模型大型建筑在施工之前，常常按照74圖2.6原型模型圖2.6原型模型75原型模型從需求收集開始，開發(fā)者和用戶在一起定義軟件的總體目標，標識出已知的需求，并規(guī)劃出進一步定義的區(qū)域。然后進行快速設計并進行編碼實現，進行原型的建造。這種快速設計和建造通常集中在那些對用戶可見的部分(如輸入方式、輸出界面)。原型建造好之后，運行原型程序，由用戶和開發(fā)者進行評估、驗證。接著進一步精化待開發(fā)軟件的需求，逐步調整原型以使其逐漸滿足用戶的真正需求，同時也使開發(fā)者對將要完成的開發(fā)任務有更深入的理解。這一過程是多次迭代進行的。原型模型從需求收集開始，開發(fā)者和用戶在一起定義軟件的76使用原型模型必須有兩個前提。其一是用戶必須積極參與原型的建造，同時開發(fā)者和用戶必須有共識：建造原型僅僅是為了定義需求，之后就必須被全部拋棄(至少是部分拋棄)，實際的軟件必須在充分考慮到軟件質量和可維護性之后才被開發(fā)。從這個意義上說，原型模型又往往被稱為“拋棄原型模型”。其二是必須有快速開發(fā)工具可供使用。使用原型模型必須有兩個前提。其一是用戶必須積極參與原772.6快速應用開發(fā)模型快速應用開發(fā)(RAD)模型是線性順序模型的一個“高速”變種，強調極端的開發(fā)周期。RAD模型通過使用基于構件的建造方法達到快速開發(fā)的效果。在需求得到很好理解、項目的范圍約束明晰的前提下(通常不容易保證這樣的條件)，采用RAD過程能夠使項目組在很短的時間內(如60～90)天創(chuàng)建出功能完善的系統。RAD過程主要用于信息應用軟件的開發(fā)，如圖2.7所示，它包含如下幾個開發(fā)階段：2.6快速應用開發(fā)模型快速應用開發(fā)(RAD)模型是78圖2.7RAD模型圖2.7RAD模型79業(yè)務建模：業(yè)務活動中的信息流被模型化。此階段說明什么信息驅動業(yè)務流程、生成什么信息、誰負責生成該信息、該信息流向何處、誰處理它等。數據建模：業(yè)務建模階段定義的一部分信息流被精化，形成一組支持該業(yè)務所需的數據對象。此階段標識出每個數據對象的特征屬性，定義這些對象之間的關系。處理建模：數據建模階段定義的數據對象變換成為要完成一項業(yè)務功能所需的信息流。此階段創(chuàng)建處理描述以便增加、修改、刪除或獲取某個數據對象。業(yè)務建模：業(yè)務活動中的信息流被模型化。此階段說明什么80應用生成：RAD過程不是采用傳統的第三代程序設計語言來創(chuàng)建軟件，而主要是復用已有的程序構件或是創(chuàng)建可復用的構件。在所有情況下，均使用自動化工具輔助軟件建造。測試及反復：RAD過程強調復用，許多構件是已經測試過的，減少了測試工作量。但是所有的新創(chuàng)建構件、所有的接口都必須測試到。采用RAD模型時，系統的每一個主要功能部件可以由一個單獨的RAD工作組完成，最后再將所有的部件集成起來形成完整的軟件。應用生成：RAD過程不是采用傳統的第三代程序設計語言81RAD模型強調可復用程序構件的開發(fā)，支持多小組并行工作以縮短整體工期。但是如果一個系統難以被適當地模塊化，構件的復用和建造就會出現問題。作為線性順序模型的一個變種，它具有線性順序模型所具有的種種特性。同時，RAD模型依賴于構件復用，它不適用于技術風險很高的、要采用很多新技術的項目。對于具有高性能需求的軟件，如果這種高性能必須通過對接口的反復調整才能實現，那么采用RAD模型也就有可能失敗。RAD模型強調可復用程序構件的開發(fā)，支持多小組并行工822.7演化軟件過程模型軟件就象其他復雜系統一樣，需要經過一段時間的演化改進，才能夠最終滿足用戶需求。業(yè)務和產品需求隨著開發(fā)的進展常常發(fā)生變更，因而難以一步到位地完成最終的軟件產品，但是，緊迫的市場期限又不允許軟件工程師過多地延長開發(fā)周期。為了應對市場競爭或商業(yè)目標的壓力，構造了“演化軟件模型”。它的基本思想是“分期完成、分步提交”?？梢韵忍峤灰粋€有限功能的版本，再逐步地使其完善。2.7演化軟件過程模型軟件就象其他復雜系統一樣，需83演化模型的主要特點是利用“迭代”方法，使工程師們漸進地開發(fā)，生產出逐步完善的軟件版本。在商業(yè)軟件開發(fā)實踐中，演化模型日益得到廣泛的應用。用戶的支持、理解和全程參與是成功采用演化模型的重要前提。演化模型兼有線性順序模型和原型模型的一些特點。但線性順序模型本質上是假設當線性開發(fā)序列完成之后就能夠交付一個完整的系統；原型模型的目的是引導用戶明確需求、幫助工程師驗證算法，總體上講它并不交付一個最終的產品系統。它們都沒有考慮到軟件的“演化”過程。根據開發(fā)策略的不同，演化模型又可以細分為“增量”模型和“螺旋”模型兩種。演化模型的主要特點是利用“迭代”方法，使工程師們漸進842.7.1增量模型增量模型融合了線性順序模型的基本成分(重復的應用這些成分)和原型模型的迭代特征，如圖2.8所示。增量模型實際上是一個隨著日程/時間的進展而交錯的線性序列集合。每一個線性序列產生一個軟件的可發(fā)布的“增量”，所有的增量都能夠結合到原型模型中去。2.7.1增量模型85圖2.8增量模型圖2.8增量模型86當使用增量模型時，第一個增量模型往往是核心部分的產品，它實現了軟件的基本需求，但很多已經明晰或者尚不明晰的補充特性還沒有發(fā)布。核心產品交由用戶使用或進行詳細復審。使用或復審評估的結果是制定下一個增量開發(fā)計劃。該計劃包括對核心產品的修改及增加一些新的功能與特性。這個過程在每一個增量發(fā)布后迭代地進行，直到產生最終的完善產品。和原型模型不一樣的是，增量模型雖然也具有“迭代”特征，但是每一個增量都發(fā)布一個可操作的產品，不妨稱之為“產品擴充迭代”。它的早期產品是最終產品的可拆卸版本，每一個版本都能夠提供給用戶實際使用。當使用增量模型時，第一個增量模型往往是核心部分的產品87在實際開發(fā)過程中，增量模型是十分有用的一種模型。對于防范技術風險、縮短產品提交時間都能夠起到良好的作用。應當再次強調的是，用戶在開發(fā)軟件的過程中，往往有“一步到位”的思想，因而增量式的工程開發(fā)必須取得用戶的全面理解與支持，否則是難以成功的。在實際開發(fā)過程中，增量模型是十分有用的一種模型。對于882.7.2螺旋模型螺旋模型也是屬于演化軟件過程模型。它將原型的迭代特征與線性順序模型中控制的和系統化的方面結合起來，使得能夠快速開發(fā)軟件的增量版本。在螺旋模型中，軟件開發(fā)是一系列的增量發(fā)布。和增量模型不同，它并不要求每一個增量都是可以運行的程序。在早期的迭代中，發(fā)布的增量可以是一個紙上的模型或原型；在以后的迭代中產生更加完善的版本。螺旋模型被劃分為若干個框架活動，如圖2.9所示?；顒右卜Q為任務區(qū)域，一般包括：2.7.2螺旋模型89(1)用戶通信：建立開發(fā)者和用戶之間有效通信所需要的任務。(2)計劃：定義資源、進度和其他項目相關信息所需要的任務。(3)風險分析：評估技術的及管理的風險所需要的任務。(4)工程：建立應用的一個或多個表示所需要的任務。(5)建造及發(fā)布：建造、測試、安裝和提供用戶支持所需要的任務。(6)用戶評估：基于在工程階段產生的或在安裝階段實現的軟件表示的評估，是獲得用戶反饋所必需的任務。(1)用戶通信：建立開發(fā)者和用戶之間有效通信所需要90圖2.9一個典型的螺旋模型圖2.9一個典型的螺旋模型91每一個框架活動(任務區(qū)域)均含有一系列的適應待開發(fā)項目特點的工作任務(活動)。在所有的情況下，都需要應用諸如軟件配置管理、軟件品質保證等保護性活動。隨著演化過程的開始，軟件工程項目組按照順時針方向沿螺旋移動。從核心開始，第一圈可能產生軟件規(guī)格說明書，第二圈可能開發(fā)出一個原型，隨后可能是軟件更完善的版本。經過計劃區(qū)域的每一圈都會對計劃進行調整，基于從用戶處得到的反饋，調整進度和費用以及版本的內容。項目管理者可以根據項目的具體情況調整所需要的迭代次數。

每一個框架活動(任務區(qū)域)均含有一系列的適應待開發(fā)項92和傳統的過程模型不同，螺旋模型能夠適應于計算機軟件產品的整個生命周期，而不是當軟件交付后就結束過程。對于大型系統及軟件的開發(fā)工作來說，螺旋模型是一種很好的模型方法。采用這種模型，隨著過程的發(fā)展演化，開發(fā)者和用戶能夠更好地理解和對待每一個演化級別上的風險。它使開發(fā)者在產品演化的任何階段上都能夠使用原型方法，保持了傳統生命周期模型中的階段化的工作方式，但同時又引入了迭代的框架，更加真實地反映了現實世界。同時也有利于防范技術風險。螺旋模型的應用同樣有賴于用戶的充分理解和積極參與。同時，它需要使用專門的風險評估技術以便識別風險、防范風險。和傳統的過程模型不同，螺旋模型能夠適應于計算機軟件產932.8軟件過程技術前面討論的過程模型必須適合于軟件項目組的使用。為滿足這一要求，先后開發(fā)出了許多過程管理工具以幫助軟件組織分析他們當前的過程，協調組織工作任務，控制和監(jiān)管進度以及管理技術質量。例如，利用配置管理工具來進行配置管理和缺陷管理；利用自動測試工具進行測試；利用統一建模語言UML來進行對象建模、分析與設計；利用Project制訂和監(jiān)測項目計劃及其進展；利用第四代技術，通過開發(fā)者在較高的層次上說明軟件的某些特征，之后工具就能夠自動的根據說明生成源代碼等等。計算機輔助軟件工程已經在軟件領域中發(fā)揮著重要的作用。2.8軟件過程技術前面討論的過程模型必須適合于軟件94采用合適的過程技術工具，使得軟件開發(fā)組織能夠建造一個自動模型，該模型包括通用的過程框架、任務集合及保護性活動。該模型一般表示成一個網絡，對其加以分析，就能夠確定典型的工作流程，考察可能導致降低開發(fā)時間和成本的可供選擇的過程結構。一旦創(chuàng)建了一個可接受的過程，就可以使用其他過程工具來分配、監(jiān)管，甚至控制過程模型中所定義的所有軟件工程任務。軟件項目組的每一個成員均能夠使用這些工具產生一個清單，包括：要完成的任務、要開發(fā)的工作產品以及要實現的質量控制活動等等。采用合適的過程技術工具，使得軟件開發(fā)組織能夠建造一個952.9軟件重用技術“重用”是提升軟件財富價值的有效途徑。一般來說，這里所指的重用可以包括知識重用、方法重用、軟件成分重用三個層次。例如，軟件工程知識的重用使我們能夠高效率的開發(fā)、維護一個又一個的軟件項目；行之有效的軟件工程方法的重用幫助我們有章可循的解決各類工程問題；軟件成分的重用則使我們在需求分析