簡介:第三章軟件項目管理,項目管理的概念軟件項目度量軟件項目計劃與估算風險分析和管理項目進度安排軟件質量保證軟件配置管理,項目管理的譜系,軟件項目管理的目的、任務和內容,目的為了使軟件項目能夠在預定成本、進度、質量的前提下順利完成,必須對軟件工程項目進行計劃、組織、監(jiān)控和管理任務制定軟件項目的實施計劃和方案;對人員進行組織和分工;按照計劃進度,以及成本管理、風險管理、質量管理的要求進行軟件開發(fā),完成軟件項目的各項要求和任務。,311軟件度量,軟件度量的概念軟件規(guī)模度量軟件功能度量,,31軟件項目度量,軟件度量分類,3111度量、估算,度量METRICS度量具有數字特征,軟件工程范圍的度量是軟件開發(fā)過程、軟件資源或軟件產品簡單屬性的定量描述。如,程序規(guī)模、操作符個數、程序中錯誤的個數等。估算ESTIMATION對軟件產品、過程、資源進行預測估算可以采用經驗公式、或參考歷史資料估算用于事前簽訂合同、立項、制定工作計劃等,軟件的外部屬性和內部屬性外部屬性軟件產品、過程、資源與環(huán)境的關系如,成本、效益、勞動生產率、可靠性、可維護性內部屬性軟件產品、過程、資源、環(huán)境自身的屬性如,產品結構、模塊化程度、復雜性、程序長度等。,產品過程資源,產品的內部屬性程序代碼長度程序功能模塊化重用性控制流數據流模塊耦合度與內聚度產品的外部屬性程序的可靠性可用性可維護性軟件的可理解性有效性可移植性,過程的內部屬性工作量計劃和進度一段時間內某類事件發(fā)生的次數過程的外部屬性成本可控制性可觀察性穩(wěn)定性資源的內部屬性人軟硬件環(huán)境方法經驗資源的外部屬性成本時間,3112面向規(guī)模的度量,代碼行數LOC或KLOC生產率PLL/E其中L軟件項目代碼行數E軟件項目工作量(人月PM)PL軟件項目生產率(LOC/PM)代碼出錯率EQRLNE/L其中NE軟件項目的代碼錯誤數EQRL每千行代碼的錯誤數,每行代碼平均成本CLS/L其中S軟件項目總開銷(元/美元)CL軟件項目每行代碼的平均成本文檔與代碼比DLPD/L其中PD軟件項目文檔頁數DL每千行代碼的平均文檔數,例軟件項目記錄,生產率PLL/E121KLOC/24PM504LOC/PM出錯率EQRLNE/L29個/121KLOC24個/KLOC平均成本CLS/L168000美元/121KLOC1388美元/LOC每千行代碼的平均文檔頁數DLPD/L365PD/121KLOC3016PD/KLOC,規(guī)模度量的優(yōu)缺點,用軟件代碼行數估算軟件規(guī)模簡單易行。缺點代碼行數的估算依賴于程序設計語言的功能和表達能力;采用代碼行估算方法會對設計精巧的軟件項目產生不利的影響;在軟件項目開發(fā)前或開發(fā)初期估算它的代碼行數十分困難;代碼行估算只適用于過程式程序設計語言,對非過程式的程序設計語言不太適用等等。,根據事務信息處理程序的基本功能定義的,在系統(tǒng)設計初期可以估算出軟件項目的規(guī)模FPCT[065001∑FI]其中CT按表31計算FI是復雜性調節(jié)值FI取值0,1,,5當FI0時,表示FI不起作用FI5時,表示FI作用最大,3113面向功能的度量,表31功能點度量,測量參數值權值用戶輸入數□4=□用戶輸出數□5=□用戶查詢數□4=□文件數□7=□外部界面數□7=□CT=□,表31中的五個信息量按下列方式取值用戶輸入數用戶為軟件提供的輸入參數個數用戶輸出數軟件系統(tǒng)為用戶提供的輸出參數個數用戶查詢數一個聯(lián)機輸入確定一次查詢,軟件以聯(lián)機輸出的形式,實時地產生一個響應文件數統(tǒng)計邏輯的主文件個數外部界面數統(tǒng)計所有機器可讀的界面,利用這些界面可以將信息從一個系統(tǒng)傳送到另一個系統(tǒng),用功能點定義相應的概念生產率PFFP/E其中PF表示每人月完成的功能點數平均成本CIS/FP其中CI表示每功能點的平均成本文檔與功能點比DIPD/FP其中DI表示每個功能點平均具有的文檔頁數代碼出錯率EORINE/FP其中EORI表示每個功能點的平均錯誤個數,面向功能的度量,軟件規(guī)模的功能點度量沒有直接涉及軟件系統(tǒng)本身的算法復雜性。1986年JONES把軟件項目中的算法復雜性因素引入到功能點計算中來,為了避免混淆,我們把ALBRECHT定義的功能點稱為簡單功能點,用FPS表示,把JONES推廣的功能點稱為功能點,用FP表示。推廣的功能點包括計算機程序中用于各類問題求解的算法因素,如求解線性代數方程組、遍歷二叉樹的各個結點、處理中斷等等。功能點計算仍用上面的公式,其中CT按表32計算。,表32推廣的功能點度量,測量參數值權值用戶輸入數□4=□用戶輸出數□5=□用戶查詢數□4=□文件數□7=□外部界面數□7=□算法□3=□CT=□對一般的工程計算或事務處理軟件,用表31和表32兩種方法計算出來的FP值應該基本上相同對于比較復雜的軟件系統(tǒng)FP比FPS的值高20~35,面向功能的度量的優(yōu)缺點,優(yōu)點①與程序設計語言無關,它不僅適用于過程式語言,也適用于非過程式的語言;②軟件項目開發(fā)初期就能基本上確定系統(tǒng)的輸入、輸出等參數,功能點度量能用于軟件項目的開發(fā)初期。缺點①它涉及到的主觀因素比較多,如各種權函數的取值;②信息領域中的某些數據有時不容易采集;③FP的值沒有直觀的物理意義。,3114代碼行度量與功能點度量的比較,代碼行度量依賴于程序設計語言,而功能點度量不依賴于程序設計語言。ALBRECHT和JONES等人對若干軟件采用事后處理的方式分別統(tǒng)計出不同程序設計語言每個功能點與代碼行數的關系,用LOC/FP的平均值表示。表33表明,一行ADA語言代碼的“功能”平均是一行FORTRAN語言代碼“功能”的14倍。一行四代語言代碼的“功能”平均是一行傳統(tǒng)程序設計語言代碼“功能”的3至5倍。,表33各種語言的LOC/FP平均值,程序設計語言LOC/FP平均值匯編語言300COBOL100FORTRAN100PASCAL90ADA70面向對象的語言30四代語言4GL20代碼生成器15,312軟件復雜性度量,1976年TJMCCABEMCCABE度量法又稱環(huán)路復雜性度量,基于程序控制結構的軟件復雜性度量模型。程序控制結構圖程序結構對應于有一個入口結點和一個出口結點的有向圖圖中每個結點對應一個語句或一個順序流程的程序代碼塊弧對應于程序中的轉移它基于一個程序模塊的程序圖中環(huán)路的個數,因此計算它先要畫出程序圖。程序圖是退化的程序流程圖。流程圖中每個處理都退化成一個結點,流線變成連接不同結點的有向弧。,MCCABE度量法,MCCABE用程序控制結構圖的巡回秩數VG作為程序結構復雜性的度量VGEN2其中E為結構圖的邊數N為結構圖的結點數可以證明VG等于結構圖中有界或無界的封閉區(qū)域個數,例31計算程序控制結構的VG值,E1E3N2N3V1V2,,計算程序控制結構的VG值,E4E3N4N3V2V2,,計算程序控制結構的VG值,E6N5V3,,例31計算如圖所示程序控制結構圖的VG值。AE1,N2,V1BE3,N3,V2CE4,N4,V2;DE3,N3,V2EE6,N5,V3,,示例,在前面的例示中,N=11,M=13,VG=M-N+P=13-11+1=3P=1,MCCABE建議把VG作為模塊規(guī)模的定量指標,一個模塊VG的值不要大于10當VG10時,模塊內部結構就會變得復雜,給編碼和測試帶來困難。,這種度量的缺點是對于不同種類的控制流的復雜性不能區(qū)分簡單IF語句與循環(huán)語句的復雜性同等看待嵌套IF語句與簡單CASE語句的復雜性是一樣的模塊間接口當成一個簡單分支一樣處理一個具有1000行的順序程序與一行語句的復雜性相同,32軟件項目計劃與估算,321軟件項目計劃,軟件項目管理人員在開發(fā)工作一開始需要進行定量估算。軟件項目計劃的目標是提供一個能使項目管理人員對資源、成本和進度做出合理估算的框架。這些估算應當在軟件項目開始時的一個有限的時間段內做出,并且隨著項目的進展定期進行更新。,軟件項目計劃的目標,軟件的范圍,軟件范圍包括功能、性能、限制、接口和可靠性。估算開始時,應對軟件的功能進行評價,對其進行適當的細化以便提供更詳細的細節(jié)。由于成本和進度的估算都與功能有關,因此常常采用某種程度的功能分解。性能的考慮包括處理和響應時間的需求。約束條件則標識產品成本、外部硬件、可用存儲或其它現(xiàn)有系統(tǒng)對軟件的限制。軟件與其它系統(tǒng)元素是相互作用的。要考慮每個接口的性質和復雜性,以確定對開發(fā)資源、成本和進度的影響。,軟件開發(fā)中的資源,322軟件項目估算,常用的估算方法①參照已經完成的類似項目估算待開發(fā)項目的成本和工作量。②將大的項目分解成若干子項目,在估算出每個子項目成本和工作量之后,再估算整個項目。③將軟件項目按軟件生存周期分解,分別估算出軟件項目在軟件開發(fā)各個階段的工作量和成本,然后再把這些工作量和成本匯總估算整個項目。④根據實驗或歷史數據給出軟件項目工作量或成本的經驗估算公式。,四種方法可以同時、單獨或組合使用,以便取長補短,提高項目估算的精度和可靠性。采用分解技術估算軟件項目應考慮系統(tǒng)集成時需要的工作量。為了實現(xiàn)軟件項目估算,實踐中開發(fā)了大量的軟件項目自動估算工具,用以支持軟件工作量或成本估算。,分解技術采用”分而治之”的策略進行軟件項目估算將項目分解為若干個主要的功能及相關的軟件工程活動,通過逐步求精的方式進行成本及工作量估算。經驗估算模型可用于補充分解技術自動估算工具實現(xiàn)一種或多種分解技術或經驗模型,與人機交互結合,自動估算將是很好的選擇。,3221代碼行、功能點和工作量估算,軟件項目的規(guī)模是影響軟件項目成本和工作量的重要因素。軟件項目代碼行和功能點估算是成本和工作量估算的基礎。采用上面的估算方法可以估算出LOC或FP的樂觀值A,悲觀值B和一般值M,然后根據下列加權公式計算出期望值EA+4M+B/6希望LOC或FP的值落在區(qū)間[A,B]之外的概率極小,當LOC或FP的期望值估算出來之后,根據以前軟件項目開發(fā)的平均生產率LOC/PM或FP/PM就可以計算出工作量。如,軟件項目的規(guī)模估算為310FP,以前完成的軟件項目的生產率為55FP/PM,于是工作量估算為E310/5556PM。,例32估算計算機輔助設計軟件項目,將CAD項目按功能分解為七個子項目①用戶界面和控制;②二維幾何分析;③三維幾何分析;④數據庫管理;⑤計算機圖形顯示;⑥外設控制;⑦設計分析。表34給出七個子項目代碼行的樂觀估計、悲觀計和一般估計值,然后計算出加權平均值。,估算計算機輔助設計軟件項目,分析七個子項目的規(guī)模復雜性和難度,參照以前開發(fā)類似項目的經驗給出開發(fā)每行代碼的平均成本,每月開發(fā)的代碼行數。用這兩組數據計算出七個子項目的開發(fā)成本和工作量。最后匯總的CAD軟件開發(fā)項目規(guī)模為33360LOC成本為656680工作量為1445PM。,再用這兩種方法分別估算軟件開發(fā)子項目在軟件工程各個階段的工作量,估算結果列入表35。兩種方法估算的工作量分別為1445PM和1525PM,相差5左右。估算的成本分別為656680和708075,相差7左右。兩種方法估算的工作量和成本基本一致。,表34代碼行和成本、工作量估算,功能樂觀一般悲觀加權LOC成本工作量LOCLOCLOC平均/LOC/PM$人月用戶界面控制1790240026502340143153276074二維幾何分析408052007400538020220107600244三維幾何分析460069008600680020220136000309數據庫管理29003400360033501824060300139圖形顯示390049006200495022200108900247外設控制19902100245021402814059920152設計分析660085009800840018300151200280總計333606566801445,表35工作量估算,功能需求分析設計編碼測試總計用戶界面控制102005357二維幾何分析20100459526三維幾何分析2512060110315數據庫管理2060304015計算機圖形顯示151104010527外設控制1560355016設計分析40140507030總計人月145612655051525每人月成本5200480042504500成本$75400292800112625227250708075,3222經驗估算模型之一COCOMO模型,計算機軟件的估算模型是根據以前完成項目的實際數據導出的,用于軟件項目的計劃階段。模型是根據“從前的”,“局部的”數據得出的,估算模型不可能完全適用于當前所有的軟件項目和全部開發(fā)環(huán)境。這些模型的計算結果僅供參考。兩個常用的估算模型COCOMO模型PUTNAM模型,COCOMO模型,1981年BOEHM提出“構造性成本模型”CONSTRUCTIVECOSTMODEL,簡稱COCOMO模型。它是在靜態(tài)、單變量模型的基礎上構造出來的。COCOMO模型分為基本、中間、詳細三個層次,分別用于軟件開發(fā)的三個不同階段?;綜OCOMO模型用于系統(tǒng)開發(fā)的初期,估算整個系統(tǒng)的工作量包括軟件維護和軟件開發(fā)所需要的時間。中間COCOMO模型用于估算各個子系統(tǒng)的工作量和開發(fā)時間。詳細COCOMO模型用于估算獨立的軟部件,如子系統(tǒng)內部的各個模塊。,1基本COCOMO模型,靜態(tài)、單變量模型EALB31DCED32其中E表示工作量,單位是人月PM。D表示開發(fā)時間,單位是月M。L是項目的代碼行估計值,單位是千行代碼A,B,C,D是常數,取值如表36所示。BOEHM把軟件劃分為組織型、半獨立型和嵌入型三類,允許不同應用領域和復雜程度的軟件按照三類軟件的適用范圍選取相應的參數A,B,C,D。給出了代碼行數與工作量、工作量與開發(fā)時間之間的函數關系,表36簡單COCOMO模型參數,軟件類型ABCD適用范圍組織型2410525038各類應用程序半獨立型3011225035各類實用程序、編譯程序等嵌入型3612025032實時處理、控制程序、操作系統(tǒng),2中間COCOMO模型,中間COCOMO模型以基本COCOMO模型為基礎,在工作量估計公式中乘以工作量調節(jié)因子EAFEALBEAF33其中L是軟件產品的目標代碼行數A,B是常數,取值如表37所示。,中間COCOMO模型,表37中間COCOMO模型參數軟件類型AB組織型32105半獨立型30112嵌入型28120,COCOMO模型,工作量調節(jié)因子EAF與軟件產品屬性、計算機屬性、人員屬性、項目屬性有關軟件產品屬性軟件可靠性、軟件復雜性、數據庫的規(guī)模。計算機屬性程序執(zhí)行時間、程序占用內存的大小、軟件開發(fā)環(huán)境的變化、軟件開發(fā)環(huán)境的響應速度。人員屬性分析員的能力、程序員的能力、有關應用領域的經驗、開發(fā)環(huán)境的經驗、程序設計語言的經驗項目屬性軟件開發(fā)方法的能力,軟件工具的質量和數量、軟件開發(fā)的進度要求。,COCOMO模型,四種屬性共15個要素。每個要素調節(jié)因子FI,I1,2,,15,的值分為很低、低、正常、高、很高、極高,共六級。正常情況下FI1。BOEHM推薦的FI值范圍070,085,100,115,130,165當15個FI的值選定后,EAF的計算如下EAF=F1F2F15,COCOMO模型,調節(jié)因子集的定義和調節(jié)因子定值是由統(tǒng)計結果和經驗決定的。不同的軟件開發(fā)組織,在不同的歷史時期,隨著環(huán)境的變化,這些數據可能改變。使用中間COCOMO模型可以估算開發(fā)軟件產品的工作量,比較各種開發(fā)方案的工作量。,例33用基本COCOMO模型估算例32,工作量、開發(fā)時間和項目開發(fā)人數在例32中,目標代碼行數為333KLOCCAD軟件開發(fā)屬于中等規(guī)模、半獨立型從表37中查到A30,B112。代入公式31E30*L11230*333112152PM,將E的估算值代入公式32取C25D035D25*E03525152035145M建議參加項目開發(fā)的人數NE/D152/145≈11例中計算出來的11人是粗略估計在軟件項目開發(fā)過程中,11個人不可能都有相同的能力和個性,相同的經驗和知識結構,并且在軟件開發(fā)的各個階段對人的要求也不同。,COCOMO模型,若干人共同開發(fā)一個軟件項目還應該增加他們之間相互通信和交換意見的額外工作量。設N個程序員組成小組,實現(xiàn)相同規(guī)模的程序,相互通信數為NN1/2每次通信和交換意見的平均工作量為Μ則增加的通信開銷為EC=ΜNN1/234,,例34計算一個程序的通信開銷,3人和5人開發(fā)一個程序相互通信和交換意見的關系如圖所示將N3和N5分別代入公式34EC3=Μ331/2=3ΜEC5=Μ551/2=10Μ,,COCOMO模型,由N個程序員組成的小組共同開發(fā)一個程序總的工作量ET滿足ETEEC35程序員小組的生產率是PGLOC/EEC36程序員小組生產率和單個程序員生產率的比為RPE/EEC37隨著程序員小組人數的增加,EC≈ΜN2/2,程序員小組的生產率將會下降。模型表明盲目增加程序員人數會推遲軟件完成的日期,3223經驗估算模型之二PUTNAM模型,1978年,PUTNAM提出了大型軟件項目工作量一般在30人年以上估算模型。它是一個動態(tài)多變量模型,適用于軟件開發(fā)的各個階段,估算模型以大型軟件項目的實測數據為基礎,導出工作量分布曲線。該曲線與著名的RAYLEIGHNORDENRN曲線相似,它描述了開發(fā)工作量,開發(fā)時間和軟件代碼行數之間的關系。,PUTNAM模型,方程LCKE1/3TD4/338其中L表示源程序代碼行數TD表示開發(fā)時間CK表示技術狀態(tài)常數E表示工作量以人年記,包括維護,PUTNAM模型揭示了軟件項目的工作量、軟件開發(fā)時間和程序代碼長度三者之間的關系,PUTNAM模型,差的軟件開發(fā)環(huán)境軟件開發(fā)沒有方法學的支持,缺乏對文檔的評審,采用批處理方式。一般的軟件開發(fā)環(huán)境應有軟件開發(fā)方法學的支持,有適宜的文檔和評審,采用交互處理方式。好的軟件開發(fā)環(huán)境應采用CASE工具和集成化CASE環(huán)境。CK2000比較差的軟件開發(fā)環(huán)境8000一般的軟件開發(fā)環(huán)境11000比較好的軟件開發(fā)環(huán),,PUTNAM模型,由218334E=L/CKTD39TD對應于RAYLEIGHNORDEN曲線的最大值,表示軟件交付時工作量最大,參與軟件項目的人最多。當工作量估算出來之后,利用每人年的開銷/PY可以估算成本。公式39表明,開發(fā)軟件項目的工作量與交貨時間的4次方成反比,將09TD代替39式的TD計算E發(fā)現(xiàn),提前10的時間要增加52的工作量,降低了軟件開發(fā)生產率。軟件開發(fā)過程中人員與時間的折衷是一個十分重要的問題。,PUTNAM模型,,331風險分析,風險的概念風險與將要發(fā)生的事情有關,研究風險就是研究明天將要發(fā)生的事情風險涉及思想、觀念、行為、地點、時間等多種因素風險隨條件的變化而改變,人們通過改變、選擇、控制與風險密切相關的條件減少、回避風險改變、選擇、控制條件的策略是不確定的,33風險分析和管理,軟件風險,軟件風險和其它風險一樣存在不確定性,有些是很難預測的。對風險的不確定性進行量化,估算某一風險可能帶來的損失。除關注軟件項目的一般性風險外,還要關注軟件項目的特殊風險,如項目的背景、特殊要求、關鍵內容、薄弱環(huán)節(jié)、技術難點、人員狀況、工作環(huán)境等。,軟件項目存在各種風險,人們關心的問題什么風險會導致軟件項目的徹底失敗顧客需求、開發(fā)環(huán)境、目標機、時間、成本的改變對軟件項目的風險會產生什么影響人們必須抓住什么機會、采取什么措施才能有效地減少風險、順利完成任務,不同類型的風險,項目風險預算、進度、人力、資源、客戶及需求項目的復雜度、規(guī)模、結構的不確定性等技術風險設計、實現(xiàn)、接口、驗證和維護規(guī)約的二義性、技術的不確定性、陳舊的技術、領先的技術商業(yè)風險無需求的產品、策路風險、管理風險、預算風險,軟件風險分析包括的部分風險標識風險估算風險規(guī)劃風險監(jiān)控,軟件風險分析,1風險標識,對待風險不能采取回避態(tài)度項目開始時應對一般性風險和特定產品風險進行系統(tǒng)標識,並隨著項目的展開不斷更新。一般可預測風險產品規(guī)模、商業(yè)影響、客戶、過程、技術、環(huán)境、人員及經驗等。識別風險的有效方法風險檢測表為了幫助項目管理人員、項目規(guī)劃人員,全面了解軟件開發(fā)過程存在的風險,BOEHM建議設計并使用各類風險檢測表,表中條目指明,常見並可預測的風險。有些風險可以預料,有些很難預料。,例36人員配備風險檢測表,1開發(fā)人員的水平如何。2開發(fā)人員在技術上是否配套。3開發(fā)人員的數量如何。4開發(fā)人員是否能夠自始至終地參加軟件開發(fā)工作。5開發(fā)人員是否能夠集中全部精力投入到軟件開發(fā)工作。6開發(fā)人員對自己的工作是否有正確的期望。7開發(fā)人員是否接受過必要的培訓。8開發(fā)人員的流動是否能夠保證工作的連續(xù)性。上述問題可以選用0,1,2,3,4,5來回答。完全肯定取值為0,反之為5,中間情況分別取值1,2,3,4值越大表示風險越大。人員配備風險檢測表反映了人的因素給軟件項目帶來的風險。,2風險估算,如果某一風險檢測表由M項組成,每項選取一個整數值0,1,,N,在最理想的情況取值為0,反之取值為N,對于中間狀態(tài)依次取值1,2,,N1當N1時取值0,1,對應布爾量真/假T/F設第I種風險檢測表第J項取值XIJ,對應的加權系數是WIJ,于是第I種風險的估算值可以定義為MΣI=∑WIJXIJ/MNJ1其中∑WIJ=M,WIJ≥0310,風險估算,如果第I種風險對整個軟件項目的風險估算加權系數是ΡI,I1,2,,L為風險要素的個數,∑ΡI=1,則軟件項目風險估算定義為LR=∑ΡIΣI311I10≤R≤1當R接近于0時表示風險比較小,R接近于1時表示風險比較大。當ΡIΣI比較大時,表示第I類風險出現(xiàn)并帶來不良影響的可能性比較大,必須引起足夠重視,設法改善條件,減小ΣI的值。,3風險評價和管理,風險評價是風險管理的重要步驟任務進一步審查風險預測的精度;更新風險優(yōu)先次序;考慮控制和/或避免可能發(fā)生風險的辦法。,風險評價,定義用三元組RI,LI,XI描述風險,I1,2,3其中RI表示風險LI表示風險發(fā)生的概率XI表示風險產生的影響對大多數軟件項目,應該定義性能、成本及進度的風險參考水平值,當某一風險或風險組合值超過水平值時項目被迫停止。,風險評估的步驟,1定義項目的風險參考水平值;2建立三元組,給出相應的參考水平值;3預測一組臨界點,定義項目終止區(qū)域;4預測什么樣的風險組合會影響參考水平值,風險表(1/3),風險類別概率影響RMMM123項目開始時應在第一列列出所有風險第二列給出風險類別;第三列給出每種風險發(fā)生的概率;第四列給出各種風險產生影響的評估值;第五列給出風險緩解、監(jiān)控和管理計劃。,風險表(2/3),評估值按風險因素性能、成本、進度的影響類別求加權平均值影響類別取值災難的1,嚴重的2,輕微的3,可忽略的4。對風險表中的風險按照發(fā)生概率大小、影響大小,由大至小排序。,風險表(3/3),項目管理者對風險表進行研究后應定義一條中止線,線上的風險較大者應給予特別的關注,線下的風險需要進一步的跟蹤、評估、排序。對風險發(fā)生概率較大的事件應引起特別關注,要及早采取措施盡量避免它的發(fā)生。,,風險評價和管理,三元組[RI,LI,XI]是風險管理的基礎設高級職員流動給項目帶來風險R1,根據歷史的經驗或直觀感覺,高級職員離開課題組的概率L170,這一風險導致事件X1發(fā)生項目開發(fā)時間延長15,成本增加20.,項目負責人采取的風險管理措施,1項目開始前控制產生風險的原因。項目開工后應設法減輕風險的影響。2了解項目開發(fā)人員變動的原因,在項目開發(fā)期間應控制上述原因,盡量減少人員的流動。3在工作方法和技術上采取適當措施,防止因人員流動給工作帶來損失。4項目在開發(fā)過程中應及時公布并交流項目開發(fā)的信息。5建立組織機構,確定文檔標準、并及時生成文檔。6對工作進行集體復審,使多數人都能了解工作的細節(jié),跟上工作進度。7為關鍵技術準備后備人員。,RMMM計劃,風險緩解、監(jiān)控和管理計劃RISKMITIGATION,MONITORING,ANDMANAGEMENTPLAN將風險分析工作文擋化,成為項目的一部分。執(zhí)行RMMM計劃需要成本當軟件項目比較大時,可能標出30至40種風險,如果為每種風險定義3至7種風險管理步驟,則風險管理本身就是一個項目。將PA
下載積分: 4 賞幣
上傳時間:2024-01-06
頁數: 113
大?。?1.17(MB)
子文件數: