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

1、XX信息軟件開發(fā)項目技術(shù)管理規(guī)范文件編號：RK-S20170802生效日期：2017.8.20受控編號：版次：Ve10修改狀態(tài)：編制：審核：批準：貴州XX信息科技有限公司目錄34581軟件需求分析82 軟件項目計劃1.23 概要設(shè)計1.64 詳細設(shè)計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ī)范，以達到過程控制的目的。與軟件開發(fā)相關(guān)的所有人員，包括各級經(jīng)理和工程師都必須遵守本軟件開發(fā)行為規(guī)范

2、。對 違反規(guī)范的開發(fā)行為，必須按照有關(guān)管理規(guī)定進行處罰。本軟件開發(fā)行為規(guī)范的內(nèi)容包括：軟件需求分析、軟件項目計劃、概要設(shè)計、詳細設(shè)計、編碼、需求管理、配置管理、軟件質(zhì)量保證、數(shù)據(jù)度量和分析等。本軟件開發(fā)行為規(guī)范，采用以下的術(shù)語描述： 規(guī)則：在軟件開發(fā)過程中強制必須遵守的行為規(guī)范。 建議：軟件開發(fā)過程中必須加以考慮的行為規(guī)范。 說明：對此規(guī)則或建議進行必要的解釋。 示例：對此規(guī)則或建議從正或反兩個方面給出例子。本軟件開發(fā)過程行為規(guī)范由技術(shù)研發(fā)部負責解釋和維護。管理、軟件項目整體開發(fā)流程風險分析說明書需求變更 說明書立項報告需求分析規(guī)格說明書項目或產(chǎn)品開發(fā)計劃三、各階段崗位職責與工作內(nèi)容序 號工作

3、名稱負責人參與人審批人工作內(nèi)容交付物工作說明1立項管理項目經(jīng)理售前經(jīng)理總經(jīng)理1.項目或產(chǎn)品建設(shè)內(nèi) 容；2.項目風險分析；3.明確后續(xù)工作；4.討 論解決方案。1 .風險分析報告；2 .如需步講解， 交付巧PPT；3 .如確定立項，交付 立項報告及解決方 案4 .立項后，確認開發(fā) 經(jīng)理1.立項報告、解決 方案提交到開發(fā)經(jīng) 理后，開始需求調(diào) 研準備。1.1項目介紹項目經(jīng)理總經(jīng)理或售前 經(jīng)理項目經(jīng)理系統(tǒng)或方案簡介無2需求分析項目經(jīng)理售前經(jīng)理、開 發(fā)經(jīng)理總工程師確認用戶需求及功能 邊界需求規(guī)格說明書1.需求規(guī)格說明書 由售前經(jīng)理編制， 提交開發(fā)經(jīng)理后； 開發(fā)經(jīng)理開始開發(fā) 計劃編制3開發(fā)計劃開發(fā)經(jīng)理項目

4、經(jīng)理、售 前經(jīng)理項目經(jīng)理1 .確定開發(fā)工期；2 .明確開發(fā)人員。3 .開發(fā)計劃交付甲方項目開發(fā)計劃書開發(fā)經(jīng)理完成計劃 編制，人員配置完 成后，經(jīng)項目經(jīng)理 提交客戶審核通 過，開發(fā)經(jīng)理完成 人員分工，開發(fā)業(yè) 務(wù)啟動4軟件設(shè)計開發(fā)經(jīng)理開發(fā)工程師總工程師1 .數(shù)據(jù)庫設(shè)計2 .概要設(shè)計1 .數(shù)據(jù)字典;2 .概要設(shè)計說明書公司米用敏捷開 發(fā)，開發(fā)經(jīng)理需按 通用模塊-基礎(chǔ)數(shù) 據(jù)管理模塊-業(yè)務(wù) 管理模塊-數(shù)據(jù)應(yīng) 用模塊進行設(shè)計， 區(qū)分無需設(shè)計的模 塊可直接進行開發(fā)5軟件編碼開發(fā)經(jīng)理開發(fā)工程師、 測試工程師項目經(jīng)理1 .完成軟件編碼；2 .完成詳細設(shè)計說明書；3 .代碼迭代及版本控制1 .軟件代碼及數(shù)據(jù)庫2

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

6、例）3 .壓力測試報告采用敏捷測試，測 試經(jīng)理根據(jù)開發(fā)進 度，逐個模塊跟進 測試6.1試運行測試經(jīng)理開發(fā)經(jīng)理項目經(jīng)理實際生產(chǎn)環(huán)境進行軟件運行測試1.軟件試運行報告取決于甲方是否提 供試運行時間7軟件部署實施經(jīng)理項目經(jīng)理、開 發(fā)工程師實施經(jīng)理在生產(chǎn)環(huán)境進行正式 系統(tǒng)部署及投運項目實施報告8驗收交付項目經(jīng)理實施工程師、 售前工程師總經(jīng)理完成項目驗收并交付 客戶使用驗收報告驗收通過后，進行 項目總結(jié)。開發(fā)組 明確運維職責后， 人員開始進入其他 項目9項目運維實施經(jīng)理項目經(jīng)理1 .及時發(fā)現(xiàn)對項目運行 期間的問題和客戶新 需求；2 .需求甄別，需及時更 改的提交開發(fā)經(jīng)理；3 .保持客戶溝通運維報告、需求

