2《IT項目管理辦法》.doc

IT項目管理辦法信息管理部2004.4目錄前言4一、術(shù)語定義5二、IT項目生存期72.1應(yīng)用開發(fā)項目生存期72.2應(yīng)用部署項目生存期82.3生存期模型裁減102.3.1內(nèi)部項目102.3.2外包項目112.3.3合作項目122.3.4采購項目122.3.5混合型項目13三、IT項目過程143.1啟動143.2項目分解與計劃143.3項目實施153.4項目結(jié)束163.5項目過程總結(jié)16四、IT項目計劃174.1項目規(guī)模估算過程184.2項目規(guī)劃過程194.3項目責(zé)任分配過程194.4項目采購計劃20五、IT項目監(jiān)控225.1項目定期評審過程235.2項目事件評審過程245.3偏離糾正過程245.4計劃修訂過程255.5項目采購監(jiān)控26六、IT項目審核286.1審核計劃過程296.2審核執(zhí)行過程29七、IT項目需求開發(fā)與管理317.1需求開發(fā)的步驟317.2需求管理的步驟34八、IT項目工作產(chǎn)品及驗收368.1交付件368.2質(zhì)量記錄378.3工作產(chǎn)品模板378.3.1任務(wù)書模板388.3.2計劃書模板388.3.3評審報告模板398.3.4需求歸納表模板398.4項目驗收408.4.1可交付物驗收408.4.2技術(shù)驗收408.4.3功能驗收418.4.4驗收計劃41九、項目經(jīng)理的職責(zé)和素質(zhì)429.1項目經(jīng)理的職責(zé)429.2項目經(jīng)理的素質(zhì)459.3項目經(jīng)理的技能47前言中外運對IT的投資是通過各種類型的IT項目來實現(xiàn)的，通過實施IT項目體現(xiàn)對IT投資的效果，因此有必要對IT項目制定相關(guān)的流程和規(guī)范。IT項目分為兩個階段：立項階段和項目執(zhí)行階段。本文只涉及項目執(zhí)行階段的管理辦法，項目立項階段的流程按照IT項目立項流程執(zhí)行。本管理辦法的適用范圍為股份公司總部。中外運股份有限公司信息化組織（以下簡稱ITO）是中外運股份有限公司專門致力于信息化建設(shè)的組織，負責(zé)企業(yè)信息系統(tǒng)應(yīng)用的支持、業(yè)務(wù)信息化的幫助以及基于信息技術(shù)的業(yè)務(wù)開拓。這些責(zé)任將使得ITO逐漸成為企業(yè)核心競爭力的一個組成部分，與此同時，也要求ITO持續(xù)地改善其IT項目管理和運行能力。為了將這些項目管理過程得到有效的落實，特制訂以下IT項目管理辦法。ITO組織內(nèi)所有人員需嚴格執(zhí)行，保證ITO內(nèi)的項目管理和系統(tǒng)運行逐漸提高到業(yè)界較高水準(zhǔn)，滿足企業(yè)業(yè)務(wù)高速發(fā)展的需要。一、術(shù)語定義1. 項目：在規(guī)定的時間和預(yù)算內(nèi)完成的某種具有特定質(zhì)量性能要求的一次性、多任務(wù)的工作。2. 項目的特征：l 目標(biāo)確定性l 時限性l 一次性l 獨特性3. 項目生存期：一個項目從立項到項目執(zhí)行結(jié)束的過程。4. 項目生存期模型：是對項目生存期的抽象，其中包括項目階段的劃分、各個階段的進入條件、輸入和輸出等生存期公共屬性。5. 關(guān)鍵過程域：是項目管理和項目執(zhí)行所要關(guān)注的重要過程域，包括項目管理、項目實施、項目支持等多方面的過程。這些過程域是根據(jù)業(yè)務(wù)需要和資源情況逐步開發(fā)定義的。6. 驗證：是對系統(tǒng)的評價過程，以確定一個項目執(zhí)行階段的產(chǎn)品是否滿足在此階段開始時所給定的條件。7. 確認：是在項目執(zhí)行過程中或項目結(jié)束時評價系統(tǒng)，以確定它是否滿足特定的需求。8. 審核：是用于驗證或確認的手段。審核是一種正式的評審活動，即需要計劃并按計劃執(zhí)行。9. 客戶需求（Customers needs）：是客戶的需要與期待，這些要求和期待直接相關(guān)于用戶的業(yè)務(wù)過程和業(yè)務(wù)任務(wù)需求。10. 系統(tǒng)需求（Requirements for System）：通過對客戶需求的分析，確定系統(tǒng)應(yīng)實現(xiàn)的規(guī)格。這些規(guī)格描述了系統(tǒng)的行為、特性和屬性。系統(tǒng)需求也稱為系統(tǒng)規(guī)格。11. 功能性需求（Functional Requirements）：支持業(yè)務(wù)功能的系統(tǒng)需求，如數(shù)據(jù)檢索、交易執(zhí)行、報告打印等。12. 非功能性需求（Non-functional Requirements）：系統(tǒng)執(zhí)行的行為特征，如可靠性、安全性、性能指標(biāo)等。13. IT（Information Technology）：信息技術(shù)。14. ITO（Information Technology Organization）：信息技術(shù)組織。15. SOW（Statement Of Work）：任務(wù)書。16. PP（Project Planning）：項目計劃。17. PR（Peer Review）：同行評審或?qū)Φ仍u審。二、IT項目生存期2.1應(yīng)用開發(fā)項目生存期應(yīng)用開發(fā)項目生存期是中外運ITO管轄的所有IT開發(fā)項目的生存期模型，該模型可通過剪裁應(yīng)用到不同類型的開發(fā)中。應(yīng)用開發(fā)項目生存期模型定義圖示如下：項目立項（略）項目執(zhí)行：用戶需求獲取SOW系統(tǒng)概念確定系統(tǒng)定義設(shè)計實現(xiàn)驗證定義過程實施過程l 項目立項結(jié)束，進入項目執(zhí)行階段。l SOW是項目執(zhí)行階段啟動的文件。l 用戶需求獲取階段是析取用戶對IT系統(tǒng)的需要（Needs），其中包括系統(tǒng)目的、范圍、目標(biāo)、業(yè)務(wù)需求、限制條件等方面。l 系統(tǒng)概念確定階段的目的是提出如何滿足用戶需要的總體策略，即確定滿足需求的系統(tǒng)基本實現(xiàn)模式，如體系、架構(gòu)、獲?。ˋcquisition）方式等內(nèi)容。l 系統(tǒng)定義階段是對用戶的需求進一步進行開發(fā)以得到系統(tǒng)實現(xiàn)的規(guī)格定義（Specification）。l 設(shè)計階段包括了系統(tǒng)層面的設(shè)計（高層設(shè)計）和實現(xiàn)層面的設(shè)計（詳細設(shè)計）。l 實現(xiàn)階段包括了具體開發(fā)、集成、工程測試。l 驗證階段是基于用戶的角度對系統(tǒng)的功能進行接收/驗證測試。l 項目結(jié)束。2.2應(yīng)用部署項目生存期應(yīng)用部署項目生存期的執(zhí)行階段是將經(jīng)過驗證的應(yīng)用系統(tǒng)部署到相關(guān)業(yè)務(wù)部門中并投入使用的過程。由于中外運規(guī)模較大，且地域分布很廣，一個大型IT應(yīng)用的部署會涉及到多個部門、多個場所和不同的內(nèi)部和外包資源，因此應(yīng)用部署往往會作為一個獨立的項目進行。應(yīng)用部署項目生存期模型就是用于此目的而建立的，該模型圖示如下：項目立項（略）項目執(zhí)行：應(yīng)用部署規(guī)劃SOW試點發(fā)布實施計劃制定特殊需求處理切換準(zhǔn)備切換l 項目立項結(jié)束，進入項目執(zhí)行階段。l SOW是項目執(zhí)行階段啟動的文件。l 應(yīng)用部署階段是一個準(zhǔn)備階段，主要目的是進行實施策略、實施方法、相關(guān)人員、時間以及試點等方面的總體規(guī)劃和所需資源的準(zhǔn)備。l 試點發(fā)布階段是實施策略和實施方法的測試階段，主要目的是確認實施策略和實施方法的可行性并獲取用于全面部署的經(jīng)驗。在應(yīng)用部署規(guī)劃時，如果確認試點發(fā)布無必要（例如，曾有過類似產(chǎn)品的發(fā)布），則可忽略此階段。l 實施計劃制定階段是應(yīng)用部署的詳細計劃階段，目的是確定具體的應(yīng)用部署活動步驟。如果應(yīng)用部署涉及到多個部門，該階段也包括每個部門的行動計劃。l 特殊需求處理階段包括識別和解決一些部署點的特殊的要求，目的是保證部署活動不會因為這些特殊要求而受到阻礙。l 切換準(zhǔn)備階段是資源落實和最后測試的階段，目的是確認切換所有的條件已就緒。l 切換階段將應(yīng)用投入實際運行的階段，其中也包括切換結(jié)束的總結(jié)（無論成功或失?。?。l 項目結(jié)束。2.3生存期模型裁減生存期模型并不意味著中外運公司的所有IT項目執(zhí)行周期一成不變地覆蓋整個生存期。不同類型的項目在生存期模型上的啟動點和終止點不完全一樣，需要根據(jù)項目的特征選擇項目生存期并根據(jù)具體情況對項目生存期進行剪裁。2.3.1內(nèi)部項目內(nèi)部項目的特征是項目的管理和資源的控制均在ITO內(nèi)部，因此可由ITO的一個項目經(jīng)理負責(zé)整個項目生存期的過程和工作產(chǎn)品。實際上，這就是基本項目生存期的應(yīng)用，具體如下：項目立項（略）項目執(zhí)行：SOW用戶需求獲取系統(tǒng)概念確定系統(tǒng)定義設(shè)計實現(xiàn)驗證應(yīng)用交付項目執(zhí)行階段由一個SOW啟動，項目經(jīng)理根據(jù)該SOW制訂項目初步計劃，計劃可在各個階段里程碑結(jié)束后進行調(diào)整。2.3.2外包項目外包項目的特征是項目的管理和資源的控制均在ITO外部，ITO代表中外運公司向外包公司發(fā)出需求并定義完成條件。ITO項目經(jīng)理的責(zé)任是負責(zé)提供合理的公司業(yè)務(wù)對IT系統(tǒng)的要求并負責(zé)確認項目輸出的有效性，具體如下：驗證項目立項（略）項目執(zhí)行：SOW用戶需求獲取系統(tǒng)概念確定ITO- 標(biāo)書- 合同企業(yè)采購部門系統(tǒng)定義設(shè)計實現(xiàn)應(yīng)用交付外包部門 項目執(zhí)行階段由一個SOW啟動，待完成了初步需求分析并形成了系統(tǒng)概念后，將用戶初步需求和系統(tǒng)概念設(shè)計反應(yīng)到標(biāo)書中來選擇外包商，反應(yīng)到合同中來啟動外包項目。此外，項目生存期中驗證階段回到ITO來執(zhí)行。一般的應(yīng)用交付涉及到用戶的參與，但該階段的管理仍以外包商負責(zé)，或雙方協(xié)調(diào)后共同負責(zé)。如果外包的范圍與上述不同，可對上述剪裁模式進行調(diào)整，關(guān)鍵是合同和驗證兩個控制點。例如僅將設(shè)計部分外包時，標(biāo)書和合同涉及的也將僅僅是設(shè)計階段，驗收也是對設(shè)計的驗收。需要注意的是驗證部分參與的內(nèi)部人員和企業(yè)內(nèi)部用戶與實現(xiàn)部分參與的人員不同。2.3.3合作項目合作項目是ITO與合作方資源統(tǒng)一管理的工作模式。若是以ITO為主，可參照2.3.1節(jié)描述的剪裁模型；如果是以外方為主，則可參照2.3.2節(jié)描述的剪裁模型。2.3.4采購項目外包項目和合作項目本質(zhì)上也是采購項目，是IT服務(wù)的采購。因此IT服務(wù)采購項目的生存期參照上面2.3.2節(jié)和2.3.3節(jié)。本節(jié)描述的是IT設(shè)備（包括軟件）的采購項目，具體如下：項目立項（略）項目執(zhí)行：驗證應(yīng)用交付SOW用戶需求獲取系統(tǒng)概念確定ITO供貨程序- 采購標(biāo)書- 采購合同企業(yè)采購部門 供應(yīng)商同樣，內(nèi)部以SOW啟動來確定設(shè)備采購的需求以及采購原則與策略（系統(tǒng)概念確定）。這些內(nèi)容確定后形成采購標(biāo)書，進而形成采購合同。供應(yīng)商按其自己的供貨程序工作。如果必要，可在他們的供貨程序中插入質(zhì)量檢驗的審核點。2.3.5混合型項目當(dāng)一個IT項目較復(fù)雜時可能包括了自行開發(fā)、合作部分、外包部分以及采購部分。在這種情況下可將項目分解成若干子項目，每個項目參照上面適用的生存期分別進行管理。三、IT項目過程下述模型是個簡化的IT項目執(zhí)行過程模型，該模型包括了最基本的控制環(huán)節(jié)、分解原則和實施過程等要素。項目執(zhí)行過程模型圖示如下：項目立項（略）項目執(zhí)行：項目分解與計劃啟動結(jié)束項目執(zhí)行3.1啟動IT項目在執(zhí)行階段必須有一個正式的啟動文件SOW。正式的含義包括：l 來自于可下達任務(wù)的授權(quán)機構(gòu)l 具有明確的主管人（發(fā)起人）l 指定了項目經(jīng)理l 清晰的任務(wù)陳述（SOW）SOW定義了項目執(zhí)行階段的開始。3.2項目分解與計劃當(dāng)項目經(jīng)理接到任務(wù)書后，假設(shè)對任務(wù)書沒有任何疑義，那么項目經(jīng)理需要執(zhí)行的第一個過程是進行項目計劃，這樣才能保證項目有序的執(zhí)行。由于直接面向任務(wù)書中SOW進行計劃會很難，特別是其中描述的任務(wù)規(guī)模很大時更是如此。一個有效的方法是將項目執(zhí)行分為若干階段，然后按階段進行規(guī)劃。例如將項目執(zhí)行分為如下的三個階段：項目執(zhí)行：SOW實現(xiàn)設(shè)計需求定義當(dāng)然，如果上述階段劃分太粗，還可以進一步細化，例如將“設(shè)計”分為“系統(tǒng)設(shè)計”和“單元設(shè)計”，將實現(xiàn)分為“編碼”、“測試”和“集成”。如果有必要，還可以增加一些階段，如在“需求定義”和“設(shè)計”之間增加一個“技術(shù)選擇”的階段來專門分析采用什么技術(shù)對系統(tǒng)開發(fā)最有效。3.3項目實施項目實施是項目計劃的執(zhí)行。為了能夠知道項目進展是否符合項目計劃，需要對實施過程進行監(jiān)控。監(jiān)控的方法是每隔一個固定的時間對項目狀態(tài)進行一次檢查，然后與計劃進行比較。如發(fā)生了偏離，則進行糾正。僅僅按固定的時間間隔檢查項目狀態(tài)有時也不能及時處理項目的問題，例如在間隔之間發(fā)生了重大影響項目計劃的事件，如一項關(guān)鍵技術(shù)無法應(yīng)用。因此要增加基于事件的檢查。偏離糾正包括兩個方面，一個方面是對項目工程活動和工作產(chǎn)品發(fā)生的偏離進行糾正，另一方面是對計劃進行修訂。這些工作必須加以控制，按嚴格的規(guī)范執(zhí)行，否則不僅僅偏離未能解決，還會引起新的問題。在項目實施過程中，雖然是按項目計劃進行的，但項目計劃僅僅是定義了在什么時間由誰完成什么任務(wù)，沒有規(guī)定如何完成這些任務(wù)。如何完成有兩種方式，一種是憑執(zhí)行者的經(jīng)驗決策，另一種是定義好完成任務(wù)的過程和模板，然后按照過程和模板進行工作。當(dāng)然，這兩種方式會結(jié)合起來。3.4項目結(jié)束項目計劃的所有任務(wù)完成了，項目就可以結(jié)束。項目計劃確定的生存期中定義了項目的結(jié)束階段和結(jié)束應(yīng)該進行的工作。項目結(jié)束不僅僅將項目交付件交給客戶就算完成了，還有一些其它總結(jié)性的工作，如項目數(shù)據(jù)匯集等。項目數(shù)據(jù)可為其它項目執(zhí)行提供依據(jù)和參照。3.5項目過程總結(jié)一個基本的項目管理體系應(yīng)管理項目的啟動、項目劃分和計劃、項目的執(zhí)行管理以及項目的結(jié)束。一個更完善的項目管理體系還應(yīng)包括如何完成工程任務(wù)以及其它任務(wù)的過程。此外，還應(yīng)包括需求開發(fā)和需求管理。四、IT項目計劃項目計劃的目的是為項目的執(zhí)行和管理提供一個合理計劃。項目計劃過程域中的過程包括估計項目規(guī)模、定義項目生存期、確定項目目標(biāo)、制訂人員、時間和投入計劃。項目計劃過程域與IT項目生存期的一個示例關(guān)系如下：用戶需求獲取系統(tǒng)概念確定系統(tǒng)定義設(shè)計實現(xiàn)驗證應(yīng)用交付計劃修訂點計劃修訂點計劃修訂點計劃修訂點計劃修訂點計劃點計劃點 箭頭所指示的是項目計劃在生存期的一個應(yīng)用場景。前兩個階段是由ITO和業(yè)務(wù)部門共同進行初步需求分析和系統(tǒng)概念確定，ITO在項目初始制訂了計劃，并在第一個階段完成后對計劃進行調(diào)整，然后實施第二個階段。第二個階段完成后，交給一個ITO內(nèi)的項目開發(fā)組織，開發(fā)組織在他們承接項目的第一個階段（生存期模型第三個階段）制訂項目計劃，并在每個階段完成后，調(diào)整或修改計劃。計劃的調(diào)整或修訂并不是必需的，只有當(dāng)發(fā)現(xiàn)計劃與實際不符時才進行。項目計劃過程的目的是為執(zhí)行軟件工程活動和管理軟件項目建立一個合理的項目計劃。項目計劃過程涉及的主要方面包括軟件項目規(guī)模評估、計劃責(zé)任的協(xié)商與確立以及軟件項目計劃的制定。項目計劃的目標(biāo)為：l 項目規(guī)模估算并文檔化，以保證在項目規(guī)劃和跟蹤中可用。l 規(guī)劃項目活動和責(zé)任并文檔化。l 項目相關(guān)組和人員同意所分配的責(zé)任。根據(jù)這些目標(biāo)，在ITO項目計劃過程域中定義了三個過程：l 項目規(guī)模估算過程l 項目規(guī)劃過程l 項目責(zé)任分配過程4.1項目規(guī)模估算過程過程名項目規(guī)模估算過程標(biāo)識PP-01目標(biāo)軟件規(guī)模估算并文檔化，以保證在項目規(guī)劃和跟蹤中可用。進入條件SOW（任務(wù)書）下達，并詳細描述了任務(wù)范圍。參與角色1. 項目經(jīng)理(由SOW確定)2. 項目人員(由SOW或項目經(jīng)理確定，包括項目經(jīng)理)3. 相關(guān)評審人員(由項目經(jīng)理確定)4. 項目主管(高層項目主管經(jīng)理，由SOW確定)輸入SOW過程步驟輸出序號描述項目經(jīng)理根據(jù)SOW確定項目工作分解 (WBS: Work Breakdown Structure) 的策略和估算準(zhǔn)則，其中包括估算單位、估算方法、估算爭議處理等。- WBS策略- 估算準(zhǔn)則項目經(jīng)理向項目人員分配項目分解任務(wù)。(如果項目規(guī)模不大，可由項目經(jīng)理本人獨立進行項目分解和任務(wù)規(guī)模估算工作。)項目人員根據(jù)WBS策略和估算準(zhǔn)則對項目進行分解估算，分別建立各自管轄任務(wù)的WBS和相應(yīng)的任務(wù)規(guī)模估算。項目經(jīng)理負責(zé)進行匯總。- 項目任務(wù)分解(WBS)項目經(jīng)理組織有關(guān)人員對WBS進行評審并根據(jù)評審結(jié)果對WBS以及估算進行修訂。評審的目地是保證分解沒有遺漏、重疊等問題；規(guī)模估算有依據(jù)。- 修訂的項目WBS和任務(wù)規(guī)模估算項目主管對WBS和估算結(jié)果進行審核。審核的目的是保證項目范圍理解正確、分解策略正確、估算結(jié)果合理。- 審核通過的項目WBS和任務(wù)規(guī)模估算項目經(jīng)理負責(zé)整理上述步驟的輸出，形成項目規(guī)模估算文件。- 項目規(guī)模估算文件完成標(biāo)志1. 項目WBS和任務(wù)規(guī)模估算通過項目主管審核。2. 形成項目規(guī)模估算文件(過程提交產(chǎn)品)。4.2項目規(guī)劃過程過程名項目規(guī)劃過程過程標(biāo)識PP-02目標(biāo)規(guī)劃項目活動和責(zé)任并文檔化。進入條件項目規(guī)模估算完成。參與角色1. 項目經(jīng)理(由SOW確定)2. 相關(guān)評審人員(由項目經(jīng)理確定)3. 項目主管(高層項目主管經(jīng)理，由SOW確定)輸入1. SOW2. 項目規(guī)模估算文件過程步驟輸出序號描述項目經(jīng)理根據(jù)SOW確定項目具體目標(biāo)和項目交付件。- 項目目標(biāo)描述- 項目交付件清單確定項目策略，其中包括項目組織結(jié)構(gòu)。- 項目組織圖等項目經(jīng)理根據(jù)SOW確定項目生存期模型。- 選擇的生存期模型項目經(jīng)理根據(jù)SOW、項目生存期模型和規(guī)模估算文件確定投入的資源，包括人力資源。- 項目資源投入表項目經(jīng)理根據(jù)SOW、項目生存期模型和規(guī)模估算文件確定項目時間安排。- 項目時間計劃表項目經(jīng)理根據(jù)SOW、項目生存期模型和規(guī)模估算文件確定投入的資金。- 項目資金計劃表項目經(jīng)理對項目可能的風(fēng)險進行分析并對高風(fēng)險給出控制策略。風(fēng)險分析是基于項目目標(biāo)和項目計劃的，即影響項目目標(biāo)和計劃可能發(fā)生的事件。- 項目風(fēng)險控制表項目經(jīng)理基于上面的輸出，產(chǎn)生項目計劃草案。- 項目計劃草案項目主管召集有關(guān)人員對項目計劃進行評審。項目經(jīng)理根據(jù)評審意見對項目計劃進行修訂，形成正式項目計劃文檔，并由項目主管根據(jù)項目確認。- 項目計劃評審報告- 項目正式計劃文檔完成標(biāo)志1. 項目計劃經(jīng)過評審。2. 正式項目計劃文檔產(chǎn)生。4.3項目責(zé)任分配過程過程名項目責(zé)任分配過程過程標(biāo)識PP-03目標(biāo)項目相關(guān)組和人員同意所分配的責(zé)任。進入條件項目正式計劃形成。參與角色1. 項目經(jīng)理(由SOW確定)2. 項目組成員(由項目計劃確定)3. 項目主管(高層項目主管經(jīng)理，由SOW確定)輸入項目計劃過程步驟輸出序號描述項目經(jīng)理根據(jù)項目成員和時間計劃生成每個人的任務(wù)時間計劃并發(fā)放給各個項目成員。- 個人項目任務(wù)時間計劃各個相關(guān)人員確認所分配的責(zé)任，其中包括：l 分配的任務(wù)和時間是合理的。l 可滿足完成任務(wù)所需要的業(yè)務(wù)要求。l 可滿足完成任務(wù)所需要的時間要求。若不能確認上述一項或若干項條件，則將情況反饋給項目經(jīng)理。- 個人項目任務(wù)時間計劃確認結(jié)果項目經(jīng)理根據(jù)反饋情況對計劃進行調(diào)整，并對變化的人員責(zé)任重復(fù)上一步驟。若有影響較大的調(diào)整，如關(guān)鍵人員的調(diào)整需得到項目主管的批準(zhǔn)。若無調(diào)整，則跳過此步驟。- 調(diào)整的項目計劃項目經(jīng)理發(fā)布項目計劃，發(fā)布對象包括：l 項目主管l 項目組成員其他項目相關(guān)組織或人員(如文檔管理部門)完成標(biāo)志1. 計劃經(jīng)過所有項目相關(guān)責(zé)任人員的確認。2. 對無法承擔(dān)項目責(zé)任進行調(diào)整并反映到計劃中。3. 調(diào)整的計劃向所有有關(guān)人員發(fā)布。4.4項目采購計劃采購規(guī)劃是確定哪些項目需求可以通過從項目組織之外采購產(chǎn)品、服務(wù)或成果，從而最好地滿足某些項目需求，是項目團隊在項目實施過程中可以自行滿足的過程。它涉及是否需要采購、如何采購、采購什么、采購多少，以及何時采購等。當(dāng)項目從實施組織之外取得項目履行所需的產(chǎn)品、服務(wù)和成果時，每項產(chǎn)品或者服務(wù)都必須經(jīng)歷從采購規(guī)劃到合同收尾的各個過程。采購規(guī)劃過程包括對每項外購決策涉及的風(fēng)險，及就風(fēng)險緩解或風(fēng)險轉(zhuǎn)移進行審核。中國外運信息化建設(shè)中的IT采購工作分成項目采購和日常采購，日常采購包括但不限于個人電腦及配件的采購。日常采購在每年年底制訂采購計劃，并通過項目采購方式選定合格經(jīng)銷商和購買產(chǎn)品種類，有效期1年。日常采購均從選定的合格經(jīng)銷商中選擇。日常采購由具體采購人在合格經(jīng)銷商中采取兩人（含）以上詢價的方式進行，部門負責(zé)人負責(zé)監(jiān)控是否按流程進行，并抽查報價。主管（副）總經(jīng)理可以確認部門負責(zé)人的簽字，也可以再次抽查。項目采購需成立采購項目組，項目組應(yīng)根據(jù)情況，在符合法律相關(guān)規(guī)定的前提下，以公開招標(biāo)、邀請招標(biāo)或者內(nèi)部議標(biāo)的方式選擇設(shè)備供應(yīng)商。五、IT項目監(jiān)控項目執(zhí)行監(jiān)控的目的是關(guān)注項目進展情況并對發(fā)生的偏差及時進行糾正。項目執(zhí)行監(jiān)控的依據(jù)是項目計劃，凡是計劃了的內(nèi)容，都需要進行監(jiān)控，例如投入和時間安排。項目計劃過程域與IT項目生存期的關(guān)系如下圖所示：用戶需求獲取系統(tǒng)概念確定系統(tǒng)定義設(shè)計實現(xiàn)驗證應(yīng)用交付監(jiān)控點監(jiān)控點監(jiān)控點監(jiān)控點監(jiān)控點監(jiān)控點監(jiān)控點監(jiān)控點監(jiān)控點監(jiān)控點監(jiān)控點監(jiān)控點項目計劃箭頭所示是項目執(zhí)行監(jiān)控的一個應(yīng)用場景。一般項目監(jiān)控采用定期評審，例如按周的定期評審。在每次定期評審中，檢查項目是否偏離了計劃。若發(fā)生了偏離，則立即采取糾正措施。此外，項目執(zhí)行監(jiān)控也可能是事件驅(qū)動的，一旦在定期評審之間發(fā)生了重要的項目管理事件，如發(fā)生了某種風(fēng)險，則進行基于事件的評審，并根據(jù)評審結(jié)果采取相應(yīng)措施。每次評審的內(nèi)容和結(jié)果要向所有相關(guān)人員通報，相關(guān)人員包括項目人員、用戶和企業(yè)相關(guān)主管。通報通常采用定期項目簡報的形式。項目監(jiān)控過程的目標(biāo)為：l 按照計劃跟蹤項目的實際結(jié)果和執(zhí)行性能。l 當(dāng)實際結(jié)果和執(zhí)行性能偏離計劃時，要采取糾正措施并對其進行管理。l 保證相關(guān)人員和組織同意所改變的責(zé)任。根據(jù)上述目標(biāo)，項目監(jiān)控過程域包括四個過程：l 項目定期評審過程l 基于事件的評審過程l 偏離糾正過程l 計劃修訂過程項目評審過程分為定期評審和基于事件評審。定期評審是正常的周期性評審，基于事件的評審是當(dāng)發(fā)生了嚴重影響項目進展事件時進行的評審?；谑录脑u審由項目經(jīng)理根據(jù)具體情況決定。偏離糾正過程用于控制管理項目進程中發(fā)現(xiàn)的問題和問題的處理。計劃修改過程用于控制和實施計劃的變更，保證變更后的計劃仍然具有合理性。5.1項目定期評審過程過程名項目定期評審過程過程標(biāo)識OM-01目標(biāo)按照計劃跟蹤項目的實際結(jié)果和執(zhí)行性能。進入條件到達項目評審時間參與角色1. 項目經(jīng)理(由SOW確定)2. 項目組成員(由項目計劃確定)輸入項目計劃過程步驟輸出序號描述項目經(jīng)理根據(jù)項目計劃本階段要求完成的內(nèi)容，收集各個項目成員的任務(wù)完成狀態(tài)。- 項目進展?fàn)顟B(tài)項目經(jīng)理將各個項目成員任務(wù)完成的狀態(tài)與計劃進行比較。若項目經(jīng)理認為出現(xiàn)與計劃的重要偏離，則與相關(guān)項目人員分析偏離原因，提出糾正措施，糾正措施包括對偏離的糾正或?qū)τ媱澋男薷?。對不是重要的偏離，則不提出糾正措施，而是列入到下次評審關(guān)注對象。偏離程度的判斷由項目經(jīng)理負責(zé)。- 偏離糾正措施項目經(jīng)理審查以前定期評審確定關(guān)注的偏離問題(如存在的話)，并確定是否采取偏離糾正措施。- 偏離糾正措施(若存在需糾正的偏離)項目經(jīng)理審查目前階段正在執(zhí)行的偏離糾正措施，若發(fā)現(xiàn)問題則給出問題解決建議。- 偏離糾正措施執(zhí)行建議項目經(jīng)理將上述評審結(jié)果形成項目定期評審報告，并發(fā)布給相關(guān)人員，發(fā)放范圍依據(jù)項目計劃。- 項目定期評審報告完成標(biāo)志1. 項目計劃本階段內(nèi)所有要求的完成內(nèi)容與實際完成狀態(tài)進行了比較。2. 對需要糾正的偏離，向相關(guān)項目人員發(fā)出了糾正措施或糾正措施執(zhí)行建議。3. 項目定期評審報告完成并向相關(guān)人員發(fā)布。5.2項目事件評審過程過程名項目事件評審過程過程標(biāo)識OM-02目標(biāo)按照計劃跟蹤項目的實際結(jié)果和執(zhí)行性能。進入條件項目經(jīng)理得到項目成員的事件報告并決定進行評審。參與角色1. 項目經(jīng)理(由SOW確定)2. 項目組相關(guān)成員(事件報告者和其他相關(guān)人員)輸入1. 事件報告2. 項目計劃過程步驟輸出序號描述項目經(jīng)理與相關(guān)人員分析事件對計劃的影響，其中包括：l 計劃進度的影響l 計劃成本的影響l 計劃資源的影響l 質(zhì)量的影響等- 事件影響分析項目經(jīng)理與相關(guān)人員確定事件處理措施，處理措施包括事件的解決、計劃的調(diào)整等方面。- 事件處理措施項目經(jīng)理落實事件處理的資源保證，如人力的保證。項目經(jīng)理將上述評審結(jié)果形成項目事件評審報告，并發(fā)布給相關(guān)人員，發(fā)放范圍包括評審會人員、主管人員以及其他相關(guān)人員。- 項目事件評審報告完成標(biāo)志1. 確定了項目事件處理措施并落實了相關(guān)事件處理的資源。2. 項目事件評審報告完成并向相關(guān)人員發(fā)布。5.3偏離糾正過程過程名計劃偏離糾正過程過程標(biāo)識OM-03目標(biāo)當(dāng)實際結(jié)果和執(zhí)行性能偏離計劃時，要采取糾正措施并對其進行管理。進入條件1. 項目定期評審會發(fā)出偏離糾正措施，或2. 項目事件評審會發(fā)出事件處理措施參與角色1. 偏離糾正人員，或2. 事件處理人員、3. 項目經(jīng)理輸入1. 偏離糾正措施，或2. 事件處理措施過程步驟輸出序號描述偏離糾正人員/事件處理人員根據(jù)偏離糾正措施/事件處理措施制訂糾正/處理步驟。- 偏離糾正/事件處理步驟偏離糾正人員/事件處理人員執(zhí)行制訂的偏離糾正/事件處理步驟，直至結(jié)束。- 偏離糾正/事件處理結(jié)果項目經(jīng)理審核偏離糾正/事件處理結(jié)果，若存在問題，則確定相應(yīng)措施，再重復(fù)1-2兩個步驟。偏離糾正人員/事件處理人員將偏離糾正/事件處理結(jié)果形成報告。- 偏離糾正/事件處理結(jié)果報告項目經(jīng)理審核偏離糾正/事件處理結(jié)果報告，并發(fā)布給有關(guān)人員。完成標(biāo)志1. 項目經(jīng)理審核通過偏離糾正/事件處理結(jié)果。2. 偏離糾正/事件處理結(jié)果報告完成并向相關(guān)人員發(fā)布。5.4計劃修訂過程過程名計劃修訂過程過程標(biāo)識OM-04目標(biāo)1. 當(dāng)實際結(jié)果和執(zhí)行性能偏離計劃時，要采取糾正措施并對其進行管理。2. 保證相關(guān)人員和組織同意所改變的責(zé)任。進入條件1. 項目定期評審會發(fā)出偏離糾正措施，該措施包括計劃的修訂，或2. 項目事件評審會發(fā)出事件處理措施，該措施包括計劃的修訂。參與角色1. 項目經(jīng)理2. 項目主管輸入1. 偏離糾正措施，或2. 事件處理措施過程步驟輸出序號描述項目經(jīng)理根據(jù)偏離糾正措施/事件處理措施確定計劃修訂的范圍和內(nèi)容。- 計劃修訂范圍和內(nèi)容項目經(jīng)理根據(jù)確定的修訂范圍和內(nèi)容修訂計劃。- 修訂的計劃若修訂的計劃涉及到人員責(zé)任的變化，則項目經(jīng)理與相關(guān)人員確認變化的責(zé)任是否可接受。若不可接受，則需進一步調(diào)整。- 修訂的計劃項目主管審核修訂的計劃，若存在問題確定重新修訂的范圍和內(nèi)容，再次執(zhí)行步驟2-3。- 重新修訂的范圍和內(nèi)容，或- 審核通過的計劃項目經(jīng)理發(fā)布經(jīng)項目主管的審核計劃，發(fā)布范圍同原計劃發(fā)布的范圍。完成標(biāo)志1. 項目主管審核通過修訂的計劃。2. 審核通過的修訂計劃向相關(guān)人員發(fā)布。5.5項目采購監(jiān)控在進行項目采購的決策過程中，應(yīng)考慮項目預(yù)算等制約因素。實施組織的長遠戰(zhàn)略也是在采購監(jiān)控中應(yīng)考慮的內(nèi)容。如果決定外購，則反映了實施組織的長遠規(guī)劃和項目的當(dāng)前需要。例如，決定購置某種開發(fā)平臺或數(shù)據(jù)庫，不是臨時使用，而是希望獲得長期支持。從項目經(jīng)濟效益上看可能合算，也可能不合算。但是如果實施組織需要長期使用該開發(fā)平臺或數(shù)據(jù)庫，則分攤到項目上的那部分購置費用就有可能低于臨時使用的費用。在進行項目采購時，應(yīng)成立采購項目組，并對項目采購的過程進行監(jiān)控。采購項目組包括業(yè)務(wù)部門和信息管理部的主管領(lǐng)導(dǎo)及相關(guān)負責(zé)人員和經(jīng)辦人員，必要時請企劃部、財務(wù)部等部門參加。根據(jù)中國外運股份有限公司投資管理規(guī)定，超過三百萬的項目采購，還要上報股份公司，經(jīng)批準(zhǔn)后方可執(zhí)行。項目采購流程如下：1. 起草立項報告項目組根據(jù)項目需求描述決定何時采購何物，制定相應(yīng)的采購計劃并起草立項報告，通過內(nèi)請流程上報公司審批。審批通過后，成立IT采購項目組，并確定項目組成員。2. 確定采購方式經(jīng)IT采購項目組討論通過后，決定采購方式，主要包括三種方式：公開招標(biāo)、邀請招標(biāo)、詢價采購。3. 供應(yīng)商的選擇和詢報價IT采購項目組應(yīng)根據(jù)備選供方的報價單進行評定，即進行供應(yīng)商的選擇。4. 確定供應(yīng)商和價格IT采購項目組經(jīng)過討論，最終確定供應(yīng)商和采購產(chǎn)品的價格。5. 簽訂合同IT采購項目組和產(chǎn)品供應(yīng)商談判后簽署采購合同。6. 合同執(zhí)行產(chǎn)品供應(yīng)商按合同規(guī)定履約，IT采購項目組成員負責(zé)產(chǎn)品驗收。7. 價款結(jié)算IT采購項目組負責(zé)辦理和產(chǎn)品供應(yīng)商的價款結(jié)算。8. 填寫IT采購申請/處理單IT采購項目組負責(zé)填寫IT采購申請/處理單。六、IT項目審核IT項目審核過程是一種正式的評審，需要較高的資源投入，因此并不意味著所有IT項目交付件都要進行正式的審核。審核對象的確定由項目經(jīng)理在項目計劃時根據(jù)質(zhì)量風(fēng)險來確定。IT項目審核包括三個部分：審核計劃、審核執(zhí)行、審核問題糾正，這三個部分描述如下：審核計劃審核計劃是基于項目計劃確定的審核對象和標(biāo)準(zhǔn)的審核過程來定義審核目標(biāo)、資源計劃和時間計劃。在項目計劃中，需要確定審核對象和相應(yīng)的審核主持人，與此同時在計劃中分配審核主持人審核計劃和審核執(zhí)行任務(wù)。在一個項目中不同階段會對不同的交付件進行審核，這些審核的主持人可以是不同的。一個主要的原則是審核主持人不能是交付件的責(zé)任人。審核執(zhí)行審核執(zhí)行包括審核準(zhǔn)備、召開審核會和建立審核記錄。審核準(zhǔn)備包括審核對象資料準(zhǔn)備、審核人員熟悉所負責(zé)的審核內(nèi)容。審核會一般不超過兩個小時，否則效率會大大降低。審核會的目的是審核交付件是否滿足相應(yīng)的準(zhǔn)則，而不是審核人的能力和具體采用的開發(fā)方法、技術(shù)的正確與否。審核記錄要記錄審核過程發(fā)現(xiàn)的缺陷，缺陷屬性，例如嚴重程度、來源（本階段產(chǎn)生的，還是前面階段遺留下來的）等。審核問題糾正審核問題糾正是解決審核中發(fā)現(xiàn)的缺陷。審核問題的糾正要加以跟蹤，直到全面完成。6.1審核計劃過程過程名審核計劃過程過程標(biāo)識PR-01目標(biāo)對審核活動進行計劃。進入條件到達項目計劃的審核計劃時間。參與角色1. 審核主持人(由項目經(jīng)理在計劃中指定)2. 審核人3. 交付件開發(fā)責(zé)任人輸入1. 審核對象定義(根據(jù)項目計劃)2. 審核過程過程步驟輸出序號描述1審核主持人根據(jù)審核對象定義確定審核目標(biāo)。- 審核目標(biāo)2審核人與交付件開發(fā)責(zé)任人討論確認審核目標(biāo)。- 交付件開發(fā)責(zé)任人確認的審核目標(biāo)3審核主持人根據(jù)審核對象和審核目標(biāo)確定主審人和審核人以及它們的責(zé)任，并得到這些人員參加審核的確認和對審核目標(biāo)的確認。- 審核人名單- 確認的審核目標(biāo)4審核主持人與交付件開發(fā)責(zé)任人確認審核材料提交的時間和發(fā)放的對象。- 審核材料提交時間、清單和發(fā)放對象5審核主持人確定審核時間和地點并得到審核人員和交付件開發(fā)責(zé)任人的確認。- 審核時間6審核主持人形成書面審核計劃并送達交付件開發(fā)責(zé)任人、所有審核人員和項目經(jīng)理。- 審核計劃完成標(biāo)志審核計劃送達所有相關(guān)人員。6.2審核執(zhí)行過程過程名審核過程執(zhí)行過程過程標(biāo)識PR-02目標(biāo)按照計劃執(zhí)行審核。進入條件1. 到達審核計劃確定的審核任務(wù)時間2. 審核對象材料發(fā)放參與角色1. 審核主持人(由項目計劃確定)2. 審核人員(由審核計劃確定，包括主審人)3. 交付件開發(fā)責(zé)任人輸入1. 審核計劃2. 審核對象材料過程步驟輸出序號描述1所有審核人通過審核對象材料了解與其責(zé)任相關(guān)的審核內(nèi)容。審核主持人對此進行確認。無2審核主持人按計劃召集審核會。無3主審人報告全面審核的結(jié)果。- 主審人審核結(jié)果4各個審核人報告各自責(zé)任范圍內(nèi)的審核的結(jié)果。- 審核人審核結(jié)果5審核人討論交付件可能的缺陷。- 候選缺陷6交付件開發(fā)責(zé)任人對審核人提出的問題應(yīng)答。無7審核人確認交付件的缺陷和缺陷屬性，其中包括嚴重程度(高、中、低)和來源(本階段產(chǎn)生，前面階段遺留)。- 缺陷清單8審核主持人形成審核報告，并得到與會人員的認可。- 審核報告確認的缺陷清單作為該報告的附件。10審核主持人向項目經(jīng)理、質(zhì)量保證經(jīng)理、配置管理經(jīng)理和與會人員提交審核報告。- 無完成標(biāo)志審核報告完成并向相關(guān)人員發(fā)布。七、IT項目需求開發(fā)與管理7.1需求開發(fā)的步驟系統(tǒng)需求是通過一系列步驟逐步轉(zhuǎn)化得到的。這些步驟可能執(zhí)行一次，就可得到開發(fā)人員所要的系統(tǒng)規(guī)格定義，但更多的是重復(fù)地執(zhí)行多次來確定系統(tǒng)規(guī)格定義。需求開發(fā)的基本步驟如下：l 確定項目范圍l 獲取客戶需求l 分析客戶需求l 制訂系統(tǒng)規(guī)格l 驗證系統(tǒng)規(guī)格l 系統(tǒng)規(guī)格受控確定項目范圍項目范圍本身往往在項目開始時也不是很容易確定?？蛻羰且粋€群體，不同層面的人員因處于不同的地位會對項目含義有不同的認識。有時在同一范圍概念下，也會有不同內(nèi)容的理解。這個階段的目的是建立一個統(tǒng)一的項目視圖并在這個視圖的基礎(chǔ)上對項目范圍取得共同的認識。項目視圖需要采用客戶容易理解的圖示來表達，例如系統(tǒng)環(huán)境關(guān)聯(lián)圖，系統(tǒng)功能層次圖、系統(tǒng)在業(yè)務(wù)價值鏈中的位置等。利用這些圖示來進一步刻畫和描述系統(tǒng)范圍要素，如支持的用戶類別、系統(tǒng)特征、基于的環(huán)境和支持目標(biāo)等。項目范圍實質(zhì)上是客戶需求的一個部分并且是一個重要的部分。項目范圍為項目任務(wù)圈定了一個問題考慮范圍。隨著需求分析的進展，項目范圍會發(fā)生變化，這些變化應(yīng)及時反映到相關(guān)的文檔中，并及時知會相關(guān)的人員。獲取客戶需求項目范圍定義是項目宏觀的需求析取，為了能夠真正開發(fā)一個應(yīng)用系統(tǒng)，必須全面了解客戶對系統(tǒng)的要求。由于客戶不是系統(tǒng)分析人員，因此這個階段的目的是確定有效的方法，然后利用所確定的方法從相對分散的需求源，系統(tǒng)化地獲取客戶需求。獲取客戶需求方法的基本原則是系統(tǒng)地定義需求類別、建立統(tǒng)一的需求表達、識別和規(guī)劃需求獲取的渠道。系統(tǒng)地建立需求類別可以將一個大的問題分解為若干小的問題，同時可幫助客戶需求獲取人員完備地收集客戶需求。建立統(tǒng)一的客戶需求表達可一致化和規(guī)范化得到的需求，為后面的工作提供一個良好的基礎(chǔ)。識別和規(guī)劃需求渠道可有效地配備資源。需求獲取渠道不僅僅是按確定用戶類別的訪談，也包括業(yè)務(wù)資料的分析等其它方面。分析客戶需求獲取的客戶需求難以直接轉(zhuǎn)化為系統(tǒng)規(guī)格定義，因為這些需求往往是概要性的、一般情況下不會完備、相互之間可能存在不一致。因此這個階段的目的是對獲取的需求系統(tǒng)地加以分析，建立一個相對完整的系統(tǒng)概念模型，如系統(tǒng)交互模型。通過系統(tǒng)概念模型的建立來細化、補充需求、消除需求中的不一致性。這個階段會繼續(xù)執(zhí)行上個階段的工作，以解決已經(jīng)獲取需求中的問題并補充分析客戶需求所需要的進一步信息。這個繼續(xù)工作不是簡單的重復(fù)需求獲取的工作，而是針對客戶需求分析中發(fā)現(xiàn)的問題?？蛻粜枨蠓治黾夹g(shù)包括許多類型，如非常形式化的建模計劃和簡單的業(yè)務(wù)場景分析技術(shù)。具體技術(shù)的采用取決于客戶需求的復(fù)雜程度、客戶的背景以及分析人員對技術(shù)的掌握等諸多因素。此外，分析技術(shù)的采用也取決于是否有有效的工具支持，特別是基于圖形的分析技術(shù)。制訂系統(tǒng)規(guī)格系統(tǒng)分析人員必須給系統(tǒng)設(shè)計人員提供完整、清晰、明確的系統(tǒng)設(shè)計要求。因此這個階段的目的是基于客戶需求和對客戶需求的分析結(jié)果建立書面的系統(tǒng)規(guī)格定義。這個規(guī)格定義不僅僅作為設(shè)計人員的設(shè)計依據(jù)，也將作為系統(tǒng)驗證的依據(jù)。同客戶需求分析一樣，系統(tǒng)規(guī)格定義也包括許多類型的方法和技術(shù)，如形式化的定義方法和自然語言的描述。一個理想的情況是分析模型和定義模型采用相同的技術(shù)。這樣不僅僅可以平滑地聯(lián)結(jié)分析客戶需求和制訂系統(tǒng)規(guī)格這兩個階段，同時也可大大提高工作效率，因為分析模型的結(jié)果可被重用到規(guī)格定義中。同樣，具體技術(shù)的采用也與客戶需求階段相同。驗證系統(tǒng)規(guī)格系統(tǒng)規(guī)格定義一旦確定，將作為開發(fā)依據(jù)貫穿在整個項目開發(fā)活動中。因此如果規(guī)格定義存在缺陷，將會產(chǎn)生很高代價的質(zhì)量成本。此外，系統(tǒng)規(guī)格是通過客戶需求的分析和轉(zhuǎn)換產(chǎn)生的，因此這個分析和轉(zhuǎn)換可能會存在偏差。這個階段的目的就是來驗證是否定義的系統(tǒng)能夠真正滿足客戶的需求。系統(tǒng)規(guī)格驗證包括用戶評審、內(nèi)部評審、走察（Walk-through）或更為嚴格的同行審核（Peer Review, Inspection）。如果需要讓客戶對系統(tǒng)實現(xiàn)后的式樣有充分地了解，還可以建立系統(tǒng)原型（Prototype）供客戶評審。系統(tǒng)驗證技術(shù)和方法的采用是風(fēng)險和成本的平衡。例如原型技術(shù)會很大程度降低實現(xiàn)的系統(tǒng)背離用戶需求的風(fēng)險，但需要較高的投入。不過由于系統(tǒng)規(guī)格是保證系統(tǒng)成功的關(guān)鍵，因此采用多種驗證形式其中包括較嚴格的驗證形式是十分必要的。系統(tǒng)規(guī)格受控正如上面多次指出的，系統(tǒng)規(guī)格將在整個項目生存期中作為系統(tǒng)實現(xiàn)的依據(jù)，其中包括設(shè)計的依據(jù)、系統(tǒng)測試的依據(jù)、驗收的依據(jù)等。因此如果系統(tǒng)規(guī)格隨意變更，則會引起整個開發(fā)的混亂。這個階段的目的是將系統(tǒng)規(guī)格納入到一種受控的狀態(tài)下。系統(tǒng)規(guī)格的受控包括兩個環(huán)節(jié)，一個環(huán)節(jié)是批準(zhǔn)，另一個環(huán)節(jié)是“凍結(jié)”。當(dāng)系統(tǒng)規(guī)格經(jīng)過完整的開發(fā)過程產(chǎn)生出來后并由各方審計無誤后，則由項目權(quán)威機構(gòu)正式批準(zhǔn)。第二個環(huán)節(jié)是將批準(zhǔn)的系統(tǒng)規(guī)格“凍結(jié)”，即不能隨意地對其更改。這之后的任何更改要通過嚴格變更控制程序。這兩個環(huán)節(jié)是將系統(tǒng)規(guī)格“基線化”?；€化是配置管理的任務(wù)。實際上，系統(tǒng)規(guī)格受控通常都是配置管理中的一個環(huán)節(jié)。7.2需求管理的步驟需求管理的目的是保證系統(tǒng)需求作為基線加以管理，即系統(tǒng)需求定義的建立、使用和修改均加以控制，以保證系統(tǒng)需求可用性和其它項目活動與系統(tǒng)需求的一致性。需求管理與配置管理密切相關(guān)。實際上，需求是作為配置項納入到配置管理中的。需求管理的基本步驟如下：l 建立系統(tǒng)需求基線l 發(fā)布系統(tǒng)需求基線l 系統(tǒng)需求基線跟蹤報告l 處理系統(tǒng)需求基線修改請求建立系統(tǒng)需求基線建立系統(tǒng)需求基線是將開發(fā)的系統(tǒng)需求置為基線狀態(tài)。如果實施了正式的需求管理和配置管理，可將系統(tǒng)規(guī)格納入到需求管理和配置管理中。例如，一個具體的做法可以是將開發(fā)完成的系統(tǒng)規(guī)格提交給配置管理，由配置管理員對規(guī)格進行配置標(biāo)識，然后入配置管理庫。發(fā)布系統(tǒng)需求基線由于系統(tǒng)需求基線是整個項目生存期項目活動的依據(jù)，因此應(yīng)將正式建立的基線及時加以發(fā)布，以確保所有相關(guān)的人員了解基線的狀態(tài)。特別當(dāng)基線修改后基線的及時發(fā)布對正在進行的項目活動至關(guān)重要。系統(tǒng)需求基線跟蹤報告為了保證系統(tǒng)需求基線被有效的實現(xiàn)，需要對需求基線的實施進行跟蹤，并將跟蹤的結(jié)果進行報告。例如跟蹤系統(tǒng)設(shè)計是否覆蓋了所有的需求基線。處理系統(tǒng)需求基線修改請求這是需求基線管理的最核心也是最復(fù)雜的一個步驟。這個步驟包括了一系列子步驟如下：l 對需要更新的基線部分提出更改請求。l 分析、審核更改請求，其中包括確認更改理由的充要性、分析更改的波及范圍、估算更改的投入等方面。l 如果同意更改，則制訂更改計劃。l 實施更改計劃。l 審核更改結(jié)果。l 批準(zhǔn)更改。l 更新需求基線。由于需求基線修改涉及到多方面人員，因此對需求基線的修改（也包括對其它基線的修改）的批準(zhǔn)要征得相關(guān)人員的同意。一般在配置管理體系下，由相關(guān)人員代表成立一個配置管理委員會來處理基線管理事項。八、IT項目工作產(chǎn)品及驗收IT項目工作產(chǎn)品是IT項目過程的輸出。這些輸出包括兩類，一類是通過開發(fā)產(chǎn)生的交付件，這些交付件是軟件產(chǎn)品的一部分，有些會最終提供給客戶使用，有些僅僅是中間產(chǎn)品（如系統(tǒng)設(shè)計）或管理文件（如項目計劃）。另一類是記錄性質(zhì)的文件，這些文件往