軟件生命周期指南

1、版本1.0軟件生命周期指南第1頁/共12頁版本1.0軟件生命周期指南文檔編號:日期:第#頁/共12頁版本1.0軟件生命周期指南第#頁/共12頁版本1.0軟件生命周期指南軟件生命周期指南丄、F亠一1刖言軟件生命周期是指軟件產(chǎn)品或軟件系統(tǒng)從產(chǎn)生、投入使用到被淘汰的全過程。在計算機技術(shù)發(fā)展的初期，人們把軟件開發(fā)簡單地理解為編寫程序。隨著軟件復(fù)雜性的增長， 人們認識到軟件開發(fā)活動應(yīng)劃分為需求分析、設(shè)計、實現(xiàn)、測試等若干個活動，并將這些活動以適當?shù)姆绞椒峙涞讲煌碾A段中去完成。軟件生命周期模型是描述軟件開發(fā)全部過程、活動和任務(wù)的結(jié)構(gòu)框架。比較常見的軟件生命周期模型是瀑布模型、增量模型、原型模型和螺旋模型

2、等。1.1目的和適用范圍本文檔規(guī)定了 組織適用的軟件生命周期模型，作為項目經(jīng)理在制定項目計劃時根據(jù) 項目需求、復(fù)雜程度、進度要求等項目特點確定采用何種開發(fā)過程的依據(jù)。如果確定的生命周期模型不在本文檔中規(guī)定的范圍內(nèi)，必須經(jīng)過SEPG和高層經(jīng)理的審批才能使用。本文檔適用于 組織的所有軟件項目。1.2縮略語SPPSPTO軟件項目計劃軟件項目跟蹤和監(jiān)控SQA軟件質(zhì)量保證SCM軟件配置管理SOW工作說明書WBS工作分解結(jié)構(gòu)SRS軟件需求規(guī)格說明書1.3參考文獻CMM 1.1。2瀑布模型瀑布模型是最常用的軟件開發(fā)模型，它的各個階段是按線性序列組織的。開發(fā)過程中的階段劃分為項目策劃、需求分析、概要設(shè)計、詳細

3、設(shè)計、編碼和單元測試、軟件集成和集成 測試、系統(tǒng)測試、驗收和安裝等（圖i）。盡管開發(fā)過程中定義了各個階段的順序，但這些階段有時是相互交迭進行的，階段間的依賴性由入口準則來確定。驗收和安裝 系統(tǒng)測試.軟件集成 編碼和單和集成測試概要設(shè)計丨需求分析項目策劃詳細設(shè)計元測試圖1瀑布模型瀑布模型的每個階段均具有以下特征：從上一階段接受本階段工作的對象，作為輸入； 對上述輸入實施本階段的活動；給出本階段的工作成果，作為輸出傳入下一階段； 對本階段工作進行評審，如果本階段工作得到確認，那么繼續(xù)下階段工作，否則返 回前一階段，甚至更前階段。瀑布模型為軟件開發(fā)與維護提供了一種有效的管理模式，根據(jù)這一管理模式制訂

4、開發(fā)計劃、進行成本預(yù)算、組織開發(fā)人員，以階段評審和文檔控制為手段有效地對整個開發(fā)過程進 行指導(dǎo)，從而保證了軟件產(chǎn)品的質(zhì)量。優(yōu)點：近30年來之所以廣為流行，是因為它在支持開發(fā)結(jié)構(gòu)化軟件、控制軟件的 開發(fā)復(fù)雜度、促進軟件開發(fā)工程化方面起著顯著作用。缺點：缺乏靈活性，無法通過開發(fā)活動澄清本來不夠確切的軟件需求。這些問題可能導(dǎo)致開發(fā)出的軟件并不是用戶真正需要的軟件，并且這一點在開發(fā)過程完成后才有所察覺。2.1項目策劃項目策劃是每個項目的初始階段，目的是為開發(fā)過程和過程管理做好必要的準備。項目策劃的主要工作是進行可行性分析和研究，進行估計和制定管理項目的計劃。主要輸入項目任務(wù)書、建議書或工作說明書（SO

