軟件工程是高等院校計算機相關學科各專業的專業基礎課，其研究范圍非常廣泛。《軟件工程理論及應用/普通高等教育“十二五”規劃教材》從實用的角度出發，在系統講解軟件工程理論和方法的同時，注重結合實例，分析軟件工程技術與工具的綜合應用；在強調傳統的結構化方法的同時，著重介紹面向對象方法。
《軟件工程理論及應用/普通高等教育“十二五”規劃教材》共分10章，包括軟件產品、軟件過程、項目管理和軟件項目計劃、項目進度安排及跟蹤、軟件工程的需求工程、軟件設計、面向對象的分析方法、面向對象設計、面向對象測試和軟件維護工程。
《軟件工程理論及應用/普通高等教育“十二五”規劃教材》將理論知識與實踐案例相結合，便于教學與應用，文字通俗易懂，概念清晰，實例豐富，實用性強，并配有習題。《軟件工程理論及應用/普通高等教育“十二五”規劃教材》可作為高等院校計算機類專業軟件工程相關課程的教材，也可作為軟件開發人員的參考書。
前言
第1章 軟件產品
1.1 軟件的發展
1.1.1 軟件產業
1.1.2 軟件的競爭
1.2 軟件危機與軟件工程
1.2.1 軟件特征
1.2.2 軟件工程
1.2 -3軟件應用
1.2.4 軟件語言
1.2.5 軟件文檔
1.3 軟件生存周期模型
1.3.1 瀑布模型
1.3.2 快速原型模型
1.3.3 螺旋模型
1.3.4 噴泉模型和其他模型
1.4 軟件工程工具及環境
本章小結
習題
第2章 軟件過程
2.1 軟件過程規范
2.2 軟件過程成熟度模型
2.2.1 初始級
2.2.2 可重復級
2.2.3 已定義級
2.2.4 已管理級
2.2.5 優化級
2.3 軟件過程管理案例
本章小結
習題
第3章 項目管理和軟件項目計劃
3.1 對估算的觀察
3.2 項目計劃目標
3.3 軟件范圍
3.4 軟件項目估算
3.5 項目管理實驗
本章小結
習題
第4章 項目進度安排及跟蹤
4.1 人員與工作量之間的關系
4.2 為軟件項目定義任務集合
4.2.1 嚴格度
4.2.2 定義適應準則
4.2.3 計算任務集合選擇因子的值
4.3 主要任務的求精
4.4 進度安排
4.5 軟件項目計劃案例
本章小結
習題
第5章 軟件工程的需求工程
5.1 軟件工程需求分析案例
5.2 需求分析的基本內容
5.2.1 需求分析的必要性
5.2.2 需求分析的原則
5.2.3 需求的類型
5.2.4 需求分析的方法
5.3 結構化分析的技巧
5.3.1 創建實體一關系圖
5.3.2 創建數據流模型
5.3.3 加工規范化
5.3.4 數據字典
5.3.5 其他分析方法概述
本章小結
習題
第6章 軟件設計
6.1 設計和軟件質量
6.2 軟件設計的演化
6.3 設計目標與任務
6.4 設計概念
6.4.1 抽象
6.4.2 求精
6.4.3 模塊化
6.4.4 軟件體系結構
6.4.5 控制層次
6.4.6 結構劃分
6.4.7 數據結構
6.4.8 信息隱藏與局部化
6.5 有效的模塊設計案例
6.5.1 模塊獨立性
6.5.2 內聚
6.5.3 耦合
本章小結
習題
第7章 面向對象的分析方法
7.1 面向對象分析概述
7.1.1 常用的00A方法
7.1.2 OOA模型
7.2 領域分析
7.2.1 復用和領域分析
7.2.2 領域分析過程
7.2.3 面向對象分析模型的類屬成分
7.3 OOA過程
7.3.1 用例
7.3.2 類一責任一協作者建模
7.3.3 定義結構和層次
7.3.4 定義主題和子系統
7.4 對象一關系模型
7.5 對象一行為模型
本章小結
習題
第8章 面向對象設計
8.1 面向對象系統的設計
8.1.1 OOD概述
8.1.2 統一的OOD方法
8.2 系統設計過程
8.2.1 劃分分析模型
8.2.2 并發性和子系統分配
8.2.3 任務管理構件
8.2.4 人機界面構件
8.2.5 數據管理構件
8.2.6 資源管理構件
8.2.7 子系統間通信
8.3 對象設計過程
8.3.1 對象描述
8.3.2 設計算法和數據結構
8.3.3 程序構件與接口
8.4 設計模式
8.4.1 描述設計模式
8.4.2 在設計中使用設計模式
本章小結
習題
第9章 面向對象測試
9.1 OOA和OOD模型的正確性
9.2 OOA和OOD的測試
9.3 OO軟件的測試案例設計的影響
9.3.1 OO概念的測試用例設計的含義
9.3.2 傳統測試案例設計方法的可用性
9.3.3 基于故障的測試
9.4 在類級別可用的測試方法
9.4.1 對OO類的測試
9.4.2 系統測試
本章小結
習題
第10章 軟件維護工程
10.1 軟件維護案例介紹
10.2 軟件維護概述
10.2.1 軟件維護的類型
10.2.2 軟件維護的困難
10.2.3 軟件維護的費用
10.2.4 軟件維護的方式
10.3 軟件系統的維護
10.3.1 概述
10.3.2 軟件維護的過程
10.3.3 軟件維護技術
10.3.4 影響維護工作量的因素
10.3.5 軟件維護的策略
10.3.6 維護成本
本章小結
習題
參考文獻
這個階段要回答的關鍵問題是：“對于上一個階段所確定的問題有可行的解決辦法嗎？”為了回答這個問題，系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計過程，也就是在較抽象的高層次上進行的分析和設計過程。可行性研究應該比較簡短，這個階段的任務不是具體解決問題，而是研究問題的范圍，探索這個問題是否值得去解，是否有可行的解決辦法。可行性研究的結果是使部門負責人做出是否繼續進行這項工程的決定的重要依據，一般來說，只有投資可能取得較大經濟效益的那些工程項目才值得繼續進行下去。可行性研究以后的那些階段將需要投入更多的人力物力。及時終止不值得投資的工程項目可以避免更大的浪費。
可行性研究的目的不是解決問題，而是確定問題“是否值得去解決”。怎樣達到這個目的？當然不能靠主觀猜想，而是要靠客觀分析。系統分析員必須分析幾種主要的可能解法的利弊，從而判斷原定的系統規模和目標是否現實，以及系統完成后所能帶來的效益是否大到值得投資開發這個系統的程度。
首先需要進一步分析和澄清問題定義。在問題定義階段初步確定的規模和目標，如果是正確的就進一步加以肯定；如果有錯誤就應該及時改正；如果對目標系統有任何約束和限制，也必須把它們清楚地列舉出來。在澄清了問題定義之后，系統分析員應該導出系統的邏輯模型。然后從系統邏輯模型出發，探索若干種可供選擇的主要解法（即系統實現方案）。對每種解法，系統分析員都應該仔細研究它的可行性，一般說來，至少應該從3個方面研究每種解法的可行性；①技術可行性，即使用現有的技術能實現這個系統嗎？②經濟可行性，即這個系統的經濟效益能超過它的開發成本嗎？③操作可行性，即系統的操作方式在這個用戶組織內行得通嗎？
必要時還應該從法律、社會效益等更廣泛的方面研究每種解法的可行性。系統分析員應該為每個可行的解法制訂一個粗略的實現進度。
可行性研究最根本的任務是對以后的行動方針提出建議。如果問題沒有可行的解，系統分析員應該建議停止這項開發工程，以避免時間、資源、人力和金錢的浪費；如果問題有可行的解，分析員應該推薦一個較好的解決方案，并且為工程制定一個初步的計劃。可行性研究需要的時間長短取決于工程的規模。一般說來，可行性研究的成本只是預期工程總成本的5％～10％。
需求分析階段的任務仍然不是具體地解決問題，而是準確地確定“為了解決這個問題，目標系統必須做什么”，主要是確定目標系統必須具備哪些功能。用戶了解他們所面對的問題，知道必須做什么，但通常不能完整準確地表達出他們的要求，更不知道怎樣利用計算機解決他們的問題；軟件開發人員知道怎樣用軟件實現人們的要求，但是對特定用戶的具體要求并不完全清楚。因此，系統分析員在需求分析階段必須和用戶密切配合，充分交流信息，以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的算法表示系統的邏輯模型。在需求分析階段確定的系統邏輯模型是以后設計和實現目標系統的基礎，因此必須準確完整地體現用戶的要求。這個階段的一項重要任務，是用正式文檔準確地記錄對目標系統的需求，即《需求分析規格說明書》。
3．系統設計
系統設計階段必須回答的關鍵問題是：“概括地說，應該怎樣實現目標系統？”系統設計的主要任務是進行總體設計和詳細設計。總體設計又稱為概要設計。首先，應該設計出實現目標系統的幾種可能的方案。通常至少應該設計出低成本、中等成本和高成本3種方案。軟件工程師應該用適當的表達工具描述每種方案，分析每種方案的優缺點，并在充分權衡每種方案利弊的基礎上推薦一個最佳方案。此外，還應該制訂出實現最佳方案的詳細計劃。如果客戶接受所推薦的方案，則應進一步完成下一項主要任務。總體設計工作確定了解決問題的策略及目標系統中應包含的程序，但是，怎樣設計這些程序呢？軟件設計的_條基本原理就是，程序應該模塊化，也就是說，一個程序應該由若干個規模適中的模塊按合理的層次結構組織而成。因此，總體設計的另一項主要任務就是設計程序的體系結構，也就是確定程序由哪些模塊組成以及模塊問的關系。
總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段即程序實現的任務就是把解法具體化，也就是回答“應該怎樣具體地實現這個系統呢？”這個關鍵問題。這個階段的任務還不是編寫程序，而是設計出程序的詳細規格說明。詳細規格說明的作用類似于其他工程領域中工程師經常使用的工程藍圖，應該包含必要的細節。程序員可以根據詳細規格說明寫出實際的程序代碼。
4．程序實現
程序實現也被稱為模塊設計，開發人員在這個階段將詳細地設計每個模塊，并確定實現模塊功能所需要的算法和數據結構。
這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊，具體包括編碼和單元測試。程序員應該根據目標系統的性質和實際環境，選取一種適當的高級程序設計語言（必要時用匯編語言），把詳細設計的結果翻譯成使用選定的語言書寫的程序，并應仔細測試編寫的每一個模塊。
5．測試確認
這個階段的關鍵任務是通過各種類型的測試及調試，使軟件達到預定的要求。最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟件結構，把經過單元測試檢驗的模塊按某種選定的策略裝配起來，在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照需求規格說明書的規定，由用戶對目標系統進行驗收，必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。為了使用戶能夠積極參加驗收測試，并且在系統投入生產性運行以后能夠正確有效地使用這個系統，通常需要以正式的或非正式的方式對用戶進行培訓。通過對軟件測試結果進行分析，可以預測軟件的可靠性；反之，根據對軟件可靠性的要求，用戶也可以決定測試和調試過程什么時候結束。軟件測試人員應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果保存下來，作為軟件配置的一個組成部分。
……
新書資訊