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

1、XX信息軟件開發(fā)工程技術治理標準文件編號：RK-S20210802生效日期：2021.8.20受控編號：版次：Ver1.0修改狀態(tài)： 貴州XX信息科技目錄一、編寫說明3二、軟件工程整體開發(fā)流程5三、各階段崗位責任與工作內容6四、各階段工作要求101.軟件需求分析102軟件工程方案143概要設計184詳細設計215編碼256需求治理267軟件配置治理288軟件質量保證299數(shù)據度量和分析32、編寫說明為了把公司已經發(fā)布的軟件開發(fā)過程標準有效地運作于產品開發(fā)活動中,把各種標準“逐步形成工程師的作業(yè)標準,特制定本軟件開發(fā)行為標準,以到達過程限制的目的.與軟件開發(fā)相關的所有人員,包括各級經理和工程師都

2、必須遵守本軟件開發(fā)行為標準.對違反標準的開發(fā)行為,必須根據有關治理規(guī)定進行處分.本軟件開發(fā)行為標準的內容包括：軟件需求分析、軟件工程方案、概要設計、詳細設計、編碼、需求治理、配置治理、軟件質量保證、數(shù)據度量和分析等.本軟件開發(fā)行為標準,采用以下的術語描述： 規(guī)那么：在軟件開發(fā)過程中強制必須遵守的行為標準. 建議：軟件開發(fā)過程中必須加以考慮的行為標準. 說明：對此規(guī)那么或建議進行必要的解釋. 例如：對此規(guī)那么或建議從正或反兩個方面給出例子.本軟件開發(fā)過程行為標準由技術研發(fā)部負責解釋和維護.、軟件工程整體開發(fā)流程需求變更說明書三、各階段崗位責任與工作內容序號工作名稱負責人參與人審批人工作內容交付物

3、工作說明1立項治理工程經理售前經理總經理1.工程或產品建設內容；2.工程風險分析；3.明確后續(xù)工作；4.討論解決方案.1 .風險分析報告；2 .如需步講解,交付展示PPT;3 .如確定立項,交付立項報告及解決力殺4 .立項后,確認開發(fā)經理1.立項報告、解決方案提交到開發(fā)經理后,開始需求調研準備.1.1工程介紹工程經理總經理或售前經理工程經理系統(tǒng)或方案簡介無2需求分析工程經理售前經理、開發(fā)經理總工程師確認用戶需求及功能邊界需求規(guī)格說明書1.需求規(guī)格說明書由售前經理編制,提交開發(fā)經理后；開發(fā)經理開始開發(fā)方案編制3開發(fā)方案開發(fā)經理工程經理、售前經理工程經理1 .確定開發(fā)工期；2 .明確開發(fā)人員.3

4、.開發(fā)方案交付甲方工程開發(fā)方案書開發(fā)經理完成方案編制,人員配置完成后,經工程經理提交客戶審核通過,開發(fā)經理完成人員分工,開發(fā)業(yè)務啟動4軟件設計開發(fā)經理開發(fā)工程師總工程師1 .數(shù)據庫設計2 .概要設計1 .數(shù)據字典;2 .概要設計說明書公司米用敏捷開發(fā),開發(fā)經理需按通用模塊-根底數(shù)據治理模塊-業(yè)務治理模塊-數(shù)據應用模塊進行設計,區(qū)分無需設計的模塊可直接進行開發(fā)5軟件編碼開發(fā)經理開發(fā)工程師、測試工程師工程經理1 .完成軟件編碼；2 .完成詳細設計說明書；3 .代碼迭代及版本限制1 .軟件代碼及數(shù)據庫2 .詳細設計說明書詳細設計說明書由該功能的開發(fā)工程師編寫5.1內部審核開發(fā)經理開發(fā)工程師總工程師1

5、.審核數(shù)據庫及代碼是否按公司技術標準執(zhí)行米用定期抽樣審核方式工作5.2版本限制開發(fā)經理總工程師1 .按公司要求進行代碼迭代與版本限制；2 .完成代碼備份各研發(fā)組,可自行確認代碼進行本地迭代方式,并定期將代碼提交貴陽總部迭代、備份5.3靜態(tài)質量審查開發(fā)經理總工程師代碼提交到SonarQube進行靜態(tài)代碼審核代碼靜態(tài)質量審核報告及整改說明進入動態(tài)測試環(huán)節(jié)前,必須提交靜態(tài)質量報告6軟件測試測試經理測試工程師、開發(fā)工程師總工程師完成軟件測試1 .測試方案2 .功能測試報告含測試用例3 .壓力測試報告采用敏捷測試,測試經理根據開發(fā)進度,逐個模塊跟進測試6.1試運行測試經理開發(fā)經理工程經理實際生產環(huán)境進行

