張 妍

（北京航空航天大學(xué)經(jīng)濟管理學(xué)院）

一、引言

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

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

（2）適應(yīng)型生命周期可以細分為：

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

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

適應(yīng)型：敏捷風(fēng)格的項目，以 2-4 周的“Sprint”推進和指導(dǎo)工作。

混合型：將預(yù)測型和適應(yīng)型方法結(jié)合在一起滿足項目需求。

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

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

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

（一）瀑布模型

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

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

（二）快速原型模型

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

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

（三）螺旋模型

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

螺旋模型強調(diào)的是產(chǎn)品從小到大，不斷改進，不斷風(fēng)險分析的過程，特別適合龐大而復(fù)雜的、高風(fēng)險的系統(tǒng)。

（四）V模型

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

(1)單元測試：對應(yīng)詳細設(shè)計階段，由開發(fā)人員執(zhí)行，測試每個功能模塊，重點測內(nèi)部業(yè)務(wù)邏輯。

(2)集成測試：對應(yīng)概要設(shè)計階段，由開發(fā)人員執(zhí)行，將已測試過的模塊組裝成系統(tǒng)進行聯(lián)調(diào)測試，檢查系統(tǒng)能否成功編譯，各個模塊之間數(shù)據(jù)通信是否正常等。

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

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

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

（五）迭代模型

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

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

（六）增量模型

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

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

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

（七）敏捷模型

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

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

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

近年來，持續(xù)集成已成為敏捷開發(fā)的最佳實踐。然而，敏捷和持續(xù)集成的理念并沒有很好的解決從“開發(fā)完成”迅速實現(xiàn)“上線發(fā)布”環(huán)節(jié)，即持續(xù)交付。DevOps恰好拓展和完善了持續(xù)集成（CI）、持續(xù)部署（CD），來優(yōu)化開發(fā)、測試、系統(tǒng)部署等環(huán)節(jié)。DevOps很好地補充了敏捷，與敏捷模型配合可以實現(xiàn)更快、更持續(xù)的生產(chǎn)部署，加速交付更高質(zhì)量和更可靠的軟件產(chǎn)品和功能。

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

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

四、結(jié)語

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

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

（1）根據(jù)項目管理的側(cè)重點（進度、質(zhì)量、成本控制、風(fēng)險管理等）選擇適合的模型。

（2）模型是否適合項目規(guī)模及其復(fù)雜性？

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

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

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

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

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

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