1、1 目的及適用范圍1.1 為規范產品研發過程，提高產品研發的效率、質量，降低研發成本，特制定本程序；1.2 本程序文件適用于侏羅紀公司產品研發；1.3 本程序文件由侏羅紀公司 制定，其解釋權及修改權屬于 ；1.4 本程序文件從2003年 月 日起執行；2 職責2.1 產品部負責產品研發；2.2 質量控制部負責對產品開發過程中的里程碑產生的相關成果和文檔進行質量控制，并將符合規范的成果放入資源中心存檔；2.3 技術支持部和市場部負責宣傳材料和用戶手冊的制作，以及和產品銷售流程的銜接環節和動作；3 產品研發流程3.1 技術副總從公司戰略規劃決案中形成產品規劃，下發給技術研發部；3.2 技術研發部經

2、理進行產品研發立項；3.3 公司組織人員對產品立項進行評審，若評審未通過，相關文檔放入行政綜合部備案；3.4 若立項評審通過，質量保證部對立項進行質量檢驗，若質檢未通過，修改立項報告；3.5 若質檢通過，開始制訂項目計劃，同時質量保證部將立項相關文檔放入行政綜合部歸檔；3.6 技術部經理將項目計劃提交給技術副總評審，若未通過，技術部經理修改項目計劃；3.7 若評審通過，質量控制部對項目計劃進行評審，若質檢評審未通過，產品經理修改項目計劃，若質檢評審通過，產品總監安排研發項目資源；3.8 產品經理獲得研發項目資源后，進行需求分析，并將相關成果交技術委員會進行內容評審；3.9 若內容評審未通過，產

3、品經理修改需求分析；若內容評審通過，質量控制部對需求分析說明進行質量檢驗；3.10 若質檢未通過，產品經理修改需求分析說明，若質檢通過，相關成果和文檔放入資源管理部歸檔，同時產品經理帶領研發相關人員進行總體設計；3.11 產品經理和研發人員完成總體設計后將相關成果交技術委員會進行內容評審；3.12 若內容評審未通過，產品經理修改總體設計說明；若內容評審通過，質量控制部對總體設計說明進行質量檢驗；3.13 若質檢未通過，產品經理修改總體設計說明，若質檢通過，相關成果和文檔放入資源管理部歸檔，同時產品經理和研發人員進行程序設計/測試；3.14 完成程序設計/測試后，產品經理將相關成果交質量控制部進

4、行功能測試，若測試未通過，產品經理修改相關成果，若測試通過，質量控制部對相關成果和文檔進行質量檢驗；3.15 若質檢未通過，產品經理修改相關成果和文檔；若質檢通過，質量控制部將相關成果和文檔放入資源管理部門歸檔；3.16 同時產品研發組制作軟件，技術支持部和市場部制作宣傳材料，之后，技術支持部對銷售人員進行內部培訓，市場部申請并取得著作權；3.17 市場部在取得著作權后制作用戶/技術手冊；3.18 產品研發組完成軟件制作后，質量控制部對制作的軟件進行質量檢驗，若未通過質檢，產品研發組重新制作軟件；若通過質檢，相關成果和文檔放入資源管理部歸檔，同時產品經理進行產品研發總結；3.19 質量控制部將

5、產品研發總結等相關成果和文檔放入資源管理部，同時市場部進行軟件產品包裝，銷售部進行產品銷售；4 相關文件4.1 產品規劃說明書 4.2 立項報告 4.3 綜合評審記錄4.4 質量控制立項報告和可行性分析報告說明書4.5 項目計劃書4.6 質量控制項目計劃評審記錄4.7 資源調度單4.8 需求分析說明書4.9 質量控制需求分析說明書評審報告4.10 資源中心驗收單4.11 評審規程4.12 總體設計說明書4.13 概要設計說明書4.14 詳細設計說明書4.15 質量控制系統設計報告評審記錄4.16 著作權相關文檔（略）4.17 軟件質量保證單4.18 軟件缺陷報告4.19 項目總結產品規劃說明書

6、公司三年產品規劃1. 2. 3. 公司年度產品計劃1. 2. 簽發人：時間合評審記錄（公司）評審對象（項目名稱及編號）評審項類（如合同、投標方案等）評審人時間業務板塊(產品中心、項目中心、服務中心、營銷中心)評審意見財務部評審意見質量控制部評審意見技術委員會評審意見專家委員會評審意見最終意見：通過修改修改內容時間立項報告評審記錄記錄編號： - 時間： 年 月 日立項建議報告名稱：編制人：參加人員：評審內容(審議通過的內容在“”中劃“”，否則劃“×”)： 1）項目啟動的背景； 2）項目的目的（合同意向或內部領導的要求）； 3）項目的范圍（項目所涉及的主要活動）； 4）項目的可行性（如，

