《軟件工程基礎》第10章 軟件生存期模型

1、10.1 軟件過程框架軟件過程框架的內(nèi)容 軟件過程框架定義了若干框架活動，為完整的軟件開發(fā)過程建立了基礎。過程框架還全面包括了可用于整個軟件過程的活動，稱為“普適性活動（Umbrella Activities）”。 10.1 軟件過程框架軟件過程框架的內(nèi)容 10.1 軟件過程框架軟件過程框架的內(nèi)容 過程框架：定義了若干框架活動，這些活動適用于所有軟件項目。普適性活動：如軟件質(zhì)量保證，軟件配置管理和測量，它們貫穿于整個過程模型之中?？蚣芑顒樱嚎蚣苤忻恳粋€活動都由一組軟件工程動作組成，每一個動作又包含一個任務集合。任務集合：每一個集合都由軟件工程工作任務、項目里程碑、軟件工程產(chǎn)品以及質(zhì)量保證點組成

2、，使得框架活動適應于不同軟件項目的特征和項目組的需求。10.1 軟件過程框架通用過程框架通用過程框架可適用于絕大多數(shù)的軟件項目，該框架由溝通、策劃、建模、構(gòu)造和部署5個通用框架活動組成。(1) 溝通。這項框架活動包含系統(tǒng)分析員與客戶之間大量的交流和協(xié)作，還包括需求獲取以及其他相關活動。 (2) 策劃。策劃活動協(xié)助軟件開發(fā)團隊定義全局目標，并為后續(xù)的軟件工程工作制定計劃。策劃活動包括一系列管理和技術實踐，如描述需要執(zhí)行的技術任務、可能的風險、資源需求、工作產(chǎn)品和工作進度計劃。10.1 軟件過程框架通用過程框架(3) 建模。建模的目的是為了更好地理解需要構(gòu)建的實體。 在軟件工程中，要創(chuàng)建兩類模型：

3、分析模型和設計模型。分析模型通過描述軟件的信息域、功能域及行為域來表達客戶的需求；設計模型描述軟件架構(gòu)、用戶界面及構(gòu)件細節(jié)，從而幫助開發(fā)者高效地開發(fā)軟件。10.1 軟件過程框架通用過程框架(4) 構(gòu)造。構(gòu)造活動包括一系列編碼和測試任務，從而為向客戶和最終用戶交付可運行軟件做好準備。(5) 部署。部署活動是將軟件（全部或者完成的部分）交付給用戶，用戶對其進行評測并給出反饋意見。 部署活動包括三個動作：交付、支持和反饋。10.1 軟件過程框架典型的普適性活動 (1) 軟件項目跟蹤和控制：由項目組根據(jù)計劃來評估項目進度，并且采取必要的措施保證項目按進度計劃進行。(2) 風險管理：評估可能對項目成果或

4、者產(chǎn)品質(zhì)量產(chǎn)生影響的風險。(3) 軟件質(zhì)量保證：確定和執(zhí)行用以保證軟件質(zhì)量的活動。(4) 正式技術評審：評估軟件工程產(chǎn)品，盡量在錯誤傳播到下一個動作或活動之前，發(fā)現(xiàn)并清除錯誤。10.1 軟件過程框架典型的普適性活動 (5)測量：定義和收集過程、項目和產(chǎn)品的度量，以幫助團隊在發(fā)布軟件的時候滿足客戶要求。同時，測量還可與其他框架協(xié)同使用。(6)軟件配置管理：管理整個軟件過程中變更所帶來的影響。(7)可復用管理：定義產(chǎn)品復用的標準（包括軟件構(gòu)件），并且建立構(gòu)件復用機制。(8)工作產(chǎn)品的準備和生產(chǎn)：包括創(chuàng)建產(chǎn)品所必須的活動，如建模、文檔、日志、表格和列表等。10.2 傳統(tǒng)軟件過程模型瀑布模型在20世紀

5、80年代之前，瀑布模型一直是唯一被廣泛采用的生命周期模型。傳統(tǒng)的瀑布模型如圖所示。 10.2 傳統(tǒng)軟件過程模型瀑布模型的特點階段間具有順序性和依賴性。其中包含兩重含義： 必須等前一階段的工作完成之后，才能開始后一階段的工作； 前一階段的輸出文檔就是后一階段的輸入文檔。10.2 傳統(tǒng)軟件過程模型瀑布模型的特點推遲實現(xiàn)的觀點 瀑布模型在編碼之前設置了系統(tǒng)分析和系統(tǒng)設計的各個階段，分析與設計階段的基本任務規(guī)定，在這兩個階段主要考慮目標系統(tǒng)的邏輯模型，不涉及軟件的物理實現(xiàn)。 清楚地區(qū)分邏輯設計與物理設計，盡可能推遲程序的物理實現(xiàn)，是按照瀑布模型開發(fā)軟件的一條重要的指導思想。10.2 傳統(tǒng)軟件過程模型瀑

