需求管理流程設(shè)計研討課件

需求管理流程研討目的瞭解需求管理流程的基本概念、實際案例；討論並確定需求管理流程的主要活動及其之間的關(guān)聯(lián)；確定需求管理流程的典型角色及其與主要活動之間的匹配情況；討論並確認需求管理流程執(zhí)行策略並收集相關(guān)建議。Copyright@2004-2014上海翰緯1第一頁，共四十三頁。主要關(guān)注點需要確定的關(guān)注點：支保部的定位？需求管理流程的管理對象和範圍？需求管理的生命週期長度？開發(fā)前還是上線投產(chǎn)？流程的角色設(shè)置和職責(zé)流程各角色的工作界面和溝通接口

目標：需求管理恰如裁縫的量體裁衣，它直接關(guān)係到最終產(chǎn)品的成型。僅從字面出發(fā)，如果一個產(chǎn)品滿足了客戶需求，那它無疑就是成功的。需求管理的過程，從需求分析開始貫穿整個項目始終，力圖實現(xiàn)最終產(chǎn)品同需求性的最佳結(jié)合。需求管理能夠確證：我們確知客戶的需求是什麼（質(zhì)量）；滿足客戶需求的最佳解決辦法（統(tǒng)一性）；Copyright@2004-2014上海翰緯2第二頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯3概念準備實際案例XX銀行需求管理流程現(xiàn)狀流程活動和流程角色設(shè)計管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第三頁，共四十三頁。需求管理-基礎(chǔ)目的：確保服務(wù)資源的生產(chǎn)能力和需求預(yù)測及模式保持一致；確保資源能力可以在需要時有效使用，在不使用時及時釋放關(guān)鍵字：業(yè)務(wù)分析服務(wù)組合資源容量如何滿足“適”：前提條件：已受理需求申請考慮要素：需求分析、需求評審、需求驗證、需求確認過程目的減小需求的不確定性提供充分需求估計和規(guī)劃，保證產(chǎn)品和需求的一致性減少因過度冗餘而導(dǎo)致閒置容量的額外成本無法得到有效的回收鞏固與提升客戶與使用者滿意度便於需求支持資源的合理配備與使用過程價值定義是指理解並影響客戶對服務(wù)的需求以及提供相應(yīng)容量以滿足這些需求的活動；術(shù)語信息技術(shù)服務(wù)需求：指業(yè)務(wù)部門以及最終用戶對信息技術(shù)服務(wù)的需求。新增服務(wù)：按照業(yè)務(wù)部門或公司統(tǒng)一規(guī)劃（或備案）確定的、滿足用戶和業(yè)務(wù)需求的新增信息技術(shù)服務(wù)，這些服務(wù)未列入已發(fā)佈的服務(wù)目錄。服務(wù)功能的變更：該服務(wù)已經(jīng)上線運行，並且已列入部已發(fā)佈的服務(wù)目錄，現(xiàn)階段主要以功能完善、修復(fù)Bug為主，通過立項續(xù)建來實現(xiàn)大版本升級。說明觸發(fā)條件：業(yè)務(wù)需求；過程模式：主動式的管理過程；過程特點：適，統(tǒng)一，一致過程概述Copyright@2004-2014上海翰緯4適第四頁，共四十三頁。需求管理流程的主要活動概述（一）需求開發(fā)需求調(diào)研：問卷訪談場景模擬需求建模和分析，可利用以下工具進行：UMLRationalRose(RationalSoftwareArchitect)PowerDesignerVISIO輸出需求定義（需求規(guī)格說明書）或需求定義說明書需求定義的確認：確認有兩層含義：首先是需求調(diào)查與分析人員與客戶間通過溝通，剔除或修訂對需求理解不一致的部分；另外一個層面的意思是指，雙方對於已達成共同理解或獲得客戶/用戶認可的部分進行承諾。Copyright@2004-2014上海翰緯5第五頁，共四十三頁。需求管理流程的主要活動概述（二）建立並識別需求狀態(tài)和跟蹤機制需求狀態(tài)是指用戶需求的一種狀態(tài)變換過程進行需求調(diào)研時，客戶對需求的描述可能有多種：客戶可以明確且清楚的提出的需求；客戶知道需要做些什麼，但又不能確定的需求；客戶本身可以得出這類需求，但需求的業(yè)務(wù)不明確，還需要等待外部信息客戶本身也說不清楚對於這些需求，在需求開發(fā)的過程中，存在著以下幾種情況:有可能要取消的因為不明確而可以後延的，同時可能轉(zhuǎn)化為被取消的需求與客戶經(jīng)過溝通或確認的，此處有兩種情況，一類是確認雙方達成共識，另一種情況是還需要再進一步溝通的。建立狀態(tài)追蹤機制：如狀態(tài)追蹤矩陣狀態(tài)示例：待確認：客戶提出需求，但雙方?jīng)]有經(jīng)過溝通或確認；已確認：經(jīng)過確認，雙方認可並達成共識；未能確認:雙方經(jīng)過確認，但沒有達成共識的需求；Copyright@2004-2014上海翰緯6第六頁，共四十三頁。需求管理流程的主要活動概述（三）技術(shù)解決方案設(shè)計技術(shù)需求分析和建模根據(jù)業(yè)務(wù)需求規(guī)格說明書或業(yè)務(wù)需求定義說明書和建模分析結(jié)果編制技術(shù)需求規(guī)格說明書評審確認技術(shù)需求開發(fā)技術(shù)解決方案：定義產(chǎn)品或服務(wù)組件以滿足需求定義組件的關(guān)係和接口明確組件的開發(fā)或獲取方式：內(nèi)部完成還是採購有條件時，可能有多套方案供評審決策需求評審和確認預(yù)審核：在進行正式評審前，需要有人員對其要進行評審的對象進行把關(guān)，確認其是否具備進入評審的初步條件。正式評審中評判需求優(yōu)劣的主要指標有：正確性、清晰性、無二義性、一致性、必要性、完整性、可實現(xiàn)性、可驗證性、可測性。如果有可能，應(yīng)制定預(yù)審核的送審材料清單和正式審核的檢查項清單。Copyright@2004-2014上海翰緯7第七頁，共四十三頁。需求管理流程的主要活動概述（四）產(chǎn)品開發(fā)與集成不在需求管理中討論需求跟蹤進行需求跟蹤的目的是為了建立和維護從用戶需求開始到測試之間的一致性與完整性。確保所有的實現(xiàn)是以用戶需求為基礎(chǔ)。對於需求實現(xiàn)是否全部的覆蓋。同時確保所有的輸出與用戶需求的符合性。正向跟蹤：以用戶需求為切入點，檢查《用戶需求說明書》或《需求規(guī)格說明書》中的每個需求是否都能在後繼工作產(chǎn)品中找到對應(yīng)點。逆向跟蹤：檢查設(shè)計文檔、代碼、測試用例等工作產(chǎn)品是否都能在《需求規(guī)格說明書》中找到出處。Copyright@2004-2014上海翰緯8第八頁，共四十三頁。需求管理流程的主要活動概述（五）需求變更控制需求變更通常會對產(chǎn)品開發(fā)和集成的進度、投入人力資源產(chǎn)生很大的影響，這是必須面臨與需要處理的問題。需求發(fā)生變更的起因主要有：隨著項目生命週期的不斷往前推進，人們（包括開發(fā)方和客戶方）對需求的瞭解越來越深入，發(fā)現(xiàn)原先的提出的需求可能存在著一定的缺陷，因此要變更需求。市場業(yè)務(wù)需求發(fā)生了變化，原先的需求可能跟不上當前的市場業(yè)務(wù)發(fā)展，因此要變更需求。需求的變更則意味著要需要重新進行估計，調(diào)整資源、重新分配任務(wù)、修改前期工作產(chǎn)品等，而作為開發(fā)者，需要增加預(yù)算與投資，開發(fā)組要為此付出較重的代價。需求變更控制的動機是：如果需求變更帶來的好處大於壞處，那麼允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。如果需求變更帶來的壞處大於好處，那麼拒絕變更。由於需求文檔是重要的配置項，需求的變更應(yīng)當遵循相關(guān)的變更管理程序。Copyright@2004-2014上海翰緯9第九頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯10概念準備實際案例XX銀行需求管理流程現(xiàn)狀流程活動和流程角色設(shè)計管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第十頁，共四十三頁。案例1：某電力局信息系統(tǒng)需求管理流程部門業(yè)務(wù)參與者職責(zé)說明備注最高管理層局領(lǐng)導(dǎo)系統(tǒng)使用者，可以使用系統(tǒng)、對信息系統(tǒng)提出需求、

