需求開發(fā)與需求管理概述

在我看來微猖， 項目管理的日常活動包括了：需求管理缘屹、故障管理凛剥、版本管理、任務管理轻姿。

???????需求管理貫穿了項目的大部分生命周期犁珠，故障管理則從第一個迭代版本出現(xiàn)直到產(chǎn)品維護階段（包括內(nèi)部故障與外部故障）結(jié)束逻炊。

??????? 所以：需求驅(qū)動開發(fā)，需求是開發(fā)的上游犁享。

?????? 在Karl E.Wiegers寫的“軟件需求”第2版中余素，第一章中就描述了需求開發(fā)與需求管理的關系。

?? 廣義的需求管理就是指需求工程炊昆，需求工程常分為需求開發(fā)（RD：requirement development）和需求管理（RM：requirement management）桨吊。

簡述之：

1，?需求開發(fā)=需求獲取與分析+編寫需求文檔+評審并確認需求文檔凤巨。

??解釋：

????? 在需求文檔得到下游（開發(fā)视乐、測試）確認后，被傳遞給下游進入 代碼開發(fā)與需求測試 活動敢茁。二者不屬于 需求開發(fā) 范圍佑淀。

　?? 由于目前的開發(fā)大多常用迭代版本(即：增量開發(fā))，一個項目中包括了多個版本彰檬，在項目起始時制定第一個版本的需求基線伸刃，在后續(xù)每個版本開發(fā)前都會補充新的需求（也會刪除、修改需求）逢倍。所以需求開發(fā)計劃也包括了多個周期捧颅。

2，需求管理＝版本規(guī)劃+需求變更控制+需求狀態(tài)跟蹤+需求追蹤瓶堕。（更全面的內(nèi)容見下面）

??解釋：

???? 版本規(guī)劃 常稱為制定需求基線隘道，它應該制定本項目周期內(nèi)症歇，每個版本所包括的需求列表（有時版本內(nèi)功能也包括了某些故障的解決郎笆，或把故障以需求的形式進行跟蹤）。

???? 需求變更控制 針對上面提到的 需求開發(fā)的多個周期 進行控制忘晤，需求開發(fā)活動每個周期開始時都依靠 需求變更控制 活動來確認需求范圍宛蚓。

???? 需求狀態(tài)跟蹤與需求追蹤 在我看來是 顆粒度粗與細 的關系，體現(xiàn)了 進度控制 的作用设塔。

???? 需求管理計劃 與 需求開發(fā)計劃 是不同的項目管理計劃凄吏、受不同的　項目進度計劃　控制，但不同的活動又緊密聯(lián)系在一起闰蛔，交叉痕钢。

??? 在傳統(tǒng)的、理想的開發(fā)模型中序六，需求開發(fā)活動（這個階段中也受 需求管理 活動控制）完成后任连，需求不再變更，則之后只剩下需求管理活動直至本項目最終版本發(fā)布例诀。但實際上随抠，在版本發(fā)布之前裁着、甚至版本維護階段，仍有新的需求產(chǎn)生拱她，則 需求開發(fā)活動 仍然不斷持續(xù)中二驰，這就是：需求開發(fā)多周期的意義。

需求開發(fā)

包括以下各活動

1. 需求獲取與需求分析：

????? 在定義了項目目標后秉沼，需求收集人員運用各種方法\工具桶雀，從不同的渠道，獲取真實的需求唬复。

???? ?需求收集工具：市場調(diào)查背犯、原型、需求專題討論會盅抚、頭腦風暴漠魏、同類/類似產(chǎn)品解剖、歷史經(jīng)驗（如以前版本中遺留下來的未實現(xiàn)功能） 等妄均。

????? 渠道包括： 如市場柱锹、客戶/用戶、競爭對手丰包、研發(fā)等

真實的需求：原始需求可能只有一句話禁熏，但整理成的用戶需求可能包括（但不限于）：市場必要性、功能（技術可行性分析邑彪、需求場景及主要過程瞧毙、可驗證性）、需求優(yōu)先級及影響面分析寄症、性能宙彪、質(zhì)量、外部接口有巧、應符合的業(yè)界標準释漆、實現(xiàn)的限制（指某些不能滿足的場景 需要明確列出）、國際化 等篮迎，并整理成?用戶需求文檔或需求屬性列表男图。

????? 需求分析工具：建模、圖形化分析甜橱、創(chuàng)建原型逊笆、編寫數(shù)據(jù)字典、Use Case岂傲、序列圖难裆、流程圖。譬胎。差牛。

分析的結(jié)果(用戶需求文檔)命锄，應該得到 客戶或需求提交人 的確認。

????有些教材將需求獲取與需求分析分成兩個活動偏化，但在我看來脐恩，這兩個活動是融合在一起的，獲取的過程中需要明確一些細節(jié)侦讨，當然需求細節(jié)的顆粒度仍然較粗谁撼，這里也是考察需求收集人員業(yè)務能力的時候芦倒，有能力的需求收集人員應該盡可能獲取或分析出 真實的需求，顆粒度適合研發(fā)需要為好。

?? 或者可以這樣認為：需求最初獲取的是 原始需求锦溪，需求分析時進行 細化樊零、轉(zhuǎn)換酣难、顯式化上層需求拖叙，得到用戶需求（但分析過程中也會向客戶確認細節(jié)）。

注1：客戶常見的困難在于：“我知道你已理解我所說的蜡歹，但我不知道我所說的是否就是我真正想要的”屋厘，“只要一看到它，我就知道我要的正是它月而，但是我無法準確描述”

注2：如果把活動與項目階段作嚴格對應的話汗洒，整個需求開發(fā)階段 還應該包括：

??? 1)，一些需求管理或需求狀態(tài)跟蹤的內(nèi)容

?????????? 用一個表格維護：需求提交人父款、需求來源（客戶公司名稱溢谤、項目 等）、需求名稱憨攒、需求描述世杀、提出時間、要求對外發(fā)布時間點或承諾時間點浓恶、要求決策時間點（即答復客戶是否能滿足要求的時間點）玫坛、需求分析人、需求狀態(tài)（已拒絕包晰、分析中、已批準炕吸。伐憾。。）赫模、需求優(yōu)先級树肃、對外部項目的影響、用戶需求文檔歸檔路徑 等瀑罗。

??? 2)胸嘴，需求決策：項目組內(nèi)對于 用戶需求 的評審及確認是否接受 的控制過程雏掠。接受后即為 已批準 狀態(tài)。??????????????????????

??? 3)劣像，文檔管理

?????????? 原始需求文檔乡话、用戶需求文檔的歸檔及列表記錄，

?????????? 重點需求或經(jīng)過反復討論過的需求耳奕，應該將需求討論記錄绑青、會議記要 歸檔或附到 用戶需求文檔中。

2.? 編寫產(chǎn)品需求：

