軟件工程基礎知識

1、軟件工程基礎知識一什么是軟件？1. 滿足功能要求和性能的指令或計算機程序集合；2. 處理信息的數(shù)據(jù)結構；3. 描述程序功能以及程序如何操作和使用所要求的文檔；二軟件危機以及產生軟件危機的原因？1.軟件開發(fā)生產率提高的速度，遠遠跟不上計算機迅速普及的趨勢。軟件產品“供不應求” 2.軟件成本在計算機系統(tǒng)總成本中所占的比例逐年上升。3. 軟件開發(fā)人員和用戶之間的信息交流往往很不充分，用戶對 “已完成的” 的軟件系統(tǒng)不滿足的現(xiàn)象經(jīng)常發(fā)生。4. 軟件產品的質量不容易保證。5. 軟件產品常常是不可維護的。6. 軟件產品的重用性差，同樣的軟件多次重復開 發(fā)。7. 軟件通常沒有適當?shù)奈臋n資料。產生軟件危機的原

2、因可歸結為兩個重要的方面： 軟件生產本身存在的復雜性； 軟件開發(fā)所使用的方法和技術。三有哪些軟件工程方法學及其要素？1. 使用最廣泛的軟件工程方法學是結構化方法學和面向對象的方法學。2. 要素：方法、工具和過程。四什么是軟件生存周期？有哪些活動？4.1 軟件生存周期 一個軟件從提出開發(fā)要求開始到軟件廢棄不用的整個過程。、編碼、測試和運行維4.2 開發(fā)活動 可行性分析和項目開發(fā)計劃、需求分析和定義、軟件設計（先后細分為：概要設計和詳細設計） 護4.3 各活動階段主要文檔4.3.1 可行行分析和項目開發(fā)計劃可性行研究報告項目開發(fā)計劃4.3.2 需求分析中的文檔 需求規(guī)格說明書 初步用戶使用手冊 確

3、認測試計劃 修改完善的軟件開發(fā)計劃4.3.3 概要設計階段文檔 概要設計說明書數(shù)據(jù)庫說明書 用戶手冊 修訂的測試計劃(測試的策略、方法、步驟)4.4.4 詳細設計階段 詳細設計說明書、螺旋模型、噴泉模型、4.4.5 系統(tǒng)測試階段 系統(tǒng)測試計劃文檔 五有哪些主要生存期模型？ 瀑布模型、原型開發(fā)模型(快速原型模型、演化模型、增量模型)5.1 瀑布模型 瀑布模型 (傳統(tǒng)的軟件周期模型 )嚴格遵循軟件生命周期各階段的固定順序：計劃、分析、設計、編程、測試和維護，上 一階段完成后才能進入到下一階段，整個模型就像一個飛流直下的瀑布。優(yōu)點：可強迫開發(fā)人員采用規(guī)范的方法，嚴格規(guī)定了各階段必須提交的文檔；要求每

4、一階段結束后，都要進行嚴格的 評審。與它最相適應的開發(fā)方法是結構化方法。缺點：不適應用戶需求的改動。5.2 原型模型5.2.1 快速原型模型 快速原型的用途是獲知用戶的真正需求，一旦需求確定了，原型即被拋棄。主要用于需求分析階段。不追求也不可能要求對需求的嚴格定義，而是采用了動態(tài)定義需求的方法，所以不能定義完善的文檔。特征：簡化項目管理、盡快建立初步需求、加強用戶參與和決策。 具有廣泛技能水平的原型化人員是原型實施的重要保證。原型化人員應該是具有經(jīng)驗與才干、訓練有素的專業(yè)人員。 衡量原型化人員能力的重要標準是他是否能夠從用戶的模糊描述中快速獲取需求。5.2.2 演化模型在快速原型模型中，原型的

5、用途是獲知用戶的真正需求，一旦需求確定了，原型即被拋棄。而演化模型應用于整個軟 件開發(fā)過程，是從初始模型逐步演化為最終軟件產品的漸進過程。也就是說，快速原型模型是一種“拋棄式”的原型 化方法，而演化模型則是一種“漸進式”的原型化方法。5.2.3 增量模型 增量模型主要用于設計階段，把軟件產品劃分為一系列的增量構件，分別進行設計、編程、集成和測試。新的增量構 件不得破壞已經(jīng)開發(fā)出來的產品。5.2.4 原型模型小結 從下面的有關原型化方法的敘述中，選擇出正確的敘述：(1) 快速原型方法是一種企圖克服傳統(tǒng)軟件周期模型缺點的開發(fā)方法。(2) 在用戶的數(shù)據(jù)資源沒有得到很好地組織和管理的時候，應該使用原型

6、化方法。(3) 在用戶沒有明確地肯定其需求的時候，應該使用原型化方法。(4) 在用戶不希望把自己的時間花在軟件開發(fā)過程中的時候，應該使用原型化方法。(5) 使用原型化方法時應該使用第三代編程語言。(6) 原型化加強了開發(fā)過程中用戶的參與和決策。(7) 原型化方法大致可分為三類：拋棄式、演化式和遞增式。(8) 原型化方法大致可分為演化式和遞增式。(9) 采用原型化方法時，軟件的開發(fā)成本較高。(10) 采用原型化方法時，關鍵的因素是建立原形的速度，而不是原形運行的效率。5.3 螺旋模型 螺旋模型綜合了瀑布模型和原型模型中的演化模型的優(yōu)點，還增加了風險分析。螺旋線第一圈的開始點可能是一個概 念項目。

7、從第二圈開始，一個新產品開發(fā)項目開始了，新產品的演化沿著螺旋線進行若干次迭代，一直轉到軟件生命 期結束。5.4 噴泉模型噴泉模型主要用于描述面向對象的開發(fā)過程。噴泉一詞體現(xiàn)了面向對象開發(fā)過程的迭代和無間隙特征。六軟件過程基礎知識6.1 軟件過程軟件過程是指人們用于開發(fā)和維護軟件及相關產品的一系列活動，包括軟件工程過程和軟件管理過程。6.2 評估工具 軟件過程的評估，通常采用軟件能力成熟度 模型( Capability Maturity Model ， CMM)。 CMM1.1 的 5 個等級(由低級到高級) ： 初始級 軟件過程是無序的，有時甚至是混亂的，對過程幾乎沒有定義，成功取決于個人努力

8、，管理是反應式(消防式) 的?？芍貜图?建立了基本的項目管理過程來跟蹤費用、進度和功能特性。制定了必要的過程紀律，能重復早先類似應用項目取得的成功。已定義級 已將軟件管理和工程兩方面的過程文檔化、標準化，并綜合成該組織的標準化軟件過程。所有項目均使用經(jīng)標準、 裁減的標準軟件過程來開發(fā)和維護軟件。已管理級 收集對軟件過程和產品質量的詳細度量，對軟件過程和產品都有定量的理解與控制。優(yōu)化級加強了定量分析，通過來自過程質量反饋和來自新觀念、新技術的反饋使過程能持續(xù)不斷地改進。七軟件工程項目管理基本知識 軟件項目管理開始于任何技術活動之前，并且貫穿于整個的軟件生命周期。 軟件工程項目管理一般分為時間管理