等待需求處理完畢、評價需求處理結(jié)果。除局領(lǐng)導(dǎo)和RA本身外的所有系統(tǒng)使用者（包括不擔(dān)任RA的部門領(lǐng)導(dǎo)）提出的需求都必須先通過部門內(nèi)審核然后進入需求評審委員會評審流程。信息需求評審委員會為保證需求管理的有效運作，特成立信息需求評審委員會，下設(shè)業(yè)務(wù)專家組和信息專家組。業(yè)務(wù)專家組負責(zé)業(yè)務(wù)評審，信息專家組負責(zé)信息技術(shù)評審。

普通使用部門基層人員及一般管理人員系統(tǒng)使用者，可以使用系統(tǒng)、對信息系統(tǒng)提出需求、

等待需求處理完畢、評價需求處理結(jié)果。部門領(lǐng)導(dǎo)RARA是部門內(nèi)需求審核人，RA由人事部發(fā)文指定，每個部門可以有一個或多

個RA。業(yè)務(wù)歸口管理部門基層人員及一般管理人員系統(tǒng)使用者，可以使用系統(tǒng)、對信息系統(tǒng)提出需求、

等待需求處理完畢、評價需求處理結(jié)果。部門領(lǐng)導(dǎo)RARA是部門內(nèi)需求審核人，RA由人事部發(fā)文指定，每個部門可以有一個或多

