qileilove

　　同行評審（Technical Review, TR）的目的是盡早地發現工作成果中的缺陷，并幫助開發人員及時消除缺陷，從而有效地提高產品的質量。

　　2、適用范圍（必寫）

　　適用于西安聯合信息技術股份有限公司項目開發部的所有項目。

　　3、定義

　　PDP(Project Define Process)項目自定義過程。

　　4、過程概要

　　同行評審為了提高軟件質量和提高程序員生產率而被普遍應用的評審方法，在業界已取得很好效果。同行評審能夠在任何開發階段執行，它可以比測試更早地發現并消除工作成果中的缺陷。同行評審的主要好處有：

　　● 通過消除工作成果的缺陷而提高產品的質量。

　　● 越早消除缺陷就越能降低開發成本。

　　● 開發人員能夠及時地得到同行專家的幫助和指導，無疑會加深對工作成果的理解，更好地預防缺陷，一定程度上提高了開發生產率。

　　同行評審包含三個活動：制定同行評審計劃、執行評審、評審缺陷管理。可在項目制定項目計劃時，同時制定同行評審計劃。

　　同行評審有以下四種基本類型：

　　● 單人評審

　　● 評審三角

　　● 組評審

　　● 走查

　　評審類型一般視工作成果的重要性和復雜性而定。其中組評審和走查需要參與人員多，為了節約時間，允許人們有選擇地對工作成果進行組評審和走查。

　　4.1 制定同行評審計劃

　　4.1.1 活動目的

　　確定需要評審的工作成果、評審方式，預定評審時間、地點以及相關人員。

　　4.1.2 啟動條件

　　《項目計劃》已啟動

　　4.1.3 輸入

　　需求文檔、開發計劃、PDP。

　　4.1.4 角色與職責

　　部門副總裁，SQA，項目經理。

　　4.1.5 主要步驟

　　1）確定被評審對象

　　項目經理確定工作產品清單后，同部門副總裁和SQA協商確定，需要進行評審的工作產品。

　　2）確定評審類型

　　部門副總裁通過權衡工作產品的范圍和業務影響（有多少時間適合分配給同行評審活動），選擇適當的同行評審類型。

　　3）說明評審要點

　　4）說明參加角色

　　5）發布審批

　　項目經理負責在項目計劃階段發布項目內部關于同行評審活動的約定（工作產品的同行評審計劃）將發布內容整合到項目計劃，在進度和資源方面給項目組內同行評審活動開展提供必要保障。

　　4.1.6 輸出

　　同行評審計劃（列入《同行評審管理表》中）

　　4.1.7 退出條件

　　同行評審計劃（列入《同行評審管理表》中），通過評審批準時

　　4.1.8 方法

　　無

　　4.1.9 工具

　　無

　　4.2.1 活動目的

　　對代碼進行快速、靈活地評審，及早地識別和消除工作成果中存在的缺陷。

　　4.2.2 啟動條件

　　代碼完成時；

　　4.2.3 輸入

　　代碼

　　4.2.4 角色與職責

　　開發組成員/組長。

　　4.2.5 主要步驟

　　開發組成員完成各自負責代碼后，由同組其他成員或者組長來進行代碼評審，評審結果可錄入《缺陷統計表》或者直接在代碼中體現。

　　4.2.6 輸出

　　缺陷統計表

　　4.2.7 退出條件

　　評審缺陷移除時

　　4.2.8 方法

　　見同行評審PPT中關于評審要點的描述

　　4.2.9 工具

　　無。

　　4.3 組評審

　　4.3.1 活動目的

　　對工作成果進行正式組評審，盡早地發現工作成果中的缺陷，幫助開發人員及時消除缺陷，促進項目組對被查對象和標準的共同理解。

　　4.3.2 啟動條件

　　工程師已完成工作成果，并已對工作成果進行了內部檢查，消除了拼寫、排版等初級錯誤。

　　4.3.3 輸入

　　待評審的工作成果和與該工作成果評審相關的一些材料，如評審檢查表。

　　4.3.4 角色與職責

　　評審組：項目相關干系人，相關部門經理，相關部門副總裁（根據需要選擇人員）

　　4.3.5 主要步驟

　　● 部門副總裁首先確定會議的人員名單，確定評審會議的時間、地點、設備，然后起草《同行評審通知》，確定評審議程和流程。

　　● 項目經理發布同行評審通知，同時把工作成果及相關材料、評審議程、檢查表等發給參與會議的評審組成員

　　● 評審組審閱工作成果及相關材料，發現缺陷并記錄在《缺陷統計表》中。

　　● 配置管理員記錄匯總各評審員缺陷表，并更新。

　　[Step2]評審

　　● [Step2.1] 主持人（項目經理）宣講

　　→ 主持人宣講本次評審會議的議程、重點、原則、時間限制等。

　　● [Step2.2] 作者（項目組）介紹工作成果

　　→ 作者扼要地介紹工作成果。

　　● [Step2.3] 識別缺陷和答辯

