組織度量庫建立和維護(hù)規(guī)程

1、生命周期模型建立日期：2009年3月18日文檔編號：CS-OPD-GC-7版本變更原因變更內(nèi)容簡述編制/修訂者批準(zhǔn)者發(fā)布日期V1.0建立V1.1修改增加迭代模型的第2種 形式以適應(yīng)公司實際開發(fā)模式1前言1.1目的該文檔為神舟軟件公司確定合適的軟件生命周期提供指導(dǎo)，說明了公司具有代表性的三種項目類型，以及對應(yīng)的軟件生命周期的描述。1.2適用范圍適用于公司所有的軟件開發(fā)項目，軟件開發(fā)可分為：項目開發(fā)、產(chǎn)品開發(fā)和升級類項目。1.3術(shù)語和縮略語EPG : Engineering Process Group 工程過程小組 SOW: Statement Of Work，工作任務(wù)說明書WBS : Work

2、Breakdown Structure，工作任務(wù)分解結(jié)構(gòu)SRS：軟件需求規(guī)格說明書PPQA:產(chǎn)品與過程質(zhì)量保證MA :度量分析CM :配置管理CCR :關(guān)鍵計算機(jī)資源過程綜述該過程闡述了公司最具代表性的項目類型特性，以及他們所對應(yīng)的軟件生命周期描述。這三種項目類型分別為：項目開發(fā)，產(chǎn)品開發(fā)，升級類項目。同時又著重對開發(fā)類項目中的瀑布模型和迭代模 型進(jìn)行了詳細(xì)描述。開發(fā)類項目 是指公司新承接的，由客戶方提出的，有明確需求的項目，或由公司自主立項的新 項目。該類項目一般有比較完整的軟件生命周期，也可能根據(jù)項目的具體情況將其中幾個階段合并或 拆分。維護(hù)類項目 是指對公司原有開發(fā)完畢的已發(fā)布的項目進(jìn)行

3、維護(hù)，維護(hù)的需求可能來自客戶提交的問題報告單，也可能來自公司內(nèi)部測試人員提交的在發(fā)布時沒有解決的問題報告單。升級類項目是指公司對原有開發(fā)完畢項目進(jìn)行的后期開發(fā)項目，后期開發(fā)的主要內(nèi)容可能包括前期項目的缺陷修復(fù)、功能增強(qiáng)、新功能等等。角色與職責(zé)職責(zé)批準(zhǔn)組織級生命周期模型;角色（參考）高層經(jīng)理（公司總經(jīng)理、副總經(jīng)理）EPG組建立、維護(hù)組織過程資產(chǎn)及生命周期模型內(nèi)容 確保組織過程資產(chǎn)滿足模型和適合組織的實際需要。事業(yè)部經(jīng)理向EPG組提交生命周期模型改進(jìn)的意見、建議項目經(jīng)理參與項目生命周期模型的評審。向事業(yè)部經(jīng)理提交項目、度量信息及過程資產(chǎn)使用的有關(guān)問題的反饋PPQA工程師參與生命周期模型的評審。度里

4、工程師參與生命周期模型的評審。配置工程師參與生命周期模型的評審。技術(shù)專豕管理專家參與生命周期模型的評審。其他有關(guān)人員4主要過程根據(jù)軟件工程和公司項目的實際情況，主要對開發(fā)類項目的瀑布模型、迭代模型，以及維護(hù)類和升 級類項目分別描述。各個項目可以根據(jù)項目的需求特點，開發(fā)周期，團(tuán)隊規(guī)模，團(tuán)隊技術(shù)水平以及應(yīng)用的重要程度等項 目的特性數(shù)據(jù)來選擇適合自己項目的軟件生命周期。4.1瀑布模型瀑布模型是最常用的軟件開發(fā)模型，它的各個階段是按線性序列組織的。開發(fā)過程中的階段劃分為項 目策劃、需求分析、概要設(shè)計、詳細(xì)設(shè)計、編碼和單元測試、軟件集成和集成測試、系統(tǒng)測試、驗收和安 裝等（圖1 ）。盡管開發(fā)過程中定義了