6、軟件運行測試1.軟件試運行報告取決于甲方是否提供試運行時間7軟件部署實施經理工程經理、開發(fā)工程師實施經理在生產環(huán)境進行正式系統(tǒng)部署及投運工程實施報告8驗收交付工程經理實施工程師、售前工程師總經理完成工程驗收并交付客戶使用驗收報告驗收通過后,進行工程總結.開發(fā)組明確運維責任后,人員開始進入其他工程工程運維實施經理工程經理1 .及時發(fā)現(xiàn)對工程運行期間的問題和客戶新需求；2 .需求甄別,需及時更改的提交開發(fā)經理；3 .保持客戶溝通運維報告、需求更改說明書9四、各階段工作要求1.軟件需求分析1-1:軟件需求分析必須在產品需求規(guī)格的根底上進行,并保證完全實現(xiàn)產品需求規(guī)格的定義.1-2:當產品的需求規(guī)格發(fā)

7、生變更時,必須修訂軟件需求規(guī)格文檔.軟件需求規(guī)格的變更必須經過評審,并保存評審記錄.1-3:必須對軟件需求規(guī)格文檔進行正規(guī)檢視.1-4:軟件需求分析過程活動結束前,必須經過評審,并保存評審記錄.1-5:在對軟件需求規(guī)格文檔的正規(guī)檢視或評審時,必須檢查軟件需求規(guī)格文檔中需求的清楚性、完備性、兼容性、一致性、正確性、可行性、易修改性、健壯性、易追溯性、易理解性、易測試性和可驗證性、性能、功能、接口、數(shù)據、可維護性等內容.說明：參考建議1-1至M-16.1-1:采用以下檢查表檢查軟件需求規(guī)格文檔中需求的清楚性序號12問題所有定義、實現(xiàn)方法是否清楚地表達了用戶的原始要求?而能實現(xiàn)過程、方法和技術要求的

8、描述上,是否沒有背離了功能的實際要求3是否沒有不能理解或造成誤解的描述?1-2:采用以下檢查表檢查軟件需求規(guī)格文檔中需求的完備性.序號1問題需求定義中是否包含了有關文件指質量手冊、質量方案以及其它有關文件種所規(guī)定的需求定義所應該包含的所有內容需求定義是否包含了有關功能、性能、限制、目標、質量等方面的所有需求功能性需求是否覆蓋了所有非正常情況的處理是否對各種操作模式如正常、非正常、有干擾等下的環(huán)境條件都作了規(guī)定是否對所有功能與時間因素有關的方面都作了考慮是否標識出了所有與時間因素有關的功能它們的時間準那么是否都說明了時間準那么的最大、最小執(zhí)行時間是否都定義了是否標識并定義了在將來可能會變化的需求

9、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)的響應時間18是否充分定義了關于人機界面的需求19是否對需求定義進行了可行性分析和相關文件資料是否已歸檔20是否對影響需求實現(xiàn)的因素進行了調查,調查結果是否已歸檔21是否有經濟效益分析,分析結果是否已歸檔22是否詳細描述了有關硬件、軟件、操作人員、操

10、作過程等方面的平安性23是否評估了本工程對用戶、其它系統(tǒng)、環(huán)境的影響特性24是否按完成時間、重要性對系統(tǒng)功能、外部接口、性能進行了優(yōu)先排序：采用以下檢查表檢查軟件需求規(guī)格文檔中需求的兼容性.1-31-41-5序號12問題界面需求是否使軟硬件系統(tǒng)具有兼容性是否有適當?shù)臉诵枨蠖x的文檔是否滿足工程文檔編寫標準在矛盾時,準可供選擇:采用以下檢查表檢查軟件需求規(guī)格文檔中需求的一致性.序號問題1各個需求之間是否一致是否有沖突和矛盾2所規(guī)定的模型、算法和數(shù)值方法是否相容3是否使用了標準的術語和定義形式4需求是否與其軟硬件操作環(huán)境相容5是否說明了軟件對其系統(tǒng)和環(huán)境的影響6是否說明了環(huán)境對軟件的影響7所米用的

