第2題： 某系統(tǒng)集成公司承接“某市智慧校園教務管理系統(tǒng)開發(fā)項目”，項目需完成學生信息管理課程調度、成績統(tǒng)計3大核心模塊的研發(fā)，需符合國家標準《信息技術軟件產品質量要求與評價》中“軟件功能性、可靠性、易用性”三級要求。任命質量保證工程師趙某負責過程合規(guī)審查，測試工程師孫某負責缺陷跟蹤，項目經理劉某負責質量決策與資源協(xié)調。
趙某編制了項目質量管理計劃，明確需求覆蓋率≥95%、軟件缺陷率≤0.4個/千行代碼、測試用例通過率≥92%三項目標。項目設定需求基線評審、詳細設計評審、單元測試驗收、系統(tǒng)測試驗收4項審查活動。應用需求跟蹤矩陣關聯(lián)需求與測試用例，應用缺陷跟蹤工具MANTIS記錄缺陷處理流程，應用魚骨圖分析質量問題根本原因，以支撐項目管理活動。項目團隊依據(jù)質量管理計劃執(zhí)行情況如下：
質量成本投入：團隊《信息技術軟件產品質量要求與評價》標準培訓2.2萬元、質量檢查清單與手冊編制1.8萬元、功能性檢查成本1萬元、第三方可靠性測試1.5萬元、需求文檔透露“跨校成績查詢”功能返工1.5萬元。代碼邏輯錯誤重構0.8萬元、上線后“課程沖突提醒”bug緊急修復0.6萬元。
質量控制執(zhí)行：需求階段通過需求跟蹤矩陣關聯(lián)250條教務需求與測試用例，最終驗證覆蓋了242條需求；開發(fā)階段累計編寫代碼5萬行，單元測試與集成測試共發(fā)現(xiàn)18個軟件缺陷，系統(tǒng)測試驗收時，執(zhí)行600條測試用例，通過了564條：針對“成績統(tǒng)計模塊數(shù)據(jù)計算偏差”缺陷，團隊用魚骨圖定位原因為“數(shù)據(jù)庫查詢語句邏輯錯誤”，制定“優(yōu)化SQL語句并增加數(shù)據(jù)校驗邏輯”的糾正措施，驗證后缺陷關閉，未影響項目上線時間。
質量持續(xù)改進：項目中期開展質量復盤會，分析出“需求評審參與人員不全”、“單元測試覆蓋率僅80%”2個問題，隨即補充教務主任參與后續(xù)評審，要求開發(fā)人員補充單元測試用例，使后期缺陷率下降30%。
【問題1】（8分）
結合案例，并參考示例，補充完整如下的本項目質量管理計劃表。

【問題2】（6分）
請分別計算本項目中的預防成本、評估成本和失敗成本。
【問題3】（4分）
計算本項目的“需求覆蓋率”和“軟件缺陷率”，并判斷是否達到項目質量目標。（結果保留兩位小數(shù)）
答案解析與討論：www.jycxcx.com/st/1102486024.html