????????對用戶需求文檔進行細化屋群，將需求過程對應到具體的產(chǎn)品闸婴，有時也稱為SRS（System Requirement Specifications）或XX需求說明書。

??????? 7 + 4特征：

????????????????? 單條需求：完整性/正確性/可行性/必要性/劃分優(yōu)先級/無二義性/可驗證性芍躏；

????????????????? 需求說明書：完整性/一致性/可修改性/可追蹤性

????????用戶需求文檔應視為與外部客戶之間的“契約”邪乍，而產(chǎn)品需求文檔則是軟件公司內(nèi)部的“契約”，后者是產(chǎn)品方案对竣、產(chǎn)品詳細設計（HLD溺欧，High Level Design)、系統(tǒng)測試?的基礎與依據(jù)柏肪。

它是 需求評審姐刁、需求管理 的對象（我認為：用戶需求也在需求管理的范圍之內(nèi)）

3，評審并確認產(chǎn)品需求文檔

?????? 評審產(chǎn)品需求文檔烦味，它確定了項目交付時用于評判是否符合客戶要求的驗收準則（內(nèi)部交付依據(jù)產(chǎn)品需求聂使，對客戶交付依據(jù)用戶需求）

?????? 有時也稱為 需求驗證、需求審核谬俄，它不是指驗證代碼柏靶，而是指審核需求文檔。

?????? 發(fā)現(xiàn)缺陷越多的評審溃论，是越成功的評審屎蜓。

?????? 評審員越全面越好：客戶、用戶需求作者钥勋、產(chǎn)品需求作者炬转、開發(fā)代表、測試代表算灸、用服代表扼劈、市場代表、售后代表菲驴、質(zhì)量代表荐吵。。。

?????? 激勵評審員的積極性先煎，也是項目管理的一個難點之一贼涩。

4，測試用例薯蝎、操作手冊的開發(fā)

???? 在產(chǎn)品需求完成同時遥倦，應完成以下兩個活動

????????? ???? 以需求為依據(jù)編寫測試用例、編寫用戶操作手冊（側(cè)重于功能方面）

? 這兩個活動依據(jù)產(chǎn)品需求進行良风，且可以在 產(chǎn)品方案 設計前完成谊迄。

??? 注：為什么不在代碼入庫，或開發(fā)代碼時再編寫測試用例：由于系統(tǒng)測試用例是基于需求做的烟央，測試經(jīng)常發(fā)現(xiàn)不了需求缺陷统诺。所以要求在審核需求階段就考慮測試標準，并在需求審核完成后疑俭，緊隨其后就 編寫測試用例粮呢。

????????? 編寫用戶手冊也是同樣的道理。

需求管理

?????? 需求管理作為整個項目計劃的一部分钞艇，在項目立項后啄寡，項目經(jīng)理應首先明確：需求管理的活動、方法和資源哩照。

需求管理目的：使顧客和項目隊伍對系統(tǒng)建立一致并保持一致挺物，保持一致意味著計劃、活動飘弧、工作產(chǎn)品都要和需求保持一致识藤，不能偏離。

所以：需求管理不僅是項目目標的體現(xiàn)次伶，也是 項目進度控制 的主要手段之一痴昧。(其它的手段如：開發(fā)計劃、測試計劃冠王、項目里程碑赶撰。。柱彻。)

任何活動都可分為三個階段：

1豪娜，計劃

2，執(zhí)行與進度控制绒疗。

3侵歇，驗收與收尾

需求管理的每個子活動與上述三個階段可以對應起來理解。

??????? 比如需求跟蹤是屬于進度控制的范圍吓蘑，但也包括了已驗收狀態(tài)的記錄。

收尾時所有需求均進入了已發(fā)布狀態(tài)，項目一般會進行 文檔的配置管理的補充與審核工作磨镶，比如 功能清單溃蔫、版本發(fā)布說明、產(chǎn)品規(guī)范琳猫。伟叛。。 應該提交脐嫂。

????? 基于需求驅(qū)動開發(fā)的理念统刮，以需求管理、需求變更控制為主線账千，將需求侥蒙、設計、開發(fā)匀奏、測試和項目管理完全工具化管理鞭衩。

1，制訂需求管理計劃

立項后完成娃善。

?? ?????包含：

?????????????? 有關人員的角色職責：

????????????????????產(chǎn)品\項目CCB(Configuration Control Board??? 配置控制委員會)(產(chǎn)品與項目并不等價论衍，產(chǎn)品內(nèi)可能包括多個項目，反之也可能)聚磺，CCB成員包括：主席坯台、秘書、項目經(jīng)理瘫寝、開發(fā)經(jīng)理蜒蕾、xx開發(fā)組負責人、測試代表矢沿、QA代表滥搭。。捣鲸。

??????????????????????各人在各子活動中的作用：牽頭瑟匆、組織、負責栽惶、參與愁溜、旁聽、被通知外厂、拍板或決策權(quán)冕象。

?????????????? 工具與方法：

????????????????????原始需求收集的工具、需求跟蹤工具汁蝶、需求追蹤工具渐扮、需求變更工具（各工具可使用如Excel表格论悴、郵件、Word文檔墓律、軟件工程軟件膀估、自己開發(fā)的OA系統(tǒng)。耻讽。察纯。）、度量指標（如需求總數(shù)针肥、已完成需求個數(shù)饼记、測試中需求個數(shù)、已發(fā)布需求個數(shù)慰枕。具则。。）捺僻、項目需求例會機制乡洼、版本規(guī)劃工具（如excel、microsoft的Project...)匕坯、版本規(guī)劃例會束昵、項目CCB會議機制。葛峻。锹雏。

?????????????????? 各工具、指標术奖、會議機制的具體內(nèi)容（如excel中應該包括哪些字段）礁遵、負責人、參與人采记。

???????????????需求追蹤：需要追蹤的工作產(chǎn)品類別及其追蹤粒度：

????????????????????需求追蹤的工作產(chǎn)品包括：市場需求文檔佣耐、產(chǎn)品需求文檔、系統(tǒng)測試用例唧龄、組件級需求兼砖、組件級方案、設計文檔既棺、代碼模塊\函數(shù)讽挟，前三者應該是最基本的跟蹤粒度。有些非常敏捷的項目可能把 產(chǎn)品需求文檔 也省掉了丸冕。

????????????????需求狀態(tài)跟蹤：跟蹤的需求狀態(tài)及其跟蹤方法：

????????????????????用戶需求耽梅、產(chǎn)品需求、產(chǎn)品組件需求 的各種狀態(tài)（可能是不同的）胖烛，如已提出眼姐、已批準或采納诅迷、已刪除、已拒絕妥凳、開發(fā)中竟贯、分析中答捕、測試中逝钥、已實現(xiàn)、已驗證拱镐、已發(fā)布艘款、變更中、已變更沃琅、已延期哗咆。。益眉。晌柬，項目需要為狀態(tài)進行定義。

