作業: 開發反覆計劃
這項作業說明如何透過 定義範圍、評估準則、活動,以及指定反覆作業的職責,來製定反覆作業計劃。
規範: 專案管理
目的

開發包含下列項目的反覆計劃:

  • 作業及責任指派的詳細工作細部結構
  • 跨反覆作業里程碑與可交付時間
  • 反覆評估準則
關係
主要說明

反覆作業本身是一組計時的作業,只專注於產生執行檔。除了最後的轉換反覆作業外,所有轉換反覆都是臨時的產品而已,產生這些轉換反覆的原因是要強制注意移轉風險,並驅使專案成功交付。執行檔可交付作業的焦點,是強制幾乎連續的整合,並使專案提早處理技術上的風險,以降低附加的風險。

重複代表重做(現有工作成果)特定的數量,以及對重做的態度變更。簡而言之,就是必須重做相當的數量才能提交品質良好的產品:藉由在不會耗費過高成本,且容易納入變更時進行變更,來建置臨時的產品,以及提早且經常評估產品架構的穩定性,以取得品質良好的最終產品。

步驟
決定反覆範圍
目的 選取執行反覆時,應考慮的一組使用案例或情境。
選取執行反覆時,必須處理的一組非功能方面的需求。 
準則: 反覆計劃 

