RUP2 第3章 靜態結構：流程描述

[mic64]

第3章 靜態結構：流程描述
本章描述如何表示Rational 統一流程。我們將介紹工作人員、活動、工作成
果、工作流程和其它描述流程會用到的元素。
Rational 統一流程的模型
流程描述誰做了什麼、如何做和什麼時候做。Rational 統一流程主要是用下
面四種模型元素（Model Element）表示：
.. 工作人員：誰（Who）
.. 活動：如何（How）
.. 工作成果：什麼（What）
.. 工作流程：何時（When）
前三個元素如圖3－1 所示，而圖3－5 則表示工作流程。
圖 3-1 工作人員、活動和工作成果
工作人員
流程的中心概念在工作人員。工作人員定出個人或團隊的行為和責任。工作
人員所執行的活動代表行為，而且每位工作人員都會與一群凝聚在一起的活動有
關。”凝聚”的意思是說這些活動最好由同一個人執行。工作人員產生、修改或
控制的工作成果代表工作人員的責任（譯註：簡單的說活動＝行為，工作成果＝
責任）。
可以把工作人員想成專案開發過程種成員戴的”帽子”。一個人可以戴很多
頂帽子。人和帽子的差異很重要，因為很自然地我們會把工作人員當作一個人或

團隊，但是在Rational 統一流程中，工作人員代表角色（Role），角色定義一個人
如何完成工作。一位工作人員可以扮演一個或多個角色，也是一組工作成果的擁
有者。我們也可以將工作人員視為一場戲中的角色（Part），一個角色（Part）可
以由許多演員來扮演（譯註：有的人可能跟譯者一樣，覺得UML 中的參與者怎
麼和Rational 統一流程中的工作人員好像。UML 把參與者定義成使用者在使用系
統時，所扮演的一個角色，換句話說，參與者代表系統外面的一個角色；另一方
面，如果把軟體開發流程當作企業流程Business Process，那麼我們可以把企業參
與者Business Actor 當作企業外部的角色，而把工作人員視為企業內的角色，換
言之，就是企業內部的參與者。在第八章企業模型工作流程中，提到如何把企業
模型Business Model 變成系統模型System Model，其中一種轉換方式就是直接把
企業物件模型中的企業工作人員變成系統模型中的候選參與者）。
下面是一些工作人員的例子：
.. 系統分析師（System Analyst）：
扮演系統分析師（System Analyst）的人，負責帶領或協調引導需求或使
用案例模型製作（Use-case Modeling）。這些工作需要描繪系統功能和限
定系統範圍。
.. 設計師（Designer）
扮演設計師（ Designer ） 的人得定義一個或多個類別的責任
（Responsibility）、運作（Operation）、屬性（Attribute）和關係（Relationship），
還要決定如何調整它們以符合實作環境需要。
.. 測試設計師（Test Designer）
扮演測試設計師（Test Designer）的人負責規畫、設計、實作和評估測試，
包括產生測試計畫（Test Plan）與測試模型（Test Model）、實作測試程
序（Test Procedure）和估計測試範圍、結果與有效性（Effectiveness）。
請注意工作人員不是一個人，而是描述企業中一個人應該如何行動和每個人
的責任。軟體開發組織中每個成員都戴著不同的帽子，扮演不同角色（Role）13。
從個人對映到工作人員是專案經理（Project Manager）規畫和組織專案成員時該
做的事。我們允許一個人扮演多個工作人員，而且一個工作人員也可以由多個人
扮演。
如圖3－2 例子，Sylvia 一個人可以在早上扮演工作人員：使用案例設計師，
而在下午扮演工作人員：設計審查人員，它們可能負責不同類別或不同設計套件
（Design Package）。
對每位工作人員而言，被指定扮演此工作人員的人應該有擔任此工作人員的
技能。所以Sylvia 應該了解如何設計使用案例，並且知道如何審查設計。
在流程中，工作人員的表示法通常會在前面加上關鍵字工作人員，例如工作
13 然而，我們時常會寫道,”類別X 的設計者做這件事”,此時嚴格說來,我們應該寫成,
“扮演類別X 設計者的人做這件事”。

