系統(tǒng)分析師-軟件工程(六)

1、系統(tǒng)分析師-軟件工程（六）（總分：44.00，做題時間：90分鐘）、單項選擇題（總題數(shù)：36,分數(shù)：44.00）為了直觀地分析系統(tǒng)的動作，從特定的視點出發(fā)描述系統(tǒng)的行為，需要采用動態(tài)分析的方法。其中_（14）_本來是表達異步系統(tǒng)的控制規(guī)則的圖形表示方法，現(xiàn)在已經(jīng)廣泛地應用于硬件與軟件系統(tǒng)的開發(fā)中，它適用 于描述與分析相互獨立、協(xié)同操作的處理系統(tǒng)，也就是并發(fā)執(zhí)行的處理系統(tǒng)。（15）是描述系統(tǒng)的狀態(tài)如何響應外部的信號進行推移的一種圖形表示。（分數(shù)：2.00）(1).A.狀態(tài)遷移圖B .時序圖C. Petri網(wǎng)D.數(shù)據(jù)流圖（分數(shù)：1.00 )A.B.C.VD.解析:(2).A.狀態(tài)遷移圖B .時序圖

2、C. Petri網(wǎng)D.數(shù)據(jù)流圖（分數(shù)：1.00 )A.VB.C.D.解析:為了直觀地分析系統(tǒng)的動作，從特定的視點岀發(fā)描述系統(tǒng)的行為，需要采用動態(tài)分析的方法。其中最常用的動態(tài)分析方法有狀態(tài)遷移圖、時序圖和Petri網(wǎng)。狀態(tài)遷移圖是描述系統(tǒng)的狀態(tài)如何響應外部的信號進行推移的一種圖形表示。時序圖用于對比在系統(tǒng)中處理時間的時序與相應的處理時間，進行系統(tǒng)分析。Petri網(wǎng)方法本來是表達異步系統(tǒng)的控制規(guī)則的圖形表示方法，現(xiàn)在已經(jīng)廣泛地應用于硬件與軟件系統(tǒng)的 開發(fā)中，它適用于描述與分析相互獨立、協(xié)同操作的處理系統(tǒng)，也就是并發(fā)執(zhí)行的處理系統(tǒng)。數(shù)據(jù)流圖是描述數(shù)據(jù)處理過程的工具，從數(shù)據(jù)傳遞和加工的角度，以圖形的方

3、式刻畫數(shù)據(jù)流從輸入到輸岀 的移動變換過程，是描述系統(tǒng)邏輯模型的圖形化工具之一。1. 在進行項目計劃前，應該首先建立 的目的和范圍，考慮可選的解決方案、 標識技術和管理的約束。沒有這些信息，就不可能進行合理的成本估算、有效的風險評估、適當?shù)捻椖咳蝿談澐只蚴强晒芾淼捻椖?進度安排。A. 人員B .產(chǎn)品C .過程D .計劃（分數(shù)：1.00 ）A.B. VC.D.解析：解析有效的項目管理集中于4P,即人員（people）、產(chǎn)品（product）、過程（process）和項目（project）4P的順序不是任意的。任何管理者如果在項目開發(fā)早期沒有鼓勵全面的客戶溝通，有可能為錯誤的問題建 造一個不錯的解決

4、方案。軟件開發(fā)者和客戶必須一起定義產(chǎn)品的目的和范圍。目的是標識岀該產(chǎn)品的總體 目標（從客戶角度），而不考慮這些目標如何實現(xiàn)。范圍是標識岀與產(chǎn)品相關的主要數(shù)據(jù)、功能和行為，更 為重要的是，它以量化的方式約束這些特性。2. 在新系統(tǒng)全部正式運行前，一部分一部分地代替舊系統(tǒng)的統(tǒng)轉換策略稱為A. 直接轉換B 位置轉換C 分段轉換D 并行轉換（分數(shù)： 1.00 ）A.B.C. VD.解析： 解析 新系統(tǒng)試運行成功之后，就可以在新系統(tǒng)和舊系統(tǒng)之間互相轉換。分段轉換又稱逐步轉換、向導轉換、試 點過渡法等。這種轉換方式實際上是直接轉換與并行轉換方式的結合。在新系統(tǒng)全部正式運行前，一部分 一部分地代替舊系統(tǒng)。那

5、些在轉換過程中還沒有正式運行的部分，可以在一個模擬環(huán)境中繼續(xù)試運行。 這種轉換方式既保證了可靠性，又不至于費用太大。但是它要求子系統(tǒng)之間有一定的獨立性，否則就無法 實現(xiàn)這種分段轉換的設想。3. 有兩種需求定義的方法嚴格定義和原型定義，在關于這兩種方法的描述中，不正確的是 A. 嚴格定義方法假定所有的需求都可以預先定義B 嚴格定義方法假定軟件開發(fā)人員與用戶之間的溝通存在障礙C. 原型定義方法認為需求分析中不可避免地要出現(xiàn)很多反復D. 原型定義方法強調(diào)用戶在軟件開發(fā)過程中的參與和決策（分數(shù)： 1.00 ）A.B. VC.D.解析： 解析 嚴格定義方法用于結構化分析和設計的場合中。該方法假定所有的需

