【筆記】過程結構及過程模型
一、軟體過程結構
軟體過程：一個為建立高質量軟體說需要完成的活動、動作和任務的框架。
軟體過程定義了軟體工程化中採用的方法，當軟體工程還包含該過程中應用的技術——技術方法和自動化工具。
1.通用過程模型
每個框架活動由一些列軟體工程動作構成；每個軟體工程動作由任務集來定義，這個任務集明確了將要完成的工作任務、將要產生的工作產品\所需要的質量保證點，以及用於表明過程狀態的里程碑。
軟體過程還有一個很重要的方面即過程流，過程流描述了在執行順序和執行時間上如何組織框架中的活動、動作和任務。
- 線性過程流從溝通到部署順序執行五個框架活動。
- 迭代過程流在執行下一個活動前重複執行之前的一個或多個活動。
- 演化過程流採用迴圈的方式執行各個活動，每次迴圈都能產生更為完善的軟體版本。
- 並行過程流將一個或多個活動與其他活動並行執行。
2.明確任務集
每一個軟體工程動作（如需求獲取以及與溝通活動相關的動作）都由若干個任務集構成，而每一個任務集都由軟體工程工作任務、相關工作產品、質量保證點和專案里程碑組成。
3.過程模式
過程描述描述了軟體工程工作中遇到的過程相關的問題，明確了問題環境並給出了針對該問題的一種或幾種可證明的解決方案。過程模式提供了一個模版 —— 一種在軟體過程的背景下統一描述問題解決方案的方法。通過模式組合，軟體團隊可以解決問題並定義最符合專案需求的開發過程。
Ambler提出了下面的過程模式的描述模版：
模式名稱：模式名稱應能清楚地表述該模式在軟體過程中的含義。
驅動力：模式的使用環境及主要問題，這些問題會顯現在軟體過程中並可能影響解決方案。
型別：定義模式型別。Ambler提出了三種類型：
- 1.步驟模式——定義了與過程的框架活動相關的問題。步驟模式包括與步驟（框架活動）有關的許多工模式。
- 2.任務模式——定義了與軟體工程動作或是工作任務相關\關係軟體工程實踐成敗的問題。
- 3.階段模式——定義在過程中發生的框架活動序列，即使這些活動流本質上是迭代的。
啟動條件：描述的是模式應用的前提條件。
問題
解決問題：描述如何成功實現模式。這部分主要討論隨著模式的啟動，過程的初始狀態（模式應用之前就已存在）是如何發生改變的。解決方案也描述了隨著模式的成功執行，模式啟動之前所獲得的軟體工程資訊和專案資訊是如何變換的。
結果描述模式成功執行之後的結果。模式完成時需要明確：（1）必須完成哪些開發組織或是開發團隊相關的活動？（2）過程的結束狀態是什麼？（3）產生了哪些軟體工程資訊或是專案資訊？
相關模式：以層次化或其他圖的方式列舉與該模式相關的其他過程模式。
已知應用和例項：說明該模式可應用的具體例項。
過程模式提供了一種有效的機制，用以解決任何與軟體過程相關的問題。模式使得軟體工程組織能夠從高層抽象開始（階段模式）建立層次化的過程描述。高層抽象描述又進一步細化為一系列步驟模式以描述框架活動，然後每一個步驟模式又進一步逐層細化為更詳細的任務模式。過很模式一旦建立起來，就可以進行復用以定義各種過程變體，即軟體開發團隊可以將模式作為過程模型的構建模組，定製特定的過程模型。
二、過程模型
概念：過程模型為軟體工程工作提供了特定的路線圖，該路線圖規定了所有活動的流程、動作、任務、迭代的程度、工作產品及要完成的工作應如何組織。
重要性：軟體過程提高了軟體工程的穩定性、可控性和有組織性，如果沒有過程約束，軟體活動將失控並變得混亂。
步驟：過程模型為軟體人員提供了開展軟體工程工作需要遵循的步驟。
工作產品：工作產品是對過程所定義的活動和任務的格式化描述。
質量保證措施：表徵軟體過程有效性的最好指標還是所構建產品的質量、及時性和壽命。
1.慣用過程模型
慣用過程模型力求達到軟體開發的結構和秩序，其活動和任務都是按照過程的特定指引順序進行的。
它規定了一套過程元素——框架活動、軟體工程動作、任務、工作產品、質量保證以及每個專案的變更控制機制。每個過程模型還定義了過程流（也稱工作流）——即過程元素相互之間關聯的方式。
瀑布模型
當從溝通到部署都採用合理的線性工作流方式的時候，可以清楚地理解問題 需求。這種情況通常發生在需要對一個已經存在的系統進行明確定義的適應性調整或是增強的時候；也可能發生在很少數新的開發工作上，但是需求必須是準確定義和相對穩定的。
瀑布模型又稱為經典生命週期，它提出了一個系統的、順序的軟體開發方法，從使用者需求規格說明開始，通過策劃、建模、構建和部署的過程，最終提供完整的軟體支援。
瀑布模型的一個變體成為V模型。V模型描述了質量保證動作同溝通、建模相關動作以及早期構建相關動作之間的關係。隨著軟體團隊工作沿著V模型左側步驟向下推進，基本問題需求逐步細化，形成了對問題及解決方案的詳盡且技術性的描述。一旦編碼結束，團隊沿著V模型右側的步驟向上推進工作，其本質上是執行了一系列測試（質量保證動作），這些測試驗證了團隊沿著V模型左側步驟向下推進過程中所生成的每個模型。
瀑布模型的問題：
- 實際的專案很少遵守瀑布模型提出的順序。雖然線性模型可以加入迭代，但是它是用間接的方式實現的，結果隨著專案組工作的推進，變更可能造成混亂。
- 客戶通常難以清楚地描述所有的需求。而瀑布模型卻要求客戶明確需求，這就很難適應在許多專案開始階段必然存在的不確定性。
- 客戶必須要有耐心，因為只有在專案接近尾聲的時候，他們才可能得到可執行的程式。對於系統中存在的重大缺陷，如果在可執行程式評審之前沒有發現，將可能造成慘重損失。
目前，軟體工作快速進展，經常面臨永不停止的變更流，特性、功能和資訊內容都會變更，瀑布模型往往並不適合這類工作。儘管如此，在需求已經確定的情況下，且工作採用線性的方式完成的時候，瀑布模型是一個很有用的過程模型。
增量過程模型
在許多情況下，初始的軟體需求有明確的定義，但是整個開發過程卻不宜單純運用線性模型。同時，可能迫切需要為使用者迅速提供一套功能有限的軟體產品， 然後在後續版本中再進行細化和擴充套件功能。在這種條件下， 需要選用一種以增量的形式生產軟體產品的過程模型。
增量模型綜合了線性過程流和並行過程流的特徵。隨著時間的推移，增量模型在每個階段都運用線性序列。每個線性序列生產出軟體的可交付增量。
運用增量模型的時候，第一個增量往往是核心產品。也就是滿足了基本的需求，但是許多附加的特性（一些是已知的，一些是未知的）沒有提供，客戶使用該核心產品並進行仔細的評估，然後根據評估結果制定下一個增量計劃。這份計劃應說明需要增加的特性和功能。每一個增量的教輔都會重複這一過程，直到最終產品的產生。
演化過程模型
軟體開發人員需要一種專門應對不斷演變的軟體產品的過程模型。演化模型是迭代的過程模型，這種模型使得軟體開發人員能夠逐步開發出更完整的軟體版本。下面介紹兩種常用的演化過程模型。
- 原型開發
客戶定義了軟體的一些基本任務，但是沒有詳細定義功能和特性需求。另一種情況下，開發人員可能對演算法效率、作業系統的適用性和人機互動的形式等情況並沒有把握。在這些情況和類似情況下，採用原型開發範型是最好的解決辦法。
不論人們以什麼方式運用它，當需求很模糊的矢耦，原型開發模型都能幫助軟體開發人員和利益相關者更好地理解究竟需要做社麼。
理想狀況下，原型系統提供了定義軟體需求的一種機制。當需要構建可執行的原型系統時，軟體開發人員可以利用已有的程式片段或應用工具快速產生可執行的程式。
原型開發存在問題：
- 利益相關者看到了軟體的工作版本，卻未察覺到軟體是隨意搭成的，也未察覺到為了儘快完成軟體，開發者沒有考慮到整體軟體質量和長期的可維護性。當開發者告訴客戶整個系統需要重建以提高軟體質量的時候，利益相關者會不願意，並且要求對軟體稍加修改使其變為一個可執行的產品。在絕大多數的情況下，軟體開發管理層會做出妥協。
- 作為一名軟體工程師，為了使一個原型快速執行起來，往往在實現過程中採用折衷的手段。他們經常會使用不合適的作業系統或程式設計語言，僅僅因為當時可用或他們對此較為熟悉。他們也經常會採用一種低效的演算法，僅為了證明系統的能力。時間長了，軟體開發人員可能會適應這些選擇，而忽略了這些選擇其實並不合適的理由，結果使並不完美的選擇成了系統的組成部分。
- 螺旋模型
螺旋模型是一種演進式軟體過程模型。它結合了原型的迭代性質和瀑布模型的可控性和系統性特點。它具有快速開發越來越完善的軟體版本的潛力。
螺旋模型是一種風險驅動型的過程模型生成器面對與軟體集中的系統它可以知道多個利益相關者的協同工作。它有兩個顯著的特點：一是採用迴圈的方式逐步加深系統定義和實現的深度，同時降低風險。二是去誒的那個一系列里程碑作為支撐點，確保利益相關者認可是可行的且令各滿意的系統解決方案。
螺旋模型被分割成一系列由軟體工程團隊定義的框架活動。每個框架活動代表螺旋上的一個片段。隨著演進過程開始，從圓心開始順時針方向，軟體團隊執行螺旋上的一圈所表示的活動。在每次演進的時候，都要考慮風險。每個演進過程都要標記里程碑——沿著螺旋路徑達到的工作產品和條件的結合體。
其他過程模型在軟體交付後就結束了。螺旋模型則不同，它應用在計算機軟體的整個生命週期。本質上，當螺旋模型以這種方式進行下去的時候，它將永遠保持可操作性，指導軟體產品的生命週期結束。過程經常會處於休止狀態，但每當有變更時，過程總能夠在合適的入口點啟動（如產品提高）。
螺旋模型是開發大型系統和軟體的很實際的方法。由於軟體隨著過程的推進而變化，因此在每一個演進層次上，開發者和客戶都可以更好地理解和應對風險。螺旋模型把原型作為降低風險的機制，更重要的是，開發者可以在產品演進的任何階段使用原型方法。它保留了經典生命週期模型中系統逐步細化的方法，但是把他納入一種迭代框架之中，這種迭代方式與真是世界更加溫和。螺旋模型要求在專案的所有階段始終考慮技術風險，如果適當地應用這種方法，就能夠在風險變為難題之前將其化解。
併發模型
併發開發模型優勢也叫做併發工程，它允許軟體團隊表述本文所描述的任何過程模型中的迭代元素和併發元素。
併發建模定義了一系列事件，這些事件將觸發軟體工程活動、動作或者任務的狀態轉換。
併發建模可用於所有型別的軟體開發，它能夠提供精確的專案當前狀態圖。它不是把軟體工程活動、動作和任務侷限在一個事件的序列，而是定義了一個過程網路。網路上每個活動、動作和任務與其他活動、動作和任務同時存在。過程網路中某一點產生的事件可以出發與每一個活動相關的狀態的轉換。
演化過程綜述
很多廣為人們尊重的軟體工程專家建議：軟體過程強調靈活性、可擴充套件性和開發速度而不是高質量。
演化模型的初中是採用迭代或者增量的方式開發高質量軟體。可是，用演化模型也可以做到強調靈活性、可延展性和開發速度。軟體團隊及其經理所面臨的挑戰就是在這些嚴格的專案、產品引數與客戶滿意度之間找到一個合理的平衡點。
2.專用過程模型
專用過程模型往往應用面較窄且較專一，值適用於某些特定的軟體工程方法。
基於構件的開發
商業現貨軟體構件由廠家作為產品供應，通過良好定義的介面提供特定的功能，這些構件能夠整合到正在構建的軟體中。基於構件的開發模型具有許多螺旋模型的特點。它本質上是演化模型，需要以迭代方式構建軟體。不同之處在於，基於構件的開發模型採用預先打包的軟體構件來開發應用系統。
建模和構建活動開始於識別可選構件。這些構件有些設計成傳統的軟體模組，有些設計成面向物件的類或類包。若不考慮構件的開發技術，則基於構建開發模型由以下步驟組成：
- 對於該問題的應用領域研究和評估可用的基於構件的產品。
- 考慮構件整合的問題。
- 設計軟體架構以容納這些構件。
- 將構件整合到架構中。
- 進行充分的測試以保證功能正常。
形式化方法模型
形式化方法模型的主要活動是生成計算機軟體形式化的數學規格說明。形式化方法使軟體開發人員可以應用嚴格的數學符號來說明、開發和驗證基於計算機的系統。這種方法的一個變形是淨室軟體工程。
形式化方法提供了一種機制，使得在軟體開發中可以避免一些問題，而這些問題在使用其他軟體工程模型時是難以解決的。使用形式化方法時，歧義性問題、不完整問題、不一致問題等都能夠更容易地被發現和改正——不是依靠特定評審，而是應用數學分析的方法。在設計階段，形式化方法是程式驗證的基礎，使軟體開發人員能夠發現和改正一些誒常常被忽略的問題。
形式化模型的問題：
- 目前，形式化模型開發非常耗時，成本也很高。
- 只有極少數程式設計師具有應用形式化方法的北京，因此需要大量的培訓。
- 對於技術水品不高的客戶，很難用這種模型進行溝通。
面向方面的軟體開發
區域性的軟體特性被做成構件（例如面向物件的類），容納後在系統架構中使用。隨著現代計算機系統變得更加複雜，某些關注點——客戶需要的屬性或者技術興趣點——已經體現在整個架構設計中。
如果某個關注點涉及系統的多個方面的功能、特性和資訊，那麼這些關注點通常被稱為橫切關注點。方面的需求定義那些對整個軟體體系結構產生影響的橫切關注點。面向方面的軟體開發（AOSD）通常稱為面向方面程式設計（AOP）或者面向方面構件工程（AOCE），它是相對較新的一種軟體工程模型，為定義、說明、設計和構建方面提供過程和方法——是對橫切關注點進行區域性表示的一種機制超越了子程式和繼承方法。
面向方面的過程還不成熟。這種過程模型看似具備了演化模型和併發過程模型的共同特點。演化模型適合定義和構建方面；而併發開發的並行特點很重要，因為方面和構件的過程活動之間建立起一步的通訊非常重要。
- 過程管理工具
過程管理工具幫助軟體組織或團隊定義完整的軟體過程模型（框架活動、動作、任務、質量保證檢查點、里程碑和工作產品）。而且，該工具為軟體工程師的技術工作提供路線圖，為經理們跟蹤和控制軟體過程提供模版。代表性工具有GDPA、ALM Studio、ProVision BPMx。
3.統一過程
在某種程度上，統一過程嘗試著從傳統的軟體過程中挖掘最好的特徵和性質，但是以敏捷軟體開發中許多最好的原則來實現。統一過程認識到與客戶溝通以及從使用者的角度描述系統（即用例）並保持該描述的一致性的重要性。它強調軟體體系結構的重要作用，並“幫助架構師專注於正確的目標，例如可理解性、對未來變更的可適應性以及複用”。它建立了迭代的、增量的過程流，提供了演進的特性，這對現代軟體開發非常重要。
統一過程的階段
UP的起始階段包括客戶溝通和策劃活動。通過與利益向掛著寫作定義軟體的業務需求，提出系統大致的結構，並制定開發計劃以保證專案開發具有迭代的增量特性。該階段識別基本的業務需求，並初步用用例描述每一類使用者所需要的主要特性和功能。此時的體系結構僅是主要子系統及其功能、特性的試探性概括。隨後，體系結構將被細化和擴充成為一組模型，以描述系統的不同檢視。策劃階段將識別各種資源，評估主要風險，制定進度計劃，併為其在軟體增量開發的各個階段中的應用建立基礎。
UP的細化階段包括溝通和通用過程模型的建模活動。細化階段擴充套件了初始階段定義的用例，並擴充套件了體系結構以包括軟體的五種檢視——用例模型、需求模型、設計模型、實現模型和部署模型。在某些情況下，細化階段建立了一個“可執行的體系結構基線”，這是建立可執行系統的第一步。體系結構基線證明了體系結構的可實現性，但沒有提供系統使用時所需的所有功能和特性。另外，在細化的最終階段將評審專案計劃以確保專案的範圍、風險和交付日期的合理性。該階段通常要對專案計劃進行修訂。
UP的構建階段與通用軟體過程中的構建活動相同。構建階段採用體系結構模型作為輸入，開發或是獲取軟體構件，使得終端使用者能夠操作用例。為達上述目的， 要對在細化階段開始的需求模型和設計模型加以完善，以反映出軟體增量的最終版本。軟體增量所要求的必須具備的特性和功能在原始碼中實現。隨著構件的實現，對每一個構件設計並實施單元測試。另外，還實時了其他整合活動（構件組裝和整合測試）。用例用於到處一族驗收測試，以便在下一個UP階段開始前執行。
UP的轉換階段包括通用構建活動的後期階段以及通用部署（交付和反饋）活動的第一部分。軟體被提交給終端使用者進行Beta測試，使用者反饋報告缺陷及必要的變更。另外，軟體開發團隊建立系統釋出所必須的支援資訊（如使用者手冊、問題解決指南及安裝步驟）。在轉換階段結束時，軟體增量成為可用的釋出版本。
UP的生產階段與通用過程的部署活動一致。在該階段，對持續使用的軟體進行監控，提供執行環境（基礎設施）的支援，提交併評估缺陷報告和變更請求。
有可能在構件、轉換和生產階段的同時，下一個軟體增量的工作已經開始。這就意味著五個UP階段並不是順序進行，而是階段性地併發進行。
軟體工程的工作流分佈在所有UP階段。在UP中，工作流類似於任務集。工作流識別了完成一個重要的軟體工程活動的必要任務，以及在成功完成任務之後所產生的工作產品。並不是工作流所識別的每一個任務都在所有的系那個目中應用。軟體開發團隊應根據各自的需要適當調整過程（動作、任務、子任務及工作產品）。
產品和過程
Margaret Davis對產品和過程的雙重性的評述：
我相信，我們對軟體組成部分和開發過程的觀測證明了軟體具有過程和產品的二象性。如果僅僅將軟體看作一個過程或是一個產品，那就應用都不能正確地理解軟體，包括其背景、應用、意義和價值。
所有的人類活動都可以看成是一個過程，我們每一個人都從這些活動中獲得對自我價值的認識，這些活動所產生的結果可以被許多人反覆地在不同情況下使用。也就是說，我們是從我們自己或是他人對我們產品的複用中得到滿足的。
因此，將複用目標融入軟體開發，這不僅潛在地增加了軟體專業人員從工作中獲得的滿足感，也增加了接受“產品和過程二象性”這一觀點的緊迫性。對於一個可複用的部件，如果僅僅從產品或是僅僅從過程的角度考慮，都不利於軟體開發，這種批那面的觀點或者影響了人們對產品的應用環境和應用方法的認識，或者忽略了該產品還可以作為其他開發活動的輸入這一事實。因此，片面地強調某一方面的觀點會極大地降低軟體複用的可能性，也會大大減少工作的成就感。