CMMI3訪談問題及答案--需求設計開發(fā)人員_第1頁
CMMI3訪談問題及答案--需求設計開發(fā)人員_第2頁
CMMI3訪談問題及答案--需求設計開發(fā)人員_第3頁
CMMI3訪談問題及答案--需求設計開發(fā)人員_第4頁
CMMI3訪談問題及答案--需求設計開發(fā)人員_第5頁
免費預覽已結束,剩余1頁可下載查看

下載本文檔

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

文檔簡介

1、需求設計開發(fā)人員1. 自我介紹,職責我叫XXX是XX項目的XXX角色。我們項目從X年X月X日開始,到X 年X月X日結束。2. 工作由誰分配?PM分配,我們從項目計劃,項目開發(fā)計劃.mpp,周例會中獲?。?. 怎么做需求的?在項目開發(fā)計劃基線后,系統(tǒng)分析師按照計劃制定需求調(diào)研計劃 , 確定活動安排和時間安排,實施人員,客戶配合人員,調(diào)研內(nèi)容等。PM審核需求調(diào)研計劃,通過后,系統(tǒng)分析師做調(diào)研前的準備,準備需求調(diào)研提綱, 按照計劃進行現(xiàn)場調(diào)研,明確客戶重點,詳細記錄并分析隱含需求?,F(xiàn)場調(diào) 研完成后,系統(tǒng)分析師完成客戶需求說明書并進行評審,通過后,PM與客戶確認需求(我們采用了書面簽字的方式,有簽字確

2、認單),通知CM基 線。客戶需求說明書基線后,系統(tǒng)分析師討論分析客戶需求,編寫軟件需求 規(guī)格說明書和評審并基線。4. 怎么做設計的?1、 在軟件需求規(guī)格說明書基線后,進入設計階段的工作。PM按照計劃分配設計 任務,設計人員做設計準備,明確設計方法,制定軟件設計說明書,通過評 審后納入基線。2、軟件設計說明書內(nèi)容包括總體設計、功能性需求設計、非功能性需求設計、接口設計、結構化設計、數(shù)據(jù)庫設計、界面設計、權限設計、安全設計、系統(tǒng)異常處理設計和系統(tǒng)維護設計等。5. 設計如何評審?參加設計評審的有PM項目組成員,其他項目技術骨干等。PM向評審委員會主任提交評審申請,評審委員會主任任命評審組長和組 員,

3、評審組長發(fā)評審通知、評審檢查單和評審材料,評審人員對材料進行預 審,并在會議前將結果反饋給評審組長,評審組長匯總大家發(fā)現(xiàn)的問題記錄 在缺陷記錄表中,召開評審會議。在會議上采用逐頁評審的方式,隨時指出 發(fā)現(xiàn)的問題, 由作者解答, 評審小組確認問題嚴重級別、 責任人和修改時間, 得出評審結論(直接通過,修改后通過,不通過) 。評審組長指定人員對發(fā) 現(xiàn)的問題進行跟蹤, 修改完之后,評審組長完成評審總結報告發(fā)給相關人員, 評審結束。6. 是否參與評審?發(fā)現(xiàn)了哪些問題?參加了。參加評審的工作產(chǎn)品包括:項目開發(fā)計劃、質(zhì)量保證計劃、配 置管理計劃、客戶需求說明書、軟件需求規(guī)格說明書、軟件設計說明書、關 鍵代

4、碼(非正式評審)、單元測試計劃、集成系統(tǒng)測試計劃。 (舉 1-2 個自己 發(fā)現(xiàn)的問題例子)7. 怎么做編碼和測試的?在軟件設計說明書基線后, PM:(1) 分配編寫單元測試計劃 、編碼及單元測試任務。(2) 若程序員不熟悉編碼規(guī)范, 可以組織對其進行培訓。 (說出本項目使用的 編碼規(guī)范,是否進行了培訓)(3) 確定編碼及單元測試的具體時間。(4) 確定關鍵模塊,編碼順序。(5) 與軟件設計師共同確定單元代碼的測試內(nèi)容,測試方式:如靜態(tài)測試, 或者動態(tài)測試。程序員搭建編碼及單元測試環(huán)境, 根據(jù)軟件設計說明書和編碼規(guī)范進行編碼和調(diào)試,按照評審后的單元測試計劃進行測試。PM組織對單元代碼進行檢查后納