6、求都是可以被預先定義的，而且認為 修改不完善的系統(tǒng)需求代價昂貴且實施困難。進行嚴格的需求定義要求系統(tǒng)開發(fā)人員與用戶能夠進行有效 地溝通，準確地了解用戶的需求，并且可以用靜態(tài)的圖形或文本工具完整地表示系統(tǒng)需求。原型方法認為并不是所有的需求在系統(tǒng)開發(fā)之前都可以進行準確定義的，而且軟件開發(fā)人員與用戶之間存 在通信的障礙。 在具備快速建模工具的情況下通過向用戶提供可以運行的系統(tǒng)模型來吸取用戶的反饋意見， 通過不斷反復、不斷修改原型系統(tǒng)可以獲取完整的系統(tǒng)需求，一旦確定了需求，就可以遵照嚴格的方法繼 續(xù)進行系統(tǒng)開發(fā)。4. 下述任務中，不屬于軟件工程需求分析階段的是 。A. 分析軟件系統(tǒng)的數(shù)據(jù)要求B 確定軟

7、件系統(tǒng)的功能需求C.確定軟件系統(tǒng)的性能要求D 確定軟件系統(tǒng)的運行平臺（分數(shù)： 1.00 ）A.B.C.D. V解析： 解析 需求分析階段的主要任務是為一個新系統(tǒng)定義業(yè)務需求， 該階段的關鍵是描述一個系統(tǒng)必須做什么（ 或者一個系統(tǒng)是什么），而不是系統(tǒng)應該如何實現(xiàn)。它通常被劃分成5個工作階段：問題分析；問題評估和方案綜合；建模；規(guī)約；復審。具體來說，需求分析階段需完成以下要求： 確定軟件系統(tǒng)的功能需求和非功能需求； 分析軟件系統(tǒng)的數(shù)據(jù)要求； 導出系統(tǒng)的邏輯模型； 修正項目開發(fā)計劃； 如有必要，可以開發(fā)一個原型系統(tǒng)。對于本題的選項D,確定軟件系統(tǒng)的運行平臺是系統(tǒng)設計階段的工作任務之一。5. 在開發(fā)一

8、個系統(tǒng)時，如果用戶對系統(tǒng)的目標不很清楚，難以定義需求，這時最好使用A. 原型法B .瀑布模型C . V-模型D .螺旋模型（分數(shù)： 1.00 ）A. VB.C.D.解析： 解析 在開發(fā)一個系統(tǒng)時，如果用戶對系統(tǒng)的目標不很清楚，難以定義需求，這時最好使用原型法的系統(tǒng)開發(fā)方 法。應用原型法的主要目的就是獲取需求。使用原型法，在用戶的共同參與下可以改善和加快需求獲取過 程。其第一步是建造一個快速原型，實現(xiàn)客戶或未來的用戶與系統(tǒng)的交互，用戶或客戶對原型進行評價， 進一步細化待開發(fā)軟件的需求。通過逐步調(diào)整原型使其滿足客戶的要求，開發(fā)人員可以確定客戶的真正需 求是什么。第二步則在第一步的基礎上開發(fā)客戶滿意

9、的軟件產(chǎn)品。顯然，快速原型方法可以克服瀑布模型 的缺點，減少由于軟件需求不明確帶來的開發(fā)風險，具有顯著的效果。選項B的“瀑布模型”，是一種將按軟件生命周期劃分為制定計劃、需求分析、軟件設計、程序編寫、軟 件測試和運行維護等 6 個基本活動，并且規(guī)定了它們自上而下、相互銜接的固定次序的系統(tǒng)開發(fā)方法。瀑 布模型強調(diào)文檔的作用，并要求每個階段都要仔細驗證。選項C的“V-模型”，是一種典型的測試模型。該模型通常會在其開始部分對軟件開發(fā)過程進行描述，其 中通過單元測試檢測代碼的開發(fā)是否符合詳細設計的要求；集成測試檢測各單元代碼是否能完好地結合到 一起，是否符合概要設計階段提出的要求；系統(tǒng)測試檢測已集成在

10、一起的產(chǎn)品是否符合系統(tǒng)規(guī)格說明書的 要求；而驗收測試則檢測產(chǎn)品是否符合最終用戶的需求。對于選項D的“螺旋模型”，是指將瀑布模型和快速原型模型結合起來，強調(diào)風險分析的一種開發(fā)模型。6. 軟件測試通常分為單元測試、組裝測試、確認測試、系統(tǒng)測試等四個階段。屬于確認測試階段的活動。A. 設計評審B 代碼審查C 結構測試D 可靠性測試（分數(shù)： 1.00 ）A.B.C.D. V解析： 解析 軟件測試通常分為單元測試、組裝測試、確認測試、系統(tǒng)測試等四個階段。表5-9給出了這4個階段的主要工作任務和測試依據(jù)。確認測試包括有效性測試和軟件配置審查。有效性測試是在模擬的環(huán)境下，運用黑盒測試方法，驗證所測 軟件是否