5、各個階段的順序，但這些階段有時是相互交迭進(jìn)行的，階段間的依賴 性由入口準(zhǔn)則來確定。瀑布模型的每個階段均具有以下特征：從上一階段接受本階段工作的對象，作為輸入；對上述輸入實施本階段的活動；給出本階段的工作成果，作為輸出傳入下一階段；對本階段工作進(jìn)行評審，如果本階段工作得到確認(rèn)，那么繼續(xù)下階段工作，否則返回前一階段，甚至 更前階段。項目策劃階段項目策劃是每個項目的初始階段，目的是為開發(fā)過程和過程管理做好必要的準(zhǔn)備。項目策劃的主要工 作是進(jìn)行估計和制定管理項目的計劃。目標(biāo)根據(jù)項目特點和組織情況制定項目計劃，并獲得相關(guān)人員的同意/批準(zhǔn)適用標(biāo)準(zhǔn)和規(guī) 范集成項目管理過程定義相關(guān)工具M(jìn)S Word文件編輯工

6、具M(jìn)s Project項目管理工具M(jìn)S Excel主要輸入項目任務(wù)書、建議書或合冋技術(shù)附件客戶書面的需求入口準(zhǔn)則客戶書面需求已被批準(zhǔn)項目任務(wù)書、建議書已被批準(zhǔn)合冋技術(shù)附件已簽定 項目經(jīng)理已經(jīng)到位 參與項目準(zhǔn)備和策劃的人員接受過相關(guān)技能的培訓(xùn)活動1. 選擇項目生命周期模型2. 建立項目已定義過程3. 構(gòu)建頂層WBS4. 估計項目的規(guī)模、工作量、成本、進(jìn)度和關(guān)鍵計算機(jī)資源（CCR）等5. 標(biāo)識和分析風(fēng)險6. 計劃資源及其獲取方式7. 編制項目計劃及 PPQA計劃和配置管理計劃8. 評審和批準(zhǔn)項目計劃和從屬計劃主要輸出估計記錄，包括規(guī)模，進(jìn)度和成本項目風(fēng)險識別和跟蹤一覽表項目計劃，包括：進(jìn)度計劃、W

7、BS項目數(shù)據(jù)管理計劃和跟蹤表 、項目相關(guān)人員參與計劃和跟蹤表PPQA十劃、配置管理計劃出口準(zhǔn)則項目計劃得到受影響的組織和個人的承諾 項目計劃得到批準(zhǔn)并置于配置管理之下度量項目策劃所花的工作量約束項目策劃：時間跨度比例占項目周期比例的5-10%投入工作量比例占項目總工作量的比例5-10%角色職責(zé)高層經(jīng)理批準(zhǔn)項目計劃，提供項目計劃所需要的資源（公司總經(jīng)理、 副總經(jīng)理）事業(yè)部經(jīng)理 （部門經(jīng)理）審核項目計劃項目經(jīng)理建立和維護(hù)項目計劃、風(fēng)險管理PPQA工程師建立和維護(hù)PPQA計劃度里工程師建立和維護(hù)度量計劃配置工程師建立和維護(hù)配置管理計劃技術(shù)專豕參與項目計劃建立和維護(hù)的評審、估計管理專家其他有關(guān)人員需求

8、分析階段需求分析階段的主要目的是生成一個正確說明客戶所有需求的文檔。用戶需求規(guī)格說明書和軟件需求規(guī)格說明書（SRS）是該階段的主要輸出。需求分析的主要工作是需求提煉及分析、需求歸檔和需求評審等。需求分析階段執(zhí)行的活動主要集中在兩個領(lǐng)域：問題分析和產(chǎn)品描述。問題分析活動分準(zhǔn)備、采集需 求和分析等，而產(chǎn)品描述活動分準(zhǔn)備SRS和評審SRS等。目標(biāo)生成一個正確說明客戶所有需求的文檔適用標(biāo)準(zhǔn)和規(guī) 范需求分析規(guī)程需求管理規(guī)程相關(guān)工具文件編輯工具：MS Word客戶需求分析工具：如ROSE、MS Visio主要輸入初始的客戶需求 分配的軟件系統(tǒng)需求入口準(zhǔn)則項目已經(jīng)立項并得到批準(zhǔn)參與需求分析的人員接受過相關(guān)技

9、能的培訓(xùn)活動一、獲取用戶需求1、確定需求的獲取方法2、進(jìn)行需求調(diào)研，獲取用戶需求，收集共利益者的需要、期望、限制條件和接 口，并且把他們轉(zhuǎn)換成顧客需求。3、確定是否需要開發(fā)原型4、文檔化用戶需求規(guī)格說明書5、評審用戶需求規(guī)格說明書6、建立需求庫、需求跟蹤矩陣二、分析需求1、分析用戶需求和利益相關(guān)者的需求2、文檔化軟件需求規(guī)格說明書3、評審軟件需求規(guī)格說明書4、維護(hù)需求跟蹤矩陣5、編制測試計劃、系統(tǒng)測試用例6、 將用戶需求規(guī)格說明書、軟件需求規(guī)格說明書、需求跟蹤矩陣形成需求基線，測試計劃、系統(tǒng)測試用例入配置庫7、根據(jù)項目監(jiān)控的情況，修正項目計劃主要輸出用戶需求規(guī)格說明書 軟件需求規(guī)格說明書 測試

