項目管理31配置管理

1、2014年上半年信息系統(tǒng)項目管理師課程31配置管理91過軟考教育學(xué)院小馬Tel:2014年3月本章基本知識點：1、配置管理的定義 P3142、配置項的定義 P314-3153、配置管理的任務(wù) P3194、CCB-配置管理委員會 P319、3296、配置項的狀態(tài)變化 圖15.5P3297、版本管理：3種版本，要會區(qū)別8、配置審核定義、作用 P3339、配置狀態(tài)報告的定義 P33410、配置管理工具 VSSCVS等P331-333*項目配置管理配置管理流程圖：*項目配置管理如果把軟件系統(tǒng)看們關(guān)注的。的一個組成部分，以下3種基線是最受人（1）功能基線：是指在系統(tǒng)分析和軟件定義階段結(jié)束時，經(jīng)過正式評審

2、批準(zhǔn)的系統(tǒng)設(shè)計規(guī)格說明中對被開發(fā)軟件系統(tǒng)的規(guī)格說明；或是指經(jīng)過項目委托和項目承辦雙方簽字同意的協(xié)議或合同中所規(guī)定的對被開發(fā)軟件系統(tǒng)的規(guī)格說明；或是指由下級申請上級同意或直接由的規(guī)格說明。下達的項目任務(wù)中所規(guī)定的對待開發(fā)軟件系統(tǒng)（2）分配基線。分配基線是指在軟件需求分析階段結(jié)束時，式評審和批準(zhǔn)的軟件需求規(guī)格說明。（3），基線?；€是指在軟件組裝與系統(tǒng)測試階段結(jié)束時式評審和批準(zhǔn)的有開發(fā)的軟件的全部配置項的規(guī)格說明。*項目配置管理各在配置管理活動中的權(quán)限:*項目配置管理配置管理中的和分工：要使配置管理活動在信息系統(tǒng)的開發(fā)和維護中得到貫徹執(zhí)行,首先要明確確定配置管理活動的相關(guān)及其職責(zé)和權(quán)限。配置管理過

3、程的主要參與如下：(1)項目經(jīng)理（Project Manager, PM )項目經(jīng)理是整個信息系統(tǒng)開發(fā)和維護活動的管理的各項活動并，他根據(jù)配置委員會的建議，批準(zhǔn)配置它們的進程。其具體工作職責(zé)如下：制訂項目的組織結(jié)構(gòu)和配置管理策略；批準(zhǔn)、發(fā)布配置管理計劃；決定項目起始基線和軟件開發(fā)工作里程碑；接受并審閱配置員會的報告。委*項目配置管理(2)配置導(dǎo)和委員會（Configuration Control Board, CCB)負責(zé)指配置管理的各項具體活動的進行，為項目經(jīng)理的決策提供建議。其具體工作職責(zé)如下：批準(zhǔn)配置項的標(biāo)志，以及軟件基線的建立；制訂策略；建立、更改基線的設(shè)置，審核變更申請；根據(jù)配置管理

4、員的報告決定相應(yīng)的對策。*項目配置管理(3)配置管理員（Configuration Management Officer, CMO)根據(jù)配置管理計劃執(zhí)行各項管理任務(wù)，定期向CCB提交報告，并列席CCB的例會，其具體工作職責(zé)如下：軟件配置管理工具的日常管理與維護；提交配置管理計劃；各配置項的管理與維護；執(zhí)行版本和變更方案；完成配置審計并提交報告；對開發(fā)題并制訂解決方案。進行相關(guān)的培訓(xùn)；識別開發(fā)過程中存在的問(4)開發(fā)（Developer, Dev)開發(fā)的職責(zé)就是根據(jù)項目組織確定的配置管理計劃和相關(guān)規(guī)定，按照配置管理工具的使用模型來完成開發(fā)任務(wù)。*項目配置管理案例分析：可能會考一些理論知識或背景里

5、提示當(dāng)前的狀況很，是怎么造成的。：單獨出配置管理的題，否則，會死人的。*項目配置管理在配置管理的主要工作中，不包括下列中的 （51） 。A. 標(biāo)識配置項C. 對工作結(jié)果的審核B.配置項的變更D. 缺陷分析下列中的 （52）是不包含在項目配置管理系統(tǒng)的基本結(jié)構(gòu)中的。A.C.開發(fā)庫受控庫B.D.知識庫庫*本章舉例信息系統(tǒng)項目完成后，最終需要在此基礎(chǔ)上進行后續(xù)開發(fā)或項目成果應(yīng)置于 （52）內(nèi)，當(dāng)將其轉(zhuǎn)移到 （53）后進行。（52）A.開發(fā)庫（53）A.開發(fā)庫B.服務(wù)器B.服務(wù)器C.受控庫C.受控庫D.D.庫庫以下有關(guān)基線的敘述，錯誤的是（63）。A. 基線由一組配置項組成B. 基線不能再被任何人任意