個RA。業(yè)務(wù)專家組信息需求評審委員會中指定的業(yè)務(wù)專家組負責(zé)對需求進行業(yè)務(wù)評審。業(yè)務(wù)專家

組按照業(yè)務(wù)條線分為若干小組，按照需求評審委

員會的規(guī)劃，每個信息系統(tǒng)都有其對應(yīng)的業(yè)務(wù)專家組，在相應(yīng)信息系統(tǒng)出現(xiàn)需求

變更和問題反饋時執(zhí)行需求業(yè)務(wù)評審工作。信息部基層人員及一般管理人員系統(tǒng)使用者，可以使用系統(tǒng)、對信息系統(tǒng)提出需求、

等待需求處理完畢、評價需求處理結(jié)果。部門領(lǐng)導(dǎo)RARA是部門內(nèi)需求審核人，RA由人事部發(fā)文指定，每個部門可以有一個或多

個RA。業(yè)務(wù)專家組信息需求評審委員會中指定的業(yè)務(wù)專家組負責(zé)對需求進行業(yè)務(wù)評審。部分業(yè)務(wù)的歸口管理部門是信息部。信息專家組需求評審委員會中指定的信息專家組負責(zé)對需求進行信息技術(shù)評審。信息

專家組分為信息系統(tǒng)組、SOA集成組、信息安全組、廠商組等。

信息專家組中的信息系統(tǒng)組由多個下屬小組組成，每個下屬小組對應(yīng)一個

信息系統(tǒng)。所有針對信息系統(tǒng)提出的需求都會先由信息系統(tǒng)組下屬小組接收處

理，由下屬小組決定是否發(fā)起與其他幾個信息專家組的會簽。信息系統(tǒng)負責(zé)人信息部為每個信息系統(tǒng)指定一個信息系統(tǒng)負責(zé)人，信息系統(tǒng)負責(zé)人

