第一篇：軟件工程考試

第一章 軟件工程學概述

1.軟件的概念，軟件的分類

答：軟件=程序+數據+文檔；

按規模分類：微型、小型、中型、大型、甚大形、極大型（6）

按性質分類：系統軟件、支撐軟件、應用軟件（3）

按工作方式分類：實時、分時、交互式、批處理（4）

按服務對象分類：項目軟件、產品軟件（2）

2.軟件危機產生的原因（2點），緩解軟件危機的途徑

答：和軟件本身的特點有關，和開發軟件的方法不正確有關；

軟件工程；

3.軟件生命周期包含的活動

答：問題定義、可行性研究、需求分析、總體設計、詳細設計、編碼、測試（8）

4.問題定義階段的任務

答：確定軟件規模、性質、目標

5.常見的軟件開發模型

瀑布模型：適用范圍是需求確定的軟件開發，是描述結構化的軟件開發模型；

快速原型模型：適用范圍是需求不確定的軟件開發；

噴泉模型：是描述面向對象的軟件開發模型；

第二章 可行性研究

1.可行性研究從哪些方面進行

答：經濟，技術，法律，操作（4）

2.系統流圖SFD的作用

答：描述系統的工作過程，建立系統的業務模型

3.數據流圖DFD的作用，符號，畫法

答：描述系統的功能，建立系統的功能模型

符號：外部實體（正方形），處理（圓形），存儲（雙實線），數據流（單箭頭線）畫法：分離成分，分層畫DFD（頂層，0層，1層）

第三章 需求分析

1.結構化的需求分析方法SA的原理

答：用DFD、DD進行功能分析，建立系統的功能模型，用E-R進行數據分析，建立系統的數據模型

第五章 總體設計

1.總體設計的原理

答：模塊化、抽象、逐步求精、信息隱藏和局部化、模塊獨立（5）

2.衡量模塊獨立的指標

答：耦合，內聚 3.總體設計的啟發規則（7點）

答：改進軟件結構提高模塊獨立性

模塊規模應該適中

深度、寬度、扇出和扇入都應適當

模塊的作用域應該在控制域之內

力爭降低模塊接口的復雜程度

設計單入口單出口的模塊

模塊功能應該可以預測

4.結構化的設計方法SD的原理

答：將DFD映射成軟件結構圖

第六章 詳細設計

1.用結構化方法進行開發在詳細設計階段的任務

答：對模塊進行設計，主要是設計模塊的界面和算法 2.結構化程序設計SP的原則（7點）

答：采用自頂向下、逐步求精的設計方法

程序中用順序、選擇、多分支、while型循環、until型循環表示程序邏輯

每種控制結構單入口、單出口

程序語句組成模塊，每個模塊單入口單出口

復雜的結構用5種基本控制結構組合嵌套實現

嚴格控制goto語句的使用，在下列情況可用：

在非結構化的語言中，用goto語句實現結構化的構造

在某種可以改善而不是損害可讀性的情況下

不僅要注意程序的結構化，還要注意數據結構的合理化

3.判斷算法是否為結構化的依據（3點）

答：由5種基本控制結構組成；

每種控制結構單入口單出口；

模塊單入口單出口

4.描述算法的工具

答：圖形工具：N-S圖，PAD圖，活動圖

語言工具：PDL語言

表格工具：判定表、判定樹

5.算法環形復雜度的度量（流程圖-流圖-區域數）

答：流程圖-流圖轉換方法：

一個判斷框縮成一個點；

一個處理框縮成一個點；

一個順序處理序列縮成一個點；

判定框和與之相連的處理框縮成一個點；

真假分支的匯聚點增加一個點

第七章 實現

1.編碼的風格（判斷題）

答：程序內部的文檔：恰當的標識符（含義鮮明、縮寫（必須保留第一個字母、輔音字母由于元音字母、字首優于字尾）+注解）、適當的注解（序言性注解、功能性注解）、程序的視覺組織（布局、空行、縮進）

2.測試的概念、原則、方法，步驟

答：概念：用最少的時間和人力，找到軟件中盡可能多的錯誤和缺陷

原則：

盡早的和不斷的測試；

事先要制定測試計劃，嚴格執行學生計劃，排除測試的隨意性；

測試從小規模測試開始，逐步進行大規模測試；

充分注意測試中的“群集”現象；

“窮舉”測試不可能，應該精心設計測試方案，使測試方案充分的覆蓋程序邏輯，以盡可能多的發現程序中的錯誤；

測試方案應該包含合理的輸入條件和不合理的輸入條件；

測試應由獨立的第三方從事；

方法有黑盒測試和白盒測試

步驟是單元測試、集成測試、系統測試、確認測試

3.白盒測試法有哪些，黑盒測試法有哪些

答：白盒測試法有：邏輯覆蓋法、基本路徑法覆蓋法、循環覆蓋法

黑盒測試法有：等價劃分法，分界值分析法，錯誤推算法

4.用邏輯覆蓋法設計測試方案

5.黑盒測試技術的原理

答：在測試中，把程序看作一個不能打開的黑盒子，在完全不考慮程序內部結構和內部 特性的情況下，在程序接口進行測試，它只檢查程序功能是否按照需求規格說明書的規定正常使用，程序是否能適當地接收輸入數據而產生正確的輸出信息。

6.可靠性的概念

答：軟件可靠性是程序在給定的事件間隔內，按照規格說明書的規定成功的運行的概率；可靠性是衡量軟件質量的指標

7.可靠性的計算

第八章 維護

1.維護的概念、分類

答：在軟件已經交付使用后，為了改正錯誤或滿足新的需要而修改軟件的過程； 改正型維護，完善型維護，適應型維護，預防型維護；

第九章 實戰

1.軟件有哪些開發方法

答：結構化的開發方法、面向對象的開發方法、傳統的開發方法與面向對象的開發方法相結合的實用開發方法

2.傳統的軟件開發方法的開發步驟

答：問題定義，可行性研究，需求分析

業務分析（業務描述，建立業務模型）

功能分析（功能描述，功能模型）

數據分析

總體設計

建立軟件結構

設計數據庫的表結構

詳細設計

模塊設計

建立數據庫，錄入數據

實現

編碼，測試

3.面向對象的開發方法的開發步驟

答：問題定義，可行性研究

面向對象的分析

業務分析

功能分析，建立系統的功能模型（參與者，需求結構，功能模型）對象分析，建立系統初步的對象模型

用例分析，建立用例分析模型（順序圖，活動圖）

擴充和完善，建立系統完整的對象模型

面向對象的總體設計

擴充和完善功能模型

軟件運行環境

軟件架構模型（軟件架構模式，軟件分層架構，軟件邏輯結構）

擴充和完善對象模型，建立平臺相關對象模型

用例設計模型（順序圖，活動圖）

數據庫設計模型（數據庫的表結構，數據庫的邏輯結構）

