軟件項目生命周期模型分析及選擇

張 妍

（北京航空航天大學經濟管理學院）

一、引言

一般來說，項目生命周期從時間維度上將項目劃分為可行性研究、需求分析、概要設計與詳細設計、編碼、測試、運行與維護六個階段，形成一個從啟動到收尾推進項目實施的主線, 是項目實施的整個過程。項目階段的數量取決于項目規模及項目復雜程度，可根據項目的實際情況進行裁剪。項目的生命周期分為：

（1）預測型生命周期是固定且連續的（瀑布式項目）。

（2）適應型生命周期可以細分為：

迭代：項目分解成更小的、逐步迭代的階段。

增量型：類似于迭代，但階段更有順序性和時間限制。

適應型：敏捷風格的項目，以 2-4 周的“Sprint”推進和指導工作。

混合型：將預測型和適應型方法結合在一起滿足項目需求。

軟件項目的規模、需求、項目負責人的管理能力、開發團隊的技術能力都是千差萬別的，只有充分了解各生命周期模型的特點，才能選擇出一個適合項目的模型。當一個項目確定了生命周期模型后，再綜合運用項目管理過程、知識領域等管理方法、工具和技術實施項目管理。

接下來，本文介紹的瀑布模型、快速原型模型、螺旋模型、V模型、迭代模型、增量模型、敏捷模型都是目前在軟件行業中通用的項目生命周期模型，這些模型被項目管理者運用于項目或項目的不同階段。

二、典型項目生命周期模型分析

（一）瀑布模型

瀑布模型也稱線性模型，以文檔驅動。該模型將軟件開發過程分為可行性研究、需求調研與分析、概要設計與詳細設計、編碼、測試、運行維護六個階段，階段之間有清晰地劃分并且按此順序先后銜接，按部就班的推進項目，每個階段只執行一次，追求“一次成型”。每個階段都對應著里程碑節點，并規定了需要完成的任務及交付產物。每一階段結束后，通過嚴格的階段評審和確認，得到完整準確的文檔，以凍結這些文檔為該階段結束的標志，并作為下一階段工作的輸入；通過每一階段執行的正確性和完整性來保證最終系統的質量。

瀑布模型如果范圍控制和風險控制做的比較好的話，就真的如瀑布一般“飛流直下三千尺”，迅速完成客戶期望，部署運行，一般在外包公司常見。

（二）快速原型模型

快速原型模型是以需求驅動的。項目規模大且需求模糊時，產品經理很難一次完成需求分析，應用快速原型模型可以減少因需求不明確帶來的系統開發風險。原型法第一步是根據客戶的迫切需求在短時間內構建一個可以演示的產品（原型），客戶對該原型進行評價，輸出具體改進意見以豐富細化軟件需求，通過反復評價和改進原型彌補漏洞，直到客戶對原型滿意認可，最終團隊完成需求分析及確認。第二步則是根據原型開發出反映客戶真正需求的軟件。

因運用原型的目的和方式不同，原型的運用方式可分為拋棄型策略和進化型策略。拋棄策略用于項目目標模糊的情形下，以此策略梳理清楚客戶真實需求，探索方案的可行性。一旦需求或者方案確定了，原型隨之作廢。進化型策略用于需要盡早向客戶提交原型的情形下，原型包含系統的核心需求和功能，在得到客戶認可后，將原型不斷擴充演變為客戶滿意的最終系統。根據項目特點、原型構建工具、技術成熟度來選擇原型的運用方式。如果客戶對系統性能、可靠性要求較高，最好采用拋棄策略；如果客戶對質量要求不高，期望實現簡單功能就可以，可采用進化策略。

（三）螺旋模型

螺旋模型引入了風險分析與規避機制，是瀑布模型、快速原型和風險分析方法的有機結合。該模型由制定計劃、風險分析、實施工程和客戶評估這四個活動組成一個循環周期，在每個螺旋循環開始前進行風險分析，并在每個螺旋循環中采用瀑布模型并構建原型以降低風險。制定計劃活動是指定義軟件的里程碑目標及項目邊界，選擇實施方案。風險分析活動是指分析和評估所選方案，識別風險并確定適當的風險預防措施。實施工程活動是指對軟件項目的整個生命周期進行需求分析、設計、編碼、測試和實施。客戶評估活動是指對此螺旋周期的工作進行評價，根據反饋建議制定下一步計劃[1]。

螺旋模型強調的是產品從小到大，不斷改進，不斷風險分析的過程，特別適合龐大而復雜的、高風險的系統。

（四）V模型

V模型以測試驅動，基本思想是測試和開發同等重要，多個測試級別與開發階段相對應。整個V模型的活動按先后順序分別是需求分析→概要設計→詳細設計→編碼→單元測試→集成測試→系統測試→驗收測試。

(1)單元測試：對應詳細設計階段，由開發人員執行，測試每個功能模塊，重點測內部業務邏輯。

(2)集成測試：對應概要設計階段，由開發人員執行，將已測試過的模塊組裝成系統進行聯調測試，檢查系統能否成功編譯，各個模塊之間數據通信是否正常等。

(3)系統測試：對應需求分析階段，由測試人員執行，將整個系統看為一個整體，對功能、接口、性能、安全進行全方位的測試，驗證功能及性能是否滿足《需求規格說明書》。

(4)驗收測試：對應用戶需求階段，一般由客戶來執行，驗證系統是否符合合同中規定的要求。

V模型將把測試過程置于編碼之后，在驗收測試環節才能由客戶驗證需求最終實現的情況，針對這一弊端，可以安排測試人員在需求分析階段介入并編寫測試用例。這樣可以盡快發現需求是否偏離，最大可能的減少返工，從而滿足用戶的實際軟件需求。

（五）迭代模型