5、W客戶需求/需要入口準則客戶需求/需要已被批準項目任務(wù)書、建議書或 sow已被批準項目經(jīng)理和相關(guān)人員已經(jīng)到位參與項目準備和策劃的人員接受過相關(guān)技能的培訓(xùn)角色與職 責高層經(jīng)理、項目經(jīng)理、 SQA和SCM工程師、測試人員、客戶或 客戶代表、項目組主要成員、領(lǐng)域?qū)＜?。項目?yīng)根據(jù)具體情況，列出每個角色的職責活動1、可行性分析和研究2、構(gòu)建WBS3、估計項目的規(guī)模、工作量、成本和CCR等4、標識和分析風險5、計劃資源及其獲取方式6、制定項目進度和預(yù)算7、編制項目計劃8、計劃驗收測試9、建立需求跟蹤矩陣10、評審和批準項目計劃和驗收計劃主要輸出WBS估計記錄風險分析表和風險評估報告軟件項目計劃，包括軟件開

6、發(fā)計劃、SQA十劃、SCM十劃等驗收計劃需求跟蹤矩陣出口準則項目約定和計劃得到受影響的組和個人的認可軟件項目計劃和驗收計劃已被批準并置于配置管理之下度量項目策劃所花的工作量和資金，評審工作量和返工工作量可應(yīng)用的 標準和規(guī) 范根據(jù)項目情況列出本階段應(yīng)該遵循的過程和產(chǎn)品的標準和規(guī)范可應(yīng)用的 規(guī)程、方 法、工具和 資源根據(jù)項目情況列出本階段其它可應(yīng)用的規(guī)程、方法、工具和資源2.2需求分析需求分析階段的主要目的是生成一個正確說明客戶所有需求的文檔。軟件需求規(guī)格說明書（SRS）是該階段的主要輸出。需求分析的主要工作是需求提煉及分析、需求歸檔和需求 評審等。需求分析階段執(zhí)行的活動主要集中在兩個領(lǐng)域：問題分

7、析和產(chǎn)品描述。問題分析活動分準備、采集需求和分析等，而產(chǎn)品描述活動分準備SRS和評審SRS等。主要輸入客戶需求/需要入口準則項目計劃得到評審和批準項目策劃階段已經(jīng)結(jié)束參與需求分析的人貝接受過相關(guān)技能的培訓(xùn)角色與職 責高層經(jīng)理、項目經(jīng)理、需求分析師、測試人員、SQA、SCM、客戶或客戶代表、領(lǐng)域?qū)ｕ购图夹g(shù)專豕。項目應(yīng)根據(jù)具體情況，列出每個角色的職責活動1、準備需求采集和分析2、采集和分析需求3、準備SRS4、細化需求跟蹤矩陣5、計劃系統(tǒng)測試6、評審SRS系統(tǒng)測試計劃和測試用例、需求跟蹤矩陣主要輸出SRS需求跟蹤矩陣系統(tǒng)測試計劃和測試用例出口準則SRS、系統(tǒng)測試計劃和測試用例、需求跟蹤矩陣得到評審

8、和批準 并置于配置管理之下度量需求分析所花的工作量和資金，評審工作量和返工工作量可應(yīng)用的 標準和規(guī) 范根據(jù)項目情況列出本階段應(yīng)該遵循的過程和產(chǎn)品的標準和規(guī)范可應(yīng)用的 規(guī)程、方 法、工具和 資源根據(jù)項目情況列出本階段其它可應(yīng)用的規(guī)程、方法、工具和資源2.3概要設(shè)計概要設(shè)計階段是從實現(xiàn)的角度開發(fā)針對客戶需求的解決方案。在這個階段給出的是高級的抽象方案，這個方案包含兩個主要部分，即應(yīng)用的功能體系結(jié)構(gòu)和數(shù)據(jù)庫設(shè)計。主要輸入SRS入口準則SRS已經(jīng)過評審和批準角色與職 責項目經(jīng)理、設(shè)計人員、測試人員、客戶或客戶代表、SQA、SCM項目應(yīng)根據(jù)具體情況，列出每個角色的職責活動1、定義標準（編碼、文檔、用戶接

9、口等）2、進行功能設(shè)計3、開發(fā)物理數(shù)據(jù)庫設(shè)計4、編寫概要設(shè)計文檔5、計劃集成測試6、評審概要設(shè)計文檔、集成測試計劃和測試用例主要輸出概要設(shè)計文檔項目標準集成測試計劃和測試用例出口準則概要設(shè)計文檔、集成測試計劃和測試用例得到評審和批準并置于 配置管理之下度量概要設(shè)計工作量、概要設(shè)計缺陷、評審工作量和返工工作量可應(yīng)用的 標準和規(guī) 范根據(jù)項目情況列出本階段應(yīng)該遵循的過程和產(chǎn)品的標準和規(guī)范可應(yīng)用的 規(guī)程、方 法、工具和 資源根據(jù)項目情況列出本階段其它可應(yīng)用的規(guī)程、方法、工具和資源2.4詳細設(shè)計在詳細設(shè)計階段，概要設(shè)計階段開發(fā)的整體應(yīng)用被分成幾個模塊和程序。為每個程序進行邏輯設(shè)計，然后歸檔作為程序規(guī)格。

