軟件項目研發(fā)管理流程_第1頁
軟件項目研發(fā)管理流程_第2頁
軟件項目研發(fā)管理流程_第3頁
免費預(yù)覽已結(jié)束,剩余35頁可下載查看

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、XX信息軟件開發(fā)項目技術(shù)管理規(guī)范文件編號:RK-S20170802生效日期:受控編號::版次:Verl.O修改狀態(tài)::編制:審核:批準:貴州XX信息科技有限公司目錄一、編寫說明3二、 軟件項目整體開發(fā)流程 4三、各階段崗位職責(zé)與工作內(nèi)容 5四、各階段工作要求91 軟件需求分析 92軟件項目計劃1.33概要設(shè)計1.74詳細設(shè)計205編碼246需求管理257軟件配置管理278軟件質(zhì)量保證289數(shù)據(jù)度量和分析31、編與說明為了把公司已經(jīng)發(fā)布的軟件開發(fā)過程規(guī)范有效地運作于產(chǎn)品開發(fā)活動中,把各種規(guī)范“逐 步形成工程師的作業(yè)規(guī)范”,特制定本軟件開發(fā)行為規(guī)范,以達到過程控制的目的。與軟件開發(fā)相關(guān)的所有人員,

2、包括各級經(jīng)理和工程師都必須遵守本軟件開發(fā)行為規(guī)范。對 違反規(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ā)部負責(zé)解釋和維護。、軟件項目整體開發(fā)流程風(fēng)險分析說明書立項管理立項報告需求分析需求分析規(guī)格說明書需求變更 說明書需

3、求變更福開發(fā)計劃項目或產(chǎn)品開發(fā)計劃設(shè)計編碼F質(zhì)量?控制驗收交付三、各階段崗位職責(zé)與工作內(nèi)容序 號工作名稱負責(zé)人參與人審批人工作內(nèi)容交付物工作說明1立項管理項目經(jīng)理售前經(jīng)理總經(jīng)理1項目或產(chǎn)品建設(shè)內(nèi) 容;2.項目風(fēng)險分析; 3明確后續(xù)工作;4討 論解決方案。1風(fēng)險分析報告;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ī)格

4、說明書 由售前經(jīng)理編制, 提交開發(fā)經(jīng)理后; 開發(fā)經(jīng)理開始開發(fā) 計劃編制3開發(fā)計劃開發(fā)經(jīng)理項目經(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. 完成軟件

5、編碼;2. 完成詳細設(shè)計說明書;3. 代碼迭代及版本控制1. 軟件代碼及數(shù)據(jù) 庫2. 詳細設(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)理測試工程

6、師、 開發(fā)工程師總工程師完成軟件測試1.測試計劃2功能測試報告(含 測試用例)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ā)組 明確運維職責(zé)后, 人員開始進入其他 項目9項目運維實施經(jīng)理項目經(jīng)理1. 及時發(fā)現(xiàn)對項目運行 期間的問題和客戶新需求;2. 需

7、求甄別,需及時更 改的提交開發(fā)經(jīng)理;3.保持客戶溝通運維報告、需求更 改說明書四、各階段工作要求1軟件需求分析1- 1 :軟件需求分析必須在產(chǎn)品需求規(guī)格的基礎(chǔ)上進行,并保證完全實現(xiàn)產(chǎn)品需求規(guī)格的定義。1- 2 :當(dāng)產(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ī)定的需求定義所應(yīng)該包含的所有內(nèi)容?2需求定義是否包含了有關(guān)功能、性能、限制、目標、質(zhì)量等方面的所有 需求?3功能性需求是否覆蓋

9、了所有非正常情況的處理?4是否對各種操作模式(如正常、非正常、有干擾等)下的環(huán)境條件都作 了規(guī)定?5是否對所有功能與時間因素有關(guān)的方面都作了考慮?6是否標識出了所有與時間因素有關(guān)的功能?它們的時間準則是否都說明 了?時間準則的最大、最小執(zhí)行時間是否都定義了?7是否標識并定義了在將來可能會變化的需求?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在不冋負

