1. 模型介紹

1.1 前言

制定軟件生命周期（Software Lift Cycle, SLC）的目的是確定項目應(yīng)該采用的軟件生命周期模型，統(tǒng)籌規(guī)劃項目的整體開發(fā)流程。

軟件生命周期是組織軟件標(biāo)準(zhǔn)過程模型的重要組成部分。本文檔闡述了周期模型選擇的規(guī)程，該規(guī)程的“目標(biāo)”、“角色與職責(zé)”、“啟動準(zhǔn)則”、“輸入”、“主要步驟”、“輸出”、“結(jié)束準(zhǔn)則”和“度量”在CMMI相關(guān)文檔中均已定義。

1.2 說明

軟件生命周期是指從設(shè)想軟件產(chǎn)品開始到軟件不再供使用為止的時間間隔。對生命周期細(xì)分階段進行管理稱為周期模型，典型的幾種生命周期模型包括瀑布模型、瀑布迭代模型、原型迭代模型、XP模型等。項目組應(yīng)在軟件項目啟動階段認(rèn)真考慮項目的特征和目標(biāo)的基礎(chǔ)上參考原有模型和組織軟件標(biāo)準(zhǔn)過程，運用《過程裁減指南》為項目開發(fā)裁減出一個軟件生命周期模型。

無論選擇何種模型，都要包括下列一般軟件工程過程必須包含的內(nèi)容：

1.需求

2.設(shè)計

3.編碼

4.集成

5.測試

2. 軟件生命周期定義

2.1 目標(biāo)

本規(guī)程的制定是為了在項目實施過程中能夠有一個統(tǒng)一的方法來分析項目需求預(yù)先識別項目特征并提供可供項目選擇的軟件生命周期模型，使其可以和OSSP結(jié)合在一起使用。

2.2 角色與職責(zé)

角色	職責(zé)	說明
項目經(jīng)理	1） 歸納軟件項目實施需求 2） 根據(jù)類似項目的開發(fā)經(jīng)驗，識別項目特征 3） 提出項目實施參考模型 4） 與項目成員一起討論裁剪模型
項目成員	1） 總結(jié)類似項目的開發(fā)經(jīng)驗，識別項目特征 2） 裁剪項目實施參考模型

2.3 啟動準(zhǔn)則

從項目啟動階段開始

2.4 輸入

《需求規(guī)格說明書》

2.5 主要步驟

軟件生命周期模型一般都是在原有的軟件生命周期模型基礎(chǔ)上根據(jù)客戶的需求范圍和目標(biāo)實現(xiàn)來判斷項目的特征，進而進行模型裁剪后產(chǎn)生。一般包括四個步驟：需求識別分析、原型參考、裁剪定義和模型實施。

圖 2-1生命周期選型流程

2.5.1 需求識別分析

從需求被識別，并且明確了需求目標(biāo)開始，就進入項目啟動階段，這個時候項目組開始組建，同時開始收集需求，項目經(jīng)理應(yīng)積極配合業(yè)務(wù)代表或者商務(wù)經(jīng)理一起參與需求研討和項目的策劃，安排有經(jīng)驗的人員進入項目組，迅速對需求進行初步分析，概括項目的特征。

此部分的需求分析還應(yīng)該包括對歷史項目的回顧，總結(jié)成功實施經(jīng)驗和吸取失敗教訓(xùn)，并歸檔備案作為組織的知識庫。

2.5.2 原型參考

當(dāng)項目需求目標(biāo)確定，同時識別出項目特征，從常用軟件生命周期模型中挑選出一個模型以供參考，該周期原型必須在很大程度上適合項目的具體特征以及能夠結(jié)合組織標(biāo)準(zhǔn)軟件過程一起使用。

項目一開始，挑選后的軟件生命周期模型僅作參考，下一步還必須結(jié)合實際的越來越豐富的需求進行裁剪以形成最終的項目指導(dǎo)模型。最終的項目指導(dǎo)模型可以歸檔成為下一個類似項目的原始參考模型。

原型的描述主要包括軟件生命周期模型的原理、優(yōu)缺點、選用規(guī)則。

2.5.3 裁剪定義

? 裁剪基于項目特征

項目特征是裁剪工作的出發(fā)點，包括項目規(guī)模（如大、中、小等）、項目類型（如新開發(fā)、外包、升級等），以及技術(shù)難易度、產(chǎn)品類型、項目的時間和質(zhì)量要求等要素。

? 明確可裁剪的對象

可裁剪對象確定了裁剪的內(nèi)容范圍，可裁剪對象不僅僅限于過程元素和活動，還包括參照標(biāo)準(zhǔn)、方法和工具、輸出成果物及模板等。

