軟工Ⅱ複習

目錄

• 軟工Ⅱ複習
  • 第一、二章
    • 名詞：軟體工程
    • 從1950s~2000s之間的特點
  • 第四章
    • 團隊特徵
    • 幾種團隊結構
    • 專案質量保障有哪些措施
    • 實驗中如何進行配置管理活動
    • 名詞：配置項
  • 第五章
    • 名詞：需求
    • 需求層次/型別
  • 第七章
    • 為什麼需要需求規格說明？
    • 對給定的需求示例，判定並修正其錯誤
    • 對給定的需求示例，設計功能測試用例
  • 第八章
    • 名詞：軟體設計
    • 軟體設計的核心思想是什麼？
    • 軟體工程設計有哪三個層次？各層的主要思想是什麼？
  • 第九、十章
    • 體系結構的概念
    • 四種體系結構的風格的優缺點
    • 體系結構設計的過程
    • 包設計原則
    • 體系結構構建之間接⼝的定義
    • 整合測試
  • 十一章
    • 名詞：可用性
    • 人機互動三因素
  • 第十二章
    • 詳細設計的出發點
    • 職責分配
    • 協作
    • 控制風格
    • 設計類圖
    • 詳細順序圖
  • 第十三章
    • 名詞：耦合（結構化設計）
    • 名詞：內聚（結構化設計）
    • 資訊隱藏的思想
    • 兩種常見的資訊隱藏決策
  • 第十四、十五章
    • OO耦合
    • 模組化原則
    • 資訊隱藏原則（接上）
  • 第十六章
    • 如何實現可修改性、可擴充套件性、靈活性
  • 第十七、十八章
    • 名詞：重構
    • 名詞：測試驅動開發
    • 名詞：結對程式設計
    • 軟體構造包含活動
    • 給定程式碼段示例，對其進行改進或者 發現其中的問題
    • 契約式設計
    • 防禦式程式設計
    • 設計測試用例
  • 第十九章 軟體測試
    • 黑盒測試
    • 白盒測試
  • 第二十、二十一章
    • 開發可維護軟體的方法
    • 演化式生命週期模型
    • 逆向工程
    • 再工程
  • 第二十二、二十三章
    • 構建-修復模型 build-fix
    • 瀑布模型
    • 增量迭代模型
    • 演化模型
    • 原型模型
    • 螺旋模型
    • Rational 統一過程模型 RUP

第一、二章

名詞：軟體工程

1. 應用系統的、規範的、可量化的方法來開發、執行和維護軟體，即將工程的方法應用於軟體
2. 對1中方法的研究

從1950s~2000s之間的特點

• 50s：
  • 虛擬計算機：出現大型計算機
  • 軟體抽象實體：軟體依賴於硬體，被視為硬體的一部分；指令碼（第1代語言）、彙編碼（第2代語言）
  • 主要現實問題：科學計算
  • 開發：像生產硬體一樣生成軟體
  • 思想：軟體的硬體的一部分
  • 總結：科學計算；以機器為中心進行程式設計；軟體是硬體的一部分
• 60s：
  • 虛擬計算機：IBM，商業大型機
  • 軟體抽象實體：第三代語言，提供函式機制
  • 主要現實問題：業務應用
  • 開發：build-fix
  • 思想：軟體不同於硬體；用軟體工程的方式生產軟體
  • 總結：業務應用；軟體不同於硬體；用軟體工程的方式生產軟體
• 70s：
  • 虛擬計算機：微型計算機，便宜了
  • 軟體抽象實體：結構化程式設計（函式過程、塊、三種基本控制結構（順序、分支、迴圈））
  • 主要現實問題：軟體花費超過硬體
  • 開發：瀑布模型；結構化設計（資料流圖DFD、實體關係圖ERD、結構圖）、結構化分析
  • 思想：越早發現和修復問題，代價越低
  • 總結：結構化方法；瀑布模型；強調規則和紀律
• 80s：
  • 虛擬計算機：PC
  • 軟體抽象實體：面向物件程式設計
  • 主要現實問題：軟體維護上費用超過軟體開發
  • 技術：結構化方法；OO程式設計；軟體複用
  • 開發：過程模型（原型、漸進交付、演化、螺旋）；過程評價；使用工具
  • 思想：沒有銀彈（無法迴避、輕易解決所有問題）；重視人的作用
  • 總結：追求生產力最大化；現代結構化/面向物件程式設計廣泛使用；重視過程的作用
