軟件開發(fā)規(guī)范

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19、標明糾正措施。必要的情況下，要及時修訂“軟件項目計劃”。2-12：在軟件項目跟蹤監(jiān)控活動中，必須定期進行總結和評審，撰寫開發(fā)狀態(tài)報告。2-19：根據項目的特點，報告的周期可以為周、雙周、月。2-13：在軟件開發(fā)各里程碑階段結束前，必須進行階段評審，對軟件項目進行重估計，必要的情況下修訂“軟件項目計劃”。 2-20：必須提供相應資源，包括工具和人員等，進行軟件項目計劃和項目跟蹤監(jiān)控活動。2-14：在軟件項目計劃和項目跟蹤監(jiān)控過程活動中，必須進行數據度量和分析。說明：參見“9. 數據度量和分析”。僅供內部使用11軟件開發(fā)行為規(guī)范3 概要設計3 概要設計3-1：概要設計要以軟件需求規(guī)格為基礎，必須保

20、證需要實現的需求規(guī)格已經被設計。3-2：當需求規(guī)格發(fā)生變更時，必須修訂相關概要設計文檔。3-3：在概要設計文檔或需求管理文檔中，必須記錄、驗證需求和概要設計的跟蹤關系。說明：需求和概要設計的跟蹤關系可參考建議3-1。3-1：采用需求、子系統(tǒng)、模塊的跟蹤矩陣表記錄需求和概要設計的跟蹤關系。3-4：必須保證概要設計文檔和代碼的一致性。當發(fā)生設計更改時，必須修訂相應設計文檔。3-5：必須對概要設計文檔進行正規(guī)檢視。3-6：概要設計過程結束前，必須通過評審，并保存評審記錄。3-7：設計更改必須經過相關評審，并保存評審記錄。3-8：對概要設計文檔的正規(guī)檢視或評審，必須檢查概要設計文檔的清晰性、完備性、規(guī)

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

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

23、 數據成員的有效值區(qū)間是否定義? 4共享和存儲數據的使用是否描述清楚?3-8：采用以下檢查表檢查概要設計文檔的功能性要求。序號問題1模塊的規(guī)格是否和軟件需求文檔中的功能需求和軟件接口規(guī)格要求保持一致.2 是否給每個子模塊確定了抽象算法?3設計和算法是否能滿足模塊的所有需求?3-9：采用以下檢查表檢查設計的接口描述。序號問題1是否描述了接口的功能特征?2接口是否便于查錯?3接口相互之間、和其他模塊、和需求說明書及接口規(guī)格書保持一致？4對接口的數量和復雜度進行了有效的平衡，使接口數量控制在一個較小數量，每個接口具有可接受的復雜度？5是否所有的接口都能描述了必要的類型、數量、質量等信息？6操作界面是

24、否考慮了用戶（例如：提供準確、清晰、有用的提示信息）？3-10：采用以下檢查表檢查設計的詳細程度。序號問題1是否估計了每個子模塊的規(guī)模（代碼的行數）？是否可信？2是否考慮了足夠數量及代表性的系統(tǒng)狀態(tài)？3詳細程度是否足夠進行下一步的詳細設計？3-11：采用以下檢查表檢查設計的可維護性。序號問題1是否模塊化設計？2模塊是否為高內聚、低耦合？3-12：采用以下檢查表檢查設計的性能。序號問題1是否進行了性能模型分析？2是否描述了所有的性能參數？（例如：實時性能約束，存儲空間，速度要求，磁盤I/O空間）3 進程是否有時間窗？（例如：需要“加鎖”的標記，信號燈，某些代碼執(zhí)行時需要屏蔽中斷）？4程序執(zhí)行過程

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

26、用的特性對目前設計的影響是否進行了分析？4對所繼承設計中已知的風險是否進行了定位和分析？ 僅供內部使用14軟件開發(fā)行為規(guī)范4 詳細設計4 詳細設計4-1：詳細設計要以軟件需求規(guī)格和概要設計為基礎，必須保證需要實現的需求規(guī)格已經被設計，必須保證概要設計定義的所有模塊已經被詳細設計。4-2：當需求規(guī)格或概要設計發(fā)生變更時，必須修訂相關詳細設計文檔。4-3：在詳細設計文檔或需求管理文檔中，必須記錄、驗證需求、概要設計、詳細設計的跟蹤關系。說明：需求、概要設計、詳細設計的跟蹤關系可參考建議4-1。4-1：采用需求、子系統(tǒng)、模塊、函數的跟蹤矩陣表記錄需求、概要設計、詳細設計的跟蹤關系。4-4：必須保證詳