6、修改C.基線是一組經(jīng)過正式并且達成一致的范圍或工作D.的測試版本不能被看作基線*本章舉例某個配置項的版本由1.0變?yōu)?.0，按照配置版本號規(guī)則表明（64）A.目前配置項處于正式發(fā)布狀態(tài)，配置項版本升級幅度較大B.目前配置項處于正式發(fā)布狀態(tài)，配置項版本升級幅度較小C.目前配置項處于正在修改狀態(tài)，配置項版本升級幅度較大D.目前配置項處于正在修改狀態(tài)，配置項版本升級幅度較小下列選項中，不屬于配置審核的作用是（65）。A.防止向用戶提交不適合的B.確保項目范圍的正確C.確保變更遵循變更規(guī)程D.找出各配置項間不匹配的現(xiàn)象*本章舉例某個配置項的版本由1.11變?yōu)?.12，按配置版本號規(guī)則表明（64）A.B

7、.C.D.目前配置項處于正在修改狀態(tài)，配置項版本升級幅度較大目前配置項處于正在修改狀態(tài)，配置項版本升級幅度較小目前配置項處于正式發(fā)布狀態(tài)，配置項版本升級幅度較小目前配置項處于正式發(fā)布狀態(tài)，配置項版本升級幅度較大配置審計包括物理審計和功能審計，（65）屬于功能審計的范疇。A代碼走查C介質(zhì)齊備性檢查B變更過程的規(guī)范性審核D配置項齊全性審核*本章舉例配置管理中有一項工作是變更，其中配置項狀態(tài)的過程如圖2所示： 在這個狀態(tài)變化過程中，圖中的（1）、（2）、（3）三個狀態(tài)依次為（65）。A、工作狀態(tài)、受控狀態(tài)、評審狀態(tài)B、評審狀態(tài)、工作狀態(tài)、受控狀態(tài)C、工作狀態(tài)、評審狀態(tài)、受控狀態(tài)D、受控狀態(tài)、評審狀態(tài)

8、、工作狀態(tài)*本章舉例在軟件配置管理中，版本的（64）的目的是按照一定的規(guī)則保存配置項A重要版本B.基線版本C. 所有版本D. 需要得版本項目組對某重要實施基于的。項目經(jīng)理（PM）為系統(tǒng)管理員。項目成員還包括配置管理員（CM）、分析、設(shè)計、開發(fā)和質(zhì)量保證（QA），其中CM和QA同時參與多個項目。下面關(guān)于該權(quán)限分配的說法正確的是（15）。A、CM的B、QA的C、分析權(quán)限應(yīng)由PM分配，且應(yīng)得到QA的批準(zhǔn)。權(quán)限應(yīng)由PM分配，其不參與項目將其權(quán)限轉(zhuǎn)給CM、設(shè)計、開發(fā)的權(quán)限應(yīng)由CM分配，且應(yīng)得到QA的批準(zhǔn)D、PM的CM權(quán)限由其分配，且PM不在時其權(quán)限不能轉(zhuǎn)給QA和*本章舉例某項目是一個新開發(fā)項目，項目計劃

9、開發(fā)周期為12，項目團隊有11個人，包括：項目經(jīng)理1人，開發(fā)工程師5人，測試工程師2人，文檔工程師1人，配置管理1人，SQA 1人。項目于2010年7月1日開始，項目計劃如下：需求分析一，總體設(shè)計一，詳細設(shè)計二，編碼五，測試一個半月，文檔準(zhǔn)備、客戶驗收測試半，修改BUG并發(fā)布半，項目開工后，項目團隊充滿地努力工作，項目經(jīng)理也非常有信心按期完成該項目，并在開工會上公布了該項目的與激勵制度。2010年8月1日，項目組按期完成需求規(guī)格設(shè)計說明書；2010年9月1日，按期完成了總體設(shè)計。此時，市場部提出，最近有幾名客戶都問到這個了，9月份可能有客戶要看演示的DEMO，需要加快開發(fā)進度，問項目經(jīng)理是否可

10、以先開發(fā)DEMO，詳細設(shè)計后后面再補充，先把的原型做出來。*本章舉例項目經(jīng)理經(jīng)過與項目組及項目管理部協(xié)商，決定去掉詳細設(shè)計這個環(huán)節(jié)，直接進入的編碼階段，安排開發(fā)工程師根據(jù)總體設(shè)計負責(zé)各自模塊的開發(fā)工作。5名開發(fā)工程師組成的開發(fā)小組進入非常忙碌的編碼階段后，經(jīng)常加班加點，開發(fā)過程中，由于原來制定的計劃已完全被打亂，SQA無法再根據(jù)原來的質(zhì)量保證計劃進行跟蹤，項目組其他法發(fā)揮作用。也已無2011年2月15日，項目經(jīng)理向公司管理層反映這個項目存在的問題，市場部提的需求有部分不能實現(xiàn)，遇到了技術(shù)瓶頸，而且有團隊成員要離職，為此由項目管理部組織會議，對新增的部分需求進行評審，包括研發(fā)總監(jiān)、研發(fā)副總裁在內(nèi)