6、布模型的特點質(zhì)量保證的觀點 每個階段都必須完成規(guī)定的文檔，沒有交出合格的文檔就是沒有完成該階段的任務。 每個階段結(jié)束前都要對所完成的文檔進行評審，以便盡早發(fā)現(xiàn)問題，改正錯誤。10.2 傳統(tǒng)軟件過程模型實際的瀑布模型實際的瀑布模型是帶“反饋環(huán)”的，如圖所示。 10.2 傳統(tǒng)軟件過程模型瀑布模型的優(yōu)點可強迫開發(fā)人員采用規(guī)范化的方法。嚴格地規(guī)定了每個階段必須提交的文檔。要求每個階段交出的所有產(chǎn)品都必須是經(jīng)過驗證的。10.2 傳統(tǒng)軟件過程模型瀑布模型的缺點由于瀑布模型幾乎完全依賴于書面的規(guī)格說明，很可能導致最終開發(fā)出的軟件產(chǎn)品不能真正滿足用戶的需要。如果需求規(guī)格說明與用戶需求之間有差異，就會發(fā)生這種情

7、況。瀑布模型只適用于項目開始時需求已確定的情況。10.2 傳統(tǒng)軟件過程模型快速原型模型快速原型是快速建立起來的可以在計算機上運行的程序，它所能完成的功能往往是最終產(chǎn)品能完成的功能的一個子集?？焖僭湍Ｐ腿鐖D所示，圖中實線箭頭表示開發(fā)過程，虛線箭頭表示維護過程。 10.2 傳統(tǒng)軟件過程模型快速原型模型的優(yōu)點(1)有助于滿足用戶的真實需求。(2)原型系統(tǒng)已經(jīng)通過與用戶的交互而得到驗證，據(jù)此產(chǎn)生的規(guī)格說明文檔能夠正確地描述用戶需求。(3)軟件產(chǎn)品的開發(fā)基本上是按線性順序進行。(4)因為規(guī)格說明文檔正確地描述了用戶需求，因此，在開發(fā)過程的后續(xù)階段不會因為發(fā)現(xiàn)規(guī)格說明文檔的錯誤而進行較大的返工。 10.

8、2 傳統(tǒng)軟件過程模型快速原型模型的優(yōu)點(5)開發(fā)人員通過建立原型系統(tǒng)已經(jīng)學到了許多東西，因此，在設計和編碼階段發(fā)生錯誤的可能性也比較小，這自然減少了在后續(xù)階段需要改正前面階段所犯錯誤的可能性。(6) 快速原型的突出特點是“快速”。開發(fā)人員應該盡可能快地建造出原型系統(tǒng)，以加速軟件開發(fā)過程，節(jié)約軟件開發(fā)成本。 原型的用途是獲知用戶的真正需求，一旦需求確定了，原型可以拋棄，當然也可以在原型的基礎上進行開發(fā)。10.2 傳統(tǒng)軟件過程模型增量模型 增量模型也稱為漸增模型，是Mills等于1980年提出來的。使用增量模型開發(fā)軟件時，把軟件產(chǎn)品作為一系列的增量構(gòu)件來設計、編碼、集成和測試。每個構(gòu)件由多個相互作

9、用的模塊構(gòu)成，并且能夠完成特定的功能。 10.2 傳統(tǒng)軟件過程模型增量模型 增量模型如圖所示。 10.2 傳統(tǒng)軟件過程模型增量模型的優(yōu)點 (1)能在較短時間內(nèi)向用戶提交可完成一些有用的工作產(chǎn)品，即從第1個構(gòu)件交付之日起，用戶就能做一些有用的工作。(2)逐步增加產(chǎn)品的功能可以使用戶有較充裕的時間學習和適應新產(chǎn)品，從而減少一個全新的軟件可能給用戶組織帶來的沖擊。(3)項目失敗的風險較低，雖然在某些增量構(gòu)件中可能遇到一些問題，但其他增量構(gòu)件將能夠成功地交付給客戶。(4)優(yōu)先級最高的服務首先交付，然后再將其他增量構(gòu)件逐次集成進來。因此，最重要的系統(tǒng)服務將接受最多的測試。 10.2 傳統(tǒng)軟件過程模型增量

