1、 項目評審制度及流程 1、 目的：主要是盡早發(fā)現(xiàn)潛在的問題，盡早糾正缺陷，控制項目整體進程。 2、 范圍：適用于研發(fā)中心項目評審工作。 3、 職責： 3.1 項目組長協(xié)助評審人員進行項目評審工作，并提交評審計劃。3.2 評審人員針對項目進行系統(tǒng)評審并撰寫評審報告。 3.3 評審人員應對評審完成發(fā)現(xiàn)的問題進行后續(xù)跟蹤處理。 4、 程序： 4.1 評審角色構成因素 評審人員的選擇是評審效果的關鍵，需要考慮以下因素： 項目重要性：項目重要性是決定角色構成的最重要的因素，先要根據項目的重要性而定。這與需要投入的成本有關，對于重要的項目一般會更多地投入資源，提高評審級別。 項目復雜度：項目的復雜度也是決

2、定角色構成的因素之一，根據溫伯格的公式，項目管理的復雜度相當于功能規(guī)模的平方數(shù)。筆者認為還應該考慮技術復雜度、技術新鮮度和文檔復雜度等因素。項目組成員的能力成分和水平。 項目組成員的能力成分和水平：評審角色構成還應當根據項目團隊成員本身的各項技術水平，特別是分析和設計的技術水平如何，行業(yè)領域知識是否豐富來進行搭配。除了團隊內部自己進行評審之外，評審團隊最好是一些獨立于項目團隊之外的成員構成。 應當注意的原則是人數(shù)要少而精，一個人可以兼多個角色，但要覆蓋各項人員需求。需要說明的是，不具備評審能力的不應參加，可以通過旁聽來提高水平。 4.2 基本角色職責 評審組長：制定評審計劃、確定或制定各項評審

3、準則、必要時組織評審人員進行培訓、組織必要的資源、進行評審分工、確保正式評審準備充分、分發(fā)待評審文檔、必要時召開并主持評審會議、向有關領導報告評審結果，并且跟蹤評審錯誤的改正。 評審人員：必要時參加與評審有關的培訓、按評審計劃閱讀待評審材料、保證對待評審材料的理解、與待評審材料作者討論，并且指出和記錄問題。 文檔作者：按評審計劃準備并按時提交待評審材料、必要時對材料進行解釋、必要時參加評審會議，并且在確定需要改進時按時完成修改。 記錄人員：評審會議中記錄評審人員提出的問題及相關討論。 項目經理：制定保證評審和改正的項目進度計劃，還要確保評審準備時間、評審會議時間及錯誤的改正時間。而且評審安排及

4、結果與所有項目成員溝通，必要時參加評審會議、閱讀評審報告、分析缺陷原因，并且改進項目質量。 4.3 文檔評審的層次 過程規(guī)范：是否符合過程規(guī)范、是否按照計劃提交、是否按時經過評審、是否準時發(fā)布（注意提交時間與發(fā)布時間的區(qū)別），以及評審的流程是否規(guī)范。 文檔規(guī)范：文檔成果符合企業(yè)或業(yè)界已經制定的文檔模板規(guī)范。企業(yè)，甚至行業(yè)應當制定統(tǒng)一的文檔規(guī)范，形成一個文檔約定和規(guī)則，以統(tǒng)一文檔內容與風格。 文檔語法：文檔成果正確使用通用的方法與術語并符合軟件工程相關的技術標準，這里所說的語法包括自然語言的語法和建模語言的語法。適合的評審人員要求：精通軟件工程、分析與設計方法、建模工具和相關標準。 文檔語義：文

5、檔成果表達清晰、無歧義，可以反映系統(tǒng)目標。所有質量合格的文檔 （包括模型）都代表它期望代表的語義，而且應該在代表這些語義時具有一致性。文字與圖表應當互相補充說明，以更加清晰。讓別人看得懂，看完后知道下一步該 怎么做。 適合的評審人員：行業(yè)業(yè)務專家、高級程序員和測試工程師。 文檔邏輯：主要體現(xiàn)需求與設計正確性、一致性，無遺漏、多余或錯誤。前后左右 考慮周全，不同文檔之間、文檔與行業(yè)標準之間、同一文檔各成分之間不互相矛盾，清晰說明相關部分之間的關系，特別是要符合相關行業(yè)的業(yè)務標準規(guī)范。 適合的評審人員：行業(yè)業(yè)務專家、產品經理和測試工程師。 文檔美學：文檔成果能否表述得更好一些，文字、圖表是否能更加

6、均衡和完整。 需要追求平衡的美，每個組成部分應該大小適中，可解讀并可變更。平衡有多個方 面，如排版次序更加合理、文字、圖形更加精煉并更易理解等。適合的評審人員：系統(tǒng)分析與設計師。 結果優(yōu)化：通過檢查判斷文檔成果（如項目計劃、需求規(guī)格及設計方案）是否還有改進的空間，以便更加方便地進行項目管理、降低成本、加快進度、提高質量并減少風險，盡可能達到最佳方案。任何一項設計都可以有許多不同的方案，通過“方案優(yōu)化”選定一種最好的方案。 適合的評審人員：系統(tǒng)分析與設計師、項目經理和產品經理。 4.4 文檔評審流程 4.4.1 評審流程概覽和流程圖 確定評審組長。 制定并發(fā)布評審計劃。 準備評審。 舉行評審會議

