【正文】 點：，沒有考慮軟件的總體質量和長期的可維護性。，可能采用不合適的操作系統(tǒng)、編程語言、效率低的算法，這些不理想的選擇成了系統(tǒng)的組成部分。l 統(tǒng)一過程的三個特點：用例驅動，以架構為核心，迭代并增量l 簡述統(tǒng)一過程（UP）的5個階段的主要內容：起始，細化，構建，轉換和生產l 螺旋模型強調了其他模型均忽略了的（風險分析）l 橫切關注點的定義：一個信用卡處理系統(tǒng)的核心關注點是借貸/存入處理，而系統(tǒng)級的關注點則是日志、事務完整性、授權、安全及性能問題等許多關注點，我們叫它橫切關注點第四章 敏捷視角下的過程l 軟件工程的敏捷理念強調4個關鍵問題：；、開發(fā)參與者與客戶之間的交流與合作；“變更代表機遇”的認識；。l 簡述極限編程（XP）過程模型所包含的4個主要框架活動：策劃，設計，編碼，測試第五章 系統(tǒng)工程l 計算機系統(tǒng)的6個系統(tǒng)要素：軟件，硬件，人員，數(shù)據(jù)庫，文檔，規(guī)程l HatleyPirbhai建模方法：用戶界面，輸入，系統(tǒng)功能和控制，輸出，維護和自檢l 系統(tǒng)環(huán)境圖（System Context Diagram）的表示方法（實例）第六章 需求工程l 需求工程的過程：起始，導出，精化，協(xié)商，規(guī)格說明，確認和管理l 在項目（起始）階段，軟件工程師會詢問一些似乎與項目無直接關系的問題，目的是對問題、方案需求方、期望方案的本質、客戶和開發(fā)人員之間初步的交流和合作的效果建立基本的諒解。l 為什么導出需求這么困難：范圍問題，理解問題，易變問題。l 用例的定義：講述了能表達主題場景的故事：最終用戶如何在一特定環(huán)境下和系統(tǒng)交互l 在需求工程的導出階段，三個主要的需求收集活動是：主持人會議、QFD和用戶場景開發(fā)第七章 構建分析模型l 分析模型在系統(tǒng)描述和設計模型之間建立橋梁。l 分析模型必須實現(xiàn)的目標：1。描述客戶需要什么；2。為軟件設計奠定基礎；3。定義在軟件完成后可以被確認的一組需求。l 分析模型的所有元素都可以直接跟蹤到設計模型。l 分析模型的4個元素：基于場景的元素，面向信息流的元素，基于類的元素，行為元素l UML泳道圖是活動圖的一種變形，可以讓建模人員表示用例所描述的活動流，同時指示哪個參與者或分析類對活動矩形所描述的活動負責。l UML狀態(tài)圖為每個類表現(xiàn)活動狀態(tài)和導致這些活動狀態(tài)變化的事件l UML順序圖說明事件如何引發(fā)一個對象到另一個對象的轉移l 簡述CRC建模的內容：CRC提供了一個簡單方法，可以識別和組織與系統(tǒng)或產品需求相關的類。l 使用UML類圖來舉例說明組合和聚合之間的區(qū)別l 使用UML類圖舉例說明關聯(lián)和依賴之間的區(qū)別系統(tǒng)分析的經驗原則（1） 系統(tǒng)開發(fā)是面向客戶的，應從客戶的角度考慮。（2） 諸如系統(tǒng)開發(fā)生命周期之類的產品更新?lián)Q代機構應該在所有的信息系統(tǒng)開發(fā)項目中建立起來。（3） 信息系統(tǒng)開發(fā)的過程并不是一個順序的過程，它允許步驟的重疊和倒轉等。（4） 如果系統(tǒng)的成功可能性受到很大限制時，應取消整個項目。（5） 文檔材料是系統(tǒng)開發(fā)生命周期中重要的可遞交成果，應加以重視第八章 設計工程l 簡述良好設計的三個特征：1。設計必須實現(xiàn)所有包含在分析模型中的明確需求，而且必須滿足客戶期望的所有隱含需求；2。對于那些生成代碼的人和那些進行測試以及隨后維護軟件的人而言，設計必須是可讀的、可理解的指南；3。設計必須提供軟件的全貌，從實現(xiàn)的角度說明數(shù)據(jù)域、功能域和行為域。l 設計模型包含的四種元素是什么：數(shù)據(jù)/類設計、體系結構設計、接口設計、構建級設計l 軟件體系結構的定義：軟件的整體結構和這種結構為系統(tǒng)提供概念上完整性的方式l 模塊應該詳細說明且精心設計以求在某個模塊中包含的信息不被不需要這些信息的其他模塊訪問l 重構的定義：是使用這樣一種方式改變軟件系統(tǒng)的過程：不改變代碼設計的外部行為而是改進其內部結構l 舉例說明逐步求精l 框架和設計模式之間的區(qū)別：框架能使應用程序的開發(fā)簡單，價格低廉，但是開發(fā)框架不是一件容易的事。它是一個需要領域和設計經驗的反復過程。設計模式可以簡化這個過程，因為它提供了對過去經驗的抽象。框架能高度抽象同一領域內的問題，進而降低開發(fā)難度和強度。因此，在軟件開發(fā)過程中把框架和模式配合起來使用，可以極大地提高軟件的重用?？蚣苁擒浖O計模式是軟件的知識第九章 進行體系結構設計l 簡述軟件體系結構的作用：1。軟件體系結構的表示有助于對計算機系統(tǒng)開發(fā)感興趣的各方（共利益者）開發(fā)交流；2。體系結構突出了早期設計決策，這些決策對隨后的所有軟件工程工作有深遠的影響，同時對系統(tǒng)作為一個可運行實體的最后成功有重要作用。3。體系結構“構建了一個相對小的，易于理解的模型，該模型描述了系統(tǒng)如何構成以及其構建如何一起工作”l 軟件體系結構的典型分類：以數(shù)據(jù)為中心，數(shù)據(jù)流體系結構，調用和返回體系結構，面向對象體系結構，層次體系結構（以圖例來說明）l 體系結構環(huán)境圖所包含的要素，以圖例來說明第十二章 軟件測試策略l 簡述軟件測試策略的螺旋模型：單元測試，集成測試，確認測試，系統(tǒng)測試l 簡述單元測試中驅動程序和樁程序的作用：驅動程序只是一個“主程序”，它接收測試用例數(shù)據(jù)，將這些數(shù)據(jù)傳遞給（將要測試的）構件并打印相關結果。樁程序的作用是替換那些從屬于將要測試的構件或被其調用的構件。l 集成測試的兩種方式：一步到位和增量集成l 試以圖例描述自頂向下集成測試方法的過程l 簡述確認測試的兩種主要方法：α測試和β測試l 系統(tǒng)測試的主要方法：恢復測試，安全測試，壓力測試，性能測試l 三種調試方法：蠻力法，回溯法，原因排除法第十三章 測試戰(zhàn)術l 好的測試所具有的特性：1。好的測試具有較高的發(fā)現(xiàn)錯誤的可能性；2。好的測試是不冗余的；3。好的測試應該是“最佳品種”4。好的測試應該既不太簡單也不太復雜。l 黑盒測試的定義：所謂黑盒測試是指在完全不考慮程序的內部結構和處理過程的前提下,在程序接口進行的測試,它只檢查程序功能是否能按照規(guī)格說明書的規(guī)定正常使用,程序是否能適當?shù)亟邮茌斎霐?shù)據(jù)產生正確的輸出信息,又稱為功能測試。白盒測試的定義：所謂白盒測試就是在知道產品內部工作過程或程序內部結構和處理過程的前提下,檢驗產品內部動作是否按照規(guī)格說明書的規(guī)定正常進行或按照程序內部的邏輯測試程序,。l 基本路徑測試的環(huán)復雜度計算方法和獨立路徑集合的識別V(G)=EN+2。其中E為流圖的邊數(shù)，N為流圖的結點數(shù)。l 控制結構測試的3個主要方法：條件測試，數(shù)據(jù)流測試，循環(huán)測試l 黑盒測試的兩個主要方法：等價類劃分，邊界值分析l 類級可應用的測試方法：隨機測試，劃分測試l 面向對象的類級劃分測試的主要方法：基于狀態(tài)劃分，基于屬性劃分，基于類別劃分l 以圖例說明從行為模型導出測試用例第十四章 產品度量l 軟件度量為產品內部屬性的質量評估提供了一種（定量）方法，從而可以是軟件工程師在產品開發(fā)出來之前進行質量評估l 軟件測量的5個主要活動：公式化，收集，分析，解釋，反饋l 面向目標的軟件測量（GQM范型）的內容：1。確定特定過程活動的明確的測量目標或將要評估的產品特性；2。定義一組必須回答的問題以達到目標；3。確定被良好公式化的度量以幫助回答這些問題l 有效軟件度量的屬性1。簡單的和可計算的2。在經驗上和直覺上有說服力3。一致的和客觀的4。單位和量綱的使用是一致的。5。編程語言的獨立性6。高質量反饋的有效機制14 / 1