5、入配置管理單元測試通過后,軟件設計師與 PM確定產(chǎn)品集成順序,準備測試環(huán)境, 測試員編寫集成系統(tǒng)測試計劃并進行評審,計劃包括測試具體內(nèi)容,測試進 度,測試方法,測試資源等內(nèi)容。測試員編寫測試用例,PM審批后進行測試。 我們項目是用TD進行測試的。測試過程中,PM協(xié)調(diào)解決測試過程中遇見的 問題直至結束。8. 編碼是否有編碼規(guī)范?說出本項目使用的編碼規(guī)范,是否進行了培訓9. 單元測試發(fā)現(xiàn)的缺陷如何處理?發(fā)現(xiàn)缺陷,程序員對代碼進行修改,修改后,進行回歸測試,直到缺陷 已關閉。確認所有缺陷已關閉,并將測試實際結果記錄到單元測試用例 最后的跟蹤列中。10. 如何寫用例?根據(jù)需求規(guī)格說明書, 覆蓋測試需求

6、;項目特別的流程分析, 異常情況, 用例發(fā)現(xiàn)缺陷的能力。11. 集成環(huán)境是怎樣的?描述本項目的集成環(huán)境。12. 集成順序是如何?為何要這么做?描述本項目的集成順序和原因。13. 是否存在開發(fā)人員覺得不是BUG測試人員覺得是的情況。怎么解決?出現(xiàn)這種情況會向項目經(jīng)理反映,在周會上進行討論,給出結論。14. 開發(fā)人員如何對配置庫進行使用?根據(jù)配置管理計劃中分配的權限使用配置管理工具。及時上傳、下載配 置庫中更新的文件。有基線的工作產(chǎn)品 CM會發(fā)布給大家,我們在配置管理 狀態(tài)報告中查看每個工作產(chǎn)品的最新狀態(tài)。15. 接受過哪些跟設計開發(fā)相關的培訓?編碼規(guī)范培訓、 dorado 、框架培訓 (Spri

7、ng 和 hibernate) 、(其他跟自 己角色相關的培訓)16. QA有無檢查你們的工作?有。在每個階段結束的時候,QA都會來檢查我們的工作,用相應的檢查 表來檢查。還會自己去檢查我們的工作產(chǎn)品,發(fā)現(xiàn)的問題會記錄到不符合問 題跟蹤表中,項目經(jīng)理指定修改人員對問題修改,QA驗證后關閉。如果有無 法關閉的不符合項,QA會層層上報直至關閉。QA還提供過程和模版的培訓,解答我們提出的問題。17. 項目測試目的?發(fā)現(xiàn)問題,確保產(chǎn)品達到需求的要求。18. 如何判斷測試已通過?根據(jù)項目開發(fā)計劃 -測試計劃中規(guī)定的測試退出準則,對測試結果進行 分析,如測試用例的覆蓋和缺陷解決率,穩(wěn)定性,是否達到結束要求

8、準則,達到要求可通過測試。19. 測試報告的內(nèi)容?測試進度、缺陷分析、測試總結(結論,不足和建議)20. 在項目進行過程中,如果發(fā)現(xiàn)過程存在問題你會怎么辦?填寫過程改進建議單交給QA或 EPG成員,他們會討論修改。21. 你提出過改進建議嗎?有/沒有,XX時候,提了 XX建議,XX時候被通過了。22. 公司組織級有沒有為你的項目提供幫助?有。首先公司制定了 14 個過程的過程和模版文檔,還有許多有用的指 導書和規(guī)范。其次,在項目開始的時候,可以參考了很多財富庫中以往同類項目的歷 史數(shù)據(jù),如度量目標、估算生產(chǎn)率、風險等,在開發(fā)階段還有許多重用庫中 可重用的代碼等。在經(jīng)驗庫中還有很多值得借鑒的經(jīng)驗教訓,使我們項目能 少走彎路。第三,EPG隨時收集過程改進建議并及時開會討論,每半年組織一次內(nèi)部評估,對我們現(xiàn)階段的工作進行檢查,及時進行改進。第四,公司每年安排至少兩輪CMM過程

溫馨提示

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

評論

0/150

提交評論