譯者 | 陳峻

審校 | 孫淑娟

軟件開發生命周期(Software Development Life Cycle，SDLC)包含了軟件從開始到發布的不同階段。它定義了一種用于提高待開發軟件質量和效率的過程。因此，SDLC旨在通過最少的資源，交付出高質量的軟件。為了避免產生嚴重項目失敗后果，軟件開發的生命周期通常可以被劃分為如下六個階段：

• 需求收集
• 設計
• 軟件開發
• 測試和質量保證
• 部署
• 維護

值得注意的是，這些階段并非是靜態的，它們可以進一步地被分解成多個子類別，以適應獨特的開發需求與流程。

圖 1 軟件開發生命周期

需求收集

這是整個周期中其他階段的基礎。在此階段，所有利益相關者(包括客戶、產品負責人等)都會去收集與待開發軟件相關的信息。對此，項目經理和相關方會頻繁召開會議。盡管此過程可能比較耗時，但是我們不可急于求成，畢竟大家需要對將要開發的產品有個清晰的了解。

利益相關方需要將收集到的所有信息，記錄到軟件需求規范(Software Requirement Specification，SRS)文檔中。在完成了需求收集后，開發團隊需要進行可行性研究，以確定項目是否能夠被完成。

設計

此階段旨在模擬軟件應用的工作方式，并設計出軟件藍圖。負責軟件高級設計的開發人員將組成設計團隊，并通過由上個階段產生的SRS文檔，來指導設計過程，并最終完成滿足要求的體系結構。此處的高級設計是指包括用戶界面、用戶流程、通信設計等方面在內的基礎要素。

軟件開發

在此階段，具有不同專業知識(例如前端和后端)的開發人員或工程師，會通過處理設計的需求，來構建和實現軟件。這既能夠由一個人，也可以由一個大型團隊來執行，具體取決于項目的規模。

后端開發人員負責構建數據庫結構和其他必要組件。最后，由前端開發人員根據設計去構建用戶界面，并按需與后端進行對接。

在配套文檔方面，用戶指南會被創建，源代碼中也應適當地留下相應的注釋。也就是說，為了保證良好的代碼質量，適當的開發指南和政策也是必不可少的。

測試

專門的測試人員協同開發團隊在此階段開展測試工作。測試既可以與開發同時進行，也可以在開發階段結束時再開展。通常，開發人員在開發軟件時就會進行單元測試，以便檢查每個源代碼單元是否能夠按照預期工作。同時，此階段也包括如下其他測試：

• 系統測試--通過測試系統，以驗證其是否滿足所有指定的需求。
• 集成測試--將各個模塊組合到一起進行測試。測試團隊通過單擊按鈕，并執行滾動和滑動操作，來與軟件交互。當然，他們并不需要了解后端的工作原理。
• 用戶驗收測試--是在啟動軟件之前，邀請潛在用戶或客戶進行的最終測試。此類測試可以驗證目標軟件，是否能夠根據需求的規范，處理各種真實的場景。

測試對于軟件開發生命周期是至關重要的。倘若無法以正確的方式開展，則會讓軟件項目團隊反復在開發和測試階段之間徘徊，進而影響到成本和時間。

部署

完成測試后，我們就需要通過部署軟件，來方便用戶使用了。在此階段，部署團隊需要通過遵循若干流程，來確保部署流程的成功。無論是簡單的流程，還是復雜的部署，都會涉及到創建諸如安裝指南、系統用戶指南等相關部署文檔。

維護

作為開發周期的最后階段，維護涉及到報告并修復在測試期間未能發現的錯誤。在修復方式上，我們既能夠采取立即糾正錯誤的方式，也可以將其作為常規性的軟件更新。

此外，軟件項目團隊還會在此階段從用戶處收集反饋，以協助軟件的改進，并提高用戶的軟件使用體驗。

SDLC方法

雖然SDLC通常都會遵從上述步驟，但是它們在實現方式上略有不同。下面，我將介紹排名靠前的6種SDLC方法：

• 瀑布
• 敏捷
• 精益
• 迭代
• 螺旋
• DevOps方法

瀑布方法

圖 2 瀑布方法

作為最古老、也是最直接的SDLC方法，瀑布方法遵循的是線性執行順序。如上圖所示，從需求收集到維護，逐步依次推進，且不存在任何逆轉或倒退的步驟。也就是說，只有當上一步完成后，才能繼續下一步。