27、細設計文檔和代碼的一致性。當發(fā)生設計更改時，必須修訂相應設計文檔。4-5：必須對重要的詳細設計文檔進行正規(guī)檢視。說明：參考建議4-2。4-2：根據模塊的復雜度、規(guī)模和在軟件系統(tǒng)中的重要程度，選擇重要的詳細設計文檔進行正規(guī)檢視。在產品中，進行正規(guī)檢視的詳細設計文檔比例要達到60%。4-6：詳細設計過程結束前，必須通過評審，并保存評審記錄。4-7：設計更改必須經過相關評審，并保存評審記錄。4-8：對詳細設計文檔的正規(guī)檢視或評審，必須檢查詳細設計文檔的清晰性、完備性、規(guī)范性、一致性、正確性、數據、功能性、接口、詳細程度、可維護性、性能、可靠性、可測試性、可追溯性。說明：參考建議4-3。4-3：采用以

28、下檢查表檢查詳細設計文檔的清晰性。序號問題1是否所有的單元和進程的設計目的都已文檔化？2單元設計，包括數據流、控制流、接口描述是否清楚？3單元的整體功能是否描述清楚？4-4：采用以下檢查表檢查詳細設計文檔的完備性。序號問題1是否提供了所有程序單元的規(guī)格？2是否描述了所采用的設計標準？3是否確定了單元應用的算法？（例如：PDL）4是否列出了單元的所有調用？5是否記錄了設計繼承的歷史和已知的風險？4-5：采用以下檢查表檢查詳細設計文檔的規(guī)范性。序號問題1文檔是否遵從了公司的標準？2單元設計是否使用了要求的方法和工具？4-6：采用以下檢查表檢查詳細設計的一致性。序號問題1在單元和單元的接口中數據成員

29、的名稱是否保持一致？2所有接口之間，接口和接口規(guī)格書之間是否保持一致？3詳細設計和概要設計文檔是否能夠完全描述“正在構建”的系統(tǒng)4-7：采用以下檢查表檢查詳細設計的正確性。序號問題1是否有邏輯錯誤？2需要使用常量名稱的地方是否有錯誤？3是否所有的條件都被處理？（>,=,< ,switch case)?4分支所處的狀態(tài)是否正確？ （邏輯沒有搞反）4-8：采用以下檢查表檢查詳細設計的數據描述。序號問題1是否所有聲明的數據塊都已經使用？2定位于單元的數據結構是否已經描述？3如果有對共享數據、文件的修改，對數據的訪問是否按照正確的共享協議進行？（例如：通過信號燈同步進程）4是否所有的邏輯單

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

31、和精度。4-11：采用以下檢查表檢查詳細設計的詳細程度。序號問題1代碼和文檔間的展開率是否小于10：1？2對模塊的所有需求都已經定義？3詳細程度是否足夠開發(fā)和維護代碼？4-12：采用以下檢查表檢查詳細設計的可維護性。序號問題1單元是否是高內聚和低外部耦合？（例如：單元的改變不會在內部出現不可預見的影響，同時對其他單元的影響最??？2是否這種設計是復雜度最小的設計？3開始部分的描述是否符合公司的要求？（例如：目的，作者，環(huán)境，非標準特性，開發(fā)歷史，輸入輸出參數，使用的文件，數據結構，引用此單元的其他單元，注釋。4-13：采用以下檢查表檢查詳細設計的性能。序號問題1進程是否有時間窗？2是否所有的時間

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

33、，測試用例集，測試結果?4-16：采用以下檢查表檢查詳細設計的可追溯性。序號問題1是否每一部分的設計都可以追溯到需求？2是否每一個設計決策都可以追溯到效益分析？3是否所有的設計決策都可以追溯到成本/效益分析？4是不是描述了每個單元的詳細需求？5單元需求是否能夠追溯到軟件規(guī)格文檔（SSD-1）？軟件規(guī)格文檔是否能夠跟蹤到單元需求？6是否有到代碼的引用或者包括代碼本身？僅供內部使用18軟件開發(fā)行為規(guī)范5 編碼5 編碼5-1：編碼必須以設計文檔為基礎，必須保證所有的設計都被編碼實現。當設計發(fā)生變更時，必須修改相關代碼。5-2：必須保證設計文檔和代碼的一致性。當代碼的修改已經造成設計更改時，必須修訂相

34、應設計文檔。5-3：必須對重要的代碼進行正規(guī)檢視。說明：參考建議5-1。5-1：根據模塊、函數/單元/進程的復雜度、規(guī)模和在軟件系統(tǒng)中的重要程度，選擇重要的代碼進行正規(guī)檢視。在產品中，進行正規(guī)檢視的代碼比例要達到40%。5-4：在代碼已經基線化后，對代碼的更改必須通過評審，并保存評審記錄。5-5：代碼必須遵守相關的編程規(guī)范規(guī)定。5-6：對代碼的正規(guī)檢視和評審，必須依照相關編程規(guī)范規(guī)定檢查編程規(guī)范符合情況。僅供內部使用19軟件開發(fā)行為規(guī)范6 需求管理6 需求管理6-1：產品項目必須安排人員負責需求管理的職責。說明：職責參見建議6-1。6-1：需求管理的職責至少應包括以下內容：序號內容1在產品項目

