第一篇：軟件工程重點

軟件是計算機系統中與硬件相互依存的另一部分，它是包括程序，數據及其相關文檔的完整集合。注意與廣義軟件概念的區別（P1）。程序是按事先設計的功能和性能要求執行的指令序列數據是使程序能正常操縱信息的數據結構 文檔是與程序開發，維護和使用有關的圖文材料

軟 件的特點.軟件是一種邏輯實體，而不是具體的物理實體。因而它具有抽象性 軟件的生產與硬件不同，在它的開發過程中沒有明顯的制造過程，可以復制，軟件的開發和運行常受到計算機系統的限制，對計算機系統有著不同程度的依賴性 軟件的開發至今尚未完全擺脫手工藝的開發方式 本身復雜 且 成本昂貴。

軟件功能分：系統，支撐，應用軟件。

軟件生存期的六個步驟，即制定計劃（確定要開發軟件系統的總目標，給出功能、性能、可靠性以及接口等方面的要求，完成該軟件任務的可行性研究，制定出完成開發任務的實施計劃）、需求分析（對待開發軟件提出的需求進行分析并給出詳細 的定義）、設計（把各項需求轉換成軟件的體系結構，對每個模塊要完成的工作進行具體的描述，為源程序編寫打下基礎）、程序編碼（把軟件設計轉換成計算機可 以接受的程序代碼）、測試（通過單元模塊測試和組裝測試，對各項需求進行有效性測試）及運行維護（改正性維護 適應性維護 完善性維護）

軟件：程序和所有使程序正確運行所需要的相關文檔和配置信息。

軟件工程：是一門工程學科，不僅涉及軟件開發，也涉及軟件項目管理、支持軟件生產的工具、方法和理論的開發等活動。

軟件過程：指制作軟件產品的一組活動及其結果。包括軟件描述（對軟件及其操作的一些約束）軟件開發（軟件設計和編程實現）軟件有效性驗證（檢查保證客戶所需）軟件進化（隨不同客戶和變化市場做修改）

軟件過程模型:從一特定角度提出的軟件過程的簡化描述。1工作流模型（描述軟件過程中各種活動的序列及其輸入輸出和相互依賴性）2數據流或活動模型（軟件過程描述成一組活動，每個活動完成一定數據轉換）3角色/動作模型（描述參與人員的不同角色和各自負責的活動）

CASE是計算機輔助軟件工程的簡寫。它包括很多種類的軟件工具，覆蓋面很廣，包括支持阮娟過程活動，如需求分析、系統建模、調試和測試等。瀑布模型：采用一些基本過程活動，并且使用單獨的過程階段表現活動。包括：需求分析和定義（通過咨詢系統用戶建立系統的服務、約束和目標）系統和軟件設計（系統設計區分硬件和軟件系統的需求，軟件設計包括識別和描述一些基本的軟件系統的抽象及其之間的關系）實現和單元測試（檢驗每個單元是否符合描述）集成 和系統測試（對系統整體測試確保滿足需求）運行和維護。優勢在于每個階段生成文檔，并且與其他模型相一致，問題在于將項目生硬分解成這些確切的階段。委托 事項一定要在過程的早期階段清晰給出，意味它難以響應用戶需求的變更。

2迭代式模型：是軟件描述、開發和有效性驗證活動交替進行的開發方 法。先開發出一個原型給用戶使用，通過用戶反饋意見不斷修改系統直到最后成熟。基本類型（探索式開發和拋棄式原型）優勢在于讓開發活動都能得到快速的反饋 信息，缺點在于1過程不可見（管理者要經常性交付把握進度）2系統結構通常較差（連續的變更損壞系統結構）

3基于組件的軟件工程（CBSE）假定系統的各個組件已經存在，開發過程焦點在于集成這些組件。階段：組件分析（給出需求描述，然后搜索能滿足需求的組件）需求修改（修改需求以反映可得 到的組件）使用復用的系統設計（開始設計系統的框架）開發和集成（集成開發的組件和現成的組件使之成為整體）優勢在于減少需要開發的軟件數量，降低軟件開 發成本和風險。缺點在于需求妥協的不可避免，對系統進化的控制不起作用。

Rational統一過程：是一個階段化了的模型，識別出軟件過程 當中的四個階段——開端（目標是建立系統的一個業務案例）細化（增進對問題域的理解，建立系統的體系框架）構造（關心系統設計、編程和測試）轉換（關注如 何將系統從開發單位轉移到用戶單位使之在真實環境工作）九個工作流——業務建模（用業務用例對業務過程建模）需求（完成對系統需求的建模）分析和設計（使用體系結構模型、組件模型、對象模型和序列模型來創建并記錄設計模型）實現（實現系統中的組件并將他們合理安排在子系統中）測試（它的執行與實現緊密 聯系）部署（創建和分發產品版本并安裝到他們的工作場所）配置和變更管理（支持工作流管理對系統的變更）項目管理（支持工作流管理系統開發）環境（用于提 供軟件開發團隊可用的合適軟件工具）六個基本實踐（反復的開發軟件、管理需求、使用基于組件的體系結構、可視化模型軟件、驗證軟件質量、控制對軟件的變 更）

軟件系統需求常常分為功能需求、非功能需求和領域需求。1功能需求——包括對系統應該提供的服務、如 何對輸入作出反應以及系統在特定條件下的行為的描述。應該即、既全面（用戶所需服務都給出描述）又具有一致性（描述不能前后矛盾）2非功能需求——對系統 提供的服務或功能給出的約束。分類：產品需求（敘述產品行為的需求，包括可移植性和可用性需求）機構需求（起源于客戶所在的機構和開發者所在的機構中的政 策和規定）外部需求（包括所有系統外部因素和開發過程，如操作、法律、道德需求）3領域需求——來自系統的應用領域的需求，反映該領域的特點。

用 戶需求是從用戶角度來描述系統功能和非功能需求，以便讓不具備專業技術知識的用戶能看懂。編寫用戶需求的一些原則：1設計一個標準的格式，保證所有的需求 定義按照該格式書寫。2使用一致的語言。定義強制性需求要使用“必須”；定義希望性需求時使用“應該”。3對文本加亮來突出顯示關鍵性需求。4盡量避免用 計算機專業術語。

系統需求：是用戶需求的擴展版，是軟件工程師開始系統設計的起點。僅僅描述系統的外部行為和對它的操作上的限制，而不包括系統應該如何設計和實現。

信息持有者（對系統需求有直接或間接影響力的人）

需 求導入和分析：軟件開發技術人員要和客戶及系統最終用戶一起調查應用領域。包括：需求發現（收集準備建立的系統和正在使用的系統的信息，并從這些信息當中 提取用戶和系統的需求）需求分類和組織、優先排序和沖突解決、需求文檔編制（記錄需求并將它作為螺旋下一循環的輸入，產生形式化的或非形式化的需求文檔）

視點：需求工程的面向視點的方法將導出過程和需求本身都用視點來組織。1交互者視點（代表與系統直接交互的人或其他系統）2間接視點（代表那些不使用系統本身但是以某種方式影響需求的信息持有者）3領域視點（代表領域和影響系統需求的那些約束）

場景：描述人如何與一個軟件系統交互。