11、滿足需求規(guī)格說明書列出的要求。在有效性測試中除考慮功能、性能以外，還需檢驗可移植性、 可靠性、兼容性、用戶界面及系統(tǒng)所提供的文檔資料是否符合要求等內(nèi)容。軟件配置審查的目的在于確保 已開發(fā)軟件的所有文檔資料均已編寫齊全，足以支持投入運行以后的軟件維護工作。表5-9軟件測試各階段的主要任務及依據(jù)階段主要任務測試依據(jù)單元測試對軟件設計的最小單位一模塊進行正確性檢驗的測試詳細設計說 明書、源程序組裝測試也稱為集成測試，它是把模塊在按照設計要求組裝起來的同時 進行測試，主要目的是發(fā)現(xiàn)域接口有半的錯誤概要設計說 明書確認 測試檢驗軟件的功能和性能及其他特性是否滿足了需求規(guī)格說明中確 定的各種需求，以及軟件

12、配置是否完全、正確需求規(guī)格說 明書、合同書系統(tǒng) 測試把通過確認測試的軟件作為整個基于計算機系統(tǒng)的一個元素，與 計算機硬件、外設、某些支持軟件、數(shù)據(jù)和人員等其他系統(tǒng)元素 結合在一起，在實際運行環(huán)境下的測試活動7.需求分析的任務是借助于當前系統(tǒng)的物理模型導岀目標系統(tǒng)的邏輯模型，解決目標系統(tǒng)“做什么”的問 題。并不是需求分析的實現(xiàn)步驟之一。A.獲得當前系統(tǒng)的物理模型 B 抽象岀當前系統(tǒng)的邏輯模型C.建立目標系統(tǒng)的邏輯模型 D 確定目標實現(xiàn)的具體技術路線（分數(shù)：1.00 ）A.B.C.D. V解析：解析軟件需求分析工作是軟件生存周期中重要的一步，也是決定性的一步。只有通過軟件需求分析，才能把軟 件功能

13、和性能的總體概念描述為具體的軟件需求規(guī)格說明，從而奠定軟件開發(fā)的基礎。軟件需求決定的是 目標系統(tǒng)“做什么”，而不是“怎么做”的問題 （例如確定目標實現(xiàn)的具體技術路線等 ）。軟件的維護并不只是修正錯誤。為了滿足用戶提岀的增加新功能、修改現(xiàn)有功能以及一般性的改進要求和 建議，需要進行（51），它是軟件維護工作的主要部分；軟件測試不可能揭露舊系統(tǒng)中所有潛在的錯誤， 所以這些程序在使用過程中還可能發(fā)生錯誤，診斷和更正這些錯誤的過程稱為（52）;為了改進軟件未來的可維護性或可靠性，或者為了給未來的改進提供更好的基礎而對軟件進行修改，這類活動稱為（53）(分數(shù)：3.00 )(1).AA.完善性維護VB .

14、適應性維護C 預防性維護D.改正性維護（分數(shù):1.00 )B.C.D.解析:(2).AA.完善性維護B.適應性維護C預防性維護D.改正性維護（分數(shù):1.00 )B.C.D.解析:(3).A完善性維護B.適應性維護C預防性維護D.改正性維護（分數(shù):1.00 )A.B.B. 7D.解析：解析按照每次進行維護的具體目標的不同，軟件維護可分為完善性維護、適應性維護、改正性（糾錯性）維護和預防性維護等 4種類型。每種軟件維護類型的定義以及在整個維護工作量中所占的比例見表5-10。表5-10軟件維護類型表維護類 型定義比例完善性為滿足用戶日益增長的需求，修改和加強現(xiàn)有系統(tǒng)的功能和性50%-維護能的維護活動

15、60%適應性維護為應用軟件適應運行環(huán)境的變化而進行的維護活動20%-25%改正性維護診斷和更正在軟件測試期間未能發(fā)現(xiàn)的遺留錯誤的維護活動20%-25%預防性為了改進軟件未來的可維護性或可靠性，或者為了給未來的改5%- 1維護進提供更好的礎而對軟件進行修改的活動10%8.下面列岀了系統(tǒng)維護工作流程中的幾項關鍵步驟，正確的工作順序是用戶提交維護申請報告交付使用更新文檔測試核實和評價維護申請報告制定維護計劃實施維護A. - B .-宀宀宀TC.- D.-（分數(shù)：1.00 ）A. 7B. 7C. 7D. 7解析：解析系統(tǒng)維護工作正確的流程順序是：用戶提交維護申請報告-核實和評價維護申請報告-制定 維護

16、計劃-實施維護-測試-更新文檔-交付使用。（27）可用于描述數(shù)據(jù)流圖中數(shù)據(jù)存儲及其之間的關系，最初用于數(shù)據(jù)庫概念設計。在某學生選課系統(tǒng)中使 用該工具來描述，學生的學號屬于（28）。（分數(shù)：2.00 ）（1）.A .實體關系圖B .數(shù)據(jù)字典C . IPO圖D .判定表（分數(shù)：1.00 ）A. 7B.C.D.解析：.A 實體B 關系C.屬性D.方法（分數(shù)：1.00 ）A.B.C. 7D.解析：實體關系（ER）模型將現(xiàn)實的信息結構統(tǒng)一用實體、屬性以及實體之間的關系來描述，它可用于描述 數(shù)據(jù)流圖中數(shù)據(jù)存儲及其之間的關系。實體是客觀存在并可互相區(qū)分的“事物”。實體必須有一組表征其特征的“屬性”來描述。關