10、同時，為每個程序生成一個單元測試計劃。詳細設(shè)計階段的活動包括通用例程和程序的確定（如數(shù)據(jù)有效性例程、框架程序的開發(fā)及用于提高生產(chǎn)率的實用程序和工具的開發(fā)）。主要輸入概要設(shè)計文檔入口準則概要設(shè)計文檔經(jīng)過評審和授權(quán)角色與職 責項目經(jīng)理、設(shè)計人員、測試人員、 SQA、SCM 項目應(yīng)根據(jù)具體情況，列出每個角色的職責 活動1、將功能分成小的構(gòu)件2、設(shè)計/開發(fā)代碼框架3、開發(fā)例程和工具4、進行程序設(shè)計5、編寫詳細設(shè)計文檔6、計劃單元測試7、評審詳細設(shè)計文檔、單元測試計劃和測試用例主要輸出詳細設(shè)計文檔 單元測試計劃和測試用例出口準則詳細設(shè)計文檔、單兀測試計劃和測試用例得到評審和批準并置于 配置管理之下度量詳

11、細設(shè)計工作量、詳細設(shè)計缺陷、單元測試缺陷、程序框架缺陷 以及評審和返工工作量可應(yīng)用的標準和規(guī)范根據(jù)項目情況列出本階段應(yīng)該遵循的過程和產(chǎn)品的標準和規(guī)范可應(yīng)用的 規(guī)程、方 法、工具和 資源根據(jù)項目情況列出本階段其它可應(yīng)用的規(guī)程、方法、工具和資源2.5編碼和單元測試在編碼階段，根據(jù)詳細設(shè)計用編程語言和合適的編碼規(guī)范產(chǎn)生源代碼、可執(zhí)行代碼和數(shù)據(jù)庫。這個階段的輸出是隨后測試和驗證的主體。主要輸入詳細設(shè)計文檔、項目標準、單元測試計劃和測試用例入口準則詳細設(shè)計文檔經(jīng)過評審和授權(quán)角色與職 責項目經(jīng)理、開發(fā)人員、測試人員項目應(yīng)根據(jù)具體情況，列出每個角色的職責活動1、生成測試數(shù)據(jù)庫2、對程序進行編碼3、代碼評審4

12、、記錄和修正缺陷5、代碼自測6、進行獨立的單元測試主要輸出測試數(shù)據(jù)可執(zhí)行代碼代碼評審報告/評審記錄獨立的單元測試報告和評審記錄出口準則成功執(zhí)行所有單元測試計劃中的測試用例度量編碼和單元測試的工作量、代碼評審缺陷、獨立的單元測試缺陷 以及評審和返工工作量可應(yīng)用的 標準和規(guī) 范根據(jù)項目情況列出本階段應(yīng)該遵循的過程和產(chǎn)品的標準和規(guī)范可應(yīng)用的 規(guī)程、方 法、工具和 資源根據(jù)項目情況列出本階段其它可應(yīng)用的規(guī)程、方法、工具和資源2.6軟件集成和集成測試軟件集成是把設(shè)計階段制定的，已通過單元測試的模塊構(gòu)建成一個完整的軟件結(jié)構(gòu)的系 統(tǒng)方法。在該階段，同時要進行集成測試，以發(fā)現(xiàn)和接口相關(guān)的缺陷。集成按集成計劃中

13、制定的順序進行，并執(zhí)行每個集成階段的相應(yīng)測試用例。主要輸入概要設(shè)計文檔和程序、集成測試計劃和測試用例入口準則被集成的模塊通過了單元測試角色與職 責項目經(jīng)理、集成人員、測試人員、開發(fā)人員項目應(yīng)根據(jù)具體情況，列出每個角色的職責活動1、確定集成環(huán)境和集成規(guī)程2、進行集成和集成測試主要輸出集成計劃、集成后的完整軟件產(chǎn)品、集成測試報告出口準則完成軟件集成，并成功地執(zhí)行了集成測試計劃中的所有測試用例度量軟件集成和集成測試的工作量、集成測試中發(fā)現(xiàn)的缺陷、返工工 作量可應(yīng)用的 標準和規(guī) 范根據(jù)項目情況列出本階段應(yīng)該遵循的過程和產(chǎn)品的標準和規(guī)范可應(yīng)用的 規(guī)程、方 法、工具和 資源根據(jù)項目情況列出本階段其它可應(yīng)用

