軟體過程的概念
軟體過程是一個為建立高質量軟體所需要完成的活動，動作和任務的框架。
1.慣用過程模型
慣用過程模型力求達到軟體開發的結構和只需，其活動和任務都是按照過程的特定指引順序進行的。
1.1 瀑布模型
瀑布模型又稱為經典生命週期，它提出了一個系統的，順序的軟體開發方法，從使用者需求規格說明開始，通過策劃，建模，構建和部署的過程，最終提供完整的軟體支援。
瀑布模型的一個變體稱為V模型。V模型描述的質量保證動作同溝通，建模相關動作以及早期構建相關動作之間的關係。隨著軟體團隊工作沿著V模型左側步驟向下推進，基本問題需求逐步細化，形成了對問題及解決方案的詳盡且技術性的描述。一旦編碼結束，團隊沿著V模型右側的步驟向上推進工作，其本質上是執行了一些列測試(質量保證動作)，這些測試驗證了團隊沿著V模型左側步驟向下推進過程中所生成的每個模型。
實際上，經典生命週期模型和V模型沒有本質區別，V模型提供了一種將驗證和確認動作應用於早期軟體工程工作中的直觀方法。
為什麼瀑布模型有時候會失效？ 1.實際的專案很少遵守瀑布模型提出的順序。雖然線性模型可以加入迭代，但是它是用間接的方式實現的，結果是，隨著專案組工作的推進，變更可能造成混亂。 2.客戶通常難以清楚的描述所有的需求。而瀑布模型卻要求客戶明確需求，這就很難適應在許多專案開始階段必然存在的不確定性。 3.客戶必須要有耐心，因為只有在專案接近尾聲的時候，他們才能得到可執行的程式。對於系統中存在的重大缺陷，如果在可執行程式評審之前沒有發現，將可能造成慘重的損失。
他的優點就是適合那種需求已經確定的情況，且工作採用線性的方式完成的時候，瀑布模型是一個很有用的過程模型。
1.2 增量過程模型
在許多情況下，初始的軟體需求有明確的定義，但是整個開發過程卻不宜單純運用線性模型。同時，可能迫切需要為使用者迅速提供一套功能有限的軟體產品，然後在後續版本中再進行細化和擴充套件功能。在這種條件下，需要選用一種以增量的形式生產軟體產品的過程模型。
隨著時間的推移，增量模型在每個階段都運用線性序列。每個線性序列生產出軟體的可交付增量。
運用增量模型的時候，第一個增量往往是核心產品。
也就是滿足了基本的需求，但是許多附加的屬性沒有提供，客戶使用該核心產品並進行仔細的評估，然後根據評估結果制定下一個增量計劃。這份計劃應說明需要對核心產品進行的修改，一遍更好的滿足和客戶的需求，，夜鶯說明需要增加的特性和功能。每一個增量的交付都會重複這一課程，知道最紅產品的產生。
1.3 演化過程模型
軟體開發人員需要一種專門應對不斷演變的軟體產品的過程模型。 演化模型是迭代的過程模型，這種模型使得軟體開發人員能夠逐步開發出更完整的軟體版本。 演化過程模型有兩種：
原型開發 已經定義了軟體的一些基本任務，但是沒有詳細定義功能和特性需求。可以幫助軟體開發人員和利益相關者更好的理解究竟需要做什麼。 就是先設計一個原形，然後在原形系統不斷調整以滿足各種利益相關者需求的過程中，採用迭代技術，同時也使開發者逐步清楚使用者的需求。
理想狀態下，原型系統提供了定義軟體需求的一種機制。當需要構建可執行的原型系統時，軟體開發人員可以利用已有的程式片段或應用工具快速產生可執行的程式。
原型系統缺點： 1.利益相關者看到了軟體的工作版本，卻未察覺到整個軟體是隨意搭成的，也未察覺到為了儘快完成軟體，開發者沒有考慮整體軟體質量和長期的可維護性。當開發者告訴客戶整個系統需要重建以提高軟體質量的時候，利益相關者會不願意，並且要求對軟體稍加修改使其變為一個可執行的產品。在絕大多數的情況下，軟體開發管理層會做出妥協。 2.作為一名軟體工程師，為了使一個原型快速執行起來，往往在實現過程中採用折衷的手段。他們經常會使用不合適的作業系統或程式設計語言，僅僅因為當時可用或他們對此較為熟悉。他們也經常會採用一種低效的演算法，僅為了證明系統的能力。時間長了，軟體開發人員可能會適應這些選擇，而忽略了這些選擇其實並不適合的理由，結果使並不完美的選擇成了系統的組成部分。
儘管問題會發生，但原型開發對於軟體工程來說仍是一個有效的範型。關鍵是要在遊戲開始的時候指定規則，也就是說，所有利益相關者必須承認原型是為定義需求伺服器的。然後丟棄原型，實際的軟體系統時以質量第一為目標而開發的。
螺旋模型
螺旋模型將軟體開發為一系列演進版本。在早期迭代中，軟體可能是一個理論模型或是原型。在後來的迭代中，會產生一系列逐漸完整的系統版本。 螺旋模型被分割成一系列由軟體工程團隊定義的框架活動。
每個框架活動代表螺旋上的一個片段。隨著演進過程開始，從圓心開始順時針方向，軟體團隊執行螺旋上的一圈所表示的活動。在每次演進的時候，都要考慮風險。每個演進過程還要標記里程碑-沿著螺旋路徑達到的工作產品和條件的結合體。 螺旋的第一圈一般開發出產品的規格說明，接下來開發產品的原型系統，並在每次迭代中逐步完善，開發不同的軟體版本。
其他過程模型在軟體交付後就結束了。螺旋模型則不同，它應用在計算機軟體的整個生命週期。因此，螺旋上的第一圈可能表示“概念開發專案”，它起始於螺旋的中心，經過多次迭代，直到概念開發的結束。如果這個概念將被開發成為實際的產品，那麼該過程將繼續沿著螺旋向外伸展，成為“新產品開發專案”。新產品將沿著螺旋通過一系列的迭代不斷的演進。最後，可以用一圈螺旋表示“產品提高專案”。本質上，當螺旋模型以這種方式進行下去的時候，它將永遠保持可操作性，知道軟體產品的生命週期結束。過程經常會處於休止狀態，但當有變更時，過程總能夠在合適的入口點啟動。
螺旋模型是開發大型系統和軟體的很實際的方法。由於軟體隨著過程的推進而變化，因此在每一個演進層次上，開發者和客戶都可以更好的理解和應對風險。螺旋模型把原型作為降低風險的機制，更重要的是，開發人員可以產品眼睛的任何階段使用原型方法。它保留了經典生命週期模型中系統逐步細化的方法，但是把它納入一種迭代框架之中，這種迭代方式與真實世界更加吻合。螺旋模型要求在專案的所有階段適中考慮技術風險，如果適當的應用該方法，就能夠在風險變為難題之前將其化解。
1.4 併發模型
併發開發模型有時也叫做併發工程，它允許軟體團隊表述本章所描述的任何過程模型中的迭代元素和併發元素。
在某一特定時間，建模活動可能處於任何一種狀態中.其他活動，動作或任務（如溝通或構建）可以用類似的方式表示。所有的軟體工程活動同時存在並處於不同的狀態。
併發建模可用於所有型別的軟體開發，它能夠提供精確的專案當前狀態圖。
併發建模可用於所有型別的軟體開發，它能夠提供精確的專案當前狀態圖。他不是軟體工程活動，動作和任務侷限在一個事件的序列，而是定義了一個過程網路。網路上每個活動，動作和任務與其他活動，動作和任務同時存在。過程網路中某一點產生的事件可以觸發與每一個活動相關的狀態的轉換。
缺點：演化模型的初衷是採用迭代或者增量的方式開發高質量軟體。可是，用演化模型也可以做到強調靈活性，可延展性和開發速度。軟體團隊及其經理所面臨的挑戰就是在這些嚴格的專案，產品引數與客戶滿意度之間找到一個合理的平衡點。
統一過程模型
UP(統一過程)起始階段包括客戶溝通和策劃活動。通過與利益相關者協作定義軟體的業務需求，提出系統的大致架構，並制定開發計劃以保證專案開發具有地帶和增量的特性。該階段識別基本的業務需求，並初步用用例描述每一類使用者所需要的主要特性和功能。此時的體系結構僅是主要子系統及其功能，特性的試探性概括。隨後，體系結構將被細化和擴充成為一組模型，以描述系統的不同檢視。擦花階段將識別各種資源，評估主要風險，指定進度計劃，併為其在軟體增量開發的各個階段中的應用建立基礎。
細化階段
包括溝通和通用過程模型的建模活動。細化階段擴充套件了初始階段定義的用例，並擴充套件了體系以包括軟體的五種檢視-用例模型，需求模型，設計模型，實現模型和部署模型。但是這個時候沒有提供系統使用時所需的所有功能和特性。在細化的最終階段將評審專案計劃以確保專案的範圍，風險和交付日期的合理性。該階段通常要對專案計劃進行修訂。
構建階段 構建階段採用體系結構模型作為輸入，開發或是獲取軟體構件，使得終端使用者能夠操作用例。為達到上述目的，要對在細化階段開始的需求模型和設計模型加以完善，以反映出軟體的最終版本。對每一個構建設計並實施單元測試。
轉換階段 包括通用構建活動的後期階段以及通用部署活動的第一部分。軟體被提交給終端使用者盡心beta測試，使用者反饋報告缺陷及必要的變更。另外，軟體開發圖那件建立系統釋出所必須的支援資訊。在轉換階段結束時，軟體增量成為可用的釋出版本。
生產階段
與通用過程的部署活動一致。在該階段，對持續使用的軟體進行監控，提供執行環境的支援，提交併評估缺陷報告和變更請求。
有可能在構建，轉換和生產階段的同時，下一個軟體增量的工作已經開始。這就意味著五個Up階段並不是順序進行，而是階段性的併發進行。
注：本文內容均來自《軟體工程 實踐者的研究方法 第八版》，僅供自己學習