CMMI3訪談問題及答案_第1頁
CMMI3訪談問題及答案_第2頁
CMMI3訪談問題及答案_第3頁
已閱讀5頁,還剩3頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

1、項目經理訪談1. 項目介紹 , 自我介紹我叫XXX是XX項目的項目經理。我們 XX項目是用XX開發的XX系統,目 的是實現XXXXX現在已經結項。我們項目從 X年X月X日開始,到X年X月X 日結束,成員有XX,XX,XX,說明各自角色。2. 請描述一下你是如何做項目計劃的?在立項建議書通過審批后,軟件事業部部經理籌建項目組,指定 PM和項目 成員。PM向配置主管(XX和QA主管(XX申請了 CM和QA在QA的協助下,PM參考財富庫中的歷史數據(北園春收費管理系統),根 據立項建議書和合同中約定的工作內容制定了項目開發計劃。1)根據軟件生命周期模型選擇指導書 ,使用軟件生命周期模型選擇表 選擇了

2、本項目的生命周期模型 XX模型,并說明選擇原因(選擇表中的選 擇結果)。2)根據項目開發過程的選擇與裁剪指導書定義了項目特點,本項目需 要X人開發X月,所以是X類項目,使用項目過程定義表對項目過 程進行裁剪,本項目裁剪了 XX活動并填寫到項目開發計劃的偏差說 明中。3)PM根據項目的具體情況(如項目較簡單,開發周期短,人員少)劃分了 里程碑。本項目分XX個里程碑(具體說明),確定了每個里程碑的開始 結束時間、到達標志和輸出件。4)對項目全部的工作任務進行分解,記錄在項目開發計劃 .mpp。5)我們使用估算指導書進行了功能點估算。先算出項目的數據功能點和項 目的交易功能點, 最后填寫數據通信、

3、性能等 14 條通用特性計算相關復 雜性調整因子及總功能點,得到調整后的功能點數,根據組織的生產率 制定本項目的生產率從而算出需要的工作量。組織級的生產率是 1(根 據歷史經驗得來),本項目的是 1。并對各階段的工作量比例進行了劃分, 根據各階段的工作量對工作任務進行了時間分配,形成進度計劃 。6)根據估算出的工作量進行了成本預算,包括人員工資、開發環境建設成本、培訓成本、公用成本。本項目的成本預算為 XX元。7)參考組織度量庫中同類項目,制定了項目度量計劃,定義了度量項,如 進度偏差率、工作量偏差率、項目規模偏差率、需求穩定度、缺陷密度 等。規定了收集的度量數據及其收集、報告頻率,度量閥值。

4、詳見度 量計劃和項目度量表的度量目標、度量項定義頁。8)對項目資源進行了計劃,包括人員、環境、軟件、硬件四方面。人員方 面規定了項目開發所需的角色、人數、工作任務、技能要求。要求到位 時間等;開發所需的環境要求 ( 工作環境標準 ) ;開發所需的硬件設備、 型號、數量、使用時間;所需的各種軟件、版本、數量、使用時間。9)參考風險庫中同類項目,使用風險管理表中的風險檢查單,根據PM的工 作經驗,識別出項目開發過程中存在的風險,判斷其發生概率和影響程 度算出風險發生的優先級,風險等級大于“中”的風險制定緩解措施和 應急措施。10)制定干系人活動計劃,列出項目開發過程中的主要活動和相關干系人, 干系

5、人包括項目組成員、客戶方關鍵人員、部門經理等這些人員和項目 組成員共同組成了項目團隊,明確了日常溝通的方式和職責。11)根據項目人員情況和公司年度培訓計劃確定完成本項目所需具備的技能 和技術水平,對于無法滿足項目需要的技能或技術制定培訓計劃。本項 目計劃做了 XX培訓,是否進行,是否有記錄,講師是誰,講義誰寫的。12)制定本項目的評審計劃:對哪些工作產品進行評審,評審方式(正式評 審或非正式評審)、計劃評審時間。 需要評審的工作產品包括: 項目開發 計劃、質量保證計劃、配置管理計劃、客戶需求說明書、軟件需求規格 說明書、軟件設計說明書、關鍵代碼(非正式評審) 、測試計劃、用戶手 冊。13)驗收

6、準則(詳見項目開發計劃)PM編寫項目開發計劃的同時,QA和CM根據項目開發計劃中的時間、人員安排制定質量保證計劃和配置管理計劃。 完成后,對整體計劃進行了評審, 評審通過后PM®知CM對計劃進行了基線和發布。3. 你是怎么做項目監控的?項目監控主要是通過對項目發計劃.mpp的更新,檢查項目組成員的項目周報、里程碑報告、項目總結會議等方式進行監控的。每周一早上 PM 會檢查項目成員的周報,填寫的工作內容和工作量是否正確,每周周五召開 項目周會, 總結本周工作完成情況, 下周工作安排, 總體進度, 對項目問題、 風險進行跟蹤。在計劃的里程碑到達后編寫相應的里程碑報告,并召開項目 里程碑會

