| CMMI變更管理為軟件開發(fā)保駕護航 |
| 新聞類別： 行業(yè)動態(tài) 瀏覽量：2801 |
CMMI變更管理過程為軟件開發(fā)保駕護航
在軟件開發(fā)的過程中，往往會出現(xiàn)業(yè)務需求、技術方案等變更，隨之產(chǎn)生的系統(tǒng)功能的變更也會不可避免地對軟件開發(fā)工作量、項目工期、產(chǎn)品質量等產(chǎn)生影響。既然變更不可避免，如何在實施變更的同時，有效化解變更帶來的風險并保持日常工作的穩(wěn)定和高效，就成為至關重要的問題。 在有效標示了配置并進行管理之后，要如何保證它們在復雜多變的開發(fā)過程中真正的處于受控的狀態(tài)，并在任何情況下都能迅速的恢復到任一歷史狀態(tài)，這就要依賴有效的變更管理。 CMMI中的變更管理是變更已發(fā)布文檔和數(shù)據(jù)的閉環(huán)過程，規(guī)范了對納入配置管理的配置項進行變更的完整流程。在項目啟動時，項目經(jīng)理需要在項目總體計劃中明確變更控制委員會（CCB）成員，由甲乙雙方管理層人員、業(yè)務人員、項目經(jīng)理、核心技術人員、測試負責人等干系人組成的CCB履行審批基線變更請求、審核基線變更實施結果等職責，為變更過程的順利實施保駕護航。 項目實施過程中發(fā)生業(yè)務變更或技術變更時，項目組一是提出變更申請，非基線變更申請?zhí)峤恢另椖拷?jīng)理進行審批，基線變更申請則提交至CCB。 二是由項目經(jīng)理組織CCB對基線變更申請進行評估，評估變更的內(nèi)容及范圍是否合理、變更風險是否可接受、工作量及工期變更是否可接受、受影響的配置項是否已被充分考慮等內(nèi)容，確定變更請求的拒絕、接受或擱置。 三是已通過CCB審批的變更申請，項目經(jīng)理拆分變更任務，指定人員實施變更。 四是項目經(jīng)理組織CCB評審變更的配置項，再由配置管理員簽入評審通過的配置項，完成變更驗證與確認。 五是配置管理員依據(jù)審批通過的《變更記錄表》將基線發(fā)布給產(chǎn)品相關人員與部門，完成變更發(fā)布。同時，項目經(jīng)理應對本次變更引起的需求變更對應關系的變化進行調(diào)整，及時更新《需求跟蹤矩陣》
缺少對變更有效的控制，往往會造成配置管理的無序，導致項目返工、延期，甚至失敗。只有讓規(guī)范的變更流程貫穿于產(chǎn)品的整個生命周期，讓所有項目組成員了解變更、形成共識、接受變更，遵循規(guī)范的變管理流程，才能盡可能地降低變更風險及影響，提升軟件開發(fā)的效率和質量。
2020年申請辦理CMMI資質有哪些要求和好處？
CMM-DEV：針對供應方：軟件開發(fā)企業(yè)、外包、集成或者硬件企業(yè)；用于知道開發(fā)過程； CMMI 1：初始級。軟件過程是無序的，有時甚至是混亂的，對過程幾乎沒有定義，成功取決于個人努力。管理是反應式的。 CMMI 2：可管理級。建立了基本的項目管理過程來跟蹤費用、進度和功能特性。制定了必要的過程紀律，能重復早先類似應用項目取得的成功經(jīng)驗。 CMMI 3：已定義級。已將軟件管理和工程兩方面的過程文檔化、標準化，并綜合成該組織的標準軟件過程。所有項目均使用經(jīng)批準、剪裁的標準軟件過程來開發(fā)和維護軟件，軟件產(chǎn)品的生產(chǎn)在整個軟件過程是可見的。 CMMI 4：量化管理級。分析對軟件過程和產(chǎn)品質量的詳細度量數(shù)據(jù)，對軟件過程和產(chǎn)品都有定量的理解與控制。管理有一個作出結論的客觀依據(jù)，管理能夠在定量的范圍內(nèi)預測性能。 CMMI 5：優(yōu)化管理級。過程的量化反饋和先進的新思想、新技術促使過程持續(xù)不斷改進。 申請CMMI等級一般從三級申請，申請的條件有研發(fā)項目數(shù)量要求和研發(fā)人員數(shù)量要求。 申請CMMI資質有哪些好處？ 1、生產(chǎn)力約有10%到20%的提升； 2、產(chǎn)品錯誤率約降低一個數(shù)量級； 3、對項目的預估與控制能力約提升40%到50%； 4、軟件企業(yè)參加招投標的重要參考依據(jù)； 5、軟件成熟度每提升一級， 約可降低5%到10%的開發(fā)成本。
|
