軟件過程模型

它有時也稱為傳統生存週期模型或瀑布模型。它提出了軟件開發的系統化的、順序的方法。其流程從系統開始，隨後是需求分析、設計、編碼、測試、支持。這種模型是最早也是應用最廣泛的軟件過程模型(雖然這種模型會引起“堵塞狀態”)。

缺點：

1、實際的項目大部分情況難以按照該模型給出的順序進行，而且這種模型的迭代是間接的，這很容易由微小的變化而造成大的混亂。

2、 經常情況下客户難以表達真正的需求，而這種模型卻要求如此，這種模型是不歡迎具有二義性問題存在的。

3、 客户要等到開發週期的晚期才能看到程序運行的測試版本，而在這時發現大的錯誤時，可能引起客户的驚慌，而後果也可能是災難性的。

4、採用這種線性模型，會經常在過程的開始和結束時碰到等待其他成員完成其所依賴的任務才能進行下去，有可能花在等待的時間比開發的時間要長。我們稱之為“堵塞狀態”。

優點：

1、它提供了一個模板，這個模板使得分析、設計、編碼、測試和支持的方法可以在該摸板下有一個共同的指導。

2、雖然有不少缺陷但比在軟件開發中隨意的狀態要好得多。

從需求收集開始，開發者和客户在一起定義軟件的總體目標，標識已知的需求並且規劃出需要進一步定義的區域。然後是“快速設計”，它集中於軟件中那些對客户可見的部分的表示，這將導致原型的創建，並由客户評估並進一步精化待開發軟件的需求。逐步調整原型使其滿足客户的需求，這個過程是迭代的。其流程從聽取客户意見開始、隨後是建造/修改原型、客户測試運行原型、然後回頭往復循環直到客户對原型滿意為止。由於這種模型可以讓客户快速的感受到實際的系統（雖然這個系統不帶有任何質量的保證），所以客户和開發者都比較喜歡這種過程模型（對於那些僅僅用來演示軟件功能的公司而言或從來不考慮軟件質量和不害怕長期維護的公司而言）。

缺點：

1、沒有考慮軟件的整體質量和長期的可維護性。

2、大部分情況是不合適的操作算法被採用目的為了演示功能，不合適的開發工具被採用僅僅為了它的方便，還有不合適的操作系統被選擇等等。

3、由於達不到質量要求產品可能被拋棄，而採用新的模型重新設計。

優點：

1、如果客户和開發者達成一致協議：原型被建造僅為了定義需求，之後就被拋棄或者部分拋棄， 那麼這種模型很合適了。

2、迷惑客户搶佔市場，這是一個首選的模型。

這是一個增量型的軟件開發過程模型，強調極短的開發週期，它是線性模型的一個“高速”變種，通過使用構件的建造方法贏得了快速開發。如果需求理解的好而且約束了項目的範圍，利用這種模型可以很快的創建出功能完善的“信息系統”。其流程從業務建模開始，隨後是數據建模、過程建模、應用生成、測試及反覆。RAD過程強調的是複用，複用已有的或開發可複用的構件。實際上RAD採用第四代技術。

缺點：

1、只能用於信息系統。

2、對於較大的項目需要足夠的人力資源去建造足夠的RAD組。

3、開發者和客户必須在很短的時間完成一系列的需求分析， 任何一方配合不當都會導致RAD項目失敗。

4、這種模型對模塊化要求比較高，如果有哪一功能不能被模塊化，那麼建造RAD所需要的構件就會有問題。

5、技術風險很高的情況下不適合這種模型。

優點：

1、開發速度快，質量有保證。

2、對信息系統特別有效。

這種模型融合了線性順序模型的基本成份和原型實現模型的迭代特徵。增量模型採用隨着日程時間的進展而交錯的線性序列。每一個線性序列產生軟件的一個可發佈的“增量”。當使用增量模型時，第一個增量往往是核心的產品，也就是説第一個增量實現了基本的需求，但很多補充的特徵還沒有發佈。客户對每一個增量的使用和評估，都做為下一個增量發佈的新特徵和功能。這個過程在每一個增量發佈後不斷從復，直到產生了最終的完善產品。增量模型強調每一個增量均發佈一個可操作的產品。

缺點：

1、至始至終開發者和客户糾纏在一起，直到完全版本出來。

優點：

1、人員分配靈活，剛開始不用投入大量人力資源，當核心產品很受歡迎時，可增加人力實現下一個增量。

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

3、具有一定的市場。

這是一個演化軟件過程模型，它將原型實現的迭代特徵和線性順序模型中控制的和系統化的方面結合起來。使得軟件的增量版本的快速開發成為可能。在螺旋模型中，軟件開發是一系列的增量發佈。在每一個迭代中，被開發系統的更加完善的版本逐步產生。螺旋模型被劃分為若干框架活動，也稱為任務區域。典型地，有3到6個任務區域：

1、客户交流：建立開發者和客户之間有效通信所需要的任務。

2、計劃：定義資源、進度、及其它相關項目信息所需要的任務。

3、風險分析：評估技術的及管理的風險所需要的任務。

4、工程：建立應用的一個或多個表示説需要的任務。

5、構造及發佈：構造、測試、安裝和提供用户支持所需要的任務。

6、客户評估：基於對在工程階段產生的或在安裝階段實現的軟件表示的評估，獲得客户反饋所需要的任務。

這是一個相對較新的模型，它的功效還需要經歷若干年的使用方能確定下來。

缺點：

1、需要相當的風險分析評估的專門技術，且成功依賴於這種技術。

2、很明顯一個大的沒有被發現的風險問題，將會導致問題的發生，可能導致演化的方法失去控制。