????????????????????部分項目可能跟蹤的需求粒度更大或更小郭脂。由于有若干層次的需求年碘，因此，需要明確需要跟蹤的是哪個層次的需求(原始需求展鸡、用戶需求屿衅、產(chǎn)品需求。莹弊。涤久。）

?????????????? 接受用戶需求、產(chǎn)品需求的準則忍弛，如項目可以定制自己的需求評審檢查單响迂。

定義審核頻度：將項目組從技術角度對追蹤關系的審核要求明確化

注：需求管理活動可以酌情剪裁掉許多內(nèi)容，視項目情況而定细疚。

???????????? 在數(shù)十蔗彤、上百研發(fā)人員參與的大項目，需求繁多惠昔、變更頻繁幕与、質(zhì)量要求高時，需要更多的管理成本投入到各種需求管理活動中镇防。

???????????? 也有些公司啦鸣，雖然項目大且需求復雜，但參與項目的各方已經(jīng)建立了一套約定俗成的規(guī)則来氧，員工的職業(yè)成熟度較高诫给，對于自己崗位的職責比較明確香拉，較少發(fā)生扯皮事件，上下游之間配合較好中狂，可以剪裁掉一部分需求管理活動凫碌，比如?需求評審、變更評審胃榕、需求追蹤\跟蹤 的簡化盛险、不再維護產(chǎn)品需求文檔 等。

?注：需求管理工具 中還應該包括??溝通機制勋又、文檔訪問控制苦掘，和設計方案、測試計劃楔壤、配置工具的結(jié)合鹤啡，跨項目追蹤能力

有些商業(yè)工具可以完成 需求管理 的全套或有關工作：提交用戶需求、指派SE分析蹲嚣、提交分析結(jié)果递瑰、文檔歸檔與基線化、決策記錄與執(zhí)行決策（拒絕或采納隙畜、掛起抖部、轉(zhuǎn)交、拆分）禾蚕、需求規(guī)劃入版本您朽、需求基線化、需求變更换淆、需求狀態(tài)跟蹤（需求狀態(tài)的變更）哗总、需求單派生出文檔單\代碼單（與設計方案、代碼開發(fā)計劃的有效銜接）倍试、導出需求追蹤矩陣讯屈、提交版本、批準版本县习、生成roadmap涮母、版本發(fā)布、計算需求度量指標躁愿、需求決策與變更通知有關人等叛本、人員角色分組自定義。加上強大的統(tǒng)計彤钟、分析来候、圖形功能。逸雹。营搅。

????? 基于文檔（比如Word云挟、Excel)存儲需求的方法有若干限制。例如：?

????????????????很難保持文檔與現(xiàn)實的一致(即文檔的變更沒有進行正確跟蹤转质，手工跟蹤只能通過詳細的修訂記錄表格來記錄 變更詳細情況與變更歷史园欣，很容易懈怠)、

????????????????通知受變更影響的設計人員是手工過程（一般是通過郵件通知 聯(lián)系人分組休蟹，對方可能會忽視郵件）沸枯、

??????????????? 不太容易做到為每一個需求保存增補的信息(每次變更的修訂必須手工記錄、維護鸡挠，很難保證全面辉饱，商業(yè)跟蹤工具可以與SVN版本建立關聯(lián))、

????????????????很難在功能需求與相應的使用實例拣展、設計、代碼缔逛、測試和項目任務之間建立聯(lián)系鏈（與第一條 文檔與現(xiàn)實 的理由一樣）

??????????????? 很難跟蹤每個需求的狀態(tài)( Excel做這個較好备埃，但Word的表格功能則較差，行列長度個數(shù)受頁面大小控制而不能讓字段太多褐奴，沒有篩選功能 )

?????? 部分項目選擇Excel按脚、結(jié)合word進行需求管理的原因可能是：商業(yè)工具的性能較差（全公司數(shù)千個項目都在數(shù)據(jù)庫內(nèi)維護），公司定義的流程不符合項目需要敦冬、公司IT部門對項目需求的反應太慢辅搬。。

2脖旱，評審需求（用戶\產(chǎn)品\組件級需求）或理解需求

????這應該屬于 需求開發(fā) 的功能堪遂，但實際上因為常與版本規(guī)劃、需求承諾?同時進行萌庆，也納入 需求管理活動中溶褪。

????主要是讓 產(chǎn)品\項目CCB 了解需求，確認優(yōu)先級與發(fā)布時間點的過程践险。

??? 可使用的工具：用戶\產(chǎn)品\組件需求 同行評審檢查單

??? 組件級需求中也包括了系統(tǒng)內(nèi)的接口需求猿妈，網(wǎng)元間接口需求\對其它網(wǎng)元的影響 則在 產(chǎn)品需求說明書 中體現(xiàn)。

注：需求開發(fā)的活動負責人是 負責每個需求的系統(tǒng)工程師巍虫。但需求開發(fā)活動也有其它角色參與彭则。評審過程必須得到所有或大部分評審員的同意。

????? 需求管理的活動負責人是：需求經(jīng)理（可以兼版本經(jīng)理占遥，有時版本經(jīng)理會獨立出來俯抖，專門負責版本規(guī)劃、版本制作等活動）筷频，需求管理活動的其它重要角色如項目經(jīng)理蚌成、版本經(jīng)理前痘、其它CCB成員。它們一般應該參與 需求開發(fā)活動中的評審過程担忧。

???????所以：評審需求 這個過程屬于 需求開發(fā)與需求管理 的交叉過程芹缔。

3，評價與承諾需求（requirement commitment）

需求承諾：需求干系人之間對需求和需求變更的文檔化約定瓶盛，它包括:需求范圍最欠、完成日期、質(zhì)量惩猫、優(yōu)先級等的約定芝硬，確保需求干系人對當前的望忆、批準的需求和因該需求引起的項目計劃溃睹、活動和工作產(chǎn)品變更負責。

?????需求評審時就評估需求影響：需求范圍的烁，工作量奶镶，工期迟赃，成本，資源厂镇，質(zhì)量目標纤壁。并形成報告上交CCB。

將潛在風險識別出來并錄入風險管理庫進行跟蹤捺信。

CCB對需求進行承諾：批準或拒絕酌媒、掛起、延期迄靠，對內(nèi)對外的發(fā)布時間點秒咨。。梨水。

????配置管理：文檔版本拭荤、代碼版本、模塊函數(shù)的編號或命名方法疫诽、歸檔目錄舅世、有關人的訪問權(quán)限。奇徒。雏亚。

注1：評價需求過程 的輸入是需求評審時確認的需求影響面分析報告，

承諾需求過程 包括了 需求規(guī)劃入哪個版本 的過程摩钙。與 版本控制 過程交叉罢低。