與瀑布模型不同，迭代模型不再強調工作的序列化過程，而是將這些過程并行化，分為多個階段，每個階段都包含這些工作且在不同階段所占比例不同，接納需求變更，允許通過需求細化來加深對問題的理解，是需求從模糊到清晰、功能反復求精的開發過程，并且每次迭代都產生一個可以發布的產品。

迭代模型一個二維的生命周期模型，以橫軸代表時間，分為初始、細化、構造、交付四個階段；以縱軸代表核心工作流程，即業務建模、需求、分析和設計、實現、測試、部署。初始階段的任務是確定項目邊界，估計項目成本和時間，展示系統候選架構，評估業務和需求風險，建立業務模型。細化階段的任務是分析問題，對架構做出決策（范圍、主要功能及非功能需求），確定技術實現的可行性和系統架構的穩定性，編制項目計劃。構造階段的任務是構件開發，組裝集成為產品，測試產品所有的功能，確定是否已經為部署軟件做好準備。交付階段的任務是組織驗收評審，獲取客戶反饋，基于反饋對系統進行調試，最終將軟件產品交付給客戶。

（六）增量模型

增量模型亦稱漸增模型，軟件功能數量逐漸增加，產品逐步發布交付。該模型將軟件視為一系列的增量組件來設計、開發、集成測試，每個組件由多個相互作用的模塊構成，并且能夠完成特定的功能。第一個增量組件通常實現最基本的軟件需求，提供最核心的功能。與瀑布模型相比，增量模型具有更短的周期，并且是分批向客戶交付產品。

增量模型的工作流程分為以下三個階段：

（1）在項目初期，為了確保系統具備穩定的架構，需要對整個系統進行需求分析和架構設計。以增量組件來確定系統的需求框架，再根據需求框架中組件的關系完成架構設計。（2）系統架構設計完成后，可執行增量組件的開發。首先對組件的需求進行細化分析，然后進行組件的設計、編碼、測試。（3）將開發完成的增量組件集成至系統，對集成后的系統進行重新驗證，驗證通過方能啟動下一個增量組件的開發[2]。

（七）敏捷模型

敏捷模型采用迭代規劃、增量交付的開發方法，開發評估以工作量為導向，任務評估采用相對估算，主張擁抱需求變化和面對面交流，簡化了繁瑣的流程和文檔管理。在敏捷開發中，項目被劃分為幾個連續的子項目，這些子項目可以獨立運行。各子項目的工作成果均通過測試，并且可集成和可操作。該模型面對瞬息萬變的市場環境和持續發展的技術時變得非常友好，適用于需求和范圍難以確定的項目。

敏捷模型有許多成熟的框架，并且各有自己的原則，比如軟件統一過程（RUP）、Scrum、看 板（kanban）、 極 限 編 程（XP)、精益軟件開發、功能驅動開發（FDD)，其中Scrum應用最廣泛。Scrum是固定周期的短迭代，Scrum中的迭代稱為沖刺Sprint，Scrum團隊由一名產品負責人（PO）、開發團隊（TM，至少3人）和一名Scrum Master（SM）組成。

敏捷項目管理分為5個階段：（1）構想：確定產品及項目范圍、項目參與者、項目團隊工作方式。（2）推測：收集產品初始要求，梳理出產品功能清單，估算項目成本，分析風險并制訂相應的應對措施，編寫基于功能的迭代交付計劃。（3）探索：組建協作的項目團隊，對項目干系人的期望值進行溝通，注重溝通效果的反饋，按期交付經測試通過的產品功能。（4）適應：檢查項目狀態和流程績效，與原計劃比對，分析差異原因，及時調整工作以開始新的迭代。（5）結束：終止項目、交流主要的學習成果并融入下一迭代工作[3]。產品在每次迭代中不斷優化，循環通常是推測→探索→適應，而構思需要定期修正。

近年來，持續集成已成為敏捷開發的最佳實踐。然而，敏捷和持續集成的理念并沒有很好的解決從“開發完成”迅速實現“上線發布”環節，即持續交付。DevOps恰好拓展和完善了持續集成（CI）、持續部署（CD），來優化開發、測試、系統部署等環節。DevOps很好地補充了敏捷，與敏捷模型配合可以實現更快、更持續的生產部署，加速交付更高質量和更可靠的軟件產品和功能。

三、項目生命周期模型的對比分析（見表1）

表1 項目生命周期模型的對比分析

四、結語

如今，軟件行業有多個通用的項目生命周期模型，每個過程模型都遵循其所獨有的一系列階段，以確保軟件開發步驟中的成功。但是，它們都不是完美的，會給項目帶來積極影響，同時伴隨而來的也會有不可預知的風險。項目規劃階段，項目管理者需要考慮項目背景、范圍、預算、干系人、風險、資源等眾多因素，決定采用何種項目生命周期管理方式，為管理項目提供基礎框架，從而更加有效地做好項目管理。

項目管理者可以通過幾個方面來選擇適合的項目生命周期模型：

（1）根據項目管理的側重點（進度、質量、成本控制、風險管理等）選擇適合的模型。

（2）模型是否適合項目規模及其復雜性？

（3）模型是否適合公司文化、組織原則？

（4）模型是否適合團隊的規模和他們的技能？

（5）模型是否適合項目中使用的技術？

（6）如果選擇這種模式，是否存在項目風險？

（7）需求是固定的還是靈活的？

若項目選擇適合的生命周期模型來設計和開發，可以起到事半功倍的效果。軟件項目過程具有隨機性以及不確定性的特點，任何一種模型可能都無法完全匹配實際的項目過程，所以在實際工作中，項目管理者不必拘泥于某一種模型，可以根據項目風險情況，適當借鑒其它生命周期的管理方式。