CMMI2級——度量與分析(Measurement and Analysis, MA)

它事 成熟度第二級的支持類【過程域】

度量的目標:

• 改進開發(fā)過程
• 改進項目控制
• 縮短項目周期
• 減少開發(fā)成本
• 提升軟件質(zhì)量
• 提升軟件性能
• 提高勞動生產(chǎn)率

度量的目的:

開發(fā)和維護度量能力，以支持對管理信息的需要

特定目標:

特定目標

SG 1 分配度量和分析活動
度量的目標和活動與識別出的信息需求取得一致

• SP 1.1 建立度量目標
• SP 1.2 詳細說明度量
• SP 1.3 指定 數(shù)據(jù)收集與存儲流程
• SP 1.4 指定 分析流程

SG 1 分配度量和分析活動

SG 2 提供度量結(jié)果
提供了滿足信息要求的度量結(jié)果

• SP 2.1 收集度量數(shù)據(jù)
• SP 2.2 分析度量數(shù)據(jù)
• SP 2.3 存儲數(shù)據(jù)和結(jié)果
• SP 2.4 提交結(jié)果

提供度量結(jié)果

CMMI2級——供應商協(xié)議管理(Supplier Agreement Management)

做軟件開發(fā)的，不免要購買一些軟硬件。軟件可能是中間件、控件、插件、組件等，硬件可能是一些服務器、PDA、單片機等。只要稍微復雜的項目，都不可避免的會有采購的問題，就算目前沒有采購，以后也會不可避免。另外也有可能把項目的一部分外包給第三方來做。

特定目標和特定實踐

SG1：簽訂供應商協(xié)議：

• SP1.1確定采購方式
• SP1.2選擇供應商
• SP1.3簽訂供應商協(xié)議

SG2：履行供應商協(xié)議：

• SP2.1執(zhí)行供應商協(xié)議
• SP2.2監(jiān)督選定的供應過程
• SP2.3評價供應商產(chǎn)品
• SP2.4驗收采購的產(chǎn)品
• SP2.5移交產(chǎn)品

特定目標和特定實踐

SAM這個PA，簡單的說可以分為4點：
1)分析項目什么東西需要采購或者外包。
2)選擇合適的供應商。
3)和供應商簽署協(xié)議，協(xié)議要寫明產(chǎn)品規(guī)格要求、驗收要求、雙方的活動、交付要求等，盡可能明細。
4)履行供應商協(xié)議。

CMMI2級——配置管理(Configuration Management) （重點）

需求計劃承諾等變更而產(chǎn)生的變化會接連不斷地發(fā)生，所有這些變化最終將體現(xiàn)在多人共同創(chuàng)建的包含源代碼、數(shù)據(jù)或者文檔的文件中所發(fā)生的變化。
為了避免項目在變更時失控，正確控制和管理變更時很必要的
軟件配置管理是項目管理中專用于關注系統(tǒng)地控制項目進行中發(fā)生變更的那些部分，由用來識別機構軟件產(chǎn)品并控制其修改的一系列活動構成

配置：

是在技術文檔中明確說明最終組成軟件產(chǎn)品的功能或者物理屬性，它包括了即將受控的所有產(chǎn)品特性、內(nèi)容及其相關文檔，而且包括軟件版本、變更文檔和軟件運行的支持數(shù)據(jù)，以及其他一切保證軟件一致性的組成要素

配置項

凡是納入配置管理范疇的 工作成果 統(tǒng)稱為配置項（CI）。
配置項主要有兩大類：

• 屬于產(chǎn)品組成部分的工作成果，例如源代碼、需求文檔、設計文檔和用戶說明書等等即目前公司采用的配置項。
• 在管理過程中產(chǎn)生的文檔例如各種周報、監(jiān)控報告等等，這些文檔雖然不是產(chǎn)品的組成部分，但是值得保存，也就是我們的數(shù)據(jù)項。

每個配置項的主要屬性有：名稱、標識符、版本、作者、日期等。所有配置項都被保存在配置庫里，確保不會混淆、丟失。配置項及其歷史記錄反映了軟件的演化過程

配置項特點：

• 它會被兩個或兩個以上的項目成員共同使用。
• 它會隨著項目的開展而發(fā)生變化。
• 對項目重要的工作產(chǎn)品。
• 一些工作產(chǎn)品之間的關系非常緊密，一個變化其他的就會受
  到影響。
• 配置項本身的變化可以使用“版本管理”對其進行控制

配置管理主要任務

• 識別在指定時間形成基線的產(chǎn)品配置
• 控制配置項變更
• 由配置庫構建和發(fā)布產(chǎn)品
• 提供精確的配置狀態(tài)
• 維護在整個軟件生命周期中配置的完整性和可跟蹤性

軟件配置管理活動可歸結(jié)為4個主要功能