9、、成本管理、人力資源管理、風險管理。7.1 時間管理7.1.1 Gantt 圖 是一種簡單的水平條形圖，它以水平線段表示子任務的工作階段，線段的起點和終點分別對應著子任務的起始時間， 線段長度指示完成該任務所需要的時間。甘特圖的優(yōu)點：直觀簡明、易學易繪、可從圖上清楚地標出子任務間的時間對比，但它也有缺點：(a) 不能顯示地描繪各項彼此間的依賴關系；(b) 進度計劃的關鍵部分不明顯，難以判斷哪些部分應當是主攻和主控的對象；(C)計劃中有潛力的部分以及潛力的大小不明確，往往造成潛力的浪費。7.1.2 PERT 網(wǎng)圖與關鍵路徑PERT 網(wǎng)圖是一個由箭頭（標識任務）和結點（標識事件）組成的有向圖。將網(wǎng)

10、絡方法用于工作計劃安排的評審和 檢查。PERT 圖不僅給出了每個任務的開始時間、結束時間和完成該任務所需的時間，還給出了任務之間的依賴關系，即 哪些任務完成后才能開始另一些任務，以及如期完成整個工程的“關鍵路徑”關鍵路徑（ Critical Path ）是由一連串的任務所組成的鏈，距離最大的一條路徑。軟件項目的管理人員應該密切注視關鍵任務的進展情況。如果希望縮短工期，只有往關鍵任務中增加資源才會有效 果。八模塊化基本知識 模塊是指執(zhí)行某一特定任務的數(shù)據(jù)和可執(zhí)行語句程序元素的集合，通常是指可通過名字來訪問的過程、函數(shù)、子程序 或宏調用等。模塊化就是將一個待開發(fā)的軟件劃分成若干個可完成某一子功能的

11、模塊，每個模塊可獨立地開發(fā)、測試，最后組裝成 完整的程序。8.1 模塊特性8.1.1 可分解性如果一種設計方法提供了將問題分解成子問題的系統(tǒng)化機制，它就能降低整個系統(tǒng)的復雜性，從而實現(xiàn)一種有效的模 塊化解決方案。8.1.2 可組裝性 如果一種設計方法使現(xiàn)存的（可復用的）設計構件能被組裝成新系統(tǒng)，它就能提供一種不需要一切從頭開始的模塊化 解決方案。8.1.3 可理解性 如果一個模塊可以作為一個獨立的單位（不用參考其他模塊）被理解，那么它就易于構造和修改。8.1.4 連續(xù)性而不是整個系統(tǒng)的修改， 則修改引起副作用就會被最小化。如果對系統(tǒng)需求的微小修改只導致對單個模塊，8.1.5 保護性如果模塊內部

12、出現(xiàn)異常情況，并且它的影響限制在模塊內部，不會影響其他模塊，則錯誤引起的副作用就會被最小化。8.2 模塊與模塊的耦合性 耦合是對一個軟件結構內不同模塊之間互連程序的度量。 耦合可以分成下列幾種，它們之間的耦合度由高到低排列。8.2.1 內容耦合 直接操作或修改另一模塊的數(shù)據(jù)，或不通過正常入口轉入另一個模塊。 軟件設計時應堅決禁止內容耦合，應設計成單入口、單出口的模塊，避免病態(tài)連接。8.2.2 公共耦合 多個模塊引用同一全局數(shù)據(jù)區(qū)。8.2.3 外部耦合 模塊與軟件以外的環(huán)境有關聯(lián)。例如，輸入輸出把一個模塊與特定的設備、格式、通信協(xié)議耦合在一起。8.2.4 控制耦合 一模塊明顯把開關量、名字等信息

13、送入另一模塊，控制另一模塊的功能。8.2.5 標記耦合兩個模塊之間通過傳遞公共指針或地址相互作用的耦合。8.2.6 數(shù)據(jù)耦合 模塊間通過傳遞數(shù)據(jù)交換信息。8.2.7 非直接耦合(無耦合) 模塊間無任何關系，獨立工作原則上講，模塊化設計總是希望模塊之間的耦合表現(xiàn)為非直接耦合方式。在以上耦合中，耦合度從高到低， 內容耦合度最高，非直接耦合度最低。8.3 模塊的內聚性 內聚是指一個模塊內各個元素彼此結合的緊密程序，它是信息隱蔽和局部的概念的自然擴展。設計時應該力求高內聚， 理想內聚的模塊應當恰好做一件事情。1).偶然內聚：一個模塊的各成分之間毫無關系。比如：一組語句在程序的多處出現(xiàn)，為了節(jié)省內存空間

14、，這些語句放 在一個模塊中，該模塊的內聚是偶然內聚的。2)3)邏輯內聚：把幾種邏輯上相關的功能組放在同一模塊中。瞬時內聚(時間內聚) ：一個模塊所包含的任務必須在同一時間間隔內執(zhí)行，例如初始化模塊。過程內聚： 通信內聚： 順序內聚： 功能內聚：一個模塊的處理元素是相關的，而且必須按特定的次序執(zhí)行。 一個模塊的所有成分都結合再同一個數(shù)據(jù)結構上。 模塊的成分同一個功能密切相關，且輸出，作為另外一個成分的輸入。 模塊內的所有成分屬于一個整體，完成單一的功能。 內聚度從低到高，偶然內聚度最低，功能內聚度最高。4)5)6)7) 在以上的內聚中，模塊的高內聚、低耦合的原則稱為模塊獨立原則，也稱為模塊設計的

15、原則。8.4 模塊的深度、寬度、扇出與扇入 深度：表示軟件結構中控制的層數(shù)。 寬度是軟件結構中同一個層次上的模塊總數(shù)的最大值 一個模塊的扇入是指直接調用該模塊的上級模塊的個數(shù)。 一個模塊的扇出是指該模塊直接調用的下級模塊的個數(shù)。設計原則：低扇出、高扇入。8.5 模塊作用域和控制域 軟件設計時，模塊的作用域應在控制域之內。8.6 模塊化基礎知識小結 通過模塊的合并和分解，降低模塊的耦合度。模塊的扇入應盡量大，扇出應盡量小。一個模塊的扇入是指直接調用該模塊的上級模塊的個數(shù)。一個模塊的扇出是指 該模塊直接調用的下級模塊的個數(shù)。扇入大表示模塊的重用性高，利用率高。扇出大表示模塊的復雜度高。所以要高 扇

