在軟體專案管理中，總是把估計值當作承諾，無論是對自已或對同事，都會造成不必要的焦慮。為避免此類困境，就算最後期限迫在眉睫，你也能專注於該做的事。然而也應該做到隨時溝通，讓相關人員看到事情進展。

   專案管理過程方針：規範產品/專案立項和結項過程，制定合理的專案計劃，並據此對專案進行跟蹤，建立對專案監控的可視性，使專案管理者能在專案執行明顯偏離專案計劃時及時採取有效的糾正措施。

   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
版權宣告：本文為博主原創文章，轉載請附上博文連結！