1、軟件開發行為規范第一版深圳市華為技術版權所有 不得復制軟件開發行為規范(第一版）為了把公司已經發布的軟件開發過程規范有效地運作于產品開發活動中，把各種規范“逐步形成工程師的作業規范”，特制定本軟件開發行為規范，以達到過程控制的目的。與軟件開發相關的所有人員，包括各級經理和工程師都必須遵守本軟件開發行為規范。對違反規范的開發行為，必須按照有關管理規定進行處罰。本軟件開發行為規范的內容包括：軟件需求分析、軟件項目計劃、概要設計、詳細設計、編碼、需求管理、配置管理、軟件質量保證、數據度量和分析等。 本軟件開發行為規范，采用以下的術語描述： 規則：在軟件開發過程中強制必須遵守的行為規范。 建議：軟件開

2、發過程中必須加以考慮的行為規范。 說明：對此規則或建議進行必要的解釋。 示例：對此規則或建議從正或反兩個方面給出例子。 本軟件開發過程行為規范由研究技術管理處負責解釋和維護。研究技術管理處目 錄1 軟件需求分析52 軟件項目計劃93 概要設計114 詳細設計145 編碼186 需求管理197 軟件配置管理218 軟件質量保證239 數據度量和分析251 軟件需求分析1-1：軟件需求分析必須在產品需求規格的基礎上進行，并保證完全實現產品需求規格的定義。1-2：當產品的需求規格發生變更時，必須修訂軟件需求規格文檔。軟件需求規格的變更必須經過評審，并保存評審記錄。1-3：必須對軟件需求規格文檔進行正

3、規檢視。1-4：軟件需求分析過程活動結束前，必須經過評審，并保存評審記錄。1-5：在對軟件需求規格文檔的正規檢視或評審時，必須檢查軟件需求規格文檔中需求的清晰性、完備性、兼容性、一致性、正確性、可行性、易修改性、健壯性、易追溯性、易理解性、易測試性和可驗證性、性能、功能、接口、數據、可維護性等內容。說明：參考建議1-1到1-16。1-1：采用以下檢查表檢查軟件需求規格文檔中需求的清晰性。序號問題1所有定義、實現方法是否清楚地表達了用戶的原始要求？2在功能實現過程、方法和技術要求的描述上，是否沒有背離了功能的實際要求？3是否沒有不能理解或造成誤解的描述 ？1-2：采用以下檢查表檢查軟件需求規格文

4、檔中需求的完備性。序號問題1需求定義中是否包含了有關文件（指質量手冊、質量計劃以及其它有關文件）種所規定的需求定義所應該包含的所有內容？2需求定義是否包含了有關功能、性能、限制、目標、質量等方面的所有需求？3功能性需求是否覆蓋了所有非正常情況的處理？4是否對各種操作模式（如正常、非正常、有干擾等）下的環境條件都作了規定？5是否對所有功能與時間因素有關的方面都作了考慮？6是否標識出了所有與時間因素有關的功能？它們的時間準則是否都說明了？時間準則的最大、最小執行時間是否都定義了？7是否標識并定義了在將來可能會變化的需求？8是否定義了系統所有的輸入？9是否標識清楚了系統輸入的來源？10是否標識出了系

5、統的輸出？11是否說明了系統輸入、輸出的類型？12是否說明了系統輸入、輸出的值域、單位、格式等？13是否說明了如何進行系統輸入的合法性檢查？14是否定義了系統輸入、輸出的精度？15是否定義了系統性能的各個方面？16在不同負載情況下，是否規定了系統的處理能力？17在不同情況下，是否規定了系統的響應時間？18是否充分定義了關于人機界面的需求？19是否對需求定義進行了可行性分析和相關文件（資料）是否已歸檔？20是否對影響需求實現的因素進行了調查，調查結果是否已歸檔？21是否有經濟效益分析，分析結果是否已歸檔？22是否詳細描述了有關硬件、軟件、操作人員、操作過程等方面的安全性？23是否評估了本項目對用

6、戶、其它系統、環境的影響特性？24是否按完成時間、重要性對系統功能、外部接口、性能進行了優先排序？1-3：采用以下檢查表檢查軟件需求規格文檔中需求的兼容性。序號問題1界面需求是否使軟硬件系統具有兼容性？2需求定義的文檔是否滿足項目文檔編寫標準？在矛盾時，是否有適當的標準可供選擇？1-4：采用以下檢查表檢查軟件需求規格文檔中需求的一致性。序號問題1各個需求之間是否一致？是否有沖突和矛盾？2所規定的模型、算法和數值方法是否相容？3是否使用了標準的術語和定義形式？4需求是否與其軟硬件操作環境相容？5是否說明了軟件對其系統和環境的影響？6是否說明了環境對軟件的影響？7所采用的技術是否與用戶要求的技術一

7、致？1-5：采用以下檢查表檢查軟件需求規格文檔中需求的正確性。序號問題1需求定義是否滿足標準的要求？2算法和規則是否有科技文獻或其它文獻作為基礎？3是否定義了對在錯誤、風險分析中所標識出的各種故障模式和錯誤類型所需的反應？4是否參照了有關的標準？5是否對每一個需求都給出了理由？理由是否充分？6對設計和實現的限制是否都有論證？1-6：采用以下檢查表檢查軟件需求規格文檔中需求的可行性。序號問題1需求定義是否使軟件的設計、實現、操作和維護都可行？2所規定的模型、數值方法和算法是否對待解決問題合適？是否能夠在相應的限制條件下實現？3是否能夠達到關于質量的要求？1-7：采用以下檢查表檢查軟件需求規格文檔

8、中需求的易修改性。序號問題1對需求定義的描述是否易于修改（如是否采用良好的結構和交叉引用表等）？2是否有冗余的信息？是否一個需求被定義了多次？1-8：采用以下檢查表檢查軟件需求規格文檔中需求的健壯性。序號問題1是否有容錯的需求？1-9：采用以下檢查表檢查軟件需求規格文檔中需求的易追溯性。序號問題1是否可從上一階段的文檔中找到需求定義中的相應內容？2需求定義是否明確地表明前階段中提出的有關需求和設計限制都已被覆蓋了？3需求定義是否便于向后繼開發階段查找信息1-10：采用以下檢查表檢查軟件需求規格文檔中需求的易理解性。序號問題1是否每一個需求都只有一種解釋？2功能性需求是否以模塊方式描述的？是否明

9、確地標識出了其功能？3是否有術語定義一覽表？4是否使用了形式化或半形式化的語言？5語言是否有歧義性？6需求定義中是否只包含了必須的實現細節而不包含不必要的實現細節？是否過分細致了？7需求定義是否足夠清楚和明確使其能夠作為開發設計規約和功能性測試數據的基礎？8需求定義的描述是否將對程序的需求和所提供的其它信息分離開來了？1-11：采用以下檢查表檢查軟件需求規格文檔中需求的易測試性和可驗證性。序號問題1需求是否可以驗證（即是否可以檢驗軟件是否滿足了需求）？2是否對每一個需求都指定了驗證過程？3數學函數的定義是否使用了精確定義的語法和語義符號？1-12：采用以下檢查表檢查軟件需求規格文檔中的性能需求

10、描述。序號問題是否精確的描述了所有的性能需求和可容忍的性能降低程度？對每一個性能應包含兩方面的內容：1 a. 在最壞情況的執行結果 2 b. 本性能失效后，對系統產生的影響1-13：采用以下檢查表檢查軟件需求規格文檔中功能需求描述。序號問題1是否清楚、明確地描述了所有的功能？2所有已描述的功能是否是必須的？是否能滿足任務書或系統目標的要求？1-14：采用以下檢查表檢查軟件需求規格文檔中的接口需求描述。序號問題1是否清楚地定義了所有的接口？3所有接口是否必須？各接口間的關系是否一致、正確？1-15：采用以下檢查表檢查軟件需求規格文檔中的數據需求描述。序號問題1在某異常數據（如條件、標志等）下，是

11、否有真正沒有考慮到的結果？2對異常數據產生的結果是否作了精確的描述？1-16：采用以下檢查表檢查軟件需求規格文檔中的可維護性需求描述。序號問題1需求定義中是否包括了可行的系統維護方法？2軟件系統間的關系是否是松耦合的（即能否保證在對某部分修改后，產生最小的連鎖效應）？2 軟件項目計劃2-1：軟件項目計劃必須以產品/軟件的需求規格為基礎。當發生需求更改時，必須修訂軟件開發計劃。說明：軟件項目計劃必須依據需求規格進行制定。項目計劃中的工作產品和工作任務應保證能完全實現需求規格的定義。當需求更改時，必須考慮需求更改的相關性，修訂相應軟件開發計劃。2-1：制定軟件項目計劃的活動制定，必須遵守“軟件項目

12、計劃規范”。2-2：軟件經理對軟件項目計劃的制定和結果負責。2-3：軟件經理和相關參與軟件項目計劃的制定和評審的人員，在參與計劃制定之前必須經過軟件工程和軟件項目計劃制定流程的培訓。2-2：對于軟件項目計劃中各項工作產品和工作任務，必須進行規模和工作量的軟件估計，并在軟件項目計劃文檔中記錄估計的方法和估計數據。說明：參考建議2-4到2-8。2-4：可以使用PERT統計估計、專家判定平均法、經驗類比估計、公式計算等方法，或以上方法的組合，進行軟件估計。示例：PERT統計估計和經驗類比估計的結合PERT統計估計值 (最大估計4×期望估計最小估計/ 6估計記錄如下：工作產品任務最大估計期望

13、估計(根據經驗類比獲得)最小估計PERT估計規模工作量規模工作量規模工作量規模工作量XX版本（增加XX特性話統模塊概要設計文檔頁數:45;增加、修改模塊設計數目:1212天文檔頁數:42;增加、修改模塊設計數目:1010天文檔頁數:30;增加、修改模塊設計數目:55天文檔頁數:41;增加、修改模塊設計數目:10天期望估計值是根據XX版本的話統模塊設計的數據獲得。2-5：對某項工作產品和任務的軟件，同時采用兩種或以上的方法進行估計，以避免一種方法的偏差。2-6：盡量采用歷史經驗數據進行軟件估計。2-7：參照“軟件估計指導書”進行軟件估計。2-8：軟件估計對應項目的任務分解結構進行。說明：軟件估計

14、對于項目的任務分解結構對應得越清晰、越細致，相應的估計越準確。2-9：在“軟件項目計劃”中必須包括項目管理活動的計劃。2-10：在“軟件項目計劃”中包括軟件重用計劃。包括重用軟件部件的計劃和開發可重用軟件部件的計劃。2-11： 在“軟件項目計劃”包括人員的培訓計劃。說明：項目人員計劃包括需要的人員類型、數量和技術等級的要求，相關人員的開始工作時間、工作周期、接受培訓的計劃等。2-12：對軟件項目進行風險分析與評估。說明：可能存在的風險領域含：需求的不明確和變更、外部的限制與對外的依賴、人力資源的到位情況、人力資源的技術等級滿足要求狀況、技術問題等。 對風險的分析與評估實踐包括：從已知的情況推導

15、出潛在風險；對風險進行分析，得出：潛在風險可能引發的問題的影響、潛在風險發生的可能性大小、風險發生的時間段等；排列風險的重點次序；對風險記錄成文件（屬于軟件項目計劃中的一部分）；風險經受風險影響人審核，并取得他的同意；根據需要，在開發過程中對風險文檔進行維護和修訂。2-3：對應工作任務，制定項目的文檔計劃。2-4：軟件項目計劃中應該包括正規檢視活動計劃、軟件質量保證計劃、軟件配置管理計劃。軟件質量保證計劃和軟件配置管理計劃可以和軟件項目計劃在同一份文檔中，也可以分開為三份文檔。說明：參考建議2-13。2-13:軟件質量保證計劃和軟件配置管理計劃作為獨立的計劃文檔。2-14：軟件項目計劃必須是整

16、個項目開發過程的計劃，包括測試。2-15：測試經理對照整個開發計劃建立軟件驗證與確認計劃。軟件驗證與確認計劃可作為獨立的計劃文檔。2-5：必須對項目工作進行分解，確定項目的工作任務，任務的責任人、資源要求、時間要求、項目的進度。2-6：必須分析任務之間的依賴性，確定并明確標識項目的關鍵路徑。2-7：“軟件項目計劃”必須按照文檔模板的要求編寫。項目組可根據項目的實際情況，對文檔模板中的內容進行裁減。項目組對文檔模板內容的裁減必須得到上級管理部門（包括產品計劃處、軟件工程組SEPG）的審核批準。2-8：軟件項目計劃必須經過評審。說明：參考建議2-16，。2-16：軟件項目計劃的評審采用以下檢查表。

17、序號問題1軟件項目計劃是否完全反映（對應）“軟件需求說明書”里的需求？2軟件項目計劃是否有開發方法的說明？3軟件項目計劃是否有資源需求的說明？4軟件項目計劃是否包含風險管理計劃？5軟件項目計劃是否包含了版本發布的機制？6軟件項目計劃是否標識了所有必須的培訓計劃？7軟件項目計劃是否標識了所有內部和外部的傳遞關系？8軟件項目計劃是否標明了項目的依賴關系？9軟件項目計劃是否標明了角色和職責？10軟件項目計劃是否標明了匯報的機制？11軟件項目計劃是否說明了跟蹤和監控機制？12軟件項目計劃是否包含“軟件質量保證計劃”和“軟件配置管理計劃”？13軟件項目計劃是否包含項目開發使用的工具？14軟件項目計劃是否

18、包含項目的各里程碑的說明？15進度中是否標明了軟件項目計劃的關鍵路徑？2-17：參加“軟件項目計劃”評審的人員，除軟件經理和項目組人員外，必須有產品經理、上級管理部門（包括軟件工程組SEPG）、SQA人員。2-18：“軟件項目計劃”通過評審后，軟件經理組織相關人員對任務進行承諾，簽定工作任務書。2-9：必須對“軟件項目計劃”進行配置管理，“軟件項目計劃”的更改必須經過評審。2-10：在開發活動中，必須按照項目跟蹤與監控計劃和體制，對照“軟件項目計劃”，跟蹤項目開發的實際結果和性能。2-11：當實際結果和“軟件項目計劃”發生偏離時，必須進行分析，根據分析結果標明糾正措施。必要的情況下，要及時修訂

19、“軟件項目計劃”。2-12：在軟件項目跟蹤監控活動中，必須定期進行總結和評審，撰寫開發狀態報告。2-19：根據項目的特點，報告的周期可以為周、雙周、月。2-13：在軟件開發各里程碑階段結束前，必須進行階段評審，對軟件項目進行重估計，必要的情況下修訂“軟件項目計劃”。 2-20：必須提供相應資源，包括工具和人員等，進行軟件項目計劃和項目跟蹤監控活動。2-14：在軟件項目計劃和項目跟蹤監控過程活動中，必須進行數據度量和分析。說明：參見“9. 數據度量和分析”。3 概要設計3-1：概要設計要以軟件需求規格為基礎，必須保證需要實現的需求規格已經被設計。3-2：當需求規格發生變更時，必須修訂相關概要設計

20、文檔。3-3：在概要設計文檔或需求管理文檔中，必須記錄、驗證需求和概要設計的跟蹤關系。說明：需求和概要設計的跟蹤關系可參考建議3-1。3-1：采用需求、子系統、模塊的跟蹤矩陣表記錄需求和概要設計的跟蹤關系。3-4：必須保證概要設計文檔和代碼的一致性。當發生設計更改時，必須修訂相應設計文檔。3-5：必須對概要設計文檔進行正規檢視。3-6：概要設計過程結束前，必須通過評審，并保存評審記錄。3-7：設計更改必須經過相關評審，并保存評審記錄。3-8：對概要設計文檔的正規檢視或評審，必須檢查概要設計文檔的清晰性、完備性、規范性、一致性、正確性、數據、功能性、接口、詳細程度、可維護性、性能、可靠性、可測試

21、性、可追溯性。說明：參考建議3-2。3-2：采用以下檢查表檢查概要設計文檔的清晰性。序號問題1程序結構，包括數據流、控制流和接口的描述是否清楚？3-3：采用以下檢查表檢查概要設計文檔的完備性。序號問題1設計目標是否定義？2需求規格評審中不完整的需求(TBD)是否都已經解決?3如果以前定義的不完整的需求(TBD)發生了改變,本設計是否能夠支持?4是否對不完整需求(TBD)的影響進行了評估?5對有可能不能實現的設計是否有風險管理計劃? 6是否對設計模式進行了描述?3-4：采用以下檢查表檢查概要設計文檔的規范性。序號問題1文檔是否符合公司模板和寫作要求?3-5：采用以下檢查表檢查概要設計文檔的一致性

22、。序號問題2程序、模塊、函數、數據成員的名稱是否保持一致？3設計是否反映了真正的操作環境?硬件環境?軟件環境?4對系統設計的多種可能的描述之間是否保持一致?(例如:靜態結構的描述和動態描述)3-6：采用以下檢查表檢查概要設計文檔的正確性。序號問題1設計在計劃、預算、技術上是否可行？2邏輯是否正確和完備？3-7：采用以下檢查表檢查概要設計文檔的數據描述。序號問題1是否對所有的數據成員,參數,對象進行了描述?2是否所有需要的數據結構都進行了定義,或者定義了不需要的數據結構?3是否所有的數據成員都進行了足夠詳細的描述? 數據成員的有效值區間是否定義? 4共享和存儲數據的使用是否描述清楚?3-8：采用

23、以下檢查表檢查概要設計文檔的功能性要求。序號問題1模塊的規格是否和軟件需求文檔中的功能需求和軟件接口規格要求保持一致.2 是否給每個子模塊確定了抽象算法?3設計和算法是否能滿足模塊的所有需求?3-9：采用以下檢查表檢查設計的接口描述。序號問題1是否描述了接口的功能特征?2接口是否便于查錯?3接口相互之間、和其他模塊、和需求說明書及接口規格書保持一致？4對接口的數量和復雜度進行了有效的平衡，使接口數量控制在一個較小數量，每個接口具有可接受的復雜度？5是否所有的接口都能描述了必要的類型、數量、質量等信息？6操作界面是否考慮了用戶（例如：提供準確、清晰、有用的提示信息）？3-10：采用以下檢查表檢查

24、設計的詳細程度。序號問題1是否估計了每個子模塊的規模（代碼的行數）？是否可信？2是否考慮了足夠數量及代表性的系統狀態？3詳細程度是否足夠進行下一步的詳細設計？3-11：采用以下檢查表檢查設計的可維護性。序號問題1是否模塊化設計？2模塊是否為高內聚、低耦合？3-12：采用以下檢查表檢查設計的性能。序號問題1是否進行了性能模型分析？2是否描述了所有的性能參數？（例如：實時性能約束，存儲空間，速度要求，磁盤I/O空間）3 進程是否有時間窗？（例如：需要“加鎖”的標記，信號燈，某些代碼執行時需要屏蔽中斷）？4程序執行過程中的關鍵路徑是否都被標識和經過分析？3-13：采用以下檢查表檢查設計的可靠性。序號

25、問題1設計是否考慮了檢錯和恢復措施？（例如：輸入檢查）2是否考慮了異常情況？3是否完全準確描述了所有的出錯情況？4設計是否能夠滿足所有系統集成方面的要求？3-14：采用以下檢查表檢查設計的可測試性。序號問題1設計是否能夠被實驗、演示或檢視以顯示它滿足了需求？2設計是否能夠使用以前的測試代碼，是否能夠進行增量式的測試？3-15：采用以下檢查表檢查設計的可追溯性。序號問題1是否每一部分的設計都可以追溯到需求說明書，接口規格說明書、或其他產品文檔？2是否所有的設計決策都可以追溯到財務分析？3對所繼承下來的那些特別和不常用的特性對目前設計的影響是否進行了分析？4對所繼承設計中已知的風險是否進行了定位和

26、分析？ 4 詳細設計4-1：詳細設計要以軟件需求規格和概要設計為基礎，必須保證需要實現的需求規格已經被設計，必須保證概要設計定義的所有模塊已經被詳細設計。4-2：當需求規格或概要設計發生變更時，必須修訂相關詳細設計文檔。4-3：在詳細設計文檔或需求管理文檔中，必須記錄、驗證需求、概要設計、詳細設計的跟蹤關系。說明：需求、概要設計、詳細設計的跟蹤關系可參考建議4-1。4-1：采用需求、子系統、模塊、函數的跟蹤矩陣表記錄需求、概要設計、詳細設計的跟蹤關系。4-4：必須保證詳細設計文檔和代碼的一致性。當發生設計更改時，必須修訂相應設計文檔。4-5：必須對重要的詳細設計文檔進行正規檢視。說明：參考建議

27、4-2。4-2：根據模塊的復雜度、規模和在軟件系統中的重要程度，選擇重要的詳細設計文檔進行正規檢視。在產品中，進行正規檢視的詳細設計文檔比例要達到60%。4-6：詳細設計過程結束前，必須通過評審，并保存評審記錄。4-7：設計更改必須經過相關評審，并保存評審記錄。4-8：對詳細設計文檔的正規檢視或評審，必須檢查詳細設計文檔的清晰性、完備性、規范性、一致性、正確性、數據、功能性、接口、詳細程度、可維護性、性能、可靠性、可測試性、可追溯性。說明：參考建議4-3。4-3：采用以下檢查表檢查詳細設計文檔的清晰性。序號問題1是否所有的單元和進程的設計目的都已文檔化？2單元設計，包括數據流、控制流、接口描述

28、是否清楚？3單元的整體功能是否描述清楚？4-4：采用以下檢查表檢查詳細設計文檔的完備性。序號問題1是否提供了所有程序單元的規格？2是否描述了所采用的設計標準？3是否確定了單元應用的算法？（例如：PDL）4是否列出了單元的所有調用？5是否記錄了設計繼承的歷史和已知的風險？4-5：采用以下檢查表檢查詳細設計文檔的規范性。序號問題1文檔是否遵從了公司的標準？2單元設計是否使用了要求的方法和工具？4-6：采用以下檢查表檢查詳細設計的一致性。序號問題1在單元和單元的接口中數據成員的名稱是否保持一致？2所有接口之間，接口和接口規格書之間是否保持一致？3詳細設計和概要設計文檔是否能夠完全描述“正在構建”的系

29、統4-7：采用以下檢查表檢查詳細設計的正確性。序號問題1是否有邏輯錯誤？2需要使用常量名稱的地方是否有錯誤？3是否所有的條件都被處理？（>,=,< ,switch case)?4分支所處的狀態是否正確？ （邏輯沒有搞反）4-8：采用以下檢查表檢查詳細設計的數據描述。序號問題1是否所有聲明的數據塊都已經使用？2定位于單元的數據結構是否已經描述？3如果有對共享數據、文件的修改，對數據的訪問是否按照正確的共享協議進行？（例如：通過信號燈同步進程）4是否所有的邏輯單元、事件標記、同步標記都已經定義和初始化？5是否所有的變量、指針、常量都已經定義并初始化？4-9：采用以下檢查表檢查詳細設計的

30、功能性要求。序號問題1設計是否使用了指定的算法？2設計是否能夠滿足需求和目的？4-10：采用以下檢查表檢查詳細設計的接口描述。序號問題1參數表是否在數量、類型和順序上保持一致？2是否所有的輸入輸出都已經正確定義并檢查過？3所傳遞參數的順序是否描述清楚？4參數傳遞的機制是否確定？5通過接口傳遞的常量和變量是否與單元設計的相同？（例如，函數中定義的常量不能在所調用的子過程中被修改）6傳入、傳出函數的參數，控制標記是否都已經描述清楚。7是否以度量單位描述了參數的值區間，準確性和精度。4-11：采用以下檢查表檢查詳細設計的詳細程度。序號問題1代碼和文檔間的展開率是否小于10：1？2對模塊的所有需求都已

31、經定義？3詳細程度是否足夠開發和維護代碼？4-12：采用以下檢查表檢查詳細設計的可維護性。序號問題1單元是否是高內聚和低外部耦合？（例如：單元的改變不會在內部出現不可預見的影響，同時對其他單元的影響最小？2是否這種設計是復雜度最小的設計？3開始部分的描述是否符合公司的要求？（例如：目的，作者，環境，非標準特性，開發歷史，輸入輸出參數，使用的文件，數據結構，引用此單元的其他單元，注釋。4-13：采用以下檢查表檢查詳細設計的性能。序號問題1進程是否有時間窗？2是否所有的時間和空間的限制都已明確？4-14：采用以下檢查表檢查詳細設計的可靠性。序號問題1初始化時是否使用了默認值，是否正確？2訪問內存時

32、是否進行了邊界檢查，以保證地址正確？（隊列，數據結構，指針，等等）3對輸入、輸出、接口和結果是否進行了錯誤檢查？4對所有錯誤情況都安排了有意義的消息反饋？5特殊情況下的返回碼是否和文檔中定義的全局返回碼一致？6是否考慮了異常情況？4-15：采用以下檢查表檢查詳細設計的可測試性。序號問題1是否每個單元都可以被測試、演示、分析或者檢視，以確認滿足需求。2設計中是否包括輔助測試的檢查點？（例如：條件編譯代碼、斷言等）3是否所有的邏輯都是可測的?4是否描述了本單元的測試驅動模塊，測試用例集，測試結果?4-16：采用以下檢查表檢查詳細設計的可追溯性。序號問題1是否每一部分的設計都可以追溯到需求？2是否每

33、一個設計決策都可以追溯到效益分析？3是否所有的設計決策都可以追溯到成本/效益分析？4是不是描述了每個單元的詳細需求？5單元需求是否能夠追溯到軟件規格文檔（SSD-1）？軟件規格文檔是否能夠跟蹤到單元需求？6是否有到代碼的引用或者包括代碼本身？5 編碼5-1：編碼必須以設計文檔為基礎，必須保證所有的設計都被編碼實現。當設計發生變更時，必須修改相關代碼。5-2：必須保證設計文檔和代碼的一致性。當代碼的修改已經造成設計更改時，必須修訂相應設計文檔。5-3：必須對重要的代碼進行正規檢視。說明：參考建議5-1。5-1：根據模塊、函數/單元/進程的復雜度、規模和在軟件系統中的重要程度，選擇重要的代碼進行正

34、規檢視。在產品中，進行正規檢視的代碼比例要達到40%。5-4：在代碼已經基線化后，對代碼的更改必須通過評審，并保存評審記錄。5-5：代碼必須遵守相關的編程規范規定。5-6：對代碼的正規檢視和評審，必須依照相關編程規范規定檢查編程規范符合情況。6 需求管理6-1：產品項目必須安排人員負責需求管理的職責。說明：職責參見建議6-1。6-1：需求管理的職責至少應包括以下內容：序號內容1在產品項目整個生存周期內，管理系統需求和它們的分配，并對其建立文檔。2實現對系統需求及其分配的更改。6-2：必須建立文檔標識分配到軟件中的產品系統需求。說明：文檔的內容參見建議6-2。6-2： 標識分配到軟件中的產品系統

35、需求的文檔至少應包含以下內容:序號內容1影響和確定軟件項目活動的非技術性需求（即：協議、條件、合同條款等）。2對軟件的技術需求。3用于確認軟件產品滿足分配需求的驗收標準。6-3：相關人員必須接受需求管理活動方面的培訓。說明：參見建議6-3。6-3： 培訓至少包括以下內容:序號內容1項目所使用的方法、標準、規程2應用領域的知識6-4：必須對對經過評審和批準的需求文檔進行管理和控制。說明：參見建議6-4。6-4：對經過評審和批準的需求至少應采用以下方法進行管理和控制：序號內容1在配置管理計劃（SCMP）中將需求文檔定義為CI。2對需求文檔進行配置管理。3相應的參考文檔進行變更/維護。6-5：必須對

36、需求變更采用嚴格的變更控制流程控制。說明：參見建議6-5。6-5：變更控制流程至少應包含以下內容：序號內容1對變化的影響進行評估2經過CCB組織的評審3通知受影響的組和個人4跟蹤解決該問題，直到關閉6-6：必須在開發過程中對需求進行跟蹤。說明：參見建議6-6。6-6：需求跟蹤活動至少應包括以下內容：序號內容1按照公司模板制定需求跟蹤說明書2跟蹤需求狀態的變化3需求的跟蹤和分配經過評審6-7：在需求管理活動中必須建立相關度量記錄。說明：參見建議6-76-7：對需求活動的度量至少應包含以下內容：序號內容1需求的數量2需求的狀態3需求的類型4需求的更改次數6-8：需求管理活動和其文檔必須接受上級管理

37、部門、產品項目經理、SQA的評審。7 軟件配置管理7-1：產品項目要任命配置管理的人員和組織，在整個配置管理活動中明確他們的職責。說明：參考建議7-1。7-1：參照軟件配置管理規范和軟件配置管理指導書，任命SCM組織。7-2：產品項目必須制定軟件配置管理計劃（SCMP)，指導整個配置管理活動。說明：參考建議7-2。7-2：項目經理根據配置管理計劃（模板），負責制定配置管理計劃。7-3：軟件配置管理計劃必須包括如下的內容：序號內容1對各階段應受控的配置項進行選擇、分類、標識。2定義配置項(CI)的命名慣例3定義版本號命名方案4制定培訓計劃5定義相關SCM流程6制定相應配置評審計劃和方法7-4：軟