17、系是實體之間存在的對應的聯(lián)系，關系也可以有屬性。在某學生選課系統(tǒng)中使用 ER圖來描述時，通常學生的學號定義 為“學生”這一實體的屬性。9.基于構件的開發(fā)(CBD)模型，融合了 模型的許多特征。該模型本質是演化的，采用迭代方法開發(fā)軟件。A.瀑布B .快速應用開發(fā)(RAD)C.螺旋D 形式化方法(分數(shù)：1.00 )A.B.C. VD.解析：解析螺旋模型是演化軟件過程模型的一種，最早由Boehm提岀，它將原型實現(xiàn)的迭代特征與線性順序模型中控制的和系統(tǒng)化的方面結合起來，使軟件的增量版本的快速開發(fā)成為可能。在螺旋模型中，軟 件開發(fā)是一系列的增量發(fā)布。面向對象技術為軟件工程的基于構件的過程模型提供了技術框

18、架?；跇嫾拈_發(fā)模型融合了螺旋模型的 許多特征。它本質上是演化型的，要求軟件創(chuàng)建迭代方法。然而，基于構件的開發(fā)模型是利用預先包裝好 的軟件構件來構造應用的。統(tǒng)一軟件開發(fā)(RUP)過程是在產(chǎn)業(yè)界業(yè)已提岀的一系列基于構件的開發(fā)模型的代表。如圖5-5所示的活動圖中，從 A到J的關鍵路徑是(72) ，I和J之間的活動開始的最早時間是(73)*(分數(shù)：2.00 )(1).A . ABEGJ B ADFHJ C. ACFGJ D ADFIJ (分數(shù):A.B. VC.1.00 )D.解析：(2).A . 13 B . 23 C . 29 D . 40 (分數(shù)：1.00 )A.B. VC.D.解析：解析 選

19、項A的路徑 選項B的路徑 選項C的路徑 選項D的路徑對于(1)空的解答思路如下。 “ABEG”所花費的時間為 “ADFH”所花費的時間為 “ACFG”所花費的時間為 “ADFIJ'所花費的時間為(3+10+2+7)=22個單位時間。 (10+9+20+10)=49 個單位時間。(5+4+3+7)=19個單位時間。 (10+9+4+4)=27個單位時間。由以上分析可知，從A到J的關鍵路徑是選項 B的路徑“ ADFH”，因為這一條路徑所花費的時間最多，決定了整個項目完成的最早時間。對于(2)空的解答思路如下。某作業(yè)松弛時間定義為該作業(yè)最遲開始時間減去其最早開始時間。由于作業(yè)F、H是關鍵路徑

20、中的兩個作業(yè)，因此作業(yè)F、H的松弛時間均為0。而在圖5-5活動圖中，作業(yè)I的最早開始時間依賴于作業(yè) F、H的最遲開始時間。作業(yè)F的最早開始時間為第19個單位時間(也是最遲開始時間)，而作業(yè)H的最早開始時間為第 39個單位時間(也是最遲開始時間)。由圖5-5的活動路徑可知，作業(yè)I最早可在第23(19+4)個單位時間開始，即I和J之間的活動開始的最早時間是第23個單位時間。另外，作業(yè)I的最遲開始時間為第 45(49-4)個單位時間。10. PROLOG©言屬于 程序設計范型，該范型將程序設計歸結為列舉事實，定義邏輯關系等。A. 過程式B 函數(shù)式C 面向邏輯D 面向對象(分數(shù)：1.00 )

21、A.B.C. VD.解析：解析程序設計范型是指程序設計的體裁。目前代表性的程序設計范型主要有：過程式程序設計范型、函數(shù)式程 序設計范型、面向邏輯的程序設計范型和；面向對象程序設計范型，見表5-2。表5-2代表性的程序設計范型表類型說明例子過程式程序設計 范型將軟件程序歸結為數(shù)據(jù)結構、算法過程或函數(shù)的設計與確定，程 序的執(zhí)行被看作是各過程調(diào)用的序列Pascal 語言、C語言函數(shù)式程序設計 范型將程序看做是“描述輸入與輸出之間的關系”的一個數(shù)學函數(shù)LISP語言面向邏輯的程序 設計范型將程序設計歸結為列舉事實、定義邏輯關系等Prolog語言面向對象程序設 計范型將程序歸結為一系列對象類，通過繼承關系

22、、消息傳遞等聯(lián)結起 來的結構對軟件開發(fā)的看法可有多種觀點，敏捷軟件開發(fā)方法是一種(83)，代表慢是極限編程 XP,它的核心思想為(84)。(分數(shù)：2.00 )(1) .A .數(shù)學觀B .建模觀C .工程觀D .協(xié)作游戲(分數(shù)：1.00 )A.B.C.D. V解析：(2) .A .強調(diào)文檔和以敏捷性應對變化B. 強調(diào)建模和以敏捷性應對變化C. 強調(diào)設計和以敏捷性應對變化D. 強調(diào)人和人之間的合作的因素和以敏捷性應對變化(分數(shù)：1.00 )A.B.C.D. V解析：解析對軟件開發(fā)的看法可有多種觀點，敏捷軟件開發(fā)方法是一種創(chuàng)作與交流的協(xié)作游戲。極限編程XP是敏捷開發(fā)的典型代表，它的核心思想是強調(diào)人和