10、計劃系統(tǒng)測試用例出口準(zhǔn)則用戶需求規(guī)格說明書、軟件需求規(guī)格說明書通過評審、所有發(fā)現(xiàn)的問題都 得到處理，并置于配置管理之下。評審覆蓋率100%錯誤發(fā)現(xiàn)率不得低于 5-15個/100頁，修復(fù)率100%;度量參見度量和分析規(guī)程約束需求階段：時間跨度比例為整個項目周期的10-25%,工作量占總工作量 5-20%角色職責(zé)中層經(jīng)理（部門經(jīng)理）參與評審項目經(jīng)理組織編寫需求文檔并參與評審需求工程師負(fù)責(zé)撰寫用戶需求規(guī)格說明書、軟件需求規(guī)格說明書、建立需求跟蹤矩陣，參與評審測試經(jīng)理根據(jù)軟件需求規(guī)格說明書撰寫系統(tǒng)測試大綱，參與評審PPQA工程師檢查軟件需求規(guī)格說明書、系統(tǒng)測試大綱、需求跟蹤矩陣的符合性，評 審活動的符

11、合性變更控制委員 會負(fù)責(zé)主持評審，并批準(zhǔn)需求基線的建立度量工程師參與里程碑評審活動； 記錄、度量和分析過程活動中產(chǎn)生的度量數(shù)據(jù)。配置工程師建立需求基線，負(fù)責(zé)將評審?fù)ㄟ^的 軟件需求規(guī)格說明書、系統(tǒng)測試大綱、需 求跟蹤矩陣入配置管理技術(shù)專豕 開發(fā)工程師 其他有關(guān)人員參與評審設(shè)計階段概要設(shè)計階段是從實現(xiàn)的角度開發(fā)針對客戶需求的解決方案，完成軟件的架構(gòu)設(shè)計和數(shù)據(jù)庫設(shè)計，詳 細(xì)設(shè)計是從架構(gòu)設(shè)計和數(shù)據(jù)庫設(shè)計入手，完成模塊的詳細(xì)設(shè)計或界面設(shè)計。目標(biāo)從實現(xiàn)的角度開發(fā)針對客戶需求的技術(shù)解決方案適用標(biāo)準(zhǔn)和規(guī) 范概要設(shè)計規(guī)程詳細(xì)設(shè)計規(guī)程相關(guān)工具文件編輯工具：MS Word、EXCEL、PowerPoint 等軟件設(shè)

12、計工具：如 ROSE、MS Visio主要輸入軟件需求規(guī)格說明書系統(tǒng)解決方案說明書（可裁減）入口準(zhǔn)則軟件需求規(guī)格說明書、系統(tǒng)解決方案說明書（可裁減）已經(jīng)通過評審，并且軟件需求和需求跟蹤矩陣已經(jīng)基線化。、概要設(shè)計1、確定設(shè)計準(zhǔn)則；2、設(shè)計產(chǎn)品和產(chǎn)品構(gòu)件。包括：總體設(shè)計、功能設(shè)計、邏輯模型設(shè)計、過程模 型設(shè)計、數(shù)據(jù)模型（數(shù)據(jù)庫）設(shè)計、實現(xiàn)模型設(shè)計、部署模型設(shè)計、用戶接 口（界面）設(shè)計、錯誤處理設(shè)計等；3、將設(shè)計文檔化，編寫概要設(shè)計說明書；4、確認(rèn)設(shè)計，評審概要設(shè)計說明書；5、根據(jù)概要設(shè)計，設(shè)計集成測試用例和用戶操作手冊；6、維護(hù)需求跟蹤矩陣；7、概要設(shè)計說明書、需求跟蹤矩陣形成設(shè)計基線，并入配置庫