16、入，低扇出。要將模塊的作用范圍限制在模塊的控制范圍之內。降低模塊之間的復雜性，避免“病態(tài)連接” 。九什么是軟件開發(fā)方法？有哪些主要方法？軟件開發(fā)方法：使用已定義好的技術集及符號表示習慣組織軟件生產的過程。 結構化方法、面向對象方法、 JACKSON 方法。，是一種面向數(shù)據(jù)流的需求分析方法。它的基本思想是自頂向下9.1 結構化方法學 結構化方法學也稱為生命周期方法學（瀑布模型方法） 逐層分解。為了在需求改變時對軟件的影響較小，結構化分析時應該使程序結構與問題結構相對應。常用工具：數(shù)據(jù)流圖（DFD）、數(shù)據(jù)字典（DD）、實例一關系圖（E R圖）及描述加工處理的結構化語言、判定表、判定樹。9.1.1數(shù)

17、據(jù)流圖 （DFD 圖）DFD 的基本成分數(shù)據(jù)流圖主要由 4 種成分組成： 數(shù)據(jù)流（ data flow ）：由一組固定成分的數(shù)據(jù)組成，表示數(shù)據(jù)的流向。它可以從源、文件流向加工，也可以從加工流向 文件和宿，還可以從一個加工流向另一個加工。通常每個數(shù)據(jù)流必須有一個合適的名字，一方面是為了區(qū)別，另一方 面也給人一個直觀的印象，使人容易理解這個數(shù)據(jù)流的含義。但流向文件或從文件流出的數(shù)據(jù)流不必命名，因為這種 數(shù)據(jù)流的組成部分就是相應文件的組成部分。加工（Process）：描述了輸入數(shù)據(jù)流到輸出數(shù)據(jù)流之間的變換，也就是輸入數(shù)據(jù)流做了什么處理后變成了輸出數(shù)據(jù)流。 每個加工有一個名字和一個編號。 編號反映了該

18、加工位于分層 DFD 的哪個層次和哪張圖中以及它是哪個加工分解出來 的子加工。文件（ file ）：可以表示數(shù)據(jù)文件，也可以表示一個數(shù)據(jù)記錄。流向文件的數(shù)據(jù)流表示寫文件，流出文件的數(shù)據(jù)流表示 讀文件，雙向箭頭表示對文件既讀又寫。每個文件都有一個文件名。源/宿（source/sink）：源是指系統(tǒng)所需數(shù)據(jù)的發(fā)源地，宿（也稱數(shù)據(jù)池）是指系統(tǒng)所產生的數(shù)據(jù)的歸宿地。無論源或宿， 均對應于外部實體，在框內應加注實體的名字，在一個軟件各級軟件系統(tǒng)中，有些源和宿可以是一個外部實體，外部 實體是指存在于軟件系統(tǒng)之外的人員或組織，它指出系統(tǒng)所需數(shù)據(jù)的發(fā)源地和系統(tǒng)所產生數(shù)據(jù)的歸宿地。分層數(shù)據(jù)流圖一套分層的的數(shù)據(jù)流

19、圖由頂層、底層、和中間層組成。畫分層數(shù)據(jù)流圖基本原則與注意事項a.自外向內，自頂向下，逐層細化，完善求精。b保持父圖與子圖的平衡。 也就是說，父圖中某加工的輸入數(shù)據(jù)流中的數(shù)據(jù)必須與它的子圖的輸入數(shù)據(jù)流在數(shù)量和名字 上相同?；蛘呤峭ㄟ^C.保持數(shù)據(jù)守恒。也就是說，一個加工所有輸出數(shù)據(jù)流中的數(shù)據(jù)必須能從該加工的輸入數(shù)據(jù)流中直接獲得， 該加工能產生的數(shù)據(jù)。d. 加工細節(jié)隱藏。根據(jù)抽象原則，在畫父圖時，只需畫出加工和加工之間的關系，而不必畫出各個加工內部的細節(jié)。e. 簡化加工間關系。在數(shù)據(jù)流圖中，加工 間的數(shù)據(jù)流越少，各加工就越相對獨立，所以應盡量減少加工間輸入輸出數(shù)據(jù)流的數(shù)目。f. 均勻分解。應該使一

20、個數(shù)據(jù)流中的各個加工分解層次大致相同。g. 適當?shù)貫閿?shù)據(jù)流、加工、文件、源/宿命名，名字應反映該成分的實際意義，避免空洞的名字。h. 忽略枝節(jié)。應集中精力于主要的數(shù)據(jù)流，而暫不考慮一些例外情況、出錯處理等枝節(jié)性問題。i. 表現(xiàn)的是數(shù)據(jù)流而不是控制流。j. 每個加工必須既有輸入數(shù)據(jù)流，又有輸出數(shù)據(jù)流 .在整套數(shù)據(jù)流圖中，每個文件必須既有讀文件的數(shù)據(jù)流又有寫文件的數(shù)據(jù)流，但在某一張子圖中可能只有讀 沒有寫或者只有寫沒有讀。小結：一個軟件系統(tǒng)，其數(shù)據(jù)流圖往往有多層。如果父圖有N個加工（Process）,則父圖允許有 0N張子圖，但是每張子圖只能對應一張父圖。在一張 DFD 圖中，任意兩個加工之間可以

21、有 0條或多條名字互不相同的數(shù)據(jù)流；在畫數(shù)據(jù)流 圖時, 應該注意父圖和子圖的平衡, 即父圖中某加工的輸入輸出數(shù)據(jù)流必須與其輸入輸出流在數(shù)量和名字上相同。DFD信息流大致可分為兩類：交換流和事務流。9.1.2 數(shù)據(jù)字典數(shù)據(jù)字典是關于數(shù)據(jù)的信息的集合也就是對數(shù)據(jù)流圖中包含的所有元素的定義的集合。組成部分：a數(shù)據(jù)項條目b數(shù)據(jù)流條目C.文件條目d.加工條目加工條目是對數(shù)據(jù)流圖中每一個不能再分 解的基本加工的精確說明。常用的加工描述方法有結構化語言、 判定樹和判定表。對于加工的描述是數(shù)據(jù)字典的組成內容之一，9.1.3 結構化語言結構化語言實際上是一種半形式化語言， 它的結構通?？煞譃閮韧鈨蓪?。外層接近于