23、人之間的合作的因素和以敏捷性應對變化。11. 下列關于軟件需求管理與需求開發(fā)的論述，正確的是 。A. 所謂需求管理是指對需求開發(fā)的管理B. 需求管理包括：需求獲取、需求分析、需求定義和需求驗證C. 需求開發(fā)是將用戶需求轉化為應用系統(tǒng)成果的過程D. 在需求管理中，要求維持對原有需求和所有產(chǎn)品構件需求的雙向跟蹤(分數(shù)：1.00)A.B.C.D. V解析：解析所有與需求直接相關的活動通稱為需求工程。需求工程的活動可分為需求開發(fā)和需求管理兩大類。其中，需求開發(fā)的目的是通過調(diào)查與分析，獲取用戶需求并定義產(chǎn)品需求。需求開發(fā)主要有需求獲取、需求分析、需求定義和需求驗證等 4個過程。需求管理的目的是確保各方對

24、需求的一致理解、管理和控制需求的變更，從需求到最終產(chǎn)品的雙向跟蹤。 在需求管理中，要收集需求的變更和變更的理由，并且維持對原有需求和產(chǎn)品及構件需求的雙向跟蹤。12. 代碼走查(code walkthrough)和代碼審查(code inspection)是兩種不同的代碼評審方法，這兩種方法的主要區(qū)別是。A. 在代碼審查中由編寫代碼的程序員來組織討論，而在代碼走查中由高級管理人員來領導評審小組的活動B. 在代碼審查中只檢查代碼中是否有錯誤，而在代碼走查中還要檢查程序與設計文檔的一致性C. 在代碼走查中只檢查程序的正確性，而在代碼審查中還要評審程序員的編程能力和工作業(yè)績D. 代碼審查是一種正式的評

25、審活動，而代碼走查的討論過程是非正式的(分數(shù)：1.00 )A.B.C.D. V解析：解析代碼審查是一種正式的評審活動，而代碼走查的討論過程是非正式的。因此選項D說法正確。而選項A的說法應改正為“在代碼走查中由編寫代碼的程序員來組織討論，而在代碼審查中由高級管理人 員來領導評審小組的活動”。選項B的說法應改正為“無論代碼審查和代碼走查都要檢查程序與設計文檔的一致性”。選項C中說要評審程序員的編程能力和工作業(yè)績也是不對的。根據(jù)McCabe環(huán)路復雜性度量，下面程序圖(圖5-2)的復雜度是(41)，對這個程序進行路徑覆蓋測試，可 得到的基本路徑是(42)。*(分數(shù)：2.00 )(1) .A . 2 B

26、 . 3 C . 4 D . 5 (分數(shù)：1.00 )A.B.C. VD.解析：(2) .A . ABCHIK ABCHJK ABCDEFGB. ABCHIK ABCHJK ABCDEFGCHIKABCDEGCHIKC. ABCHIK ABCHJK ABCDEFGCHIKABDEGCHJKD. ABCHIK ABCHJK ABCDEFGCHjKABCDEFGCHJKABCDEGCHIK分數(shù)：1.00 )A.B. VC.D.解析： 解析 對程序圖環(huán)路復雜度的求解有 3 種方法。解法 1：程序圖的環(huán)路數(shù)是源代碼復雜程度的度量。根據(jù)McCabe度量法，環(huán)路數(shù)N=e-n+2,其中，e表示有向圖的邊數(shù)，

27、n表示節(jié)點數(shù)。圖5-2中e=13,n=11,得到N=13-11+2=4。解法 2：計算有向圖把平面劃分成的區(qū)域數(shù)。圖5-2 中有3個閉合區(qū)域外加 1個開放區(qū)域，共 4個區(qū)域。所以程序圖的復雜度是 4。解法3:圖5-2中有3個判斷節(jié)點，即節(jié)點 C E、H所以程序圖的復雜度是判斷節(jié)點數(shù)加1，即3+1=4。路徑測試的關鍵是要找出程序圖中所有可能的路徑，這些基本路徑都是從程序起點到終點，并且包含了至 少一條獨立的邊。對圖 5-2 所示的程序進行路徑覆蓋測試，可得到 4條基本路徑: ABCHIK；ABCHJK；ABCDEFGCHIKABCDEGCHIK13. 開發(fā)專家系統(tǒng)時，通過描述事實和規(guī)則由模式匹配

28、得出結論，這種情況下適用的開發(fā)語言是 。A. 面向對象語言 B .函數(shù)式語言C .過程式語言D .邏輯式語言（分數(shù): 1.00 ）A.B.C.D. V解析: 解析 用邏輯式程序設計語言編寫程序不需要描述具體的解題過程，只需要給出一些必要的事實和規(guī)則。這些規(guī) 則是解決問題的方法的規(guī)范說明，根據(jù)這些事實和規(guī)則，計算機利用謂詞邏輯，通過演繹推理得到求解問 題的執(zhí)行序列。邏輯式語言主要用在人工智能領域，也應用在自然語言處理、數(shù)據(jù)庫查詢、算法描述等方 面，尤其適合于作為專家系統(tǒng)的開發(fā)工具。函數(shù)式程序設計語言的數(shù)據(jù)結構本質上是表，而函數(shù)又可以作為值出現(xiàn)在表中，因此函數(shù)式程序的控制結 構取決于函數(shù)，以及函數(shù)