14、的規(guī)程、方法、工具和資源2.7系統(tǒng)測試系統(tǒng)測試是依據(jù)需求規(guī)格說明書驗證軟件產(chǎn)品有效性的活動。 這個階段是為了發(fā)現(xiàn)那些 只有通過測試整個系統(tǒng)才能暴露的缺陷， 像外部接口、性能、安全和可靠性等只有在這個階 段才能判斷其是否有效。主要輸入軟件需求規(guī)格說明書、集成后的完整軟件產(chǎn)品、系統(tǒng)測試計劃和 測試用例入口準則軟件產(chǎn)品通過了集成測試角色與職 責項目經(jīng)理、系統(tǒng)測試人員、開發(fā)人員項目應(yīng)根據(jù)具體情況，列出每個角色的職責活動1、確定系統(tǒng)測試環(huán)境和測試規(guī)程2、進行系統(tǒng)測試主要輸出系統(tǒng)測試報告出口準則成功地執(zhí)行了系統(tǒng)測試計劃中的所有測試用例度量系統(tǒng)測試的工作量、系統(tǒng)測試中發(fā)現(xiàn)的缺陷、返工工作量可應(yīng)用的 標準和規(guī)

15、 范根據(jù)項目情況列出本階段應(yīng)該遵循的過程和產(chǎn)品的標準和規(guī)范可應(yīng)用的 規(guī)程、方 法、工具和 資源根據(jù)項目情況列出本階段其它可應(yīng)用的規(guī)程、方法、工具和資源2.8驗收和安裝在驗收和安裝階段， 軟件產(chǎn)品被集成到它的操作環(huán)境中，并在這個環(huán)境中經(jīng)受測試，以確保它按需求執(zhí)行。這個階段包括兩個基本任務(wù)：使軟件得以驗收和在客戶處安裝。驗收指的是用戶根據(jù)早期準備的驗收測試計劃而進行正式的測試，并對測試結(jié)果進行分析， 以確定系統(tǒng)是否滿足驗收準則。當分析結(jié)果滿足驗收準則時，用戶接受軟件。安裝指的是把接受的 軟件置于實際的產(chǎn)品環(huán)境中。主要輸入系統(tǒng)測試后的軟件產(chǎn)品、驗收計劃入口準則軟件產(chǎn)品通過了系統(tǒng)測試角色與職 責項目經(jīng)

16、理、安裝隊伍、客戶、開發(fā)人員項目應(yīng)根據(jù)具體情況，列出每個角色的職責活動1、按計劃執(zhí)行驗收2、執(zhí)行安裝主要輸出驗收報告、安裝后的軟件出口準則客戶在驗收報告上簽字、軟件運行在實際的產(chǎn)品環(huán)境中度量驗收和安裝的工作量、驗收中發(fā)現(xiàn)的缺陷、返工工作量可應(yīng)用的 標準和規(guī) 范根據(jù)項目情況列出本階段應(yīng)該遵循的過程和產(chǎn)品的標準和規(guī)范可應(yīng)用的 規(guī)程、方 法、工具和 資源根據(jù)項目情況列出本階段其它可應(yīng)用的規(guī)程、方法、工具和資源3其他生命周期模型3.1原型模型原型模型從需求采集開始，開發(fā)者和客戶一起定義軟件的總體目標，標識出已知需求并規(guī)劃出進一步定義的范圍。 然后是進行快速設(shè)計， 快速設(shè)計集中于軟件中那些對客戶可見部

