【正文】 912：對軟件穩(wěn)定度進行度量 說明：與軟件穩(wěn)定度相關的度量的例子有： 需求變更的頻率 缺陷變更的頻率 問題解決效率 92：對風險進行度量。 95：對工作量進行度量 說明：按書面規(guī)程導出工作量估計，要進行軟件工作量度量如下： 工作量在軟件生存 周期的分布的估計值與實際值 各軟件工作產品的工作量的估計值與實際值 獨立管理的作業(yè)或階段的工作量的估計值與實際值 SQA工作量的估計值與實際值 SCM工作量的估計值與實際值 準備同行評審的工作量的估計值與實際值 參加同行評審的工作量的估計值與實際值 用于過程評估的工作量的估計值與實際值 用于過程制定和改進的工作量的估計值與實際值 軟件開發(fā)行為規(guī)范 8 軟件質量保證 僅供內部使用 29 管理項目的工作量的估計值與實際值 項目計劃和執(zhí)行跟蹤監(jiān)控的工作量 重計劃工作的工作量 對每個需求的更改提議進行分析的工作量 軟件工程組支持其它工程組花費的工作量 其它工程組支持軟件 工程組花費的工作量 因同行評審返工的工作量，等等。 91:建議每個項目建立一個軟件過程數據庫。 說明：參考建議 84。 序號 問題 1 制定 SQA計劃的活動是否按照公司的相關規(guī)范進行？ 如果存在偏差，是否形成了偏 差文檔，并得到研究技術管理處的批準？ 2 SQA計劃是否符合公司規(guī)范中 SQA計劃模板的要求？ 如果存在偏差，是否形成了偏差文檔，并得到研究技術管理處的批準？ 3 SQA活動是否按照 SQA計劃進行？ 4 SQA計劃是否經過計劃中涉及的相關組和個人的評審，并得到 SQA經理、產品項目經理的批準？ 5 SQA計劃和軟件項目計劃是否在項目的里程碑處進行了修改，修改是否得到批準？ SQA計劃和軟件項目開發(fā)計劃是否同步變更？ 84： SQA必須對產品軟件開發(fā)過程進行過程審計。 說明：參考建議 76。 79：必須定義流程指導配置狀態(tài)發(fā)布。 說明：參考建議 72。 軟件開發(fā)行為規(guī)范 6 需求管理 僅供內部使用 22 65：變更控制流程至少應包含以下內容： 序號 內容 1 對變化的影響進行評估 2 經過 CCB組織的評審 3 通知受影響的組和個人 4 跟蹤解決該問題，直到關閉 66：必須在開發(fā)過程中對需求進行跟蹤。 說明：參見建議 63。 61：需求管理的職責至少應包括以下內容： 序號 內容 1 在產品項目整個生存周期內，管理系統(tǒng)需求和它們的分配，并對其建立文檔。 說明：參考建議 51。 序號 問題 1 初 始化時是否使用了默認值，是否正確？ 2 訪問內存時是否進行了邊界檢查，以保證地址正確？（隊列，數據結構，指針，等等） 3 對輸入、輸出、接口和結果是否進行了錯誤檢查？ 4 對所有錯誤情況都安排了有意義的消息反饋？ 5 特殊情況下的返回碼是否和文檔中定義的全局返回碼一致？ 6 是否考慮了異常情況？ 415：采用以下檢查表檢查詳細設計的可測試性。 序號 問題 1 設計是否使用了指定的算法？ 2 設計是否能夠滿足需求和目的？ 410：采用以下檢查表檢查詳細設計的接口描述。 說明：參考建議 43。當發(fā)生設計更改時，必須修訂相應設計文檔。 序號 問題 1 設計是否考慮了檢錯和恢復措施？（例如：輸入檢查） 2 是否考慮了異常情況？ 3 是否完全準確描述了所有的出錯情況？ 4 設計是否能夠滿足所有系統(tǒng)集成方面的要求？ 314：采用以下檢查表檢查設計的可測試性。 序號 問題 2 程序、模塊、函數、數據成員的名稱是否保持一致？ 3 設計是否反映了真正的操作環(huán)境 ?硬件環(huán)境 ?軟件環(huán)境 ? 4 對系統(tǒng)設計的多種可能的描述之間是否保持一致 ?(例如 :靜態(tài)結構的描述和動態(tài)描述 ) 36：采用以下檢查表檢查概要設計文檔的正確性。 36：概要設計過程結束前，必須通過評審，并保存評審記錄。 軟件開發(fā)行為規(guī)范 3 概要設計 僅供內部使用 13 3 概要設計 31：概要設計要以軟件需求規(guī)格為基礎，必須保證需要實現的需求規(guī)格已經被設計。 211：當實際結果和“軟件項目計劃”發(fā)生偏離時，必須進行分析，根據分析結果標明糾正措施。項目組對文檔模板內容的裁減必須得到上級管理部門（包括產品計劃處、軟件工程組 SEPG）的審核批準。 213:軟件質量保證計劃和軟件配置管理計劃作為獨立的計劃文檔。 說明：項目人員計劃包括需要的人員類型、數量和技術等級的要求，相關人員的開始工作時間、工作周期、接受培訓的計劃等。 26：盡量采用歷史經驗數據進行軟件估計。 說明：參考建議 24到 28。當發(fā)生需求更改時，必須修訂軟件開發(fā)計劃。 序號 問題 1 是否可從上一 階段的文檔中找到需求定義中的相應內容？ 2 需求定義是否明確地表明前階段中提出的有關需求和設計限制都已被覆蓋了？ 3 需求定義是否便于向后繼開發(fā)階段查找信息 110：采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易理解性。 序號 問題 1 所有定義、實現方法是否清楚地表達了用戶的原始要求？ 2 在功能實現過程、方法和技術要求的描述上，是否沒有背離了功能的實際要求？ 3 是否沒有不能理解或造成誤解的描述 ？ 12：采用以 下檢查表檢查軟件需求規(guī)格文檔中需求的完備性。 研究技術管理處 僅供內部使用 4 目 錄 1 軟件需求分析 5 2 軟件項目計劃 9 3 概要設計 11 4 詳細設計 14 5 編碼 18 6 需求管理 19 7 軟件配置管理 21 8 軟件質量保證 23 9 數據度量和分析 25 軟件開發(fā)行為規(guī)范 1 軟件需求分析 僅供內部使用 5 1 軟件需求分析 11：軟件需求分析必須在產品需求規(guī)格的基礎上進行，并保證完全實現產品需求規(guī)格的定義。 與軟件開發(fā)相關的所有人員，包括各級經理和工程師都必須遵守本軟件開發(fā)行為規(guī)范。 ★ 說明 ：對此規(guī)則或建議進行必要的解釋。 15：在對軟件需 求規(guī)格文檔的正規(guī)檢視或評審時，必須檢查軟件需求規(guī)格文檔中需求的清晰性、完備性、兼容性、一致性、正確性、可行性、易修改性、健壯性、易追溯性、易理解性、易測試性和可驗證性、性能、功能、接口、數據、可維護性等內容。 序號 問題 1 需求定義是否使軟件的設計、實現、操作和維護都可行？ 2 所規(guī)定 的模型、數值方法和算法是否對待解決問題合適？是否能夠在相 軟件開發(fā)行為規(guī)范 1 軟件需求分析 僅供內部使用 7 應的限制條件下實現？ 3 是否能夠達到關于質量的要求？ 17：采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易修改性。 序號 問題 1 是否清楚地定義了所有的接口？ 3 所有接 口是否必須？各接口間的關系是否一致、正確？ 115：采用以下檢查表檢查軟件需求規(guī)格文檔中的數據需求描述。 22：軟件經理對軟件項目計劃的制定和結果負責。增加、修改模塊設計數目 :5 5天 文檔頁數 :41。 210：在“軟件項目計劃”中包括軟件重用計劃。 24：軟件項目計劃中應該包括正規(guī) 檢視活動計劃、軟件質量保證計劃、軟件配置管理計劃。 26：必須分 析任務之間的依賴性，確定并明確標識項目的關鍵路徑。 218：“軟件項目計劃”通過評審后，軟件經理組織相關人員對任務進行承諾，簽定工作任務書。 220：必須提供相應資源，包括工具和人員等，進行軟件項目計劃和項目跟蹤監(jiān)控活動。 34：必須保證概要設計文檔和代碼的一致性。 序號 問題 1 程序結構，包括數據流、控制流和接口的描述是否清楚？ 33：采用以下檢查表檢查概要設計文檔的完備性。 序號 問題 軟件開發(fā)行為規(guī)范 3 概要設計 僅供內部使用 15 1 是否估計了每個子模塊的規(guī)模（代碼的行數）？是否可信？ 2 是否考慮了足夠數量及代表性的系統(tǒng)狀態(tài)？ 3 詳細程度是否足夠進行下一步的詳細設計？ 311：采用以下檢查表檢查設計的可維護性。 說明：需求、概要設計、詳細設計的跟蹤關系可參考建議 41。 46：詳細設計過程結束前，必須通過評審，并保存評審記錄 。 序號 問題 1 在單元和單元的接口中數據成員的名稱是否保持一致？ 2 所有接口之間，接口和接口規(guī)格書 之間是否保持一致