反覆的範圍是由 4 個因素決定:

  • 專案的最高風險
  • 系統需要的功能
  • 在「專案計劃」中分配給反覆作業的時間
  • 階段及階段特定的目標(請參閱概念:階段

在反覆作業的起始規劃中,要選取足夠的工作來填滿針對反覆作業規劃的時間,雖然「專案管理人員」可以有一些寬容時間來涵蓋資源限制以及在開發「反覆計劃」時的其他技術方面的考量。很明顯的,已針對上一個反覆階段規劃,但尚未完成的工作(由於縮減上一個反覆範圍,以符合排程),通常會具有高優先順序。

工作範圍也必須用適宜的方法來驅動,以便在反覆作業期間,將可應用的人員配置層次擴充到最高程度,以完成反覆作業。例如,通常即使有足夠的資源可用,因而針對反覆作業加派一倍的人員,也無法完成一倍的工作。可以有效運用的最高人員數目,是依整體的軟體規模和架構而定,並且可以由諸如 COCOMO II 之類的估算模型提供這項資訊(請參閱 [BOE00])。

反覆作業的實際執行接著會交由計時框管理,亦即範圍和品質(依探查到的問題未更正而言)會做積極的管理,以符合結束日期。

詳述階段中: 

共有三種主要動力會驅使在詳述中,定義反覆作業的目標:

  • 風險
  • 重要性
  • 涵蓋面

定義反覆作業目標的主要動力是風險。您需要愈早開始減輕或消弭風險愈好。這是詳述階段的常見情況,因為在這個階段時,應該要減輕大部分的風險,不過這仍然會是建構作業的關鍵元素,因為某些風險仍然會很高,或發現新的風險。但是由於詳述階段的目標是要建立架構的基準線,因此這裡也需要考慮其他事項,例如確定架構會處理要開發的所有軟體層面(涵蓋面)。這一點很重要,因為架構就會用來進行進一步的規劃:團隊組織、估算需要開發的程式等。

最後,雖然專注於風險管理是很重要的事,但也不可忽視系統的主要任務;解決棘手問題是好事,但在解決問題時不可損害到核心功能:請確定確實有涵蓋系統的主要功能或服務 (重要性),即使那些功能或服務並不會有風險也一樣。

在「風險清單」中,針對損傷力最大的風險,在一些使用案例中指出一些情境,來強制開發小組「正視」該風險。

範例

  • 如果有類似「資料庫 D 可在 OS Y 正確運作」的整合風險存在時,請務必包含一個情境來進行一些資料庫互動,即使是很細微的動作也無妨。
  • 如果有類似「計算飛機航線的時間」的效能風險存在,請務必包含一個情境來納入此項計算,至少要計算最明顯和最常見的案例。

對於重要性,請確定有包括系統提供的最基本功能或服務。 從使用案例中挑出一些情境,來代表最常見的情況、系統最常提供的服務或功能形式。這項努力是由軟體架構文件驅動,提供一組具優先順利的使用案例或使用案例子流程,由軟體 架構師挑選來反映出具有架構重要性的使用案例或情境。

範例

  • 對於電話交換機而言,一般的點對點呼叫是早期反覆作業的明顯必要項目。把這一項做對,要比解決錯誤處理子系統的操作員配置中的迴旋失敗模式更重要。

對於涵蓋面,在逼近詳述階段的尾聲時,包含一些情境來探查 您已經知道需要開發的一些區域,雖然這些區域既不重要,也沒有風險。

建立一次可以處理多個問題的較長、端對端且涵蓋從開始到結束的情境,通常是比較具有經濟效益的做法。

最常發生的情況是情境變得太厚,例如試圖涵蓋太多不同的層面、變化以及錯誤情況 (請參閱反覆計劃)。

另外在詳述階段中,請記得某些風險可能是人為或程式化本質引起的:團隊文化、訓練、工具選擇、新技術等,並且只要做一遍反覆作業,即可減輕這些風險。

範例

  1. 在用戶端工作站上建立一份訂閱者記錄,以儲存至伺服器上的資料庫中,這包括使用者對話框,但不包括所有欄位,並且假設沒有偵測到錯誤。
    將一些重要功能和一些整合風險(資料庫及通訊軟體)及整合問題 (處理兩種不同的平台)合併。同時亦強制設計師熟悉新的 GUI 設計工具。最後產生一個原型,以便用來向使用者做示範,以取得意見回饋。
  2. 確定最多可以建立 20,000 個訂閱者,並且在存取一個訂閱者時,最長不可超過 200 毫秒。
    處理一些關鍵效能問題(容量或資料,以及回應時間),若不解決這些問題,將會顯著影響架構。
  3. 復原訂閱者位址變更。
    一項簡單的功能,強制設計師思考有關所有「復原」功能的設計。如此即會向使用者觸發一些推回反應,指出哪些東西在復原時,只需要合理的成本即可達成。
  4. 完成與供應鏈管理相對的所有使用案例。
    詳述階段的目標也要完成需求擷取,也許是依組合擷取。

建構階段中: 

當專案移入建構階段時,風險仍然是一個主要動力,特別是新發現且非預期的風險。不過這時完成使用案例也會開始成為動力。反覆作業可以依特性逐一規劃,請盡量提早完成一些最重要的特性,以便那些特性可以在一個以上的反覆作業中,進行完整的測試。在接近建構尾聲時,全部使用案例的健全性將會成為主要目標。

範例

  1. 實作所有呼叫轉接的變式,包括錯誤的呼叫在內。
    這是一組相關的特性。其中一個特性可能已在詳述階段期間實作,並且會作為其餘開發作業的原型。
  2. 完成所有電話操作員特性,但夜間服務除外。
    這是另一組特性。
  3. 在兩部電腦的設置中,每小時達到 5,000 個交易。
    這會設定在上一個反覆作業期間達到的實際效能所需要的效能(僅 2,357/小時)
  4. 整合「環球資訊系統」的新版本。
    這可能是最小的架構變更,這些是由先前發現的問題所需要的變更。
  5. 修正所有層次 1 和層次 2 問題
    修正在上一個反覆作業期間發現,但沒有立即修正的,並且延遲到目前的問題。

轉換階段中: 

主要目標是完成這一代產品。反覆作業的目標是用修正哪些問題來設定,這裡也會包括對效能或可用性的改善之處。如果必須捨棄特性(或停用)才能及時達到建構尾聲 (IOC 里程碑或測試版)時,若那些特性不會妨礙目前已達成的項目,現在可以完成或啟用那些特性。

範例

  1. 修正在客戶處使用測試版所發現的嚴重性 1 問題。
    可以將品質目標附加到相關的市場可靠性中。
  2. 消弭因為資料不相符,而造成的所有開機毀損。
    這是以品質表示的另一個目標。
  3. 達到每分鐘 2,000 個交易。
    效能調整,包括做一些最佳化設定:資料結構變更、快取及更靈敏的演算法。
  4. 將不同對話框數目縮減 30%。
    縮減視覺雜亂來改進可用性
  5. 產生德文版和日文版。
    由於缺少時間和為了減少重做,因此測試版只提供給使用英文的客戶。
定義反覆評估準則

每一次反覆作業最後都會產生可執行版本。這個版本並不是一般的正式版本品質 (僅最後的轉換反覆例外),但仍然可以用來進行評估。

評估初始階段反覆作業

「初始階段反覆作業」通常都專注於提供產品的概念,並建立取得專案資金核准所需要的支援。因此,「反覆版本」通常是功能方面的證明概念原型,其在使用者介面的表層下,並沒有實際的實作程式碼。評估準則會指向使用者接受度和品質測量。

在某些情況下,關鍵的技術障礙必須先在初始階段就加以克服,才有可能取得產品開發資金;如果是這種情況,評估準則就必須反映這一點。

評估詳述反覆作業

詳述反覆作業會專注於建立穩定的架構。因此,「詳述評估準則」必須專注於評量架構的穩定性。這裡可以使用的測量包括:

  • 介面穩定性(或毀損)
  • 架構的變更率(與架構基準線相比較)
  • 主要功能的效能

主要目標是要確保在建構階段中的變更不會擴散至整個系統,導致過多的重做情況。

評估架構及轉換反覆

建構和轉換反覆會和額外的軟體測試,以及如毀損、問題密度以及錯誤發現率等變更管理維度一起測量。這些反覆作業的焦點是找出錯誤,以加以修正。

發現錯誤的方式有幾種:檢驗及程式碼複查、功能測試、效能測試以及負荷量測試。每一種技術都是為了發現特定的一組問題,並且每項技術各有其重要性。 有關這些技術的特點,會在 Rational Unified Process Test 規範中討論。



定義反覆活動

依據反覆作業的目標,必須選取要在反覆作業期間執行的一組作業。通常每一項反覆作業都會進行軟體生命週期的所有作業的一部分:

  • 選取可實施必要功能的使用案例和情境
  • 研究及記載使用案例行為(或情境)
  • 分析行為,並配置到可提供必要行為的子系統及類別
  • 設計、實作類別與子系統,以及進行單元測試
  • 整合系統並當作一體測試
  • 針對外部版本(alpha、beta 以及通用版),將產品包裝為發行格式,並轉移到使用者環境。

這些作業所執行的測試程度,是視專案的反覆和階段而定。個別規範(需要、分析及設計、測試等)會定義一些一般性工作,這些工作可在流程配置期間,針對組織做進一步調整。

指出會受影響的工作成果和作業

在選取並概略勾勒出要開發的情境或全部使用案例(加上待修正的問題)後,您需要找出哪些工作成果會受到影響:

  • 哪些類別需要修訂?
  • 哪些子系統會受影響,或甚至於要建立?
  • 哪些介面可能需要修改
  • 哪些文件需要更新

然後從程序規範擷取需要進行的作業,並放置在您的計劃中。有些作業只需在一次反覆中做一次 (這裡的範例),有些則需要針對每個類別、使用案例、子系統分別執行一次(範例)。將作業和其明顯的相依關係連接,並配置一些預估的人力。針對程序說明的大部分作業都很小,因此只要一個人就可以完成,或是只需要一小組人在幾小時或少數幾天之內就可以完成。

您很可能會發現在反覆作業中沒有足夠的時間可以完成所有作業。這時並不需要延長反覆作業 (因而會延長最終的交付時間,或是減少反覆作業次數),而是要縮減反覆作業的企圖。視您所在的階段,請將情境設得簡單一點,或縮減或停用特性。

指派職責

定義好反覆作業應做的一組作業後,必須將那些作業指派給個別的專案小組成員。視可用的人員資源以及反覆作業的範圍,那些作業可以委由個體或一個小組完成。審查和檢驗則一定是小組作業。其他諸如編寫使用案例或設計及實作類別等作業,都一定是單獨的作業(只有新進小組成員和作為顧問的資深小組成員搭擋時例外)。

一般而言,每一項工作成果都必須由某個個體負責,即使工作可能是由一個小組完成:

  • 使用案例
  • 子系統
  • 類別
  • 測試及測試計劃
  • 等等。

若沒有一個單一的聯絡點,則很難確保一致性。



主要考量

專案規劃是指專案管理人員將專案的特定交付程序實例化(以及後續的執行管理) (請參閱工作成果:開發程序)。此程序通常稱為程序制定。

「實例化」的程序是指可制定的專案/反覆/活動計劃(其中包括實際專案的實際活動和工作成果)。交付程序可以透過將 Rational Method Composer 的 交付流程匯入  Rational Portfolio Manager (RPM),再複製設定為 isRepeatable 或 hasMultipleOccurences 的活動和作業、建立實際工作成果、指定實際的資源給角色等,來實例化工作。 

詳細資訊