38、件配置管理計劃必須經過由開發人員、產品項目經理、SQA參加的評審，并獲得批準，并基線化。7-5：軟件配置管理計劃和軟件項目開發計劃必須同步變更。7-6：問題跟蹤要有一套流程支持，該流程要包括問題的描述，分類，評估，設計，實現，驗證，歸檔的整個生命過程。7-7：變更申請要有一套流程支持，該流程要保證該變更申請（針對已基線化的配置項）有一個初始化，分類，設計，評估，分派，實現，驗證，歸檔的整個過程。7-8：每個版本有一個符合規范的版本描述文檔。7-9：必須定義流程指導配置狀態發布。說明：參考建議7-3。7-3：在配置管理計劃中描述配置狀態發布的周期，內容和模板。7-10：配置項(CI)的變更和配置

39、管理活動的運行狀態通知到相關的部門組織和個人。7-11：定期對變更申請(CR)的處理情況進行統計并將統計和分析結果進行發布，發布內容至少包括：單位時間內處理的CRs數量，CRs分布統計表，CRs流通量統計表，CRs狀態分布統計表等。說明：參考建議7-4。7-4：建議正常情況2周發布一次，更改頻繁時是1周，更改較少時是3周7-12：建立可以體現開發版本和基線版本兩種不同受控程度的配置庫系統說明：參考建議7-5。7-5：建議使用SCM工具的分支功能實現不同類型的版本控制7-13：制定一個基線化流程指導建立基線。說明：參考建議7-6。7-6：建議在配置管理計劃中對流程進行描述，該流程要保證基線化過程