7、議,向軟件部經理和項目成員匯報項目的完成情況,使用度量表中 本階段的進度偏移、工作量偏差等度量數據對項目現階段情況進行分析,匯 報發現的問題和存在的風險,以及經驗和教訓。度量分析員根據度量計劃中 規定的收集頻率收集度量數據。每周周會對風險管理表中的風險進行跟蹤。 項目結項時編寫項目總結報告,召開項目總結會議。4. 如何跟蹤項目進度 ?偏差如何解決主要是通過對項目發計劃.mpp的更新,檢查項目組成員的項目周報、 里程碑報告、項目總結會議等方式進行跟蹤的。發現偏差的時候根據情況及 時調整工作安排,如果偏差超過閥值( 15%)的話就會按規定進行重計劃。5. 如何管理風險每周在周會上對風險進行跟蹤,

8、對已識別風險的發生概率和影響程度分 析是否有變化,風險狀態是否有變化,是否產生新的風險,并記錄在項目周 報和風險管理表中。如果風險發生的話會轉化為項目問題記錄在項目問題 跟蹤表中進行跟蹤,風險狀態改為關閉。項目結項時, PM將風險管理表提 交EPG EPG審核通過后納入組織財富庫中的風險庫以供今后的項目做參考。6. 度量分析活動如何做度量分析員按照度量計劃中規定的頻率和來源收集度量數據并填入項 目度量表中,每階段由PM和度量分析員對本階段的數據進行分析,并將結 果在項目里程碑會議上報告。如果度量結果超過閥值的話會做重計劃。項目 結項時,會生成本項目的總體度量結果,PM和度量分析員對度量結果進行

9、分 析,總結經驗教訓并提交 EPG EPG審核通過后納入組織財富庫中的度量庫 以供今后的項目做參考。7. 何時做決策分析?針對什么問題,怎么做公司標準過程中規定在系統架構選擇的時候必須進行決策分析, 其他需 要決策的時候都可以采用。本項目有 /沒有做決策分析(有的話接著講,沒 有做就說明原因)。在決定系統架構的時候我們出現了 2 種選擇, 1 是 XXX 架構,2是XXX架構(說明這兩種架構的優缺點)。PM向軟件部經理提交了 決策申請和兩個架構的方案,軟件部經理同意進行決策后,決定決策人員, 決策方法,下發決策通知,召開決策會議。在會議上,我們使用決策分析指 南中提供的“加權打分法”對兩個方案

10、進行了打分,最后選擇了分數較高的 XX方法。軟件部經理將決策分析報告發給所有參會人員, PM按照決策結果 執行。8. 項目如何做需求在項目開發計劃基線后,系統分析師按照計劃制定需求調研計劃 , 確定活動安排和時間安排,實施人員,客戶配合人員,調研內容等。 PM審核 需求調研計劃,通過后,系統分析師做調研前的準備,準備需求調研提綱, 按照計劃進行現場調研,明確客戶重點,詳細記錄并分析隱含需求。現場調 研完成后,系統分析師完成客戶需求說明書并進行評審,通過后,PM與客戶確認需求(我們采用了書面簽字的方式,有簽字確認單),通知CMS 線。客戶需求說明書基線后,系統分析師討論分析客戶需求,編寫軟件需求

11、 規格說明書和評審并基線。9. 如何管理需求變更?如有需要進行 需求變更 。在項目進行中,用戶提出需求變更或項目開發 期間出現需求變化,系統分析師分析對需求變化進行初步分析。如果需求變 更則按照變更控制流程進行變更。PM填寫需求跟蹤矩陣中的相關部分, 查看需求變更的影響是否已經被有效的實現。10. 如何跟蹤需求 (如何保證需求和工作產品的一致性) ?在需求分析完成后,PM建立本項目的需求跟蹤矩陣,在每個階段結束時, PM填寫需求跟蹤矩陣中的相關部分,發生需求變更時,PM需要檢查需 求跟蹤矩陣中的對應部分,通過需求跟蹤矩陣,每個客戶需求說明書中記 錄的功能都能在每階段的工作產品中一一對應, 從而

12、保證需求不丟失并與工 作產品一致。11. 變更控制怎么做?在配置管理計劃中規定了本項目 CC(變更控制委員會)小組成員(PM 系統分析師,QA軟件部經理等)。發現變更時,由發現人提出變更填寫變 更控制表的相關部分,CCB對變更進行影響分析(工作量,影響程度,風險) PM組織CCB會議進行評審,并作出是否同意變更的決議。如果不同意變更, 應說明原因。變更申請通過后,PM通知CM解凍相關配置項,并為實現該變 更的人員授予合適的訪問權限,變更人員實現變更,PM安排相關人員對實現 的變更進行驗證,通過后,PM通知CM重新將配置項基線并發布。12. 怎么做設計?在軟件需求規格說明書基線后,進入設計階段的

