2025年工信部軟考考試試題及答案一、單項(xiàng)選擇題（每題1分，共75題）1.某企業(yè)啟動(dòng)智能工廠改造項(xiàng)目，在項(xiàng)目章程中明確“通過部署工業(yè)互聯(lián)網(wǎng)平臺(tái)實(shí)現(xiàn)設(shè)備聯(lián)網(wǎng)率提升至90%，生產(chǎn)效率提高20%”，這體現(xiàn)了項(xiàng)目章程的哪項(xiàng)核心作用？A.授權(quán)項(xiàng)目經(jīng)理B.定義項(xiàng)目高層級需求C.確定項(xiàng)目預(yù)算D.明確項(xiàng)目驗(yàn)收標(biāo)準(zhǔn)答案：B2.關(guān)于數(shù)據(jù)要素市場化配置，以下表述錯(cuò)誤的是：A.數(shù)據(jù)確權(quán)應(yīng)遵循“誰收集誰所有”原則B.數(shù)據(jù)交易需建立合規(guī)性評估機(jī)制C.公共數(shù)據(jù)開放應(yīng)分級分類管理D.數(shù)據(jù)資產(chǎn)入表需滿足可計(jì)量、可控制條件答案：A3.某項(xiàng)目采用敏捷開發(fā)，迭代周期為2周。第3次迭代中，開發(fā)團(tuán)隊(duì)發(fā)現(xiàn)用戶故事“訂單自動(dòng)分倉”需要調(diào)用外部物流接口，但未在需求文檔中說明。此時(shí)最合理的處理方式是：A.直接修改需求文檔，增加接口調(diào)用需求B.提交變更請求，評估對迭代目標(biāo)的影響C.推遲該用戶故事到下一次迭代D.要求產(chǎn)品負(fù)責(zé)人立即澄清需求答案：D4.依據(jù)《信息系統(tǒng)項(xiàng)目管理師教程（第4版）》，以下不屬于項(xiàng)目管理知識(shí)領(lǐng)域的是：A.需求管理B.資源管理C.相關(guān)方管理D.采購管理答案：A5.某云計(jì)算項(xiàng)目進(jìn)行成本估算時(shí)，采用參數(shù)估算，已知類似項(xiàng)目服務(wù)器采購成本為100萬元（服務(wù)器數(shù)量100臺(tái)，單價(jià)1萬元），當(dāng)前項(xiàng)目需部署150臺(tái)服務(wù)器，且單價(jià)上漲5%，則服務(wù)器采購成本估算為：A.150萬元B.157.5萬元C.162萬元D.175萬元答案：B（計(jì)算：150臺(tái)×1萬元×1.05=157.5萬元）6.關(guān)于網(wǎng)絡(luò)安全等級保護(hù)2.0，以下說法正確的是：A.第一級系統(tǒng)由運(yùn)營者自行保護(hù)B.第三級系統(tǒng)需定期開展?jié)B透測試C.第四級系統(tǒng)由國家關(guān)鍵信息基礎(chǔ)設(shè)施保護(hù)D.第五級系統(tǒng)由公安部直接監(jiān)管答案：A7.某項(xiàng)目進(jìn)度績效指數(shù)（SPI）為0.85，成本績效指數(shù)（CPI）為1.02，此時(shí)項(xiàng)目經(jīng)理應(yīng)優(yōu)先采取的措施是：A.增加資源趕工B.優(yōu)化工作流程提高效率C.調(diào)整預(yù)算基準(zhǔn)D.分析進(jìn)度偏差根本原因答案：D8.依據(jù)《政府采購法》，采用競爭性談判方式采購的，談判小組由采購人代表和評審專家共（）人以上單數(shù)組成，其中專家不得少于成員總數(shù)的（）。A.3，2/3B.5，1/2C.3，1/2D.5，2/3答案：A9.區(qū)塊鏈技術(shù)在供應(yīng)鏈金融中的應(yīng)用主要解決的核心問題是：A.數(shù)據(jù)存儲(chǔ)容量問題B.多方信任與數(shù)據(jù)不可篡改C.交易處理速度問題D.智能合約執(zhí)行效率答案：B10.某項(xiàng)目進(jìn)行風(fēng)險(xiǎn)定性分析，使用概率和影響矩陣對風(fēng)險(xiǎn)排序。某風(fēng)險(xiǎn)發(fā)生概率為60%，對項(xiàng)目進(jìn)度的影響等級為“嚴(yán)重（0.7）”，對成本的影響等級為“中等（0.4）”，則該風(fēng)險(xiǎn)的綜合影響值為：A.0.6×(0.7+0.4)/2=0.33B.0.6×max(0.7,0.4)=0.42C.0.6×0.7+0.6×0.4=0.66D.取進(jìn)度和成本影響的較大值0.7，綜合值0.6×0.7=0.42答案：D（通常取對項(xiàng)目目標(biāo)影響最大的維度計(jì)算）二、案例分析題（每題25分，共3題）案例一：某制造企業(yè)啟動(dòng)“智能質(zhì)檢系統(tǒng)”開發(fā)項(xiàng)目，工期6個(gè)月，預(yù)算480萬元。項(xiàng)目團(tuán)隊(duì)包括需求分析師2人、開發(fā)工程師5人、測試工程師3人、項(xiàng)目經(jīng)理1人。執(zhí)行到第3個(gè)月末時(shí)，發(fā)生以下情況：1.原計(jì)劃完成需求確認(rèn)、系統(tǒng)設(shè)計(jì)、原型開發(fā)三個(gè)階段，實(shí)際完成需求確認(rèn)（100%）、系統(tǒng)設(shè)計(jì)（80%）、原型開發(fā)（30%）；2.已發(fā)提供本220萬元，其中需求確認(rèn)階段實(shí)際成本50萬元（預(yù)算45萬元），系統(tǒng)設(shè)計(jì)階段實(shí)際成本120萬元（預(yù)算100萬元），原型開發(fā)階段實(shí)際成本50萬元（預(yù)算80萬元）；3.關(guān)鍵開發(fā)工程師張某因家庭原因提出離職，交接周期需1個(gè)月；4.客戶提出新增“與MES系統(tǒng)對接”功能需求，要求在驗(yàn)收前完成。問題1：計(jì)算項(xiàng)目當(dāng)前的PV、EV、AC，并分析成本和進(jìn)度績效。問題2：針對開發(fā)工程師離職風(fēng)險(xiǎn)，提出3項(xiàng)應(yīng)對措施。問題3：處理客戶新增需求的合理流程是什么？答案：問題1：PV（計(jì)劃價(jià)值）=需求確認(rèn)預(yù)算45萬+系統(tǒng)設(shè)計(jì)預(yù)算100萬+原型開發(fā)預(yù)算80萬×（3/6，假設(shè)按階段平均分配？需明確階段權(quán)重）→實(shí)際項(xiàng)目中階段權(quán)重通常按工作量占比，假設(shè)需求確認(rèn)（20%）、系統(tǒng)設(shè)計(jì)（30%）、原型開發(fā)（30%）、測試（20%），則前3月PV=480萬×(20%+30%+30%×(3/3))=480×80%=384萬？但更準(zhǔn)確的是按各階段預(yù)算：需求確認(rèn)45萬（100%）、系統(tǒng)設(shè)計(jì)100萬（100%計(jì)劃）、原型開發(fā)80萬（100%計(jì)劃），則PV=45+100+80=225萬（假設(shè)階段按順序執(zhí)行，前3月應(yīng)完成這三個(gè)階段）。EV（掙值）=需求確認(rèn)45萬×100%+系統(tǒng)設(shè)計(jì)100萬×80%+原型開發(fā)80萬×30%=45+80+24=149萬AC（實(shí)際成本）=50+120+50=220萬CPI=EV/AC=149/220≈0.68（成本超支）SPI=EV/PV=149/225≈0.66（進(jìn)度嚴(yán)重滯后）問題2：（1）立即啟動(dòng)內(nèi)部調(diào)崗，從其他項(xiàng)目組協(xié)調(diào)有類似經(jīng)驗(yàn)的開發(fā)人員臨時(shí)支援；（2）與張某協(xié)商延長交接期，明確關(guān)鍵任務(wù)清單，要求其完成核心模塊的代碼注釋和接口文檔；（3）調(diào)整項(xiàng)目計(jì)劃，將張某負(fù)責(zé)的模塊拆分，由其他工程師并行開發(fā)，增加每日站會(huì)跟蹤進(jìn)度；（4）考慮外部招聘，聯(lián)系獵頭尋找有智能質(zhì)檢系統(tǒng)開發(fā)經(jīng)驗(yàn)的工程師，作為備用方案。問題3：（1）接收需求：與客戶對接人確認(rèn)新增需求的具體功能、接口規(guī)范、數(shù)據(jù)格式等細(xì)節(jié)；（2）評估影響：組織技術(shù)團(tuán)隊(duì)分析該需求對系統(tǒng)架構(gòu)、開發(fā)工作量、測試范圍、項(xiàng)目工期和成本的影響；（3）提交變更請求：編制變更申請單，包括需求描述、評估結(jié)果（預(yù)計(jì)增加開發(fā)工時(shí)80人天，工期延長2周，成本增加35萬元）；（4）變更審批：提交變更控制委員會(huì)（CCB）審批，需客戶代表、項(xiàng)目經(jīng)理、技術(shù)負(fù)責(zé)人共同確認(rèn)；（5）實(shí)施變更：審批通過后，更新項(xiàng)目管理計(jì)劃（進(jìn)度計(jì)劃、成本基準(zhǔn)、需求文檔等），通知相關(guān)方；（6）跟蹤驗(yàn)證：在開發(fā)和測試階段重點(diǎn)關(guān)注該功能的實(shí)現(xiàn)情況，驗(yàn)收時(shí)進(jìn)行專項(xiàng)測試。案例二：某政務(wù)云平臺(tái)項(xiàng)目采用總分包模式，主包方A公司負(fù)責(zé)整體集成，分包方B公司負(fù)責(zé)服務(wù)器采購與部署，分包方C公司負(fù)責(zé)安全運(yùn)維。項(xiàng)目執(zhí)行中出現(xiàn)以下問題：B公司未按合同約定時(shí)間交付服務(wù)器，導(dǎo)致集成工作延誤2周；C公司在安全測試中發(fā)現(xiàn)平臺(tái)存在SQL注入漏洞，要求A公司修改代碼，A公司認(rèn)為是C公司測試方法不當(dāng)；客戶投訴項(xiàng)目周報(bào)信息不完整，關(guān)鍵風(fēng)險(xiǎn)未及時(shí)披露。問題1：分析B公司延誤的責(zé)任歸屬及處理方式。問題2：如何解決A公司與C公司的爭議？問題3：改進(jìn)項(xiàng)目溝通管理的具體措施有哪些？答案：問題1：責(zé)任歸屬：B公司作為分包方，未履行合同中“交付時(shí)間”條款，應(yīng)承擔(dān)主要責(zé)任。主包方A公司對分包管理存在失職，未提前監(jiān)控B公司進(jìn)度，需承擔(dān)連帶責(zé)任。處理方式：（1）A公司立即與B公司召開緊急會(huì)議，要求其增加資源（如臨時(shí)租賃備用服務(wù)器）追趕進(jìn)度，明確新的交付時(shí)間節(jié)點(diǎn)；（2）依據(jù)合同中的違約條款，扣除B公司部分履約保證金（如合同約定每延誤1天扣0.5%合同額）；（3）向客戶提交進(jìn)度偏差報(bào)告，說明延誤原因及補(bǔ)救措施，爭取客戶諒解；（4）更新項(xiàng)目進(jìn)度計(jì)劃，調(diào)整后續(xù)集成工作的資源分配，通過并行工作減少總工期影響。問題2：（1）組織三方（A、C、客戶）技術(shù)專家對漏洞進(jìn)行復(fù)現(xiàn)驗(yàn)證，使用標(biāo)準(zhǔn)化測試工具（如OWASPZAP）重新檢測；（2）若確認(rèn)是代碼漏洞，A公司需立即修復(fù)，并由C公司重新測試直至通過；（3）若因C公司測試用例設(shè)計(jì)不合理導(dǎo)致誤報(bào)，C公司需調(diào)整測試方案，重新執(zhí)行測試；（4）在合同中補(bǔ)充明確“漏洞認(rèn)定標(biāo)準(zhǔn)”（如參考CVE漏洞庫）和“測試方法規(guī)范”，避免后續(xù)爭議；（5）建立技術(shù)問題協(xié)商機(jī)制，每周召開技術(shù)協(xié)調(diào)會(huì)，及時(shí)解決接口、標(biāo)準(zhǔn)等問題。問題3：（1）制定溝通管理計(jì)劃，明確周報(bào)內(nèi)容模板（包括進(jìn)度狀態(tài)、成本偏差、風(fēng)險(xiǎn)登記冊更新、待解決事項(xiàng)）；（2）增加關(guān)鍵風(fēng)險(xiǎn)的預(yù)警機(jī)制，對風(fēng)險(xiǎn)等級為“高”的事項(xiàng)需在24小時(shí)內(nèi)通過郵件+電話雙重通知相關(guān)方；（3）建立分層溝通渠道：日常問題通過項(xiàng)目管理工具（如飛書、釘釘）溝通，重大問題召開現(xiàn)場會(huì)議；（4）定期組織客戶滿意度調(diào)查，每兩周與客戶代表進(jìn)行1次非正式溝通，了解其隱性需求；（5）培訓(xùn)項(xiàng)目團(tuán)隊(duì)溝通技巧，特別是如何用客戶易懂的語言（非技術(shù)術(shù)語）描述技術(shù)問題。案例三：某科技公司研發(fā)“智能客服機(jī)器人”項(xiàng)目，采用Scrum框架。在第5次迭代（2周周期）中，出現(xiàn)以下情況：產(chǎn)品待辦列表（ProductBacklog）中有12個(gè)用戶故事，故事點(diǎn)總計(jì)60點(diǎn)（團(tuán)隊(duì)速率為30點(diǎn)/迭代）；開發(fā)人員在迭代第3天發(fā)現(xiàn)“多輪對話引擎”需要NLP模型支持，但未在故事中說明，需額外5個(gè)故事點(diǎn)；測試人員反饋前一次迭代遺留的3個(gè)缺陷（嚴(yán)重等級）需在本次迭代修復(fù)，預(yù)計(jì)占用8個(gè)故事點(diǎn)；客戶要求將“微信公眾號接入”故事（8個(gè)故事點(diǎn)）提前至本次迭代。問題1：本次迭代計(jì)劃的用戶故事點(diǎn)數(shù)是否合理？說明原因。問題2：如何處理新增的NLP模型需求？問題3：平衡客戶需求與迭代目標(biāo)的策略有哪些？答案：問題1：不合理。團(tuán)隊(duì)速率為30點(diǎn)/迭代，原計(jì)劃60點(diǎn)遠(yuǎn)超團(tuán)隊(duì)處理能力。正確的迭代待辦列表（SprintBacklog）應(yīng)根據(jù)歷史速率選擇不超過30點(diǎn)的用戶故事。可能是產(chǎn)品負(fù)責(zé)人（PO）未合理排序或高估團(tuán)隊(duì)能力。問題2：（1）立即召開每日站會(huì)（DailyScrum），向ScrumMaster和團(tuán)隊(duì)同步該需求；（2）由產(chǎn)品負(fù)責(zé)人（PO）與客戶確認(rèn)“多輪對話引擎”是否為本次迭代的核心功能，若為必須，則評估其對迭代目標(biāo)的影響；（3）調(diào)整迭代待辦列表：若NLP模型是關(guān)鍵依賴，需將原計(jì)劃中的低優(yōu)先級故事（如“短信接口開發(fā)”）移出，騰出5個(gè)故事點(diǎn)；（4）更新故事描述，補(bǔ)充NLP模型的技術(shù)要求，并與NLP團(tuán)隊(duì)協(xié)調(diào)資源支持；（5）在迭代回顧會(huì)議（SprintRetrospective）中分析需求遺漏原因，優(yōu)化需求細(xì)化流程（如增加技術(shù)評審環(huán)節(jié)）。問題3：（1）建立需求優(yōu)先級排序機(jī)制，使用MoSCoW法（必須有、應(yīng)該有、可以有、不會(huì)有）對客戶需求分類；（2）在迭代計(jì)劃會(huì)議（SprintPlanning）中與客戶明確：本次迭代目標(biāo)是“完成核心對話功能開發(fā)”，超出目標(biāo)的需求需評估對目標(biāo)的影響；（3）對于客戶緊急需求，若不影響迭代目標(biāo)，可替換迭代待辦列表中低優(yōu)先級故事（需團(tuán)隊(duì)同意）；（4）定期向客戶展示迭代增量（SprintReview），通過可運(yùn)行的軟件讓客戶直觀看到進(jìn)展，減少非必要需求變更；（5）設(shè)置“緩沖故事點(diǎn)”（如預(yù)留10%的速率），用于處理臨時(shí)缺陷修復(fù)或小需求調(diào)整，本次案例中遺留缺陷8點(diǎn)可使用緩沖點(diǎn)。三、論文題（75分）論數(shù)字化轉(zhuǎn)型背景下的IT項(xiàng)目需求管理實(shí)踐隨著企業(yè)數(shù)字化轉(zhuǎn)型的深入，IT項(xiàng)目需求的復(fù)雜性和動(dòng)態(tài)性顯著增加。需求管理作為項(xiàng)目成功的關(guān)鍵環(huán)節(jié)，需要在需求獲取、分析、驗(yàn)證和控制等方面采取科學(xué)方法。請結(jié)合實(shí)際項(xiàng)目經(jīng)驗(yàn)，論述以下內(nèi)容：1.數(shù)字化轉(zhuǎn)型對IT項(xiàng)目需求管理提出的新挑戰(zhàn)；2.需求管理過程中采用的關(guān)鍵方法與工具；3.實(shí)施需求管理的具體實(shí)踐及取得的成效。答案（摘要）：在某制造企業(yè)“數(shù)字化車間管理系統(tǒng)”項(xiàng)目中，筆者作為項(xiàng)目經(jīng)理，針對數(shù)字化轉(zhuǎn)型帶來的需求模糊性、跨部門協(xié)同難、技術(shù)融合度高等挑戰(zhàn)，采用“用戶旅程圖+敏捷需求迭代”的管理方法，結(jié)合Jira需求管理工具，有效控制了需求變更。具體實(shí)踐包括：（1）需求獲取階段：組織跨部門workshops（生產(chǎn)、工藝、IT、設(shè)備部門），使用用戶旅程圖梳理從訂單下達(dá)、排產(chǎn)、加工到質(zhì)檢的全流程痛點(diǎn)，識(shí)別出“設(shè)備OEE實(shí)時(shí)計(jì)算”“質(zhì)量異常預(yù)警”等23個(gè)核心需求；（2）需求分析階段：采用用例建模（UseCase）明確每個(gè)需求的參與者、前置條件和流程步驟，通過故事點(diǎn)估算（斐波那契數(shù)列）量化開發(fā)工作量，避免需求鍍金；（3）需求驗(yàn)證階段：每周進(jìn)行原型評審（Axure原