10、構(gòu)件開發(fā) 每個增量構(gòu)件應當實現(xiàn)某種系統(tǒng)功能，因此增量構(gòu)件的開發(fā)可以采用瀑布模型的方式，如圖所示。 10.2 傳統(tǒng)軟件過程模型采用增量模型需注意的問題 (1)在把每個新的增量構(gòu)件集成到現(xiàn)有軟件體系結(jié)構(gòu)中時，必須不破壞原來已經(jīng)開發(fā)出的產(chǎn)品。(2)軟件體系結(jié)構(gòu)必須是開放的，即向現(xiàn)有產(chǎn)品中加入新構(gòu)件的過程必須簡單、方便。 因此，采用增量模型比采用瀑布模型和快速原型模型更需要精心的設計。10.2 傳統(tǒng)軟件過程模型螺旋模型 螺旋模型最初是Boehm于1988年提出來的。該模型將瀑布模型與快速原型模型結(jié)合起來，并且加入兩種模型均忽略了的風險分析。螺旋模型的基本思想是，使用原型及其他方法來盡量降低風險。 10

11、.2 傳統(tǒng)軟件過程模型螺旋模型 理解這種模型的一個簡便方法，是把它看做在每個階段之前都增加了風險分析過程的快速原型模型。 10.2 傳統(tǒng)軟件過程模型完整的螺旋模型 10.2 傳統(tǒng)軟件過程模型完整的螺旋模型 在螺旋模型中，軟件過程表示成一個螺線，而不是像以往的模型那樣表示為一個具有回溯的活動序列。在螺線上的每一個循環(huán)表示過程的一個階段。每個階段開始時的任務是確定該階段的目標、為完成這些目標選擇方案及設定這些方案的約束條件。接下來的任務是，從風險角度分析上一步的工作結(jié)果，努力排除各種潛在的風險，通常用建造原型的方法來排除風險。如果成功地排除了所有風險，則啟動下一步開發(fā)步驟，在這個步驟的工作過程相當

12、于純粹的瀑布模型。最后是評價該階段的工作成果并計劃下一個階段的工作。10.2 傳統(tǒng)軟件過程模型螺旋模型的4項活動 螺線上的每一個循環(huán)可劃分為4個象限，分別表達了4個方面的活動。(1)目標設定定義在該階段的目標，弄清對過程和產(chǎn)品的限制條件，制訂詳細的管理計劃，識別項目風險，可能還要計劃與這些風險有關的對策。(2)風險估計與弱化針對每一個風險進行詳細分析，設想弱化風險的步驟。(3)開發(fā)與驗證評價風險之后選擇系統(tǒng)開發(fā)模型。 (4)計劃評價開發(fā)工作，確定是否繼續(xù)進行螺線的下一個循環(huán)。如果確定要繼續(xù)，則計劃項目的下一個階段的工作。10.2 傳統(tǒng)軟件過程模型螺旋模型的優(yōu)點 對可選方案和約束條件的強調(diào)有利于

13、已有軟件的重用，也有助于把軟件質(zhì)量作為軟件開發(fā)的一個重要目標。減少了過多測試或測試不足所帶來的風險。在螺旋模型中維護只是模型的另一個周期，因而在維護和開發(fā)之間并沒有本質(zhì)區(qū)別。10.2 傳統(tǒng)軟件過程模型螺旋模型的缺點 螺旋模型是風險驅(qū)動的，因此要求軟件開發(fā)人員必須具有豐富的風險評估經(jīng)驗和這方面的專門知識，否則將出現(xiàn)真正的風險：當項目實際上正在走向災難時，開發(fā)人員可能還以為一切正常。10.2 傳統(tǒng)軟件過程模型噴泉模型 噴泉模型是典型的面向?qū)ο笊芷谀Ｐ汀?“噴泉”一詞體現(xiàn)了迭代和無間隙特性。圖中代表不同階段的圓圈相互重疊，這明確表示兩個活動之間存在重疊。 10.3 現(xiàn)代軟件過程模型基于構(gòu)件的開發(fā)