7、人力、技術資源的可利用性）； 5）項目存在風險與控制； 6）項目的重要里程碑和主要提交產品； 7）項目的規模（估計所需的工作量和資源種類）； 8）項目啟動的預算（項目啟動所需的資源）； 9）項目市場前景及效益的簡要分析。 評審意見：評審結論:填表審批1 本頁不足記述評審意見時，可以加入附頁，附頁格式自行設計，總頁數包括本頁與所有附頁。第 頁/共 頁可行性分析報告評審記錄記錄編號： - 時間： 年 月 日可行性分析報告編號：可行性分析報告名稱：編制部門：編制人：參加人員:評審內容:(評審中審議通過的內容在“”中劃“”否則劃“×”)：1) 軟件產品功能要點及產品化程度書 2) 量化的市場

8、前景、效益分析和競爭對手分析 3) 開發優勢 4) 技術路線 5) 成本估算 6) 進度估算 7) 可用的現行技術、重用軟件和開發平臺 評審意見:評審結論：填表審批1 本頁不足記述評審意見時，可以加入附頁，附頁格式自行設計，總頁數包括本頁與所有附頁。第 頁/共 頁項目計劃書項目名稱項目編號項目經理項目任務描述項目總時間及關鍵里程碑設置項目資源（人力、技術、設備）項目費用預計審批人意見：總監： 副總監： 執委會：備注：抄送財務部、人力資源部時間項目啟動計劃評審記錄記錄編號： 時間： 年 月 日項目編號：項目名稱：項目啟動計劃編號：開發部門：PM：評審地點：參加評審人員:評審內容(評審中審議通過的

9、內容在“”中劃“”否則劃“×”)：1) 項目的目的是否明確？ 2) 對項目的規模是否進行估算？ 3) 是否進行項目啟動的預算？ 4) 階段輸出結果是否明確？ 5) 其它方面評審意見：評審結論：填表：審批：1. 項目啟動計劃評審由項目管理部門組織評審。2. 評審完成后由開發體系決策層SMG批準。3. 本頁不足記述結果時，可以加入附頁，附頁格式自行設計，總頁數包括本頁與所有附頁。第 頁/共 頁開發計劃評審記錄記錄編號： 時間： 年 月 日項目編號：項目名稱：項目計劃編號：開發部門：PSM：評審地點：參加評審人員:評審內容：評審意見：評審結論：填表：審批：1. 開發計劃評審由項目管理部門組

10、織評審。2. 評審完成后由開發體系決策層SMG批準。3. 本頁不足記述結果時，可以加入附頁，附頁格式自行設計，總頁數包括本頁與所有附頁。第 頁/共 頁開發計劃檢查表（開發計劃評審附頁）軟件問題報告記錄編號： - 時間： 年 月 日項目編號：項目名稱：軟件項編號：軟件項名稱：版本號：問題描述：報告人簽字/日期:修改描述（主要是修改后與修改前的對比，如所用資源的變化、提交時間的變化、功能的變化等）：修改人簽字/日期：填寫：審批：1.問題描述欄中可以填寫問題現象及其產生原因，如果有用戶的書面說明，則可以直接引用。2.修改描述一欄描述問題的確切原因、修改辦法以及修改后的效果。3.本頁不足記述時，可以有

11、附頁，格式自定?？傢摂蛋ū卷撆c所有附頁。項目資源調度單（借鑒產品中心任務書）項目名稱項目編號項目經理項目的跨中心（部門）資源調度緣由及申請人審批人正式調用時間：起：止：備注：抄送財務、人力資源部時間軟件需求分析說明書1. 引言1.1 目的說明編寫軟件需求說明書的目的，指出預期的讀者。1.2 背景（1） 待開發的軟件系統的名稱；（2） 本項目的任務提出者、開發者、用戶及實現該軟件的計算中心或計算機網絡；（3） 該軟件系統同其他系統或其他機構的基本的相互來往關系。1.3 參考資料列出所用的參考資料，如：（1） 本項目的經核準的計劃任務書或合同、上級機關的批文；（2） 屬于本項目的其他已發表的文件

