1 前言
由于我的本科專業為計算機科學，軟體工程不屬于我的必修課程，導致我雖然是計算機科班學生，卻缺乏軟體工程相關的知識，在實習招聘程序中，軟體工程知識，尤其是軟體程序模型相關的知識，常被問及，因此正好借高級軟體工程期末博客的機會，記錄下自己課內外對于軟體危機和軟體程序模型的一些識訓，
2 軟體危機
軟體危機是指落后的軟體生產方式無法滿足迅速增長的計算機軟體需求，從而導致軟體開發與維護程序中出現一系列嚴重問題的現象，由于軟體規模越來越大，軟體復雜性越來越高，可靠性問題也越來越突出，軟體概念結構的復雜性，無法達成軟體概念的完整性和一致性，迫切需要改變軟體生產方式，提高軟體程序效率，軟體危機隨之爆發，
有關軟體危機的爭論是從1975年的《人月神話》開始的，Fred Brooks在書中指出大型專案中難以匯集眾多軟體程序參與人員的設計理念，從而使得大型軟體專案往往會進展緩慢、成本暴漲及錯誤百出，這是軟體危機的典型體現，
1986年，Brooks發表了一篇著名的論文“沒有銀彈（No Silver Bullet: Essence and Accidents of Software Engineering）”，斷言“在10年內無法找到解決軟體危機的殺手锏（銀彈），
1990年，面向物件分析與設計領域的大師Brad Cox，針對Brooks的觀點，發表了一篇重要文章“有一個銀彈（There Is a Silver Bullet）”，以說明他找到了應對軟體危機的殺手锏，即經濟上的利益誘導會促使人類將軟體組件內的復雜結構包裝起來，使得軟體組件簡單易用，由這些組件整合而成的大型軟體，自然也簡單易用，從而軟體危機得以化解，
1995年初，Brooks的名著《人月神話》第二版出版，書中的文章里Brooks贊揚Brad Cox的文章，但他仍然認為殺手锏仍未出現，
1995年底，作為回應，Brad Cox發表了文章“No Silver Bullet Reconsidered”，文章里Brad Cox深刻探討了文化和思維范式的變遷，從人類文化的觀點闡釋軟體危機的原因，最終得到樂觀的結論：解決軟體危機的殺手锏（銀彈）是可能的，簡單來說，Brad Cox認為可以利用軟體供應鏈來鼓勵組織和個人生產、買賣軟體組件以及更小的子子孫孫組件，如果買賣各層組件者皆有利可圖，形成產業鏈，人們自然會想盡辦法將組件封裝得簡單易用，
如今來看，Brooks的預測是千真萬確的，軟體危機的困境依然沒有從根本上找到解決方法，
3 軟體程序模型
作為軟體工程延緩軟體危機的努力，軟體開發程序模型應運而生，軟體開發程序模型是指軟體開發全部程序、活動和任務的結構框架，軟體開發包括分析、設計、實作、交付和維護階段， 使用軟體開發程序模型有以下幾點好處：
- 讓整個專案團隊對軟體開發程序有一致的理解（專案團隊）
- 讓我們審視軟體程序中是否有活動上的沖突，是否有重復勞動和遺漏，（活動本身）
- 在規劃軟體程序時，方便我們為特定的目標評估合適的軟體程序，（規劃）
3-1 瀑布模型
瀑布模型（Waterfall） 是最簡單的軟體開發歷史上第一個模型，瀑布模型將軟體生命周期劃分為制定計劃、需求分析、軟體設計、程式撰寫、軟體測驗和運行維護等六個基本活動，并且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落，瀑布模型易于理解，但是這種模型的線性程序太理想化，已不再適合現代的軟體開發模式，幾乎被業界拋棄，其主要問題在于：
- 各個階段的劃分完全固定，階段之間產生大量的檔案，極大地增加了作業量；
- 由于開發模型是線性的，用戶只有等到整個程序的末期才能見到開發成果，從而增加了開發的風險；
- 早期的錯誤可能要等到開發后期的測驗階段才能發現，進而帶來嚴重的后果；
3-2 原型化的瀑布模型（快速原型）
由于瀑布模型在軟體程序的后期才能看到結果，會將各種風隙訓攢到后期，為了盡早暴露風險進行風險控制，在瀑布模型的基礎上增加一個原型化階段，可以將風險前移，
原型就是根據需要完成的軟體的一部分，完成哪一部分是根據開發原型的目標確定，例如需求分析階段原型可以是用戶介面原型，可以有效地整理需求，提供直觀的反饋形式，有利于確認需求是否被準確理解；在設計階段，原型可能是系統架構的一部分，有利于驗證技術方案的可行性，
3-3 V模型
V模型也稱為V模型或驗證與驗證模型，是瀑布方法的擴展，使用 V 模型時，進度并不會直線移動，而是在實施和開發后逐漸上升，
對于V型專案，早期測驗介入是與瀑布模型相比的主要區別，每個開發階段都有一個并行測驗階段，這有助于在繼續下一步之前驗證和驗證每個步驟，單元測驗、集成測驗和系統測驗在不同層面驗證設計，交付測驗確認需求是否得到滿足，
3-4 迭代和增量模型
迭代和增量模型將迭代設計和作業流與增量構建模型結合在一起，在這種情況下，團隊將按周期開發產品，并以漸進方式構建小零件，開發的交付策略分為兩種，一是增量開發，二是迭代開發，增量開發就是從一個功能子系統開始交付，每次交付會增加一些功能，這樣逐步擴展功能最終完成整個系統功能的開發，迭代開發是首先完成一個完整的系統或者完整系統的框架，然后每次交付會升級其中的某個功能子系統，這樣反復迭代逐步細化最終完成系統開發，
迭代和增量模型的一個有價值的特點是可以在不知道所有需求的情況下開始開發，該模型包含其他模型的步驟——需求收集，設計，實施和測驗，但要經過多次構建，開發團隊可以利用先前構建中取得的成就來改善下一構建，迭代和增量模型可能看起來像一組微型瀑布模型或微型 V 形模型，
3-5 螺旋模型
螺旋模型是一種演化軟體開發程序模型，兼顧了快速原型的迭代的特征以及瀑布模型的系統化與嚴格監控，螺旋模型被認為是最靈活的 方法之一，它從迭代模型及其重復中獲得啟發，該專案以“螺旋式”的方式反復經歷四個階段，直到完成為止，從而可以進行多輪改進，在每個迭代階段，構建原型是螺旋模型減小風險的基本策，迭代程序主要分為四個階段：制定計劃、風險分析、實施工程、客戶評估，
螺旋模型主要用于大型專案，它允許構建高度定制的產品，并且用戶反饋可以在專案的早期就被納入，但可能有專案會形成永無止境的螺旋式發展的風險，
3-6 敏捷模型
敏捷模型是迭代和增量方法的組合，致力于通過早期交付作業軟體來適應靈活的需求并滿足用戶和客戶的需求，敏捷專案中的需求和解決方案可能會在開發程序中發展，
通過敏捷開發，該產品被分為小的增量構建，并以迭代方式交付，將所有任務劃分為較小的時間范圍，以便為每個版本準備作業功能，最終產品版本包含所有必需的功能，敏捷開發是技術行業中使用最廣泛的，敏捷軟體開發生命周期有許多成熟的方法，最受歡迎的兩個是Scrum和看板，
4 總結
在我看來，軟體危機從未被真正解決，當下一次應用需求和開發能力錯位時可能還會出現（比如量子計算機的軟體開發），但軟體工程會通過不斷地改進和優化軟體開發程序來延緩這個危機，
高級軟體工程課程讓我受益頗多，課程內容十分實用，Vscode和Git命令大大提升了我平時的開發效率和編碼體驗，軟體工程思想也給我帶來了很多啟發，讓我在設計編碼時能衡量代碼架構的合理性，本文所述的軟體開發程序模型知識補足了我在軟體工程專業方面的短板，感謝老師一學期的陪伴和教導，
參考資料：代碼中的軟體工程 https://gitee.com/mengning997/se
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/498968.html
標籤：其他