CMMI

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

一、概述

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

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

下面我們就如下幾個(gè)方面對需求管理體系進(jìn)行分析、 研究：

1， 需求的管理的基本活動(dòng)

2， 結(jié)合當(dāng)前項(xiàng)目簡述需求管理實(shí)踐中的問題、 解決方案 。

二、需求管理的基本活動(dòng)

在需求管理過程中， 包含如下關(guān)鍵活動(dòng)：

1、 需求提出

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

2、 需求分析及評審

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

3、 需求計(jì)劃定制及跟蹤

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

4、 需求變更控制

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

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

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

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

三、 項(xiàng)目實(shí)踐過程示例

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

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

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

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

（二） 問題的解決方案

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

1） 需要向領(lǐng)導(dǎo)層闡述需求管理制度形成、 按新流程推進(jìn)后， 可以在項(xiàng)目資金整 體投入方面得到控制， 因?yàn)樾枨蟊旧碣|(zhì)量和開發(fā)質(zhì)量都得以提升， 日常爭論降低， 分析、 開發(fā)效率都得到提高。

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

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

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

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

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

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

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

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

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

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

（四） 改進(jìn)小結(jié)

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

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