文章目錄

• 一、CMM/CMMI與軟件配置管理
• • • 產品完整性
• 二、三庫管理
• 三、基線管理
• • • 基線管理的好處
    • 基線管理的步驟
• 四、配置庫管理
• 五、變更管理
• • • 變更管理流程
• 六、配置審計
• 七、配置狀態報告

一、CMM/CMMI與軟件配置管理

軟件配置管理是CMM/CMMI二級（可重復級）的一個重要KPA。
CMM/CMMI又將軟件配置管理的目的定義為建立和維護產品的完整性。

產品完整性

項目提交的工作成果是產品集合完整、子產品正確的。

• 產品集合完整：產品包含的子產品是完整的；
• 子產品正確：子產品達到了需求要求，滿足標準、規程的要求。

二、三庫管理

配置項在開發庫、受控庫和產品庫之間遷移，一級比一級的控制更加嚴格。
在CMM中，對開發庫的管理沒有要求，但要對受控庫和產品庫進行管理。

• 開發庫
  存放開發過程中需要保留的各種信息，供開發人員專用；
• 受控庫
  在軟件開發某個階段工作結束后，將產品或有關信息存入；
• 產品庫
  在軟件產品完成系統測試后，作為最終產品存入庫內。

按照三庫管理的思路，軟件開發組日常的工作在開發庫中開展，當工作達到里程碑時，再遷移到受控庫，在受控庫中經過更加嚴格的測試后，再上升到產品庫，最后發布。
三庫間通常通過權限與流程控制實現配置項再不同庫之間的流轉以及人員訪問。即邏輯獨立，物理上在一起。

三、基線管理

每個基線都接受配置管理的控制，對其的修改將按照變更控制的要求進行。在一個軟件開發階段結束時，上一個基線加上增加和修改的內容形成下一個基線。

基線管理的好處

• 重現性：及時返回并重新生成軟件系統版本的能力。
• 可追蹤性：建立項目工作之間的前后繼承關系。
• 版本隔離：基線為開發工件提供了一個定點和快照，新項目可以中基線提供的定點中建立。

基線管理的步驟

在開發前確定基線的配置

在批準基線前，根據配置檢查配置項的完整性

對每個配置項，確定版本的正確性

為每個配置項建立基線標志

基線變更管理

基線報告和審計信息

四、配置庫管理

每個配置項從建立開始，就被劃分成3個分支：私有分支、集成分支和公共（主干）分支，分別對應三類工作空間，由CMO統一管理。

• 私有分支：是開發人員的私有開發空間，除該開發人員外，其他人無權操作；
• 集成分支：對應開發團隊的公共空間，開發團隊擁有讀寫權限，而其他成員只有只讀權限，SIO和相關指定負責人進行管理；
• 公共分支：對應整個軟件開發組織的公共空間。對全體人員只開發只讀權限，由SIO負責管理。

決定配置庫的結構是配置管理活動的重要基礎，一般常用的是兩種組織形式：按配置類型分類建庫和按任務建庫。

五、變更管理

保證配置項在開發過程中始終處于受控狀態，且在任何情況都能迅速恢復到任一歷史狀態。
為了更好知道變更范圍的影響分析，可以通過《需求追蹤表》和《配置項依賴關系表》發現受到影響的內容。

變更管理流程

提出變更請求

CCB審核并決定是否批準

分配人員，提取SCI，進行修改

提交修改后的SCI，并測試

重建軟件版本

復審所有SCI的變化

發布新版本

六、配置審計

作為變更控制的補充手段，確保變更需求已被切實實現。審計機制保證修改的動作被完整地記錄。
配置審計有兩種，分別是物理審計和功能審計。

• 物理審計（PCA）：檢查版本是否正確一致（完整性）。一般由非配置管理人員進行，如SQA（質量保證人員）
  • 配置項是否齊備
  • 版本是否齊全
• 功能審計（FCA）：檢查配置項是否完整，各種過程文檔是否齊備、正確、與需求是否一致（一致性），歸結為兩點，即完全和齊備。一般由CMO進行。

七、配置狀態報告

配置狀態報告就是根據配置項操作的記錄來向管理者報告軟件開發活動的進展情況。通常是定期進行、通過case工具自動生成的。著重反應當前基線配置項的狀態，對變更情況和配置庫情況也應進行說明。

總結

以上是生活随笔為你收集整理的软件配置管理（三）软件配置管理核心功能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。