CMMI5評估提問單及回答要點

1、序號問題1項目中怎么運用4級與5級的內容？在項目中如何使用PPO、PPM、PPB?2用了這模型后，覺的有用嗎？現(xiàn)在項目的質量有沒有比以前的好？有原因分析嗎？3EPG小組怎樣幫項目運用模型-PPM?1百口口宀占宀k1=1-7A73n=iziilfnnrrriv/innD、4壩曰其它的人員了解用到的模型（PPO、ITIM、PPB丿嗎？5*j有沒有考慮到規(guī)模（PPM）的最佳范圍？6你認為這些最佳范圍真正的有用嗎？7有沒有建立UCP規(guī)模的案例？如新員工過來，讓他了解1個UCP有多大？8需求根據(jù)矩陣有做嗎？9需求跟蹤矩陣填與花了多少時間呢？10決策分析有做嗎？對每個方案是怎樣打分的？你們做了什么研究？1

2、1風險管理有做嗎？如何做？12有哪些風險你們認為不是很關鍵，不需要跟蹤的？13項目中有建立基線嗎？基線報告有嗎？確認時間？14你們用什么開發(fā)語言？如何集成？15怎么樣編譯？編譯的流程？從哪里取源代碼,放在哪里編譯？會不會放在單獨的電腦上編譯？在另外的機器單獨編譯的原因？該機器有沒有做別的用處？若/+右1=1一BHrinrntfi+mhHi=i16有做同行評中嗎？有沒有對源代碼做編碼規(guī)范方面的同行評審？17y111項目里會收集哪些度量數(shù)據(jù)？18你覺得你們項目中哪些流程做的太復雜或可以不要做的？19對4級、5級的改進，你們了解嗎？如公司做了哪些模型？哪些創(chuàng)新？20對項目目標的了解？21在你們的項目

3、中，你們怎樣了解到項目的需求？會和客戶起分析需求嗎？22需求調研是開發(fā)做還是別人做？23測試人員怎樣了解到需求的？24怎樣知道大家對需求的了解是一致的？如果有個人很安靜，你如何知道他知道這些需求？25需求了解到，下一步做什么工作？26怎樣計劃你們的測試計劃？如何估算時間？27寫測試用例的時間是怎樣估算的？看測試計劃？28開發(fā)人員知道項目是怎么估算的？是否有參加這個估算？個需求或一個模塊如何知道有幾個UCP?舉一個例子29詳細說明一個模塊，你怎樣知道它有多少個UCP?10.8UCP需要多少的工作量？你們認為這個估算方法準確嗎？30后來有設計評審嗎？你們的設計是怎樣做的？你們怎么知道這樣設計是最合

4、適的？31誰會參加設計評審？32是不是每個開發(fā)人員都會寫各自的設計？有多少設計文檔呢？最終文檔的整合？33概要設計和詳細設計多長時間？34詳細說明設計評審怎樣做？評審刖做怎樣的準備？你們在評審的時候為什么要討論這些問題？一個設計的評審，花多長時間？35設計做完了下步會做什么呢？36為什么集成測試用例要等到概要設計完成后再寫？37問測試：你認為開發(fā)人員的設計寫得足夠詳細嗎？38問開發(fā)人員：你們怎樣知道你們的設計足夠詳細，足夠幫助測試人員編寫用例？可提供給測試人員？39誰會檢查你們的測試用例？測試用例誰評審？什么時候檢查？40開發(fā)中通過什么檢查來確定源代碼的質量？41你們互相檢查中找到問題，如何通

5、知？42開發(fā)人員：單兀測試做嗎？（指的是白盒測試）自己測試時候是否會寫測試用例？怎樣知道單元測試做到什么程度？有記錄嗎？43先單兀測試再交叉檢查嗎？為何這樣安排？44你們怎樣把你們的系統(tǒng)交給測試人員做集成測試？45模板不好用之類的，你們怎么處理？46你們會了解你朋友公司的開發(fā)流程？47哪些地方你們有沒有覺得太復雜，有修改或簡化的必要？48你目做了哪模四做預五級感內容？嗎？認為數(shù)據(jù)足夠、隹確49你用了這1模型做預測，感覺有用嗎？認為數(shù)據(jù)足夠隹確嗎？50項目做了哪些改進創(chuàng)新？51做了哪些原因分析？要有對應的記錄。52在你們項目中怎樣估算和預測你們需要的工作呢？具體如何估算工作的規(guī)模大?。扛鶕?jù)功能點