• 90s：
  • 虛擬計算機：全球資訊網
  • 軟體抽象實體：面向物件分析與設計方法
  • 主要現實問題：大規模軟體
  • 技術：OO方法（設計模式、原則）；軟體體系結構；人機互動；需求工程；軟體複用（框架、構件）；web開發
  • 開發：過程模型RUP；過程改進；開源軟體
  • 思想：重視最佳實踐方法
  • 總結：企業為中心的大規模軟體開發；追求快速開發、可變更新和使用者價值；Web應用出現
• 00s：
  • 虛擬計算機：嵌入式裝置、移動端
  • 軟體抽象實體：OO改進，UML
  • 主要現實問題：基於internet應用；面向消費大眾
  • 開發：敏捷方法
  • 總結：大規模Web應用；大量面向大眾的Web產品；追求快速開發、可變更新、使用者價值和創新

第四章

團隊特徵

• 共同目標
• 共擔責任
• 技能互補
• 明確結構

幾種團隊結構

專案質量保障有哪些措施

• 軟體開發過程不可見+越晚發現缺陷、修復代價越高 → 質量保證活動要貫穿整個開發過程獨立、持續地進行
• 評審：需求評審、體系結構評審、詳細設計評審、程式碼評審
• 度量：需求度量、設計度量、程式碼獨立、測試度量
• 整合測試 測試度量

實驗中如何進行配置管理活動

1. 標識配置項（有哪些需要儲存的管理，設定ID，說明特徵，如生產者，基線建立時間，使用者等）
2. 版本控制（版本號）
3. 變更控制（發生變更時需要提交請求、評估、決策、執行等）
4. 配置審計（定期進行，驗證完整性、正確性，通常在交付or發行前、開發結束後或維護工作中）
5. 狀態報告
6. 軟體釋出管理

名詞：配置項

置於軟體配置管理之下的軟體配置的各組相關專案，包括各類管理文件、評審記錄雨文件、軟體文件、原始碼和可執行檔案、執行所需的系統軟體和支援軟體以及有關資料。

（複習提綱無這個）

第五章

名詞：需求

1. 使用者為了接解決問題或達到某些目標所需要的條件或能力
2. 系統或系統部件為了滿足合同、標準、規範或其它正式文件所規定的要求而需要具備的條件或能力
3. 對1或2中的一個條件或一個能力的一種文件化表述

需求層次/型別

https://www.cnblogs.com/cpaulyz/p/12470218.html

第七章

為什麼需要需求規格說明？

• 軟體開發過程中會將開發任務細分為多個子任務分配給不同的人員，分解的子任務之間需要相互溝通和交流。

• 子任務和人員間存在錯綜複雜的關係，存在大量溝通與交流，所以軟體系統開發中需要編寫多種不同型別的文件來針對專案中需要進行廣泛交流的內容。

• 用例文件以使用者的角度以用例文字來描述系統和外界互動；需求規格說明文件從軟體產品角度以系統級需求列表方式描述系統解決方案

對給定的需求示例，判定並修正其錯誤

主要考慮需求書寫要點

• 使用使用者術語

  • 不要使用“類、函式、引數、物件”等計算機術語

• 可驗證

  • 不要用模糊和歧義詞彙
  • R1：使用者查詢介面應該友好 x
  • R1：使用者完成任何一個操作滑鼠點選次數都不能超過5次 √

• 可行性

  • 技術上、成本上

對給定的需求示例，設計功能測試用例

第八章

名詞：軟體設計

• 軟體設計指軟體實現的規格說明，也指產生這個規格說明的過程
• 軟體設計是一份軟體設計工程師創造的設計規格說明，包含軟體設計描述和軟體原型，保證軟體能夠滿足需求規格，在一定的時間、費用、人員等限制條件下能夠將軟體部署在一定的物理環境裡，達到業務目標。

• 工程設計和藝術設計都很重要。既要用系統化的方法構造軟體內部結構，進行折中的設計策劃，也要從藝術人員角度出發，注重效率和優雅。
• 設計過程是演化和迭代的
• 軟體設計是問題求解和決策的過程；問題空間是使用者的需求和專案約束，解空間是軟體設計方案。這個過程叫決策。

軟體設計的核心思想是什麼？

