軟件項目研發(fā)管理流程

1、XX 信息軟件開發(fā)項目技術(shù)管理規(guī)范文件編號：生效日期：受控編號：2017.8.20RK-S20170802版次： Ver1.0修改狀態(tài)：編制：審核：批準：貴州 XX信息科技有限公司目錄一、編寫說明1二、軟件項目整體開發(fā)流程3三、各階段崗位職責與工作內(nèi)容4四、各階段工作要求81軟件需求分析82 軟件項目計劃1 23 概要設計1 64 詳細設計1 95 編碼2 36 需求管理2 47 軟件配置管理2 68 軟件質(zhì)量保證2 79 數(shù)據(jù)度量和分析3 0一、編寫說明為了把公司已經(jīng)發(fā)布的軟件開發(fā)過程規(guī)范有效地運作于產(chǎn)品開發(fā)活動中，把各種規(guī)范“逐步形成工程師的作業(yè)規(guī)范”，特制定本軟件開發(fā)行為規(guī)范，以達到過程

2、控制的目的。1/32與軟件開發(fā)相關(guān)的所有人員，包括各級經(jīng)理和工程師都必須遵守本軟件開發(fā)行為規(guī)范。對違反規(guī)范的開發(fā)行為，必須按照有關(guān)管理規(guī)定進行處罰。本軟件開發(fā)行為規(guī)范的內(nèi)容包括：軟件需求分析、軟件項目計劃、概要設計、詳細設計、編碼、需求管理、配置管理、軟件質(zhì)量保證、數(shù)據(jù)度量和分析等。本軟件開發(fā)行為規(guī)范，采用以下的術(shù)語描述： 規(guī)則 ：在軟件開發(fā)過程中強制必須遵守的行為規(guī)范。 建議 ：軟件開發(fā)過程中必須加以考慮的行為規(guī)范。 說明 ：對此規(guī)則或建議進行必要的解釋。 示例 ：對此規(guī)則或建議從正或反兩個方面給出例子。本軟件開發(fā)過程行為規(guī)范由技術(shù)研發(fā)部負責解釋和維護。2/32需求變更說明書二、軟件項目整體

3、開發(fā)流程立項管理需求分析開發(fā)計劃需求變更設計編碼質(zhì)量控制驗收交付風險分析說明書立項報告需求分析規(guī)格說明書項目或產(chǎn)品開發(fā)計劃概要設計說明書數(shù)據(jù)庫字典詳細設計說明書軟件代碼及注釋測試計劃測試用例及報告驗收報告3/32三、各階段崗位職責與工作內(nèi)容序工作名稱負責人參與人審批人工作內(nèi)容交付物工作說明號1.風險分析報告；2.如需進一步講1.項目或產(chǎn)品建設內(nèi)解，交付展示 PPT;容； 2.項目風險分析；3.如確定立項，交1立項管理項目經(jīng)理售前經(jīng)理總經(jīng)理3.明確后續(xù)工作； 4.討付立項報告及解決論解決方案。方案4.立項后，確認開發(fā)經(jīng)理總經(jīng)理或售前1.1項目介紹 項目經(jīng)理 項目經(jīng)理 系統(tǒng)或方案簡介 無經(jīng)理1.立

4、項報告、解決方案提交到開發(fā)經(jīng)理后，開始需求調(diào)研準備。1.需求規(guī)格說明書由售前經(jīng)理編制，售前經(jīng)理、開確認用戶需求及功能2需求分析項目經(jīng)理總工程師需求規(guī)格說明書提交開發(fā)經(jīng)理后；發(fā)經(jīng)理邊界開發(fā)經(jīng)理開始開發(fā)計劃編制4/32開發(fā)經(jīng)理完成計劃編制，人員配置完項目經(jīng)理、售1.確定開發(fā)工期；成后，經(jīng)項目經(jīng)理3開發(fā)計劃開發(fā)經(jīng)理項目經(jīng)理2.明確開發(fā)人員。項目開發(fā)計劃書提交客戶審核通前經(jīng)理3.開發(fā)計劃交付甲方過，開發(fā)經(jīng)理完成人員分工，開發(fā)業(yè)務啟動公司采用敏捷開發(fā)，開發(fā)經(jīng)理需按通用模塊 -基礎(chǔ)數(shù)4軟件設計開發(fā)經(jīng)理開發(fā)工程師總工程師1.數(shù)據(jù)庫設計1.數(shù)據(jù)字典；據(jù)管理模塊 -業(yè)務2.概要設計2.概要設計說明書管理模塊 -