22、形式化語言，而內層近似于自然語言的描述。9.1.4 實體關系圖（ ER 圖）實體關系圖（ Entity-RelabionshipDiagram），簡稱E-R圖，包含實體、關系和屬性等3種基本成分。通常用矩形框代表實體，并用直線把實體（或關系）與其屬性連接起來。E-R 圖通常用于數(shù)據(jù)庫應用系統(tǒng)。9.2 結構化設計 結構化設計通?？煞譃楦乓O計和詳細設計，但是主要用于概要設計階段。概要設計的任務是確定軟件系統(tǒng)的 結構，進行模塊劃分，確定每個模塊的功能、接口以及模塊間的調用關系。詳細設計的任務是為每個模塊設計實現(xiàn)的 細節(jié)。9.2.1 概要設計 經(jīng)過需求分析階段的工作，系統(tǒng)必須“做什么”已經(jīng)清楚了，概

23、要設計的基本目的就是回答“概括地說，系統(tǒng)應 該如實現(xiàn)？”這個問題。概要設計的重要任務： 將一個復雜的系統(tǒng)按功能化分為模塊、確定每個模塊的功能、確定模塊之間的調用關系、確定模塊之間的接口（模塊 之間傳遞的信息） 、評價模塊的結構質量。1.軟件結構圖形工具結構化設計方法（SD）方法采用結構圖（Structure Chart）、層次圖和HIPO圖描述軟件結構。結構圖的主要成分有模塊、調用和數(shù)據(jù)，結構圖中的模塊用矩形表示，在矩形框內可標上模塊的名字。模塊間如 有箭頭或直線相連，表明它們之間有調用關系。層次圖用來描繪軟件的層次結構.層次圖中一個矩形框代表一個模塊,方框間的連線表示模塊間的調用關系HIPO

24、 圖實際上就是層次圖加輸入 /處理/輸出圖 . HIPO 圖是美國 IBM 公司發(fā)明的“層次圖加輸入 /處理/輸出圖”，是 在層次圖里出了最頂層的方框之外，每個方框都加了編號。編號規(guī)則和數(shù)據(jù)流圖的編號規(guī)則一樣。9.2.2 詳細設計 概要設計已經(jīng)確定了每個模塊的功能和接口，詳細設計的任務就是為每個模塊設計其實現(xiàn)的細節(jié)。詳細設計階段的根本目標是確定應該怎樣具體地實現(xiàn)所要求的系統(tǒng)，得出對目標系統(tǒng)的精確描述。1.詳細設計階段的內容 為每個模塊進行詳細的算法設計。 為模塊內部的數(shù)據(jù)結構進行設計。 對數(shù)據(jù)庫進行物理設計。其他詳細設計工具主要包括程序流程圖（系統(tǒng)流程圖 ）、盒圖（ N-S 圖）、 PAD 圖

25、和偽碼（ PDL）。2人機界面設計人機界面的設計質量，直接影響用戶對軟件產品的評價。界面的美觀、靈活和風格都很重要，但人機界面設計中最 重要的也是最基本的目標是軟件的易操作性。人機界面設計主要包括系統(tǒng)響應時間、 用戶幫助設計、 出錯信息處理和命令交互設計等幾個方面。9.3 Jackson 方法上面講的結構化設計方法是面向數(shù)據(jù)流的，另外還有一種面向數(shù)據(jù)結構的設計方法，Jackson 方法是最著名的面向數(shù)據(jù)結構的設計方法,而不是面向數(shù)據(jù)流的設計方法。Jackson 方法的基本步驟是：建立系統(tǒng)的數(shù)據(jù)結構；以數(shù)據(jù)結構為基礎，對應地建立程序結構；列出程序中要用到 的各種基本操作，再將這些操作分配到程序結

26、構適當?shù)哪K中。9.4 面向對象分析方法（ 00A ） 十軟件工具軟件工具是指用于輔助軟件開發(fā)、 運行、 維護、 管理、 支持等過程中的活動的軟件。 通常也稱為 CASE （Computer Aided Software Engineering, 計算機輔助軟件工程）工具。按軟件過程的活動分為軟件開發(fā)工具、軟件維護工具和軟件管理工具等。十一 . 軟件開發(fā)環(huán)境 集成型開發(fā)環(huán)境通?？捎晒ぞ呒铜h(huán)境集成機制兩部分組成。這種環(huán)境應具有開放性和可裁減性。環(huán)境集成機制主要 有數(shù)據(jù)集成機制、控制集成機制和界面集成機制。十二 . 軟件質量管理基礎知識6 個方面來衡量。12.1 軟件質量軟件質量模型可從軟件功能

27、性、可靠性、可用性、效率、可維護性、可移植性 （1）功能性 與功能及其指定的性質的一組軟件屬性。（2）可靠性 軟件在規(guī)定的一段時間內和規(guī)定的條件下保持其性能水平有關的一組軟件屬性。也可以稱為在規(guī)定的條件下和 規(guī)定的時間間隔內，軟件實現(xiàn)其規(guī)定功能的概率。（ 3）可用性 與使用的難易程序及規(guī)定或隱含用戶對使用方式所做的評價有關的軟件屬性。（4）效率 與在規(guī)定條件的性能水平與所用資源量之間的關系有關的一組軟件屬性。（5）可維護性 與軟件維護的難易程序有關的一組軟件屬性。（6）可移植性 軟件可從某一環(huán)境轉移到另一環(huán)境的能力有關的一組屬性。即軟件從一個計算機系統(tǒng)轉換到另一個計算機系統(tǒng) 運行的難易程度是指

28、軟件的可移植性。為了提高可移植性，應注意提高軟件的設備獨立性。采用表格驅動程序有助于 提高設備獨立性。為了提高可移植性，還應有完備的文檔資料。使用C 語言開發(fā)的系統(tǒng)軟件具有較好的可移植性。12.2 軟件質量保證 軟件質量保證的主要困難表現(xiàn)在以下幾個方面：1） 軟件開發(fā)的管理人員往往關心項目開發(fā)的成本與進度。因為成本和進度是顯而易見的，而軟件質量則難以度量。他們必定沒有太高的熱情去控制開發(fā)的質量，如果軟件開發(fā)的管理人員對交付的軟件含有多少隱患并不必負什么責任， 更不必說保證質量并不容易且代價昂貴。 開發(fā)人員的習慣一旦形成難以改變，他們的形為也難于控制，而高質量的軟件產品，又主要取決于參與開發(fā)的人

29、員。復雜的軟件項目需要許多技術人員和管理人員參與，對問題的不同認識和誤解如不能及時消除必然影響軟件質量。軟件開發(fā)人員的頻繁流動，特別是骨干開發(fā)人員的流失，也會使軟件質量受到一定的影響。軟件質量的保證手段： 開發(fā)初期制定質量保證計劃，并在開發(fā)中堅持實行。 開發(fā)前選定或制定開發(fā)標準或開發(fā)規(guī)范，并遵照實施。 從開始就選擇分析設計方法和工具，形成高質量的分析模型和設計模型。 嚴格執(zhí)行階段評審，以便及時發(fā)現(xiàn)問題。各個開發(fā)階段的測試。 對軟件的每次“變動”都要經(jīng)過申請、評估、批準、實施等步驟。 軟件質量特性的度量化。軟件生存期的各階段都要完整的文檔。十三 .軟件測試軟件測試的費用已經(jīng)超過軟件開發(fā)費用的30