29、的定義和調(diào)用。函數(shù)式語言主要用于符號數(shù)據(jù)處理，如微分和積分演算、數(shù)理邏 輯、游戲推演以及人工智能等其他領域。14. 新項目與過去成功開發(fā)過的一個項目類似，但規(guī)模更大，這時應該使用進行項目開發(fā)設計。A. 原型法B .變換模型C .瀑布模型D .螺旋模型（分數(shù): 1.00 ）A.B.C. VD.解析: 解析 由于新項目與過去成功開發(fā)過的一個項目類似，已經(jīng)有了以前成功的項目開發(fā)經(jīng)驗和積累的軟件模塊，因 此應該用盡可能將這些經(jīng)驗和軟件模塊應用到新項目中，即對于這個規(guī)模更大的軟件項目，應該使用瀑布 模型進行開發(fā)。15. 測試是保證軟件質量的重要手段。根據(jù)國家標準 GB 8566-88 計算機軟件開發(fā)規(guī)范

30、的規(guī)定，應該在 階段制定系統(tǒng)測試計劃。A. 需求分析B .概要設計C .詳細設計D .系統(tǒng)測試分數(shù): 1.00 ）B.C.D.解析：解析根據(jù)國家標準GB 8566-88計算機軟件開發(fā)規(guī)范的規(guī)定，單元測試是根據(jù)詳細設計階段給出的“規(guī)格說 明書”在編碼階段完成的測試工作；集成測試的計劃是在概要設計階段制定的；系統(tǒng)測試計劃應該在需求 分析階段就開始制訂，并在設計階段細化和完善，而不是等系統(tǒng)編碼完成后才制訂測試計劃；而驗收測試 則檢測產(chǎn)品是否符合最終用戶的需求。軟件測試的各個階段與軟件開發(fā)階段的對應關系如圖5-3所示。*16. 結構模板能夠幫助分析員建立一個逐層細化的層次結構。結構環(huán)境圖(ACD, A

31、rchitecture ContextDiagram)則位于層次結構的項層。在從ACD導出的中給出了各個專門子系統(tǒng)和重要的(數(shù)據(jù)與控制)信息流。A. 系統(tǒng)語境圖(SCD) B .結構互連圖(AID)C.結構流程圖(AFD) D 結構圖的規(guī)格說明(ADS)(分數(shù)：1.00 )A.B.C. VD.解析：解析結構模板能夠幫助分析員建立一個逐層細化的層次結構，類似于所有在系統(tǒng)和軟件工程中使 用的建模技術一樣。結構模板如圖5-9所示。用戶界面處理輸入處理處理與控制功能輸出處理維護與自測試圖5-9結構模板模型圖結構環(huán)境圖(ACD)位于層次結構的項層，建立了待實現(xiàn)系統(tǒng)與系統(tǒng)運行環(huán)境之間的信息邊界。從ACD中

32、可以導出結構流程圖(AFD)，AFD給出了各個專門子系統(tǒng)和重要的 (數(shù)據(jù)與控制)信息流。最初始的結構流程圖是 AFD層次結構的頂層節(jié)點，在原始 AFD中的每一個圓角矩形都可以分解，擴充成為另一個結構模板，從而 形成AFD的層次結構。17. 軟件設計的主要任務是設計軟件的結構、過程和模塊，其中軟件結構設計的主要任務是要確定。A. 模塊間的操作細節(jié) B .模塊問的相似性C.模塊問的組成關系 D 模塊的具體功能(分數(shù)：1.00 )A.B.C. VD.解析：解析軟件設計通常可分為概要設計和詳細設計兩個階段。其中，概要設計的主要任務是軟件系統(tǒng)的結構、 進行模塊劃分、確定每個模塊的功能、接口以及模塊間的調(diào)

33、用關系。體系結構設計的主要目標是開發(fā)一個模塊化的程序結構，并表示岀模塊間的控制關系。此外，體系結構設 計將程序結構和數(shù)據(jù)結構相結合，為數(shù)據(jù)在程序中的流動定義了接口。因此，軟件結構設計的主要任務是 要確定模塊問的組成關系。對于選項A "模塊間的操作細節(jié)”屬于軟件物理設計的工作任務之一；對于選項D "模塊的具體功能”屬于軟件邏輯設計的工作任務之一，選項A及選項D均是軟件實現(xiàn)過程中需要考慮的內(nèi)容。而對于選項B “模塊問的相似性”不屬于是軟件結構設計的主要任務之一。18. 在面向數(shù)據(jù)流的設計方法中，一般把數(shù)據(jù)流圖中的數(shù)據(jù)流劃分為 兩種。A. 數(shù)據(jù)流和事務流 B 變換流和數(shù)據(jù)流 C