5、數(shù)據(jù)應用模塊進行設計，區(qū)分無需設計的模塊可直接進行開發(fā)1.完成軟件編碼；開發(fā)工程師、2.完成詳細設計說明1.軟件代碼及數(shù)據(jù)詳細設計說明書由5軟件編碼開發(fā)經(jīng)理項目經(jīng)理書；庫該功能的開發(fā)工程測試工程師3.代碼迭代及版本控2.詳細設計說明書師編寫制5.1內(nèi)部審核開發(fā)經(jīng)理開發(fā)工程師總工程師1. 審核數(shù)據(jù)庫及代碼是采用定期抽樣審核否按公司技術(shù)規(guī)范執(zhí)行方式工作5/32各研發(fā)組，可自行確1. 按公司要求進行代碼認代碼進行本地迭5.2版本控制開發(fā)經(jīng)理總工程師迭代與版本控制；代方式，并定期將代2. 完成代碼備份碼提交貴陽總部迭代、備份靜態(tài)質(zhì)量審代碼提交到 SonarQube代碼靜態(tài)質(zhì)量審核報進入動態(tài)測試環(huán)節(jié)5.

6、3開發(fā)經(jīng)理總工程師前，必須提交靜態(tài)質(zhì)查進行靜態(tài)代碼審核告及整改說明量報告1.測試計劃采用敏捷測試，測6軟件測試測試經(jīng)理測試工程師、總工程師完成軟件測試2.功能測試報告試經(jīng)理根據(jù)開發(fā)進開發(fā)工程師（含測試用例）度，逐個模塊跟進3.壓力測試報告測試6.1試運行測試經(jīng)理開發(fā)經(jīng)理項目經(jīng)理實際生產(chǎn)環(huán)境進行軟件1. 軟件試運行報告取決于甲方是否提運行測試供試運行時間7軟件部署實施經(jīng)理項目經(jīng)理、開實施經(jīng)理在生產(chǎn)環(huán)境進行正式項目實施報告發(fā)工程師系統(tǒng)部署及投運驗收通過后，進行實施工程師、完成項目驗收并交付項目總結(jié)。開發(fā)組8驗收交付項目經(jīng)理總經(jīng)理驗收報告明確運維職責后，售前工程師客戶使用人員開始進入其他項目6/32

7、1.及時發(fā)現(xiàn)對項目運行期間的問題和客戶新需求；運維報告、需求更9項目運維實施經(jīng)理項目經(jīng)理2.需求甄別，需及時更改說明書改的提交開發(fā)經(jīng)理；3.保持客戶溝通7/32四、各階段工作要求1軟件需求分析1-1 ：軟件需求分析必須在產(chǎn)品需求規(guī)格的基礎(chǔ)上進行，并保證完全實現(xiàn)產(chǎn)品需求規(guī)格的定義。1-2 ：當產(chǎn)品的需求規(guī)格發(fā)生變更時，必須修訂軟件需求規(guī)格文檔。軟件需求規(guī)格的變更必須經(jīng)過評審，并保存評審記錄。1-3 ：必須對軟件需求規(guī)格文檔進行正規(guī)檢視。1-4 ：軟件需求分析過程活動結(jié)束前，必須經(jīng)過評審，并保存評審記錄。1-5 ：在對軟件需求規(guī)格文檔的正規(guī)檢視或評審時，必須檢查軟件需求規(guī)格文檔中需求的清晰性、完備

