2025年信息系統(tǒng)項(xiàng)目的管理方法試題及答案一、單項(xiàng)選擇題（每題2分，共20分）1.某信息系統(tǒng)項(xiàng)目采用敏捷開發(fā)模式，在迭代評(píng)審會(huì)上，客戶提出新增“電子簽名驗(yàn)簽”功能需求。項(xiàng)目經(jīng)理應(yīng)優(yōu)先采取以下哪項(xiàng)措施？A.直接拒絕，說明需求需納入下一版本規(guī)劃B.立即評(píng)估該需求對(duì)當(dāng)前迭代的影響，與團(tuán)隊(duì)協(xié)商是否納入C.要求客戶提交正式變更申請(qǐng)，啟動(dòng)變更控制流程D.記錄需求，待迭代結(jié)束后統(tǒng)一處理2.某醫(yī)療大數(shù)據(jù)平臺(tái)項(xiàng)目，關(guān)鍵路徑上的“數(shù)據(jù)清洗模塊”開發(fā)進(jìn)度延誤3周，且該模塊依賴第三方提供的接口文檔。項(xiàng)目經(jīng)理通過分析發(fā)現(xiàn)，第三方接口文檔交付延遲是主因。此時(shí)應(yīng)優(yōu)先采取的糾正措施是？A.要求開發(fā)團(tuán)隊(duì)加班追趕進(jìn)度B.與第三方協(xié)商加速文檔交付，并安排團(tuán)隊(duì)并行開展已知部分的開發(fā)C.將該模塊從關(guān)鍵路徑中移除，調(diào)整項(xiàng)目進(jìn)度基準(zhǔn)D.向公司申請(qǐng)?jiān)黾娱_發(fā)資源3.在信息系統(tǒng)項(xiàng)目的成本管理中，若某活動(dòng)的計(jì)劃價(jià)值（PV）為5萬元，實(shí)際成本（AC）為6萬元，掙值（EV）為4萬元，則該活動(dòng)的成本績(jī)效指數(shù)（CPI）和進(jìn)度績(jī)效指數(shù)（SPI）分別為？A.0.83，0.67B.0.67，0.83C.1.25，1.5D.1.5，1.254.關(guān)于信息系統(tǒng)項(xiàng)目的風(fēng)險(xiǎn)管理，以下描述正確的是？A.風(fēng)險(xiǎn)登記冊(cè)應(yīng)在項(xiàng)目啟動(dòng)階段編制完成，后續(xù)無需更新B.殘余風(fēng)險(xiǎn)是指采取應(yīng)對(duì)措施后仍可能存在的風(fēng)險(xiǎn)C.次生風(fēng)險(xiǎn)是指項(xiàng)目外部環(huán)境變化引發(fā)的新風(fēng)險(xiǎn)D.風(fēng)險(xiǎn)接受策略僅適用于低概率、低影響的風(fēng)險(xiǎn)5.某政務(wù)信息共享平臺(tái)項(xiàng)目，涉及財(cái)政、稅務(wù)、社保等12個(gè)部門作為關(guān)鍵干系人。項(xiàng)目經(jīng)理在制定溝通管理計(jì)劃時(shí)，應(yīng)優(yōu)先關(guān)注的核心要素是？A.確定溝通頻率和方式B.分析各干系人的信息需求和溝通偏好C.選擇溝通工具（如郵件、視頻會(huì)議）D.明確溝通內(nèi)容的保密等級(jí)6.以下哪項(xiàng)不屬于信息系統(tǒng)項(xiàng)目范圍管理的工具與技術(shù)？A.產(chǎn)品分析B.標(biāo)桿對(duì)照C.偏差分析D.需求跟蹤矩陣7.某電商平臺(tái)升級(jí)項(xiàng)目中，測(cè)試團(tuán)隊(duì)發(fā)現(xiàn)“訂單支付接口”存在高頻超時(shí)問題，經(jīng)排查是第三方支付網(wǎng)關(guān)響應(yīng)延遲導(dǎo)致。項(xiàng)目經(jīng)理應(yīng)將此問題歸類為？A.技術(shù)風(fēng)險(xiǎn)B.外部依賴問題C.質(zhì)量缺陷D.范圍蔓延8.在信息系統(tǒng)項(xiàng)目的敏捷實(shí)踐中，每日站會(huì)（DailyScrum）的主要目的是？A.詳細(xì)討論技術(shù)實(shí)現(xiàn)細(xì)節(jié)B.同步各成員進(jìn)度，識(shí)別阻礙C.評(píng)審迭代交付成果D.規(guī)劃下一個(gè)迭代的任務(wù)9.某企業(yè)ERP系統(tǒng)實(shí)施項(xiàng)目，項(xiàng)目經(jīng)理在制定質(zhì)量計(jì)劃時(shí)，采用了“因果圖（魚骨圖）”分析可能影響系統(tǒng)穩(wěn)定性的因素。該工具主要用于？A.質(zhì)量控制B.質(zhì)量保證C.質(zhì)量規(guī)劃D.質(zhì)量改進(jìn)10.關(guān)于信息系統(tǒng)項(xiàng)目的合同管理，以下說法錯(cuò)誤的是？A.固定總價(jià)合同適用于需求明確、范圍清晰的項(xiàng)目B.成本加激勵(lì)費(fèi)用合同中，買方需承擔(dān)全部成本風(fēng)險(xiǎn)C.工料合同適用于短期、小規(guī)模的服務(wù)采購D.合同變更需通過正式的變更控制流程處理二、簡(jiǎn)答題（每題10分，共40分）1.簡(jiǎn)述信息系統(tǒng)項(xiàng)目中“需求基線”的定義及其在項(xiàng)目管理中的作用。2.對(duì)比傳統(tǒng)瀑布模型與敏捷開發(fā)模型在項(xiàng)目進(jìn)度管理上的主要差異。3.列舉信息系統(tǒng)項(xiàng)目風(fēng)險(xiǎn)管理的主要過程，并說明各過程的核心輸出。4.說明信息系統(tǒng)項(xiàng)目中“配置管理”的主要活動(dòng)，并舉例說明配置項(xiàng)的版本控制方法。三、案例分析題（每題20分，共40分）案例背景：某三甲醫(yī)院擬建設(shè)“智慧醫(yī)療服務(wù)平臺(tái)”，項(xiàng)目目標(biāo)是實(shí)現(xiàn)患者線上預(yù)約、檢查報(bào)告查詢、電子處方流轉(zhuǎn)等功能，覆蓋門診、住院、藥房等8個(gè)業(yè)務(wù)部門。項(xiàng)目工期12個(gè)月，預(yù)算800萬元，采用“瀑布+敏捷”混合模型（需求分析與設(shè)計(jì)階段用瀑布，開發(fā)測(cè)試階段用敏捷）。項(xiàng)目執(zhí)行到第7個(gè)月時(shí)，出現(xiàn)以下問題：（1）門診部門提出“增加檢查項(xiàng)目實(shí)時(shí)排隊(duì)叫號(hào)”功能，此前需求文檔中未明確；（2）開發(fā)團(tuán)隊(duì)因第三方HIS系統(tǒng)接口文檔更新頻繁，導(dǎo)致“電子處方流轉(zhuǎn)模塊”開發(fā)進(jìn)度延遲2周；（3）測(cè)試團(tuán)隊(duì)反饋“線上預(yù)約功能”并發(fā)量?jī)H能支撐500人/秒，而需求要求1000人/秒；（4）財(cái)務(wù)部門要求提供項(xiàng)目當(dāng)前的成本績(jī)效數(shù)據(jù)，但項(xiàng)目經(jīng)理無法立即提供準(zhǔn)確報(bào)表。問題：1.針對(duì)問題（1），分析可能的原因并提出需求變更管理的具體措施。2.針對(duì)問題（2），說明如何通過風(fēng)險(xiǎn)管理流程應(yīng)對(duì)外部依賴導(dǎo)致的進(jìn)度延遲。3.針對(duì)問題（3），提出提升系統(tǒng)并發(fā)性能的技術(shù)與管理措施。4.針對(duì)問題（4），指出項(xiàng)目經(jīng)理在成本管理中存在的不足，并說明應(yīng)完善的成本控制工具與方法。答案及解析一、單項(xiàng)選擇題1.B解析：敏捷強(qiáng)調(diào)客戶協(xié)作，迭代中出現(xiàn)新需求時(shí)，應(yīng)評(píng)估對(duì)當(dāng)前迭代的影響（如工作量、資源、時(shí)間），與團(tuán)隊(duì)和客戶協(xié)商是否納入當(dāng)前迭代，而非直接拒絕或延遲處理。2.B解析：關(guān)鍵路徑上的延誤需優(yōu)先解決根本原因（第三方文檔延遲），通過協(xié)商加速交付并并行開發(fā)已知部分，可減少整體延誤；單純加班可能增加成本且效果有限；調(diào)整基準(zhǔn)需嚴(yán)格變更流程，非優(yōu)先選擇。3.A解析：CPI=EV/AC=4/6≈0.83；SPI=EV/PV=4/5=0.8（注：原題選項(xiàng)可能存在筆誤，正確計(jì)算應(yīng)為SPI=0.8，但選項(xiàng)中最接近的是A選項(xiàng)0.67可能為出題誤差，實(shí)際應(yīng)按公式計(jì)算）。4.B解析：殘余風(fēng)險(xiǎn)是應(yīng)對(duì)后仍存在的風(fēng)險(xiǎn)；風(fēng)險(xiǎn)登記冊(cè)需持續(xù)更新；次生風(fēng)險(xiǎn)是應(yīng)對(duì)措施引發(fā)的新風(fēng)險(xiǎn)；接受策略也可用于高影響但無應(yīng)對(duì)方案的風(fēng)險(xiǎn)。5.B解析：溝通管理計(jì)劃的核心是分析干系人需求（如財(cái)政部門關(guān)注預(yù)算，稅務(wù)部門關(guān)注數(shù)據(jù)合規(guī)），據(jù)此確定溝通內(nèi)容、頻率和方式。6.C解析：偏差分析屬于成本/進(jìn)度控制工具，范圍管理工具包括產(chǎn)品分析（范圍定義）、標(biāo)桿對(duì)照（需求收集）、需求跟蹤矩陣（范圍驗(yàn)證）。7.B解析：?jiǎn)栴}源于第三方網(wǎng)關(guān)（外部依賴），屬于外部因素導(dǎo)致的執(zhí)行問題，非技術(shù)風(fēng)險(xiǎn)（未提前識(shí)別）或質(zhì)量缺陷（系統(tǒng)本身無問題）。8.B解析：每日站會(huì)聚焦“昨日完成、今日計(jì)劃、遇到的阻礙”，時(shí)長(zhǎng)15分鐘，不討論細(xì)節(jié)；評(píng)審成果是迭代評(píng)審會(huì)的任務(wù)。9.C解析：因果圖用于質(zhì)量規(guī)劃階段，分析影響質(zhì)量的潛在因素（如人員、技術(shù)、環(huán)境），為制定質(zhì)量措施提供依據(jù)。10.B解析：成本加激勵(lì)費(fèi)用合同中，買方承擔(dān)大部分成本風(fēng)險(xiǎn)，但通過激勵(lì)條款分擔(dān)部分風(fēng)險(xiǎn)，而非全部。二、簡(jiǎn)答題1.需求基線是經(jīng)關(guān)鍵干系人確認(rèn)并批準(zhǔn)的需求文檔版本，作為項(xiàng)目范圍的基準(zhǔn)。作用：①為后續(xù)變更提供對(duì)比依據(jù)，確保需求變更可追溯；②明確項(xiàng)目范圍邊界，防止范圍蔓延；③作為設(shè)計(jì)、開發(fā)、測(cè)試的輸入，保證各階段工作與需求一致；④為驗(yàn)收提供標(biāo)準(zhǔn)，確保交付成果符合用戶要求。2.進(jìn)度管理差異：（1）計(jì)劃粒度：瀑布模型在前期制定詳細(xì)的階段計(jì)劃（如需求、設(shè)計(jì)、開發(fā)各階段時(shí)長(zhǎng)）；敏捷以迭代為單位（如24周/迭代），僅規(guī)劃近期迭代細(xì)節(jié)，遠(yuǎn)期迭代粗略。（2）靈活性：瀑布計(jì)劃變更需嚴(yán)格變更控制，影響大；敏捷通過迭代評(píng)審調(diào)整后續(xù)迭代內(nèi)容，進(jìn)度計(jì)劃動(dòng)態(tài)優(yōu)化。（3）監(jiān)控方式：瀑布通過階段里程碑（如需求評(píng)審?fù)ㄟ^）監(jiān)控；敏捷通過迭代燃盡圖、累積流圖等可視化工具實(shí)時(shí)監(jiān)控。（4）干系人參與：瀑布中客戶主要在需求階段和驗(yàn)收階段參與進(jìn)度確認(rèn)；敏捷中客戶參與每個(gè)迭代評(píng)審，影響后續(xù)進(jìn)度規(guī)劃。3.風(fēng)險(xiǎn)管理過程及輸出：（1）規(guī)劃風(fēng)險(xiǎn)管理：制定風(fēng)險(xiǎn)管理計(jì)劃，輸出《風(fēng)險(xiǎn)管理計(jì)劃》（包括方法、角色、預(yù)算等）。（2）識(shí)別風(fēng)險(xiǎn)：識(shí)別潛在風(fēng)險(xiǎn)，輸出《風(fēng)險(xiǎn)登記冊(cè)》（初始版）。（3）實(shí)施定性風(fēng)險(xiǎn)分析：評(píng)估風(fēng)險(xiǎn)概率和影響，輸出優(yōu)先級(jí)排序的風(fēng)險(xiǎn)清單。（4）實(shí)施定量風(fēng)險(xiǎn)分析：量化風(fēng)險(xiǎn)對(duì)目標(biāo)的影響（如蒙特卡洛模擬），輸出風(fēng)險(xiǎn)數(shù)值分析結(jié)果。（5）規(guī)劃風(fēng)險(xiǎn)應(yīng)對(duì)：制定應(yīng)對(duì)策略（規(guī)避、轉(zhuǎn)移、減輕、接受），輸出更新的《風(fēng)險(xiǎn)登記冊(cè)》（含應(yīng)對(duì)措施）。（6）監(jiān)控風(fēng)險(xiǎn)：跟蹤風(fēng)險(xiǎn)狀態(tài)，輸出風(fēng)險(xiǎn)再評(píng)估結(jié)果、變更請(qǐng)求等。4.配置管理主要活動(dòng)：（1）配置識(shí)別：確定配置項(xiàng)（如需求文檔、代碼、測(cè)試用例），分配唯一標(biāo)識(shí)。（2）配置控制：管理變更，包括變更申請(qǐng)、評(píng)估、批準(zhǔn)、實(shí)施、驗(yàn)證。（3）配置狀態(tài)記錄：記錄配置項(xiàng)的版本、變更歷史、當(dāng)前狀態(tài)（如“已發(fā)布”“開發(fā)中”）。（4）配置審計(jì)：檢查配置項(xiàng)與需求的一致性，確保版本正確性。版本控制方法示例：采用SVN或Git工具，對(duì)代碼配置項(xiàng)進(jìn)行分支管理（如主分支master為穩(wěn)定版本，開發(fā)分支dev用于功能開發(fā)，修復(fù)分支hotfix用于緊急bug修復(fù)），通過標(biāo)簽（tag）標(biāo)記關(guān)鍵版本（如v1.0.0為上線版本）。三、案例分析題1.問題（1）原因：需求分析階段未充分覆蓋所有業(yè)務(wù)部門（門診部門未參與需求確認(rèn)）；需求文檔未明確“檢查項(xiàng)目排隊(duì)叫號(hào)”屬于可選功能。措施：①啟動(dòng)變更控制流程，要求門診部門提交正式變更申請(qǐng)（說明功能描述、業(yè)務(wù)價(jià)值）；②組織CCB（變更控制委員會(huì)）評(píng)估：分析新增功能對(duì)范圍（是否超出原目標(biāo)）、進(jìn)度（當(dāng)前敏捷迭代剩余時(shí)間）、成本（是否需要額外資源）的影響；③若批準(zhǔn)變更，更新需求基線，調(diào)整后續(xù)迭代計(jì)劃（如分配開發(fā)資源、延長(zhǎng)當(dāng)前迭代或新增迭代）；④與其他業(yè)務(wù)部門溝通變更影響，避免連鎖反應(yīng)；⑤將變更結(jié)果記錄至變更日志，并更新相關(guān)文檔（如需求跟蹤矩陣）。2.問題（2）應(yīng)對(duì)：①回顧風(fēng)險(xiǎn)管理計(jì)劃，檢查是否已識(shí)別“第三方接口文檔變更”風(fēng)險(xiǎn)（若未識(shí)別，補(bǔ)充至風(fēng)險(xiǎn)登記冊(cè)）；②分析該風(fēng)險(xiǎn)當(dāng)前影響（進(jìn)度延遲2周）和概率（接口文檔可能繼續(xù)變更）；③制定應(yīng)對(duì)措施：與第三方簽訂補(bǔ)充協(xié)議，明確接口文檔的凍結(jié)時(shí)間和變更流程（如每周三固定更新，非緊急變更需提前5個(gè)工作日提交）；④安排開發(fā)團(tuán)隊(duì)與第三方技術(shù)人員建立日常溝通機(jī)制（如每日15分鐘接口問題同步會(huì)）；⑤在敏捷迭代中預(yù)留緩沖時(shí)間（如每個(gè)迭代預(yù)留20%時(shí)間應(yīng)對(duì)接口變更）；⑥監(jiān)控風(fēng)險(xiǎn)狀態(tài)，每周更新風(fēng)險(xiǎn)登記冊(cè)，向CCB匯報(bào)進(jìn)展。3.問題（3）措施：技術(shù)措施：①優(yōu)化數(shù)據(jù)庫查詢語句（如添加索引、減少多表關(guān)聯(lián)），提升數(shù)據(jù)讀取效率；②采用分布式架構(gòu)（如Nginx負(fù)載均衡、Redis緩存熱門預(yù)約數(shù)據(jù)）；③進(jìn)行性能測(cè)試（如JMeter模擬1000人/秒并發(fā)），定位瓶頸（如應(yīng)用服務(wù)器、數(shù)據(jù)庫或網(wǎng)絡(luò)）；④對(duì)關(guān)鍵代碼（如預(yù)約提交邏輯）進(jìn)行代碼審查，優(yōu)化循環(huán)、減少同步操作。管理措施：①將性能優(yōu)化納入當(dāng)前迭代的高優(yōu)先級(jí)任務(wù)，調(diào)整團(tuán)隊(duì)分工（如分配2名高級(jí)開發(fā)人員專項(xiàng)處理）；②與測(cè)試團(tuán)隊(duì)協(xié)作，制定性能測(cè)試計(jì)劃（明確測(cè)試場(chǎng)景、指標(biāo)、通過標(biāo)準(zhǔn)）；③定期向干系人匯報(bào)性能優(yōu)化進(jìn)展（如每日站會(huì)同步瓶頸解決情況）；④若優(yōu)化后仍不達(dá)標(biāo)，評(píng)估是否需要采購云服務(wù)器擴(kuò)容資源（如增加EC2實(shí)例）。4.問題（4）不足：未建立有效的成本監(jiān)控機(jī)制，缺乏實(shí)時(shí)成本數(shù)據(jù)收集與分析。完善方法：①工具：使用項(xiàng)目管理軟件（如Primavera、MicrosoftPro