保證系統(tǒng)正常運行、處理跟進系統(tǒng)改造。Copyright@2004-2014上海翰緯11第十一頁，共四十三頁。案例1：Copyright@2004-2014上海翰緯12第十二頁，共四十三頁。案例2：某軟件開發(fā)商需求管理流程角色職責(zé)能力要求備注客戶/最終用戶被邀請參與《軟件需求規(guī)格說明書》的評審；參與并確認客戶需求的定義。

項目經(jīng)理

參與《軟件需求規(guī)格說明書》的評審；建立并維護本項目的需求跟蹤矩陣，跟蹤需求負責(zé)接收《需求變更申請表》，組織需求變更活動的開展；定義需求狀態(tài)類型；分析需求跟蹤狀態(tài)結(jié)果；接受需求變更、需求狀態(tài)類別確定的培訓(xùn)

高級經(jīng)理參與《軟件需求規(guī)格說明書》的評審批準軟件需求規(guī)格說明書評審報告

項目組成員協(xié)助項目經(jīng)理定義客戶原始需求或需求協(xié)助項目經(jīng)理編寫軟件需求規(guī)格說明書負責(zé)不同階段的需求跟蹤矩陣內(nèi)容（素材）的更新、分析、再利用負責(zé)變更的需求的修改；

測試人員參與《軟件需求規(guī)格說明書》的評審；負責(zé)不同階段的跟蹤矩陣內(nèi)容（素材）的更新、分析、再利用

配置管理人員

參與《軟件需求規(guī)格說明書》的評審；負責(zé)將需求基線納入配置管理；并在需求基線的變更過程中，記錄變更狀態(tài)；發(fā)布變更和基線；更新需求基線；統(tǒng)計需求變更總數(shù)；接受需求變更、需求狀態(tài)表填寫、需求狀態(tài)圖繪制的培訓(xùn)

質(zhì)量保證人員參與《軟件需求規(guī)格說明書》的評審；檢查《需求跟蹤矩陣》的填寫，協(xié)助項目經(jīng)理分析需求跟蹤狀態(tài)結(jié)果

Copyright@2004-2014上海翰緯13第十三頁，共四十三頁。案例2：某軟件開發(fā)商需求管理流程Copyright@2004-2014上海翰緯14第十四頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯15概念準備實際案例XX銀行需求管理流程現(xiàn)狀流程活動和流程角色設(shè)計管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第十五頁，共四十三頁。需求管理（差距分析&現(xiàn)狀）現(xiàn)狀：優(yōu)勢：不足：Copyright@2004-2014上海翰緯16第十六頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯17概念準備實際案例XX銀行需求管理流程現(xiàn)狀流程活動和流程角色設(shè)計管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第十七頁，共四十三頁。對需求的處理將遵循以下執(zhí)行途徑提交需求： （1）需求來源：業(yè)務(wù)部門關(guān)閉事件： （1）一般有手動關(guān)閉和自動關(guān)閉兩種方式； （2）採用首問負責(zé)制，一般應(yīng)集中由服務(wù)臺（一線）工作人員關(guān)閉，如有特殊需求可由需求經(jīng)理關(guān)閉。Copyright@2004-2014上海翰緯18第十八頁，共四十三頁。需求管理流程活動根據(jù)實際業(yè)務(wù)需求提出需求申請交至服務(wù)臺；記錄需求申請，並創(chuàng)建和分派需求申請單；受理技術(shù)需求；判定需求信息是否充足；技術(shù)需求分析和建模，並編寫業(yè)務(wù)需求說明書；創(chuàng)建變更申請；業(yè)務(wù)需求內(nèi)部評審和提交技術(shù)需求受理分析和評審確認變更管理評審分析評審變更申請進，並反饋變更相關(guān)情況；記錄更新需求評審結(jié)果，並反饋結(jié)果；需求關(guān)閉與用戶驗證結(jié)果，徵求用戶同意關(guān)閉事件根據(jù)知識管理流程決定是否需要進行更新知識庫關(guān)閉事件，設(shè)定適當?shù)年P(guān)閉代碼