30、%左右?！案弋a”測試是指用少量的測試用例，發(fā)現(xiàn)被測試程序盡可能多的錯誤。13.1 軟件測試經(jīng)過的步驟單元測試 集成測試 確認測試 系統(tǒng)測試13.2 測試與軟件開發(fā)各階段的關系 單元測試對程序中每一個程序單元進行測試，檢查各個模塊是否爭取實現(xiàn)規(guī)定的功能，從而發(fā)現(xiàn)模塊在編碼中或算法 中的錯誤，該階段涉及編碼和詳細設計文檔。集成測試是為了檢查與設計相關的軟件體系結構的有關問題，也就是檢查概要設計是否合理有效。確認測試主要是檢查已實現(xiàn)的軟件是否滿足需求規(guī)格說明書中已確定了的各種需求。系統(tǒng)測試是把已確認的軟件與其他系統(tǒng)元素（如硬件，其他支持軟件、數(shù)據(jù)、人工等）結合在一起進行測試，以確定 軟件是否可以支付

31、使用。13.3 白盒測試 白盒測試又稱為結構測試?？梢园殉绦蚩闯裳b在一個透明盒子里，測試者（一般為編程者）完全知道程序的結構和處 理算法。按照程序內部邏輯設計測試用例，檢測程序中的主要執(zhí)行通路是否能按預定要求正常工作。 白盒測試多用于單元測試階段。邏輯覆蓋是主要的白盒測試技術。白盒測試時，確定測試數(shù)據(jù)應根據(jù)程序的內部邏輯 和指定的覆蓋方式。采用一下幾種邏輯覆蓋標準：語句覆蓋判定覆蓋條件覆蓋判定 /條件覆蓋條件組合覆蓋路徑覆蓋 滿足條件組合覆蓋測試用例，也一定滿足判定條件覆蓋。因此，條件組合覆蓋是上述五種覆蓋標準中最強的一種。13.4 黑盒測試 黑盒測試，又稱為功能測試。把軟件看做是一個不透明的

32、黑盒子，完全不考慮（或不了解）軟件內部結構和處理算法， 它只檢測軟件功能是否能按照軟件需求說明書的要求正常使用，軟件是否能適當?shù)慕邮茌斎霐?shù)據(jù)并產生正確的輸出信 息，軟件運行過程中能否保持外部信息（例如文件和數(shù)據(jù)庫）的完整性等。常用的黑盒測試技術包括等價類劃分，邊值分析、錯誤推測和因果圖等。其中等價類劃分和邊界值分析法方法最常用。 如果兩者結合使用，更有可能發(fā)現(xiàn)軟件中的錯誤。13.4 灰盒測試 灰盒測試介于白盒測試和黑盒測試之間，它把軟件看做是一個半透明的灰盒子，結合考慮軟件的內部結構和外部功能 設計測試用例13.5 回歸測試糾正了程序中的錯誤之后，選擇部分或全部原先已測試過的測試用例，對修改后

33、程序重新測試以驗證對軟件修改后有 沒有引出新的錯誤，稱為回歸測試。13.6 單元測試單元測試（ Unit testing ）也稱為模塊測試或結構測試，通?？煞旁诰幊屉A段（實現(xiàn)階段 ），主要采用邏輯覆蓋技術，由程序員對自己編寫的模塊自行測試，檢查模塊是否能實現(xiàn)了詳細設計說明書中規(guī)定的功能和算法。stub）模塊。頂層模塊測試時不需要驅動模塊，底層模塊單元測試主要發(fā)現(xiàn)編程和詳細設計中產生的錯誤。 測試一個模塊時需要為該模塊編寫一個驅動模塊和若干個樁（ 測試時不需要樁模塊。在進行單元測試時，常用的方法是白盒測試（采用邏輯覆蓋的測試技術 ），輔之以黑盒測試。13.7 集成測試集成測試（ integrat

34、ion testing ）也稱為組裝測試，在單元測試的基礎之上，把所有的模塊組裝成一個系統(tǒng)進行測試。主 要測試設計階段產生的錯誤，集成測試計劃應該在概要設計階段制定。非漸增式集成測試 首先將每個模塊分別進行單元測試，再把所有的模塊組裝成一個完整的系統(tǒng)進行測試。目前在進行集成測試時已普遍 采用漸增式集成。漸增式集成測試 又可以分為自頂向下集成和自底向上集成。自頂向下集成先測試上層模塊，再測試下層模塊，由于測試下層模塊時上 層模塊已經(jīng)測試過，所以不必要另外編寫驅動模塊。自底向上集成，先測試下層模塊，再測試上層模塊。頂層模塊測試時不需要驅動模塊，底層模塊測試時不需要樁模塊。 軟件的集成測試最好由不屬

35、于該軟件開發(fā)組的軟件設計人員承擔，以提高集成測試的效果。13.8 確認測試 在系統(tǒng)驗收測試中，驗證測試是在模擬的環(huán)境中進行強度測試的基礎上進行，主要依據(jù)軟件需求說明書檢測軟件的功 能，性能及其他特征是否與用戶的要求一致，而確認測試是在一個實際環(huán)境中使用真實數(shù)據(jù)運行系統(tǒng)。確認測試計劃應該在需求分析階段制定。a測試由用戶在開發(fā)者的場所進行，并且在開發(fā)者的指導下進行測試。開發(fā)者負責紀錄發(fā)現(xiàn)的錯誤和使用中遇到的問題，也 就是說 a 測試是在受控的環(huán)境中進行的。B測試是在一個或多個用戶的現(xiàn)場由該軟件的最終用戶實施的，開發(fā)者通常不在現(xiàn)場，用戶負責記錄發(fā)現(xiàn)的錯誤和使用中遇到的問題并把這些問題報告給開發(fā)者。也

36、就是說，3測試是在受控的環(huán)境中進行的。經(jīng)過確認測試之后的軟件通常就可以交付使用了。13.9 系統(tǒng)測試 系統(tǒng)測試是將已經(jīng)確認的軟件、計算機硬件、外設和網(wǎng)絡等其他因素結合在一起，進行信息系統(tǒng)的各種組裝測試 和確認測試，其目的是通過與系統(tǒng)的需求相比較，發(fā)現(xiàn)所開發(fā)的系統(tǒng)與用戶需求不符或矛盾的地方。包括以下的測試： 恢復測試：監(jiān)測系統(tǒng)的容錯能力 安全性測試：監(jiān)測系統(tǒng)的安全機制、保密措施是否完善等防范能力。 強度測試：測試軟件的異常情況的處理能力。 性能測試：監(jiān)測系統(tǒng)是否滿足系統(tǒng)設計方案說明書對性能的要求?？煽啃詼y試：從平均失效間隔是否超過了規(guī)定的時限，因故障而停機的時間在一年中不應超過的時間來進行檢測。