7、更 改說明書管理管理四、各階段工作要求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ī)格文檔中需求的清晰性、完備性、兼容性、一致性、正確性、可行性、易修改性、健壯性、易追溯性、易理解性、易測試性和可驗證性、性能、功能、接口、數(shù)據(jù)、可維護性等內(nèi)容。說

8、明：參考建議1-1至M-16 。1-1 :采用以下檢查表檢查軟件需求規(guī)格文檔中需求的清晰性序號12問題所有定義、實現(xiàn)方法是否清楚地表達了用戶的原始要求?而能實現(xiàn)過程、方法和技術(shù)要求的描述上，是否沒有背離了功能的實 際要求？3是否沒有不能理解或造成誤解的描述？1-2 ：采用以下檢查表檢查軟件需求規(guī)格文檔中需求的完備性。序號1問題需求定義中是否包含了有關(guān)文件（指質(zhì)量手冊、質(zhì)量計劃以及其它有關(guān) 文件）種所規(guī)定的需求定義所應(yīng)該包含的所有內(nèi)容？需求定義是否包含了有關(guān)功能、性能、限制、目標、質(zhì)量等方面的所有 需求？功能性需求是否覆蓋了所有非正常情況的處理？是否對各種操作模式（如正常、非正常、有干擾等）下的

9、環(huán)境條件都作 了規(guī)定？是否對所有功能與時間因素有關(guān)的方面都作了考慮？是否標識出了所有與時間因素有關(guān)的功能？它們的時間準則是否都說明 了？時間準則的最大、最小執(zhí)行時間是否都定義了？是否標識并定義了在將來可能會變化的需求？8是否定義了系統(tǒng)所有的輸入？9是否標識清楚系統(tǒng)輸入的來源？10是否標識出了系統(tǒng)的輸出？11是否說明了系統(tǒng)輸入、輸出的類型？12是否說明了系統(tǒng)輸入、輸出的值域、單位、格式等？13是否說明了如何進行系統(tǒng)輸入的合法性檢查？14是否定義了系統(tǒng)輸入、輸出的精度？15是否定義了系統(tǒng)性能的各個方面,16在不同負哦情況下，是否規(guī)定了系統(tǒng)的處理能力？17在不同情況下，是否規(guī)定了系統(tǒng)的響應(yīng)時間？18

10、是否充分定義了關(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)先排序？：采用以下檢查表檢查軟件需求規(guī)格文檔中需求的兼容性。1-31-41-51-6序號12問題界面需求是否使軟硬件系統(tǒng)具有兼容性？是否有適當?shù)臉诵枨蠖x的文檔是否滿足項目文檔編寫標準？在矛盾時, 準可供選擇？:采用

11、以下檢查表檢查軟件需求規(guī)格文檔中需求的一致性。序號問題1各個需求之間是否一致？是否有沖突和矛盾？2所規(guī)定的模型、算法和數(shù)值方法是否相容？3是否使用了標準的術(shù)語和定義形式？4需求是否與其軟硬件操作環(huán)境相容？5是否說明了軟件對其系統(tǒng)和環(huán)境的影響？6是否說明了環(huán)境對軟件的影響？7所米用的技術(shù)是否與用戶要求的技術(shù)一致?:采用以下檢查表檢查軟件需求規(guī)格文檔中需求的正確性。序號問題1需求定義是否滿足標準的要求？2算法和規(guī)則是否有科技文獻或其它文獻作為基礎(chǔ)？3是否定義了對在錯誤、風險分析中所標識出的各種故障模式和錯誤類型 所需的反應(yīng)？4是否參照了有美的標準？5是否對竄-個需求都給出了理由？理由是否充分？對設(shè)

12、計和實現(xiàn)的限制是否都有論證?6:采用以下檢查表檢查軟件需求規(guī)格文檔中需求的可行性。序號12問題需求定義是否使軟件的設(shè)計、實現(xiàn)、操作和維護都可行?所規(guī)定的模型、數(shù)值方法和算法是否對待解決問題合適？是否能夠在相應(yīng)的限制條件下實現(xiàn)？是否能夠達到關(guān)于質(zhì)量的要求？1-7 :采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易修改性序號問題1對需求定義的描述是否易于修改（如是否米用良好的結(jié)構(gòu)和交叉引用表 等）？2是否有冗余的信息？是否一個需求被定義了多次?1-8 :采用以下檢查表檢查軟件需求規(guī)格文檔中需求的健壯性序號問題序號121-10序號1問題是否每一個需求都只有一種解釋?1是否有容錯的需求?1-9 :采用以下