人員：整合測試人員。附錄A 列出Rational 統一流程定義的所有工作人員。
圖 3-2 人員和工作人員
活動
工作人員擁有活動，活動定義工作人員所執行的工作。活動是工作的單位，
它代表扮演此角色（Role）的人應該完成的工作，活動會對專案產生有意義的結
果。活動有清楚的目標，通常會產生或更新工作成果（例如模型、類別Class 或
計畫）。每個活動都會分配給一位特定工作人員。
活動的詳細程度可能從幾小時到幾天。活動通常會有一位工作人員，也會影
響到一個或幾個工作成果。把活動當做計畫或進度的元素。如果把活動定的太
小，很容易忽略它；可是如果把活動定的太大，進度就變成活動的一部分。
活動可能會重複影響到同一個工作成果好幾次，尤其是從一個反覆到另一個
反覆，改良或擴充系統時更容易發生重複的活動。重複的活動可能由同樣的工作
人員執行，但不一定是同一個人。
以物件導向的術語來說，如果把工作人員當成一個主動物件，那麼工作人員
所執行的活動就是這個物件的操作（Operation）。下面是一些活動的例子：
.. 規畫一次反覆：由工作人員：專案經理執行
.. 找出使用案例和參與者：由工作人員：系統分析師執行
.. 審查設計：由工作人員：設計審查人員執行
.. 執行效能測試：由工作人員：效能測試人員執行
活動表示法通常會在前面加上關鍵字活動，例如活動：找出使用案例和參與
者。從第7 章到第15 章將介紹Rational 統一流程定義的所有活動。

活動的步驟
活動可分解成幾個步驟。步驟有三種：
.. 思考步驟（Thinking Steps）
在這個步驟中，工作人員試圖去了解工作本質、收集並檢查輸入的工作
成果，還要規劃結果。
.. 執行步驟（Performing Steps）
在這個步驟中，工作人員產生或更新某些工作成果。
.. 審查步驟（Reviewing Steps）
在這個步驟中，工作人員檢查結果是否符合準則（Criteria）。
執行每個活動時，並不是所有步驟都要執行。步驟是可選擇的。例如，活動：
找出使用案例和參與者可以分解成下面七個步驟：
1. 找出參與者。
2. 找出使用案例。
3. 描述參與者和使用案例間如何互動。
4. 把使用案例和參與者放入套件中。
5. 用使用案例圖表現使用案例模型。
6. 調查使用案例模型。
7. 評估結果。
搜尋部分（步驟一到步驟三）需要思考；執行部份（步驟四到步驟六）記錄
使用案例模型（Use-case Model）；審查部分（步驟七）由工作人員估計結果，以
評估完整性（Integrity）、堅固性（Robustness）、可理解性（Intelligibility）或其它
品質。
工作成果
工作成果分成輸入工作成果和輸出工作成果。它是流程產生、修改或使用的
資訊。工作成果代表專案的實際產品：也就是在產生最終產品的過程中，專案所
產生或使用的東西。工作人員把工作成果當成活動的輸入資訊，也把工作成果當
作輸出資訊或結果。以物件導向術語來說，工作成果是活動的參數（Parameter），
就像活動是主動物件（工作人員）的操作（Operation）一樣。
工作成果有許多不同形式：
.. 模型，例如使用案例模型（Use-case Model）或設計模型（Design Model）
.. 模型元素（Model Element）－也就是模型中的元素，例如類別、使用案
例或子系統