8、性、兼容性、一致性、正確性、可行性、易修改性、健壯性、易追溯性、易理解性、易測試性和可驗證性、性能、功能、接口、數(shù)據(jù)、可維護性等內(nèi)容。說明：參考建議1-1 到 1-16 。1-1 ：采用以下檢查表檢查軟件需求規(guī)格文檔中需求的清晰性。序號問題1 所有定義、實現(xiàn)方法是否清楚地表達了用戶的原始要求？2 在功能實現(xiàn)過程、方法和技術(shù)要求的描述上，是否沒有背離了功能的實際要求？3 是否沒有不能理解或造成誤解的描述？1-2 ：采用以下檢查表檢查軟件需求規(guī)格文檔中需求的完備性。序號問題1 需求定義中是否包含了有關(guān)文件（指質(zhì)量手冊、質(zhì)量計劃以及其它有關(guān)文件）種所規(guī)定的需求定義所應該包含的所有內(nèi)容？2 需求定義是

9、否包含了有關(guān)功能、性能、限制、目標、質(zhì)量等方面的所有需求？3 功能性需求是否覆蓋了所有非正常情況的處理？4 是否對各種操作模式（如正常、非正常、有干擾等）下的環(huán)境條件都作了規(guī)定？5 是否對所有功能與時間因素有關(guān)的方面都作了考慮？6 是否標識出了所有與時間因素有關(guān)的功能？它們的時間準則是否都說明了？時間準則的最大、最小執(zhí)行時間是否都定義了？7 是否標識并定義了在將來可能會變化的需求？8/328 是否定義了系統(tǒng)所有的輸入？9 是否標識清楚了系統(tǒng)輸入的來源？10 是否標識出了系統(tǒng)的輸出？11 是否說明了系統(tǒng)輸入、輸出的類型？12 是否說明了系統(tǒng)輸入、輸出的值域、單位、格式等？13 是否說明了如何進行

10、系統(tǒng)輸入的合法性檢查？14 是否定義了系統(tǒng)輸入、輸出的精度？15 是否定義了系統(tǒng)性能的各個方面？16 在不同負載情況下，是否規(guī)定了系統(tǒng)的處理能力？17 在不同情況下，是否規(guī)定了系統(tǒng)的響應時間？18 是否充分定義了關(guān)于人機界面的需求？19 是否對需求定義進行了可行性分析和相關(guān)文件（資料）是否已歸檔？20 是否對影響需求實現(xiàn)的因素進行了調(diào)查，調(diào)查結(jié)果是否已歸檔？21 是否有經(jīng)濟效益分析，分析結(jié)果是否已歸檔？22 是否詳細描述了有關(guān)硬件、軟件、操作人員、 操作過程等方面的安全性？23 是否評估了本項目對用戶、其它系統(tǒng)、環(huán)境的影響特性？24 是否按完成時間、 重要性對系統(tǒng)功能、外部接口、 性能進行了優(yōu)

11、先排序？1-3 ：采用以下檢查表檢查軟件需求規(guī)格文檔中需求的兼容性。序號問題1界面需求是否使軟硬件系統(tǒng)具有兼容性？2需求定義的文檔是否滿足項目文檔編寫標準？在矛盾時，是否有適當?shù)臉藴士晒┻x擇？1-4 ：采用以下檢查表檢查軟件需求規(guī)格文檔中需求的一致性。序號問題1 各個需求之間是否一致？是否有沖突和矛盾？2 所規(guī)定的模型、算法和數(shù)值方法是否相容？3 是否使用了標準的術(shù)語和定義形式？4 需求是否與其軟硬件操作環(huán)境相容？5 是否說明了軟件對其系統(tǒng)和環(huán)境的影響？6 是否說明了環(huán)境對軟件的影響？7 所采用的技術(shù)是否與用戶要求的技術(shù)一致？1-5 ：采用以下檢查表檢查軟件需求規(guī)格文檔中需求的正確性。序號問題

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

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

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

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

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

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