12、；（3） 本文件中各處引用的文件、資料，包括所需用到的軟件開發標準。（4） 列出這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。1.4 術語列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。2. 項目概述本部分描述影響產品和其需求的一般因素。此處并不說明具體的需求，其描述的內容僅僅是為了更容易理解、深化需求規格，其用意是為從多方面、多角度考慮需求以提供思維參考點。2.1 一般描述本節描述軟件開發項目的意圖、應用目標、作用范圍以及其他應向讀者說明的有關該軟件開發的背景材料，解釋待開發產品和其相關的其他產品或項目的關系。l 如果本產品是獨立的，而且自含全部

13、內容，應在此說明。l 如果所定義的產品是一個較大系統或項目中的一個組成部分，那么在此需要描述如下內容：u 要概述這個較大的系統或項目的每一個組成部分的功能，并說明其接口；u 指出本產品主要的外部接口（不需要詳細描述，詳細描述放在其他章節中）；u 描述所使用的計算機硬件、外圍設備。這里僅僅是一個綜述性描述?！炯记伞吭诒竟澋拿枋鲋?，用一個方框圖來表達一個較大的系統或項目的主要組成部分、相互聯系和外部接口是非常有幫助的。【提醒注意】本節所描述的既不是設計方案，也不是在方案設計時的約束條件，它僅僅為方案設計時的約束條件提供了一個可以解釋的理由。2.2 功能簡述對待的軟件產品功能提供一個摘要?！炯记伞縰

14、 編制功能的一種方法是制作功能表，以便客戶或第一次讀這個文件的人很容易理解；u 用方框圖來表達不同的功能和它們的關系有益于理解。【提醒注意】u 方框圖不是產品的設計，而只是一種有效的解釋方式。u 本節不是具體需求的陳述，只是對具體需求部分中為什么要對一些需求做出描述的鋪墊。2.3 用戶特點本節描述產品最終用戶（包括操作員、維護員和系統工作人員等）具有的受教育水平、工作經驗及技術專長等一般特點。如果系統的大多數用戶是一些臨時的用戶，那么就要求系統包含如何完成基本功能的提示，而不是假設用戶已經從過去的會議或從閱讀用戶指南中了解到這些細節。2.4 假定和約束給出影響軟件需求說明書中陳述的需求的每一個

15、因素。這些因素不是軟件的設計約束，但是它們的改變可能影響到需求說明書中的需求。這些假定和約束條件可能包括：管理方針；運行環境，包括硬件設備和支持軟件的限制；與其他應用間的接口；并行操作；實時功能；審查功能；控制功能；所需的高級語言；通信協議；應用的臨界點；安全保密方面的考慮等。【提醒注意】u 本節中描述的因素是軟件需求所依據的基石，當這些基石發生不可抗拒或控制的改變時對產品需求將造成影響。u 本節的內容不能用來陳述具體需求或強加若干特殊的設計約束，而應對具體需求部分中的某些具體需求或設計約束的描述提供理由。3. 具體需求本章應包括軟件開發者在建立設計時需要的全部細節。本章的編寫應該遵循如下基本

16、原則：l 遵循可驗證性、無歧義性等的準則，對每一個需求細節作具體描述；l 在軟件需求說明書前言、項目概述、附錄部分的有關討論中，要提供對任何一個具體需求交叉引用的背景；l 按符合邏輯的和可讀的方式組織；l 詳細描述每一個需求，使得該需求應達到的目標能夠用指定的方法進行客觀的驗證?！咎嵝炎⒁狻棵恳豁椥枨蟮拿枋龆紤ㄖ辽?個方面的內容：功能需求；性能需求；屬性需求；外部接口需求；設計約束。3.1 功能需求用文字、圖表或數學公式詳細描述被開發軟件的輸入、處理、輸出以及在上述過程中發生的基本操作。對于每一類功能或者有時對于每一個功能，這部分通常由引言、輸入、處理、輸出四個部分組成：3.1.1 引言（

17、1） 描述該功能要達到的目標、所采用的方法和技術；（2） 清楚說明功能意圖的由來和背景。3.1.2 輸入（1） 詳細描述該功能的所有輸入數據，如：輸入源、數量、度量單位、時間設定、有效輸入范圍（包括精度和公差）。（2） 操作員具體的操作控制細節的需求。其中有名字、操作員活動的描述、控制臺或操作員的位置。例如：當打印檢查時，要求操作員進行格式調整。（3） 指明引用的輸入接口資料。3.1.3 處理描述為獲得預期輸出結果，對輸入數據及中間參數進行的全部操作。它包括如下的說明：（1） 輸入數據的有效性檢查手段；（2） 操作的順序和處理過程，包括事件的時間設定；（3） 異常情況的響應，例如：溢出、通信故

