IT項(xiàng)目管理辦法_第1頁
IT項(xiàng)目管理辦法_第2頁
IT項(xiàng)目管理辦法_第3頁
IT項(xiàng)目管理辦法_第4頁
IT項(xiàng)目管理辦法_第5頁
已閱讀5頁,還剩43頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

IT工程管理方法信息管理部2024.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工程實(shí)施 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)品及驗(yà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工程驗(yàn)收 408.4.1可交付物驗(yàn)收 408.4.2技術(shù)驗(yàn)收 408.4.3功能驗(yàn)收 418.4.4驗(yàn)收方案 41九、工程經(jīng)理的職責(zé)和素質(zhì) 429.1工程經(jīng)理的職責(zé) 429.2工程經(jīng)理的素質(zhì) 459.3工程經(jīng)理的技能 47前言中外運(yùn)對IT的投資是通過各種類型的IT工程來實(shí)現(xiàn)的,通過實(shí)施IT工程表達(dá)對IT投資的效果,因此有必要對IT工程制定相關(guān)的流程和標(biāo)準(zhǔn)。IT工程分為兩個階段:立項(xiàng)階段和工程執(zhí)行階段。本文只涉及工程執(zhí)行階段的管理方法,工程立項(xiàng)階段的流程按照?IT工程立項(xiàng)流程?執(zhí)行。本管理方法的適用范圍為股份公司總部。中外運(yùn)股份有限公司信息化組織〔以下簡稱ITO〕是中外運(yùn)股份有限公司專門致力于信息化建設(shè)的組織,負(fù)責(zé)企業(yè)信息系統(tǒng)應(yīng)用的支持、業(yè)務(wù)信息化的幫助以及基于信息技術(shù)的業(yè)務(wù)開拓。這些責(zé)任將使得ITO逐漸成為企業(yè)核心競爭力的一個組成局部,與此同時,也要求ITO持續(xù)地改善其IT工程管理和運(yùn)行能力。為了將這些工程管理過程得到有效的落實(shí),特制訂以下IT工程管理方法。ITO組織內(nèi)所有人員需嚴(yán)格執(zhí)行,保證ITO內(nèi)的工程管理和系統(tǒng)運(yùn)行逐漸提高到業(yè)界較高水準(zhǔn),滿足企業(yè)業(yè)務(wù)高速開展的需要。一、術(shù)語定義工程:在規(guī)定的時間和預(yù)算內(nèi)完成的某種具有特定質(zhì)量性能要求的一次性、多任務(wù)的工作。工程的特征:目標(biāo)確定性時限性一次性獨(dú)特性工程生存期:一個工程從立項(xiàng)到工程執(zhí)行結(jié)束的過程。工程生存期模型:是對工程生存期的抽象,其中包括工程階段的劃分、各個階段的進(jìn)入條件、輸入和輸出等生存期公共屬性。關(guān)鍵過程域:是工程管理和工程執(zhí)行所要關(guān)注的重要過程域,包括工程管理、工程實(shí)施、工程支持等多方面的過程。這些過程域是根據(jù)業(yè)務(wù)需要和資源情況逐步開發(fā)定義的。驗(yàn)證:是對系統(tǒng)的評價過程,以確定一個工程執(zhí)行階段的產(chǎn)品是否滿足在此階段開始時所給定的條件。確認(rèn):是在工程執(zhí)行過程中或工程結(jié)束時評價系統(tǒng),以確定它是否滿足特定的需求。審核:是用于驗(yàn)證或確認(rèn)的手段。審核是一種正式的評審活動,即需要方案并按方案執(zhí)行??蛻粜枨蟆睠ustomer’sneeds〕:是客戶的需要與期待,這些要求和期待直接相關(guān)于用戶的業(yè)務(wù)過程和業(yè)務(wù)任務(wù)需求。系統(tǒng)需求〔RequirementsforSystem〕:通過對客戶需求的分析,確定系統(tǒng)應(yīng)實(shí)現(xiàn)的規(guī)格。這些規(guī)格描述了系統(tǒng)的行為、特性和屬性。系統(tǒng)需求也稱為系統(tǒng)規(guī)格。功能性需求〔FunctionalRequirements〕:支持業(yè)務(wù)功能的系統(tǒng)需求,如數(shù)據(jù)檢索、交易執(zhí)行、報告打印等。非功能性需求〔Non-functionalRequirements〕:系統(tǒng)執(zhí)行的行為特征,如可靠性、平安性、性能指標(biāo)等。IT〔InformationTechnology〕:信息技術(shù)。ITO〔InformationTechnologyOrganization〕:信息技術(shù)組織。SOW〔StatementOfWork〕:任務(wù)書。PP〔ProjectPlanning〕:工程方案。PR〔PeerReview〕:同行評審或?qū)Φ仍u審。二、IT工程生存期2.1應(yīng)用開發(fā)工程生存期應(yīng)用開發(fā)工程生存期是中外運(yùn)ITO管轄的所有IT開發(fā)工程的生存期模型,該模型可通過剪裁應(yīng)用到不同類型的開發(fā)中。應(yīng)用開發(fā)工程生存期模型定義圖示如下:工程立項(xiàng)〔略〕工程執(zhí)行:用戶需求獲取用戶需求獲取SOW系統(tǒng)概念確定系統(tǒng)定義設(shè)計實(shí)現(xiàn)驗(yàn)證定義過程實(shí)施過程工程立項(xiàng)結(jié)束,進(jìn)入工程執(zhí)行階段。SOW是工程執(zhí)行階段啟動的文件。用戶需求獲取階段是析取用戶對IT系統(tǒng)的需要〔Needs〕,其中包括系統(tǒng)目的、范圍、目標(biāo)、業(yè)務(wù)需求、限制條件等方面。系統(tǒng)概念確定階段的目的是提出如何滿足用戶需要的總體策略,即確定滿足需求的系統(tǒng)根本實(shí)現(xiàn)模式,如體系、架構(gòu)、獲取〔Acquisition〕方式等內(nèi)容。系統(tǒng)定義階段是對用戶的需求進(jìn)一步進(jìn)行開發(fā)以得到系統(tǒng)實(shí)現(xiàn)的規(guī)格定義〔Specification〕。設(shè)計階段包括了系統(tǒng)層面的設(shè)計〔高層設(shè)計〕和實(shí)現(xiàn)層面的設(shè)計〔詳細(xì)設(shè)計〕。實(shí)現(xiàn)階段包括了具體開發(fā)、集成、工程測試。驗(yàn)證階段是基于用戶的角度對系統(tǒng)的功能進(jìn)行接收/驗(yàn)證測試。工程結(jié)束。2.2應(yīng)用部署工程生存期應(yīng)用部署工程生存期的執(zhí)行階段是將經(jīng)過驗(yàn)證的應(yīng)用系統(tǒng)部署到相關(guān)業(yè)務(wù)部門中并投入使用的過程。由于中外運(yùn)規(guī)模較大,且地域分布很廣,一個大型IT應(yīng)用的部署會涉及到多個部門、多個場所和不同的內(nèi)部和外包資源,因此應(yīng)用部署往往會作為一個獨(dú)立的工程進(jìn)行。應(yīng)用部署工程生存期模型就是用于此目的而建立的,該模型圖示如下:工程立項(xiàng)〔略〕工程執(zhí)行:應(yīng)用部署規(guī)劃應(yīng)用部署規(guī)劃SOW試點(diǎn)發(fā)布實(shí)施方案制定特殊需求處理切換準(zhǔn)備切換工程立項(xiàng)結(jié)束,進(jìn)入工程執(zhí)行階段。SOW是工程執(zhí)行階段啟動的文件。應(yīng)用部署階段是一個準(zhǔn)備階段,主要目的是進(jìn)行實(shí)施策略、實(shí)施方法、相關(guān)人員、時間以及試點(diǎn)等方面的總體規(guī)劃和所需資源的準(zhǔn)備。試點(diǎn)發(fā)布階段是實(shí)施策略和實(shí)施方法的測試階段,主要目的是確認(rèn)實(shí)施策略和實(shí)施方法的可行性并獲取用于全面部署的經(jīng)驗(yàn)。在應(yīng)用部署規(guī)劃時,如果確認(rèn)試點(diǎn)發(fā)布無必要〔例如,曾有過類似產(chǎn)品的發(fā)布〕,那么可忽略此階段。實(shí)施方案制定階段是應(yīng)用部署的詳細(xì)方案階段,目的是確定具體的應(yīng)用部署活動步驟。如果應(yīng)用部署涉及到多個部門,該階段也包括每個部門的行動方案。特殊需求處理階段包括識別和解決一些部署點(diǎn)的特殊的要求,目的是保證部署活動不會因?yàn)檫@些特殊要求而受到阻礙。切換準(zhǔn)備階段是資源落實(shí)和最后測試的階段,目的是確認(rèn)切換所有的條件已就緒。切換階段將應(yīng)用投入實(shí)際運(yùn)行的階段,其中也包括切換結(jié)束的總結(jié)〔無論成功或失敗〕。工程結(jié)束。2.3生存期模型裁減生存期模型并不意味著中外運(yùn)公司的所有IT工程執(zhí)行周期一成不變地覆蓋整個生存期。不同類型的工程在生存期模型上的啟動點(diǎn)和終止點(diǎn)不完全一樣,需要根據(jù)工程的特征選擇工程生存期并根據(jù)具體情況對工程生存期進(jìn)行剪裁。2.3.1內(nèi)部工程內(nèi)部工程的特征是工程的管理和資源的控制均在ITO內(nèi)部,因此可由ITO的一個工程經(jīng)理負(fù)責(zé)整個工程生存期的過程和工作產(chǎn)品。實(shí)際上,這就是根本工程生存期的應(yīng)用,具體如下:工程立項(xiàng)〔略〕工程執(zhí)行:SOWSOW用戶需求獲取系統(tǒng)概念確定系統(tǒng)定義設(shè)計實(shí)現(xiàn)驗(yàn)證應(yīng)用交付工程執(zhí)行階段由一個SOW啟動,工程經(jīng)理根據(jù)該SOW制訂工程初步方案,方案可在各個階段里程碑結(jié)束后進(jìn)行調(diào)整。2.3.2外包工程外包工程的特征是工程的管理和資源的控制均在ITO外部,ITO代表中外運(yùn)公司向外包公司發(fā)出需求并定義完成條件。ITO工程經(jīng)理的責(zé)任是負(fù)責(zé)提供合理的公司業(yè)務(wù)對IT系統(tǒng)的要求并負(fù)責(zé)確認(rèn)工程輸出的有效性,具體如下:驗(yàn)證工程立項(xiàng)〔略〕工程執(zhí)行:SOWSOW用戶需求獲取系統(tǒng)概念確定ITO-標(biāo)書-標(biāo)書-合同企業(yè)采購部門系統(tǒng)定義設(shè)計實(shí)現(xiàn)應(yīng)用交付外包部門工程執(zhí)行階段由一個SOW啟動,待完成了初步需求分析并形成了系統(tǒng)概念后,將用戶初步需求和系統(tǒng)概念設(shè)計反響到標(biāo)書中來選擇外包商,反響到合同中來啟動外包工程。此外,工程生存期中驗(yàn)證階段回到ITO來執(zhí)行。一般的應(yīng)用交付涉及到用戶的參與,但該階段的管理仍以外包商負(fù)責(zé),或雙方協(xié)調(diào)后共同負(fù)責(zé)。如果外包的范圍與上述不同,可對上述剪裁模式進(jìn)行調(diào)整,關(guān)鍵是合同和驗(yàn)證兩個控制點(diǎn)。例如僅將設(shè)計局部外包時,標(biāo)書和合同涉及的也將僅僅是設(shè)計階段,驗(yàn)收也是對設(shè)計的驗(yàn)收。需要注意的是驗(yàn)證局部參與的內(nèi)部人員和企業(yè)內(nèi)部用戶與實(shí)現(xiàn)局部參與的人員不同。2.3.3合作工程合作工程是ITO與合作方資源統(tǒng)一管理的工作模式。假設(shè)是以ITO為主,可參照2.3.1節(jié)描述的剪裁模型;如果是以外方為主,那么可參照2.3.2節(jié)描述的剪裁模型。2.3.4采購工程外包工程和合作工程本質(zhì)上也是采購工程,是IT效勞的采購。因此IT效勞采購工程的生存期參照上面2.3.2節(jié)和2.3.3節(jié)。本節(jié)描述的是IT設(shè)備〔包括軟件〕的采購工程,具體如下:工程立項(xiàng)〔略〕工程執(zhí)行:驗(yàn)證應(yīng)用交付SOWSOW用戶需求獲取系統(tǒng)概念確定ITO供貨程序-采購標(biāo)書-采購標(biāo)書-采購合同企業(yè)采購部門供應(yīng)商同樣,內(nèi)部以SOW啟動來確定設(shè)備采購的需求以及采購原那么與策略〔系統(tǒng)概念確定〕。這些內(nèi)容確定后形成采購標(biāo)書,進(jìn)而形成采購合同。供應(yīng)商按其自己的供貨程序工作。如果必要,可在他們的供貨程序中插入質(zhì)量檢驗(yàn)的審核點(diǎn)。2.3.5混合型工程當(dāng)一個IT工程較復(fù)雜時可能包括了自行開發(fā)、合作局部、外包局部以及采購局部。在這種情況下可將工程分解成假設(shè)干子工程,每個工程參照上面適用的生存期分別進(jìn)行管理。三、IT工程過程下述模型是個簡化的IT工程執(zhí)行過程模型,該模型包括了最根本的控制環(huán)節(jié)、分解原那么和實(shí)施過程等要素。工程執(zhí)行過程模型圖示如下:工程立項(xiàng)〔略〕工程執(zhí)行:工程分解與方案啟動結(jié)束工程執(zhí)行工程分解與方案啟動結(jié)束工程執(zhí)行3.1啟動IT工程在執(zhí)行階段必須有一個正式的啟動文件SOW。正式的含義包括:來自于可下達(dá)任務(wù)的授權(quán)機(jī)構(gòu)具有明確的主管人〔發(fā)起人〕指定了工程經(jīng)理清晰的任務(wù)陳述〔SOW〕SOW定義了工程執(zhí)行階段的開始。3.2工程分解與方案當(dāng)工程經(jīng)理接到任務(wù)書后,假設(shè)對任務(wù)書沒有任何疑義,那么工程經(jīng)理需要執(zhí)行的第一個過程是進(jìn)行工程方案,這樣才能保證工程有序的執(zhí)行。由于直接面向任務(wù)書中SOW進(jìn)行方案會很難,特別是其中描述的任務(wù)規(guī)模很大時更是如此。一個有效的方法是將工程執(zhí)行分為假設(shè)干階段,然后按階段進(jìn)行規(guī)劃。例如將工程執(zhí)行分為如下的三個階段:工程執(zhí)行:SOW實(shí)現(xiàn)設(shè)計需求定義SOW實(shí)現(xiàn)設(shè)計需求定義當(dāng)然,如果上述階段劃分太粗,還可以進(jìn)一步細(xì)化,例如將“設(shè)計〞分為“系統(tǒng)設(shè)計〞和“單元設(shè)計〞,將實(shí)現(xiàn)分為“編碼〞、“測試〞和“集成〞。如果有必要,還可以增加一些階段,如在“需求定義〞和“設(shè)計〞之間增加一個“技術(shù)選擇〞的階段來專門分析采用什么技術(shù)對系統(tǒng)開發(fā)最有效。3.3工程實(shí)施工程實(shí)施是工程方案的執(zhí)行。為了能夠知道工程進(jìn)展是否符合工程方案,需要對實(shí)施過程進(jìn)行監(jiān)控。監(jiān)控的方法是每隔一個固定的時間對工程狀態(tài)進(jìn)行一次檢查,然后與方案進(jìn)行比較。如發(fā)生了偏離,那么進(jìn)行糾正。僅僅按固定的時間間隔檢查工程狀態(tài)有時也不能及時處理工程的問題,例如在間隔之間發(fā)生了重大影響工程方案的事件,如一項(xiàng)關(guān)鍵技術(shù)無法應(yīng)用。因此要增加基于事件的檢查。偏離糾正包括兩個方面,一個方面是對工程工程活動和工作產(chǎn)品發(fā)生的偏離進(jìn)行糾正,另一方面是對方案進(jìn)行修訂。這些工作必須加以控制,按嚴(yán)格的標(biāo)準(zhǔn)執(zhí)行,否那么不僅僅偏離未能解決,還會引起新的問題。在工程實(shí)施過程中,雖然是按工程方案進(jìn)行的,但工程方案僅僅是定義了在什么時間由誰完成什么任務(wù),沒有規(guī)定如何完成這些任務(wù)。如何完成有兩種方式,一種是憑執(zhí)行者的經(jīng)驗(yàn)決策,另一種是定義好完成任務(wù)的過程和模板,然后按照過程和模板進(jìn)行工作。當(dāng)然,這兩種方式會結(jié)合起來。3.4工程結(jié)束工程方案的所有任務(wù)完成了,工程就可以結(jié)束。工程方案確定的生存期中定義了工程的結(jié)束階段和結(jié)束應(yīng)該進(jìn)行的工作。工程結(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è)計實(shí)現(xiàn)驗(yàn)證應(yīng)用交付計劃修訂點(diǎn)計劃計劃修訂點(diǎn)計劃修訂點(diǎn)計劃修訂點(diǎn)計劃修訂點(diǎn)計劃修訂點(diǎn)計劃點(diǎn)計劃點(diǎn)箭頭所指示的是工程方案在生存期的一個應(yīng)用場景。前兩個階段是由ITO和業(yè)務(wù)部門共同進(jìn)行初步需求分析和系統(tǒng)概念確定,ITO在工程初始制訂了方案,并在第一個階段完成后對方案進(jìn)行調(diào)整,然后實(shí)施第二個階段。第二個階段完成后,交給一個ITO內(nèi)的工程開發(fā)組織,開發(fā)組織在他們承接工程的第一個階段〔生存期模型第三個階段〕制訂工程方案,并在每個階段完成后,調(diào)整或修改方案。方案的調(diào)整或修訂并不是必需的,只有當(dāng)發(fā)現(xiàn)方案與實(shí)際不符時才進(jìn)行。工程方案過程的目的是為執(zhí)行軟件工程活動和管理軟件工程建立一個合理的工程方案。工程方案過程涉及的主要方面包括軟件工程規(guī)模評估、方案責(zé)任的協(xié)商與確立以及軟件工程方案的制定。工程方案的目標(biāo)為:工程規(guī)模估算并文檔化,以保證在工程規(guī)劃和跟蹤中可用。規(guī)劃工程活動和責(zé)任并文檔化。工程相關(guān)組和人員同意所分配的責(zé)任。 根據(jù)這些目標(biāo),在ITO工程方案過程域中定義了三個過程:工程規(guī)模估算過程工程規(guī)劃過程工程責(zé)任分配過程4.1工程規(guī)模估算過程過程名工程規(guī)模估算過程標(biāo)識PP-01目標(biāo)軟件規(guī)模估算并文檔化,以保證在工程規(guī)劃和跟蹤中可用。進(jìn)入條件SOW〔任務(wù)書〕下達(dá),并詳細(xì)描述了任務(wù)范圍。參與角色工程經(jīng)理(由SOW確定)工程人員(由SOW或工程經(jīng)理確定,包括工程經(jīng)理)相關(guān)評審人員(由工程經(jīng)理確定)工程主管(高層工程主管經(jīng)理,由SOW確定)輸入SOW過程步驟輸出序號描述工程經(jīng)理根據(jù)SOW確定工程工作分解(WBS:WorkBreakdownStructure)的策略和估算準(zhǔn)那么,其中包括估算單位、估算方法、估算爭議處理等。WBS策略估算準(zhǔn)那么工程經(jīng)理向工程人員分配工程分解任務(wù)。(如果工程規(guī)模不大,可由工程經(jīng)理本人獨(dú)立進(jìn)行工程分解和任務(wù)規(guī)模估算工作。)工程人員根據(jù)WBS策略和估算準(zhǔn)那么對工程進(jìn)行分解估算,分別建立各自管轄任務(wù)的WBS和相應(yīng)的任務(wù)規(guī)模估算。工程經(jīng)理負(fù)責(zé)進(jìn)行匯總。工程任務(wù)分解(WBS)工程經(jīng)理組織有關(guān)人員對WBS進(jìn)行評審并根據(jù)評審結(jié)果對WBS以及估算進(jìn)行修訂。評審的目地是保證分解沒有遺漏、重疊等問題;規(guī)模估算有依據(jù)。修訂的工程WBS和任務(wù)規(guī)模估算工程主管對WBS和估算結(jié)果進(jìn)行審核。審核的目的是保證工程范圍理解正確、分解策略正確、估算結(jié)果合理。審核通過的工程WBS和任務(wù)規(guī)模估算工程經(jīng)理負(fù)責(zé)整理上述步驟的輸出,形成工程規(guī)模估算文件。工程規(guī)模估算文件完成標(biāo)志工程WBS和任務(wù)規(guī)模估算通過工程主管審核。形成工程規(guī)模估算文件(過程提交產(chǎn)品)。4.2工程規(guī)劃過程過程名工程規(guī)劃過程過程標(biāo)識PP-02目標(biāo)規(guī)劃工程活動和責(zé)任并文檔化。進(jìn)入條件工程規(guī)模估算完成。參與角色工程經(jīng)理(由SOW確定)相關(guān)評審人員(由工程經(jīng)理確定)工程主管(高層工程主管經(jīng)理,由SOW確定)輸入SOW工程規(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)險進(jìn)行分析并對高風(fēng)險給出控制策略。風(fēng)險分析是基于工程目標(biāo)和工程方案的,即影響工程目標(biāo)和方案可能發(fā)生的事件。工程風(fēng)險控制表工程經(jīng)理基于上面的輸出,產(chǎn)生工程方案草案。工程方案草案工程主管召集有關(guān)人員對工程方案進(jìn)行評審。工程經(jīng)理根據(jù)評審意見對工程方案進(jìn)行修訂,形成正式工程方案文檔,并由工程主管根據(jù)工程確認(rèn)。工程方案評審報告工程正式方案文檔完成標(biāo)志工程方案經(jīng)過評審。正式工程方案文檔產(chǎn)生。4.3工程責(zé)任分配過程過程名工程責(zé)任分配過程過程標(biāo)識PP-03目標(biāo)工程相關(guān)組和人員同意所分配的責(zé)任。進(jìn)入條件工程正式方案形成。參與角色工程經(jīng)理(由SOW確定)工程組成員(由工程方案確定)工程主管(高層工程主管經(jīng)理,由SOW確定)輸入工程方案過程步驟輸出序號描述工程經(jīng)理根據(jù)工程成員和時間方案生成每個人的任務(wù)時間方案并發(fā)放給各個工程成員。個人工程任務(wù)時間方案各個相關(guān)人員確認(rèn)所分配的責(zé)任,其中包括:分配的任務(wù)和時間是合理的??蓾M足完成任務(wù)所需要的業(yè)務(wù)要求??蓾M足完成任務(wù)所需要的時間要求。假設(shè)不能確認(rèn)上述一項(xiàng)或假設(shè)干項(xiàng)條件,那么將情況反響給工程經(jīng)理。個人工程任務(wù)時間方案確認(rèn)結(jié)果工程經(jīng)理根據(jù)反響情況對方案進(jìn)行調(diào)整,并對變化的人員責(zé)任重復(fù)上一步驟。假設(shè)有影響較大的調(diào)整,如關(guān)鍵人員的調(diào)整需得到工程主管的批準(zhǔn)。假設(shè)無調(diào)整,那么跳過此步驟。調(diào)整的工程方案工程經(jīng)理發(fā)布工程方案,發(fā)布對象包括:工程主管工程組成員其他工程相關(guān)組織或人員(如文檔管理部門)完成標(biāo)志方案經(jīng)過所有工程相關(guān)責(zé)任人員確實(shí)認(rèn)。對無法承擔(dān)工程責(zé)任進(jìn)行調(diào)整并反映到方案中。調(diào)整的方案向所有有關(guān)人員發(fā)布。4.4工程采購方案采購規(guī)劃是確定哪些工程需求可以通過從工程組織之外采購產(chǎn)品、效勞或成果,從而最好地滿足某些工程需求,是工程團(tuán)隊在工程實(shí)施過程中可以自行滿足的過程。它涉及是否需要采購、如何采購、采購什么、采購多少,以及何時采購等。當(dāng)工程從實(shí)施組織之外取得工程履行所需的產(chǎn)品、效勞和成果時,每項(xiàng)產(chǎn)品或者效勞都必須經(jīng)歷從采購規(guī)劃到合同收尾的各個過程。采購規(guī)劃過程包括對每項(xiàng)外購決策涉及的風(fēng)險,及就風(fēng)險緩解或風(fēng)險轉(zhuǎn)移進(jìn)行審核。中國外運(yùn)信息化建設(shè)中的IT采購工作分成工程采購和日常采購,日常采購包括但不限于個人電腦及配件的采購。日常采購在每年年底制訂采購方案,并通過工程采購方式選定合格經(jīng)銷商和購置產(chǎn)品種類,有效期1年。日常采購均從選定的合格經(jīng)銷商中選擇。日常采購由具體采購人在合格經(jīng)銷商中采取兩人〔含〕以上詢價的方式進(jìn)行,部門負(fù)責(zé)人負(fù)責(zé)監(jiān)控是否按流程進(jìn)行,并抽查報價。主管〔副〕總經(jīng)理可以確認(rèn)部門負(fù)責(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)注工程進(jìn)展情況并對發(fā)生的偏差及時進(jìn)行糾正。工程執(zhí)行監(jiān)控的依據(jù)是工程方案,但凡方案了的內(nèi)容,都需要進(jìn)行監(jiān)控,例如投入和時間安排。工程方案過程域與IT工程生存期的關(guān)系如以下圖所示:用戶需求獲取系統(tǒng)概念確定系統(tǒng)定義設(shè)計實(shí)現(xiàn)驗(yàn)證應(yīng)用交付監(jiān)控點(diǎn)監(jiān)控點(diǎn)監(jiān)控點(diǎn)監(jiān)控點(diǎn)監(jiān)控點(diǎn)監(jiān)控點(diǎn)監(jiān)控點(diǎn)監(jiān)控點(diǎn)監(jiān)控點(diǎn)監(jiān)控點(diǎn)監(jiān)控點(diǎn)監(jiān)控點(diǎn)監(jiān)控點(diǎn)工程方案工程方案箭頭所示是工程執(zhí)行監(jiān)控的一個應(yīng)用場景。一般工程監(jiān)控采用定期評審,例如按周的定期評審。在每次定期評審中,檢查工程是否偏離了方案。假設(shè)發(fā)生了偏離,那么立即采取糾正措施。此外,工程執(zhí)行監(jiān)控也可能是事件驅(qū)動的,一旦在定期評審之間發(fā)生了重要的工程管理事件,如發(fā)生了某種風(fēng)險,那么進(jìn)行基于事件的評審,并根據(jù)評審結(jié)果采取相應(yīng)措施。每次評審的內(nèi)容和結(jié)果要向所有相關(guān)人員通報,相關(guān)人員包括工程人員、用戶和企業(yè)相關(guān)主管。通報通常采用定期工程簡報的形式。工程監(jiān)控過程的目標(biāo)為:按照方案跟蹤工程的實(shí)際結(jié)果和執(zhí)行性能。當(dāng)實(shí)際結(jié)果和執(zhí)行性能偏離方案時,要采取糾正措施并對其進(jìn)行管理。保證相關(guān)人員和組織同意所改變的責(zé)任。根據(jù)上述目標(biāo),工程監(jiān)控過程域包括四個過程:工程定期評審過程基于事件的評審過程偏離糾正過程方案修訂過程工程評審過程分為定期評審和基于事件評審。定期評審是正常的周期性評審,基于事件的評審是當(dāng)發(fā)生了嚴(yán)重影響工程進(jìn)展事件時進(jìn)行的評審?;谑录脑u審由工程經(jīng)理根據(jù)具體情況決定。偏離糾正過程用于控制管理工程進(jìn)程中發(fā)現(xiàn)的問題和問題的處理。方案修改正程用于控制和實(shí)施方案的變更,保證變更后的方案仍然具有合理性。5.1工程定期評審過程過程名工程定期評審過程過程標(biāo)識OM-01目標(biāo)按照方案跟蹤工程的實(shí)際結(jié)果和執(zhí)行性能。進(jìn)入條件到達(dá)工程評審時間參與角色工程經(jīng)理(由SOW確定)工程組成員(由工程方案確定)輸入工程方案過程步驟輸出序號描述工程經(jīng)理根據(jù)工程方案本階段要求完成的內(nèi)容,收集各個工程成員的任務(wù)完成狀態(tài)。工程進(jìn)展?fàn)顟B(tài)工程經(jīng)理將各個工程成員任務(wù)完成的狀態(tài)與方案進(jìn)行比較。假設(shè)工程經(jīng)理認(rèn)為出現(xiàn)與方案的重要偏離,那么與相關(guān)工程人員分析偏離原因,提出糾正措施,糾正措施包括對偏離的糾正或?qū)Ψ桨傅男薷?。對不是重要的偏離,那么不提出糾正措施,而是列入到下次評審關(guān)注對象。偏離程度的判斷由工程經(jīng)理負(fù)責(zé)。偏離糾正措施工程經(jīng)理審查以前定期評審確定關(guān)注的偏離問題(如存在的話),并確定是否采取偏離糾正措施。偏離糾正措施(假設(shè)存在需糾正的偏離)工程經(jīng)理審查目前階段正在執(zhí)行的偏離糾正措施,假設(shè)發(fā)現(xiàn)問題那么給出問題解決建議。偏離糾正措施執(zhí)行建議工程經(jīng)理將上述評審結(jié)果形成工程定期評審報告,并發(fā)布給相關(guān)人員,發(fā)放范圍依據(jù)工程方案。工程定期評審報告完成標(biāo)志工程方案本階段內(nèi)所有要求的完成內(nèi)容與實(shí)際完成狀態(tài)進(jìn)行了比較。對需要糾正的偏離,向相關(guān)工程人員發(fā)出了糾正措施或糾正措施執(zhí)行建議。工程定期評審報告完成并向相關(guān)人員發(fā)布。5.2工程事件評審過程過程名工程事件評審過程過程標(biāo)識OM-02目標(biāo)按照方案跟蹤工程的實(shí)際結(jié)果和執(zhí)行性能。進(jìn)入條件工程經(jīng)理得到工程成員的事件報告并決定進(jìn)行評審。參與角色工程經(jīng)理(由SOW確定)工程組相關(guān)成員(事件報告者和其他相關(guān)人員)輸入事件報告工程方案過程步驟輸出序號描述工程經(jīng)理與相關(guān)人員分析事件對方案的影響,其中包括:方案進(jìn)度的影響方案本錢的影響方案資源的影響質(zhì)量的影響等事件影響分析工程經(jīng)理與相關(guān)人員確定事件處理措施,處理措施包括事件的解決、方案的調(diào)整等方面。事件處理措施工程經(jīng)理落實(shí)事件處理的資源保證,如人力的保證。工程經(jīng)理將上述評審結(jié)果形成工程事件評審報告,并發(fā)布給相關(guān)人員,發(fā)放范圍包括評審會人員、主管人員以及其他相關(guān)人員。工程事件評審報告完成標(biāo)志確定了工程事件處理措施并落實(shí)了相關(guān)事件處理的資源。工程事件評審報告完成并向相關(guān)人員發(fā)布。5.3偏離糾正過程過程名方案偏離糾正過程過程標(biāo)識OM-03目標(biāo)當(dāng)實(shí)際結(jié)果和執(zhí)行性能偏離方案時,要采取糾正措施并對其進(jìn)行管理。進(jìn)入條件工程定期評審會發(fā)出偏離糾正措施,或工程事件評審會發(fā)出事件處理措施參與角色偏離糾正人員,或事件處理人員、工程經(jīng)理輸入偏離糾正措施,或事件處理措施過程步驟輸出序號描述偏離糾正人員/事件處理人員根據(jù)偏離糾正措施/事件處理措施制訂糾正/處理步驟。偏離糾正/事件處理步驟偏離糾正人員/事件處理人員執(zhí)行制訂的偏離糾正/事件處理步驟,直至結(jié)束。偏離糾正/事件處理結(jié)果工程經(jīng)理審核偏離糾正/事件處理結(jié)果,假設(shè)存在問題,那么確定相應(yīng)措施,再重復(fù)1-2兩個步驟。偏離糾正人員/事件處理人員將偏離糾正/事件處理結(jié)果形成報告。偏離糾正/事件處理結(jié)果報告工程經(jīng)理審核偏離糾正/事件處理結(jié)果報告,并發(fā)布給有關(guān)人員。完成標(biāo)志工程經(jīng)理審核通過偏離糾正/事件處理結(jié)果。偏離糾正/事件處理結(jié)果報告完成并向相關(guān)人員發(fā)布。5.4方案修訂過程過程名方案修訂過程過程標(biāo)識OM-04目標(biāo)當(dāng)實(shí)際結(jié)果和執(zhí)行性能偏離方案時,要采取糾正措施并對其進(jìn)行管理。保證相關(guān)人員和組織同意所改變的責(zé)任。進(jìn)入條件工程定期評審會發(fā)出偏離糾正措施,該措施包括方案的修訂,或工程事件評審會發(fā)出事件處理措施,該措施包括方案的修訂。參與角色工程經(jīng)理工程主管輸入偏離糾正措施,或事件處理措施過程步驟輸出序號描述工程經(jīng)理根據(jù)偏離糾正措施/事件處理措施確定方案修訂的范圍和內(nèi)容。方案修訂范圍和內(nèi)容工程經(jīng)理根據(jù)確定的修訂范圍和內(nèi)容修訂方案。修訂的方案假設(shè)修訂的方案涉及到人員責(zé)任的變化,那么工程經(jīng)理與相關(guān)人員確認(rèn)變化的責(zé)任是否可接受。假設(shè)不可接受,那么需進(jìn)一步調(diào)整。修訂的方案工程主管審核修訂的方案,假設(shè)存在問題確定重新修訂的范圍和內(nèi)容,再次執(zhí)行步驟2-3。重新修訂的范圍和內(nèi)容,或?qū)徍送ㄟ^的方案工程經(jīng)理發(fā)布經(jīng)工程主管的審核方案,發(fā)布范圍同原方案發(fā)布的范圍。完成標(biāo)志工程主管審核通過修訂的方案。審核通過的修訂方案向相關(guān)人員發(fā)布。5.5工程采購監(jiān)控在進(jìn)行工程采購的決策過程中,應(yīng)考慮工程預(yù)算等制約因素。實(shí)施組織的長遠(yuǎn)戰(zhàn)略也是在采購監(jiān)控中應(yīng)考慮的內(nèi)容。如果斷定外購,那么反映了實(shí)施組織的長遠(yuǎn)規(guī)劃和工程的當(dāng)前需要。例如,決定購置某種開發(fā)平臺或數(shù)據(jù)庫,不是臨時使用,而是希望獲得長期支持。從工程經(jīng)濟(jì)效益上看可能合算,也可能不合算。但是如果實(shí)施組織需要長期使用該開發(fā)平臺或數(shù)據(jù)庫,那么分?jǐn)偟焦こ躺系哪蔷植抠徶觅M(fèi)用就有可能低于臨時使用的費(fèi)用。在進(jìn)行工程采購時,應(yīng)成立采購工程組,并對工程采購的過程進(jìn)行監(jiān)控。采購工程組包括業(yè)務(wù)部門和信息管理部的主管領(lǐng)導(dǎo)及相關(guān)負(fù)責(zé)人員和經(jīng)辦人員,必要時請企劃部、財務(wù)部等部門參加。根據(jù)?中國外運(yùn)股份有限公司投資管理規(guī)定?,超過三百萬的工程采購,還要上報股份公司,經(jīng)批準(zhǔn)前方可執(zhí)行。工程采購流程如下:起草立項(xiàng)報告工程組根據(jù)工程需求描述決定何時采購何物,制定相應(yīng)的采購方案并起草立項(xiàng)報告,通過內(nèi)請流程上報公司審批。審批通過后,成立IT采購工程組,并確定工程組成員。確定采購方式經(jīng)IT采購工程組討論通過后,決定采購方式,主要包括三種方式:公開招標(biāo)、邀請招標(biāo)、詢價采購。供應(yīng)商的選擇和詢報價IT采購工程組應(yīng)根據(jù)備選供方的報價單進(jìn)行評定,即進(jìn)行供應(yīng)商的選擇。確定供應(yīng)商和價格IT采購工程組經(jīng)過討論,最終確定供應(yīng)商和采購產(chǎn)品的價格。簽訂合同IT采購工程組和產(chǎn)品供應(yīng)商談判后簽署采購合同。合同執(zhí)行產(chǎn)品供應(yīng)商按合同規(guī)定履約,IT采購工程組成員負(fù)責(zé)產(chǎn)品驗(yàn)收。價款結(jié)算IT采購工程組負(fù)責(zé)辦理和產(chǎn)品供應(yīng)商的價款結(jié)算。填寫IT采購申請/處理單IT采購工程組負(fù)責(zé)填寫IT采購申請/處理單。六、IT工程審核IT工程審核過程是一種正式的評審,需要較高的資源投入,因此并不意味著所有IT工程交付件都要進(jìn)行正式的審核。審核對象確實(shí)定由工程經(jīng)理在工程方案時根據(jù)質(zhì)量風(fēng)險來確定。IT工程審核包括三個局部:審核方案、審核執(zhí)行、審核問題糾正,這三個局部描述如下:審核方案審核方案是基于工程方案確定的審核對象和標(biāo)準(zhǔn)的審核過程來定義審核目標(biāo)、資源方案和時間方案。在工程方案中,需要確定審核對象和相應(yīng)的審核主持人,與此同時在方案中分配審核主持人審核方案和審核執(zhí)行任務(wù)。在一個工程中不同階段會對不同的交付件進(jìn)行審核,這些審核的主持人可以是不同的。一個主要的原那么是審核主持人不能是交付件的責(zé)任人。審核執(zhí)行審核執(zhí)行包括審核準(zhǔn)備、召開審核會和建立審核記錄。審核準(zhǔn)備包括審核對象資料準(zhǔn)備、審核人員熟悉所負(fù)責(zé)的審核內(nèi)容。審核會一般不超過兩個小時,否那么效率會大大降低。審核會的目的是審核交付件是否滿足相應(yīng)的準(zhǔn)那么,而不是審核人的能力和具體采用的開發(fā)方法、技術(shù)的正確與否。審核記錄要記錄審核過程發(fā)現(xiàn)的缺陷,缺陷屬性,例如嚴(yán)重程度、來源〔本階段產(chǎn)生的,還是前面階段遺留下來的〕等。審核問題糾正審核問題糾正是解決審核中發(fā)現(xiàn)的缺陷。審核問題的糾正要加以跟蹤,直到全面完成。6.1審核方案過程過程名審核方案過程過程標(biāo)識PR-01目標(biāo)對審核活動進(jìn)行方案。進(jìn)入條件到達(dá)工程方案的審核方案時間。參與角色審核主持人(由工程經(jīng)理在方案中指定)審核人交付件開發(fā)責(zé)任人輸入審核對象定義(根據(jù)工程方案)審核過程過程步驟輸出序號描述1審核主持人根據(jù)審核對象定義確定審核目標(biāo)。審核目標(biāo)2審核人與交付件開發(fā)責(zé)任人討論確認(rèn)審核目標(biāo)。交付件開發(fā)責(zé)任人確認(rèn)的審核目標(biāo)3審核主持人根據(jù)審核對象和審核目標(biāo)確定主審人和審核人以及它們的責(zé)任,并得到這些人員參加審核確實(shí)認(rèn)和對審核目標(biāo)確實(shí)認(rèn)。審核人名單確認(rèn)的審核目標(biāo)4審核主持人與交付件開發(fā)責(zé)任人確認(rèn)審核材料提交的時間和發(fā)放的對象。審核材料提交時間、清單和發(fā)放對象5審核主持人確定審核時間和地點(diǎn)并得到審核人員和交付件開發(fā)責(zé)任人確實(shí)認(rèn)。審核時間6審核主持人形成書面審核方案并送達(dá)交付件開發(fā)責(zé)任人、所有審核人員和工程經(jīng)理。審核方案完成標(biāo)志審核方案送達(dá)所有相關(guān)人員。6.2審核執(zhí)行過程過程名審核過程執(zhí)行過程過程標(biāo)識PR-02目標(biāo)按照方案執(zhí)行審核。進(jìn)入條件到達(dá)審核方案確定的審核任務(wù)時間審核對象材料發(fā)放參與角色審核主持人(由工程方案確定)審核人員(由審核方案確定,包括主審人)交付件開發(fā)責(zé)任人輸入審核方案審核對象材料過程步驟輸出序號描述1所有審核人通過審核對象材料了解與其責(zé)任相關(guān)的審核內(nèi)容。審核主持人對此進(jìn)行確認(rèn)。無2審核主持人按方案召集審核會。無3主審人報告全面審核的結(jié)果。主審人審核結(jié)果4各個審核人報告各自責(zé)任范圍內(nèi)的審核的結(jié)果。審核人審核結(jié)果5審核人討論交付件可能的缺陷。候選缺陷6交付件開發(fā)責(zé)任人對審核人提出的問題應(yīng)答。無7審核人確認(rèn)交付件的缺陷和缺陷屬性,其中包括嚴(yán)重程度(高、中、低)和來源(本階段產(chǎn)生,前面階段遺留)。缺陷清單8審核主持人形成審核報告,并得到與會人員的認(rèn)可。審核報告確認(rèn)的缺陷清單作為該報告的附件。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ā)的根本步驟如下:確定工程范圍獲取客戶需求分析客戶需求制訂系統(tǒng)規(guī)格驗(yàn)證系統(tǒng)規(guī)格系統(tǒng)規(guī)格受控確定工程范圍工程范圍本身往往在工程開始時也不是很容易確定。客戶是一個群體,不同層面的人員因處于不同的地位會對工程含義有不同的認(rèn)識。有時在同一范圍概念下,也會有不同內(nèi)容的理解。這個階段的目的是建立一個統(tǒng)一的工程視圖并在這個視圖的根底上對工程范圍取得共同的認(rèn)識。工程視圖需要采用客戶容易理解的圖示來表達(dá),例如系統(tǒng)環(huán)境關(guān)聯(lián)圖,系統(tǒng)功能層次圖、系統(tǒng)在業(yè)務(wù)價值鏈中的位置等。利用這些圖示來進(jìn)一步刻畫和描述系統(tǒng)范圍要素,如支持的用戶類別、系統(tǒng)特征、基于的環(huán)境和支持目標(biāo)等。工程范圍實(shí)質(zhì)上是客戶需求的一個局部并且是一個重要的局部。工程范圍為工程任務(wù)圈定了一個問題考慮范圍。隨著需求分析的進(jìn)展,工程范圍會發(fā)生變化,這些變化應(yīng)及時反映到相關(guān)的文檔中,并及時知會相關(guān)的人員。獲取客戶需求工程范圍定義是工程宏觀的需求析取,為了能夠真正開發(fā)一個應(yīng)用系統(tǒng),必須全面了解客戶對系統(tǒng)的要求。由于客戶不是系統(tǒng)分析人員,因此這個階段的目的是確定有效的方法,然后利用所確定的方法從相對分散的需求源,系統(tǒng)化地獲取客戶需求。獲取客戶需求方法的根本原那么是系統(tǒng)地定義需求類別、建立統(tǒng)一的需求表達(dá)、識別和規(guī)劃需求獲取的渠道。系統(tǒng)地建立需求類別可以將一個大的問題分解為假設(shè)干小的問題,同時可幫助客戶需求獲取人員完備地收集客戶需求。建立統(tǒng)一的客戶需求表達(dá)可一致化和標(biāo)準(zhǔn)化得到的需求,為后面的工作提供一個良好的根底。識別和規(guī)劃需求渠道可有效地配備資源。需求獲取渠道不僅僅是按確定用戶類別的訪談,也包括業(yè)務(wù)資料的分析等其它方面。分析客戶需求獲取的客戶需求難以直接轉(zhuǎn)化為系統(tǒng)規(guī)格定義,因?yàn)檫@些需求往往是概要性的、一般情況下不會完備、相互之間可能存在不一致。因此這個階段的目的是對獲取的需求系統(tǒng)地加以分析,建立一個相對完整的系統(tǒng)概念模型,如系統(tǒng)交互模型。通過系統(tǒng)概念模型的建立來細(xì)化、補(bǔ)充需求、消除需求中的不一致性。這個階段會繼續(xù)執(zhí)行上個階段的工作,以解決已經(jīng)獲取需求中的問題并補(bǔ)充分析客戶需求所需要的進(jìn)一步信息。這個繼續(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)驗(yàn)證的依據(jù)。同客戶需求分析一樣,系統(tǒng)規(guī)格定義也包括許多類型的方法和技術(shù),如形式化的定義方法和自然語言的描述。一個理想的情況是分析模型和定義模型采用相同的技術(shù)。這樣不僅僅可以平滑地聯(lián)結(jié)分析客戶需求和制訂系統(tǒng)規(guī)格這兩個階段,同時也可大大提高工作效率,因?yàn)榉治瞿P偷慕Y(jié)果可被重用到規(guī)格定義中。同樣,具體技術(shù)的采用也與客戶需求階段相同。驗(yàn)證系統(tǒng)規(guī)格系統(tǒng)規(guī)格定義一旦確定,將作為開發(fā)依據(jù)貫穿在整個工程開發(fā)活動中。因此如果規(guī)格定義存在缺陷,將會產(chǎn)生很高代價的質(zhì)量本錢。此外,系統(tǒng)規(guī)格是通過客戶需求的分析和轉(zhuǎn)換產(chǎn)生的,因此這個分析和轉(zhuǎn)換可能會存在偏差。這個階段的目的就是來驗(yàn)證是否認(rèn)義的系統(tǒng)能夠真正滿足客戶的需求。系統(tǒng)規(guī)格驗(yàn)證包括用戶評審、內(nèi)部評審、走察〔Walk-through〕或更為嚴(yán)格的同行審核〔PeerReview,Inspection〕。如果需要讓客戶對系統(tǒng)實(shí)現(xiàn)后的式樣有充分地了解,還可以建立系統(tǒng)原型〔Prototype〕供客戶評審。系統(tǒng)驗(yàn)證技術(shù)和方法的采用是風(fēng)險和本錢的平衡。例如原型技術(shù)會很大程度降低實(shí)現(xiàn)的系統(tǒng)背離用戶需求的風(fēng)險,但需要較高的投入。不過由于系統(tǒng)規(guī)格是保證系統(tǒng)成功的關(guān)鍵,因此采用多種驗(yàn)證形式其中包括較嚴(yán)格的驗(yàn)證形式是十分必要的。系統(tǒng)規(guī)格受控正如上面屢次指出的,系統(tǒng)規(guī)格將在整個工程生存期中作為系統(tǒng)實(shí)現(xiàn)的依據(jù),其中包括設(shè)計的依據(jù)、系統(tǒng)測試的依據(jù)、驗(yàn)收的依據(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)威機(jī)構(gòu)正式批準(zhǔn)。第二個環(huán)節(jié)是將批準(zhǔn)的系統(tǒng)規(guī)格“凍結(jié)〞,即不能隨意地對其更改。這之后的任何更改要通過嚴(yán)格變更控制程序。這兩個環(huán)節(jié)是將系統(tǒng)規(guī)格“基線化〞?;€化是配置管理的任務(wù)。實(shí)際上,系統(tǒng)規(guī)格受控通常都是配置管理中的一個環(huán)節(jié)。7.2需求管理的步驟需求管理的目的是保證系統(tǒng)需求作為基線加以管理,即系統(tǒng)需求定義的建立、使用和修改均加以控制,以保證系統(tǒng)需求可用性和其它工程活動與系統(tǒng)需求的一致性。需求管理與配置管理密切相關(guān)。實(shí)際上,需求是作為配置項(xiàng)納入到配置管理中的。需求管理的根本步驟如下:建立系統(tǒng)需求基線發(fā)布系統(tǒng)需求基線系統(tǒng)需求基線跟蹤報告處理系統(tǒng)需求基線修改請求建立系統(tǒng)需求基線建立系統(tǒng)需求基線是將開發(fā)的系統(tǒng)需求置為基線狀態(tài)。如果實(shí)施了正式的需求管理和配置管理,可將系統(tǒng)規(guī)格納入到需求管理和配置管理中。例如,一個具體的做法可以是將開發(fā)完成的系統(tǒng)規(guī)格提交給配置管理,由配置管理員對規(guī)格進(jìn)行配置標(biāo)識,然后入配置管理庫。發(fā)布系統(tǒng)需求基線由于系統(tǒng)需求基線是整個工程生存期工程活動的依據(jù),因此應(yīng)將正式建立的基線及時加以發(fā)布,以確保所有相關(guān)的人員了解基線的狀態(tài)。特別當(dāng)基線修改后基線的及時發(fā)布對正在進(jìn)行的工程活動至關(guān)重要。系統(tǒng)需求基線跟蹤報告為了保證系統(tǒng)需求基線被有效的實(shí)現(xiàn),需要對需求基線的實(shí)施進(jìn)行跟蹤,并將跟蹤的結(jié)果進(jìn)行報告。例如跟蹤系統(tǒng)設(shè)計是否覆蓋了所有的需求基線。處理系統(tǒng)需求基線修改請求這是需求基線管理的最核心也是最復(fù)雜的一個步驟。這個步驟包括了一系列子步驟如下:對需要更新的基線局部提出更改請求。分析、審核更改請求,其中包括確認(rèn)更改理由的充要性、分析更改的涉及范圍、估算更改的投入等方面。如果同意更改,那么制訂更改方案。實(shí)施更改方案。審核更改結(jié)果。批準(zhǔn)更改。更新需求基線。由于需求基線修改涉及到多方面人員,因此對需求基線的修改〔也包括對其它基線的修改〕的批準(zhǔn)要征得相關(guān)人員的同意。一般在配置管理體系下,由相關(guān)人員代表成立一個配置管理委員會來處理基線管理事項(xiàng)。八、IT工程工作產(chǎn)品及驗(yàn)收IT工程工作產(chǎn)品是IT工程過程的輸出。這些輸出包括兩類,一類是通過開發(fā)產(chǎn)生的交付件,這些交付件是軟件產(chǎn)品的一局部,有些會最終提供應(yīng)客戶使用,有些僅僅是中間產(chǎn)品〔如系統(tǒng)設(shè)計〕或管理文件〔如工程方案〕。另一類是記錄性質(zhì)的文件,這些文件往往作為質(zhì)量證據(jù)使用,應(yīng)此稱之為質(zhì)量記錄,如評審記錄報告、測試記錄報告等。無論是交付件還是質(zhì)量記錄,一旦產(chǎn)生可能被多個人屢次使用,特別是工作產(chǎn)品。如果這些產(chǎn)品能按類別分別以統(tǒng)一的形式與內(nèi)容要素產(chǎn)生,那么可有效的提高工作產(chǎn)品的質(zhì)量,降低工作產(chǎn)品的交流本錢。8.1交付件工程交付件一般由四局部組成,封面、目錄、正文、附件。工程文件屬性信息需包括工程交付件的封面中文件標(biāo)題的下方。工程交付件屬性信息包括:工程交付件編號交付件類別版本號完成時間開發(fā)責(zé)任人批準(zhǔn)人密級所有的交付件都應(yīng)包含上述屬性信息,這些屬性定義可用于交付件文檔的管理并有利于交付件的使用。8.2質(zhì)量記錄工程質(zhì)量記錄是各種過程活動的記錄,也包括活動的報告。質(zhì)量記錄的重要特征是客觀。質(zhì)量記錄一般為表格形式的文件,這些表格形式的文件在形式上并不一致。原那么上標(biāo)識信息應(yīng)涉及在表格的開始局部,其它信息在表格結(jié)尾局部。工程質(zhì)量記錄屬性信息包括:記錄編號記錄類別記錄時間記錄人審核批準(zhǔn)人所有的質(zhì)量記錄都應(yīng)包含上述屬性信息,這些屬性定義可用于質(zhì)量記錄的管理并有利于質(zhì)量記錄的引用。一類質(zhì)量記錄往往在工程中有多個實(shí)例,因此質(zhì)量記錄可以通告定義模板來減輕質(zhì)量記錄格式的創(chuàng)立工作。8.3工作產(chǎn)品模板工作產(chǎn)品模板包括交付件模板和質(zhì)量記錄模板。模板的定義和應(yīng)用將可標(biāo)準(zhǔn)工作產(chǎn)品的格式和內(nèi)容要素,也可減少在工程過程中創(chuàng)立文檔格式的工作量。工作產(chǎn)品模板的應(yīng)用本質(zhì)也是質(zhì)量控制的手段。8.3.1任務(wù)書模板 工程名稱工程標(biāo)識工程主管工程下達(dá)時間年月 日工程經(jīng)理方案提交時限年月 日工程定義類型用戶目標(biāo)內(nèi)容描述輸入工程限制時間資金資源實(shí)現(xiàn)8.3.2方案書模板1.引言1.1目的 1.2范圍1.3參考資料1.4版本歷史2.工程概述3.工程目標(biāo)和交付件4.實(shí)施策略5.工程生存期6.任務(wù)分解與估算7.資源規(guī)劃7.1人力資源 7.2設(shè)施工具7.3關(guān)鍵資源8.時間方案9.預(yù)算10.風(fēng)險識別與控制11.工程監(jiān)控8.3.3評審報告模板工程名稱工程編號評審時間評審地點(diǎn)評審類別評審人員姓名工程職責(zé)評審職責(zé)簽字No.評審項(xiàng)評審意見/結(jié)論0102030405060708091011…評審報告起草人/時間評審報告審核人/時間8.3.4需求歸納表模板ID摘要類別描述優(yōu)先級來源狀態(tài)8.4工程驗(yàn)收8.4.1可交付物驗(yàn)收可交付物是指工程驗(yàn)收時向客戶提交的系統(tǒng)、源程序和文檔,通常的工程可交付物如下:?需求分析報告??功能規(guī)格說明書??體系架構(gòu)設(shè)計說明書?風(fēng)格設(shè)計的效果樣片〔圖片〕、頁面原型以及圖素〔經(jīng)切割的圖片原素〕詳細(xì)設(shè)計文檔為工程實(shí)施所編制的特定的程序代碼可能涉及到的網(wǎng)頁框架模板?系統(tǒng)維護(hù)手冊??用戶使用手冊?各階段的工程進(jìn)度報告8.4.2技術(shù)驗(yàn)收通過驗(yàn)收會的形式向客戶陳述系統(tǒng)體系架構(gòu)的合理性,并從下面幾個方面對技術(shù)架構(gòu)進(jìn)行驗(yàn)收:系統(tǒng)的可靠性系統(tǒng)的平安性系統(tǒng)的延展性系統(tǒng)的操作性系統(tǒng)性能可能存在的技術(shù)問題和技術(shù)風(fēng)險8.4.3功能驗(yàn)收功能驗(yàn)收主要針對功能性需求的滿足程度進(jìn)行驗(yàn)收,通常包括以下幾個方面:信息展示需求的滿足程度業(yè)務(wù)功能需求的滿足程度用戶管理需求的滿足程度數(shù)據(jù)初始化需求的滿足程度應(yīng)用集成需求的滿足程度未完全滿足的需求在下一期工程中的安排8.4.4驗(yàn)收方案編號任務(wù)開始時間完成時間參與部門1可交付物驗(yàn)收2技術(shù)驗(yàn)收3功能驗(yàn)收4驗(yàn)收會5最終驗(yàn)收簽字