用例：是一種基于場景的需求導出技術，識別與系統的單個交互。

需求管理是一個對系統需求變更了解和控制的過程，需要跟蹤各個需求并維護他們與所依賴需求之間的關聯關系。分持久和易變的需求。

在 需求管理階段，必須決定一下內容——需求識別、需求管理過程、可追溯策略、CASE工具支持。3類可追溯信息：1源可追溯性信息連接需求到提出需求的信息 持有者和這些需求的基本原理2需求可追溯性信息連接需求文檔中 依賴的需求3設計可追溯性信息連接需求到其實現的設計模塊。需求變更管理三個階段：1問題分析和變更描述階段（要對問題或變更提議進行分析以檢查它的有效 性）2變更分析和成本計算（對被提議的變更產生的影響進行評估并且估計系統設計和實現的成本）3變更實現。體系結構設計是設法建立一個系統組成來滿足功能性和非功能性需求。所 開發的體系結構模型會包括：靜態結構模型（給出子系統或組件，將其作為一個個獨立的單元開發）動態過程模型（給出系統在運行時的過程組成）接口模型（定義 每個子系統從它們的公共接口能得到服務）關系模型（給出如子系統間的數據流這樣的關系）分布模型（給出子系統在多臺計算機上是如何分布的）模 塊化分解：將子系統分解為模塊，有兩種策略：1 面向對象的分解（將系統分解為一組相互通信的對象）一個面向對象的系統體系結構模型是將系統看成一組松散的對象結合，這些對象都有良好的接口定義，對象請 求其他對象提供的服務。優勢在于其對象間是松散耦合的，對對象實現的修改可以不影響其他對象，缺點在于對象必須明確地給出引用的其他對象的名字及其接口。2 面向功能的流水線操作（將系統分解為一些功能模塊，這些功能模塊接受輸入并轉換它們為輸出數據）好處在于1支持換換的復用2直觀，能將它們的工作理解成輸 入輸出處理3可以簡單的再系統中增加新的轉換4無論作為順序的還是并發的系統，其實現容易。其主要缺點是需要一種適合于所有轉換的通用格式。

數據處理系統是批處理系統，數據的輸入和輸出時成批地從文件或數據庫中取出或存入，而不是對用戶終端進行輸入和輸出。形成輸入—處理—輸出結構。事務處理系統是設計用來處理用戶對數據庫信息的查詢或者請求更新數據庫的。

快速軟件開發的原因：新的軟件需要快速開發來順應新的的機遇，響應競爭壓力。事實上很多業務都寧愿犧牲一些軟件的質量并降低某些需求來贏得快速軟件移交。還因為業務運營于一個變化的環境中，因此實際上通常不可能導出一個完全的穩定的軟件需求。

基本特征：1描述、設計和實現過程是并發的2系統通過一系列增量開發出來3系統用戶界面通常是采用交互式開發系統開發的。

敏 捷方法的基本原則：客戶參與（客戶應該在開發過程中始終緊密參與其中）增量式移交（軟件以增量的方式進行開發，客戶指定每個增量中的包含需求）人非過程（開發團隊的技術應該得到承認和發揚）接收變更（設計系統使之適應這些變更）保持簡單性（致力于所開發的軟件和開發過程的簡單性）

極限編程 的經驗：增量式規劃（需求記錄在腳本上，開發者將腳本分解為開發任務）小版本（首先開發能提供業務價值的一個最小有用集合）簡單設計（只進行有限需求設 計）測試優先開發（功能實現之前，采用一個自動單元測試框架來書寫此新功能的測試）重構（保持代碼簡單和可維護性）結對編程（檢查彼此工作提供支持）集體 所有（配對的開發人員參與系統的所有方面，所有開發者享有全部代碼）連續集成（任務一完成，就將它集成到大系統中）可忍受速度（不能接受大量超時）在場客 戶（系統最終用戶的代表應該全程滿時配合XP團隊）

檢驗和有效性驗證：實現過程之后，必須對所開發的程序進行驗證，它是對 這些檢查和分析過程的總稱。檢驗的作用是檢查軟件是否符合它的描述。應該檢查系統是否滿足了需求所定義的功能的和非功能的需求。有效性驗證卻是一個更一般的過程，其目標是保證軟件系 統能滿足客戶的期待。

V&V過程中，系統檢查和分析有兩種互補的方法：1軟件審查或配對審查——審查可以輔之以某些對系統源文本或 者是相關文檔的自動分析，是一種靜態的V&V技術，因為你無需再計算機上運行系統。2包括使用測試數據來運行軟件的實現，檢驗軟件的輸出和它的操 作行為，測試是一種動態的V&V技術。在軟件過程的不同階段，有2中截然不同的測試類型：1有效性測試——試圖證明軟件是用戶所期望的即滿足需求 2缺陷測試——試圖使缺陷暴露出來，而不是要仿真它在實際中的使用。發現程序和描述的不一致。

檢驗和有效性驗證過程試圖確定軟件系統中存在缺陷，程序調試時一個對缺陷定位和修正的過程。

軟件測試的目標：1向開發者和用戶展示軟件滿足它的需求。2為了找出軟件中的缺陷和不足，即軟件的活動室不正確的、所不希望的或不符合它的描述的。測試過程：組件測試（單個程序組件的測試）—系統測試（對一組組件集成的系統進行測試）

系統測試：兩個階段1集成測試（測試小組可以深入到系統源代碼）自上而下集成：首先開發系統的框架，然后將組件加入到框架中。自下而上集成：集成基礎設施組件，然后添加功能組件.2發布測試（對要發布給用戶的系統版本進行測試）測試原則：是給測試團隊提示，以幫助他們選擇將揭示系統中的缺陷測試。接口測試：目標是為了檢測由于接口的錯誤或無效的接口假設所造成的故障.接口類型1參數接口（數據從一個過程傳到另外一個過程）.2共享內存接口（內存塊為過程或函數所共享.）3程序接口（子系統封裝一組程序，這些程序為其他子系統調用.）4消息傳遞接口（子系統通過傳遞消息請求其他子系統上的服務）劃分測試：由于類中成員的這些等價行為，這些類通常叫做等價劃分或者域.結構化測試（白盒測試）：根據軟件的結構知識和實現知識導出測試的測試用例設計方法。路徑測試：目標是要練習組件或程序中的每一條執行路徑。

要 點：測試只能證明系統中存在錯誤，它不能說明系統中不再有缺陷.；組件測試是組件開發者的責任，獨立的測試團隊通常執行系統測試.；集成測試是最初的系統 測試活動，發布測試關心的是測試客戶版本，應該驗證所要發布的系統滿足了它的需求.；在缺陷測試時，應根據經驗和準則來設計測試用例.；接口測試是要發現 組合組件的接口中的缺陷.；等價劃分是導出測試用例的一個方法，需要找出輸入和輸出數據集合上的劃分并用這些劃分中的數據執行系統.；結構化分析依賴于分 析一個程序由此來確定路徑.；測試自動化通過使用一系列軟件工具支持測試過程，以減少測試過程的花費.什么是黑盒測試和白盒測試？ 任何工程產品（注意是任何工程產品）都可以使用以下兩種方法之一進行測試。黑盒測試：已知產品的功能設計規格，可以進行測試證明每個實現了的功能是否符合要求。白盒測試：已知產品的內部工作過程，可以通過測試證明每種內部操作是否符合設計規格要求，所有內部成分是否以經過檢查。軟件的黑盒測試意味著測試要在軟件的接口處進行。這種方法是把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需 求規格說明書，檢查程序的功能是否符合它的功能說明。因此黑盒測試又叫功能測試或數據驅動測試。黑盒測試主要是為了發現以下幾類錯誤：

