系統架構設計師 - 真題 - 選擇題真題分類彙總

0. 經驗

• 最後的英語題必定要作，而且作對，這個是比較有把握拿分的。要謹慎，看懂上下文真正的含義和意圖。
• 有的計算題太花時間，能夠先放一下，或者簡單演算、反推出一個答案，後面再慢慢驗證。
• 後面的題不涉及算法、計算等，有可能作的比較快
• 重點
  • ！！！貌似考的很均勻，大知識點都會照顧到。這樣反而更好，容易及格。
  • ！！！其實能夠倒着作！！！全部數學題、算法題最後作！！！
  • 按主題彙總頻率
    • 優先作的（簡單、傳統、比較有把握，按順序以下：）
      • 軟件架構設計及各類架構風格
        • 判斷是哪一種架構風格
        • 每一年3-5個題
      • 架構設計階段識別出的場景及相關的質量屬性
        • 每一年1個大題，含5個題。
        • 主要考察案例項目架構設計中識別出的是什麼質量屬性，可使用什麼方案。
        • 每一年連答案都不怎麼變！！！！！！！！！
      • 系統建模
        • 每一年2個題
      • 軟件工程（分析、設計、測試）
        • 每一年3-6個題
        • 設計模式
          • 每一年1個大題，含4個題。
          • 2個考察設計模式分類判斷，2個考察具體是什麼設計模式。
      • 系統配置與性能評價
        • 每一年1個題
      • 項目管理
        • 每一年4-7個題。
      • 法律法規
        • 每一年3個題。
      • 企業信息化戰略與實施
        • 每一年2-6個題
      • 英語閱讀
        • 每一年5個題
        • 即考察詞彙，也考察技術
    • 後作的（難的）
      • 數學與經濟管理
        • 每一年2個題
        • 題目有可能有點難，先掃一眼，不行就放後面作

1. 計算機組成與體系結構

• 流水線
  • （2017）某計算機系統採用5 級流水線結構執行指令， 設每條指令的執行由取指令(2 Δt )、分析指令(1Δt )、取操做數(3Δt )、運算(1Δt )和寫回結果(2Δt ) 組成， 並分別用5 個子部件完成，該流水線的最大吞吐率爲（ 1/3Δt） ；若連續向流水線輸入10 條指令，則該流水線的加速比爲（5:2）
    • n/(2t+1t+3t+1t+2t+(n-1)*3t)=n/(6t+3nt)，n無窮大時近似爲1/3Δt
  • （2016）某指令流水線由5段組成（t，3t，t，2t，t），連續輸入100 條指令時的吞吐率爲（100/305t）。
• 校驗與糾錯
  • （2018）若信息碼字爲111000110，生成多項式G(x)=x5+x3+x+1，則計算出的CRC校驗碼爲（11001）。
• CPU
  • （2018）目前處理器市場中存在CPU和DSP兩種類型處理器，分別用於不一樣場景，這兩種處理器具備不一樣的體系結構，DSP採用（哈佛結構）。
  • （2018）CPU的頻率有主頻、倍頻和外頻。某處理器外頻是200MHz，倍頻是13，該款處理器的主頻是（2.6GHz）。
• 總線
  • （2018）如下關於串行總線的說法中，正確的是（串行總線傳輸的波特率是總線初始化時預先定義好的，使用中不可改變）。
  • （2015）下列說法中正確的是（半雙工總線可在兩個方向上輪流傳輸信息，全雙工總線可在兩個方向上同時傳輸信息）。
• 存儲
  • 磁盤
    • （2018）在磁盤調度管理中，應先進行移臂調度，再進行旋轉調度。假設磁盤移動臂位於21號柱面上，進程的請求序列以下表所示。若是採用最短移臂調度算法，那麼系統的響應序列應爲（283571469）
    • （2017）在磁盤上存儲數據的排列方式會影響I/O 服務的總時間。假設每磁道劃分紅10 個物理塊，每塊存放1 個邏輯記錄。邏輯記錄R1，R2， ...， RI0存放在同一個磁道上， 記錄的安排順序以下表所示......;假定磁盤的旋轉速度爲30ms/周，磁頭當前處在R1 的開始處。若系統順序處理這些記錄，使用單緩衝區，每一個記錄處理時間爲6ms，則處理這10 個記錄的最長時間爲（306ms） ;若對信息存儲進行優化分佈後，處理10 個記錄的最少時間爲（90ms）
      • 本題後面一問要求計算處理10 個記錄的最少時間。其實只要把記錄間隔存放，就能達到這個目標。在物理塊1 中存放R1，在物理存4 中存放R2，在物理塊7中存放R3，依此類推，這樣能夠作到每條記錄的讀取與處理時間之和均爲9ms，因此處理10 條記錄一共90ms。
    • （2015）假若有3塊容量是80G的硬盤作RAID 5陣列，則這個RAID 5的容量是（160G）；而若是有2塊80G的盤和1塊40G的盤，此時RAID 5的容量是（80G）。
    • （2014）計算機採用分級存儲體系的主要目的是爲了（解決存儲的容量、價格和速度之間的矛盾）。
  • 雙緩衝與單緩衝
    • （2016）某計算機系統輸入/ 輸出採用雙緩衝工做方式，假設磁盤塊與緩衝區大小相同，每一個盤塊讀入緩衝區的時間T 爲10 μs，緩衝區送用戶區的時間M 爲6μs，系統對每一個磁盤塊數據韻處理時間C 爲2μs。若用戶須要將大小爲10 個磁盤塊的Docl 文件逐塊從磁盤讀入緩衝區，並送用戶區進行處理，那麼採用雙緩衝須要花費的時間爲10*10+（6+2）=108μs，比使用單緩衝節約了(10+6)*10+2-108=54μs 時間。
  • 文件系統
    • （2018）某文件系統採用多級索引結構， 若磁盤塊的大小爲4K字節，每一個塊號需佔4字節，那麼採用二級索引結構時的文件最大長度可佔用（1024×1024）個物理塊。
    • （2016）某文件系統文件存儲採用文件索引節點法。假設文件索引節點中有8 個地址項iaddr[0] ～ iaddr[7] ，每一個地址項大小爲4 字節，其中地址項iaddr[0] ～iaddr[5] 爲直接地址索引， iaddr[6] 是一級間接地址索引， iaddr[7] 是二級間接地址索引，磁盤索引塊和磁盤數據塊大小均爲4KB。該文件系統可表示的單個文件最大長度是（4198424）KB。若要訪問iclsClient.dll 文件的邏輯塊號分別爲六、520和1030 ，則系統應分別採用（一級間接地址索引、一級間接地址索引和二級間接地址索引）。
      • 直接地址索引可存0～5 共6 個地址； 每一個地址項大小爲4 字節，磁盤索引塊大小4KB，故一級間接地址索引可存4*1024/4=1024 個地址； 二級間接地址索引可存1024*1024=1048576 個地址，磁盤數據塊大小均爲4KB，因此可表示的單個文件最大長度是(6+1024+1048576)*4=4198424KB 。
      • 邏輯塊號爲6 即iaddr[6] 是一級間接地址索引， 6<520<1024+6 即邏輯塊號520 也是一級間接地址索引，邏輯塊號是從0 開始編號的，所以1030 已是二級間接地址索引。
    • （2014）某文件系統文件存儲採用文件索引節點法。假設磁盤索引塊和磁盤數據塊大小均爲1KB，每一個文件的索引節點中有8個地址項iaddr[0]～iaddr[7]，每一個地址項大小爲4字節，其中iaddr[0]～iaddr[5]爲直接地址索引，iaddr[6]是一級間接地址索引，iaddr[7]是二級間接地址索引。若是要訪問icwutil.dll文件的邏輯塊號分別爲0、260和518，則系統應分別採用（3）。該文件系統可表示的單個文件最大長度是（4）KB。
• DMA（直接存儲器訪問）
  • （2017）DMA （直接存儲器訪問）工做方式是在（主存與外設）之間創建起直接的數據通路。