• 主要思路：分而治之
• 核心思想：分解、抽象
  • 分解：橫向上將系統分割為子系統以及子系統之間的聯絡
  • 抽象：縱向上分離介面和實現

軟體工程設計有哪三個層次？各層的主要思想是什麼？

• 高層設計，反映軟體高層抽象的構建層次，描述高層結構、關注點和設計決策，主要是部件、連線件、配置

• 中層設計，關注構成元件的模組劃分、匯入匯出、過程之間呼叫關係、類之間協作（模組化、資訊隱藏、OO原則）

• 底層設計，深入模組和類內部，關注資料結構、演算法、型別、語句、控制結構等（程式碼設計）

• 體系結構設計——高層和部分中層

• 詳細設計——中層和部分底層

• 構造階段——部分底層

第九、十章

體系結構的概念

軟體體系結構 = 部件 + 連線件 + 配置

• 部件：承載系統主要功能
• 連線件：定義部件間互動（和部件平等）
• 配置：定義了部件和連線件之間的關聯

一個軟體系統的體系結構定義了系統的計算部件和部件之間的互動

四種體系結構的風格的優缺點

• 主程式/子程式
  • 上層呼叫下層，下層不可呼叫上層；單執行緒；上層轉移控制權
  • 優點：流程清晰，易於理解；強控制性
  • 缺點：強耦合，依賴互動方的介面規格，難以修改和複用；限制資料互動，可能產生公共耦合、
• 面向物件風格
  • 物件隱藏內部資料，提供對外介面服務；通過方法呼叫來連線；物件維護自身資料一致性和完整性；自治單位
  • 優點：內部實現可修改；易開發、易理解、易複用
  • 缺點：介面耦合性；標識耦合性（需要有互動物件的標識）；OO的副作用（如重入問題）
• 分層
  • 下層為上層提供服務，上層呼叫下層；層次之間遵守協議；禁止跨層次連線；禁止逆向連線
  • 優點：設計機制清晰，易於理解；支援並行開發；可複用性、內部修改性
  • 缺點：互動協議難以修改；禁止跨層呼叫，可能會有冗餘呼叫而效能損失；難以確定層次數量和粒度
• MVC
  • 使用者行為要通過控制層
  • 優點：易開發性；檢視、控制在開發中易修改性；多檢視，適用web開發
  • 缺點：複雜；模型修改難（檢視和控制都依賴於它）

體系結構設計的過程

1. 分析關鍵需求和專案約束
2. 選擇合適的體系結構風格
3. 進行體系結構邏輯（抽象）設計
4. 根據邏輯設計進行體系結構物理（實現）設計
5. 完善體系結構設計
6. 新增構件介面
7. 迭代3~7

包設計原則

• 內聚
  • 共同封閉原則 CCP
    • 一起修改的類放在一起
    • 越大越好
    • 早期，對開發者而言
  • 共同重用原則 CRP
    • 一起被重用的放在一起
    • 越小越好
    • 後期，對重用者
  • 重用等價釋出原則 REP
    • 包的目的是給人別人重用
    • 重用的粒度就是包的粒度
• 耦合
  • 無環依賴原則 ADP
    • 包的依賴結構是一個有向無環圖
    • 抽取公共依賴or抽取介面
  • 穩定依賴原則 SDP
    • 依賴關係隨著穩定的方向
    • 依賴穩定的包，穩定性 = 依賴別人 / （依賴別人+別人依賴）
  • 穩定抽象原則 SAP
    • 穩定的包應該是抽象的，不穩定的包是具體的

體系結構構建之間接⼝的定義

p144

整合測試

p177

• 大爆炸式
• 持續整合
  • 自頂向下
    • 一個Driver，下層用stub，不斷用下層模組來代替stub
    • 按深度優先可以首先驗證一個完整的功能需求；利於定位故障
    • 樁開發量大；底層測試不充分
  • 自底向上
    • 用Driver來替代上層
    • 樁工作量小；底層元件開發可以並行；利於故障定位
    • 驅動開發量大；高層測試不充分
  • 持續整合
    • 每次完成一些開發任務後就用開發結果來替代stub測試

十一章

名詞：可用性

衡量人機互動設計的目標，多維度的質量屬性

• 易學性：新手使用者容易學習；完全沒有培訓的使用者完成特定任務所需的時間
• 效率：熟練使用者完成特定任務需要的時間
• 易記性：以前使用過系統的使用者完成特點任務需要的時間
• 出錯率：使用者使用系統時犯多少錯、錯誤多嚴重、能否從錯誤中容易地恢復
• 主管滿意度：使用者體驗，調查問卷