界面設計模型（界面結構模型，屏幕界面模型）

組件圖

部署模型

面向對象的詳細設計

確定每個用例的實現算法

建立數據庫，錄入數據

面向對象實現

編碼，測試

4.BCE、MVC是什么

答：BCE是用例分析模式、MVC是程序設計思想

5.傳統的開發方法與面向對象的開發方法相結合的實用開發方法的開發步驟 答：問題定義，可行性研究

需求分析

業務分析

功能分析

數據分析

動態分析

總體設計

軟件運行環境

軟件架構模式（C/S B/S）

建立軟件結構圖

設計數據庫的表結構

詳細設計

模塊設計

建立數據庫，錄入數據

實現

編碼，測試

第二篇：軟件工程考試

軟件工程是用工程、科學和數學的原則與方法研制、維護計算機軟件的有關技術和管理方法 軟件工程三要素：方法、工具和過程

軟件工程的內容：軟件開發技術和軟件開發管理兩個方面

可行性研究方面:技術可行性經濟可行性操作可行性法律可行性

IT項目可行性研究審計的概念:事前對IT項目從技術和經濟兩個方而進行的詳細論證，涉及

數據字典是關于數據的信息的集合，也就是對數據流圖中包含的所有元素的定義的集合.包括（1）數據流（2）數據元素（3）數據存儲（4）處理 驗證軟件需求的正確性：（1）一致性：所有需求必須是一致的，任何一條需求不能和其他需求互相矛盾。(2)完整性： 需求必須是完整的，規格說明書應該包括用戶需要的每一個功能或性能(3)現實性：指定的需求應該是用現有的硬件技術和軟件技術基本上可以實現的。對硬件技術的進步可以做些預測，對軟件技術的進步則很難做出預測，只能從現有技術水平出發判斷需求的現實性。(4)有效性： 必須證明需求是正確有效的，確實能解決用戶面對的問題。

軟件設計過程有：1數據設計：將實體 – 關系圖中描述的對象和關系，以及數據詞典中描述的詳細數據內容轉化為數據結構的定義。2總體結構（系統結構）設計： 定義軟件系統各主要成份之間的關系。3過程設計： 把結構成份轉換成軟件的過程性描述。4接口設計：定義軟件內部各成份之間、軟件與其它協同系統之間及軟件與用戶之間的交互機制。軟件設計方法：結構化設計方法(SD)面向數據結構的設計方法(JSD方法)面向對象的設計方法(OOD)

軟件設計分兩個階段完成：結構設計：結構設計是總體設計階段的任務。結構設計確定程序由哪些模塊組成，以及這些模塊之間的關系。過程設計：確定每個模塊的處理過程

結構程序設計:一種設計程序的技術，它采用自頂向下逐步求精的設計方法和單入口單出口的控制結構

軟件測試：是根據軟件開發各階段的文檔資料和程序的內部結構，精心設計一組“高產”的測試用例，利用這些實例執行程序，找出軟件中潛在的各種錯誤和缺陷的過程 黑盒法（黑盒技術是把被測試對象看成一個黑盒子，測試人員完全不考慮程序的內部結構和處理過程，只在軟件的接口處進行測試，依據需求規格說明書，檢查程序是否滿足功能要求 白盒法（白盒技術）：是把測試對象看作一個打開的盒子，測試人員須了解程序的內部結構和處理過程，以檢查處理過程的細節為基礎，對程序中盡可能多的邏輯路徑進行測試，檢查內部控制結構和數據結構是否有錯，實際的運行狀態與預期的狀態是否一致。驅動模塊：驅動模塊是用來模擬被測模塊的上級調用模塊的模塊，功能要比真正的上級模塊簡單得多，它只完成接受測試數據，以上級模塊調用被測模塊的格式驅動被測模塊，接收被測模塊的測試結果并輸出。

樁模塊：樁模塊用來代替被測試模塊所調用的模塊。它的作用是返回被測模塊所需的信息。單元測試：：單元測試指對源程序中每一個程序單元進行測試，檢查各個模塊是否正確實現規定的功能，從而發現模塊在編碼中或算法中的錯誤。

集成測試：是指在單元測試的基礎上，將所有模塊按照設計要求組裝成一個完整的系統進行的測試，故也稱組裝測試或聯合測試。

確認測試：又稱有效性測試。是為了檢查軟件的功能與性能是否與需求規格說明書中確定的指標相符合所進行的測試

單元測試內容①模塊接口②局部數據結構③重要的執行路徑④錯誤處理⑤邊界條件。調試的目的確定錯誤的原因和位置，并改正錯誤，因此調試也稱為糾錯(Debug)調試的技術手段有簡單的調試方法、歸納法、演繹法和回溯法等 軟件可維護性：軟件能夠被理解、校正、適應及增強功能的容易程度

為了保證軟件的可維護性，需要做哪些質量保證檢查?（1）在檢查點進行檢查。檢查點是指軟件開發的每一個階段的終點。（2）驗收檢查。驗收檢查是一個特殊的檢查點的檢查，它是把軟件從開發轉移到維護的最后一次檢查。（3）周期性的維護檢查（4）對軟件包的檢查。好的文檔有以下幾方面的作用：（1）好的文檔能提高程序的可閱讀性，但壞的文檔比沒有文檔更壞；（2）好的文檔意味著簡明性，風格的一致性，容易修改；（3）程序編碼中應該有必要的注釋以提高程序的可理解性；（4）程序越長、越復雜，則它對文檔的需求也越迫切 軟件維護的流程：定維護申請報告。審查申請報告并批準。進行維護并做詳細記錄。復審 面向對象方法學的出發點和基本原則:是盡可能模擬人類習慣的思維方式，使開發軟件的方法與過程盡可能接近人類認識世界解決問題的方法與過程.描述問題的問題域與實現解法的求解域在結構上盡可能一致。

對象是用面向對象方法學開發軟件時對客觀世界實體的抽象，它是由描述實體屬性的數據及可以對這些數據施加的所有操作封裝在一起構成的統一體。傳統的數據是用傳統方法學開發軟件時對客觀世界實體的抽象，但是，種抽象是不全面的：數據只能描述實體的靜態屬性，不能描述實體的動態行為。必須從外界對數據施加操作，才能改變數據實現實體應有的行為。對象與傳統數據有本質區別，它不是被動地等待外界對它施加操作，相反，它是進行處理的主體。必須發消息請求對象主動地執行它的某些操作，處理它的私有數據，而不能直接從外界對它的私有數據進行操作。

對象模型的五個層次：主題層（也稱為范疇層），類—&—對象層，結構層，屬性層，服務層

面向對象實現主要包括兩項工作：把面向對象設計結果，翻譯成用某種程序語言書寫的面向對象程序；測試并調試面向對象的程序

面向對象軟件的測試分四個層次進行：算法層、類層、主題層、系統層