13、檢查表檢查軟件需求規(guī)格文檔中需求的易追溯性 問題是否可從上一階段的文檔中找到需求定義中的相應(yīng)內(nèi)容?需求定義是否明確地表明前階段中提出的有關(guān)需求和設(shè)計限制都已被覆 蓋了？3需求定義是否便于向后繼開發(fā)階段查找信息:采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易理解性。23456功能性需求是否以模塊方式描述的？是否明確地標識出了其功能？是否有術(shù)語定義一覽表？是否使用了形式化或半形式化的語言?語言是否有歧義性？需求定義中是否只包含了必須的實現(xiàn)細節(jié)而不包含不必要的實現(xiàn)細節(jié)？是否過分細致了 ？需求定義是否足夠清楚和明確使其能夠作為開發(fā)設(shè)計規(guī)約和功能性測試 數(shù)據(jù)的基礎(chǔ)？需求定義的描述是否將對程序的需求和所提供

14、的其它信息分離開來了？1-11:采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易測試性和可驗證性。序號123問題需求是否可以驗證（即是否可以檢驗軟件是否滿足了需求）？是否對每一個需求都指定了驗證過程？數(shù)學函數(shù)的定義是否使用了精確定義的語法和語義符號？1-12：采用以下檢查表檢查軟件需求規(guī)格文檔中的性能需求描述o序號問題1-131-141-151-16是否精確的描述了所有的性能需求和可容忍的性能降低程度？對每一個性能應(yīng)包含兩方卸的內(nèi)谷：1a.在最壞情況的執(zhí)行結(jié)果2b.本性能失效后，對系統(tǒng)產(chǎn)生的影響：采用以下檢查表檢查軟件需求規(guī)格文檔中功能需求描述。WIfil1是否清楚、明確地描述了所有的功能？2所有

15、史描述的功能是否是必須的？是否能滿足任務(wù)書或系統(tǒng)目標的要 求？:采用以下檢查表檢查軟件需求規(guī)格文檔中的接口需求描述。序號 1可題一1是否清楚地定義了所有的接口?3所有接口是否必須？各接口間的關(guān)系是否一致、正確？：采用以下檢查表檢查軟件需求規(guī)格文檔中的數(shù)據(jù)需求描述。序號12問題在某異常數(shù)據(jù)（如條件、標志等）下，是否有真正沒有考慮到的結(jié)果? 對異常數(shù)據(jù)產(chǎn)生的結(jié)果是否作了精確的描述？序號問題1需求定義中是否包括了可行的系統(tǒng)維護方法？2軟件系統(tǒng)間的關(guān)系是否是松耦合的（即能否保證在對某部分修改后，產(chǎn)生最小的連鎖效應(yīng)）？:采用以下檢查表檢查軟件需求規(guī)格文檔中的可維護性需求描述。2軟件項目計劃2-1 :軟件

16、項目計劃必須以產(chǎn)品/軟件的需求規(guī)格為基礎(chǔ)。當發(fā)生需求更改時，必須修訂軟件開發(fā)計劃。 說明：軟件項目計劃必須依據(jù)需求規(guī)格進行制定。項目計劃中的工作產(chǎn)品和工作任務(wù)應(yīng)保證能完 全實現(xiàn)需求規(guī)格的定義。當需求更改時，必須考慮需求更改的相關(guān)性，修訂相應(yīng)軟件開發(fā)計劃。2-1:制定軟件項目計劃的活動制定，必須遵守“軟件項目計劃規(guī)范”。2-2：軟件經(jīng)理對軟件項目計劃的制定和結(jié)果負責。2-3:軟件經(jīng)理和相關(guān)參與軟件項目計劃的制定和評審的人員，在參與計劃制定之前必須經(jīng)過軟件工程 和軟件項目計劃制定流程的培訓。2-2 :對于軟件項目計劃中各項工作產(chǎn)品和工作任務(wù), 目計劃文檔中記錄估計的方法和估計數(shù)據(jù)。說明：參考建議2

17、-4到2-8 。必須進行規(guī)模和工作量的軟件估計，并在軟件項2-4 :可以使用PERT統(tǒng)計估計、專家判定平均法、經(jīng)驗類比估計、公式計算等方法，或以上方法的組 合，進行軟件估計。示例：PERT統(tǒng)計估計和經(jīng)驗類比估計的結(jié)合PERT統(tǒng)計估計值 =（最大估計+ 4 X期望估計+最小估計/ 6 估計記錄如下：工作產(chǎn) 品任務(wù)"tn期望彳計（根據(jù)經(jīng)驗 類比獲得）最小估計PERTtH規(guī)模工作量規(guī)模工作量規(guī)模工作量規(guī)模工作量XX版本 （增加XX特 性話統(tǒng) 模塊概 要設(shè)計文檔頁 數(shù):45;增 加、修改 模塊設(shè) 計數(shù)目：1212天文檔頁 數(shù):42;增 加、修改 模塊設(shè) 計數(shù)目：1010天文檔頁 數(shù):30;增