13、；活動8、根據(jù)項目監(jiān)控的情況，修正項目計劃。、詳細(xì)設(shè)計1、根據(jù)概要設(shè)計說明書細(xì)化模塊功能、用戶接口（界面），并細(xì)化功能模塊的數(shù)據(jù)結(jié)構(gòu)和算法，完善重用軟件和單元的算法和處理流程；2、將設(shè)計文檔化，編寫詳細(xì)設(shè)計說明書；3、根據(jù)詳細(xì)設(shè)計，完善用戶操作手冊，設(shè)計單兀測試用例；4、確認(rèn)設(shè)計，評審詳細(xì)設(shè)計說明書；5、維護(hù)需求跟蹤矩陣；6、詳細(xì)設(shè)計說明書、需求跟蹤矩陣形成設(shè)計基線，并入配置庫；7、根據(jù)項目監(jiān)控的情況，修正項目計劃。概要設(shè)計說明書數(shù)據(jù)庫設(shè)計說明書（可裁減）集成測試用例主要輸出詳細(xì)設(shè)計說明書用戶操作手冊 單元測試用例評審報告概要設(shè)計說明書、數(shù)據(jù)庫設(shè)計說明書（可裁減）、詳細(xì)設(shè)計說明書得到 評審和批

14、準(zhǔn)并置于配置管理之下出口準(zhǔn)則評審覆蓋率100%錯誤發(fā)現(xiàn)率不得低于 5-15個/100頁修復(fù)率100%度量參見度量和分析規(guī)程約束設(shè)計投入的時間跨度占項目周期比例20-50%,工作量占20-50%角色職責(zé)中層經(jīng)理（部門經(jīng)理）參與評審，協(xié)調(diào)資源配置項目經(jīng)理負(fù)責(zé)組織編寫設(shè)計文檔并參與評審開發(fā)工程師承擔(dān)產(chǎn)品設(shè)計并編寫設(shè)計文檔并參與評審，建立需求跟蹤矩陣測試工程師根據(jù)測試計劃測試大綱編寫接口測試用例，參與評審PPQA工程師檢查設(shè)計文檔、需求跟蹤矩陣、項目計劃的符合性，評審活動的符合性變更控制委員 會負(fù)責(zé)主持評審，并批準(zhǔn)需求基線的建立度里工程師參與里程碑評審活動； 記錄、度量和分析過程活動中產(chǎn)生的度量數(shù)據(jù)。

15、配置工程師建立設(shè)計基線，負(fù)責(zé)將評審?fù)ㄟ^的概要設(shè)計說明書、詳細(xì)設(shè)計說明書、集成測試綱、需求跟蹤矩陣入配置管理技術(shù)專豕 開發(fā)工程師 其他有關(guān)人員參與評審編碼階段在實現(xiàn)階段，根據(jù)詳細(xì)設(shè)計用編程語言和合適的編碼規(guī)范產(chǎn)生源代碼、可執(zhí)行代碼和數(shù)據(jù)庫，并將產(chǎn) 生的代碼按照一定的集成準(zhǔn)則組裝在一起。這個階段的輸出是隨后測試和驗證的主體。目標(biāo)根據(jù)詳細(xì)設(shè)計用編程語言和合適的編碼規(guī)范產(chǎn)生正確的源代碼適用標(biāo)準(zhǔn)和規(guī) 范編碼和單兀測試規(guī)程 單兀測試規(guī)程、走查規(guī)程相關(guān)工具相關(guān)語言的基礎(chǔ)開發(fā)環(huán)境主要輸入概要設(shè)計說明書、數(shù)據(jù)庫設(shè)計說明書、詳細(xì)設(shè)計說明書、單兀測試用 例、項目計劃、需求跟蹤矩陣入口準(zhǔn)則設(shè)計文檔已通過評審，設(shè)計基線

16、已經(jīng)建立活動1、確定編碼規(guī)則和編程環(huán)境；2、編碼、走杳和單兀測試。3、對已經(jīng)通過單元測試的代碼，根據(jù)設(shè)計的要求，按照產(chǎn)品集成規(guī)程進(jìn) 行模塊級的集成；4、編寫模塊開發(fā)說明書；5、維護(hù)需求跟蹤矩陣；6、單元測試用例形成基線，并入配置庫；7、 根據(jù)項目監(jiān)控的情況，修正項目計劃；主要輸出源程序文件可執(zhí)行代碼代碼走查報告和評審記錄 單元測試記錄和測試報告用戶操作手冊單元測試用例出口準(zhǔn)則代碼成功執(zhí)行所有單元測試計劃中的測試用例； 所有代碼完成單元測試并集成到模塊一級； 走查覆蓋率30%，單元測試語句覆蓋率 100%;單元測試缺陷發(fā)現(xiàn)率：5-10個/千行，代碼走查缺陷發(fā)現(xiàn)率 ：5-10個/千行； 缺陷修復(fù)率