項目管理者的目標: 定義全部項目任務，識別出關鍵任務，跟蹤關鍵任務的進展狀況，以保證能及時發現拖延進度的情況

軟件配置管理主要有5項任務： 標識 版本控制 變化控制 配置審計 報告 軟件工程實施項目管理的目的 ： 在于它能夠幫助我們進行系統性思考，并切實可行地進行全局性安排，同時也可以為項目開發的人力資源需求提供依據。

項目管理者的任務：確保信息系統項目符合預算和進度要求，并確保交付的系統能夠達到預定的目標

軟件的質量保證活動： 是確保軟件產品從誕生到消亡為止的所有階段的質量的活動。即為了確定、達到和維護需要的軟件質量而進行的所有有計劃、有系統的管理活動 對編制高質量文檔的要求：(1)針對性(2)精確性(3)清晰性(4)完整性(5)靈活性

第三篇：軟件工程考試總結

2.說明結構化程序設計的主要思想是什么？ 答：（1）自頂向下、逐步求精的程序設計方法（2分）（2）使用3種基本控制結構、單入口、單出口來構造程序。結構化程序設計是實現該目標的關鍵技術之一，它指導人們用良好的思想方法開發易于理解、易于驗證的程序。結構化程序設計方法的基本要點是： 1）采用自頂向下、逐步求精的程序設計方法2）使用三種基本控制結構構造程序 3）主程序員組的組織形式。

3.軟件測試包括哪些步驟？說明這些步驟的測試對象是什么？答：（1）單元測試，測試對象單元模塊（2）集成測試，測試對象為組裝后的程序模塊（3）確認測試，測試對象為可運行的目標軟件系統

4.需求分析與軟件設計二個階段任務的主要區別是什么？ 答：需求分析定義軟件的用戶需求，即定義待開發軟件能做什么軟件設計定義軟件的實現細節以滿足用戶需求，即研究如何實現軟件 5.說明軟件測試和調試的目的有何區別？

答：測試的目的是判斷和發現軟件是否有錯誤 調試的目的是定位軟件錯誤并糾正錯誤。

7、白盒法：該方法把測試對象看作一個打開的盒子，測試人員須了解程序的內部結構和處理過程，以檢查處理過程的細節為基礎，對程序中盡可能多的邏輯路徑進行測試，檢查內部控制結構和數據結構是否有錯，實際的運行狀態與預期的狀態是否一致。白盒法也不可能進行窮舉測試。

8、黑盒法：該方法把被測試對象看成一個黑盒子，測試人員完全不考慮程序的內部結構和處理過程，只在軟件接口處進行測試，依照需求規格說明書，檢查程序是否滿足功能要求。因此，黑盒測試又稱為功能測試或數據驅動測試

9、面向對象設計：是把分析階段得到的需求轉變成符合成本和質量要求的、抽象的系統實現方案的過程。或者說，面向對象設計就是用面向對象觀點建立求解域模型的過程。

10、結構化設計：面向數據流的設計是以需求分析階段產生的數據流圖為基礎，按一定的步驟映射成軟件結構，因此又稱結構化設計（SD）。

11、結構化分析：是根據分解與抽象的原則，按照系統中數據處理的流程，用數據圖來建立系統的功能模型，從而完成需求分析工作

結構化方法是一種傳統的軟件開發方法，它是由結構化分析、結構化設計和結構化程序設計三部分有機組合而成的。它的基本思想：把一個復雜問題的求解過程分階段進行，而且這種分解是自頂向下，逐層分解，使得每個階段處理的問題都控制在人們容易理解和處理的范圍內。

結構化分析方法(Structured Method，結構化方法)是強調開發方法的結構合理性以及所開發軟件的結構合理性的軟件開發方法。結構是指系統內各個組成要素之間的相互聯系、相互作用的框架。結構化開發方法提出了一組提高軟件結構合理性的準則，如分解與抽象、模塊獨立性、信息隱蔽等。針對軟件生存周期各個不同的階段，它有結構化分析(SA)、結構化設計(SD)和結構化程序設計(SP)等方法。

結構化分析方法是面向____數據流___進行需求分析的方法。結構化分析方法使用____數據字典______與____加工說明___來描述。

13、系統流程圖：是描述物理系統的傳統工具，它用圖形符號來表示系統中的各個元素，例如人工處理、數據處理、數據庫、文件、設備等。它表達了系統中各個元素之間的信息流動的情況。4.軟件生存周期

軟件生存周期是指軟件產品從考慮其概念開始到該軟件產品交付使用，直至最終退役為止的整個過程，一般包括計劃、分析、設計、實現、測試、集成、交付、維護等階段。

2、采用黑盒技術設計測試用例有哪幾種方法？這些方法各有什么特點？ ㈠等價類劃分。等價類劃分是將輸入數據域按有效的或無效的（也稱合理的或不合理的）劃分成若干個等價類，測試每個等價類的代表值就等于對該類其它值的測試。㈡邊界值分析。該方法是將測試邊界情況作為重點目標，選取正好等于，剛剛大于或剛剛小于邊界值的情況，根據這些情況選擇測試用例。㈢錯誤推測。錯誤推測法沒有確定的步驟，憑檢驗進行。它的基本思想是列出程序中可能發生錯誤的情況，根據這些情況選擇測試用例

3,Gantt圖是歷史悠久，應用廣泛的制定進度的計劃的工具。形象的描繪任務分解情況，以及每個子任務的開始時間和結束時間，具有直觀簡明，容易掌握，容易繪制的優點。缺點1不能顯式描繪各項作業依賴關系2進度的關鍵部分不明確，難于確定哪些是主攻和主控3有潛力的部分不明確，造成浪費。工程網絡 0分軟件危機定義和產生的因有哪些？

當軟件開發技術的進步不能跟上硬件技術的進步，未能滿足發展的要求，致軟件開發中遇到的問題找不到解決的辦法，使問題積累起來，形成了尖銳的矛盾，因而導致了軟件危機。