18、 加、修改 模塊設(shè) 計數(shù)目：55天文檔頁 數(shù):41;增 加、修改 模塊設(shè) 計數(shù)目：109.5天期望估計值是根據(jù)XX版本的話統(tǒng)模塊設(shè)計的數(shù)據(jù)獲得。2-5:對某項工作產(chǎn)品和任務(wù)的軟件，同時采用兩種或以上的方法進行估計，以避免一種方法的偏差2-6：盡量采用歷史經(jīng)驗數(shù)據(jù)進行軟件估計。2-7：參照“軟件估計指導(dǎo)書”進行軟件估計。2-8 :軟件估計對應(yīng)項目的任務(wù)分解結(jié)構(gòu)進行。說明：軟件估計對于項目的任務(wù)分解結(jié)構(gòu)對應(yīng)得越清晰、越細致，相應(yīng)的估計越準確。2-9：在“軟件項目計劃”中必須包括項目管理活動的計劃。2-10:在“軟件項目計劃”中包括軟件重用計劃。包括重用軟件部件的計劃和開發(fā)可重用軟件部件的 計劃。2

19、-11 ：在“軟件項目計劃”包括人員的培訓計劃。說明：項目人員計劃包括需要的人員類型、數(shù)量和技術(shù)等級的要求，相關(guān)人員的開始工作時間、工作周期、接受培訓的計劃等。2-12：對軟件項目進行風險分析與評估。說明：可能存在的風險領(lǐng)域含：需求的不明確和變更、外部的限制與對外的依賴、人力資源的到位情況、人力資源的技術(shù)等級滿足要求狀況、技術(shù)問題等。對風險的分析與評估實踐包括：從已知的情況推導(dǎo)出潛在風險；對風險進行分析，得出：潛在風險可能引發(fā)的問題的影響、潛在風險發(fā)生的可能性大小、風險發(fā)生的時間段等；排列風險的重點次序；對風險記錄成文件（屬于軟件項目計劃中的一部分）；風險經(jīng)受風險影響人審核，并取得他的同意；根

20、據(jù)需要，在開發(fā)過程中對風險文檔進行維護和修訂。2-3 :對應(yīng)工作任務(wù)，制定項目的文檔計劃。2-4 :軟件項目計劃中應(yīng)該包括正規(guī)檢視活動計劃、軟件質(zhì)量保證計劃、軟件配置管理計劃。軟件質(zhì)量保證計劃和軟件配置管理計劃可以和軟件項目計劃在同一份文檔中，也可以分開為三份文檔。說明：參考建議2-13 。2-13:軟件質(zhì)量保證計劃和軟件配置管理計劃作為獨立的計劃文檔。2-14：軟件項目計劃必須是整個項目開發(fā)過程的計劃，包括測試。2-15：測試經(jīng)理對照整個開發(fā)計劃建立軟件驗證與確認計劃。軟件驗證與確認計劃可作為獨立的計劃 文檔。2-5 :必須對項目工作進行分解，確定項目的工作任務(wù)，任務(wù)的責任人、資源要求、時間

21、要求、項目的 進度。2-6 :必須分析任務(wù)之間的依賴性，確定并明確標識項目的關(guān)鍵路徑。2-7 : “軟件項目計劃”必須按照文檔模板的要求編寫。項目組可根據(jù)項目的實際情況，對文檔模板中 的內(nèi)容進行裁減。項目組對文檔模板內(nèi)容的裁減必須得到上級管理部門（包括產(chǎn)品計劃處、軟件工程 組SEPG）的審核批準。2-8 :軟件項目計劃必須經(jīng)過評審。說明：參考建議2-16 ,。2-16：軟件項目計劃的評審采用以下檢查表序號問題1軟件項目計劃是否完全反映（對應(yīng)）“軟件需求說明書”里的需求？2軟件項目計劃是否有卅發(fā)方法的說明？3軟件項目計劃是否有資源需求的說明？4軟件項目計劃是否包含風險管理計劃？5軟件項目計劃是否

22、包含了版本發(fā)布的機制？6軟件項目計劃是否標識了所有必須的培訓計劃？7軟件項目計劃是否標識了所有內(nèi)部和外部的傳遞關(guān)系？8軟件項目計劃是否標明了項目的依賴關(guān)系？9軟件項目計劃是否標明了角色和職責？10軟件項目計劃是否標明了匯報的機制？11軟件項目計劃是否說明了跟蹤和監(jiān)控機制？12軟件項目計劃是否包含“軟件質(zhì)量保證計劃”和“軟件配置管理計劃”？13軟件項目計劃是否包含項目開發(fā)使用的工具？14軟件項目計劃是否包含項目的各里程碑的說明？15進度中是否標明了軟件項目計劃的關(guān)鍵路徑？2-17:參加“軟件項目計劃”評審的人員，除軟件經(jīng)理和項目組人員外，必須有產(chǎn)品經(jīng)理、上級管理 部門（包括軟件工程組SEPG）、

