1 前言

由于我的本科專業(yè)為計(jì)算機(jī)科學(xué)，軟件工程不屬于我的必修課程，導(dǎo)致我雖然是計(jì)算機(jī)科班學(xué)生，卻缺乏軟件工程相關(guān)的知識(shí)。在實(shí)習(xí)招聘過(guò)程中，軟件工程知識(shí)，尤其是軟件過(guò)程模型相關(guān)的知識(shí)，常被問(wèn)及。因此正好借高級(jí)軟件工程期末博客的機(jī)會(huì)，記錄下自己課內(nèi)外對(duì)于軟件危機(jī)和軟件過(guò)程模型的一些收獲。

為江北等地區(qū)用戶提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及江北網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站、江北網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

2 軟件危機(jī)

軟件危機(jī)是指落后的軟件生產(chǎn)方式無(wú)法滿足迅速增長(zhǎng)的計(jì)算機(jī)軟件需求，從而導(dǎo)致軟件開(kāi)發(fā)與維護(hù)過(guò)程中出現(xiàn)一系列嚴(yán)重問(wèn)題的現(xiàn)象。由于軟件規(guī)模越來(lái)越大，軟件復(fù)雜性越來(lái)越高，可靠性問(wèn)題也越來(lái)越突出，軟件概念結(jié)構(gòu)的復(fù)雜性，無(wú)法達(dá)成軟件概念的完整性和一致性，迫切需要改變軟件生產(chǎn)方式，提高軟件過(guò)程效率，軟件危機(jī)隨之爆發(fā)。

有關(guān)軟件危機(jī)的爭(zhēng)論是從1975年的《人月神話》開(kāi)始的，F(xiàn)red Brooks在書中指出大型項(xiàng)目中難以匯集眾多軟件過(guò)程參與人員的設(shè)計(jì)理念，從而使得大型軟件項(xiàng)目往往會(huì)進(jìn)展緩慢、成本暴漲及錯(cuò)誤百出，這是軟件危機(jī)的典型體現(xiàn)。

1986年，Brooks發(fā)表了一篇著名的論文“沒(méi)有銀彈（No Silver Bullet: Essence and Accidents of Software Engineering）”，斷言“在10年內(nèi)無(wú)法找到解決軟件危機(jī)的殺手锏（銀彈）。

1990年，面向?qū)ο蠓治雠c設(shè)計(jì)領(lǐng)域的大師Brad Cox，針對(duì)Brooks的觀點(diǎn)，發(fā)表了一篇重要文章“有一個(gè)銀彈（There Is a Silver Bullet）”，以說(shuō)明他找到了應(yīng)對(duì)軟件危機(jī)的殺手锏，即經(jīng)濟(jì)上的利益誘導(dǎo)會(huì)促使人類將軟件組件內(nèi)的復(fù)雜結(jié)構(gòu)包裝起來(lái)，使得軟件組件簡(jiǎn)單易用，由這些組件整合而成的大型軟件，自然也簡(jiǎn)單易用，從而軟件危機(jī)得以化解。

1995年初，Brooks的名著《人月神話》第二版出版，書中的文章里Brooks贊揚(yáng)Brad Cox的文章，但他仍然認(rèn)為殺手锏仍未出現(xiàn)。

1995年底，作為回應(yīng)，Brad Cox發(fā)表了文章“No Silver Bullet Reconsidered”。文章里Brad Cox深刻探討了文化和思維范式的變遷，從人類文化的觀點(diǎn)闡釋軟件危機(jī)的原因，最終得到樂(lè)觀的結(jié)論：解決軟件危機(jī)的殺手锏（銀彈）是可能的。簡(jiǎn)單來(lái)說(shuō)，Brad Cox認(rèn)為可以利用軟件供應(yīng)鏈來(lái)鼓勵(lì)組織和個(gè)人生產(chǎn)、買賣軟件組件以及更小的子子孫孫組件。如果買賣各層組件者皆有利可圖，形成產(chǎn)業(yè)鏈，人們自然會(huì)想盡辦法將組件封裝得簡(jiǎn)單易用。

如今來(lái)看，Brooks的預(yù)測(cè)是千真萬(wàn)確的，軟件危機(jī)的困境依然沒(méi)有從根本上找到解決方法。

3 軟件過(guò)程模型