40、中的物理配置審計（PCA,功能配置審計（FCA,SQA評審和審計等過程。7-14：內外的發布必須只能來自基線庫。7-15：產品項目經理、SQA要定期對SCM的活動和其文檔進行評審/檢查，輸出評審/檢查結果，制定并實施改進措施7-16：相關SCM評審要制定相應的Checklist進行指導，評審要有記錄。8 軟件質量保證8-1：產品項目組要有相關的SQA人員和組織，并開展SQA活動。8-2: 產品項目SQA的組織活動必須通過如下檢查。序號問題1產品項目是否建立一個獨立的、能夠支持那些要求獨立性活動的SQA組織？對所有項目，SQA功能是否到位？2SQA組是否有一個向產品組之上的管理者、管理部門報告的

41、渠道？3是否為組織進行SQA活動提供足夠的資源和費用？4SQA組的成員是否接受了培訓以完成他們的SQA活動？5項目的軟件相關成員是否接受了有關SQA組任務、職責、權利等的相關培訓？6上級管理部門是否對產品項目的SQA活動及其結果進行了定期評審？7產品項目經理是否定期和事件驅動地參與評審SQA活動?8SQA組活動及其工作產品是否接受了SQA組之外的專家進行的定期評審？9項目組是否制定一個執行SQA活動的計劃SQAP。如制定了SQA計劃，計劃的制訂是否按照已文檔化的組織的SQA規程和SQA計劃模版執行？8-3: 產品項目必須有SQA計劃，SQA計劃必須通過如下檢查。序號問題1制定SQA計劃的活動是