1、是否有不正確或遺漏的功能？

2、在接口上，輸入是否能正確的接受？能否輸出正確的結果？

3、是否有數據結構錯誤或外部信息（例如數據文件）訪問錯誤？

4、性能上是否能夠滿足要求？

5、是否有初始化或終止性錯誤？ 軟件的白盒測試是對軟件的過程性細節做細致的檢查。這種方法是把測試對象看做一個打開的盒子，它允許測試人員利用程序內部的邏輯結構及有關信息，設計或選 擇測試用例，對程序所有邏輯路徑進行測試。通過在不同點檢查程序狀態，確定實際狀態是否與預期的狀態一致。因此白盒測試又稱為結構測試或邏輯驅動測試。白 盒測試主要是想對程序模塊進行如下檢查：

1、對程序模塊的所有獨立的執行路徑至少測試一遍。

2、對所有的邏輯判定，取“真”與取“假”的兩種情況都能至少測一遍。

3、在循環的邊界和運行的界限內執行循環體。

4、測試內部數據結構的有效性，等等。以上事實說明，軟件測試有一個致命的缺陷，即測試的不完全、不徹底性。由于任何程序只能進行少量（相對于窮舉的巨大數量而言）的有限的測試，在未發現錯誤 時，不能說明程序中沒有錯誤。

配置管理的重要性：涉及程序和標準的發展和應用來管理不斷發展的軟件產品；配置管理有時候被看做是軟件質量管理過程的一部分；當進行配置管理時，受控系統有時也稱為基線，因為它們是受控進化的一個起點.四種主要配置管理活動： 配置管理規劃：描述配置管理應該使用的標準和規劃。1配置項識別（應該定義文檔命名規則，以便類型相同的文檔命名也類似）2配置數據庫（用于記錄與配置有關的所有信息）

變更管理：需求不斷發生變化，系統也相應作出變更。關注的是對變化保持跟蹤，并確保它們用最具成本效益的方式實施.變更請求表（記錄了變更的建議、變更的請求、變更的原因以及變更的迫切性.它還記錄了變更評估、影響分析、變更成本和建議.）

版本和發布管理：是識別和追蹤一個系統的各個版本和發布的過程。版本 一個系統版本就是一個系統實例，在某種程度上有別于其他系統實例.變體 有一些版本可能在功能上沒有什么區別，只是為了不同的硬件或軟件配置而設計.發布版本： 一個系統的發布版本就是要分發給客戶的版本.版本管理規程應該規定明確的標識每個組件版本的方法.三種基本的版本標識方法 1版本編號;2基于屬性的標識;3面向變更的標識.系統構建：把軟件組件編譯和連接成一個程序并在特定目標配置上運行的過程.CASE工具可用于支持所有的配置管理活動.支持配置管理的CASE工具可以是一些獨立的工具分別用來支持變更管理、版本管理和系統構建，也可以是集成的系統，為所有的配置管理支持提供一個一致的接口.

第二篇：軟件工程重點總結

1、什么是軟件危機？

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

2、軟件危機的主要表現

（1）對軟件開發成本和進度的估計常常很不準確

（2）用戶對“已完成的”軟件系統不滿意現象經常發生

（3）軟件產品質量往往靠不住

（4）軟件往往是不可維護的（5）軟件通常沒有適當的文檔資料

（6）軟件成本在計算機系統總成本中所占的比例逐年上升

（7）軟件開發生產效率提高的速度，遠遠跟不上計算機應用迅速普及深入的趨勢

3、軟件危機產生的原因

(1)來自軟件自身的特點

是軟件系統的邏輯部件，缺乏可見性，管理和控制軟件開發過程相當困難；規模龐大、復雜，修改、維護困難。

(2)軟件開發與維護的方法不當

忽視需求分析；認為軟件開發等于程序編寫；輕視軟件維護。

4、如何消除軟件危機？

