系統(tǒng)集成項目管理工程師案例分析當(dāng)天每日一練試題地址：m.xiexiliangjiufa.com/exam/ExamDayAL.aspx?t1=2

往期系統(tǒng)集成項目管理工程師每日一練試題匯總：m.xiexiliangjiufa.com/class27-2-1.aspx

系統(tǒng)集成項目管理工程師案例分析每日一練試題（2020/2/7）在線測試：m.xiexiliangjiufa.com/exam/ExamDayAL.aspx?t1=2&day=2020/2/7

系統(tǒng)集成項目管理工程師案例分析每日一練試題內(nèi)容（2020/2/7）

試題一（25分）

某公司承接了一個銀行業(yè)務(wù)系統(tǒng)的軟件開發(fā)項目，質(zhì)量要求非常高。項目經(jīng)理小趙制定了項目的整體計劃，將項目劃分為需求、設(shè)計、編碼和測試四個階段，他將測試階段預(yù)留了大量時間，以便開展充分的測試工作。

需求分析完成后，項目組編寫了《需求分析報告》，項目經(jīng)理小趙召集部分骨干人員召開評審會。為了盡快進入下一階段工作，評審會從早上9點一直開到晚上9點，終于把全部的文件都審?fù)炅?。評審組找到了幾處小問題，并當(dāng)場進行了修改，項目經(jīng)理宣布可以進入設(shè)計階段了。編程結(jié)束后，進入了測試階段。第一輪測試，發(fā)現(xiàn)了70個缺陷。項目組對發(fā)現(xiàn)的缺陷進行了修改，又重新提交了測試。第二輪又發(fā)現(xiàn)了100多個缺陷，就這樣反復(fù)修改和測試，直到第六輪，發(fā)現(xiàn)了33個缺陷。各輪發(fā)現(xiàn)的缺陷數(shù)如下：

這時，小趙終于松了一口氣，由于第六輪只剩下33個缺陷，他覺得測試工作應(yīng)該很快就會結(jié)束了。

【問題1】（10分）

請分析此項目的質(zhì)量管理過程中存在哪些問題。

【問題2】（9分）

請在答題紙上標(biāo)出縱坐標(biāo)的刻度值，并畫出測試缺陷的趨勢圖。根據(jù)趨勢圖分析“小趙覺得測試工作很快就會結(jié)束了”是否有道理，并分析原因。

【問題3】（3分）

請結(jié)合軟件生命開發(fā)周期分析軟件存在缺陷的可能原因。

【問題4】（3分）

請結(jié)合實際經(jīng)驗說明軟件項目的質(zhì)量管理工作應(yīng)重點完成哪些工作。

信管網(wǎng)汪林林：
【問題1】 1、項目經(jīng)理小趙沒有制定項目管理計劃。 【問題2】 第六輪發(fā)現(xiàn)了33個缺陷 并不代表缺陷呈現(xiàn)下降趨勢了。 【問題3】 開發(fā)過程中 單元測試、集成測試、系統(tǒng)測試、驗收測試沒有到位。 【問題4】

信管網(wǎng)zyy0431ok：
問題1 1.評審會不應(yīng)該只有項目組成員參加，應(yīng)該包括相關(guān)干系人，包括甲方的人員 2.需求出現(xiàn)問題，當(dāng)場修改：沒有走變更流程，提交變更控制委員會 3.沒有編制有效的質(zhì)量管理計劃 4.出現(xiàn)了太多測試問題，開發(fā)階段不嚴(yán)謹(jǐn) 問題2 沒有道理，根據(jù)趨勢圖，并沒有呈下降趨勢 問題3 軟件開發(fā)周期包括：需求分析、設(shè)計、編碼、測試、運維、收尾階段 將測試階段時間太長，沒有保證設(shè)計過程的正確性，完全交由測試問題，不合理 問題4 1.規(guī)劃質(zhì)量管理 2.質(zhì)量保證： 3.質(zhì)量控制

信管網(wǎng)ada_04160216：
1、缺少質(zhì)量管理計劃、沒有設(shè)立質(zhì)量監(jiān)督部門、沒有專業(yè)的質(zhì)量控制人員、缺少質(zhì)量標(biāo)準(zhǔn)和規(guī)范、需求分析不詳細、缺少質(zhì)量控制和質(zhì)量管理、沒有建立質(zhì)量保證體系、項目經(jīng)理在質(zhì)量管理方面經(jīng)驗欠缺 2、 3、需求分析不充分，需求分析沒有得到用戶的確認(rèn)，

信管網(wǎng)go1946：
問題1、沒有指定質(zhì)量管理計劃、沒有對質(zhì)量保證工作，只有質(zhì)量控制（測試） 質(zhì)量控制也有問題：需求評審沒有干客戶參與，評審會是發(fā)現(xiàn)問題的， 評審會時間過長，起不到作用，測試工作、測試方法、測試用例、人員上、測試環(huán)境上存在問題，項目在重大里程碑上應(yīng)由用戶進行評審。 問題2：不能判斷很快結(jié)束，沒有成下降趨勢 問題3：產(chǎn)生的缺陷可能是需求缺陷、設(shè)計缺陷、編碼錯誤、測試不充分 問題4：指定質(zhì)量保證幾乎啊、安排質(zhì)量保證人員負責(zé)質(zhì)量保證工作，對軟件開飯過程進行審計，注重測試工作，安排獨立測試人員、對發(fā)現(xiàn)問題進行統(tǒng)計分析，確認(rèn)軟件質(zhì)量

信管網(wǎng)victornie：
問題1 1） 未制定單獨的質(zhì)量管理計劃，未安排質(zhì)量管理人員 2）未實施質(zhì)量保證工作 3）質(zhì)量控制方面存在問題 （1）在重大里程碑處需由干系人對階段性成果進行評審 ，確保結(jié)果與預(yù)期目標(biāo)一致 （2）需求評審沒有客戶參與，可能導(dǎo)致最終對需求不能達成一致，設(shè)計文件未經(jīng)過正式評審，可能導(dǎo)致設(shè)計文件有許多錯誤 （3）技術(shù)評審會是為了發(fā)現(xiàn)問題，而不是修改問題，評審會沒有達到預(yù)期效果 （4）需求評審控制得不好。需求評審屬于技術(shù)評審，會議持續(xù)時間過長，起不到質(zhì)量控制的作用 4）測試工作中在測試用例、測試方法、測試人員及測試環(huán)境等方面存在問題 問題2 不能判斷測試可以結(jié)束，因為6輪測試的缺陷數(shù)并沒有呈整體下降并趨于穩(wěn)定的趨勢 問題3 原因可能是 需求缺陷 設(shè)計缺陷 編碼錯誤 測試不充分 問題4 1） 制定質(zhì)量保證計劃 2）安排獨立于項目組的質(zhì)量保證人員負責(zé)qa 3）對軟件開發(fā)過程實施質(zhì)量審計 4）注重對需求和設(shè)計等開發(fā)過程文件的技術(shù)評審工作 5）注重測試工作，應(yīng)安排相對獨立的測試人員 6）對發(fā)現(xiàn)的缺陷進行統(tǒng)計分析，確認(rèn)軟件質(zhì)量。