10、載情況下,是否規(guī)定了系統(tǒng)的處理能力?17在不同情況下,是否規(guī)定了系統(tǒng)的響應(yī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)先排序?1- 3 :采用以下檢查表檢查軟件需求規(guī)格文檔中需求的兼容性序號問題1界面需求是否使軟硬件系統(tǒng)具有兼容性?2需求定義的文檔是

11、否滿足項目文檔編寫標準?在矛盾時, 準可供選擇?是否有適當(dāng)?shù)臉?- 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ī)格文檔中需求的正確性。序號問題1需求定義是否滿足標準的要求?2算法和規(guī)則是否有科技文獻或其它文獻作為基礎(chǔ)?3是否定義了對在錯誤、風(fēng)險分析中所標識出的各種故障模式和錯誤類型

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

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

14、性測試 數(shù)據(jù)的基礎(chǔ)?8需求定義的描述是否將對程序的需求和所提供的其它信息分離開來了?:采用以下檢查表檢查軟件需求規(guī)格文檔中需求的易測試性和可驗證性序號問題1需求是否可以驗證(即是否可以檢驗軟件是否滿足了需求)?2是否對每一個需求都指定了驗證過程?3數(shù)學(xué)函數(shù)的定義是否使用了精確定義的語法和語義符號?米用以下檢查表檢查軟件需求規(guī)格文檔中的性能需求描述。序號問題1-121-7 :1-8 :1-9 :1-101-111-131-141-151-16是否精確的描述了所有的性能需求和可容忍的性能降低程度?對每一個 性能應(yīng)包含兩方面的內(nèi)容:a.b.在最壞情況的執(zhí)行結(jié)果本性能失效后,對系統(tǒng)產(chǎn)生的影響:采用以下

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

16、即能否保證在對某部分修改后,產(chǎn)生最小的連鎖效應(yīng))?2軟件項目計劃2- 1 :軟件項目計劃必須以產(chǎn)品/軟件的需求規(guī)格為基礎(chǔ)。當(dāng)發(fā)生需求更改時,必須修訂軟件開發(fā)計劃。 說明:軟件項目計劃必須依據(jù)需求規(guī)格進行制定。項目計劃中的工作產(chǎn)品和工作任務(wù)應(yīng)保證能完 全實現(xiàn)需求規(guī)格的定義。當(dāng)需求更改時,必須考慮需求更改的相關(guān)性,修訂相應(yīng)軟件開發(fā)計劃。2- 1 :制定軟件項目計劃的活動制定,必須遵守“軟件項目計劃規(guī)范”。2- 2 :軟件經(jīng)理對軟件項目計劃的制定和結(jié)果負責(zé)。2- 3 :軟件經(jīng)理和相關(guān)參與軟件項目計劃的制定和評審的人員,在參與計劃制定之前必須經(jīng)過軟件工程 和軟件項目計劃制定流程的培訓(xùn)。2- 2 :對于