23、SQA人員。2-18: “軟件項目計劃”通過評審后，軟件經(jīng)理組織相關(guān)人員對任務(wù)進行承諾，簽定工作任務(wù)書2-9 :必須對“軟件項目計劃”進行配置管理，“軟件項目計劃”的更改必須經(jīng)過評審。2-10 :在開發(fā)活動中，必須按照項目跟蹤與監(jiān)控計劃和體制，對照“軟件項目計劃”，跟蹤項目開發(fā)的實際結(jié)果和性能。2-11 :當實際結(jié)果和“軟件項目計劃”發(fā)生偏離時，必須進行分析，根據(jù)分析結(jié)果標明糾正措施。必 要的情況下，要及時修訂“軟件項目計劃”。2-12 :在軟件項目跟蹤監(jiān)控活動中，必須定期進行總結(jié)和評審，撰寫開發(fā)狀態(tài)報告。2-19:根據(jù)項目的特點，報告的周期可以為周、雙周、月。2-13 :在軟件開發(fā)各里程碑階

24、段結(jié)束前，必須進行階段評審，對軟件項目進行重估計，必要的情況下 修訂“軟件項目計劃”。2-20:必須提供相應(yīng)資源，包括工具和人員等，進行軟件項目計劃和項目跟蹤監(jiān)控活動。2-14 :在軟件項目計劃和項目跟蹤監(jiān)控過程活動中，必須進行數(shù)據(jù)度量和分析。說明：參見“ 9.數(shù)據(jù)度量和分析”。3概要設(shè)計3-1 :概要設(shè)計要以軟件需求規(guī)格為基礎(chǔ)，必須保證需要實現(xiàn)的需求規(guī)格已經(jīng)被設(shè)計。3-2 :當需求規(guī)格發(fā)生變更時，必須修訂相關(guān)概要設(shè)計文檔。3-3 :在概要設(shè)計文檔或需求管理文檔中，必須記錄、驗證需求和概要設(shè)計的跟蹤關(guān)系。說明：需求和概要設(shè)計的跟蹤關(guān)系可參考建議3-1。3-1 :采用需求、子系統(tǒng)、模塊的跟蹤矩陣

25、表記錄需求和概要設(shè)計的跟蹤關(guān)系。3-4 :必須保證概要設(shè)計文檔和代碼的一致性。當發(fā)生設(shè)計更改時，必須修訂相應(yīng)設(shè)計文檔。3-5 :必須對概要設(shè)計文檔進行正規(guī)檢視。3-6 :概要設(shè)計過程結(jié)束前，必須通過評審，并保存評審記錄。3-7 :設(shè)計更改必須經(jīng)過相關(guān)評審，并保存評審記錄。3-8 :對概要設(shè)計文檔的正規(guī)檢視或評審，必須檢查概要設(shè)計文檔的清晰性、完備性、規(guī)范性、一致性、正確性、數(shù)據(jù)、功能性、接口、詳細程度、可維護性、性能、可靠性、可測試性、可追溯性。說明：參考建議3-2 。3-33-2 ：采用以下檢查表檢查概要設(shè)計文檔的清晰性序號問題1程序結(jié)構(gòu)，包括數(shù)據(jù)流、控制流和接口的描述是否清楚？:采用以下檢

26、查表檢查概要設(shè)計文檔的完備性。序號問題1設(shè)計目標是否定義？2需求規(guī)格評審中不完整的需求（TBD）是否都已經(jīng)解決？3如果以前定義的不完整的需求 （TBD）發(fā)生了改變，本設(shè)計是否能夠支持？4是否對不完整需求（TBD）的影響進行了評估？5對有可能不能實現(xiàn)的設(shè)計是否有風險管理計劃？6是否對設(shè)計模式進行了描述？3-4 :采用以下檢查表檢查概要設(shè)計文檔的規(guī)范性 &3-5 :1采用以下檢查表檢查概要設(shè)計文檔的一致性0文檔是否符合公司模板和寫作要求3-6 :3-7 :3-9 :3-10序號問題2程序、模塊、函數(shù)、數(shù)據(jù)成員的名稱是否保持一致？3設(shè)計是否反映了真正的操作環(huán)境？硬件環(huán)境？軟件環(huán)境？4對系統(tǒng)設(shè)

27、計的多種可能的描述之間是否保持一致?（例如：靜態(tài)結(jié)構(gòu)的描述和動態(tài)描述）采用以下檢查表檢查概要設(shè)計文檔的正確性。序號問題1設(shè)計在計劃、預(yù)算、技術(shù)上是否可行？2邏輯是否止確和完備？采用以下檢查表檢查概要設(shè)計文檔的數(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ù)的使用是否描述清楚 ？令查表檢查概要設(shè)計文檔的功能性要求。序號問題1模塊的規(guī)格是否和軟件需求文檔中的功能需求和軟件接口規(guī)格要求保 持致.2是否給每個子模塊確定了抽

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

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

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

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

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