11、，最終決定要繼續(xù)開發(fā)，確定進行。問題的解決時間為2011年3月15日，其他工作繼續(xù)*本章舉例遺憾的是，問題一直到5月1日才解決，這時已有2名開發(fā)問題而離職，項目經(jīng)理除了要考慮項目進度外，還要考慮項目，由于此時其他項目任務(wù)也很重，公司很緊張，他不得不重新招聘開發(fā)。等項目經(jīng)理招到2個新人后，已是2011年6月15日，這本應(yīng)是項目計劃中系統(tǒng)測試結(jié)束的關(guān)鍵里程碑，但現(xiàn)在編碼任務(wù)至少還需要1個月，在公司的月度會議上，項目經(jīng)理向包括總裁在內(nèi)的各位導(dǎo)做了匯報，并因為項目進度延遲受到了批評。2011年8月1日，測試部終于拿到了系統(tǒng)的第一個測試版本。領(lǐng)2011年10月20日，系統(tǒng)終于開發(fā)和測試完畢，測試部輸出最

12、終的測試報告，同意該、需求規(guī)格說庫。向市場發(fā)布，所有的文檔，包括詳細設(shè)計、說明書等還沒有上傳到配置*本章舉例【問題1】（12分）請簡要分析本題案例在下面管理方面存在哪些問題？【問題2】（3分）本題案例中的項目至少延期了多少時間?！締栴}3】（10分）為了實現(xiàn)本題案例中市場部提出的要求，作為項目經(jīng)理，你認為可以采取哪些措施來應(yīng)對。*本章舉例【問題1】（12分）(1)風(fēng)險管理問題，公司以及項目經(jīng)理對“詳細設(shè)計到后面再補充”變更造成的風(fēng)險預(yù)計不充分，對團隊成員離職的風(fēng)險預(yù)估不足(2)管理問題：項目經(jīng)理與之間的失敗，項目經(jīng)理與市場部之間不足；項目經(jīng)理可能與團隊成員的；在整個項目實施過程中，缺少與客戶的和

13、需求確認等(3)缺少有效的需求變更流程，對需求沒有進行、評審和確認，變更風(fēng)險未到位。(4) “去掉詳細設(shè)計環(huán)節(jié)”后，沒有對項目管理計劃做相應(yīng)的變更和調(diào)整，特別是缺少變更后的質(zhì)量管理計劃，沒有及時更新測試管理計劃*本章舉例(5) 項目經(jīng)理沒有做好團隊建設(shè)，績效激勵可能的困境沒有急思廣益(6) 項目經(jīng)理對整個項目的整體把控，對項目(7)項目經(jīng)理對項目執(zhí)行過程中的相關(guān)有不斷細化和完善項目計劃比較弱，執(zhí)行過程中沒(8)項目的配置管理缺乏過程的跟蹤和審計，或配置管理不嚴(yán)格，(9)整個項目沒有相應(yīng)的監(jiān)督機制和監(jiān)督漏和工作流程的隨意更改，導(dǎo)致重要環(huán)節(jié)的缺(10)項目進度和質(zhì)量未到位，（包含但不限于以包含但不

14、限于以，列出6點就可以，每小點2分，最多12分，類似即可）*本章舉例【問題2】（3分）320天，或者是近4【問題3】（10分）(1)積極與客戶交流，盡可能收集客戶的需求，功能部分的需求可以推托（或者是先下來，協(xié)商后分批延后開發(fā)），但是客戶體驗的需求要盡量滿足(2)積極與市場部發(fā)部的實現(xiàn)難度過，讓其在接受客戶需求的時候也考慮下研(3)及時與客戶和市場部諸多影響情況，說明現(xiàn)階段變更可能對項目造成的(4)遵循整體變更流程，相關(guān)客戶需求，對需求變更可能帶來的影響進行較全面的評估，形成經(jīng)建設(shè)方簽字確認的新需求文件，并提交CCB審批；將相關(guān)的變更信息及時有效目干系人相關(guān)的項*本章舉例(5) 在防范風(fēng)險的前提下，將客戶需求的DEMO版軟件的設(shè)計、開發(fā)與原項目計劃中詳細設(shè)計階段一起并行施工，即把DEMO版軟件作為新增的附加功能進行設(shè)計，但是不影響原定計劃和設(shè)計目標(biāo)，同時，利用DE