3.1風險分析
教學內容：風險標識、風險估計、風險評價和風險管理與監控。
教學重點：風險標識。
教學難點：風險估計。
教學方法：課堂講授+討論。
教學要求：掌握風險標誌方法，了解風險估計和評價，理解風險管理。
思考題：為何要對軟體專案進行風險分析？
3.1.1風險標識
風險發生的「不確定性」和風險發生後帶來的「損失」是風險包含的兩個重要特性。在進行風險分析時重要的是量化「不確定性」的大小和與每個風險相關的「損失」的程度。風險標識是進行風險分析的第一步。
從巨集觀上來看，可將風險分為3類，即專案風險、技術風險和商業風險。另一種常用風險分類方式由charette提出，將風險分為了3類：已知風險、可**風險和不可**風險。
一種識別風險的好辦法便是得用一組提問幫助專案計畫人員了解在專案和計畫方面存在哪些風險。boehm建議使用乙個「風險專案檢查表」，列出所有可能的與每個風險因素有關的提問，從以下幾個方面識別已知的或可**的風險。
①產品規模
②商業影響
③客戶特性
④過程定義
⑤開發環境
⑥建造技術
⑦人員數量及經驗
3.1.2風險估計
風險估計主要有兩個方面的工作，一是估計風險發生的可能性，另外是估計與風險相關的問題出現後將會帶來的損失。為此，專案計畫人員、其它管理人員和技術人員一起進行四種風險估計活動，即建立乙個尺度或標準來表示乙個風險的可能性；描述風險的結果；估計風險對專案和產品的影響；確定風險估計的正確性，給出風險估計的定量結果。
估計每個風險所產生的影響時，對4個風險因素：效能（即產品能夠滿足需求且符合其使用目的的不確定程度）、成本（即專案預算能夠被維持的不確定程度）、支援（即軟體易於糾錯、適應及增強的不確定程度）和進度（即專案進度能夠被維持且產品能按時交付的不確定程度），分別確定影響類別（即災難的、嚴重的、輕微的和可忽略的），並求平均或加權平均，得到乙個整體的影響值。
不同的風險發生後對專案造成的影響各不相同，主要有3個方面需要考慮，即風險的性質（風險發生時可能產生的問題）、風險的範圍（風險的嚴重性及總的分布，如專案的多少部分或有多少使用者受到損害等）、風險的時間（何時能感受到風險及風險持結多長時間）。據此確定風險估計的加權係數，以得到專案的風險估計。
3.1.3風險評價
在風險評價時，可根據風險估計的結果，建立一系列三元組：[ri, pi, ei]，其中ri表示風險，pi表示風險出現的概率，ei表示風險產生的影響，i=1,2,…,m表示風險的序號，假定軟體專案共有m種風險。
要對專案風險進行評價，必須定義乙個風險參考水準。對於大多數專案而言，效能、成本、支援和進度就是典型的風險參考水準。對於效能下降、成本超支、支援困難或進度延遲，都有乙個水準值的要求，超出它就會導致專案被迫終止。
在軟體專案的風險分析中，乙個風險參考水準存在乙個單獨的點，稱之為參考點或臨界點，在該點上決定繼續或終止（如果問題較大）該專案都是可以接受的，但超過它時會引起專案終止。通常，風險評價可分為如下4步：
①定義專案的各種風險參考水準，如成本、進度等；
②找出每個[ri, pi, ei]與各參考水準之間的關係；
③**一組臨界點以定義專案的終止區，該區由一條曲線或易變動區域來界定；
④**怎樣的風險組合，會影響參考水準。
3.1.4 風險管理與監控
風險管理是指利用某些技術，如原型化、軟體自動化、可靠性工程學，以及某些專案管理方法等設法避免或轉移風險。與每種風險相關的三元組[ri, pi, ei]是風險管理的基礎。
[例3-1]設專案組高階職員流動給專案帶來的風險為r1，基於過去的歷史和管理經驗，高階職員離開專案組的概率為p1=70%；該風險帶來的影響e1的估計值使專案開發時間增加25%，專案的成本增加30%。為了管理這一風險，專案管理者必須制訂一些策略，一種可能的風險管理策略如下：
①與現有人員**人員流動的原因，在專案開發期間控制這些原因，儘量減少人員的流動；
②在專案開始前，採取行動緩解在管理控制之下的原因；
③專案啟動時做好人員流動的準備；
④對專案進行良好的組織，使每一開發活動的資訊能被廣泛傳播和交流；
⑤制定文件標準並建立相應機制，確保文件能被及時建立；
⑥對所有工作進行詳細複審，使大多數人能了解工作細節，跟上工作進度；
⑦對每個關鍵的技術人員均指定後備人員。
實施風險管理策略會帶來一些額外的開銷。專案管理人員或計畫人員要對風險管理策略的實施進行成本/效益分析。僅當實施風險管理策略所需的成本小於風險管理帶來的效益（即風險帶來的影響）時才可考慮實施風險管理策略。
例如[3-1]實施其對應的風險管理策略僅增加2%的成本和4%的開發時間，而風險帶來的影響的估計值使專案開發時間增加25%，成本增加30%，從而管理或計畫人員應考慮實施有關風險管理策略。
從風險管理的角度來看，風險發生的概率和風險影響起著不同的作用。乙個具有高影響但發生概率很低的風險不應該花太多的管理成本。而高影響且發生概率為中到高的風險以及低影響且高發生概率的風險，應該首先列入管理的考慮之中。
同時，對於有些已標出、評估及**過的風險可能也不納入風險管理的考慮。按照pareto的80-20規則，80%的軟體風險能夠由僅僅20%的已標出風險來說明。
隨著專案的進展，風險監控活動便開始了，風險監控是一種追蹤活動，主要有3個目標：
①事件和主要風險因素的跟蹤，判斷乙個**的風險事實上是否發生了；
②風險估計，確保針對某個風險制定的風險管理措施正在實施；
③收集可用於將來風險分析的資訊。
在例3-1中，應該監控：專案組成員對於專案壓力的一般態度，專案組的凝聚力；專案組成員之間的關係；與利益相關的潛在問題；在公司內外工作的可能性；等等。
3.2 進度安排
教學內容：進度安排的基本原則、工作量分配、pert技術、gantt圖技術。
教學重點：pert技術、gantt圖技術。
教學難點：pert技術。
教學方法：課堂講授+習題。
教學要求：掌握pert技術和gantt技術，了解進度安排的基本原則。
3.2.1 進度安排的基本原則
同軟體工程的其它方面一樣，有一些基本原則可以用來指導軟體專案計畫的進度安排。
①任務分解：將軟體工程專案的任務分解成易管理的子任務,即作業;
②作業依存：確保作業間的依存關係——順序和併發；
③時間分配：為每個作業指定開始和終止時間；
④資源約束：在進行時間分配時應考慮資源約束，如人員數量、工具；
⑤定義責任：應指定某特定小組負責某個作業；
⑥定義結果：對每個作業定義相應的結構——產品或產品的一部分；
⑦定義里程碑：每個作業或作業系列應與專案的里程碑相聯絡。
隨著專案進度的發展，上述每條原則都可能用到。
3.2.2 工作量分配
在可行性研究階段，通過成本估算方法獲得了完成某項軟體開發任務所需工作量的估計值。在制訂軟體專案計畫時，需要將工作量的估計值在軟體定義與開發階段進行分配。
另一種稱為「40-20-40規則」的工作量分配建議方案認為：在整個軟體開發過程中，編碼的工作量約佔20%，編碼前的工作量佔40%，編碼後的工作量也佔40%，顯然，這一工作量分配方案不強調編碼工作。實驗上，現在對於大型軟體專案而言，編碼的工作量所佔分額還在進一步縮小。
對實際開發的軟體專案進行統計表明；一般在計畫階段所需工作量很少超過專案總工作量的2%~3%，除非是具有高風險的巨資專案；需求分析可能占用專案工作量的10%~25%,用於分析或原型開發的工作量與專案規模和複雜度成正比增長；通常有20%~25%的工作量用於軟體設計，包括設計評審和迭代修改的時間；由於設計時投入了相當的工作量，使編碼工作變得相對簡單些，用15%~20%的工作量就可以完成；測試和隨後的除錯工作約佔30%~40%的工作量，且測試的工作量取決於軟體的質量特性要求，如可靠性程度等。
3.2.3 進度安排方法
軟體專案的進度安排與任何乙個工程專案的進度安排沒有實質上的不同。首先識別一組專案任務作業，建立任務作業之間的相互關聯，然後估算各個任務的工作量，分配人力和其它資源，指定進度時序。原則上可以把一般工程專案的進度安排方法和工具應用於軟體工程專案。
下面主要介紹兩種方法，pert技術和gantt圖方法。
1．pert技術
pert技術（program evaluation & review technique，pert） 又叫計畫評審技術。20世紀50年代後期，美國海軍和洛克希德公司首次提出這一技術，並成功地應用於北極星飛彈的研究和開發。幾十年來，它在許多任務程領域獲得了廣泛的應用，有時也因此稱之為工程網路技術。
2．gantt圖方法
gantt圖，又稱橫道圖，用水平線段來描述各作業的進度安排。一般在每一作業的起始時刻和約束時刻各畫乙個小三角形，當作業開始或結束時，把小三角形塗黑。gantt圖的橫軸列出的是日曆時間，縱軸列出的是作業名稱。
3.3 專案組織
教學內容： 人員組織規律、人員組織形式。
教學重點： 人員時間權衡定律、brooks定律。
教學難點：矩陣模式組織結構。
教學方法：課堂講授。
教學要求：了解人員組織規律，熟悉人員組織形式。
思考題：為何向已經延期的專案增加開發人員反而會使專案更加延期？為何軟體開發人員應該少而精？
3.3.1 人員組織規律
對於乙個軟體專案而言，單個軟體專業人員不可能在有限時間內單獨完成。如何合理地組織這些人員參與軟體的開發是專案成敗的關鍵。為此，軟體專案管理者應該重視軟體專案的人員組織規律，不能簡單地對待。
1．rayleigh-norden曲線
以rayleigh爵士的名字命名的曲線本來是用於解釋某些科學現象的。2023年，norden發現該曲線可用來說明科研及專案開發在實施過程中人力的需求。2023年,putnam又發現在軟體生存期各階段所需的人力分配具有與rayleigh曲線十分相似的形狀。
2．兩條定律
putnam在對raleigh曲線進行大量研究的基礎了，提出了putnam模型。該模型指出，軟體開發工作量與軟體開發時間的4次方成反比，putnam將這一結論稱之為「軟體開發的人員——時間權衡定律」。
3.3.2 人員組織形式
人員組織是一切軟體專案管理的關鍵。無法想象乙個鬆散、責任不明確的一夥人在一起可以高效地開發軟體。軟體開發機構選擇怎樣的人員組織形式，要針對軟體專案的特點和參與人員的素質來決定。
在建立軟體開發組織時，應注意：責任到人——盡早將責任落實，便於管理；合理分工——減少不必要的通訊，提高工作效率；責權均衡——責任與權力的平衡，有助於任務的完成。就軟體專案的組織結構而言，通常有兩種模式可供選擇。
（1）層次模式
層次模式是一種傳統的管理結構，每一層人員向上層報告工作並且管理下層的人員。
（2）矩陣模式
矩陣模式實際是層次模式的擴充套件，一方面每個專案有乙個專案經理管理，另一方面，每乙個專案又分為若干階段，按受階段經理的管理。
對於層次模式中的小組和矩陣模式中的子項的組織，主要有三種組織形式。
（1）主程式小組
主程式設計師小組組織形式最早由h. mills提出，並由baker描述出來，小組主要由以下人員組成：1名主程式設計師；2-5名技術人員；1名後備程式設計師。
（2）民主小組
2023年weinberg首次描述了民主小組的組織形式。民主小組一般由5-7人組成，其中1人兼任組長。民主小組的最基本概念是「無我程式設計」（egoless programming），人人把小組開發的程式看成是「我們的」程式，而不是「我的」程式。
遇到問題時，組員之間可以平等地交換意見，從而可以充分發揮每個成員工作的積極性。
（3）層次小組
在層次小組內，人員分成三個層次：專案負責人（組長）1人，負責全組的工作，直接管理2-3名高階程式設計師；每位高階程式設計師下屬若干名程式設計師，負責子課題的有關工作。
3.4小結
軟體專案計畫是繼可行性研究之後軟體工程管理的重要組成部分，主要內容包括風險分析、進度安排和專案組織。
風險分析是軟體專案計畫的乙個主要成部分之一。當對軟體專案期望很高時，均會進行風險分析活動，不過大多數軟體專案管理者會非正式地完成它。標識、估計、評價和管理風險有可能會占用較多的專案計畫工作量。
但由於經過風險分析，能夠做到「知已知彼」（彼即風險），從而「百戰不殆」，使得開發者能夠戰勝風險帶來的損失，使專案成功。
進度安排是軟體專案計畫的關鍵組成部分。實際工作中，進度安排的落空不僅會造成專案開發成本的提高，造成有形的經濟損失，而且會使客戶的不滿意度、不信任度增，造成有形的經濟損失。借助pert技術和gantt圖方法可以方便地進行軟體專案的進度安排。
專案組織是軟體專案計畫中與人直接相關的部分。在軟體開發過程中，人是最活躍的部分。如何最大限度地發揮每個開發人員的工作效率是軟體專案管理者應該積極重視的問題。
rayleigh-norden曲線，各類人員參與程度曲線，人員時間權衡定律和brooks定律等人員組織規律值得軟體專案管理者借鑑。一些成功的組織形式，如民主小組、主程式設計師小組和層次小組，軟體專案管理者可以根據專案的實際情況靈活運用。一般軟體專案計畫在需求分析後才能正式定稿，在軟體開發過程中可能還要隨實際情況不斷改變。
軟體專案計畫
專案名稱 c 2010 xx 資訊科技 版本歷史 檔案控制 本文件的任何內容變更需要sepg審批。本文件儲存在公司的sepg配置庫中，以供軟體部以及相關人員查詢使用。目錄1.專案介紹 4 1.1 專案範圍與目標 4 1.2 客戶與終端使用者介紹 4 1.3 開發方介紹 4 1.4 制約 5 2.專案...
軟體專案管理計畫
version 1.0 revision 目錄1.簡介 1 1.1 專案概述 1 1.2 專案交付產品 1 1.3 spmp的演化 1 1.4 參考資料 1 1.5 術語與縮寫 1 2.專案組織 1 2.1 過程模型 1 2.2 組織結構 2 2.3 組織介面 2 2.4 專案職責 2 3.管理過程...
軟體專案開發計畫
專案名稱 部門級文件管理系統 專案編號 編寫人員 編寫日期 2004 5 10 審批人員 審批日期 歷史修改記錄 1.引言 3 1.1.編寫目的 3 1.2.專案標識 3 1.3.專案背景 3 1.4.術語定義 3 1.5.參考資料 3 1.6.約束和假定 4 2.專案概況 4 2.1.專案產品 4...