受理業(yè)務(wù)需求；判定需求信息是否充分；業(yè)務(wù)需求分析和建模，並編寫業(yè)務(wù)需求說明書；業(yè)務(wù)需求可行性評審；記錄需求評審結(jié)果；業(yè)務(wù)需求受理分析和評審確認Copyright@2004-2014上海翰緯19第十九頁，共四十三頁。需求管理與其他流程的關(guān)係Copyright@2004-2014上海翰緯20第二十頁，共四十三頁。需求管理流程角色Copyright@2004-2014上海翰緯21需求管理流程角色主要職責(zé)需求提出人業(yè)務(wù)部門提交需求。服務(wù)臺分派需求單。更新需求記錄。跟蹤整個需求管理流程。業(yè)務(wù)需求經(jīng)理支持保障部內(nèi)業(yè)務(wù)需求負責(zé)人。協(xié)調(diào)相關(guān)資源進行業(yè)務(wù)需求分析建模、業(yè)務(wù)需求評審，保障需求管理按照預(yù)定流程順利運作。負責(zé)需求管理與其他流程的交互管理工作。業(yè)務(wù)需求分析員信息科技部內(nèi)技術(shù)需求負責(zé)人協(xié)調(diào)相關(guān)資源進行技術(shù)需求分析建模，技術(shù)需求評審工作。技術(shù)需求經(jīng)理信息科技部內(nèi)技術(shù)需求負責(zé)人。協(xié)調(diào)相關(guān)資源進行技術(shù)需求分析建模，技術(shù)需求評審工作。技術(shù)需求分析員技術(shù)需求分析建模和定義描述，並編寫技術(shù)需求規(guī)格說明書。第二十一頁，共四十三頁。需求管理流程角色匹配Copyright@2004-2014上海翰緯22需求管理流程角色對應(yīng)XX銀行相關(guān)崗位/人員需求提出人服務(wù)臺業(yè)務(wù)需求經(jīng)理業(yè)務(wù)需求分析員技術(shù)需求經(jīng)理技術(shù)需求分析員第二十二頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯23概念準備實際案例XX銀行需求管理流程現(xiàn)狀流程活動和流程角色設(shè)計管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第二十三頁，共四十三頁。需求管理流程的流程原則業(yè)務(wù)部門與信息科技部、支持保障部應(yīng)本著團結(jié)、協(xié)作的原則在信息技術(shù)服務(wù)需求的全生命週期內(nèi)保持充分溝通。需求的生命週期包括：需求提交、需求分析、需求審核、需求開發(fā)、需求測試、需求驗證和需求上線。流程執(zhí)行應(yīng)遵循以下原則：需求的提交與分析遵循需求管理流程。需求審核分為以下兩種情況：如需立項審批應(yīng)遵循公司立項和招投標相關(guān)規(guī)定；其他情況遵循變更管理流程的變更策略。需求開發(fā)、測試、驗證和上線在發(fā)佈和部署管理流程中實現(xiàn)，並遵循流程中發(fā)佈和部署的相關(guān)策略。Copyright@2004-2014上海翰緯24第二十四頁，共四十三頁。需求單的責(zé)任人策略責(zé)任人策略用來確保每個需求在任何時段都有適當?shù)娜藛T來負責(zé)，從而保證需求處理的及時性和有效性，確保需求的處理能夠得到及時跟蹤和協(xié)調(diào)。事件單的責(zé)任人策略當一個需求被創(chuàng)建後，事件需求受理員負責(zé)這個需求單，其負責(zé)跟蹤需求處理的進展直至最終的解決；當需求單被分派後，需求經(jīng)理員負責(zé)此需求單，但是分派方（需求受理員）有責(zé)任通知被分派的需求經(jīng)理，需求經(jīng)理協(xié)調(diào)需求分析員完成需求分析和建模工作；需求單被需求經(jīng)理接受之後，需求經(jīng)理對該單負責(zé)；Copyright@2004-2014上海翰緯25第二十五頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯26概念準備實際案例XX銀行需求管理流程現(xiàn)狀流程活動和流程角色設(shè)計管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第二十六頁，共四十三頁。需求管理流程總結(jié)Copyright@2004-2014上海翰緯27需求管理是服務(wù)管理非常重要的一個方面。如果對客戶的服務(wù)需求缺乏充分的需求管理，則需求的不確定性就會成為服務(wù)提供者的一個主要風(fēng)險來源。需求管理的流程核心是需求來源於業(yè)務(wù)部門，需求提交後由服務(wù)臺開單，經(jīng)過需求和技術(shù)需求分析建模和評審，交由變更管理評審，最終由服務(wù)臺關(guān)單。第二十七頁，共四十三頁。需求管理流程課後作業(yè)對今天現(xiàn)場討論未達成一致的管理流程、角色匹配、管理策略等，翰緯會根據(jù)需要提供作業(yè)範本和其他實例參考，XX銀行各團隊需參考翰緯給出的範例和範本，制定自己的管理策略。Copyright@2004-2014上海翰緯28第二十八頁，共四十三頁。議程/AgendaCopyright@2004-2014上海翰緯29概念準備實際案例XX銀行需求管理流程現(xiàn)狀流程活動和流程角色設(shè)計管理策略研討總結(jié)與課後作業(yè)安排附錄：理論依據(jù)第二十九頁，共四十三頁。ITILV3StrategyService：DemandManagement