6、如何估算？53你們在開發(fā)源代碼的時候，你們會做代碼的互相檢查及同行評審，請詳細說明。54項目經理如何分配代碼走查的工作？55般花費多少時間做互相檢查？56怎樣知道應該找出來的問題已經檢查出來了？57是否會做同行評審，怎么做同行評審？58在你們項目有沒有做壓力測試、性能測試？59項目有沒有做決策分析？評估表中的分值是什么意思？項目成員是否有參與到決策分析？60項目有沒有做裁剪？做了哪些裁剪？為什么？61項目4級、5級的工作如何？62EPG有沒有將這些實際的數(shù)據(jù)更新到模型中？63誰參加了決策分析？64風險管理？65項目有壓力、性能測試嗎？有使用工具嗎？66如何記錄性能測試的數(shù)據(jù)？67為什么不做壓力

7、測試？68項目的進度計劃如何？69互相檢查的評審是怎樣做的？（指代碼評審）70在檢查的時候怎么知道你找出了足夠的缺陷？71測試人員找到了問題，你們有沒有分析為什么當時你們沒有找到？72單兀測試（開發(fā)層面）和交叉檢查，哪個先做？73項目經王里會檢杳開發(fā)人員的源代碼嗎？一個人檢杳，還是起檢杳？如果在下個項目，你安排時間，和開發(fā)人員面對面檢杳，你覺得好嗎？（指大家一起坐下來檢杳）74通過互相檢杳的工作，會不會覺得自己的能力提咼了？有沒有更好的方法來快速提高新員工的能力？75你們有沒有參加過同行評中會.具體1情況/怎樣；花了多長時間？76開發(fā)人員是否檢杳測試人員的測試用例嗎？77驗收測試誰來做？驗收測

8、試記錄？對于驗收測試發(fā)現(xiàn)的問題，你們有沒有分析為什么你們在走杳或者評審的時候沒有找到這些問題？后來你們有改進你們的測試用例嗎？78測試用例是否有進行版本管理？79TD中有保留測試用例的歷史版本記錄嗎？80你們的項目基線是什么時候建立的？81單兀測試報告和系統(tǒng)測試分析報告是如何與的？82你認為項目最關鍵的地方在哪里？83在你們的項目中，會收集哪些度量數(shù)據(jù)？84你們花了多少時間填寫需求跟蹤矩陣？85你認為在你們的項目中哪些流程做得太復雜了，或者哪些流程可以不做？86項目主要做了哪些功能？介紹一下產品。87你們的項目人員通過什么方法來了解項目的需求？花多少時間來做需求的討論？88你們項目有沒有安排什

9、么培訓來幫你們的開發(fā)人員更了解你們的需求？89你們怎樣確認你們的項目人員對需求有足夠的了解？90怎樣跟你們的內部客戶了解和確認需求的？91有沒有其他的方法幫他們挖掘需求？92怎樣開發(fā)你們的腳本？93你們怎樣設計你們的產品？94你們開發(fā)這些系統(tǒng)有哪些競爭對手？95之刖1.0的系統(tǒng),客戶在用的時候有沒有遇到什么問題？96為什么會有界面？97有文檔記錄多少的數(shù)據(jù)量對應多少的內存？98測試人員怎樣模擬流量的問題？是否寫在測試用例？99你們會怎樣寫測試報告？需要寫模擬流量的相關結果。100測試報告有哪些內容？101除了流量的問題還有別的問題需要考慮到嗎？102培訓計劃是怎樣建起來的？103怎樣記錄人員參

10、加了哪些培訓？104怎樣評估培訓效果？培訓資料在服務器上的備份？105有沒有從客戶方面考慮一些特殊情況？（即有沒有性能方面的需求？）106你們在設計的時候，怎樣考慮設計能否滿足需求？107在據(jù)庫的時設計曲怎道模擬性能的求？量？介用什么工108在測試的時候，你們怎樣模擬實際的數(shù)據(jù)量會丿|1么丄具?109關于這些性能的需求，你們有沒有做決策分析？110在你們的項目中，有性能方面的需求，在開發(fā)的時候，怎樣關注你們的源代碼能否滿足這些需求？怎樣檢查？111性能方面的測試用例有寫嗎？112會用到什么樣的工具來幫助做性能測試？113有沒有寫關于性能測試方面的報告？114性能測試方面的計劃什么時候寫？注：跑