42、否按照公司的相關規范進行？ 如果存在偏差，是否形成了偏差文檔，并得到研究技術管理處的批準？2SQA計劃是否符合公司規范中SQA計劃模板的要求？ 如果存在偏差，是否形成了偏差文檔，并得到研究技術管理處的批準？ 3SQA活動是否按照SQA計劃進行？ 4SQA計劃是否經過計劃中涉及的相關組和個人的評審，并得到SQA經理、產品項目經理的批準？5SQA計劃和軟件項目計劃是否在項目的里程碑處進行了修改，修改是否得到批準？SQA計劃和軟件項目開發計劃是否同步變更？8-4：SQA必須對產品軟件開發過程進行過程審計。說明：參考建議8-1。8-1：要對以下的過程進行審計：需求分析過程、軟件概要設計過程、軟件詳細設

43、計過程、軟件測試過程、版本發布過程、配置管理過程、變更控制過程、需求管理過程。8-5：SQA的過程審計必須通過如下的檢查。序號問題1產品項目是否明確定義了各種軟件活動過程？定義的活動過程是否經過SQA和相關管理部門的批準？2軟件過程審計是否按照公司制訂的軟件過程審計規程執行？3SQA是否對每一個軟件活動過程提交了過程審計報告？4是否提交了過程不符合項報告？5SQA的過程審計結果是否通過適當的渠道報告給適當的管理者？8-6：SQA必須參與項目的技術評審活動。說明：參考建議8-2，8-3。8-2：SQA必須參與項目的技術評審活動包括：需求評審、系統設計評審、概要設計評審、詳細設計評審等 。8-3：