18、 ×期望估計最小估計/ 6估計記錄如下：工作產(chǎn)最大估計期望估計 (根據(jù)經(jīng)驗最小估計PERT估計品任務類比獲得 )規(guī)模工作量規(guī)模工作量規(guī)模工作量規(guī)模工作量XX 版本文檔頁12天文檔頁10天文檔頁5天文檔頁9.5天（增加數(shù):45; 增數(shù) :42;增數(shù) :30;增數(shù) :41;增XX 特加、修改加、修改加、修改加、修改性話統(tǒng)模塊設模塊設模塊設模塊設模塊概計數(shù)計數(shù)計數(shù)目 :5計數(shù)要設計目:12目 :10目 :10期望估計值是根據(jù)XX版本的話統(tǒng)模塊設計的數(shù)據(jù)獲得。2- 5 ：對某項工作產(chǎn)品和任務的軟件，同時采用兩種或以上的方法進行估計，以避免一種方法的偏差。2- 6 ：盡量采用歷史經(jīng)驗數(shù)據(jù)進行軟

19、件估計。12/322- 7 ：參照“軟件估計指導書”進行軟件估計。2- 8 ：軟件估計對應項目的任務分解結(jié)構(gòu)進行。說明：軟件估計對于項目的任務分解結(jié)構(gòu)對應得越清晰、越細致，相應的估計越準確。2- 9 ：在“軟件項目計劃”中必須包括項目管理活動的計劃。2- 10 ：在“軟件項目計劃”中包括軟件重用計劃。包括重用軟件部件的計劃和開發(fā)可重用軟件部件的計劃。2- 11 ： 在“軟件項目計劃”包括人員的培訓計劃。說明：項目人員計劃包括需要的人員類型、數(shù)量和技術(shù)等級的要求，相關(guān)人員的開始工作時間、工作周期、接受培訓的計劃等。2- 12 ：對軟件項目進行風險分析與評估。說明：可能存在的風險領(lǐng)域含：需求的不明

20、確和變更、外部的限制與對外的依賴、人力資源的到位情況、人力資源的技術(shù)等級滿足要求狀況、技術(shù)問題等。對風險的分析與評估實踐包括：從已知的情況推導出潛在風險；對風險進行分析，得出：潛在風險可能引發(fā)的問題的影響、潛在風險發(fā)生的可能性大小、風險發(fā)生的時間段等；排列風險的重點次序；對風險記錄成文件（屬于軟件項目計劃中的一部分）；風險經(jīng)受風險影響人審核，并取得他的同意；根據(jù)需要，在開發(fā)過程中對風險文檔進行維護和修訂。2-3 ：對應工作任務，制定項目的文檔計劃。2-4 ：軟件項目計劃中應該包括正規(guī)檢視活動計劃、軟件質(zhì)量保證計劃、軟件配置管理計劃。軟件質(zhì)量保證計劃和軟件配置管理計劃可以和軟件項目計劃在同一份文

21、檔中，也可以分開為三份文檔。說明：參考建議2-13 。2-13:軟件質(zhì)量保證計劃和軟件配置管理計劃作為獨立的計劃文檔。2-1 4 ：軟件項目計劃必須是整個項目開發(fā)過程的計劃，包括測試。13/322- 15 ：測試經(jīng)理對照整個開發(fā)計劃建立軟件驗證與確認計劃。軟件驗證與確認計劃可作為獨立的計劃文檔。2-5 ：必須對項目工作進行分解，確定項目的工作任務，任務的責任人、資源要求、時間要求、項目的進度。2-6 ：必須分析任務之間的依賴性，確定并明確標識項目的關(guān)鍵路徑。2-7 ：“軟件項目計劃”必須按照文檔模板的要求編寫。項目組可根據(jù)項目的實際情況，對文檔模板中的內(nèi)容進行裁減。項目組對文檔模板內(nèi)容的裁減必