11、Roadrunner產生的報告要有115你們項目作了哪些CMMI四級五級方面的改進？116自動化測試需要做到怎么樣的覆蓋率？自動化能在確認驗收階段做，為什么不能在單元測試和系統(tǒng)測試階段使用？117集成測試、系統(tǒng)測試會用自動化測試嗎？118項目關鍵過程用的是改進刖還是改進后的模型？用這些模型，你們感覺有幫助嗎？119每個階段的數(shù)據(jù)與預測的數(shù)據(jù)不一致的時候會做什么的分析呢？120個項目的QA怎么開始？121般周審計哪些內容？122基線的審計在什么時候？123是否有列表展示檢查點？124再執(zhí)行的過程中怎作是否做了相應否會滿足項目的量化目125再執(zhí)仃的過程中怎么樣怎道壩口是否會滿足壩曰的量化曰標？12

12、6在Qa工作中遇到什么樣的困難？127對于QA收集哪些度量數(shù)據(jù)？128EPG的工作是否有組織QA來審計？129怎么樣做備份？130怎樣檢查備份是否成功？131災難恢復計劃？132模擬預測時，缺陷注入數(shù)的范圍,如何確定是可以滿足我們的目標的？133改進后還會重新模擬預測嗎？回答要點內容均在項目關鍵過程監(jiān)控表中。項目組員需要知道自己所在的項目米用了什么創(chuàng)新，以及做了哪些原因分析.有協(xié)助項目經理對關鍵過程進行預測以及相關的量化管理，提供創(chuàng)新方法供項目參考，協(xié)助項目組做原因分析。了解有有用有，對于高級工程師來說，1個UCP需要花10小時來完成；對于中級工程師來說，1個UCP需要花20小時來完成；對于初

13、級工程師來說，1個UCP需要花30小時來完成；有及時更新需求點在各個階段的狀態(tài)，每次只需花少量的時間有，具體詳見自己所在項目的決策分析報告，項目組員都需要了解決策的內容。有，具體參見風險計劃及跟蹤表，自己所在的項目有哪些風險，項目所有人都需要知道。風險跟蹤表-列入的都是關鍵的風險，需要跟蹤的。不重要的風險，都在項目例會上解決了有。在配置管理計劃及跟蹤表中，都有詳細記錄。產品集成計劃與報告中有記錄因為本地環(huán)境不干靜,為保證編譯的準確性，需要有單獨的干凈的環(huán)境做編譯有工作量、工期、缺陷、需求數(shù)、風險個數(shù)等。具體參見項目度量數(shù)據(jù)庫沒有公司對需求開發(fā)、詳細設計、驗收測試二個關鍵過程分別建立了基線模型；

14、創(chuàng)新：需求開發(fā)米用平臺錄入，詳細設計米用分多次組內討論的形式,驗收測試采用自動化測試。（創(chuàng)新的具體內容需要知道）項目關鍵過程監(jiān)控表中，三個關鍵過程的單位規(guī)模缺陷數(shù)和單位規(guī)模投入時間都有各自的目標值。項目在實施過程中，需要主動地去滿足這些目標值。即回答項目是如何做需求調研的，需要列舉需求調研的方式根據(jù)項目實際情況回答參與項目的需求評審，查看項目的需求說明書通過項目例會、需求評審會開發(fā)人員做系統(tǒng)設計，測試人員編寫測試用例（測試計劃中內容）對每個模塊（或需求）實現(xiàn)的功能來制定（根據(jù)每個模塊需要測的功能來估算）根據(jù)項目規(guī)模、平均生產率、工作量分配比例來估算測試時間（具體參看項目估算報告的“第四步估算工

15、作量”，有關測試的相關估算）開發(fā)人員均了解并參加項目的估算，UCP=TCF*ECF*UUCP,通過估算該需求用例種類和用例角色的復雜度，得出該需求的UUCP（原始用例點數(shù)），然后乘以TCF（技術復雜度）和ECF（環(huán)境復雜度），得出該需求的UCP（具體參看項目估算報告的“第三步計算規(guī)模數(shù)”）同上，具體參看項目估算報告的“第三步計算規(guī)模數(shù)”；工作量=項目規(guī)模（UCP）*平均生產率該估算方法準確有。根據(jù)需求來做。通過設計評審項目組所有成員，包括測試人員、QA和配置根據(jù)項目實際情況回答設計文檔有概要設計說明書，詳細設計說明書（包括模塊設計、數(shù)據(jù)庫設計、界面設計、接口設計的相關內谷）參見DevPIan中