35、整個生存周期內，管理系統(tǒng)需求和它們的分配，并對其建立文檔。2實現對系統(tǒng)需求及其分配的更改。6-2：必須建立文檔標識分配到軟件中的產品系統(tǒng)需求。說明：文檔的內容參見建議6-2。6-2： 標識分配到軟件中的產品系統(tǒng)需求的文檔至少應包含以下內容:序號內容1影響和確定軟件項目活動的非技術性需求（即：協議、條件、合同條款等）。2對軟件的技術需求。3用于確認軟件產品滿足分配需求的驗收標準。6-3：相關人員必須接受需求管理活動方面的培訓。說明：參見建議6-3。6-3： 培訓至少包括以下內容:序號內容1項目所使用的方法、標準、規(guī)程2應用領域的知識6-4：必須對對經過評審和批準的需求文檔進行管理和控制。說明：參

36、見建議6-4。6-4：對經過評審和批準的需求至少應采用以下方法進行管理和控制：序號內容1在配置管理計劃（SCMP）中將需求文檔定義為CI。2對需求文檔進行配置管理。3相應的參考文檔進行變更/維護。6-5：必須對需求變更采用嚴格的變更控制流程控制。說明：參見建議6-5。6-5：變更控制流程至少應包含以下內容：序號內容1對變化的影響進行評估2經過CCB組織的評審3通知受影響的組和個人4跟蹤解決該問題，直到關閉6-6：必須在開發(fā)過程中對需求進行跟蹤。說明：參見建議6-6。6-6：需求跟蹤活動至少應包括以下內容：序號內容1按照公司模板制定需求跟蹤說明書2跟蹤需求狀態(tài)的變化3需求的跟蹤和分配經過評審6-

37、7：在需求管理活動中必須建立相關度量記錄。說明：參見建議6-76-7：對需求活動的度量至少應包含以下內容：序號內容1需求的數量2需求的狀態(tài)3需求的類型4需求的更改次數6-8：需求管理活動和其文檔必須接受上級管理部門、產品項目經理、SQA的評審。僅供內部使用21軟件開發(fā)行為規(guī)范7 軟件配置管理7 軟件配置管理7-1：產品項目要任命配置管理的人員和組織，在整個配置管理活動中明確他們的職責。說明：參考建議7-1。7-1：參照軟件配置管理規(guī)范和軟件配置管理指導書，任命SCM組織。7-2：產品項目必須制定軟件配置管理計劃（SCMP)，指導整個配置管理活動。說明：參考建議7-2。7-2：項目經理根據配置管

38、理計劃（模板），負責制定配置管理計劃。7-3：軟件配置管理計劃必須包括如下的內容：序號內容1對各階段應受控的配置項進行選擇、分類、標識。2定義配置項(CI)的命名慣例3定義版本號命名方案4制定培訓計劃5定義相關SCM流程6制定相應配置評審計劃和方法7-4：軟件配置管理計劃必須經過由開發(fā)人員、產品項目經理、SQA參加的評審，并獲得批準，并基線化。7-5：軟件配置管理計劃和軟件項目開發(fā)計劃必須同步變更。7-6：問題跟蹤要有一套流程支持，該流程要包括問題的描述，分類，評估，設計，實現，驗證，歸檔的整個生命過程。7-7：變更申請要有一套流程支持，該流程要保證該變更申請（針對已基線化的配置項）有一個初始

39、化，分類，設計，評估，分派，實現，驗證，歸檔的整個過程。7-8：每個版本有一個符合規(guī)范的版本描述文檔。7-9：必須定義流程指導配置狀態(tài)發(fā)布。說明：參考建議7-3。7-3：在配置管理計劃中描述配置狀態(tài)發(fā)布的周期，內容和模板。7-10：配置項(CI)的變更和配置管理活動的運行狀態(tài)通知到相關的部門組織和個人。7-11：定期對變更申請(CR)的處理情況進行統(tǒng)計并將統(tǒng)計和分析結果進行發(fā)布，發(fā)布內容至少包括：單位時間內處理的CRs數量，CRs分布統(tǒng)計表，CRs流通量統(tǒng)計表，CRs狀態(tài)分布統(tǒng)計表等。說明：參考建議7-4。7-4：建議正常情況2周發(fā)布一次，更改頻繁時是1周，更改較少時是3周7-12：建立可以體