3、這種模型相對比較新，應用不廣泛，其功效需要進一步的驗證。

優點：

1、對於大型系統及軟件的開發，這種模型是一個很好的方法。開發者和客户能夠較好地對待和理解每一個演化級別上的風險。

螺旋模型提出了強調客户交流的一個框架活動。該活動的目標是從客户處誘導項目需求。在理想情況下，開發者簡單地詢問客户需要什麼,而客户提供足夠的細節進行下去。不幸的是這種情形很少發生。在現實中，客户和開發者進入一個談判過程，客户被要求在成本和應市之間的約束下平衡功能、性能、和其它產品或系統特徵。最好的談判追求“雙贏”結果，也就是説通過談判客户獲得大部份系統的功能，而開發者則獲得現實的和可達到的預算和時限。對客户的交流定義了下面的活動：

1、系統或子系統的關鍵“風險承擔者”的標識。

2、風險承擔者的“贏條件”的確定。

3、風險承擔者的贏條件談判，以將它們協調為一組滿足各方考慮的雙贏條件。

缺點：

1、需要額外的談判技巧。

優點：

1、客户和開發者達到一種平衡。

這種模型關注於多個任務的併發執行，表示為一系列的主要技術活動、任務及它們的相關狀態。併發過程模型是由客户要求、管理決策、評審結果驅動的。該模型不是將軟件工程活動限定為一個順序的事件序列，而是定義了一個活動網絡。網絡上的每一個活動均可於其它活動同時發生。這種模型可以提供一個項目的當前狀態的準確視圖。

缺點：暫時無

優點：

1、可用於所有類型的軟件開發，而對於客户/服務器結構更加有效。

2、可以隨時查閲到開發的狀態。

面向對象的技術為軟件工程的基於構件的過程模型提供了技術框架。面向對象模型強調了類的創建、類的封裝了的數據、操縱該數據的算法。一般來講經過合適的設計和實現，面向對象的類可以在不同的應用及基於計算機的系統的體系結構中複用。基於構件的開發模型融合了螺旋模型的許多特徵，它本質上是演化形的，要求軟件創建的迭代方法。然而基於構件的開發模型是利用預先包裝好的軟件構件（有時成為類）來構造應用。

開發活動從候選類的標識開始，這一步是通過檢查將被應用系統操縱的數據及用於實現該操縱的算法來完成的。相關的數據和算法被封裝成一個類。

缺點：

1、過分依賴於構件，構件庫的質量影響着產品質量。

優點：

1、構件可複用。提高了開發效率。

2、採用了面向對象的技術。

形式化方法模型包含了一組活動，他們導致了計算機軟件的數學規約。形式化方法使得軟件工程師們能夠通過應用一個嚴格的數學符號體系來規約、開發、和驗證基於計算機的系統。 這種方法的一個變種，稱為淨室軟件工程，已經被一些組織所採用。在開發中使用形式化方法時，它們提供了一種機制，能夠消除使用其它軟件過程模型難以克服的很多問題。二義性、不完整性、不一致性能被更容易地發現和糾正，而不是通過專門的評審，是通過對應用的數學分析。 形式化方法提供了可以產生無缺陷軟件的承諾。

缺點：

1、開發費用昂貴（對開發人員需要多方面的培訓），而且需要的時間較長。

2、不能將這種模型作為對客户通信的機制，因為客户對這些數學語言一無所知。

3、還不流行。

優點：

1、形式化規約可直接作為程序驗證的基礎，可以儘早的發現和糾正錯誤（包括那些其它情況下不能發現的錯誤）。

2、開發出來的軟件具有很高的安全性和健壯性，特別適合安全部門或者軟件錯誤會造成經濟損失的開發者。

3、具有開發無缺陷軟件的承諾。

一系列的軟件工具的使用，是第四代技術的特點。這些工具有一個共同的特點：能夠使軟件工程師們在較高級別上規約軟件的某些特徵，然後根據開發者的規約自動生成源代碼。我們知道，軟件在越高的級別上被規約，就越能被快速的建造出程序。軟件工程的

4GT模型集中於規約軟件的能力：使用特殊的語言形式或一種採用客户可以理解的術語描述待解決問題的圖形符號體系。和其它模型一樣，4GT也是從需求收集這一步開始的，要將一個4GT實現變成最終產品，開發者還必須進行徹底的測試、開發有意義的文檔，並且同樣要完成其它模型中同樣要求的所有集成活動。總而言之，4GT已經成為軟件工程的一個重要方法。特別是和基於構件的開發模型結合起來時，4GT模型可能成為當前軟件開發的主流模型。

缺點：

1、用工具生成的源代碼可能是“低效”的。

2、生成的大型軟件的可維護性還令人懷疑。

3、在某些情況下可能需要更多的時間。

優點：

1、縮短了軟件開發時間，提高了建造軟件的效率。

2、對很多不同的應用領域提供了一種可行性途徑和解決方案

過程模型總分為三大類：

1.慣例過程模型：

(1)瀑布模型(又叫作生命週期模型)。

(2) 增量過程模型: 包括增量模型、RAD模型。

(3) 演化過程模型: 包括 原型開發模型、螺旋模型、協同開發模型。

(4) 專用過程模型: 包括 基於構件的開發模型、形式化方法模型、面向方面的軟件開發模型。

2.面向對象模型：

(1)噴泉模型。

(2)可重用部件組裝模型。

3.敏捷過程模型：

(1) XP模型。

(2) 自適應軟件開發。

(3) 動態系統開發。

(4) Scrum模型。

(5) Crystal模型。

(6) 特徵驅動開發。

(7) 敏捷建模。

(參考文獻:軟件工程-實踐者的研究方法 (美) Poger S.Pressman )