在軟件項目管理中，總是把估計值當作承諾，無論是對自已或對同事，都會造成不必要的焦慮。為避免此類困境，就算最后期限迫在眉睫，你也能專注於該做的事。然而也應該做到隨時溝通，讓相關人員看到事情進展。
項目管理過程方針：規范產品/項目立項和結項過程，制定合理的項目計划，並據此對項目進行跟蹤，建立對項目監控的可視性，使項目管理者能在項目執行明顯偏離項目計划時及時采取有效的糾正措施。
CMMI由如下內容構成，組織級體系文件、工作指南、證據；在工作中處理問題原則，識別問題、跟蹤問題、解決問題、關閉問題。
一、關於訪談
1、訪談問題類型及回答方法
提問類型有：如何（How）、什么（What）、分析、有沒有、是否等類型。
回答方法有：
⑴、輸入條件、前提=>過程描述=>輸出產品
⑵、事前預測=>事中控制=>事后分析
⑶、制度（或體系）已經存在=>被使用=>被一致執行=>改進，形成閉環
⑷、回答問題關鍵詞：依據軟件開發過程體系文件（或指南）、受過培訓、經過評審、發布通知（例會、報給項目經理）
⑸、結合實際項目回答。
2、訪談內容關鍵點
計划、評審、度量、量化管理、風險、決策分析。
⑴、量化分析技術
量化管理技術：統計過程控制技術、蒙特卡洛分析技術、多目標決策分析技術
⑵、量化分析工具
MiniTab、CrystarBall
3、什么是過程？
過程是為了達到特定目標所實施的一系統活動或步驟。一個標准的過程應該包括：
目標/目的（Purpose）
角色與職責（Role and Responsibility）
入口准則（Entry Criteria）
出口准則（Exit Criteria）
輸入（Inputs）
輸出（Outputs）
流程圖及活動說明（Activities）
度量（Measures）
驗證（Verification）
4、過程域
⑴、項目管理主要7個過程域
⑵、基本項目管理過程域模型
⑶、高級項目管理過程域模型
5、評審方法
在體系文件《技術評審過程》中定義了評審方法。
審查（Inspection），通常是由經過技術評審培訓的項目經理或PPQA主持，規模在3～7人之間為宜，一般在完成了一個工作產品后對其進行的評審
輪查（EmailRouting），通常由技術負責人或項目經理召集，一般三人以上參加。目的在於通過對開發人員的工作產品的技術審查，提出改進意見
走查（Walkthrough），審查的范圍根據需求的優先級通常由管理人員來確定，主要是靜態質量分析和編程規則檢查。通常是小型討論會，一般是在工作產品形成的早期進行，作者有一定的想法時，希望從中獲得一些幫助或補充一些想法。當然也可以在編制工作產品的任何階段進行，兩三個人參加，由作者主持，主要是評估和提高工作產品的質量
二、准則、依據
1、風險的管理策略：
a. 當風險系數(高)在16~25之間，必須制定應急計划，並且隨時監控風險變化情況，一旦風險發生，則立刻啟動應急計划。
b. 當風險系數(中)在 9~15之間，可不制定應急計划，定期監控風險變更情況，隨時准備啟動緩解措施。
c. 當風險系數(低)在 1~8之間，可不制定應急計划，定期監控風險變更情況，必要時啟動緩解措施。
注：對於部分低風險，可選擇接受。
2、項目QPPO下達：
經營管理部立項審批時下達，基於內部環境(例如：基線)與外部環境(例如：客戶要求)的考慮，項目經理在QA的協助下，預測項目QPPO達成率：
若QPPO達成率 〉95 ，則接受
若QPPO達成率在 90-95之間， 則將其納入風險進行監控與管理
若QPPO達成率 < 90 ,則與管理層進行談判、溝通，是否可以降低目標，如果降低，則重新進行QPPO達成率預測；否則則接受，並納入風險進行監控
3、評審通過准則：
評審出缺陷數滿足要求。
4、評審准則（以需求為例）：
依據《技術評審檢查列表》中“用戶需求說明書檢查單”，主要有：完整性、一致性、描述清晰性等9項檢查點。
5、任務分解准則（WBS）：
依據《項目定義過程》、《項目估算報告》、《項目實施計划》、《項目進度計划模版》等過程體系文件和指南，任務分解准則如下：
⑴、WBS分解分類：項目分解WBS（項目管理類型任務分解）、技術分解WBS（項目工程任務及特有技術工作內容分解）。
⑵、WBS分解原則：
項目要求；
定義逐步求精；
人時（工作量）：一般的任務不超過2周，也就是80人時；
任務責任到人；
團隊工作原則：項目經理在制定項目計划過程中，尤其是在任務分解，工期估計對關鍵過程中一定要與項目成員一起進行。
6、評審員的選擇准則：
在要評審的領域擁有豐富經驗。
具備專業技術知識。
能夠有效識別待評審工作產品中存在的缺陷。
7、評審度量指標
評審活動的工時及工作量
評審發現的缺陷數（按嚴重程度及類型）
評審產品的規模
8、項目經理技能
項目估算的能力
有較強的溝通協調能力
風險識別、分析、管理的能力
項目策划的能力
進度及預算編制的能力
項目監控與管理的能力
具體需求管理的能力
9、基線、版本、存儲的定義
基線：是由一個或多個配置項組成的邏輯實體，並可以作為進一步開發的基礎。組成基線的配置項需要經過正式的評審和批准、正式的變更控制規程。通過評審的文檔、開發文檔，以及通過測試的，例如：代碼、計划（策划階段）
版本：
存儲：工作記錄，例如：會議紀要、報告
11、項目級Car基本改進原則：
項目執行中，當前性能目標無法達到現有組織過程性能。
項目執行中，出現的缺陷或問題等導致與當前組織過程績效出現嚴重偏差，明顯影響項目績效。
工作產品與需求出現明顯的偏離。
12、確定軟件開發生命周期模型的參考規則
13、完成里程碑成果的准則：
偏差不大於20%（項目可控）
交付產品通過審批或驗證
里程碑內主要工作完成。
14、軟件項目風險管理規則
風險類別有：人員、客戶、管理、質量、測試、環境等；
風險系數有：高、中、低；
風險發生概率和風險影響范圍分別1～5分。
三、項目策划實踐
1、項目策划實踐過程簡述
我在試點項目中的，策划過程如下圖所示，其中包含過程中的輸入、輸出，以及參與的角色。
2、流程中關鍵點說明：
⑴、項目實施計划內容：
項目的章程、項目概況、項目組構成及人力資源計划、項目預算及進度計划、干系人參與計划、其他下屬計划（度量分析計划以及數據管理計划、項目監控計划、需求管理計划、決策分析計划、項目評審計划、承諾管理等子計划）。
⑵、項目估算
a.如何使用資產庫和歷史數據？做估算、計划。
過程裁剪指南、軟件生命周期指南、標准工作環境指南、團隊指南等、風險庫；
開發過程定義（PDP）
生產率、估算模型、工作分配比例、人員技能水平。
b.估算參數：代碼行、頁碼、缺陷密度；質量參數：缺陷清除率、缺陷數；
c.文檔（需求、設計等技術文檔）是按類比法進行估算（頁碼），參考規定相當的度量庫，再通過頁數轉換為工作量（轉換模型）；
d.采用Delphi（專家法）估算代碼行數，額定偏差為20%；
e.項目管理占比為10～15%，預留5%，QA%5～6、CM3～4%。
⑶、生命周期
本項目采用瀑布模型，在需求比較明確、文檔，復雜度較低情況下采用，思路、路徑清晰，但是前期出現的問題，在后期會方法；
需求階段、設計階段、編碼及單元測試階段、集成測試階段、系統測試階段、驗收測試階段，其中，需求、編碼及單元測試、系統測試、驗收測試為里程碑。
⑷、估算成本、估算假設
估算成本由工作量（人工成本）、差旅、采購等成本構成。
估算假設：
團隊水平高於平均水平，包括環境、士氣；
需求變更范圍很小；
技術復雜度低。
Budget——指標/人天（成本）
⑸、進度計划
任務分解（WBS）->網絡圖（前置、后期任務）->分配資源->估算任務（征詢當事人的意見）->資源平衡->設定里程碑。
⑹、人力資源計划
根據項目工期、工作量、溝通工作，按項目時間進度來安排項目人員進出。
識別項目需要技能、業務知識，例如此項目需要Cordys平台開發技術；
根據人員技術，進行差距分析，例如有部分人員缺乏Cordys平台開發技術；
根據差異制定培訓計划。
⑺、軟、硬件資源及其環境
組織級工作環境提供了標准辦公環境，例如工作終端、配置庫等；
項目特有環境，例如：開發服務器。
3、關鍵過程舉例說明
⑴、項目過程定義（過程剪裁）
在項目過程定義中，在項目級QA的協助下，參考《組織過程裁剪指南》和《軟件生命周期》裁剪定制適合於項目的生命周期模型，制定《項目定義過程》。例如：接口設計過程，在項目定義中剪裁到詳細設計文檔中體現。
⑵、如何管理項目計划？
管理項目計划包括漸進明細維護項目計划，與組員及時溝通計划完成情況，以及通過周例會、周報、報工系統收集計划完成情況和進度，並通過掙值分析分析項目的偏差，也通過周例會收集風險、問題，及時跟蹤；
通過掙值分析管理項目進度、成本偏差；
問題管理，識別問題、跟蹤問題、關閉問題。
⑶、如何評價團隊的有效性，如何構建項目團隊的？
組織團隊指南；
在項目啟動時，項目通知中初步提供人員；
按項目實施計划模版，制定人力資源計划，對人員進行分工（項目經理、開發人員、QA、CM）。
⑷、什么地方記錄了項目干系人，如何確保干系人參與有效？
在項目實施計划中干系人管理計划中，干系人溝通記錄；
在與干系人溝通時，事前通知，事中控制、確認，事后分析。
⑸、項目關鍵依賴
依賴客戶，需要客戶提供需求和需求確認，以及系統部署、驗收測試。
四、量化管理及監控（QPM）實踐
1、度量點、統計技術的選擇准則：
度量點選擇准則：
（1） 與商業目標有關的度量點；
（2） 度量點能覆蓋項目生命周期；
（3） 度量是能夠被有效地正確地收集；
（4） 度量點是客觀的；
（5） 度量點有足夠的歷史數據;
（6）通過改變過程或子過程，度量點是可控制的；
統計技術的選擇准則：
（1）根據度量點的數據類型選擇統計技術，X/Y都是連續型變量，則選擇相關性分析和回歸分析；
（2）根據度量點的單值性，選擇單值-移動極差I-MR控制圖.
2、量化過程
⑴、量化執行過程圖
量化優化路徑說明：
⑵、MiniTab回歸預測
在每個子過程的前后，都需要進行回歸預測，例如需求評審前，預測需求評審缺陷移除率（RR_Defect）是否在基線范圍內（PPB-PPM），預測輸入是：
（RR_Size ）需求評審文檔正文頁數（單位：頁）；
（RR_Workload） 需求評審投入工作量（單位：人天）；
（RR_TL） 需求評審高級人員比例
⑶、蒙特卡洛模擬分析（水晶球）
在需求啟動和各個子過程階段后，使用CB:OptQuest，根據項目過程性能目標選擇最佳的過程或子過程的組合。選擇完之后將最佳方案的實現概率填寫到QPMPlan中。
3、量化管理結果達成規則（QPPO沖突）
達成概率>95%，接受
90—95%，關注風險，有10%-5%的概率達不到
<90%，協商（降低目標，不降低也只能接受，當風險管理）談判
補充：工作量（成本）是限定條件，量化管理就是達成成本與質量的平衡，綜合考慮，達到較好的性價比。如果，不滿足綜合性價比，則可以進行決策分析。
4、度量點在什么時候發生變化：
QPPO發生變化，過程發生變化，公司要求度量額外信息，導致度量點的變化，客戶提出的要求（個性化的要求，例如非標准度量要求）。
5、過程性能監控
使用統計過程控制技術，對每一次評審的性能進行監控。如果在子過程性能監控中發現過程不穩定時，需要分析異常原因，並且采取糾正措施。
過程性能監控說明子過程穩定性和有能力規則如下：
不能超過上下限；
不能出現連續7個上升；
在規格線之間表示有能力。
6、量化項目管理問題記錄
需要仔細分析量化項目管理問題記錄，包括原因及異常說明、應對措施、實施效果、圖表說明、固化措施（提交到EPG），詳細內容略。
7、開發過程量化分析與評審過程量化分析差異
⑴、預測缺陷注入率(RD_DIR\SD_DIR\CD_DIR)
在項目需求開發前獲取RD_Effort和RD_DE，使用Minitab中RD_DIR回歸公式預測RD_DIR的預測值、上限值和下限值，如果預測值不在基線范圍內，則需要調整RD_Effort和RD_DE，並重新預測。將調整后的因子和預測值填入需求開發前調整列。把RD_DIR的最新預測值定義成三角分布。
⑵、評審過程使用Minitab線性回歸預測缺陷移除率（DRR）在PPB-PPM范圍內
⑶、
五、原因分析與解決過程實踐
1、觸發條件（入口准則）
在量化分析子過程過程中，發生未達能力問題時，在調整因子或優化路徑情況下，無法達成QPPO，則根據體系文件《原因分析與解決過程》所規定的入口准則，啟動根因分析，由項目經理編制根因分析實施計划。
工作中，發生計划等活動中未預測到的事件（問題或好的方法），觸發根因分析，根因分析要使用預測模型。
2、過程
⑴、確定原因分析的范圍
⑵、分析原因，確定建議的改進措施
項目組（經理）組織項目相關人員，同樣采用魚骨圖（魚骨圖至少應分解到第三層）和Pareto圖等技術，分析問題和缺陷的根本原因，並制定改進措施。
⑶、制定行動計划
項目經理制定計划，經EPG批准后執行。
⑷、實施改進建議
項目組（經理）組織項目相關人員，在項目級QA的指導下，執行項目改進措施及建議。
⑸、評價實施效果
3、根因分析實踐
對項目單元測試過程進行分析，分析單元測試缺陷移除率低的原因，並制定改進實施方案。
⑴、要因分析：
對輸入、工具、人員、管理、過程、環境等原因，逐級深化分析，根因分析目標就是魚頭（UT_DRR低，單元測試缺陷移除率低的問題）。
⑵、做Pareto分析圖表
按二八原則，80%的問題是由於20%原因造成的，選出20%的問題進行改進方案。
⑶、應對方案
說明：AP－Action Proposal，行動方案；
H－高，M－中，L－低；
●－實施，○－暫緩實施，△－不實施
4、改進實施方案
●方案目標
通過改進方案的實施：
經過單元測試用例的重新梳理及測試用例評審提高單元測試用例的質量；
通過重新測試保證測試的充分性，提高代碼質量。
●活動名稱
重新整理單元測試用例
單元測試用例評審
對單元測試缺陷移除率低的模塊進行重新測試，並對后續模塊進行測試
跟蹤執行效果
進行效果評價
5、CAR實施效果評價報告
⑴、效果分析說明：
●統計分析結果說明：通過本次原因分析與解決工作的實施，改進前與改進后的RR_DRR改進效果說明如下：
●分析結論：
如上圖所示：CAR方案實施后，后續的單元測試模塊過程過程能力也得控制，穩定性也得到顯著提高。
因此判定本次CAR的執行有效。
⑵、固化改進成果
單元測試用例的質量對於單元測試過程至關重要，因此要加強單元測試用例的評審；
修改編碼與測試過程，刪除編碼與測試過程中單元測試用例可不進行評審的描述。
六、決策分析過程實踐
1、輸入：組織級過程體系文件《決策分析過程》、《決策分析指南》
入口准則：存在多個技術方案選擇時
2、決策准則
⑴、入口准則
全新標准產品立項時。
定制產品立項時。
存在多個技術方案選擇時。
決定全新開發、復用還是采購商用組件時，同時所做出的決定對項目的成敗或進度、成本影響大於50%時。
⑵、評估准則
評估准則選擇，依據體系文件中決策分析報告模版的“建議評估准則”。
3、評估方法
此次（項目僅有一次）評估方法為專家打分法（Delphi）。
評估常用方法有：SWOT分析、頭腦風暴法、決策樹分析法。
4、候選方案列表
方案一：自主開發消息管理
方案二：采用第三方消息中間件（IBM MQ）
5、實施過程與計划
項目經理根據項目前期的需求和方案，識別出兩套技術解決方案，根據組織級過程體系文件《決策分析過程》、《決策分析指南》和入口准則，編制“決策分析計划”，計划內容包括（開始時間為3月28日）：
決策問題描述：
制定決策分析計划：
成立決策小組：小組由項目組成員、項目QA、項目經理構成；
建立評估准則：根據待決策問題的特征，確定明確的評估准則和評分標准，填寫評估准則列表；
識別候選方案：尋找潛在的候選解決方案，填寫候選方案列表
確定評估方法：
評選候選方案：
完成決策分析：根據評估結果確定最終方案，填寫決策分析報告。
6、決策分析結果
根據兩種方案評估結果和可接受准則：方案一得分最高，並且評估項1達到60分，所以選擇方案一。
風險：對現有系統改造，改造質量影響系統穩定運行；應對措施：引入了代碼自動化檢查工具及測試工具，提升代碼質量
七、項目監控實踐
項目監控(Project Monitoringand ControlPMC)的目的是通過周期性地跟蹤項目計划的各種參數，如進度、工作量、資源、工作成果等，並不斷的了解項目進展情況，以便當項目實際進展狀況顯著偏離計划時能夠及時采取糾正措施。
1、監控依據
過程體系文件《項目監控過程》
模版：個人工作周報、項目工作周報、里程碑報告、例會會議紀要、外部干系人管理記錄
2、入口准則
項目計划已發布。
項目組人員已到位，並得到相關培訓。
3、監控輸入
項目實施計划
項目進度計划
質量保證計划與跟蹤表
配置管理計划與跟蹤表
風險管理跟蹤表
4、監控輸出
項目進度計划（已更新）
個人工作周報
項目工作周報
項目度量數據庫
里程碑報告
例會會議紀要
里程碑評審會議紀要
風險管理跟蹤表（已更新）
外部干系人管理記錄
5、證據舉例
以項目例會為例，在例會上監控內容和點如下：
工作進度及完成工作量，識別項目偏差並分析；
識別問題並分析問題；
識別風險並跟蹤風險，對項目風險進行規避，直至關閉；
按進度計划，安排組員的具體任務（TFS），並協調相關任務；
QA監控過程符合狀況；
進行干系人計划跟蹤，組織干系人參與里程碑會議和其他討論會。
八、度量實踐
1、度量體系簡介
⑴、度量目標
項目性能度量:監控項目性能，保證項目能夠按計划要求完成項目任務
產品質量度量:監控項目產品工作質量，保證項目能夠高質量地完成
需求變更度量:監控項目需求穩定性，保證通過需求管理及需求開發活動，減少需求變更
過程質量度量:監控項目過程質量，保證QA人員能夠了解項目成員對過程的遵守程度，識別不符合項高的過程加以指導和審計
項目規模度量:監控項目的規模，識別估計規模和實際規模的偏差
其它度量數據:監控各階段的評審和測試方式、資源投入、人員水平、各過程的復用率、覆蓋率、按期交付率
⑵、掙值分析
PV：計划工作量的預算成本
EV：已經完成工作量的預算成本
AC：已經完成工作量的實際成本。
進度偏差率(SV%)：進度偏差SV（SV=EV-PV）與計划工時的預算成本BCWS（PV）之間的比值
成本偏差率(CV%)：成本差異CV（CV=EV-AC）與已完成工時的預算成本BCWP（EV）的比值
進度性能指標(SPI)
成本性能指標(CPI)
2、度量數據收集來源
報工系統
技術評審報告
各類測試報告
周例會
3、度量數據記錄在度量數據庫里
4、度量過程
如上圖所示，度量是周期性的工作，發生在各個階段和里程碑點之后，數據來源於工作周報（報工系統）、技術評審報告、估算報告、測試計划和報告等，度量數據記錄在度量數據庫里。
5、度量分析
度量分析主要是在度量數據庫和里程碑報告中，結項報告是引用度量報告。
九、項目風險管理實踐
1、概述（基本概念補充）
⑴、風險應對策略
風險應對策略就是對已經識別的風險進行定性分析、定量分析和進行風險排序，制訂相應的應對措施和整體策略。
風險規避：是改變項目計划來消除特定風險事件的威脅。例如，對於開發過程中存在的技術風險，我們可以采用成熟的技術，團隊成員熟悉的技術或迭代式的開發過程等方法來規避風險。
風險轉移：是轉移風險的后果給第三方，通過合同的約定，由保證策略或者供應商擔保。
風險減輕：是減少不利的風險事件的后果和可能性到一個可以接受的范圍。通常在項目的早期采取風險減輕策略可以收到更好的效果。
風險接受：准備應對風險事件，包括積極的開發應急計划，或者消極的接受風險的后果。對於不可預見的風險，例如不可抗力；或者在風險規避，風險轉移或者風險減輕不可行，或者上述活動執行成本超過接受風險的情況下采用。
⑵、風險來源
來自那些不好的事情，或者是造成潛在問題的源頭：
不穩定的需求
復雜、不成熟的技術
過多的接口
客戶的配合情況
團隊技術水平低
（來源於公司資產庫——風險庫，項目個性化情況。）
⑶、風險分類
在風險管理指南中，風險分類定義有：需求、設計、編碼、測試、開發環境、人員、客戶、管理、質量、商業（市場）、其他。
2、識別風險與風險分析
⑴、識別風險
項目經理針對項目情況，綜合考慮項目成本、進度、質量、范圍等因素，項目經理組織風險分析小組進行識別風險活動，並將識別結果及時更新到《風險管理跟蹤表》中。
在識別風險過程中，需要明確風險項、風險來源、風險類別等要素，並參考《風險數據庫》。
風險識別方式：頭腦風暴法、假設法、訪談法、文檔審查法等。
⑵、風險分析
項目經理根據項目情況，組織風險分析小組對風險進行定性分析，確定每個風險項的“風險發生概率”、“風險影響范圍”，計算出風險系數，並及時更新到《風險管理跟蹤表》。
（風險系數=風險發生概率×風險影響范圍。）
風險影響范圍包括：范圍、成本、進度、質量等項，每項分為1～5級（例如成本5級划分如下：小於5%的成本增加、5%～10%的成本增加、11%～20%的成本增加、21%～30%的成本增加、大於30%的成本增加）。
風險發生概率也分成5級
3、風險應對措施/計划
首先，參考公司資產庫中的風險庫（風險列表），公司以往最佳實踐所提供的應對措施，業界常用的應對措施；
接着，是團隊的智慧，大家討論。
例如：在實施計划中安排培訓計划，減輕人力資源不足、不穩定的風險。
4、如何跟蹤風險，跟蹤哪些？
按項目實施計划，通過項目周例會，在風險跟蹤管理表上進行跟蹤風險。
跟蹤開放狀態風險及其應對措施
跟蹤重新分析
不斷識別新風險
風險跟蹤記錄在風險跟蹤管理表中。
5、舉例說明本項目風險跟蹤情況
本項目識別出8個風險項，主要風險是：
人力資源不足,資源負載嚴重，可能影響項目進度、質量，來源是不穩定的團隊；
不能按進度計划要求完成項目開發各階段任務，來源是技術不成熟。
十、技術評審與測試
1、技術評審概況
2、評審收集數據
評審規模、規模單位（例如頁數）
預評審工作量（人時）
評審人數
評審總工作量
缺陷數量
3、評審缺陷分類、等級
⑴、缺陷分類:
遺漏（M）：Missing，工作產品遺漏了必要的內容。
錯誤（W）：Wrong，工作產品存在錯誤。
其它（E）：Extra，其它不屬於以上兩類的缺陷。
⑵、缺陷等級（DefectSeverity）:
致命缺陷（A）：指被評審的工作產品存在結構上或內容上的缺陷，如果不進行修正后續的工作無法開展或造成軟件存在功能上的缺陷。
嚴重缺陷（B）：指被評審的工作產品存在內容上的缺陷，如果不進行修正后續的工作可能產生更為嚴重的缺陷。
一般缺陷（C）：指被評審的工作產品存在內容上的缺陷，如果不進行修正后續的工作基本不受影響，但可能對最終的軟件產品質量造成一定影響。
輕微缺陷（D）：指被評審的工作產品存在文字、規范等方面的缺陷，不會對最終的軟件產品質量造成影響。
十一、軟件開發過程中的知識點
1、需求跟蹤矩陣的兩個作用
跟蹤管理需求變更；
跟蹤需求實現完全覆蓋，保證需求與輸出產品完整一致。
2、需求變更評價及其影響分析
需求變更接受后，將涉及到計划調整，一般工期影響不大，主要是成本。
⑴、變更影響分析報告
⑵、變更控制跟蹤
變更申請->變更分析->變更審批->變更執行->變更驗證->重新入庫與發布
變更起止時間、狀態（開放、關閉）
3、變更影響值分析規則
注：
如果級別為1，需要由CCB審批后才可執行；
如果級別為2，需要CCB組長審批后即可執行；
如果級別為3，只要項目經理審批就可執行。
十二、過程建議及貢獻
1、建議采用商用級代碼檢查和自動化測試工具
例如：業界發明了程序靜態分析（Program StaticAnalysis）技術，靜態分析是指在不運行代碼的方式下，通過詞法分析、語法分析、控制流分析等技術對程序代碼進行掃描，驗證代碼是否滿足規范性、安全性、可靠性、可維護性等指標的一種代碼分析技術。它可以幫助軟件開發人員、質量保證人員查找代碼中存在的結構性錯誤、安全漏洞和代碼缺陷等問題，從而保證軟件的整體質量。靜態分析的特點是能夠在代碼研發的全周期協助開發人員優化代碼，縮短項目周期，降低研發成本，提高代碼質量。
建議采用商用軟件Klocwork Insight。
2、項目貢獻（對EPG貢獻）
⑴、貢獻有：
項目度量數據
項目經驗教訓（包括好的經驗、不好的教訓）
復用代碼
好的工作產品，例如設計、架構
CAR的輸出
⑵、經驗教訓舉例
在單元測試中，采用交叉測試，並提高測試用例的質量，對發現更多的缺陷有很大的幫助；
在設計階段同行評審中，由於組員臨時出差，找其他項目人員替代參與評審，評審時識別缺陷偏少，原因是替代人員對業務、技術架構不熟悉，很難識別問題，因此，在以后評審時，盡量安排項目組成員或對業務、技術較熟悉人員參與，例如，在后續評審時，通過經理協商，把出差人員抽調回來。
2013年11月1日補充。
---------------------
作者：肖永威
來源：CSDN
原文：https://blog.csdn.net/xiaoyw71/article/details/15338443
版權聲明：本文為博主原創文章，轉載請附上博文鏈接！