34、變換流和事務流 D 控制流和事務流（分數(shù)：1.00 ）A.B.C. VD.解析：解析結構化設計方法方法采用結構圖（sc）來描述程序的結構。結構圖的基本成分由模塊、調(diào)用和輸入/輸出數(shù)據(jù)組成。通常在需求分析階段，用結構化分析方法產(chǎn)生了數(shù)據(jù)流圖。面向數(shù)據(jù)流的設計能方便地將數(shù)據(jù)流圖（DFD）轉換成程序結構圖，數(shù)據(jù)流圖中從系統(tǒng)的輸入數(shù)據(jù)到系統(tǒng)的輸岀數(shù)據(jù)流的一連串連續(xù)變換將形成一條信息流。數(shù)據(jù)流圖的信息流大體可分為兩種類型，一種是變換流，另一種是事務流。信息沿著輸入通路進入系統(tǒng)，同時將信息的外部形式轉換成內(nèi)部表示，然后通過變換中心處理，再沿著輸岀通路轉換成外部形式化離開系統(tǒng)。具有這種特性的信息流稱為變換流

35、。信息沿著輸入通路到達一個事務中心，事務中心根據(jù)輸入信息的類型在若干個動作序列中選擇一個來執(zhí)行，這種信息流稱為事務流。19. 某工程計劃如圖5-4所示，由于任務A延遲了一天，為保證該工程按時完成，應將任務一縮短一天，使 成本增加最少。表5-12列岀了各任務每縮短一天所需增加的成本。表5-12某工程任務與每縮短一天所需增加的成本表任務每縮短一天需要增加的成本A4B6C3D2E2.5F2.5G5*A. B B. C C. D D. E（分數(shù)：1.00 ）A.B.C.D. V解析：解析關鍵路徑是一個相關任務序列，該序列具有最大總和的最可能工期。關鍵路徑?jīng)Q定了項目最 早可能完成的時間。對于圖 5-4，

36、其關鍵路徑為：ABEG共需 23天。由于圖5-4中任務A延誤了一天，只有縮短處于關鍵路徑上的任務的完成時間，才可能保證工程按時完成。查表5-12中所列的數(shù)據(jù)可知，將任務 A B、E G縮短一天所增加的成本分別為：4、6、2.5和5,因此選擇將任務E縮短一天，是使成本增加最小的方法。20. 黑盒測試方法是根據(jù)軟件產(chǎn)品的功能設計規(guī)格說明書，通過運行程序進行測試，證實每個已經(jīng)實現(xiàn)的功能是否符合設計要求。 如果某產(chǎn)品的文本編輯框允許輸入 1255個字符，采用測試方法，其測試數(shù) 據(jù)為：0個字符、1個字符、255個字符和256個字符。A. 等價類劃分B 邊界值分析C 比較測試D 正交數(shù)組測試（分數(shù):1.0

37、0 ）A.B. VC.D.解析：解析對于選項A的“等價類劃分測試方法”是將程序的輸入域劃分為數(shù)據(jù)類，以便導岀測試案例，等價劃分的 測試案例設計基于對輸入條件的等價類評估。對于選項B的“邊界值分析測試方法”是一種補充等價類劃分的測試案例設計技術，它不是選擇等價類的任意元素，而是選擇等價類邊界的測試案例。例如，如果某產(chǎn)品的文本編輯框允許輸入1255個字符，則其邊界值分析測試數(shù)據(jù)為：第0個字符、第1個字符、第255個字符和第256個字符。對于選項C的“比較測試方法”是利用冗余系統(tǒng)的經(jīng)驗，對關鍵應用程序開發(fā)不同的版本，利用自動化工具對其輸岀進行比較。對于選項D的“正交數(shù)組測試方法”被應用于輸入域相對較

38、小但對窮舉測試而言又過大的問題。正交數(shù)組 測試對于發(fā)現(xiàn)與區(qū)域錯誤相關的錯誤特別有用。21. 某工程計劃如圖5-7所示，各個作業(yè)所需的天數(shù)如表 5-13所列，設該工程從第 0天開工，則作業(yè)I最 遲應在第天開工。表5-13各個作業(yè)所需天數(shù)表作業(yè)ABCDEFGHIJ所需天數(shù)87911845428*（分數(shù)：1.00 ）A.B. VC.D.解析：解析本試題解答時，可先將表5-13中各個作業(yè)所需的天數(shù)標注在圖5-7中。該工程的關鍵路徑應是從節(jié)點到節(jié)點各條路徑中作業(yè)總天數(shù)最多的路徑，即TTTT，因 此，該工程需要7+8+5+4=24天才能完成。關鍵路徑上的各作業(yè)（B、E、G H）的松弛時間為0（即最早開工時

39、間等于最遲開工時間），這些作業(yè)的開工時問必須分別確定為第 0天、第7天、第15天、第20天。如果每個作業(yè)按最遲時間開工（最壞打算），那么整個工程應按倒計數(shù)安排各個作業(yè)的開工時間。查表5-13知，作業(yè)J需要8天，因此作業(yè)J最遲應在第24-8=16天開工，而作業(yè) G最遲應在第15天開工。作業(yè)I的緊后作業(yè)有作業(yè) G和J，作業(yè)G和J必須在作業(yè)I結束后才能開工。因此，作業(yè)I最遲應在第15天結束，否則將影響作業(yè)G的開工。查表5-13知，作業(yè)I需要2天，因此，作業(yè)I最遲開工時間應在第13天。22. 質量控制非常重要，但是進行質量控制也需要一定的成本。可以降低質量控制的成本。A.使用抽樣統(tǒng)計B 進行過程分析C