44、SQA在技術評審過程應檢查：序號問題1技術評審的方法對被評審的軟件工作產品是合適的？2技術評審的過程是按照公司制訂的技術評審過程規程執行的嗎？3技術評審的結果是否相應的評審規程的要求形成了報告？4技術評審的報告，報告給SQA人員了嗎？5SQA人員對技術評審的結果進行分析了嗎？8-7：SQA人員必須定期生成SQA活動的報告。說明：參考建議8-4。8-4：對SQA報告的檢查包括：序號內容1是否報告各種軟件工作產品的評審記錄？2報告的評審記錄是否符合公司規范的要求？3是否有軟件過程審計的審計報告？4是否把報告送交給上級管理部門、技術管理處、產品項目經理嗎？5是否有軟件過程分析和質量報告？8-8：產品

45、項目的SQA人員必須制定一個實施SQA工作的月度計劃、季度計劃，和年度計劃。計劃必須得到上級SQA經理的評審和批準。8-9：SQA經理應當每月定期地與其下屬SQA人員，就其工作的月度計劃、季度計劃，和年度計劃進行協商溝通。8-10：SQA經理應當對其下屬的SQA人員的SQA活動的實際完成情況與計劃進行監督和管理。對其管轄的SQA人員的SQA活動進行定期地（至少每月一次)審核。8-11：當SQA人員遇到不能在產品項目組內部協商解決的質量問題時，必須將該問題上報給產品/業務部管理者和其上級SQA經理。9 數據度量和分析9-1：每個項目要記錄軟件過程數據。9-1:建議每個項目建立一個軟件過程數據庫。

46、說明：該數據庫可以采用電子表格或NOTES流等形式。9-2：項目軟件過程數據庫得到管理且存取訪問受控。說明：敏感數據要受到保護。9-3：必須對軟件規模進行度量。說明：按書面規程估計工作產品的規模和更改規模，對所有主要軟件工作產品和活動都作估計，軟件工作產品能分解到能滿足估計所需要的粒度。可由一組同行或專家審核估計值。軟件規模度量的例子如下：功能點數目代碼行數文檔頁數需求數目等的估計值與實際值9-4：必須對軟件復雜度進行度量。9-5：對工作量進行度量說明：按書面規程導出工作量估計，要進行軟件工作量度量如下：工作量在軟件生存周期的分布的估計值與實際值各軟件工作產品的工作量的估計值與實際值獨立管理的作業或階段的工作量的估計值與實際值SQA工作量的估計值與實際值SCM工作量的估計值與實際值準備同行評審的工作量的估計值與實際值參加同行評審的工作量的估計值與實際值用于過程評估的工作量的估計值與實際值用于過程制定和改進的工作量的估計值與實際值管理項目的工作量的估計值與實際值項目計