注2：需求承諾表包括：需求名稱，實現(xiàn)版本，交付日期网持，承載質(zhì)量 等信息宜岛，是對市場的一個承諾。

??????????? 需求承諾表也可以與 需求跟蹤表 合一功舀。比如在每周需求例會中對上周新來的需求進行規(guī)劃萍倡、承諾。

注3：項目經(jīng)常會從各種源頭收到需求：各局點服務人員辟汰、某地銷售處列敲、市場應標人員、上級領導戴而、其它產(chǎn)品或項目、內(nèi)部開發(fā)人員扁眯、內(nèi)部測試人員的郵件命满、會議記要胶台、用戶需求說明書韩脏。

?????? 比如許多需求通過郵件收到，項目經(jīng)理隨意指定一個SE進行分析阅仔、隨意給開發(fā)經(jīng)理指定一個版本號與完成時間點八酒，難以進行后期的監(jiān)控羞迷。

項目的需求收集應該有一個統(tǒng)一入口，需求提交人應該提交需求的具體描述抖甘、要求時間點、有關市場項目米奸、簡單影響面 等信息，然后需求經(jīng)理定期收集后指定需求SE分析。需求經(jīng)理通過需求跟蹤表記錄 已分析狀態(tài) 及要求完成分析工作的時間點，并對分析工作的完成狀態(tài)進行監(jiān)控哈扮。

????? 上述工作也屬于需求管理活動范圍。

4摘仅，需求的基線化和版本控制（版本控制即版本規(guī)劃）

基線化包括

????????????版本的基線化

????????????需求的基線化

????????????文檔的基線化

????????????代碼的基線化

版本的基線化是指 版本規(guī)劃（或版本計劃，含一段時間內(nèi)多個版本的制作測試發(fā)布時間點與內(nèi)含功能點） 的基線化娃属，基線化的含義是當上下游對版本計劃達成一致時，決策或評審會議舉行 那天的時間點為基線化時間點膳犹，它是項目管理的重要里程碑。之后對版本計劃的變更納入 變更控制 范圍须床。

????? ?每個版本指定一個時間點铐料，之前所有規(guī)劃入這個版本的需求應該已經(jīng)編寫評審完成。這是項目進度控制的一個重要時間點钠惩。

????? 將需求規(guī)劃入各個版本篓跛，各版本指定做版本時間點、發(fā)布時間點沐寺、測試周期 等狐援。

基線化操作表示對這個版本的需求內(nèi)容進行凍結(jié)，在基線化時間點之后的需求變化走用戶需求變更流程究孕，可能修改版本計劃（版本發(fā)布時間點不變）或補充版本計劃（推遲版本發(fā)布時間點）

公司可能把需求變更啥酱、文檔變更、代碼變更控制 下放到項目線管理厨诸，而只對版本變更進行控制镶殷。

?????需求的基線化：在需求（用戶需求、產(chǎn)品需求）經(jīng)過評審后微酬，需求的修改納入 變更控制 范圍批钠。

需求評審會議舉行 那天的時間點為基線化時間點。

???需求的變更 可能引起文檔變更得封、版本規(guī)劃變更、代碼變更指郁。

???? 文檔的基線化：在某文檔（需求文檔忙上、設計方案、測試方案闲坎、功能指導書疫粥。。腰懂。）通過評審后梗逮，文檔的修改納入 變更控制 范圍。

文檔評審會議舉行 那天的時間點為基線化時間點绣溜。

????文檔的變更 可能由需求變更慷彤、故障、代碼變更 引起。文檔變更常與 需求變更底哗、版本變更岁诉、代碼變更 同時受影響。

????代碼的基線化：這里各項目的控制力度可能不同跋选，因為基線化之后的變更控制由項目線涕癣、開發(fā)經(jīng)理進行，而開發(fā)任務下達到 代碼基線化 之間的代碼修改 可屬于開發(fā)人員自己的行為前标。所以：

????????有些管理較細化項目要求在代碼入庫（版本發(fā)布庫坠韩、或測試庫，視開發(fā)經(jīng)理管理粒度而定）之后不能輕易修改炼列。必須提交代碼變更申請只搁，并經(jīng)CCB（可能是開發(fā)CCB、或項目CCB）批準通過唯鸭。代碼入了測試庫之后须蜗，經(jīng)測試人員測試通過后才允許入發(fā)布庫（經(jīng)過CCB批準后才可入）。

????????有些管理較粗的項目要求將 版本對外發(fā)布 的時間點作為本版本有關代碼的基線化時間點目溉，之后對代碼的優(yōu)化修改明肮、發(fā)現(xiàn)故障觸發(fā)修改，都走變更控制流程缭付。即代碼的基線化等價于 版本發(fā)布柿估。版本在發(fā)布之后，代碼進入嚴格受控狀態(tài)陷猫。

???????完全沒有控制的項目秫舌，在版本對外發(fā)布后，仍允許開發(fā)人員隨時修改代碼绣檬。外場故障一發(fā)生足陨，開發(fā)人員隨意修改代碼解決后制作版本發(fā)布給現(xiàn)場。

注：代碼可能分為幾個庫：開發(fā)庫（供開發(fā)人員自己平時測試之用）娇未、測試庫（代碼入測試庫之后墨缘，測試人員發(fā)生故障后可以要求開發(fā)人員修改）、發(fā)布庫（最終代碼零抬，版本制作基于發(fā)布庫）镊讼。最差的情況是三個庫合一。中間的控制粒度是 開發(fā)庫與測試庫合一平夜。

???? 視項目內(nèi)各成員權(quán)限讓有關人等了解到各元素的最新修訂蝶棋。

????? 沒建基線前、或者兩個基線時間點之間忽妒，改動控制就可以比較寬松玩裙。

基線的另一個意義：如果某個路徑走不下去兼贸，可以恢復到某個起點。

版本計劃献酗、需求寝受、文檔、代碼的基線化罕偎，意味著：“版本”的意義擴展了

????????????上述各管理元素應跟蹤 其歷史修訂 情況很澄，

??????????? 常規(guī)所指的版本計劃，是指代碼的版本颜及，每個版本內(nèi)含若干需求甩苛、文檔、代碼文檔的某個版本俏站。??

????????????但需求讯蒲、文檔也可以有自己的版本計劃。三種版本計劃之間存在對齊關系肄扎。比如每個文檔都有自己的版本墨林，從V0.1開始，每次小修訂都讓小版本號增加一位犯祠，大修訂則增加大版旭等。可能還涉及各文檔的版本號對齊控制衡载。?從文檔對象出發(fā)搔耕，能跟蹤到每個文檔版本所屬的代碼版本、需求版本痰娱。

???????????版本控制的最簡單方法是根據(jù)標準約定手工標記軟件需求說明書的每一次修改弃榨。?更高級別的使用版本控制工具