（1）對計算機軟件有一個正確的認識(軟件≠程序）

（2）必須充分認識到軟件開發不是某種個體勞動的神秘技巧，而應該是一種組織良好、管理嚴密、各類人員協同配合、共同完成的工程項目

（3）推廣使用在實踐中總結出來的開發軟件的成功技術和方法

（4）開發和使用更好的軟件工具

5、面向對象的三種模型：對象模型 動態模型 功能模型 P2166、模塊獨立性的兩個標準：耦合 內聚 P977、軟件測試方法：黑盒測試 白盒測試 P1518、軟件調試的途徑：蠻干法 回溯法 原因排除法 P1789、可行性研究：確定問題是否有行得通的解決辦法 P3510、需求分析：準確地回答“系統必須干什么”這個問題 P5511、軟件成分的重用級別：代碼重用 設計結果重用 分析結果重用

可被重用的軟件成分有：項目計劃，成本估計，體系結構，需求模型和規格說明，設計，源代碼，用戶文檔和技術文檔，用戶界面，數據，測試用例。

12、軟件可靠性的定義：軟件在給定的時間間隔內，按照規格說明書的規定成功地運行的概率。

軟件可用性的定義：程序在給定的時間點，按照規格說明書的規定，成功地運行的概率。可靠性與可用性之間的主要差別是，可靠性意味著在0到t這段時間內系統沒有失效，而可用性只意味著在時刻t，系統是正常運行的。P17913、白盒測試：邏輯覆蓋 控制結構測試 P162

黑盒測試：等價劃分 邊界值分析 調試 P171

環形復雜度的計算：復雜度=邊數-點數+2P13714、面向對象的3個子模式：對象模型 動態模型 功能模型 P232

對象模型的5個層次：主題層 類與對象層 結構層 屬性層 服務層 P23215、軟件定義階段干什么事：確定軟件開發工程必須完成的總目標；確定工程的可行性；導

出實現工程目標應該采用的策略及系統必須完成的功能；估計完成該工程需要的資源和成本，并制定工程進度表。

16、類和對象的關系：類是具有相同數據和相同操作的一組相似對象的定義，也就是說，類

是對具有相同屬性和行為的一個或多個對象的描述。類是支持繼承的抽象數據類型，而對象就是類的實例。P21117、UML有哪些圖？ P2171、用例圖：展示系統外部的各類執行者與系統提供的各種用例之間的關系

2、類圖：展示系統中類的靜態結構

3、對象圖：是類圖的一種實例化圖

4、狀態圖：描述一類對象具有的所有可能的狀態及其轉移關系

5、時序圖：展示對象之間的一種動態協作關系

6、合作圖：從另一個角度展示對象之間的動態協作關系

7、活動圖：展示系統中各種活動的執行流程

8、構件圖：展示程序代碼的物理結構

9、配置圖：展示軟件在硬件環境中的配置關系

18、能力成熟度模型（CMM）：初始級 可重復級 已定義級 已管理級 優化級 P31119、什么是軟件生命周期模型?試比較瀑布模型、快速原型模型、增量模型和螺旋模型的優

缺點，說明每種模型的適用范圍。P33習題1.720、軟件的可維護性定義：維護人員理解、改正、改動或改進這個軟件的難易程度。決定可維護性的因素：可理解性 可測試性 可修改性 可移植性 可重用性。

文檔是影響可維護性的決定性因素。P19521、如何評價軟件規格說明書？

從四個方面：一致性 完整性 現實性 有效性 P7022、層次圖 P10223、深度：軟件結構中控制的層數 P100

寬度：軟件結構中同一個層次上的總數的最大值

扇出：一個模塊直接控制（調用）的模塊數目

散入：一個模塊被多少個上級模塊直接調用

24、面向數據流的設計方法 P10425、類構件的重用方式：實例重用 繼承重用 多態重用

1.什么是軟件工程？軟件工程和計算機科學有何區別？

軟件工程是指導計算機軟件開發和維護的一門工程學科。

計算機科學研究的是構成計算機和軟件系統基礎的有關理論和方法，而軟件工程則是研究軟件制作中的實際問題。

2、流程圖與數據流圖有什么主要區別？

（1）數據流圖（date flow diagram , DFD），是SA方法中用于表示系統邏輯模型的一種工具，它以圖形的方式描繪數據在系統中流動和處理的過程，由于它只反映系統必須完成的邏輯功能，所以它是一種功能模型，是從數據的角度來描述一個系統的；而流程圖則是從對數據加工的角度來描述系統的；

（2）數據流圖中的箭頭是數據流，而流程圖中的箭頭則是控制流,它表達的是程序執行的次序；

（3）數據流圖適合于宏觀地分析一個組織業務概況,而程序流程圖只適合于描述系統中某個加工的執行細節。

（4）數據流程圖應該重點描述了數據加工的過程，主要是模塊內部，數據流圖則是描述模塊之間的關系。

3．軟件需求分析的任務是什么？有哪些主要步驟？

需求分析的基本任務是深入描述軟件的功能和性能、確定軟件設計的約束和軟件同其它系統元素的接口細節、定義軟件的其它有效性需求，總之，需求分析的任務就是借助于當前系統的邏輯模型導出目標系統的邏輯模型，解決目標系統的 “做什么” 的問題。

主要步驟：

1.問題識別

(1)功能需求：明確所開發的軟件必須具備什么樣的功能。

(2)性能需求：明確待開發的軟件的技術性能指標。

(3)環境需求：明確軟件運行時所需要的軟、硬件的要求。

(4)用戶界面需求：明確人機交互方式、輸入輸出數據格式。

2.分析與綜合，導出軟件的邏輯模型

分析人員對獲取的需求，進行一致性的分析檢查，在分析、綜合中逐步細化軟件功能，劃分成各個子功能。用圖文結合的形式，建立起新系統的邏輯模型。

3.編寫文檔

(1)編寫“需求規格說明書”，把雙方共同的理解與分析結果用規范的方式描述出來，作為今后各項工作的基礎。

(2)編寫初步用戶使用手冊，著重反映被開發軟件的用戶功能界面和用戶使用的具體要求，用戶手冊能強制分析人員從用戶使用的觀點考慮軟件。

(3)編寫確認測試計劃，作為今后確認和驗收的依據。

(4)修改完善軟件開發計劃。在需求分析階段對待開發的系統有了更進一步的了解，所以能更準確地估計開發成本、進度及資源要求，因此對原計劃要進行適當修正。

4．簡述結構化分析、設計的要點：

結構化分析方法適合于數據處理類型軟件的需求分析。

其要點是“自頂向下” 地開發系統,由整體到各組成部分,由表及里,由抽象到具體,逐步求精.(1)模塊化

(2)由頂向下,逐步求精.(3)上層模塊分解為下層模塊,有三種不同的結構形式,即順序結構,選擇結構和循環結構.5．數據字典包含哪些主要內容？

數據字典通常包括數據項、數據結構、數據流、數據存儲和處理過程五個部分.據字典內容包括：

數據庫中所有模式對象的信息，如表、視圖、簇、及索引等。

分配多少空間，當前使用了多少空間等。

列的缺省值。

約束信息的完整性。

用戶的名字。

用戶及角色被授予的權限。

用戶訪問或使用的審計信息。

其它產生的數據庫信息。

6．軟件測試的目標是什么，有哪幾種主要有測試方法？

軟件測試的目標：

(1)測試是為了發現程序中的錯誤而執行程序的過程；

(2)好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案；

(3)成功的測試是發現了至今為止尚未發現的錯誤的測試。

軟件測試的方法有黑盒測試、白盒測試。

7．白盒測試主要有哪些覆蓋？

語句覆蓋、判定覆蓋、條件覆蓋、判定/條件覆蓋、條件組合覆蓋、點覆蓋、邊覆蓋、路徑覆蓋

8、選擇一種程序設計語言的主要有哪些依據？

為了使程序容易測試和維護以減少生命周期的總成本，選用的高級語言應該有理想的模塊化機制，以及可讀性好的控制結構和數據結構；為了便于調試和提高軟件可靠性，語言特點應該使編譯程序能夠盡可能多地發現程序中的錯誤；為了降低軟件開發和維護的成本，選用的語言應該有良好的獨立編譯機制。上述這些要求是選擇語言的理想標準，但是在實際選用語言時不能僅僅考慮理論上的標準，還必須同時考慮實用方面的各種限制。

(1)系統用戶的要求

(2)可以使用的編譯程序

(3)可以得到的軟件工具

(4)系統規模

(5)程序員的知識

(6)軟件可移植性要求

(7)軟件的應用領域

9．軟件的維護的目標是什么，有哪幾種維護類型？

糾正在使用過程中暴露出來的錯誤而進行的改進性維護，適應外部環境的變化而進行的適應性維護，改進原有的軟件而進行的完善性維護，以及改進將來的可維護性和可靠性而進行的預防性維護。

軟件維護主要劃分為糾錯性維護、適應性維護和完善性維護。

(1)糾錯性維護。由于前期的測試不可能揭露軟件系統中所有潛在的錯誤，用戶在使用軟件時仍將會遇到錯誤，診斷和改正這些錯誤的過程稱為糾錯性維護。

(2)適應性維護。由于新的硬件設備不斷推出，操作系統和編譯系統也不斷地升級，為了使軟件能適應新的環境而引起的程序修改和擴充活動稱為適應性維護。

(3)完善性維護。在軟件的正常使用過程中，用戶還會不斷地提出新的需求。為了滿足用戶新的需求而增加軟件功能的活動稱為完善性維護。

10．簡述提高軟件質量的主要措施。

復審：是在軟件生命周期每個階段結束之前，都采用一定的標準對該段產生的軟件配置成分進行嚴格的正式或非正式的檢測。

復查：是檢查已有的材料，以斷定在軟件生命周期某個階段的工作是否能夠開始或繼續。管理復審：是向開發組織或使用部門的管理人員提供有關項目的總體狀況、成本和進度等方面的情況，以便他們從管理角度對開發工作進行審查。

測試：包括測試計劃、測試過程和測試結果3個階段。

11．面向對象如何實現模塊獨立性，其偶合和內聚的含義是什么？

因為對象是由數據及可以對這些數據施加的操作所組成的統一體，而且對象是以數據為中心的，操作圍繞對其數據所需做的處理來設置，沒有無關的操作。因此，對象內部各種元素彼此結合得很緊密。內聚性相當強，由于完成對象所需要的元素（數據和方法）基本上都被封裝在對象內部，它與外界的聯系自然就比較少。因此，對象之間的耦合通常比較松。總之，面向對象使用對象、類、繼承和消息的方法，既使用類和繼承等機制，而且對象之間僅能通過傳遞消息實現彼此通信來實現模塊的獨立性。

12．面向對象和面向過程軟件工程有哪些區別？

（1）面向過程就是分析出解決問題所需要的步驟，然后用函數把這些步驟一步一步實現，使用的時候一個一個依次調用就可以了。面向對象是把構成問題事務分解成各個對象，建立對象的目的不是為了完成一個步驟，而是為了描敘某個事物在整個解決問題的步驟中的行為。（2）面向過程是把一件事一項工程分解成為一個個小的功能,用一個個函數來實現.面向對象是把事情看成是一個個小的對象組成的,或者說一個個小部分組成的,這些對象之間的相互關系,構成了整個項目.在面向對象的思想中，萬物皆對象。而“類”，就是對象的抽象或者說是概括。

13.簡述對象、類、消息、方法的基本概念。

(1)對象是人們要進行研究的任何事物，從最簡單的整數到復雜的飛機等均可看作對象，它不僅能表示具體的事物，還能表示抽象的規則、計劃或事件。

(2)類是具有相同或相似性質的對象的抽象。對象的抽象是類，類的具體化就是對象，也可以說類的實例是對象。類具有屬性，它是對象的狀態的抽象，用數據結構來描述類的屬性。類具有操作，它是對象的行為的抽象，用操作名和實現該操作的方法來描述。

(3)對象之間進行通信的結構叫做消息。在對象的操作中，當一個消息發送給某個對象時，消息包含接收對象去執行某種操作的信息。發送一條消息至少要包括說明接受消息的對象名、發送給該對象的消息名（即對象名、方法名）。一般還要對參數加以說明，參數可以是認識該消息的對象所知道的變量名，或者是所有對象都知道的全局變量名。

(4)類中操作的實現過程叫做方法，一個方法有方法名、參數、方法體。

14．簡述面向對象分析設計的三個模型。

答：三個模型：對象模型、動態模型、功能模型

（1）對象模型描述系統的靜態結構，包括類和對象，它們的屬性和操作，以及它們之間的關系。構造對象模型的目的在于找出與應用程序密切相關的概念。對象模型用包含對象及對象的關系圖表示。

（2）動態模型著重于系統的控制邏輯，考察在任何時候對象及其關系的改變，描述這些涉及時序和改變的狀態。動態模型包括狀態圖和事件跟蹤圖。狀態圖是一個狀態和事件的網絡，側重于描述每一類對象的動態行為。事件跟蹤圖則側重于說明系統執行過程中的一個特點“場景”，也叫做腳本(scenarios)，是完成系統某個功能的一個事件序列。腳本通常起始于一個系統外部的輸入事件，結束于一個系統外部的輸出事件。

（3）功能模型著重于系統內部數據的傳送和處理。功能模型表明，通過計算，從輸出數據能得到什么樣的輸出數據，但不考慮參加計算的數據按什么時序執行。功能模型由多個數據流圖組成，它們指明從外部輸出，通過操作和內部存儲，直到外部輸出的整個數據流情況。功能模型還包括了對象模型內部數據間的限制。功能模型中的數據流圖往往形成一個層次結構，一個數據流圖的過程可以由下一層的數據流圖作進一步的說明。

第三篇：軟件工程 重點歸納

程序：能夠完成預定功能、并滿足性能要求的可執行的指令序列。

軟件:計算機程序以及開發、使用和維護程序所需要的所有文檔,是包括程序、數據及其相關文檔的完整集合。

軟件=知識+程序+文檔+數據

1、程序設計時期（1946～1956）軟件=程序

開發方式：個體

主要特征：計算機硬件=計算機

用途少，規模小；不作為商品；

開發者=使用者：自己開發，自己使用。

2、程序系統時期（1956～1968）軟件=程序+說明

開發方式：作坊式

主要特征：程序規模增大，多人分工合作。

軟件作為商品，即程序設計者≠使用者；

程序開發和使用的文檔資料已不可缺少。

3、軟件工程時期（1968～現在）軟件=程序+數據+文檔

開發方式：工程化

主要特征：按工程管理的方法管理整個軟件開發過程。

軟件生產的進度、數量、質量、成本與社會對軟件的需求量和希望要求甚遠，開發成本和進度難以控制，指令難以保證，與硬件發展形成強烈反差。這就是所謂的“軟件危機”。--現實與希望形成的巨大落差 產生軟件危機的原因 ●客觀原因：

軟件是手工勞動，是智力產品----生產率低。

軟件是邏輯實體，出錯容易，糾錯困難。

軟件的復雜性使得僅靠人的智力難以駕馭。●主觀原因

開發方式：認為開發軟件就是寫程序。

組織方式：作坊式的生產方式；開發無計劃、開發過程無規范、開發過程難控制。

用戶方面：對軟件需求描述不精確。

開發人員方面：對用戶需求的理解與用戶本來愿望有差異，相互之間的信息交流不及時、不準確、有誤解。

成本、進度和質量

軟件工程三要素：過程、方法和工具

軟件生存周期包括三個時期：

軟件定義

問題定義、可行性研究、需求分析

? 需求規格說明書 ? 初步用戶手冊 ? 軟件初步測試計劃

軟件開發 概要設計、詳細設計、編碼及模塊測試、綜合測試

軟件使用和維護 改正性維護、適應性維護、完善性維護、預防性維護

軟件過程模型--瀑布模型

軟件過程模型—螺旋模型

數據字典的內容：

數據流

數據元素

數據存儲

處理

數據結構的定義：描述數據結構的組成（1）定義式

數據結構名=數據項1+數據項2+……+數據項n 數據定義使用的符號： = 定義為

+ 和：連接兩個分量 [ ] 選擇：表示從中選擇一項。{ } 重復：表示由0個或多個組成。

m{ }n 重復：表示至少出現m次，至多出現n次。

（）可選：表示其中的內容可出現，也可不出現。

IPO（Input/process/output）圖是輸入/處理/輸出的簡稱，是由IBM公司發展完善起來的一種圖形工具，能方便地描繪輸入數據、數據的處理和輸出數據之間的關系。

ER模型包括“實體”、“聯系”和“屬性”三個基本部分。

實體：是客觀世界中存在的且可以相互區分的 物。如：職工、教師、產品等 聯系：客觀世界中事物間的聯系。往往表示實體間發生的某種行為。屬性：是實體或聯系具有的性質，通常一個實體由若干個性質來刻畫。

通常用“范式”（Normal Formas）定義消除數據的冗余的程度。

總體設計過程

一、系統體系結構設計

二、軟件結構設計

三、數據庫設計

四、制定測試計劃

五、書寫文檔

六、審核和復審

軟件設計原理

? 抽象——抽出事物的本質特征而暫不考慮它們的細節。

? 抽象和求精是一對互補的概念。求精則是幫助設計者逐步揭示出低層細節。這兩個概念都有助于幫助設計者在設計演化過程中構造出完整的設計模型。

? 模塊化

? 信息隱蔽（和局部化）——信息隱蔽是模塊設計的基本原則，局部化是實現信息

隱蔽的重要方法。? 模塊獨立

? 模塊的獨立程度的度量標準——內聚:衡量一個模塊內部各個元素彼此結合的緊密程度；耦合:衡量不同模塊彼此間互相依賴（連接）的緊密程度。

層次圖：描述軟件的層次結構（H圖）。

層次圖中每個矩形框代表一個模塊，矩形框之間的連線表示模塊調用關系。

層次圖適合用來描繪軟件的層次結構。HIPO圖：層次圖+IPO圖

對H圖的每個方框，都有一張IPO圖與之對應，來描述方框所代表的模塊的處理過程。并且對每個IPO圖都對應H圖中方框相同的標記和編號，便于追蹤。

面向數據流的設計方法

? 概念

? 變換流分析設計 ? 事物流分析設計 ? 混合流分析設計 ? 設計優化

PAD是問題分析圖（Problem Analysis Diagram）

變換流：

事務流：

概要設計小結

一、任務

1、系統體系結構設計：確定系統的總體物理實現方案。

2、軟件結構設計：確定模塊和模塊間的動態調用管理。

3、數據結構設計（或數據庫設計）：確定系統中數據的總體結構。（數據庫：邏輯設計、物理設計、安全性設計）。

4、接口設計：外部接口、人機界面設計

二、設計原理

1、模塊獨立性原理：信息隱蔽、耦合、內聚

2、思維工具：抽象

3：啟發式規則：改進軟件結構，提高系統質量

三、設計工具： HIPO圖、結構圖

四、面向數據流的設計方法----結構化設計方法

1、從分析型的數據流圖向軟件結構的轉換

2、從事務型的數據流圖向軟件結構的轉換

詳細設計工具分為圖形、表格和語言三類。主要工具有： ■程序流程圖 ■盒圖（N-S圖）■PAD圖 ■判定表 ■判定樹

■過程設計語言（PDL）

McCabe方法根據程序控制流的復雜程度來定量度量程序的復雜程度，這樣度量出的結果稱為程序的環行復雜度。

用戶界面設計原則

1、置用戶于控制之下。用戶界面能夠對用戶的操作做出恰當的反應，并幫助用戶完成需要的工作。

2、減少用戶的記憶負擔。系統應該“記住”有關的信息，通過默認項、快捷方式或界面視覺減少用戶的記憶負擔。

3、保持界面的一致性。用戶應該以一致的方式展示和獲取信息。問題：

●系統響應時間 ●用戶幫助設施 ●錯誤信息處理 ●命令交互

界面設計包括：

●界面對話設計

●數據輸入界面設計

●數據輸出設計（屏幕顯示設計）。

常用的界面設計元素有：

●問題描述語言

●數據表格

●圖形與圖標

●菜單

●對話框

●窗口

G.J.Myers關于軟件測試的觀點:

1、測試是為了發現程序中的錯誤而執行程序的過程。

2、好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案。

3、成功的測試是發現了迄今為止尚未發現的錯誤的測試。

E.D.Dijkstra:程序測試能證明程序中的錯誤，是為了證明程序有錯，而不是證明程序無錯。必須記住：測試無法說明錯誤不存在，它只能表示軟件錯誤已經出現。

軟件測試準則

1、以用戶需求為基準

2、嚴格執行測試計劃

3、測試中的群集現象

2-8原理：80%的錯誤可能集中在20%的模塊中。

4、程序邏輯覆蓋程度

5、第三方獨立進行測試

6、合理的輸入和不合理的輸入

7、預期輸出結果

步驟：

1、模塊測試

2、子系統測試

3、系統測試

4、驗收測試

5、平行運行

確認測試包括：

●軟件有效性測試——運用黑盒測試方法，驗證軟件是否滿足需求規格說明書列出的需求。

●軟件配置復審——保證軟件配置的所有成分都齊全，質量符合要求，文檔與程序一致，具有完成軟件維護所必須的細節，并且已經編排好分類的目錄。、●α和β測試

●驗收測試。

白盒測試：按照程序內部邏輯測試程序。檢查程序中的每條通路是否都能按照預定要求正常工作。這種測試完全了解程序的結構和處理過程。因此，白盒測試又稱為結構測試或邏輯驅動測試。黑盒測試主要是為了發現一下幾類錯誤： ●是否有不正確或遺漏了的功能；

●界面錯誤：輸入能否正確地接受？能否輸出正確的結果？ ●是否有數據結構或外部信息（如數據文件）訪問錯誤； ●性能上是否能夠滿足要求； ●是否有初始化或終止性錯誤。

軟件工程的主要目的就是要提高軟件的可維護性，減少軟件維護所需要的工作量,降低軟件系統的總成本。

軟件維護——軟件投入運行后，解決發生的各種故障，增強其功能，使之適應新的環境的活動。

1、改正性維護

2、適應性維護

3、完善性維護

4、預防性維護

維護工作量： M=p+k*exp(c-d)

P:生產性工作量：分析、評價、設計、修改和編碼。K:經驗系數

C:程序復雜性系數：文檔少都會引起復雜程度增加。D:維護人員對軟件的熟悉程度

維護過程

? 維護組織

? 維護報告

? 維護的事件流

? 保存維護記錄

? 評價維護活動

為了確定軟件維護的有效程度，確定軟件產品的質量，同時確定維護活動的開銷，詳細記錄維護中進行的工作及工作量。主要內容包括（18項）

? 程序標識 ? 源程序語句數

? 機器指令條數 ? 使用的程序設計語言 ? 程序安裝的日期

? 安裝以來運行的次數 ? 安裝以來的失效次數 ? 程序變動的層次和標識 ? 每個改動耗費的人時數 ? 程序改動的日期 ? 程序變動增加的源語句數 ? 維護人員名字

? 程序變動而刪除的源語句數 ? 維護要求表的標識

軟件配置管理（SCM）

? 維護類型 ? 維護開始時間和完成時間 ? 累計用于維護的人時數

? 與完成的維護相聯系的純效益

軟件維護和軟件配置管理之間的區別是：維護是一組軟件工程活動，它們發生于軟件已交付用戶并已投入運行之后；軟件配置管理是一組跟蹤和控制活動，它們開始于軟件開發項目開始之時，結束于軟件被淘汰之時。

軟件配置管理的主要目標是使變更更容易地被適應，并減少當變化必須發生時所需花費的工作量。

對維護活動進行度量。內容包括：

（1）每次程序運行平均失效次數（2）用于每一類維護活動的總人時數

（3）平均每個程序、每種語言、每種維護類型所作的程序變動次數（4）維護過程中增加或刪除一個源語句平均花費的人時數。（5）維護每種語言花費的人時數（6）一張維護要求表的平均周轉時間（7）不同維護類型所占的百分比

第四篇：軟件工程重點整理

可以把軟件開發的本質概括為：不同抽象層術語之間，以及不同抽象層處理邏輯之間的映射 需求分析產生的正式文檔是需求規約

在結構化分析方法中，表示“數據的靜態結構”的術語是數據存儲

對模塊的寬度影響最大的因素是模塊的扇出 下列術語，可用于抽象客觀世界中事物的是類

大學由若干專業系構成，則大學與專業的關系是組合

下列軟件測試技術中，依據程序邏輯結構的是白盒測試技術 單元測試期間，通常考慮模塊的重要的執行路徑

軟件基本過程指那些與軟件生產直接相關的活動集，可分為供應過程、開發過程、運行過程、維護過程和獲取過程

在常見的軟件開發模型中，適用于項目的開發風險很大或客戶不能確定系統需求的模型是螺旋模型

CMMI 能力等級中的 3 級是已定義級

軟件生產率、軟件質量滿足不了社會發展的需求，并成為其發展的制約因素，這一現象被稱為軟件危機

對于單一的一個需求，必須具有的基本性質：必要的、無歧義的、可測試的、可跟蹤的以及可測量的。

需求規約的基本性質包括重要性和穩定性程度、可修改的、完整的和一致的

在結構化分析方法中，可采用結構化自然語言、判定表和判定樹描述加工

用于定義數據流圖包含的所有數據流和數據存儲的數據結構，直到給出構成以上數據的各數據項的基本數據類型的工具是數據字典

在 UML 中，用于描述關聯的一定“內涵”的術語是關聯名 RUP 利用 UML 提供的術語和工具定義了需求獲取層、系統分析層、設計層和實現層，并給出了實現各層模型之間映射的基本活動以及相關的指導

軟件測試是一個有程序的過程，包括測試設計、測試執行以及測試結果比較等

由于軟件錯誤的復雜性，在軟件工程測試中，應綜合運用測試技

術，并且應實施合理的測試序列：

單元測試、集成測試、有效性測試和系統測試

《IS0/IEC 軟件生存周期過程 12207—1995》標準按過程主體把軟件生存周期過程分為基本過程、支持過程和組織過程 針對開發的 CMMI 是一個有關產品和服務的過程改善的成熟度模型，集成了 3 個源模型：軟件 CMM、系統工程 CMM和產品集成開發 CMM

CMMI 中，遵循一個過程可達到的預期結果的程度是指過程能力

CMMI 模型基于過程途徑思想，通過過程把軟件質量的 3 個支撐點：受訓的人員、規程和方法、工具和設備進行集成，以開發所期望的系統/產品

請簡述計算機軟件的概念以及提出軟件工程概念的目的

（1）計算機軟件一般是指計算機系統中的程序及其文檔（2）其中，程序是計算機任務的處理對象和處理規則的描述（3）文檔是為了理解程序所需的闡述性資料（4）軟件工程概念的提出，其目的是倡導以工程的原理、原則和方法進行軟件開發，以解決出現的軟件危機。

請簡述初始發現需求的常用技術（1）自悟（2）交談（3）觀察（4）小組會（5）提煉

請敘述信息隱藏的概念及其意義

（1）信息隱藏是指在每個模塊中所包含的信息不允許其他不需要這些信息的模塊訪問（2）它是實現模塊低耦合的一種有效途徑（3）但是，如果一個模塊是“絕對”信息隱藏的，那么這種模塊對系統而言是毫無意義的

什么是驗證和確認？請敘述它們的區別

（1）驗證就是證實一個過程或項目的每一軟件工作產品/服務是否正確地反映了所規約的需求（2）確認就是證實所期望使用的軟件工作產品是否滿足其需求（3）區別：驗證是通過提供的客觀證據，證實規約的需求是否得以滿足；確認是通過提供的客觀證據，證實有關特定期望的使用或應用的需求是否得以滿足

第五篇：軟件工程重點總結

軟件工程復習重點總結

1.(P-2)

Analysis:

decompose a large problem into smaller, understandable pieces，(一個大問題分解成更小的、可以理解部分)abstraction is the key Synthesis:

build(compose)software from smaller building blocks,(生成撰寫軟件從較小的構造塊)composition is challenging 2Software Engineering Solving Problems(continued)：(P-4)

method： refers to a formal procedure（指的是一個正式的程序）

tool：an instrument or automated system for accomplishing something in a better way procedure（過程）：a combination of tools and techniques to produce a product（工具和技術來生產一種產品的組合）

paradigm（范例）：philosophy or approach for building a product 3.(P-6)

A fault: occurs when a human makes a mistake, called an error, in performing some software activities（在執行某些軟件活動）;

A failure: is a departure（偏差）from the system’s required behaviour;

Error can lead to fault；fault can lead to failure。4.participates in a project：(P-15)

Customer:

the company, organization, or person who pays for the software system Developer:

the company, organization, or person who is building the software system User: the person or people who will actually use the system

5.Activities and objects(P-16)– An activity is an event initiated by a trigger（活動是由一個觸發器的事件）– Objects or entities are the elements involved in the activities（Objects 或實體是要素參與活動的）

6.Relationships and the system boundaries(P-17)– A relationship defines the interaction among entities and activities（A 關系定義實體和活動的相互作用）

– System boundaries determine the origin of input and destinations of the output（邊界確定輸入的來源與目的地的輸出）

7.a system as a collection of things :(P-17)a set of entities(一組實體), a set of activities , a description of the relationships among entities and activities and a definition of the system.8.The development of software includes the following activities(P-24)? ? ? ? Requirements analysis and definition System design Program design Writing the programs ? Unit testing ? Integration testing ? System testing ? System delivery ? Maintenance 9.developer roles(P-26)Analyst

Designer

Programmer

Tester

Trainer 10.(P-45)A process: a series of steps involving activities, constrains, and resources that produce an intended output of some kind（一系列步驟涉及活動，受到了限制，及資源，產生一預期的輸出）

A process involves a set of tools and techniques 11.(P-46)

Software life cycle:

Implementation ,delivery ,use, and maintenance（實施、發布、使用及維修）

When a process involves building a software, the process may be referred to as software life cycle – – – – – – – Requirements analysis and definition System(architecture)design Program(detailed/procedural)design Writing programs(coding/implementation)Testing: unit, integration, system System delivery(deployment)Maintenance

12．software process models：（P-48）

Waterfall model

V model Prototyping model(原型化)Operational specification model Transformational model（轉化）

Phased development（階段化開發）: increments and iterations（反復遞增）Spiral model（螺旋模型）Agile methods（敏捷方法）

13.Prototyping is useful for verification(確認)and validation（驗證）（P-51）14.Elements of a process are viewed in terms of seven types（P-64）

Activity – Sequence – Process model 過程模型 – – – – Resource Control Policy Organization

15.Project schedule(P-83)Describes the software-development cycle for a particular project by

enumerating the phases or stages of the project(枚舉階段或項目的階段)

breaking each phase into discrete tasks or activities to be completed(每個階段分成離散任務或活動，以完成)

Portrays(描繪)the interactions(相互影響)among the activities and estimates(估算)the times that each task or activity will take

16.Activity and milestone(P-83)Activity: takes place over a period of time

Milestone: completion of an activity--a particular point in time

17.Critical Path Method(CPM)(P--87)

見作業

18.Key activities requiring personnel（P-95）

requirements analysis system design program design program implementation（實現，執行）testing training maintenance

quality assurance（保證）

19.risk（P—119）

is an unwanted event that has negative consequences(消極結果)

20.Risk impact(影響):（P--120）

the loss associated with the event與該事件關聯的損失

Risk probability(概率):

the likelihood that the event will occur事件發生的可能性

Risk control(控制):

the degree to which we can change the outcome我們可以更改結果的程度

Quantify(量化)the effect of risks：

Risk exposure =(risk probability)x(risk impact)

21.Risk management：（P--121）

risk assessment（評估）

risk control

22.（P--143）

A requirement：

is an expression of desired behaviour是所需行為的表達式 A requirement deals with ：

objects or entities，the states they can be in，and the functions that are performed to change states or object characteristics

23.Process for Capturing Requirements（P--144）

Elicitation（引入）

Analysis

Specification Validation（驗證）

////構成了software requirements specification(說明書)

24.functional requirement（P---148）

describes required behavior in terms of required activitie描述所需的活動所需的行為s Quality requirement or nonfunctional requirement describes some quality characteristic that the software must possess(擁有)

Design constraint(約束):

a design decision such as choice of platform or interface components設計的平臺或界面組件如選擇決策 Process constraint: a restriction on the techniques or resources that can be used to build the system 對技術或可用于構建系統的資源限制

25.Prioritization might separate requirements into three categories（P--152）

Essential(基本): absolutely must be met絕對需要滿足的需求

Desirable(合意): highly desirable but not necessary非常理想，但不必須的 Optional(可選): possible but could be eliminated但可能被淘汰

26.Requirements definition:（P--154）

a complete listing of everything the customer wants to achieve完整列表的客戶希望實現的一切

Describing the entities in the environment where the system will be installed

描述在將安裝在系統環境中的實體 Requirements specification:

restates（重申）the requirements as a specification of how the proposed（提出）system shall behave

27.ER diagram have three core constructs（P--158）ER 圖表有三個核心構造

An entity: depicted as a rectangle, represents a collection of real-world objects that have common properties and behaviors描述為一個的矩形表示一個實際

的對象的集合 具有公共屬性和行為

A relationship: depicted as an edge between two entities, with diamond in the middle of the edge specifying（指定）the type of relationship描述為一個兩個實體之間的邊緣

An attribute: an annotation(注解)on an entity that describes data or properties associated with the entity描述數據或與該實體相關聯的屬性的實體上的注釋

28.（P--172）

A data-flow diagram(DFD)models functionality and the flow of data from one function to another數據流關系圖 DFD 模型的功能和數據到另一個函數的流

– A buble represents a process一個 buble 表示一個流程 – An arrow represents data flow一個箭頭表示數據流量

– A data store: a formal repository(倉庫)or database of information –

Rectangles represent actors: entities that provide input data or receive the output result矩形表示參與者： 實體提供輸入的數據或接收輸出結果

–

29.(P--223)Design: is the creative process of transforming the problem into a solution The description of a solution is also known as design 是創造過程的問題轉化為解決方案的描述稱為設計

30.Design is a two-part interactive process(P—224)– Conceptual design(system design)(概念性設計)– Technical design(技術性設計)

–

31.(P—228)Modules or components: 組件

composite parts of design A system is modular when

– each activity of the system is performed by exactly one component活動的系統由一個組件執行

– inputs and outputs of each component are well-defined

? all inputs to it are essential to its function輸入其功能至關重要

? all outputs are produced by one of its actions輸出由其動作之一制作

32.Architectural Styles and Strategies Three Design Levels:(P—229)

Architecture（系統結構）

Code design

Executable design（執行設計）

33.Architectural Styles and Strategies Design Styles（P—230）

Pipes and filters(管道/過濾器)Object-oriented design Implicit invocation(隱式調用)Layering（分層設計）Repositories(數據倉庫)Interpreters(解釋器)Process control(過程控制)Client-server(客戶/服務器)

34.Component independence（P--248）

Coupling(耦合度)Cohesion(內聚度)Highly coupled when there is a great deal of dependencies Loosely coupled components have some dependency, but the interconnections among components are weak（大多數采用松散）

Uncoupled components have no interconnections at all

35.We can measure coupling along a range of dependence（P--249）

Characteristics of Good Design Coupling: Types of Coupling

Content(內容)coupling

Common(公共)coupling Control(控制)coupling Stamp(標記)coupling Data(數據)coupling 36.Exceptions can be handled in one of three ways：（P—255）異常處理

– Retry(重試)– Correct(更正)– Report(報告)

37.program component involves at least three major aspect:(P---340)

Control structures ,algorithms,and data structure 38.making the codeefficiency(效率)may have hidden costs(代價)(P--342)– cost to write the code faster – cost to test the code – cost to understand the code – cost to modify the code

39.Software Faults and Failures types of Faults(P--367)軟件故障及故障的類型的故障

Algorithmic fault算法

Computation and precision fault 計算和精度 Documentation fault Stress or overload faults Capacity or boundary faults 容量邊界 Timing or coordination faults(協調)Throughput(吞吐量)or Performance faults Recovery fault 恢復故障

Hardware and system software fault Standards and procedures fault

40.Testing Organization（P—371.）

Module testing, component testing, or unit testing(單元測試)Integration testing(集成測試)The next step is ensuring that the interfaces among the components are defined and handled properly.Performance testing(性能測試)Compares the system with the remainder of these software an hardware requirements.41.Testing steps（P--372）

42.Integration Testing集成測試（P--390）具體實例見作業

Bottom-up(自底向上)

Merging components to test the larger system

Top-down(自頂向下)

Big-bang(大棒)

Sandwich testing(多層結構測試)

Modified top-down(改性自上而下)

Modified sandwich(改性多層結構測試)

43.Principles of System Testing Regression Testing Steps（P—425）系統測試回歸測試步驟的原則

? Inserting the new code ? Testing functions known to be affected by the new code ? Testing essential function of m to verify that they still work properly整體 ? Continuing function testing m + 1

44.Types of Performance Tests（P--436）性能測試

Stress tests(壓力)Volume tests(容量)Configuration tests(配置)Compatibility tests(兼容)

Regression tests(回歸)Security tests(安全)Timing tests(響應時間)Environmental tests(環境)Quality tests(質量)Recovery tests(恢復)Maintenance tests(可維護性)Documentation tests(文檔)Human factors(usability)tests(使用)

45.Software reliability:

operating without failure under given condition for a given time interval 無故障下經營給予指定的時間間隔內的條件 Software availability:

operating successfully according to specification at a given point in time 成功經營，依法規范在指定點的時間 Software maintainability:

for a given condition of use, a maintenance activity can be carried out within stated time interval, procedures and resources 為給定的使用條件，維護活動可以內進行既定的時差 過程資源

注意：作業是重點，必考！這個翻譯（長字段的）僅供參考，要結合軟件工程的角度加以分析理解！