目錄
第一章 軟件工程概述 1.1軟件
軟件是計算機中與硬件相互依存的另一部分，軟件包括程序、數據及相關文檔的完整集合。
軟件的特點：邏輯實體、生產與硬件不同、不會磨損和老化、依賴硬件、手工開發為主、成本高，風險高、涉及社會因素
1.2軟件危機 1.2.1軟件危機的表現與原因
表現：在軟件開發的過程中，會經常出現一些不能按時完成任務、產品質量得不到保證、工作效率低下和開發經費嚴重超支等現象。計算機軟件的開發、維護和應用過程中普遍出現的這一些嚴重的問題便是軟件危機。
原因：
忽視軟件開發前期的調研和需求分析工作
缺乏軟件開發的經驗和有關軟件開發數據的積累，使得開發計劃很難制定。
開發過程缺乏統一的、規范化的方法論指導
忽視與用戶、開發組成員間的及時有效的溝通
文檔資料不規范不準確。導致開發者失去工作的基礎，管理者失去管理的依據。
沒有完善的質量保證體系
忽視測試的重要性和不重視維護
1.2.2軟件危機的啟示
軟件危機給我們的最大啟示，是使我們更加深刻的認識 到軟件的特性以及軟件產品開發的內在規律。
1.3軟件工程 1.3.1軟件工程的概念
IEEE對軟件工程的定義為：將系統化、嚴格約束的、可量化的方法應用于軟件的開發、運行和維護，即將工程化應用于軟件。
軟件工程層次圖
軟件工程以關注質量為目標，方法、工具、過程是軟件工程的三要素
1.3.2軟件工程研究的內容
軟件開發技術：主要研究軟件開發的方法、軟件開發過程、軟件開發工具和環境
軟件開發過程管理：主要研究軟件工程經濟學和軟件管理學
1.3.3軟件工程目標和原則
目標：
達到要求的軟件功能
取得較好的軟件性能
開發出高質量的軟件
付出較低的開發成本
需要較低的維護費用
能按時完成開發工作
及時交付使用
原則：
用分階段的生命周期計劃進行嚴格的管理
堅持進行階段評審
實行嚴格的產品控制
采用現代程序設計技術
軟件工程結果應該清楚地審查
開發小組的人員應該少而精
承認不斷改進軟件軟件工程實踐的必要性
1.3.4軟件工程的發展
1.4軟件開發方法
常見的軟件開發方法包括：
結構化方法
面向數據結構方法
面向對象方法
形式化方法
第二章 軟件過程 2.1軟件過程概述
軟件過程是為了開發出軟件產品，或者是為了完成軟件工程項目而需要完成的有關軟件工程的活動，每一項活動又可以分為一系列的工程任務。
2.2軟件生命周期 2.2.1軟件生命周期的概念
軟件產品的生命周期是指從設計該產品的構想開始，到軟件需求 的確定、軟件設計、軟件實現、產品測試與驗收、投入使用以及 產品版本的不斷更新，到最終該產品被市場淘汰的全過程。
2.2.2傳統軟件生命周期的各個階段
2.3軟件過程模型
常見的軟件開發模型有很多種，這里主要介紹瀑布模型、快速原型模型、增量模型、螺旋模型、噴泉模型、基于組件的開發模型、統一軟件開發過程模型以及敏捷模型與極限編程。
2.3.1瀑布模型
瀑布模型是一種線性的開發模型，具有不可回溯性
優點：過程模型簡單
缺點：無法適應變更
瀑布模型適用于具有以下特征的軟件開發項目：
軟件開發過程中需求不發生變化或很少變化，開發人員可以一次性獲取到全部需求。
軟件開發人員具有豐富的經驗，對軟件應用領域很熟悉。
軟件項目的風險較低。瀑布模型不具有完善的風險控制機制
2.3.2快速原型模型
快速原型的本質是“快速”
原型系統內部結構并不重要，重要的是，必須迅速地構建原型然后根據用戶意見不斷地修改原型。
原型還一個重要的用途是獲取用戶的需求。
快速原型模型適用于具有以下特征的軟件開發項目：
已有產品或產品的原型（樣本），只需客戶化的工程項目
簡單而熟悉的行業或領域
有快速原型開發工具
進行產品移植或升級
2.3.3增量模型
增量模型是把待開發的軟件系統模塊化，將每個模塊作為一個增量組件，從而分批次的分析、設計、編碼和測試這些增量組件。軟件開發過程是遞增式的過程。
優點：將待開發的軟件系統模塊化和組件化。可以分批次的提交產品，降低了軟件開發的風險。
缺點：要求待開發的軟件系統可以被模塊化。
增量模型適用于具有以下特征的軟件開發項目：
軟件產品可以分批次地進行交付
待開發的軟件系統能夠被模塊化
軟件開發人員對應用領域不熟悉，難以一次性的進行系統開發
項目管理人員把握全局的水平較高
2.3.4螺旋模型
螺旋模型是一種用于風險較大的大型軟件項目開發的過程模型。該模型將瀑布模型與快速原型模型結合起來，并且加入了這兩種模型忽略了的風險分析。
優點：將風險分析擴展到各個階段中，大幅降低軟件開發的風險
缺點：管理和控制較為復雜，可操作性不強，對項目管理人員的要求較高
螺旋模型適用于具有以下特征的軟件開發項目：
支持需求不明確、特別是大型軟件系統的開發
支持面向過程、面向對象等多種軟件開發方法
2.3.5噴泉模型
噴泉模型主要適用于面向對象的軟件項目的開發。
各階段之間沒有明顯的界限軟件設計基本方法，而且常常重復、迭代地進行。
2.3.6基于組件的開發模型
考慮的焦點是集成，而非是實現。
體現了軟件復用的思想，降低了開發成本和風險，并加速了產品開發。
2.3.7統一軟件開發過程模型
是一種面向對象軟件開發模型，解決了螺旋模型的可操作性問題，采用迭代和增量遞進的開發策略，并以用例驅動為特點。
特點：基于迭代地思想、由軟件構件構建而成，適用范圍極為廣泛，但對開發人員的素質要求較高
2.3.8敏捷過程與極限編程（XP）
極限編程是一種實踐性較強的規范化的軟件開發方法，它強調用戶需求和團隊合作工作。
第三章 可行性研究及需求分析 3.1可行性研究 3.1.1項目立項概述
項目立項包括項目發起、項目論證、項目審核和項目立項4個過程。
可行性研究不是解決問題，而是確定問題是否值得去解決。
3.1.2可行性研究的內容
戰略可行性、操作可行性、計劃可行性、技術可行性、社會可行性、市場可行性、經濟可行性、風險可行性
3.1.3可行性研究的步驟
明確系統目標、分析研究現行系統、設計新系統的高層邏輯模型、獲得并比較可行的方案、撰寫可行性研究報告
3.2需求分析 3.2.1需求分析的任務
確定系統的運行環境要求：硬件環境、軟件環境
確定系統的功能性需求和非功能性需求
進行有效的需求分析
在需求分析的過程中應遵守一些原則
需求分析的兩個任務：建模階段、描述階段
需求分析規格說明書
3.2.2需求分析的步驟
需求獲取
分析建模
需求描述（編寫SRS）
需求驗證
3.2.3需求管理 3.2.4需求分析的常用方法
功能分解方法：將一個系統看成是由若干功能模塊組成的（自頂向下，逐步求精）
結構化分析方法：邏輯模型由數據流圖和數據詞典構成并表示，它是一種面向數據流的需求分析方法
信息建模方法：E-R圖，其基本要素由實體、屬性和關系構成
面向對象的分析方法：描述系統靜態結構的對象模型、描述系統控制結構的動態模型、描述系統計算結構的功能模型，其中對象模型是最基本、最核心、最重要的
第四章 結構化分析 4.1結構化分析概述
一種考慮數據和處理的需求分析方法被稱作結構化分析方法（SA法）
結構化分析方法是一種面向數據流的需求分析方法
結構化分析方法適合于數據處理類型軟件的需求分析
4.2結構化分析方法
4.2.1功能建模
功能建模的思想就是用抽象模型的概念，按照軟件內部數據傳遞和變換的關系，自頂向下逐層分解。
數據流圖（DFD圖）：
1、數據流圖中表示的符號：
（1）數據變換：表示對數據進行加工或處理
（2）外部實體：表示數據的源點或終點，它是系統之外的實體，同一個外部實體可以在一張數據流程圖中出現若干次。
（3）數據流：表示數據和數據的流動方向
（4）數據存儲：表示輸入或輸出文件
2、環境圖
環境圖也稱為系統頂層數據流圖（或0層數據流圖），僅包括一個數據處理過程。
功能模型數據流圖——訂貨系統實例：
需求描述：
? 假設一家工廠的采購部里的采購員每天需要訂貨系統產生一張訂貨報表。報表按照零件編號排序，表中列出了所有需要再次訂貨的零件。對于每個需要再次訂貨的零件應該列出下述信息：零件編號、零件名稱、價格、主要供應商、次要供應商。
? 零件入庫或出庫稱作事務，倉庫管理員通過倉庫的終端把事務報告給訂貨系統。當某種零件的庫存少于庫存量臨界值時就應該再次訂貨了。
畫出數據流圖：
頂層：
0層：
1層：
4.2.2數據建模
數據建模的思想是在較高的抽象層次上對數據庫結構進行建模。數據模型用實體-關系圖來描述。
數據模型包括3種相互關聯的信息：數據對象（實體）、屬性、關系
（1）數據對象：矩形框代表實體
（2）屬性：定義數據對象的性質，用橢圓形來表示實體的屬性
（3）關系：數據對象彼此之間互相連接的方式，用菱形來表示
數據模型E-R圖——倉庫管理系統實例
? 請為某倉庫的管理系統設計一個ER模型。該倉庫管理系統主要管理零件的訂購和供應等事項。倉庫管理系統向工程項目供應零件，并且根據需要向供應商訂購零件。
? 實體類型“零件”的主要屬性是：零件編號，零件名稱，顏色，重量。實體類型“工程項目”的屬性主要是：項目 編號，項目名稱，開工日期。實體類型“供應商”的屬性主要有：供應商編號，供應商名稱，地址。
4.2.3行為模型
狀態轉換圖是一種描述系統對內部或外部事件響應的行為模型。它描述系統狀態和事件。
事件引發系統在不同狀態間進行轉換，而不是描述系統中數據的流動。
這種模型尤其適合用來描述實時系統，因為這類系統多是由外部環境的激勵而驅動的。
1、狀態：
狀態是任何可以被觀察到的系統行為模式，一個狀態代表系統的一種行為模式。
2、事件：
事件是在某個特定時刻發生的事情軟件設計基本方法，它是對引起系統做動作或從一個狀態轉換到另一個狀態的外界事件的抽象。簡而言之，事件就是引起系統做動作或轉換狀態的控制信息。
狀態圖中所使用的主要符號：
行為模型狀態轉換圖——圖書館系統為例：
圖書館系統里的圖書主要有這幾種狀態：新上、可借閱、已借出、已丟棄這四種狀態，觸發這些狀態進行轉換的事件有分類、借閱、歸還、續借、破損、遺失等。
4.2.4數據字典
可以把數據字典作為數據流圖的補充，對數據流圖中的所有元素作詳細的文字說明。
4.2.5加工規格說明
加工規格說明一般用結構化語言、判定表和判定樹來表述。
第五章 軟件設計 5.1軟件設計的基本概念 5.1.1軟件設計的意義和目標 5.1.2軟件設計的原則
一、模塊化：
1、概念：把系統或程序劃分為獨立命名并且可以獨立訪問的模塊，每個模塊完成一個特定的子功能。模塊集成起來可以構成一個整體，完成特定的功能。
2、屬性：
功能：指定該模塊要完成的任務
邏輯：描述模塊為了完成任務內部需要怎么做
狀態：表明使用該模塊時的環境和條件
3、注意：模塊規模要適中、提高模塊獨立性，降低耦合度、提高模塊的內聚程度、加強模塊的保護性。
（1）模塊獨立性：軟件系統中每個模塊只涉及軟件要求的具體的子功能，與其他模塊沒有太多聯系。
（2）耦合：是模塊之間互相連接的緊密程度的度量。其強弱取決于模塊間接口的復雜程度、進入或訪問一個模塊的點以及通過接口的數據。
非直接耦合：兩個模塊間沒有直接關系，他們之間不存在直接的數據聯系
數據耦合：調用模塊和被調用模塊之間只傳遞簡單的數據參數
標記耦合：調用模塊和被調用模塊之間傳遞數據結構而不是簡單數據。
控制耦合：模塊之間傳遞的不是數據信息，而是控制信息。
外部耦合：系統允許多個模塊同時訪問同一個全局變量
公共耦合：系統允許多個模塊同時訪問同一個全局性的數據結構。
內容耦合：兩個模塊中的一個模塊直接引用了另一個模塊的內容，那么他們之間就是內容耦合。
軟件設計時，要注意盡量使用數據耦合，少用控制耦合，限制公共耦合的使用范圍，完全不用內容耦合。
（3）內聚：一個模塊內各個元素彼此結合的緊密程度用內聚（或稱聚合）來度量。模塊內聚性高，就意味著模塊內部各個元素是為了完成一個功能而存在。
內聚和耦合是密切相關的，模塊內的高內聚往往意味著模塊間的松耦合。
偶然內聚：一個模塊內的各處理元素之間沒有任何實質性聯系，只是偶然地被湊到一起。
邏輯內聚：模塊內部各組成成分的處理動作在邏輯上相似，但是功能卻彼此不同。
時間內聚：如果一個模塊包含的任務必須在同一段時間內執行，就叫時間內聚。
過程內聚：模塊內部各個成分按照確定的順序進行并不相關聯系的工作。
通信內聚：如果模塊中所有元素都使用同一個輸入數據和（或）產生同一個輸出數據，則稱為通信數據。
順序內聚：如果一個模塊內的處理元素和同一個功能密切相關，而且這些處理必須順序執行（通常一個處理元素的輸出數據作為下一個處理元素的輸入數據），則稱為順序內聚。
功能內聚：如果模塊內所有處理元素屬于一個整體，完成一個單一的功能，則稱為功能內聚。功能內聚是最高程度的內聚
二、抽象
三、逐步求精
四、信息隱藏
一個模塊內包含的信息（過程和數據）對于不需要這些信息的模塊來說，是不能訪問的。
這一原理的目的，是為了提高模塊的獨立性。
五、復用性原則
軟件復用就是將已有的軟件成分用于構造新的軟件系統。
六、靈活性設計
5.1.3軟件設計的分類
軟件設計可以從活動任務觀點和工程管理觀點分別對其進行分類
5.2數據庫結構設計
數據庫結構設計包括概念結構設計、邏輯結構設計和物理結構設計。
5.3用戶界面設計
