譯者 | 陳峻

審校 | 孫淑娟

軟件開(kāi)發(fā)生命周期(Software Development Life Cycle，SDLC)包含了軟件從開(kāi)始到發(fā)布的不同階段。它定義了一種用于提高待開(kāi)發(fā)軟件質(zhì)量和效率的過(guò)程。因此，SDLC旨在通過(guò)最少的資源，交付出高質(zhì)量的軟件。為了避免產(chǎn)生嚴(yán)重項(xiàng)目失敗后果，軟件開(kāi)發(fā)的生命周期通?？梢员粍澐譃槿缦铝鶄€(gè)階段：

• 需求收集
• 設(shè)計(jì)
• 軟件開(kāi)發(fā)
• 測(cè)試和質(zhì)量保證
• 部署
• 維護(hù)

值得注意的是，這些階段并非是靜態(tài)的，它們可以進(jìn)一步地被分解成多個(gè)子類(lèi)別，以適應(yīng)獨(dú)特的開(kāi)發(fā)需求與流程。

圖 1 軟件開(kāi)發(fā)生命周期

需求收集

這是整個(gè)周期中其他階段的基礎(chǔ)。在此階段，所有利益相關(guān)者(包括客戶(hù)、產(chǎn)品負(fù)責(zé)人等)都會(huì)去收集與待開(kāi)發(fā)軟件相關(guān)的信息。對(duì)此，項(xiàng)目經(jīng)理和相關(guān)方會(huì)頻繁召開(kāi)會(huì)議。盡管此過(guò)程可能比較耗時(shí)，但是我們不可急于求成，畢竟大家需要對(duì)將要開(kāi)發(fā)的產(chǎn)品有個(gè)清晰的了解。

利益相關(guān)方需要將收集到的所有信息，記錄到軟件需求規(guī)范(Software Requirement Specification，SRS)文檔中。在完成了需求收集后，開(kāi)發(fā)團(tuán)隊(duì)需要進(jìn)行可行性研究，以確定項(xiàng)目是否能夠被完成。

設(shè)計(jì)

此階段旨在模擬軟件應(yīng)用的工作方式，并設(shè)計(jì)出軟件藍(lán)圖。負(fù)責(zé)軟件高級(jí)設(shè)計(jì)的開(kāi)發(fā)人員將組成設(shè)計(jì)團(tuán)隊(duì)，并通過(guò)由上個(gè)階段產(chǎn)生的SRS文檔，來(lái)指導(dǎo)設(shè)計(jì)過(guò)程，并最終完成滿(mǎn)足要求的體系結(jié)構(gòu)。此處的高級(jí)設(shè)計(jì)是指包括用戶(hù)界面、用戶(hù)流程、通信設(shè)計(jì)等方面在內(nèi)的基礎(chǔ)要素。

軟件開(kāi)發(fā)

在此階段，具有不同專(zhuān)業(yè)知識(shí)(例如前端和后端)的開(kāi)發(fā)人員或工程師，會(huì)通過(guò)處理設(shè)計(jì)的需求，來(lái)構(gòu)建和實(shí)現(xiàn)軟件。這既能夠由一個(gè)人，也可以由一個(gè)大型團(tuán)隊(duì)來(lái)執(zhí)行，具體取決于項(xiàng)目的規(guī)模。

后端開(kāi)發(fā)人員負(fù)責(zé)構(gòu)建數(shù)據(jù)庫(kù)結(jié)構(gòu)和其他必要組件。最后，由前端開(kāi)發(fā)人員根據(jù)設(shè)計(jì)去構(gòu)建用戶(hù)界面，并按需與后端進(jìn)行對(duì)接。

在配套文檔方面，用戶(hù)指南會(huì)被創(chuàng)建，源代碼中也應(yīng)適當(dāng)?shù)亓粝孪鄳?yīng)的注釋。也就是說(shuō)，為了保證良好的代碼質(zhì)量，適當(dāng)?shù)拈_(kāi)發(fā)指南和政策也是必不可少的。

測(cè)試