22、須得到上級管理部門（包括產(chǎn)品計劃處、軟件工程組SEPG）的審核批準。2-8 ：軟件項目計劃必須經(jīng)過評審。說明：參考建議2-16 ，。2- 16 ：軟件項目計劃的評審采用以下檢查表。序號問題1 軟件項目計劃是否完全反映（對應）“軟件需求說明書”里的需求？2 軟件項目計劃是否有開發(fā)方法的說明？3 軟件項目計劃是否有資源需求的說明？4 軟件項目計劃是否包含風險管理計劃？5 軟件項目計劃是否包含了版本發(fā)布的機制？6 軟件項目計劃是否標識了所有必須的培訓計劃？7 軟件項目計劃是否標識了所有內(nèi)部和外部的傳遞關(guān)系？8 軟件項目計劃是否標明了項目的依賴關(guān)系？9 軟件項目計劃是否標明了角色和職責？10 軟件項目

23、計劃是否標明了匯報的機制？11 軟件項目計劃是否說明了跟蹤和監(jiān)控機制？12 軟件項目計劃是否包含“軟件質(zhì)量保證計劃”和“軟件配置管理計劃”？13 軟件項目計劃是否包含項目開發(fā)使用的工具？14 軟件項目計劃是否包含項目的各里程碑的說明？15 進度中是否標明了軟件項目計劃的關(guān)鍵路徑？2-17 ：參加“軟件項目計劃”評審的人員，除軟件經(jīng)理和項目組人員外，必須有產(chǎn)品經(jīng)理、上級管理部門（包括軟件工程組 SEPG ）、 SQA 人員。2-18 ：“軟件項目計劃”通過評審后，軟件經(jīng)理組織相關(guān)人員對任務進行承諾，簽定工作任務書。2-9 ：必須對“軟件項目計劃”進行配置管理，“軟件項目計劃”的更改必須經(jīng)過評審。

24、2-10 ：在開發(fā)活動中，必須按照項目跟蹤與監(jiān)控計劃和體制，對照“軟件項目計劃”，跟蹤項目開發(fā)14/32的實際結(jié)果和性能。2-11 ：當實際結(jié)果和“軟件項目計劃”發(fā)生偏離時，必須進行分析，根據(jù)分析結(jié)果標明糾正措施。必要的情況下，要及時修訂“軟件項目計劃”。2-12 ：在軟件項目跟蹤監(jiān)控活動中，必須定期進行總結(jié)和評審，撰寫開發(fā)狀態(tài)報告。2-19 ：根據(jù)項目的特點，報告的周期可以為周、雙周、月。2-13 ：在軟件開發(fā)各里程碑階段結(jié)束前，必須進行階段評審，對軟件項目進行重估計，必要的情況下修訂“軟件項目計劃”。2-20 ：必須提供相應資源，包括工具和人員等，進行軟件項目計劃和項目跟蹤監(jiān)控活動。2-1

25、4 ：在軟件項目計劃和項目跟蹤監(jiān)控過程活動中，必須進行數(shù)據(jù)度量和分析。說明：參見“ 9. 數(shù)據(jù)度量和分析”。15/323 概要設計3-1 ：概要設計要以軟件需求規(guī)格為基礎(chǔ)，必須保證需要實現(xiàn)的需求規(guī)格已經(jīng)被設計。3-2 ：當需求規(guī)格發(fā)生變更時，必須修訂相關(guān)概要設計文檔。3-3 ：在概要設計文檔或需求管理文檔中，必須記錄、驗證需求和概要設計的跟蹤關(guān)系。說明：需求和概要設計的跟蹤關(guān)系可參考建議3-1 。3-1 ：采用需求、子系統(tǒng)、模塊的跟蹤矩陣表記錄需求和概要設計的跟蹤關(guān)系。3-4 ：必須保證概要設計文檔和代碼的一致性。當發(fā)生設計更改時，必須修訂相應設計文檔。3-5 ：必須對概要設計文檔進行正規(guī)檢視