7、。 改正、跟蹤和回歸評審。 分析、總結和報告。 歸檔。 4.4.2 確定評審組長 由品質保證人員與項目經理、部門經理論協(xié)商，確定項目的評審級別及評審人員角色構成要求，初步確定評審組長人選。品質保證人員與評審組長溝通，最終確定評審組長。評審組長充分了解項目相關情況，為制定評審計劃做好準備。 4.4.3 評審計劃 評審組長制定評審計劃（根據項目計劃和質量計劃） 。 評審組長確定評審對象和評審時間。 評審組長確定評審級別和策略（形式的組合）。 評審組長確定評審流程裁減和提交物。 評審組長確定入口條件并通過準則。 評審組長確定回歸評審準則。 評審組長制定評審檢查表（CheckList）。 評審組長確定

8、評審角色構成。 評審組長根據評審角色構成確定評審人員并成立評審小組。 相關人員（評審人員和項目團隊雙方）確認評審計劃。評審組長發(fā)布評審計劃。 4.4.4 評審準備 正式評審前準備：文檔作者向相關人員發(fā)布文檔。 評審人員閱讀了解文檔，爭取發(fā)現(xiàn)大部分問題。 文檔作者解決大部分發(fā)現(xiàn)的問題。 評審組長確定會議地點、環(huán)境、設備和所有材料。 評審組長確定人員職責和會議議程。 評審組長確定評審開始條件成熟。 評審組長通知相關人員到會。 4.4.5 評審會議 主持人（評審組長）宣布會議議程、人員職責和會場紀律。 文檔作者介紹工作成果，對評審人員的疑問進行必要的解釋。 評審人員對不解之處提出疑問，指出問題或缺陷

9、并說明根據。 文檔作者與評審人員討論缺陷的真實性，分清缺陷性問題和建議性問題，討論確定是否需要按照評審人員的要求進行改進。一般不涉及為節(jié)省時間改進方案或錯誤的糾正方案。 4.4.6 評審記錄 正式評審應當記錄有共識的問題或缺陷，也要記錄有爭議待解決的問題。使評審工 作文檔化，便于跟蹤最終解決。 總體記錄：包括項目名稱、系統(tǒng)名稱版本號、 日期時間、 主文檔名稱、附文檔名稱、 文檔版本號、作者、評審類型（首次、回歸、部分和階段） 、評審人員和評審結論。 缺陷記錄：包括缺陷編號、提出者、章節(jié)頁碼、缺陷描述、缺陷類型（嚴重、一 般和建議）和承諾改正時間。 驗證記錄：全部打勾的 CheckList，說明

10、 CheckList 所列的工作都已經做完，所列的內容都已經評審完，確保工作的完整性。 4.4.7 評審結論評審結論包括如下內容： 是否需要修改？這是就成果的整體而言，結論可以是無需、少量、較大或是一個量化的數(shù)字。 項目組確定是否接受修改要求？這是針對具體的一條意見或建議。有些問題可能是 誤會，消除了就不是問題；有些建議性的問題，項目組考慮進度可不接受修改要求。 如不接受修改要求，項目組給出不修改的理由。 如何處理？是否需要進行回歸評審？ 總體結論：合格或不合格。 確定的修改責任人和跟蹤責任人。 確定的回歸評審時間。 是否都認同評審結論？如果需要做得更正式一些，可以要求相關人員簽字表示同意評審

11、結論，簽字 。 4.4.8 跟蹤與總結 評審中發(fā)現(xiàn)的問題的后續(xù)跟蹤是改正錯誤并消除缺陷的有效措施， 應當有專門的負責人進行后續(xù)跟蹤確認錯誤都已改正，根據結論必要時回歸評審。 評審組長分析評審數(shù)據并總結經驗。 評審組長發(fā)布評審記錄與數(shù)據分析報告。 管理人員應當防止評審數(shù)據被不恰當?shù)厥褂?，如果使用評審數(shù)據來對個人進行績效 評價，將會給以后的評審工作造成障礙，使評審各方不能放開進行評審。 評審組長進行工作總結，工作總結很有必要，有利于對項目或過程的改進。 評審組長提交各類評審報告，有關領導批準發(fā)布通過的文檔。 4.4.9 材料歸檔 評審材料歸檔是項目配置管理工作的一部分。新建項目，記載配置管理工具中為此項目建立一個目錄，并建立下列子目錄。 待評閱態(tài)：文件放入此目錄后會自動通過郵件通知需要評閱的人員，全體評閱人員評閱完畢，也會自動通過郵件把意見通知文檔作者并實現(xiàn)到期自動提醒功能。 待評審態(tài)：文件放入此目錄后會自動通過郵件通知需要評審的人員，全體評閱人員