九、工程經(jīng)理的職責(zé)和素質(zhì)9.1工程經(jīng)理的職責(zé)工程經(jīng)理是負(fù)責(zé)管理工程日常工作的個人。工程經(jīng)理通常需要明確地給予授權(quán),以便能取得其他部門的支持與合作,帶著工程小組按時、按質(zhì)并在批準(zhǔn)的預(yù)算范圍內(nèi)完成任務(wù)。信息管理部IT工程經(jīng)理的職責(zé)包括:挑選工程組成員;制定工程方案并得到相關(guān)領(lǐng)導(dǎo)的認(rèn)可;對工程進(jìn)行界定并得到相關(guān)領(lǐng)導(dǎo)的認(rèn)可;負(fù)責(zé)信息溝通;識別并處理風(fēng)險;有效分配并使用資源;監(jiān)控并跟蹤工程的進(jìn)展;解決工程執(zhí)行過程中出現(xiàn)的阻礙進(jìn)展的問題;控制范圍、本錢、進(jìn)度、質(zhì)量等;領(lǐng)導(dǎo)工程小組;提交工程可交付使用的成果及收益;負(fù)責(zé)評價工程組成員的表現(xiàn)。簡單的講,工程經(jīng)理就是要關(guān)注四方面的內(nèi)容:T——時間C——本錢Q——質(zhì)量性能S——工作范圍即在規(guī)定的時間內(nèi),在批準(zhǔn)的預(yù)算內(nèi),完成事先確定的工作范圍內(nèi)的工作,并且到達(dá)預(yù)期的質(zhì)量性能要求,這就是工程經(jīng)理的崗位職責(zé)。中外運(yùn)公司的IT工程經(jīng)理應(yīng)該面臨更劇烈的競爭,需要承受更大的壓力,需要介入更廣闊的業(yè)務(wù),具體的崗位職責(zé)表達(dá)在方案、組織、指導(dǎo)、控制四個方面。方案方案決不是可有可無的,而是必不可少的。如果沒有方案,工程后期的控制便沒有根底。工程經(jīng)理的方案職責(zé)具體包括:確定工程目標(biāo),并取得管理層與客戶的一致意見;制定工程方案,并取得管理層的批準(zhǔn);確定工程所需要的資源;制定工程管理所用的技術(shù)、方法、程序和規(guī)章。組織工程經(jīng)理是工程責(zé)、權(quán)、利的主體,是工程的組織者。工程經(jīng)理應(yīng)該把組織職責(zé)放在首位,在工程內(nèi)部建立一個領(lǐng)導(dǎo)核心,實(shí)現(xiàn)工程班子的最正確組合和有效領(lǐng)導(dǎo)。工程經(jīng)理組織工作的核心就是配備人員、制定規(guī)章制度、明確崗位責(zé)任、建立工程內(nèi)部和外部的溝通渠道等。對于工程組的工作,工程經(jīng)理要獲得工程組成員的承諾;對于工程組外部的工作,工程經(jīng)理需要與客戶界定各自的職責(zé)范圍并達(dá)成協(xié)議,還要注意與工程組成員和客戶的溝通協(xié)調(diào)。另外,工程經(jīng)理還應(yīng)該營造一種團(tuán)結(jié)緊張、嚴(yán)肅活潑的工作環(huán)境,使各方面的人員都能高效地工作。組織工作成功的標(biāo)準(zhǔn)是工程組織能夠高效率運(yùn)轉(zhuǎn)和能夠?qū)崿F(xiàn)有效的領(lǐng)導(dǎo)。工程經(jīng)理組織工作的具體內(nèi)容包括:開發(fā)工程所需要的人力資源,即組建工程小組;建立適當(dāng)?shù)墓こ坦芾斫M織機(jī)構(gòu)圖;對工程各職位進(jìn)行描述,制定工程管理責(zé)任矩陣;確保工程組成員理解和接受他們的職責(zé);組織工程組成員制定工程方案;促進(jìn)工程團(tuán)隊內(nèi)外部的有效溝通;根據(jù)批準(zhǔn)的工程方案,配置各種資源。指導(dǎo)工程經(jīng)理需要把握工程的方向,需要指引工程組成員有效地完成工程目標(biāo),需要進(jìn)行工程決策,這些都是工程經(jīng)理的指導(dǎo)職能。工程經(jīng)理是工程組的最高決策者,及時、正確地做出各種決策,既是工程經(jīng)理的根本任務(wù),也是工程管理能否順利實(shí)施的重要前提,更是工程能否實(shí)現(xiàn)預(yù)期目標(biāo)的關(guān)鍵。工程經(jīng)理的指導(dǎo)職能具體表達(dá)在:具體指導(dǎo)實(shí)施工程方案中的各項(xiàng)活動;提供階段性的工程進(jìn)

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論