17、軟件項目計劃中各項工作產(chǎn)品和工作任務(wù), 目計劃文檔中記錄估計的方法和估計數(shù)據(jù)。說明:參考建議2-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ù)最大估計期望估計 類比獲得(根據(jù)經(jīng)驗)最小估計PERT估計規(guī)模工作量規(guī)模工作量規(guī)模工作量規(guī)模工作量XX版本(增加XX特 性話統(tǒng) 模塊概 要設(shè)計文檔頁 數(shù):45;增 加、修改模塊設(shè) 計數(shù)目:121

18、2天文檔頁 數(shù):42;增 加、修改模塊設(shè) 計數(shù)目:1010天文檔頁數(shù):30;增加、修改模塊設(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 :在“

19、軟件項目計劃”中包括軟件重用計劃。包括重用軟件部件的計劃和開發(fā)可重用軟件部件的 計劃。2- 11 :在“軟件項目計劃”包括人員的培訓(xùn)計劃。說明:項目人員計劃包括需要的人員類型、數(shù)量和技術(shù)等級的要求,相關(guān)人員的開始工作時間、 工作周期、接受培訓(xùn)的計劃等。2- 12 :對軟件項目進行風(fēng)險分析與評估。說明:可能存在的風(fēng)險領(lǐng)域含:需求的不明確和變更、外部的限制與對外的依賴、人力資源的到 位情況、人力資源的技術(shù)等級滿足要求狀況、技術(shù)問題等。對風(fēng)險的分析與評估實踐包括:從已知的情況推導(dǎo)出潛在風(fēng)險;對風(fēng)險進行分析,得出:潛在風(fēng)險可能引發(fā)的問題的影響、潛在風(fēng)險發(fā)生的可能性大小、風(fēng)險發(fā)生的時間段等;排列風(fēng)險的重

20、點次序;對風(fēng)險記錄成文件(屬于軟件項目計劃中的一部分);風(fēng)險經(jīng)受風(fēng)險影響人審核,并取得他的同意;根據(jù)需要,在開發(fā)過程中對風(fēng)險文檔進行維護和修訂。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ā)計劃建立軟件驗證與確認計劃。軟件驗證與確認計

21、劃可作為獨立的計劃 文檔。2-5 :必須對項目工作進行分解,確定項目的工作任務(wù),任務(wù)的責(zé)任人、資源要求、時間要求、項目的 進度。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軟件項目計劃

22、是否有開發(fā)方法的說明?3軟件項目計劃是否有資源需求的說明?4軟件項目計劃是否包含風(fēng)險管理計劃?5軟件項目計劃是否包含了版本發(fā)布的機制?6軟件項目計劃是否標識了所有必須的培訓(xùn)計劃?7軟件項目計劃是否標識了所有內(nèi)部和外部的傳遞關(guān)系?8軟件項目計劃是否標明了項目的依賴關(guān)系?9軟件項目計劃是否標明了角色和職責(zé)?10軟件項目計劃是否標明了匯報的機制?11軟件項目計劃是否說明了跟蹤和監(jiān)控機制?12軟件項目計劃是否包含“軟件質(zhì)量保證計劃”和“軟件配置管理計劃”?13軟件項目計劃是否包含項目開發(fā)使用的工具?14軟件項目計劃是否包含項目的各里程碑的說明?15進度中是否標明了軟件項目計劃的關(guān)鍵路徑?2-17 :參

23、加“軟件項目計劃”評審的人員,除軟件經(jīng)理和項目組人員外,必須有產(chǎn)品經(jīng)理、上級管理 部門(包括軟件工程組SEPG)、SQA人員。2-18 :“軟件項目計劃”通過評審后,軟件經(jīng)理組織相關(guān)人員對任務(wù)進行承諾,簽定工作任務(wù)書。2-9 :必須對“軟件項目計劃”進行配置管理,“軟件項目計劃”的更改必須經(jīng)過評審。2-10 :在開發(fā)活動中,必須按照項目跟蹤與監(jiān)控計劃和體制,對照“軟件項目計劃”,跟蹤項目開發(fā)的實際結(jié)果和性能。2-11 :當(dāng)實際結(jié)果和“軟件項目計劃”發(fā)生偏離時,必須進行分析,根據(jù)分析結(jié)果標明糾正措施。必 要的情況下,要及時修訂“軟件項目計劃”。2-12 :在軟件項目跟蹤監(jiān)控活動中,必須定期進行總

24、結(jié)和評審,撰寫開發(fā)狀態(tài)報告。2-19 :根據(jù)項目的特點,報告的周期可以為周、雙周、月。2-13 :在軟件開發(fā)各里程碑階段結(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 :當(dāng)需求規(guī)格發(fā)生變更時,必須修訂相關(guān)概要設(shè)計文檔。3- 3 :在概要設(shè)計文檔或需求管理文檔中,必須

25、記錄、驗證需求和概要設(shè)計的跟蹤關(guān)系。說明:需求和概要設(shè)計的跟蹤關(guān)系可參考建議3-1。3- 1 :采用需求、子系統(tǒng)、模塊的跟蹤矩陣表記錄需求和概要設(shè)計的跟蹤關(guān)系。3- 4 :必須保證概要設(shè)計文檔和代碼的一致性。當(dāng)發(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ù)、功能性、接口、詳細程度、可維護性、性能、可靠性、可測試性、可追溯性。說明:參考建議

26、3-2 。3- 2 :采用以下檢查表檢查概要設(shè)計文檔的清晰性。序號問題1程序結(jié)構(gòu),包括數(shù)據(jù)流、控制流和接口的描述是否清楚?3- 3 :采用以下檢查表檢查概要設(shè)計文檔的完備性序號問題1設(shè)計目標是否定義?2需求規(guī)格評審中不完整的需求(TBD)是否都已經(jīng)解決?3如果以前定義的不完整的需求 (TBD)發(fā)生了改變,本設(shè)計是否能夠支持?4是否對不完整需求(TBD)的影響進行了評估?5對有可能不能實現(xiàn)的設(shè)計是否有風(fēng)險管理計劃?6是否對設(shè)計模式進行了描述 ?3- 4 :采用以下檢查表檢查概要設(shè)計文檔的規(guī)范性 序號 問題文檔是否符合公司模板和寫作要求3- 5 :采用以下檢查表檢查概要設(shè)計文檔的一致性。序號問題2

27、程序、模塊、函數(shù)、數(shù)據(jù)成員的名稱是否保持一致?3設(shè)計是否反映了真正的操作環(huán)境?硬件環(huán)境?軟件環(huán)境?4對系統(tǒng)設(shè)計的多種可能的描述之間是否保持一致?(例如:靜態(tài)結(jié)構(gòu)的描述和動態(tài)描述)3- 6 :采用以下檢查表檢查概要設(shè)計文檔的正確性。序號問題1設(shè)計在計劃、預(yù)算、技術(shù)上是否可仃?2邏輯是否正確和完備?3- 7 :采用以下檢查表檢查概要設(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ù)的使用是否描述清楚?3- 8 :采用以下

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

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

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

31、了定位和分析?必須致性、4詳細設(shè)計4- 1 :詳細設(shè)計要以軟件需求規(guī)格和概要設(shè)計為基礎(chǔ),必須保證需要實現(xiàn)的需求規(guī)格已經(jīng)被設(shè)計,保證概要設(shè)計定義的所有模塊已經(jīng)被詳細設(shè)計。4- 2 :當(dāng)需求規(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è)計文檔和代碼的一致性。當(dāng)發(fā)生設(shè)計更改時,必須修訂相應(yīng)設(shè)計文檔。4- 5 :必須對重要的詳細

32、設(shè)計文檔進行正規(guī)檢視。說明:參考建議4-2 。4- 2 :根據(jù)模塊的復(fù)雜度、規(guī)模和在軟件系統(tǒng)中的重要程度,選擇重要的詳細設(shè)計文檔進行正規(guī)檢視 在產(chǎn)品中,進行正規(guī)檢視的詳細設(shè)計文檔比例要達到 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è)計文檔的清晰性。序號問題1是否所有的單兀和進程的設(shè)計目

33、的都已文檔化?2單元設(shè)計,包括數(shù)據(jù)流、控制流、接口描述是否清楚?3單元的整體功能是否描述清楚?4- 4 :采用以下檢查表檢查詳細設(shè)計文檔的完備性序號問題1是否提供了所有程序單元的規(guī)格?2是否描述了所采用的設(shè)計標準?3是否確定了單元應(yīng)用的算法?(例如:PDL4是否列出了單兀的所有調(diào)用?5是否記錄了設(shè)計繼承的歷史和已知的風(fēng)險?4- 5 :采用以下檢查表檢查詳細設(shè)計文檔的規(guī)范性序號問題1文檔是否遵從了公司的標準?2單兀設(shè)計是否使用了要求的方法和工具?4- 6 :采用以下檢查表檢查詳細設(shè)計的一致性。序號問題1在單兀和單兀的接口中數(shù)據(jù)成員的名稱是否保持一致?2所有接口之間,接口和接口規(guī)格書之間是否保持一

34、致?3詳細設(shè)計和概要設(shè)計文檔是否能夠完全描述“正在構(gòu)建”的系統(tǒng)4- 7 :采用以下檢查表檢查詳細設(shè)計的正確性。序號問題1是否有邏輯錯誤?2需要使用常量名稱的地方是否有錯誤?3是否所有的條件都被處理? (>,=,< switch case)?4分支所處的狀態(tài)是否正確?(邏輯沒有搞反)4- 8 :采用以下檢查表檢查詳細設(shè)計的數(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是否所有的變量、

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

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

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

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

39、- 1:根據(jù)模塊、函數(shù)/單元/進程的復(fù)雜度、規(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ì)量檢測。6需求管理6- 1 :產(chǎn)品項目必須安排人員負責(zé)需求管理的職責(zé)。說明:職責(zé)參見建議6-1 。6-1 :需求管理的職責(zé)至

40、少應(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。6-2 :標識分配到軟件中的產(chǎn)品系統(tǒng)需求的文檔至少應(yīng)包含以下內(nèi)容序號內(nèi)容1影響和確定軟件項目活動的非技術(shù)性需求(即:協(xié)議、條件、合冋條款等)。2對軟件的技術(shù)需求。3用于確認軟件產(chǎn)品滿足分配需求的驗收標準。6- 3 :相關(guān)人員必須接受需求管理活動方面的培訓(xùn)。說明:參見建議6-3 。6-3 :培訓(xùn)至少包括以下內(nèi)容:序號內(nèi)容1項目所使用的方法、標準、規(guī)程2應(yīng)用領(lǐng)域的知識6- 4 :必須對

41、對經(jīng)過評審和批準的需求文檔進行管理和控制。說明:參見建議6-4。6-4 :對經(jīng)過評審和批準的需求至少應(yīng)采用以下方法進行管理和控制:序號內(nèi)容1在配置管理計劃(SCMP)中將需求文檔定義為 CI。2對需求文檔進行配置管理。3相應(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)容:序號內(nèi)容1按照公司模板

42、制定需求跟蹤說明書2跟蹤需求狀態(tài)的變化3需求的跟蹤和分配經(jīng)過評審6- 7 :在需求管理活動中必須建立相關(guān)度量記錄。說明:參見建議6-76-7 :對需求活動的度量至少應(yīng)包含以下內(nèi)容:序號內(nèi)容1需求的數(shù)量2需求的狀態(tài)3需求的類型4需求的更改次數(shù)6-8 :需求管理活動和其文檔必須接受上級管理部門、產(chǎn)品項目經(jīng)理、SQA的評審。7軟件配置管理7- 1 :產(chǎn)品項目要任命配置管理的人員和組織,在整個配置管理活動中明確他們的職責(zé)。 說明:參考建議7-1 。7- 1 :參照軟件配置管理規(guī)范和軟件配置管理指導(dǎo)書,任命 SCM組織SCMP),指導(dǎo)整個配置管理活動。7- 2 :產(chǎn)品項目必須制定軟件配置管理計劃( 說明

43、:參考建議7-2 。7- 2 :項目經(jīng)理根據(jù)配置管理計劃(模板),負責(zé)制定配置管理計劃7-3 :軟件配置管理計劃必須包括如下的內(nèi)容:序號內(nèi)容1對各階段應(yīng)受控的配置項進行選擇、分類、標識。2定義配置項(CI)的命名慣例3定義版本號命名方案4制定培訓(xùn)計劃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 :變更申請要有一

44、套流程支持,該流程要保證該變更申請(針對已基線化的配置項)有一個初始化,分類,設(shè)計,評估,分派,實現(xiàn),驗證,歸檔的整個過程。7- 8 :每個版本有一個符合規(guī)范的版本描述文檔。7- 9 :必須定義流程指導(dǎo)配置狀態(tài)發(fā)布。說明:參考建議7-3 。7- 3 :在配置管理計劃中描述配置狀態(tài)發(fā)布的周期,內(nèi)容和模板。7- 10 :配置項(Cl)的變更和配置管理活動的運行狀態(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

45、-4 。7- 4 :建議正常情況2周發(fā)布一次,更改頻繁時是1周,更改較少時是3周7- 12 :建立可以體現(xiàn)開發(fā)版本和基線版本兩種不同受控程度的配置庫系統(tǒng)說明:參考建議7-5 。7-5 :建議使用SCM工具的分支功能實現(xiàn)不同類型的版本控制7-13 :制定一個基線化流程指導(dǎo)建立基線。說明:參考建議7-6 。7-6 :建議在配置管理計劃中對流程進行描述,該流程要保證基線化過程中的物理配置審計( PCA 功能配置審計(FCA,SQA評審和審計等過程。7-14 :內(nèi)外的發(fā)布必須只能來自基線庫。7-15 :產(chǎn)品項目經(jīng)理、SQA要定期對SCM勺活動和其文檔進行評審 /檢查,輸出評審/檢查結(jié)果,制定 并實施改

46、進措施7-16 :相關(guān)SCM評審要制定相應(yīng)的 Checklist進行指導(dǎo),評審要有記錄。8軟件質(zhì)量保證8- 1 :產(chǎn)品項目組要有相關(guān)的 SQA人員和組織,并開展 SQA活動。8- 2: 產(chǎn)品項目SQA的組織活動必須通過如下檢查。序號問題1產(chǎn)品項目是否建立一個獨立的、能夠支持那些要求獨立性活動的 SQAI織?對所有項目,SQA功能是否到位?2SQAI是否有一個向產(chǎn)品組之上的管理者、管理部門報告的渠道?3是否為組織進行SQ/活動提供足夠的資源和費用?4SQ/組的成員是否接受了培訓(xùn)以完成他們的SQI活動?5項目的軟件相關(guān)成員是否接受了有關(guān)SQA組任務(wù)、職責(zé)、權(quán)利等的相關(guān)培訓(xùn)?6上級管理部門是否對產(chǎn)品

47、項目的 SQ鮎動及其結(jié)果進行了定期評審?7產(chǎn)品項目經(jīng)理是否定期和事件驅(qū)動地參與評審SQ活動?8SQAI活動及其工作產(chǎn)品是否接受了SQH之外的專家進行的定期評審?9項目組是否制定一個執(zhí)行 SQA活動的計劃SQAP。如制定了 SQA計劃,計劃 的制訂是否按照已文檔化的組織的SQA規(guī)程和SQA計劃模版執(zhí)行?8- 3:產(chǎn)品項目必須有SQA計劃,SQA計劃必須通過如下檢查。序號問題1制定SQA十劃的活動是否按照公司的相關(guān)規(guī)范進行? 成了偏差文檔,并得到研究技術(shù)管理處的批準?如杲存在偏差,是否形2SQA十劃是否符合公司規(guī)范中 SQA十劃模板的要求? 成了偏差文檔,并得到研究技術(shù)管理處的批準?如果存在偏差,

48、是否形3SQAS動是否按照SQA十劃進行?4SQA十劃是否經(jīng)過計劃中涉及的相關(guān)組和個人的評審, 項目經(jīng)理的批準?并得到SQ經(jīng)理、產(chǎn)品5SQA十劃和軟件項目計劃是否在項目的里程碑處進行了修改,修改是否得到 批準? SQA十劃和軟件項目開發(fā)計劃是否冋步變更?8- 4 : SQA必須對產(chǎn)品軟件開發(fā)過程進行過程審計。說明:參考建議8-1 。8- 1 :要對以下的過程進行審計:需求分析過程、軟件概要設(shè)計過程、軟件詳細設(shè)計過程、軟件測試過 程、版本發(fā)布過程、配置管理過程、變更控制過程、需求管理過程。8- 5 : SQA的過程審計必須通過如下的檢查。序號問題1產(chǎn)品項目是否明確定義了各種軟件活動過程?定義的活

49、動過程是否經(jīng)過 和相關(guān)管理部門的批準?SQA2軟件過程審計是否按照公司制訂的軟件過程審計規(guī)程執(zhí)行?3SQ/是否對每一個軟件活動過程提交了過程審計報告?4是否提交了過程不符合項報告?5SQA勺過程審計結(jié)果是否通過適當(dāng)?shù)那缊蟾娼o適當(dāng)?shù)墓芾碚撸?- 6 : SQA必須參與項目的技術(shù)評審活動。說明:參考建議8-2,8-3 。8- 2 : SQA必須參與項目的技術(shù)評審活動包括:需求評審、系統(tǒng)設(shè)計評審、概要設(shè)計評審、詳細設(shè)計評 審等。8- 3 : SQA在技術(shù)評審過程應(yīng)檢查:序號問題1技術(shù)評審的方法對被評審的軟件工作產(chǎn)品是合適的?2技術(shù)評審的過程是按照公司制訂的技術(shù)評審過程規(guī)程執(zhí)行的嗎?3技術(shù)評審的結(jié)果是否相應(yīng)的評審規(guī)程的要求形成了報告?4技術(shù)評審的報告,報告給 SQA人員了嗎?:5SQA人員對技術(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工作的月度計劃、季

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論