CMMI

CMMI全稱是Capability Maturity Model Integration，即能力成熟度模型集成(也有稱為:軟件能力成熟度集成模型) ，是美國國防部的一個設想，1994年由美國國防部(United States Department of Defense)與卡內(nèi)基-梅隆大學(Carnegie-Mellon University)下的軟件工程研究中心(Software Engineering Institute，SEISM)以及美國國防工業(yè)協(xié)會(National Defense Industrial Association)共同開發(fā)和研制的，他們計劃把現(xiàn)在所有現(xiàn)存實施的與即將被發(fā)展出來的各種能力成熟度模型，集成到一個框架中去，申請此認證的前提條件是該企業(yè)具有有效的軟件企業(yè)認定證書。

一、概述

項目需求管理（Requirements Management, REQM） 的目的， 在于管理項目產(chǎn)品及產(chǎn) 品組件的需求， 并界定這些需求與項目計劃及工作產(chǎn)品間的差異。

項目實行適當?shù)牟襟E， 確保議定的需求是受管理的， 以支持項目策劃和執(zhí)行的需要。需求管理也須記錄需求變更及其 理由， 并維護原始需求與所有產(chǎn)品和產(chǎn)品組件需求的間的雙向追溯性。從實踐意義上講， 需求是針對客戶各類需求經(jīng)雙方（或多方） 溝通確認后形成的一種協(xié) 議， 協(xié)議的范圍是明確的、 可控的。在協(xié)議簽訂后， 需求的計劃有定制、 進度有跟蹤、 結果 有度量。針對需求的變化， 需要明確需求變化的原因及變更內(nèi)容。需求的緊急程度及嚴重程 度可評估， 以確定需求及其變更的優(yōu)先級， 從而排定切實可行的需求計劃。

下面我們就如下幾個方面對需求管理體系進行分析、 研究：

1， 需求的管理的基本活動

2， 結合當前項目簡述需求管理實踐中的問題、 解決方案 。

二、需求管理的基本活動

在需求管理過程中， 包含如下關鍵活動：

1、 需求提出

針對客戶的需求提出， 開發(fā)方進入需求了解環(huán)節(jié)。需求了解采用訪談、 文檔、 多方會 議等形式采集基礎信息， 在此基礎上結合系統(tǒng)原型進行差異化分析。

2、 需求分析及評審

需求分析中， 針對需求、 系統(tǒng)差異進行差異記錄并制定相應的矯正方案。

3、 需求計劃定制及跟蹤

需求計劃的定制以用戶、 開發(fā)團隊、 計劃跟蹤者協(xié)商一致的結果為依據(jù)。其過程實質(zhì) 是取得用戶對于進度的認可、 取得團隊對于進度的承諾。其成果物—需求跟蹤表， 對于 后續(xù)的需求跟蹤起到警示標的作用。

4、 需求變更控制

用戶對于系統(tǒng)、 需求的理解是漸進的過程， 因此某種意義上說需求變更存在必然性。如何有效率和有效果地管理這些新增需求或變更需求是很重要的。如果需求變更控制不 當， 不但造成新的需求變更得不到滿足， 而且對于需求進度的管理、 對于系統(tǒng)穩(wěn)定性的 影響都將是負面的。變更控制， 需要追溯變更的緣由， 記錄變更的原因、 內(nèi)容， 并做好 變更比例的度量。保證需求的可追溯性， 對于需求變更管理至關重要；在進行需求變更 對項目計劃、 活動及工作產(chǎn)品的影響評估時尤其需要需求追溯表這些管理工具。

5、 需求制度建立及其優(yōu)化

在需求管理過程中的各個環(huán)節(jié)， 存在較多的爭執(zhí)點， 這就需要制度進行明確。形成一 個系統(tǒng)的、 規(guī)范的制度， 使需求管理過程可細化度量；制度的形成需要配備對應的資源， 比 如需求跟蹤工具、 需求干系人的培訓管理。通過制度保證需求過程可監(jiān)控、 上層管理者可以 跟蹤需求的進展情況等。6、 需求成本控制

需求開發(fā)面臨成本投入的現(xiàn)實， 需求開發(fā)本身、 需求管理本身， 因需求開發(fā)、 管理造成 的物力、 人力消耗都是現(xiàn)實的成本。在日常系統(tǒng)運作中， 對于需求必要性的評審， 對于系統(tǒng) 變更的控制， 對于人員的培訓都是提高效率降低總成本的方式。

三、 項目實踐過程示例

（一） 需求管理過程中的問題

1、 需求提交后， 存在需求過于簡單描述不清等問題， 需求分析壓力較大。2、 需求分析時， 不夠細化或完全按照客戶的意見進行系統(tǒng)分析， 沒有考慮系統(tǒng)內(nèi) 的關聯(lián)性。存在雙方理解差異， 待功能交付后， 用戶提出所見非所求， 造成需 求、 bug 爭論不休， 需求變更及 bug 修復頻繁， 影響系統(tǒng)穩(wěn)定并造成成本消耗。

3、 需求的優(yōu)先級沒有劃定， 需求進度難以排定， 造成開發(fā)壓力較大且用戶不滿意 的局面。

