cmmi軟件開發(fā)流程圖

1、軟件開發(fā)流程軟件工程生命周期模型需求分析需求分析流程圖過程描述1、由部門經(jīng)理組建臨時工程組，并指定PM開發(fā)人員、測試人員、QA人數(shù)根據(jù)工程規(guī)模確定。2、PM制定需求階段日程表，該表須通過研發(fā)經(jīng)理審核3、PM指示配置管理員建立配置庫。4、 由PM與測試負責人提岀裁剪申請，QA指導臨時工程組人員對工程進展裁剪，形成工程裁剪表。5、EPG和部門經(jīng)理對裁剪結果進展審批，審批通過工程裁剪表正式生效。6、 PM與測試負責人確定工程管理機制，容包括組織結構、 溝通、跟蹤、報告、風險管理、問題管理、QACM等。7、工程組人員與客戶進展溝通，編寫需求清單列表。8、PM組織臨時工程組成員確定系統(tǒng)架構，編寫架構設計

2、書和需求規(guī)格書。架構設計過程中的重要的技術 方案選擇、開發(fā) /采購/ 復用分析等容要明確表達在架構設計書中。? 對技術方案選擇 例如，系統(tǒng)結構、開發(fā)平臺、數(shù)據(jù)庫等的選擇 ，要事先建立評價準那么 例如，滿 足系統(tǒng)需求的能力 例如，功能、性能、可靠性等 、技術的開展前景、供應商資質(zhì)與實力等 與相對 優(yōu)先級，采用討論表決的方法選擇并確定最終的技術方案。? 關于自行開發(fā)和采購復用的分析，如果公司有根本滿足系統(tǒng)需要的可復用組件 包括其分析、設計、代碼、測試用例等 ，一般應進展復用；本公司沒有能力開發(fā)或沒有必要開發(fā)的非核心技術局部，如果采購本錢在工程可承受圍， 可考慮采購；否那么，由工程組自行開發(fā)。架構設

3、計的總體候選方案選擇和供應商選擇要使用正式的方法做決策。9、PM召集臨時工程組、測試負責人等技術骨干評審架構設計書和需求規(guī)格書。10、PM組織臨時工程組與客戶溝通、說明需求，必要時編制系統(tǒng)原型向客戶展示，直到臨時工程組、客戶 就需求的真實含義達成共識、客戶書面確認需求規(guī)格書為止。11、臨時工程組確定工程目標的圍，明確系統(tǒng)邊界，建立系統(tǒng)的模塊分解結構。12、PM與測試負責人遵循?工程估算流程?組織人員進展工程估算。13、PM測試負責人與臨時工程組確定工程關鍵參數(shù)。? 工作量、工期、日程、人數(shù)? 本錢 / 預算由于本公司的工程的絕大局部本錢是人力本錢，對估計本錢的管理等同于估計工作 量的管理，對實

4、際本錢的管理等同于實際工作量的管理，對預算的管理等同于方案工作量的管 理。? 質(zhì)量目標14、PM測試負責人與部門經(jīng)理協(xié)調(diào)人員與資源、方案知識技能、協(xié)調(diào)相關干系人的參與。15、工程組基于公司環(huán)境標準，結合工程實際情況建立適合的工作環(huán)境。16、PM測試負責人編制工程方案書。17、PM測試負責人編制工程日程表。18、 臨時工程組、研發(fā)部、QA評審工程方案書，評審通過后正式生效。19、PM指示配置管理員建立配置基線。20、 PM編制階段總結報告工程總結報告中的度量分析頁面，召開階段會議。設計設計流程圖過程描述1) 工程經(jīng)理組織工程組人員學習需求規(guī)格書;2) 工程經(jīng)理組織工程組中的開發(fā)人員確定設計約束，