專(zhuān)門(mén)的測(cè)試人員協(xié)同開(kāi)發(fā)團(tuán)隊(duì)在此階段開(kāi)展測(cè)試工作。測(cè)試既可以與開(kāi)發(fā)同時(shí)進(jìn)行，也可以在開(kāi)發(fā)階段結(jié)束時(shí)再開(kāi)展。通常，開(kāi)發(fā)人員在開(kāi)發(fā)軟件時(shí)就會(huì)進(jìn)行單元測(cè)試，以便檢查每個(gè)源代碼單元是否能夠按照預(yù)期工作。同時(shí)，此階段也包括如下其他測(cè)試：

• 系統(tǒng)測(cè)試--通過(guò)測(cè)試系統(tǒng)，以驗(yàn)證其是否滿(mǎn)足所有指定的需求。
• 集成測(cè)試--將各個(gè)模塊組合到一起進(jìn)行測(cè)試。測(cè)試團(tuán)隊(duì)通過(guò)單擊按鈕，并執(zhí)行滾動(dòng)和滑動(dòng)操作，來(lái)與軟件交互。當(dāng)然，他們并不需要了解后端的工作原理。
• 用戶(hù)驗(yàn)收測(cè)試--是在啟動(dòng)軟件之前，邀請(qǐng)潛在用戶(hù)或客戶(hù)進(jìn)行的最終測(cè)試。此類(lèi)測(cè)試可以驗(yàn)證目標(biāo)軟件，是否能夠根據(jù)需求的規(guī)范，處理各種真實(shí)的場(chǎng)景。

測(cè)試對(duì)于軟件開(kāi)發(fā)生命周期是至關(guān)重要的。倘若無(wú)法以正確的方式開(kāi)展，則會(huì)讓軟件項(xiàng)目團(tuán)隊(duì)反復(fù)在開(kāi)發(fā)和測(cè)試階段之間徘徊，進(jìn)而影響到成本和時(shí)間。

部署

完成測(cè)試后，我們就需要通過(guò)部署軟件，來(lái)方便用戶(hù)使用了。在此階段，部署團(tuán)隊(duì)需要通過(guò)遵循若干流程，來(lái)確保部署流程的成功。無(wú)論是簡(jiǎn)單的流程，還是復(fù)雜的部署，都會(huì)涉及到創(chuàng)建諸如安裝指南、系統(tǒng)用戶(hù)指南等相關(guān)部署文檔。

維護(hù)

作為開(kāi)發(fā)周期的最后階段，維護(hù)涉及到報(bào)告并修復(fù)在測(cè)試期間未能發(fā)現(xiàn)的錯(cuò)誤。在修復(fù)方式上，我們既能夠采取立即糾正錯(cuò)誤的方式，也可以將其作為常規(guī)性的軟件更新。

此外，軟件項(xiàng)目團(tuán)隊(duì)還會(huì)在此階段從用戶(hù)處收集反饋，以協(xié)助軟件的改進(jìn)，并提高用戶(hù)的軟件使用體驗(yàn)。

SDLC方法

雖然SDLC通常都會(huì)遵從上述步驟，但是它們?cè)趯?shí)現(xiàn)方式上略有不同。下面，我將介紹排名靠前的6種SDLC方法：

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

瀑布方法

圖 2 瀑布方法

作為最古老、也是最直接的SDLC方法，瀑布方法遵循的是線(xiàn)性執(zhí)行順序。如上圖所示，從需求收集到維護(hù)，逐步依次推進(jìn)，且不存在任何逆轉(zhuǎn)或倒退的步驟。也就是說(shuō)，只有當(dāng)上一步完成后，才能繼續(xù)下一步。

由于在設(shè)計(jì)階段之后，該方法不存在任何變化或調(diào)整的余地，因此，我們需要在需求收集階段，收集到有關(guān)項(xiàng)目的所有信息，即制作軟件藍(lán)圖。可見(jiàn)，對(duì)于經(jīng)驗(yàn)不足的開(kāi)發(fā)團(tuán)隊(duì)而言，如果能夠保證軟件的需求從項(xiàng)目開(kāi)始就精確且穩(wěn)定的話(huà)，便可以采用瀑布方法。也就是說(shuō)，瀑布模型的成功，在很大程度上取決于需求收集階段的輸出是否清晰。當(dāng)然，它也比較適合那些耗時(shí)較長(zhǎng)的項(xiàng)目。

瀑布的優(yōu)勢(shì)

• 需求在初始階段就能夠被精心設(shè)計(jì)。
• 具有容易理解的線(xiàn)性結(jié)構(gòu)。
• 易于管理。

瀑布的缺點(diǎn)

• 既不靈活，又不支持變更。
• 任何階段一旦出現(xiàn)延遲，都會(huì)導(dǎo)致項(xiàng)目無(wú)法推進(jìn)。
• 由于較為死板，因此項(xiàng)目總體時(shí)間較長(zhǎng)。
• 并不鼓勵(lì)在初始階段之后，利益相關(guān)者進(jìn)行積極地溝通。

敏捷方法

圖 3 敏捷方法生命周期

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

在敏捷開(kāi)發(fā)的生命周期中，每個(gè)階段都有一個(gè)“儀式(ceremony)”，以便從開(kāi)發(fā)團(tuán)隊(duì)和參與項(xiàng)目的其他利益相關(guān)者處獲取反饋。其中包括：沖刺(sprint)計(jì)劃、每日scrum、沖刺評(píng)審、以及沖刺回顧。

總地說(shuō)來(lái)，敏捷開(kāi)發(fā)是在各個(gè)“沖刺”中進(jìn)行的，每個(gè)沖刺通常持續(xù)大約2到4周。每個(gè)沖刺的目標(biāo)不一定是構(gòu)建MVP(最小可行產(chǎn)品，Minimum Viable Product)，而是構(gòu)建可供客戶(hù)使用的軟件的一小部分。其交付出來(lái)的可能只是某個(gè)功能，而非具有完全功能的產(chǎn)品。也就是說(shuō)，交付成果可能只是一個(gè)將來(lái)能夠被慢慢增加的功能性服務(wù)，而不一定是MVP。

圖 4 構(gòu)建最小可行產(chǎn)品的示例

在每個(gè)沖刺結(jié)束后的沖刺審查階段，如果利益相關(guān)者對(duì)開(kāi)發(fā)的功能感到滿(mǎn)意的話(huà)，方可開(kāi)展下一輪沖刺。雖然新的功能是在沖刺中被開(kāi)發(fā)的，但是整個(gè)項(xiàng)目期間的沖刺數(shù)量并不受限。它往往取決于項(xiàng)目和團(tuán)隊(duì)的規(guī)模。因此，敏捷方法最適用于那些從一開(kāi)始就無(wú)法明確所有要求的項(xiàng)目。

敏捷的優(yōu)勢(shì)

• 適合不斷變化的需求。
• 鼓勵(lì)利益相關(guān)者之間的反饋和持續(xù)溝通。
• 由于采用了增量式方法，因此更易于管理各種潛在風(fēng)險(xiǎn)。

敏捷的缺點(diǎn)

• 最少量的文檔。
• 需要具有高技能的資源。
• 如果溝通低效，則可能拖慢項(xiàng)目的速度。
• 如果過(guò)度依賴(lài)客戶(hù)的互動(dòng)，則可能會(huì)導(dǎo)致項(xiàng)目走向錯(cuò)誤的方向。

精益方法

軟件開(kāi)發(fā)領(lǐng)域的精益方法源于精益制造的原則。這種方法旨在減少生產(chǎn)過(guò)程中的浪費(fèi)和成本，從而實(shí)現(xiàn)利潤(rùn)的最大化。該方法雖與敏捷開(kāi)發(fā)類(lèi)似，但是側(cè)重于效率、快速交付、以及迭代式開(kāi)發(fā)。而區(qū)別在于，敏捷方法更專(zhuān)注于持續(xù)溝通和協(xié)作，以體現(xiàn)價(jià)值;而精益方法更專(zhuān)注于消除浪費(fèi)，以創(chuàng)造客戶(hù)價(jià)值。

精益方法的七個(gè)核心概念：

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

精益方法的優(yōu)勢(shì)

• 由于團(tuán)隊(duì)參與到了決策之中，因此創(chuàng)造力得到了激發(fā)。
• 能夠盡早地消除浪費(fèi)，降低成本，并加快交付的速度。

精益方法的缺點(diǎn)

• 對(duì)于紀(jì)律性較差的團(tuán)隊(duì)而言，它不一定是最佳選擇。
• 項(xiàng)目目標(biāo)和重點(diǎn)可能會(huì)受到諸多靈活性的影響。

迭代方法

圖 5 迭代開(kāi)發(fā)模型

開(kāi)發(fā)界引入迭代方法作為瀑布模型的替代方案。它通過(guò)添加迭代式重復(fù)性開(kāi)發(fā)周期，來(lái)克隆瀑布方法的所有步驟。由于最終產(chǎn)品的各個(gè)部分在完成后，才在每次迭代結(jié)束時(shí)發(fā)布的，因此這種方法也屬于增量式。具體而言，迭代方法的初始階段是計(jì)劃，而最后一個(gè)階段是部署。介于兩者之間的是：計(jì)劃、設(shè)計(jì)、實(shí)施、測(cè)試和評(píng)估的循環(huán)過(guò)程。

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

迭代的優(yōu)點(diǎn)

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

迭代的缺點(diǎn)

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

螺旋方法

作為一種具有風(fēng)險(xiǎn)意識(shí)的軟件開(kāi)發(fā)方法，螺旋方法側(cè)重于降低軟件開(kāi)發(fā)過(guò)程中的各項(xiàng)風(fēng)險(xiǎn)。它屬于一種迭代的開(kāi)發(fā)方法，在循環(huán)中不斷推進(jìn)。由于結(jié)合了瀑布模型和原型設(shè)計(jì)，因此螺旋方法是最靈活的SDLC方法，并具有如下四個(gè)主要階段：

• 第一階段--定義項(xiàng)目目標(biāo)并收集需求。
• 第二階段--該方法的核心是進(jìn)行全面的風(fēng)險(xiǎn)分析和計(jì)劃，消減已發(fā)現(xiàn)的風(fēng)險(xiǎn)。產(chǎn)品原型會(huì)在本階段交付出來(lái)。
• 第三階段--執(zhí)行開(kāi)發(fā)和測(cè)試。
• 第四階段--涉及評(píng)估已開(kāi)發(fā)的內(nèi)容，并計(jì)劃開(kāi)展下一次迭代。

螺旋方法主要適用于高度定制化的軟件開(kāi)發(fā)。此外，用戶(hù)對(duì)于原型的反饋可以在迭代后期(在開(kāi)發(fā)階段)擴(kuò)展各項(xiàng)功能。

螺旋方法的優(yōu)勢(shì)

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

螺旋方法的缺點(diǎn)

• 它更關(guān)注成本收益。
• 它比其他SDLC方法更復(fù)雜。
• 它需要專(zhuān)家進(jìn)行風(fēng)險(xiǎn)分析。
• 由于嚴(yán)重依賴(lài)風(fēng)險(xiǎn)分析，因此倘若風(fēng)險(xiǎn)分析不到位，則可能會(huì)使整個(gè)項(xiàng)目變得十分脆弱。

DevOps方法

圖 6 DevOps方法

在傳統(tǒng)的軟件開(kāi)發(fā)方法中，開(kāi)發(fā)人員和運(yùn)維人員之間幾乎沒(méi)有協(xié)作。特別是在運(yùn)營(yíng)過(guò)程中，開(kāi)發(fā)人員往往被視為“構(gòu)建者”的角色。這就造成了溝通和協(xié)作上的差距，以及在反饋過(guò)程中出現(xiàn)混淆。而軟件開(kāi)發(fā)的DevOps方法恰好彌合了兩者之間的溝通鴻溝。其目標(biāo)是通過(guò)將開(kāi)發(fā)和運(yùn)營(yíng)團(tuán)隊(duì)有效地結(jié)合起來(lái)，以快速地開(kāi)發(fā)出更可靠的優(yōu)質(zhì)軟件。值得一提的是，DevOps也是一種將手動(dòng)開(kāi)發(fā)轉(zhuǎn)換為自動(dòng)化軟件開(kāi)發(fā)的方法。通常，DevOps方法會(huì)被劃分為如下5個(gè)階段：

• 持續(xù)開(kāi)發(fā)--此階段涉及到軟件應(yīng)用的規(guī)劃和開(kāi)發(fā)。
• 持續(xù)集成—此階段會(huì)將新的功能性代碼與現(xiàn)有的代碼相集成。
• 持續(xù)測(cè)試--開(kāi)發(fā)團(tuán)隊(duì)和QA測(cè)試人員會(huì)使用maven和TestNG等自動(dòng)化工具開(kāi)展測(cè)試，以確保在新的功能中掃清缺陷。自動(dòng)化測(cè)試為各種測(cè)試用例的執(zhí)行節(jié)省了大量時(shí)間。
• 持續(xù)部署--此階段會(huì)使用類(lèi)似puppet的配置管理工具、以及容器化工具，將代碼部署到生產(chǎn)環(huán)境(即服務(wù)器上)。它們還將協(xié)助安排服務(wù)器上的更新，并保持配置的一致性。
• 持續(xù)監(jiān)控—運(yùn)營(yíng)團(tuán)隊(duì)會(huì)在此階段通過(guò)使用Nagios、Relix和Splunk等工具，主動(dòng)監(jiān)控用戶(hù)活動(dòng)中的錯(cuò)誤、異常、不當(dāng)?shù)能浖袨?、以及軟件的性能。所有在此階段被發(fā)現(xiàn)的問(wèn)題都會(huì)被傳遞給開(kāi)發(fā)團(tuán)隊(duì)，以便在持續(xù)開(kāi)發(fā)階段進(jìn)行修復(fù)，進(jìn)而提高軟件的質(zhì)量。

DevOps的優(yōu)勢(shì)

• 促進(jìn)了合作。
• 通過(guò)持續(xù)開(kāi)發(fā)和部署，更快地向市場(chǎng)交付軟件。
• 最大化地利用Relix。

DevOps的缺點(diǎn)

• 當(dāng)各個(gè)團(tuán)隊(duì)使用不同的環(huán)境時(shí)，將無(wú)法保證軟件的安全。
• 涉及到人工輸入的過(guò)程時(shí)，可能會(huì)減慢整體運(yùn)營(yíng)的速度。

小結(jié)

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

事實(shí)上，軟件開(kāi)發(fā)并沒(méi)有所謂的“最佳”方法，它們往往各有利弊。因此在選擇具體方法之前，您需要了解待選方法對(duì)手頭項(xiàng)目的實(shí)用性。當(dāng)然，為了盡可能地采用最適合現(xiàn)有流程的方法，許多公司會(huì)同時(shí)使用兩種不同方法的組合，通過(guò)取長(zhǎng)補(bǔ)短來(lái)實(shí)現(xiàn)有效的融合，并相輔相成地完成軟件的交付任務(wù)。

譯者介紹

陳峻 (Julian Chen)，51CTO社區(qū)編輯，具有十多年的IT項(xiàng)目實(shí)施經(jīng)驗(yàn)，善于對(duì)內(nèi)外部資源與風(fēng)險(xiǎn)實(shí)施管控，專(zhuān)注傳播網(wǎng)絡(luò)與信息安全知識(shí)與經(jīng)驗(yàn);持續(xù)以博文、專(zhuān)題和譯文等形式，分享前沿技術(shù)與新知;經(jīng)常以線(xiàn)上、線(xiàn)下等方式，開(kāi)展信息安全類(lèi)培訓(xùn)與授課。

原文標(biāo)題：??The Complete Guide to SDLC??，作者：Mario Olomu