第十二章--第十六章
十二章至十六章這幾章也是項目管理的重要章節，特點是考試題點都比較集中，而且涉及幾個重要的法律法規，如果大家精力是時間夠用，可以查閱“招投標法”、“著作權法”“政府採購法”等相關法規，如果時間精力不寬裕，建議複習第三版中涉及法律法規的內容。
第十二章 採購管理
這一章出題點最多的是招標投標法，教程中的內容並不多。如果大家有時間，建議將《中華人民共和國招標投標法》多看幾遍，如果時間和精力不夠，那需要把第三版中的12.4.3招投標的內容熟練掌握，從2017年-2019年的試題中統計來看，題點主要從教材中的招投標法內容中出而且沒有出現2次以上的考試題點。
但是相關的規範和法規需要掌握，政府採購法、招標法是重點，需要結合歷年考題查看幾個法規經常出現的知識點。
需要知道的是：
●採購方不僅僅是甲方，有時候乙方外包也可以是採購方，所以採購方簡單理解就是出錢的一方。
●採購檔案保存期限：永久、長期（30年）、短期（10年）。
●採購管理的過程、輸入、輸出、工具和技術。
第十三章 合同管理
從2017年-2019年試題統計中分析，合同管理出題點不是很多，佔比也不高，主要集中在合同的類型，要會區分、辨別。建議大家掌握“13.1.1合同的類型”中的6.合同類型的選擇內容。
13.1.1合同的類型
1.按項目範圍劃分
1)項目總承包合同
2) 項目單項承包合同
3) 項目分包合同
2.按項目付款方式劃分
以項目付款方式爲標準進行劃分，通常可將合同分爲兩大類，即總價和成本補償類。 還有第三種常用合同類型，即混合型的工料合同。
3.總價合同
1)固定總價合同
2)總價加激勵費用合同
3) 總價加經濟價格調整合同
4) 訂購單
4.成本補償合同
1)成本加固定費用合同
2)成本加激勵費用合同
成本加激勵費用合同（Cost Plus Incentive Fee, CPIF)爲賣方報銷履行合同工作所 發生的一切合法成本（即成本實報實銷）並在賣方達到合同規定的績效目標時，向賣方 支付預先確定的激勵費用。
在CPIF合同下，如果賣方的實際成本低於目標成本，節餘部分由雙方按一定比例 分成（例如，按照80/20的比例分享，卽買方80%,賣方20%);如果賣方的實際成本 高於目標成本，超過目標成本的部分由雙方按比例分擔（例如，基於賣方的實際成本， 按照20/80的比例分擔，即買方20%,賣方80%)。
在CPIF合同下，如果實際成本大於目標成本，賣方可以得到的付款總數爲“目標 成本+目標費用+買方應負擔的成本超支”；如果實際成本小於目標成本，則賣方可以得 到的付款總數爲“目標成本+目標費用-買方應享受的成本節約”。例如，表13-3是一個 成本加激勵費用合同的示例。
3)成本加獎勵費用合同
5.工料合同
6.合同類型的選擇
口袋應試：試題中常會出現給你一種情況，讓你使用哪種合同，選擇合同類型的技巧：
●如果工作範圍明確、且項目的設計已具備詳細的細節，則使用總價合同；
●如果工作性質清楚，但範圍不是很清楚，而且工作不復雜，又需要快速簽訂合同， 則使用工料合同。
●如果工作範圍尚不清楚，則使用成本補償合同。
●如果雙方分擔風險，則使用工料合同；如果買方承擔成本風險，則使用成本補償 合同；如果賣方承擔成本風險，則使用總價合同。
●如果是購買標準產品，且數量不大，則使用單邊合同。
另外：
●成本加激勵費用合同與成本補償合同意義相同。
●買方承擔成本風險，用成本補償合同；
●賣方承擔成本風險，用總價合同；
●購買標準產品並且數量不大，用單邊合同；
第三版[email protected]
出題概率：★★
190154、190355
●出於篇幅考慮，本篇備考彙總的試題解析並未收錄3次以下的考點內容，如需查閱，請在微信中搜索“信息系統項目管理師口袋應試”小程序，或者關注我的個人公衆號“跬步郎”。
第十四章 文檔與配置管理
從2017-2019年的試題統計中分析：雖然本章名字叫“文檔與配置管理”，但是文檔的內容這幾年出題很少。題點主要集中在：14.2.1配置管理的概念以及14.2.3日常配置管理活動中，這兩節是必須掌握的內容，其中：配置項狀態、版本號的區分；“配置控制委員會”的概念和組成，“配置管理員”的權限都是出題點；另外，配置控制的流程和任務也是出題的要點。其它內容也建議大家有精力的話儘量掌握。
14.2.1配置管理的概念
1.配置項
典型配置項包括項目計劃書、需求文檔、設計文檔、源代碼、 可執行代碼、測試用例、運行軟件所需的各種數據，它們經評審和檢查通過後進入配置 管理。
2.配置項狀態
配置項的狀態可分爲“草稿”“正式”和“修改”三種。配置項剛建立時，其狀態 爲“草稿”。配置項通過評審後：其狀態變爲“正式”。此後若更改配置項，則其狀態變 爲“修改”。當配置項修改完畢並重新通過評審時，其狀態又變爲“正式”。
3. 配置項版本號
配置項的版本號規則與配置項的狀態相關。
(1) 處於“草稿”狀態的配置項的版本號格式爲0.YZ, YZ的數字範圍爲01~99。 隨着草稿的修正，YZ的取值應遞增。YZ的初值和增幅由用戶自己把握。
(2) 處於“正式”狀態的配置項的版本號格式爲XY, X爲主版本號，取值範圍爲 1~9。Y爲次版本號，取值範圍爲0~9。配置項第一次成爲“正式”文件時，版本號爲1.0。
如果配置項升級幅度比較小，可以將變動部分製作成配置項的附件，附件版本依次爲1.0，1.1,…。當附件的變動積累到一定程度時，配置項的Y值可適量增加，Y值增加一定程度時，X值將適量增加。當配置項升級幅度比較大時，才允許直接増大X值。
(3) 處於“修改”狀態的配置項的版本號格式爲X.YZ。配置項正在修改時，一般只增大Z值，X.Y值保持不變。當配置項修改完畢，狀態成爲“正式”時，將Z值設置爲0,增加X.Y值。
6. 配置庫
配置庫（Configuration Library)存放配置項並記錄與配置項相關的所有信息，是配置管理的有力工具，利用庫中的信息可回答許多配置管理的問題，例如：
●哪些客戶已提取了某個特定的系統版本？
●運行一個給定的系統版本需要什麼硬件和系統軟件？
●—個系統到目前已生成了多少個版本，何時生成的？
●如果某一特定的構件變更了，會影響到系統的哪些版本？
●一個特定的版本曾提出過哪幾個變更請求？
●一個特定的版本有多少己報告的錯誤？
8.配置控制委員會
注：變更控制委員會(Change Control Board，CCB)也稱爲配置控制委員會(Connguration Control Board)
配置控制委員會（Configuration Control Board, CCB),負責對配置變更做出評估、 審批以及監督已批准變更的實施。
CCB建立在項目級，其成員可以包括項目經理、用戶代表、產品經理、開發工程師、 測試工程師、質量控制人員、配置管理員等。CCB不必是常設機構，完全可以根據工作 的需要組成，例如按變更內容和變更請求的不同，組成不同的CCB。小的項目CCB可 以只有一個人，甚至只是兼職人員。
9, 配置管理員
配置管理員（ConfigurationManagement Officer, CMO),負責在整個項目生命週期中進行配置管理活動，具體有：
●編寫配置管理計劃。
●建立和維護配置管理系統。
●建立和維護配置庫。
●配置項識別。
●建立和管理基線。
●版本管理和配置控制。
●配置狀態報告。
●配置審計。
●發佈管理和交付。
●對項目成員進行配置管理培訓。
第三版[email protected]
出題概率：★★★★
180151、180311、180352、190152、
14.2.3日常配置管理活動
2.配置標識
配置標識（Configuration Identification)也稱配置識別，包括爲系統選擇配置項並在 技術文檔中記錄配置項的功能和物理特徵。
配置標識是配置管理員的職能，基本步驟如下：
(1)識別需要受控的配置項。
(2)爲每個配置項指定唯一性的標識號。
(3)定義每個配置項的重要特徵。
(4)確定每個配置項的所有者及其責任。
(5)確定配置項進入配置管理的時間和條件。
(6)建立和控制基線。
(7)維護文檔和組件的修訂與產品版本之間的關係。
3.配置控制
配置控制即配置項和基線的變更控制，包括下述任務：標識和記錄變更申請，分析 和評價變更，批准或否決申請，實現、驗證和發佈己修改的配置項。
1) 變更申請
2) 變更評估
3) 通告評估結果
4) 變更實施
5) 變更驗證與確認
項目經理指定人員對變更後的配置項進行測試或驗證。
項目經理應將變更與驗證的結果提交CCB,由其確認變更是否已經按要求完成。
6) 變更的發佈
7) 基於配置庫的變更控制
現以某軟件產品升級爲例，簡述其流程（配置庫的變更控制流程）：
(1) 將待升級的基線（假設版本號爲V2.1)從產品庫中取出，放入受控庫。
(2) 程序員將欲修改的代碼段從受控庫中檢出（Checkout),放入自己的開發庫中 進行修改。代碼被Check out後即被“鎖定”，以保證同一段代碼只能同時被一個程序員 修改，如果甲正對其修改，乙就無法Check out。
(3) 程序員將開發庫中修改好的代碼段檢入（Checkin)受控庫。Check in後，代碼的“鎖定”被解除，其他程序員可以Check out該段代碼了。
4.配置狀態報告
配置狀態報告應該包含以下內容。
(1) 每個受控配置項的標識和狀態。一旦配置項被置於配置控制下，就應該記錄和保存它的每個後繼進展的版本和狀態。
(2) 每個變更申請的狀態和已批准的修改的實施狀態。
(3) 每個基線的當前和過去版本的狀態以及各版本的比較。
(4) 其他配置管理過程活動的記錄。
5. 配置審計
配置審計（ConfigurationAudit)也稱配置審覈或配置評價，包括功能配置審計和物 理配置審計，分別用以驗證當前配置項的一致性和完整性。
1）功能配置審計：
功能配置審計（Functional Configuration Audit)是審計配置項的一致性（配置項的實際功效是否與其需求一致）
2)物理配置審計：
物理配置審計（Physical Configuration Audit)是審計配置項的完整性（配置項的物理存在是否與預期一致）
第三版[email protected]
出題概率：★★★★★
170310、170362、190112、190151、190351、
第十五章 知識管理
從2017年-2019年試題出題情況看，本章出題的知識點並不多，主要的知識點在《著作權法》，建議掌握《著作權法》或第三版教程中關於著作權的內容。其它要點出題概率不高，並沒有3星以上的題點，所以在本資料中就不列出了，有精力的同學可以參考“信息系統項目管理師口袋應試”小程序中的對應章節，裏面有詳細題點。另外，建議大家可以通讀15.3-知識產權保護這一節，把這一節裏面涉及“著作權法”、“軟件保護條例”、“專利法”掌握一下，另外“商標法”也越來越受到重視，建議大家多瞭解，對實際工作也是有好處的。
第十六章 變更管理
從2017年-2019年試題出題概率分析，本章內容只在變更管理工作程序中出現過考題，大家根據個人的時間和精力複習即可。
16.3.2項目變更管理工作程序：
1．提出與接受變更申請
變更提出應當及時以正式方式進行，並留下書面記錄。
2．對變更的初審
變更初審的目的如下。
(1) 對變更提出方施加影響，確認變更的必要性，確保變更是有價值的。
(2) 格式校驗，完整性校驗，確保評估所需信息準備充分。
(3) 在干係人間就提出供評估的變更信息達成共識。
變更初審的常見方式爲變更申請文檔的審覈流轉。
3．變更方案論證
變更方案的主要作用，首先是對變更請求是否可行實現進行論證，如果可能實現，則將變更請求由技術要求轉化爲資源需求，以供CCB決策。
4．項目管理委員會審查
審查過程，是項目所有者根據變更申請及評估方案，決定是否變更項目基準。
5.發出變更通知並組織實施
評審通過，意味着基準的調整，同時確保變更方案中的資源需求及時到位。
6．變更實施的監控
變更實施的過程監控，通常由項目經理負責基準的監控。
7．變更效果的評估
變更評估可以從以下幾個方面進行評估：
(1) 首要的評估依據，是項目的基準。
(2) 還需結合變更的初衷來看，變更所要達到的目的是否已達成。 .
(3) 評估變更方案中的技術論證、經濟論證內容與實施過程的差距並促發解決。
8，判斷髮生變更後的項目是否已納入正常軌道
基準調整後，需要確認的是資源配置是否及時到位，涉及人員的調整，更需多加關注。
第三版[email protected]
出題概率：★★★
170134、180152、190353、