人機互動三因素

1. 人
   • 精神模型
     • 使用者總是看到自己想看的
     • 精神模型就是人機互動時頭腦中的人物模型。使用者識別影象，根據隱喻將控制元件和熟悉事務聯絡起來。
   • 差異性
     • 不同群體的任務模型不同，比如新手使用者、熟練使用者、專家使用者
     • 為不同使用者群體提供差異化的互動機制。比如為新手提供GUI，為專家提供命令列、快捷方式、熱鍵
2. 計算機
   • 視覺化設計
     • 不要暴露內部設計
     • 展示細節
3. 互動
   • 導航
     • 為使用者提供完成任務的入口，好的導航符合精神模型
     • 選單導航、快捷方式導航、列表導航、狀態列導航、按鈕導航
   • 反饋
     • 對使用者行為進行反饋，讓使用者意識到行為的後果
     • 聲音、視覺...
   • 互動原則（重點）
     • 簡介設計：圖片比描述文字更清晰。7±2原則，有效表達下越簡潔越好
     • 一致性設計：相似的任務相似的互動；與已有的軟體類似，遵循使用者已有的精神模型
     • 低出錯率設計：避免錯誤操作（disabled button）；錯誤提示；故障恢復手冊
     • 易記性：減少記憶負擔（自動補全、提示）；逐層遞進地展示；直觀的快捷方式（圖片按鈕）；設定有意義的預設值

例⼦**違反了哪些條界⾯設計原則

精神模型、差異性

導航、反饋、協作式設計

第十二章

詳細設計的出發點

• 需求開發的結果（需求規格說明和需求分析模型）
• 軟體體系結構的結果（軟體體系結構設計方案與原型）

職責分配

GRASP職責分配原則

• 資訊專家：

  • 把職責分配給有實現功能必需的資訊的類

• 創造者：

  • 實際應用中，符合下列任一條件的時候，都應該由類Ａ來建立類Ｂ，這時Ａ是Ｂ的建立者：

    a. Ａ是Ｂ的聚合

    b. Ａ是Ｂ的容器

    c. Ａ持有初始化Ｂ的資訊(資料)

    d. Ａ記錄Ｂ的例項

    e. Ａ頻繁使用Ｂ

• 控制器

  • 將處理外部傳來的系統事件資訊的職責分配給一個類

    a. 系統事件的接收與處理通常由一個高階類來代替。

    b. 一個子系統會有很多控制器類，分別處理不同的事務。

協作

每個類/方法的職責有限，物件之間進行協作可以完成更大的的職責

• 從小到大，將物件的小職責聚合形成大職責
• 從大到小，將大職責分配給各個小物件

控制風格

為了完成大職責，需要對職責分配做決策。控制風格決定了決策由誰來做和怎麼做決策。

設計類圖

P203 表12-2

詳細順序圖

P206 表12-3

第十三章

名詞：耦合（結構化設計）

描述兩個模組間關係的複雜程度

名詞：內聚（結構化設計）

一個模組內部的聯絡的緊密性

資訊隱藏的思想

每個模組承擔著一定的職責，對外表現為一份契約，並且在這份契約之下隱藏著只有這個模組知道的設計決策或祕密，決策實現的細節只有模組自己知道

封裝類的職責，隱藏職責的實現；預計將發生的變更，抽象它的介面，隱藏內部實現機制

• 主要祕密：實現的使用者需求
• 次要祕密：實現細節，如資料結構、演算法

兩種常見的資訊隱藏決策

• 根據需求分配職責
• 內部實現機制

第十四、十五章

OO耦合

1. 訪問耦合

   降低方法：

   • 面向介面程式設計
   • 介面分離原則
   • 迪米特法則

2. 繼承耦合

   降低方法：

   • 里氏替換原則
   • 組合代替繼承

模組化原則

1. 全域性變數是危險的

2. 顯示一些

   martin.data["firstname"] = "Martin"; // 不好
   martin.firstName = "Martin"; // 好
   

3. 不要重複

4. 面向介面程式設計

5. 迪米特法則

   不和陌生人說話——引入區域性變數、委託

6. 介面分離原則

   面向最小介面

7. 里氏替換原則

   父類能被子類代替；require no more，promise no less