1）軟件日益復雜和龐大（2）軟件開發管理困難和復雜（3）軟件開發技術落后(4）生產方式落后（5）開發工具落后（6）軟件開發費用不斷增加

1、可行性研究的任務是什么？ 首先需要進行概要的分析研究，初步確定項目的規模和目標，確定項目的約束和限制，把他們清楚地列舉出來。然后，分析員進行簡要的需求分析，抽象出該項目的邏輯結構，建立邏輯模型。從邏輯模型出發，經過壓縮的設計，探索出若干種可供選擇的主要解決方法，對每種解決方法都要研究它的可行性，可從以下三個方面分析研究每種解決方法的可行性。㈠技術可行性：對要開發項目的功能、性能、限制條件進行分析，確定在現有的資源條件下，技術風險有多大，項目是否能實現。㈡經濟可行性：進行開發成本的估算以及了解取得效益的評估，確定要開發的項目是否值得投資開發。㈢社會可行性：要開發的項目是否存在任何侵犯、妨礙等責任問題，要開發項目的運行方式在用戶組織內是否行得通，現有管理制度、人員素質、操作方式是否可行。

2、需求分析的任務是什么？

需求分析的任務是確定待開發的軟件系統“做什么”。具體任務包括確定軟件系統的功能需求、性能需求和運行環境約束，編制軟件需求規格說明書、軟件系統的驗收測試準則和初步的用戶手冊。

需求分析是指，開發人員要準確理解用戶的要求，進行細致的調查分析，將用戶非形式的需求陳述轉化為完整的需求定義，再由需求定義轉換到相應的形式功能規約（需求規格說明）的過程。

3、概要設計的定義和基本任務是什么？

進入了設計階段，要把軟件“做什么”的邏輯模型變換為“怎么做”的物理模型，即著手實現軟件的需求，并將設計的結果反應在“設計規格說明書”文檔中，所以軟件設計是一個把軟件需求轉換為軟件表示的過程，最初這種表示只是描述了軟件的總的體系結構，稱為軟件的概要設計或結構設計。①采用某種設計方法，將一個復雜的系統按功能劃分成模塊。②確定每個模塊的功能。③確定模塊之間的調用關系。④確定模塊之間的接口，即模塊之間傳遞的信息。⑤評價模塊結構的質量。⑵數據結構及數據庫設計，漢數據結構的設計及數據庫的設計。⑶編寫概要設計文檔。主要有：概要設計說明書；數據庫設計說明書；用戶手冊；修訂測試計劃。⑷評審

4、詳細設計的基本任務是什么？有哪幾種描述方法？ 詳細設計是軟件設計的第二階段，其基本任務有：為每個模塊進行詳細的算法設計；為模塊內的數據結構進行設計；對數據庫進行物理設計，即確定數據庫的物理結構；其它設計，根據軟件系統類型，還可能要進行代碼設計、輸入/輸出格式設計、人機對話設計；編寫詳細設計說明書；評審。詳細描述處理過程常用三種工具：圖形、表格和語言。如結構化程序流程圖、盒圖和問題分析圖。IPO圖也是詳細設計的主要工具之一。表格工具如判定表可作為詳細設計中描述邏輯條件復雜的算法。過程設計語言（PDL）是一種用于描述模塊算法設計和處理細節的語言工具。

能力成熟度模型（CMM）用于評價軟件機構的軟件過程能力成熟度德模型 文檔：程序開發使用和維護所常用的圖文資料

2衡量模塊獨立性的兩個定性的標準是內聚和耦合。耦合是指對一個軟件結構內不同模塊彼此之間互相依賴的緊密程度。內聚標志一個模塊內各元素彼此的緊密1簡述兩種不同集成測試的比較：自頂向下測試法主要，優點是不需要測試驅動程序，能夠在測試階段的早期實現并驗證系統的主要功能，而且能在早期發現上層模塊的接口的錯誤，自頂向下的缺點是需要存根程序，可能遇到與此相聯系的測試困難，底層關鍵模塊中的錯誤發現的較晚，而且用這種方法不能展開人力。自底向下正好相反。

影響維護的因素：可理解性，可測試性，可修改性，可移植性，重用性

總體設計的九個階段：1設想供選擇的方案，2選擇合適的方案，3推薦最佳方案，4功能分解，5設計軟件結構 6設計數據庫，7制定測試計劃，8書寫文檔，9審查和復查

軟件工程：是指導計算機軟件開發和維護的工程學科，采用工程概念，原理，技術和方法來開發和維護軟件，吧經過實踐考驗而證明的管理技術和當前能夠得到的最好的技術方法結合起來。要素是方法，工具，過程 系統流程圖是描繪物理系統的傳統工具，他的基本思想是用圖形符號以黑盒子形式描繪組成系統的每個部件。表達的是數據在系統各部件的流動情況，而不是對數據進行加工處理的控制過程。

3個子模型和5個層次：靜態結構（對象模型）交互次序（動態模型）數據變換（功能模型）主題層，類和對象層，結構層，屬性層，服務層

結構化方法有結構化分析、結構化設計、結構化程序設計構成，它是一種面向數據流的開發方法。

結構化設計對數據流有兩種分析方法，他們是變換分析設計和事務分析設計。質量保證是有計劃的和系統性的活動，它對部件或產品滿足確定的技術需求提供足夠的信心。

軟件質量保證措施（SQA）基于非執行的測試（復審和評審）基于執行的測試（軟件測試）和程序正確性證明

數據字典的內容：數據流，數據流分量，數據存儲，數據處理

數據流圖的內容：數據流，數據存儲，數據處理，數據的原點和終點。

數據流圖（DFD）是一種圖形化技術，他描繪信息流和數據從輸入移動到輸出的過程中經受的變換。

可行性研究中，數據流圖，系統流程圖，數據字典

需求分析：訪談，實體聯系圖，狀態轉換圖，層次方框圖，Warnier圖，IPO圖 總體設計：層次圖和HIPO圖，結構圖

詳細設計：過程設計中有程序流程圖，盒圖，PAD圖，判定表，判定樹，過程設計語言。面向數據結構的設計方法：Jackson圖程序復雜度的定量MaCabe方法和Halstead方法

設計人機界面的過程中4個問題，系統響應時間，用戶幫助設施，出錯信息處理和命令交互

耦合:盡量使用數據耦合少用控制耦合和特征耦合，限制公共環境耦合的范圍，完全不用內容耦合

內聚:偶然內聚，邏輯內聚時間內聚，中內聚有過程內聚通信內聚，高內聚，功能內聚，順序內聚

模塊化就是把程序劃分為獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，把這些模塊集起來構成一個整體，可以完成指定的功能滿足用戶的需求 狀態轉換圖通過描繪系統狀態及引起系統狀態轉換的事件，來表示系統的行為

5.軟件配置管理，簡稱SCM，它用于整個軟件工程過程。其主要目標是：標識變更；控制變更；確保變更正確地實現；報告有關變更。SCM是一組管理整個軟件生存期各階段中變更的活動。

Jackson的畫法：

1定輸入和輸出數據結構

2分析確定在輸入和輸出數據結構中有對應關系的數據單元，最高層輸入和輸出相對應等有其他。

3從數據結構圖導出程序結構圖

4列出所有的操作和條件，并把它們分配到程序結構圖的適當位置。5最后用偽碼表示程序處理過程 盒圖的特點：

1功能域明確，可以從盒圖上一眼看出來 2不可能任意轉移控制

3很容易確定局部和全程數據的作用域

4很容易表現嵌套關系，也可以表示模塊的層次結構。PAD圖：

1使用表示結構化控制結構的PAD符號結構所設計出來的程序必然是結構化程序。

2PAD圖所描繪的程序結構非常清晰

3PAD圖表現程序邏輯，易讀，易懂，易記 4，容易將PAD圖轉換成高級語言源程序

5即可用于表示程序邏輯，也可用于描繪數據結構 6PAD的符號支持自頂向下，逐步求精方法

第四篇：軟件工程考試總結范文

第一章 軟件工程學概述

1.軟件：是程序、數據及相關文檔的完整集合。

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

3.產生軟件危機的原因

A.與軟件本身的特點有關。管理和控制軟件開發過程相當困難，軟件較難維護，它規模龐大，程序復雜性將隨著

程序規模的增加而呈指數上升。

B.和軟件開發與維護的方法不正確有關。

4.消除軟件危機的途徑：

A.應該對計算機軟件有一個正確認識。

B.認識到軟件開發不是某種個體勞動的神秘技巧，而應該是一種組織良好、管理嚴密、各類人員協同配合、共同

發完成的工程項目。

C.充分吸取和借鑒人類長期以來從事各種工程項目所積累的行之有效的原理、概念、技術和方法。

D.開發和使用更好的軟件工具。

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

6.軟件工程的特征：

A.軟件工程關注于大型程序的構造。

B.軟件工程的中心課題是控制復雜性。

C.軟件經常變化。

D.開發軟件的效率非常重要。

E.和諧的合作是開發軟件的關鍵。

F.軟件必須有效地支持它的用戶。

G.在軟件工程領域中通常由具有一種文化背景的人替具有另一種文化背景的人創造產品。

7.軟件工程學的方法學3要素：方法、工具、過程。

方法學：傳統方法學、面向對象方法學。

8.軟件生命周期：

軟件定義、軟件開發、運行維護三個過程。

軟件定義包括問題定義、可行性研究、需求分析3個階段。

軟件開發包括總體設計、詳細設計、編碼和單元測試、綜合測試4個階段。

9.軟件過程：是為了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。

10.過程模型：瀑布模型、快速原型模型、增量模型、螺旋模型、噴泉模型。

瀑布模型：優點：1.可強迫開發員采用規范的方法2.嚴格地規定了每個階段必須提交的文件3.要求每個階段交出的所有產品都必須經過質量保證小組的仔細驗證。缺點：傳統的瀑布模型過于理想化，是由文檔驅動的。

快速原型模型：通過快速構建起一個可在計算機上運行的原型系統，讓用戶試用原型并收集用戶反饋意見的方法，獲取用戶真正的需要。

增量模型：優點：能在較短時間內向用戶提交可完成部分工作的產品；逐步增加產品功能可以使用戶有較充實的時

間學習和適應新產品，從而減少一個全新的軟件可能給客戶組織帶來的沖擊。

螺旋模型：優點：對可選方案和約束條件的強調有利于已有軟件的重用；減少了過多測試；維護只是螺旋模型中另

一個周期。

第二章 可行性研究（確定問題是否能解決）

1.可行性研究的三個方面：技術可行性：使用現有的技術能否實現該系統。

經濟可行性：該系統的經濟效應能否超過它的開發成本。

操作可行性：系統的操作方式在這個組織內是否行得通。

2.系統流程圖：概括的描繪物理系統的傳統工具。表達的是數據在系統各部件之間流動的情況。

基本符號：處理、輸入輸出、連接、換頁連接、數據流。

3.數據流圖DFD：一種圖形化技術，它描繪信息流和數據從輸入移動到輸出的過程中所經受的變換。描繪邏輯過程。

基本符號：數據的源點/終點、變換數據的處理、數據存儲、數據流。

數據流圖的命名：先為數據流命名，再為處理命名。

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

數據字典的內容：數據流、數據流分量（數據元素）、數據存儲、處理。

定義數據的方法：順序、選擇、重復。

符號：=等價于、+和、[ ]或、{ }重復、（）可選

4.成本估計技術：代碼行技術、任務分解技術、自動估計成本技術。

第三章 需求分析（系統必須做什么）

1.需求分析的任務：

A.確定對系統的綜合要求。

B.分析系統的數據要求。

C.導出系統的邏輯模型。

D.修正系統開發計劃。

2.與用戶溝通獲取需求的方法：

A.訪談。

B.面向數據流自頂向下求精。（結構化分析方法）

C.簡易的應用規格說明技術。

D.快速建立軟件原型。

3.實體—聯系圖（E-R圖）包含的3種信息：數據對象（矩形）、屬性（圓角矩形）、聯系（菱形）。

4.狀態轉換圖：通過描繪系統的狀態及引起系統狀態轉換的事件，來表示系統的行為。

狀態：是任何可被觀察到的系統行為模式，有初態、中間狀態、終態。一張狀態圖中只能有一個初態，0到多個終態。

事件：引起系統做動作或（和）轉換狀態的控制信息。

符號：初態（實心圓）、終態（一對同心圓，內圓為實心圓）、狀態轉換（箭頭）。

5.該階段可用到的其他圖形：層次方框圖、Warnier圖、IPO圖、注：E—R圖建立數據模型，數據流圖建立功能模型，狀態圖建立行為模型。

第五章 總體設計（概括的說系統應該如何實現）將軟件需求轉化為數據結構和軟件的系統結構。

1.基本任務：A.劃分出組成系統的物理元素：程序、文件、數據庫、人工過程和文檔等。

B.設計軟件的結構。也就是要確定系統中每個程序由哪些模塊組成，以及這些模塊相互間的關系。

2.階段：系統設計階段，確定系統的具體實現方案。

結構設計階段：確定軟件結構。

典型的總體設計過程包括9個步驟：

設想供選擇的方案，選取合理的方案，推薦最佳方案，功能分解，設計軟件結構，設計數據庫，制定

測試計劃，書寫文檔，審查和復審。

3.設計原理：模塊化、抽象、逐步求精、信息隱藏和局部化、模塊獨立。

模塊：由邊界元素限定的相鄰程序元素的序列，而且有一個總體標識符代替它。

模塊化：就是把程序劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，把這些模塊集成起來構成一個整體，可以完成指定的功能滿足用戶需求。

抽象：就是抽出事物的本質特征而暫時不考慮它們的細節。

逐步求精：為了能集中精力解決主要問題而盡量推遲對問題細節的考慮。可看作是一項把一個時期內必須解決的種種問題按優先級排序的技術。

信息隱藏：設計和確定的模塊，使得一個模塊內包含的信息對于不需要這些信息的模塊來說，是不能訪問的。局部化：把一些關系密切的軟件元素物理地放得彼此靠近。

模塊的獨立程度的定性標準度量：內聚、耦合。

耦合：是對一個軟件結構內不同模塊之間互連程度的度量。耦合由低程度到高程度分為：數據耦合、控制耦合、特征耦合、公共環境耦合、內容耦合。

內聚：標志著一個模塊內各個元素彼此結合的緊密程度。底內聚有偶然內聚、邏輯內聚、時間內聚。中內聚包括

過程內聚和通信內聚。高內聚包括順序內聚和功能內聚。

注：盡量使用數據耦合，少用控制耦合和特征耦合，限制公共環境耦合的范圍，完全不用內容耦合。

4.啟發規則：

改進軟件結構提高模塊獨立性。模塊規模應該適中。深度、寬度、扇出和扇入都應適當。模塊的作用域應該在控制域之內。力爭降低模塊接口的復雜程度。設計單入口單出口的模塊。模塊功能應該可以預測。

深度：表示軟件結構中控制的層數。

寬度：軟件結構內同一個層次上模塊總數的最大值。

扇出：一個模塊直接控制的模塊數。

扇入：表示一個模塊有多少個上級模塊直接調用它。

注：設計的很好的軟件結構，通常頂層扇出比較高，中層扇出較少，底層扇入到公共的使用模塊中去。（底層模塊有高扇入）

5.面向數據流的設計方法：

目標：給出設計軟件結構的一個系統化的途徑。

概念：把信息流映射策劃那個軟件結構，信息流的類型決定了映射的方。

信息流的類型：變換流和事務流。

變換流的特點：信息以“外部世界”的形式進入軟件系統，經處理以后再以“外部世界”的形式離開系統。事務流的特點：數據沿輸入通路到達一個處理，該處理根據輸入數據的類型在若干個動作序列中選出一個來執行。

6.變換分析：把具有變換流特點的數據流圖按預先確定的模式映射成軟件結構。

第一步：復查基本系統模型。

第二步：復查并精化數據流圖。

第三步：確定數據流圖是變換特性還是事務特性。

第四步：確定輸入流和輸出流的邊界，從而孤立出變化中心。

第五步：完成第一級分解。

第六步：完成第二次分解。

第七步：使用設計度量和啟發規則對第一次分割得到的軟件結構進一步精化。

第六章 詳細設計（怎樣具體地實現所要求的系統）即過程設計。通過對結構表示進行細化，得到軟

件詳細的數據結構和算法。

1.詳細設計的內容：

用圖表列出系統的每個程序，包括每個模塊和子程序名稱、標識符、層出結構關系。對程序的功能、性能、輸入、輸出、算法、流程、接口等進行描述

內容包括：程序描述：程序簡要描述，意義和特點

功能：程序應具備的功能

性能：精度、靈活性和時間特性等

輸入項

輸出項

2.人機界面設計指南：

一般交互指南：涉及信息顯示、數據輸入和系統整體控制。

保持一致性，提供有意義的反饋，在執行有破壞性的動作之前要求用戶確認，允許取消絕大多數

操作，減少在兩次操作之間必須記憶的信息量，提高對話、移動和思考的效率，允許犯錯誤，按

功能對動作分類，并據此設計屏幕布局，提供對用戶工作內容敏感的幫助設施，用簡單動詞或動

詞短語作為命令名。

信息顯示指南：只顯示與當前工作內容有關的信息，不要用數據淹沒用戶，使用一致標記、標準的縮寫和可預知的顏色，允許用戶保持可視化的語境，產生有意義的出錯信息，使用大小寫、縮進和文本分組以幫

助理解，使用窗口分隔不同類型的信息，使用“模擬”顯示表示信息，以使信息更容易被用戶提取，高效率地使用顯示屏。

數據輸入指南：盡量減少用戶的輸入動作，保持信息顯示和數據輸入之間的一致性，允許用戶自定義輸入，交互

應該是靈活的，并且可調整成用戶最喜歡的輸入方式，交互應該是靈活的，并且可調整成用戶最喜

歡的輸入方式，讓用戶控制交互流，對所有輸入動作都提供幫助，消除冗余的輸入。

3.過程設計工具：分為圖形、表格、語言。有程序流程圖、盒圖（N—S圖）、PAD圖（問題分析圖）、判定表、判

定樹、過程設計語言（PDL或偽碼）。

4.程序復雜程度的定量度量：

McCabe方法：根據程序控制流的復雜程度度量度量程序的復雜度，結果稱為環形復雜度。

流圖：實質上是“退化了的”程序流程圖。有結點（圓）、邊（箭頭）。

區域：邊和結點圍成的面積。

5.計算環形復雜度的方法：

A.區域數=環形復雜度。

B.流圖G的環形復雜度V(G)=E—N+2，E為邊數，N為結點數。

C.V(G)=P+1，P為判定結點的數目。

第七章 實現（編碼和測試）

1.軟件測試：就是在軟件投入運行前，對軟件需求分析、設計規格說明和編碼的最終復審，是軟件質量保證的關鍵

步驟。

2.測試的目的：在軟件投入生產性運行之前，盡可能多現的發軟件在運行中的錯誤。

3.測試方法：黑盒測試、白盒測試。

黑盒測試：已經知道產品應有的功能，檢驗每個功能是否都能正常使用。也叫功能測試。

白盒測試：已經知道產品的內部工作過程，檢驗這些過程是否按照規格說明書的規定正常進行。也叫

結構測試。

以黑盒測試為主，白盒測試為輔。

4.測試步驟：模塊測試、子系統測試、系統測試、驗收測試，平行測試。

5.白盒測試技術：

邏輯覆蓋：是對一系列測試過程的總稱，這組測試過程逐漸進行越來越完整的通路測試。

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

基本路徑測試：

一、根據過程設計結果畫出相應流圖。

二、計算流圖的環境復雜度。

三、確定線路獨立路徑的基本組合。獨立路徑是指至少引入程序的一個新處理語句集合或一

個新條件路徑，就是至少包含一條在定義該路徑之前不曾用過的邊。

獨立路徑數=環形復雜度

四、設計可強制執行基本集合中每條路徑的測試用例。

6.調試：在測試發現錯誤之后排除錯誤的過程。

7.軟件維護：在軟件已交付使用之后，為了改正錯誤或者滿足新的需要而修改軟件的過程。分為改進性維護、適應性

維護、完善性維護、預防性維護。

決定軟件可維護性的因素：可理解性、可測試性、可修改性、可移植性、可重用性。

8.軟件項目管理：通過計劃、組織和控制等一系列活動，合理的配置和使用各種資源，以達到既定目標的過程。管理內容：估算軟件規模，工作量估算、進度計劃、人員組織、質量保證、軟件配置管理、能力成熟度模型。

第五篇：軟件工程

2.2軟件開發的基本策略

人們都有自己的世界觀和方法論，能自然而然地運用于生活和工作中。同樣，程序員腦子里的軟件工程觀念會無形地支配其怎么去做事情。軟件工程三十年的發展，已經積累了相當多的方法，但這些方法不是嚴密的理論。實踐人員不應該教條地套用方法，更重要的是學會“選擇合適的方法”和“產生新方法”。有謀略才會有好的戰術。幾千年前，我們的祖先就在打鬧之際寫下了很多心得體會，被現代人很好地運用于工業和商業。本節講述軟件開發中的三種基本策略：“復用”、“分而治之”、“優化——折衷”。

2.2.1復用

復用就是指“利用現成的東西”，文人稱之為“拿來主義”。被復用的對象可以是有形的物體，也可以是無形的成果。復用不是人類懶惰的表現而是智慧的表現。因為人類總是在繼承了前人的成果，不斷加以利用、改進或創新后才會進步。所以當我們歡度國慶時，要搞清楚祖國遠不止50歲，我們今天享用到的財富還有上下五千年人民的貢獻。進步只是應該的，不進步則就可恥了。

復用的內涵包括了提高質量與生產率兩者。由經驗可知，在一個新系統中，大部分的內容是成熟的，只有小部分內容是創新的。一般地可以相信成熟的東西總是比較可靠的（即具有高質量），而大量成熟的工作可以通過復用來快速實現（即具有高生產率）。勤勞并且聰明的人們應該把大部分的時間用在小比例的創新工作上，而把小部分的時間用在大比例的成熟工作中，這樣才能把工作做得又快又好。

把復用的思想用于軟件開發，稱為軟件復用。據統計，世上已有1000億多行程序，無數功能被重寫了成千上萬次，真是浪費哪。面向對象（Object Oriented）學者的口頭禪就是“請不要再發明相同的車輪子了”。

將具有一定集成度并可以重復使用的軟件組成單元稱為軟構件(Software Component)。軟件復用可以表述為：構造新的軟件系統可以不必每次從零做起，直接使用已有的軟構件，即可組裝（或加以合理修改）成新的系統。復用方法合理化并簡化了軟件開發過程，減少了總的開發工作量與維護代價，既降低了軟件的成本又提高了生產率。另一方面，由于軟構件是經過反復使用驗證的，自身具有較高的質量。因此由軟構件組成的新系統也具有較高的質量。利用軟構件生產應用軟件的過程如圖1.5所示。

軟件復用不僅要使自己拿來方便，還要讓別人拿去方便，是“拿來拿去主義”。面向對象方法，Microsoft公司的COM規范 [Rogerson 1999]，都能很好地用于實現大規模的軟件復用。

2.2.2分而治之

分而治之是指把一個復雜的問題分解成若干個簡單的問題，然后逐個解決。這種樸素的思想來源于人們生活與工作的經驗，完全適合于技術領域。軟件人員在執行分而治之的時候，應該著重考慮：復雜問題分解后，每個問題能否用程序實現？所有程序最終能否集成為一個軟件系統并有效解決原始的復雜問題？

圖1.6表示了軟件領域的分而治之策略。諸如軟件的體系結構設計、模塊化設計都是分而治之的具體表現。軟件的分而治之不可以“硬分硬治”。不像為了吃一個西瓜或是一只雞，揮刀斬成n塊，再把每塊塞進嘴里粉碎攪拌，然后交由胃腸來消化吸收，象征復雜問題的西瓜或是雞也就此消失了。

2.2.3優化——折衷

軟件的優化是指優化軟件的各個質量因素，如提高運行速度，提高對內存資源的利用率，使用戶界面更加友好，使三維圖形的真實感更強等等。想做好優化工作，首先要讓開發人員都有正確的認識：優化工作不是可有可無的事情，而是必須要做的事情。當優化工作成為一種責任時，程序員才會不斷改進軟件中的算法，數據結構和程序組織，從而提高軟件質量。

著名的3D游戲軟件Quake，能夠在PC機上實時地繪制高度真實感的復雜場景。Quake的開發者能把很多成熟的圖形技術發揮到極致，例如把Bresenham畫線、多邊形裁剪、樹遍歷等算法的速度提高近一個數量級。我第一次看到Quake時不僅感到震動，而且深受打擊。這個PC游戲軟件的技術水平已經遠勝于我所見識到的國內領先的圖形學相關科研成果。這對我們日益盛行的點到完止的研發工作真是莫大的諷刺。所以當我們開發的軟件表現出很多不可救藥的病癥時，不要怨機器差。真的是我們自己沒有把工作做好，寫不好字卻嫌筆鈍。

就假設我們經過思想教育后，精神抖擻，隨時準備為優化工作干上六天七夜。但愿意做并不意味著就能把事情做好。優化工作的復雜之處是很多目標存在千絲萬縷的關系，可謂數不清理還亂。當不能夠使所有的目標都得到優化時，就需要“折衷”策略。

軟件中的折衷策略是指通過協調各個質量因素，實現整體質量的最優。就象黨支部副書記扮演和事佬的角色：“…為了使整個組織具有最好的戰斗力，我們要重用幾個人，照顧一些人，在萬不得已的情況下委屈一批人”。

軟件折衷的重要原則是不能使某一方損失關鍵的職能，更不可以象“舍魚而取熊掌”那樣拋棄一方。例如3D動畫軟件的瓶頸通常是速度，但如果為了提高速度而在程序中取消光照明計算，那么場景就會喪失真實感，3D動畫也就不再有意義了（如果人類全是色盲，計算機圖形學將變得異常簡單）。

人都有惰性，如果允許濫用折衷的話，那么一當碰到困難，人們就會用拆東墻補西墻的方式去折衷，不再下苦功去做有意義的優化。所以我們有必要為折衷制定嚴正的立場：在保證其它因素不差的前提下，使某些因素變得更好。

下面讓我們用“優化——折衷”的策略解決“魚和熊掌不可得兼”的難題。

問題提出：假設魚每千克10元，熊掌每千克一萬元。有個倔脾氣的人只有20元錢，非得要吃上一公斤美妙的“熊掌燒魚”，怎么辦？

解決方案：化9元9角9分錢買999克魚肉，化10元錢買1克熊掌肉，可做一道“熊掌戲魚”菜。剩下的那一分錢還可建立獎勵基金。

2.3一些不正確的觀念

本節例舉并分析一些不正確的軟件工程觀念，可幫助初學者少犯相似的錯誤。

觀念之一：我們擁有一套講述如何開發軟件的書籍，書中充滿了標準與示例，可以幫助我們解決軟件開發中遇到的任何問題。

客觀情況：好的參考書無疑能指導我們的工作。充分利用書籍中的方法、技術和技巧，可以有效地解決軟件開發中大量常見的問題。但實踐者并不能因此依賴于書籍，這是因為：（1）現實的工作中，由于條件千差萬別，即使是相當成熟的軟件工程規范，常常也無法套用。（2）軟件技術日新月異，沒有哪一種軟件標準能長盛不衰。祖傳秘方在某些領域很吃香，而在軟件領域則意味著落后。

觀念之二：我們擁有最好的開發工具、最好的計算機，一定能做出優秀的軟件。

客觀情況：良好的開發環境只是產出成果的必要條件，而不是充分條件。如果擁有好環境的是一群庸人，難保他們不干出南轅北轍的事情。

觀念之三：如果我們落后于計劃，可以增加更多的程序員來解決。

客觀情況：軟件開發不同于傳統的農業生產，人多不見得力量大。如果給落后于計劃的項目增添新手，可能會更加延誤項目。因為：（1）新手會產生很多新的錯誤，使項目混亂。（2）老手向新手解釋工作以及交流思想都要花費時間，使實際開發時間更少。所以科學的項目計劃很重要，不在乎計劃能提前多少，重在恰如其分。如果用“大躍進”的方式奔向共產主義，只會產生倒退的后果。

觀念之四：既然需求分析很困難，不管三七二十一先把軟件做了再說，反正軟件是靈活的，隨時可以修改。

客觀情況：對需求把握得越準確，軟件的修修補補就越少。有些需求在一開始時很難確定，在開發過程中要不斷地加以改正。軟件修改越早代價越少，修改越晚代價越大，就跟治病一樣道理。

2.4一些有爭議的觀念

本節探討一些有爭議的觀念，目的不在于得出“正確”或“錯誤”的評斷，而在于爭議會激發更多理性的思考。

爭議之一：如果軟件運行較慢，是換一臺更快的計算機，還是設計一種更快的算法？

作者觀點：如果開發軟件的目的是為了學習或是研究，那么應該設計一種更快的算法。如果該軟件已經用于商業，則需謹慎考慮：若換一臺更快的計算機能解決問題，則是最快的解決方案。改進算法雖然可以從根本上提高軟件的運行速度，但可能引入錯誤以及延誤進程。技術狂毫無疑問會選擇后者，因為他們覺得放棄任何可以優化的機會就等于犯罪。

類似的爭議還有：是買現成的程序，還是徹底自己開發？技術人員和商業人士常常會有不同的選擇。

爭議之二：有最好的軟件工程方法，最好的編程語言嗎？

作者觀點：在軟件領域永遠沒有最好的，只有更好的。能解決問題的都是好方法或是好語言。程序員在最初學習Basic、Fortran、Pascal、C、C++等語言時會感覺一個比一個好，不免有喜新厭舊之舉。而如今 的Visual Basic、Delphi、Visual C++、Java等語言各有所長，真的難分優劣。開發人員應該根據客觀條件，選擇自己熟悉的方法和語言，才能保證合格的質量與生產率。

程序設計是自由與快樂的事情，不要發誓忠于某某主義而自尋煩惱。

爭議之三：編程時是否應該多使用技巧？

作者觀點：就軟件開發而言，技巧的優點在于能另辟蹊徑地解決一些問題，缺點是技巧并不為人熟知。若在程序中用太多的技巧，可能會留下隱患，別人也難以理解程序。鑒于一個局部的優點對整個系統而言是微不足道的，而一個錯誤則可能是致命的。作者建議用自然的方式編程，少用技巧。

《狼三則》的故事告訴我們“失敗的技巧通常是技倆”。當我們在編程時無法判斷是用了技巧還是用了技倆，那就少用。《賣油翁》的故事又告訴我們“熟能生巧”，表明技巧是自然而然產生的，而不是賣弄出來的。賣油翁的絕技是可到中央電視臺表演的，而他老人家卻謙虛地說：“沒啥沒啥，用熟了而已”。

爭議之四：軟件中的錯誤是否可按嚴重程度分等級？

作者觀點：在定量分析時，可以將錯誤分等級，以便于管理。微軟的一些開發小組將錯誤分成四個等級 [Cusumano 1996]，如表1.1所示。

一級嚴重：錯誤導致軟件崩潰。

二級嚴重：錯誤導致一個特性不能運行并且沒有替代方案。

三級嚴重：錯誤導致一個特性不能運行但有替代方案。

四級嚴重：錯誤是表面化的或是微小的。

表1.1 錯誤的四個等級

上述分類是非常技術性的，并不是普適的。假設某個財務軟件有兩個錯誤：錯誤A使該軟件死掉，錯誤B導致工資計算錯誤。按表1.1分類，錯誤A屬一級嚴重，錯誤B屬二級嚴重。但事實上B要比A嚴重。工資算多了或者算少了，將會使老板或員工遭受經濟損失。而錯誤A只使操作員感到厭煩，并沒有造成經濟損失。另一個示例是操作手冊寫錯，按表1.1分類則屬四級嚴重，但這種錯誤可能導致機毀人亡。

開發人員應該意識到：所有的錯誤都是嚴重的，不存在微不足道的錯誤。這樣才能少犯錯誤。

2.5小 結

軟件工程學科發展到今天，已經有了很多方法和規范，學之不盡。本章只在宏觀上討論了軟件工程的一些

思想，更具體的內容將在后面的章節論述。無論是什么好方法，貴在理解與靈活運用，而不可當成靈丹妙藥，不象“吃了腦黃金或腦白金，就能使一億人先聰明起來”。

3程序員與程序經理

工作在第一線的軟件開發人員是程序員和程序經理，他們決定著軟件的命運。良好的程序員隊伍和出色的管理是軟件項目成功的必要條件。管理不是管制，不是去卡住人家的脖子，因為程序員不是一群野鴨子。管理的目的是讓大家一起把工作做好，并且讓各人獲得各自的快樂和滿足。當一個組織被出色地領導時，雇員甚至不知道他們已被領導。在項目完成時，他們會自豪地說：“看看我們通過努力取得的成績吧”。所以管理者不能老惦記著自己是一個官，而應時刻意識到自己是責任的主要承擔者。

我們經常會聽到有經理頭銜的人在高談闊論：“編程我不會，做個項目還不easy？派個人去搞系統分析，回頭再叫幾個程序員把需求譯成程序，不就OK了嗎？”

不懂英語的人準以為easy和OK是貶義詞。要讓軟件項目失敗很容易，只要符合下列條件之一即可：

（1）項目經理對軟件一無所知；

（2）技術負責人對編程不感興趣；

（3）真真編寫代碼的程序員是臨時雇用的。

如果上述三個條件同時具備，就請放心失敗好了。

讓我們少幻想自己是比爾·蓋茨，先當好程序員和程序經理再說。

3.1了解程序員

早期的程序員干活能從軟件直通硬件，個個生猛無比。又因他們的作息時間、言行舉止與常人不太一樣，久而久之就給人們留下了“神秘”、“孤僻”的印象。如今軟件行業被炒得熱火朝天，有能耐的程序員即便躲在大山岙的軍工廠里也能被挖出來。而更多原本不是程序員的人操起幾本“速成”、“二十一天通”等書籍也加入了這個行業。現在國內號稱有上百萬程序員，這支大軍魚龍混雜，已搞不清那些是正規軍，那些是民兵游擊隊了。