11、技術是否與用戶要求的技術一致?:采用以下檢查表檢查軟件需求規(guī)格文檔中需求的正確性.序號問題1需求定義是否滿足標準的要求2算法和規(guī)那么是否有科技文獻或其它文獻作為根底3是否認義了對在錯誤、風險分析中所標識出的各種故障模式和錯誤類型所需的反響4是否參照了有美的標準5是否對竄-個需求都給出了理由理由是否充分6|對設計和實現(xiàn)的限制是否都有論證序號問題1需求定義是否使軟件的設計、實現(xiàn)、操作和維護都可行2所規(guī)定的模型、數(shù)值方法和算法是否對待解決問題適宜是否能夠在相應的限制條件下實現(xiàn)3是否能夠到達關于質量的要求采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易修改性序號問題1對需求定義的描述是否易于修改如是否米用

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

13、的語言?語言是否有歧義性需求定義中是否只包含了必須的實現(xiàn)細節(jié)而不包含不必要的實現(xiàn)細節(jié)是否過分細致了需求定義是否足夠清楚和明確使其能夠作為開發(fā)設計規(guī)約和功能性測試數(shù)據的根底需求定義的描述是否將對程序的需求和所提供的其它信息別離開來了1-11:采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易測試性和可驗證性.序號123問題需求是否可以驗證即是否可以檢驗軟件是否滿足了需求是否對每一個需求都指定了驗證過程數(shù)學函數(shù)的定義是否使用了精確定義的語法和語義符號1-12：采用以下檢查表檢查軟件需求規(guī)格文檔中的性能需求描述o序號問題1-131-141-151-16是否精確的描述了所有的性能需求和可容忍的性能降低程度對

14、每一個性能應包含兩方卸的內谷：1a.在最壞情況的執(zhí)行結果2b.本性能失效后,對系統(tǒng)產生的影響:采用以下檢查表檢查軟件需求規(guī)格文檔中功能需求描述.序號12問題是否清楚、明確地描述了所有的功能?所有已描述的功能是否是必須的是否能滿足任務書或系統(tǒng)目標的要求:采用以下檢查表檢查軟件需求規(guī)格文檔中的接口需求描述.序號13問題是否清楚地定義了所有的接口?所有接口是否必須各接口間的關系是否一致、正確?：采用以下檢查表檢查軟件需求規(guī)格文檔中的數(shù)據需求描述.序號12問題在某異常數(shù)據如條件、標志等下,是否有真正沒有考慮到的結果?對異常數(shù)據產生的結果是否作了精確的描述序號問題1需求定義中是否包括了可行的系統(tǒng)維護方法

15、2軟件系統(tǒng)間的關系是否是松耦合的即能否保證在對某局部修改后,產生最小的連鎖效應:采用以下檢查表檢查軟件需求規(guī)格文檔中的可維護性需求描述.2軟件工程方案2-1:軟件工程方案必須以產品/軟件的需求規(guī)格為根底.當發(fā)生需求更改時,必須修訂軟件開發(fā)方案.說明：軟件工程方案必須依據需求規(guī)格進行制定.工程方案中的工作產品和工作任務應保證能完全實現(xiàn)需求規(guī)格的定義.當需求更改時,必須考慮需求更改的相關性,修訂相應軟件開發(fā)方案.2-1:制定軟件工程方案的活動制定,必須遵守“軟件工程方案標準.2-2:軟件經理對軟件工程方案的制定和結果負責.2-3:軟件經理和相關參與軟件工程方案的制定和評審的人員,在參與方案制定之前

16、必須經過軟件工程和軟件工程方案制定流程的培訓.2-2:對于軟件工程方案中各項工作產品和工作任務,必須進行規(guī)模和工作量的軟件估計,并在軟件項目方案文檔中記錄估計的方法和估計數(shù)據.說明：參考建議2-4到2-8.2-4:可以使用PERT統(tǒng)計估計、專家判定平均法、經驗類比估計、公式計算等方法,或以上方法的組合,進行軟件估計.例如：PERT統(tǒng)計估計和經驗類比估計的結合PERT統(tǒng)計估計值=最大估計+4X期望估計+最小估計/6估計記錄如下：工作產品任務"tn期望彳計根據經驗類比獲得最小估計PERWH規(guī)模工作量規(guī)模工作量規(guī)模工作量規(guī)模工作量XX版本增加XX特性話統(tǒng)模塊概要設計文檔頁數(shù):45;增加、修