由于在設計階段之后，該方法不存在任何變化或調整的余地，因此，我們需要在需求收集階段，收集到有關項目的所有信息，即制作軟件藍圖。可見，對于經驗不足的開發團隊而言，如果能夠保證軟件的需求從項目開始就精確且穩定的話，便可以采用瀑布方法。也就是說，瀑布模型的成功，在很大程度上取決于需求收集階段的輸出是否清晰。當然，它也比較適合那些耗時較長的項目。

瀑布的優勢

• 需求在初始階段就能夠被精心設計。
• 具有容易理解的線性結構。
• 易于管理。

瀑布的缺點

• 既不靈活，又不支持變更。
• 任何階段一旦出現延遲，都會導致項目無法推進。
• 由于較為死板，因此項目總體時間較長。
• 并不鼓勵在初始階段之后，利益相關者進行積極地溝通。

敏捷方法

圖 3 敏捷方法生命周期

敏捷(Agile)即為快速輕松的移動能力。以溝通和靈活性為中心的敏捷原則與方法，提倡以更短的周期和增量式地進行部署與發布。

在敏捷開發的生命周期中，每個階段都有一個“儀式(ceremony)”，以便從開發團隊和參與項目的其他利益相關者處獲取反饋。其中包括：沖刺(sprint)計劃、每日scrum、沖刺評審、以及沖刺回顧。

總地說來，敏捷開發是在各個“沖刺”中進行的，每個沖刺通常持續大約2到4周。每個沖刺的目標不一定是構建MVP(最小可行產品，Minimum Viable Product)，而是構建可供客戶使用的軟件的一小部分。其交付出來的可能只是某個功能，而非具有完全功能的產品。也就是說，交付成果可能只是一個將來能夠被慢慢增加的功能性服務，而不一定是MVP。

圖 4 構建最小可行產品的示例

在每個沖刺結束后的沖刺審查階段，如果利益相關者對開發的功能感到滿意的話，方可開展下一輪沖刺。雖然新的功能是在沖刺中被開發的，但是整個項目期間的沖刺數量并不受限。它往往取決于項目和團隊的規模。因此，敏捷方法最適用于那些從一開始就無法明確所有要求的項目。

敏捷的優勢

• 適合不斷變化的需求。
• 鼓勵利益相關者之間的反饋和持續溝通。
• 由于采用了增量式方法，因此更易于管理各種潛在風險。

敏捷的缺點

• 最少量的文檔。
• 需要具有高技能的資源。
• 如果溝通低效，則可能拖慢項目的速度。
• 如果過度依賴客戶的互動，則可能會導致項目走向錯誤的方向。

精益方法

軟件開發領域的精益方法源于精益制造的原則。這種方法旨在減少生產過程中的浪費和成本，從而實現利潤的最大化。該方法雖與敏捷開發類似，但是側重于效率、快速交付、以及迭代式開發。而區別在于，敏捷方法更專注于持續溝通和協作，以體現價值;而精益方法更專注于消除浪費，以創造客戶價值。

精益方法的七個核心概念：

• 消除浪費--鼓勵開發團隊盡可能多地消除浪費。這種方法在某種程度上并不鼓勵多任務處理。這意味著它只需要完成“份內”的處理工作，并通過節省構建所謂“錦上添花”的功能，來節省時間。同時在所有開發階段都避免了不必要的文檔和會議。
• 鼓勵學習--通過鼓勵創建一個有利于所有相關成員學習的環境，來促進團隊對軟件開發過程予以反饋。
• 推遲決定--在做出決定之前，應仔細考慮各種事實。
• 盡快交付--由于交付是基于時間的，因此它會專注于滿足交付期限的增量式交付，而非大禮包式的發布。
• 團隊授權--它避開了針對團隊的微觀管理，而是鼓勵大家積極地參與到決策過程中，讓彼此感到參與了重要的項目。它不但為團隊成員提供了指導方向，而且為失敗留出了足夠的空間。
• 構建質量--由于在開發周期的所有階段都關注客戶價值，因此它會定期進行有關質量保證的各項測試。
• 整體優化--通過關注整個項目，而不是單獨的項目模塊，來有效地將組織戰略與項目方案相結合。

精益方法的優勢

• 由于團隊參與到了決策之中，因此創造力得到了激發。
• 能夠盡早地消除浪費，降低成本，并加快交付的速度。

精益方法的缺點

• 對于紀律性較差的團隊而言，它不一定是最佳選擇。
• 項目目標和重點可能會受到諸多靈活性的影響。

迭代方法

圖 5 迭代開發模型

