目的
|
選取執行反覆時,應考慮的一組使用案例或情境。
選取執行反覆時,必須處理的一組非功能方面的需求。
|
準則: 反覆計劃
|
反覆的範圍是由 4 個因素決定:
-
專案的最高風險
-
系統需要的功能
-
在「專案計劃」中分配給反覆作業的時間
-
階段及階段特定的目標(請參閱概念:階段)
在反覆作業的起始規劃中,要選取足夠的工作來填滿針對反覆作業規劃的時間,雖然「專案管理人員」可以有一些寬容時間來涵蓋資源限制以及在開發「反覆計劃」時的其他技術方面的考量。很明顯的,已針對上一個反覆階段規劃,但尚未完成的工作(由於縮減上一個反覆範圍,以符合排程),通常會具有高優先順序。
工作範圍也必須用適宜的方法來驅動,以便在反覆作業期間,將可應用的人員配置層次擴充到最高程度,以完成反覆作業。例如,通常即使有足夠的資源可用,因而針對反覆作業加派一倍的人員,也無法完成一倍的工作。可以有效運用的最高人員數目,是依整體的軟體規模和架構而定,並且可以由諸如
COCOMO II 之類的估算模型提供這項資訊(請參閱 [BOE00])。
反覆作業的實際執行接著會交由計時框管理,亦即範圍和品質(依探查到的問題未更正而言)會做積極的管理,以符合結束日期。
在詳述階段中:
共有三種主要動力會驅使在詳述中,定義反覆作業的目標:
定義反覆作業目標的主要動力是風險。您需要愈早開始減輕或消弭風險愈好。這是詳述階段的常見情況,因為在這個階段時,應該要減輕大部分的風險,不過這仍然會是建構作業的關鍵元素,因為某些風險仍然會很高,或發現新的風險。但是由於詳述階段的目標是要建立架構的基準線,因此這裡也需要考慮其他事項,例如確定架構會處理要開發的所有軟體層面(涵蓋面)。這一點很重要,因為架構就會用來進行進一步的規劃:團隊組織、估算需要開發的程式等。
最後,雖然專注於風險管理是很重要的事,但也不可忽視系統的主要任務;解決棘手問題是好事,但在解決問題時不可損害到核心功能:請確定確實有涵蓋系統的主要功能或服務 (重要性),即使那些功能或服務並不會有風險也一樣。
在「風險清單」中,針對損傷力最大的風險,在一些使用案例中指出一些情境,來強制開發小組「正視」該風險。
範例
-
如果有類似「資料庫 D 可在 OS Y 正確運作」的整合風險存在時,請務必包含一個情境來進行一些資料庫互動,即使是很細微的動作也無妨。
-
如果有類似「計算飛機航線的時間」的效能風險存在,請務必包含一個情境來納入此項計算,至少要計算最明顯和最常見的案例。
對於重要性,請確定有包括系統提供的最基本功能或服務。 從使用案例中挑出一些情境,來代表最常見的情況、系統最常提供的服務或功能形式。這項努力是由軟體架構文件驅動,提供一組具優先順利的使用案例或使用案例子流程,由軟體
架構師挑選來反映出具有架構重要性的使用案例或情境。
範例
-
對於電話交換機而言,一般的點對點呼叫是早期反覆作業的明顯必要項目。把這一項做對,要比解決錯誤處理子系統的操作員配置中的迴旋失敗模式更重要。
對於涵蓋面,在逼近詳述階段的尾聲時,包含一些情境來探查 您已經知道需要開發的一些區域,雖然這些區域既不重要,也沒有風險。
建立一次可以處理多個問題的較長、端對端且涵蓋從開始到結束的情境,通常是比較具有經濟效益的做法。
最常發生的情況是情境變得太厚,例如試圖涵蓋太多不同的層面、變化以及錯誤情況 (請參閱反覆計劃)。
另外在詳述階段中,請記得某些風險可能是人為或程式化本質引起的:團隊文化、訓練、工具選擇、新技術等,並且只要做一遍反覆作業,即可減輕這些風險。
範例
-
在用戶端工作站上建立一份訂閱者記錄,以儲存至伺服器上的資料庫中,這包括使用者對話框,但不包括所有欄位,並且假設沒有偵測到錯誤。
將一些重要功能和一些整合風險(資料庫及通訊軟體)及整合問題 (處理兩種不同的平台)合併。同時亦強制設計師熟悉新的 GUI 設計工具。最後產生一個原型,以便用來向使用者做示範,以取得意見回饋。
-
確定最多可以建立 20,000 個訂閱者,並且在存取一個訂閱者時,最長不可超過 200 毫秒。
處理一些關鍵效能問題(容量或資料,以及回應時間),若不解決這些問題,將會顯著影響架構。
-
復原訂閱者位址變更。
一項簡單的功能,強制設計師思考有關所有「復原」功能的設計。如此即會向使用者觸發一些推回反應,指出哪些東西在復原時,只需要合理的成本即可達成。
-
完成與供應鏈管理相對的所有使用案例。
詳述階段的目標也要完成需求擷取,也許是依組合擷取。
在建構階段中:
當專案移入建構階段時,風險仍然是一個主要動力,特別是新發現且非預期的風險。不過這時完成使用案例也會開始成為動力。反覆作業可以依特性逐一規劃,請盡量提早完成一些最重要的特性,以便那些特性可以在一個以上的反覆作業中,進行完整的測試。在接近建構尾聲時,全部使用案例的健全性將會成為主要目標。
範例
-
實作所有呼叫轉接的變式,包括錯誤的呼叫在內。
這是一組相關的特性。其中一個特性可能已在詳述階段期間實作,並且會作為其餘開發作業的原型。
-
完成所有電話操作員特性,但夜間服務除外。
這是另一組特性。
-
在兩部電腦的設置中,每小時達到 5,000 個交易。
這會設定在上一個反覆作業期間達到的實際效能所需要的效能(僅 2,357/小時)
-
整合「環球資訊系統」的新版本。
這可能是最小的架構變更,這些是由先前發現的問題所需要的變更。
-
修正所有層次 1 和層次 2 問題
修正在上一個反覆作業期間發現,但沒有立即修正的,並且延遲到目前的問題。
在轉換階段中:
主要目標是完成這一代產品。反覆作業的目標是用修正哪些問題來設定,這裡也會包括對效能或可用性的改善之處。如果必須捨棄特性(或停用)才能及時達到建構尾聲 (IOC
里程碑或測試版)時,若那些特性不會妨礙目前已達成的項目,現在可以完成或啟用那些特性。
範例
-
修正在客戶處使用測試版所發現的嚴重性 1 問題。
可以將品質目標附加到相關的市場可靠性中。
-
消弭因為資料不相符,而造成的所有開機毀損。
這是以品質表示的另一個目標。
-
達到每分鐘 2,000 個交易。
效能調整,包括做一些最佳化設定:資料結構變更、快取及更靈敏的演算法。
-
將不同對話框數目縮減 30%。
縮減視覺雜亂來改進可用性
-
產生德文版和日文版。
由於缺少時間和為了減少重做,因此測試版只提供給使用英文的客戶。
|