33、格5 是否描述了所采用的設(shè)計標準？是否確定了單元應(yīng)用的算法？（例如：是否列出了單元的所有調(diào)用?PDD是否記錄了設(shè)計繼承的歷史和已知的風險?4-5 :采用以下檢查表檢查詳細設(shè)計文檔的規(guī)范性。序號1問題文檔是否遵從了公司的標準?單元設(shè)計是否使用了要求的方法和工具?4-6 :序號問題1在單兀和單兀的接口中數(shù)據(jù)成員的名稱是否保持一致？2所有接口之間，接口和接口規(guī)格書之間是否保持一致？3詳細設(shè)計和概要設(shè)計文檔是否能夠完全描述“正在構(gòu)建”的系統(tǒng)采用以下檢查表檢查詳細設(shè)計的一致性。4-7 :序號問題1是否有邏輯錯誤？2需要使用常量名稱的地方是否有錯誤,3是否所有的條件都被處理？（>尸,< ,sw

34、itch case）?4分支所處的狀態(tài)是否止確？（邏輯沒有搞反）采用以下檢查表檢查詳細設(shè)計的正確性。4-8 :序號問題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)定義并初始化？采用以下檢查表檢查詳細設(shè)計的數(shù)據(jù)描述4-9 :序號問題1設(shè)計是否使用了指定的算法？2設(shè)計是否能夠滿足需求和目的？米用以下檢查表檢查詳細設(shè)計的接口描述。序號問題1參數(shù)表是否在數(shù)量、類型和順序上保持一致？2

35、是否所有的輸入輸出都已經(jīng)正確定義并檢查過？3所傳遞參數(shù)的順序是否描述清楚？4參數(shù)傳遞的機制是否確定？5通過接口傳遞的常量和變量是否與單兀設(shè)計的相同？ 的常量不能在所調(diào)用的子過程中被修改）（例如，函數(shù)中定義4-10采用以下檢查表檢查詳細設(shè)計的功能性要求6傳入、傳出函數(shù)的參數(shù)，控制標記是否都已經(jīng)描述清楚。7是否以度量單位描述了參數(shù)的值區(qū)間，準確性和精度。4-11:采用以下檢查表檢查詳細設(shè)計的詳細程度。序號12問題代碼和文檔間的展開率是否小于 10： 1?對模塊的所有需求都已經(jīng)定義?詳細程度是否足夠開發(fā)和維護代碼？4-12序號問題1單兀是否是高內(nèi)聚和低外部耦合？（例如：單兀的改變不會在內(nèi)部出現(xiàn) 不口

36、預(yù)見的影響，同時對其他單兀的影響最小？2是否這種設(shè)計是復(fù)雜度最小的設(shè)計？3開始部分的描述是否符合公司的要求？（例如：目的，作者，環(huán)境，非 標準特性，開發(fā)歷史，輸入輸出參數(shù)，使用的文件，數(shù)據(jù)結(jié)構(gòu)，引用此 單元的其他單元，注釋。:采用以下檢查表檢查詳細設(shè)計的可維護性。:采用以下檢查表檢查詳細設(shè)計的性能4-13序號問題1進程是否有時間窗？2是否所有的時間和空間的限制都已明確?4-14:采用以下檢查表檢查詳細設(shè)計的可靠性W Ifil1初始化時是否使用了默認值，是否正確？2訪問內(nèi)存時是否進行了邊界檢查，以保證地址正確？（隊列，數(shù)據(jù)結(jié)構(gòu)， 指針，等等）3對輸入、輸出、接口和結(jié)果是否進行了錯誤檢查？4對所有

37、錯誤情況都安排了有意義的消息反饋？5特殊情況下的返回碼是否和文檔中定義的全局返回碼一致?6是否考慮了異常情況？：采用以下檢查表檢查詳細設(shè)計的可測試性4-15序號問題1是否每個單兀都可以被測試、演示、分析或者檢視，以確認滿足需求。2設(shè)計中是否包括輔助測試的檢查點？（例如：條件編譯代碼、斷言等）3是否所有的邏輯都是可測的？4是否描述了本單元的測試驅(qū)動模塊，測試用例集，測試結(jié)果？：采用以下檢查表檢查詳細設(shè)計的可追溯性。4-16序號12問題是否每一部分的設(shè)計都可以追溯到需求？ 是否每一個設(shè)計決策都可以追溯到效益分析?3是否所有的設(shè)計決策都可以追溯到成本/效益分析？4是不是描述了每個單兀的詳細需求,5單

38、兀需求是否能夠追溯到軟件規(guī)格文檔 能夠跟蹤到單元需求？(SSD-1) ?軟件規(guī)格文檔是否6是否有到代碼的引用或者包括代碼本身？5編碼5-1 :編碼必須以設(shè)計文檔為基礎(chǔ)，必須保證所有的設(shè)計都被編碼實現(xiàn)。當設(shè)計發(fā)生變更時，必須修改相關(guān)代碼。5-2 :必須保證設(shè)計文檔和代碼的一致性。當代碼的修改已經(jīng)造成設(shè)計更改時，必須修訂相應(yīng)設(shè)計文檔。5-3 :必須對重要的代碼進行正規(guī)檢視。說明：參考建議5-1 。5-1：根據(jù)模塊、函數(shù)/單元/進程的復(fù)雜度、規(guī)模和在軟件系統(tǒng)中的重要程度，選擇重要的代碼進行正 規(guī)檢視。在產(chǎn)品中，進行正規(guī)檢視的代碼比例要達到 40%。5-4 :在代碼已經(jīng)基線化后，對代碼的更改必須通過評

