第一章

1、軟件危機是指在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題

2、1968年NATO軟件工程早期定義：軟件工程就是為了經濟地獲得可靠的且能在實際機器

上有效地運行的軟件，而建立和使用完善的工程原理

1993年IEEE具體定義：1、把系統的規范的可度量的途徑應用于軟件開發、運行和維護過程，

也就是把工程應用于軟件；2、研究1中提到的途徑

3、軟件工程的7條基本原理：

1、用分階段的生命周期計劃嚴格管理

2、堅持進行階段評審

3、實行嚴格的產品控制

4、采用現代程序設計技術

5、結果應能清楚地審查

6、開發小組的人員應該少而精

7、承認不斷改進軟件工程實踐的必要性

4、軟件生命周期

軟件生命周期由軟件定義、軟件開發和運行維護（軟件維護）組成

軟件定義：1、問題定義2、可行性研究3、需求分析

軟件開發：4、總體設計5、詳細設計6、編碼和單元測試7、綜合測試

維護運行:8、軟件維護

5、軟件過程是為了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任

務的工作步驟

6、傳統瀑布模型開發軟件的特點：1＞階段間具有順序性和依賴性

2、推遲實現的觀點

3、質量保證的觀點

圖1-10RUP軟件開發生命周期P24

第二章

7、可行性研究的目的：用最小的代價在盡可能短的時間內確定問題是否能夠解決

8、從三個方面研究每種解法可行性：技術可行性、經濟可行性、操作可行性

9、可行性研究過程的步驟：1、復查系統規模和目標

2、研究目前正在使用的系統

3、導出新系統的高層邏輯模型

4、進一步定義問題

5、導出和評價供選擇的解法

6、推薦行動方針

7、草擬開發計劃

8、書寫文檔提交審杳

10、系統流程圖是概括地描繪物理系統的傳統工具，它的基本思想是用圖形符號以黑盒子形

式描繪組成系統的每個部件（程序、文檔、數據庫、人工過程等）

11、數據流圖（DFD）是一種圖形化技術，它描繪信息流和數據從輸入移動到輸出的過程中

所經受的變換

12、數據字典是關于數據的信息的集合，也就是對數據流圖中包含的所有元素的定義的集合

13、數據字典由對下列4類元素的定義組成：1、數據流2、數據流分流（即數據元素）3、

數據存儲4、處理

14、3種估算技術：1、代碼行技術2、任務分解技術3、自動估計成本技術

第三章

15、用于需求分析的結構化分析方法遵守準則：1、必須理解并描述問題的信息域，根據這

條準則應該建立數據模型2、必須定義軟件應完成的功能，這條準則要求建立功能模型

3、必須描述作為外部事件結果的軟件行為，這條準則要求建立行為模型

4、必須對描述信息、功能和行為的模型進行分解.，用層次的方式展示細節

16、對軟件系統的綜合要求：1、功能需求2、性能需求3、可靠性和可用性需求4、出錯

處理需求5、接口需求6、約束7、逆向需求8、將來可能提出的要求

17、根據結構化分析準則，需求分析過程應該建立數據模型、功能模型和行為模型

實體-聯系圖描繪數據對象與數據對象之間的關系，是用于建立數據模型的圖形

數據流圖描繪當數據在軟件系統中移動時被變換的邏輯過程，指明系統具有的變換數據的功

能，因此，數據流圖是建立功能模型的基礎。

狀態轉換圖（簡稱狀態圖）指明了作為外部事件結果的系統行為。為此，狀態轉換圖描繪了

系統的各種行為模式（狀態）和在不同狀態間轉換的方式，狀態轉換圖是行為建模的基礎

18、數據模型中包含3種相互關聯的信息：數據對象、數據對象的屬性、數據對象彼此間相

互連接的關系

19、狀態轉換圖（狀態圖）通過描繪系統的狀態及引起系統狀態轉換的事件，來表示系統的

行為。此外，狀態圖還指明了作為特定事件的結果系統瘠做那些動作（例如處理數據）

狀態：是任何可以被觀察到的系統行為模式，一個狀態代表系統的一種行為模式

事件：是在某個特定時刻發生的事情，他是對引起系統做動作或（和）從一個和組昂臺轉換

到另一個狀態的外界事件的抽象。簡而言之，事件就是引起系統做動作或（和）轉換狀態的

控制信息

20、從4個方面驗證軟件需求的正確性：一致性、完整性、現實性、有效性

第四章

21、按照形式化的程度可以把軟件工程使用的方法劃分為：非形式化、半形式化、形式化

22、應用形式化方法的準則：1、應該選用適當的表示方法2、應該形式化但不要過分形式

化3、應該估算成本4、應該有形式化方法顧問隨時提供咨詢5、不應該放棄傳統的開發方

法6、應該建立詳細的文檔7、不應該放棄質量標準8、不應該盲目依賴形式化方法9、應

該測試、測試再測試10、應該重用

23、常用的形式化方法：有窮狀態機、Petri網、Z語言

第五章

24、總體設計的目的：1、劃分出組成系統的物理元素2、設計軟件的結構

25、總體設計過程的兩個主要階段：系統設計階段（確定系統的具體實現方法）結構設計階

段（確定軟件結構）

26、總體設計過程九個步驟：1、設想供選擇的方案2、選取合理的方案3、推薦最佳方案4、

功能分解5、設計軟件結構6、設計數據庫7、制定測試計劃8、書寫文檔（包括系統說明、

用戶手冊、測試計劃、詳細的實現計劃、數據庫設計結果）9、審查和復審

27、軟件設計過程應該遵循的原理：模塊化、抽象、逐步求精、信息隱藏和局部化、模塊獨

28、幾條啟發式規則：1、改進軟件結構提高模塊獨立化2、模塊規模應該適中3、深度、寬

度、扇出和扇入都應適當4、模塊的作用域應該在控制域之內5、力爭降低模塊接口的復雜

程度6、設計單入口單出口的模塊7、模塊功能應該可以預測

第六章

29、詳細設計的根本目標是確定應該怎么具體地實現所要求的系統

30、詳細設計階段的任務還不是具體地編寫程序，而是要設計出程序的藍圖

31、結構程序設計經典定義：如果一個程序的代碼僅僅通過順序、選擇和循環這3種基本控

制結構進行連接，并且每個代碼塊只有一個入口和一個出口，則稱這個程序是結構化的

3種基本的控制結構：順序結構、IF-THEN-ELSE型選擇（分支）結構、D5WHILE型循環結構

其他：DO-UNTIL型循環結構、多分支結構

32、設計人機界面過程中遇到的問題：系統響應時間、用戶幫助設施、出錯信息處理和命令

交互

33、人機界面設計指南：一般交互指南、信息