17、改模塊設計數(shù)目：1212天文檔頁數(shù):42;增加、修改模塊設計數(shù)目:1010天文檔頁數(shù):30;增加、修改模塊設計數(shù)目：55天文檔頁數(shù):41;增加、修改模塊設計數(shù)目:109.5天期望估計值是根據XX版本的話統(tǒng)模塊設計的數(shù)據獲得.2-5:對某項工作產品和任務的軟件,同時采用兩種或以上的方法進行估計,以防止一種方法的偏差2-6：盡量采用歷史經驗數(shù)據進行軟件估計.2-7：參照“軟件估計指導書進行軟件估計2-8:軟件估計對應工程的任務分解結構進行.說明：軟件估計對于工程的任務分解結構對應得越清楚、越細致,相應的估計越準確.2-9：在“軟件工程方案中必須包括工程治理活動的方案.2-10:在“軟件工程方案中包

18、括軟件重用方案.包括重用軟件部件的方案和開發(fā)可重用軟件部件的方案.2-11：在“軟件工程方案包括人員的培訓方案.說明：工程人員方案包括需要的人員類型、數(shù)量和技術等級的要求,相關人員的開始工作時間、工作周期、接受培訓的方案等.2-12:對軟件工程進行風險分析與評估.說明：可能存在的風險領域含：需求的不明確和變更、外部的限制與對外的依賴、人力資源的到位情況、人力資源的技術等級滿足要求狀況、技術問題等.對風險的分析與評估實踐包括：從的情況推導出潛在風險；對風險進行分析,得出：潛在風險可能引發(fā)的問題的影響、潛在風險發(fā)生的可能性大小、風險發(fā)生的時間段等；排列風險的重點次序；對風險記錄成文件屬于軟件工程方

19、案中的一局部；風險經受風險影響人審核,并取得他的同意；根據需要,在開發(fā)過程中對風險文檔進行維護和修訂.2-3:對應工作任務,制定工程的文檔方案.2-4:軟件工程方案中應該包括正規(guī)檢視活動方案、軟件質量保證方案、軟件配置治理方案.軟件質量保證方案和軟件配置治理方案可以和軟件工程方案在同一份文檔中,也可以分開為三份文檔.說明：參考建議2-13.2-13:軟件質量保證方案和軟件配置治理方案作為獨立的方案文檔.2-14：軟件工程方案必須是整個工程開發(fā)過程的方案,包括測試.2-15：測試經理對照整個開發(fā)方案建立軟件驗證與確認方案.軟件驗證與確認方案可作為獨立的方案文檔.2-5:必須對工程工作進行分解,確

20、定工程的工作任務,任務的責任人、資源要求、時間要求、工程的進度.2-6:必須分析任務之間的依賴性,確定并明確標識工程的關鍵路徑.2-7:“軟件工程方案必須根據文檔模板的要求編寫.工程組可根據工程的實際情況,對文檔模板中的內容進行裁減.工程組對文檔模板內容的裁減必須得到上級治理部門包括產品方案處、軟件工程組SEPG的審核批準.2-8:軟件工程方案必須經過評審.說明：參考建議2-16,.2-16:軟件工程方案的評審采用以下檢查表序號問題1軟件工程方案是否完全反映對應“軟件需求說明書里的需求2軟件工程方案是否有卅發(fā)方法的說明3軟件工程方案是否有資源需求的說明4軟件工程方案是否包含風險治理方案5軟件工

21、程方案是否包含了版本發(fā)布的機制6軟件工程方案是否標識了所有必須的培訓方案7軟件工程方案是否標識了所有內部和外部的傳遞關系8軟件工程方案是否標明了工程的依賴關系9軟件工程方案是否標明了角色和責任10軟件工程方案是否標明了匯報的機制11軟件工程方案是否說明了跟蹤和監(jiān)控機制12軟件工程方案是否包含“軟件質量保證方案和“軟件配置治理方案13軟件工程方案是否包含工程開發(fā)使用的工具14軟件工程方案是否包含工程的各里程碑的說明15進度中是否標明了軟件工程方案的關鍵路徑2-17:參加“軟件工程方案評審的人員,除軟件經理和工程組人員外,必須有產品經理、上級治理部門包括軟件工程組SEPG、SQA人員.2-18：“