39、審，并保存評審記錄。5-5 :代碼必須遵守相關(guān)的 XX言息JAVAII程規(guī)范。5-6 :對代碼的正規(guī)檢視和評審，必須依照“XX言息JAV斕程規(guī)范”的規(guī)定檢查編程規(guī)范程度，并對代碼符合情況進行考量。5-7 :項目編碼完成后，必須提交Sonarqube平臺進行靜態(tài)質(zhì)量檢測。6需求管理6-1 :產(chǎn)品項目必須安排人員負責需求管理的職責。說明：職責參見建議6-1 。6-1 :需求管理的職責至少應(yīng)包括以下內(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

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

41、相應(yīng)的參考文檔進行變更/維護。6-5 :必須對需求變更采用嚴格的變更控制流程控制。說明：參見建議6-5 。6-5：變更控制流程至少應(yīng)包含以下內(nèi)容:序號內(nèi)容1對變化的影響進行評估2經(jīng)過CCB組織的評審3通知受影響的組和個人4跟蹤解決該問題，直到關(guān)閉6-6 :必須在開發(fā)過程中對需求進行跟蹤。說明：參見建議6-6 。6-6:需求跟蹤活動至少應(yīng)包括以下內(nèi)容: W#|內(nèi)容1按照公司模板制定需求跟蹤說明書2跟蹤需求狀態(tài)的變化3需求的跟蹤和分配經(jīng)過評審6-7 :在需求管理活動中必須建立相關(guān)度量記錄。說明：參見建議6-7 6-7:對需求活動的度量至少應(yīng)包含以下內(nèi)容:WW1需求的數(shù)量2需求的狀態(tài)3需求的類型4需

42、求的更改次數(shù)6-8 :需求管理活動和其文檔必須接受上級管理部門、產(chǎn)品項目經(jīng)理、SQA的評審。7軟件配置管理7-1 :產(chǎn)品項目要任命配置管理的人員和組織，在整個配置管理活動中明確他們的職責。 說明：參考建議7-1 。7-1 :參照軟件配置管理規(guī)范和軟件配置管理指導(dǎo)書，任命 SCMfi織。7-2 :產(chǎn)品項目必須制定軟件配置管理計劃（ SCMP）,指導(dǎo)整個配置管理活動。 說明：參考建議7-2 。7-2：項目經(jīng)理根據(jù)配置管理計劃（模板），負責制定配置管理計劃。7-3 :軟件配置管理計劃必須包括如下的內(nèi)容:序號內(nèi)容1對各階段應(yīng)受控的配置項進行選擇、分類、標識。2定義配置項（CI）的命名慣例3定義版本號命

43、名方案4制定培訓計劃5定義相關(guān)SCM流程6制定相應(yīng)配置評審計劃和方法7-4 :軟件配置管理計劃必須經(jīng)過由開發(fā)人員、產(chǎn)品項目經(jīng)理、SQA參加的評審，并獲得批準，并基線化。7-5 :軟件配置管理計劃和軟件項目開發(fā)計劃必須同步變更。7-6 :問題跟蹤要有一套流程支持，該流程要包括問題的描述，分類，評估，設(shè)計，實現(xiàn)，驗證，歸檔 的整個生命過程。7-7 :變更申請要有一套流程支持，該流程要保證該變更申請 （針對已基線化的配置項） 有一個初始化,分類，設(shè)計，評估，分派，實現(xiàn)，驗證，歸檔的整個過程。7-8 :每個版本有一個符合規(guī)范的版本描述文檔。7-9 :必須定義流程指導(dǎo)配置狀態(tài)發(fā)布。說明：參考建議7-3

44、。7-3:在配置管理計劃中描述配置狀態(tài)發(fā)布的周期，內(nèi)容和模板。7-10 :配置項（CI）的變更和配置管理活動的運行狀態(tài)通知到相關(guān)的部門組織和個人。7-11 :定期對變更申請（CR）的處理情況進行統(tǒng)計并將統(tǒng)計和分析結(jié)果進行發(fā)布，發(fā)布內(nèi)容至少包括：單位時間內(nèi)處理的 CRs數(shù)量，CRs分布統(tǒng)計表，CRs流通量統(tǒng)計表，CRs狀態(tài)分布統(tǒng)計表等。說明：參考建議7-4 。7-4:建議正常情況2周發(fā)布一次，更改頻繁時是1周，更改較少時是3周7-12 :建立可以體現(xiàn)開發(fā)版本和基線版本兩種不同受控程度的配置庫系統(tǒng) 說明：參考建議7-5 。7-5 :建議使用SCM工具的分支功能實現(xiàn)不同類型的版本控制7-13 :制定

45、一個基線化流程指導(dǎo)建立基線。說明：參考建議7-6 。7-6：建議在配置管理計劃中對流程進行描述，該流程要保證基線化過程中的物理配置審計（ PCA 功能配置審計（FCA，SQA評審和審計等過程。7-14 :內(nèi)外的發(fā)布必須只能來自基線庫。7-15 :產(chǎn)品項目經(jīng)理、SQA要定期對SCM勺活動和其文本至S行評審 /檢查，輸出評審/檢查結(jié)果，制定 并實施改進措施7-16 :相關(guān)SCMW審要制定相應(yīng)的 Checklist進行指導(dǎo)，評審要有記錄。8軟件質(zhì)量保證8-1 :產(chǎn)品項目組要有相關(guān)的 SQA人員和組織，并開展 SQA活動。8-2: 產(chǎn)品項目SQA的組織活動必須通過如下檢查。序號問題T產(chǎn)品項目是否建立一

46、個獨立的、能夠支持那些要求獨立性活動的SQA!織？對所有項目，SQ勵能是否到位？2SQAi是否有一個向產(chǎn)品組之上的管理者、管理部門報告的疝73是否為組織進行SQ粘動提供足夠的資源和費用？4SQAI的成員是否接受了培訓以完成他們的SQ船動？5項目的軟件相關(guān)成員是否接受J侶大SQAi任務(wù)、職責、權(quán)利等的相關(guān)培訓？6上級管理部門是否對產(chǎn)品項目的 SQ序動及其結(jié)果進行了定期評審？7產(chǎn)品項目經(jīng)理是否定期和事件驅(qū)動地參與評審SQ席動？8SQAI活動及其工作產(chǎn)品是否接受了 SQA!之外的專家進行的定期評審？9項目組是否制定一個執(zhí)行 SQA活動的計劃SQAP。如制定了 SQA計戈ij,計戈IJ 的制訂是否按照

47、已文檔化的組織的SQA規(guī)程和SQA計劃模版執(zhí)行？8-3: 產(chǎn)品項目必須有SQA計劃，SQA計劃必須通過如下檢查。序號問題1制定SQA十劃的活動是否按照公司的相關(guān)規(guī)范進行？ 成了偏差文檔，并得到研究技術(shù)管理處的批準？2 SQA十劃是否符合公司規(guī)范中 SQA十劃模板的要求? 成了偏差文檔，并得到研究技術(shù)管理處的批準？如果存在偏差，是否形如果存在偏差，是否形3SQ砧動是否按照SQA十劃進行?4 SQA十劃是否經(jīng)過計劃中涉及的相關(guān)組和個人的評審, 項目經(jīng)理的批準？并得到SQAS理、產(chǎn)品5 SQA十劃和軟件項目計劃是否在項目的里程碑處進行了修改，修改是否得到 批準？ SQA十劃和軟件項目開發(fā)計劃是否同步

48、變更？8-4 : SQA必須對產(chǎn)品軟件開發(fā)過程進行過程審計。說明：參考建議8-1 。8-1 :要對以下的過程進行審計：需求分析過程、軟件概要設(shè)計過程、軟件詳細設(shè)計過程、軟件測試過 程、版本發(fā)布過程、配置管理過程、變更控制過程、需求管理過程。8-5 : SQA的過程審計必須通過如下的檢查。序號12345問題產(chǎn)品項目是否明確定義了各種軟件活動過程？定義的活動過程是否經(jīng)過和相關(guān)管理部門的批準？軟件過程審計是否按照公司制訂的軟件過程審計規(guī)程執(zhí)行？SQ勰否對每一個軟件活動過程提交了過程審計報告？是否提交了過程不符合項報告？SQA勺過程審計結(jié)果是否通過適當?shù)那缊蟾娼o適當?shù)墓芾碚?？SQA8-6 : SQA