14、模型 基于構(gòu)件的軟件工程（component-based software engineering，CBSE）是強調(diào)使用可復用的軟件“構(gòu)件”來設計和構(gòu)造基于計算機的系統(tǒng)的過程。Clements對CBSE給出了如下描述。10.3 現(xiàn)代軟件過程模型基于構(gòu)件的開發(fā)模型 Clements對CBSE給出了如下描述。 CBSE正在改變大型軟件系統(tǒng)的開發(fā)方式。CBSE體現(xiàn)了Frod Brooks和其他人支持的“購買，而非構(gòu)造”的思想。就如同早期的子程序?qū)⒊绦騿T從考慮編程細節(jié)中解脫出來一樣，CBSE將考慮的重點從編碼轉(zhuǎn)移到組裝軟件系統(tǒng)?？紤]的焦點是“集成”，而不再是“實現(xiàn)”。這樣做的基礎是假定在很多大型軟件系

15、統(tǒng)中存在足夠多的共性，使得開發(fā)可復用的構(gòu)件來滿足這些共性是可行的。10.3 現(xiàn)代軟件過程模型基于構(gòu)件的開發(fā)模型 當軟件團隊使用傳統(tǒng)的需求獲取技術確定了待開發(fā)軟件的系統(tǒng)需求時，該過程開始。體系結(jié)構(gòu)設計完成后，并不立即進行詳細設計任務，而是針對每一系統(tǒng)需求考慮以下問題:(1)現(xiàn)有的商品化構(gòu)件（commercial off-the-shelf，COTS）是否能夠?qū)崿F(xiàn)該需求？(2)內(nèi)部開發(fā)的可復用構(gòu)件是否能夠?qū)崿F(xiàn)該需求？(3)可用構(gòu)件的接口與待構(gòu)造系統(tǒng)的體系結(jié)構(gòu)是否相容？ 10.3 現(xiàn)代軟件過程模型基于構(gòu)件的開發(fā)模型 10.3 現(xiàn)代軟件過程模型開發(fā)步驟 不考慮構(gòu)件的開發(fā)技術，基于構(gòu)件的開發(fā)模型由以下步

16、驟組成： (1)對于該問題領域的基于構(gòu)件的可用產(chǎn)品進行研究和評估。(2)考慮構(gòu)件集成的問題。(3)設計軟件架構(gòu)以容納這些構(gòu)件。(4)將構(gòu)件集成到架構(gòu)中。(5)進行充分的測試以保證功能正常。10.3 現(xiàn)代軟件過程模型典型的構(gòu)件模型 (1)OMG/CORBA。對象管理組織發(fā)布了公共對象請求代理體系結(jié)構(gòu)（OMG/CORBA），一個對象請求代理提供了多種服務使得可復用構(gòu)件（對象）可以與其他構(gòu)件通信。(2)Microsoft COM。微軟公司開發(fā)了構(gòu)件對象模型（COM），此模型提供了運行于Windows操作系統(tǒng)下的單個應用中使用不同廠商生產(chǎn)的構(gòu)件的規(guī)格說明。(3)Sun JavaBean構(gòu)件。JavaB

17、ean構(gòu)件系統(tǒng)是一個可移植的、平臺獨立的、使用Java程序設計語言開發(fā)的CBSE基礎設施。 10.3 現(xiàn)代軟件過程模型形式化方法模型 形式化系統(tǒng)開發(fā)模型是一種基于形式化數(shù)學變換的軟件開發(fā)方法，它可將系統(tǒng)規(guī)格說明轉(zhuǎn)換為可執(zhí)行的程序。 10.3 現(xiàn)代軟件過程模型與瀑布模型的區(qū)別 軟件需求規(guī)格說明被細化為用數(shù)學記號表達的詳細的形式化規(guī)格說明。設計、實現(xiàn)和單元測試等開發(fā)過程由變換開發(fā)過程代替。通過一系列變換將形式化規(guī)格說明細化成為程序。這種細化的過程如圖所示。10.3 現(xiàn)代軟件過程模型面向方面的軟件開發(fā) 面向方面的軟件開發(fā)（aspect-oriented software development，AO

18、SD）通常稱為面向方面編程（aspect-oriented progamming，AOP），是相對較新的一種軟件工程模型，為定義、說明、設計和構(gòu)建方面（aspect）提供過程和方法。 10.3 現(xiàn)代軟件過程模型統(tǒng)一過程 由Booch、Jacobson及Rumbaugh提出，統(tǒng)一過程模型如圖所示。 10.3 現(xiàn)代軟件過程模型統(tǒng)一過程的工作流 在統(tǒng)一過程中，有5個核心工作流。 需求工作流。需求工作流的目標是確保開發(fā)人員構(gòu)建正確的系統(tǒng)。 分析工作流。分析工作流的目標是分析和細化需求。 設計工作流。設計工作流是對分析工作流的細化，直到設計模型可以被程序員實現(xiàn)為止。 實現(xiàn)工作流。實現(xiàn)工作流的目標是：用選

