準則: 實作中的重要決策
這個準則說明在調整流程的「實作」方面時必須考量的重要事項。
關係
主要說明

決定如何使用工作成果

決定要使用什麼工作成果及如何使用。除了指出要使用什麼工作成果之外,也必須調整要使用的每一個工作成果,以符合專案的需求。 

下表指出建議哪些「實作」工作成果及哪些可視為選用(亦即,只在特定的情況下使用)。 至於其他調整注意事項,請參閱工作成果說明頁的調整章節。

工作成果 目的

調整(選用、建議)

實作模型

實作子系統實作元素

實作模型是程式碼、可執行程式,以及在執行環境中建置和管理系統時所需要的所有其他工作成果。

實作由實作元素組成,其中包括程式碼(原始碼、二進位檔和可執行程式)以及包含資訊的檔案(如開機檔或 Readme 檔)。

實作子系統是實作元素及其他實作子系統的集合,它用來將實作模型分成較小的零件,以建立實作模型的結構。

所有軟體專案都有一個實作模型,實作元素至少包括部分程式碼和可執行程式。

部分專案也包括子系統、程式庫和視覺化模型。

當有大量需要組織的實作元素時,子系統非常有用。

整合建置計劃 定義元件應該採用的實作次序、整合系統時所要建立的建置項,以及評量它們的方式。

選用。

如果您需要進行整合規劃,建議採用。請只在整合無關緊要時,才省略它。



決定單元測試涵蓋面

請決定單元測試的執行範圍及程式碼涵蓋面層次,等級是從非正式到 100% 的程式碼涵蓋面。 測試計劃中說明這個等級。

單元測試涵蓋面的層次通常是由接受程式碼的整合和系統測試人員的需求來驅動。系統測試人員的工作依賴程式碼的品質。如果程式碼有太多問題。整合和系統測試人員往往會將程式碼退回給實作者。這就表示開發流程不好,解決方案可能是要求實作者做更多徹底的單元測試。

當然,您不能期待單元測試的程式碼完全無誤。不過,您確實需要在單元測試和品質之間找出「健全」的平衡。

不同階段的單元測試涵蓋面層次也可能各不相同。即使是非常看重安全、在建構和轉換期間需要 100% 程式碼涵蓋面的專案,在詳述期間,通常也不會有這項需要,因為許多類別在這個階段只會局部實作。

決定如何檢視程式碼

決定應該檢視程式碼到達什麼程度。 

以下是檢視程式碼的好處:

  • 既強制也鼓勵專案採用共用的程式撰寫風格。檢視程式碼是讓專案成員遵循程式設計準則的有效方式。為了確保這一點,檢視所有作者和實作者的結果,比檢視所有程式碼檔案重要。
  • 找出自動測試找不到的錯誤。檢視程式碼會擷取到測試時所未發現的錯誤。
  • 使每個人分享知識,以及將老手的知識傳給新人。

以下是檢視程式碼的缺點:

  • 消耗時間和資源。
  • 如果處置不當,效率可能很差。檢視程式碼有可能淪於「為了必須檢視而檢視」,而不是有效彌補自動化測試的手段。

如需程式碼複查的相關資訊,請參閱作業:審查程式碼

檢視程式碼為專案帶來許多附加價值。任何專案,只要開始測量與程式碼檢視相關的錯誤和維護問題的層次,都宣稱它們的效能因檢視而有了改善。不過,許多組織的「起飛」都會發生困難,原因如下:

  • 收集的資料不足以驗證程式碼的檢視確實有效。
  • 收集太多資料。
  • 實作者對他們的程式碼充滿保護心態。
  • 檢視陷入形式的泥沼。
  • 管理檢視太費工夫。

請記住下列各點,以便從程式碼檢視中得到最大好處:

  • 只收集適當的資料。
  • 測量檢視的效能,並顯示結果。
  • 以「精練」的方式來使用檢視。

如需審查層次的相關資訊,請參閱準則:審查層次。