開發界引入迭代方法作為瀑布模型的替代方案。它通過添加迭代式重復性開發周期，來克隆瀑布方法的所有步驟。由于最終產品的各個部分在完成后，才在每次迭代結束時發布的，因此這種方法也屬于增量式。具體而言，迭代方法的初始階段是計劃，而最后一個階段是部署。介于兩者之間的是：計劃、設計、實施、測試和評估的循環過程。

迭代方法雖與敏捷方法類似，但是它涉及的客戶參與度較少，并且具有預定義的增量范圍。

迭代的優點

• 在早期階段，它能夠生成產品的可運行版本。
• 其變更的成本更低。
• 由于產品被分成較小的部分，因此更易于管理。

迭代的缺點

• 可能需要更多的資源。
• 有必要全面了解各項需求。
• 不適合小型項目。

螺旋方法

作為一種具有風險意識的軟件開發方法，螺旋方法側重于降低軟件開發過程中的各項風險。它屬于一種迭代的開發方法，在循環中不斷推進。由于結合了瀑布模型和原型設計，因此螺旋方法是最靈活的SDLC方法，并具有如下四個主要階段：

• 第一階段--定義項目目標并收集需求。
• 第二階段--該方法的核心是進行全面的風險分析和計劃，消減已發現的風險。產品原型會在本階段交付出來。
• 第三階段--執行開發和測試。
• 第四階段--涉及評估已開發的內容，并計劃開展下一次迭代。

螺旋方法主要適用于高度定制化的軟件開發。此外，用戶對于原型的反饋可以在迭代后期(在開發階段)擴展各項功能。

螺旋方法的優勢

• 由于引入了廣泛的風險分析，因此盡可能地避免了風險。
• 它適用于較大型的項目。
• 可以在迭代后期添加其他功能。

螺旋方法的缺點

• 它更關注成本收益。
• 它比其他SDLC方法更復雜。
• 它需要專家進行風險分析。
• 由于嚴重依賴風險分析，因此倘若風險分析不到位，則可能會使整個項目變得十分脆弱。

DevOps方法

圖 6 DevOps方法

在傳統的軟件開發方法中，開發人員和運維人員之間幾乎沒有協作。特別是在運營過程中，開發人員往往被視為“構建者”的角色。這就造成了溝通和協作上的差距，以及在反饋過程中出現混淆。而軟件開發的DevOps方法恰好彌合了兩者之間的溝通鴻溝。其目標是通過將開發和運營團隊有效地結合起來，以快速地開發出更可靠的優質軟件。值得一提的是，DevOps也是一種將手動開發轉換為自動化軟件開發的方法。通常，DevOps方法會被劃分為如下5個階段：

• 持續開發--此階段涉及到軟件應用的規劃和開發。
• 持續集成—此階段會將新的功能性代碼與現有的代碼相集成。
• 持續測試--開發團隊和QA測試人員會使用maven和TestNG等自動化工具開展測試，以確保在新的功能中掃清缺陷。自動化測試為各種測試用例的執行節省了大量時間。
• 持續部署--此階段會使用類似puppet的配置管理工具、以及容器化工具，將代碼部署到生產環境(即服務器上)。它們還將協助安排服務器上的更新，并保持配置的一致性。
• 持續監控—運營團隊會在此階段通過使用Nagios、Relix和Splunk等工具，主動監控用戶活動中的錯誤、異常、不當的軟件行為、以及軟件的性能。所有在此階段被發現的問題都會被傳遞給開發團隊，以便在持續開發階段進行修復，進而提高軟件的質量。

DevOps的優勢

• 促進了合作。
• 通過持續開發和部署，更快地向市場交付軟件。
• 最大化地利用Relix。

DevOps的缺點

• 當各個團隊使用不同的環境時，將無法保證軟件的安全。
• 涉及到人工輸入的過程時，可能會減慢整體運營的速度。

小結

綜上所述，軟件開發生命周期中的每一個階段都是非常重要的。我們只有正確地執行了每個步驟，才能最大限度地利用現有資源，并交付出高質量、可靠的軟件。

事實上，軟件開發并沒有所謂的“最佳”方法，它們往往各有利弊。因此在選擇具體方法之前，您需要了解待選方法對手頭項目的實用性。當然，為了盡可能地采用最適合現有流程的方法，許多公司會同時使用兩種不同方法的組合，通過取長補短來實現有效的融合，并相輔相成地完成軟件的交付任務。

譯者介紹

陳峻 (Julian Chen)，51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗;持續以博文、專題和譯文等形式，分享前沿技術與新知;經常以線上、線下等方式，開展信息安全類培訓與授課。

原文標題：??The Complete Guide to SDLC??，作者：Mario Olomu