49、必須參與項目的技術(shù)評審活動。說明：參考建議8-2 , 8-3 。8-2: SQA必須參與項目的技術(shù)評審活動包括：需求評審、系統(tǒng)設(shè)計評審、概要設(shè)計評審、詳細設(shè)計評 審等。8-3: SQA®技術(shù)評審過程應(yīng)檢查:12345序號問題 技術(shù)評審的方法對被評審的軟件工作產(chǎn)品是合適的？技術(shù)評審的過程是按照公司制訂的技術(shù)評審過程規(guī)程執(zhí)行的嗎?技術(shù)評審的結(jié)果是否相應(yīng)的評審規(guī)程的要求形成了報告?技術(shù)評審的報告，報告給SQA人員了嗎?SQ從員對技術(shù)評審的結(jié)果進行分析了嗎？8-7 : SQA人員必須定期生成SQA活動的報告。說明：參考建議8-4 。8-4：對SQA報告的檢查包括:序號內(nèi)容1是否報告各種軟件工作產(chǎn)品的評審記錄?2報告的評審記錄是否符合公司規(guī)范的要求？3是否有軟件過程審計的審計報告？4是否把報告送交給上級管理部門、技術(shù)管理處、產(chǎn)品項目經(jīng)理嗎?5是否有軟件過程分析和質(zhì)量報告？8-8 :產(chǎn)品項目的SQA人員必須制定一個實施 SQA工作的月度計劃、