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

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

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

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

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

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

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

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

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

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

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