軟件工程是指導計算機軟件開發和維護的工程學科。軟件工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義。比較認可的一種定義認為：軟件工程是研究和應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟件，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來。軟件工程一直以來都缺乏一個統一的定義，很多學者、組織機構都分別給出了自己的定義。如何寫好軟件工程論文？具體如下：
軟件工程方向的專業論文選題，按照目前培養方案的要求，必須是與軟件工程有關的內容。
所謂與軟件工程有關的內容包括：
1. 軟件的開發
這是最常見的選題方向，也是最正規、最容易得到認可的方向。一般來說，軟件開發的題目，可以是一個系統，也可以是一個或者幾個模塊。不過，不論是系統還是模塊，都要包括如下幾個階段：
a） 需求分析
b） 概要（總體）設計和詳細設計
c） 編碼（是指重要的、關鍵的算法部分）
d） 部署和測試
2. 軟件工程的其它方向內容
例如：
a） 軟件需求管理、變更
b） 軟件體系架構
c） 軟件測試 （軟件測試方向的論文大綱參見博文《軟件測試相關碩士論文大綱》）
d） 軟件過程改進
e） 更多內容，參見《軟件工程知識體系指南》
論文的素材
需要特別強調的是，論文絕不是一周兩周閉門造車就能寫出來的。日常工作中要不斷撰寫相關工作的需求分析、概要設計、詳細設計、數據庫設計、關鍵算法、測試用例、測試結果等方面的文檔。這些文檔，都是論文的素材。
論文工作所描述的軟件開發可以是一個完整系統，也可以是某個系統中的多個模塊。最好能夠按照瀑布模型，覆蓋需求、設計（概要/詳細）、編碼及測試這幾個階段。
摘要 【關于摘要的寫法，參見博文《如何撰寫論文的摘要》】
1. 序言
介紹論文的課題來源、課題實施的背景、課題預期達到的目標等
1.1 課題背景（課題來源、選題目的和意義）
1.2 課題任務（本課題的整體研究/開發內容）
1.2.1 課題內容（介紹課題的主要內容）
1.2.2 本人承擔任務（作者在該課題中所做的主要工作。作者的工作可能僅是課題研究內容的一部分。這一部分必須有，是評閱人及答辯委員重點看的內容）
1.3 論文結構（描述論文的整體結構，以及每一章節的主要內容）
2. 相關技術
介紹論文中用到的所有重要的技術，對其原理及使用方法做簡單介紹 （但是不要介紹這些常見技術：Android、
注意：在論文其它章節不可再出現原理性的技術介紹
3. 需求分析（功能需求、性能/安全//界面需求等）：必須使用用例圖分析！
3.1 業務建模（如果需要的話，可以在本節中描述使用本軟件系統的企業/組織機構在執行業務時的流程。業務建模重點描述企業執行某種業務時要遵循的流程以及涉及到 的人員和角色。這里基本不涉及到軟件，也不需要描述軟件。即，企業不使用軟件，也要遵循的業務流程）
3.1.1 組織圖（畫出本軟件相關業務中所涉及的企業組織結構圖，在這個組織圖中，包含業務涉及到的人員及其角色，然后說明這些角色的任務職責等）
3.1.2 業務流程1 （使用活動圖/流程圖描述業務流程）
3.1.3 業務流程2
3.1.n 業務流程k
3.2 總體需求（給出總體用例圖，然后描述每個用例的執行流程）
3.3 功能1需求分析（給出功能1的細化用例圖，描述每個子用例的執行流程）
3.4 … （功能n需求分析）（給出功能n的細化用例圖）
3.5 性能需求（如果有）
3.6 安全性需求（如果有）
3.7 界面需求（描述界面設計的一些基本要求，比如色彩、布局、字體等。具體的界面設計，放到詳細設計階段處理）
3.8 … （其它需求）
補充說明：
1）關于需求分析的具體寫法，不要自己編，或者將項目工程建議書中的東西直接拿來使用。請點擊【百度文庫中的文檔】
2）在需求分析章節中，不可出現“模塊”、“子系統”等字樣。這些字樣是設計階段才應該有的概念。
4. 概要設計（包括系統架構。若系統架構特別復雜，也可單列一章。概要設計內容，可以參見百度百科的“概要設計”詞條）
4.1 系統整體結構（本節必須有，否則論文不合格）（本節內容必須要有功能結構圖，即用一張圖表現系統中各個功能模塊/子系統之間的層次、先后關系）
4.2 模塊間接口設計
4.3 數據庫總體設計（本節指數據庫整體設計，給出ER圖并簡要說明即可，也可以在ER圖之外再增加對每張表的簡要說明。但是不涉及表的具體結構，僅說明表間關系，以及數據庫與其他模塊間關系）
4.4 系統部署結構（一般是指你的軟件系統所運行的服務器群組及網絡環境的拓撲）
4.5 界面結構 （這里是對界面需求的細化和展示。這里展示的是軟件總體上的界面結構，而不是每一個功能、頁面的界面結構。比如，可以用線框圖描繪一個基于web的界面分為三個部分：上面的LOGO區，左側的導航區，右側的功能展示區，下部的輔助鏈接區。但是，也僅僅局限于一個大致的、抽象的結構。）
4.6 …
5. 詳細設計（包括各個模塊/類/函數的設計，以及數據庫的設計）
5.1 xxx模塊設計
5.2 xxx模塊設計
5.3 數據庫表結構設計（具體的表結構）
5.4 數據庫查詢接口設計（如果有）
5.5 人機交互接口設計（如果有）
5.5 xxx接口設計
5.6 界面設計 （這里可以用線框圖描繪每一個模塊/功能頁面的界面布局、色彩、文本、字體要求。！！！但是絕對不可以用截圖！！！ 因為截圖是實現階段才有的！）
5.7 …
6. 實現（其中可以包括關鍵算法的少量代碼，論文所有代碼不超過100行），盡量避免粘貼代碼，代之以相應的流程圖或者活動圖。非關鍵的代碼會被認為有“刷論文”的嫌疑，答辯時必然會被要求從論文中刪除。
6.1 xxx模塊實現（具體算法、流程說明；界面截圖及其說明（如果有的話）；流程圖或者活動圖）
6.2 xxx模塊實現
6.3 xxx算法實現
6.4 …
7. 部署和測試（比較復雜的軟件系統需要描述部署環境。部署部分有時也可以與 ch6 放在一章。測試一般要給出測試用例、測試結果）
7.1 軟硬件環境
7.2 部署流程
7.3 測試用例
7.3.1 xxx模塊測試用例設計
7.3.2 xxx模塊測試用例設計
7.4 測試結果及分析
7.4.1 xxx測試結果及分析
7.4.2 xxx測試結果及分析
8. 結語
8.1 工作總結（對論文所述工作進行總述總結）
8.2 工作不足與展望（對論文工作的不足之處進行總結，并且說明改進的方向）
一篇工程碩士論文最好能夠包含上述內容，這樣，結構上比較完整。在寫作時，章節可以略微調整（例如，將詳細設計和實現合并為一章，或者將概要設計與詳細設計合并為一章）。大部分論文的章節數量均在6-7章左右，過多或者過少均不好。
論文行文風格
論文的文字要通順，不得有錯別字，這是將論文提交給導師之前必須達到的標準。方法有二：
a） 利用word的語法檢查功能，所有在檢查后有波浪線的文字，都需要仔細審核
b） 與其它同學合作，兩個人在同一個屏幕前，共同通讀一篇論文，這樣，98%以上的錯誤都能夠檢查出來。
最后對于錯別字，我的處理方式是：1. 第一次審稿，發現三個錯別字，打回去重新檢查，推遲一周復審；2.復審又發現達到或者超過3個錯別字，打回去重新檢查，推遲兩周復審；3.三審發現還有3個或者3個以上錯別字，那么論文會被推遲到最后一刻審核，并且在論文的導師意見中有如后字樣：“該生治學態度隨意，論文錯別字較多，論文寫作能力難以達到工程碩士要求”.