　　→ 評審組根據“缺陷表”提出查找到的缺陷。

　　→ 作者根據缺陷進行答辯，雙方要對每個缺陷達成共識（避免誤解）。

　　● [Step2.4] 討論缺陷解決方案

　　→ 作者和評審組共同討論缺陷的解決方案。

　　→ 對于當場難以解決的問題，由主持人決定“是否有必要繼續討論”或者“另定時間再討論”。

　　● [Step2.5] 會議結束決議

　　→ 針對所有缺陷給出評審結論和意見，主持人簽字后本次會議結束。評審結論有三種：

　　（1）工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。

　　（2）工作成果基本合格，需要作少量的修改，之后通過審核即可。

　　（3）工作成果不合格，需要作比較大的修改，之后必須重新對其評審。

　　[Step3] 修正、跟蹤與審核

　　● [Step3.1] 修正與跟蹤

　　→ 作者修正工作成果，消除已發現的缺陷。

　　→ 項目經理及SQA跟蹤每個缺陷的狀態。

　　● [Step3.2] 提交審核

　　→ 作者消除所有已發現的缺陷后，再將修正后的工作成果遞交給評審組審核。

　　● [Step3.2] 審核工作成果

　　→ 評審組審核修正后的工作成果。審核結論有兩種：

　　（1）修正后的工作成果合格。

　　（2）修正后的工作成果仍然不合格，需重新修改，重復[Step3]。

　　4.3.6 輸出

　　缺陷統計表、評審記錄表（列入《同行評審管理表》中）

　　4.3.7 退出條件

　　評審缺陷關閉并且工作成果經過審核后合格。

　　4.3.8 方法

　　見同行評審PPT中關于評審要點的描述。

　　4.3.9 工具

　　《評審檢查表》

　　4.4.1 活動目的

　　盡早地將缺陷移除；促進項目組對被查對象和標準的共同理解

　　4.4.2 啟動條件

　　執行走查的工作成果完成時

　　4.4.3 輸入

　　管理類文檔產物、代碼、 項目Demo以及與工作成果評審相關的一些材料，如評審檢查表。

　　4.4.4 角色與職責

　　評審組：項目相關干系人，相關部門經理，相關部門副總裁（根據需要選擇人員）

　　4.4.5 主要步驟

　　[Step1]評審

　　● [Step1.1] 主持人（項目經理）宣講

　　→ 主持人宣講本次評審會議的議程、重點、原則、時間限制等。

　　● [Step1.2] 作者介紹工作成果

　　→ 作者扼要地介紹工作成果。

　　● [Step1.3] 識別缺陷和答辯

　　→ 評審組根據“缺陷表”提出查找到的缺陷。

　　→ 作者根據缺陷進行答辯，雙方要對每個缺陷達成共識（避免誤解）。

　　● [Step1.4] 討論缺陷解決方案

　　→ 作者和評審組共同討論缺陷的解決方案。

　　→ 對于當場難以解決的問題，由主持人決定“是否有必要繼續討論”或者“另定時間再討論”。

　　● [Step1.5] 會議結束決議

　　針對所有缺陷給出評審結論和意見，主持人發起評審結論的確定，如評審組無法形成多數統一意見，由評審組最高領導作出最終判斷。

　　→ 評審結論有三種：

　　（4）工作成果合格，“無需修改”或者“需要輕微修改但不必再審核”。

　　（5）工作成果基本合格，需要作少量的修改，之后通過審核即可。

　　（6）工作成果不合格，需要作比較大的修改，之后必須重新對其評審。

字體:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿 

　　[Step2] 修正、跟蹤與審核

　　● [Step2.1] 修正與跟蹤

　　→ 作者修正工作成果，消除已發現的缺陷。

　　→ 評審主持人和SQA跟蹤每個缺陷的狀態。

　　● [Step2.2] 提交審核

　　→ 作者消除所有已發現的缺陷后，再將修正后的工作成果遞交給評審組審核。

　　● [Step2.3] 審核工作成果

　　→ 評審主持人（或者指定審查員）審核修正后的工作成果。審核結論有兩種：

　　（3）修正后的工作成果合格。

　　（4）修正后的工作成果仍然不合格，需重新修改，重復[Step3]。

　　4.4.6 輸出

　　缺陷統計表、評審記錄表（列入《同行評審管理表》中）

　　4.4.7 退出條件

　　評審缺陷關閉并且工作成果經過審核合格時。

　　4.4.8 方法

　　見同行評審PPT中關于評審要點的描述

　　4.4.9 工具

　　《評審檢查表》

　　5、實施建議

　　希望最早進行此過程的培訓，讓評審人員明確目的、各評審人的職責，評審關注點。

　　不同設計時，不同角色評審人員關注點。

　　裁剪建議：可根據項目特點裁剪部分項目成果的評審。

　　6、涉及到的相關文件和表單

　　《評審檢查表》

　　《缺陷統計表》

　　《同行評審管理表》