17、：100%度量參見度量和分析規(guī)程約束編碼投入的時間占項目比例20-50%,工作量占20-50%。角色職責(zé)項目經(jīng)理監(jiān)控項目的進(jìn)度，協(xié)調(diào)計劃和資源，必要時參與項目開發(fā)工作開發(fā)工程師編碼；代碼走查；細(xì)化單元測試用例并相互測試； 記錄并編寫走查、單元測試報告。PPQA工程師以抽查方式檢查代碼的規(guī)范性、檢查走查和單兀測試活動的規(guī)范性度里人貝參與里程碑評審活動； 記錄、度量和分析過程活動中產(chǎn)生的度量數(shù)據(jù)。配置工程師為下一步的測試和集成建立基線，將已經(jīng)通過單兀測試的模塊及其單兀測試 用例入基線管理，需求跟蹤矩陣入配置管理。技術(shù)專豕參與走查其他人員測試階段軟件集成是把設(shè)計階段制定的，已通過單元測試的模塊構(gòu)建成

18、一個完整的軟件結(jié)構(gòu)的系統(tǒng)方法。在該 階段，同時要進(jìn)行集成測試，以發(fā)現(xiàn)和接口相關(guān)的缺陷。集成按集成計劃中制定的順序進(jìn)行，并執(zhí)行每個 集成階段的相應(yīng)測試用例。系統(tǒng)測試是依據(jù)需求規(guī)格說明書驗證軟件產(chǎn)品有效性的活動。目標(biāo)進(jìn)行集成和集成測試，以發(fā)現(xiàn)和接口相關(guān)的缺陷。 進(jìn)行系統(tǒng)測試，以發(fā)現(xiàn)系統(tǒng)與需求不符合的情況。適用標(biāo)準(zhǔn)和規(guī) 范軟件集成測試規(guī)程軟件系統(tǒng)測試規(guī)程、產(chǎn)品標(biāo)準(zhǔn)（包括國家和行業(yè)標(biāo)準(zhǔn)） 軟件測試停止標(biāo)準(zhǔn) 軟件缺陷分類標(biāo)準(zhǔn) 軟件測試設(shè)計規(guī)程 軟件缺陷 管理規(guī)程軟件測試規(guī)程相關(guān)工具Test Director 或 Rational Test 等主要輸入軟件需求規(guī)格說明書 概要設(shè)計說明書需求跟蹤矩陣集成測試

19、用例系統(tǒng)測試用例可執(zhí)行代碼入口準(zhǔn)則被集成的模塊已經(jīng)通過單元測試活動一、集成和集成測試1、確疋集成準(zhǔn)則、制疋集成計劃、元善測試計劃；2、完善集成測試用例并通過評審；3、搭建測試環(huán)境；4、檢查集成環(huán)境、檢查集成產(chǎn)品接口、集成產(chǎn)品模塊及其版本的正確性；5、編譯和組裝待測版本代碼；6、 執(zhí)行測試用例，記錄測試結(jié)果，編寫測試報告，直至集成測試通過；7、對測試進(jìn)行評估，檢驗測試結(jié)果是否達(dá)到測試出口標(biāo)準(zhǔn)或中止標(biāo)準(zhǔn)；8、內(nèi)部發(fā)布（如通知相關(guān)人員）通過集成測試的項目階段代碼小版本，等待 進(jìn)入下一階段測試；9、比較、分析測試的實際與預(yù)期結(jié)果，形成測試總結(jié)提交評審；10、 測試通過的代碼和構(gòu)件入基線管理，測試記錄、

20、測試報告和測試 總結(jié)入配置管理庫。二、系統(tǒng)測試1、依據(jù)測試計劃，搭建符合條件的測試環(huán)境；2、檢查版本的正確性后；3、執(zhí)行測試對鎖定版本按測試計劃執(zhí)行測試用例，直至系統(tǒng)測試通過；系統(tǒng)測試的最后階段還應(yīng)包括對配置庫文檔的測試。采用需求跟蹤矩 陣表、用戶手冊等文檔對配置庫中的工作產(chǎn)品進(jìn)行測試，如描述不正 確或未及時更新的文檔（如需求規(guī)格說明書等），發(fā)現(xiàn)并跟蹤其解決情況直到滿足需求、計劃要求。4、評估測試：項目經(jīng)理及測試經(jīng)理定期對系統(tǒng)測試質(zhì)量及效果、進(jìn)度情況進(jìn) 行評估，確定測試覆蓋完整性，檢驗測試結(jié)果是否達(dá)到測試出口準(zhǔn)則或停 止準(zhǔn)則。5、發(fā)布版本：內(nèi)部發(fā)布通過了系統(tǒng)測試的項目代碼小版本，直至項目最終完

