軟件項目計劃完整

1、第 3 章 軟件項目計劃3.1風(fēng)險分析教學(xué)內(nèi)容：風(fēng)險標(biāo)識、風(fēng)險估計、風(fēng)險評價和風(fēng)險管理與監(jiān)控。教學(xué)重點：風(fēng)險標(biāo)識。教學(xué)難點：風(fēng)險估計。教學(xué)方法：課堂講授 + 討論。教學(xué)要求：掌握風(fēng)險標(biāo)志方法，了解風(fēng)險估計和評價，理解風(fēng)險管理。思 考 題：為何要對軟件項目進行風(fēng)險分析？風(fēng)險標(biāo)識風(fēng)險發(fā)生的“不確定性”和風(fēng)險發(fā)生后帶來的“損失”是風(fēng)險包含的兩個重要 特性。在進行風(fēng)險分析時重要的是量化“不確定性”的大小和與每個風(fēng)險相關(guān)的 “損失”的程度。風(fēng)險標(biāo)識是進行風(fēng)險分析的第一步。從宏觀上來看，可將風(fēng)險分為 3 類，即項目風(fēng)險、技術(shù)風(fēng)險和商業(yè)風(fēng)險。另一種常用風(fēng)險分類方式由Charette提出，將風(fēng)險分為了 3類：

2、已知風(fēng)險、可預(yù)測風(fēng)險和不可預(yù)測風(fēng)險。一種識別風(fēng)險的好辦法便是得用一組提問幫助項目計劃人員了解在項目和計劃 方面存在哪些風(fēng)險。Boehm建議使用一個“風(fēng)險項目檢查表”， 列出所有可能的 與每個風(fēng)險因素有關(guān)的提問，從以下幾個方面識別已知的或可預(yù)測的風(fēng)險。 產(chǎn)品規(guī)模 商業(yè)影響 客戶特性 過程定義 開發(fā)環(huán)境 建造技術(shù) 人員數(shù)量及經(jīng)驗風(fēng)險估計風(fēng)險估計主要有兩個方面的工作， 一是估計風(fēng)險發(fā)生的可能性， 另外是估計與風(fēng) 險相關(guān)的問題出現(xiàn)后將會帶來的損失。 為此， 項目計劃人員、 其它管理人員和技 術(shù)人員一起進行四種風(fēng)險估計活動， 即建立一個尺度或標(biāo)準(zhǔn)來表示一個風(fēng)險的可 能性；描述風(fēng)險的結(jié)果； 估計風(fēng)險對項目

3、和產(chǎn)品的影響； 確定風(fēng)險估計的正確性， 給出風(fēng)險估計的定量結(jié)果。估計每個風(fēng)險所產(chǎn)生的影響時， 對 4 個風(fēng)險因素：性能（即產(chǎn)品能夠滿足需求且 符合其使用目的的不確定程度） 、成本（即項目預(yù)算能夠被維持的不確定程度） 、 支持（即軟件易于糾錯、適應(yīng)及增強的不確定程度）和進度（即項目進度能夠被 維持且產(chǎn)品能按時交付的不確定程度） ，分別確定影響類別（即災(zāi)難的、 嚴(yán)重的、 輕微的和可忽略的），并求平均或加權(quán)平均，得到一個整體的影響值。 不同的風(fēng)險發(fā)生后對項目造成的影響各不相同， 主要有 3個方面需要考慮， 即風(fēng) 險的性質(zhì)（風(fēng)險發(fā)生時可能產(chǎn)生的問題）、風(fēng)險的范圍（風(fēng)險的嚴(yán)重性及總的分 布，如項目的多少

4、部分或有多少用戶受到損害等）、風(fēng)險的時間（何時能感受到 風(fēng)險及風(fēng)險持結(jié)多長時間） 。據(jù)此確定風(fēng)險估計的加權(quán)系數(shù)， 以得到項目的風(fēng)險 估計風(fēng)險評價ri, pi, ei,其中 ri在風(fēng)險評價時，可根據(jù)風(fēng)險估計的結(jié)果，建立一系列三元組：表示風(fēng)險，pi表示風(fēng)險出現(xiàn)的概率，ei表示風(fēng)險產(chǎn)生的影響，i=1,2,表示風(fēng)險的序號,假定軟件項目共有 M 種風(fēng)險。要對項目風(fēng)險進行評價， 必須定義一個風(fēng)險參考水準(zhǔn)。 對于大多數(shù)項目而言， 性 能、成本、支持和進度就是典型的風(fēng)險參考水準(zhǔn)。對于性能下降、成本超支、支 持困難或進度延遲， 都有一個水準(zhǔn)值的要求， 超出它就會導(dǎo)致項目被迫終止。 在 軟件項目的風(fēng)險分析中， 一