? 確定裁剪所考慮的要素

裁剪要素界定了裁剪的方向和尺度。例如，對于某個裁剪對象，其范圍、頻度等都是裁剪要素。對于有開發(fā)經(jīng)驗的小項目，可以適當(dāng)減少對于技術(shù)方面的評審的頻度。

? 裁剪的決定要基于風(fēng)險進行考慮

基于風(fēng)險可檢驗裁剪的適當(dāng)性。對過程或活動的調(diào)整或放棄需要通過分析其所帶來的風(fēng)險和影響再做決定。

2.5.4 模型實施

裁剪后的新周期模型，是個適應(yīng)項目特征的項目標(biāo)準(zhǔn)軟件過程，該過程包含軟件生命周期模型的原理、優(yōu)缺點等描述，能夠幫助軟件開發(fā)人員更好地理解和運用此生命周期進行項目開發(fā)。

新周期模型對于項目開發(fā)具有指導(dǎo)意義，必須將該模型下達通知到項目組所有成員，項目經(jīng)理必須監(jiān)督保證此模型的實施與推廣，實現(xiàn)“項目可控，質(zhì)量可靠”的最終目標(biāo)。

2.5.5 輸出

《項目已定義過程》（PDP）

2.6 結(jié)束準(zhǔn)則

項目結(jié)項。

2.7 度量

度量的目的是統(tǒng)計用裁減后的軟件生命周期模型指導(dǎo)項目過程進展后，此項目產(chǎn)生的所有工作量。

同樣的軟件項目，實施不同的周期模型，項目的總的工作量也是不同的，好的周期模型不僅能夠大大縮減工作量，同時也保證代碼的質(zhì)量。不合理的周期模型則會因為保證質(zhì)量的需要引入重復(fù)的各類階段審查，進而產(chǎn)生更多、更冗長的無法跟蹤維護的文檔導(dǎo)致項目失敗，或者忽略關(guān)鍵性的階段審查而帶來需求的不明確及代碼的重復(fù)返工，同樣也導(dǎo)致了項目失敗。

軟件生命周期模型的引入，將對項目過程劃分成幾個不同的階段，規(guī)模較大的項目則階段內(nèi)還分更多小的階段，每個階段都將對本階段內(nèi)產(chǎn)生的成果物進行審查。因此，如何估算審查的工作量也必須包含在此度量活動中。

3. 常用軟件生命周期模型

軟件項目生命周期是指從軟件產(chǎn)品的設(shè)想開始到軟件不再使用而結(jié)束的時間。軟件項目生命周期一般包括售前階段、需求階段、設(shè)計階段、實現(xiàn)階段、測試階段、部署上線階段、運行和維護階段等。由于軟件實施組織是為不同的商業(yè)客戶生產(chǎn)軟件，所以傳統(tǒng)的軟件項目生命周期不可能適用于公司所有軟件項目的實施情況，為此EPG在軟件工程學(xué)科的傳統(tǒng)生命周期的基礎(chǔ)上，綜合了組織所有項目的特征，定義出了一個大而全的生命周期模型。每個軟件項目可以在可選擇軟件周期參考模型的過程中，結(jié)合組織標(biāo)準(zhǔn)軟件過程，運用過程裁減標(biāo)準(zhǔn)進行裁減，從而成為項目的實施標(biāo)準(zhǔn)過程。

3.1 產(chǎn)品或定制型項目生命周期模型

標(biāo)準(zhǔn)瀑布生命周期模型

3.1.1 標(biāo)準(zhǔn)瀑布生命周期模型（V）

標(biāo)準(zhǔn)瀑布生命周期模型適用于公司內(nèi)部研發(fā)項目、為客戶開發(fā)系統(tǒng)的項目、二次開發(fā)和推廣移植的項目。模型用圖形的方式來描述，顯示了它們應(yīng)用的階段及其輸入/輸出。描述了在何種條件下使用該模型，需要注意風(fēng)險和應(yīng)用裁剪的指導(dǎo)。

當(dāng)開發(fā)的系統(tǒng)規(guī)模和復(fù)雜度較高，達到需要采用多層設(shè)計時，推薦使用標(biāo)準(zhǔn)的生命周期。最終的系統(tǒng)被分解為多于一個的子系統(tǒng)。每個子系統(tǒng)由一個或多個模塊組成。每個模塊由一個或多個單元。一個單元是最小的可獨立測試的單位。用于集成測試的模塊測試計劃和集成測試計劃中的模塊就是從單元而來，子系統(tǒng)從模塊而來。

使用指南:

? 需求很好地被理解了且期望是相對穩(wěn)定的。

