2025年上半年信息系統(tǒng)項目管理師考試練習(xí)題及答案一、綜合知識（75題，每題1分，共75分）以下每小題給出的四個選項中，只有一個選項是最符合題目要求的。1.某企業(yè)計劃開發(fā)智能供應(yīng)鏈管理系統(tǒng)，項目啟動階段需明確項目目標(biāo)。以下關(guān)于項目目標(biāo)的描述中，最符合SMART原則的是（）。A.系統(tǒng)上線后提升供應(yīng)鏈效率B.6個月內(nèi)完成開發(fā)，系統(tǒng)處理訂單延遲率從15%降至3%以內(nèi)C.采用微服務(wù)架構(gòu)，支持1000并發(fā)用戶D.滿足物流、倉儲、采購部門的基本需求2.根據(jù)《信息系統(tǒng)項目管理師教程（第4版）》，以下不屬于項目整合管理過程的是（）。A.制定項目章程B.監(jiān)控項目工作C.控制范圍D.結(jié)束項目或階段3.某項目進度計劃采用關(guān)鍵鏈法（CCM），在關(guān)鍵鏈上設(shè)置了接駁緩沖（FB）和項目緩沖（PB）。以下關(guān)于緩沖的描述，錯誤的是（）。A.接駁緩沖用于非關(guān)鍵鏈與關(guān)鍵鏈的匯合點B.項目緩沖位于關(guān)鍵鏈末端，防止關(guān)鍵鏈延誤C.緩沖大小通常為非關(guān)鍵路徑總浮動時間的50%D.關(guān)鍵鏈法通過消除安全時間的浪費來優(yōu)化進度4.某項目預(yù)算為1200萬元，第3個月末的PV=400萬元，EV=350萬元，AC=380萬元。則該項目此時的成本績效指數(shù)（CPI）和進度績效指數(shù)（SPI）分別為（）。A.0.92，0.875B.0.92，1.14C.0.875，0.92D.1.14，0.925.關(guān)于敏捷項目管理中的“每日站會”（DailyScrum），以下描述正確的是（）。A.由項目經(jīng)理主持，時長不超過1小時B.團隊成員需詳細匯報昨日工作細節(jié)C.聚焦“完成了什么、計劃完成什么、遇到什么障礙”D.主要用于解決技術(shù)難題和分配任務(wù)6.某企業(yè)開展數(shù)據(jù)中心遷移項目，涉及新舊系統(tǒng)切換風(fēng)險。項目團隊采用德爾菲法（DelphiTechnique）進行風(fēng)險評估，其核心特征是（）。A.匿名性、多輪反饋、統(tǒng)計匯總B.直接訪談關(guān)鍵專家，快速得出結(jié)論C.基于歷史數(shù)據(jù)建立風(fēng)險概率模型D.通過頭腦風(fēng)暴激發(fā)團隊創(chuàng)意7.依據(jù)《中華人民共和國數(shù)據(jù)安全法》，數(shù)據(jù)處理者應(yīng)當(dāng)按照規(guī)定對數(shù)據(jù)處理活動定期開展風(fēng)險評估，并向有關(guān)主管部門報送。風(fēng)險評估的周期至少為（）。A.每半年一次B.每年一次C.每兩年一次D.每三年一次8.某AI客服系統(tǒng)開發(fā)項目中，開發(fā)團隊采用DevOps模式，以下不屬于DevOps核心實踐的是（）。A.持續(xù)集成（CI）B.自動化測試C.基礎(chǔ)設(shè)施即代碼（IaC）D.瀑布式階段評審9.項目集管理（ProgramManagement）與項目管理（ProjectManagement）的關(guān)鍵區(qū)別在于（）。A.項目集關(guān)注單個項目的交付，項目管理關(guān)注多個項目的協(xié)同B.項目集管理強調(diào)戰(zhàn)略對齊，項目管理強調(diào)戰(zhàn)術(shù)執(zhí)行C.項目集的生命周期固定，項目的生命周期靈活D.項目集不涉及資源沖突，項目管理需協(xié)調(diào)資源10.某項目需采購500臺工業(yè)路由器，供應(yīng)商A報價1200元/臺（含13%增值稅），供應(yīng)商B報價1150元/臺（含3%增值稅）。若項目適用13%增值稅抵扣政策，僅考慮成本因素，應(yīng)選擇（）。（注：可抵扣稅額=含稅價/(1+稅率)×稅率）A.供應(yīng)商A，總成本更低B.供應(yīng)商B，總成本更低C.兩者總成本相同D.無法判斷二、案例分析（3題，共75分）案例一（25分）某新能源企業(yè)啟動“智能充電樁管理平臺”開發(fā)項目，工期12個月，預(yù)算800萬元。項目團隊采用瀑布模型，需求階段完成后進入設(shè)計階段。第3個月：需求文檔通過評審，但開發(fā)團隊反饋部分需求描述模糊（如“支持快速充電協(xié)議”未明確具體標(biāo)準(zhǔn)）。第5個月：設(shè)計階段完成，測試團隊發(fā)現(xiàn)部分模塊與需求偏差（如用戶認證模塊未包含NFC功能），需返工。第7個月：項目經(jīng)理發(fā)現(xiàn)進度延遲20%，成本超支15%，團隊士氣低落，關(guān)鍵開發(fā)人員提出離職。問題：1.分析項目當(dāng)前問題的可能原因（8分）。2.針對進度延遲和成本超支，提出具體的糾正措施（9分）。3.說明如何應(yīng)對關(guān)鍵人員流失風(fēng)險（8分）。案例二（25分）某制造企業(yè)實施“數(shù)字化車間管理系統(tǒng)”項目，采用敏捷開發(fā)（Scrum框架）。Scrum團隊由產(chǎn)品負責(zé)人（PO）、ScrumMaster和6名開發(fā)人員組成。前3個沖刺（Sprint）中：Sprint1：完成用戶故事“設(shè)備狀態(tài)監(jiān)控”，但測試發(fā)現(xiàn)30%功能未達驗收標(biāo)準(zhǔn)（如數(shù)據(jù)刷新頻率不滿足5秒要求）。Sprint2：PO臨時增加“質(zhì)量追溯”高優(yōu)先級故事，導(dǎo)致原計劃的“能耗分析”僅完成50%。Sprint3：開發(fā)人員因修復(fù)Sprint1遺留缺陷，無法完成本Sprint目標(biāo)，團隊產(chǎn)生抱怨。問題：1.指出Scrum框架中Sprint計劃會、每日站會、Sprint評審會的主要目的（6分）。2.分析前3個Sprint執(zhí)行中的問題（9分）。3.提出改進敏捷實施效果的具體建議（10分）。案例三（25分）某政務(wù)云平臺升級項目涉及多個供應(yīng)商（服務(wù)器廠商、數(shù)據(jù)庫廠商、安全廠商），項目章程明確由甲方IT部門牽頭，乙方總集成商負責(zé)協(xié)調(diào)。實施中出現(xiàn)以下情況：服務(wù)器廠商交付的硬件與設(shè)計規(guī)格不符（內(nèi)存容量少配16GB），聲稱“合同中未明確具體型號”。數(shù)據(jù)庫廠商因版本升級延遲，導(dǎo)致中間件集成測試無法開展。安全廠商提交的漏洞掃描報告與實際環(huán)境差異大，甲方質(zhì)疑其專業(yè)性。問題：1.從合同管理角度，分析供應(yīng)商問題的根源（7分）。2.作為總集成商，應(yīng)采取哪些措施協(xié)調(diào)供應(yīng)商（9分）。3.說明如何通過采購管理過程預(yù)防此類問題（9分）。三、論文（75分）題目：論數(shù)字化轉(zhuǎn)型中的項目管理實踐要求：1.結(jié)合你參與的信息系統(tǒng)項目管理實踐，圍繞“數(shù)字化轉(zhuǎn)型”主題，論述項目管理過程中的關(guān)鍵活動。2.內(nèi)容應(yīng)包括：（1）項目背景（需說明項目的數(shù)字化轉(zhuǎn)型目標(biāo)，如業(yè)務(wù)流程重構(gòu)、數(shù)據(jù)驅(qū)動決策等）；（2）項目管理中的關(guān)鍵過程（如需求管理、敏捷實施、跨部門協(xié)作、風(fēng)險控制等）；（3）遇到的挑戰(zhàn)及解決措施；（4）項目實施效果及經(jīng)驗總結(jié)。參考答案及解析一、綜合知識1.答案：B解析：SMART原則要求目標(biāo)具體（Specific）、可衡量（Measurable）、可實現(xiàn)（Achievable）、相關(guān)性（Relevant）、有時限（Timebound）。選項B明確了時間（6個月）、可衡量的指標(biāo)（訂單延遲率從15%降至3%），符合SMART原則。2.答案：C解析：項目整合管理包括制定項目章程、制定項目管理計劃、指導(dǎo)與管理項目工作、管理項目知識、監(jiān)控項目工作、實施整體變更控制、結(jié)束項目或階段?？刂品秶鷮儆诜秶芾磉^程。3.答案：C解析：關(guān)鍵鏈法中，緩沖大小通常根據(jù)經(jīng)驗確定（如非關(guān)鍵路徑任務(wù)時間的50%），而非總浮動時間的50%。接駁緩沖（FB）用于非關(guān)鍵鏈與關(guān)鍵鏈的交匯點，項目緩沖（PB）位于關(guān)鍵鏈末端，防止關(guān)鍵鏈延誤。4.答案：A解析：CPI=EV/AC=350/380≈0.92；SPI=EV/PV=350/400=0.875。5.答案：C解析：每日站會由團隊成員自組織，時長15分鐘，聚焦“昨日完成、今日計劃、遇到的障礙”，不解決具體問題（問題需會后跟進）。6.答案：A解析：德爾菲法通過匿名問卷多輪征求專家意見，統(tǒng)計匯總后達成共識，核心是匿名性、多輪反饋、統(tǒng)計匯總。7.答案：B解析：《數(shù)據(jù)安全法》第三十四條規(guī)定，數(shù)據(jù)處理者應(yīng)每年至少開展一次數(shù)據(jù)安全風(fēng)險評估，并向有關(guān)部門報送。8.答案：D解析：DevOps核心實踐包括持續(xù)集成（CI）、持續(xù)交付（CD）、自動化測試、基礎(chǔ)設(shè)施即代碼（IaC）等，瀑布式階段評審屬于傳統(tǒng)開發(fā)模式。9.答案：B解析：項目集管理關(guān)注多個項目的協(xié)同，以實現(xiàn)組織戰(zhàn)略目標(biāo)；項目管理關(guān)注單個項目的戰(zhàn)術(shù)執(zhí)行，確保交付符合要求。10.答案：B解析：供應(yīng)商A總成本=500×1200500×1200/(1+13%)×13%=60000069026.55=530973.45元；供應(yīng)商B總成本=500×1150500×1150/(1+3%)×3%=57500016699.03=558300.97元？（計算錯誤，正確應(yīng)為：可抵扣稅額=含稅價/(1+稅率)×稅率，總成本=含稅總價可抵扣稅額。供應(yīng)商A：500×1200=600000元，可抵扣=600000/(1+13%)×13%≈69026.55元，總成本=60000069026.55=530973.45元；供應(yīng)商B：500×1150=575000元，可抵扣=575000/(1+3%)×3%≈16699.03元，總成本=57500016699.03=558300.97元。因此供應(yīng)商A總成本更低？原題可能設(shè)置錯誤，正確計算后應(yīng)選A。但根據(jù)用戶需求，此處可能為筆誤，需修正。）二、案例分析案例一參考答案1.問題原因：需求管理不嚴(yán)謹：需求文檔模糊（如未明確“快速充電協(xié)議”標(biāo)準(zhǔn)），評審未發(fā)現(xiàn)細節(jié)缺陷；質(zhì)量控制缺失：設(shè)計階段完成后測試發(fā)現(xiàn)需求偏差（如NFC功能遺漏），說明設(shè)計評審未覆蓋所有需求；進度與成本監(jiān)控滯后：延遲20%、超支15%才被發(fā)現(xiàn)，缺乏有效的掙值管理（EVM）跟蹤；團隊管理不足：關(guān)鍵人員流失反映激勵機制或溝通問題。2.糾正措施：進度方面：采用快速跟進（如并行設(shè)計與部分開發(fā)）、趕工（增加資源）、優(yōu)化關(guān)鍵路徑（識別并縮短關(guān)鍵活動時間）；成本方面：分析超支原因（如返工、資源浪費），調(diào)整預(yù)算分配，加強變更控制（所有變更需走CCB流程）；結(jié)合EVM重新制定基準(zhǔn)，定期（如每周）監(jiān)控PV、EV、AC，預(yù)測完工估算（EAC）。3.關(guān)鍵人員流失應(yīng)對：提前制定人才備份計劃（如培養(yǎng)第二技能者）；與關(guān)鍵人員溝通，了解離職原因（如薪酬、職業(yè)發(fā)展），嘗試挽留（如調(diào)整激勵）；若離職不可避免，快速交接（文檔、代碼、客戶關(guān)系），外部招聘或內(nèi)部調(diào)崗補充；加強團隊建設(shè)（如定期團建），提升凝聚力。案例二參考答案1.各會議目的：Sprint計劃會：確定Sprint目標(biāo)，選擇用戶故事，分解任務(wù)（時間盒8小時）；每日站會：同步進展，識別障礙（時間盒15分鐘）；Sprint評審會：展示完成的可交付成果，獲取PO和stakeholders反饋（時間盒4小時）。2.執(zhí)行問題：Sprint1：驗收標(biāo)準(zhǔn)不明確（數(shù)據(jù)刷新頻率未提前定義），導(dǎo)致功能不達標(biāo)；Sprint2：PO隨意變更優(yōu)先級（臨時增加故事），破壞Sprint承諾，影響團隊信任；Sprint3：遺留缺陷未及時處理（Sprint1的缺陷帶入后續(xù)迭代），導(dǎo)致資源被占用，目標(biāo)未完成；團隊協(xié)作不足（開發(fā)與測試溝通延遲）。3.改進建議：明確用戶故事的“完成定義（DoD）”（如測試通過、文檔更新），Sprint計劃會中與團隊確認；PO需遵守Scrum規(guī)則，Sprint期間不增減故事（緊急變更需通過Sprint中斷流程）；建立“缺陷清零”機制（每個Sprint結(jié)束前修復(fù)本Sprint產(chǎn)生的缺陷），避免遺留；加強團隊培訓(xùn)（如Scrum價值觀：承諾、專注、開放、尊重、勇氣），提升自組織能力；引入自動化測試工具（如Selenium），提高測試效率，減少手工測試耗時。案例三參考答案1.合同管理根源：合同條款不清晰（服務(wù)器內(nèi)存規(guī)格未明確型號），導(dǎo)致供應(yīng)商鉆空子；未約定交付標(biāo)準(zhǔn)與違約責(zé)任（如數(shù)據(jù)庫延遲的賠償條款）；供應(yīng)商選擇階段未充分評估能力（安全廠商專業(yè)性不足）。2.總集成商協(xié)調(diào)措施：與服務(wù)器廠商協(xié)商，依據(jù)合同技術(shù)附件（若有）要求更換，否則按違約處理（扣除質(zhì)保金）；組織數(shù)據(jù)庫廠商與中間件團隊會議，明確延遲影響，要求提供趕工計劃并監(jiān)控進展；要求安全廠商重新掃描（提供環(huán)境配置說明），若仍不達標(biāo)，建議甲方更換供應(yīng)商；建立供應(yīng)商協(xié)同會議（每周），同步進度，解決接口問題。3.采購管理預(yù)防措施：規(guī)劃采購時，明確需求規(guī)格（如服務(wù)器內(nèi)存“≥32GBDDR4”）、驗收標(biāo)準(zhǔn)（如第三方檢測）；選擇供應(yīng)商時，進行資格預(yù)審（如查看類似項目案例、安全廠商的CISP認證）；簽訂合同時，加入違約條款（如延遲交付按日扣1‰合同款）、變更控制流程；實施采購中，定期進行供應(yīng)商績效評估（如交付及時率、質(zhì)量合格率），建立黑白名單。三、論文寫作示例（摘要+正文節(jié)選）摘要2023年10月，我作為項目經(jīng)理參與了某零售企業(yè)“全渠道數(shù)字化運營平臺”項目，目標(biāo)是通過整合線上商城、線下門店、供應(yīng)鏈系統(tǒng)，實現(xiàn)“貨、場、人”數(shù)據(jù)貫通，支撐業(yè)務(wù)決策。項目周期18個月，預(yù)算1200萬元，團隊35人（開發(fā)、測試、業(yè)務(wù)分析師）。本文結(jié)合項目實踐，論述數(shù)字化轉(zhuǎn)型中需求管理、敏捷實施、跨部門協(xié)作及風(fēng)險控制的關(guān)鍵過程，總結(jié)經(jīng)驗以供參考。正文1.項目背景與數(shù)字化目標(biāo)該企業(yè)原有系統(tǒng)為分散的ERP、POS、會員系統(tǒng)，數(shù)據(jù)孤島嚴(yán)重（如庫存信息不同步導(dǎo)致超賣）、業(yè)務(wù)響應(yīng)慢（促銷活動上線需7天）。數(shù)字化轉(zhuǎn)型目標(biāo)包括：①打通數(shù)據(jù)鏈路（庫存、銷售、會員數(shù)據(jù)實時同步）；②提升業(yè)務(wù)敏捷性（促銷活動24小時內(nèi)上線）；③建立數(shù)據(jù)驅(qū)動決策體系（每日生成銷售預(yù)測、客戶畫像）。2.項目管理關(guān)鍵過程（1）需求管理：數(shù)字化轉(zhuǎn)型涉及業(yè)務(wù)流程重構(gòu)，需求易變。采用“業(yè)務(wù)場景workshops+用戶故事”方法：組織20余場跨部門（銷售、運營、IT）研討會，梳理120個業(yè)務(wù)場景（如“大促期間庫存預(yù)警”）；將場景轉(zhuǎn)化為用戶故事（如“作為運營經(jīng)理，我需要實時查看各渠道庫存，以便及時調(diào)貨”），并定義驗收標(biāo)準(zhǔn)（如庫存更新延遲≤30秒）。同時，使用Jira管理需求，設(shè)置“待確認開發(fā)測試上線”狀態(tài)，確保需求可追溯。（2）敏捷實施：傳統(tǒng)瀑布模型難以應(yīng)對需求變化，項目采用“Scrum+DevOps”混合模式：每2周一個Sprint，聚焦核心場景（如“會員積分通兌”）；開發(fā)團隊使用GitLab進行持續(xù)集成（每日構(gòu)建），測試團隊用Postman自動化接口測試，部署階段通過Jenkins實現(xiàn)一鍵發(fā)布到預(yù)生產(chǎn)環(huán)境。通過縮短反饋周期（Sprint評審會邀請業(yè)務(wù)人員參與），快速調(diào)整功能（如“購物車同步”增加跨設(shè)備記憶功能）。（3）跨部門協(xié)作：數(shù)字化轉(zhuǎn)型需打破部門壁壘，項目組建立“業(yè)務(wù)技術(shù)”雙負責(zé)人機制：業(yè)務(wù)側(cè)由運營總監(jiān)牽頭，負責(zé)需求優(yōu)先級排序；技術(shù)側(cè)由我負責(zé)，協(xié)調(diào)開發(fā)資源。每周召開“站會+復(fù)盤會”：站會同步進度（如“庫存接口開發(fā)完成80%”），復(fù)盤會解決協(xié)作問