5、個風(fēng)險參考水準(zhǔn)存在一個單獨的點， 稱之為參考點或 臨界點，在該點上決定繼續(xù)或終止（如果問題較大）該項目都是可以接受的，但 超過它時會引起項目終止。通常，風(fēng)險評價可分為如下4 步： 定義項目的各種風(fēng)險參考水準(zhǔn)，如成本、進度等； 找出每個ri, pi, ei與各參考水準(zhǔn)之間的關(guān)系； 預(yù)測一組臨界點以定義項目的終止區(qū)，該區(qū)由一條曲線或易變動區(qū)域來界定； 預(yù)測怎樣的風(fēng)險組合，會影響參考水準(zhǔn)。3.1.4 風(fēng)險管理與監(jiān)控 風(fēng)險管理是指利用某些技術(shù)，如原型化、軟件自動化、可靠性工程學(xué)，以及某些 項目管理方法等設(shè)法避免或轉(zhuǎn)移風(fēng)險。與每種風(fēng)險相關(guān)的三元組ri, pi, ei是風(fēng)險管理的基礎(chǔ)。例3-1設(shè)項目組高級

6、職員流動給項目帶來的風(fēng)險為 r1,基于過去的歷史和管理經(jīng) 驗，高級職員離開項目組的概率為p仁70%；該風(fēng)險帶來的影響el的估計值使項 目開發(fā)時間增加 25%，項目的成本增加 30%。為了管理這一風(fēng)險， 項目管理者必 須制訂一些策略，一種可能的風(fēng)險管理策略如下： 與現(xiàn)有人員探討人員流動的原因， 在項目開發(fā)期間控制這些原因， 盡量減少人 員的流動； 在項目開始前，采取行動緩解在管理控制之下的原因； 項目啟動時做好人員流動的準(zhǔn)備； 對項目進行良好的組織，使每一開發(fā)活動的信息能被廣泛傳播和交流； 制定文檔標(biāo)準(zhǔn)并建立相應(yīng)機制，確保文檔能被及時建立； 對所有工作進行詳細(xì)復(fù)審，使大多數(shù)人能了解工作細(xì)節(jié)，跟上

7、工作進度； 對每個關(guān)鍵的技術(shù)人員均指定后備人員。實施風(fēng)險管理策略會帶來一些額外的開銷。 項目管理人員或計劃人員要對風(fēng)險管 理策略的實施進行成本 / 效益分析。僅當(dāng)實施風(fēng)險管理策略所需的成本小于風(fēng)險 管理帶來的效益（即風(fēng)險帶來的影響）時才可考慮實施風(fēng)險管理策略。例如 3-1 實施其對應(yīng)的風(fēng)險管理策略僅增加 2%的成本和 4%的開發(fā)時間，而風(fēng)險帶來的影 響的估計值使項目開發(fā)時間增加 25%，成本增加 30%，從而管理或計劃人員應(yīng)考 慮實施有關(guān)風(fēng)險管理策略。從風(fēng)險管理的角度來看， 風(fēng)險發(fā)生的概率和風(fēng)險影響起著不同的作用。 一個具有 高影響但發(fā)生概率很低的風(fēng)險不應(yīng)該花太多的管理成本。 而高影響且發(fā)生概

8、率為 中到高的風(fēng)險以及低影響且高發(fā)生概率的風(fēng)險，應(yīng)該首先列入管理的考慮之中。 同時，對于有些已標(biāo)出、 評估及預(yù)測過的風(fēng)險可能也不納入風(fēng)險管理的考慮。 按 照Pareto的80-20規(guī)則，80%的軟件風(fēng)險能夠由僅僅20%的已標(biāo)出風(fēng)險來說明。 隨著項目的進展，風(fēng)險監(jiān)控活動便開始了，風(fēng)險監(jiān)控是一種追蹤活動，主要有 3個目標(biāo)： 事件和主要風(fēng)險因素的跟蹤，判斷一個預(yù)測的風(fēng)險事實上是否發(fā)生了； 風(fēng)險估計，確保針對某個風(fēng)險制定的風(fēng)險管理措施正在實施； 收集可用于將來風(fēng)險分析的信息。在例 3-1中，應(yīng)該監(jiān)控：項目組成員對于項目壓力的一般態(tài)度， 項目組的凝聚力；項目組成員之間的關(guān)系； 與利益相關(guān)的潛在問題； 在