? 解決方案的技術(shù)和架構(gòu)被很好地理解。

? 高可維護的和可支持的解決方案的需要。

? 所有中間交付物受控的基線具有良好的可視性和可靠性。

優(yōu)點:

? 對管理層提供實施可視性。

? 由于需求相對穩(wěn)定度較高，其時間表具有很好的穩(wěn)定度。

注意事項:

? 在不清晰、不穩(wěn)定的需求和技術(shù)條件下不能很好工作。

? 由于在一個階段結(jié)束時要做很多文檔并要所有的干系人簽字，有很大的開銷。

? 所有的干系人都要在每一個階段結(jié)束時進行說明或簽字。

? 根據(jù)工作量和時間分析，由于項目范圍的改變而導(dǎo)致的中途更正是花很大代價的。

裁剪指南:

? 模塊測試計劃和集成測試計劃可以組合在一個文檔中。

? 這個模型中的階段和檢查點都不能做變更。

3.1.2 V-瀑布生命周期為關(guān)鍵產(chǎn)品(VC)

瀑布生命周期為關(guān)鍵產(chǎn)品

該模型是經(jīng)過裁剪的模型。推薦在中等復(fù)雜度和規(guī)模的項目中使用，在這些項目中解決方案可以用兩層來表示。系統(tǒng)由多于一個模塊組成，同時每個模塊又是由一個或多個單元組成。這種模型在軟件可靠性要求很高是被選擇，要求除開發(fā)者以外的人來進行測試。對這個生命周期來說，單元測試是必要的 。

使用指南:

? 安全/任務(wù)關(guān)鍵軟件開發(fā)

? 整個開發(fā)過程中的可跟蹤性和透明性的需求

? 控制開發(fā)的需求（成本、范圍和時間表）

優(yōu)點:

? 正規(guī)化保證了經(jīng)過高度測試后形成可靠的系統(tǒng)

注意事項:

? 在開發(fā)過程中，最終用戶不可視。

? 在測試計劃評審中包括顧客。

裁剪指導(dǎo):

? 這個模型中的階段和檢查點都不能做變更。

3.1.3 階段V-瀑布生命周期 (V4)

階段V-瀑布生命周期

該模型適合于對正規(guī)化程度低的小到中型項目。系統(tǒng)的規(guī)模和復(fù)雜度低，可以用一層設(shè)計來表示。最終的系統(tǒng)可以用一個或多個單元來構(gòu)成。在這個生命周期中單元測試是必要的。

使用指南:

? 項目的工作量, 周轉(zhuǎn)時間中等

? 產(chǎn)品復(fù)雜度和團隊規(guī)模中等

? 需求和技術(shù)比較好地被理解

? 比V瀑布在周轉(zhuǎn)時間的性能上要更好。

優(yōu)點:

? 對時間表有中等的控制

? 中等的開銷

? 對交付的解決方案有合理控制

注意事項:

? 在開發(fā)過程中，最終用戶不可視。

? 對很復(fù)雜的項目不建議使用，因為它只提供了一層設(shè)計。

裁剪指導(dǎo):

? 這個模型中的設(shè)計階段是由VC模型中的概要設(shè)計和詳細(xì)設(shè)計組合而成的。只有一層設(shè)計和測試的文檔是必需的。

? 在V模型需要測試計劃同所測試的開發(fā)一同被評審和基線化時，一個項目可以在每個測試計劃被評審和基線化時裁剪和設(shè)置檢查點。然而測試計劃活動一定要在階段指示的地方啟動，如ST計劃一定要在RA&P階段啟動。

3.1.4 演示生命周期(D)

演示生命周期

這個模型僅適合用于一個演示的系統(tǒng)開發(fā)，最終其將會被丟棄，它形成的成果將是對開發(fā)概念的證明。如果在其原型出來之后需要對此項目進行產(chǎn)品化，需要對這個開發(fā)的軟件進行詳細(xì)評估。

調(diào)查階段是在SC檢查點之前的所有階段的合并。調(diào)查、分析、計劃和設(shè)計活動都在這個階段進行。

使用指南:

? 很小范圍和團隊規(guī)模 – 可能1或2人的團隊。

? 低開發(fā)成本，高周轉(zhuǎn)時間。

? 不能提供訓(xùn)練有素的經(jīng)歷和開發(fā)者。

? 項目失敗影響低。

優(yōu)點:

? 很低 (可能最低) 成本。

? 中途修正是容易和便宜的。

注意事項

? 不可靠的時間表。

? 產(chǎn)品不可靠或沒有擴展項。

? 對管理層和顧客幾乎都是不可見的。

裁剪指導(dǎo):

? 根據(jù)產(chǎn)品的需要在發(fā)布階段的交付物要在整個SVW交付集中選擇。要建立這些交付物一致的基線。

3.1.5 進化開發(fā)模型（EVO）:

進化開發(fā)模型

進化開發(fā)模型 (EVO)是一種迭代的模型，可用來降低大項目的風(fēng)險。 風(fēng)險可以有很多種類，這個模型的每一個迭代或發(fā)布都針對了特定的風(fēng)險集合。風(fēng)險可以是對需求理解不清楚、新技術(shù)的使用、架構(gòu)的可行性、潛在的性能問題等。每一個迭代都有不同的模型作為基礎(chǔ)。

使用指南:

? 中到大項目, 可靠性和最終用戶的可視性很重要。

? 需求、架構(gòu)和技術(shù)都沒有很好地理解。

? 最終產(chǎn)品要有好的擴展性。

優(yōu)點:

? 對管理層和顧客有很高的可視性。

? 風(fēng)險管理容易。

? 中等的成本，至少提供了相對穩(wěn)定的時間表。

注意:

? 需要有很有經(jīng)驗的和成熟的管理。

? 對每個周期的管理和文檔都有成本。

? 中途修改要明確定義，包括對原型周期。

? 在迭代過程中發(fā)生巨大的變化會導(dǎo)致成本花費和缺乏可靠性及擴展性。

裁剪指導(dǎo):

? 每一個迭代都有不同的模型作為基礎(chǔ)，這些模型是從前面幾種基本瀑布模型選出的，遵循它們的裁剪指導(dǎo)。在每個迭代中可以使用不同的模型。

3.1.6 生命周期模型裁剪說明

裁剪項	類型（活動或工作產(chǎn)品）	裁減要素（增加、刪除、修改）	裁減條件
標(biāo)準(zhǔn)瀑布生命周期模型模塊測試計劃	工作產(chǎn)品	刪除	模塊測試計劃與集成測試計劃可合并在一個文檔中。
進化開發(fā)模型	活動	修改	每一個迭代可使用不同的基本瀑布模型，并遵循其裁剪指導(dǎo)。

3.1.7 生命周期模型使用指南匯總

生命周期模型	使用指南	優(yōu)點	注意事項
標(biāo)準(zhǔn)瀑布生命周期模型	1.安全/任務(wù)關(guān)鍵軟件開發(fā) 2.整個開發(fā)過程中的可跟蹤性和透明性的需求 3.控制開發(fā)的需求（成本、范圍和時間表）	正規(guī)化保證了經(jīng)過高度測試后形成可靠的系統(tǒng)	1.在開發(fā)過程中，最終用戶不可視。 2.在測試計劃評審中包括顧客。
V瀑布模型為關(guān)鍵產(chǎn)品（VC）	1.安全/任務(wù)關(guān)鍵軟件開發(fā) 2.整個開發(fā)過程中的可跟蹤性和透明性的需求 3.控制開發(fā)的需求（成本、范圍和時間表）	正規(guī)化保證了經(jīng)過高度測試后形成可靠的系統(tǒng)	1.在開發(fā)過程中，最終用戶不可視。 2.在測試計劃評審中包括顧客。
階段V-瀑布生命周期 (V4)	1.項目的工作量, 周轉(zhuǎn)時間中等 2.產(chǎn)品復(fù)雜度和團隊規(guī)模中等 3.需求和技術(shù)比較好地被理解 4.比V瀑布在周轉(zhuǎn)時間的性能上要更好。	1.對時間表有中等的控制 2.中等的開銷 3.對交付的解決方案有合理控制	1.在開發(fā)過程中，最終用戶不可視。 2.對很復(fù)雜的項目不建議使用，因為它只提供了一層設(shè)計。
演示生命周期（D）	1.很小范圍和團隊規(guī)模 – 可能1或2人的團隊。 2.低開發(fā)成本，高周轉(zhuǎn)時間。 3.不能提供訓(xùn)練有素的經(jīng)歷和開發(fā)者。 4.項目失敗影響低。	1.很低 (可能最低) 成本。 2.中途修正是容易和便宜的。	1.不可靠的時間表。 2.產(chǎn)品不可靠或沒有擴展項。 3.對管理層和顧客幾乎都是不可見的。
進化開發(fā)模型（EVO）	1.中到大項目, 可靠性和最終用戶的可視性很重要。 2.需求、架構(gòu)和技術(shù)都沒有很好地理解。 3.最終產(chǎn)品要有好的擴展性。	1.對管理層和顧客有很高的可視性。 2.風(fēng)險管理容易。 3.中等的成本，至少提供了相對穩(wěn)定的時間表。	1.需要有很有經(jīng)驗的和成熟的管理。 2.對每個周期的管理和文檔都有成本。 3.中途修改要明確定義，包括對原型周期。 4.在迭代過程中發(fā)生巨大的變化會導(dǎo)致成本花費和缺乏可靠性及擴展性。

3.2 升級維護型項目生命周期模型

本模型描述了修補一個缺陷開展的活動。當(dāng)缺陷修補活動需要作為一個獨立的項目時，建議采用本項目生命周期模型。

缺陷分類

分析

修補

測試

補丁/修補版本

單個缺陷的活動遵循缺陷管理的過程，該過程根據(jù)缺陷跟蹤機制/工具的不同而改變。

本活動的指南和在本生命周期可能的裁剪在腳注中提供。

表1缺陷修補項目生命周期模型

注：表格中對應(yīng)的數(shù)字標(biāo)號，請參考表格后的裁減指南；

階段	分類	分析 ⑹	修補	測試	補丁/修補版本 ⑼
輸入	●服務(wù)要求/變更要求 ●市場評審 ⑿	●區(qū)分優(yōu)先次序的 CR ●充足的信息展開分析 ●調(diào)試工具	●源代碼 ●數(shù)據(jù)庫 ●分析階段輸出 ●依賴信息	●修補階段輸出 ●測試用例組	●分支代碼的頂部 ●構(gòu)造環(huán)境 ●測試用例組 補丁工具
任務(wù)	●初步分析⑵ ●初步估計⑶ ●區(qū)分優(yōu)先次序的CR ⑷ ●更新 CR ⑸	●調(diào)查并模擬缺陷⑺ ●調(diào)試代碼 ●設(shè)計測試用例⑻ ●更新 CR ⑸	●編制修補代碼 ●單元測試修補代碼 ●更新回歸測試用例 ●同行評審 ●更新 CR ⑸	●回歸測試 ●由提交者驗證 (如果可行) ●登記已修改的代碼 ●更新CR ⑸	●構(gòu)造項目 ●回歸/ 整合/系統(tǒng)測試 ●準(zhǔn)備補丁 ●評審補丁文檔 ●補丁/修補版本 ●更新 CR⑸
輸 出	●分類并更新的CR	●缺陷隔離和用戶推薦的分析完成 ●更新 CR	●包含修補的代碼 ●單元測試后的代碼 ●測試用例組 ●同行評審日志 ●更新的 CR	●測試結(jié)果 ●測試后的代碼基線	●測試結(jié)果 ●補丁評審日志（如果可行） ●補丁 ●補丁樣板/檢查列表 (如果可行) ●更新 CR

注：任務(wù)/活動指南和裁剪指南：

1. 該模型也可以用于小的功能增強型項目 (小于1個月的工作量)。

2. 初步分析用于判斷缺陷的相關(guān)信息。比如，缺陷是否屬于另一個項目/部件，是否和已經(jīng)存在的缺陷重復(fù)，是否由一個操作者的失誤引起或是一個增加要求，或者需要被作為技術(shù)攻關(guān)項目來處理。

3. 初步估計用于初步評估修復(fù)缺陷需修改規(guī)模、工作量、成本等。

4. 為缺陷指定修復(fù)的優(yōu)先級。

5. 缺陷修補過程中需要適當(dāng)?shù)馗翪R狀態(tài)。同樣，在生命周期的每個階段需要更新相關(guān)CR信息。

6. 根據(jù)CR優(yōu)先級進行缺陷修補問題的分析。

7. 作為分析階段的第一步，缺陷需要在開發(fā)環(huán)境或客戶的測試環(huán)境里再次形成。這可能需要提交缺陷者提供更多的信息。在這個階段，如果缺陷被確認(rèn)為不可重新形成的，同樣的缺陷可能被關(guān)閉或者分析可能使用跟蹤和核心等，他們可能被用來引起一個缺陷。依賴于業(yè)務(wù)影響，有些缺陷可以在不能被重新構(gòu)造的情況下修補。

8. 如果缺陷被成功地復(fù)制，那么單元測試也相應(yīng)地將被增進。然后測試缺陷的用例將組合到回歸測試中，如果存在，和測試計劃一致。

9. 每一個缺陷修補可能不會導(dǎo)致一個補丁。通常一個補丁用來修補一段時間內(nèi)積累的多個缺陷。但是有時 (一個熱點修補)一個補丁可能只修補一個缺陷。當(dāng)一個修補被捆綁到一個完成的產(chǎn)品版本后，項目管理生命周期的版本發(fā)布階段應(yīng)隨之開始。