• RISC（精簡指令系統計算機）與CISC（複雜指令系統計算機）
  • （2017）RISC( 精簡指令系統計算機）的特色不包括：（尋址方式儘可能豐富，指令功能儘量強）。
• 嵌入式系統
  • （2018）嵌入式系統設計通常要考慮低功耗， 軟件設計也要考慮低功耗設計，軟件低功耗設計通常採用（編譯優化技術、軟硬件協同設計和算法優化）。
  • （2016）在嵌入式系統的存儲部件中，存取速度最快的是（寄存器組）。
  • （2015）在嵌入式操做系統中，板級支持包BSP做爲對硬件的抽象，實現了（硬件有關性，操做系統無關性）。
    • 在嵌入式系統中，板級支持包Board Support Package(簡稱BSP)是對硬件抽象層的實現，是介於主板的硬件和操做系統驅動程序之間的一層，爲整個軟件系統提供底層硬件支持，是介於底層硬件和上層軟件之間的底層軟件開發包，它主要的功能是給上層提供統一接口，同時屏蔽各類硬件底層的差別，以及提供操做系統的驅動及硬件驅動。簡單地說，就是BSP包含了全部與硬件有關的代碼，爲操做系統提供了硬件平臺無關性。
  • （2015）如下描述中，（用於特定領域，不須要支持多任務）不是嵌入式操做系統的特色。
  • （2015）嵌入式軟件設計須要考慮（硬件無關性）以保障軟件良好的可移植性。
  • （2014）如下關於嵌入式數據庫管理系統的描述不正確的是（嵌入式數據庫管理系統通常不支持多線程併發操做）。
  • （2014）如下嵌入式處理器類型中不具有內存管理單元(MMU)的是（Cortex-M3），嵌入式操做系統（uC/OS-II）能夠運行在它上面。

2. 操做系統

• 進程管理
  • （2018）某計算機系統中的進程管理採用三態模型，那麼下圖所示的PCB（進程控制塊）的組織方式採用（索引方式），圖中（有2個運行進程，3個就緒進程，4個阻塞進程）。
  • （2017）前趨圖(Precedence Graph) 是一個有向無環圖，記爲：→ ={（Pi，Pj ）|Pi must complete before Pj may strat}。假設系統中進程P={P1，P2，P3，P4，P5，P6，P7，P8}，且進程的前驅圖以下：......那麼前驅圖可記爲：（→={（P1,P2),(P1,P3),(P1,P4),(P2,P5（),P3,P5),(P4,P6),(P5,P7),(P6,P7),(P7,P8)}）。
  • （2015）某航空公司機票銷售系統有n個售票點，該系統爲每一個售票點建立一個進程Pi（i=1，2，…，n）管理機票銷售。假設Tj（j=1，2，…，m）單元存放某日某航班的機票剩餘票數，Temp爲Pi進程的臨時工做單元，x爲某用戶的訂票張數。初始化時系統應將信號量S賦值爲（1）。Pi進程的工做流程以下圖所示，若用P操做和V操做實現進程間的同步與互斥，則圖中空(a)，空(b)和空(c)處應分別填入（P(S),V(S)和V(S)）。
  • （2015）假設系統採用段式存儲管理方法，進程P的段表以下所示。邏輯地址（(0,810)和(4,120)）不能轉換爲對應的物理地址；不能轉換爲對應的物理地址的緣由是進行（邏輯地址到物理地址轉換時地址越界）。
    • 段內地址810大於段長，故地址越界
  • （2014）某計算機系統中有一個CPU、一臺輸入設備和一臺輸出設備，假設系統中有四個做業T一、T二、T3和T4，系統採用優先級調度，且T1的優先級>T2的優先級>T3的優先級>T4的優先級。每一個做業具備三個程序段：輸入Ii、計算Ci和輸出Pi(i=1,2,3,4)，其執行順序爲Ii→Ci→Pi。這四個做業各程序段併發執行的前驅圖以下所示。圖中①、②、③分別爲（I二、I三、C2），④、⑤、⑥分別爲（C四、P三、P4）。
• 死鎖與活鎖
  • （2015）若系統中存在n個等待事務Ti（i=0,1，2，…，n-1），其中：T0正等待被T1鎖住的數據項A1，T1正等待被T2鎖住的數據項A2，…，Ti正等待被Ti+1鎖住的數據項Ai+1，…，Tn-1正等待被T0鎖住的數據項A0，則系統處於（死鎖）狀態。
• 實時操做系統（RTOS）
  • （2017）如下關於RTOS （實時操做系統）的敘述中，不正確的是（RTOS 不能針對硬件變化進行結構與功能上的配置及裁剪）。
  • （2016）實時操做系統（RTOS）內核與應用程序之間的接口稱爲（API）。

3. 數據庫系統

• 關係模式及關係運算（演算）
  • （2018）
  • （2017）
  • （2016）給定關係模式R（A，B，C，D，E）、S（D，E，F，G）和π1,2,4,6 （R? S），通過天然鏈接和投影運算後的屬性列數分別爲（7和4）。
  • （2015）若關係R、S以下圖所示，則關係R與S進行天然鏈接運算後的元組個數和屬性列數分別爲（3和4）；關係代數表達式π1,4(σ3=6(R×S))與關係代數表達式（πA,R,D(σR.C=S.D(R×S))）等價。
  • （2014）設關係模式R(U,F)，其中U爲屬性集，F是U上的一組函數依賴，那麼函數依賴的公理系統（Armstrong公理系統）中的合併規則是指（若A→B，A→C，則A→BC）爲F所蘊涵。
  • （2014）若關係模式R和S分別爲：R(A,B,C,D)、S(B,C,E,F)，則關係R與S天然聯結運算後的屬性列有（6）個，與表達方式π1,3,5,6（σ3<6（RS））等價的SQL語句爲：SELECT （A,R.C,E,F） FROM R, S WHERE （R.B=S.B AND R.C=S.C AND R.C<S.F）
• 碼、函數依賴與範式
  • （2017）給定關係模式R(U，F)，其中: 屬性集U={A1 ,A2,A3,A4,A5,A6}， 函數依賴集F={A1→A2, A1→A3, A3→A4, A1A5→A6}。關係模式R 的候選碼爲（A1 A5），因爲R存在非主屬性對碼的部分函數依賴，因此R屬於（1NF）。
  • （2016）給定關係R（A1，A2，A3，A4，A5）上的函數依賴集F={A1→A2A5，A2→A3A4，A3→A2}，R 的候選關鍵字爲（A1）。函數依賴（A3→A2A4）∈ F+ 。
• 數據倉庫
  • （2018）數據倉庫中，數據（相對穩定性）是指數據一旦進入數據倉庫後，將被長期保留並按期加載和刷新，能夠進行各類查詢操做，但不多對數據進行修改和刪除操做。
• 靜態轉儲與動態轉儲
  • （2016）假設某證券公司的股票交易系統中有正在運行的事務，此時，若要轉儲該交易系統數據庫中的所有數據，則應採用（動態全局轉儲）方式。
• 分佈式數據庫
  • （2017）分佈式數據庫兩階段提交協議中的兩個階段是指（表決階段、執行階段）。
  • （2015）在分佈式數據庫中包括分片透明、複製透明、位置透明和邏輯透明等基本概念，其中：（邏輯透明）是指局部數據模型透明，即用戶或應用程序無需知道局部場地使用的是哪一種數據模型。

4. 計算機網絡

• 分層
  • （2014）下列安全協議中（HTTPS）是應用層安全協議。
• DiffServ
  • （2016）IETF 定義的區分服務（ DiffServ ）模型要求每一個IP 分組都要根據IPv4協議頭中的（服務類型）字段加上一個DS 碼點，而後內部路由器根據DS 碼點的值對分組進行調度和轉發。
  • （2014）IETF定義的集成服務(IntServ)把Internet服務分紅了三種服務質量不一樣的類型，這三種服務不包括（突發式服務：若是有富餘的帶寬，網絡保證知足服務質量的需求）。
• IPv6
  • （2016）在IPv6 無狀態自動配置過程當中，主機將其（MAC 地址）附加在地址前綴11111110 10 以後，產生一個鏈路本地地址。
  • （2015）如下關於IPv6的論述中，正確的是（IPv6的地址長度爲128比特）。
• 管理距離
  • （2016）若是管理距離爲15 ，則（該路由信息比較可靠）。
• DNS
  • （2018）在客戶機上運行nslookup查詢某服務器名稱時能解析出IP地址，查詢IP地址時卻不能解析出服務器名稱，解決這一問題的方法是（爲該服務器建立PTR記錄）。