26、。3-6 ：概要設計過程結(jié)束前，必須通過評審，并保存評審記錄。3-7 ：設計更改必須經(jīng)過相關(guān)評審，并保存評審記錄。3-8 ：對概要設計文檔的正規(guī)檢視或評審，必須檢查概要設計文檔的清晰性、完備性、 規(guī)范性、一致性、正確性、數(shù)據(jù)、功能性、接口、詳細程度、可維護性、性能、可靠性、可測試性、可追溯性。說明：參考建議3-2 。3-2 ：采用以下檢查表檢查概要設計文檔的清晰性。序號問題1 程序結(jié)構(gòu)，包括數(shù)據(jù)流、控制流和接口的描述是否清楚？3-3 ：采用以下檢查表檢查概要設計文檔的完備性。序號問題1 設計目標是否定義？2 需求規(guī)格評審中不完整的需求 (TBD) 是否都已經(jīng)解決 ?3 如果以前定義的不完整的需

27、求 (TBD) 發(fā)生了改變 , 本設計是否能夠支持 ?4 是否對不完整需求 (TBD)的影響進行了評估 ?5對有可能不能實現(xiàn)的設計是否有風險管理計劃?6是否對設計模式進行了描述 ?3-4 ：采用以下檢查表檢查概要設計文檔的規(guī)范性。序號問題1 文檔是否符合公司模板和寫作要求?16/323-5 ：采用以下檢查表檢查概要設計文檔的一致性。序號問題2 程序、模塊、函數(shù)、數(shù)據(jù)成員的名稱是否保持一致？3 設計是否反映了真正的操作環(huán)境 ?硬件環(huán)境 ?軟件環(huán)境 ?4 對系統(tǒng)設計的多種可能的描述之間是否保持一致 ?( 例如 : 靜態(tài)結(jié)構(gòu)的描述和動態(tài)描述 )3-6 ：采用以下檢查表檢查概要設計文檔的正確性。序號問

28、題1 設計在計劃、預算、技術(shù)上是否可行？2 邏輯是否正確和完備？3-7 ：采用以下檢查表檢查概要設計文檔的數(shù)據(jù)描述。序號問題1是否對所有的數(shù)據(jù)成員 , 參數(shù) , 對象進行了描述 ?2是否所有需要的數(shù)據(jù)結(jié)構(gòu)都進行了定義, 或者定義了不需要的數(shù)據(jù)結(jié)構(gòu) ?3是否所有的數(shù)據(jù)成員都進行了足夠詳細的描述? 數(shù)據(jù)成員的有效值區(qū)間是否定義 ?4共享和存儲數(shù)據(jù)的使用是否描述清楚?3-8 ：采用以下檢查表檢查概要設計文檔的功能性要求。序號問題1 模塊的規(guī)格是否和軟件需求文檔中的功能需求和軟件接口規(guī)格要求保持一致 .2 是否給每個子模塊確定了抽象算法?3 設計和算法是否能滿足模塊的所有需求?3-9 ：采用以下檢查表

29、檢查設計的接口描述。序號問題1是否描述了接口的功能特征 ?2接口是否便于查錯 ?3 接口相互之間、和其他模塊、和需求說明書及接口規(guī)格書保持一致？4 對接口的數(shù)量和復雜度進行了有效的平衡，使接口數(shù)量控制在一個較小數(shù)量，每個接口具有可接受的復雜度？5 是否所有的接口都能描述了必要的類型、數(shù)量、質(zhì)量等信息？6 操作界面是否考慮了用戶 （例如： 提供準確、 清晰、有用的提示信息） ？3-10 ：采用以下檢查表檢查設計的詳細程度。序號問題1 是否估計了每個子模塊的規(guī)模（代碼的行數(shù)）？是否可信？2 是否考慮了足夠數(shù)量及代表性的系統(tǒng)狀態(tài)？3 詳細程度是否足夠進行下一步的詳細設計？17/323-11 ：采用以

