1.4 軟體過程&開發模型

05-15

「過程」的定義：
使用資源將輸入轉化為輸出的活動所構成的系統。(ISO9000)此處的「系統」指「相互關聯或相互作用的一組要素」。

軟體過程，是為了獲得高質量軟體所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。

軟體生命周期

①軟體定義時期（系統分析）

(1). 問題定義
(2). 可行性研究

(3). 需求分析

②軟體開發時期

(4). 總體設計
(5). 詳細設計
(6). 編碼和單元測試
(7). 綜合測試

③軟體維護時期

(8). 運行維護——每次維護都是一次簡化的定義和開發過程

瀑布模型（Waterfall Model）

瀑布模型最早於1970年由溫斯頓·羅伊斯（Winston Royce）提出，藉助了其他行業（比如建築）的成熟經驗。

但是，軟體行業和其他看得見、摸得著的行業不通，房子建好了，是不能改的，但軟體寫好了，可以卻修改！所以溫斯頓當時就指出：

相鄰步驟要有回溯，要回頭解決上一階段未能解決的問題；
溫斯頓還指出，最好把這個模型走兩遍，先做個版本，收集反饋再改進。

但是，老百姓不喜歡太複雜的東西。為了方便研究，溫斯頓的改進措施被無視，瀑布模型只保留了主幹部分。如下圖所示：

特點

1. 階段分明——前階段為後階段的基礎（順序性、依賴性）
2. 推遲實現——實踐表明，對於大型項目：編碼越早，耗時越多，於是瀑布模型把編碼放在第四階段
3. 質量保證——每個階段必須完成規定的文檔，並對文檔進行評審

優點：

規範，
文檔齊備，
質量有保證

缺點：

（1）開發過程一般不能逆轉，否則代價太大；
（2）實際的項目開發很難嚴格按該模型進行；
（3）需要明確的客戶需求（實際上不可能）
（4）軟體的實際情況必須到項目開發的後期才能看到，要求客戶有足夠的耐心。

瀑布模型的使用範圍：

（1）用戶的需求非常明確、全面，很少變更；
（2）開發人員對軟體的應用領域很熟悉；

瀑布模型寧有種乎？?

mp.weixin.qq.com

快速原型模型

快速完成可運行的程序，功能只實現部分。

用戶試用之後，提出修改意見，開發人員快速修改原型，再試用……

一旦用戶滿意（開發人員與用戶達成共識），則表明需求確定，按此開發完整軟體產品。

優點：

（1）需求不會出太大偏差，有效降低風險
（2）如果需要對用戶培訓，後續版本的開發與培訓的可以同步，節約時間；
（3）對用戶比較友好，早期就能看到產品。

缺點：

不利於開發人員的創新

螺旋模型

快速原型模型的加強版，每個階段之前增加了風險分析。

螺旋模型適用於大型項目，但頻繁的風險分析成本很高，且要求開發人員具有豐富的風險評估的知識和經驗。

優點：

（1）靈活，各個階段可以進行變更。
（2）小分段構建大系統，成本計算更容易。
（3）風險可控，
（4）質量有保證。
（5）隨著項目推進，客戶始終掌握項目的最新信息，客戶能夠和管理層有效地交互。

缺點：

（1）建設周期長，而軟體技術發展比較快，可能軟體開發完成後，和當前的技術水平有較大的差距，無法滿足當前用戶需求。

適用範圍：

（1）大項目
（2）需求不明確
（3）預算充足

增量模型

第一個版本只提供最核心的功能（不僅僅是個原型），增量版本不斷地加功能。

難點：需要提高系統的可擴展性。

優點：

（1）人員分配靈活，剛開始不用投入大量人力資源；
（2）如果核心產品很受歡迎，則可增加人力實現下一個增量；
（3）可先發布部分功能給客戶，對客戶起到鎮靜劑的作用。

（4）用戶有充裕的時間學習和適應新產品

缺點：

（1）軟體必須具備開放式的體系結構（即需要很強的可擴展性，設計和實現難度較大）；
（2）並行開發構件時，可能無法集成（風險）
（3）容易變成邊做邊改，從而使軟體過程的控制失去整體性。

適用範圍：

（1）進行已有產品升級或新版本開發，增量模型是非常適合的；
（2）對完成期限嚴格要求的產品，可以使用增量模型；
（3）對所開發的領域比較熟悉而且已有原型系統。

RUP

RUP（Rational Unified Process），Rational 統一過程，也叫「統一軟體開發過程」。是一套軟體開發方法論。

最佳實踐（RUP總結的商業軟體開發經驗）

（1）迭代式開發

（2）管理需求

（3）使用基於構件的體系結構。構件：指功能清晰的模塊/子系統，可復用。

（4）可視化建模

UML——Unified Modeling Language，又稱統一建模語言

（5）軟體質量驗證——要求貫穿於整個開發過程、全體成員參與。

（6）控制軟體變更