• DHCP
  • （2018）若是發送給DHCP客戶端的地址已經被其餘DHCP客戶端使用，客戶端會向服務器發送（DhcpDecline）信息包拒絕接受已經分配的地址信息。
• 協議
  • （2017）下面可提供安全電子郵件服務的是（S/MIME）。
• 網絡規劃/設計
  • （2017）在網絡規劃中， 政府內外網之間應該部署網絡安全防禦設備。在下圖中部署的設備A 是（網閘），對設備A 的做用描述錯誤的是（採用專用硬件控制技術保證內外網的實時鏈接）。
  • （2017）網絡邏輯結構設計的內容不包括（用戶培訓計劃）。
  • （2017）某企業經過一臺路由器上聯總部， 下聯4 個分支結構， 設計人員分配給下級機構一個連續的地址空間， 採用一個子網或者超網段表示。這樣作的主要做用是（層次化路由選擇）。
  • （2014）結構化佈線系統分爲六個子系統，其中水平子系統（鏈接了幹線子系統和工做區子系統）。
  • （2014）按照網絡分層設計模型，一般把局域網設計爲3層，即核心層、匯聚層和接入層，如下關於分層網絡功能的描述中，不正確的是（核心層設備負責數據包過濾、策略路由等功能）。

5. 軟件架構（體系結構）設計

• 概念
  • （2014）某公司欲開發一個用於分佈式登陸的服務端程序，使用面向鏈接的TCP協議併發地處理多客戶端登陸請求。用戶要求該服務端程序運行在Linux、Solaris和WindowsNT等多種操做系統平臺之上，而不一樣的操做系統的相關API函數和數據都有所不一樣。針對這種狀況，公司的架構師決定採用「包裝器外觀(Wrapper Facade)」架構模式解決操做系統的差別問題。具體來講，服務端程序應該在包裝器外觀的實例上調用須要的方法，而後將請求和請求的參數發送給（操做系統API函數），調用成功後將結果返回。使用該模式（提升了底層代碼訪問的一致性，但下降了服務端程序的調用性能）。
• 演化
• 架構評估
  • 評估方法
    • （2014）識別風險、非風險、敏感點和權衡點是進行軟件架構評估的重要過程。「改變業務數據編碼方式會對系統的性能和安全性產生影響」是對（權衡點）的描述，「假設用戶請求的頻率爲每秒1個，業務處理時間小於30毫秒，則將請求響應時間設定爲1秒鐘是能夠接受的」是對（非風險）的描述。
      • 風險是某個存在問題的架構設計決策，可能會致使問題：非風險與風險相對，是良好的架構設計決策；
      • 敏感點是一個或多個構件的特性；權衡點是影響多個質量屬性的特性，是多個質量屬性的敏感點。
  • 軟件系統架構評估中所廣泛關注的（架構設計過程當中識別出的）質量屬性
    • （2018）某公司欲開發一我的員管理系統，在架構設計階段，公司的架構師識別出3個核心質量屬性場景。其中「管理系統遭遇斷電後，可以在15秒內自動切換至備用系統並恢復正常運行」主要與（可用性）質量屬性相關，一般可採用（主動冗餘）架構策略實現該屬性；「系統正常運行時，人員信息查詢請求應該在2秒內返回結果」主要與（性能）質量屬性相關，一般可採用（資源調度）架構策略實現該屬性；「系統須要對用戶的操做狀況進行記錄，並對全部針對系統的惡意操做行爲進行報警和記錄」主要與（安全性）質量屬性相關，一般可採用（追蹤審計）架構策略實現該屬性。
    • （2017）某公司欲開發一個在線交易網站， 在架構設計階段， 公司的架構師識別出3個核心質量屬性場景。其中"網站正常運行時， 用戶發起的交易請求應該在3 秒內完成" 主要與（性能）質量屬性相關，一般可採用（資源調度）架構策略實現該屬性; "在線交易主站宕機後，可以在3 秒內自動切換至備用站點並恢復正常運行"主要與（可用性）質量屬性相關，一般可採用（心跳）架構策略實現該屬性; "系統應該具有必定的安全保護措施， 從而可以抵擋惡意的入侵破壞行爲，並對全部針對網站的攻擊行爲進行報警和記錄"主要與（安全性）質量屬性相關，一般可採用（追蹤審計）架構策略實現該屬性。
    • （2016）某公司欲開發一個智能機器人系統， 在架構設計階段， 公司的架構師識別出3 個核心質量屬性場景。其中「機器人系統主電源斷電後，可以在10 秒內自動啓動備用電源並進行切換，恢復正常運行」主要與（可用性）質量屬性相關，一般可採用（主動冗餘）架構策略實現該屬性；「機器人在正常運動過程當中若是發現前方2 米內有人或者障礙物，應在1 秒內中止並在2 秒內選擇一條新的運行路徑」主要與（互操做性）質量屬性相關，一般可採用（資源調度）架構策略實現該屬性；「對機器人的遠程控制命令應該進行加密，從而可以抵擋惡意的入侵破壞行爲，並對攻擊進行報警和記錄」主要與（安全性）質量屬性相關，一般可採用（追蹤審計）架構策略實現該屬性。
    • （2015）某公司欲開發一個網上商城系統，在架構設計階段，公司的架構師識別出3個核心質量屬性場景，其中「系統主站斷電後，可以在2分鐘內自動切換到備用站點，並恢復正常運行」主要與（可用性）質量屬性相關，一般可採用（主動冗餘）架構策略實現該屬性；「在併發用戶數不超過1000人時，用戶的交易請求應該在0.5s內完成」主要與（性能）質量屬性相關一般可採用（資源調度）架構策略實現該屬性；「系統應該可以抵擋惡意用戶的入侵行爲，並進行報警和記錄」主要與（安全性）質量屬性相關，一般可採用（追蹤審計）架構策略實現該屬性。
    • （2014）某公司欲開發一個在線交易系統，在架構設計階段，公司的架構師識別出3個核心質量屬性場景。其中「當系統面臨斷電故障後，須要在1小時內切換至備份站點並恢復正常運行」主要與（可用性）質量屬性相關，一般可採用（心跳）架構策略實現該屬性；「在併發用戶數量爲1000人時，用戶的交易請求須要在0.5秒內獲得響應」主要與（性能）質量屬性相關，一般可採用（資源調度）架構策略實現該屬性；「對系統的消息中間件進行替換時，替換工做須要在5人/月內完成」主要與（可修改性）質量屬性相關，一般可採用（接口-實現分離）架構策略實現該屬性。