21、 整版本發(fā)布。6、測試總結(jié)：測試負(fù)責(zé)人負(fù)責(zé)匯總、分析測試結(jié)果，形成測試總結(jié)提交 評審。主要輸出集成計劃和測試用例 集成后的完整軟件產(chǎn)品測試記錄測試總結(jié)出口準(zhǔn)則成功地執(zhí)行了集成測試和系統(tǒng)測試計劃中的所有測試用例 測試發(fā)現(xiàn)的缺陷按軟件測試停止標(biāo)準(zhǔn)執(zhí)行度量參見度量和分析規(guī)程約束測試投入的時間占項目比例10-30%，測試工程師工作量占 10-15%， 項目組工作量占10%以內(nèi)。角色職責(zé)中層經(jīng)理（事業(yè)部經(jīng)理）參與評審，協(xié)調(diào)資源配置項目經(jīng)理監(jiān)控項目的進(jìn)度，協(xié)調(diào)計劃和資源軟件工程師配合測試，修復(fù)發(fā)現(xiàn)的問題測試工程師進(jìn)行測試、撰寫測試報告PPQA工程師檢查測試活動的規(guī)范性度量工程師測試發(fā)現(xiàn)的缺陷數(shù)和密度、本階

22、段所用的時間和工作量配置工程師負(fù)責(zé)將評審?fù)ㄟ^的集成后的完整軟件產(chǎn)品、集成測試和系統(tǒng)測試報告入配置管理庫管理實施階段在實施和驗收階段，軟件產(chǎn)品將被集成到用戶的業(yè)務(wù)操作環(huán)境中，并在這個環(huán)境中運行，以確保它按 需求執(zhí)行。這個階段包括兩個基本任務(wù)：使軟件得以驗收和在客戶處安裝。驗收指的是用戶根據(jù)早期準(zhǔn)備的驗收測試計劃而進(jìn)行正式的測試，并對測試結(jié)果進(jìn)行分析，以確定系統(tǒng)是否滿足驗收準(zhǔn)則。當(dāng)分析結(jié)果 滿足驗收準(zhǔn)則時，用戶接受軟件。安裝指的是把接受的軟件置于實際的產(chǎn)品環(huán)境中。目標(biāo)軟件通過驗收，安裝系統(tǒng)使其上線運行。適用標(biāo)準(zhǔn)和規(guī) 范實施規(guī)程驗收規(guī)程相關(guān)工具無主要輸入系統(tǒng)測試后的軟件產(chǎn)品安裝手冊、用戶手冊、維護(hù)手

23、冊、用戶二次開發(fā)接口手冊入口準(zhǔn)則軟件產(chǎn)品通過了系統(tǒng)測試活動一、安裝實施1、制定實施計劃2、編寫安裝手冊3、確認(rèn)系統(tǒng)安裝運行的環(huán)境滿足要求4、執(zhí)行安裝，填寫產(chǎn)品安裝報告5、按用戶業(yè)務(wù)模型準(zhǔn)備實施數(shù)據(jù)并實施6、實施計劃和初始化數(shù)據(jù)入基線管理二、驗收1、制定驗收計劃2、 準(zhǔn)備驗收材料（如果需要用戶應(yīng)提交試運行報告）3、如果需要演示，搭建演示環(huán)境，并演示4、按計劃執(zhí)行驗收評審5、 驗收計劃入基線管理，試運行報告、評審結(jié)論入配置管理主要輸出實施計劃安裝手冊產(chǎn)品安裝報告 驗收計劃試運行報告評審結(jié)論驗收報告 安裝后的軟件系統(tǒng)出口準(zhǔn)則客戶在驗收報告上簽字、軟件在業(yè)務(wù)環(huán)境中正常運行，顧客的需求得到實現(xiàn)。度量參見

24、度量和分析規(guī)程約束顧客提出的，如：環(huán)境、性能指標(biāo)和質(zhì)量指標(biāo)等。角色職責(zé)項目經(jīng)理監(jiān)控項目的進(jìn)度，協(xié)調(diào)計劃和資源，撰寫驗收計劃實施人員確認(rèn)系統(tǒng)安裝運行的環(huán)境滿足要求、執(zhí)行安裝調(diào)試運行及維護(hù)客戶參與驗收過程，驗收報告上簽字PPQA檢查交付給客戶的內(nèi)容是否符合文檔規(guī)范性度量工程師測試發(fā)現(xiàn)的缺陷數(shù)和密度、本階段所用的時間和工作量配置工程師負(fù)責(zé)將評審?fù)ㄟ^的集成后的完整軟件產(chǎn)品、集成測試和系統(tǒng)測試報告入配置管理庫管理維護(hù)階段在維護(hù)階段，軟件產(chǎn)品已經(jīng)安裝到用戶的業(yè)務(wù)操作環(huán)境中，并已經(jīng)在這個環(huán)境中正常運行。維護(hù)階段 的目標(biāo)是：持續(xù)地確保軟件在業(yè)務(wù)環(huán)境中正常地運行；進(jìn)一步收集和發(fā)現(xiàn)產(chǎn)品運行過程中的各種問題、用戶的

