2019年上半年軟考成績出來查完松了一口氣，也在預料之中論文涉險過關。雖然沒壓中題目不過使用的案例和相關的點都一樣，硬著頭皮寫完。 去年的架構論文昏昏沉沉的兩個小時才寫了1900字，這回龍飛鳳舞寫居然提前15分鐘寫完了。把文章公布出來僅供參考，案例是不能再用了。

論軟件開發模型的應用
摘要：
軟件開發模型能清晰、直觀地表達軟件開發全過程，明確規定了要完成的主要活動和任務，用來作為軟件項目工作的基礎。對于不同的軟件系統，可以采用不同的開發方法、運用不同的管理方法和手段等，以及允許采用不同的軟件工具和不同的軟件工程環境。針對不同的項目使用不同的開發模型能夠有效的提高項目成功率。
本文將結合某省級《機動車駕駛員計時培訓系統》的開發過程介紹，如何在中型的管理系統中使用“統一過程過程模型UP“與”敏捷開發方法（SCRUM）“，并結合面向服務的微服務開發方法完成整個軟件項目。在該項目中本人擔任系統規劃、分析及架構設計的工作。本文將著重討論統一過程模型UP與敏捷開發方法SCRUM在項目中的各實施步驟和取得的效果。最后本文還將討論本項目開發時碰到的困難和存在的問題。
正文：
2017年初本人接受了某公司的委托負責組織人員開發某省的《機動車駕駛員計時培訓系統》。項目包含了軟件部分、車載終端部分、服務器、網絡、安裝調試等。項目使用范圍涵蓋省級主管部門、所有地級市以上的駕考培訓機構和主管部門。本人在該項目中除了負責部分組織協調工作以外，主要負責軟件部分的需求分析和架構設計工作。該系統需要按照交通運輸部2016年修訂的《機動車駕駛員計時培訓系統平臺技術規范》來進行開發。該項目的中標公司是一家負責交通路網工程的公司，并沒有太多的軟件開發背景，造成了后期運維相當困難。公司高層決定基于這一項目培養自己的軟件開發和運維團隊。本人在基于以上相關因素初步確定了軟件的開發模型和系統架構。
傳統的軟件開發模型有瀑布模型、原型模型、增量模型、螺旋模型、噴泉模型、統一過程模型、敏捷開發方法。最早的瀑布模型嚴格遵循工程化的思想，規劃、分析、設計、評審、構建、驗收、交付每一步都需要上一步的結果做為輸入。原型模型則是快速開發一個小型版本并不斷演化或拋棄，對于規模不大，需求不明確的項目有較好的效果。螺旋模型則是瀑布模型和原型模型的綜合強調了風險的控制。噴泉模型是早期的面向對象開發模型，核心特點是迭代，分析、設計、編碼等活動的邊界不明顯允許交叉進行。統一過程模型UP是一套完整的開發組織方式，核心是用例驅動、架構為中心、迭代與增量。分為初始、細化、構建、交付四個階段。敏捷方法同樣也是基于面向對象的，強調的是可工作的軟件強于繁瑣的文檔，并且敏捷方法提出了許多實用性的軟件開發方法。敏捷方法可以做為統一過程模型的一個補充來使用。
針對本項目的特點我們確定了采用統一過程模型UP與敏捷開發SCRUM結合的方式進行。
在仔細閱讀了《技術規范》后得到了兩點結論，一、規范中已經將《監管服務平臺》和《計時平臺》所應具有的功能描述得比較詳盡?？梢灾苯訉⑽募械南嚓P說明直接轉化為用例。這就符合UP中用例為中心的思想。二、《技術規范》中將個省級平臺中的靜態數據同步接口全部統一成為restful的方式，并且強調了采用事件驅動的方式進行?；谶@點決定了該系統的中心架構是基于事件驅動的微服務架構。這也符合UP模型的以架構為中心的思想。
敏捷方法SCRUM的核心是用戶故事，不同于傳統的用例、用戶故事可以是一個較為模糊的需求描述，在開發時將分析與設計的權利都賦予具體的設計人員，在例如預約教練、預約考試、支付管理、刷卡、刷臉、登記等受眾面廣、強調用戶體驗的功能時，能夠更快的發布新版本。
遵循UP模型分為下面四個階段
在初始階段
1.識別系統的主要參與者，通過分析《技術規范》中所要求的功能模塊整理出主要參與者如：全國駕培平臺、省級交管部門、市級交管部門、駕駛培訓機構、教練車終端、教練、學員等。識別主要參與者的目的是為了更好的劃定系統邊界。
2.確定項目邊界，制定大體的開發計劃。在這個階段的工作對于項目的成敗非常關鍵。在調研時發現各市級交管部門已經有在運行的計時培訓系統但規則和管理范圍都不一致，且系統管理的范圍也不一致。因此為了防止需求蔓延在與省級交管部門開會時就明確了，所有教練車終端數據直接通過Socket通訊方式傳輸給省級平臺不再直接與原市級平臺對接，市級平臺通過省級平臺統一的restful接口獲取數據，原有市級平臺的改造由各地市負責不列入此項目。類似的項目風險在第一輪與第二輪迭代中還有很多，此處不一一列舉。
3.定立系統的業務模型、建立系統目標里程碑完成初始階段。訂立目標就是建立省級監管服務平臺、和省級計時平臺，全省教練車終端與省級計時平臺時時通訊。兩個平臺與相關的系統有統一的靜態通訊接口。
在細化階段首先制定需求獲取方案。監管部門相關人員采用訪談、開會等方式進行。對于駕駛培訓機構相關人員采用采樣、觀摩、問卷調查等方式進行。然后需求分析階段進一步細化參與者和用例，并確定用例之間關系。確定了系統的總體框架后利用效用決策樹將系統的基礎服務和重要服務構件排序，確定開發順序并分配開發小組。將例如車載認證、場地同步、終端學時同步、地圖GIS繪制等服務列為關鍵的高風險點重點開發并提供備選方案；將培訓機構、教練車、教練、學員的服務等列為優先開發的基礎服務；將監督、投訴、評價等列為非重點服務，將預約、收費、檢查等列為第三方服務。最后制定出詳細的開發進度表。
在系統構建階段，在此階段大部分的服務采用敏捷開發SCRUM的方式分小組進行。敏捷開發做為統一過程模型的補充我們在此項目中主要經借鑒了SCRUM幾個方法。一、用戶故事。在細化階段并不能將所有的用例都一一細化，需求獲取、分析在開發階段常常也一直在迭代進行，因此需要在一些服務開發時將分析的權利放到設計師頭上，充分發揮軟件設計師和前端設計師的作用。二、使用燃盡圖代替甘特圖等繁重的項目管理文檔，同時也避免了口頭匯報工作的不準確性。三、站立會議每天的短暫會議可以了解小組成員開發時碰到的困難以便按能力和興趣重新分配任務。或成員間提供技術幫助。
我們按照開發計劃將受眾面廣、并發高的20%的功能做為第一輪分析、設計和構建的重點，由核心小組的成員完成。剩余80%的功能由有經驗的軟件設計師和前端工程師帶領在校學生或實習生完成。這樣安排原因有兩點，一、本項目整體是基于面向對象的方法學進行開發的。對于使用關系數據庫開發項目經驗越豐富的開發者面向過程的思維就難以轉變，會造成項目代碼嚴重依賴數據結構。這與我們采用的微服務架構相背。采用實習生可以將“系統結構存在與對象之間，數據庫只是對象的持久化工具”的思想灌輸給他們，也有利于培養后期運維隊伍。二、采用校企合作或實習生可以有效降低工資成本。
交付階段我們在關鍵服務完成80%的時候就開始與在部分地市開始與車載終端的安裝進行部署與聯調。在第二與第三輪迭代完成全部的安裝、測試工作。在此階段同時將一些開發人員轉成后期維護人員，專門閱讀文檔和編寫測試用例。
本系統在2017年10月份完成主體功能，2018年初隨車載終端在部分地市聯合調試運營，2018年底完成了一期投資所要求的所有功能服務。由于該項目是與駕校合作從學員培訓費中回收投資成本，因此后期的運維團隊格外重要。基于前面所采用的開發策略，后期的維護人員直接從開發人員中轉換過來保證了技術連續性這也是本項目的一大特點。
雖然本項目采用面向對象的方法和敏捷開發來應對需求變化但開發過程中還是由于政策變化導致了部分服務完全重構。在做系統的分析和設計時都是基于《技術規范》，該規范還是以面向過程的方法為核心，假定系統已經存在來規定系統應該做什么，這樣導致我們前期抽象用例時有很多不準確的地方，帶到開發階段導致迭代次數過多發布了一些無用的版本。但總體來說項目還是較為成功的。

總結

以上是生活随笔為你收集整理的为软考准备的论文！！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。