作為軟件工程延緩軟件危機(jī)的努力，軟件開(kāi)發(fā)過(guò)程模型應(yīng)運(yùn)而生。軟件開(kāi)發(fā)過(guò)程模型是指軟件開(kāi)發(fā)全部過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架。軟件開(kāi)發(fā)包括分析、設(shè)計(jì)、實(shí)現(xiàn)、交付和維護(hù)階段。 使用軟件開(kāi)發(fā)過(guò)程模型有以下幾點(diǎn)好處：

• 讓整個(gè)項(xiàng)目團(tuán)隊(duì)對(duì)軟件開(kāi)發(fā)過(guò)程有一致的理解（項(xiàng)目團(tuán)隊(duì)）
• 讓我們審視軟件過(guò)程中是否有活動(dòng)上的沖突，是否有重復(fù)勞動(dòng)和遺漏。（活動(dòng)本身）
• 在規(guī)劃軟件過(guò)程時(shí)，方便我們?yōu)樘囟ǖ哪繕?biāo)評(píng)估合適的軟件過(guò)程。（規(guī)劃）

3-1 瀑布模型

瀑布模型（Waterfall） 是最簡(jiǎn)單的軟件開(kāi)發(fā)歷史上第一個(gè)模型。瀑布模型將軟件生命周期劃分為制定計(jì)劃、需求分析、軟件設(shè)計(jì)、程序編寫、軟件測(cè)試和運(yùn)行維護(hù)等六個(gè)基本活動(dòng)，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級(jí)下落。瀑布模型易于理解，但是這種模型的線性過(guò)程太理想化，已不再適合現(xiàn)代的軟件開(kāi)發(fā)模式，幾乎被業(yè)界拋棄，其主要問(wèn)題在于：

• 各個(gè)階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量；
• 由于開(kāi)發(fā)模型是線性的，用戶只有等到整個(gè)過(guò)程的末期才能見(jiàn)到開(kāi)發(fā)成果，從而增加了開(kāi)發(fā)的風(fēng)險(xiǎn)；
• 早期的錯(cuò)誤可能要等到開(kāi)發(fā)后期的測(cè)試階段才能發(fā)現(xiàn)，進(jìn)而帶來(lái)嚴(yán)重的后果；

3-2 原型化的瀑布模型（快速原型）

由于瀑布模型在軟件過(guò)程的后期才能看到結(jié)果，會(huì)將各種風(fēng)險(xiǎn)積攢到后期，為了盡早暴露風(fēng)險(xiǎn)進(jìn)行風(fēng)險(xiǎn)控制，在瀑布模型的基礎(chǔ)上增加一個(gè)原型化階段，可以將風(fēng)險(xiǎn)前移。

原型就是根據(jù)需要完成的軟件的一部分，完成哪一部分是根據(jù)開(kāi)發(fā)原型的目標(biāo)確定。例如需求分析階段原型可以是用戶接口原型，可以有效地整理需求，提供直觀的反饋形式，有利于確認(rèn)需求是否被準(zhǔn)確理解；在設(shè)計(jì)階段，原型可能是系統(tǒng)架構(gòu)的一部分，有利于驗(yàn)證技術(shù)方案的可行性。

3-3 V模型

V模型也稱為V模型或驗(yàn)證與驗(yàn)證模型，是瀑布方法的擴(kuò)展。使用 V 模型時(shí)，進(jìn)度并不會(huì)直線移動(dòng)，而是在實(shí)施和開(kāi)發(fā)后逐漸上升。

對(duì)于V型項(xiàng)目，早期測(cè)試介入是與瀑布模型相比的主要區(qū)別。每個(gè)開(kāi)發(fā)階段都有一個(gè)并行測(cè)試階段，這有助于在繼續(xù)下一步之前驗(yàn)證和驗(yàn)證每個(gè)步驟。單元測(cè)試、集成測(cè)試和系統(tǒng)測(cè)試在不同層面驗(yàn)證設(shè)計(jì)，交付測(cè)試確認(rèn)需求是否得到滿足。

3-4 迭代和增量模型

迭代和增量模型將迭代設(shè)計(jì)和工作流與增量構(gòu)建模型結(jié)合在一起。在這種情況下，團(tuán)隊(duì)將按周期開(kāi)發(fā)產(chǎn)品，并以漸進(jìn)方式構(gòu)建小零件。開(kāi)發(fā)的交付策略分為兩種，一是增量開(kāi)發(fā)，二是迭代開(kāi)發(fā)。增量開(kāi)發(fā)就是從一個(gè)功能子系統(tǒng)開(kāi)始交付，每次交付會(huì)增加一些功能，這樣逐步擴(kuò)展功能最終完成整個(gè)系統(tǒng)功能的開(kāi)發(fā)。迭代開(kāi)發(fā)是首先完成一個(gè)完整的系統(tǒng)或者完整系統(tǒng)的框架，然后每次交付會(huì)升級(jí)其中的某個(gè)功能子系統(tǒng)，這樣反復(fù)迭代逐步細(xì)化最終完成系統(tǒng)開(kāi)發(fā)。

迭代和增量模型的一個(gè)有價(jià)值的特點(diǎn)是可以在不知道所有需求的情況下開(kāi)始開(kāi)發(fā)。該模型包含其他模型的步驟——需求收集，設(shè)計(jì)，實(shí)施和測(cè)試，但要經(jīng)過(guò)多次構(gòu)建。開(kāi)發(fā)團(tuán)隊(duì)可以利用先前構(gòu)建中取得的成就來(lái)改善下一構(gòu)建。迭代和增量模型可能看起來(lái)像一組微型瀑布模型或微型 V 形模型。

3-5 螺旋模型

螺旋模型是一種演化軟件開(kāi)發(fā)過(guò)程模型，兼顧了快速原型的迭代的特征以及瀑布模型的系統(tǒng)化與嚴(yán)格監(jiān)控。螺旋模型被認(rèn)為是最靈活的 方法之一。它從迭代模型及其重復(fù)中獲得啟發(fā)。該項(xiàng)目以“螺旋式”的方式反復(fù)經(jīng)歷四個(gè)階段，直到完成為止，從而可以進(jìn)行多輪改進(jìn)，在每個(gè)迭代階段，構(gòu)建原型是螺旋模型減小風(fēng)險(xiǎn)的基本策。迭代過(guò)程主要分為四個(gè)階段：制定計(jì)劃、風(fēng)險(xiǎn)分析、實(shí)施工程、客戶評(píng)估。

螺旋模型主要用于大型項(xiàng)目，它允許構(gòu)建高度定制的產(chǎn)品，并且用戶反饋可以在項(xiàng)目的早期就被納入。但可能有項(xiàng)目會(huì)形成永無(wú)止境的螺旋式發(fā)展的風(fēng)險(xiǎn)。

3-6 敏捷模型

敏捷模型是迭代和增量方法的組合，致力于通過(guò)早期交付工作軟件來(lái)適應(yīng)靈活的需求并滿足用戶和客戶的需求。敏捷項(xiàng)目中的需求和解決方案可能會(huì)在開(kāi)發(fā)過(guò)程中發(fā)展。

通過(guò)敏捷開(kāi)發(fā)，該產(chǎn)品被分為小的增量構(gòu)建，并以迭代方式交付。將所有任務(wù)劃分為較小的時(shí)間范圍，以便為每個(gè)版本準(zhǔn)備工作功能。最終產(chǎn)品版本包含所有必需的功能。敏捷開(kāi)發(fā)是技術(shù)行業(yè)中使用最廣泛的。敏捷軟件開(kāi)發(fā)生命周期有許多成熟的方法，最受歡迎的兩個(gè)是Scrum和看板。

4 總結(jié)

在我看來(lái)，軟件危機(jī)從未被真正解決，當(dāng)下一次應(yīng)用需求和開(kāi)發(fā)能力錯(cuò)位時(shí)可能還會(huì)出現(xiàn)（比如量子計(jì)算機(jī)的軟件開(kāi)發(fā)），但軟件工程會(huì)通過(guò)不斷地改進(jìn)和優(yōu)化軟件開(kāi)發(fā)過(guò)程來(lái)延緩這個(gè)危機(jī)。
高級(jí)軟件工程課程讓我受益頗多，課程內(nèi)容十分實(shí)用。Vscode和Git命令大大提升了我平時(shí)的開(kāi)發(fā)效率和編碼體驗(yàn)，軟件工程思想也給我?guī)?lái)了很多啟發(fā)，讓我在設(shè)計(jì)編碼時(shí)能衡量代碼架構(gòu)的合理性。本文所述的軟件開(kāi)發(fā)過(guò)程模型知識(shí)補(bǔ)足了我在軟件工程專業(yè)方面的短板，感謝老師一學(xué)期的陪伴和教導(dǎo)。

參考資料：代碼中的軟件工程 https://gitee.com/mengning997/se