軟件工程-過程模型

軟件過程的概念

軟件過程是一個爲建立高質量軟件所須要完成的活動，動做和任務的框架。

1.慣用過程模型

慣用過程模型力求達到軟件開發的結構和只需，其活動和任務都是按照過程的特定指引順序進行的。

1.1 瀑布模型

瀑布模型又稱爲經典生命週期，它提出了一個系統的，順序的軟件開發方法，從用戶需求規格說明開始，經過策劃，建模，構建和部署的過程，最終提供完整的軟件支持。

瀑布模型的一個變體稱爲V模型。V模型描述的質量保證動做同溝通，建模相關動做以及早期構建相關動做之間的關係。隨着軟件團隊工做沿着V模型左側步驟向下推動，基本問題需求逐步細化，造成了對問題及解決方案的詳盡且技術性的描述。一旦編碼結束，團隊沿着V模型右側的步驟向上推動工做，其本質上是執行了一些列測試(質量保證動做)，這些測試驗證了團隊沿着V模型左側步驟向下推動過程當中所生成的每一個模型。 實際上，經典生命週期模型和V模型沒有本質區別，V模型提供了一種將驗證和確認動做應用於早期軟件工程工做中的直觀方法。

爲何瀑布模型有時候會失效？ 1.實際的項目不多遵照瀑布模型提出的順序。雖然線性模型能夠加入迭代，可是它是用間接的方式實現的，結果是，隨着項目組工做的推動，變動可能形成混亂。 2.客戶一般難以清楚的描述全部的需求。而瀑布模型卻要求客戶明確需求，這就很難適應在許多項目開始階段必然存在的不肯定性。 3.客戶必需要有耐心，由於只有在項目接近尾聲的時候，他們才能獲得可執行的程序。對於系統中存在的重大缺陷，若是在可執行程序評審以前沒有發現，將可能形成慘重的損失。

他的優勢就是適合那種需求已經肯定的狀況，且工做採用線性的方式完成的時候，瀑布模型是一個頗有用的過程模型。

1.2 增量過程模型

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

隨着時間的推移，增量模型在每一個階段都運用線性序列。每一個線性序列生產出軟件的可交付增量。

運用增量模型的時候，第一個增量每每是核心產品。 也就是知足了基本的需求，可是許多附加的屬性沒有提供，客戶使用該核心產品並進行仔細的評估，而後根據評估結果制定下一個增量計劃。這份計劃應說明須要對核心產品進行的修改，一遍更好的知足和客戶的需求，，夜鶯說明須要增長的特性和功能。每個增量的交付都會重複這一課程，知道最紅產品的產生。

1.3 演化過程模型

軟件開發人員須要一種專門應對不斷演變的軟件產品的過程模型。 演化模型是迭代的過程模型，這種模型使得軟件開發人員可以逐步開發出更完整的軟件版本。 演化過程模型有兩種：

原型開發 已經定義了軟件的一些基本任務，可是沒有詳細定義功能和特性需求。能夠幫助軟件開發人員和利益相關者更好的理解究竟須要作什麼。 就是先設計一個原形，而後在原形系統不斷調整以知足各類利益相關者需求的過程當中，採用迭代技術，同時也使開發者逐步清楚用戶的需求。

理想狀態下，原型系統提供了定義軟件需求的一種機制。當須要構建可執行的原型系統時，軟件開發人員能夠利用已有的程序片斷或應用工具快速產生可執行的程序。

原型系統缺點： 1.利益相關者看到了軟件的工做版本，卻未察覺到整個軟件是隨意搭成的，也未察覺到爲了儘快完成軟件，開發者沒有考慮總體軟件質量和長期的可維護性。當開發者告訴客戶整個系統須要重建以提升軟件質量的時候，利益相關者會不肯意，而且要求對軟件稍加修改使其變爲一個可運行的產品。在絕大多數的狀況下，軟件開發管理層會作出妥協。 2.做爲一名軟件工程師，爲了使一個原型快速運行起來，每每在實現過程當中採用折衷的手段。他們常常會使用不合適的操做系統或程序設計語言，僅僅由於當時可用或他們對此較爲熟悉。他們也常常會採用一種低效的算法，僅爲了證實系統的能力。時間長了，軟件開發人員可能會適應這些選擇，而忽略了這些選擇其實並不適合的理由，結果使並不完美的選擇成了系統的組成部分。

儘管問題會發生，但原型開發對於軟件工程來講還是一個有效的範型。關鍵是要在遊戲開始的時候指定規則，也就是說，全部利益相關者必須認可原型是爲定義需求服務器的。而後丟棄原型，實際的軟件系統時以質量第一爲目標而開發的。

螺旋模型

螺旋模型將軟件開發爲一系列演進版本。在早期迭代中，軟件多是一個理論模型或是原型。在後來的迭代中，會產生一系列逐漸完整的系統版本。 螺旋模型被分割成一系列由軟件工程團隊定義的框架活動。