9、公司內(nèi)外工作的可能性； 等3.2 進度安排教學(xué)內(nèi)容：進度安排的基本原則、工作量分配、PERT技術(shù)、Gantt圖技術(shù)。教學(xué)重點：PERT技術(shù)、Gantt圖技術(shù)。教學(xué)難點：PERT技術(shù)。教學(xué)方法：課堂講授 +習(xí)題。教學(xué)要求：掌握PERT技術(shù)和Gantt技術(shù)，了解進度安排的基本原則。3.2.1 進度安排的基本原則同軟件工程的其它方面一樣， 有一些基本原則可以用來指導(dǎo)軟件項目計劃的進度 安排。 任務(wù)分解：將軟件工程項目的任務(wù)分解成易管理的子任務(wù)，即作業(yè)； 作業(yè)依存：確保作業(yè)間的依存關(guān)系一一順序和并發(fā)； 時間分配：為每個作業(yè)指定開始和終止時間； 資源約束：在進行時間分配時應(yīng)考慮資源約束，如人員數(shù)量、工具

10、; 定義責(zé)任：應(yīng)指定某特定小組負(fù)責(zé)某個作業(yè)； 定義結(jié)果：對每個作業(yè)定義相應(yīng)的結(jié)構(gòu)產(chǎn)品或產(chǎn)品的一部分; 定義里程碑：每個作業(yè)或作業(yè)系列應(yīng)與項目的里程碑相聯(lián)系。隨著項目進度的發(fā)展，上述每條原則都可能用到。3.2.2 工作量分配在可行性研究階段， 通過成本估算方法獲得了完成某項軟件開發(fā)任務(wù)所需工作量 的估計值。 在制訂軟件項目計劃時， 需要將工作量的估計值在軟件定義與開發(fā)階 段進行分配。另一種稱為“ -4200-40規(guī)則”的工作量分配建議方案認(rèn)為：在整個軟件開發(fā)過程 中，編碼的工作量約占 20%，編碼前的工作量占 40%，編碼后的工作量也占 40%， 顯然，這一工作量分配方案不強調(diào)編碼工作。 實驗上

11、， 現(xiàn)在對于大型軟件項目而 言，編碼的工作量所占分額還在進一步縮小。對實際開發(fā)的軟件項目進行統(tǒng)計表明； 一般在計劃階段所需工作量很少超過項目 總工作量的 2%3%，除非是具有高風(fēng)險的巨資項目；需求分析可能占用項目工 作量的 10%25%,用于分析或原型開發(fā)的工作量與項目規(guī)模和復(fù)雜度成正比增 長；通常有 20%25%的工作量用于軟件設(shè)計， 包括設(shè)計評審和迭代修改的時間； 由于設(shè)計時投入了相當(dāng)?shù)墓ぷ髁?，使編碼工作變得相對簡單些，用15%20%的工作量就可以完成；測試和隨后的調(diào)試工作約占 30%40%的工作量，且測試的 工作量取決于軟件的質(zhì)量特性要求，如可靠性程度等。3.2.3 進度安排方法 軟件項

12、目的進度安排與任何一個工程項目的進度安排沒有實質(zhì)上的不同。 首先識 別一組項目任務(wù)作業(yè)， 建立任務(wù)作業(yè)之間的相互關(guān)聯(lián)， 然后估算各個任務(wù)的工作 量，分配人力和其它資源， 指定進度時序。 原則上可以把一般工程項目的進度安 排方法和工具應(yīng)用于軟件工程項目。 下面主要介紹兩種方法， PERT 技術(shù)和 Gantt 圖方法。1PERT 技術(shù)PERT 技術(shù)( Program Evaluation & Review Techniqu，ePERT) 又叫計劃評審技術(shù)。20 世紀(jì) 50 年代后期，美國海軍和洛克希德公司首次提出這一技術(shù)，并成功地應(yīng) 用于北極星導(dǎo)彈的研究和開發(fā)。 幾十年來，它在許多工程領(lǐng)域

13、獲得了廣泛的應(yīng)用， 有時也因此稱之為工程網(wǎng)絡(luò)技術(shù)。2Gantt 圖方法Gantt 圖，又稱橫道圖，用水平線段來描述各作業(yè)的進度安排。一般在每一作業(yè) 的起始時刻和約束時刻各畫一個小三角形， 當(dāng)作業(yè)開始或結(jié)束時， 把小三角形涂 黑。 Gantt 圖的橫軸列出的是日歷時間，縱軸列出的是作業(yè)名稱。3.3 項目組織教學(xué)內(nèi)容：人員組織規(guī)律、人員組織形式。教學(xué)重點：人員時間權(quán)衡定律、 Brooks 定律。教學(xué)難點：矩陣模式組織結(jié)構(gòu)。教學(xué)方法：課堂講授。教學(xué)要求： 了解人員組織規(guī)律，熟悉人員組織形式 思 考 題：為何向已經(jīng)延期的項目增加開發(fā)人員反而會使項目更加延期？為何軟 件開發(fā)人員應(yīng)該少而精？3.3.1 人

