1. 模型介紹

1.1 前言

制定軟件生命周期（Software Lift Cycle, SLC）的目的是確定項目應該采用的軟件生命周期模型，統籌規劃項目的整體開發流程。

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

1.2 說明

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

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

1.需求

2.設計

3.編碼

4.集成

5.測試

2. 軟件生命周期定義

2.1 目標

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

2.2 角色與職責

2.3 啟動準則

從項目啟動階段開始

2.4 輸入

《需求規格說明書》

2.5 主要步驟

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

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

2.5.1 需求識別分析

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

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

2.5.2 原型參考

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

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

原型的描述主要包括軟件生命周期模型的原理、優缺點、選用規則。

2.5.3 裁剪定義

裁剪基于項目特征

項目特征是裁剪工作的出發點，包括項目規模（如大、中、小等）、項目類型（如新開發、外包、升級等），以及技術難易度、產品類型、項目的時間和質量要求等要素。

明確可裁剪的對象

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

確定裁剪所考慮的要素

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

裁剪的決定要基于風險進行考慮

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

2.5.4 模型實施

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

新周期模型對于項目開發具有指導意義，必須將該模型下達通知到項目組所有成員，項目經理必須監督保證此模型的實施與推廣，實現“項目可控，質量可靠”的最終目標。

2.5.5 輸出

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

2.6 結束準則

項目結項。

2.7 度量

度量的目的是統計用裁減后的軟件生命周期模型指導項目過程進展后，此項目產生的所有工作量。

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

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

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

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

3.1 產品或定制型項目生命周期模型

標準瀑布生命周期模型

3.1.1 標準瀑布生命周期模型（V）

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

當開發的系統規模和復雜度較高，達到需要采用多層設計時，推薦使用標準的生命周期。最終的系統被分解為多于一個的子系統。每個子系統由一個或多個模塊組成。每個模塊由一個或多個單元。一個單元是最小的可獨立測試的單位。用于集成測試的模塊測試計劃和集成測試計劃中的模塊就是從單元而來，子系統從模塊而來。

使用指南:

需求很好地被理解了且期望是相對穩定的。

解決方案的技術和架構被很好地理解。

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

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

優點:

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

由于需求相對穩定度較高，其時間表具有很好的穩定度。

注意事項:

在不清晰、不穩定的需求和技術條件下不能很好工作。

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

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

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

裁剪指南:

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

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

3.1.2 V-瀑布生命周期為關鍵產品(VC)

瀑布生命周期為關鍵產品

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

使用指南:

安全/任務關鍵軟件開發

整個開發過程中的可跟蹤性和透明性的需求

控制開發的需求（成本、范圍和時間表）

優點:

正規化保證了經過高度測試后形成可靠的系統

注意事項:

在開發過程中，最終用戶不可視。

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

裁剪指導:

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

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

階段V-瀑布生命周期

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

使用指南:

項目的工作量, 周轉時間中等

產品復雜度和團隊規模中等

需求和技術比較好地被理解

比V瀑布在周轉時間的性能上要更好。

優點:

對時間表有中等的控制

中等的開銷

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

注意事項:

在開發過程中，最終用戶不可視。

對很復雜的項目不建議使用，因為它只提供了一層設計。

裁剪指導:

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

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

3.1.4 演示生命周期(D)

演示生命周期

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

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

使用指南:

很小范圍和團隊規模 – 可能1或2人的團隊。

低開發成本，高周轉時間。

不能提供訓練有素的經歷和開發者。

項目失敗影響低。

優點:

很低 (可能最低) 成本。

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

注意事項

不可靠的時間表。

產品不可靠或沒有擴展項。

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

裁剪指導:

根據產品的需要在發布階段的交付物要在整個SVW交付集中選擇。要建立這些交付物一致的基線。

3.1.5 進化開發模型（EVO）:

進化開發模型

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

使用指南:

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

需求、架構和技術都沒有很好地理解。

最終產品要有好的擴展性。

優點:

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

風險管理容易。

中等的成本，至少提供了相對穩定的時間表。

注意:

需要有很有經驗的和成熟的管理。

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

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

在迭代過程中發生巨大的變化會導致成本花費和缺乏可靠性及擴展性。

裁剪指導:

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

3.1.6 生命周期模型裁剪說明

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

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

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

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

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

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

注：表格中對應的數字標號，請參考表格后的裁減指南；

注：任務/活動指南和裁剪指南：

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

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

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

4. 為缺陷指定修復的優先級。

5. 缺陷修補過程中需要適當地更新CR狀態。同樣，在生命周期的每個階段需要更新相關CR信息。

6. 根據CR優先級進行缺陷修補問題的分析。

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

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

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