13、工作。PM按照計劃分配 設計任務,設計人員做設計準備,明確設計方法,制定軟件設計說明書,通 過評審后納入基線。軟件設計說明書內容包括總體設計、功能性需求設計、非功能性需求設計、接口設計、結構化設計、數據庫設計、界面設計、權限設計、安全設計、 系統異常處理設計和系統維護設計等。13. 你們是怎么進行開發的?在軟件設計說明書基線后, PM:(1) 分配編碼及單元測試任務,必要時需要針對編碼人員講解需求和設計規 則。(2) 若程序員不熟悉編碼規范, 可以組織對其進行培訓。(說出本項目使用的 編碼規范,是否進行了培訓)(3) 確定編碼及單元模塊測試的具體時間。(4) 確定關鍵模塊,編碼順序。(5) 與

14、軟件設計師共同確定單元代碼的測試內容,測試方式:如靜態測試, 或者動態測試。程序員搭建編碼及模塊測試環境, 根據軟件設計說明書和編碼規范進行 編碼和調試,按照評審后的模塊測試計劃進行測試。PM組織對模塊代碼進行 檢查后納入配置管理。模塊測試通過后,軟件設計師與 PM確定產品集成順序,準備測試環境, 測試員編寫集成系統測試計劃并進行評審,計劃包括測試具體內容,測試進 度,測試方法,測試資源等內容。測試員編寫測試用例,PM審批后進行測試。 我們項目是用XX工具進行測試的。測試過程中,PM協調解決測試過程中遇 見的問題直至結束。測試通過準則見項目開發計劃14. 接受過哪些相關的培訓?怎么做的?1)

15、入職時參加過新員工培訓(制度方面)2) 公司每年至少組織1次CMM過程培訓3) 項目組根據需求制定的培訓計劃中的培訓4) 公司組織的講師培訓(培訓技巧方面)公司在年初會收集大家的培訓需求,然后根據公司預算做年度培訓計 劃。我們通過發布的年度培訓計劃了解本年的培訓, 有外部和內部兩種培訓, 外部培訓是參加一些收費的培訓,參加之前會跟公司簽訂 3 年的培訓協議, 內部培訓是公司內部組織的一些培訓,由培訓管理員 XX 進行管理。沒有參 加外部培訓,內部培訓是按照培訓計劃,接到培訓通知后,按時參加培訓, 如果不能參加的話需要向軟件部經理和培訓管理員請假。在簽到表上簽到, 參加培訓,結束后會有幾種方式進

16、行考核,如現場提問打分,部門培訓效果 反饋表和考試,由培訓管理員(人力資源部王華)管理。15. QA和CM在項目里做什么工作?QA編寫質量保證計劃;協助項目經理裁減項目定義過程;為項目 成員提供過程使用過程培訓; 按照質量保證計劃的時間使用相應的審計檢查 單進行質量保證審核(過程審核,工作產品審核) ;跟蹤驗證不符合問題直 至關閉,如果遇到無法解決的問題會層層上報直至關閉。CM負責制定配置管理計劃;建立并維護PCF(項目配置文件夾)的 內部結構;權限管理;監督、協調、協助配置管理活動;產品發布,資料管 理。日常的變更管理和控制,以及日常的代碼配置管理。16. 怎么做評審?都有哪些人參加PM向評

17、審委員會主任提交評審申請,評審委員會主任任命評審組長和組 員,評審組長發評審通知、評審檢查單和評審材料,評審人員對材料進行預 審,并在會議前將結果反饋給評審組長,評審組長匯總大家發現的問題記錄 在缺陷記錄表中,召開評審會議。在會議上采用逐頁評審的方式,隨時指出 發現的問題, 由作者解答, 評審小組確認問題嚴重級別、 責任人和修改時間, 得出評審結論(直接通過,修改后通過,不通過) 。評審組長指定人員對發 現的問題進行跟蹤, 修改完之后,評審組長完成評審總結報告發給相關人員, 評審結束。17. 在項目進行過程中,如果發現過程存在問題你會怎么辦?填寫過程改進建議單交給QA或 EPG成員,他們會討論修改。18. 你提出過改進建議嗎?有,內部驗收報告中驗收測試用例沒有地方記錄測試結果, 2014-1-24 提出, 2014-2-14EPG 接受并進行了修改。19. 公司組織級有沒有為你的項目提供幫助?有。首先公司制定了 14 個過程的過程和模板文檔,還有許多有用的指 導書和規范。其次,在項目開始的時候,我參考了很多財富庫中以往同類項目的歷史 數

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論