14、員組織規(guī)律對于一個軟件項目而言， 單個軟件專業(yè)人員不可能在有限時間內(nèi)單獨完成。 如何 合理地組織這些人員參與軟件的開發(fā)是項目成敗的關(guān)鍵。 為此，軟件項目管理者 應(yīng)該重視軟件項目的人員組織規(guī)律，不能簡單地對待。1. Rayleigh-Norden曲線以Rayleigh爵士的名字命名的曲線本來是用于解釋某些科學(xué)現(xiàn)象的。1958年，Norden 發(fā)現(xiàn)該曲線可用來說明科研及項目開發(fā)在實施過程中人力的需求。 1976 年,Put nam又發(fā)現(xiàn)在軟件生存期各階段所需的人力分配具有與 Rayleigh曲線十分 相似的形狀。2. 兩條定律Putnam在對Raleigh曲線進行大量研究的基礎(chǔ)了，提出了 Putn

15、am模型。該模型 指出，軟件開發(fā)工作量與軟件開發(fā)時間的 4次方成反比，Put nam將這一結(jié)論稱 之為“軟件開發(fā)的人員時間權(quán)衡定律”。3.3.2 人員組織形式人員組織是一切軟件項目管理的關(guān)鍵。 無法想象一個松散、 責(zé)任不明確的一伙人在一起可以高效地開發(fā)軟件。 軟件開發(fā)機構(gòu)選擇怎樣的人員組織形式， 要針對軟 件項目的特點和參與人員的素質(zhì)來決定。 在建立軟件開發(fā)組織時， 應(yīng)注意： 責(zé)任 到人盡早將責(zé)任落實， 便于管理； 合理分工減少不必要的通信， 提高工 作效率； 責(zé)權(quán)均衡責(zé)任與權(quán)力的平衡， 有助于任務(wù)的完成。 就軟件項目的組 織結(jié)構(gòu)而言，通常有兩種模式可供選擇。（1）層次模式層次模式是一種傳統(tǒng)的

16、管理結(jié)構(gòu)， 每一層人員向上層報告工作并且管理下層的人 員。（2）矩陣模式矩陣模式實際是層次模式的擴展， 一方面每個項目有一個項目經(jīng)理管理， 另一方 面，每一個項目又分為若干階段，按受階段經(jīng)理的管理。對于層次模式中的小組和矩陣模式中的子項的組織，主要有三種組織形式。 （1）主程序小組主程序員小組組織形式最早由 H. Mills提出，并由Baker描述出來，小組主要由 以下人員組成： 1名主程序員； 2-5名技術(shù)人員； 1 名后備程序員。（2）民主小組1971年Weinberg首次描述了民主小組的組織形式。民主小組一般由5-7人組成,其中 1 人兼任組長。民主小組的最基本概念是“無我程序設(shè)計”（

17、egoless programming，人人把小組開發(fā)的程序看成是“我們的”程序，而不是“我的”程序。遇到問題時， 組員之間可以平等地交換意見， 從而可以充分發(fā)揮每個成員 工作的積極性。（ 3）層次小組在層次小組內(nèi)， 人員分成三個層次：項目負(fù)責(zé)人（組長） 1 人，負(fù)責(zé)全組的工作， 直接管理 2-3 名高級程序員；每位高級程序員下屬若干名程序員，負(fù)責(zé)子課題的 有關(guān)工作。3.4小結(jié) 軟件項目計劃是繼可行性研究之后軟件工程管理的重要組成部分， 主要內(nèi)容包括 風(fēng)險分析、進度安排和項目組織。風(fēng)險分析是軟件項目計劃的一個主要成部分之一。 當(dāng)對軟件項目期望很高時， 均 會進行風(fēng)險分析活動， 不過大多數(shù)軟件項目管理者會非正式地完成它。 標(biāo)識、估 計、評價和管理風(fēng)險有可能會占用較多的項目計劃工作量。 但由于經(jīng)過風(fēng)險分析， 能夠做到“知已知彼”（彼即風(fēng)險），從而“百戰(zhàn)不殆”，使得開發(fā)者能夠戰(zhàn)勝 風(fēng)險帶來的損失，使項目成功。進度安排是軟件項目計劃的關(guān)鍵組成部分。 實際工作中， 進度安排的落空不僅會 造成項目開發(fā)成本的提高， 造成有形的經(jīng)濟損失， 而且會使客戶的不滿意度、 不 信任度增，造成有形的經(jīng)濟損失。借助 PERT技