40、.對全程進行監(jiān)督 D 進行質量審計（分數(shù)：1.00 ）B.C.D.解析：解析質量控制（QC）就是項目管理組的人員采取有效措施，監(jiān)督項目的具體實施結果，判斷他們是 否符合有關的項目質量標準，并確定消除產(chǎn)生不良結果原因的途徑?？梢?，進行質量控制是確保項目質量 得以完滿實現(xiàn)的過程。質量控制應貫穿于項目執(zhí)行的全過程。質量成本是指為了達到產(chǎn)品或服務質量而進行的全部工作所發(fā)生的所有成本。進行質量控制一定要注意成 本，使用抽樣統(tǒng)計可以降低質量控制的成本。23. 對00系統(tǒng)的技術度量的識別特征，Berard定義了導致特殊度量的特征。其中 抑制程序構件的操作細節(jié)，只有對訪問構件必須的信息被提供給其他希望訪問它的

41、構件。A.局部化B .封裝C .信息隱蔽D .繼承（分數(shù)： 1.00 ）A.B.C. VD.解析： 解析 Berard 定義了 5 個導致特殊度量的特征：局部化、封裝、信息隱蔽、繼承和對象抽象技術。 局部化是一個軟件特征，它指明信息在程序中被集中的方式。對于 00系統(tǒng)，封裝包含了類的責任 （包含其屬性和操作 ）以及類的狀態(tài) （由特定的屬性值定義 ）。 信息隱蔽抑制程序構件的操作細節(jié)，只有對訪問構件必須的信息被提供給其他希望訪問它的構件。 繼承是使某對象的責任能夠傳播到其他對象的機制，繼承出現(xiàn)在類層次的所有層面上。對象抽象技術使設計者能夠關注程序構件的本質細節(jié)，而無需考慮底層細節(jié)的機制。24.

42、在關于逆向工程 （reverse engineering） 的描述中，正確的是 。A. 從已經(jīng)安裝的軟件中提取設計規(guī)范，用以進行軟件開發(fā)B. 按照“輸出-處理-輸入”的順序設計軟件C. 用硬件來實現(xiàn)軟件的功能D. 根據(jù)軟件處理的對象來選擇開發(fā)語言和開發(fā)工具（分數(shù)： 1.00 ）A. VB.C.D.解析： 解析 逆向工程是軟件再生 （software rejuvenation） 的一種方法。軟件再生的 4 種基本方法是： 文檔重構。它對源代碼進行靜態(tài)分析，從而產(chǎn)生系統(tǒng)文檔，幫助維護人員理解和引用源代碼。 結構重組。它對源代碼進行重組，重新編寫為結構化的源代碼，使其復雜性有所降低。 逆向工程。它通

43、過對源代碼進行靜態(tài)分析得到系統(tǒng)規(guī)范和設計信息，并且提取出工程信息，例如模塊和 變量表、交叉引用表、數(shù)據(jù)接口表、測試路徑等。 再工程。它是逆向工程過程的擴展，根據(jù)逆向工程抽取的信息，在不改變原系統(tǒng)功能的前提下產(chǎn)生新的 系統(tǒng)源代碼。25. 某工程計劃如圖5-6所示，圖中標注了完成任務 AH所需的天數(shù)，其中虛線表示虛任務。經(jīng)評審后發(fā)現(xiàn)，任務D還可以縮短3天（即只需7天就能完成），則總工程可以縮短 天。*A. 0 B . 1 C . 2 D . 3（分數(shù):1.00）A.B. VC.D.解析：解析本試題的解答思路如下。 在圖5-6所示的工程網(wǎng)絡計劃圖中，虛線表示虛任務。虛任務是指具有不占時間、不消耗資源

44、的任務，該作業(yè)需要0天完成。它主要用于體現(xiàn)任務之間的某種銜接關系，即圖5-6中任務H必須在任務E、F都完成后才能開始。 評審前，圖5-6的關鍵路徑（最費時路徑）：-，共計需要29天 經(jīng)評審后，任務D可以縮短3天（即由原來的10天變?yōu)?天），此時，圖5-6的關鍵路徑改變?yōu)椋?-2-3-6-7 ，共需要28天。因此，在任務 D可以縮短3天的情況下，該工程需要28天才能完成。 可見，在任務D縮短3天的情況下，總工程只能縮短1天。26. 實施新舊信息系統(tǒng)轉換，采用 方式風險最小。A.直接轉換B 并行轉換C 分段轉換D 分塊轉換（分數(shù)：1.00 ）A.B. VC.D.解析：解析新舊信息系統(tǒng)之間的轉換有直接轉換、并行轉換和分段轉換，見表5-3。表5-3系統(tǒng)之間的轉換方式對比表轉 換 方 式描述備注直接 轉 換是指在確定新系統(tǒng)運行無誤時，立刻啟用新系統(tǒng)， 終止舊系統(tǒng)運行這種轉換方式對人員、設備費用很節(jié)省。這 種方式一般適用于一些處理過程不太復雜，數(shù) 據(jù)不太重要的場合并行 轉 換是指新舊系統(tǒng)并行工作一段時間，經(jīng)過一段時間的 考驗以后，新系統(tǒng)正式替代舊系統(tǒng)。對于較復雜的大型 系統(tǒng)