4、 過多的爭論造成了 臨時事務增多， 對于需求開發(fā)的支持滯后， 項目整體進展緩 慢， 客戶滿意度較低。

（二） 問題的解決方案

1 、 建立需求管理制度 會同業(yè)務部門、 系統(tǒng)建設部門及其上級管理者采用會議、 文檔確認等形式就需 求的提交、 需求優(yōu)先級劃分、 需求規(guī)范進行。 涉及到領導命題（需要高層領導的 發(fā)起、 參與和支持）、 投資命題（需要計劃， 配備專職人員以及管理時間和資金投 入） 及團隊命題（需要全體人員的協(xié)作和努力）。

1） 需要向領導層闡述需求管理制度形成、 按新流程推進后， 可以在項目資金整 體投入方面得到控制， 因為需求本身質(zhì)量和開發(fā)質(zhì)量都得以提升， 日常爭論降低， 分析、 開發(fā)效率都得到提高。

2） 該制度的形成需要配備相應的工具， 對于需求的計劃跟蹤、 需求評審、 需求 質(zhì)量控制進行有效監(jiān)控。需要加強人員培訓， 熟悉相應的工具；需要增加若干審批 環(huán)節(jié)， 增加管理資金投入。

3） 新制度形成會造成各環(huán)節(jié)流程變動， 對于過往習慣造成影響， 這就需要整個 團隊的適應。需要各部門群策群力， 才能將制度落到實處。

2、 需求接收及其分析 需求文檔提供及分析文檔形成也涉及到了文檔命題（需要文檔（解釋和溝通） 支 持過程活動可視化， 使得復雜的智力密集的支持過程活動得到有效地控制）。在開 發(fā)前期形成雙方認可的文檔是減少功能交付后爭議的有效辦法。

3、 需求評審 在需求文檔和需求分析文檔形成后， 可會同專家小組， 對于需求提交、 分析的 質(zhì)量進行監(jiān)控， 在評審過程中就雙方理解的差異進行消除， 并對后續(xù)需求提交、 分析的質(zhì)量提出指導意見。評審后， 形成評審文檔備案。

4、 需求計劃定制及跟蹤 在需求經(jīng)過多方確認后， 可根據(jù)現(xiàn)有開發(fā)團隊的人力結合需求的優(yōu)先級確定需 求開發(fā)計劃， 并將計劃登記入需求跟蹤表， 需求過程進行統(tǒng)一跟蹤， 各部門均可 獲取當前需求的進展狀態(tài)。如果對于計劃有調(diào)整需求的， 需要有明確的審批機制， 評估調(diào)整計劃對于項目整體進度的影響， 經(jīng)過相關干系人協(xié)調(diào)一致后， 予以調(diào)整。

5、 需求開發(fā)及更新過程 需求開發(fā)階段， 需要在設計文檔、 測試文檔提供方面進行加強， 提高需求開發(fā) 的整體質(zhì)量。需求提交納入配置管理庫， 由專人進行版本的更新， 在更新時檢查 對應文檔的提供情況。

6、 需求變更 變更需要在新流程中明確登記原因、 追溯變更設計的功能點， 并對變更進行審 核。變更得到嚴格控制， 并定期對各部門變更進行統(tǒng)計， 提高需求提交的計劃性和 需求本身的質(zhì)量。

7、 團隊培訓 成熟度命題（需要不斷地組織學習以持續(xù)地改進全組織的軟件支持過程能力。一方面團隊需要學習新流程推行中需要遵循的規(guī)范， 另一方面團隊也需要接觸新流 程配套使用的工具。同時需要不斷提升自身業(yè)務、 技術水平以適應新流程。效果命題：需要明確地努力和定期地強化其效果。通過不斷增加團隊的適應水 平， 使新流程的效果得以顯現(xiàn)， 不斷的效果顯現(xiàn)本身就是對團隊的激勵， 使得新流 程的認可度不斷提升。

8、 過程改進 過程命題：需要仔細地進行過程設計來減輕甚至消除軟件支持過程認知障礙并提 高群體認知活動的效力和效率。新流程的形成必然存在一定的瑕疵， 因此在流 程推進過程中需要不斷總結， 消除新流程推進過程中的問題。使各部門消除推 進新流程的顧慮， 體現(xiàn)新流程的價值。

（三） 形成的流程 經(jīng)過多方討論， 我們形成了需求管理理流程

（四） 改進小結

在執(zhí)行新的管理制度后， 得到領導層的支持， 并有序推進。各業(yè)務部門在實踐過 程中發(fā)現(xiàn)新的流程帶來了需求開發(fā)質(zhì)量的提高和團隊需求進度承諾的有效， 也普遍接受 了新的管理流程。開發(fā)在推行新流程后， 減少了臨時事務， 客戶滿意度提高， 團隊士氣 得以提升， 也普遍接受了新的流程。

領導層在經(jīng)過數(shù)月后發(fā)現(xiàn)需求提交和開發(fā)質(zhì)量大幅度提升、 需求進度可控， 對項目 團隊和各部門的工作都給予了較高評價！