業(yè)務(wù)活動模式Copyright@2004-2014上海翰緯30業(yè)務(wù)活動影響服務(wù)需求模式（來源：OGC）第三十頁，共四十三頁。ITILV3StrategyService：DemandManagement

業(yè)務(wù)活動模式業(yè)務(wù)（流程）是服務(wù)需求的主要來源。業(yè)務(wù)活動模式（PBA）影響著服務(wù)提供者提供的需求方式。必須研究客戶的業(yè)務(wù)以便確定、分析和設(shè)計這些模式，從而為容量管理提供充分的基礎(chǔ)。業(yè)務(wù)活動模式（PBA）PBA是用於描述一項或多項業(yè)務(wù)（流程）活動的負載（workload）情況的需求分析文檔。業(yè)務(wù)活動隨時間而變化的“走勢圖”有助於幫助IT服務(wù)提供者深入瞭解並規(guī)劃不同級別的業(yè)務(wù)活動。定義一項業(yè)務(wù)的一些動態(tài)變化的關(guān)鍵參數(shù)，包括與客戶、供應(yīng)商、合作夥伴以及其他利益相關(guān)者的關(guān)係。PBA需納入變更管理的控制。PBA中需要描述業(yè)務(wù)流程的一些重要參數(shù)，如頻率、數(shù)量、位置和持續(xù)時間等。分析PBA是為如下的服務(wù)管理職能和流程提供輸入：服務(wù)設(shè)計後可以優(yōu)化設(shè)計，以適應(yīng)需求的方式；服務(wù)目錄可以將需求方式與適當?shù)姆?wù)對應(yīng)；服務(wù)組合管理可以批準在增加容量、新的服務(wù)或變更服務(wù)上進行的投資；服務(wù)運營可以調(diào)整資源的分配和安排；服務(wù)運營可以識別機會，通過對緊密匹配的需求方式進行分組而合併需求；財務(wù)管理可以批準合適的激勵措施，從而影響需求。Copyright@2004-2014上海翰緯31第三十一頁，共四十三頁。ITILV3StrategyService：DemandManagement

業(yè)務(wù)活動模式和用戶概述業(yè)務(wù)活動推動了服務(wù)的需求。用戶概述（如人員、流程和應(yīng)用）產(chǎn)生了業(yè)務(wù)活動模式（PBA）。用戶概述（UserProfile）是用於描述用戶對各種IT服務(wù)的需求的一種需求分析性文檔。每份用戶概述文件與一份或者多分PBA文件相關(guān)聯(lián)，如下圖：對於有些業(yè)務(wù)流程或系統(tǒng)，我們也可以將其視為一個用戶，可根據(jù)實際情況進行判斷。Copyright@2004-2014上海翰緯32第三十二頁，共四十三頁。CMMI開發(fā)模型V1.3：Part1