18、障、錯誤處理等；（4） 受操作影響的參數；（5） 降級運行的要求；（6） 用于把系統輸入變換成相應輸出的任何方法（方程式、數學算法、邏輯操作等）。（7） 輸出數據的有效性檢查手段。3.1.4 輸出（1） 詳細描述該功能所有輸出數據，例如：輸出目的地、數量、度量單位、時間關系、有效輸出的范圍（包括精度和公差）、非法值的處理、出錯信息；（2） 指明引用的輸出接口資料?！炯记伞靠梢杂昧斜淼姆绞剑ɡ鏘PO表即輸入、處理、輸出表的形式），逐項定量和定性地敘述對軟件所提出的功能要求?！咎嵝炎⒁狻繉χ赜谳斎胼敵鲂袨榈南到y來說，需求說明書應指定所有有意義的輸入、輸出對及其序列。當一個系統要求記憶它的狀態時

19、，需要這個序列，使得它可以根據本次輸入和以前的狀態做出響應。這種情況猶如有限狀態機。3.2 性能需求從整體來說，本節應具體說明軟件、或人與軟件交互的靜態或動態數值需求。靜態數值需求可能包括：支持的終端數，支持并行操作的用戶數，處理的文卷和記錄數，表和文卷的大小等。動態數值需求可能包括：欲處理的事務和任務的數量，以及在正常情況下和峰值工作條件下一定時間周期中處理的數據總量等。所有這些需求都必須用可以度量的術語來敘述。例如：95%的事務必須在小于1s時間內處理完，不然，操作員將不等待處理的完成。u 精度說明對該軟件的輸入、輸出數據精度的要求，可能包括傳輸過程中的精度。 u 時間特性要求說

20、明對于該軟件的時間特性要求，如對響應時間、更新處理時間、數據的轉換和傳送時間、解題時間等的要求。 u 靈活性說明對該軟件的靈活性的要求，即當需求發生某些變化時，該軟件對這些變化的適應能力，如：操作方式上的變化、運行環境的變化、同其他軟件的接口的變化、精度和有效時限的變化、計劃的變化或改進等。 對于為了提供這些靈活性而進行的專門設計的部分應該加以標明。3.3 軟件屬性需求在軟件的需求之中有若干個屬性，下面列舉一部分。【提醒注意】下列屬性決不能理解為是一個標準的或完整的清單，而應根據項目實際情況予以列舉。3.3.1 正確性3.3.2 健壯性3.3.3 安全保密性這里指的是保護軟件的要素，

21、以防止各種非法的訪問、使用、修改、破壞或者泄密。這個領域的具體需求必須包括：利用可靠的密碼技術，掌握特定的記錄或歷史數據集，給不同的模塊分配不同的功能，限定一個程序中某些區域的通信，計算臨界值的檢查等。3.3.4 易使用性3.3.5 可理解性3.3.6 可維護性這里規定若干需求以確保軟件是可維護的。例如：軟件模塊所需要的特殊的耦合矩陣，為微型裝置指定特殊的數據/程序分割要求等。3.3.7 可測試性3.3.8 可移植性這里規定把軟件從一種環境移植到另一種環境所要求的用戶程序、用戶接口兼容方面的約束等。3.4 外部接口需求3.4.1 用戶接口（1） 提供用戶使用軟件產品時的界面需求。例如，如果系統

22、的用戶通過顯示終端進行操作，就必須指定如下要求：對屏幕格式的要求，報表或菜單的頁面顯示格式和內容，用戶命令的格式，輸入輸出的相對時間，程序功能鍵的可用性。（2） 列出輸出錯誤信息的格式。3.4.2 硬件接口（1） 指出軟件產品與系統硬部件之間每一個接口的邏輯特點。（2） 指出硬件接口支持的設備。（3） 描述軟件與硬件接口之間以及硬件接口與支持設備之間的約定。3.4.3 軟件接口描述項目待開發軟件產品與其它有關軟件的接口關系，并指出這些軟件的以下內容：名字、助記符、規格說明號、版本號、來源。【提醒注意】對于每一個接口，應說明與軟件產品相關的接口軟件的目的，并根據信息的內容和格式定義接口，這里不必