37、安裝測試：監(jiān)測軟件在安裝過程中是否有錯誤、是否容易操作等。系統(tǒng)測試計劃在系統(tǒng)測試階段初期制定。問答題1、可行性研究的任務是什么？首先需要進行概要的分析研究，初步確定項目的規(guī)模和目標，確定項目的約束和限制，把他們清楚地列舉出來。然后，分析員進行簡 要的需求分析，抽象出該項目的邏輯結構，建立邏輯模型。從邏輯模型出發(fā)，經(jīng)過壓縮的設計，探索出若干種可供選擇的主要解決方法， 對每種解決方法都要研究它的可行性，可從以下三個方面分析研究每種解決方法的可行性。技術可行性：對要開發(fā)項目的功能、性能、 限制條件進行分析，確定在現(xiàn)有的資源條件下，技術風險有多大，項目是否能實現(xiàn)。經(jīng)濟可行性：進行開發(fā)成本的估算以及了解

38、取得效 益的評估，確定要開發(fā)的項目是否值得投資開發(fā)。社會可行性：要開發(fā)的項目是否存在任何侵犯、妨礙等責任問題，要開發(fā)項目的運行 方式在用戶組織內是否行得通，現(xiàn)有管理制度、人員素質、操作方式是否可行。2、需求分析階段的基本任務是什么？需求分析階段的基本任務是要準確的定義新系統(tǒng)的目標，為了滿足用戶需要，回答系統(tǒng)必須“做什么”的問題。本階段要進行以下幾方面 的工作：問題識別。雙方確定對問題的綜合需求，這些需求包括：功能需求、性能需求、環(huán)境需求、用戶界面需求，另外還有可靠性、 安全性、保密性、可移植性、可維護性等方面的需求。分析與綜合，導出軟件的邏輯模型。分析人員對獲取的需求，進行一致性的分析檢查，在

39、分析、綜合中逐步細化軟件功能，劃分成各個子功能。這里也包括對數(shù)據(jù)域進行分解，并分配到各個子功能上，以確定系統(tǒng)的構成 及主要成份，并用圖文結合的形式，建立起新系統(tǒng)的邏輯模型。編寫文檔。編寫“需求規(guī)格說明書”、編寫初步用戶使用手冊、編寫確 認測試計劃、修改完善軟件開發(fā)計劃。3、什么是模塊的影響范圍？什么是模塊的控制范圍？他們之間應該建立什么關系？一個模塊的作用范圍（或稱影響范圍）指受該模塊內一個判定影響的所有模塊的集合。一個模塊的控制范圍指模塊本身以及其所有下 屬模塊（直接或間接從屬于它的模塊）的集合。一個模塊的作用范圍應在其控制范圍之內，且判定所在的模塊應在其影響的模塊在層次上 盡量靠近。如果再

40、設計過程中，發(fā)現(xiàn)模塊作用范圍不在其控制范圍之內，可以用“上移判點”或“下移受判斷影響的模塊，將它下移到判 斷所在模塊的控制范圍內”的方法加以改進。4、非漸增式測試與漸增式測試有什么區(qū)別？漸增式測試如何組裝模塊？非漸增式測試與漸增式測試的測試方法有以下區(qū)別：非漸增式測試方法把單元測試和集成測試分成兩個不同的階段，前一階段完成 模塊的單元測試， 后一階段完成集成測試。 而漸增式測試往往把單元測試與集成測試和在一起， 同時完成。 非漸增式需要更多的工作量， 因為每個模塊都需要驅動模塊和樁模塊，而漸增式利用已測試過的模塊作為驅動模塊或樁模塊，因此工作量較少。漸增式可以較早的發(fā) 現(xiàn)接口之間的錯誤，非漸增

41、式最后組裝是才發(fā)現(xiàn)。漸增式有利于排錯，發(fā)生錯誤往往和最近加進來的模塊有關，而非漸增式發(fā)現(xiàn)接口錯 誤推遲到最后，很難判斷是哪一部分接口出錯。漸增式比較徹底，已測試的模塊和新的模塊再測試。漸增式占用的時間較多，但非漸 增式須更多的驅動模塊、樁模塊也占用一些時間。非漸增式開始可并行測試所有模塊，能充分利用人力，對測試大型軟件很有意義。漸 增式測試有以下兩種不同的組裝模塊的方法：自頂向下組合。該方法只需編寫樁模塊，其步驟是從頂層模塊開始，沿被測程序的軟件結 構圖的控制路徑逐步向下測試，從而把各個模塊都結合起來，它又有兩種組合策略：深度有先策略：先從軟件結構中選擇一條主控制路 徑，把該路徑上的模塊一個個

42、結合進來進行測試，以便完成一個特定的子功能，接著再結合其它需要優(yōu)先考慮的路徑。寬度有先策略：逐層結合直接下屬的所有模塊。 自低向上結合。 該方法僅需編寫驅動模塊。 其步驟為： 把底層模塊組合成實現(xiàn)一個個特定子功能的族。為每一個族編寫一個驅動模塊，以協(xié)調測試用例的輸入和測試結果的輸出。對模塊族進行測試。按軟件結構圖依次向上擴展，用實 際模塊替換驅動模塊，形成一個個更大的族。重復至步，直至軟件系統(tǒng)全部測試完畢。5、軟件質量與軟件質量保證的含義是什么？從實際應用來說，軟件質量定義為：與所確定的功能和性能需求的一致性。與所成文的開發(fā)標準一致性。與所有專業(yè)開發(fā)的軟 件所期望的隱含特性的一致性。軟件質量保

43、證就是向用戶及社會提供滿意的高質量的產品，確保軟件產品從誕生到消亡為止的所有階段的 質量的活動，即確定、達到和維護需要的軟件質量而進行的所有有計劃、有系統(tǒng)的管理活動。5、軟件工程標準化的意義是什么？都有哪些軟件工程標準？積極推進軟件工程標準化， 其道理是顯而易見的。 僅就一個軟件開發(fā)項目來說， 有許多層次， 不同分工的人員相互配合， 在開發(fā)項目的各個部分以及各開發(fā)階段之間也都存在許多聯(lián)系和銜接問題。如何把這些錯綜復雜的關系協(xié)調好，需要有一系列統(tǒng)一的約束 和規(guī)定。在軟件開發(fā)項目取得階段成果或最后完成是時，需要進行階段評價和驗收測試。投入運行的軟件，其維護工作中遇到問題又與開 發(fā)工作者有著密切的關