16、的項目進度計劃檢查待評審的工作產品,將發(fā)現(xiàn)的缺陷填寫到技術評審準備表中；將有異議的地方與評審小組共同商討解決方案；所花的時間，參見各自所在項目的設計評審報告編碼需求時只提到接口的大致內容，在概要設計中會有比較詳細的描述。是設計評審的時候，測試人員會參加，如有不清楚的地方，測試人員會提出，開發(fā)人員對設計文檔加以完善,最終大家共同確認通過。測試組長、QA、項目經理會檢查，最終經測試經理審核通過。代碼互相交叉檢查將缺陷記錄到TD中有項目經理或項目經理指定專人會去檢查單元測試的情況DevTrack中有對該任務的跟蹤記錄是把確認好的，放到集成區(qū)提過程改進建議，將相關內容記錄到過程改進建議表中，提交給EP

17、G根據(jù)實際情況回答注：不能說公司的過程、模版很復雜之類的，如果要說有，那么，舉的例子最好是些很輕微的問題。結合項目關鍵過程監(jiān)控表中的內容進行詳細講解有用，數(shù)據(jù)還是比較準確的參看各自所在項目的項目關鍵過程監(jiān)控表中的改進創(chuàng)新”。參看各自所在項目的項目關鍵過程監(jiān)控表中的原因分析”。UCP=TCF*ECF*UUCP,通過估算各功能點的用例種類和用例角色的復雜度，得出UUCP（原始用例點數(shù)），然后乘以TCF（技術復雜度）和ECF（環(huán)境復雜度），得出各功能點的UCP（具體參看項目估算報告的“第三步計算規(guī)模數(shù)”）結合各自項目的情況，說明如何做代碼走查。根據(jù)項目的實際情況回答根據(jù)項目的實際情況回答通過同行評審

18、即回答技術評審的流程：主要分為評審前準備、評審過程、評審后對問題的跟蹤驗證。根據(jù)項目實際情況回答有。結合決策分析報告的候選方案評估準則”中的評分標準說明”進行說明。看決策分析報告的“決策參與人員”中是否有你的名字。有；組織提供給項目組項目定義過程的模板，項目通過填寫項目特征值，自動生成項目過程及工作產品裁剪的相關內容，然后再對個別的過程或工作產品的裁剪情況進行微調。結合項目關鍵過程監(jiān)控表中的內容進行詳細講解有參看決策分析報告的“決策參與人員”參看項目的風險計劃及跟蹤表根據(jù)項目實際情況回答參看項目的性能測試結果報告根據(jù)項目實際情況回答DevPIan結合各自項目的情況，說明如何做代碼走查。同行評審

19、，或項目經理對代碼走查的情況進行檢查有。具體的，需結合項目情況舉個例子前者會。結合各自項目的情況進行說明如果進度不緊，這個方法挺好的，有助于找出足夠的缺陷。有。具體的，結合項目情況進行舉例說明。有由質量管理部經理安排其他的測試人員（非本項目的測試人員）來做；測試出的缺陷記錄到TD中；有有，測試用例經審核通過后，納入項目的基線中有階段結束后，及時建立該階段的基線，具體在配置管理計劃及跟蹤表中有詳細安排。具體需結合這兩份報告的大致內容進行說明。工合項工關鍵過程監(jiān)控表數(shù)中的險個數(shù)行詳細體解見項目度量數(shù)工作量、丄期、缺陷、需求數(shù)乂、風險1數(shù)乂等。具體參見項曰度量數(shù)據(jù)庫及時更新需求點在各個階段的狀態(tài),每次只需花少量的時間沒有根據(jù)項目實際情況回答需求評審。所花的時間參見需求評審的技術評審報告中記錄的時間。（包括評審前的準備時間和評審過程的時間）有（注意：幫帶、自學等都屬于培訓）需求評審會，項目例會讓客戶參與需求的評審，或者把需求說明書發(fā)給客戶確認。多了解客戶的環(huán)境,幫助客戶去挖掘他們的需求根據(jù)項目實際情況回答根據(jù)項目實際情況回答根據(jù)項目實際情況回答根據(jù)項目實際情況回答根據(jù)項目實際情況回答根據(jù)項目