• 配置識別
• 變更控制
• 配置狀態(tài)統(tǒng)計
• 配置審核 （正式審核，非正式審核）

基線Baseline

定義:
已經(jīng)正式通過復審核批準的某規(guī)約或者產(chǎn)品，它因此可以作為進一步開發(fā)的基礎，并且只能通過正式的變化控制過程改變
軟件文檔或源碼(或其它產(chǎn)出物)的一個穩(wěn)定版本,它是進一步開發(fā)的基礎。
由一組配置項組成，這些配置項構成了一個相對穩(wěn)定的整體?；€中的配置項被“凍結(jié)”了，不能再被任何人隨
意修改。
經(jīng)過正式評審和認可的一組軟件配置項，此后，它們將作為下一步開發(fā)工作的基礎，而且只有通過正式的變更控制流程才能被更改，例如設計說明書是編碼的工作的基礎，它可以成為軟件基線

里程碑（可以有多個）：基線通常對應于項目/開發(fā)過程中的里程碑，一個產(chǎn)品可以有多個基線，也可以只有一個基線。
主要屬性：名稱、標識符、版本、日期等
正式標準：基線是項目儲存庫中每個工件版本在特定時期的一個“快照”。它提供一個正式標準，隨后的工作基于此標準，并且只有經(jīng)過授權后才能變更這個標準。
更改：對基線的更改必須遵循變更控制規(guī)程。
"放行"基線：交付給外部顧客的基線
"構造"基線：內(nèi)部使用的基線

軟件配置管理的目的 ：

在項目的整個軟件生命周期內(nèi)建立并維護軟件項目產(chǎn)品的完整性，記錄并報告配置的狀態(tài)，驗證配置項的完整性和正確性。
建立和維護工作產(chǎn)品的完成性，使用配置項，配置控制，培植狀態(tài)統(tǒng)計和配置審計。
通過配置標識、配置控制、配置狀態(tài)報告和配置審計等手段，建立和維護工作產(chǎn)品的完整性。

特定目標和特定實踐

軟件配置管理

配置管理---【SG1建立基線】

SG1建立基線

SP1：識別出需要置于配置管理之下的的配置項、組件和相關的工作產(chǎn)品
SP2：建立和維護配置管理和變更管理的系統(tǒng)以控制工作產(chǎn)品

• 協(xié)同開發(fā)的基礎:控制進度、質(zhì)量
• 公司資產(chǎn)的生命線
• 要求開發(fā)人員改變一些工作習慣

SP3：創(chuàng)建和發(fā)布了內(nèi)部使用以及發(fā)布給客戶的基線

--------實現(xiàn)活動--基線控制--------

• 計劃
• 需求分析
• 設計
• 編碼
• 測試

基線控制

--------控制方法--版本--------

基本就是git里面那些東西，大概看一看

版本的訪問

版本的訪問

版本的分支
是軟件配置項同時沿著兩個或多個分支展開，新版本獨立地添加到各自的分支中

版本的分支

版本的合并
是軟件配置項同時沿著兩個或多個分支展開，新版本獨立地添加到各自的分支中

版本的合并

版本控制
通過分支和合并為并行開發(fā)提供支持

• 并行開發(fā)允許不同的項目在同一時間使用相同的原文件；
• 并行開發(fā)隔離了那些永遠不被共享的工作；
• 并行開發(fā)允許工程師即使某一條開發(fā)線被凍結(jié)了，仍可以沿著一個分支繼續(xù)開發(fā)。

分支、合并、比較
文件比較－用來比較兩個或多個分支或基線中具有相同名字的文件，并識別這些不同的文件。

分支作用

• 缺陷修正
• 多版本
• 并行開發(fā)

所有合并必須合并到主分支

所有合并必須合并到主分支，子分支完成合并后，不再演進
適用于對軟件缺陷的修正工作管理

一個子分支的演進可以通過主分支傳遞給其他子分支

但是所有的變化均要反映到主分支，各個分支均可進行合并
適用于具有核心版本的產(chǎn)品
圍繞核心版本推進各個分支的演進
一個子分支的演進可以通過主分支傳遞給其他子分支

配置管理---【SG2跟蹤和控制變更】

在配置管理之下的配置項變更得到跟蹤和控制

跟蹤和控制變更

SP 2.2:控制配置項的變更