?????????? 每個版本->需求->文檔->代碼塊 的追蹤、關系關系梨睁，能支持正向鲸睛、反向追溯、同級關聯(lián)關系確定坡贺。

5腊凶，需求變更（requirement change）管理??

????????需求變更，是指增加拴念、修改和刪除已經(jīng)基線化的版本需求。

重點是變更影響分析（Change Impact Analysis褐缠，CIA）：通過廣泛的確認政鼠，對變更進行分析，以確定：變更的必要性队魏、可行性（技術公般、成本等）万搔；可能的工作量及對進度的影響；可能的受影響的工作產(chǎn)品（利用需求追蹤矩陣RTM）或其它事項

CIA的目的：為“CCB決策是否要做”提供經(jīng)過廣泛確認的官帘、基于經(jīng)驗的依據(jù)

需求變更過程控制 的目標：控制項目范圍的擴展

擴展需求指在軟件需求基線已經(jīng)確定后又要增添新的功能或進行較大改動

管理范圍擴展的第一步就是把新系統(tǒng)的 視圖瞬雹、范圍、限制?文檔化并作為業(yè)務需求的一部分

控制范圍擴展的方法是要敢于說“不”

??????需求變更管理的流程是：

需求提交-分析-重承諾需求-實施變更（指對基線的變更）

1）刽虹，當版本規(guī)劃中的用戶需求已經(jīng)凍結(jié)酗捌，用戶需求變化后 需要提交申請。

產(chǎn)品\產(chǎn)品組件需求 已經(jīng)基線化涌哲，存在 產(chǎn)品\產(chǎn)品組件需求 變更的申請

2）胖缤，分析內(nèi)容包括但不限于：規(guī)模，工作量阀圾，進度哪廓，風險，質(zhì)量初烘，成本涡真，需要變更的產(chǎn)品需求，危害分析等等肾筐，

提交《變更影響分析報告》

3）哆料，重新確認新的承諾:

3.1，如果雙方?jīng)]有改變承諾（即不接受變更請求）局齿，那么應當將由此產(chǎn)生的風險納入項目的風險管理庫中進行管理剧劝。

3.2，需求被決策后的狀態(tài)有以下幾種狀態(tài)：拒絕抓歼、接受讥此、提交上級CCB、掛起谣妻、延期等萄喳。

如果接受需求變更請求，可能要修改需求\設計\測試文檔\用戶隨機資料與代碼蹋半，要通知受影響的所有人員他巨。

4），實施變更减江，

修改工作產(chǎn)品（系統(tǒng)方案染突、設計文檔、代碼辈灼、測試用例份企。。巡莹。）的活動司志，且產(chǎn)品都要評審和驗證甜紫，納入 需求追蹤和狀態(tài)跟蹤 管理。

?? 現(xiàn)有版本可能重新制定骂远，會影響開發(fā)計劃囚霸，開發(fā)任務的進度需要重新制定。

需求變更控制策略 包括：

制訂的過程必須用于所有需求變更請求激才。（某些項目會為緊急需求制定綠色通道拓型，即省略一些控制過程直接跳到開發(fā)。但應嚴格受控并記錄贸营，活動主體為項目經(jīng)理）

?????? 需求變更請求吨述，必須由CCB決定是否采納或拒絕。

?????? 必須提交變更影響分析（并納入 變更數(shù)據(jù)庫 歸檔）钞脂，供CCB決策揣云。????

??????? 當需求變更請求被拒絕后，只記錄其拒絕狀態(tài)冰啃，其它狀態(tài)不再進行跟蹤邓夕。

未獲批準的變更，除可行性論證之外阎毅，不應再做其它設計和實現(xiàn)工作焚刚。

決不能刪除或修改變更請求的原始文檔，即需求的變更部分必須重新提交 產(chǎn)品需求文檔扇调，對現(xiàn)有文檔的影響也應記錄矿咕。（因項目而異，某些項目允許修改原來已經(jīng)基線化的文檔狼钮，但對原始文檔的修訂必須進行記錄)

需求變更 需要跟蹤碳柱，特點是關聯(lián)到 原需求的追蹤矩陣與跟蹤狀態(tài)。

需求變更 必須有專門的跟蹤工具熬芜。

典型的失控變更

顧客直接對程序員提需求

出于對領導意見的尊重莲镣，錯誤被交付給用戶，

競爭對手的功能直接被加入本產(chǎn)品涎拉。

程序員添加的“對顧客有寶貴好處”的產(chǎn)品行為

程序員為調(diào)試瑞侮、提高技藝或者解悶而加入的功能

管理需求變更

識別不可避免的變更，為之制定計劃

建立需求基線

建立唯一的變更控制流程

利用變更控制系統(tǒng)捕捉變更

管理變更的結(jié)構(gòu)

注：需求變更的流程 與2鼓拧、3半火、4、6季俩、7慈缔、8步需求管理活動一致。也應包括 需求開發(fā) 的全部過程种玛。

??????在迭代版本管理方式下藐鹤，經(jīng)常放棄需求變更過程，新需求赂韵、舊需求的修改\刪除 統(tǒng)一作為新需求提交->分析->評審->承諾->基線化->開發(fā)->測試->?發(fā)布娱节。

???????版本迭代的周期應該與項目一般的需求變更規(guī)律一致。

?????? 對于需求變化非常頻繁的行業(yè)祭示、公司（比如項目進行中肄满，每周都會有新需求過來并要求緊急開發(fā)），版本迭代的周期很短质涛，可能一個月就需要出一個對外發(fā)布的版本稠歉。?每周的CCB上都會對新需求進行承諾并規(guī)劃到下個月、或下下月版本中汇陆。

???????? 那些需求變更較少（銷售人員總是傾向于過分承諾怒炸、很多需求都要求緊急開發(fā)，如研發(fā)能頂住市場壓力毡代，推遲承諾時間點或決策時間點相當于需求變更較少）阅羹，版本迭代的周期可以放長。

注： 需求變更 中很重要的地方是：要把變更通知到所有涉及人員教寂，項目人員以及時準確的獲取到需求與變更資料捏鱼。

??????? 尤其是對于舊需求有變化時，更要如此酪耕。

???????? 這可能由 需求變更控制工具 自動實現(xiàn)（比如關聯(lián)到原需求后导梆，可以自動發(fā)送變更給 原需求的有關人員）

注：需求變更可能會對當前版本進度、計劃構(gòu)成影響迂烁。

6看尼，需求追蹤（requirements trace）

需求追蹤在需求、設計婚被、實現(xiàn)狡忙、測試間建立追蹤關系，以保證需求被正確址芯、完整地傳遞到下游（即不存在“需求遺漏”）灾茁，且不存在“實現(xiàn)鍍金”（具體問題具體分析）