5、這些約束可能包括一下幾個方面:需求約束，需求規(guī)格書中約定的設計約束；隱含約束，需求規(guī)格書中沒有，但對系統(tǒng)的設計或者使用帶來潛在影響的特殊約束。3工程經(jīng)理與開發(fā)人員根據(jù)需求規(guī)格書、架構設計書進展設計，編制?設計說明書? 。? 基于對業(yè)務和現(xiàn)有系統(tǒng)結構的理解，劃分 / 調(diào)整系統(tǒng)模塊。? 描述各系統(tǒng)模塊協(xié)作實現(xiàn)各業(yè)務場景的處理流程 可用序列圖 。? 必要時 通常要反復幾輪 ，修正系統(tǒng)模塊劃分和處理流程。? 描述各處理流程中的各活動的輸入、處理、輸出和可能的異常。? 系統(tǒng)模塊構成與其相互關系。 可用類圖、包圖。 ? 系統(tǒng)模塊部設計。 功能、管理的數(shù)據(jù)、對外的效勞、對的效勞, 要求明確各模塊的對外接口。

6、 4開發(fā)人員根據(jù)?需求規(guī)格書? 、?架構設計書?進展設計、 ?設計說明書?進展用戶界面和數(shù)據(jù)庫以與接口 等方面的詳細設計，納入?設計說明書? 。? 用戶界面設計。 建議使用 Visio 中的窗口和對話框、工具欄和菜單、公共控件這幾個形狀組來繪 制，具體操作方法是：點擊“文件選項 選定“形狀 選定“軟件和數(shù)據(jù)庫 選定“軟件 依次選定上述三類形狀組。 ? 數(shù)據(jù)庫設計。? 文件設計 文件的存貯位置與名稱、格式與容定義。 。? 接口設計。 含部通訊接口、外部通訊接口、用戶圖形界面、報表、其它接口。 5工程經(jīng)理組織開發(fā)人員、測試人員與其他技術骨干評審?設計說明書? 。6配置管理員建立設計階段配置基線；7

7、工程經(jīng)理編制階段報告 工程總結報告中的度量數(shù)據(jù)頁面 ，組織工程組人員并邀請部門經(jīng)理召開階段會 議，并形成會議紀要。編碼流程編碼流程圖輸入開發(fā)人員輸出開始編碼標準界面標準設計說明書V(1)繪制詳細類圖r(2)審核詳細類圖1r(3)培訓編碼、界面 »標準1!(4)開發(fā)環(huán)境配置(5)編碼與調(diào)試|1r(6)評審代碼4¥知米囪(7)進行聯(lián)調(diào)(8)編寫階段報告一過程描述a) 根據(jù)準入條件中的設計文檔，繪制詳細類圖，以指導編碼。b) 對生成的類圖進展審核。c) 工程經(jīng)理組織開發(fā)人員學習編碼規(guī)、用戶界面規(guī)，以保障程序的可靠性、可讀性、可修改性、可維護 性、一致性以與界面的規(guī)性。d) 開發(fā)環(huán)

8、境的配置工程經(jīng)理或其指定人員在公司的?開發(fā)環(huán)境指南?的根底上編制開發(fā)環(huán)境配置說明，工程組成員遵照開發(fā) 環(huán)境配置說明配置統(tǒng)一的開發(fā)環(huán)境。e) 編寫與調(diào)試BUG。開發(fā)人員根據(jù)設計說明書和編碼規(guī)、用戶界面規(guī)的要求編寫代碼，自行進展檢查、調(diào)試并解決f) 評審代碼 工程經(jīng)理組織開發(fā)人員、工程組外的專家等對本工程修訂的所有代碼進展評審或?qū)徟) 進展自測 開發(fā)人員對代碼進展聯(lián)調(diào)，對照測試人員編制的測試用例中的正常業(yè)務流程局部在測試用例中已明確標岀進展測試，并全部通過測試。聯(lián)調(diào)測試中，不要求記錄BUG不須編制測試報告。h) 編寫階段報告 工程經(jīng)理編制階段報告，召開階段會議。編碼規(guī)見規(guī)說明書測試流程測試流程

