2023上半年系統(tǒng)集成項目管理工程師練習題及答案一、單項選擇題（共75題，每題1分，每題的備選項中，只有1個最符合題意）1.關于信息系統(tǒng)集成特點的描述，正確的是：A.以硬件集成為核心，軟件和服務為輔助B.強調(diào)各組件的獨立運行能力C.需滿足用戶對整體性能的需求D.技術導向優(yōu)先于客戶需求導向答案：C解析：信息系統(tǒng)集成的核心是滿足用戶對整體系統(tǒng)的需求，強調(diào)各組件的協(xié)同工作而非獨立運行，以客戶需求為導向，軟硬件和服務需有機結合，因此選C。2.某項目采用敏捷開發(fā)模式，在迭代規(guī)劃會議中，團隊確定了本次迭代的用戶故事。該活動屬于敏捷項目管理的：A.沖刺計劃會議B.每日站會C.沖刺評審會議D.沖刺回顧會議答案：A解析：敏捷開發(fā)中，沖刺計劃會議（SprintPlanning）的主要任務是確定迭代目標和待完成的用戶故事，每日站會是每日同步進展，評審會議是展示成果，回顧會議是總結改進，故選A。3.以下不屬于項目管理十大知識領域的是：A.干系人管理B.需求管理C.資源管理D.采購管理答案：B解析：PMBOK指南（第7版）十大知識領域包括整合、范圍、進度、成本、質(zhì)量、資源、溝通、風險、采購、干系人管理，需求管理屬于范圍管理的子過程，因此選B。4.某項目的進度績效指數(shù)（SPI）為0.8，成本績效指數(shù)（CPI）為1.2，此時項目的狀態(tài)是：A.進度超前，成本超支B.進度滯后，成本節(jié)約C.進度超前，成本節(jié)約D.進度滯后，成本超支答案：B解析：SPI<1表示進度滯后，CPI>1表示成本節(jié)約，因此選B。5.關于云計算服務模式的描述，正確的是：A.IaaS提供操作系統(tǒng)和開發(fā)環(huán)境B.PaaS提供服務器、存儲和網(wǎng)絡C.SaaS提供完整的應用服務D.DaaS提供數(shù)據(jù)庫管理服務答案：C解析：IaaS（基礎設施即服務）提供服務器、存儲、網(wǎng)絡等基礎資源；PaaS（平臺即服務）提供開發(fā)環(huán)境、中間件等；SaaS（軟件即服務）提供完整應用（如郵件系統(tǒng)）；DaaS（數(shù)據(jù)即服務）提供數(shù)據(jù)服務，故選C。6.項目章程的批準人通常是：A.項目經(jīng)理B.項目團隊C.高級管理層D.客戶代表答案：C解析：項目章程由項目啟動者或發(fā)起人批準，通常是高級管理層或項目組合經(jīng)理，故選C。7.某項目的網(wǎng)絡圖中，活動A的最早開始時間（ES）為第3天，持續(xù)時間5天；活動B與A完成后開始，ES為第9天，持續(xù)時間3天。則活動A的自由浮動時間（FF）為：A.0天B.1天C.2天D.3天答案：B解析：活動A的最早完成時間（EF）=3+5=8天；活動B的ES=9天，因此A的自由浮動時間=B的ESA的EF=98=1天，故選B。8.以下屬于配置管理中“基線”的是：A.需求文檔的草稿版本B.經(jīng)過評審并正式發(fā)布的設計文檔C.開發(fā)過程中修改的代碼臨時版本D.測試團隊提交的缺陷報告答案：B解析：基線是經(jīng)過正式評審和批準的配置項，作為后續(xù)開發(fā)的基準，草稿、臨時版本、缺陷報告不屬于基線，故選B。9.根據(jù)《中華人民共和國政府采購法》，政府采購的主要方式是：A.競爭性談判B.單一來源采購C.公開招標D.詢價答案：C解析：政府采購法規(guī)定，公開招標是主要采購方式，其他方式為補充，故選C。10.風險管理過程中，“對風險發(fā)生的概率和影響進行量化分析”屬于：A.風險識別B.風險定性分析C.風險定量分析D.風險應對規(guī)劃答案：C解析：風險定量分析是對概率和影響進行數(shù)值化分析，定性分析是相對等級評估，故選C。（注：因篇幅限制，此處僅展示前10題，實際考試含75題，后續(xù)題目覆蓋范圍管理、質(zhì)量管理、溝通管理、合同管理等領域，例如：范圍說明書的內(nèi)容、質(zhì)量控制工具（如因果圖）、溝通渠道計算、合同類型選擇等。）二、案例分析題（共3題，每題25分，共75分）案例一：進度管理問題某公司承接了一個企業(yè)資源計劃（ERP）系統(tǒng)開發(fā)項目，合同工期180天。項目網(wǎng)絡圖如下（單位：天）：```A(30)→B(40)→D(50)→H(30)A→C(25)→E(35)→HB→F(20)→G(30)→H```問題1：計算項目的關鍵路徑和總工期。問題2：若活動D延遲10天，是否影響總工期？說明理由。問題3：為確保項目按原工期完成，可采取哪些趕工措施？答案：問題1：關鍵路徑是最長路徑，計算各路徑長度：A→B→D→H：30+40+50+30=150天A→C→E→H：30+25+35+30=120天A→B→F→G→H：30+40+20+30+30=150天因此關鍵路徑為A→B→D→H和A→B→F→G→H，總工期150天。問題2：活動D在關鍵路徑A→B→D→H上，原持續(xù)時間50天，延遲10天后變?yōu)?0天，該路徑長度變?yōu)?0+40+60+30=160天，超過原總工期150天，因此會導致總工期延遲10天。問題3：趕工措施包括：①增加資源（如安排更多開發(fā)人員）縮短關鍵活動時間（如D、B、F、G）；②并行處理部分活動（如F和D是否可部分重疊）；③優(yōu)化活動順序（如調(diào)整H的依賴關系，提前開始部分工作）；④采用更高效的技術或工具（如自動化測試工具減少測試時間）。案例二：成本管理問題某項目計劃工期6個月，預算總成本（BAC）為600萬元。第3個月末，實際成本（AC）為320萬元，掙值（EV）為280萬元，計劃價值（PV）為300萬元。問題1：計算成本偏差（CV）、進度偏差（SV）、成本績效指數(shù)（CPI）、進度績效指數(shù)（SPI）。問題2：分析項目當前的成本和進度狀態(tài)。問題3：提出成本控制的具體措施。答案：問題1：CV=EVAC=280320=40萬元；SV=EVPV=280300=20萬元；CPI=EV/AC=280/320=0.875；SPI=EV/PV=280/300≈0.933。問題2：CV<0（40萬元），CPI<1（0.875），說明成本超支；SV<0（20萬元），SPI<1（0.933），說明進度滯后。問題3：成本控制措施：①分析超支原因（如資源浪費、需求變更），針對性調(diào)整；②加強變更管理，嚴格審批范圍變更；③優(yōu)化資源分配（如減少非關鍵活動的資源投入）；④與供應商協(xié)商降低采購成本；⑤對團隊進行成本意識培訓，避免返工。案例三：溝通管理問題某項目團隊包括開發(fā)組（8人）、測試組（5人）、客戶代表（2人）、項目經(jīng)理1人。項目執(zhí)行中，客戶頻繁抱怨需求理解偏差，開發(fā)組反饋測試組提交的缺陷報告不清晰，團隊會議效率低下。問題1：計算當前團隊的溝通渠道數(shù)。問題2：分析溝通問題的可能原因。問題3：提出溝通改進措施。答案：問題1：溝通渠道數(shù)公式：n(n1)/2，n=8+5+2+1=16人，渠道數(shù)=16×15/2=120條。問題2：可能原因：①溝通需求分析不足，未明確各角色的信息需求；②溝通方式選擇不當（如缺陷報告模板不規(guī)范）；③溝通頻率不合理（客戶需求變更未及時同步）；④會議缺乏準備（無議程、無結論跟蹤）；⑤干系人參與度低（客戶未充分參與需求確認）。問題3：改進措施：①制定溝通管理計劃，明確各干系人的溝通需求、方式、頻率；②標準化文檔模板（如缺陷報告模板包含步驟、預期結果）；③增加客戶需求確認會議（如每周需求評審）；④優(yōu)化會議流程（會前發(fā)議程、會中記錄決議、會后跟蹤落實）；⑤使用協(xié)作工具（如Jira跟蹤缺陷，騰訊文檔共享需求）。三、論文題（共1題，75分）題目：論信息系統(tǒng)項目的范圍管理要求：結合你參與的信息系統(tǒng)項目，論述范圍管理的過程及實踐經(jīng)驗。范文：在數(shù)字化轉型背景下，我于2022年擔任某制造企業(yè)“生產(chǎn)管理系統(tǒng)”項目的項目經(jīng)理，負責系統(tǒng)的需求分析、開發(fā)及上線。項目目標是實現(xiàn)生產(chǎn)計劃、物料追蹤、質(zhì)量檢測的全流程數(shù)字化，涉及生產(chǎn)部、物流部、質(zhì)檢部等多個部門，預算800萬元，工期12個月。以下結合該項目，論述范圍管理的具體實踐。一、規(guī)劃范圍管理項目啟動后，我組織核心團隊（需求分析師、部門代表）召開范圍規(guī)劃會議。首先，通過訪談和問卷調(diào)查收集干系人需求：生產(chǎn)部希望實時查看設備狀態(tài)，物流部要求與ERP系統(tǒng)對接，質(zhì)檢部需要缺陷追溯功能。結合《PMBOK指南》，我們制定了《范圍管理計劃》，明確范圍定義工具（需求跟蹤矩陣）、確認方法（用戶簽字確認）、控制流程（變更申請→評估→審批→更新）。同時，制定《需求管理計劃》，規(guī)定需求變更的觸發(fā)條件（如影響成本超5%需高層審批），為后續(xù)工作奠定基礎。二、收集需求與定義范圍收集需求階段，我們采用用戶故事（UserStory）和原型法。例如，針對生產(chǎn)部“設備狀態(tài)監(jiān)控”需求，繪制了包含設備編號、運行狀態(tài)、故障預警的原型圖，通過3輪迭代確認細節(jié)。隨后，將分散的需求整理為《需求規(guī)格說明書》，明確功能點（如生產(chǎn)計劃排程、物料齊套檢查）和非功能需求（響應時間≤2秒）。為避免范圍蔓延，我們使用WBS（工作分解結構）將項目分解為需求分析、系統(tǒng)設計、開發(fā)、測試、上線5個階段，每個階段再分解為子任務（如“系統(tǒng)設計”分解為架構設計、數(shù)據(jù)庫設計、接口設計），WBS最底層為可交付物（如《數(shù)據(jù)庫ER圖》）。三、確認范圍與控制范圍確認范圍階段，我們組織各部門代表對可交付物進行驗收。例如，完成“生產(chǎn)計劃模塊”開發(fā)后，邀請生產(chǎn)部經(jīng)理進行功能測試，發(fā)現(xiàn)“排程規(guī)則不支持緊急訂單插單”的問題，通過需求跟蹤矩陣定位到原始需求未明確該場景，經(jīng)協(xié)商補充需求并更新范圍基準?？刂品秶鷷r，建立變更管理委員會（CCB），包含客戶代表、技術總監(jiān)、財務總監(jiān)。項目中期，客戶提出增加“移動端審批”功能，經(jīng)評估需額外投入30萬元、工期延長1個月，CCB認為該功能非核心，建議二期實現(xiàn)，避免了范圍失控。