需求追蹤是衡量下游工作產(chǎn)品完成程度的重要工具；是實現(xiàn)工作產(chǎn)品彼此間保持一致的重要手段谷炸；是變更影響分析中確定波及范圍的重要依據(jù)北专；需要由項目系統(tǒng)工程組保證追蹤關系的完整性、正確性

管理單個需求和其它項目可交付工作產(chǎn)品之間的依賴關系

需求追蹤矩陣（requirements traceability matrix）分縱向與橫向

從需求到測試的縱向追蹤關系(指兩個工作產(chǎn)品間的關系旬陡、工作產(chǎn)品的歸檔目錄拓颓、工作產(chǎn)品的當前狀態(tài)）?? 包括：

1.用戶需求與產(chǎn)品需求

2.用戶需求與外部接口

3.產(chǎn)品需求與內(nèi)部接口

4.產(chǎn)品需求與產(chǎn)品組件需求

5.產(chǎn)品需求與系統(tǒng)設計

6.系統(tǒng)設計與子系統(tǒng)設計

7.子系統(tǒng)設計與詳細設計

8.詳細設計與代碼

9.代碼與單元測試

10.產(chǎn)品需求與系統(tǒng)測試

11.內(nèi)部接口與集成測試

????? 需求追蹤從用戶需求開始進行追蹤，包括對用戶需求相互之間關系的標識和建立用戶需求同下游工作產(chǎn)品元素（如產(chǎn)品需求描孟、系統(tǒng)設計驶睦、產(chǎn)品組件件需求說明書砰左、子系統(tǒng)設計、詳細設計场航、接口說明書缠导、源代碼塊、測試用例溉痢、用戶手冊等）之間的相關聯(lián)系僻造。

比如項目可以 建立市場需求—產(chǎn)品/平臺需求—系統(tǒng)測試用例之間的可視追蹤關系，其它工作產(chǎn)品則不納入需求追蹤孩饼。

對所有追蹤對象建立橫向追蹤關系：例如同級設計文檔的某兩個相關功能之間的追蹤??? 同級追蹤對象之間是否建立了橫向的追蹤關系

檢查有關聯(lián)關系的系統(tǒng)方案之間是否有追蹤髓削、接口說明之間是否有追蹤、詳細設計之間是否有追蹤镀娶、代碼等之間是否有追蹤

需求追蹤結(jié)果對項目成員發(fā)布的方案立膛，發(fā)布給哪些人，定期發(fā)布還是不定期發(fā)布汽畴。

項目的需求追蹤粒度：條目旧巾、工作產(chǎn)品等等，應該能滿足現(xiàn)有的項目現(xiàn)狀忍些。比如：需求變更發(fā)生時是否能通過需求追蹤表定位到關聯(lián)的工作產(chǎn)品和責任人鲁猩，是否需要進行橫向追蹤。罢坝。廓握。

????? 需求追蹤的頻次，應根據(jù)項目周期長度嘁酿、歷史需求穩(wěn)定度來確定隙券，即這個活動的觸發(fā)時機，比如某工作產(chǎn)品評審完成后應在追蹤表中建立與上游工作產(chǎn)品間的追蹤關系闹司。????? 比如每周檢查并更新一次各追蹤對象的當前狀態(tài)娱仔、隨時補充新的追蹤對象（比如進行緊急需求開發(fā)時，應及時根據(jù)工作產(chǎn)品的輸出情況進行需求追蹤活動)游桩。

????? 需求追蹤 應該評審并糾正不一致性牲迫。比如每個版本基線建立時，CCB應審核追蹤矩陣的建立借卧，確認所有需求分析盹憎、評審、承諾活動已經(jīng)完成铐刘。??? 比如每周項目例會上向項目CCB進行匯總陪每，可供CCB了解當前項目進度與資源分配情況。??? QA在每個里程碑評審之前進行檢查。

??????研發(fā)人員利用需求追蹤維護需求和工作產(chǎn)品的一致性檩禾，當發(fā)現(xiàn)不一致時應進行相應的記錄挂签，并采取相應的糾正措施。

注：需求追蹤信息是項目管理的重要依據(jù)盼产，是 需求變更 的重要參考竹握。

（很多項目中執(zhí)行了需求狀態(tài)跟蹤，但沒有嚴格執(zhí)行 需求追蹤辆飘，是因為這些項目管理的顆粒度針對只針對一條用戶需求，他們對需求的幾個關鍵點作了管理谓传，確保了：需求進行了代碼開發(fā)蜈项、測試驗證通過、發(fā)布給某用戶的版本中包括了用戶要求的需求項续挟。中間過程不在項目級別進行管理紧卒。

?? 這些項目在CMMI中不會視為 高可靠過程。）

注：需求追蹤 要求需求得到有效管理诗祸，

????????如各來源發(fā)來的需求均有統(tǒng)一的渠道跑芳、統(tǒng)一的接口人、統(tǒng)一歸檔直颅、是否接受電話博个、郵件提交需求，

????????哪些故障可以走需求流程功偿，

????????沒有經(jīng)過CCB承諾的需求不應下發(fā)給開發(fā)部盆佣，開發(fā)部只接受CCB下達的任務刘急，

問題舉例：

忘記實現(xiàn)子需求

變更時不清楚要變動的地方

搞不清改動的影響面有多大

取消需求抑堡，設計仍然在進行

追蹤注意事項

顯式追蹤和隱式追蹤

父子關系

間接追蹤關系

沖突關系

盡量使用專用工具

信息訪問權(quán)限

注意審核

及時維護

尺度把握

追蹤范圍

從產(chǎn)品重要、關鍵的部分追蹤起

從需求信息追蹤起

追蹤頻度

每個里程碑游盲？

每個基線吨瞎？

每周/日痹兜？

追蹤人員

項目經(jīng)理？

項目經(jīng)理+各組長颤诀？

每個人字旭？

思想顧忌

“需求追蹤思想雖好，不適合我們”

我們的直覺經(jīng)常不可靠着绊，嘗試一下

習慣了就好了

“系統(tǒng)這么大谐算，不現(xiàn)實”

正因為系統(tǒng)這么大，才需要追蹤

“變更這么多归露，維護追蹤信息是巨大的負擔”

變更越多洲脂，追蹤信息越有價值

“時間緊迫，人手不夠”

向返工要時間

向救火要人手

在下列情況下維護負擔過重：

追蹤面廣

關聯(lián)復雜

變更頻繁

常見困境

拒絕更新追蹤關系的改變

難以承受，放棄追蹤矩陣

7恐锦，需求狀態(tài)跟蹤（requirements status track）

需求狀態(tài)跟蹤：??維護用戶需求在產(chǎn)品研發(fā)過程中的狀態(tài)變遷往果，定義項目生命周期中反映需求完成程度的狀態(tài)；確定“需求”與“狀態(tài)對應的工作產(chǎn)品”間的對應關系一铅；收集證據(jù)陕贮；根據(jù)狀態(tài)定義及證據(jù)，定期或事件驅(qū)動地刷新每條需求的狀態(tài)