30、下檢查表檢查設計的可維護性。序號問題1 是否模塊化設計？2 模塊是否為高內(nèi)聚、低耦合？3-12 ：采用以下檢查表檢查設計的性能。序號問題1 是否進行了性能模型分析？2 是否描述了所有的性能參數(shù)？（例如：實時性能約束，存儲空間，速度要求，磁盤 I/O 空間）3 進程是否有時間窗？（例如：需要“加鎖”的標記，信號燈，某些代碼執(zhí)行時需要屏蔽中斷）？4 程序執(zhí)行過程中的關(guān)鍵路徑是否都被標識和經(jīng)過分析？3-13 ：采用以下檢查表檢查設計的可靠性。序號問題1 設計是否考慮了檢錯和恢復措施？（例如：輸入檢查）2 是否考慮了異常情況？3 是否完全準確描述了所有的出錯情況？4 設計是否能夠滿足所有系統(tǒng)集成方面的

31、要求？3-14 ：采用以下檢查表檢查設計的可測試性。序號問題1 設計是否能夠被實驗、演示或檢視以顯示它滿足了需求？2 設計是否能夠使用以前的測試代碼，是否能夠進行增量式的測試？3-15 ：采用以下檢查表檢查設計的可追溯性。序號問題1 是否每一部分的設計都可以追溯到需求說明書，接口規(guī)格說明書、或其他產(chǎn)品文檔？2 是否所有的設計決策都可以追溯到財務分析？3 對所繼承下來的那些特別和不常用的特性對目前設計的影響是否進行了分析？4 對所繼承設計中已知的風險是否進行了定位和分析？18/324 詳細設計4-1 ：詳細設計要以軟件需求規(guī)格和概要設計為基礎(chǔ)，必須保證需要實現(xiàn)的需求規(guī)格已經(jīng)被設計，必須保證概要設

32、計定義的所有模塊已經(jīng)被詳細設計。4-2 ：當需求規(guī)格或概要設計發(fā)生變更時，必須修訂相關(guān)詳細設計文檔。4-3 ：在詳細設計文檔或需求管理文檔中，必須記錄、驗證需求、概要設計、詳細設計的跟蹤關(guān)系。說明：需求、概要設計、詳細設計的跟蹤關(guān)系可參考建議4-1 。4-1 ：采用需求、子系統(tǒng)、模塊、函數(shù)的跟蹤矩陣表記錄需求、概要設計、詳細設計的跟蹤關(guān)系。4-4 ：必須保證詳細設計文檔和代碼的一致性。當發(fā)生設計更改時，必須修訂相應設計文檔。4-5 ：必須對重要的詳細設計文檔進行正規(guī)檢視。說明：參考建議4-2 。4-2 ：根據(jù)模塊的復雜度、規(guī)模和在軟件系統(tǒng)中的重要程度，選擇重要的詳細設計文檔進行正規(guī)檢視。在產(chǎn)品

33、中，進行正規(guī)檢視的詳細設計文檔比例要達到60%。4-6 ：詳細設計過程結(jié)束前，必須通過評審，并保存評審記錄。4-7 ：設計更改必須經(jīng)過相關(guān)評審，并保存評審記錄。4-8 ：對詳細設計文檔的正規(guī)檢視或評審，必須檢查詳細設計文檔的清晰性、完備性、 規(guī)范性、一致性、正確性、數(shù)據(jù)、功能性、接口、詳細程度、可維護性、性能、可靠性、可測試性、可追溯性。說明：參考建議4-3 。4-3 ：采用以下檢查表檢查詳細設計文檔的清晰性。序號問題1 是否所有的單元和進程的設計目的都已文檔化？2 單元設計，包括數(shù)據(jù)流、控制流、接口描述是否清楚？3 單元的整體功能是否描述清楚？4-4 ：采用以下檢查表檢查詳細設計文檔的完備性