17、分的表示（如輸入方式和輸出格式）。快速設(shè)計導(dǎo)致原型的建造。原型由客戶進行評價，并進一步精化待開發(fā)的軟件需求。逐步調(diào)整原型使其滿足客戶的要求，同時也使開發(fā)者對將要做的事情有更好的理解，這個過程是迭代的。最終系統(tǒng)設(shè)計最終系統(tǒng)實現(xiàn)圖2原型模型原型模型在克服瀑布模型缺點、減少由于軟件需求不明確給開發(fā)工作帶來風險方面，確有顯著效果。軟件系統(tǒng)的原型有多種形式：丟棄型一一原型開發(fā)之后，已獲取了更為清晰的需求信息，原型無需保留而廢棄；演示型一一開發(fā)原型僅以演示為目標；樣品型一一原型規(guī)模與最終產(chǎn)品相同，只是原型僅供研究用；增長式演式型一一原型作為軟件最終產(chǎn)品的一部分，可以滿足用戶的部分需求，進一步在此基礎(chǔ)上開發(fā)

18、，則可增加需求，實現(xiàn)后再交付使用；粗陋型一一用較短時間開發(fā)的簡易原型。原形模型適合：客戶能提出一般性的目標，但不能標出詳細的輸入、處理及輸出需求； 或開發(fā)者不能確定算法的有效性、操作系統(tǒng)的適應(yīng)性及人機交互的形式。3.2螺旋模型螺旋模型是將瀑布模型與進化模型相結(jié)合，并增加了兩者所忽略的風險分析。它將軟件項目開發(fā)分別劃分為四類活動，沿著螺線旋轉(zhuǎn)，在笛卡兒坐標的四個象限上分別表達了四個 方面的活動，即：制訂計劃一一確定軟件目標，選定實施方案，弄清項目開發(fā)的限制條件；風險分析一一分析所選方案，考慮如何識別和消除風險；實施工程一一實施軟件開發(fā)；客戶評估一一評價開發(fā)工作，提出修正建議。沿螺線自內(nèi)向外每旋轉(zhuǎn)

19、一圈便開發(fā)出更為完善的一個新的軟件版本。螺旋模型通常用以指導(dǎo)大型軟件項目的開發(fā)，如果開發(fā)風險過大，開發(fā)者和客戶無法承受，項目有可能因此終止。多數(shù)情況下會沿著螺線繼續(xù)下去，自內(nèi)向外逐步延伸， 最終得到滿意的軟件。如果對所開發(fā)項目的需求已有了較好的理解或較大的把握，無需開發(fā)原型，便可采用普通的瀑布模型。這在螺旋模型中可認為是單圈螺線。與此相反，如果對所開發(fā)項目的需求理解較差，需要開發(fā)原型， 甚至需要不止一個原型的幫助，那就要經(jīng)歷多圈螺線。在這種情況下，外圈的開發(fā)包含了更多的活動。也可能某些開發(fā)采用了不同的模型。和其它模型相比螺旋模型的優(yōu)越性較為明顯，但要求許多客戶接受和相信進化方法并不如果項目風險

20、較大，又容易。本模型的使用需要具有相當豐富的風險評估經(jīng)驗和專門知識。未能及時發(fā)現(xiàn)，勢必造成重大損失。制訂計劃累計成本鳳臉分析試客戶評價風險分析原型、毎亟2 原型3 I原事鳳險分分成與測提交線評價方案，識別鳳、浦除風險險析析驗收I 實現(xiàn)|測試!詳細設(shè)計/開發(fā)驗證 下一產(chǎn)品 實施工程螺握模型圖3螺旋模型3.3增量模型增量模型融合了瀑布模型的基本成分和原型的迭代特征。增量模型采用隨著日程時間的進展而交錯的線性序列。每一個線性序列產(chǎn)生軟件的一個可發(fā)布的“增量”。每一個增量的處理流程均可以采用原型模型。在使用增量模型時，第一個增量往往是核心產(chǎn)品，以后每次交付可使用的部分功能， 每次交付包含前一次交付的功能和一些新功能，最后一次交付一個完整的系統(tǒng)。增量模型適用于業(yè)務(wù)高速發(fā)展的用戶應(yīng)用系統(tǒng)。使用該模型時，首次交付的內(nèi)容通常完成了最基本的需求，其它需求通過交付內(nèi)容的使用情況和評價來制定下一次交付內(nèi) 容的開發(fā)計劃，此過程不斷重復(fù)，直到滿足整個系統(tǒng)需求。這種模型適用于需求逐漸清晰的 軟件項目。圖4增量模型3.4 RAD模型快速應(yīng)用開發(fā)模型（RAD模型）是瀑布模型的一個“高速”變種，強調(diào)極短的開發(fā)周 期。通過使用基于構(gòu)件的建造方法獲得快速開發(fā)。如果需求理解的好，且約束了項目范圍， RA