需求狀態(tài)跟蹤結(jié)果是判斷項目進展的很客觀的依據(jù)潘飘；需求追蹤關系是狀態(tài)跟蹤的基礎肮之。

對產(chǎn)品的需求狀態(tài)進行統(tǒng)計分析可以查明對應項目的進度狀況，需求跟蹤就是對需求狀態(tài)的收集分析卜录。需求的狀態(tài)定義如下：

需求已提交戈擒，需求已刪除，需求已拒絕艰毒，需求已批準筐高，已重復，已掛起丑瞧，已下達開發(fā)任務柑土，代碼已實現(xiàn)，測試已驗證绊汹，版本已發(fā)布稽屏。。灸促。

對于每一條用戶需求诫欠，相關人員對它進行狀態(tài)跟蹤，直至關閉浴栽；

需要跟蹤的對象包括：市場需求荒叼，產(chǎn)品需求，軟件需求典鸡，硬件需求被廓。當不區(qū)分軟硬件、每條市場需求對應一條產(chǎn)品需求萝玷，則每個用戶需求只有一個條目嫁乘。

活動：

?? 1），通過 需求追蹤矩陣球碉，識別與用戶需求關聯(lián)的所有工作產(chǎn)品元素 是否實現(xiàn)蜓斧。這是檢查 用戶需求是否實現(xiàn)的方法。

2）睁冬，定期統(tǒng)計并報告需求狀態(tài)分布

3）挎春，審核需求狀態(tài)表，識別需求與產(chǎn)品或項目工作的不一致，采取糾正措施直奋。

要有一個合適的需求狀態(tài)發(fā)布方式能庆，維護與評審時機。

注：需求狀態(tài)跟蹤一般可視為項目進度控制的手段脚线，它比需求追蹤的顆粒度要大搁胆，因為它關心的重點是： 需求 是否得到代碼開發(fā)、測試并發(fā)布邮绿。

????? 需求追蹤主要是為了維護上下游產(chǎn)品的一致性渠旁，并作為需求狀態(tài)跟蹤的輸入。

??? ??部分管理粒度粗的項目(比如敏捷項目)只要求需求狀態(tài)跟蹤船逮，而不要求需求追蹤一死，因為對需求（story)到代碼之間的工作產(chǎn)品不進行管理。如果要在 需求跟蹤與需求追蹤 之間作個折衷的話傻唾，可以在需求狀態(tài)跟蹤表 中記錄到 需求子功能點分解 級別。

注：?父子關聯(lián)：?部分需求會與其它項目協(xié)同開發(fā)承耿，如果不通過需求追蹤來做冠骄，則應在 需求跟蹤 表中對需求的下達其它產(chǎn)品、對方代碼完成加袋、對方測試完成情況進行跟蹤凛辣。

????? 沖突關聯(lián)：某些需求之間有交叉重復關系。比如需求A與需求B中均有重合的功能點职烧，也有不重合的功能點扁誓。此時應指定同一個需求SE分析、下達同一個開發(fā)任務蚀之，新的需求任務應包括需求A與需求B的所有功能蝗敢。需求跟蹤表 此時只跟蹤一條需求，另一條置為 已重復 狀態(tài)足删。

????? 需要哪些需求狀態(tài)：根據(jù)項目特點（哪些研發(fā)階段特別長寿谴，哪些研發(fā)階段特別關鍵）可以定制，比如敏捷項目中可能只記錄采納的需求失受，即不跟蹤：需求已刪除讶泰，需求已拒絕，需求已批準拂到，已掛起痪署。。兄旬。 等狀態(tài)狼犯。當開發(fā)與測試人員合一時，代碼已實現(xiàn)，測試已驗證 兩個狀態(tài)也會合一辜王。

注：?充分利用工具的自動工作特性劈狐，將 需求跟蹤、版本規(guī)劃呐馆、度量肥缔、需求變更、開發(fā)測試任務的下達\完成汹来、文檔修訂或變更 等過程集成续膳。

8，度量方式

1收班，需求狀態(tài)統(tǒng)計坟岔，是觀察項目進度的重要手段

?? 已實現(xiàn)需求個數(shù)

?? 已驗證需求個數(shù)

?? 開發(fā)中需求個數(shù)

?? 未分析需求個數(shù)

2，需求變更的度量方法摔桦，是觀察項目立項后需求變更的手段

????需求穩(wěn)定度：變更的需求個數(shù)/基線化時的需求個數(shù)

變更控制狀態(tài)報告：?用報告社付、圖表來總結(jié)變更控制數(shù)據(jù)庫的內(nèi)容和按狀態(tài)分類的變更請求數(shù)量

比如：項目周期內(nèi)，變更的產(chǎn)品需求數(shù)目

接收邻耕、未作決定鸥咖、結(jié)束處理的變更請求的數(shù)量

已實現(xiàn)需求變更（包括增、刪兄世、改）的合計數(shù)量

每個需求源發(fā)出的變更請求的數(shù)量

每一個已應用的需求建議變更和實現(xiàn)變更的數(shù)量

投入處理變更的人力啼辣、物力

一個具體的需求跟蹤流程圖

??????? 圖中每個矩形框表示一個需求活動，在許多活動完成后御滩，都會觸發(fā)需求經(jīng)理填寫用戶需求跟蹤表鸥拧、產(chǎn)品需求跟蹤表的信息，這就要求各個活動都要有輸出信息削解，所以項目上要建立有效的信息通報機制富弦。

??????? 在已掛起狀態(tài)之后，用戶需求可能后續(xù)被重新批準(圖中略去這部分過程)氛驮。

??????? 在用戶需求狀態(tài)上有“部分實現(xiàn)”狀態(tài)舆声，表示某條需求因故分為多個階段或版本提供×“已批準”表示項目經(jīng)理決定接受這個需求媳握，此后會觸發(fā)產(chǎn)品需求的編寫過程，所以為了跟蹤產(chǎn)品需求文檔的提交與評審狀態(tài)磷脯，另外用“需求文檔狀態(tài)”信息項進行記錄蛾找。

??????? 因為項目經(jīng)理在評估用戶需求分析報告時，可能會拒絕或掛起用戶需求赵誓。所以在用戶需求批準之后打毛，需求作者才會開始編寫產(chǎn)品需求說明書柿赊。使得產(chǎn)品需求沒有 已提議、已批準幻枉、已拒絕碰声、已掛起 狀態(tài)。

??????? 在規(guī)劃版本活動之后熬甫，可能產(chǎn)生需求變更活動胰挑，并可能刪除用戶需求或產(chǎn)品需求。

??????? 在制作版本完成后椿肩，產(chǎn)品需求跟蹤表中本版本有關的產(chǎn)品需求被置為已實現(xiàn)狀態(tài)瞻颂，并記錄了版本號。測試經(jīng)理按版本號導出本版本已實現(xiàn)的產(chǎn)品需求郑象，建立測試用例并組織驗證版本贡这。