44、系。軟件的管理工作則滲透到軟件生存期的每一個環(huán)節(jié)。所有這些都要要求提供統(tǒng)一的行動規(guī)范和衡量準則，使得 各種工作都有章可循。軟件工程的標準主要有以下三個：FIPS135是美國國家標準局發(fā)布的軟件文檔管理指南 NSAC 39是美國核子安全分析中心發(fā)布的安全參數(shù)顯示系統(tǒng)的驗證與確認。ISO5807是國際標準化組織公布（現(xiàn)已成為中國的國家標準）的信息處理一數(shù)據(jù)流程圖、程序流程圖、程序網(wǎng)絡圖和系統(tǒng)資源圖的文件編制符號及約定。6、采用黑盒技術設計測試用例有哪幾種方法？這些方法各有什么特點？等價類劃分。等價類劃分是將輸入數(shù)據(jù)域按有效的或無效的（也稱合理的或不合理的）劃分成若干個等價類，測試每個等價類的代表值

45、 就等于對該類其它值的測試。 邊界值分析。 該方法是將測試邊界情況作為重點目標， 選取正好等于， 剛剛大于或剛剛小于邊界值的情況， 根據(jù)這些情況選擇測試用例。錯誤推測。錯誤推測法沒有確定的步驟，憑檢驗進行。它的基本思想是列出程序中可能發(fā)生錯誤的情況， 根據(jù)這些情況選擇測試用例。 因果圖。 因果圖能有效的檢測輸入條件的各種組合可能會引起的錯誤。 因果圖的基本原理是通過畫因果圖， 把用自然語言描述的功能說明轉換為判定表，最后為判定表的每一列設計一個測試用例。7、軟件生產經(jīng)歷了幾個階段？各有何特征？軟件生產至今已經(jīng)歷了三個階段：程序設計時代（1946-1956）:這個階段的生產方式是個體手工勞動，使

46、用的工具實際其語言、匯編語言。開發(fā)方法是追求編程技巧，追求程序運行效率。硬件特征是價格貴、存儲容量小，運行可靠性差。軟件特征是只有程序、程序設計概 念，不重視程序設計方法。程序系統(tǒng)時代（1956-1968）:這個階段的生產方式是作坊式的小集團合作生產，生產工具是高級語言，開發(fā)1968方法仍就靠個人技巧，但開始提出結構化方法。硬件特征是速度、容量、工作可靠性有明顯提高。軟件特征是程序員數(shù)量猛增，但開發(fā)技 術沒有新的突破，開發(fā)人員的素質和落后的開發(fā)技術不適應規(guī)模大、結構復雜的軟件開發(fā)，導致軟件危機的產生。軟件工程時代（ 至今）：這個階段的生產方式是工程化的生產，使用數(shù)據(jù)庫、開發(fā)工具、開發(fā)環(huán)境、網(wǎng)絡

47、、分布式、面向對象技術來開發(fā)軟件。硬件特征 是向超高速、大容量、微型化以及網(wǎng)絡化方向發(fā)展。軟件特征是開發(fā)技術有很大進步，但是未能獲得突破性進展，軟件價格不斷上升，沒 有完全擺脫軟件危機。8、簡述 Gantt 圖的功能及不足。Gantt 圖常用水平線段來描述把任務分解成子任務，以及每個子任務的進度安排，動態(tài)反映軟件開發(fā)進度情況，該圖可以：表示任務 分解成子任務情況； 表示每個任務的開始時間和完成時間， 線段的長度表示子任務完成所需要的時間； 表示子任務之間的并行和串行關系。 Gantt 圖只能表示任務之間的并行與串行的關系，難以反映多個任務之間存在的復雜關系，不能直觀表示任務之間相互依賴制約關系

48、，以 及哪些任務是關鍵字任務等信息，因此僅僅用 Gantt 圖作為進度的安排是不夠的。9、什么是數(shù)據(jù)字典？其作用是什么？它有哪些條目？數(shù)據(jù)字典（簡稱DD）是用來定義數(shù)據(jù)流圖中的各個成分的具體含義的，它以一種準確的、無二義性的說明方式為系統(tǒng)的分析、設計及維護提供了有關元素的一致的定義和詳細的描述。他和數(shù)據(jù)流圖共同構成了系統(tǒng)的邏輯模型，是需求規(guī)格說明書的主要組成部分。 數(shù)據(jù)字典是為分析人員查找數(shù)據(jù)流圖中有關名字的詳細定義而服務的，因此也像普通字典一樣，要把所有條目按一定的次序排列起來，以便查閱。數(shù)據(jù)字典有以下四類條目：數(shù)據(jù)流、數(shù)據(jù)項、數(shù)據(jù)存儲、基本加工。數(shù)據(jù)項是組成數(shù)據(jù) 流和數(shù)據(jù)存儲的最小元素。源

49、點、終點不在系統(tǒng)之內，故一般不在字典中說明。該方法從程序產生錯誤的地方出發(fā)，人10、調試的目的是什么？調試有哪些技術手段？調試的目的是確定錯誤的原因和位置，并改正錯誤，因此調試也成為糾錯。調試技術主要 有：簡單的調試方法，主要有在程序中插入打印語句、運行部分程序等；歸納法調試，他從測試結果發(fā)現(xiàn)的線索（錯誤跡象、征兆）入手、 分析他們之間的聯(lián)系，導處錯誤原因的假設，然后再證明或否定這個假設；演繹法調試，該方法列出所有可能的錯誤原因的假設，然后利 用測試數(shù)據(jù)排除不適當?shù)募僭O，最后再測試數(shù)據(jù)驗證余下的假設確實是出錯的原因；回溯法調試， 工沿程序的邏輯路徑反向搜索，直到找到錯誤的原因為止。11、如何做

50、好軟件質量保證工作？采用技術手段和工具。質量保證活動要貫 組織正式技術評審，在軟件開發(fā)的第一個 設計評審、 審計和測試等具體手段來保證質量。 推選軟件工程規(guī)范（標準）。軟件質量保證工作是軟件工程管理的重要內容，軟件質量保證應做好以下幾個方面的工作： 徹開發(fā)過程始終，必須從采用技術手段和工具，尤其是使用軟件開發(fā)環(huán)境來進行軟件開發(fā)。 階段結束時， 都要組織正式的技術評審。 國家標準要求單位必須采用審查、 文檔評審、對軟件的變更進行控制。軟件的修改和變更常常會引起潛 對軟件質量進行度量。即對軟件質量進行跟蹤，及時記錄和報告軟件質量情況。加強軟件測試。軟件測試是質量保證的重要手段，因為測試可發(fā)現(xiàn)軟件可