.. 文件，例如企業案例（Business Case）文件或軟體架構文件（Software
Architecture Document）
.. 原始碼（Source Code）
.. 可執行檔（Executable）
工作成果是Rational 統一流程用的術語，其它流程可能用工作產品（Work
Product）或工作單位（Work Unit）等等。交付產品（Deliverable）代表那些最後
交給客戶或使用者的工作成果集合。圖3－3 表示Rational 統一流程的一些工作
成果。
工作成果可能由其它工作成果組成。例如，設計模型（Design Model）包含
許多類別；軟體開發計畫（Software Development Plan）包含其它計畫：人員配置
計畫、階段計畫、測量計畫和反覆計畫（Iteration Plan）等等。
工作成果很有可能會有版本控制（Version Control）或組態管理（Configuration
Management）。如果無法對內部、基本的工作成果給版本，可以只針對作為外部
容器的工作成果給版本。例如，你只控制整個設計模型（Design Model）或套件
（Package）版本，而無法控制個別類別版本。
通常，工作成果不是文件。許多流程過度專注在文件上，尤其是紙上文件。
Rational 統一流程並不鼓勵系統化產生紙上文件。專案管理工作成果最有效率、
最實際的方法是利用產生或管理工作成果的工具維護它們，必要時再從工具即時
產生文件（或快照）。
圖 3-3 Rational 統一流程的主要工作成果
你應該將工作成果的內容和工具交給相關的當事人，而不是在紙上寫寫。這
種方法確保傳達的是最新、實際的專案工作資訊，而且不需額外的功夫就可以產
生資訊。

下面是一些工作成果的例子：
.. Rational Rose 裡的設計模型（Design Model）（譯註：Rational Rose 為視覺
式模型製作軟體Visually Model Software）
.. Microsoft Project 裡的專案計畫
.. ClearQuest 裡的瑕疵（譯註：CleaseQuest 產品主要用來做組態與變動管
理）
.. Requisite Pro 裡的專案需求資料庫（譯註：Requisite Pro 產品主要用來做
需求管理）
某些工作成果必須用純文字文件表示，例如專案的外部意見，有時候純文字
是描述資訊的最好方法。
為了讓所有資訊都由特定人員負責，縱使一個人擁有工作成果，其它人可能
使用或有權更改這份工作成果，工作成果的責任最好還是只屬於一位工作人員。
工作成果表示法通常是在前面加上關鍵字工作成果，例如工作成果：使用案
例分鏡腳本（Use Case Storyboard）。
報告（Report）
模型和模型元素（Model Element）可能會有相關的報告（Report）。報告是用
工具粹取出來的模型和模型元素資訊。例如代表審查工作的工作成果或一組工作
成果的報告。跟正規工作成果不一樣，報告沒有版本控制（Version Control）。你
可以在任何時候用工作成果產生報告。
工作成果輯（Artifact Set）
Rational 統一流程的工作成果主要有五種資訊集合：
.. 管理輯（Management Set）
.. 需求輯（Requirement Set）
.. 設計輯（Design Set）
.. 實作輯（Implementation Set）
.. 配置輯（Deployment Set）
管理輯（Management Set）包含所有跟軟體公司和專案管理相關的工作成果：
.. 規劃用的工作成果，例如軟體開發計畫（Software Development Plan）、
企業案例（Business Case）、專案所用的流程實例（開發案例Development
Case）等等
.. 作業用的工作成果，例如發行版本（Release）描述、狀態評價、配置文
件和瑕疵資料

需求輯（Requirement Set）包含所有跟開發軟體系統的定義相關的工作成果：
.. 願景（Vision）文件
.. 用關係人的需要（Need）、使用案例模型（Use-case Model）和輔助規格
（Supplementary Specification）來表示需求
.. 企業模型（Business Model）：如果需要了解系統支援的企業流程（Business
Process）的話
設計輯（Design Set）包含對想建立系統的描述：
.. 設計模型（Design Model）
.. 架構描述
.. 測試模型（Test Model）
實作輯（Implementation Set）包含：
.. 原始碼（Source Code）和可執行檔（Executable）
.. 相關資料檔或產生資料檔所需的檔案
配置輯（Deployment Set）包含所有的推出資訊，包括：
.. 安裝材料
.. 使用者文件
.. 訓練教材
在反覆式開發流程（Iterative Development Process）中，工作成果不是在某個
階段產生、完成或固定不再改。相反地，這五種資訊輯在開發週期會不斷演
進、成長，就跟圖3－4 呈現的狀況一樣。附錄B 列出所有Rational 統一流
程定義的工作成果，並且按工作流程加以整理。
工作流程
單單列出所有工作人員、活動和工作成果並不足以構成流程。我們需要能夠
描述活動順序並顯示工作人員互動的方法，而且所描述的活動順序要能產生有價
值的結果。工作流程就是一連串的活動，而且這些活動會產生可測量價值的結
果。以UML 的術語來看，工作流程可以用順序圖（Sequence Diagram）、合作圖
（Collaboration Diagram）和活動圖（Activity Diagram）表示。本書用活動圖表示
工作流程。圖3－5 是一個工作流程的例子14。
14 嚴格說來，我們的核心工作流程是工作流程類別，會有許多可能的工作流程實例屬於這
些類別。