34、。序號問題1 是否提供了所有程序單元的規(guī)格？2 是否描述了所采用的設計標準？19/323 是否確定了單元應用的算法？（例如：PDL）4 是否列出了單元的所有調(diào)用？5 是否記錄了設計繼承的歷史和已知的風險？4-5 ：采用以下檢查表檢查詳細設計文檔的規(guī)范性。序號問題1 文檔是否遵從了公司的標準？2 單元設計是否使用了要求的方法和工具？4-6 ：采用以下檢查表檢查詳細設計的一致性。序號問題1 在單元和單元的接口中數(shù)據(jù)成員的名稱是否保持一致？2 所有接口之間，接口和接口規(guī)格書之間是否保持一致？3 詳細設計和概要設計文檔是否能夠完全描述“正在構(gòu)建”的系統(tǒng)4-7 ：采用以下檢查表檢查詳細設計的正確性。序號

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

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

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

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

39、部分的設計都可以追溯到需求？2 是否每一個設計決策都可以追溯到效益分析？21/323 是否所有的設計決策都可以追溯到成本/ 效益分析？4 是不是描述了每個單元的詳細需求？5 單元需求是否能夠追溯到軟件規(guī)格文檔 （ SSD-1）？軟件規(guī)格文檔是否能夠跟蹤到單元需求？6 是否有到代碼的引用或者包括代碼本身？22/325 編碼5-1 ：編碼必須以設計文檔為基礎(chǔ)，必須保證所有的設計都被編碼實現(xiàn)。當設計發(fā)生變更時，必須修改相關(guān)代碼。5-2 ：必須保證設計文檔和代碼的一致性。當代碼的修改已經(jīng)造成設計更改時，必須修訂相應設計文檔。5-3 ：必須對重要的代碼進行正規(guī)檢視。說明：參考建議5-1 。5- 1 ：根

40、據(jù)模塊、函數(shù) / 單元/ 進程的復雜度、規(guī)模和在軟件系統(tǒng)中的重要程度，選擇重要的代碼進行正規(guī)檢視。在產(chǎn)品中，進行正規(guī)檢視的代碼比例要達到40%。5-4：在代碼已經(jīng)基線化后，對代碼的更改必須通過評審，并保存評審記錄。5-5：代碼必須遵守相關(guān)的 XX信息 JAVA編程規(guī)范。5-6：對代碼的正規(guī)檢視和評審，必須依照”XX信息 JAVA編程規(guī)范 ”的規(guī)定檢查編程規(guī)范程度，并對代碼符合情況進行考量。5-7：項目編碼完成后，必須提交Sonarqube 平臺進行靜態(tài)質(zhì)量檢測。23/326 需求管理6-1 ：產(chǎn)品項目必須安排人員負責需求管理的職責。說明：職責參見建議6-1 。6-1 ：需求管理的職責至少應包括

41、以下內(nèi)容：序號內(nèi)容1 在產(chǎn)品項目整個生存周期內(nèi)，管理系統(tǒng)需求和它們的分配，并對其建立文檔。2 實現(xiàn)對系統(tǒng)需求及其分配的更改。6-2 ：必須建立文檔標識分配到軟件中的產(chǎn)品系統(tǒng)需求。說明：文檔的內(nèi)容參見建議6-2 。6-2 ： 標識分配到軟件中的產(chǎn)品系統(tǒng)需求的文檔至少應包含以下內(nèi)容:序號內(nèi)容1 影響和確定軟件項目活動的非技術(shù)性需求（即：協(xié)議、條件、合同條款等）。2 對軟件的技術(shù)需求。3 用于確認軟件產(chǎn)品滿足分配需求的驗收標準。6-3 ：相關(guān)人員必須接受需求管理活動方面的培訓。說明：參見建議6-3 。6- 3 ： 培訓至少包括以下內(nèi)容 :序號內(nèi)容1 項目所使用的方法、標準、規(guī)程2 應用領(lǐng)域的知識6-4 ：必須對對經(jīng)過評審和批準的需求文檔進行管理和控制。說明：參見建議6-4 。6- 4 ：對經(jīng)過評審和批準的需求至少應采用以下方法進行管理和控制：序號內(nèi)容1 在配置管理計劃（SCMP ）中將需求文檔定義為CI。2 對需求文檔進行配置管理。3 相應的參考文檔進行變更 /維護。6-5 ：必須對需求變更采用嚴