第3題： 某大型制造集團公司啟動了ERP 系統(tǒng)升級改造至云平臺的項目，旨在實現(xiàn)業(yè)務流程標準化、提升數(shù)據(jù)實時性和支持智能制造轉型。
項目執(zhí)行過程中，小李識別了干系人，將集團領導、財務部門領導、分廠綜合辦列為核心干系人，記入干系人登記冊，并進行了如下溝通管理相關的活動。
活動1：項目初期，由于系統(tǒng)升級過程需要得到各個部門的大力支持，因此項目經理小李與集團領導匯報獲批后，通過企業(yè)內網發(fā)布ERP系統(tǒng)升級通知。
活動2：小李重點走訪了財務部門領導，在分析財務業(yè)務目前的困境與問題基礎上收集了相應的需求，并帶領團隊經過多次會議討論給出了相應的解決方案。
活動3：由于集團公司各分廠距離較遠，溝通比較困難，小李通過郵件的方式通知分廠綜合辦，告知系統(tǒng)升級的優(yōu)勢，要求一周內安排業(yè)務骨干支持需求調研工作。兩周后小李未收到分廠反饋，經微信溝通發(fā)現(xiàn)部分分廠長并未收到通知，收到通知的分廠長也由于生產進度緊張，擔心新系統(tǒng)升級過程會影響工作進度，并未安排業(yè)務骨干參與需求調研的工作。
活動4：新產品進入開發(fā)階段后，發(fā)現(xiàn)缺乏舊系統(tǒng)的邏輯接口說明，輾轉找到負責維護舊系統(tǒng)的技術員，溝通時了解到他擔心新系統(tǒng)上線后自己被取代而不愿意配合。給項目團隊的開發(fā)造成很大阻力。
進入測試階段，由于系統(tǒng)流程不符合生產實際操作，數(shù)據(jù)遷移頻繁報錯等，導致開發(fā)工作陷入停滯，預算超支，工期延誤。
【問題1】（5分）
分析案例，指出項目組在干系人管理和溝通管理方面出現(xiàn)的問題。
【問題2】（8分）
結合案例，請分別寫出4個溝通活動中涉及的干系人以及小李與各干系人溝通時分別采取的溝通方式。
【問題3】（4分）
在識別干系人過程中，應用數(shù)據(jù)表現(xiàn)技術對干系人進行分類，分類方法有哪些？

答案解析與討論：www.jycxcx.com/st/11024923209.html

第4題：

A科技公司成功中標某高校的“智慧校園”綜合管理平臺項目，公司任命老王負責項目管理工作，并選派年輕工程師小陳擔任配置管理員。在項目啟動會上，小陳展示了根據(jù)公司模板編制的配置管理計劃，但由于缺乏大型項目實戰(zhàn)經驗，該計劃中的部分內容與實際項目需求存在脫節(jié)。
開發(fā)階段，開發(fā)人員小李在實現(xiàn)“課表推送”功能時，發(fā)現(xiàn)需求文檔針對該功能的描述不合理，他直接在受控庫中修改了文檔，并基于修改后的需求進行了開發(fā)。
測試階段.產品經理發(fā)現(xiàn)“課表推送”功能實現(xiàn)與原始設計存在偏差，但已無法追溯需求文檔的變更記錄。
集成測試階段，“成績管理”模塊集成測試頻繁失敗，調查發(fā)現(xiàn)受控庫中具有依賴關系的數(shù)據(jù)庫腳本與程序代碼的版本不一致，一是因為兩名開發(fā)人員分別在本地修改了同一個數(shù)據(jù)庫腳本。未遵守配置庫的變更及檢出機制，修改后的數(shù)據(jù)庫腳本提交到受控庫中后出現(xiàn)了版本覆蓋問題。臨近交付，開始執(zhí)行配置審計工作時，發(fā)現(xiàn)用戶手冊與系統(tǒng)功能存在多處差異。追溯發(fā)現(xiàn)，文檔團隊使用的仍是早期的基線版本，后續(xù)的變更都未能及時同步到文檔庫。
【問題1】（8分）
請簡述該項自在配置管理上存在的問題。
【問題2】（5分）
針對數(shù)據(jù)庫腳本與代碼版本不一致的問題，請從配置管理的角度提出具體改進方案。
【問題3】（4分）
判斷正誤。
（1）配置庫中的受控庫充許開發(fā)人員直接修改配置項。（）
（2）配置狀態(tài)報告應該包含每個配置項的變更歷史記錄。（）
（3）配置審計只需要在項目結束時進行。（）
（4）配置項的狀態(tài)一般包括“草稿”、“正式”和“修改”三種狀態(tài)。（）
【問題4】（3分）
配置庫通?？煞譃椋?）、受控庫和（2）三種類型。其中，包含已發(fā)布使用的各種基線的存檔，并被置于完全的配置管理之下的庫是（3）。

答案解析與討論：www.jycxcx.com/st/110250432.html