4.過程域之間的關(guān)係:項目管理類（項目管理類）Copyright@2004-2014上海翰緯33基本項目管理過程域CMMI-DEV中的七個項目管理類過程域：?集成項目管理（IPM）?項目監(jiān)督與控制（PMC）?項目計畫（PP）?量化項目管理（QPM）?需求管理（REQM）?風(fēng)險管理（RSKM）?供方協(xié)議管理（SAM）第三十三頁，共四十三頁。CMMI開發(fā)模型V1.3：Part1

4.過程域之間的關(guān)係:項目管理類—需求管理（REQM）CMMI-DEV中的七個項目管理類過程域：集成項目管理（IntegratedProjectManagement，IPM）項目監(jiān)督與控制（ProjectMonitoringandControl，PMC）項目計畫（ProjectPlanning，PP）量化項目管理（QuantitativeProjectManagement，QPM）需求管理（RequirementsManagement，REQM）風(fēng)險管理（RiskManagement，RSKM）供方協(xié)議管理（SupplierAgreementManagement，SAM）需求管理（RequirementsManagement，REQM）對需求進行維護。描述了獲得並控制需求的變更，並確保其它相關(guān)計畫與資料保持最新狀態(tài)的活動。提供了從客戶需求到產(chǎn)品需求到產(chǎn)品元件需求的需求可追溯性。確保需求的變更能夠體現(xiàn)在項目計畫、活動與工作產(chǎn)品中。需求管理是動態(tài)且經(jīng)常迴圈發(fā)生的事件序列。Copyright@2004-2014上海翰緯34第三十四頁，共四十三頁。CMMI開發(fā)模型V1.3：Part1

4.過程域之間的關(guān)係:工程類Copyright@2004-2014上海翰緯35工程類過程域：

適用于開發(fā)領(lǐng)域中任何產(chǎn)品或服務(wù)的開發(fā)（如，軟體產(chǎn)品、硬體產(chǎn)品、服務(wù)、過程等）。CMMI-DEV中的五個工程類過程域是：產(chǎn)品集成（ProductIntegration，PI）需求開發(fā)（RequirementsDevelopment，RD）技術(shù)解決方案（TechnicalSolution，TS）確認（Validation，VAL）驗證（Verification，VER）

第三十五頁，共四十三頁。CMMI：Part1應(yīng)用於發(fā)展的CMMI

4.過程域之間的關(guān)係:工程類Copyright@2004-2014上海翰緯36工程類過程域第三十六頁，共四十三頁。CMMI開發(fā)模型V1.3：Part1

4.過程域之間的關(guān)係:工程類需求開發(fā)（RD）識別客戶需要並將這些需要轉(zhuǎn)化為產(chǎn)品需求。產(chǎn)品需求的集合被加以分析，生成高層次的概念解決方案。該需求集合隨後被分配，以建立最初的產(chǎn)品元件需求集合。該產(chǎn)品與產(chǎn)品元件的需求集合清晰地描述了產(chǎn)品的性能、品質(zhì)屬性、設(shè)計功能、驗證需求等等，並通過開發(fā)人員能夠理解並使用的術(shù)語進行描述。提供需求至“技術(shù)解決方案”過程域，在此處需求被轉(zhuǎn)換為產(chǎn)品架構(gòu)、產(chǎn)品元件設(shè)計與產(chǎn)品元件（如通過編碼、製造等）。需求也被提供給“產(chǎn)品集成”過程域，在此處產(chǎn)品元件被組合起來，介面得到驗證，以確保其符合“需求開發(fā)”過程域所提供的介面需求。技術(shù)解決方案（TS）開發(fā)產(chǎn)品元件的技術(shù)資料包，用於“產(chǎn)品集成”過程域或“供方協(xié)議管理”過程域。備選解決方案被考察，並基於已建立的準則選擇最優(yōu)設(shè)計。這些準則可以因產(chǎn)品不同而有顯著區(qū)別，這取決於產(chǎn)品類型、操作環(huán)境、性能需求、支援需求以及成本或交付進度。依賴於“驗證”過程域中的特定實踐，以在設(shè)計過程中並在最後的構(gòu)建之前，執(zhí)行設(shè)計驗證與同級評審。Copyright@2004-2014上海翰緯37第三十七頁，共四十三頁。CMMI開發(fā)模型V1.3：Part1