每一個框架活動表明螺旋上的一個片斷。隨着演進過程開始，從圓心開始順時針方向，軟件團隊執行螺旋上的一圈所表示的活動。在每次演進的時候，都要考慮風險。每一個演進過程還要標記里程碑-沿着螺旋路徑達到的工做產品和條件的結合體。 螺旋的第一圈通常開發出產品的規格說明，接下來開發產品的原型系統，並在每次迭代中逐步完善，開發不一樣的軟件版本。

其餘過程模型在軟件交付後就結束了。螺旋模型則不一樣，它應用在計算機軟件的整個生命週期。所以，螺旋上的第一圈可能表示「概念開發項目」，它起始於螺旋的中心，通過屢次迭代，直到概念開發的結束。若是這個概念將被開發成爲實際的產品，那麼該過程將繼續沿着螺旋向外伸展，成爲「新產品開發項目」。新產品將沿着螺旋經過一系列的迭代不斷的演進。最後，能夠用一圈螺旋表示「產品提升項目」。本質上，當螺旋模型以這種方式進行下去的時候，它將永遠保持可操做性，知道軟件產品的生命週期結束。過程常常會處於休止狀態，但當有變動時，過程總可以在合適的入口點啓動。

螺旋模型是開發大型系統和軟件的很實際的方法。因爲軟件隨着過程的推動而變化，所以在每個演進層次上，開發者和客戶均可以更好的理解和應對風險。螺旋模型把原型做爲下降風險的機制，更重要的是，開發人員能夠產品眼睛的任何階段使用原型方法。它保留了經典生命週期模型中系統逐步細化的方法，可是把它歸入一種迭代框架之中，這種迭代方式與真實世界更加吻合。螺旋模型要求在項目的全部階段適中考慮技術風險，若是適當的應用該方法，就可以在風險變爲難題以前將其化解。

1.4 併發模型

併發開發模型有時也叫作併發工程，它容許軟件團隊表述本章所描述的任何過程模型中的迭代元素和併發元素。 在某一特定時間，建模活動可能處於任何一種狀態中.其餘活動，動做或任務（如溝通或構建）能夠用相似的方式表示。全部的軟件工程活動同時存在並處於不一樣的狀態。

併發建模可用於全部類型的軟件開發，它可以提供精確的項目當前狀態圖。

併發建模可用於全部類型的軟件開發，它可以提供精確的項目當前狀態圖。他不是軟件工程活動，動做和任務侷限在一個事件的序列，而是定義了一個過程網絡。網絡上每一個活動，動做和任務與其餘活動，動做和任務同時存在。過程網絡中某一點產生的事件能夠觸發與每個活動相關的狀態的轉換。

缺點：演化模型的初衷是採用迭代或者增量的方式開發高質量軟件。但是，用演化模型也能夠作到強調靈活性，可延展性和開發速度。軟件團隊及其經理所面臨的挑戰就是在這些嚴格的項目，產品參數與客戶滿意度之間找到一個合理的平衡點。

統一過程模型

UP(統一過程)起始階段包括客戶溝通和策劃活動。經過與利益相關者協做定義軟件的業務需求，提出系統的大體架構，並制定開發計劃以保證項目開發具備地帶和增量的特性。該階段識別基本的業務需求，並初步用用例描述每一類用戶所須要的主要特性和功能。此時的體系結構僅是主要子系統及其功能，特性的試探性歸納。隨後，體系結構將被細化和擴充成爲一組模型，以描述系統的不一樣視圖。擦花階段將識別各類資源，評估主要風險，指定進度計劃，併爲其在軟件增量開發的各個階段中的應用創建基礎。

細化階段

包括溝通和通用過程模型的建模活動。細化階段擴展了初始階段定義的用例，並擴展了體系以包括軟件的五種視圖-用例模型，需求模型，設計模型，實現模型和部署模型。可是這個時候沒有提供系統使用時所需的全部功能和特性。在細化的最終階段將評審項目計劃以確保項目的範圍，風險和交付日期的合理性。該階段一般要對項目計劃進行修訂。

構建階段 構建階段採用體系結構模型做爲輸入，開發或是獲取軟件構件，使得最終用戶可以操做用例。爲達到上述目的，要對在細化階段開始的需求模型和設計模型加以完善，以反映出軟件的最終版本。對每個構建設計並實施單元測試。

轉換階段 包括通用構建活動的後期階段以及通用部署活動的第一部分。軟件被提交給最終用戶盡心beta測試，用戶反饋報告缺陷及必要的變動。另外，軟件開發圖那件建立系統發佈所必須的支持信息。在轉換階段結束時，軟件增量成爲可用的發佈版本。

生產階段

與通用過程的部署活動一致。在該階段，對持續使用的軟件進行監控，提供運行環境的支持，提交併評估缺陷報告和變動請求。

有可能在構建，轉換和生產階段的同時，下一個軟件增量的工做已經開始。這就意味着五個Up階段並非順序進行，而是階段性的併發進行。

注：本文內容均來自《軟件工程 實踐者的研究方法 第八版》，僅供本身學習