評審規程V1

2022-12-24 06:42:03 字數 2864 閱讀 1579

評審過程

文件編號:ver _prs

文件資訊:公司級別過程檔案

文件名稱:評審過程

文件類別:工程過程類

密級:內部

版本資訊:1.0

建立日期:

建立人:

審核者:

批准人:

批准日期:

保管人:

存放位置:

文件修訂記錄

*變化狀態:a——增加,m——修改,d——刪除

文件審批資訊

目錄1 簡介 4

1.1 目的 4

1.2 適用範圍 4

1.3 背景描述 4

1.4 引用檔案 4

1.5 術語表 4

1.6 參考資料 5

2 過程/規程總體描述 5

2.1 過程/規程概述 5

2.2 過程/規程結構描述 5

3 過程/規程元素描述 7

3.1 制定專案評審計畫 7

3.2 制定評審任務計畫 9

3.3 正式評審 11

3.4 填寫評審總結報告 14

3.5 修改評審缺陷 15

3.6 跟蹤評審缺陷 17

4 附錄 20

4.1 附錄a-相關過程 20

4.2 附錄b-相關規程 20

4.3 附錄c-相關指南 20

4.4 附錄d-相關模板列表 20

圖索引:

圖表 1 評審過程流圖 6

圖表 2 預審過程流圖 12

圖表 3 形成評審結論過程流圖 15

本文的目的是為在開發軟體專案上成功地執行各種評審活動所提供的評審過程框架。

本文件適用於組織內的各軟體專案的評審活動。

無● 《質量保證過程檔案編號:nfs-china-qm_qa_prs

● 《度量分析過程檔案編號:nfs-china-qm_ma_prs

● 《軟體測試過程檔案編號:nfs-china-qm_vv_test_prs

● 作者或產品責任人:建立或維護被評審的工作產品的個體。

● 初始交付產品:由作者交付的等待評審的工作產品。

● 評審產品描述者:評審會議的乙個參與者,他需要在評審會議上向其他評審者描述所評審的產品。

● 評審會議記錄者:評審會議的乙個參與者,他需要在評審會議上記錄評審中發現的所有問題和缺陷,並記錄在《評審會議記錄》中。

● 因果分析:評審的乙個階段,評審者追查每乙個所發現的缺陷的產生原因,並確定阻止該類缺陷再出現的辦法。

● 缺陷檢查表:在一類指定的工作產品中所發現的缺陷種類的列表。

● 可交付產品:在工程專案的執行過程中產生的臨時的或最後的文件、程式、檔案或其他工件,在本過程中同「工作產品」。

● 評審材料包:由工作產品的作者和評審組長評審會之前分發給評審人員的一組材料,包括被評審的工作產品及定義其規格說明的文件、標準、必要的表單、檢查表和規則集,以及測試文件等。

● 評審組長:領導評審活動,也稱為評審領導。他負責同作者一起計畫評審活動,制定進度,布置會議,從其領導的評審活動中收集和報告測量資料,並可能參與驗證作者的返工結果。

評審組長通常由質量保證人員兼任,產品作者不應充當該角色。

● 規則:指導作者以特定的方式完成任務和產品文件的語句或標準。

● 工作產品:在開發過程中所產生的文件、程式或其他成品,可能是專案中間產品或最終發布的產品,以及一些支援專案成功開發的支援性文件。例如專案計畫、需求規格說明、設計文件、使用者介面設計、源**、測試文件、使用者及系統文件、培訓材料,以及過程文件等。

● paulk, mark c., et al. capability maturity model for software, version 1.

1 cmu/sei-93-tr-24

● paulk, mark c., et al. key practices of the capability maturity model, version 1.

1, cmu/sei-93-tr-25

● national aeronautics and space administration. software formal inspections guidebook, nasa-gb-a302

● wiegers, karl e. peer reviews in software: a practical guide. addison-wesley, 2002.

● instructional handbook for formal inspections. downloaded from web

● wiegers, karl e. seven truths about peer reviews.

評審的目的是由一組有資格的人員對軟體設計和開發的輸出進行評價,以判斷確定設計和開發的輸出能否實現軟體產品預先定義的規格,同時通過評審標識出與規格和標準的偏差。它向管理部門提供充足的證據以證明:

1)設計和開發的輸出符合了其規格要求;

2)設計和開發的輸出是否滿足相關法律、法規以及企業標準的要求;

3)軟體產品的更改得到了恰當地實施;

4)軟體產品的更改只對那些規格發生了更改的系統區域有影響,沒有引入新的問題。

評審應該遵守幾項基本的原則:

1) 保持公正客觀的態度;

2) 評審針對工作產品,而不是個人;

3) 評審的目的是發現問題,從而解決問題;

4) 盡量保持小型的評審小組;

5) 評審會議時間不宜過長;

6) 評審前必須先做準備。

評審活動的過程結構圖如下所示。

專案計畫v1

摘要 簡要描述該文件的內容。修改歷史 注釋 評審號為評審記錄表的編號。更改請求號為文件更改控制工具自動生成的編號。正式批准 注釋 1.可以根據專案情況定製表中的角色。2.直接參與或與專案有密切聯絡的其它組織或部門 包含內部和外部 負責人的簽名。目錄1 概述 5 1.1 專案介紹 5 1.2 範圍 5...

專利撰寫格式V1

本發明公開了 本發明的方法包括 本發明技術方案能夠。例如有效提公升安全性 先註明選擇附圖幾,待檔案正式提交時再從說明書附圖中拷貝貼上。1 一種。方法,其特徵在於,包括 2 根據權利要求1所述的。方法,其特徵在於 5 一種。系統,其特徵在於 6 根據權利要求5所述的。系統,其特徵在於 一種。方法及系統...

專案管理規範v1

專案文件管理規範 金蝶建築與房地產事業部 實施管理部 目錄1.目的 3 2.範圍 3 3.文件發布標準 3 4.文件變更標準 4 5.文件歸檔標準 4 6.專案文件範圍 5 7.文件審計標準 6 附件 10 在專案生命週期中會形成很多文件資料,包括工作文件和技術文件。這些文件資料是未來進行系統維護 ...