23、詳細描述任何已有完整文件的接口，只要引用定義該接口的文件即可。3.4.4 通訊接口說明各種通信接口及協議，例如局部網絡的協議等。3.5 設計約束3.5.1 其它標準的約束描述由現有的標準或規則派生的要求。例如：報表格式、數據命名、財務處理、審計追蹤等等。3.5.2 硬件設備的約束描述在各種硬件約束下運行而產生的軟件要求，可能的約束有硬件配置的特點（接口數、指令系統等），內存儲器和輔助存儲器的容量等。3.6 數據需求【提醒注意】u 此部分內容一般在數據要求說明書中進行描述，如果項目軟件產品規模較小，系統復雜程度較低，數據需求較簡單，也可在此章中描述。u 此部分內容也可能在功能需求中予以說明。3.

24、6.1 數據描述（1） 列出作為控制和引用而使用的靜態數據元素（2） 列出動態輸入數據元素（3） 列出動態輸出數據元素（4） 列出軟件內部生成的數據元素3.6.2 數據獲?。?） 列出提供輸入數據的機構（2） 列出數據輸入介質和設備（3） 列出數據輸出介質和設備3.7 其它專門需求根據軟件和用戶組織的特性等，某些需求在這里描述，下面列舉一部分。【提醒注意】下列需求項決不能理解為是一個標準的或完整的清單，而應根據項目實際情況予以列舉。3.6.1 數據庫本項對作為項目產品的一部分進行開發的數據庫規定一些需求，它們可能包括：（1） 在功能需求中標識的信息類別；（2） 使用的頻率（3） 存取能力；（4

25、） 數據元素和文卷描述符；（5） 數據元素、記錄和文卷的關系；（6） 靜態和動態的組織；（7） 數據保存要求?！咎嵝炎⒁狻咳绻褂靡粋€現有的數據庫包，這個數據庫包應在“軟件接口”中命名，并在那里詳細說明。3.6.2 數據管理能力說明需要管理的文卷和記錄的個數、表和文卷的大小規模，要按可預見的增長對數據及其分量的存儲要求做出估算。3.6.3 操作這里說明用戶組織之中各種方式的操作。例如：（1） 用戶初操作；（2） 交互作用操作的周期和無人操作周期；（3） 數據處理支持功能；（4） 后援和恢復操作?！咎嵝炎⒁狻窟@里的內容有時是“用戶接口”的一部分。3.6.4 故障處理4. 運行環境規定4.1 設備

26、列出運行該軟件所需要的硬設備。說明其中的新型設備及其專門功能，包括：（1） 處理器型號及內存容量；（2） 外存容量、聯機或脫機、媒體及其存儲格式，設備的型號及數量；（3） 輸入及輸出設備的型號和數量，聯機或脫機； （4） 數據通信設備的型號和數量；（5） 功能鍵及其他專用硬件。4.2 支持軟件列出支持軟件,包括要用到的操作系統、編譯（或匯編）程序、測試支持軟件等。4.3 接口說明該軟件同其它軟硬件之間的接口、數據通信協議等。4.4 控制說明控制該軟件的運行的方法和控制信號，并說明這些控制信號的來源?！咎嵝炎⒁狻勘菊轮械膬热萦袝r在前面的章節中已說明。5. 支持信息支持信息指目錄表、索引和附錄。l

27、 目錄表和索引很重要，而且應按照可以接受的文件規則來編寫。l 對一個實際的需求說明書來說，如有必要應該編寫附錄。附錄中可能包括：(1) 輸入輸出格式樣本，成本分析研究的描述或用戶調查結果；(2) 有助于理解需求說明書的背景信息；(3) 軟件所解決問題的描述；(4) 用戶歷史、背景、經歷和操作特點；(5) 交叉訪問表。按先后次序進行編排，使一些不完全的軟件需求得以完善；(6) 特殊的裝配指令用于編碼和媒體，以滿足安全、輸出、初始裝入或其他要求。當包括附錄時，需求說明書必須明確地說明附錄是不是需求要考慮的部分。分析說明書評審記錄 記錄編號： - 時間： 年 月 日項目編號：項目名稱：項目軟件經理P

28、SM：需求分析報告編制人：參加評審人員：評審內容：(評審中審議通過的內容在“”中劃“”，否則劃“×”)1.無岐義性 2.完整性 3.可驗證性 4.一致性 5.可使用性 6.符合需求分析報告編寫規范的要求 評審意見：風險評估總結：評審結論：(評審中審議通過的內容在“”中劃“”，否則劃“×”)1. 通過評審，可以進入下一階段 2. 未通過評審，修改后重新評審 填表：審批：1. 本頁不足記錄結果時，可以有附頁，附頁格式自定。總頁數包括本頁與所有附頁。第 頁/共 頁評審規程狀態：草稿標識號：評審當前版本：初始版前一版本：修訂版發布日期：摘要本文詳細描述了軟件工作產品的評審規程。將要