圖 3-4 成長中的資訊輯
有時我們不太可能表達出活動之間的相依性（Dependency）（也不實際）。尤
其如果兩個活動包含相同工作人員或個人時，它們之間常有比看起來更緊密的結
合。人不是機器，而且工作流程也無法逐字解釋成需要人準確且機械化遵循的程
式。
有許多方法可以整理工作流程的一連串活動。我們把Rational 統一流程的工
作流程組織如下：
.. 核心工作流程（Core Workflow）
.. 工作流程細節（Workflow Details）
.. 反覆計畫（Iteration Plan）
核心工作流程（Core Workflow）
Rational 統一流程有九個核心工作流程（Core Workflow），把所有工作人員
和活動，從邏輯依不同範圍或原則分成幾類（見圖3－6）。流程的核心工作流程
包含六個核心工程工作流程和三個核心支援工作流程。

圖 3-5 工作流程範例
核心工程工作流程如下：
.. 企業模型工作流程（Business Modeling Workflow）
.. 需求工作流程（Requirements Workflow）
.. 分析與設計工作流程（Analysis and Design Workflow）
.. 實作工作流程（Implementation Workflow）
.. 測試工作流程（Test Workflow）
.. 配置工作流程（Deployment Workflow）

圖 3-6 九個核心工作流程
核心支援工作流程如下：
.. 專案管理工作流程（Project Management Workflow）
.. 組態管理與變動管理工作流程（Configuration and Change Management
Workflow）
.. 環境工作流程（Environment Workflow）
雖然六個核心工程工作流程是用傳統瀑布式（Waterfall）流程的循序式階段
名稱來命名，但是看完第4 章你將知道反覆式流程（Iterative Process）的階段和
循序式階段是不同的，而且在整個生命週期，這些工作流程會不斷重複。一個專
案實際、完整的工作流程是由這九個核心工作流程（Core Workflow）交錯組成，
而且在反覆中，這些工作流程會一再重複，只是每次強調的重點不同。從第7
章到第15 章會更詳細介紹核心工作流程。
工作流程細節（Workflow Details）
每個核心工作流程（Core Workflow）都涵蓋許多範圍。為了把它們進一步分
解，Rational 統一流程用工作流程細節（Workflow Details）表示一群關係密切的
特定活動。例如一起執行或用循環方式執行的一群活動；在同一工作地點、同一
群人完成的活動；某些活動會產生一個有趣的中間結果。此外，工作流程細節也
會顯示出資訊流（Information Flows）（活動的輸入工作成果和輸出工作成果），說
明活動和工作成果是如何互動的。

反覆計畫（Iteration Plan）
反覆計畫（Iteration Plan）是流程的另一種表示法。它描述流程中標準反覆
發生的事。事實上，它非常近似於工作流程應該處理的事。你可以將它視為某個
反覆的流程實例、選擇在反覆執行的活動或根據需要重複這些活動。有無限種方
法可以完成流程實例。Rational 統一流程包含標準反覆計畫的描述。這些描述主
要是為了教學目的，我們在第16 章可以看到一些例子。
額外的流程元素
工作人員、活動（以工作流程加以組織）和工作成果表現Rational 統一流程
的靜態結構骨幹。其它附加在活動或工作成果的元素讓流程更容易被瞭解和使
用，而且對採用流程的人來說也提供更容易了解的說明。這些額外的流程元素有：
.. 指引
.. 範本（Template）
.. 工具指導員
.. 概念
這些額外的元素用來加強主要元素，如圖3－7 所示。
圖 3-7 額外的範本、工具指導員和指引

