論敏捷開發在企業軟件開發中的應用
論基于構件的軟件開發?
論軟件系統架構評估?
論高可靠性系統中軟件容錯技術的應用?
論軟件系統架構風格?

論軟件開發模型的選擇與應用

摘要：?

本文以一個招標業務系統的軟件開發過程為例，討論了軟件開發模型的選擇與應用。文章首先對項目特點進行了分析，然后對目前常用的開發模型——瀑布模型、演化模型、螺旋模型、敏捷開發模型的優缺點做了對比分析。根據項目實際情況，以及模型的特點，最終選定了敏捷開發模型。并說明了項目是如何應用敏捷開發模型完成開發工作的。最后簡要敘述了開發模型的演變趨勢和特征，和堅持以項目特點為主的開發模型選擇策略。 該項目是2010年3月為一家國內大型招標代理機構開發的業務運營系統，特點是：工期要求短、開發團隊小、技術難度低、需求不明確或不斷變化。我有幸作為技術負責人參與了該項目的開發工作，主要負責承擔該項目的需求分析和系統設計工作，并經過合理分析選擇采用敏捷開發模型順利完成任務，獲得各方一致好評。

正文：?

本人就職于一家國有大型外貿集團的信息管理部門，主要負責參與整個集團的信息系統的設計開發和維護管理工作。隨著人民幣匯率不斷升值、國內購買力不斷增強，外貿集團下屬的招標代理公司的招標業務量近年增長迅猛，過去人工管理的業務運作模式無法適應，成為制約公司業務發展的瓶頸。因此，該公司領導要求在較短的時間內迅速建立一套支持招標業務運營的信息系統，加快業務運作流程、提高工作效率和招標服務質量。該項目從2010年3月初開始啟動，經過信息部和招標公司的通力合作，歷時近6個月，至8月底完成驗收，并于9月1日正式啟用。我有幸作為技術負責人參與了該項目的開發工作，主要負責承擔該項目的需求分析和系統設計工作。 我經過調查分析發現：1、招標在國內尚屬比較新穎、特殊的一個行業，目前軟件業界尚無成型的招標軟件產品可供引進或者借鑒。2、但該項目技術難度要求不高，我們可以依靠本部門技術力量自主研發。3、該公司各業務部門的招標類型不同，操作手法不一，因而需求目標模糊、界定困難，而且隨著招標業務的發展，需求還可能不斷變化。4、由于業務部門需求迫切，招標公司領導要求盡快實現啟用。根據上述情況，我與項目小組的技術人員經過充分的討論分析，對當前流行的幾種開發模型進行了比較和選擇： 瀑布模型按軟件生存周期各階段固定順序開發，要求大量文檔配合，工作量大、缺乏靈活性，可能直到開發完成才發現不符合客戶需求。該方式比較適合需求明確、有類似成功案例參照模仿的項目，因此不適合招標業務系統的開發需要。 演化模型（原型法）先根據基本需求快速構造可運行版本——原型，再根據客戶反饋重復不斷改進至令客戶滿意。它雖然能解決需求不明確的問題，但其風險是：開發效率低、項目進度和預算難以控制，因此也不適合招標業務系統快速開發的需要。 螺旋模型將瀑布模型和演化模型相結合，它強調了其他模型所忽視的風險分析，特別適合于大型復雜的系統，而反復迭代也導致工期較長。而招標業務系統規模有限、技術難度低且工期有限，因此不宜采用螺旋模型。 對于這種工期要求短、開發團隊小、技術難度低、需求不明確或不斷變化的項目，我經過分析比較后認為最適合采用“敏捷開發”的輕量級開發方法，而實際開發應用過程也證明了這一選擇的正確性： 敏捷開發首先要求“客戶直接參與”，敏捷宣言中的一句是“客戶合作勝過客戶談判”。意思是讓客戶參與到項目中，通過緊密的合作來實現項目開發，要比合同談判效果好得多。項目開發過程中需要客戶及時地、頻繁地進行反饋，因此將客戶經常拉到開發現場，就是成功地開始。在項目開發過程中，由于招標公司領導層非常重視，主動召開動員會議，積極發動業務人員參與配合，因而需求調查工作迅速鋪開。但在調查的過程中，我覺得客戶的代表性很重要： <1>參與的客戶必須對自身從事的招標業務非常熟悉，能夠對相關問題給出正確而全面的反饋意見。 <2>由于招標公司各業務部門的招標類型不同，操作手法存在差異，客戶參與過程中更多的是從部門角度出發考慮問題。因而我們不能偏聽一方，需要綜合各方意見，全盤考慮。因此，我向招標公司領導要求：每一個部門都安排一名資深業務員參與到項目中來，配合需求分析、模塊試用和反饋意見。在招標公司的積極參與配合下，項目開展順利、沒走多少彎路。 <3>敏捷開發的另一個特點是“小版本發布”，要求經常提交可工作的軟件，間隔越短越好。由于敏捷開發奉行“客戶合作、客戶參與”，而要讓客戶更加有效的參與，經常性地、頻繁地交付可工作的中間軟件版本，將可以有效地加強開發人員于客戶之間的溝通，從而將隱藏的錯誤和需求變化及早發現和觸動。在具體的開發過程中，我們依據招標業務的流程順序，從“項目立項建檔、招標公告發布、評標專家抽選”，到“標書發售、保證金收退、開標評標中標”，直至“結果公示、收中標費、結案評審、項目歸檔”，逐個環節依次開發提交，平均每周發布一次。因此，招標公司領導能夠根據我們不斷提供的最新中間版本了解項目進展，配合協同組織工作；各部門的用戶代表能夠及時參與試用和反饋意見。 敏捷開發還有一個特點是“較少的文檔”，敏捷宣言中提出“可以工作的軟件勝過面面俱到的文檔”。對于開發團隊而言，各種文檔規范越繁多越細致，真正用于開發的時間就越少，開發速度和效率也就越低；對于客戶而言，真正能夠產生價值的東西是可以工作的軟件，而非這些面面俱到的文檔。在實際開發過程中，為節省時間、加快開發效率，我們對要編寫的文檔類型進行了裁減，例如：由于項目規模小、技術難度低，對項目成功很有把握，因此省略了“可行性研究報告”。我們也對必須編寫的文檔的進行了簡化，例如：我們大量采用草圖直接勾畫用戶操作界面，并附加文字說明的方式，與客戶進行直觀的溝通交流，經客戶認可后的，做成示意圖直接加入“需求說明書”和“設計說明書”，簡化了文檔的文字編寫，也更直觀清晰。當然，“較少的文檔”并不是說不要文檔。為了保證項目的開發質量和后繼的維護工作，以及客戶培訓工作的順利進行，我們對“數據庫設計說明書”、“用戶操作手冊”等文檔還是做了認真細致的編輯。 最終這個項目在工期短、需求不明確等困難下，依靠敏捷開發方法的思想指導和實踐應用，在有關領導、開發團隊和用戶的積極配合、共同努力下順利完成，獲得一致好評。 隨著軟件技術的迅速發展和市場變化，新的軟件開發模型也不斷出現，如：噴泉模型、RUP模型、智能模型（四代技術4GL）等。這些開發模型都是結合各種新技術、新變化而發展演變的，都有各自的優點和缺點，在實際應用中存在著許多不足和局限性。我們應該注意分析區別各種開發模型的適用對象、范圍，堅持以項目為主，根據實際開發的項目特點來選擇合適的開發模型。需要考慮的因素包括：需求是否明確或變化；項目的規模、技術難度、風險與開發團隊的力量、水平；項目的工期限制等，這樣才能選擇合適的開發模型，并順利的應用到項目開發中。

總結

以上是生活随笔為你收集整理的2019年架构软考论文押题（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

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