軟體工程是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。下面是小編為大家整理的軟體工程的發展碩士論文，歡迎閱讀。
摘要：軟體工程是一類工程。工程是將理論和知識應用於實踐的科學。就軟體工程而言，它借鑑了傳統工程的原則和方法，以求高效地開發高質量軟體。其中應用了電腦科學、數學和管理科學。本文只要闡述軟體工程的發展過程及其發展趨勢。
關鍵詞：軟體工程；模型；迭代；
1.軟體工程概述
20世紀六七十年代，計算機硬體技術有了很大的發展，為計算機的廣泛應用創造了條件，並要求軟體與之相適應。當時的軟體生產具有個體化、作坊式特點，開發工具落後，開發平臺單一，程式設計語言功能差。尤其是軟體維護工作，耗費大量的人力、物力和計算機資源，許多程式的個體化特性使得它們無法修改和維護。有的乾脆廢棄原有系統不用，從頭編寫新軟體。與此同時，軟體的規模越來越大，結構越來越複雜，軟體管理和維護困難，開發費用不斷增加。這種軟體開發技術、開發工具和生產方式落後的狀況與計算機應用迅速普及和對軟體的需求日益增加形成了尖銳的矛盾，由此而產生了“軟體危機”。軟體危機的產生使計算機軟體專家認識到軟體開發必須以新的方法作指導，原有的軟體開發方法必須改變，他們決定把工程技術的思想引入軟體開發領域，使軟體開發走上工程學科的途徑，以擺脫日益嚴重的.軟體危機。於是，美國和西歐的一些科學家在1968年的NATO(北大西洋公約組織)會議上第一次提出了“軟體工程”這個名詞，是利用工程學的方法開發和維護計算機軟體的一門學科。從此，軟體工程作為-- F～I 學科正式誕生，人們開始了軟體工程的研究。
2.軟體工程發展過程中常用模型
軟體的質量因素很多，如正確性、可靠性、容錯性、易用性、靈活性、可擴充性、可理解性、可維護性等等。有些因素相互重疊，有些則相牴觸，真要提高質量可不容易啊!軟體工程的主要環節有：人員管理、專案管理、可行性與需求分析、系統設計、程式設計、測試、維護等。
軟體工程模型建議用一定的流程將各個環節連線起來，並可用規範的方式操作全過程，如同工廠的生產線。常見的軟體工程模型有：瀑布模型(線形模型)，漸增式模型，螺旋模型，快速原型模型等。
最早出現的軟體工程模型是線性模型(又稱瀑布模型)。線性模型太理想化，太單純，已不再適合現代的軟體開發模式，幾乎被業界拋棄。偶而被人提起。都屬於被貶物件．未被留一絲惋惜。但我們應該認識到，“線性”是人們最容易掌握並能熟練應用的思想方法。當人們碰到一個複雜的“非線性”問題時，總是千方百計地將其分解或轉化為一系列簡單的線性問題，然後逐個解決。一個軟體系統的整體nf能是複雜的，而單個子程式總是簡單的，可以用線性的方式來實現，否則幹活就太累了。線性是一種簡潔，簡潔就是美。當我們領會了線性的精神。就不要再呆板地套用線性模型的外表，而應該用活它。例如漸增式模型實質就是分段的線性模型，如圖3所示。螺旋模型則是接連的彎曲了的線性模型。在其它模型中都能夠找到線性模型的影子。 畢業
3.軟體工程的發展變化
國外很多專案的開發都是基於一些圖形化的東西來做的，他們的日的是儘量少寫程式碼甚至不寫程式碼。程式碼能夠通過圖形化的方式自動生成，這樣的一個好處就是如果使用者的需求變化或者業務邏輯發生變化，我們需要做的就是對圖形表示的調整。然後重新自動生成程式碼，這也就是國外開發很注重對專案的概念和邏輯分析的原因。
他們的重點是把業務規則和需求用圖形化的方式表現出來，然後通過CASE工具自動生成程式碼。所以當國人還在不停的開發一個又一個的MIS工具的時候，國外已經把很多精力放到了CASE工具的製作上。
社會進步的一個很明顯的現象就是社會分工越來越細，軟體的開發也不例外。為什麼在軟體開發的今天已經不能出現象裘伯君這樣的軟體英雄的原因也在這裡，單憑個人之力，我們也許窮盡有生之年也開發不出象Windows這樣的作業系統。因為。當前軟體行業的壁壘無非就是兩個，一個就是以技術創新取勝，你模仿的了其中的介面，但是你沒有辦法實現其中的核心功能。結果是你只能購買其技術核心，而你作一些邊角工作。不舉別的例子，比如VB這樣的開發工具，其核心部分是它和第三方提供的COM控制元件或者是DLL函式庫，你所做的就是一個整合的工作。
4.軟體工程發展的趨勢
由於計算能力向伺服器端的快速集中，提供高平行計算能力和可用性的中介軟體技術被廣泛採用，甚至已經成為構建大型軟體系統的必選項；軟體工程會如何發展呢?我覺得在未來幾年我們會看到如下的趨勢：
迭代、敏捷，漸成標準：隨著軟體交付週期的日益加快，迭代化開發已經成為大多數軟體開發團隊的必選項。但是迭代對整個團隊的需求、架構、協同及測試能力都提出了更高的要求，現在許多開發團隊都在試圖匯入迭代化開發的過程中，敏捷可是被看成迭代化開發的一種匯入方式。這不過敏捷的範圍其實比迭代化開發更大一些。
持續整合，蓄勢待發：持續整合是保證迭代化開發質量的主要方式，通過持續整合可以利用自動化的方式來儘量自動地、儘早保證程式碼質量。隨著迭代和敏捷的流行，持續整合相關的工具成為現在市場上的新熱點(如持續整合框架IBM RationalBuitdForge，開源軟體CruiseControl，程式碼靜態分析工具Klocworklnsight,IBM Rational Software Analyzer等)。
持續整合是一個複雜的系統工程，組織需要首先將現有的配置管理／變更管理工具與Build環境緊密整合並完成自動化Build過程，在根據企業／專案／產品的現狀，定義如何自動化地檢測軟體質量(程式碼靜態分析、單元測試或冒煙測試)，並定義需要自動化生成的管理報表。
需求工程，漸成熱點：專業化的角色，日益複雜的業務創新，全球分佈的團隊以及網際網路級的交付速度，這些都對需求獲取的正確性和有效性提出了更高的要求；同時，需求分析員又可以方便地通過用例分析(use case analysis)將需求體系精華成分析模型。在這一過程中，需求分析員可以更進一步地完善基於用例的需求體系，而不必擔心分析模型會汙染需求，從而實現需求與分析的分離及有效互動。
參考文獻：
[1]史濟民等．軟體工程．高等教育出版社，2002．
[2]張海藩．軟體工程導論．清華大學出版社．
[3]馬承志．PowerBuilder 8．0程式設計例項與技巧，機械工業出版社
[4]崔杜武，PowerBuilder 8．0從基礎到應用．人民郵電出版社． 畢