指引
因為活動和步驟只作為需要完成事情的一個參考，所以它們通常很簡單並且
點到為止。而指引不但要讓尋求協助的新手覺得有用，還要對有經驗的人扮演提
醒者的角色。
指引附加在活動、步驟或工作成果上。指引有如規則、忠告或有啟發性的方
法，支援活動和步驟。指引描述有良好格式的工作成果，描述的重點在它們特殊
的地方，例如什麼因素構成好的使用案例和類別。指引也描述產生工作成果的技
術、從一個工作成果到另一個工作成果的轉換過程或統一模型語言（UML）的使
用方法。指引也用來評估工作成果品質－搭配工作成果的檢核清單（Check List）
－或審核活動。下面是指引的種類：
.. 工作指引（Work Guidelines），指示活動如何進行，特別針對群體活動；
例如：
－審核工作指引（Work Guidelines）
－使用案例研討會指引
.. 工作成果指引（Artifact Guidelines）配合特定的工作成果，描述如何開
發、評估和使用此工作成果，例如：
－模型製作指引（Modeling Guidelines），描述有良好格式的模型元素
（Model Element），例如使用案例、類別或測試案例（Test Case）
－程式指引（Programing Guidelines），例如C++或Ada，描述有良好格式
的程式
－使用者介面指引（User Interface Guidelines）
－產生特定工作成果的指引，例如反覆計畫（Iteration Plan）的風險清單
（Risk List）
－作為審查或工作人員檢驗活動是否已經完成的檢核點（Checkpoint）
有些指引需要根據組織或專案的不同加以改良或特殊化，以滿足專案特性
（Feature），例如使用特殊的技術或工具。下面是一些這種指引的例子：
.. 使用者介面指引（User Interface Guidelines），例如描述一個專案特殊的
視窗形式：調色盤、字形、圖示庫等等。
.. 程式指引（Programing Guidelines），例如描述專案特殊的命名習慣。
範本（Template）
範本（Template）是工作成果的模型或原型（Prototype）。跟工作成果相關的
範本可能有一個或多個，它們產生相對應的工作成果。範本會連結到它所使用的
工具上。例如：

.. Microsoft Word 範本，用來產生文件或報告
.. Microsoft Word 或FrameMaker 的SoDA 範本，可以從一些工具（例如
Rational Rose、RequisitePro 或TeamTest）取出資訊
.. 流程中不同元素用的Microsoft FrontPage 範本
.. 產生專案計畫的Microsoft Project 範本
跟指引一樣，不同組織在使用範本（Template）前可能會先把它加以客製化
（Customization），例如加入公司商標、專案辨識證明或專案特定組態資訊等等。
工具指導員
活動、步驟和相關指引提供一般性指導給採用流程的人。如果想要更進一步
的話，工具指導員是提供額外指導的方法，它會一步一步執行步驟展示如何使用
特殊的軟體工具。Rational 統一流程提供工具指導員，把活動和相關工具結合起
來，例如Rational Rose、RequisitePro、ClearCase、ClearQuest 和TestStudio。工具指
導員幾乎完全把流程和工具的相依性（Dependency）封裝起來，讓活動不受工具
細節限制。開發組織可以延伸工具指導員概念，提供其它的工具指導員。
概念
主要的概念，例如反覆、週期、工作成果、風險和效能測試等等，之前都已
經分別介紹過了，它們通常會附在最合適的核心工作流程（Core Workflow）上。
還有許多其它概念也會在本書一一介紹。
流程框架（Process Framework）
從結構來看，Rational 統一流程形成一個流程框架（Process Framework）。為
了改良或讓流程符合組織需要，工作人員、工作成果、活動、指引、概念和工具
指導員都是可增加或被取代的元素。開發的方法在第17 章環境工作流程
（Environment Workflow）中描述。
摘要
.. Rational 統一流程的模型以三種基本實體為基礎：工作人員、活動和工
作成果。
.. 工作流程把活動和工作人員連在一起，產生有價值的結果。
.. 指引、範本（Template）和工具指導員提供一份詳細指導給採用流程的
人，讓流程的描述更完整。

.. Rational 統一流程是一種流程框架（Process Framework），它的組織方式
讓我們可以自行設定靜態結構的組態。