1 需求的層次

業務需求
反映企業或客戶對系統高層次的目標需求
用戶需求
描述用戶的具體目標，或用戶要求系統必需能完成的任務
系統需求
從系統的角度來說明軟件的需求，包括功能需求、非功能需求和設計約束等。
- 功能需求
  系統需要實現的某項功能。
- 非功能需求
  可維護性、可靠性、效率等
- 設計約束
  必需使用的哪種數據庫，必需運行在Linux操作系統等。
常規需求
用戶任務系統應該具備的功能或性能，實現越多用戶會越滿意
期望需求
用戶想系統應具備的需求，但是不能具體描述，如果得到滿足會很滿意
意外需求
用戶需求外的功能或性能，實現後用戶會更高興

2 需求分析

常用結構化方法（SA方法）進行需求分析
SA方法進行需求分析的核心是數據字典
圍繞數據字典這個核心，有三個數據模型

模型	表現形式	描述
數據模型	實體-聯繫圖（E-R圖）	描述實體、屬性、以及實體之間的關係
功能模型	數據流圖（DFD）	從數據傳遞和加工的角度，利用圖形符號通過逐層細分描述系統內各個部件的功能和數據在它們之間傳遞的情況，來說明系統所完成功能
行爲模型（狀態模型）	狀態轉換圖（STD）	通過描述系統的狀態和引起系統狀態轉換的事件，表示系統的行爲，指出作爲特定事件的結果將執行哪些動作

在項目開發的後期需要對需求進行驗證

3 UML

每年都會考，1-3分。書本（P39）

UML中的14種圖。每一種圖的用途和表現形式需要了解。
UML中的關係

4 軟件架構設計

軟件架構設計的核心是實現軟件的複用，可以在不同的軟件中使用同一個架構
敏感點
一個或多個構件的特性
權衡點
影響多個質量屬性的特性
軟件架構評估人員最關注的是質量屬性

5 軟件設計

結構化設計（OOA）
面向對象設計（OOD）
軟件設計原則：高內聚、低耦合
設計模型
能力成熟度模型CMMI
測試的方法
- 靜態測試
- 動態測試
- 白盒測試：也稱結構測試
- 黑盒測試：也稱功能測試
- 單元測試：對單個模塊測試，一般是開發者自己做
- 集成測試：各個模塊組合後，測試各模塊的協調、聯動、功能接口等要求是否滿足。
- 確認測試：驗證軟件功能、性能等是否滿足用戶需求
  - 內部確認測試：開發組織內部進行測試
  - Alpha測試：由用戶在開發環境下進行測試
  - Beta測試：由用戶在實際使用環境進行測試，通過後，才把產品發佈給全體用戶。
- 系統測試
- 配置項測試
- 迴歸測試：新功能的加入可能會影響以前的功能，需要對以前的功能進行迴歸測試
調試和測試的區別
- 測試的目的是找出存在的錯誤；調試的目的是定位錯誤並修正錯誤
- 調試在測試之後進行，測試和調試在目標、方法和目的上有所不同
- 測試從一個已知的條件開始，使用預定義的過程，有預知的結果
- 調試從一個未知的條件開始，結束的過程不可預知
- 測試過程可以事先設計，進度可以事先確定
- 調試不能描述過程和持續時間
軟件測試的管理
企業應用集成（EAI）
- 表示集成
  界面集成，比較原始和最淺層次的集成，常用的集成，屬於黑盒集成。將原有零散的系統界面集成在一個新的界面中。
- 數據集成
  各數據庫由自己的數據結構，把多個數據庫的數據集成在一起，形成一個新的數據結構，屬於白盒集成
- 控制集成
  功能集成或應用集成，在業務邏輯層上對應用系統進行集成。集成處秩序簡單的API就可以訪問。屬於黑盒集成。
- 業務流程集成
  過程集成，這個集成超越了數據和系統，它由一系列基於標準的、統一數據格式的工作流組成。
- 企業之間的集成
  適用於大多數要實施電子商務的企業，以及企業之間的應用集成。使得應用集成架構裏的業務夥伴，都可以通過集成供應鏈內的所有應用和數據庫實現信息共享。