• 風格
  • （2018）某公司欲開發一個大型多人即時戰略遊戲，遊戲設計的目標之一是可以支持玩家自行建立戰役地圖，定義遊戲對象的行爲和對象之間的關係。針對該需求，公司應該採用（解釋器）架構風格最爲合適。在架構設計階段，公司的架構師識別出2個核心質量屬性場景。其中，「在併發用戶數量爲10000人時，用戶的請求須要在1秒內獲得響應」主要與（性能）質量屬性相關；「對遊戲系統進行二次開發的時間不超過3個月」主要與（可修改性）質量屬性相關。
  • （2018）在倉庫風格中，有兩種不一樣的構件，其中，（中央數據結構）說明當前狀態，（獨立構件）在中央數據存儲上執行。
  • （2017）軟件架構風格描述某一特定領域中的系統組織方式和慣用模式，反映了領域中衆多系統所共有的（結構和語義）特徵。對於語音識別、知識推理等問題複雜、解空間很大、求解過程不肯定的這一類軟件系統，一般會採用（黑板）架構風格。對於因數據輸入某個構件，通過內部處理，產生數據輸出的系統，一般會採用（管道-過濾器）架構風格。
  • （2017）某公司擬開發一個VIP管理系統，系統須要根據不一樣商場活動，不按期更新VIP會員的審覈標準和VIP折扣系統。針對上述需求，採用（規則系統）架構風格最爲合適。
  • （2017）某公司擬開發一個新聞系統， 該系統可根據用戶的註冊興趣， 向用戶推送其感興趣的新聞內容，該系統應該採用（事件驅動系統）架構風格最爲合適。
  • （2017）系統中的構件和鏈接件都有一個頂部和一個底部，構件的頂部應鏈接到某鏈接件的底部， 構件的底部則應鏈接到某鏈接的頂部， 構件和構件之間不容許直接鏈接，鏈接件直接鏈接時， 必須由其中一個的底部鏈接到另外一個的頂部。上述構件和鏈接件的組織規則描述的是（C2）架構風格。
  • （2016）（C2）架構風格能夠歸納爲經過鏈接件綁定在一塊兒按照一組規則運做的並行構件。
  • （2016）某公司擬爲某種新型可編程機器人開發相應的編譯器。該編譯過程包括詞法分析、語法分析、語義分析和代碼生成四個階段， 每一個階段產生的結果做爲下一個階段的輸入， 且需獨立存儲。針對上述描述， 該集成開發環境應採用（管道—過濾器）架構風格最爲合適。
  • （2016）軟件架構風格是描述某—特定應用領域中系統組織方式的慣用模式。一個體繫結構定義了—個詞彙表和一組（約束）。架構風格反映領域中衆多系統所共有的結構和（語義特徵）。
  • （2016）某公司擬開發一個掃地機器人。機器人的控制者首先定義清潔流程和流程中任務之間的關係， 機器人接受任務後， 須要響應外界環境中觸發的一些突發事件，根據自身狀態進行動態調整，最終自動完成任務。針對上述需求，該機器人應該採用（規則系統）架構風格最爲合適。
  • （2016）某企業內部現有的主要業務功能已封裝成爲Web 服務。爲了拓展業務範圍，須要將現有的業務功能進行多種組合， 造成新的業務功能。針對業務靈活組合這一要求，採用（解釋器）架構風格最爲合適。
  • （2015）軟件架構風格是描述某一特定應用領域中系統組織方式的慣用模式。架構風格反映領域中衆多系統所共育的結構和（語義特性），強調對架構（設計）的重用。
  • （2015）某公司擬開發一個地面清潔機器人。機器人的控制者首先定義清潔任務和任務之間的關係，機器人接受任務後，須要響應外界環境中觸發的一些突發事件，根據自身狀態進行動態調整，最終自動完成任務。針對上述需求，該機器人應該採用（規則系統）架構風格最爲合適。
  • （2015）某公司擬開發一個語音識別系統，其語音識別的主要過程包括分割原始語音信號、識別音素、產生候選詞、斷定語法片段、提供語義解釋等，每一個過程都須要進行基於先驗知識的條件判斷並進行相應的識別動做。針對該系統的特色，採用（黑板）架構風格最爲合適。
  • （2015）某公司擬開發了個轎車巡航定速系統，系統須要持續測量車輛當前的實時速度，並根據設定的指望速度啓動控制轎車的油門和剎車。針對上述需求，採用（過程控制）架構風格最爲合適。
  • （2015）某公司擬開發一套在線遊戲系統，該系統的設計目標之一是支持用戶自行定義遊戲對象屬性，行爲和對象之間的交互關係。爲了實現上述目標，公司應該採用（解釋器）架構風格最爲合適。
  • （2015）某公司爲其研發的硬件產品設計實現了一種特定的編程語言，爲了方便開發者進行軟件開發，公司擬開發一套針對該編程語言的集成開發環境，包括代碼編輯、語法高亮、代碼編譯、運行調試等功能。針對上述描述，該集成開發環境應採用（數據倉儲）架構風格最爲合適。
  • （2014）軟件架構風格描述某一特定領域中的系統組織方式和慣用模式，反映了領域中衆多系統所共有的（結構和語義）特徵。對於語音識別、知識推理等問題複雜、解空間很大、求解過程不肯定的這一類軟件系統。一般會採用（黑板）架構風格。
  • 具體分類
    • 面向服務架構（SOA）
      • （2016）面向服務系統構建過程當中，（SOAP（Simple Object Access Protocol ））用於實現Web 服務的遠程調用，（BPEL（Business Process Execution Language ））用來將分散的、功能單一的Web 服務組織成一個複雜的有機應用。
    • 面向構件的編程
      • （2018）構件組裝成軟件系統的過程能夠分爲三個不一樣的層次：（定製、集成和擴展）。
      • （2017）軟件構件是一個獨立可部署的軟件單元， 與程序設計中的對象不一樣， 構件（利用工廠方法(如構造函數）來建立本身的實例）。
      • （2017）爲了使一個接口的規範和實現該接口的構件獲得普遍應用，須要實現接口的標準化。接口標準化是對（接口中消息模式、格式和協議）的標準化。
      • （2017）OMG接口定義語言IDL 文件包含了六種不一樣的元素， （值類型）是一個IDL 文件最核心的內容，（模塊定義）將映射爲Java 語言中的包(Package) 或c++語言中的命名空間(Namespace)。
      • （2016）面向構件的編程(Component Oriented Programming ，COP)關注於如何支持創建面向構件的解決方案。面向構件的編程所須要的基本支持包括（多態性、模塊封裝性、後期綁定和裝載、安全性）。
      • （2016）關於構件的描述，正確的是（構件包含了一組須要同時部署的原子構件）。
      • CORBA
        • （2018）CORBA服務端構件模型中，（伺服對象（Servant））是CORBA對象的真正實現，負責完成客戶端請求。
        • （2016）CORBA 構件模型中， （可移植對象適配器POA）的做用是在底層傳輸平臺與接收調用並返回結果的對象實現之間進行協調，（伺服對象Servant）是最終完成客戶請求的服務對象實現。
      • Java
        • （2018）J2EE應用系統支持五種不一樣類型的構件模型，包括（Applet、Servlet、JSP、EJB、Application Client）。
        • （2018）EJB是企業級Java構件，用於開發和部署多層結構的、分佈式的、面向對象的Java應用系統。其中，（會話型構件）負責完成服務端與客戶端的交互；（實體型構件）用於數據持久化來簡化數據庫開發工做；（消息驅動構件）主要用來處理併發和異步訪問操做。
        • （2016）基於JavaEE平臺的基礎功能服務構建應用系統時， （JCA、JMS 和JavaIDL）可用來集成遺產系統。
    • 微服務架構
    • 面向對象架構風格
    • 黑板系統
    • 管道-過濾器
    • 事件驅動系統
    • C2架構/體系結構風格
    • 解釋器
    • 倉庫風格/數據倉儲
    • 過程控制
    • 規則系統
    • 無服務器架構
• 體系結構文檔化過程
  • （2017）體系結構文檔化有助於輔助系統分析人員和程序員去實現體系結構。體系結構文檔化過程的主要輸出包括（體系結構規格說明、測試體系結構需求的質量設計說明書）。
• 特定領域軟件架構（Domain Specific Software Architecture, DSSA）
  • （2018）特定領域軟件架構（Domain Specific Software Architecture, DSSA）的基本活動包括領域分析、領域設計和領域實現。其中，領域分析的主要目的是得到領域模型。領域設計的主要目標是得到（特定領域軟件架構）。領域實現是爲了（開發和組織可重用信息，對基礎軟件架構進行實現）。
  • （2016）SSA 是在一個特定應用領域中爲一組應用提供組織結構參考的軟件體系結構，參與DSSA 的人員能夠劃分爲4 種角色，包括領域專家、領域設計人員、領域實現人員和（領域分析師），其基本活動包括領域分析、領域設計和（領域實現）。
  • （2015）特定領域軟件架構（Domain Specific Software Architecture, DSSA）以一個特定問題領域爲對象，造成由領域參考模型，參考需求，（參考架構）等組成的開發基礎架構，支持一個特定領域中多個應用的生成。DSSA的基本活動包括領域分析、領域設計和領域實現。其中領域分析的主要目的是得到（領域模型），從而描述領域中系統之間共同的需求，即領域需求；領域設計的主要目標是得到（特定領域軟件架構），從而描述領域模型中表示需求的解決方案；領域實現的主要目標是開發和組織可重用信息，並實現基礎軟件架構。
  • （2014）特定領域軟件架構(Domain Specific Software Architecture, DSSA)是在一個特定應用領域中，爲一組應用提供組織結構參考的標準軟件體系結構。參加DSSA的人員能夠劃分爲多種角色，其中（領域分析者）的任務是控制整個領域分析過程，進行知識獲取，將獲取的知識組織到領域模型中；（領域設計者）的任務是根據領域模型和現有系統開發出DSSA，並對DSSA的準確性和一致性進行驗證。
• 架構權衡分析方法(Architecture Tradeoff Analysis Method, ATAM)
  • （2018）體系結構權衡分析方法（Architecture Tradeoff Analysis Method，ATAM）包含4個主要的活動領域，分別是場景和需求收集、體系結構視圖和場景實現、（屬性模型構造和分析） 、折中。基於場景的架構分析方法（Scenarios-based Architecture Analysis Method， SAAM）的主要輸入是問題描述、需求聲明和（體系結構描述）。
  • （2015）架構權衡分析方法(Architecture Tradeoff Analysis Method, ATAM)是在基於場景的架構分析方法（Scenarios-based Architecture Analysis Method, SAAM）基礎之上發展起來的，主要包括場景和需求收集、（架構視圖和場景實現），屬性模型構造和分析，屬性模型折中等四個階段。ATAM方法要求在系統開發以前，首先對這些質量屬性進行（評價）和折中。
  • （2014）體系結構權衡分析方法(Architecture Tradeoff Analysis Method, ATAM)是一種常見的系統架構評估框架，該框架主要關注系統的（需求說明），針對性能（架構描述）安全性和可修改性，在系統開發以前進行分析、評價與折中。
• 其餘
  • （2018）某公司欲開發一個大型多人即時戰略遊戲，遊戲設計的目標之一是可以支持玩家自行建立戰役地圖，定義遊戲對象的行爲和對象之間的關係。針對該需求，公司應該採用（解釋器）架構風格最爲合適。在架構設計階段，公司的架構師識別出2個核心質量屬性場景。其中，「在併發用戶數量爲10000人時，用戶的請求須要在1秒內獲得響應」主要與（性能）質量屬性相關；「對遊戲系統進行二次開發的時間不超過3個月」主要與（可修改性）質量屬性相關。
  • （2017）在基於體系結構的軟件設計方法中， 採用（視角與視圖）來描述軟件架構， 採用（用例）但來描述功能需求，採用（質量場景）來描述質量需求。
  • （2016）（可變性）不屬於可修改性考慮的內容。
  • （2016）處理流程設計是系統設計的重要內容。如下關於處理流程設計工具的敘述中，不正確的是（程序流程圖（PFD）用於描速系統中每一個模塊的輸入，輸出和數據加工）。
  • （2015）軟件架構是下降成本、改進質量、按時和按需交付產品的關鍵因素。軟件架構設計需知足系統的（質量屬性），如性能、安全性和可修改性等，並可以指導設計人員和實現人員的工做。
  • （2015）架構描述語言(Architecture Description Language，ADL）是一種爲明確說明軟件系統的概念架構和對這些概念架構建模提供功能的語言。ADL主要包括如下組成部分：組件、組件接口、（鏈接件）和架構配置。
  • （2015）基於架構的軟件開發(Architecture Based Software Development，ABSD)強調由商業、質量和功能需求的組合驅動軟件架構設計。它強調採用（視角與視圖）描述軟件架構，用（用例與質量場景）來描述需求。
  • （2015）軟件架構設計包括提出架構模型，產生架構設計和進行設計評審等活動，是一個迭代的過程。架構設計主要關注軟件組件的結構、屬性和（交互做用），並經過多種（視圖）全面描述特定系統的架構。
  • （2015）如下關於軟件架構風格與系統性能的關係敘述中，錯誤的是（採用面向對象架構風格的系統，能夠經過引入對象管理層提升系統性能）。
    • 能夠經過減小功能調用層次提升系統性能。
  • （2014）在對一個軟件系統的架構進行設計與確認以後，須要進行架構複審。架構複審的目的是爲了標識潛在的風險，及早發現架構設計中的缺陷和錯誤。在架構複審過程電，主要由（用戶表明與領域專家）決定架構是否知足需求、質量需求是否在設計中獲得體現。
  • （2014）將系統需求模型轉換爲架構模型是軟件系統需求分析階段的一項重要工做，如下描述中，（如何採用表格或用例映射保證轉換的可追蹤性）是在轉換過程當中須要關注的問題。
  • （2014）如下關於軟件架構設計重要性的描述，（軟件架構設計可以幫助架構師更好地捕獲和細化系統需求）是錯誤的。
  • （2014）在軟件的使用過程當中，用戶每每會對軟件提出新的功能與性能要求。爲了知足這些要求，須要修改或再開發軟件。在這種狀況下進行的維護活動稱爲（完善性維護）。
  • （2014）下列關於聯合需求計劃(Joint Requirement Planning, JRP)的敘述中，不正確的是（JRP的主要目的是對需求進行分析和驗證）。
    • JRP是一個經過高度組織的羣體會議來分析企業內的問題並獲取需求的過程，它是聯合應用開發（JAD)的-部分。JRP的主要意圖是收集需求，而不是對需求進行分析和驗證。
    • （2014）系統建議方案中不該該包含的內容是（系統詳細設計方案）。

6. 系統建模

• 結構化程序設計
  • （2017）結構化程序設計採用自頂向下、逐步求精及模塊化的程序設計方法， 經過（順序、分支和循環）三種基本的控制結構能夠構造出任何單入口單出口的程序。
  • （2014）在結構化分析方法中，用（DFD）表示功能模型，用（狀態轉換圖）表示行爲模型。
• 面向對象分析與設計
  • 軟件架構建模技術 - "4+1"視圖模型
    • （2018）體系結構模型的多視圖表示是從不一樣的視角描述特定系統的體系結構。著名的4+1模型支持從（邏輯視圖、開發視圖、物理視圖、進程視圖、統一的場景）描述系統體系結構。
    • （2014）「4+1」視圖主要用於描述系統邏輯架構，最先由Philippe Kruchten於1995年提出。其中（邏輯）視圖用於描述對象模型，並說明系統應該爲用戶提供哪些服務。當採用面向對象的設計方法描述對象模型時，一般使用（類圖）表達類的內部屬性和行爲，以及類集合之間的交互關係；採用（狀態圖）定義對象的內部行爲。
    • （2014）在UML提供的系統視圖中，（進程視圖）是邏輯視圖的一次執行實例，描述了併發與同步結構；（用例視圖）是最基本的需求分析模型。
    • （2017）面向對象的分析模型主要由頂層架構圖、用例與用例圖和（領域概念模型）構成：設計模型則包含以（包圖）表示的軟件體系機構圖、以交互圖表示的用例實現圖、完整精確的類圖、描述複雜對象的（狀態圖）和用以描述流程化處理過程的活動圖等。
    • （2016）面向對象的分析模型主要由（頂層架構圖）、用例與用例圖、領域概念模型構成；設計模型則包含以包圖表示的軟件體系結構圖、以交互圖表示的（用例實現圖）、完整精確的類圖、針對複雜對象的狀態圖和描述流程化處理過程的（活動圖）等。
    • （2015）用例（use case）用來描述系統對事件作出響應時所採起的行動。用例之間是具備相關性的。在一個會員管理系統中，會員註冊時能夠採用電話和郵件兩種方式。用例「會員註冊」和「電話註冊」、「郵件註冊」之間是（泛化（generalize））關係。
    • （2014）在UML提供的系統視圖中，（進程視圖）是邏輯視圖的一次執行實例，描述了併發與同步結構；（用例視圖）是最基本的需求分析模型。
• 軟件/信息系統建模方法

7. 軟件工程

• 軟件設計
  • （2018）軟件概要設計包括設計軟件的結構、肯定系統功能模塊及其相互關係，主要採用（模塊結構圖、層次圖和HIPO圖）描述程序的結構。
  • （2018）軟件設計包括了四個既獨立又相互聯繫的活動：高質量的（數據設計）將改善程序結構和模塊劃分，下降過程複雜性；（軟件結構設計）的主要目標是開發一個模塊化的程序結構，並表示出模塊間的控制關係；（人機界面設計）描述了軟件與用戶之間的交互關係。
• 軟件重用
  • （2018）軟件重用能夠分爲垂直式重用和水平式重用，（標準函數庫）是一種典型的水平式重用。
  • （2016）軟件重用是指在兩次或屢次不一樣的軟件開發過程當中重複使用相同或類似軟件元素的過程。軟件元素包括（需求分析文檔、設計文檔、程序代碼）、測試用例和領域知識等。
• 可修改性(Modifiability)
• 軟件維護
• 設計模式
  • （2018）設計模式描述了一個出如今特定設計語境中的設計再現問題，併爲它的解決方案提供了一個通過充分驗證的通用方案，不一樣的設計模式關注解決不一樣的問題。例如，抽象工廠模式提供一個接口，能夠建立一系列相關或相互依賴的對象， 而無需指定它們具體的類，它是一種（建立型）模式；（Bridge）模式將類的抽象部分和它的實現部分分離出來，使它們能夠獨立變化，它屬於（結構型）模式；（Command）模式將一個請求封裝爲一個對象，從而可用不一樣的請求對客戶進行參數化，將請求排隊或記錄請求日誌，支持可撤銷的操做。
  • （2017）按照設計模式的目的進行劃分， 現有的設計模式能夠分爲三類。其中建立型模式經過採用抽象類所定義的接口，封裝了系統中對象如何建立、組合等信息，其表明有（Singleton）模式等；（結構型）模式主要用於如何組合已有的類和對象以得到更大的結構，其表明有Adapter 模式等；（行爲型）模式主要用於對象之間的職責及其提供服務的分配方式，其表明有（Visitor）模式等。
  • （2016）設計模式基於面向對象技術，是人們在長期的開發實踐中良好經驗的結晶，提供了一個簡單、統一的描述方法， 使得人們能夠複用這些軟件設計辦法、過程管理經驗。按照設計模式的目的進行劃分，現有的設計模式能夠分爲建立型、（結構型）和行爲型三種類型。其中（Singleton）屬於建立型模式，（Memento）屬於行爲型模式。（Bridge）模式能夠將一個複雜的組件分紅功能性抽象和內部實現兩個獨立的但又相關的繼層次結構，從而能夠實現接口與實現分離。
  • （2015）某軟件公司欲開發一個繪圖軟件，要求使用不一樣的繪圖程序繪製不一樣的圖形。在明確用戶需求後，該公司的架構師決定採用Bridge模式實現該軟件，並設計UML類圖以下圖所示。圖中與Bridge模式中的「Abstraction」角色相對應的類是（Shape），與「Implementor」角色相對應的類是（Drawing）。
  • （2015）在面向對象設計的原則中、（依賴倒置）原則是指抽象不該該依賴予細節，細節應該依賴於抽象，即應針對接口編程，而不是針對實現編程。
  • （2014）某廣告公司的宣傳產品有宣傳冊、文章、傳單等多種形式，宣傳產品的出版方式包括紙質方式、CD、DVD、在線發佈等。現要求爲該廣告公司設計一個管理這些宣傳產品的應用，採用（Bridge）設計模式較爲合適，該模式（將抽象部分與它的實現部分分離，使它們均可以獨立地變化）。
  • （2014）一組對象以定義良好可是複雜的方式進行通訊，產生的相互依賴關係結構混亂且難以理解。採用（中介者(Mediator)）模式，用一個特定對象來封裝一系列的對象交互，從而使各對象不須要顯式地相互引用，使其耦合鬆散，並且能夠獨立地改變它們之間的交互。
• 系統工程
  • （2018）系統工程利用計算機做爲工具，對系統的結構、元素、（信息）和反饋等進行分析，以達到最優（規劃）、最優設計、最優管理和最優控制的目的。霍爾（A.D. Hall）於1969年提出了系統方法的三維結構體系，一般稱爲霍爾三維結構，這是系統工程方法論的基礎。霍爾三維結構以時間維、（邏輯）維、知識維組成的立體結構歸納性地表示出系統工程的各階段、各步驟以及所涉及的知識範圍。其中時間維是系統的工做進程，對於一個具體的工程項目，能夠分爲7個階段，在（研製）階段會作出研製方案及生產計劃。
• 系統構建
  • （2017）系統移植也是系統構建的一種實現方法，在移植工做中，（計劃階段）須要最終肯定移植方法。
• 逆向工程、再工程、設計恢復等
  • （2017）應用系統構建中能夠採用多種不一樣的技術， （逆向工程（ (Reverse Engineering)）能夠將軟件某種形式的描述轉換爲更高級的抽象表現形式，而利用這些獲取的信息， （再工程(Re-engineering)）可以對現有系統進行修改或重構，從而產生系統的一個新版本。
• 界面設計
  • （2014）下列關於用戶界面設計的敘述中，錯誤的是（界面交互模型應常常進行修改）。
• 測試
  • （2018）軟件測試通常分爲兩個大類：動態測試和靜態測試。前者經過運行程序發現錯誤，包括（邊界值分析、邏輯覆蓋、基本路徑）等方法；後者採用人工和計算機輔助靜態分析的手段對程序進行檢測，包括（桌面檢查、代碼審查、代碼走查）等方法。
  • （2017）軟件確認測試也稱爲有效性測試，主要驗證（軟件功能、性能及其它特性是否與用戶需求一致）。確認測試計劃一般是在需求分析階段完成的。根據用戶的參與程度不一樣， 軟件確認測試一般包括（內部測試、Alpha、Beta 和驗收測試）。
  • （2016）軟件集成測試將已經過單元測試的模塊集成在一塊兒， 主要測試模塊之間的協做性。從組裝策略而言，能夠分爲（一次性組裝和增量式組裝）。集成測試計劃一般是在（軟件概要設計）階段完成，集成測試通常採用黑盒測試方法。
  • （2015）（集成測試）的目的是檢查模塊之間，以及模塊和已集成的軟件之間的接口關係，並驗證已集成的軟件是否符合設計要求。其測試的技術依據是（軟件概要設計文檔）。
  • （2014）在單元測試中，（驅動模塊用來調用被測模塊，自頂向下的單元測試中不須要另外編寫驅動模塊）。
  • （2014）下列關於軟件調試與軟件測試的敘述中，正確的是（軟件測試的目的是找出存在的錯誤，軟件調試的目的是定位並修正錯誤）。
  • （2014）在靜態測試中，主要是對程序代碼進行靜態分析。「數據初始化、賦值或引用過程當中的異常」屬於靜態分析中的（數據流分析）。

8. 項目管理

• 項目範圍管理
  • （2017）項目範圍管理中，範圍定義的輸入包括（項目章程、項目範圍管理計劃、組織過程資產和批准的變動申請）。
  • （2015）關於項目範圍管理描述，正確的是（項目範圍定義是生產項目計劃的基礎）。
• 項目成本管理
  • （2016）項目的成本管理中， （成本預算）將總的成本估算分配到各項活動和工做包上，來創建一個成本的基線。
• 需求管理
  • （2018）下面關於變動控制的描述中，（變動控制委員會只能夠由一個小組擔任）是不正確的。
  • （2018）需求管理是一個對系統需求變動、瞭解和控制的過程。如下活動中，（文檔管理）不屬於需求管理的主要活動。
  • （2017）如下關於需求陳述的描述中,（在良好的需求陳述中，全部需求都應被視爲同等重要）是不正確的。
  • （2017）一個好的變動控制過程，給項目風險承擔者提供了正式的建議變動機制。以下圖所示的需求變動管理過程當中，①②③處對應的內容應分別是(問題分析與變動描述、變動分析與成本計算、變動實現)。
  • （2015）下列敘述中，不知足好的需求陳述要求的是（全部需求都應被視爲同等重要）。
  • （2015）一個大型軟件系統的需求老是有變化的。爲了下降項目開發的風險，須要一個好的變動控制過程。以下圖所示的需求變動管理過程當中，①②③處對應的內容應是（問題分析與變動描述，變動分析與成本計算，變動實現）；自動化工具可以幫助變動控制過程更有效地運做，（記錄每個狀態變動的日期及變動者）是這類工具應具備的特性之一。
• 項目時間管理
  • （2018）項目時間管理中的過程包括（活動定義、活動排序、活動的資源估算、活動歷時估算、制定計劃和進度控制）。
• 項目開發管理
  • 文檔
    • （2018）文檔是影響軟件可維護性的決定因素。軟件系統的文檔能夠分爲用戶文檔和系統文檔兩類。其中，（系統設計）不屬於用戶文檔包括的內容。
  • 開發模型、方法
    • （2018）系統模塊化程度較高時，更適合於採用（快速應用開發）方法，該方法經過使用基於構件的開發方法得到快速開發。（螺旋模型）把整個軟件開發流程分紅多個階段， 每個階段都由目標設定、風險分析、開發和有效性驗證以及評審構成。
    • （2018）軟件開發過程模型中，（原型模型）主要由原型開發階段和目標軟件開發階段構成。
    • （2017）軟件過程是製做軟件產品的一組活動以及結果，這些活動主要由軟件人員來完成，主要包括（軟件描述、軟件開發、軟件有效性驗證和軟件進化）。軟件過程模型是軟件開發實際過程的抽象與歸納，它應該包括構成軟件過程的各類活動。軟件過程有各類各樣的模型，其中，（瀑布模型）的活動之間存在因果關係，前一階段工做的結果是後一段階段工做的輸入描述。
    • （2017）如下關於敏捷方法的敘述中，（敏捷型方法的思考角度是"面向開發過程"的）是不正確的。
    • （2016）螺旋模型在（原型模型）的基礎上擴展而成。
    • （2016）（水晶系列（ Crystal ）開發方法）適用於程序開發人員在地域上分佈很廣的開發團隊。（功用驅動開發方法（ FDD））中，編程開發人員分紅首席程序員和「類」程序員。
    • （2015）RUP強調採用（迭代和增量）的方式來開發軟件，這樣作的好處是（在軟件開發的早期就能夠對關鍵的，影響大的風險進行處理）。
    • （2014）下列關於敏捷方法的敘述中，錯誤的是（敏捷方法尤爲適合於開發團隊比較龐大的項目）。
• 項目配置管理
  • （2017）項目配置管理中， 產品配置是指一個產品在其生命週期各個階段所產生的各類形式和各類版本的文檔、計算機程序、部件及數據的集合。該集合中的每個元素稱爲該產品配置中的一個配置頂， （工做計劃）不屬於產品組成部分工做成果的配置頂。
  • （2015）項目配置管理中，配置項的狀態一般包括（草稿、正式發佈和正在修改）。
• 軟件系統工具
  • （2017）UNIX的源代碼控制工具（ Source Code control System，SCCS）是軟件項目開發中經常使用的（版本控制工具）。
  • （2017）軟件系統工具的種類繁多， 一般能夠按照軟件過程活動將軟件工具分爲（軟件開發工具、軟件維護工具、軟件管理工具和軟件支持工具）。
  • （2016）在軟件系統工具中， 版本控制工具屬於（軟件維護工具），軟件評價工具屬於（軟件管理和軟件支持工具）。
• CMM
  • （2016）（能力成熟度模型（ Capacity Maturity Model ））在軟件開發機構中被普遍用來指導軟件過程改進。
• 集成機制
  • （2018）軟件開發環境應支持多種集成機制。其中，（環境信息庫）用於存儲與系統開發有關的信息，並支持信息的交流與共享； （過程控制與消息服務器）是實現過程集成和控制集成的基礎。

9. 系統配置與性能評價

• （2018）爲了優化系統的性能，有時須要對系統進行調整。對於不一樣的系統，其調整參數也不盡相同。例如，對於數據庫系統，主要包括CPU/內存使用情況、（查詢語句性能）、進程/線程使用狀態、日誌文件大小等。對於應用系統，主要包括應用系統的可用性、響應時間、（併發用戶數）、特定應用資源佔用等。
• （2017）對計算機評價的主要性能指標有時鐘頻率、(數據處理速率)、運算精度和內存容量等。對數據庫管理系統評價的主要性能指標有（最大鏈接數）、數據庫所容許的索引數量和最大併發實物處理能力等。
• （2016）把應用程序中應用最頻繁的那部分核心程序做爲評價計算機性能的標準程序，稱爲（基準測試）程序。（丟包率）不是對Web 服務器進行性能評估的主要指標。
• （2015）爲了測試新系統的性能，用戶必須依靠評價程序來評價機器的性能，如下四種評價程序，（合成基準程序）評測的準確程度最低。
  • 相對於小型基準程序、真實程序和核心程序，用合成基準程序評測的準確程度最低。
• （2014）在實際應用中，用戶一般依靠評價程序來測試系統的性能。如下評價程序中，（合成基準程序）的評測準確程度最低。事務處理性臺昱委員會(Transaction Processing Performance Council, TPC)是制定商務應用基準程序(benchmark)標準規範、性能和價格度量，並管理測試結果發佈的非營利組織，其發佈的TPC-C是（在線事務處理）的基準程序。

10. 系統可靠性分析與設計

11. 系統安全性與保密性設計

• （2018）數字簽名首先須要生成消息摘要，而後發送方用本身的私鑰對報文摘要進行加密， 接收方用發送方的公鑰驗證真僞。生成消息摘要的目的是（防止篡改），對摘要進行加密的目的是（防止抵賴）。
• （2016）DES 加密算法的密鑰長度爲56 位，三重DES 的密鑰長度爲（112）位。
• （2016）下列攻擊方式中，流量分析屬於（被動攻擊）方式。
• （2014）下列攻擊方式中，（SQL注入攻擊）不是利用TCP/IP漏洞發起的攻擊。

12. 數學與經濟管理

• （2018）在以下線性約束條件下：2x+3y<=30；x+2y>=10；x>=y；x>=5；y>=0，目標函數2x+3y的極小值爲（17.5）。
• （2018）某企業準備將四個工人甲、乙、丙、丁分配在A、B、C、D四個崗位。每一個工人因爲技術水平不一樣，在不一樣崗位上天天完成任務所需的工時見下表。適當安排崗位，可以使四個工人以最短的總工時（14）所有完成天天的任務。
• （2017）某工程包括A、B、C、D 四個做業，其銜接關係、正常進度下所需天數和所需直接費用、趕工進度下所需的最少天數和天天須要增長的直接費用見下表。該工程的間接費用爲天天5 萬元。據此，能夠估算出完成該工程最少須要費用（106）萬元，以此最低費用完成該工程須要（7）天。
  • 經過結點依賴圖，結合題目正常進度所需天數很容易看出ACD爲關鍵路徑。關鍵路徑長度爲12 天。但這樣獲得的就是最短工期與最少花費嗎？不是。由於題目指出間接花費是天天5 萬元，而趕工天天的費用僅2-4 萬。此時趕工完成部分任務，既能縮短工期，又能下降費用，是合適的解決方案，通過分析，趕工方案爲：A趕工2 天，B趕工1 天，D 趕工3 天。此時關鍵路徑長度爲7 天，總花費爲106萬。
• （2016）如下關於數學建模的敘述中，不正確的是（數學建模須要從失敗和用戶的反饋中學習和改進）。
• （2015）甲、乙、丙、丁4人加工A、B、C、D四種工件所需工時以下表所示。指派每人加工一種工件，四人加工四種工件其總工時最短的最優方案中，工件B應由（6）加工。
• （2015）小王須要從①地開車到⑦地，可供選擇的路線以下圖所示。圖中，各條箭線表示路段及其行駛方向，箭線旁標註的數字表示該路段的擁堵率（描述堵車的狀況，即堵車機率）。擁堵率=1-暢通率，擁堵率=0時表示徹底暢通，擁堵率=1時表示沒法行駛。根據該圖，小主選擇擁堵狀況最少（暢通狀況最好）的路線是（12357）。
• （2014）某服裝店有甲、乙、丙、丁四個縫製小組。甲組天天能縫製5件上衣或6條褲子；乙組天天能縫製6件上衣或7條褲子；丙組天天能縫製7件上衣或8條褲子；丁組天天能縫製8件上衣或9條褲子。每組天天要麼縫製上衣，要麼縫製褲子，不能弄混。訂單要求上衣和褲子必須配套（每套衣服包括一件上衣和一條褲子）。只要作好合理安排，該服裝店15天最多能縫製（211）套衣服。
• （2014）生產某種產品有兩個建廠方案：（1）建大廠，須要初期投資500萬元。若是產品銷路好，每一年能夠獲利200萬元；若是銷路很差，每一年會虧損20萬元。（2）建小廠，須要初期投資200萬元。若是產品銷路好，每一年能夠獲利100萬元；若是銷路很差，每一年只能獲利20萬元。市揚調研代表，將來2年這種產品銷路好的機率爲70%。若是這2年銷路好，則後續5年銷路好的機率上升爲80%；若是這2年銷路很差，則後續5年銷路好的機率僅爲10%。爲取得7年最大總收益，決策者應（建大廠，總收益略多於300萬元）。

13. 法律法規與標準化

• 著做權
  • （2018）譚某是CZB物流公司的業務系統管理員。任職期間，譚某根據公司的業務要求開發了「報關業務系統」，並由公司使用。如下說法正確的是（報關業務系統V1.0的著做權屬於CZB物流公司）。
  • （2018）軟件著做權受法律保護的期限是（50年）。一旦保護期滿，權利將自行終止，成爲社會公衆能夠自由使用的知識。
  • （2018）某軟件程序員接受X公司（軟件著做權人）委託開發一個軟件，三個月後又接受Y公司委託開發功能相似的軟件，該程序員僅將受X公司委託開發的軟件略做修改即完成提交給Y公司，此種行爲（構成侵權）。
  • （2016）軟件著做權保護的對象不包括（處理過程）。
  • （2016）M 公司購買了N 畫家創做的一幅美術做品原件。M 公司未經N 畫家的許可，擅自將這幅美術做品做爲商標註冊，並大量複製用於該公司的產品上。M公司的行爲侵犯了N 畫家的（著做權）。
  • （2015）用戶提出需求並提供經費，委託軟件公司開發軟件。雙方商定的協議（委託開發合同）中未涉及軟件著做權歸屬，其軟件著做權應由（軟件公司）享有。
  • （2015）某攝影家創做一件攝影做品出版後，將原件出售給了某軟件設計師。軟件設計師不慎將原件毀壞；則該件攝影做品的著做權（仍然由攝影家）享有。
  • （2015）軟件設計師王某在其公司的某一綜合信息管理系統軟件開發項目中、承擔了大部分程序設計工做。該系統交付用戶，投入試運行後，王某辭職離開公司，並帶走了該綜合信息管理系統的源程序，拒不交還公司。王某認爲綜合信息管理系統源是他獨立完成的，他是綜合信息管理系統源程序的軟件著做權人。王某的行爲（侵犯了公司的軟件著做權）。
  • （2014）甲公司接受乙公司委託開發了一項應用軟件，雙方沒有訂立任何書面合同。在此狀況下，（甲公司）享有該軟件的著做權。
  • （2014）如下關於軟件著做權產生時間的表述中，正確的是（自軟件開發完成之日時）。
• 商標權
  • （2017）甲、乙軟件公司同日就其財務軟件產品分別申請"用友"和"用有"商標註冊。兩財務軟件類似，且甲、乙第一次使用"用友"和"用有"商標時間均爲2015 年7月12 日。此情形下，（由甲、乙抽籤結果肯定誰）能獲准註冊。
  • （2014）軟件商標權的保護對象是指（軟件註冊商標）。
• 專利
• 其餘
  • （2017）王某買了一幅美術做品原件，則他享有該美術做品的（全部權與其展覽權）。
  • （2017）某人持有盜版軟件， 但不知道該軟件是盜版的， 該軟件的提供者不能證實其提供的複製品有合法來源。此狀況下，則該軟件的（提供者）應承擔法律責任。
  • （2016）M 軟件公司的軟件產品註冊商標爲N，爲確保公司在市場競爭中佔據優點，對員工進行了保密約束。此情形下，（公司享有專利權）的說法是錯誤的。

14. 企業信息化戰略與實施

• （2017）用於管理信息系統規劃的方法有不少， 其中（戰略目標集轉化法）將整個過程當作是一個「信息集合」，並將組織的戰略目標轉變爲管理信息系統的戰略目標。（企業系統規劃法）經過自上而下地識別企業目標、企業過程和數據， 而後對數據進行分析， 自下而上地設計信息系統。
• （2017）組織信息化需求一般包含三個層次，其中（戰略）需求的目標是提高組織的競爭能力，爲組織的可持續發展提供支持環境。(運做)需求包含實現信息化戰略目標的需求、運營策略的需求和人才培養的需求三個方面。技術需求主要強調在信息層技術層面上對系統的完善、升級、集成和整合提出的需求。
• （2016）電子政務是對現有的政府形態的一種改造，利用信息技術和其餘相關技術，將其管理和服務職能進行集成，在網絡上實現政府組織結構和工做流程優化重組。與電子政務相關的行爲主體有三個，即政府、（企（事）業單位）及居民。國家和地方人口信息的採集、處理和利用，屬於（政府對居民）的電子政務活動。
• （2016）ERP（Enterprise Resource Planning ）是創建在信息技術的基礎上，利用現代企業的先進管理思想，對企業的物流、資金流和（信息）流進行全面集成管理的管理信息系統， 爲企業提供決策、計劃、控制與經營業績評估的全方位和系統化的管理平臺。在ERP系統中，（庫存）管理模塊主要是對企業物料的進、出、存進行管理。
• （2015）對於遺留系統的評價框架以下圖所示，那麼處於「高水平、低價值」區的遺留系統適合於採用的演化策略爲（集成）。
• （2015）與方案一相比，方案二的優勢是（業務的連續性獲得保障）。方案二還有一些缺點，下列不屬於其缺點的是（缺乏網閘，不能實現財務系統與Internet的物理隔離）。
• （2015）供應鏈中的信息流覆蓋了從供應商、製造商到分銷商，再到零售商等供應鏈中的全部環節，其信息流分爲需求信息流和供應信息流，（生產計劃）屬於需求信息流，（完工報告單）屬於供應信息流。
• （2015）電子政務的主要應用模式中不包括（政府對公務員（Government To Employee）？政府對客戶（Government To Customer）？）。
• （2015）電子商務系統中參與電子商務活動的實體包括（客戶、商戶、銀行和認證中心）。
• （2015）商業智能系統的處理過程包括四個主要階段：數據預處理經過（數據抽取、轉換和裝載）實現企業原始數據的初步整合；創建數據倉庫是後續數據處理的基礎；數據分析是體現系統智能的關鍵，主要採用（聯機分析處理）和（數據挖掘）技術，前者可以實現數據的上卷、下鑽和旋轉分析，後者利用隱藏的知識，經過創建分析模型預測企業將來發展趨勢；數據展示主要完成數據處理結果的可化。
• （2014）商業智能是企業對商業數據的蒐集、管理和分析的系統過程，主要技術包括（數據倉庫、聯機分析和數據挖掘）。
• （2014）集成平臺是支持企業信息集成的支撐環境，包括硬件、軟件、軟件工具和系統。集成平臺的基本功能中，（信息集成服務）實現不一樣數據庫系統之間的數據交換、互操做、分佈數據管理和共享信息模型定義；（應用集成服務）可以爲應用提供數據交換和訪問操做，使各類不一樣的系統可以相互協做。
• （2014）ERP是對企業物流資源，資金流資源和信息流資源進行全面集成管理的管理信息系統。在ERP五個層次的計劃中，（生產計劃大綱）根據經營計劃的生產目標制定，是對企業經營計劃的細化；（主生產計劃）說明了在必定時期內生產什麼，生產多少和何時交貨，它的編制是ERP的主要工做內容；（能力需求計劃）可以幫助企業儘早發現企業生產能力的瓶頸，爲實現企業的生產任務提供能力方面的保障。
• （2014）企業信息化音定要創建在企業戰略規劃基礎之上，以企業戰略規劃爲基礎創建的企業管理模式是創建（企業戰略數據模型）的依據。

15. 英語

• objective
• be assigned to
• be allocated to
• be divided into
• retrieve data
• accounting records
• presentation
• acceptance
• specify：具體說明; 明確規定; 詳述; 詳列
  • used to develop the hardware and software specification
• the overall architecture
• placement
• experienced architecture designers and consultants
• refine ... to ...
• change over time：隨時間變化
• capacity
• reliability：可靠性
• disruption： 中斷; 擾亂; 混亂;
• an intentional act：故意的行爲
• Cultural and political requirements
• perform a particular transaction
• seldom
• outdated technology
• referential integrity
• legacy database
• hierarchical database
• synchronized
• Software architecture reconstruction is an interpretive, interactive, and iterative process including many activities.
• Reverse engineering
• implementation artifacts
• construct
• manipulate
• reconcile:vt. 使一致；使和解；調停，調解；使順從
• augment:vi. 增長；增大
• Information extraction
• architectural elements
• facility