40、現開發(fā)版本和基線版本兩種不同受控程度的配置庫系統(tǒng)說明：參考建議7-5。7-5：建議使用SCM工具的分支功能實現不同類型的版本控制7-13：制定一個基線化流程指導建立基線。說明：參考建議7-6。7-6：建議在配置管理計劃中對流程進行描述，該流程要保證基線化過程中的物理配置審計（PCA,功能配置審計（FCA,SQA評審和審計等過程。7-14：內外的發(fā)布必須只能來自基線庫。7-15：產品項目經理、SQA要定期對SCM的活動和其文檔進行評審/檢查，輸出評審/檢查結果，制定并實施改進措施7-16：相關SCM評審要制定相應的Checklist進行指導，評審要有記錄。僅供內部使用23軟件開發(fā)行為規(guī)范8 軟件

41、質量保證8 軟件質量保證8-1：產品項目組要有相關的SQA人員和組織，并開展SQA活動。8-2: 產品項目SQA的組織活動必須通過如下檢查。序號問題1產品項目是否建立一個獨立的、能夠支持那些要求獨立性活動的SQA組織？對所有項目，SQA功能是否到位？2SQA組是否有一個向產品組之上的管理者、管理部門報告的渠道？3是否為組織進行SQA活動提供足夠的資源和費用？4SQA組的成員是否接受了培訓以完成他們的SQA活動？5項目的軟件相關成員是否接受了有關SQA組任務、職責、權利等的相關培訓？6上級管理部門是否對產品項目的SQA活動及其結果進行了定期評審？7產品項目經理是否定期和事件驅動地參與評審SQA活

42、動?8SQA組活動及其工作產品是否接受了SQA組之外的專家進行的定期評審？9項目組是否制定一個執(zhí)行SQA活動的計劃SQAP。如制定了SQA計劃，計劃的制訂是否按照已文檔化的組織的SQA規(guī)程和SQA計劃模版執(zhí)行？8-3: 產品項目必須有SQA計劃，SQA計劃必須通過如下檢查。序號問題1制定SQA計劃的活動是否按照公司的相關規(guī)范進行？ 如果存在偏差，是否形成了偏差文檔，并得到研究技術管理處的批準？2SQA計劃是否符合公司規(guī)范中SQA計劃模板的要求？ 如果存在偏差，是否形成了偏差文檔，并得到研究技術管理處的批準？ 3SQA活動是否按照SQA計劃進行？ 4SQA計劃是否經過計劃中涉及的相關組和個人的評

43、審，并得到SQA經理、產品項目經理的批準？5SQA計劃和軟件項目計劃是否在項目的里程碑處進行了修改，修改是否得到批準？SQA計劃和軟件項目開發(fā)計劃是否同步變更？8-4：SQA必須對產品軟件開發(fā)過程進行過程審計。說明：參考建議8-1。8-1：要對以下的過程進行審計：需求分析過程、軟件概要設計過程、軟件詳細設計過程、軟件測試過程、版本發(fā)布過程、配置管理過程、變更控制過程、需求管理過程。8-5：SQA的過程審計必須通過如下的檢查。序號問題1產品項目是否明確定義了各種軟件活動過程？定義的活動過程是否經過SQA和相關管理部門的批準？2軟件過程審計是否按照公司制訂的軟件過程審計規(guī)程執(zhí)行？3SQA是否對每一

44、個軟件活動過程提交了過程審計報告？4是否提交了過程不符合項報告？5SQA的過程審計結果是否通過適當的渠道報告給適當的管理者？8-6：SQA必須參與項目的技術評審活動。說明：參考建議8-2，8-3。8-2：SQA必須參與項目的技術評審活動包括：需求評審、系統(tǒng)設計評審、概要設計評審、詳細設計評審等 。8-3：SQA在技術評審過程應檢查：序號問題1技術評審的方法對被評審的軟件工作產品是合適的？2技術評審的過程是按照公司制訂的技術評審過程規(guī)程執(zhí)行的嗎？3技術評審的結果是否相應的評審規(guī)程的要求形成了報告？4技術評審的報告，報告給SQA人員了嗎？5SQA人員對技術評審的結果進行分析了嗎？8-7：SQA人員

45、必須定期生成SQA活動的報告。說明：參考建議8-4。8-4：對SQA報告的檢查包括：序號內容1是否報告各種軟件工作產品的評審記錄？2報告的評審記錄是否符合公司規(guī)范的要求？3是否有軟件過程審計的審計報告？4是否把報告送交給上級管理部門、技術管理處、產品項目經理嗎？5是否有軟件過程分析和質量報告？8-8：產品項目的SQA人員必須制定一個實施SQA工作的月度計劃、季度計劃，和年度計劃。計劃必須得到上級SQA經理的評審和批準。8-9：SQA經理應當每月定期地與其下屬SQA人員，就其工作的月度計劃、季度計劃，和年度計劃進行協商溝通。8-10：SQA經理應當對其下屬的SQA人員的SQA活動的實際完成情況與計劃進行監(jiān)督和管