8. 組合代替繼承

9. 單一職責原則

資訊隱藏原則（接上）

10. 封裝

隱藏內部結構（迭代器）、隱藏內部物件（給副本，不給引用）

11. 許可權最小化原則
12. 開放/關閉原則

對擴充套件開放、對修改關閉；多型增加新型別（變更放在子類中）

13. 依賴倒置原則

改變耦合的方向性；高層依賴介面，底層實現介面；LSP作為保障，實現OCP

第十六章

如何實現可修改性、可擴充套件性、靈活性

介面和實現分離

第十七、十八章

名詞：重構

• 修改軟體系統的嚴謹方法，在不修改外部表現的情況下改進內部結構
• 時機：增加新功能時（完成後、消除新功能帶來的壞味道）；發現缺陷進行修復時；程式碼評審時

名詞：測試驅動開發

• 測試優先的開發，隨著極限程式設計而普及
• 在編寫程式碼前優先完成該段程式碼的測試程式碼，由測試工具自動裝載執行，也可以程式設計師手動執行。完成測試程式碼後，程式設計師再編寫程式程式碼，並在程式設計過程中重複執行測試程式碼，以驗證程式程式碼的正確性。

名詞：結對程式設計

思想：兩個程式設計師挨著坐在一起，共同協作進行軟體構造活動

駕駛員：輸入程式碼

觀察員：評審，考慮戰略性方向

兩個程式設計師經常互換角色

軟體構造包含活動

• 詳細設計
• 程式設計
• 測試
• 除錯
• 程式碼評審
• 整合與構建
• 構造管理

給定程式碼段示例，對其進行改進或者 發現其中的問題

• 易讀性：程式碼縮排；相關邏輯組織在一起（成員變數生命、構造析構、public、private...）；空行分割；命名；註釋
• 易維護：
  • 小型任務：方法的程式碼內聚，恰好完成一個功能與目標
  • 複雜決策：用新的布林變數（多個布林運算）；封裝決策；表驅動
  • 資料使用：命名、全域性變數

契約式設計

思想：在前置條件滿足下開始執行，完成後能滿足後置條件，那麼這個函式或方法就是正確、可靠的

• 異常方式：

  // 前置檢查
  if (...){
      throw new Exception("....");
  }
  // do...
  // 後置檢查
  if (...){
      throw new Exception("....");
  }
  

  測試驅動開發也是一種契約式設計，把契約放在測試用例中

• 斷言方式：

  // 前置檢查
  assert()
  // do...
  // 後置檢查
  assert()
  

防禦式程式設計

思想：與其他方法、作業系統、硬體等外界環境互動時，外界發生錯誤，保護方法內部不受損害

• 異常
• 斷言

相同：

都要檢查輸入引數的正確性

差異：

防禦式程式設計將所有與外界的互動都納入防禦範圍，如IO、有效性等

防禦式程式設計不檢查後置條件，交給使用者自行檢查

設計測試用例

第十九章 軟體測試

黑盒測試

完全基於輸入和輸出資料來判定測試物件的正確性，使用規格說明來設計輸入和輸出

• 等價類劃分：把輸入域劃分為若干部分，從每部分選取少數具有代表性資料作為測試用例
• 邊界值劃分：等價類的邊界
• 決策表
• 狀態轉換

白盒測試

不關心測試物件的規格，按照測試物件內部的程式結構來設計測試用例進行測試

• 語句覆蓋：每條語句都至少執行一次
• 條件覆蓋：每個判斷的結果至少執行一次
  • 和語句覆蓋的區別在於只有if沒有else的情況下，條件覆蓋要都有，語句覆蓋只要單側
• 路徑覆蓋：每條路徑至少執行一次

第二十、二十一章

開發可維護軟體的方法

• 考慮軟體的可變更性
  • 需求分析時候，分析需求的穩定性，預測可能發生的變化
  • 設計時，使用資訊隱藏，OCP等方法
• 為降低維護難度而開發
  • 技術文件
  • 程式碼可讀性
  • 維護需求跟蹤鏈 “需求←→設計←→編碼←→測試”
  • 維護迴歸測試集線

演化式生命週期模型

包括初始開發、演化、服務、逐步淘汰、停止五個階段

• 初步開發：第一個版本，重要工作是建立一個好的軟體體系結構

• 演化：新增需求、變更需求、修改缺陷

  ↓轉換

  • 喪失可演化性
  • 沒有業務價值
  • 競品