29、執行評審的所有項目的軟件工作產品都必須遵循該評審規程。修改歷史日期版本作者修改內容評審號更改請求號目錄1 目的和范圍282 評審角色282.1 作者282.2 評審組長282.3 記錄員282.4 其他參與人員293 評審過程293.1 計劃階段293.1.1 進入條件293.1.2 目的293.1.3 活動293.2 準備階段293.2.1 進入條件303.2.2 目的303.2.3 活動303.3 執行階段303.3.1 進入條件303.3.2 目的303.3.3 活動303.4 整理階段313.4.1 進入條件313.4.2 目的313.4.3 活動314 附錄A 評審活動檢查表325

30、附錄B 評審記錄表336 附錄C 評審通知351 目的和范圍本文檔主要描述了軟件工作產品的評審過程，目的是能夠及早和有效地發現并排除軟件工作產品的缺陷。2 評審角色在評審時有四種角色：作者、評審組長、記錄員及其他人員。這些角色在評審會上要承擔不同的職責。角色的劃分必須遵循下面的原則：作者和評審組長是必須的角色，且不能為同一人記錄員可以是任何人員，也可由作者或評審組長兼任其他人員在數量上沒有限制，可以來自與項目相關的其它組織或部門所有人員都必須具備相關的技術背景知識，對評審的軟件工作產品有足夠的了解，熟悉評審規程。2.1 作者作者是指被評審的軟件工作產品的作者，其主要職責如下：準備相關的評審資料

31、完成評審后的修改工作 評審組長評審組長必須為該軟件工作產品所屬領域的高級技術人員，其主要職責如下：指導作者組織并實施評審活動，對評審材料進行初審，確定參加評審的人員按照評審規程主持評審會議在評審會議上控制評審進度，提醒參加者不要在某一問題上花費過多時間對評審中發現的問題進行分析判斷，確定處理辦法，建議為兩類：1. 問題項：當場確定為問題，需要解決2. 調查項：無法確定是否為主要問題，需要進一步調查確認決定評審結果（通過和再評審）2.3 記錄員記錄員在評審會議中記錄發現的問題及相關的數據，其主要職責如下：填寫評審記錄表作為評審員參與評審2.4 其他參與人員其他人員評審軟件工作產品，回答問題、參與

32、討論同時幫助解決問題。所有的參與人員都必須嚴格遵循評審規程。3 評審過程評審過程分為四個階段，每一階段都包含一定的任務描述，可以參考評審活動檢查表執行評審。評審活動檢查表是幫助評審人員正確執行評審的工具，它與本章所描述的各階段的具體活動是一致的。評審過程的四個階段為：計劃、準備、執行和整理。 每一階段必須順序地執行，才能保證評審成功。 下面將詳細描述這四個步驟。3.1 計劃階段這是評審的第一階段，其每一步都有詳細說明，只有計劃階段的任務完成后才能進入準備階段。3.1.1 進入條件軟件工作產品滿足規范要求軟件工作產品經過拼寫檢查3.1.2 目的確保作者提供正確的評審材料確保軟件工作產品滿足評審要

33、求確定評審員并明確其職責3.1.3 活動作者準備評審所需的材料，包含被評審的軟件工作產品、支持材料及評審表格等技術委員會指定評審組長評審組長檢查進入標準是否滿足技術委員會確定參評人員。也可由技術委員會委托評審組長確定需要參加評審的人員評審組長確認作者準備好所需要的材料評審組長與作者共同確定評審會議日程3.2 準備階段3.2.1 進入條件評審材料已準備好參加者對被評審的軟件工作產品具備必要的背景知識評審組長確認評審材料符合要求3.2.2 目的評審員明確自己的職責所有評審員在評審之前得到評審材料確保評審員在評審之前閱讀評審材料，找出問題3.2.3 活動作者發評審會議通知給所有評審員作者將評審材料分

34、發給所有評審員評審組長標識軟件工作產品的范圍，強調重點，提取問題評審組長熟悉議程，確保評審進度評審員仔細閱讀評審材料，在評審材料上做評注，找出問題所有評審員記錄自己準備所花費的時間3.3 執行階段執行評審必須召開評審會議，所有評審員進行面對面地討論是必要的。3.3.1 進入條件所有評審員得到評審材料所有評審員根據自己的角色要求準備并且評審軟件工作產品所有評審員記錄自己的準備時間。本次評審的準備時間是所有評審員的準備時間之和會議室和其它資源已經準備就緒作者準備就緒，重要參加人員能夠出席評審會議3.3.2 目的找出、記錄和分析所有問題3.3.3 活動評審組長檢查所有評審員是否已經做好評審的準備工作