9、圖過程描述1、測試負責人組織測試人員學習、評審?用戶需求列表?、?需求規(guī)格書?。在學習、評審過程中充分理解客戶與業(yè)務需求，確保文檔信息的正確性、充分性、一致性。2、測試負責人組織測試人員完成編寫整個工程的測試方案。3、測試負責人組織測試人員基于?需求規(guī)格書?編寫測試用例。當?設計說明書?通過評審后，測試人員基于?設計說明書?對測試用例進展必要的調(diào)整。測試用例的組織分類須遵循以下原那么：? 測試用例的組織分類例如，文檔名、頁面名、一級標題、二級標題等必須與需求規(guī)格書中的各需求點明確對應起來。4、測試負責人組織測試人員、開發(fā)人員、PM評審測試方案、測試用例。5、測試負責人指示配置管理員將測試方案與

10、測試用例文檔入庫。6、 測試負責人組織PM開發(fā)人員、測試人員召開階段會議并形成階段報告。驗收流程驗收流程圖過程描述1)工程經(jīng)理與客服人員溝通驗收事項2) 客服人員在客戶指定的環(huán)境下參照?安裝維護手冊?進展產(chǎn)品安裝調(diào)試，并把合同約定的文檔、源程 序等交給客戶。3) 客服人員對客戶進展系統(tǒng)操作方法培訓。4) 客戶試用系統(tǒng)開展業(yè)務， 測試人員收集客戶反響的問題； 如果客戶驗收測試環(huán)境與生產(chǎn)環(huán)境差異明顯 時，要進展性能測試，以保證滿足系統(tǒng)性能需求。5) 測試人員在驗收中發(fā)現(xiàn)缺陷并告知工程經(jīng)理， 工程經(jīng)理將缺陷記錄到 BugFree 中。某些情況下 例如， 缺陷描述不詳、明顯不是缺陷等工程經(jīng)理可以向相關

11、人員測試人員、客戶解釋、說明，達成一 致后駁回相關人員測試人員、客戶提出的問題。6) 工程經(jīng)理將缺陷分派給適合的開發(fā)人員。7) 開發(fā)人員分析缺陷的原因與解決該缺陷，并將該缺陷的解決方法與解決狀態(tài)更新BugFree 。8) 工程經(jīng)理將所有已處理的缺陷轉移至測試人員進展缺陷修復確實認。? 如果測試結果說明缺陷仍未解決， 工程組測試人員通過工程經(jīng)理將該缺陷返回給處理該缺陷的開 發(fā)人員。? 如果測試結果說明缺陷已解決，工程組測試人員告知工程經(jīng)理，工程經(jīng)理關閉該缺陷。9) 在更新驗收版本之前，測試人員要進展一次回歸測試。對即將發(fā)布的新版本，進展一次整體的測試。10) 驗收中發(fā)現(xiàn)的缺陷累積到一定程度或嚴重

12、缺陷導致驗收無法繼續(xù)時，應更新驗收版本。? 必須解決的缺陷全部解決后，配置管理員更新代碼與配套文檔并標識驗收的產(chǎn)品版本，工程經(jīng)理 指定人員更新驗收版本并部署至驗收環(huán)境中。? 測試人員分析本次更新涉與的圍，確定回歸測試的圍，并在此圍進展回歸測試。? 如果更新驗收版本之后，要回到活動4 ，直至驗收通過。11) 工程經(jīng)理和客戶代表根據(jù)驗收期間的測試記錄等依據(jù)驗收通過準那么， 達成一致， 根據(jù)所簽署的商務 合同，向客戶交付合同中要求提供的交付物，包括?用戶手冊? 、?安裝維護手冊?等，并取得客戶驗 收通過的書面確認。12) 工程經(jīng)理收集整理工程相關的資料和數(shù)據(jù)，在工程組分配工程關閉各項工作，包括技術總結、軟件產(chǎn)品總結，相關數(shù)據(jù)整理等。13) 配置管理員對配置庫進展更新，整理相關工作產(chǎn)品。14) 工