25、意見和改進(jìn)建議， 為產(chǎn)品的完善提供依據(jù);產(chǎn)品維護(hù)活動是持續(xù)不斷進(jìn)行的，直至軟件生命周期的結(jié)束。目標(biāo)確保產(chǎn)品在業(yè)務(wù)環(huán)境中正常地運行。適用標(biāo)準(zhǔn)和規(guī) 范產(chǎn)品維護(hù)規(guī)程相關(guān)工具無主要輸入用戶驗收后的運行系統(tǒng)、驗收報告、合同維護(hù)條款入口準(zhǔn)則系統(tǒng)已經(jīng)通過客戶驗收參與人員和相 關(guān)人員項目經(jīng)理、實施工程師、客戶活動1、確保軟件在業(yè)務(wù)環(huán)境中的正常運行，對因?qū)嵤┮鸬膯栴}由實施人員及時修正；對軟件內(nèi)部BUG,按照測試規(guī)程的要求進(jìn)行記錄缺陷及跟蹤報告；2、 收集用戶對產(chǎn)品的意見和建議，填寫產(chǎn)品維護(hù)記錄；3、分析收集和記錄的 BUG、用戶的意見和建議，提交項目經(jīng)理。4、 按BUG嚴(yán)重程度和修改優(yōu)先級的規(guī)定，項目經(jīng)理確定

26、是否修訂BUG ；5、根據(jù)不斷收集和分析的結(jié)果，項目經(jīng)理提出改進(jìn)建議，并得到批準(zhǔn)，進(jìn)行 必要的修訂、開發(fā)等活動，使產(chǎn)品不斷得到完善。6、產(chǎn)品維護(hù)負(fù)責(zé)人應(yīng)定期（通常一個維護(hù)周期為一年）將過程中的所有配置項提交項目經(jīng)理入配置庫，編寫產(chǎn)品維護(hù)總結(jié)報告。主要輸出缺陷及跟蹤報告產(chǎn)品維護(hù)記錄產(chǎn)品維護(hù)報告發(fā)生變更的需求跟蹤矩陣 修訂、開發(fā)的軟件代碼 其它相關(guān)的評審文件和記錄等出口準(zhǔn)則客戶提出的問題已經(jīng)得到解決或和客戶達(dá)成一致協(xié)定。 軟件生命周期結(jié)束，或維護(hù)期滿，完成維護(hù)任務(wù)；度量度量維護(hù)的工作量和成本，【整個維護(hù)期間的缺陷密度】約束【主要是來自組織內(nèi)部：如期限、工作量投入等】裁剪指南在實際的使用過程中，根據(jù)

27、軟件項目的特點可以對瀑布模型進(jìn)行裁剪。一般而言，以下幾種裁剪是經(jīng) 常存在的，只要PPQA工程師同意即可：1. 項目策劃階段并入需求分析階段。前提是該階段前期，制定一個粗略的項目整體計劃和當(dāng)前階段 的詳細(xì)計劃，并且在該階段后期，制定出相對比較實用的項目整體計劃。2. 需求分析階段可以根據(jù)項目的實際情況，將用戶需求規(guī)格說明書和軟件需求規(guī)格說明書 合并為需求規(guī)格說明書。3. 根據(jù)項目的人員配置情況，在有替代的活動來驗證相應(yīng)工作產(chǎn)品的可測試性時，測試計劃和測試 用例的編制時間可以適當(dāng)?shù)暮笱?。不過，必須確保測試計劃和測試用例經(jīng)過有效的評審以后，才 可以開始實際的測試活動。4. 在項目策劃階段，項目經(jīng)理確