35、記錄員記錄評審員的準備時間，開始評審作者為軟件工作產品逐項進行概要介紹記錄員在評審會議上記錄發現的問題所有評審員把重點放在討論和提出問題上評審員使用自己注釋的評審材料對有問題的地方提出討論作者和評審員協助評審組長描述和分析問題，發現一個問題后，評審組長確保該問題被正確記錄所有評審員提出對評審會議的改進建議，記錄員在評審表上記錄要點評審組長確保評審完成 評審組長在評審組的協助下決定評審結果。如果沒有問題或發現的問題類型和數量容易改正和處理，其結果為“通過”，否則為“再評審”如果需要“再評審”，可以只評審需要評審的部分。評審組長記錄需要再被評審的部分3.4 整理階段3.4.1 進入條件問題已被記錄

36、在評審表中3.4.2 目的修正評審中發現的所有問題確保所有需要進行調查的項目已經被分析，并且被排除評審數據被記錄3.4.3 活動評審組長估計并跟蹤修改問題所需時間對于問題項，作者確保有問題記錄對于調查項，經研究后，如果是問題項，作者負責解決并記錄在評審表中作者修正所有問題項評審組長協調所有評審員檢查作者已修改過的內容。如果沒有問題，則評審結果定為“通過”，否則，評審組長應提出解決方案所有評審員確認后，在評審表上簽字如果使用評審工具代替評審記錄表，則作者在評審工具中生成一個新的評審記錄表，填入相應內容并提交4 附錄A 評審活動檢查表階段作者評審組長其他評審員計劃¨¨ 接受評審

37、組長角色并確定評審目標¨ 準備評審材料¨ 檢查評審進入條件是否滿足¨ 同評審組長一起選擇評審員¨ 確定需要參加評審的人員¨ 接受評審員角色¨ 與評審組長共同準備¨ 確保評審材料準備好¨ 核實進入條件¨ 理解自己的職責¨ 給所有評審員發評審會議通知¨ 學習并且評注軟件工作產品¨ 學習并且評注軟件工作產品¨ 將被評審材料分發給所有評審員¨ 熟悉評審議程¨ 記錄個人的準備時間¨ 確保會議室和其它資源準備就緒¨ 記錄個人的準備時間執行

38、¨ 介紹評審會議日程¨ 控制評審進度¨ 按時出席，提供準備時間¨ 逐項概要介紹軟件工作產品¨ 分析問題¨ 記錄員記錄所有評審員姓名及準備時間¨ 決定評審結果¨ 參加討論并提出問題¨ 記錄員記錄問題¨ 所有評審員提出對評審會議的改進建議，記錄員在評審表上記錄要點整理¨ 改正評審所發現的問題¨ 估計并跟蹤需要修改問題所需時間¨ 如果有評審工具，則生成一個新的評審記錄表，填入相應內容并提交¨ 檢查修改內容的正確性¨ 閱讀并確認評審記錄表內容的正確性&#

39、168; 提交文檔¨ 簽字¨ 簽字注：首先由技術委員會指定評審組長。5 附錄B 評審記錄表評審會日期：_ 開始時間：_ 結束時間：_評審會地點：_第_次評審評審主題：_ _軟件工作產品名稱：_軟件工作產品大?。篲SLOC/頁軟件工作產品標識號：_版本號：_ _評審員及準備時間：角色姓名準備時間（小時）評審組長作者記錄員評審員總和問題記錄：序號位置描述類型狀態問題項調查項未解決已解決問題項調查項未解決已解決修改軟件工作產品工作量（小時）：_評審結果： 通過 再評審改進建議：_ _ _簽字：角色姓名簽字評審組長評審員6 附錄C 評審通知主題：第 次評審期望準備時間：評審會日期：

40、 開始時間： 持續時間： 評審會地點：軟件工作產品名稱：軟件工作產品標識號： 版本號： 評審組長： 記錄員：其他評審員：議程： 起止時間主題軟件工作產品信息：軟件工作產品標識號：版本：軟件工作產品大?。⊿LOC/頁）：其它支持材料：遵循標準：其它：概要設計說明書1. 引言1.5 目的說明編寫概要設計說明書的目的，指出預期的讀者。1.6 背景（4） 待開發的軟件系統的名稱；（5） 本項目的任務提出者、開發者、用戶及實現該軟件的計算中心或計算機網絡；（6） 該軟件系統同其他系統或其他機構的基本的相互來往關系。1.7 參考資料列出所用的參考資料，如：（5） 本項目的經核準的計劃任務書或合同、上級機關