51、發(fā)現(xiàn)軟件中大多數(shù)潛在錯誤。 用戶可以自己指定軟件工程規(guī)范（標準），但標準一旦確認就應貫徹執(zhí)行。 伏的錯誤，因此必須嚴格控制軟件的修改和變更。12、什么是數(shù)據(jù)流圖？其作用是什么？DFD，是SA方法中用于表示系統(tǒng)邏輯模型的一種工具。它以圖形的方式描述數(shù)據(jù)在系統(tǒng)其中的基本符號各表示什么含義？數(shù)據(jù)流圖簡稱中流動和處理的過程，由于它只反映系統(tǒng)必須完成的邏輯功能，所以它是一種功能模型。數(shù)據(jù)流圖有四種基本圖形符號：“T”箭頭表示 數(shù)據(jù)流；“O”圓或橢圓表述加工；“=”雙杠表示數(shù)據(jù)存儲；“”方框表示數(shù)據(jù)的源點或終點。13 什么是確認測試？該階段有哪些工作？確認測試又稱有效性測試。它的任務是檢查軟件的功能與性能

52、是否與需求規(guī)格說明書中確定的指標相符合。確認測試階段有兩項工作，進 行確認測試與軟件配置審查。確認測試一般是在模擬環(huán)境中運用黑盒測試方法，由專門測試人員和用戶參加的測試。軟件配置審查的任務是檢查軟件的所有文檔資料的完整性、正確性。如果發(fā)現(xiàn)遺漏和錯誤，應補充和改正，同時要編排好目錄，為以后的軟件維護工作 奠定基礎。14、詳細設計的基本任務是什么？有哪幾種描述方法？詳細設計是軟件設計的第二階段，其基本任務有：為每個模塊進行詳細的算法設計；為模塊內的數(shù)據(jù)結構進行設計；對數(shù)據(jù)庫進行物理設 計，即確定數(shù)據(jù)庫的物理結構；其它設計，根據(jù)軟件系統(tǒng)類型，還可能要進行代碼設計、輸入/輸出格式設計、人機對話設計；編

53、寫詳細設計說明書；評審。詳細描述處理過程常用三種工具：圖形、表格和語言。如結構化程序流程圖、盒圖和問題分析圖。IPO 圖也是詳細設計的主要工具之一。表格工具如判定表可作為詳細設計中描述邏輯條件復雜的算法。過程設計語言（PDL）是一種用于描述模塊算法設計和處理細節(jié)的語言工具。15、什么是軟件危機？其產生的原因是什么？當軟件開發(fā)技術的進步不能跟上硬件技術的進步，未能滿足發(fā)展的要求，致軟件開發(fā)中遇到 的問題找不到解決的辦法，使問題積累起來，形成了尖銳的矛盾，因而導致了軟件危機。主要表現(xiàn)為：經(jīng)費預算經(jīng)常突破，完成時間一再拖延； 開發(fā)的軟件不能滿足用戶要求； 開發(fā)的軟件可維護性差； 開發(fā)的軟件可靠性差。

54、造成軟件危機的原因是由于軟件產 品本身的特點以及開發(fā)軟件的方式、方法、技術和人員引起的。共產生原因主要有以下幾方面：軟件的規(guī)模越來越大，結構越來越復 雜； 軟件開發(fā)管理困難而復雜； 軟件開發(fā)費用不斷增加； 軟件開發(fā)技術落后； 生產方式落后； 開發(fā)工具落后，生產率提 高緩慢。16、CASE 工作臺有哪些分類？一個 CASE 工作臺是一組工具集，支持像設計、實現(xiàn)或測試等特定的軟件開發(fā)階段。工作臺工具能通過共 享文件、共享倉庫或共享數(shù)據(jù)結構來集成。 它能支持大多數(shù)的軟件過程活動。 工作臺有： 程序設計工作臺； 分析和設計工作臺； 測試工作臺； 交叉開發(fā)工作臺； 配置管理（ CM ）工作臺； 文檔工作

55、臺 項目管理工作臺。18、 什么是 CASE？CASE 工具有哪些分類？CASE 是一組工具和方法的集合，可以輔助軟件開發(fā)生命周期各階段進行軟件開發(fā)。從學術研究角度講， CASE 是多年來在軟件開發(fā)管理、 軟件開發(fā)方法、軟件開發(fā)環(huán)境和軟件工具等方面研究和發(fā)展的產物。 CASE 把軟件開發(fā)技術、軟件工具和軟件開發(fā)方法集成到一個統(tǒng)一而 一致的框架中，并且吸引了 CAD （計算機輔助設計）、軟件工程、操作系統(tǒng)、數(shù)據(jù)庫、網(wǎng)絡和許多其它計算機領域的原理和技術。因而，CASE領域是一個應用集成和綜合的領域。從產業(yè)角度講，CASE是種類繁多的軟件開發(fā)和系統(tǒng)集成的產品及軟件工具的集合。CASE分類： CASE

56、 技術種類 CASE 系統(tǒng)所涉及到的技術有兩類：一類是支持軟件開發(fā)過程本身的技術；另一類是支持軟件開發(fā)過程管理的技 術。從 CASE 系統(tǒng)產生方式來看，還有一種特殊的 CASE 技術，即元 CASE 技術。他是生成 CASE 系統(tǒng)的生成器所采用的技術。該生 成器可用來創(chuàng)建支持軟件開發(fā)過程活動及過程管理的CASE系統(tǒng)。v2CASE工具的分類對CASE工具分類的標準可分為：功能。功能是對軟件進行分類的最常用的標準。支持的過程。根據(jù)支持的過程，工具可分為設計工具、編程工具、維護工具等。支持的范圍。根 據(jù)支持的范圍，可分為窄支持、較寬支持和一般支持工具。窄支持指支持過程中特定的任務，較寬支持是指支持特

57、定過程階段；一般支持 是指支持覆蓋軟件過程的全部階段或大多數(shù)階段。1993年，F(xiàn)uggetta根據(jù)CASE系統(tǒng)對軟件過程的支持范圍，提出CASE系統(tǒng)可分為三類：支持單個過程任務的工具。工具可能是通用的，或者也可能歸組到工作臺。工作臺支持某一過程所有活動或某些活動。他們一般以或 多或少的集成度組成工具集。環(huán)境支持軟件過程所有活動或至少大部分。他們一般包括幾個不同的工作臺，將這些工作臺以某種方式集 成起來。19 軟件維護的特點是什么？主要體現(xiàn)在三個方面： 非結構化維護和結構化維護。軟件的開發(fā)過程對軟件的維護有很大的影響。若不采用軟件工程的方法開發(fā)軟件， 則軟件只有程序而無文檔，維護工作非常困難，這是一種非結構化的維護。若采用軟件工程的方法開發(fā)軟件，則各階段都有相應的文檔， 容易進行維護工作，這是一種結構化的維護。 維護的困難性。軟件維護的困難性是由于