【正文】 1997)中定義了以下形式的重用： 操作重用（ 操作 Reuse） 是復雜操作的重用，如工具性操作或度雜的數(shù)學操作。根據(jù)需要可以產(chǎn)生更詳細的報告。 項目測量示例 系統(tǒng) 級測量 –在 系統(tǒng) 中的數(shù)量 類 /對象 級測量 –在 系統(tǒng) 中的數(shù)量 類 /對象 級測量 –比例和平均值 代碼 測量 –比例和平均值 規(guī)模測量 分析：需求， 行動者， 輸入消息 組件，輸出消息 組件， 輸入 對象 /數(shù)據(jù) 組件，輸出 對象 / 數(shù)據(jù) 組件， Use Case， Use Case 場景 設(shè)計：可執(zhí)行 組件，組件間的 消息，節(jié)點， 節(jié)點間的連接 包，類， 接口 ，操作 ， 屬性 ， 關(guān)系 ，對象，消息，狀態(tài) ， 變換 ， 異常 類， 重用 類 代碼 行數(shù) /系統(tǒng) LOC/類， LOC/操作 LOC 指 NCSS –Nonment Source Statements 復雜性測量 Use Case 場景 /Use Case 泛化的級別水平 類 和接口 /包， 屬性 /類， 操作 /類，關(guān) 系 /類， 發(fā)送 消息 /類， 發(fā)送 消息/操作 ， 參數(shù) /操作 ， 子 類 /超 類 加權(quán)操作 / 類，McCabe Cyclomatic 復雜性 / 操作 ，Halsted 操作 /操作 ，Length * (Fanin * Fanout)^2 重用性測量 重用的模式 ， 重用的 組件 重用的模式 ， 重用的 包， 重用的類 質(zhì)量測量 缺陷 缺陷 缺陷 缺陷 我們的目標是使用 CASE 和其他工具來監(jiān)控。參見 Lorenz 和 Kidd 的 對象 Oriented Software Metrics. 項目測量（ Project Metrics） 提供關(guān)于系統(tǒng)、包、類和其他元素的信息。” 管理測量（ Management Metrics） 提供關(guān)于項目進度、資源和其他管理關(guān)注的要素計劃和實際對比的信息。應該使用 CASE 工具和代碼分析工具來自動進行測量數(shù)據(jù)的收集。 需求模型 分析模型 設(shè)計模型 實現(xiàn)模型 測試模型 關(guān) 鍵 的UML 元素 系統(tǒng)，行動者，Use Case， 迭代 業(yè)務(wù)包 ，類，對象，消息 硬件和軟件配置， 包，類，對象，消息 組件，節(jié)點， 代碼 測試計劃 和 測試用例 工作要點 將 系統(tǒng) 看成黑盒進行建模 在問題域?qū)I(yè)務(wù)元素建模，不涉及實現(xiàn)細節(jié) 為根據(jù)一個特定的實現(xiàn)（如 硬件和軟件配置 ）更新分析模型中的視圖和規(guī)格說明 為發(fā)布環(huán)境的物理元素建模， 代碼 滿足所有需求 單元 (類 /操作 ) 測試 ， 集成 /系統(tǒng) /驗收測試 目標 元素之間弱偶合 強內(nèi)聚 所有 Use Case 和場景都有充分的信息，所有增量 /迭代已計劃 滿足需求的最簡單的業(yè)務(wù) /問題域模型 有充分的信息可以生成代碼或手工編碼 優(yōu)化 組件體系結(jié)構(gòu) –網(wǎng)絡(luò)友好， 代碼 滿足所有需求 充分的測試保證 代碼 滿足所有需求 靜態(tài) /結(jié)構(gòu)性視圖 方塊圖和 Use Case 圖 包 圖 /類 圖 包 圖 /類 圖 組件 圖 /部署圖 /逆向工程 類 圖 動態(tài) /時間相關(guān)的視圖 Use Case 圖 ， 為每個 Use Case 的每個 Use Case 場景 繪制 序列圖 為每個 Use Case場景 繪制 序列圖 ，為每個基于狀態(tài)的類繪制 狀態(tài)圖，為每個復雜的操作繪制 活動圖 為每個 Use Case 場景 繪制 序列圖 ，為每個基于狀態(tài)的類繪制 狀態(tài)圖， 為每個復雜的操作繪制活動圖 根據(jù)需要更新 序列圖 來顯示分布式 消息 工具 ROSE ， 需求 跟蹤 ， 配置管理 ROSE， 需求跟蹤 ，配置管理 ROSE， 需求跟蹤 ，配置管理 ROSE， 需求跟蹤 ， 配置管理，測試 配置管理，測試 關(guān)鍵角色 業(yè)務(wù) /系統(tǒng)分析員 業(yè)務(wù) /系統(tǒng)分析員 程序員 體系結(jié)構(gòu)師，程序員 程序員 /測試員 模型結(jié)束 項目經(jīng)理 ， 體系結(jié)構(gòu)師，客戶 /用戶 項目經(jīng)理，體系結(jié)構(gòu)師，客戶 /用戶 項目經(jīng)理 ，體系結(jié)構(gòu)師 項目經(jīng)理，體系結(jié)構(gòu)師 項目經(jīng)理，體系結(jié)構(gòu)師， 負責驗收的 客戶 /用戶 測量和監(jiān)控 測量（ Metrics） 提供了監(jiān)控進展、進行估計、識別風險和識別高風險復雜實體的定量手段。 基于 RUP 的軟件開發(fā)過程規(guī)范 Draft 1 項目視圖/ 軟件需求規(guī)約包視圖包含所有用例的用例視圖為每個U s e C a s e C o u r s e 繪制序列圖為每個U s e C a s e s 所有C o u r s e 繪制活動圖序列圖和/ 或協(xié)作圖活動圖和狀態(tài)圖Activity StateActivity StateActivity StateActivity StateStateState第四步：實現(xiàn)流程環(huán)境( 軟件和硬件)組件圖/ 部署圖和代碼第三步：設(shè)計流程環(huán)境( 軟件和硬件)更新類圖/ 包圖/ 序列圖/ 協(xié)作圖/ 活動圖/ 狀態(tài)圖系統(tǒng)/ 子系統(tǒng)/ 組件第一步：需求包/ 類/ 對象第二步：分析類模型第五步：測試和部署測試模型構(gòu)造 配置模型配置模型基于 RUP 的軟件開發(fā)過程規(guī)范 Draft 1 這些模型在 RUP 中的關(guān)鍵部分如下表所示。每個 OO 項目 Use Case要收集以下信息：名稱、發(fā)起者、輸入?yún)?shù)、輸出返回值、前提條件 /異常情況、后置條件/異常情況、基本 /樂觀的場景、替代 /悲觀場景、業(yè)務(wù)規(guī)則、測試用例。模型復審應包含對主要的 UML 視圖和問題的簡要評述。所有 UML 視圖和規(guī)格說明應被放置在姓名目錄中，并且使所有項目復審和評論人員可以獲得。 UML 模型是當前模型的位置，例如 XYZ\F:UMLModels\. OO 項目 進度狀態(tài)表 迭代 1樂觀 /簡單 迭代 2正常 /中等 迭代 3悲觀 /復雜 UML 模型 計劃開始日期 修訂的開始日期 實際開始日期 計劃完成日期 修訂的完成日期 實際完成 /復查日期 目前完成百分比（ %） 模型復審日期 構(gòu)造批準日期 備注 UML 模型的復審每兩周進行一次或在每個迭代結(jié)束時進行。每個迭代通常需要 3–4 個星期。 基于 RUP 的軟件開發(fā)過程規(guī)范 Draft 1 Use Case 增量和 Build/Release 迭代 OO 項目 由多個 Use Case 增量組成。它完整地經(jīng)歷整個軟件開發(fā)過程的各個階段，例如對一個 Use Case增量的需求、分析、設(shè)計、實現(xiàn)和測試，得到一個可執(zhí)行的發(fā)布項。 一個 Use Case 場景（ Use Case 場景 ）是一個 Use Case 的一系列交互，例如 樂觀的（簡單）、正常（中等）或悲觀的 (復雜 ) 場景。 需求跟蹤表 (Partial) 需求編號 需求名稱 引用 Use Case 名稱 UML 元素 測試用例 描述 負責人 DepositToSavings Account DepositToSavingsAccount 有良好定義的項目需求的益處有： ? 支持溝通，使項目成員為實現(xiàn)需求而工作 ? 支持定義 Use Case、 Use Case 增量 和 build/release 迭代 (在一個增量內(nèi)的 Use Case 場景 ) ? 支持識別和解決在需求中的不一致性問題 ? 支持創(chuàng)建一個質(zhì)量系統(tǒng)，它完全滿足客戶需求 6 迭代計劃和監(jiān)控 OO 項目 應使用 RUP 中定義的迭代增量軟件開發(fā)過程。這些項目資產(chǎn)必須可被重用。 人員需求和角色指派 對一個 52 周 的項目的按周階段化分示例 角色 先啟階段 –5 周 精化階段 –16 周 構(gòu)建階段 –26 周 產(chǎn)品化階段 –5 周 項目經(jīng)理 1–John Smith 1–John Smith 1–John Smith 1–John Smith 體系結(jié)構(gòu)師 1–??? 1–??? 1–??? 1–??? 客戶 /用戶 1–??? 1–??? 1–??? 1–??? 業(yè)務(wù) /系統(tǒng)分析員 3–???， ???， ??? 3–???， ???， ??? 3–???， ???， ??? 0 開發(fā)人員 /程序員 0 3–???， ???， ??? 3–???， ???， ??? 1–??? QA 測試員 0 1–??? 1–??? 1–??? 其他 TBD TBD TBD TBD 合計 6 10 10 5 為項目成員規(guī)定良好定義的角色的益處有： ? 支持有效的計劃和決策 基于 RUP 的軟件開發(fā)過程規(guī)范 Draft 1 ? 支持溝通，使項目成員知道他們的職責 ? 通過不同的項目成員從不同角度工作，支持創(chuàng)建一個質(zhì)量系統(tǒng) 項目 資源 資源必須被識別、預算和控制 —— 包括人力資源和其他資源，如工具、設(shè)備等。 QA 測試員 –創(chuàng)建測試計劃、測試用例、測試過程和相關(guān)的測試文檔。 業(yè)務(wù) /系統(tǒng)分析員 –領(lǐng)導和協(xié)調(diào)在業(yè)務(wù)建模、需求、和分析模型工作中的需求收集、 USE CASE 建模和類建模。創(chuàng)建用來形成報告和生成代碼的 CASE工具腳本。負責保證 UML 模型的正確性和完整性。提供過程環(huán)境（硬件和軟件配置清單）和實現(xiàn)模型（組件圖和部署圖）。 體系結(jié)構(gòu)師 –監(jiān)督項目的技術(shù)方面，包括整個系統(tǒng)的 體系結(jié)構(gòu) 、組件、組件的接口和組件之間的通訊。軟件從體系結(jié)構(gòu)基線發(fā)展到可以向用戶交付的程度 將軟件交到用戶的手中 產(chǎn)品 項目視圖文檔、 USE CASE 列表、項目詞匯表、商業(yè)案例（商業(yè)環(huán)境、成功標準、贏利預測）、風險評估、項目計劃、業(yè)務(wù)模型 USE CASE 模型、非功能性需求、軟件體系結(jié)構(gòu)、體系 結(jié)構(gòu)原型、迭代計劃、開發(fā)案例、初步的用戶手冊 UML 模型（需求、分析、設(shè)計、實現(xiàn)、測試）、每次迭代的交付項（ Build/Release） 推向市場或交給用戶的軟