41、的批文；（6） 屬于本項目的其他已發表的文件；（7） 本文件中各處引用的文件、資料，包括所需用到的軟件開發標準。（8） 列出這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。1.8 術語列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。2. 總體設計2.2 需求規定簡要說明對本系統的主要的輸入輸出項目、處理的功能與性能等的要求。2.3 運行環境簡要地說明對本系統的運行環境（包括硬件環境和支持環境）的規定。2.4 基本設計概念和處理流程說明本系統的基本設計概念和處理流程，盡量使用圖表的形式。2.5 結構用一覽表及框圖的形式說明本系統的系統元素（各層模塊、子

42、程序、公用程序等）的劃分，扼要說明每個系統元素的標識符和功能，分層次地給出各元素之間的控制與被控制關系。2.6 功能需求與程序的關系用如下的矩陣圖說明各項功能需求的實現同各塊程序的分配關系： 程序1 程序2 程序m 功能需求1 功能需求2 功能需求n 2.7 人工處理過程說明在本軟件系統的工作過程中不得不包含的人工處理過程。2.8 尚未解決的問題說明在概要設計過程中尚未解決而設計者認為在系統完成之前必須解決的各個問題。3. 接口設計3.1 用戶接口說明將向用戶提供的命令和它們的語法結構，以及軟件的回答信息。3.2 外部接口說明本系統同外界的所有接口的安排包括軟件與硬件之間的接口、本系統與各支持

43、軟件之間的接口關系。3.3 內部接口說明本系統之內的各個系統元素之間的接口的安排。4. 運行設計4.1 運行模塊組合說明對系統施加不同的外界運行控制時所引起的各種不同的運行模塊組合，說明每時每種運行所歷經的內部模塊和支持軟件。4.2 運行控制說明每一種外界的運行控制的方式方法和操作步驟。4.3 運行時間說明每種運行模塊組合將占用各種資源的時間。5. 系統數據結構設計5.1 邏輯結構設計要點給出本系統內所使用的每個數據結構的名稱、標識符以及它們之中每個數據項、記錄、文卷和系的標識、定義、長度及它們之間的層次的或表格的相互關系。5.2 物理結構設計要點給出本系統內所使用的每個數據結構中的每個數據項

44、的存儲要求，訪問方法、存取單位、存取的物理關系（索引、設備、存儲區域）、設計考慮和保密條件。5.3 數據結構與程序的關系說明各個數據結構與訪問這些數據結構的各個程序之間的對應關系，可采用如下的矩陣圖的形式： 程序1 程序2 程序m 數據結構1 數據結構2 數據結構n 6. 系統出錯處理設計6.1 出錯信息用一覽表的方式說明每種可能的出錯或故障情況出現時，系統輸出信息的形式、含意及處理方法。6.2 補救措施說明故障出現后可能采取的變通措施，包括：（1） 后備技術革新：說明準備采用的后備技術，當原始系統數據萬一丟失時啟用的副本的建立和啟動的技術，例如周期性地把磁盤信息記錄到磁帶上去就是對于磁盤媒體

45、的一種后備技術；（2） 降效技術：說明準備采用的后備技術，使用另一個效率稍低的系統或方法來求得所需結果的某些部分，例如一個自動系統的降效技術可以是手工操作和數據的人工記錄；（3） 恢復及再啟動技術：說明將使用的恢復再啟動技術，使軟件從故障點恢復執行或使軟件從頭開始重新運行的方法。6.3 系統維護設計說明為了系統維護的方便而在程序內部設計中做出的安排，包括在程序中專門安排用于系統的檢查與維護的檢測點和專用模塊。詳細設計說明書1. 引言1.1 目的說明編寫詳細設計說明書的目的，指出預期的讀者。1.2 背景（7） 待開發的軟件系統的名稱；（8） 本項目的任務提出者、開發者、用戶及實現該軟件的計算中心或計算機網絡；（9） 該軟件系統同其他系統或其他機構的基本的相互來往關系。1.3 參考資料列出所用的參考資料，如：（9） 本項目的經核準的計劃任務書或合同、上級機關的批文；（10） 屬于本項目的其他已發表的文件；（11） 本文件中各處引用的文件、資料，包括所需用到的軟件開發標準。（12） 列出這些文件資料的標題、文件編號、發表日期和出版單位，說明能夠得到這些文件資料的來源。1.4 術語列出本文件中用到的專門術語的定義和外文首字母組詞的原詞組。2.