22、軟件工程方案通過評審后,軟件經理組織相關人員對任務進行承諾,簽定工作任務書.2-9:必須對“軟件工程方案進行配置治理,“軟件工程方案的更改必須經過評審.2-10:在開發(fā)活動中,必須根據工程跟蹤與監(jiān)控方案和體制,對照“軟件工程方案,跟蹤工程開發(fā)的實際結果和性能.2-11:當實際結果和“軟件工程方案發(fā)生偏離時,必須進行分析,根據分析結果標明糾正舉措.必要的情況下,要及時修訂“軟件工程方案.2-12:在軟件工程跟蹤監(jiān)控活動中,必須定期進行總結和評審,撰寫開發(fā)狀態(tài)報告.2-19:根據工程的特點,報告的周期可以為周、雙周、月.2-13:在軟件開發(fā)各里程碑階段結束前,必須進行階段評審,對軟件工程進行重估計

23、,必要的情況下修訂“軟件工程方案.2-20：必須提供相應資源,包括工具和人員等,進行軟件工程方案和工程跟蹤監(jiān)控活動.2-14:在軟件工程方案和工程跟蹤監(jiān)控過程活動中,必須進行數(shù)據度量和分析.說明：參見“9.數(shù)據度量和分析.3概要設計3-1:概要設計要以軟件需求規(guī)格為根底,必須保證需要實現(xiàn)的需求規(guī)格已經被設計.3-2:當需求規(guī)格發(fā)生變更時,必須修訂相關概要設計文檔.3-3:在概要設計文檔或需求治理文檔中,必須記錄、驗證需求和概要設計的跟蹤關系.說明：需求和概要設計的跟蹤關系可參考建議3-1.3-1:采用需求、子系統(tǒng)、模塊的跟蹤矩陣表記錄需求和概要設計的跟蹤關系.3-4:必須保證概要設計文檔和代碼

24、的一致性.當發(fā)生設計更改時,必須修訂相應設計文檔.3-5:必須對概要設計文檔進行正規(guī)檢視.3-6:概要設計過程結束前,必須通過評審,并保存評審記錄.3-7:設計更改必須經過相關評審,并保存評審記錄.3-8:對概要設計文檔的正規(guī)檢視或評審,必須檢查概要設計文檔的清楚性、完備性、標準性、一致性、正確性、數(shù)據、功能性、接口、詳細程度、可維護性、性能、可靠性、可測試性、可追溯性.說明：參考建議3-2.3-2:采用以下檢查表檢查概要設計文檔的清楚性.序號問題彳程序結構,包括數(shù)據流、限制流和接口的描述是否清楚3-3:采用以下檢查表檢查概要設計文檔的完備性序號問題1設計目標是否認義2需求規(guī)格評審中不完整的需

25、求TBD是否都已經解決3如果以前定義的不完整的需求TBD發(fā)生了改變,本設計是否能夠支持4是否對不完整需求TBD的影響進行了評估5對有可能不能實現(xiàn)的設計是否有風險治理方案6是否對設計模式進行了描述3-4:采用以下檢查表檢查概要設計文檔的標準性3-5:3-6:3-7:1|文檔是否符合公司模板和寫作要求序號問題2程序、模塊、函數(shù)、數(shù)據成員的名稱是否保持一致3設計是否反映了真正的操作環(huán)境硬件環(huán)境軟件環(huán)境4對系統(tǒng)設計的多種可能的描述之間是否保持一致例如：靜態(tài)結構的描述和動態(tài)描述采用以下檢查表檢查概要設計文檔的一致性.采用以下檢查表檢查概要設計文檔的正確性.序號12問題設計在方案、預算、技術上是否可行?邏

26、輯是否正確和完備采用以下檢查表檢查概要設計文檔的數(shù)據描述.序號問題是否對所有的數(shù)據成員,參數(shù),對象進行了描述是否所有需要的數(shù)據結構都進行了定義,或者定義了不需要的數(shù)據結構是否所有的數(shù)據成員都進行了足夠詳細的描述數(shù)據成員的有效值區(qū)間是否認義共享和存儲數(shù)據的使用是否描述清楚T3-8:采用以下檢查表檢查概要設計文檔的功能性要求.序號問題模塊的規(guī)格是否和軟件需求文檔中的功能需求和軟件接口規(guī)格要求保持一'致.是否給每個子模塊確定了抽象算法?設計和算法是否能滿足模塊的所有需求T3-9:采用以下檢查表檢查設計的接口描述.序號1234問題是否描述了接口的功能特征一接口是否便于查錯接口相互之間、和其他模