19、擇的實現(xiàn)語言實現(xiàn)目標信息系統(tǒng)。 測試工作流。測試工作流是質(zhì)量保證組的職責。10.3 現(xiàn)代軟件過程模型統(tǒng)一過程的階段 統(tǒng)一過程有4個階段，分別是初始階段、細化階段、構(gòu)造階段和移交階段。 初始階段。初始階段主要關注項目計劃和風險評估，其目的是確定是否值得開發(fā)目標信息系統(tǒng)。 細化階段。細化階段關心定義系統(tǒng)的總體框架，其目標是：細化初始需求（用況）、細化體系結(jié)構(gòu)、監(jiān)控風險并細化它們的優(yōu)先級、細化業(yè)務案例以及制訂項目管理計劃。 構(gòu)造階段。構(gòu)造階段是建立系統(tǒng)，構(gòu)造信息系統(tǒng)的第1個具有操作質(zhì)量的版本，以能夠交付給客戶進行測試的版本結(jié)束，有時稱為測試版本。 移交階段。移交階段包含測試時期，以發(fā)布完整的系統(tǒng)而終

20、止，其目標是確保信息系統(tǒng)真正滿足客戶的需求。 10.3 現(xiàn)代軟件過程模型敏捷過程模型 2001年，Kent Beck等17名編程大師發(fā)表“敏捷軟件開發(fā)”宣言： 我們正在通過親身實踐以及幫助他人實踐的方式來揭示更好的軟件開發(fā)之路，通過這項工作，我們認為： 個體和交互勝過過程和工具； 可工作軟件勝過寬泛的文檔； 客戶合作勝過合同談判； 響應變化勝過遵循計劃。 10.3 現(xiàn)代軟件過程模型敏捷過程模型 對于敏捷開發(fā)，Ivar Jacobson給出了下面非常有用的論述。 “敏捷（Agility）已經(jīng)成為當今現(xiàn)代軟件過程的一個時髦用詞。每個人都是敏捷的，敏捷團隊是能夠適當響應變化的靈活團隊。變化就是軟件開

21、發(fā)本身，軟件構(gòu)建有變化、團隊成員在變化、使用新技術會帶來變化，各種變化都會對開發(fā)的軟件產(chǎn)品以及項目本身造成影響。我們必須接受的是支持變化的意識，它應當根植于軟件開發(fā)中的每一件事中，因為這是軟件的心臟與靈魂。敏捷團隊意識到軟件是團隊中所有人共同開發(fā)完成的，這些人的個人技能和合作能力是項目成功的關鍵所在?！?0.3 現(xiàn)代軟件過程模型敏捷過程模型 任何一個敏捷過程都可以由所強調(diào)的3個關鍵假設識別出來，這3個假設可適用于大多數(shù)軟件項目。(1) 提前預測哪些需求是穩(wěn)定的、哪些需求會變化非常困難。同樣的，預測項目進行中客戶優(yōu)先級的變化也很困難。(2) 對很多軟件，設計和構(gòu)建是交錯進行的。事實上，兩種活動應

22、當順序開展以保證通過構(gòu)建實施來驗證設計模型，而在通過構(gòu)建驗證之前很難估計應該設計到什么程度。(3) 從制訂計劃的角度來看，分析、設計、構(gòu)建和測試并不像我們所設想的那么容易預測。10.3 現(xiàn)代軟件過程模型極限編程 極限編程（eXtreme Programming，XP）使用面向?qū)ο蠓椒ㄗ鳛橥扑]的開發(fā)范型。XP包含了策劃、設計、編碼和測試4個框架活動的規(guī)則和實踐。 10.3 現(xiàn)代軟件過程模型極限編程的框架活動 策劃。策劃活動開始于建立健全描述待開發(fā)軟件特征與功能需求的“故事”（也稱為用戶故事）。 設計。XP設計嚴格遵循KIS（keep it simple， 保持簡潔）原則，通常更愿意使用簡單設計而不是更為復雜的表述。 編碼。XP推薦在故事開發(fā)和基本設計完成之后，團隊不應直接開始編碼，而是開發(fā)一系列用于檢測本次（軟件增量）發(fā)行包括所有故事的單元測試，一旦建立起單元測試，開發(fā)者就可以更集中精力于必須實現(xiàn)的內(nèi)容以通過單元測試。 測試。 10.3 現(xiàn)代軟件過程模型自適應軟件開發(fā) 自適應軟件開發(fā)（adapt