• 組建CCB (變更控制委員會英文縮寫）
• 要規(guī)定控制級別！
• 要確認變更實施

--------變更管理任務--------

變更控制的目的 不是為了防止變更，而是管理變更
變更控制的目的 是防止配置項被隨意修改而導致混亂。

軟件變更的不可避免性
? 錯誤更正
? 產(chǎn)品改進
? 需求變更

軟件變更的復雜性
? 軟件配置項數(shù)量大
? 版本多
? 變更的遷延性
? 人員溝通協(xié)調(diào)

變更管理的任務
? 分析變更
? 記錄和追蹤變更
? 采取措施保證變更在受控狀態(tài)下進行

變更管理任務

--------控制基線的變更--------
目的
? 識別變更授權人
? 維護配置的穩(wěn)定性和完整性
? 確保變更控制的有效性

定義變更權威---》控制變更---》管理問題報告

--------變更管理--------
變更管理是配置管理的一個重點和難點。

當基線庫配置項需要變更時，一定要實施變更流程：
? 變更實施前必須填寫《變更申請表》，
? 經(jīng)CCB評審通過后，
? 才能從基線庫中提出需變更的配置項并實施變更。
? 變更實施完成后，必須通過評審驗證才能重新進入基線庫。

變更流程

--------配置變更委員會CCB-------
授權進行正式基線變更的機構

職能：
? 確保變更被分類以及被評估
? 決定需要實施的變更的優(yōu)先級
? 評審和批準變更
? 確保只有被批準的變更得到實施

CCB成員最好各司其職,成員可能包括：
? 項目經(jīng)理，配置管理員，質(zhì)量保證人員，開發(fā)人員代表，客戶代表

配置管理---【SG3建立完整性】

基線的完整性得到了建立和維護

建立完整性

SP 3.1：建立和維護描述配置項的配置記錄
? 記錄變更
? 記錄基線狀態(tài)
? 發(fā)布狀態(tài)報告

SP 3.2：執(zhí)行了配置審計以維護配置基線的完整性
? 功能審計和物理審計
? 產(chǎn)品/基線出門前的保證

配置狀態(tài)報告
一種配置管理活動
目的是向項目所有成員提供已批準的基線和過程的當前狀態(tài)，也提供基線變更信息。報告的方式可以多種多樣，如發(fā)OA、Email
應該把握好時機：變更請求被批準時；建立基線及基線版本發(fā)生變化時；項目組任何需要的時候。

配置審計
定義：對于存儲配置項及相關記錄的軟件基線庫的結(jié)構、內(nèi)容和設施進行檢驗，其目的在于驗證基線是否符合描述基線的文檔。

? 配置審計的目的就是要保證所有人員（包括配置管理員、CCB、和普通項目成員）都遵守配置管理規(guī)范。
? 可以作為變更控制的補充手段，來確保某一變更需求已被切實實現(xiàn)。
? 配置審計包括三方面的內(nèi)容：基線發(fā)布審計、產(chǎn)品發(fā)布審計、日常審計。
? 配置審計的對象是項目的主要配置項

驗證內(nèi)容包括：
? 對于產(chǎn)品的功能和性能的需求作比較，可參考需求跟蹤矩陣
? 配置項的處理是否有背離初始的規(guī)格說明或已批準的變更請求的現(xiàn)象
? 配置標識的準則是否得到了遵循；
? 變更控制規(guī)程是否以遵循，變更記錄是否可供使用
? 是否保持了可追溯性。

配置審核工作：
? 功能配置審核(FCA)——驗證配置項的實際功效是與其軟件需求一致的。
? 物理配置審核(PCA)——確定配置項符合預期的物理特性，即特定的媒體形式。

功能配置審計可以包括按測試數(shù)據(jù)審計正式測試文檔、審計驗證和確認報告、評審所有批準的變更、評審對以前交付的文檔的更新、抽查設計評審的輸出、對比代碼和文檔化的需求、進行評審以確保所有測試已執(zhí)行。功能配置審計還可以包括依據(jù)功能和性能需求進行額外的和抽樣的測試。

物理配置審計可以包括審計系統(tǒng)規(guī)格說明書的完整性、審計功能和審計報告、了解不符合采取的措施、對比架構設計和詳細設計組件的一致性、評審模塊列表以確定符合己批準的編碼標準、審計手冊（如用戶手冊、操作手冊）的格式、完整性和與系統(tǒng)功能描述的符合性等。

--------審計－工作步驟--------

• 由項目經(jīng)理決定何時進行配置審計工作

• 質(zhì)量保證組或軟件組的配置管理組指定該項目的配置審計人員

• 項目經(jīng)理和配置審計員決定審核范圍。

• 配置審計員準備配置審計檢查單

• 配置審計員安排時間審核文檔和記錄，審核活動可能涉及到：
  ? 項目范圍配置項的檢入（check-in）及檢出（check_out）
  ? 評審記錄配置項的變更歷史
  ? 測試記錄文件的命名
  ? 變更請求版本的編號

• 配置審計員在審核中發(fā)現(xiàn)不符合現(xiàn)象，并作記錄。

• 由項目經(jīng)理負責消除不符合現(xiàn)象。

• 配置審計員驗證所有發(fā)現(xiàn)的不符合現(xiàn)象確已得到解決。

實現(xiàn)中的配置管理基本流程

變更會涉及到的配置項分析實例