2025年信息系統(tǒng)開發(fā)與管理考試試卷及答案一、單項選擇題（每題2分，共20分）1.以下關(guān)于信息系統(tǒng)開發(fā)瀑布模型的描述中，正確的是（）A.強調(diào)迭代和快速反饋，適用于需求模糊的項目B.各階段嚴格順序執(zhí)行，前一階段完成后才能進入下一階段C.允許開發(fā)過程中頻繁調(diào)整需求，靈活性高D.主要依賴用戶參與原型設(shè)計，降低開發(fā)風(fēng)險答案：B2.需求規(guī)格說明書（SRS）的核心作用是（）A.記錄項目開發(fā)進度和資源分配B.明確系統(tǒng)功能、性能及約束條件，作為開發(fā)與驗收依據(jù)C.描述系統(tǒng)架構(gòu)設(shè)計和模塊劃分D.匯總測試用例和測試結(jié)果答案：B3.在UML（統(tǒng)一建模語言）中，用于描述系統(tǒng)動態(tài)行為、展示對象間交互過程的圖是（）A.類圖B.用例圖C.順序圖D.狀態(tài)圖答案：C4.敏捷開發(fā)（AgileDevelopment）的核心原則不包括（）A.個體與交互重于流程與工具B.可工作的軟件重于詳盡的文檔C.客戶協(xié)作重于合同談判D.嚴格遵循計劃重于響應(yīng)變化答案：D5.數(shù)據(jù)倉庫（DataWarehouse）的主要特性是（）A.面向事務(wù)處理，支持實時更新B.面向主題，集成、穩(wěn)定且隨時間變化C.支持OLTP（聯(lián)機事務(wù)處理），數(shù)據(jù)粒度細D.數(shù)據(jù)結(jié)構(gòu)靈活，適合臨時查詢答案：B6.信息系統(tǒng)安全管理中，“最小權(quán)限原則”指的是（）A.系統(tǒng)管理員擁有最高權(quán)限，其他用戶無權(quán)限B.用戶僅獲得完成任務(wù)所需的最低權(quán)限C.所有用戶權(quán)限相同，避免特權(quán)濫用D.權(quán)限根據(jù)用戶職位自動分配，無需人工調(diào)整答案：B7.某信息系統(tǒng)項目的關(guān)鍵路徑長度為30天，其中活動A的總浮動時間為5天，自由浮動時間為3天。若活動A延遲4天完成，項目總工期將（）A.延遲4天B.延遲1天C.不受影響D.延遲3天答案：B（關(guān)鍵路徑總浮動時間為0，活動A的總浮動時間為5天，延遲4天未超過總浮動時間，因此不影響關(guān)鍵路徑；但自由浮動時間為3天，延遲4天會影響后續(xù)活動的最早開始時間，但總工期由關(guān)鍵路徑?jīng)Q定，因此總工期不變？需修正：關(guān)鍵路徑上的活動總浮動時間為0，若活動A不在關(guān)鍵路徑上，總浮動時間5天，延遲4天不影響總工期。正確答案應(yīng)為C？需重新確認。）（注：原題存在邏輯錯誤，正確場景應(yīng)為：若活動A在關(guān)鍵路徑上，則總浮動時間為0，延遲4天會導(dǎo)致總工期延遲4天；若不在關(guān)鍵路徑上，總浮動時間5天，延遲4天不影響總工期。假設(shè)題目中活動A不在關(guān)鍵路徑上，正確答案為C。）修正后答案：C8.B/S（瀏覽器/服務(wù)器）架構(gòu)相較于C/S（客戶端/服務(wù)器）架構(gòu)的主要優(yōu)勢是（）A.客戶端無需安裝專用軟件，維護成本低B.數(shù)據(jù)處理能力強，適合復(fù)雜業(yè)務(wù)邏輯C.安全性更高，客戶端存儲敏感數(shù)據(jù)D.對網(wǎng)絡(luò)帶寬要求低，響應(yīng)速度快答案：A9.面向?qū)ο笤O(shè)計（OOD）中，“封裝”的主要目的是（）A.提高代碼復(fù)用性，通過繼承實現(xiàn)B.隱藏對象內(nèi)部細節(jié)，僅暴露接口C.支持多態(tài)，允許不同對象響應(yīng)同一消息D.優(yōu)化算法復(fù)雜度，降低運行時間答案：B10.COBIT（信息及相關(guān)技術(shù)控制目標(biāo)）框架的核心目標(biāo)是（）A.規(guī)范信息系統(tǒng)開發(fā)的生命周期流程B.提供IT治理與管理的最佳實踐，確保IT與業(yè)務(wù)目標(biāo)一致C.定義數(shù)據(jù)庫設(shè)計的范式規(guī)則，提升數(shù)據(jù)冗余控制D.指導(dǎo)敏捷團隊的每日站會與迭代規(guī)劃答案：B二、填空題（每題2分，共20分）1.信息系統(tǒng)開發(fā)的三個主要階段包括需求分析、系統(tǒng)設(shè)計和系統(tǒng)實施與運維。2.需求分析中常用的建模方法包括用例建模、數(shù)據(jù)流圖（DFD）和實體-關(guān)系圖（E-R圖）。3.UML中的交互圖主要包括順序圖（SequenceDiagram）和協(xié)作圖（CollaborationDiagram）。4.敏捷開發(fā)的核心價值觀體現(xiàn)在《敏捷宣言》中，包括個體與交互、可工作的軟件、客戶協(xié)作和響應(yīng)變化。5.數(shù)據(jù)字典的主要組成部分包括數(shù)據(jù)項、數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)流、數(shù)據(jù)存儲和處理邏輯。6.信息系統(tǒng)項目管理的三重約束是范圍、時間和成本。7.數(shù)據(jù)庫設(shè)計的三大范式中，第三范式（3NF）要求不存在非主屬性對碼的傳遞函數(shù)依賴。8.信息系統(tǒng)運維的主要內(nèi)容包括日常監(jiān)控、故障處理、性能優(yōu)化和版本更新。9.風(fēng)險管理的基本流程包括風(fēng)險識別、風(fēng)險評估、風(fēng)險應(yīng)對和風(fēng)險監(jiān)控。10.COSO（企業(yè)風(fēng)險管理整合框架）的五大要素是內(nèi)部環(huán)境、目標(biāo)設(shè)定、事件識別、風(fēng)險評估和風(fēng)險應(yīng)對。三、簡答題（每題10分，共50分）1.比較瀑布模型與敏捷開發(fā)的優(yōu)缺點，并說明各自適用的項目場景。答案：瀑布模型優(yōu)點：階段劃分明確，文檔驅(qū)動，便于管理和驗收；缺點：靈活性差，需求變更成本高，后期發(fā)現(xiàn)錯誤修復(fù)代價大。適用場景：需求明確、技術(shù)成熟、規(guī)模較大的傳統(tǒng)項目（如政府公文系統(tǒng)）。敏捷開發(fā)優(yōu)點：迭代增量交付，快速響應(yīng)需求變更，強調(diào)客戶協(xié)作；缺點：對團隊溝通能力要求高，文檔可能不夠完善，大規(guī)模項目管理難度大。適用場景：需求模糊、市場變化快的互聯(lián)網(wǎng)產(chǎn)品（如社交應(yīng)用開發(fā)）。2.需求分析中用戶參與的重要性體現(xiàn)在哪些方面？如何有效促進用戶參與？答案：重要性：用戶是需求的直接來源，參與可避免需求偏差；用戶認可需求規(guī)格說明書可降低后期驗收風(fēng)險；用戶參與能提升對系統(tǒng)的接受度。促進方法：建立用戶代表小組，定期召開需求研討會；使用原型法讓用戶直觀體驗設(shè)計；設(shè)置反饋渠道（如在線表單、定期訪談）；培訓(xùn)用戶掌握需求表達工具（如用例描述模板）。3.簡述UML用例圖在需求建模中的作用，并說明繪制用例圖的主要步驟。答案：作用：用例圖通過“參與者（Actor）”和“用例（UseCase）”的交互，直觀展示系統(tǒng)功能邊界；幫助開發(fā)團隊與用戶達成需求共識；作為后續(xù)詳細設(shè)計的基礎(chǔ)。繪制步驟：（1）確定系統(tǒng)邊界（明確“系統(tǒng)”包含的范圍）；（2）識別參與者（與系統(tǒng)交互的人或外部系統(tǒng)）；（3）識別用例（系統(tǒng)為參與者提供的具體功能）；（4）定義用例與參與者的關(guān)聯(lián)（關(guān)聯(lián)關(guān)系）；（5）添加用例間的擴展（extend）或包含（include）關(guān)系，細化功能邏輯。4.信息系統(tǒng)項目風(fēng)險管理的流程包括哪些關(guān)鍵活動？請舉例說明風(fēng)險應(yīng)對策略。答案：流程：（1）風(fēng)險識別（如通過頭腦風(fēng)暴法列出“需求頻繁變更”“核心開發(fā)人員離職”等風(fēng)險）；（2）風(fēng)險評估（定性分析概率與影響，定量計算風(fēng)險值）；（3）風(fēng)險應(yīng)對（制定規(guī)避、轉(zhuǎn)移、減輕或接受策略）；（4）風(fēng)險監(jiān)控（跟蹤風(fēng)險狀態(tài)，調(diào)整應(yīng)對措施）。示例：針對“核心開發(fā)人員離職”風(fēng)險，應(yīng)對策略可包括：（1）規(guī)避：提前簽訂保密協(xié)議與服務(wù)期合同；（2）減輕：建立知識共享機制，確保技術(shù)文檔完整；（3）轉(zhuǎn)移：為關(guān)鍵崗位購買人才保險；（4）接受：預(yù)留應(yīng)急預(yù)算用于招聘替代人員。5.數(shù)據(jù)庫設(shè)計中，E-R模型向關(guān)系模型轉(zhuǎn)換的主要規(guī)則有哪些？請舉例說明。答案：主要規(guī)則：（1）實體轉(zhuǎn)換為關(guān)系表，實體屬性轉(zhuǎn)換為表字段，主碼對應(yīng)實體標(biāo)識符；（2）一對一（1:1）聯(lián)系：可將任一實體的主碼加入另一實體的關(guān)系表；（3）一對多（1:n）聯(lián)系：將“1”方的主碼加入“n”方的關(guān)系表作為外碼；（4）多對多（m:n）聯(lián)系：創(chuàng)建獨立的關(guān)系表，包含雙方主碼及聯(lián)系屬性，主碼為雙方主碼的組合。示例：學(xué)生（學(xué)號，姓名）與課程（課程號，名稱）是多對多聯(lián)系“選課”（成績）。轉(zhuǎn)換后生成三個表：學(xué)生（學(xué)號，姓名）、課程（課程號，名稱）、選課（學(xué)號，課程號，成績），其中“學(xué)號”和“課程號”是外碼，組合為主碼。四、應(yīng)用題（每題15分，共30分）1.某連鎖超市計劃開發(fā)“供應(yīng)鏈管理系統(tǒng)”，需求包括：供應(yīng)商管理、采購訂單跟蹤、庫存實時監(jiān)控、物流信息同步。已知該超市業(yè)務(wù)流程穩(wěn)定，但供應(yīng)商數(shù)量多（約500家），且存在部分供應(yīng)商信息化水平較低（僅支持電話/郵件溝通）。請為該項目選擇合適的信息系統(tǒng)開發(fā)模型，并說明選擇理由及實施步驟。答案：選擇模型：螺旋模型（或增量模型，需結(jié)合場景分析）。更合理選擇為增量模型，理由：超市業(yè)務(wù)流程穩(wěn)定（需求較明確），但供應(yīng)商信息化水平差異大（部分需求需逐步驗證）。增量模型可分階段交付核心功能（如供應(yīng)商管理、采購訂單跟蹤），后續(xù)增量完善庫存監(jiān)控和物流同步，降低一次性開發(fā)風(fēng)險。實施步驟：（1）需求確認：與超市管理層、采購部門確認核心功能優(yōu)先級（如“采購訂單跟蹤”為首要）；（2）第一增量開發(fā)：完成供應(yīng)商信息錄入、采購訂單生成與狀態(tài)更新功能，采用瀑布模型完成設(shè)計、編碼、測試；（3）用戶驗證：邀請5-10家信息化水平較高的供應(yīng)商試用，收集反饋；（4）第二增量開發(fā)：增加庫存實時監(jiān)控（對接超市現(xiàn)有ERP系統(tǒng)）、物流信息接口（與第三方物流系統(tǒng)對接）；（5）全量部署：針對信息化水平低的供應(yīng)商，提供離線錄入功能（如Excel模板導(dǎo)入），確保系統(tǒng)覆蓋所有供應(yīng)商。2.某高校圖書館需開發(fā)“讀者借閱管理系統(tǒng)”，用戶需求如下：讀者可查詢圖書庫存并預(yù)約借閱；管理員可錄入新書、修改圖書狀態(tài)（在架/借出/丟失）；系統(tǒng)需記錄借閱記錄（讀者ID、圖書ID、借出日期、應(yīng)還日期、實際歸還日期）。請根據(jù)需求繪制頂層數(shù)據(jù)流圖（0層DFD），并設(shè)計關(guān)鍵數(shù)據(jù)字典條目（至少包含3個）。答案：頂層數(shù)據(jù)流圖（0層DFD）：-外部實體：讀者、圖書管理員-系統(tǒng)：讀者借閱管理系統(tǒng)-輸入數(shù)據(jù)流：讀者（查詢請求、預(yù)約請求）；圖書管理員（新書錄入、狀態(tài)修改）-輸出數(shù)據(jù)流：系統(tǒng)（庫存查詢結(jié)果、預(yù)約確認）；系統(tǒng)（借閱記錄存儲、圖書狀態(tài)更新）關(guān)鍵數(shù)據(jù)字典條目示例：（1）數(shù)據(jù)項：讀者ID類型：字符串（長度8）取值范圍：2位學(xué)院代碼+6位學(xué)號（如“01202301”）說明：唯一標(biāo)識讀者身份（2）數(shù)據(jù)結(jié)構(gòu)：圖書信息組成：圖書ID+書名+作者+出版社+出版日期+狀態(tài)（在架/借出/丟失）說明：描述單本圖書的基本屬性（3）數(shù)據(jù)流：預(yù)約請求組成：讀者ID+圖書ID+預(yù)約日期流向：讀者→系統(tǒng)說明：讀者發(fā)起圖書預(yù)約的請求數(shù)據(jù)五、案例分析題（20分）案例背景：某科技公司承接“智慧社區(qū)管理系統(tǒng)”開發(fā)項目，采用敏捷開發(fā)模式，迭代周期為2周。項目初期，客戶頻繁提出需求變更（如新增“訪客人臉識別”“物業(yè)繳費接口”），導(dǎo)致開發(fā)團隊頻繁調(diào)整任務(wù)；團隊成員分布在3個城市，溝通依賴線上會議，效率較低；測試人員因需求不穩(wěn)定，無法及時編寫測試用例，多次出現(xiàn)迭代交付版本存在嚴重bug。問題：（1）分析項目當(dāng)前面臨的主要問題及根本原因；（2）提出具體改進措施。答案：（1）主要問題及根本原因：-需求變更失控：客戶未理解敏捷“響應(yīng)變化”的邊界，開發(fā)團隊未建立需求變更評估機制（如“需求池”優(yōu)先級排序）。-分布式團隊溝通效率低：缺乏高效的協(xié)作工具，未制定明確的溝通規(guī)則（如每日站會的時間、內(nèi)容規(guī)范）。-測試延遲與質(zhì)量問題：測試與開發(fā)不同步，未采用“測試驅(qū)動開發(fā)（TDD）”，需求變更未及時更新測試用例。（2）改進措施：-需求管理：建立“產(chǎn)品待辦列表（ProductBacklog）”，與客戶共同評估變更需求