Software Process Models
簡介
軟件過程是構建軟件的一系列活動，這些活動包含了軟件從無到有的開發過程。然而越來越多的新型軟件都是通過擴展已有的系統或集成現有的軟件組件來完成開發。
軟件過程模型是一種軟件過程的抽象表現，每種過程模型會從一種特殊的視角來表示一種過程，因此僅僅會提供一種局部的信息來反映該過程。本節將介紹一些常用的過程模型，然後從架構的角度來說明他們，因此，我們將探討每個過程的框架結構而不會涉及到具體的細節活動。
瀑布模型
第一種發佈的軟件開發過程模型衍生自很多系統工程的過程中，這種模型如圖1.
此模型由於是從一個階段到另一個階段的層級形式，所以被稱爲瀑布模型或軟件生命週期模型。瀑布模型包含的基本開發活動有：
1. 需求分析和定義：由用戶建立系統服務、受限約束以及實現目標，然後定義具體細節和指定系統規範。
2. 系統和軟件設計：系統設計過程把需求劃分爲硬件和軟件系統兩部分，並建立整體的系統架構。而軟件設計則會確定並描述系統抽象定義關係。
3. 實現和單元測試：在此階段，軟件設計會由程序集或程序單元來實現，而單元測試則是驗證每個模塊是否滿足需求定義。
4. 集成和系統測試：把獨立的程序單元集成爲一個完整的系統並測試其功能是否符合需求規範。
5. 使用和維護：一般的，這是一個長期階段，安裝好系統後並交付用戶使用。維護則包含有修改錯誤，改進系統實現。
一般而言，每個階段都會形成很多文檔，上一個階段沒有完成時，則不能開始下一個階段。事實上，這些過程會相互重疊並相互補充信息。在設計階段，會確認需求中的問題而在編碼階段來尋查到具體的問題。這些過程不僅僅是一種線性模型，而且還會有開發活動的不斷迭代。
由於文檔生成的會有成本，所以迭代會帶來昂貴的代價並涉及到重大的返工。完成一部分迭代開發後，凍結部分開發活動，如需求分析，然後再繼續後續開發階段。有問題留待以後解決，置之不顧，或者通過編程繞過去，這種過早的凍結需求分析可能會不滿足用戶的實際要求，這種設計會造成很糟糕的系統結構。
在瀑布模型的最後一個階段，軟件會付諸使用。在這個過程中，會發現原來的軟件需求中的很多疏忽的地方，除此之外還會添加一些新的功能，因此係統會漸漸變得更適合使用。在確認這些變化時可能又會重複前期的過程。
瀑布模型的優點是各個階段的文檔化同時還適合其他過程模型，它的缺點則是把項目不靈活的劃分成不同的階段，早期階段形成的文檔約定會很難的隨着用戶需求的改變而變化。
因此，在系統開發時，只有需求被充分理解後或者需求不會明顯的改變，就適合使用瀑布模型。然而，瀑布模型依然是很多工程項目中的一種過程模型，基於此方式的軟件過程仍然常用於軟件開發。
漸進式開發模型
漸進式開發：先開發一種最初的實現版本，然後交予用戶並獲取他們的修改意見，然後再做改進，直到重複多個版本後最終達到用戶的需求。這種模式如圖2。
在此模型中，需求、開發、確認這些活動在實際開發過程中是相互交叉的而不是單獨獨立的，並根據每項活動的結果對其他活動作出快速的反饋。
關於漸進式開發模型還有兩種基本的類型：
1. 探索式開發：與用戶協同制定需求並逐漸完成最終目標系統。先開發部分功能，然後不斷新增其他的功能。
2. 原型開發：通過原型設計來逐步理解用戶的需求，原型設計能夠集中表達對初期對用戶需求的理解。
漸進式開發模型在系統開發過程中常常比瀑布式模型要更能夠滿足用戶的需求，基於漸進式開發的模型的優點可以隨時添加新的需求到系統中，用戶改變需求後可以很有效的反應到系統中，但是從工程和管理的角度來看，漸進式模型有兩點缺點：
1. 過程不明顯，因此不利於項目經理完成可交付項目進度，如果項目開發過快時，生成每個版本的文檔時，成本也不合算。
2. 系統結構很亂。頻繁的修改會破壞系統的結構，而且後期的修改會更困難同時花費更多成本。
漸進式開發模型很適合中小型系統的開發，對於一些分組開發的大型，複雜而且週期很長的系統，這種模型就會造成特別嚴重的問題，因爲這種方式很難建立一個穩定的系統架構，因此與其他團隊集成的時候就會很困難。
針對大型的系統，常推薦採用瀑布模型和漸進式模型的混合模型來完成開發，採用原型設計來解決需求中模糊的地方，然後採用結構良好的方式來重新實現系統。對於能夠確定的需求功能就採用瀑布模型，對於其他的部分如用戶界面這類很難提前指定的功能，就通過使用逐步探究的方式來完成開發。
基於組件的軟件工程
在大多數的軟件項目中有很多軟件的複用。開發人員可以把相似的設計或代碼複用到相應的需求中，當需要的時候，他們通過查找和修改代碼後，然後把這些代碼合併到其他系統中，在漸進式開發模型中，軟件的複用對於快速的開發是非常必要的。
這種非正式的軟件複用常常不用考慮使用的開發過程，但是在過去的幾年裏，出現了一種叫基於組件的軟件工程（CBSE）模型，這種模型很注重複用，如今已經變得越來越常用。
面向複用的方式依靠很多基礎軟件組件和一些集成框架，有時候，一些提供特殊功能如文本格式化或數值計算的系統組件還是現成可用的。CBSE的通用過程模型如圖3所示。
在這個模型中，最初的需求分析階段和最後的系統驗證階段可類比其他過程模型，但中間的面向複用的過程卻是不同的，這些階段如下：
1. 組件分析：在有需求規格說明的情況下，需要進行查找操作，通常都沒有很精確的匹配結果，所使用的組件僅能提供一些已知的功能。
2. 需求修改：在此階段會利用有獲取到的組件信息來重新分析需求，然後修改至反映到可用的組件上。當不能修改確定的需求時，則會重新分析組件。
3. 系統重用設計：在此階段會設計或重用系統框架，設計人員把重用的組件融入到系統框架中，如果某些組件實在是不能滿足需要時，則會重新設計新的軟件組件。
4. 開發和集成：在此階段會開發不能通過第三方獲取的程序，然後集成已有的和其他現成的組件來創建一個新的系統。系統集成在這個模型中只是一個軟件過程而不是獨立的活動。
基於組件的軟件工程模型很明顯的優點是可減少軟件開發量以及開發成本和風險，而且常常帶來很快的開發效率，然而需求卻作出一些妥協，因此會導致系統可能不滿足用戶的實際需要。此外，還存在版本更替時不便於控制的情況。
軟件測試技術
目前有許多可能的軟件測試技術，他們可混合的用來提供最好的測試覆蓋和結果。不管有多少測試，都不可能全面而徹底的保證程序的正確性，不可能測試所有的輸入數據和代碼執行路徑。
根據各種條件測試技術可以分成幾種類型，如下的討論則是基於5種條件而言的：(1)可見性，(2)自動化，(3)劃分條件，(4)覆蓋範圍，(5)腳本處理。可如圖4所示：
測試中的條件不是獨立的，比如兩種劃分條件可應用到黑盒測試，但是不能應用於白盒測試，腳本技術測試（迴歸測試、運動測試）都是自動化的測試。
黑盒測試假定測試者在測試中不知道或者忽略測序單元的功能，然後提供一些輸入數據最終獲取輸出結果，並與預期的結果相對比。由於不要求實現技術，黑河測試可有用戶來實施，因此這也是接受測試的主要技術。
黑盒技術常常測試系統的功能或者一些精確的功能輸出，還應用於一些限制性測試，如系統性能或安全性測試。當程序中沒有實現預期的功能需求時，黑盒測試的指定的目標就是測試該功能是否遺漏，在這種情況中，測試單元會獲取數據然後觸發該功能，如果失敗了則會知道程序中沒有代碼實現。
白盒測試（代碼測試）與黑盒測試相反，它更能揭示的測試的內容。用這種方式，測試者需要考慮代碼然後決定輸入的數據，並利用數據來選擇執行路徑。根據測試規格，黑盒測試必須在白盒測試之後，這樣才能定位到發現的錯誤。
與黑盒測試不一樣，白盒測試不用限制代碼測試，它還適用於其他開發構件，如設計模型和規格文檔。這種類型的測試使用審視技術，例如走查、審查等。用黑盒測試還能發現程序中的無作用的代碼（Dead Code，程序中永遠都不能被執行的語句）。
等值劃分和邊界值技術應用最多是在黑盒測試中，但也可以應用在白盒測試中。他們是黑盒測試技術中的一些特殊方式，以此來抵消不可能進行詳盡的測試。
等值劃分把輸入數據劃分成均勻的幾組測試目標，然後假設任意一劃分組的測試結果與其他組一樣，因此可以忽略其他劃分組的測試結果。選擇一組劃分數據是很困難的，因爲需要充分理解數據還有符合程序的要求。從這個方面上講，劃分部分本身實際上不是黑盒測試，黑盒測試是一種提供了等值劃分測試的測試技術。
邊界值測試僅僅是一種附加的附加數據分析技術，它用於輔助等值劃分測試。在等值劃分測試中，邊界值一種極端的情況，例如，如果從1到100的整數劃分的話，則會執行邊界分析，在這個例子中就是-1，0，+1還有99，100，101。自然地，對於-1，101就是錯誤的條件。
覆蓋技術可以決定白盒測試執行多少代碼。操作覆蓋（方法覆蓋）確保代碼中的每個操作都能夠被至少執行一次，操作覆蓋是現代面向對象的，常用於替換過程語言中的語句和分支覆蓋。
路徑覆蓋爲程序中的執行路徑排上編號，並一個一個的執行他們。很明顯，在大型程序中，這樣的編號是不確定的，測試者只能定義最關鍵最常用的路徑，然後執行這些路徑。
測試可以是手動進行也可以自動進行。在手動測試中，測試者需要與應用程序相互交互，首先啓動程序，有條不紊的執行程序的功能，並觀察執行結果。自動測試則是根據預先的定義的測試腳本然後實施執行步驟，測試腳本首先定義好每一步的測試行爲和預期結果，實際應用中，用例和其他需求文檔常常用於編寫測試腳本。
手動測試最大的問題是在大多數實際情境中都是基於實時數據來執行的，對於手動測試中重複的執行部分，沒有固定的預先定義的基準數據來保證相同的輸出結果。因此，在自動測試的腳本中，預期的輸出結果常常不會定義的很精確。測試的輸出結果一般不會顯示在屏幕上，而是儲存在數據庫中，這迫使測試者編寫並允許SQL腳本或其他測試框架，來檢查測試行動的結果。
對於準備、執行和管理方面，手動測試要花費很多代價，他們不能滿足測試的要求量，而自動化測試使用工具來執行大量的測試，還不用人工參與。這些工具能夠生成測試後的報表來幫助管理測試結果，自然地，需要由人來準備執行任務，還有編寫測試腳本，安裝測試環境等。
正如在圖4中顯示的那樣，自動化測試可分爲迴歸測試和運動測試。迴歸測試的意思是用相同的腳步重複的在相同的基線數據上進行測試，然後根據執行結果與上次測試結果做對比，觀察是否不一致。測試的功能從表面上看起來都是不相關的。
迴歸測試由預定的測試腳本在設定的時間裏自動的執行，在測試人員的測試中，測試人員的操作會被捕獲工具程序記錄到原始測試腳本中，迴歸測試是一種腳本的重複執行活動，在許多情況下，測試人員會修改記錄捕獲腳本來允許重複測試一些工具不能完成的功能。
運動測試也是一種自動的覆蓋測試，運動測試工具能夠自動和隨機的生成很多測試方案，並能由用戶執行測試，這種測試方式可類比用戶隨機按鍵，選擇菜單或者點擊任意按鈕。工具生成的測試行爲被記錄在腳本中，這些腳本能夠測試程序的功能，一旦程序有任何的錯誤或故障，都會記錄在單獨的腳步中，這些腳本叫做缺陷腳本，可用於重新定位錯誤然後找出原因。
由於迴歸測試和運動測試都是使用捕獲工具，因此他們可以相互配合使用，然後創建一種很強大的自動化測試環境。在實踐中，自動化測試的難點不是在實施上而是在穩定的測試環境（帶有相同的數據庫，相同的應用程序，網絡速度，桌面環境，分辨率，顏色，字體等）中運行連續的程序腳本。所有的自動測試結束後，都應該能夠清理環境，然後重建數據庫和重新整理程序測試工具等。