28、認(rèn)此項目不需新的代碼開發(fā)，可跳過設(shè)計和編碼階段，直接進(jìn)入實 施和驗收階段，此類項目類似現(xiàn)用產(chǎn)品的實施項目。根據(jù)項目需要，在經(jīng) EPG 審核并獲得高層經(jīng)理的批準(zhǔn)下，也可對瀑布模型做出其他方式的裁剪。4.1.9 瀑布模型的特點瀑布模型的特點是： 當(dāng)有一個穩(wěn)定的產(chǎn)品需求定義和很容易被理解的技術(shù)解決方案時， 該模型可通過階段評審以幫助 項目組及早地發(fā)現(xiàn)問題及缺陷，而不至于將問題及缺陷帶入下游，從而避免發(fā)生更大的錯誤，避 免花更多的時間去糾正； 當(dāng)要對一個定義得很好的版本進(jìn)行維護(hù)或?qū)⒁粋€產(chǎn)品移植到一個新的平臺上， 瀑布模型是一個恰 當(dāng)?shù)倪x擇； 當(dāng)團(tuán)隊技能比較弱或者缺乏經(jīng)驗的時候，瀑布模型提供了清晰的開發(fā)

29、模式，并方便管理； 當(dāng)質(zhì)量要求高于成本和進(jìn)度要求時，它表現(xiàn)得尤為出色。瀑布模型的缺點是： 瀑布模型是一種理想化的線性模型，不能適用需求的變化，無法克服變化引發(fā)的問題。如果上一 步做錯了，下一步也會跟著錯，直到產(chǎn)品做完了才發(fā)現(xiàn)需求的遺漏和錯誤，只好從頭到尾進(jìn)行修 改，這樣逆流而上解決問題是非常困難的；開發(fā)人員常常陷入“阻塞狀態(tài)” ，一部分組員不得不停下來等待別人把前頭的任務(wù)完成； 該模型是在項目全部完成后一次性向客戶交付產(chǎn)品，而不能分階段的交付可運行產(chǎn)品，不能滿足 急著使用產(chǎn)品的用戶，而會引起用戶的不滿。4.2 迭代模型 迭代模型是典型地應(yīng)用于開發(fā)一個沒有完整定義的產(chǎn)品以及需求更快地被開發(fā)和創(chuàng)建

30、一個能展示產(chǎn) 品外貌和功能的最初版本時，但它也可以用于開發(fā)已知需求和定義的產(chǎn)品。迭代是一種工作流的步驟，當(dāng) 需求被更好地理解并且產(chǎn)品被進(jìn)一步定義時， 產(chǎn)品的下一個迭代就產(chǎn)生了。 每個迭代都是下個迭代的基礎(chǔ)。 每一次迭代過程的開發(fā)都是一個瀑布模型。迭代次數(shù)由項目經(jīng)理根據(jù)具體情況定義。組織級迭代模型主要包括兩類：迭代模型一 . 迭代被分為若干個階段，每個階段都是一個完整的瀑布模型； 迭代模型二 . 迭代被分為三個主要的階段：初始階段、構(gòu)建階段和系統(tǒng)提交階段。4.2.1 迭代模型一 此類型迭代可以用于開發(fā)一個沒有完整定義的產(chǎn)品，或者用于用戶需求不明確，需要不斷開發(fā)用戶需 求的項目，也可以用于開發(fā)已知

31、需求和定義的產(chǎn)品。其過程如下圖需求分析設(shè)計實現(xiàn)測試實施項目策劃維護(hù)需求分析設(shè)計實現(xiàn)實施項目策劃.丿測試丿項目策劃設(shè)計測試實施需求分析. .丿實現(xiàn)丿每一次的迭代都可以根據(jù)實際情況對瀑布模型進(jìn)行裁減，以便更快地開發(fā)用戶需求。422迭代模型二此類型迭代主要用于開發(fā)一個沒有完整定義的產(chǎn)品，或者用于用戶需求不明確，需要不斷開發(fā)用戶需 求的項目。每一次的迭代都可以根據(jù)實際情況對瀑布模型進(jìn)行裁減。其開發(fā)流程圖如下：初始階段構(gòu)建階段提交階段4.2.2.1初始階段項目初始階段的主要任務(wù)是根據(jù)用戶業(yè)務(wù)領(lǐng)域模型構(gòu)思未來系統(tǒng)的概貌，確定和評估項目的可行性。確定項目目標(biāo)、估計未來系統(tǒng)的范圍和規(guī)模，以及項目中應(yīng)包含的內(nèi)容，分析和確定開發(fā)方法和技術(shù)措施,以及預(yù)期的開發(fā)風(fēng)險等，并且估計項目需要的資源（人財物）。通過分析用戶業(yè)務(wù)領(lǐng)域問題，建立系統(tǒng)的基本架構(gòu)，找出可能的開發(fā)風(fēng)險的應(yīng)對措施，確定資金和資 源的分配，制定系統(tǒng)的開發(fā)計劃。初始階段可以包括幾個迭代，并開發(fā)出初始的原型，以便開發(fā)用戶需求。在這個階段的側(cè)重點是制定 項