形態基準

形態管理是針對硬體、軟體、韌體、文件、測量等進行變更管理的過程。當初始狀態、和下一個狀態之間需要變更時，一系列變更的有效狀態的標示，變得很重要。對於一個形態項目修訂歷史之中有效狀態的識別，是形態基準（Configuration Baseline）識別的核心目的[1]。

典型的有效狀態，是指收到一個正式核准的情況，可能是很明確的，或者是默許的 (核准情況可以是個別被標示，或者是僅只表明關聯於一個特定的形態基準)。然而，此核准情況經常被正式公開認可，因此，一個形態基準也可以標示出一個被核准的型態項目，例如: 一個專案計劃已經被簽署執行，這種情境之下，一個已知的形態基準，可以關聯到許多的形態項目。

大體而言，一個形態基準可以是一個單一的工作產品（Work Product），或者是一整套可用來做為邏輯基礎對照的工作產品。一個形態基準也可以被建立為後續選擇活動的基礎(該工作產品符合特定的準則)，此活動可以歸因於正式的核准。

相反地，一個專案的形態，可以包括一個、或多個形態基準、形態的情況、以及任何可以蒐集到的度量方法（Metrics）。現行的形態，關聯到現行的情況、現行的形態稽核、現行的度量方法、以及所有形態項目的最新修訂版本。

類似 (但卻不常發生) 的情形，是一個形態基準可以關聯到一個特定專案所有相關的項目，這可以包括此專案內所有項目的全部修訂版本、或僅只是所有項目的最新修訂版本，必須依靠其來龍去脈來判定。例如：按照原先計劃推行專案的形態基準。

形態基準，可以被專門化為特有型式的基準[2]，舉例如下：

  • 功能基準（Functional Baseline）： 初始建立的規格、合約等；
  • 分配基準（Allocated Baseline）： 一旦需求被核准後的工作產品的狀態；
  • 開發基準（Developmental Baseline）： 在開發過程之中的工作產品的狀態；
  • 產品基準（Product Baseline）： 包含專案可以發行的內容；
  • 其他基準： 以業主的商業慣例為基礎；

形態基準的功用（Capabilities）

標明核准狀態，可以涵蓋一個形態基準的大部分用途；而形態基準的建立，也可以僅只標示出在時間歷程中的工作進度，以這個例子而言，一個基準可視為一個有形的投資，經過持續的集體努力，而獲得的成果，例如：一個開發基準。形態基準也可以用來標示里程碑（Milestones）；雖然，有些里程碑也表示為核准。

形態基準被賦予的價值，不只擁有能識別出工作產品中值得注意的狀態的能力，也提供另一獨特的重點：資料回溯(恢復)（retrieve）的能力。一旦資料回溯，在那一小部分的工作產品的狀態，共用了變更歷史中相同的意涵，而該意涵也受到監視，此形態基準被視為嚴苛品質(善意、或非善意)，因此，基準識別、監控、和資料回溯都是成就形態管理的關鍵要素。然而，一個特定基準的放鬆管制，必須依照其利用來執行形態管理的系統而變更，該系統可以採用手動、自動、或混合的方法。一旦資料回溯，該基準可以比作為一個特定的形態，或另一個基準。

大部分的形態基準，都是建立於時間軸上的一個固定點[2]，並持續參照於該參考點 (狀態的識別)。然而，有些形態基準的建立，是為了彰顯項目本身的參考點，無視於針對該項目的任何變更。後者的形態基準，隨著工作的進度而發展，並持續針對該專案值得注意的工作產品進行識別。

基準化的形態項目（Baselining Configuration Items）

執行形態管理的過程中，可以針對有利害關係的當事者，將一特定狀態的形態項目 (或工作產品) 建立為基準。在這樣的概念裡，將一個工作產品建立為基準，可能需要針對該工作產品進行特定的變更，以確保能夠匹配其參考基準所關聯的特性。這類作法可以因為不同的背景而變化，不過，許多範例則有另一個含意，亦即工作產品從工作進行中的狀態，被重設為初始狀態。

形態基準管制（Baseline Control）

在許多不同的環境之中，形態基準受到管制之後，將因此導致該工作產品在那個基準的後續特定活動，遭到禁止、或者允許。這些活動被謹慎地挑選、與管制，並再次藉由形態管理系統來監控。因此，形態基準將依循慣例由形態管理稽核管制。稽核可以包括針對形態基準、牽涉於任何動作的個體識別、形態基準變更的評估、(重新)核准證明、狀態記述（accounting）、度量採集（metric collection）、另一基準的比較、或以上全部...等 所進行的特定活動的檢查。

可應用性（Applicability）

形態基準存在的價值，不只是版本控制系統而已。形態基準也出現在UML模型系統、商業規則管理系統、與其他系統之中。

除了硬體工程、與软體工程的領域之外，形態基準也會出現在醫學(例如：監控健康進展)、政治學(例如：統計數字)、與其他領域...等。

參見

參考資料
  1. CMMI Product Team, "Chpt 7, Maturity Level 2: Managed, Configuration Management, SP 1.3," in Capability Maturity Model Integration, Version 1.1 (CMMI-SE/SW/IPPD/SS, V1.1): Staged Representation, Carnegie Mellon Software Engineering Institute.
  2. IEEE Computer Society, "Chpt 7, 2.1.5. Baseline," in Guide to the Software Engineering Body of Knowledge, 2004 Version, Edited by Deborah Plummer. IEEE Computer Society Press, 2005. ISBN 0-7695-2330-7
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.