• 服務：仍被部分使用者使用，但不是重點。週期性修復bug、少量需求增量

• 逐步淘汰：不維護

• 停止：使用者不再使用

逆向工程

處理遺留軟體時，可能是一個沒有任何文件和源程式的軟體，這時候就需要逆向工程

思想：抽取軟體系統的需求與設計而隱藏實現細節，然後在需求和設計的層次上描述軟體系統，以建立對系統更加準確和清晰的理解

再工程

逆向工程是理解軟體，而不修改軟體，再工程是對軟體修改，而不花大力氣理解軟體，因此在處理遺留軟體時，需要逆向工程前導。

檢查和改造一個目標系統，用新的模式及其實現來複原該目標系統。目的是對遺留軟體系統進行在開發，用新技術來改進。

已有系統 （逆向工程）→ 抽象檢視 （再工程）→ （正向工程）→ 再工程系統

第二十二、二十三章

構建-修復模型 build-fix

構建第一個版本 → 修復 → 修復 → ... → 維護

• 缺點：
  • 沒有規範，複雜度一旦超出個人控制能力就會失敗
  • 沒有分析需求、考慮體系結構、測試和可維護性，也沒有任何文件
• 適用：
  • 軟體規模很小，幾百行程式，個人開發
  • 對質量要求不高，出錯也無所謂
  • 只關注開發，不用維護

瀑布模型

文件驅動，分為需求分析、軟體設計、軟體構造、軟體測試、軟體交付、軟體維護

• 允許反覆和迭代

• 每個活動結束都需要進行驗證

• 缺點

  • 文件期望過高（成本工作量大、很難為變更的需求建立完備的文件）
  • 線性假設侷限性（需要一定後續工作後才能驗證）
  • 里程碑顆粒過粗（喪失早發現缺陷早修復）

• 使用

  • 需求成熟、穩定
  • 使用技術成熟、穩定，沒有不確定的技術難題，沒有開發人員不熟悉
  • 複雜度適中，不會有太大文件負擔和過粗里程碑

增量迭代模型

需求驅動，迭代式、漸進交付和並行開發

• 第一個迭代完成核心內容，滿足基本需求

• 少量的不確定性和影響不大的變更通過迭代的方式加以解決

• 優點

  • 迭代式，符合軟體開發實踐
  • 漸進交付，加強使用者反饋
  • 並行開發，縮短軟體開發時間

• 缺點：需要一個完備、清晰的專案前景

• 適用性：大規模軟體系統開發

演化模型

和增量迭代模型類似，不同在於模糊了維護和新開發的界限

• 優點：同上
• 缺點：在前代基礎上修改和擴充套件，容易讓後代忽略分析和設計工作，變成build-fix
• 適用：不穩定領域的開規模軟體開發

原型模型

• 拋棄式原型：解決不確定性，用於建立需求，用完拋棄

• 演化式原型：成為產品的一部分，必須有很好的質量

• 優點：

  • 加強了與客戶、使用者的交流
  • 適用於非常新穎的領域，因為這些領域有不確定性

• 缺點：

  • 原型開發成本時間高
  • 很多時候不捨得拋棄“拋棄式原型”，使得質量差的程式碼進入產品

• 適用：有大量不確定性的新穎領域

螺旋模型

風險驅動，充分利用原型方法解決風險

思想：儘早解決比較高的風險，如果無法解決，那麼早發現比專案結束時再發現好，至少損失少得多

分為制定計劃、風險評估、實施工程、客戶評估四個象限，開發階段是瀑布式的，風險分析是迭代的

• 與原型模型相比，原型只解決需求不確定性，螺旋模型還解決專案開發中常見的各組型別風險
• 優點：降低風險
• 缺點：
  • 同原型
  • 模型過於複雜，不利於管理者依據其組織軟體開發活動
• 適用：大規模高風險軟體開發

Rational 統一過程模型 RUP

四個階段：初始、細化、構造、交付

核心過程工作流：商業建模，需求、分析和設計、實現、測試、部署

核心支援工作流：配置和變更管理、專案管理、環境

• 優點：
  • 吸取和借鑑實踐方法
  • 可以進行裁剪，適用面廣
  • 有工程工具支援
• 缺點：
  • 沒有考慮交付後的維護問題
  • 裁剪和配置困難
• 適用：
  • 重量級/輕量級