常見問題：

1，跨項目協(xié)同

?? 各項目的開發(fā)流程經(jīng)常需要納入整體管理厂榛，至少要一致盖矫。

?? 某任務在各項目的進度必須一致、之間的任務交互如何可控击奶、如何提交需求給其它項目炼彪、進度如何反饋？

??????? 如何監(jiān)控其它項目的任務進度正歼、質(zhì)量？

??????? 問題發(fā)生如何追溯原因拷橘？

??????? 需求分析在各項目的理解要一致局义，在評審上如何協(xié)作？

??????? 發(fā)現(xiàn)問題如何反饋給其它項目冗疮？

??????? 項目間接口文檔的形式萄唇、內(nèi)容、如何歸檔术幔、文檔配置項的管理另萤？

2，通過需求管理對研發(fā)過程進行質(zhì)量監(jiān)控

?????? 許多公司號稱全面诅挑、全員的質(zhì)量控制四敞。

??????? 實際操作時，在各方資源總是不足的情況下拔妥，全面的質(zhì)量控制會降低當前項目進度忿危。以下列出一些可選用的措施。

注：無論是從理論上没龙，還是從實踐上分析铺厨，有效的缎玫、全面的需求管理如得到執(zhí)行，從長期看解滓，會降低產(chǎn)品的故障率赃磨，產(chǎn)品開發(fā)、故障響應速率可以穩(wěn)定的評估出來洼裤，從而達到可控的項目管理邻辉。

??????? 但受 結(jié)果導向 績效體系影響，項目經(jīng)理一般只關注短期目標的實現(xiàn)逸邦。

??? 下面針對的軟件企業(yè)是：CMMI1恩沛、CMMI2，或者企業(yè)已經(jīng)有部分過程達到CMMI3（至少各種標準缕减、流程在文字上作了定義雷客，執(zhí)行上則因人而異）

? 一、較粗的管理層面桥狡。

??? 1）需求評審與需求承諾的加強搅裙。

??????? 文字上明確各需求的評審員角色并要求必須參加，抄送人角色裹芝。部逮。

??????? 各產(chǎn)品提供需求評審通過檢查單，可列出產(chǎn)品常見的需求模糊問題嫂易、各方面的產(chǎn)品指標受影響程度兄朋、業(yè)務流程細化到什么程度等。

??????? 需求承諾必須有哪幾級領導參與怜械，介紹市場背景颅和，任務具體執(zhí)行部門（開發(fā)、測試）是否能當場承諾任務進度缕允，他們對上游有何要求峡扩。

??? 2）需求狀態(tài)跟蹤

??????????? 各條需求當前是否已提交開發(fā)、是否已提交測試障本，是否已發(fā)布教届。

??? 3）需求周報、項目周報及例會制度驾霜。

??????????? 需求周報可列出本周需求變更情況案训，已經(jīng)規(guī)劃到版本的需求清單和未規(guī)劃的需求清單等。抄送人員要全面粪糙。

??????????? 重點需求重點跟蹤萤衰。

??????????? 需求例會對 未規(guī)劃需求 進行規(guī)劃，現(xiàn)有需求規(guī)劃的變更猜旬，需求分析中面對的困難 等脆栋。

??????????? 項目周報列出本周項目進度倦卖、已發(fā)現(xiàn)故障情況、未解決事宜與負責人椿争、風險跟蹤情況怕膛。。秦踪。褐捻，

??????????? 項目例會是供各方面項目成員交流問題的一個平臺。

?? 4）故障管理

??????????????? 當前未解決故障列表椅邓，故障復盤柠逞，

???? 5）質(zhì)量管理

??????????????? 任務預警（故障、需求任務的進度是否拖延）景馁，未完成任務跟蹤板壮，度量指標統(tǒng)計，質(zhì)量周報合住，改進措施跟蹤绰精。

??? 二、細化管理

在上述活動的基礎上透葛，增加以下活動笨使。

? 1）需求追蹤采用某工具進行管理。

??? 需求僚害、設計硫椰、測試、代碼各級產(chǎn)品的完成日期萨蚕，負責人靶草，歸檔路徑，評審會議記要路徑门岔，受影響的其它項目的狀態(tài)。

??? 各研發(fā)階段執(zhí)行情況可一目了然烤送，監(jiān)控哪些產(chǎn)品的提交寒随、評審狀態(tài)，定期檢查與通報帮坚，及時發(fā)現(xiàn)識別風險妻往。

? 2)需求變更控制

??????? 變更歷史追蹤。试和。讯泣。

注：CMMI主要有5種成熟度級別，從低到高分別是初始級阅悍、已管理級好渠、已定義級昨稼、定量管理級和持續(xù)優(yōu)化級。

初始級（1級）：過程的執(zhí)行往往是即興管理拳锚，對人的依賴性很高假栓，結(jié)果很難預測，管理層實踐可能會無效霍掺。

已管理級（2級）：項目管理規(guī)范化了匾荆，組織方針、項目計劃和過程描述都被建立杆烁，并文檔化牙丽，有適當?shù)馁Y源，責任指派和授權(quán)兔魂，小項目可以根據(jù)過去的經(jīng)驗進行預測烤芦。規(guī)范化有助于現(xiàn)有實踐在壓力下仍能進行，同時對管理人員來講入热，過程活動和工作產(chǎn)品的狀態(tài)在預定義的點上是可見的拍棕。

??????? 在本成熟度級別中主要有7個工作域，需求管理勺良、項目計劃绰播、項目監(jiān)督和控制、測量和分析尚困、配置管理蠢箩、供應商協(xié)議管理、過程和產(chǎn)品質(zhì)量保證事甜。

已定義級（3級）：在已管理級的基礎上谬泌，整個組織有標準的過程，項目可以根據(jù)需要進行裁剪逻谦，工程過程可以更有效的設施掌实，組織的活動是可預測的，培訓也是有計劃的邦马。在整個活動過程中贱鼻，角色和職責分明，過程和產(chǎn)品的狀態(tài)在整個研發(fā)過程都是可見的滋将。

??????? 在這個級別主要有14個工作域邻悬，需求開發(fā)、技術解決方案随闽、產(chǎn)品集成父丰、驗證、確認掘宪、組織過程聚焦蛾扇、組織過程定義攘烛、組織級培訓、集成項目管理屁桑、集成供應商管理医寿、風險管理、決策分析和解決蘑斧、集成的組織環(huán)境靖秩、集成團隊。

??????? 和2級相比竖瘾，在過程描述上沟突，3級更詳細、嚴格捕传，并且在實施管理是更強調(diào)了解過程活動之間關系惠拭、過程的詳細度量值以及過程的工作產(chǎn)品和服務。