27、塊、和需求說明書及接口規(guī)格書保持一致對接口的數(shù)量和復雜度進行了有效的平衡,使接口數(shù)量限制在一個較小數(shù)量,每個接口具有可接受的復雜度是否所有的接口都能描述了必要的類型、數(shù)量、質量等信息一操作界面是否考慮了用戶例如：提供準確、清楚、有用的提示信息3-10:采用以下檢查表檢查設計的詳細程度.序號問題1是否估計了每個子模塊的規(guī)模代碼的行數(shù)是否可信?3-112是否考慮了足夠數(shù)量及代表性的系統(tǒng)狀態(tài)?3卜羊細程度是否足夠進行下一步的詳細設計?:采用以下檢查表檢查設計的可維護性.序號問題1是否模塊化設計2模塊是否為高內聚、低耦合3-12序號問題1是否進行了性能模型分析2是否描述了所有的性能參數(shù)例如：實時性能約

28、束,存儲空間,速度要求,磁盤I/O空間3進程是否有時間窗例如：需要“加鎖的標記,信號燈,某些代碼執(zhí)行時需要屏蔽中斷4程序執(zhí)行過程中的關鍵路徑是否都被標識和經過分析:采用以下檢查表檢查設計的性能3-13序號問題1設計是否考慮了檢錯和恢復舉措例如：輸入檢查2是否考慮了異常情況3是否完全準確描述了所有的出錯情況4設計是否能夠滿足所有系統(tǒng)集成方面的要求:采用以下檢查表檢查設計的可靠性:采用以下檢查表檢查設計的可測試性3-14序號問題1設計是否能夠被實驗、演示或檢視以顯示它滿足了需求2設計是否能夠使用以前的測試代碼,是否能夠進行增量式的測試?3-15序號問題1是否每一局部的設計都可以追溯到需求說明書,接

29、口規(guī)格說明書、或其他產品文檔2是否所有的設計決策都可以追溯到財務分析3對所繼承下來的那些特別和不常用的特性對目前設計的影響是否進行了分析4對所繼承設計中的風險是否進行了定位和分析:采用以下檢查表檢查設計的可追溯性4詳細設計4-1:詳細設計要以軟件需求規(guī)格和概要設計為根底,必須保證需要實現(xiàn)的需求規(guī)格已經被設計,必須保證概要設計定義的所有模塊已經被詳細設計.4-2:當需求規(guī)格或概要設計發(fā)生變更時,必須修訂相關詳細設計文檔.4-3:在詳細設計文檔或需求治理文檔中,必須記錄、驗證需求、概要設計、詳細設計的跟蹤關系.說明：需求、概要設計、詳細設計的跟蹤關系可參考建議4-1.4-1:采用需求、子系統(tǒng)、模塊

30、、函數(shù)的跟蹤矩陣表記錄需求、概要設計、詳細設計的跟蹤關系.4-4:必須保證詳細設計文檔和代碼的一致性.當發(fā)生設計更改時,必須修訂相應設計文檔.4-5:必須對重要的詳細設計文檔進行正規(guī)檢視.說明：參考建議4-2.4-2：根據模塊的復雜度、規(guī)模和在軟件系統(tǒng)中的重要程度,選擇重要的詳細設計文檔進行正規(guī)檢視.在產品中,進行正規(guī)檢視的詳細設計文檔比例要到達60%.4-6:詳細設計過程結束前,必須通過評審,并保存評審記錄.4-7:設計更改必須經過相關評審,并保存評審記錄.4-8:對詳細設計文檔的正規(guī)檢視或評審,必須檢查詳細設計文檔的清楚性、完備性、標準性、一致性、正確性、數(shù)據、功能性、接口、詳細程度、可維

31、護性、性能、可靠性、可測試性、可追溯性.說明：參考建議4-3.4-3:采用以下檢查表檢查詳細設計文檔的清楚性.序號問題1是否所有的單兀和進程的設計目的都已文檔化2單元設計,包括數(shù)據流、限制流、接口描述是否清楚3單元的整體功能是否描述清楚4-4:采用以下檢查表檢查詳細設計文檔的完備性序號卜'可題7是否提供了所有程序單元的規(guī)格2是否描述了所采用的設計標準3是否確定了單元應用的算法例如：PDD4是否列出了單兀的所有調用5是否記錄了設計繼承的歷史和的風險4-5:采用以下檢查表檢查詳細設計文檔的標準性.序號可題一1文檔是否遵從了公司的標準?2單元設計是否使用了要求的方法和工具?4-6:采用以下檢

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

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

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

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

36、動模塊,測試用例集,測試結果4序號問題1是否每一局部的設計都可以追溯到需求2是否每一個設計決策都可以追溯到效益分析3是否所有的設計決策都可以追溯到本錢/效益分析4；是不是描述了每個單兀的詳細需求,5單兀需求是否能夠追溯到軟件規(guī)格文檔SSD-1?軟件規(guī)格文檔是否能夠跟蹤到單元需求6是否有到代碼的引用或者包括代碼本身5編碼5-1:編碼必須以設計文檔為根底,必須保證所有的設計都被編碼實現(xiàn).當設計發(fā)生變更時,必須修改相關代碼.5-2:必須保證設計文檔和代碼的一致性.當代碼的修改已經造成設計更改時,必須修訂相應設計文檔.5-3:必須對重要的代碼進行正規(guī)檢視.說明：參考建議5-1.5-1:根據模塊、函數(shù)/

37、單元/進程的復雜度、規(guī)模和在軟件系統(tǒng)中的重要程度,選擇重要的代碼進行正規(guī)檢視.在產品中,進行正規(guī)檢視的代碼比例要到達40%.5-4:在代碼已經基線化后,對代碼的更改必須通過評審,并保存評審記錄.5-5:代碼必須遵守相關的XX言息JAV腕程標準.5-6:對代碼的正規(guī)檢視和評審,必須依照“XX言息JAV斕程標準的規(guī)定檢查編程標準程度,并對代碼符合情況進行考量.5-7:工程編碼完成后,必須提交Sonarqube平臺進行靜態(tài)質量檢測.6需求治理6-1:產品工程必須安排人員負責需求治理的責任.說明：責任參見建議6-1.6-1:需求治理的責任至少應包括以下內容：>¥WW1在產品工程整個生存

38、周期內,治理系統(tǒng)需求和它們的分配,并對其建立文檔.2實現(xiàn)對系統(tǒng)需求及其分配的更改.6-2:必須建立文檔標識分配到軟件中的產品系統(tǒng)需求.說明：文檔的內容參見建議6-2.6-2:標識分配到軟件中的產品系統(tǒng)需求的文檔至少應包含以下內容I內容1影響和確定軟件工程活動的非技術性需求即：協(xié)議、條件、合同條款等.2對軟件的技術需求.3用于確認軟件產品滿足分配需求的驗收標準.6-3:相關人員必須接受需求治理活動方面的培訓.說明：參見建議6-3.6-3:培訓至少包括以下內容：jf#Ww1工程所使用的方法、標準、規(guī)程2應用領域的知識6-4:必須對對經過評審和批準的需求文檔進行治理和限制.說明：參見建議6-4.6-

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

40、建立相關度量記錄.說明：參見建議6-76-7：對需求活動的度量至少應包含以下內容:序號內容1需求的數(shù)量2需求的狀態(tài)3需求的類型4需求的更改次數(shù)6-8:需求治理活動和其文檔必須接受上級治理部門、產品工程經理、SQA的評審.7軟件配置治理7-1:產品工程要任命配置治理的人員和組織,在整個配置治理活動中明確他們的責任.說明：參考建議7-1.7-1:參照?軟件配置治理標準?和?軟件配置治理指導書?,任命SCMfi織.7-2:產品工程必須制定軟件配置治理方案SCMP,指導整個配置治理活動.說明：參考建議7-2.7-2:工程經理根據?配置治理方案模板?,負責制定配置治理方案.7-3:軟件配置治理方案必須包

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

42、個符合標準的版本描述文檔.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數(shù)量,CRs分布統(tǒng)計表,CRs流通量統(tǒng)計表,CRs狀態(tài)分布統(tǒng)計表等.說明：參考建議7-4.7-4:建議正常情況2周發(fā)布一次,更改頻繁時是1周,更改較少時是3周7-12:建立可以表達開發(fā)版本和基線版本兩種不同受控程度的配置庫系統(tǒng)說明：參考建議7-5.7-5:建議使