4.過程域之間的關(guān)係:工程類驗證（VER)確保選定的工作產(chǎn)品滿足規(guī)定的需求。選擇工作產(chǎn)品與驗證方法，用於對照規(guī)定的需求對工作產(chǎn)品進行驗證。驗證也應(yīng)對了同級評審。確認（VAL)對照客戶需要，增量式地對產(chǎn)品進行確認。確認可以在操作環(huán)境或模擬的操作環(huán)境下執(zhí)行。在確認的需求方面與客戶進行協(xié)調(diào)是該過程域的重要元素。範圍包括對產(chǎn)品、產(chǎn)品元件、選定的中間工作產(chǎn)品與過程的確認。產(chǎn)品集成（PI）包含的特定實踐與建立集成策略、進行產(chǎn)品元件集成、以及向客戶交付產(chǎn)品等相關(guān)聯(lián)。在實施產(chǎn)品集成過程時使用了“確認”過程域與“驗證”過程域中的特定實踐。介面驗證是集成過程中的必要事件。在操作環(huán)境中進行產(chǎn)品集成時，就要使用到“確認”過程域中的特定實踐。Copyright@2004-2014上海翰緯38第三十八頁，共四十三頁。CMMI:Part2通用目標與通用實踐以及過程域

產(chǎn)品集成（PI)目的：將產(chǎn)品元件裝配成產(chǎn)品，確保產(chǎn)品作為一個整體正確地運行（即具有所要求的功能與品質(zhì)屬性），並交付產(chǎn)品。簡介：本過程域涉及如何將產(chǎn)品元件集成為更複雜的產(chǎn)品元件或者完整的產(chǎn)品。本過程域的範圍是按照已定義的集成策略與規(guī)程，在一個階段或者增量式的多個階段中進行產(chǎn)品元件的漸進裝配，以實現(xiàn)完整的產(chǎn)品集成。所有過程域中使用的術(shù)語“產(chǎn)品”與“產(chǎn)品元件”，其含義也包括服務(wù)、服務(wù)系統(tǒng)及其元件。產(chǎn)品集成的一個重要方面是管理產(chǎn)品與產(chǎn)品元件的內(nèi)部與外部介面，以確保介面間的相容性。特定目標與特定實踐：

SG1準備產(chǎn)品集成SP1.1建立集成策略SP1.2建立產(chǎn)品集成環(huán)境SP1.3建立產(chǎn)品集成規(guī)程與準則SG2確保介面相容性SP2.1評審介面描述的完整性SP2.2管理介面SG3裝配產(chǎn)品元件並交付產(chǎn)品SP3.1確定需集成的產(chǎn)品元件準備就緒SP3.2裝配產(chǎn)品元件SP3.3評價裝配後的產(chǎn)品元件SP3.4打包並交付產(chǎn)品或產(chǎn)品元件Copyright@2004-2014上海翰緯39第三十九頁，共四十三頁。CMMI:Part2通用目標與通用實踐以及過程域

需求開發(fā)（RD)目的：挖掘、分析並建立客戶需求、產(chǎn)品需求與產(chǎn)品元件需求。簡介：過程域描述3類需求：客戶需求、產(chǎn)品需求與產(chǎn)品元件需求。需求涉及：相關(guān)干係人的需要，包括與不同的產(chǎn)品生命週期階段和產(chǎn)品屬性（回應(yīng)性、安全性、可靠性等）相關(guān)的需要。源於設(shè)計解決方案（如：商用現(xiàn)貨產(chǎn)品的集成、特定架構(gòu)模式的使用等）的選擇所帶來的約束。

特定目標與特定實踐：SG1開發(fā)客戶需求SP1.1挖掘需要SP1.2將干係人的需要轉(zhuǎn)換為客戶需求SG2開發(fā)產(chǎn)品需求SP2.1建立產(chǎn)品與產(chǎn)品元件需求SP2.2分配產(chǎn)品元件需求