43、用SCM工具的分支功能實現(xiàn)不同類型的版本限制7-13:制定一個基線化流程指導建立基線.說明：參考建議7-6.7-6：建議在配置治理方案中對流程進行描述,該流程要保證基線化過程中的物理配置審計PCA功能配置審計FCA,SQA評審和審計等過程.7-14:內外的發(fā)布必須只能來自基線庫.7-15:產品工程經理、SQA要定期對SCM勺活動和其文本至S行評審/檢查,輸出評審/檢查結果,制定并實施改良舉措7-16:相關SCMF審要制定相應的Checklist進行指導,評審要有記錄.8軟件質量保證8-1:產品工程組要有相關的SQA人員和組織,并開展SQA活動.8-2:產品工程SQA的組織活動必須通過如下檢查.

44、序號問題產品工程是否建立一個獨立的、能夠支持那些要求獨立性活動的SQA!織?對所有工程,SQ助能是否到位SQAI是否有一個向產品組之上的治理者、治理部門報告的渠道?是否為組織進行SQ粘動提供足夠的資源和費用4SQAI的成員是否接受了培訓以完成他們的SQ船動5工程的軟件相關成員是否接受了有關SQA1任務、責任、權利等的相關培訓6上級治理部門是否對產品工程的SQ序動及其結果進行了定期評審7產品工程經理是否認期和事件驅動地參與評審SQ席動8SQAI活動及其工作產品是否接受了SQA!之外的專家進行的定期評審9工程組是否制定一個執(zhí)行SQA活動的方案SQAP.如制定了SQA計戈ij,計戈ij的制訂是否根據

45、已文檔化的組織的SQA規(guī)程和SQA方案模版執(zhí)行產品工程必須有SQA方案,SQA方案必須通過如下檢查.序號問題1制定SQA十劃的活動是否根據公司的相關標準進行如果存在偏差,是否形成了偏差文檔,并得到研究技術治理處的批準2SQA十劃是否符合公司標準中SQA十戈ij模板的要求如果存在偏差,是否形成了偏差文檔,并得到研究技術治理處的批準3SQ砧動是否根據SQA十劃進行4SQA十劃是否經過方案中涉及的相關組和個人的評審,并得到SQ魔理、產品工程經理的批準5SQA十劃和軟件工程方案是否在工程的里程碑處進行了修改,修改是否得到批準SQA十劃和軟件工程開發(fā)方案是否R步變更8-3:8-4:SQA必須對產品軟件開

46、發(fā)過程進行過程審計.說明：參考建議8-1.8-5SQA的過程審計必須通過如下的檢查.序號12345問題產品工程是否明確定義了各種軟件活動過程定義的活動過程是否經過和相關治理部門的批準軟件過程審計是否根據公司制訂的軟件過程審計規(guī)程執(zhí)行SQ勰否對每一個軟件活動過程提交了過程審計報告是否提交了過程不符合項報告SQA勺過程審計結果是否通過適當?shù)那缊蟾娼o適當?shù)闹卫碚逽QA8-1:要對以下的過程進行審計：需求分析過程、軟件概要設計過程、軟件詳細設計過程、軟件測試過程、版本發(fā)布過程、配置治理過程、變更限制過程、需求治理過程.8-6:SQA必須參與工程的技術評審活動.說明：參考建議8-2,8-3.8-2:S

47、QA必須參與工程的技術評審活動包括：需求評審、系統(tǒng)設計評審、概要設計評審、詳細設計評審等.8-3：SQAft技術評審過程應檢查:序號問題技術評審的方法對被評審的軟件工作產品是適宜的?技術評審的過程是根據公司制訂的技術評審過程規(guī)程執(zhí)行的嗎?技術評審的結果是否相應的評審規(guī)程的要求形成了報告4技術評審的報告,報告給SQA人員了嗎?5SQ從員對技術評審的結果進行分析了嗎8-7:SQA人員必須定期生成SQA活動的報告.說明：參考建議8-4.8-4:對SQA報告的檢查包括:序號內容1是否報告各種軟件工作產品的評審記錄2報告的評審記錄是否符合公司標準的要求?3是否有軟件過程審計的審計報告4是否把報告送交給上級治理部門、技術治理處、產品工程經理嗎是否有軟件過程分析和質量報告?58-8:產品工程的SQA人員必須制定一個實施SQA工作的月度方案、季度方案,和年度方案.方案必須得到上級SQA經理的評審和批準.8-9:SQ